galcott1
asked on
SQL Server 2008 remote connection problem
I was trying to establish a remote connection to SQL Server 2008 from another machine on my network. The server is running the XP firewall. I thought I had everything set up correctly on the server (TCP/IP enabled, remote connections enabled, TCP port 1433 enabled on the firewall). The remote connection repeatedly failed. Based on some information I found on another site, I tried to telnet from the workstation to that machine on port 1433 (telnet 192.168.15.102 1433) and got a message "no connection could be made because the target machine actively refused it". If port 1433 was open why would this happen? I finally set up an exception in the firewall for the SQL Server program (sqlserver.exe) and then the remote connection worked. But I wonder why this was necessary; I have never seen it happen before with previous versions of SQL Server.
Anthony Perkins
Perhaps it is not the default instance and therefore using another port?
ASKER
It is the default instance; that's how I installed it.
If its the default instance, then try the below steps:
1. In Surface Area Configuration Manager, check whether remote connections are enabled or not.
2. In Surface Area Configuration Manager, check whether SQL Browser Service is up and running.
3. In Surface Area Configuration Manager, check whether Transport Protocols, Both Named pipes and TCP/IP is enabled or not.
4. In SQL Server Configuration Manager, under Transport Protocols check whether TCP/IP is enabled( as per your statement it is enabled). Click on the another tab on it and check whether TCP / IP Dynamic ports are set to blank.
And check whether TCP/IP port is set to 1433.
5. If you do any changes, Restart the SQL Server Services
I hope now it is done.
1. In Surface Area Configuration Manager, check whether remote connections are enabled or not.
2. In Surface Area Configuration Manager, check whether SQL Browser Service is up and running.
3. In Surface Area Configuration Manager, check whether Transport Protocols, Both Named pipes and TCP/IP is enabled or not.
4. In SQL Server Configuration Manager, under Transport Protocols check whether TCP/IP is enabled( as per your statement it is enabled). Click on the another tab on it and check whether TCP / IP Dynamic ports are set to blank.
And check whether TCP/IP port is set to 1433.
5. If you do any changes, Restart the SQL Server Services
I hope now it is done.
ASKER
Everything seems correct but I am not sure about the ports. Attached is a screen shot of the TCP/IP properties screen. Does this look correct? How do I check whether the SQL Server TCP port is set to 1433? Thanks.
tcp.jpg
tcp.jpg
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I did that and it worked. But what I don't understand is why wasn't it set up that way when SQL Server was installed? Port 1433 is supposed to be the default. Check out this Microsoft article which confirms that:
http://msdn.microsoft.com/en-us/library/cc646023.aspx. This problem never occurred in previous versions of SQL Server. Whatever they have done now just makes it more difficult to set up.
http://msdn.microsoft.com/en-us/library/cc646023.aspx. This problem never occurred in previous versions of SQL Server. Whatever they have done now just makes it more difficult to set up.
>>This problem never occurred in previous versions of SQL Server<<
Most users prefer to err on the side of caution, hence the added security.
>>Whatever they have done now just makes it more difficult to set up.<<
See here http://www.robkerr.com/post/2008/07/Windows-Firewall-and-SQL-Server-2008.aspx
Most users prefer to err on the side of caution, hence the added security.
>>Whatever they have done now just makes it more difficult to set up.<<
See here http://www.robkerr.com/post/2008/07/Windows-Firewall-and-SQL-Server-2008.aspx
ASKER
The problem I have with this is directly contradicts the MS documentation, as far as I can see. The article I mentioned above, in reference to port 1433, says "This is the most common port allowed through the firewall. It applies to routine connections to the default installation of the Database Engine, or a named instance that is the only instance running on the computer.". That article was ever referenced in a popup message somewhere during the installation of SQL Server 2008. Also, in the SQL Server Books Online page about configuring ports, it states "If enabled, the default instance of the SQL Server Database Engine listens on TCP port 1433". That seems crystal clear but it's not installed that way. And my installation was a default instance. So what's going on here?
galcott,
What you have referred over there is correct.
SQL Server is configured to listen port no 1433 by default.
But in your Windows Firewall, all ports will be blocked by default.
Hence you have to add an exception in Windows Firewall for the port 1433 to listen to communications from other server.
Kindly try the below steps for it.
1. Go to Control Panel --> Windows Firewall.
2. Navigate to Exceptions Tab.
3. Click Add Port and Type 1433 for TCP port and name it as SQL Server.
The above successfully allows you to listen on the port 1433
What you have referred over there is correct.
SQL Server is configured to listen port no 1433 by default.
But in your Windows Firewall, all ports will be blocked by default.
Hence you have to add an exception in Windows Firewall for the port 1433 to listen to communications from other server.
Kindly try the below steps for it.
1. Go to Control Panel --> Windows Firewall.
2. Navigate to Exceptions Tab.
3. Click Add Port and Type 1433 for TCP port and name it as SQL Server.
The above successfully allows you to listen on the port 1433
ASKER
My whole point is that the SQL Server was NOT configured on port 1433. I had the exception set from the beginning. Please re-read my original message.
Then kindly do one thing..
Execute the system procedure sp_readerrorlog.
And in one of the resultset, you will be able to find keywords like
"Server is listening on Port xxxx"
That is the port in which your server instance is listening upon.
If you telnet from that port, then you will be able to get through it.
Execute the system procedure sp_readerrorlog.
And in one of the resultset, you will be able to find keywords like
"Server is listening on Port xxxx"
That is the port in which your server instance is listening upon.
If you telnet from that port, then you will be able to get through it.
ASKER
As I told you before, I changed the ports to 1433 in response to your previous reply and it worked. Since then I have just been trying to figure out why it works so differently from the way it is documented.