Cannot remotely connect on SQL Server Instances by name.

Hi all,

On my computer I have installed two instances of SQL Server 2000. The first one is the default instance of SQL Server Personal Edition and the second one is an MSDE instance.

From other PCs on the company LAN I can connect, by name, only to the first one and not to the MSDE instance.

I have tried the combination IP Address, TCP Port and it work fine.

Anyone any ideas?

Thanks in advance,

Stavros Makridis.

did you get this fixed ever?|||

Hi,

the named instance is accessible with MachineName\InstanceName,PortNumber in SQL Server 2000.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de|||

Jens K. Suessmeyer wrote:

Hi,

the named instance is accessible with MachineName\InstanceName,PortNumber in SQL Server 2000.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

If tcp port is specified in the connection string, the instance name value is ignored.|||UDP port 1434 must be blocked somehow. SQL Browser needs this port to resolve srv\instance to a valid server:tcp_port.|||He is using SQL 2000, so no SQL Browser.|||

Yes there is. Browser is handled by the first instance of sqlserver internally.

|||

I wasn′t aware of that, do you have some links about this topic and this internal feature ?

|||You can find it in bol and on technet.

Here is an excerpt from bol (ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/3cc00d3a-487c-4cd9-a155-655f02485fa0.htm):
"Background

Prior to Microsoft SQL Server 2000, only one instance of SQL Server could be installed on a computer. SQL Server listened for incoming requests on port 1433, assigned to SQL Server by the official Internet Assigned Numbers Authority (IANA). Only one instance of SQL Server can use a port, so when SQL Server 2000 introduced support for multiple instances of SQL Server, SQL Server Resolution Protocol (SSRP) was developed to listen on UDP port 1434. This listener service responded to client requests with the names of the installed instances, and the ports or named pipes used by the instance. To resolve limitations of the SSRP system, SQL Server 2005 introduces the SQL Server Browser service as a replacement for SSRP."

Cannot remotely connect on SQL Server Instances by name.

Hi all,

On my computer I have installed two instances of SQL Server 2000. The first one is the default instance of SQL Server Personal Edition and the second one is an MSDE instance.

From other PCs on the company LAN I can connect, by name, only to the first one and not to the MSDE instance.

I have tried the combination IP Address, TCP Port and it work fine.

Anyone any ideas?

Thanks in advance,

Stavros Makridis.

did you get this fixed ever?|||

Hi,

the named instance is accessible with MachineName\InstanceName,PortNumber in SQL Server 2000.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

Jens K. Suessmeyer wrote:

Hi,

the named instance is accessible with MachineName\InstanceName,PortNumber in SQL Server 2000.

HTH, Jens K. Suessmeyer.

http://www.sqlserver2005.de

If tcp port is specified in the connection string, the instance name value is ignored.|||UDP port 1434 must be blocked somehow. SQL Browser needs this port to resolve srv\instance to a valid server:tcp_port.|||He is using SQL 2000, so no SQL Browser.|||

Yes there is. Browser is handled by the first instance of sqlserver internally.

|||

I wasn′t aware of that, do you have some links about this topic and this internal feature ?

|||You can find it in bol and on technet.

Here is an excerpt from bol (ms-help://MS.SQLCC.v9/MS.SQLSVR.v9.en/udb9/html/3cc00d3a-487c-4cd9-a155-655f02485fa0.htm):
"Background

Prior to Microsoft SQL Server 2000, only one instance of SQL Server

could be installed on a computer. SQL Server listened for incoming requests on

port 1433, assigned to SQL Server by the official Internet Assigned Numbers

Authority (IANA). Only one instance of SQL Server can use a port, so when SQL

Server 2000 introduced support for multiple instances of SQL Server, SQL Server

Resolution Protocol (SSRP) was developed to listen on UDP port 1434. This

listener service responded to client requests with the names of the installed

instances, and the ports or named pipes used by the instance. To resolve

limitations of the SSRP system, SQL Server 2005 introduces the SQL Server

Browser service as a replacement for SSRP."

Cannot Register the server

I've installed an Instance of MSDE on a Win2k Machine and and WinXP Machine.
I'm able to register the Instances locally through EM (v.8.0), but when I
try to register them from a different PC with EM on it, I get the following
error.
SQL Server does not exist or access is denied. ConnectionOpen (Connect()
Is MSDE limited to local Enterprise Management?
Wack
This message will self destruct.
hi Ray,
Ray Lewis wrote:
> I've installed an Instance of MSDE on a Win2k Machine and and WinXP
> Machine. I'm able to register the Instances locally through EM
> (v.8.0), but when I try to register them from a different PC with EM
> on it, I get the following error.
> SQL Server does not exist or access is denied. ConnectionOpen
> (Connect()
> Is MSDE limited to local Enterprise Management?
please verify the network protocols are enabled via Server Network Utility
(svrnetcn.exe)...
MSDE installs by default disabling network protocols in order to prevent
external connections/attacks... you have to provide the
DISABLENETWORKPROTOCOLS=0
parameter at install time in order to force network protocols to be enable,
or, later afte install, use svrnetcn.exe to enable and configure the desired
protocol
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.10.0 - DbaMgr ver 0.56.0
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||Thanks. I finally discovered that. Also, on XP SP2, you need to allow port
1433 through the firewall.
Wack
This message will self destruct.
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:38p2mrF5riea7U1@.individual.net...
> hi Ray,
> Ray Lewis wrote:
> please verify the network protocols are enabled via Server Network Utility
> (svrnetcn.exe)...
> MSDE installs by default disabling network protocols in order to prevent
> external connections/attacks... you have to provide the
> DISABLENETWORKPROTOCOLS=0
> parameter at install time in order to force network protocols to be
enable,
> or, later afte install, use svrnetcn.exe to enable and configure the
desired
> protocol
> --
> Andrea Montanari (Microsoft MVP - SQL Server)
> http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
> DbaMgr2k ver 0.10.0 - DbaMgr ver 0.56.0
> (my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
> interface)
> -- remove DMO to reply
>

Cannot Install Sqlserver 2005 Developer Edition with Vista Ultimate

Currently I am just trying to completely remove all Vista Ultimate's knowledge of installed instances of SQLServer 2005 Developer edition.

I cannot do this for some reason. This all began when I tried to install SQLServer 2005 and it installed but I could not connect to it. Now I have two installed instances that I cannot access, after removing all SQL programs from the Programs and Features icon in the control panel.

I tried running "WIndows Installer CleanUp Utility" as I read in a thread on this forum. This did not help. After going thru and removing all SQLServer programs using the "programs and features" icon in control panel... The installation process shows two installed instances of SQLServer 2005.

1) How can I completely erase all Vista Ultimate's knowledge of any SQLServer 2005 install and start over?

I have downloaded SQLServer 2005 SP 2, and run it, but clearly what I should do, and what Microsoft has asked me to do are not working...

2) What should I be doing to install SQLServer 2005 Developer Edition successfully?

I have been a strong supporter of Microsoft, but this is getting me very frustrated.

Please help,

- Chaz

Posted by Caddre - Moderator MVP on alternate, thread by another user:

If you have admin permissions in Vista this thread could help you.

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1901664&SiteID=1

- It worked for me and solved my situation.

FYI, Chaz

|||

Make sure that Control Panel does not have any reference to SQL Server components (like SQL Support files, etc)

You can go into the Registry and remove the keys

HKLM\Software\Microsoft\Microsoft SQL Server and MSSQLServer

HKLM\System\CurrentControlSet\Services\MSSQL*

Also remove the Program Files\Microsoft SQL Server directories.

You can also take a look at this support article:

http://support.microsoft.com/kb/909967/en-us

Cannot install MS SQL 2000 Developer Edition to my computer

When come to Create Instances screen and click next it prompt error message

although i had restart my computer.

A previous program Installation created pending file operations on the installation machine. You must restart the computer before running setup.

That message is normally because there is a 'runonce' flag set (and some files to be replaced).

However, if you have re-booted your computer (not just logged off and on), then the flag 'should' be cleared.

|||

yes i had restart even shutdown but still prompt the same errors.

Cannot generate SSPI context on laptop from different domain

Hi All,
I have Domain A with several SQL servers installed. One WinXP Pro laptop
user reports that he can't connect to any SQL server instances using Windows
authentication (the servers run win2k3 OS SP1 with SQL 2000 sp4 & 2005 sp1)
and gets the error:
Cannot generate SSPI context. (.Net SqlClient Data Provider)
His laptop is unique in that it's part of another domain, Domain B which has
no trust relationship with Domain A, nor should it. When he is in the office
at Domain A, he logs in to his laptop using cached domain credentials for
Domain B,and has entered a Managed Network Password entry for the SQL server
s
in Domain A.
It appears that if I have him log into his laptop using a local account
rather than his domain account (from Domain B) the Managed Network Password
entry works and he can successfully connect to the SQL servers on Domain A.
Any suggestions on how I can get the Windows security token of the user
account to successfully connect to SQL Server in this situation where he is
using cached domain credentials (Domain B) with a Managed Network Password
(For Domain A). I would prefer not to make a trust between the domains while
still allowing him to connect to SQL using his existing laptop profile.
Thanks!Hi,
I understand that you would like to establish a connection from your laptop
computer in domain B to your SQL Server instance in domain A. The two
separated domains are non-trusted.
If I have misunderstood, please let me know.
As far as I know, if two separated domains have no trust relationship, any
one of the two domains could not connect to the other's SQL Server
instances with Windows Authentication by using its peer domain's user
account. To establish a connection, you can create a same local user
account with the same password on both of the computers which belong to the
two different domains. Cached domain account may have permission to access
the share resources in domain B; however it could not be used to connect to
SQL Server instance. That is not secure.
Appreciate your understanding on this limitation. If you have any other
questions or concerns, please feel free to let us know. Have a good day!
Best regards,
Charles Wang
Microsoft Online Community Support
========================================
=============
Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscript...ault.aspx#notif
ications
If you are using Outlook Express, please make sure you clear the check box
"Tools/Options/Read: Get 300 headers at a time" to see your reply promptly.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscript...t/default.aspx.
========================================
==============
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
========================================
==============
This posting is provided "AS IS" with no warranties, and confers no rights.
========================================
==============|||Hi,
I am interested in this issue. Would you mind letting me know the result of
the suggestions? If you need further assistance, feel free to let me know.
I will be more than happy to be of assistance.
Charles Wang
Microsoft Online Community Support
========================================
==============
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
========================================
==============
This posting is provided "AS IS" with no warranties, and confers no rights.
========================================
==============|||Hey Charles,
Thanks for the suggestion and explanation.
If I understand the workaround you suggest it's similar to the workaround I
implemented in that the user logs into his laptop using a local account
rather than his domain account (cached from Domain B), I then added a Manage
d
Network Password entry for a domain user account for the user in Domain A an
d
he can then successfully connect to the SQL servers on Domain A.
The problem is caused by the fact that the laptop is part of Domain B and
there is no trust relationship set up between the domains. I wanted to solve
the problem by getting the Managed Network Password entry to work while he i
s
logged in to his laptop with his domain account cached from Domain B.
However, I understand from your explanation that this is not feasible.
"Charles Wang[MSFT]" wrote:

> Hi,
> I am interested in this issue. Would you mind letting me know the result o
f
> the suggestions? If you need further assistance, feel free to let me know.
> I will be more than happy to be of assistance.
> Charles Wang
> Microsoft Online Community Support
> ========================================
==============
> When responding to posts, please "Reply to Group" via
> your newsreader so that others may learn and benefit
> from this issue.
> ========================================
==============
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> ========================================
==============
>|||Hi Matt,
Thanks for your response.
Appreciate your understanding that this is a by design limitation. If it is
allowed, SQL Server may face many security issues. At least a simple
scenario that we can imagine is that any other users can use this cache
accout to attack SQL Server.
Your workaround is similar as my suggested workaround. Both of them are
safe, since any user who wants to use the user account to log in SQL Server
must know the correct password. For a cache account, we may just know its
user name, but do not know its password, so there may be potential security
problem if it is allowed to be used to connect to SQL Server.
Please feel free to let me know if you need further assistance on this
issue. Have a good day!
Best regards,
Charles Wang
Microsoft Online Community Support
========================================
=============
Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscript...ault.aspx#notif
ications
If you are using Outlook Express, please make sure you clear the check box
"Tools/Options/Read: Get 300 headers at a time" to see your reply promptly.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscript...t/default.aspx.
========================================
==============
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
========================================
==============
This posting is provided "AS IS" with no warranties, and confers no rights.
========================================
==============

Cannot generate SSPI context on laptop from different domain

Hi All,
I have Domain A with several SQL servers installed. One WinXP Pro laptop
user reports that he can't connect to any SQL server instances using Windows
authentication (the servers run win2k3 OS SP1 with SQL 2000 sp4 & 2005 sp1)
and gets the error:
Cannot generate SSPI context. (.Net SqlClient Data Provider)
His laptop is unique in that it's part of another domain, Domain B which has
no trust relationship with Domain A, nor should it. When he is in the office
at Domain A, he logs in to his laptop using cached domain credentials for
Domain B,and has entered a Managed Network Password entry for the SQL servers
in Domain A.
It appears that if I have him log into his laptop using a local account
rather than his domain account (from Domain B) the Managed Network Password
entry works and he can successfully connect to the SQL servers on Domain A.
Any suggestions on how I can get the Windows security token of the user
account to successfully connect to SQL Server in this situation where he is
using cached domain credentials (Domain B) with a Managed Network Password
(For Domain A). I would prefer not to make a trust between the domains while
still allowing him to connect to SQL using his existing laptop profile.
Thanks!
Hi,
I understand that you would like to establish a connection from your laptop
computer in domain B to your SQL Server instance in domain A. The two
separated domains are non-trusted.
If I have misunderstood, please let me know.
As far as I know, if two separated domains have no trust relationship, any
one of the two domains could not connect to the other's SQL Server
instances with Windows Authentication by using its peer domain's user
account. To establish a connection, you can create a same local user
account with the same password on both of the computers which belong to the
two different domains. Cached domain account may have permission to access
the share resources in domain B; however it could not be used to connect to
SQL Server instance. That is not secure.
Appreciate your understanding on this limitation. If you have any other
questions or concerns, please feel free to let us know. Have a good day!
Best regards,
Charles Wang
Microsoft Online Community Support
================================================== ===
Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
If you are using Outlook Express, please make sure you clear the check box
"Tools/Options/Read: Get 300 headers at a time" to see your reply promptly.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
================================================== ====
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
================================================== ====
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====
|||Hi,
I am interested in this issue. Would you mind letting me know the result of
the suggestions? If you need further assistance, feel free to let me know.
I will be more than happy to be of assistance.
Charles Wang
Microsoft Online Community Support
================================================== ====
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
================================================== ====
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====
|||Hey Charles,
Thanks for the suggestion and explanation.
If I understand the workaround you suggest it's similar to the workaround I
implemented in that the user logs into his laptop using a local account
rather than his domain account (cached from Domain B), I then added a Managed
Network Password entry for a domain user account for the user in Domain A and
he can then successfully connect to the SQL servers on Domain A.
The problem is caused by the fact that the laptop is part of Domain B and
there is no trust relationship set up between the domains. I wanted to solve
the problem by getting the Managed Network Password entry to work while he is
logged in to his laptop with his domain account cached from Domain B.
However, I understand from your explanation that this is not feasible.
"Charles Wang[MSFT]" wrote:

> Hi,
> I am interested in this issue. Would you mind letting me know the result of
> the suggestions? If you need further assistance, feel free to let me know.
> I will be more than happy to be of assistance.
> Charles Wang
> Microsoft Online Community Support
> ================================================== ====
> When responding to posts, please "Reply to Group" via
> your newsreader so that others may learn and benefit
> from this issue.
> ================================================== ====
> This posting is provided "AS IS" with no warranties, and confers no rights.
> ================================================== ====
>
|||Hi Matt,
Thanks for your response.
Appreciate your understanding that this is a by design limitation. If it is
allowed, SQL Server may face many security issues. At least a simple
scenario that we can imagine is that any other users can use this cache
accout to attack SQL Server.
Your workaround is similar as my suggested workaround. Both of them are
safe, since any user who wants to use the user account to log in SQL Server
must know the correct password. For a cache account, we may just know its
user name, but do not know its password, so there may be potential security
problem if it is allowed to be used to connect to SQL Server.
Please feel free to let me know if you need further assistance on this
issue. Have a good day!
Best regards,
Charles Wang
Microsoft Online Community Support
================================================== ===
Get notification to my posts through email? Please refer to:
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications
If you are using Outlook Express, please make sure you clear the check box
"Tools/Options/Read: Get 300 headers at a time" to see your reply promptly.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
================================================== ====
When responding to posts, please "Reply to Group" via
your newsreader so that others may learn and benefit
from this issue.
================================================== ====
This posting is provided "AS IS" with no warranties, and confers no rights.
================================================== ====

Cannot generate SSPI context and Windows 2000 service pack 4

We have had two instances of installing Windows 2000 Service Pack 4 [*]
on machines running SQL Server 2000 SP3a+HF and subsequently seeing errors f
rom SQL Server client tools (QA and Enterprise Manager):
Cannot generate SSPI context
SETSPN -L shows a valid service principle name, and the other options in KB
811889 have been tried. We are using a domain user account as the service ac
count for SQL Server.
What else can we look for to resolve this problem please?
[*] re-building the machine with SP3 and the problem does not appear. We
need W2K SP4 for SQL Server Reporting Services.This happens because of a Kerberos authentication protocol issue, I would
suggest you to do the following things
1. Enable Kerberos logging on the client machine (documented at
http://support.microsoft.com/defaul...kb;EN-US;262177). Now try to
connect to the remote SQL Server, if you get the same error message then
check the SYSTEM eventlog. You would find Kerberos failure events which give
you good information about what went wrong.
2. If there are no Kerberos errors on the client machines, you could be
having some error messages on the APPLICATION eventlog of the SQL Server
machine which will say that the SQL Server couldnot decrypt the login
packets from the clients which implies that there are multiple SPNs
registered and the AD picked a wrong one. You can find all the registered
SPNs in your AD by using the command
ldifde -d "CN=Users,DC=betaland" -l servicePrincipalName -F
NewoutputUsers.txt
and then clean up the redundant ones. This is explained in
http://support.microsoft.com/?id=319723
Thanks,
Bala.
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified at
http://www.microsoft.com/info/cpyright.htm
"Nigel Williams" <nwilliams@.fictitious.kom> wrote in message
news:DE140101-7F0E-4AE1-86DC-626028B66D5D@.microsoft.com...
> We have had two instances of installing Windows 2000 Service Pack 4 [*] on[/co
lor]
machines running SQL Server 2000 SP3a+HF and subsequently seeing errors from
SQL Server client tools (QA and Enterprise Manager):
> Cannot generate SSPI context
> SETSPN -L shows a valid service principle name, and the other options in
KB 811889 have been tried. We are using a domain user account as the service
account for SQL Server.
> What else can we look for to resolve this problem please?
>
> [*] re-building the machine with SP3 and the problem does not appear. We[/colo
r]
need W2K SP4 for SQL Server Reporting Services.
>

Cannot find SQLResourceLoader.dll

We have a server with the default instance and 2 addtional named instances running SQL 2000 SP4. I attempted to install another instance for SQL 2005 and promptly ran into the above error when running DTS packages on the default SQL 2000 instance.

The legacy components had been installed and the server had been re-started. I also tried re-registering the dll as suggested on another forum post.

Any ideas on what I could do to get around this problem? We need to keep our existing SQL 2000 installs as is until we have a SQL 2005 server setup ready to take over the workload with absolute minimal downtime.

Thanks
Phill
mailto:philcart@.gmail.com
http://www.philcart.net/blog
http://www.sqlserver.org.au/user/bio/ViewBio.aspx?bioId=46
http://www.sqlservercentral.com/forums/userinfo.aspx?id=5534

Phil, did you hit any issues installing the legacy components from the SQL 2005 tools package? This typically is the fix for this issue.

Thanks,
Sam Lester (MSFT)

|||

No errors were reported during the install.

Over the weekend I had a chance to perform a couple of install/uninstalls. I actually did it 4 times and it failed on the 1st and 3rd times.

Guess there is something shaky there.