We recently took our Sql Server box off-line, installed a new hard drive,
then re-installed Sql Server 2000. A client who was able to connect fine
through EM/QA prior to the re-install is now unable to successfully register
the sql server - he keeps getting 'Sql Server does not exist or Access
Denied' error.

There is no domain conflict, no IP address blocking, and we have double
checked login/password/roles/permissions - cannot find anything wrong. Even
sa cannot do a successful registration through Client machine. This client
can ping the server and vice versa. He can also access the server throuh
Remote Desktop Connection. If he types '\\ServerName\C$' into the run box, he
can access the server C drive.

Does anyone know what might be wrong? Is it possible we checked a wrong box
during installation?

Thanks for your assistance.

bill

bill_morgan wrote:
> We recently took our Sql Server box off-line, installed a new hard drive,
> then re-installed Sql Server 2000. A client who was able to connect fine
> through EM/QA prior to the re-install is now unable to successfully register
> the sql server - he keeps getting 'Sql Server does not exist or Access
> Denied' error.
>
> There is no domain conflict, no IP address blocking, and we have double
> checked login/password/roles/permissions - cannot find anything wrong. Even
> sa cannot do a successful registration through Client machine. This client
> can ping the server and vice versa. He can also access the server throuh
> Remote Desktop Connection. If he types '\\ServerName\C$' into the run box, he
> can access the server C drive.
>
> Does anyone know what might be wrong? Is it possible we checked a wrong box
> during installation?
>
> Thanks for your assistance.
>
> bill

Is the Windows firewall or IP filtering enabled either on the server or
on the machine?

Are the client and server on the same subnet, or there is some routing
involved?

A quick test: what happens if you use the ip address and port number
instead of the server name in your connection? Like "192.168.1.1,1433"
(using a comma for the port suffix).

Regards,
lucm

Hi, lucm ... thanks for your reply.

Using 'IP-address, port-number' produced the same result - server failed to
register. We also double-checked to make sure that port 1433 was the
designated port number for the server.

Firewall is not up on the server box yet, and there is no IP filtering in
place on the server level. As to your other suggestions, we are verifying the
status and we'll come back with the answers. Thanks again for your .

"lucm@iqato.com" wrote:

> bill_morgan wrote:
> > We recently took our Sql Server box off-line, installed a new hard drive,
> > then re-installed Sql Server 2000. A client who was able to connect fine
> > through EM/QA prior to the re-install is now unable to successfully register
> > the sql server - he keeps getting 'Sql Server does not exist or Access
> > Denied' error.
> >
> > There is no domain conflict, no IP address blocking, and we have double
> > checked login/password/roles/permissions - cannot find anything wrong. Even
> > sa cannot do a successful registration through Client machine. This client
> > can ping the server and vice versa. He can also access the server throuh
> > Remote Desktop Connection. If he types '\\ServerName\C$' into the run box, he
> > can access the server C drive.
> >
> > Does anyone know what might be wrong? Is it possible we checked a wrong box
> > during installation?
> >
> > Thanks for your assistance.
> >
> > bill
>
> Is the Windows firewall or IP filtering enabled either on the server or
> on the machine?
>
> Are the client and server on the same subnet, or there is some routing
> involved?
>
> A quick test: what happens if you use the ip address and port number
> instead of the server name in your connection? Like "192.168.1.1,1433"
> (using a comma for the port suffix).
>
> Regards,
> lucm
>
>

WCM wrote:
> Hi, lucm ... thanks for your reply.
>
> Using 'IP-address, port-number' produced the same result - server failed to
> register. We also double-checked to make sure that port 1433 was the
> designated port number for the server.
>
> Firewall is not up on the server box yet, and there is no IP filtering in
> place on the server level. As to your other suggestions, we are verifying the
> status and we'll come back with the answers. Thanks again for your .
>

Since you checked the port then I supposed you made sure that the
TCP/IP protocol was enabled in the "Server network utility".

One quick diagnostic: download PortQryUi from Microsoft (free). With
this tool you will know if the service can be reached or not. Check for
SQL service in the list of tests available. If you can't reach the
server, try from another workstation.

One more question; what kind of authentication are you using? Windows
or mixed? If you use mixed, make sure that this option is enabled (in
the server properties, security tab).

Also fire up the query analyzer on the server and type "select
@@servername". This should give you the actual name of the server. If
the name does not match then it has to be fixed.

Regards,
lucm

Hi again, lucm,

Thank you for the additional suggestions, which I am following up on this
afternoon. So far, problem persists.

One additional question for you: I deleted username/login/pwd for the client
that is having sql server registration problems, and I added new login,
username and pwd for him.

Question: The new username/login is showing up in EM as it should, but when
I run exec xp_logininfo 'username' in QA (where 'username' is the actual
username of the client), I get the following system error message: Server:
Msg 8198, Level 16, State 21, Procedure xp_logininfo, Line 58 Could not
obtain information about Windows NT group/user 'username'.

Doesn't this mean there is a username recognition problem?

Thanks ...

"lucm@iqato.com" wrote:

> WCM wrote:
> > Hi, lucm ... thanks for your reply.
> >
> > Using 'IP-address, port-number' produced the same result - server failed to
> > register. We also double-checked to make sure that port 1433 was the
> > designated port number for the server.
> >
> > Firewall is not up on the server box yet, and there is no IP filtering in
> > place on the server level. As to your other suggestions, we are verifying the
> > status and we'll come back with the answers. Thanks again for your .
> >
>
> Since you checked the port then I supposed you made sure that the
> TCP/IP protocol was enabled in the "Server network utility".
>
> One quick diagnostic: download PortQryUi from Microsoft (free). With
> this tool you will know if the service can be reached or not. Check for
> SQL service in the list of tests available. If you can't reach the
> server, try from another workstation.
>
> One more question; what kind of authentication are you using? Windows
> or mixed? If you use mixed, make sure that this option is enabled (in
> the server properties, security tab).
>
> Also fire up the query analyzer on the server and type "select
> @@servername". This should give you the actual name of the server. If
> the name does not match then it has to be fixed.
>
> Regards,
> lucm
>
>

lucm,
I downloaded portqryui from MS as you suggested. Following is part of
return from running the diagnostic on the server IP address. Diagnositc was
able to resolve the IP address into the correct server name. Does the NOT
LISTENING indicate a problem?

TCP port 1433 (ms-sql-s service): NOT LISTENING
portqry.exe -n [ip address here] -e 1433 -p TCP exits with return code
0x00000001.



"lucm@iqato.com" wrote:

> WCM wrote:
> > Hi, lucm ... thanks for your reply.
> >
> > Using 'IP-address, port-number' produced the same result - server failed to
> > register. We also double-checked to make sure that port 1433 was the
> > designated port number for the server.
> >
> > Firewall is not up on the server box yet, and there is no IP filtering in
> > place on the server level. As to your other suggestions, we are verifying the
> > status and we'll come back with the answers. Thanks again for your .
> >
>
> Since you checked the port then I supposed you made sure that the
> TCP/IP protocol was enabled in the "Server network utility".
>
> One quick diagnostic: download PortQryUi from Microsoft (free). With
> this tool you will know if the service can be reached or not. Check for
> SQL service in the list of tests available. If you can't reach the
> server, try from another workstation.
>
> One more question; what kind of authentication are you using? Windows
> or mixed? If you use mixed, make sure that this option is enabled (in
> the server properties, security tab).
>
> Also fire up the query analyzer on the server and type "select
> @@servername". This should give you the actual name of the server. If
> the name does not match then it has to be fixed.
>
> Regards,
> lucm
>
>

BTW: our entire company is on same subnet - no routing - no firewall or IP
filtering on my local workstation (or presently, on server either).

"lucm@iqato.com" wrote:

> WCM wrote:
> > Hi, lucm ... thanks for your reply.
> >
> > Using 'IP-address, port-number' produced the same result - server failed to
> > register. We also double-checked to make sure that port 1433 was the
> > designated port number for the server.
> >
> > Firewall is not up on the server box yet, and there is no IP filtering in
> > place on the server level. As to your other suggestions, we are verifying the
> > status and we'll come back with the answers. Thanks again for your .
> >
>
> Since you checked the port then I supposed you made sure that the
> TCP/IP protocol was enabled in the "Server network utility".
>
> One quick diagnostic: download PortQryUi from Microsoft (free). With
> this tool you will know if the service can be reached or not. Check for
> SQL service in the list of tests available. If you can't reach the
> server, try from another workstation.
>
> One more question; what kind of authentication are you using? Windows
> or mixed? If you use mixed, make sure that this option is enabled (in
> the server properties, security tab).
>
> Also fire up the query analyzer on the server and type "select
> @@servername". This should give you the actual name of the server. If
> the name does not match then it has to be fixed.
>
> Regards,
> lucm
>
>

Hi, lucm,

Additional responses to your suggestions: our authentication is "mixed" and
'select @@servername' does return the right servername.

I think your portqryui suggestion is leading us in the right direction. If
our firewall is down and there is no IP blocking in place, what could be
causing port 1433 to be NOT LISTENING?

"WCM" wrote:

> Hi again, lucm,
>
> Thank you for the additional suggestions, which I am following up on this
> afternoon. So far, problem persists.
>
> One additional question for you: I deleted username/login/pwd for the client
> that is having sql server registration problems, and I added new login,
> username and pwd for him.
>
> Question: The new username/login is showing up in EM as it should, but when
> I run exec xp_logininfo 'username' in QA (where 'username' is the actual
> username of the client), I get the following system error message: Server:
> Msg 8198, Level 16, State 21, Procedure xp_logininfo, Line 58 Could not
> obtain information about Windows NT group/user 'username'.
>
> Doesn't this mean there is a username recognition problem?
>
> Thanks ...
>
> "lucm@iqato.com" wrote:
>
> > WCM wrote:
> > > Hi, lucm ... thanks for your reply.
> > >
> > > Using 'IP-address, port-number' produced the same result - server failed to
> > > register. We also double-checked to make sure that port 1433 was the
> > > designated port number for the server.
> > >
> > > Firewall is not up on the server box yet, and there is no IP filtering in
> > > place on the server level. As to your other suggestions, we are verifying the
> > > status and we'll come back with the answers. Thanks again for your .
> > >
> >
> > Since you checked the port then I supposed you made sure that the
> > TCP/IP protocol was enabled in the "Server network utility".
> >
> > One quick diagnostic: download PortQryUi from Microsoft (free). With
> > this tool you will know if the service can be reached or not. Check for
> > SQL service in the list of tests available. If you can't reach the
> > server, try from another workstation.
> >
> > One more question; what kind of authentication are you using? Windows
> > or mixed? If you use mixed, make sure that this option is enabled (in
> > the server properties, security tab).
> >
> > Also fire up the query analyzer on the server and type "select
> > @@servername". This should give you the actual name of the server. If
> > the name does not match then it has to be fixed.
> >
> > Regards,
> > lucm
> >
> >

WCM wrote:
> lucm,
> I downloaded portqryui from MS as you suggested. Following is part of
> return from running the diagnostic on the server IP address. Diagnositc was
> able to resolve the IP address into the correct server name. Does the NOT
> LISTENING indicate a problem?
>
> TCP port 1433 (ms-sql-s service): NOT LISTENING
> portqry.exe -n [ip address here] -e 1433 -p TCP exits with return code
> 0x00000001.
>

Basically it means that there is no SQL service running on port 1433 at
this address. It does sound like the TCP/IP protocol is not enabled in
the server properties. Or the port has been changed. Did you select the
default instance when you installed?

One more test. Find the software called SuperScan from Foundstone
(free), and scan the server's IP (from the workstation) to see what
ports are open to communication. Make sure to scan all ports (1 to
65k), 2-3 passes in the service discovery. For every port that is
listed as open but that you don't know for sure why, try to connect
with PortQryUi.

You could also run the "netstat -a" command on the server and see what
ports are flagged as "listening".

Regards,
lucm

WCM wrote:
> BTW: our entire company is on same subnet - no routing - no firewall or IP
> filtering on my local workstation (or presently, on server either).
>

By any chance, when you reinstalled the server, did you move it from
one switch port to another one? This is a long shot, but you could try
to power-cycle every switch or hub between the workstation and the
server, and power-cycle the two machines as well.

In the past I've seen some very bizarre behavior from machines
connected to a misconfigured Cisco switch, but power-cycling was a
short-term cure in most cases. Long enough to diagnose the problem, at
least.

Anyways, this is a quick test that can't hurt if you are allowed some
downtime on your network.

Regards,
lucm

I forgot to mention in previous response that TCP/IP is enabled in server
properties > General > Nework Configuration. Default instance was selected
during installation.

Thanks for the additional suggestions. I will try them out and let you know
what happens. We have now had 2 seasoned sql server sa's going over all our
settings, and so far we have not discovered the problem.


"lucm@iqato.com" wrote:

> WCM wrote:
> > lucm,
> > I downloaded portqryui from MS as you suggested. Following is part of
> > return from running the diagnostic on the server IP address. Diagnositc was
> > able to resolve the IP address into the correct server name. Does the NOT
> > LISTENING indicate a problem?
> >
> > TCP port 1433 (ms-sql-s service): NOT LISTENING
> > portqry.exe -n [ip address here] -e 1433 -p TCP exits with return code
> > 0x00000001.
> >
>
> Basically it means that there is no SQL service running on port 1433 at
> this address. It does sound like the TCP/IP protocol is not enabled in
> the server properties. Or the port has been changed. Did you select the
> default instance when you installed?
>
> One more test. Find the software called SuperScan from Foundstone
> (free), and scan the server's IP (from the workstation) to see what
> ports are open to communication. Make sure to scan all ports (1 to
> 65k), 2-3 passes in the service discovery. For every port that is
> listed as open but that you don't know for sure why, try to connect
> with PortQryUi.
>
> You could also run the "netstat -a" command on the server and see what
> ports are flagged as "listening".
>
> Regards,
> lucm
>
>

I will ask the IT guys do this, and let you know what comes up. In the
meantime, I'm getting Superscan and will run netstat -a. BTW, this is a
valuable learning experience for me. Thanks for your patient assistance.

bill

"lucm@iqato.com" wrote:

> WCM wrote:
> > BTW: our entire company is on same subnet - no routing - no firewall or IP
> > filtering on my local workstation (or presently, on server either).
> >
>
> By any chance, when you reinstalled the server, did you move it from
> one switch port to another one? This is a long shot, but you could try
> to power-cycle every switch or hub between the workstation and the
> server, and power-cycle the two machines as well.
>
> In the past I've seen some very bizarre behavior from machines
> connected to a misconfigured Cisco switch, but power-cycling was a
> short-term cure in most cases. Long enough to diagnose the problem, at
> least.
>
> Anyways, this is a quick test that can't hurt if you are allowed some
> downtime on your network.
>
> Regards,
> lucm
>
>

Question on superscan: I am running it from client machine - am I correct in
assuming that "HostName" should be the sql server IP address and that "Start
IP' and "End IP" should both be my client IP address?

I ran the scan (with above assumptions) using the default "Host and Service
Discover Options" - results were no IP ports listening. It is taking a long
time to run the scan on 1 - 65K ports / 3 passes - that's why I ask the
question above. Thanks.

"lucm@iqato.com" wrote:

> WCM wrote:
> > BTW: our entire company is on same subnet - no routing - no firewall or IP
> > filtering on my local workstation (or presently, on server either).
> >
>
> By any chance, when you reinstalled the server, did you move it from
> one switch port to another one? This is a long shot, but you could try
> to power-cycle every switch or hub between the workstation and the
> server, and power-cycle the two machines as well.
>
> In the past I've seen some very bizarre behavior from machines
> connected to a misconfigured Cisco switch, but power-cycling was a
> short-term cure in most cases. Long enough to diagnose the problem, at
> least.
>
> Anyways, this is a quick test that can't hurt if you are allowed some
> downtime on your network.
>
> Regards,
> lucm
>
>

WCM wrote:
> Question on superscan: I am running it from client machine - am I correct in
> assuming that "HostName" should be the sql server IP address and that "Start
> IP' and "End IP" should both be my client IP address?
>
> I ran the scan (with above assumptions) using the default "Host and Service
> Discover Options" - results were no IP ports listening. It is taking a long
> time to run the scan on 1 - 65K ports / 3 passes - that's why I ask the
> question above. Thanks.

You are correct about the hostname.

Don't use the default options. For a quick test leave the default
ports, but check all options in the Host Discovery section. In UDP
select "Data+ICMP" scan, and in TCP select "Connect" scan.

This should report you at least one of the netbios ports (137-139, or
445). If you have IIS on the server this should report the port 80 as
well. If you still get nothing, but the host is reported as "live",
then either there is some firewall involved or you are not scanning a
Windows box.

But then you said you can connect to the server using Remote Desktop...
This is puzzling.

Did you check if you have a Cisco switch somewhere between the
machines? For bizarre network-related issues a misconfigured Catalyst
can be the culprit. As an example, just last month a friend of mine
spent two days troubleshooting a bizarre Exchange behavior and finally
found out the issue was the port configuration on his switch. He too
was able to connect with Remote Desktop or UNC so he was not suspicious
about the switch.

Regards,
lucm

--------------------------------------------------------------------------------

Will do, and I will get back to you with the results. I have to wait for
the IT guys to do the network stuff.

Also found following on Net while searching for other users experiencing
this same problem. Question: Do you think this is worth the try?

BEGIN:
resolution to port 1433 not listening:

The problem is around security for the slammer worm, and a dll called
DBNETLIB.dll. When this file is out of date, Server 2003 and perhaps SP2 on
XP (I've had a similar experience with XP SP2) will actually disable the
TCP/IP protocol
for SQL Server to limit an attack. The link below will take you to a fix
that will examine your install of SQL Server, then apply appropriate updates.
This will update the DBNETLIB.DLL which is responsible for managing the
TCP/IP protocol for SQL Server. Most people will assume that installing SP3a
will fix this issue, unfortunately, it does not, and I found it is ok so
install this critical update after SP3a.

http://www.microsoft.com/downloads/d...displaylang=en

This should definitely solve your issue, knowledge on this topic is
surprisingly limited, I have to think that many more people have been hit by
this one.
END:




"lucm@iqato.com" wrote:

> WCM wrote:
> > Question on superscan: I am running it from client machine - am I correct in
> > assuming that "HostName" should be the sql server IP address and that "Start
> > IP' and "End IP" should both be my client IP address?
> >
> > I ran the scan (with above assumptions) using the default "Host and Service
> > Discover Options" - results were no IP ports listening. It is taking a long
> > time to run the scan on 1 - 65K ports / 3 passes - that's why I ask the
> > question above. Thanks.
>
> You are correct about the hostname.
>
> Don't use the default options. For a quick test leave the default
> ports, but check all options in the Host Discovery section. In UDP
> select "Data+ICMP" scan, and in TCP select "Connect" scan.
>
> This should report you at least one of the netbios ports (137-139, or
> 445). If you have IIS on the server this should report the port 80 as
> well. If you still get nothing, but the host is reported as "live",
> then either there is some firewall involved or you are not scanning a
> Windows box.
>
> But then you said you can connect to the server using Remote Desktop...
> This is puzzling.
>
> Did you check if you have a Cisco switch somewhere between the
> machines? For bizarre network-related issues a misconfigured Catalyst
> can be the culprit. As an example, just last month a friend of mine
> spent two days troubleshooting a bizarre Exchange behavior and finally
> found out the issue was the port configuration on his switch. He too
> was able to connect with Remote Desktop or UNC so he was not suspicious
> about the switch.
>
> Regards,
> lucm
>
>

WCM wrote:
> --------------------------------------------------------------------------------
>
> Will do, and I will get back to you with the results. I have to wait for
> the IT guys to do the network stuff.
>
> Also found following on Net while searching for other users experiencing
> this same problem. Question: Do you think this is worth the try?
>
> BEGIN:
> resolution to port 1433 not listening:
>
> The problem is around security for the slammer worm, and a dll called
> DBNETLIB.dll. When this file is out of date, Server 2003 and perhaps SP2 on
> XP (I've had a similar experience with XP SP2) will actually disable the
> TCP/IP protocol
> for SQL Server to limit an attack. The link below will take you to a fix
> that will examine your install of SQL Server, then apply appropriate updates.
> This will update the DBNETLIB.DLL which is responsible for managing the
> TCP/IP protocol for SQL Server. Most people will assume that installing SP3a
> will fix this issue, unfortunately, it does not, and I found it is ok so
> install this critical update after SP3a.
>
> http://www.microsoft.com/downloads/d...displaylang=en
>
> This should definitely solve your issue, knowledge on this topic is
> surprisingly limited, I have to think that many more people have been hit by
> this one.
> END:
>

This leads to a very basic question that should have been asked right
from the start: what service packs did you apply on your initial
installation? And on the second? Since you had some experienced DBAs
looking at your installation, this probably have been validated.

If you don't have SP4, then there is a lot of potential issues, and
most of them are not worth investigating as they will be solved by the
SP4. The Slammer protection mechanism could be the problem, however I
never heard about such scenario.

Regards,
lucm

Hi, Lucm. the "slammer worm" fix from Microsoft (see my previous post) fixed
the problem ("obscure", to say the least). Now Port 1433 is LISTENING. Your
ongoing has been extremely valuable to us. Thank you for your patient
listening and responses.

"lucm@iqato.com" wrote:

> WCM wrote:
> > Question on superscan: I am running it from client machine - am I correct in
> > assuming that "HostName" should be the sql server IP address and that "Start
> > IP' and "End IP" should both be my client IP address?
> >
> > I ran the scan (with above assumptions) using the default "Host and Service
> > Discover Options" - results were no IP ports listening. It is taking a long
> > time to run the scan on 1 - 65K ports / 3 passes - that's why I ask the
> > question above. Thanks.
>
> You are correct about the hostname.
>
> Don't use the default options. For a quick test leave the default
> ports, but check all options in the Host Discovery section. In UDP
> select "Data+ICMP" scan, and in TCP select "Connect" scan.
>
> This should report you at least one of the netbios ports (137-139, or
> 445). If you have IIS on the server this should report the port 80 as
> well. If you still get nothing, but the host is reported as "live",
> then either there is some firewall involved or you are not scanning a
> Windows box.
>
> But then you said you can connect to the server using Remote Desktop...
> This is puzzling.
>
> Did you check if you have a Cisco switch somewhere between the
> machines? For bizarre network-related issues a misconfigured Catalyst
> can be the culprit. As an example, just last month a friend of mine
> spent two days troubleshooting a bizarre Exchange behavior and finally
> found out the issue was the port configuration on his switch. He too
> was able to connect with Remote Desktop or UNC so he was not suspicious
> about the switch.
>
> Regards,
> lucm
>
>