February 10, 2011 at 8:10 am
We want to rollout a new account to use for SQL Services. On a Dev server (SQL 2005 SP3, Windows Server 2003 SP2), I changed the account through SQL Configuration Manager. After restarting the services, from my remote desktop, I get an error "Cannot Generate SSPI Context" when I try to connect with Windows Authentication. 'sa' connects fine remotely, and Windows authentication is fine if I log on to the server and open SQL there.
I've tried various combinations of changing services to LocalSystem, then back to the new account, rebooting between changes, doing steps in different sequence. Once or twice, it has then worked, but when I try later, I get the error again.
Is there a "best practice" list for changing SQL services to a new account ?
February 10, 2011 at 8:20 am
Can you try to drop server and add server back?
Sp_dropserver @Servername
Sp_addserver @Servername,local
February 10, 2011 at 10:07 am
How would that help ? Isn't that for renaming the server ?
I just changed the Service account to LocalSystem, restarted, changed to my new SQL Service Account, restarted, and it worked - I could connect.
Then I rebooted the server and got the error again ?!?!?! Back to square 1 :angry:
February 10, 2011 at 12:54 pm
I had a similiar experience. SQL logins had no problem to connect to SQL. only one Windows Logins could connect, other not.
Drop server and add server did help on my case.
February 10, 2011 at 2:26 pm
homebrew01 (2/10/2011)
How would that help ? Isn't that for renaming the server ?I just changed the Service account to LocalSystem, restarted, changed to my new SQL Service Account, restarted, and it worked - I could connect.
Then I rebooted the server and got the error again ?!?!?! Back to square 1 :angry:
You need to add a SPN in AD.:-)
February 10, 2011 at 2:31 pm
You need to manually delete the SPN fo MSSQLSvc in AD linked to the old account.
Run this in a command prompt to verify that there is a MSSQLSvc SPN registered on the old account:
setspn -L <old account name>
If you see a MSSQLSvc/srvname you have to delete it with setspn -D
February 14, 2011 at 8:25 am
Is this an expected situation when changing the SQL Service account ?
Or did I do something wrong initially ?
I'd like to avoid any problems when I do the production servers.
February 14, 2011 at 9:21 am
At least it is what has happened to me every time we change the service account. I don't know if there is a way to avoid it (having the account removing and re-registering the SPN). Perhaps someone else can enlighten us on this issue.
February 15, 2011 at 12:35 pm
I don't see SETSPN.exe on the server, so maybe server tools are not installed. Perhaps the original problem is caused by the old SQL Services account being a domain admin at some point, and the new SQL Services account I want to use is only a local admin on the sever, and can't alter the SPN behind the scenes when I change the logon information for the service ?
February 15, 2011 at 1:41 pm
You can use adsiedit and remove/add the servicePrincipalName in AD, but you can also use another pc or server with Windows and run setspn.
February 21, 2011 at 12:18 pm
Thanks for the help ... (Big Edit because I think I found the problem... didn't realize there was already a reply)
Here's a follow-up for anyone else with a similar problem
I logged onto a 3rd server, thinking I could now change the SQL services account to the new account (I'm local admin on the box). It accepts the change, but I get an error of "Access Denied" after chaning the account, and SQL Services won't start. Event Log says: Server local connection provider failed to listen on [ \\.\pipe\SQLLocal\MSSQLSERVER ]. Error: 0x5
Worse than before !
I search the error and found this, suggesting a reboot should fix it http://blogs.msdn.com/b/sql_protocols/archive/2006/03/09/546655.aspx
" ... snip ... If the listening named-pipes are not closed properly during the last shutdown of SQL Server, there will be orphan named-pipe handles in the windows kernel file system. Since the listening pipes are opened ACLing to the current user, if you happen to switch SQL Server to run under different account, you will get error 0x05(ERROR_ACCESS_DENIED). ... snip ...
The solution is to either switch back to previous account and make a clean shutdown of SQL Server, or reboot the machine. In most cases, I feel the later is faster.... snip"
... so far, so good:
February 21, 2011 at 12:40 pm
Did you use SQL Server Configuration Manager to change the account? Is the new account member of any local Windows security groups? What errors are logged for SQL Server during startup in the event log and SQL Error log (<SQL Server installation path>\Data\Log\)?
February 21, 2011 at 12:58 pm
Nils, Sorry for the confusion and thanks for all your help ... see my corrected & edited post above.
February 21, 2011 at 1:29 pm
Hope the reboot will fix the problem 🙂
January 17, 2013 at 7:05 am
I am currently sitting with the same issue on a SQL 2008 R2 server running on a Server 2003 R2 SP2 OS, I had to install the setspn.exe from http://www.microsoft.com/en-us/download/details.aspx?id=4461
I got the server registered by running setspn -R MYSERVERNAME in command prompt.
I will let you know if this resolved it after the server gets restarted later.
Viewing 15 posts - 1 through 15 (of 20 total)
You must be logged in to reply to this topic. Login to reply