There are already plenty of articles and documents related to:

• Changing SCOM Account passwords
• Moving Ops/DW/SSRS databases (which requires some account config)

However, I couldn’t find a complete document that described how to completely replace/change all of the core SCOM accounts for SQL and SCOM. It’s not uncommon for these core service accounts to be changed periodically due to security policies. If you are unable to leverage gMSA for your accounts (now supported by SCOM 2019 UR1) then hopefully this will remove some of the pain associated with changing accounts.

Assumptions

1. You have an existing, working installation of SCOM; a functional SCOM management group (SCOM 2012/2016/2019).
2. You have adhered to best practices and utilized the 4 standard SCOM accounts for your installation:
   OMAA – Management Server Action Account
   DAS/SDK – Data Access Service and Management Configuration Service
   DW Reader – Data Reader account is used to deploy reports and for SSRS service.
   DW Writer – Data Warehouse Write account

Overview

1. Clone existing SQL logins
2. Configure SCOM mgmt servers
   a) Local Admin account membership
   b) User Rights Assignment (Local Security Policy)
   c) Add SPNs for mgmt servers
   d) System Center Data Access service credential update
   e) System Center Management Configuration service credential update
3. Configure SSRS server
   – SQL Server Reporting service (SSRS) Configuration wizard
4. Update credentials for relevant accounts in the SCOM Console
   – Update/create SCOM accounts with new credentials
   – Update security profile
5. Update DWWrite account in DataWarehouse table
6. Verify management group health

Backup your databases and servers.

Seriously, only a rookie clown would attempt to make major changes in their environment without fresh DB backups and/or snapshots of their servers.

1) Clone Existing SQL Logins

Explained in detail HERE

…A quick glance at my cloning results:

I ran all 4 of the scripts and now my new logins are created. They are identical to the original accounts. EASY!

2) Configure SCOM Management Servers

a) Add new SDK/DAS account and OMAA account to Local Admins group membership on SCOM management servers.

I already have a domain global security group (SCOMAdmins) which is already a member of the Administrators local group on all mgmt servers.
I add my 2 new accounts to this domain group:

b) User Rights Assignment (Local Security Policy)

Open Local Security Policy. From the Start menu or cmd prompt (admin) or PowerShell prompt (admin) type:
secpol.msc
..this will open the console.

Add your duplicate accounts wherever you see your original accounts.

Examples of original account permissions:

SCOM 2016 example AFTER adding new accounts…

Note: the Generate security audits permission is not granted by default but is typically allowed for the DAS/SDK account. Add it if you like.

c) Service Principal Names

Remove existing SPNs.
If you set up your environment correctly, you should have SPNs configured for your DAS/SDK account already. We need to delete these because we will be creating new SPNs for the new DAS/SDK account.

Here is an example of how to remove your original SPNs.
PowerShell (RunAs Administrator)

<#
Remove existing SPNs.

'svcOMDAS' is MY SCOM DAS/SDK service account. Use YOUR service account name.
'ms01', 'ms02' are MY server names. Use YOUR server names.

Use YOUR mgmt server names and YOUR DAS/SDK account name
in the commands below
#>

# MS01.contoso.com
setspn -D MSOMSdkSvc/ms01 svcOMDAS
setspn -D MSOMSdkSvc/ms01.contoso.com svcOMDAS
	
# MS02.contoso.com
setspn -D MSOMSdkSvc/ms02 svcOMDAS
setspn -D MSOMSdkSvc/ms02.contoso.com svcOMDAS

Create New SPNs.
Here is an example of how I would set service principal names for the new DAS/SDK account for both of my management servers.
PowerShell (RunAs Administrator)

<#
'svcOMDAS2' is MY SCOM DAS/SDK service account. Use YOUR service account name.
'ms01' is MY first mgmt server name. Use YOUR server names.
	
Set a SPN for both the NetBIOS and FQDN of each mgmt server.
Examples with MY lab mgmt servers:
#>

# MS01.contoso.com
setspn -S MSOMSdkSvc/ms01 svcOMDAS2
setspn -S MSOMSdkSvc/ms01.contoso.com svcOMDAS2
	
# MS02.contoso.com
setspn -S MSOMSdkSvc/ms02 svcOMDAS2
setspn -S MSOMSdkSvc/ms02.contoso.com svcOMDAS2

d) System Center Data Access service

Notice that I am not notified that the new account has been granted the “Log on as a service” permission because this was already granted/configured in the previous step.

Restart the service.

e) System Center Management Configuration service

Restart the service.

3) Configure Reporting Server (SSRS)

Open the Reporting Services Configuration Manager.
This should be available on your SSRS server (wherever the SQL Server Reporting Services is installed).

Connect to the SSRS instance.

Service Account: Update the account credential. This is used for the Windows service: SQL Server Reporting Services

You will be prompted to backup the Encryption Key.

I’m prompted to provide credentials to initiate the new account permissions configuration. (the new account is already configured but this is fine to proceed here)

Service account is updated successfully.

Database: No need to modify anything here.

Update the Execution account if you bother to use one.

4) Update credentials for Relevant Accounts in the SCOM Console

If you check the OperationsManager event log, you will likely see plenty of errors at this point because we still need to configure a few things in the SCOM Console.

Add the new accounts to the user role shown:
Operations Manager Report Security Administrators

Update the Data Warehouse Report Deployment Account
Simply modify the User name and Password fields.

Update the Data Warehouse Action Account
Simply modify the User name and Password fields.

Operations Manager Action Account (OMAA)

Create a new OMAA action account

NOTE: If you attempt to simply modify the account User name in the field shown below, the Console will not update the existing account, instead it will create a second account with the new name.

Configure the Default Action Account profile

Update your management servers with the new OMAA account.

Restart the Windows service: Microsoft Monitoring Agent service on all SCOM mgmt servers.

At this point it’s a good idea to verify that your Default Action Account profile settings were saved correctly.

5) Update DWWrite Account name in DataWarehouse Table

The Writer account is used in this table:
OperationsManagerDW.dbo.vManagementGroup
and must be updated to the new account name.

You will likely see errors in the OpsMan event log related to your new Writer account. Don’t worry, this is expected until you update the DB table.

The easy way: edit the view directly.

Alternate approach:

You will need to know your management group ID. This is easy to get with PowerShell:

Get-SCOMManagementGroup | select Id

Example from my lab:

Once you have your mgmt group Id, you can update your DW with this SQL command:

-- Include your Writer account and SCOM management group ID

UPDATE OperationsManagerDW.dbo.vManagementGroup SET WriterLoginName='DOMAIN\WRITERACCOUNT' WHERE ManagementGroupGuid='YOUR-MANAGEMENTGROUP-ID-HERE'

Verify the update with this SQL command:

USE OperationsManagerDW
SELECT * FROM vManagementGroup

6) Verify that your management servers are happy and healthy