| Author |
 Topic  |
|
|
Curt
Moderator
USA
6659 Posts
Status: offline |
 Posted - 01/03/2012 : 9:53:05 PM
|
Client needs me to connect a stand alone web server outside of the domain to a SQL 2005 server inside the domain.
There are two web servers. The first one is Windows 2003, with no internal firewall. There is a local admin account and password that match the same local user name and password on the SQL server. That account is given the rights to the databases needed to connect via an ODBC conection it works.
On the Windows 2008 R2 box I cannot connect.
Hard to see what can be wrong.
I loaded the SQL 2005 native cliend on the 2008 server.
Tried different user names.
TCP and named sockets.
Nothing yet. Any idea.
|
Curt Spanburgh
Microsoft Certified Business Solution Specialist.
Dynamics CRM MVP
Contributing Editor, Windows IT Pro
He that is walking with wise persons will become wise, but he that is having dealings with the stupid ones will fare badly.
Proverbs 13:20
|
|
|
Wiseman82
Old Timer
United Kingdom
520 Posts
Status: offline |
Posted - 01/04/2012 : 03:39:47 AM
|
I would make sure mixed mode authentication is enabled and give SQL authentication a try to see if that works. I haven't tried "workgroup" style authentication with SQL Server before - I'm guessing it probably should work, but I'd give SQL authentication a try to rule that out as an issue.
Also, is this a default instance? If it's not, try specifying the port used in the connection. Also, what error do you get when you try to connect?
You mentioned that there are two web servers - are both of these outside the domain, but one is running SQL 2008 instead of 2003? The 2003 is able to connect? Is the firewall enabled on the 2008 instance?
|
David Wiseman
MCSE (2000/2003), MCSA (2003), MCDBA, MCITP:Database Administrator
 |
 |
|
|
Playwell
Honorable But Hopeless Addict
Netherlands
4832 Posts
Status: offline |
Posted - 01/04/2012 : 07:45:06 AM
|
try to name the machine name of the sql server:
<machine>\account |
'People who think they know everything are a great annoyance to those of us who do. '
Quote by Isaac Asimov
|
|
|
|
Curt
Moderator
USA
6659 Posts
Status: offline |
Posted - 01/04/2012 : 10:04:07 AM
|
I will give these a try. But I will also have to figure out a way to check the PIX to PIX configuration between the firewalls in Seattle and Carlsbad, CA.
The "Project Manager" thought that he just needed a Great Plains person to run an MSI and run the wizard.
Ha!!!!
When is anything easy.
Will report back ASAP.
|
Curt Spanburgh
Microsoft Certified Business Solution Specialist.
Dynamics CRM MVP
Contributing Editor, Windows IT Pro
He that is walking with wise persons will become wise, but he that is having dealings with the stupid ones will fare badly.
Proverbs 13:20
|
|
|
|
Playwell
Honorable But Hopeless Addict
Netherlands
4832 Posts
Status: offline |
Posted - 01/04/2012 : 11:44:24 AM
|
By default 1433 is all you need
The asa's are being difficult when you try to telnet on that port, because they are statefull firewalls and a telnet is not very applicationlike.
You could try t4eportping
|
'People who think they know everything are a great annoyance to those of us who do. '
Quote by Isaac Asimov
|
|
|
|
Curt
Moderator
USA
6659 Posts
Status: offline |
Posted - 01/04/2012 : 6:17:44 PM
|
OK, using the SQL native client 10.0 I get SQLSTATE: '80001'
Microsoft SQL server native client 10.0 TCP Provider: No Such host is known.
SQL State: 'HYT00'
SQL Server Error :0
then using the Windows 2008 SQL client and the ip address of the SQL server.
SQLState: '28000'
SQL Server error ; 18452
Odbc SQL server Driver Login failed for the user. The user is not associated with a trusted SQL Server connection.
using the name of the server SQL2005 I get:
SQLState: '01000'
SQL Server error: 11001
Odbc SQL server Driver Login failed for the user.
SQL State: '80001'
SQWL server error:6
ODBC SQL Server Driver Tcp/oip sockets specified SQL server not found.
I added the ip and server name to the host file.
Can't resolve the name.
It's a network error.
|
Curt Spanburgh
Microsoft Certified Business Solution Specialist.
Dynamics CRM MVP
Contributing Editor, Windows IT Pro
He that is walking with wise persons will become wise, but he that is having dealings with the stupid ones will fare badly.
Proverbs 13:20
|
|
|
|
JamesNT
Moderator
USA
3151 Posts
Status: offline |
Posted - 01/04/2012 : 9:15:13 PM
|
Working with Curt, we got the ODBC problem resolved. However, the machine connecting is Windows Server 2008 64-bit machine. Great Plains 9.0 will not run on this OS.
Official Blog Post: http://blogs.msdn.com/b/gp/archive/2009/08/04/windows-7-and-dynamics-gp-compatibility.aspx
Note: When Curt and I noticed that the eConnect component required MDAC 2.7 SP1 we pretty much knew the deal.
The client will need to do one of the following:
1. Downgrade the server.
2. Remove all other roles/features from this server and make it a Hyper-V machine then install Server 2003.
3. Upgrade Great Plains to version 10.
I would say option 2 is the most viable.
JamesNT |
James Summerlin
www.jamessummerlin.com |
Edited by - JamesNT on 01/04/2012 9:20:12 PM |
|
|
|
jantanik
Welcome Newcomer
USA
3 Posts
Status: offline |
Posted - 01/05/2012 : 12:26:45 AM
|
I would suggest you to go through the following link, i hope it may helpful to you.
support.microsoft.com/kb/231812 |
|
|
|
AnthonyBell
Welcome Newcomer
1 Posts
Status: offline |
|
|
Curt
Moderator
USA
6659 Posts
Status: offline |
Posted - 04/03/2012 : 09:04:26 AM
|
Thanks.
I can telnet to both PIX boxes in both locations now.
quote:
Originally posted by Playwell
By default 1433 is all you need
The asa's are being difficult when you try to telnet on that port, because they are statefull firewalls and a telnet is not very applicationlike.
You could try t4eportping
|
Curt Spanburgh
Microsoft Certified Business Solution Specialist.
Dynamics CRM MVP
Contributing Editor, Windows IT Pro
He that is walking with wise persons will become wise, but he that is having dealings with the stupid ones will fare badly.
Proverbs 13:20
|
|
|
| |
Topic |
|
ODBC error
