Resetting SDK and Action-Account passwords

Resetting the passwords of the domain-accounts used for the SDK and Action accounts for SCOM can be a pit of a pain. Actually, this is a bit downplayed when I look at the issues I experienced at a customerssite.

This article is based upon a situation where the Action- and SDK-accounts are already Domain Accounts. If that is not the case, don’t read further, but go here.

Eventhough there is a small article about resetting the password used for the domain account for the SDK Service, found here, real-life experiences are a ‘bit’ more tedious. Especially when one is using Reporting in SCOM and this is running under the SDK-Account. Then more changes comes into play.

So let’s start.

The primary changes are straightforward on itself. In the AD one changes the passwords for the Action- and SDK-Account used by SCOM. On the RMS the related services (OpsMgr SDK Service and OpsMgr Config Service) have to be changed so these services reflect the new situation as well. These changes will occur after a restart of these services.

Now the SCOM Console has to be started. Go to the Administration pane and go to Security, Run As Accounts. Check every account listed under Action Account and Windows to see whether adjustments have to be made. If needed, do so and Apply the changes. Double check everything here to be sure all is well.

Then move on to the SQL-server which is also SQL Reporting Server. Open the Services mmc and check whether the SRS-service is running with the SDK-Account. If so, change the password to the new one as well. Restart this service.

Now start IIS Manager and go to Application Pools, Report Server. Right click it, go to the tab Identity and check whether the SDK-Account is being used here as well. If so, change the password to the new one as well. Restart this Application Pool.

On the same server, start the Reporting Services Configuration tool. Go to the fourth option, displayed on the left, Windows Service Identity. Check whether it is running with the SDK-Account. If so, change the password to the new one as well. Click Apply.

Now go to the sixth option, Database Setup. Check whether it is running with the SDK-Account. If so, change the password to the new one as well. Click Apply. Sometimes the first run can give an error. Click Apply for a second time and all is well.

Now go to the eleventh option, Execution Account. Check whether it is running with the SDK-Account. If so, change the password to the new one as well. Click Apply.

Click the button Refresh (upperleft) and check the status of SRS. All should be green, except for SharePoint Integration and Email Settings. These settings are not crucial for SCOM Reporting.

Check this webpage on the SRS server to see whether Reporting is up & running: http://localhost/Reports. It can take a while since the Application Pool has been restarted. But when all is well, the webpage of SRS should be displayed. If not, recheck everything and adjust what and where needed.

Go back to the RMS. Stop all SCOM related services. Start those services again with the OpsMgr Health Service as the least one. But before starting this service, empty the OpsMgr eventlog of the RMS. Keep this eventlog open.

Start the OpsMgr Health Service and check the OpsMgr eventlog. There shouldn’t be any EventID’s with number 7000,source Health Service. When these events occur there are still problems with the validation of the related accounts (Action and/or SDK). Check these events and check under Administration Pane of the SCOM Console to see whether some accounts haven’t been forgotten.

When all is well EventID’s 7026, source Health Service appear after a restart of the OpsMgr Health Service. These events tell you that the validation of the RunAs Accounts has been succesfully.