Named Pipes
-
I don't have a problem per se, but I've ran across a situation upgrading/migrating SQL Server from a non-dedicated to a dedicated server. The co-hosted applications run using the TCP/IP protocols. However, the upgrade process for the applications run using Named Pipes (don't ask me why).
The only way I could get Named Pipes to work with the newly separated/upgraded SQL Server host was to make the application's login context a Windows Admin on the new SQL Server. Different versions of client tools make no difference. I've tested back-and-forth: Admin... Go, Not-Admin... No Go. Is that normal? Has anyone else run into the Named Pipes/Admin issue?
Just curious. All systems still operational.
-
The app might have been an admin on the nondedicated machine and you were not aware of it. Being an admin and named pipes v TCP should not have anything to do with each other.
Follow me on Twitter: http://www.twitter.com/way0utwest
Forum Etiquette: How to post data/code on a forum to get the best help
My Blog: www.voiceofthedba.com -
The app was/is an admin on the nondedicated machine. I just didn't understand why it had to be an admin on the newly separated SQL server in order for named pipes to work. If I can connect to SQL using TCP w/o admin rights or a Windows account (it uses SQL Server login - I know, don't remind me best practices are to use Windows account), why do I need admin rights or a Windows account to use Named Pipes? Is there a Named Pipes/Windows Authentication type issue associated with Named Pipes that doesn't pertain to TCP?
Again, all is working ok. This is just one of those "inquiring minds want to know" type things.
-
Has the app's admin account been granted to access SQL Server?
Did non-admin accounts work with TCP/IP? Same question too, are they granted to access SQL Server?
-
The app's windows account has not been granted access to the new SQL Server. The app uses SQL authentication with a login that is dbo to a dedicated database. TCP/IP works just fine. NP only works after the app's windows account is made a member of the new server's Administrators group which also results in SQL sysadmin membership through BUILTIN\Administrators. The original SQL login used in the DSN in ODBC Administrator never changes. Only the protocol of the DSN is changed. TCP/IP works w/ or w/o windows Administators group membership. NP only works w/ windows Administators group membership. Why does NP require windows Administrators group membership and TCP/IP doesn't?
-
NP demands an "authenticated network connection". You can try to see if you can connect with explorer to the SQL server as you say that the app's windows account has not been granted access to the new SQL server. If you can't connect, you will not be able to connect with NP. You should not need to be an admin, but you need to be able to access the SQL server machine. TCP does not have this type of validation, and can validate directly against SQL server.
This is because NP is a kind of network access protocol.
-
Halleluiah. I was suspecting something of that nature, but never ran across it before. Thanks.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply