March 21, 2008 at 7:37 pm
Hello;
I am having a problem that I can't seem to resolve.
I have an instance of SQL 2005 that will not establish a connection to another instance of SQL 2005 in one direction (Server1->DevStation1).
What I receive when connecting one instance (Server1) to another (DevStation1) using SSMS is the general error:
An error has occurred while establishing a connection to the server. When connecting to SQL Server 2005, this failure may be caused by the fact that under the default settings SQL Server does not allow remote connections. (provider: TCP Provider, error: 0 - No connection could be made because the target machine actively refused it.) (.Net SqlClient Data Provider)
Error Number: 10061
Severity: 20
State: 0
What makes this situation frustrating is that DevStation1 instance *can* connect to the Server1 instance (DevStation1->Server1) using SSMS, and all the other SQL instances can connect to each other in any way without any problem. It is only the one connection in that one way (Server1->DevStation1) that is the problem. I have gone as far as uninstalling and reinstalling MS SQL 2005 on the Server1 instance to clear any problems but the one way connection problem persists after re-installation.
There are no other problems in the environment and no errors in the SQL or Event Manager logs.
This leaves me to believe that there is a setting stuck somewhere or the connection is failing at a point that I can't see. I was hoping someone here might have some ideas. I am looking to test a Database Mirroring High availability solution and I want to use DevStation1 as the witness, so I need Server1 to connect with it.
Thanks!
---
As a backgrounder, here is a brief description of the SQL enviroment:
Server1/Server1 SQL 2005 SP2 (Dev Ed) Windows 2003 SP2 (test.local)
Server1/Server1 SQL 2005 SP2 (Dev Ed) Windows 2003 SP2 (test.local)
DevStation1/DevStation1 SQL 2005 SP2 (Dev Ed) Windows XP PRO SP2 (test.local)
DevStation2/DevStation2 SQL 2005 SP2 (Dev Ed) Windows XP PRO SP2 (test.local)
The SQL 2005 SP2 (Dev Ed) are vanilla and everything is genuine software. Everything talks with TCP/IP and every computer sees one another in the domain.
DevStation2 and DevStation2 are configured as per MS KB914277 article for access through the Win XP firewall, and the SAC is configured to allow remote connections. Server1 and Server2 have both been configured with the SAC to allow remote connections.
As mentioned DevStation2 is configured identically to DevStation1 and has no issues connecting or being connected to any of the other instances in the SQL environment.
March 21, 2008 at 10:26 pm
Are they in different domains? and if so what is the trust relationship?
[font="Times New Roman"]-- RBarryYoung[/font], [font="Times New Roman"] (302)375-0451[/font] blog: MovingSQL.com, Twitter: @RBarryYoung[font="Arial Black"]
Proactive Performance Solutions, Inc. [/font][font="Verdana"] "Performance is our middle name."[/font]
March 21, 2008 at 11:02 pm
Same domain, all computers have no problem seeing or communicating with each other as far as I can tell (no problems). Same IP subnet as well for what it is worth.
I have been trying to figure out what may be broken in the connection process. I have been running WireShark packet capture on the DevStation1 and Server1. In the connection problem (Server1->DevStation1) authentication packets are being exchanged from the server and arrive to the devstation. Still analyzing the results.
Based on what I am seeing though it might be the SQL 2005 Instance on the Devstation1 that is having the problem. Even though the XP firewall and SAC are configured properly, it may not be authenticating properly using SQL Logins (sa). Something might be broken...
I am tempted to reinstall SQL 2005 SP2 and see if that might solve the problem.
March 22, 2008 at 2:36 pm
I re-installed SQL 2005 SP2 and there an error during the re-installation about an administrative rights error on a COM object. After the SP re-installation the the connection problem was resolved. Looks like there was a change in the local system environment or something corrupted.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply