May 14, 2007 at 6:48 am
Hello all,
I am using Management Studio to connect to a SQL Server 2005 Standard Ed + SP1.
MStudio returns the following message:
------------------------------
Cannot connect to 'servername'
A connection was successfully established with the server, but then an error occurred during the login process. (provider: TCP Provider, error: 0 - The specified network name is no longer available.) (Microsoft SQL Server, Error: 64)
------------------------------
The setup:
I run the Managament Studio from my laptop.
The server on which SQL Server 2005 runs is a Vmware guest, OS W2003 SP1.
Local and Remote connections are defined as 'Using TCP/IP only'
What I tried:
I tried to connect using only the ip-address; this results in the same error.
I can ping this server.
I tried SQLPing2 (by Chip Andrews, http://www.sqlsecurity.com); this tool does not detect the server.
I tried SQLCMD; this results in the following error:
HResult 0x40, Level 16, State 1
TCP Provider: The specified network name is no longer available.
Sqlcmd: Error: Microsoft SQL Native Client : Communication link failure
Does any of you have experience with this type of behaviour?
Thanks.
Hans
May 16, 2007 at 12:10 pm
Try to connect on Named Pipes. If Named Pipes connect then it is a Firewall issue
Regards,Yelena Varsha
May 18, 2007 at 5:57 am
Thank you for the reply Yelena.
I used Configuration Manager to enable Named Pies, and restarted the service, but it did not help.
I checked the Application log on the server, and it shows the following:
---------------------------
The login packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library. [CLIENT: 'ip-address']
---------------------------
I'm totally at a loss here.
regards,
Hans
May 18, 2007 at 11:10 am
Hans,
did you create a client network utility entry or a client entry for your server in Configuration Manager on your Client? you have to have Named Pipes enabled on the server AND have a client alias for Named Pipes on your client.
Regards,Yelena Varsha
May 21, 2007 at 3:19 am
Hello Yelena,
I was not aware of the need for that.
Following your advice I created an alias on my client machine, pointing to the server that I want to access, via Named Pipes. Named Pipes is enabled on the server (which had a restart after I enabled Named Pipes).
I still get the same error.
regards,
Hans
May 21, 2007 at 11:02 am
Hans,
Please, try to do the following in the command prompt from the client computer
telnet servername 1433
telnet servername 445
where servername is you server name. 1433 is the default port for SQL Server, 445 is a port for Named Pipes
also post here the beginning of the SQL Server error log on the server with the following lines. These lines should be about 20 lines from the top of the Errorlog file. The file is located at: C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\LOG in the default installation. Instead of C: it could be any other drive letter and folders depending on where did you install SQL Server. These lines will tell us the ports, protocols and names, especially if it is a named instance.
2007-05-21 10:25:40.11 spid5s Server name is 'MyServerName. This is an informational message only. No user action is required.
2007-05-21 10:25:40.11 spid9s Starting up database 'model'.
2007-05-21 10:25:40.12 Server Server is listening on [ 'any' <ipv4> 1433].
2007-05-21 10:25:40.12 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\MSSQLSERVER ].
2007-05-21 10:25:40.12 Server Server local connection provider is ready to accept connection on [ \\.\pipe\sql\query ].
2007-05-21 10:25:40.13 Server Server is listening on [ 'any' <ipv4> 1434].
2007-05-21 10:25:40.13 Server Dedicated admin connection support was established for listening remotely on port 1434.
2007-05-21 10:25:40.15 Server SQL Server is now ready for client connections. This is an informational message; no user action is required.
2007-05-21 10:25:40.22 spid12s Starting up database 'msdb'.
2007-05-21 10:25:40.22 spid13s Starting up database 'ReportServer'.
Regards,Yelena Varsha
May 22, 2007 at 2:20 am
Yelena,
I tried the telnet; in both cases I get a blank screen, and a blinking cursor. When I type and press enter, no reply.
The part of the log you mentioned in the previous mail looks like this:
2007-05-18 13:50:45.87 spid5s Server name is 'YOTC-AS76'. This is an informational message only. No user action is required.
2007-05-18 13:50:46.31 spid9s CHECKDB for database 'model' finished without errors on 2007-05-18 00:15:21.850 (local time). This is an informational message only; no user action is required.
2007-05-18 13:50:46.32 spid9s Clearing tempdb database.
2007-05-18 13:50:46.95 spid9s Starting up database 'tempdb'.
2007-05-18 13:50:47.01 spid9s CHECKDB for database 'tempdb' finished without errors on 2007-05-18 00:15:21.850 (local time). This is an informational message only; no user action is required.
2007-05-18 13:50:47.04 spid12s The Service Broker protocol transport is disabled or not configured.
2007-05-18 13:50:47.04 spid12s The Database Mirroring protocol transport is disabled or not configured.
2007-05-18 13:50:47.09 spid12s Service Broker manager has started.
2007-05-18 13:50:47.20 Server The certificate was successfully loaded for encryption.
2007-05-18 13:50:47.26 Server Server is listening on [ 'any' 1433].
2007-05-18 13:50:47.28 Server Server local connection provider is ready to accept connection on [ \\.\pipe\SQLLocal\MSSQLSERVER ].
2007-05-18 13:50:47.28 Server Server named pipe provider is ready to accept connection on [ \\.\pipe\sql\query ].
2007-05-18 13:50:47.29 Server Server is listening on [ 127.0.0.1 1434].
2007-05-18 13:50:47.29 Server Dedicated admin connection support was established for listening locally on port 1434.
2007-05-18 13:50:47.37 Server SQL Server is now ready for client connections. This is an informational message; no user action is required.
2007-05-18 13:50:49.14 spid17s Starting up database 'Measurements'.
----------------
I see one difference: at timestamp 13:50:47.29, it shows it is listening on 127.0.0.1, instead of 'any'.
I checked the TCP/IP properties on the server; IP1 shows the ip-address of the server. IP2 shows 127.0.0.1
Could this have anything to do with it?
regards,
Hans
May 22, 2007 at 2:27 am
BTW: in the error log the ipv4 shows up; as I just did a copy/paste it did not show in the previous post (because of the brackets it is interpreted as a html tag probably).
May 22, 2007 at 9:17 am
The "blank screen" and "blinking cursor" means that you are successfully connecting to either port. I'm guessing that this is not a SQL Server problem and instead is an issue with VMWare. What version are you hosting your SQL Server on? Is it on your local machine? How is the network configured?
May 22, 2007 at 9:35 am
Hello Michael,
We have a couple of hardware servers on which we run Vmware ESX.
These servers host a couple of vmware guests; those guests have SQL2005 installed.
I can connect to most of these guests via Windows authentication, but there are a few that return the error I mentioned before.
Something new came up today; I rebooted the troubling server and connected to it via a SQL Server account, and this succeeded!
For the moment I'm ok I guess, but I'm still puzzled why I can't connect to the server via Windows authentication.
May 22, 2007 at 2:25 pm
Hans,
Your log is OK, Michael already explained to you that your telnet worked, so port 1433 that is indicated in the log is open and named pipes probably work. Check for the status of NetLogon service if it is started - one of my servers had NetLogin service down today, nobody could do Windows authentication mapping a share. Also try telnet command using Kerberos port 88. See this article for more ports to test.
http://technet.microsoft.com/en-us/library/bb125069.aspx
Configuring an Intranet Firewall
Regards,Yelena Varsha
October 17, 2007 at 5:38 pm
Sometimes, especially in a VM env, the firewall can cause these problems. In the firewall on the server allow it to open port 1433, what SQL SErver uses to listen to connections ...also .. are you trying to connect to the default instance?, if not make sure 'sql server browser service' is running on the server.
[View this on the server ...Start > Run > services.msc ]
----------------------------------------------------
October 17, 2007 at 7:03 pm
tcp/445 is a generic port, so you can't assume that because you can connect to it SQL Server allows you to connect via Named Pipes. With regards to SQL Server and TCP/IP, the error log tells you if it can establish a listening session on the respective tcp port (in a default instance this is 1433 unless you've changed it). Also, unless the network card is set not to be connected, this is probably not a VMware issue if you can ping it. If you couldn't ping it, I'd say check the virtual NICs VMware creates on your system (the host system) and make sure they are properly enabled and that all the VMware services are running.
There's a couple of things you can do from the server when this sort of thing happens. First, run netstat -ano and get the PID for 0.0.0.0:1433 (or whatever the listening port is). Bring up Task Manager and make sure this PID matches sqlservr.exe. If it doesn't, something else grabbed the listening port and SQL Server can't use it. Run Profiler and configure the Audit Login Failure event. Then make a connection and see if it is even getting through. If it is and you see the event fire when you try to connect, then there is an authentication issue, not a network issue. If you don't see a connection, always check your firewall. When not managed via a GPO, we have sometimes seen the firewall activate after something as simple as a different user logging on to the system. The system will still usually ping but nothing else happens.
K. Brian Kelley
@kbriankelley
October 17, 2007 at 7:07 pm
Yelena Varshal (5/22/2007)
Also try telnet command using Kerberos port 88.
On a normal member server this port is not enabled. This should only be on when the Kerberos Key Distribution Center (KDC) service is enabled and running. That service only runs on domain controllers. Therefore, unless SQL Server is on a DC (not recommended), if something is listening on this port, it isn't Kerberos related (and probably should be investigated).
For more on the KDC service with regards to member servers, see here:
K. Brian Kelley
@kbriankelley
August 1, 2011 at 5:28 am
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply