How to change SMA Service Accounts
A SMA (Service Management Automation) infrastructure has typically two different service accounts being used for running the basic environment.
**Runbook Service Account
** This account is used to execute the Runbook Worker Service, to compile and launch the workflows (runbooks)
**Web Service App Pool Account
** The account is used as the web application pool identity of SMA REST web service
Changing the Runbook Service Account
- Stop all “Runbook Service” services on any runbook workers
- Assign the new user account to all “Runbook Service” services
- Change the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ServiceManagementAutomation\RunbookWorker\ServiceAccount accordingly
(although I’ve found that it works without changing this value, I’d still recommend to do it so) - Add the new user to the local group “Performance Monitor Users” on each runbook worker, remove the old account
- Add the user as a new SQL login on the SQL server hosting the SMA database and assign “dbwowner” rights on the SMA database
- Start all “Runbook Service” services on any runbook workers
Changing the app pool service account
- Stop the SMA IIS application pool on any node hosting the SMA web service
- Change the SMA app pool identity on any node hosting the SMA web service
- Add the the new user to the local group “Performance Monitor Users” on any node hosting the SMA web service, remove the old account
- Start the IIS application pool
General permission considerations
Neither to the runbook service account, nor to the app pool account you should assign extended privileges. The service accounts does not require special permissions, beside the membership of the local Performance Monitor Users group and the right to “logon as a service”. To work with permissions, use SMA credential assets instead and tend to use different credentials for different target systems and services. This prevents you having a “all in one master hero service account”.
Keep calm and automate the world…..