November 29, 2004 at 2:44 pm
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.
November 29, 2004 at 9:12 pm
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.
November 30, 2004 at 7:01 am
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.
November 30, 2004 at 8:09 am
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?
November 30, 2004 at 9:18 am
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?
November 30, 2004 at 1:15 pm
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.
November 30, 2004 at 1:20 pm
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