MSDE on SBS2003 from Network

I have created a new MSDE instance on my SBS 2003 Standard server, using
MSDE setup.
The service is started, and I can access the MSDE instance locally on the
server, but I am unable to access it from other PCs on the network (in the
domain).
Specifically, I am using SQL Server Enterprise Manager. It reports the
message "Sql Server does not exist or access denied" when I try to connect
to the instance (using "myserver\instance-name"). I tried ISQL and also get
access denied.
I installed Enterprise Manager locally on the server and it connects to the
instance without problem.
Looking at the Properties/General/Network Configuration I can see TCPIP is
enabled and now using port 1433 (although it was set to port 0 after
installation?).
My user account is a valid login with the "System Administrator" role an has
dbo access to all databases.
The Windows Firewall allows port 1433 at the client and no firewall on the
server.
What else to check?
richlm wrote:

>I have created a new MSDE instance on my SBS 2003 Standard server, using
>MSDE setup.
>The service is started, and I can access the MSDE instance locally on the
>server, but I am unable to access it from other PCs on the network (in the
>domain).
>Specifically, I am using SQL Server Enterprise Manager. It reports the
>message "Sql Server does not exist or access denied" when I try to connect
>to the instance (using "myserver\instance-name"). I tried ISQL and also
>get access denied.
The default for MSDE is to not listen to the network, only the local
machine.

>I installed Enterprise Manager locally on the server and it connects to
>the instance without problem.
>Looking at the Properties/General/Network Configuration I can see TCPIP is
>enabled and now using port 1433 (although it was set to port 0 after
>installation?).
This was in the Server Network Utility, yes?
Has the MSDE instance been restarted since you enabled a network protocol?

>My user account is a valid login with the "System Administrator" role an
>has dbo access to all databases.
>The Windows Firewall allows port 1433 at the client and no firewall on the
>server.
The Windows Firewall on a client is irrelevant, since it has no impact on
outgoing connections. It would only be of interest if MSDE (or SQL) was
installed on the workstation itself.
Out of interest, where did you get the SQL client utilities from? They're
not included with SBS2003 Standard, nor are you licenced to use them in an
SBS2003 Standard environment.
Steve Foster [SBS MVP]
MVPs do not work for Microsoft. Please reply only to the newsgroups.
|||Yes, TCP 1433 is at the top of the list of "enabled protocols" in the server
network utility, and I restarted the MSDE service after setting the port.
But I just realized that cliconfg does not allow me to choose which MSDE
instance to apply the changes to.
I just found a Microsoft support notice "Server Network Utility may display
incorrect protocol properties in SQL Server 2000" at
http://support.microsoft.com/?kbid=887700 - I'll investigate this further
(although I'm using SP4 so the hotfix does not apply).
As for licencing, I have an MSDN Universal subscription which includes the
use of SQL client tools for development purposes. But thanks for the
reminder, and I'll re-check the licence terms to make sure I've not
misunderstood something about where the tools can be used.
Richard.
|||richlm wrote:

>Yes, TCP 1433 is at the top of the list of "enabled protocols" in the
>server network utility, and I restarted the MSDE service after setting the
>port.
>But I just realized that cliconfg does not allow me to choose which MSDE
>instance to apply the changes to.
Eh?

>I just found a Microsoft support notice "Server Network Utility may
>display incorrect protocol properties in SQL Server 2000" at
>http://support.microsoft.com/?kbid=887700 - I'll investigate this further
>(although I'm using SP4 so the hotfix does not apply).
>As for licencing, I have an MSDN Universal subscription which includes the
>use of SQL client tools for development purposes. But thanks for the
>reminder, and I'll re-check the licence terms to make sure I've not
>misunderstood something about where the tools can be used.
AIUI, the MSDN licence does not cover using the SQL client utilities to
manage a production server. So, unless your SBS is only used for your
development network, you are not legally allowed to use the MSDN licence
to manage SQL services on SBS. But hey, IANAL, nor a member of the licence
police...
Steve Foster [SBS MVP]
MVPs do not work for Microsoft. Please reply only to the newsgroups.
|||OK - I should be running svrnetcn.exe and not cliconfg.exe...
Now I can choose the instance - and can confirm that the problem referred to
at http://support.microsoft.com/?kbid=887700 also applies to SP4. The
workaround suggested there (choose another instance then go back to the one
you really wanted) refreshes the UI correctly.
But I still can't connect remotely using EM or OSQL - yet both work locally.
I've googled to the end of the earth and not found other suggestions so my
guess now is it's probably due to the fact I have installed VS2005 on my
client - which also installs SQL 2005 express.
When I try to connect using OSQL I get the following error:
[SQL Native Client]Unable to complete login process due to delay in opening
server connection.
This perhaps implies my client PC is "broken" for connecting to SQL 2000
instances?
The version of "SQL Server Native Client" I currently use is 9.00.1314.06.
I think I'll wait for SQL 2005 launch in a couple of weeks, where
(hopefully) this problem goes away.
Can anyone confirm this?
|||Richard Money wrote:

>OK - I should be running svrnetcn.exe and not cliconfg.exe...
>Now I can choose the instance - and can confirm that the problem referred
>to at http://support.microsoft.com/?kbid=887700 also applies to SP4. The
>workaround suggested there (choose another instance then go back to the
>one you really wanted) refreshes the UI correctly.
>But I still can't connect remotely using EM or OSQL - yet both work
>locally. I've googled to the end of the earth and not found other
>suggestions so my guess now is it's probably due to the fact I have
>installed VS2005 on my client - which also installs SQL 2005 express.
>When I try to connect using OSQL I get the following error:
>[SQL Native Client]Unable to complete login process due to delay in
>opening server connection.
>This perhaps implies my client PC is "broken" for connecting to SQL 2000
>instances?
>The version of "SQL Server Native Client" I currently use is 9.00.1314.06.
>I think I'll wait for SQL 2005 launch in a couple of weeks, where
>(hopefully) this problem goes away.
>Can anyone confirm this?
I don't know whether SQL2005 beta client tools can communicate with
SQL2000. I suspect that that is something likely to be left until very
close to RTM (and may require that SQL2000 gets an update of some sort).
I'd stick to trying with SQL2000 client utilities.
Steve Foster [SBS MVP]
MVPs do not work for Microsoft. Please reply only to the newsgroups.
|||Pretty sure that my problem connecting to MSDE over network was due to a
pre-release version of SQL2005 Express (sept. CTP) on my client.
Have just successfully installed the RTM of SQL Express on SBS as a named
instance, enabled networking using the SQL Server Configuration Manager, and
I can connect to the instance from VS2005 (RTM) running on another machine.
The default SBS instances for Sharepoint and SBSMonitoring are still running
MSDE (and still work!).
Now I'm happy:-)

msde licence

we get from a company installed at our customer sides an application using
msde in a win 2000 server (terminal) or higher network enwironment. We have a
lot of troubles because this application is going to let our application fail
often , and we get a lot of instability.
Hi rudolph,
Sorry, but dont' see a question here. Why do you think that the MSDE is
causing instability for your app?
Regards,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"rudolph" <rudolph@.discussions.microsoft.com> wrote in message
news:121817FD-B051-4D59-9690-BDD6DA952ADA@.microsoft.com...
> we get from a company installed at our customer sides an application using
> msde in a win 2000 server (terminal) or higher network enwironment. We
> have a
> lot of troubles because this application is going to let our application
> fail
> often , and we get a lot of instability.
|||Hi Greg!
My question is, that we have done out of a pervasive sql based application
an Interface to a small application. This small application is using msde in
a enviroment, we are using, win 2003 or winn200 Server with terminal clients.
The company, who has done the small aplication we are interfacing has
installed at our clients side either msde or MSSQL Server products, depending
on their stability.We have not been asked by them what they are going to
install I thought, that msde is a client product and not a server product. IS
msde a product which can run simitaniosly in our environment?
"Greg Low [MVP]" wrote:

> Hi rudolph,
> Sorry, but dont' see a question here. Why do you think that the MSDE is
> causing instability for your app?
> Regards,
> --
> Greg Low [MVP]
> MSDE Manager SQL Tools
> www.whitebearconsulting.com
> "rudolph" <rudolph@.discussions.microsoft.com> wrote in message
> news:121817FD-B051-4D59-9690-BDD6DA952ADA@.microsoft.com...
>
>
|||hi Rudolph,
rudolph wrote:
> Hi Greg!
> My question is, that we have done out of a pervasive sql based
> application an Interface to a small application. This small
> application is using msde in a enviroment, we are using, win 2003 or
> winn200 Server with terminal clients. The company, who has done the
> small aplication we are interfacing has installed at our clients side
> either msde or MSSQL Server products, depending on their stability. We
> have not been asked by them what they are going to install I thought,
> that msde is a client product and not a server product. IS msde a
> product which can run simitaniosly in our environment?
I'm not Greg (hi Greg :D) but, again, I do not understand the "stability"
problems...
MSDE is one of the editions of SQL Server, limited some way, but shares the
same core functionnalities and features...
MSDE is not a client product as Access, it's a "scaled down" version of a
full blown "enterprise" DBMS, with built-in limitation for database size,
concurrent workloads, and so on...
as regard as your last question,
>IS msde a
> product which can run simitaniosly in our environment?
I should say yes, but your environment is not public , and of course it
all depends on your requirements..
regards
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
|||Hi Rudolph,
And to add to what Andrea said, we've used it in that sort of environment
many, many times without issue.
HTH,
Greg Low [MVP]
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Andrea Montanari" <andrea.sqlDMO@.virgilio.it> wrote in message
news:35pbuqF4pmdlaU1@.individual.net...
> hi Rudolph,
> rudolph wrote:
> I'm not Greg (hi Greg :D) but, again, I do not understand the "stability"
> problems...
> MSDE is one of the editions of SQL Server, limited some way, but shares
> the
> same core functionnalities and features...
> MSDE is not a client product as Access, it's a "scaled down" version of a
> full blown "enterprise" DBMS, with built-in limitation for database size,
> concurrent workloads, and so on...
> as regard as your last question,
> I should say yes, but your environment is not public , and of course it
> all depends on your requirements..
> regards
> --
> 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
>