How to Configure SQL Server Port on Multiple Instances

This sounds like a network problem; if the other remote clients can access the instance then it seems unlikely it is an instance-specific problem.

1. Be sure that firewalls on the notebooks are turned off or (better) are allowing TCP traffic through the port your server is using.

2. If you are connecting using the server's host name or machine name, make sure it resolves to the correct IP from the notebooks. Try this from a command prompt on the notebooks:

   C:\> ping my.databaseserver.com
   

   or

   C:\> ping OUR_SQLSERVER 
   

   In the output the IP address to which my.databaseserver.com/OUR_SQLSERVER resolves will be displayed.

3. See if you can connect directly via TCP to check for misconfiguration of the SQL clients. On the notebooks, type this at a command prompt:

   C:\> telnet 192.168.1.200 1433
   

Substitute your SQL Server's IP and the port it is using. The reply you get will not be readable, but unless you get a message like Could not open connection to the host, on port 1433: Connect failed, you are at least able to connect to the server.

Hope this points you toward a resolution.

This is an extremely common error, with literally millions of search results online. The typical troubleshooting steps include:

• Make sure the SQL Server service is actually running (SQL Server Configuration Manager > SQL Server Services > check the State of the specific instance and make sure it says "Running", otherwise right-click > Start).
• Make sure the SQL Server Browser service is running, you can check this in Configuration Manager as above, or using sc query sqlbrowser from the command line (if it is not running, right-click > Start or run net start sqlbrowser from the command line).

• If you are trying to connect to a different machine (or using a name that forces you to route outside of your machine for some reason), make sure the server is configured to allow remote connections. You can fix this by using remote desktop to connect to that server and running this locally:

  EXEC sys.sp_configure N'remote access', 1;
  GO
  RECONFIGURE WITH OVERRIDE;
  

  Of course this might be hard to do if it's the local instance you can't connect to, so you'll have to get connected locally using other steps in this list first before you'll be able to talk to the server to change this setting.

• Make sure the port SQL Server is running on is open, and that TCP/IP is enabled (SQL Server Express Edition, for example, expects Named Pipes for remote connections by default). You can see this in Configuration Manager > SQL Server Network Configuration > Protocols for <instance name> > TCP/IP, right-click, properties, IP Addresses tab, scroll all the way down to see (a) that TCP/IP is enabled (and if not, right-click > Enable, may as well try enabling Named Pipes too), and check what port is listed under IPAll > TCP Dynamic Ports or TCP Port. Note that if it's using dynamic ports, that port could change, and if SQL Browser is not configured to start automatically, you'll be right back here potentially on your next reboot.
• Make sure the server name is correct, and be sure to try IP address, simple server name, and fully-qualified domain name. If the server is local, try localhost and 127.0.0.1 in addition to the server name. Make sure you can traceroute/tracert to the server and telnet to the running port. If you can connect to one of these hosts but not others, either change your connection string, change your hosts file and/or DNS, or consult your network administrator.
• Make sure the instance name is correct. Often people type their machine name and don't realize that they are trying to connect to a named instance, which requires syntax like server_name_or_ip\SQLEXPRESS - a common one as SQLEXPRESS is typically the instance name in use when running SQL Server Express Edition.
• If you can't connect using any of those methods, it is likely a firewall issue. You'll need to determine which ports to open and for whom (of course your SQL Server should be secured from external traffic whenever possible), but you can quickly test if this is the problem by momentarily disabling the firewall altogether.

A lot of this is documented much more elaborately here (found in Paul White's wiki post here):

• How to Troubleshoot Connecting to the SQL Server Database Engine