This one is strange...
I have a server at home that's part of my home network (workgroup). It has SQL Server 2008 R2 SP1 running on it. I've been connecting to it from my (other) desktop regularly for months now and tonight all of a sudden I can't connect to it from my desktop. I can connect to it if I RDP onto the server and connect locally. I've checked the event logs on the server and nothing interesting appears.
Here's the (unhelpful) error returned by Management Studio from my desktop when trying to connect to the server:
Timeout expired. The timeout period elapsed prior to completion of
the operation or the server is not responding. (.Net SqlClient Data
Provider)
I'm kinda stumped by this really. I've tried connecting with sqlcmd - it tells me this:
Sqlcmd: Error: Microsoft SQL Server Native Client 10.0 : Unable to
complete login process due to delay in opening server connection.
Not really sure what that means. I've made sure SQL Server is configured to allow remote connections and have used netstat -a and seen that it's listening on port 1433 (for all IPs).
Anyone got any helpful ideas? I've rebooted the server too, but that didn't change anything.
EDIT/UPDATE: from my desktop I can ping the server by host name and I get something like this:
Reply from fe80::9077:4449:4b37:cad1%12: time<1ms
but if I try to ping it by it's IP address it times out. I wonder if that points to some kind of IPv4 vs. IPv6 issue?
Is the IP adress resolved from your desktop the actual ipadress of the server ?
Run a ipconfig /all from the server, and do a nslookup from your desktop to see if IP addresses are matching. I had cases when the DNS was messed up, and IP address resolution was wrong.
Related
I have SQL Server Express 2017 running on Windows Server 2016 Standard (default instance, not named). It has remote connections enabled and is listening on port 1433 and has TCP/IP and Named Pipes enabled. I have several Surface Tablets running Windows 10 and Windows 11. These tablets make a VPN connection to the server to connect to SQL Server. All of the tablets, except one of them, can connect to SQL Server. All tablets connect using the server's IP address and with SQL Server Authentication. All tablets are connected to the same WiFi router - both the ones that CAN connect and the one that CANNOT, so I believe router settings are not the problem.
The tablet that fails to connect can ping the server successfully. It cannot, however, telnet to port 1433 on the server - this times out. All other tablets can make the telnet connection. Also, using sqlcmd to connect (sqlcmd -S ip-address -U user-name -P password) works on all tablets except the one. This returns error 53. Checking the SQL Server logs after attempting to connect using sqlcmd shows no errors. So this tablet is definitely not even reaching SQL Server.
I have disabled all Windows Firewall options on the tablet with no change - still cannot telnet or connect via sqlcmd.
I have walked through multiple remote connection troubleshooting guides step by step, but most of them assume that NO remote systems can connect to SQL Server. In this case, it is just one system. So I know that the server is configured properly to allow remote connections. I just cannot determine what is different about this one tablet that is preventing it from making a connection.
What might be preventing this one system from making this connection? Any settings or other options I should be looking at?
SOLVED: After performing tracert on multiple systems that connect to this server including the problem tablet as well as attempting to telnet to various ports at the server's IP address, I discovered that the WiFi network that the tablet was on had a conflicting IP address with the server. The previous tablets that tested fine were, unbeknownst to me, on different wifi networks that did not have this conflict. As a result, this tablet was attempting to connect to a completely different device despite being properly connected to the server's network via VPN.
So the additional piece of advice to add to this troubleshooting process would be to very closely scrutinize the output of ipconfig /all. Even though you may be connected to the network of the SQL Server system you are trying to connect to remotely, if the IP of the SQL Server system is duplicated on your local network, it can be very difficult to see that all of your connection attempts are actually routing to a different system - that is why the connection is failing.
What to look for in ipconfig /all... check the client system's IP address and the default gateway that it is using. If these are using private IP addresses (as most do) most commonly starting with 192.168.x.x, and you are trying to connect to SQL Server over VPN via which the server also has a private IP address, check if your local subnet is matching the server's subnet. For instance, both the client (tablet) subnet and the server subnet were 192.168.20.x There's a chance for an IP address conflict in these conditions.
Another check that I found was helpful was, on the client, to DISCONNECT from the remote server and then try to ping the SQL Server IP address. If the ping succeeds, the server's IP address is being duplicated by another system.
I have a domain with 10+ clients. The server was rebooted recently, and upon reboot, two of the clients are receiving an error when attempting to access the SQL Server. The clients are running Win7 64bit with MS Office 2013 32bit. All the other computers have no issue.
The MS Access database uses linked tables to connect to the SQL Server 2008 R2 using Trusted Authentication. When opening the Access database, Access hangs for about 30 seconds before showing this error message:
Connection Failed; SQLState: 'S1T00'; SQL Server Error: 0;
[Microsoft][ODBC SQL Server Driver]Login Timeout Expired
When I click OK to clear the error, the SQL Login prompt appears. The server address is already entered, and we use a Trusted connection. Without changing any of the settings I click OK to the login prompt, and it connects to the database successfully.
Sites discussing the same problem (but without a solution that has worked for me):
SQLServerCentral -- Database Journal
(I'm limited by reputation and can't post additional links, but I also found a Google Groups post suggesting resetting Winsock. Another post on SQLServerCentral (Topic1245190-391-1) describes the same issue but has no clear solution)
What I Have Tried:
netsh winsock reset
netsh int ip reset resetlog.txt
netsh int ipv4 reset
sfc /scannow
Restarting the client computer
Run msaccess.exe as administrator
Confirm connection strings use server IP, not server name
Any help is appreciated!
I just ran into this problem. It's exactly as you posted. Access works locally on the same server as SQL, but on remote machines gave the S1T00 error. The problem was with the firewall. Needed to open port 1433.
Make the story short: Couple of the days one of the drivers in the raid started failing. After we changed the driver and rebuild it, we were not able to start SQL server. Therefore we re-installed it and restored all our DBs from backups.
Now, before hard drive crash and before the SQL was re-installed all our custom programs on the Win 2008 R2 server were able to connect to the remote SMTP host (like smtp.gmail.com) and send emails. We also used SQL database Mail and we reconfigured it, however we still receiving massages like "could not connect to mail server".
Is it possible that during SQL Uninstall some of windows services was stopped and now it cannot connect to a remote SMTP host. Where should I look and what should I try?
ok, I found my error. In the process of the server restoring I set wrong IP on one NIC and DNS was not reachable...
I'm so frustrated I'm going to give all of my rep points if someone can help me with this.
Scenario:
There was a domain name change and the development server had a SQL Server Express working. Since I have forgotten the SA password and was not able to login with any account from the new domain I decided to uninstall and re-install a new SQL Server 2008 R2 Express.
I installed SQL Server Express from WPI with management studio. After the installation I can open the local server with Management Studio, but cannot open from a remote Management studio.
What I did to try to figure out WTH is going on:
I made sure Remote connection was checked on the SQL Options "Connections"
I enable TCP/IP and Named Pipe on SQL Server Configuration for my instance SQLEXPRESS
I ensure that the port was OK on Properties of TCP/IP of the SQL Server Configuration, there were no value at first, so I manual entered 1433, stop, start the server, try to connect.
a) I even try playing with the Active / Enable value, and with a stop, start, re-try in between every any changes.
Disable the Windows Server 2008 firewall, even added a manual rules for 1433.
Make sure the instance name was good on hkey_local..\software\ms\sql\... and the one I see on the local Management Studio, it's SQLEXPRESS
I can ping the server with its name or ip address, I even tried to connect with the IP address as well.
I'm just trying to connect from another server with another Management Studio, and here is the error I get:
Cannot connect to DEVSERVER\SQLEXPRESS.
ADDITIONAL INFORMATION:
A network-related or instance-specific error occurred while
establishing a connection to SQL Server. The server was not found or
was not accessible. Verify that the instance name is correct and that
SQL Server is configured to allow remote connections. (provider: SQL
Network Interfaces, error: 26 - Error Locating Server/Instance
Specified) (Microsoft SQL Server, Error: -1)
The server is a Windows Server 2008 x64
What a time waster
TIA for any tips, can't believe what's happening.
UPDATE:
I telnet from the remote server on port 80 just to make sure it's not a network problem, and I got HTML result, since firewall is disabled, and tcp/ip is enabled, SQL Browser started, Remote connection is activated it's hard to put the finger on what's not OK.
We had the same problem, finally figured out that a dynamic port entry has to be given along with the SQLExpress login .. ie 192.168.1.25\SQLEXPRESS,45490... then it allowed the login to happen.
We had installed a new SQLEXPRESS 2008 R2 (Windows 7 Professional Edition) in a new machine & was trying to connect to this DB from another machine from the mgmt studio and it was not connecting, nor was it connecting from any of the client machines.
We tried to check the SQLEXPRESS Browser / TCPIP was enabled and spent couple of hrs before we we figured out that the Dynamic port was causing this issue.
You can find this information, Open the SQLEXPRESS Configuration Manager, Select SQL Server Network Configuration on the left menu![Configuration Manager][1]
Select Protocol for SQLEXPRESS
You will find the TCPIP Enabled on the right side, click on the TCPIP and select properties
go to IPALL .. you will find the dynamic port info there.
btw, we tried installation on two HP PCs had the same issue & was solved with the dynamic port, while when we tried the installation on the ACer PC - did not get this dynamic port issue - so not really sure if it had anything to do with the OEM OS setup !?
However, the above solved our situation.
Last time this has happened to me, it was because I forgot about the SQL Server Browser service.
Did you try these steps: http://blogs.msdn.com/b/sqlexpress/archive/2005/05/05/415084.aspx ?
SQLEXPRESS is named instance, so it doesnt listen on 1433 port (it's for default instance). Try this:
Disable firewall
Start SQL Browser
Try to connect from remote machine
My problem solved by using the server configuration manager to disable the dynamic port (blank = disable), and fix the port to 1433
When I connect to the SQL Server 2008 remotely it only works once, after that the server hangs. The service cannot be stopped or restarted and when trying to connect again it gives a 'Timeout' error.
The server has TCP/IP connections enabled. The default port is set to 1433 and I cleared the 0 from the dynamic ports. I enabled the 127.0.0.1 IP and the public IP and set the 1433 IP to them. Named pipes and the other protocol (Shared Memory or something) are disabled.
I am connecting from the remote machine using the 'sa' user and a strong password. The server is set to accept both authentication modes.
Connecting for the first time from the remote machine works perfect. Queries work and data can be retrieved from the databases. After disconnecting and trying to connect again it gives a timeout error. This error is generated because the SQL Server is hanged somewhere.
At this point it is impossible to Stop or Restart the SQL Server service from the service machine. The only solution is to restart the computer. However, connecting to the server locally from SQL Management Studio still works.
I think it has something to do with going into an infinite loop somewhere, or it doesn't drop the connection on the 1433 port after disconnecting from the remote machine and it still waits for input from it.
have you ruled out anything at the network layer such as software or hardware firewalls, NAT'ing, proxies ect?
Are you running SQL Server as a default or named instance?
if you do a netstat while things are working & then when you get a time out, what do you see?
Try running network monitor or wireshark on the server to see if the request is getting through & if so is the server responding?
EDIT:
It's a bit of a concern that you can connect to the server on port 1433 when sql server isn't running you should be getting a connection refused (no firewall) or a timeout (with a firewall)
Run profiler on the server & audit logins/logouts you should be able to see the client connect? it may help you troubleshoot the issue?
Try a blunt instrument like re-installing the sql server connectivity driver eg. mdac, sql native on the client.