Hello,

I have a client app that connects to a remote instance of SQL Server 2005
Express. The client uses the SQL Browser to locate available SQL instances.

The SQL instance has Shared Memory, Named Pipes, and TCP/IP turned on, and
TCP/IP is configured to use a static port (5721).

The firewall on the SQL machine has the following exceptions: 1434 UDP (SQL
Browser) and 5721 TCP (SQL Server).

I have no problems locating the SQL instance using Management Studio or with
the SQL Browser in my client. However, I cannot connect either with
Management Studio or my client unless I also turn on the "File and Printer
Sharing" exception in the firewall. The BOL says that File and Printer
Sharing is required if using Named Pipes through the firewall, but I don't
understand where Named Pipes are being used when I try to connect.

In my client (C# app) I'm using the SQLConnection class with a very vanilla
connection string; the only addition the the port number of the SQL
instance.

Is SQLConnection using Named Pipes behind the scenes? Can someone explain
what's going on here and suggest how I might get around having to turn File
and Printer Sharing on?

Thanks!

Keith

P.S. Everything works fine if the firewall is turned off.

Perhaps the connection is made using Named Pipes? I'd use cliconfg.exe on the client to verify that
TCP/IP (sockets) is selected higher than Named Pipes. Sockets shouldn't require anything else but
the TCP port. Unless you are trying a Windows logins, of course. Also, since you specify the port in
your connection string, you shouldn't need the SQL Server browser service on the server (unless it
is needed for other purposes, of course).

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi


"Keith" <keith (AT) alh (DOT) com> wrote

"Tibor Karaszi" <tibor_please.no.email_karaszi (AT) hotmail (DOT) nomail.com> wrote in
message news:4F9AE0A4-4F1B-462E-AD9B-3C840072AC33 (AT) microsoft (DOT) com...
Tibor,

Thanks for the reply. Could you clarify what you mean when you said "Unless
you are trying a Windows logins, of course." Are you saying that Windows
Authentication/Mixed Mode uses Named Pipes to communicate with the domain
controller? I was not aware of that. I am using mixed mode authentication.

Thanks!

Keith

That is a server-side setting. What matters is how the client tries to connect. IS the client
connecting using a Windows account or using a SQL Server account?

For Windows authentication, SQL Server need to enumerate the SIDs for the account you pass with
Windows (DC). The client should be able to connect using TCP/IP Sockets, assuming the client user
has logged into the AD in the first place. If not, I assume that some AD validation is attempted
when the login to SQL Server is performed. (But I admit that AD is far from my expertise...)

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi


"Keith" <keith (AT) alh (DOT) com> wrote

"Tibor Karaszi" <tibor_please.no.email_karaszi (AT) hotmail (DOT) nomail.com> wrote in
message news:E402B142-E357-4124-A897-43E4D1747848 (AT) microsoft (DOT) com...
I assume Windows account since I'm not passing any user/pw information in
the connection string.

The user(s) are already members of the domain. In this particular instance,
the user is me and I'm a domain/olap admin.

BTW I looked for "cliconfig.exe" so I could check the client-side
configuration and didn't find it anywhere on my machines. What package/app
installs it?

Then I assume you say something like "Integrated security = true", or "trusted connection".


If you have logged on to the domain, then ti sould work fine over the TCP/IP netlib.


It is cliconfg.exe, not cliconfig.exe. It is part of Windows.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi


"Keith" <keith (AT) alh (DOT) com> wrote

"Tibor Karaszi" <tibor_please.no.email_karaszi (AT) hotmail (DOT) nomail.com> wrote in
message news:EBDE3F42-3AF0-4A34-8EB3-C67C8D771FE9 (AT) microsoft (DOT) com...
Yes, trusted connection.

My apologies, now I see it. I verified that TCP is before Named Pipes, and
even disabled Named Pipes but
I still can't connect using either my client app or Management Studio.
(error 26 : Error location server/instance specified) after easily locating
it with the browser.

In my client I even tried to force a protocol in the collection string using
tcp:<server/instance> and also Network Library=DBMSSOCN but with no luck.

I'm in the process of trying all these permutations on a clean(er) machine,
but in the mean time do yo have anymore suggestions?

Keith

I'm out of ideas, I'm afraid. Sounds to me more like a Windows/network/security issue to me, which
is a bit out of my expertise.--

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi


"Keith" <keith (AT) alh (DOT) com> wrote