June 12, 2019 at 12:51 pm
I need to change the SQL server service and agent service accounts on my SQL server instances. However they are in a 2 node active/passive cluster configuration.
I am not sure how to proceed, what is the best process to change the accounts?
June 12, 2019 at 2:26 pm
Fail over so that both/all instances are on Node 1. Change the service accounts on Node 2. Fail over both/all instances Node 2. Change the service accounts on Node 1. Fail each instance back to its starting location.
John
June 12, 2019 at 2:31 pm
I have said Instance, thereby implying I am using FCI, I am using just Availability Groups. I need to change the SQL Server service and Agent account on both sql server instances where there is always on using availability groups.
June 12, 2019 at 2:38 pm
Same principle. Fail over all AGs to one node, do whatever maintenance you need on the other, then do it again in reverse. I take it you don't have any non-AG production databases on either of the nodes?
John
June 12, 2019 at 2:46 pm
No, there are no no-AG databases. Ok thanks for the reply seems simple enough - failover AGs to primary, change SQL Server/Agent accounts on secondary and then do the same in reverse.
June 13, 2019 at 11:25 am
I have tried changing the SQL Server Agent account first through Configuration Manager. However after entering the new service account name and password and hitting the apply button I get the following error -
'The specified network password is not correct.'
Having checked the password is correct I am at a loss as to what is wrong. I am an admin on the box but not a domain admin, but I have changed this before from the default to using a gMSA account, however now we are having to go with just a normal domain service account.
June 13, 2019 at 3:00 pm
Ensure your sysadmin hasn't left the 'User must change password at first login' checkbox checked when he\she created the service accounts.
June 20, 2019 at 2:49 am
On a GMSA, make sure you assign the account permissions in Windows. Depending on the application I have found that logon as service, logon as a batch and log on locally have been required. I usually assign all three of those. depending on the service, it may need to use the local profile, which would require logon rights and there can be some things that require batch logon rights.
July 28, 2020 at 6:39 pm
You will have to at some point restart the services. Once you do that it breaks the AoAG and they stop syncronizing. Not sure why others have suggested that just changing the account on the secondary and then failing over, and then changing the account on the primary and then failing back over WITHOUT restarting the services somehow works, because it doesn't.
What we need to know is if it's possible to change service accounts on both servers in the cluster without disrupting the AoAG syncronization, and without having to drop the databases out of AoAG on the secondary. What we've found is that you basically have to remove the databases from the availability group, update the service accounts on the secondary, then update the accounts on the primary, and then add the databases back into the availability group. We'd like to prevent that. And you can't from what has been suggested by others previously.
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply