4

I've been working solidly on this issue for the past three weeks. I cannot seem to find where the actual issue is.

I just recently found this article on how to troubleshoot the connection. I made it down to step 4 on the client machine and telnet failed. What would be the next recommended step in the process?

I've already gone onto the server and changed the TCP Port option under IP2 and IPALL in Server Configuration Manager with no change. Thanks in advance to anyone who can fix the issue that this machine is having.

edit: I left out a bunch of details...

  1. There is no firewall installed on either machine
  2. No anti-virus is installed on either machine
  3. I have checked and rechecked the IP address of the machine I'm trying to ping
  4. The port is forwarded in the router
  5. The command I used to check the connection was: telnet XXX.XXX.XXX.XXX 1433
  6. It returned with: Could not open connection to the host, on port 1433: Connect failed

Here was the result of the netstat command: screenshot

So the question is, which one do I use?

Ian Kemp
  • 119
  • 10
Otacon
  • 41
  • 1
  • 1
  • 5
  • Is the SQL Server service running, and can you verify that it's listening on the correct port with `netstat`? Are there any firewalls between the client that you're testing from and the server? – Shane Madden Aug 29 '12 at 19:32
  • 1
    1. Run netstat on the server and verify that SQL server is "listening" on the port you expect it to be. 2. Verify that the Windows firewall on the server (if it's enabled) has an inbound rule that allows incoming connections to the port that SQL is "listening" on. 3. Telnet to the SQL port from the server itself. This will confirm whether or not it's a server problem or a network problem. – joeqwerty Aug 29 '12 at 19:34
  • 1
    Read the _rest_ of the article you linked, as well. – Michael Hampton Aug 29 '12 at 19:35
  • The netstat command by itself (no options used) only shows active connections. You need to see all of the "listening" ports as well. Run "netstat -a -n -o" to see all of the listening ports as well as the active connections. This will also show you the PID associated with a particular "listening" port (or active connection) which will allow you to verify that the SQL server process (based on it's PID as viewed in Task Manager) is in fact "listening" on the correct ip address and port. – joeqwerty Aug 29 '12 at 19:55
  • What specific process am I looking for? Am I looking for sqlservr.exe? – Otacon Aug 29 '12 at 20:01
  • I went ahead and took another screenshot. This is what I got out of it: [screenshot](http://i48.tinypic.com/2ueh84x.jpg) – Otacon Aug 29 '12 at 20:07
  • Based on the second screenshot it looks like you have 2 instances of SQL running and one of them is listening on port 1433. It's also listening on another port as well, maybe that's Analysis Services? At any rate, try to telnet from the server to itself on port 1433. – joeqwerty Aug 29 '12 at 20:26
  • I used both the loopback IP and the actual IP and both came back without error, so I'm pretty sure the server itself is broadcasting and listening. – Otacon Aug 29 '12 at 20:56

0 Answers0