November 5, 2015 at 8:20 am
I have a vendor's SQL Server 2008R2 that I'm being asked to back up. I changed the SQL Server and Agent services to run under our domain SQLAdmin service account. It was under a local user account. I know the services have been restarted since the change. My service account is in the sysadmin role. But I can't run a backup, message: Could not obtain information about Windows NT group/user 'mydomain/myuser', error code 0x5.
In my searching and poking around, I see that all the server roles are disabled (red arrow pointing down).
My thinking is I should be able to enable the sysadmin role and be good, but can't find how to do that.
Can anyone help?
Thanks much.
November 5, 2015 at 8:56 am
0x5 is an access denied error.
When you changed the service account did you use services.msc or SQL Server Config Manager?
Also if backing up to a network share, does the accounts have access?
Server roles cant be disabled, are you using SSMS 2012 to look at 2008R2 instances? what your seeing is a Pin not an arrow, the Pin details that the role is static and cannot be modified as with 2012 on wards you can create custom server roles.
November 5, 2015 at 9:14 am
Yes, using SSMS 2012. I used service.msc to change the service login. And yes, the account running SQL Server and the Agent have access to the network share. Its the same account and same shares I back up all my SQL Servers to.
In SSMS, if I run:
execute as user='myDomain\myAccount'
go
I get error "Could not obtain information about Windows NT group/user 'myDomain\myAccount', error code 0x5."
November 5, 2015 at 9:15 am
Even if I back up to a local drive, I can't copy that file to the network.
November 5, 2015 at 11:57 am
Service accounts should be changed via config manager not services.msc.
Open up config manager switch the account back to the original account, then switch it back to domain account. This ensures that the nessesary permission sets are applied to the services accounts for running sql. As it adds the account into the nessesary groups and re-encrypts the service master key otherwise you can run into problems.
General best practise is that each service and server has its own account that way if the account is compromised it's only that one service that is potentially affected and not every service that uses that account.
November 5, 2015 at 12:16 pm
I'll have to do that after hours when the app is idle. I'll have to change it to the built in Network Service account then back. The services were being run by a local account the vendor set up and I don't know the password.
Its rare that I don't install SQL Server here, even with vendor apps, so I'm not often changing service logins.
Thanks for the information. I'll post the results.
November 6, 2015 at 8:13 am
Changing the service accounts through the Configuration Manager worked.
Thank you very much.
Viewing 7 posts - 1 through 6 (of 6 total)
You must be logged in to reply to this topic. Login to reply