gMSA Configuration, Operations Manager 2019 UR1

12/14/2020, Version 1.3 Final

Prepared by:
CJ Rawson
Senior Customer Engineer

Contributors:
Scott Mathemeier
Senior Customer Engineer

Editing and other minor contributions:
Tyson Paul
Senior Customer Engineer

Revision and Signoff Sheet
Change Record

Date	Author	Version	Change Reference
06/06/2020	CJ Rawson	1	Initial final for review/discussion
06/10/2020	CJ Rawson	1.1	Added Security Matrix to Appendix
06/16/2020	Scott Mathemeier	1.2	Updated verbiage, nomenclature, formatting
12/14/2020	Scott Mathemeier	1.3	Update service account verbiage and SQL Ops Mgr db roles table

Reviewers

Name	Version Approved	Position	Date

Table of Contents

1 gMSA Implementation Summary 5

1.1 Business Need 5

1.2 Implementation Intent and Benefits 5

2 Implementation Overview 6

2.1 Scope 6

2.2 Approach 6

3 Implementation Assumptions 8

4 Process Preparation 9

4.1 Create list of servers 9

4.2 Create list of service accounts aligned to gMSAs 9

4.3 Prepare Active Directory (If gMSA not already enabled) 9

5 Create and Populate Server Security Groups 10

6 Create and Verify the gMSAs in Active Directory 11

6.1 Create SQL gMSAs 11

6.2 Create SCOM gMSAs 13

6.3 Verify gMSA configuration 14

7 Update Applicable Domain Resources 15

7.1 SCOM Security Groups 15

7.2 SCOM User Rights Assignments 15

7.3 SQL Security Groups 16

7.4 SQL User Rights Assignments 16

8 Install and test gMSA on applicable servers 17

8.1 SQL Servers 17

8.2 SCOM Servers 17

8.3 Reporting Server 18

9 Configure SQL gMSAs 19

9.1 Database Configurations 19

9.2 Service Logon Configurations 23

10 Configure SSRS gMSA 25

10.1 Backup Encryption Key 25

10.2 Service Logon Configuration 25

10.3 Reporting Instance Configurations 26

11 Configure SCOM gMSAs 29

11.1 Update the DAS/SDK logons 29

11.2 Update RunAs Accounts 29

11.3 Update User Roles 32

12 Post implementation validation and clean-up 33

13 Appendix: 34

13.1 References 34

gMSA Implementation Summary

Operations Manager 2019 UR1 supports group managed service accounts (gMSA). This instructional guide details the accounts used for gMSA, and the procedure involved to configure gMSA support.

Business Need

gMSAs provide a single identity solution for services running on a server, server farm, or on systems behind a Network Load Balancer. By providing a gMSA solution, services can be configured for gMSA principal and the password management handled by Windows.

When gMSAs are properly implemented, services or service administrators do not need to manage password synchronization between service instances. The gMSA supports hosts that are kept offline for an extended period-of-time, and management of member hosts for all instances of a service. This means you can deploy a service that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.

Implementation Intent and Benefits

A standalone Managed Service Account (sMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators. This type of managed service account (MSA) was introduced in Windows Server 2008 R2 and Windows 7.

The group Managed Service Account (gMSA) provides the same functionality within the domain but also extends that functionality over multiple servers. When connecting to a service hosted on a server farm, such as a Network Load Balanced solution, the authentication protocols supporting mutual authentication require that all instances of the services use the same principal. When a gMSA is used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.

The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. The Key Distribution Service shares a secret which is used to create keys for the account. These keys are periodically changed. For a gMSA, the domain controller computes the password on the key provided by the Key Distribution Services, in addition to other attributes of the gMSA. Member hosts can obtain the current and preceding password values by contacting a domain controller.

Implementation Overview

With this instruction, administrators will be able to replace existing service and RunAs accounts with Group Managed Service Accounts (gMSA). This guide includes the Operations Manager and Operations Manager Data Warehouse SQL instances as well.

Scope

Currently, Operations Manager uses the following accounts and services:

• Action Accounts
  An “Action Account” is an account that you can designate for any agent (this includes mgmt servers) to use as the default. This account will be used for all workflows unless there is some other “RunAs” account specified in an account profile (AKA Security Profile) applicable to the agent.
  • Management Server Action Account – this is the default action account designated for management servers to use for all workflows that execute on the mgmt servers. This is a domain account with local admin permissions on the mgmt servers.
  • Agent Action account – This is almost always Local System.
  • GW Server Action account – This is almost always Local System.
  • Run as accounts – Any additional account that should/could be added to a given Security Profile; example: SQL Server Discovery. Any SQL discovery workflows that execute on the agent and that reference the SQL Server Discovery Profile will then use the account specified in the profile.
• System Center Management Configuration service and System Center Data Access Service (needs to be a part of local admin group).
  This is a domain account and is typically referred to as the “SDK” or “DAS” account although it is used for both the SDK/DAS service and the SC Mgmt Configuration service.
• SQL Accounts
  • Data Reader account (for SSRS)* (see below about gMSA for this account)
  • Data Warehouse Write account (for DW)
  • SQL Engine Service Account
    OperationsManager and OperationsManager DW Database Instances
  • SQL Agent Service Account
    OperationsManager and OperationsManager DW Database Instances. This is usually the same as the SQL Engine account.
• Agent Installation account
  • During agent deployment from the Console, the Management Server Action Account (MSAA) is presented as the default. (At the time of this writing. )
    However, this MSAA account should not be used for agent deployment. That is to say that the MSAA should not have local admin permissions on any servers beyond your SCOM management servers. Why is this account selected as the default? It shouldn’t be and this point has already been addressed with the System Center Product Group. Hopefully we’ll see this get updated in a future release.
    2023.02.10: This has been corrected in SCOM 2022

This guide will only cover core accounts for core feature functionality. Additional features, accounts, and services can be added following the same procedures as applicable to the intended instance.

* Please note that a gMSA account is NOT officially supported for the SQL report server service for the Data Reader account for SCOM.

BUT it’s obviously possible. Many folks have implemented it in their own environments and it works great. Proceed with gMSA for the Data Reader account at your own risk. Don’t expect support from Microsoft if you can’t get it to work correctly.

Approach

In order to replace the current accounts with gMSAs, the following tasks must be completed:

• Plan:
  • Identify accounts to be replaced by gMSAs
  • Identify servers and/or groups of servers to manage the applicable gMSAs
• Prepare:
  • Configure Active Directory for first-time use of gMSAs
  • Create and configure security groups if/as applicable
  • Delete existing Service Principal Names (SPNs) that will be replaced
  • Create and verify gMSAs
  • Update security group membership
  • Update user rights assignment group policies

Implement:

• Install Active Directory PowerShell Modules on each server managing gMSAs
• Install and test gMSA on each server as applicable to hosted services and configured permissions

Configure SQL:

• Add gMSA accounts to existing database instance logins
• For each service account being replaced, replicate instance mappings and permissions with the gMSA it is being replaced with.
• Update service logons

Configure SSRS:

• Backup encryption key
• Update service logon
• Change database credentials
• Verify execution account (CANNOT be gMSA, requires logon locally permission; do not “deny” the log on locally permission)
• Restore encryption key

Configure SCOM:

• Update service logons
• Update RunAs accounts
• Update Data Warehouse database writer logon name
• Update User Roles

Post Configuration:

• Verify all services are running as expected
• Perform reboots and failovers as applicable
• Disable/Clean-up old service accounts
  • Verify before deleting; however, old SQL accounts should be cleaned-up following this process as SQL supports gMSA natively during install
  • Note: You may want to keep the SCOM service accounts available and just disable them, as you will need them when adding or reinstalling features as SCOM 2019 RTM does not support gMSA.

Implementation Assumptions

The following assumptions have been made in preparing this guide:

• The implementation team has a working knowledge of Active Directory, SQL, Operations Manager, and PowerShell
• Accounts being replaced by gMSAs have been compiled and reviewed for eligibility
• Servers managing gMSAs have been compiled and reviewed for eligibility
• The current Operations Manager environment is at 2019 UR1 or higher
• The current Operations Manager environment (to include SQL) is in a “Healthy” state
• The script execution policy enables the necessary PowerShell scripts to be run:

# View Policy
Get-ExecutionPolicy

Process Preparation

Create list of servers (my lab servers examples)

SQL Servers

• CJRPASQLV0001 (SQL Cluster Node 1)
• CJRPASQLV0002 (SQL Cluster Node 2)
• CJRPASQLVC001 (SQL Cluster Virtual Namespace)

SCOM Servers

• CJRPASCOV0001 (SCOM Management Server)
• CJRPASSRV0001 (SCOM Reporting and Web Console Server)

Create list of service accounts aligned to gMSAs

SQL Service Accounts

• SQL Service Agent Account for SCOM and SCOMDW Instances
  • Svc-scom-sqla -> gMSA-SCOM-SQLa
• SQL Service Engine Account for SCOM and SCOMDW Instances
  • Svc-scom-sqle -> gMSA-SCOM-SQLe

SCOM Service Accounts

• Management Server Action Account (MSAA)
  • Svc-scom-msa -> gMSA-SCOM-MSA
• Data Warehouse Write Account (DW Write)
  • Svc-scom-dwwrite -> gMSA-SCOM-DWW
• Data Warehouse Report Deployment Account (DW Read)
  • Svc-scom-dwread -> gMSA-SCOM-DWR
• Data Access Service Account (DAS/SDK)
  • Svc-scom-das -> gMSA-SCOM-DAS

Prepare Active Directory (If gMSA is not already enabled)

Active Directory requires a prerequisite enablement command to be run before you introduce group Managed Service Accounts (gMSA) into the domain.

# prerequisite enablement
Add-KdsRootKey -EffectiveTime ((Get-Date).addhours(-10))

Create and Populate Server Security Groups

For this environment we’re configuring two groups of gMSAs to support this SCOM deployment, SQL and SCOM. These can be broken out or condensed as you see fit for your environment. The same process would apply for each.

Each server must be restarted when added to a security group.

This applies the intended membership/permissions.

Create two global security groups in Active Directory. Be sure to add “Computers” to the Object Types when searching for the computers to add to the security groups. These computers will have permissions to manage the gMSAs associated later in this process.

You also have the option to assign permissions to specific computer objects; if this is the case, you do not need to create the groups. This is just an easier way to update/manage permissions.

One group for your SQL servers – we leveraged the cluster name to create the group name.

One group for your SCOM Servers – we included the Management and Reporting server.

Create and Verify the gMSAs in Active Directory

Create SQL gMSAs

There will be two accounts applicable to the SQL instances in this scenario, SQL engine and SQL agent accounts. These accounts are leveraged for both SCOM and SCOMDW SQL instances. Again, you’re able to further breakout the groups/permissions if your environment requires it.

If your environment blocks RC4, this is the default encryption type and will fail configuration if you do not change it. Be sure to specify the encryption type to avoid issues.

Include any applicable SPNs, be sure to remove these SPNs from previously configured accounts beforehand.

Here is the current SQL Engine service account/SPN alignment:

# list SPN
SetSPN -l svc-scom-sqle

Find the service account in Active Directory and edit the “Attribute Editor” properties for “servicePrincipalName”: (You can also perform this step via “SetSPN -d”)

Before:

After:

Once you’ve identified your encryption capabilities and deleted any SPNs you need to realign, you’re ready to create the SQL gMSA accounts for SQL.

Keep in mind, there is a 15-character limit to a gMSA account name.

To clarify the variables: “Name” is the name of the gMSA you’re creating.
“DNSHostName” is the domain controller you’re leveraging for the account creation.
“DNSHostName” is the fully qualified domain name (FQDN) of the service account.
“PrincipalsAllowedToRetrieveManagedPassword” is the group or computer object you’re assigning permissions to the service account. “KerberosEncryptionType” is/are the encryption types supported/desired (If not specified, ‘None‘ is default)

New-ADServiceAccount -Name gMSA-SCOM-SQLa -DNSHostName gMSA-SCOM-SQLa.CJRawson.lab -PrincipalsAllowedToRetrieveManagedPassword grpsec-SQL_CJRPASQLVC001 -KerberosEncryptionType AES128,AES256

The account will appear in the “Managed Service Accounts” container in Active Directory.

New-ADServiceAccount -Name gMSA-SCOM-SQLe -DNSHostName gMSA-SCOM-SQLe.CJRawson.lab -PrincipalsAllowedToRetrieveManagedPassword grpsec-SQL_CJRPASQLVC001 -KerberosEncryptionType AES128,AES256 -ServicePrincipalNames MSSQLSvc/CJRPASQLVCV04.CJRawson.lab:SCOM, MSSQLSvc/CJRPASQLVCV04.CJRawson.lab:49440, MSSQLSvc/CJRPASQLVCV04:49440, MSSQLSvc/CJRPASQLVCV04:SCOM, MSSQLSvc/CJRPASQLVCV05.CJRawson.lab:SCOMDW, MSSQLSvc/CJRPASQLVCV05.CJRawson.lab:49444, MSSQLSvc/CJRPASQLVCV05:49444, MSSQLSvc/CJRPASQLVCV05:SCOMDW

Once created, verify your SPNs are set by checking the gMSA account properties:

New SPNs:

Or by leveraging the SetSPN -l command:

Create SCOM gMSAs

Following the same process, here is the list of accounts being configured for the SCOM Server Group. The same process applies for each group/server as they align permissions to each gMSA.

• Management Server Account (MSAA)
• Data Warehouse Write Account (DW Write)
• Data Warehouse Report Deployment Account (DW Read)
• Data Access Service Account (DAS/SDK)

Keep in mind, if you’re leveraging SPNs for your current DAS/SDK account, you’ll need to remove them prior to creating the new gMSA with the SPNs.

Remove SPNs before creating the DAS/SDK gMSA:

Once the SPNs are cleaned-up, here are the commands to create the gMSAs in Active Directory:

New-ADServiceAccount -Name gMSA-SCOM-DWR -DNSHostName gMSA-SCOM-DWR.CJRawson.lab -PrincipalsAllowedToRetrieveManagedPassword grpsec-SCOM_OpsMgrServers -KerberosEncryptionType AES128,AES256

New-ADServiceAccount -Name gMSA-SCOM-DWW -DNSHostName gMSA-SCOM-DWW.CJRawson.lab -PrincipalsAllowedToRetrieveManagedPassword grpsec-SCOM_OpsMgrServers -KerberosEncryptionType AES128,AES256

New-ADServiceAccount -Name gMSA-SCOM-MSA -DNSHostName gMSA-SCOM-MSA.CJRawson.lab -PrincipalsAllowedToRetrieveManagedPassword grpsec-SCOM_OpsMgrServers -KerberosEncryptionType AES128,AES256

New-ADServiceAccount -Name gMSA-SCOM-DAS -DNSHostName gMSA-SCOM-DAS.CJRawson.lab -PrincipalsAllowedToRetrieveManagedPassword grpsec-SCOM_OpsMgrServers -KerberosEncryptionType AES128,AES256 -ServicePrincipalNames MSOMSdkSvc/OpsMgr, MSOMSdkSvc/OpsMgr.CJRawson.lab, MSOMSdkSvc/CJRPASCOV0001, MSOMSdkSvc/CJRPASCOV0001.CJRawson.lab

Accounts created in the “Managed Service Account” container in Active Directory

View Updated SPNs:

Verify gMSA configuration

Run the following commands in context with your environment to verify the configuration:

Get-ADServiceAccount gMSA-SCOM-SQLa -Properties msDS-GroupMsaMembership | Select -Expand msDS-GroupMsaMembership | Select -Expand Access | Select -Expand IdentityReference

Get-ADServiceAccount gMSA-SCOM-SQLe -Properties msDS-GroupMsaMembership | Select -Expand msDS-GroupMsaMembership | Select -Expand Access | Select -Expand IdentityReferencep

Get-ADServiceAccount gMSA-SCOM-DWR -Properties msDS-GroupMsaMembership | Select -Expand msDS-GroupMsaMembership | Select -Expand Access | Select -Expand IdentityReference

Get-ADServiceAccount gMSA-SCOM-DWW -Properties msDS-GroupMsaMembership | Select -Expand msDS-GroupMsaMembership | Select -Expand Access | Select -Expand IdentityReference

Get-ADServiceAccount gMSA-SCOM-MSA -Properties msDS-GroupMsaMembership | Select -Expand msDS-GroupMsaMembership | Select -Expand Access | Select -Expand IdentityReference

Get-ADServiceAccount gMSA-SCOM-DAS -Properties msDS-GroupMsaMembership | Select -Expand msDS-GroupMsaMembership | Select -Expand Access | Select -Expand IdentityReference

Update Applicable Domain Resources

SCOM Security Groups

In this environment we leverage two security groups to apply user rights assignments for SCOM.

Update “SCOM_Admins” global security group to include the new SDK/DAS gMSAs.
Note: This group has local admin permission on the management servers.

SCOM_Admins Security Group Additions:

• gMSA-SCOM-MSA
• gMSA-SCOM-DAS
  
  

Update “SCOM_RunAs” global security group to include the new SCOM gMSAs.
Note: This group has “Log on as a service” user right via Group Policy.

SCOM_RunAs Security Group Additions:

• gMSA-SCOM-DWW
• gMSA-SCOM-DWR
• gMSA-SCOM-MSA
• gMSA-SCOM-DAS

SCOM User Rights Assignments

Leverage Group Policy to update/enable required user rights assignments:

Add the gMSA-SCOM-DWR and gMSA-SCOM-DWW accounts to the “Log on as a batch job”.

Add the gMSA-SCOM-DAS account to the “Generate security audits” user right via Group Policy. The old DAS/SDK account will be removed post completion of the gMSA configuration.

SQL Security Groups

In this environment we leverage a security group to apply user rights assignments for SQL service accounts.

Update “SQL_SvcAccounts” global security group to include the SQL gMSAs.

SQL_SvcAccounts Security Group Additions:

• gMSA-SCOM-SQLe
• gMSA-SCOM-SQLa
• gMSA-SCOM-DWR

SQL User Rights Assignments

Leverage Group Policy to update/enable required user rights assignments:

Install and test gMSA on applicable servers

Each server leveraging a gMSA requires the Active Directory PowerShell Modules installed. This is built into the Windows image and can be installed with the following PowerShell commands:

Import-Module ServerManager

Add-WindowsFeature RSAT-AD-PowerShell

Import-Module ActiveDirectory

SQL Servers

Run the following commands to configure and test the gMSAs. They should each return a value of “True”:

Add-WindowsFeature RSAT-AD-PowerShell

Import-Module ActiveDirectory

Install-ADServiceAccount gMSA-SCOM-SQLe

Install-ADServiceAccount gMSA-SCOM-SQLa

Test-ADServiceAccount gMSA-SCOM-SQLe

Test-ADServiceAccount gMSA-SCOM-SQLa

SCOM Servers

Run the following commands:

Install-ADServiceAccount gMSA-SCOM-DWR

Install-ADServiceAccount gMSA-SCOM-MSA

Install-ADServiceAccount gMSA-SCOM-DAS

Test-ADServiceAccount gMSA-SCOM-DWW

Test-ADServiceAccount gMSA-SCOM-DWR

Test-ADServiceAccount gMSA-SCOM-MSA

Test-ADServiceAccount gMSA-SCOM-DAS

Reporting Server

Run the following commands:

Import-Module ServerManager

Add-WindowsFeature RSAT-AD-PowerShell

Import-Module ActiveDirectory

Install-ADServiceAccount gMSA-SCOM-DWR

Test-ADServiceAccount gMSA-SCOM-DWR

Configure SQL gMSAs

Database Configurations

There are articles online explaining minimum permissions for each account; however, I recommend taking note of current service account permissions in case you have custom permissions setup for additional applications/services associated with your databases/instances. Alternatively, you can match permissions up one-for-one as I’m going to explain below. This ensures you have the necessary permissions associated with your environment.

If for some reason things do not come back online as anticipated following the changes, leverage the article in the appendix to view and validate required permissions.

Note for SQL AlwaysOn Availability Groups: you will create the logins and permission on the primary node, then create just the logins on the secondary nodes. The permissions will follow the accounts to the secondaries as long as the logins exist.

In this environment, there are two SQL instances: SCOM and SCOMDW.

Create the new logins under each instance as applicable:

Within SQL Server Management Studio (SSMS), connect to your instances:

Starting with SCOM:

Expand the tree under SCOM>Security>Logins – Right-click Logins and select “New Login”

Select “Search”

Select “Change Location” and change it to either “Entire Directory” or a domain within the directory.

Next, select “Object Types…” and add “Service Accounts”

Enter the service account name you want to add and select “Check Name” to ensure it resolves.

Verify account information for the new login and select “OK”

Do this for each service account you’re replacing with a gMSA. Changes to the environment look like this:

SCOM Instance Before:

SCOM Instance After:

SCOMDW Instance Before:

SCOMDW Instance After:

Once you identify the applicable service accounts being replaced by gMSAs, you will go into each SQL instance and database to perform a one-to-one permissions replacement from the service account being replaced to the aligned gMSA. This is a recommendation as there have been issues for some when trying to set permissions based on general guidance. Keep in mind, if this is a new instance or one with no SQL permission customizations, the permission matrix located at the end of the article provides minimum permission requirements.

The following screenshots are to be used as process instruction and example only, they intentionally do not show full permission/instance alignment as the lab is not configured for default permissions and we do not want to confuse implementers nor do we want to provide an assumption all environment permissions are the same.

Again, if this is a new instance or one with no SQL permission customizations, the permission matrix located at the end of the article provides minimum permission requirements.

Right-click on the service account being replaced, select Properties.

Right-click on the gMSA replacing the previous service account, select Properties.

The properties of both logins should be displayed:

Next, go to “User Mappings”

One at a time, identify a selected database under the current service account mapping and duplicate the information in the gMSA that is replacing it. Below is just an example of my lab instance ‘msdb’ database before and after permissions have been duplicated for one of my new gMSA accounts. This is an example of the duplication process not of the specific permissions that may be required on your instance.

The ‘msdb’ Before:

The ‘msdb’ After:

Perform these steps for your remaining gMSAs across the applicable instances.

Reminder, for SQL AlwaysOn Availability Groups: you only need to configure the User Mappings when you create the first set of logins on the Primary Node. For each additional node you’ll only add the logins to the instances, you do not configure the User Mapping. The User Mappings will follow the databases during failover and align to the accounts in the failover node. The accounts/logins just need to exist on the other nodes for that to happen.

Service Logon Configurations

Make the following service-level changes on SQL:

You will continue to receive connection errors until the SQL service accounts are updated due to the SPN changes made earlier. We’ll need to make the changes on the primary SQL server, restart the services, and then update the secondary nodes. Services may failover and generate connection/logon errors as this process takes place. Continue through the process from node-to-node until the entire environment is completed. Once completed, fail the instance over from node-to-node to ensure the logons are updated properly. If not, troubleshoot accordingly, first by validating gMSA as it aligns to the applicable service, and then the necessary permissions.

Open Services.msc and locate the applicable SQL Engine and SQL Agent services, right-click, select Properties, then select the “Log On” tab to update the logon account information.

Select “Browse”

Select “Locations…” and change to “Entire Directory” and then enter and “Check Name” for the applicable gMSA account.

Blank out the password and select “OK”

Configure SSRS gMSA

Start by connecting to the SSRS Instance through SQL Reporting Services Configuration Manager.

Open Reporting Services Configuration Manager and open the SCOM Reporting Service instance

Backup Encryption Key

Select “Encryption Keys” and follow the “Backup” process.

Service Logon Configuration

Update the Reporting Services logon information with the Data Reader gMSA. Follow the same process as with the SQL services’ logon information.

Before:

After:

Once changed, restart the service for the changes to take effect.

Reporting Instance Configurations

Open Reporting Services Configuration Manager again and open the SCOM Reporting Service instance

Next, select “Service Account” and update the Account information, remember to end the account name with “$” so the instance knows it is a gMSA and therefore doesn’t require a password to be entered. Select apply once completed.

Select “Database” and “Change Credentials”

On the first page, select “Test Connection” to validate connectivity to the database.

Select “OK” to close the Test Connection box then select “Next”

Change the Authentication Type to “Service Credentials” and select “Next” > ”Next” >”Finish”

Verify Update:

Select “Execution Account”, keep the Data Reader service account here.

NOTE: SCOM Reporting Service does not support gMSA for the remote Execution Account, reports will not launch if this account is not properly configured. This service account requires “Log on Local” user rights on the Report Server as well. Do not deny the Log on Locally permission.

Next, select “Encryption Keys” and Restore the previously backed-up key.

Validate the changes by selecting “Scale-out Deployment”, the instance should display with a “Joined” status:

Configure SCOM gMSAs

Update the DAS/SDK logons

Once updated, restart the services for the updates to take effect:

Before:

After:

Update RunAs Accounts

Open the Operations Manager Console and navigate to Administration> Run As Configuration> Accounts

Update the credentials for the Data Warehouse Action Account (DW Writer)

Logon to your Primary SQL server instance for the SCOMDW and run the following query against the Data Warehouse database. Replace “OperationsManagerDW” with the name of your Data Warehouse Database.

SELECT [ManagementGroupDefaultName],[WriterLoginName] FROM [OperationsManagerDW].[dbo].[ManagementGroup]

If the query doesn’t return the updated gMSA account…like this one:

Then run the following query to update it. Replace “OperationsManagerDW”, “Domain\Username$”, and “SCOM Management Group Name” as applicable.

Be sure to include the trailing “$” to the gMSA.

UPDATE [OperationsManagerDW].[dbo].[ManagementGroup] SET [WriterLoginName] = 'DOMAIN\USERNAME' WHERE [ManagementGroupDefaultName] = 'SCOM MANAGEMENT GROUP NAME'

Re-run previous query to verify:

Back in the SCOM Console update the “Data Warehouse Report Deployment Account”:

And then the Default Action Account:

Update User Roles

While still in the SCOM Console, update the “Operations Manager Report Security Administrators” User Role to include the new Data Warehouse gMSAs (Data Reader and Data Writer accounts).

Post implementation validation and clean-up

• Verify all services are running as expected
  • SQL Services
  • SQL Reporting Service
  • SCOM Services
• Perform reboots and failovers as applicable
  • Verify your applicable high-availability is performing as-expected.
• Disable/Clean-up old services accounts
  • Old SQL service accounts should be cleaned-up following this process as SQL supports gMSA natively during install. Note: Verify this for your version of SQL before deleting.
  • You may want to keep the SCOM service accounts available and just disable them. SCOM 2019 RTM does not support gMSA so you will need them when adding or reinstalling features.

Note: If your management server turns grey in the Console, you may need to clear the agent cache (not Console cache).

This can be done easily with Clear-SCOMCache (available in the SCOMHelper PowerShell module).

If you encounter the following: Event ID 7011, you may have to restart your HealthService.

The Health Service has downloaded a new account in management group <YourSCOMGroup>, but the password is blank.  The Health Service does not support managing Windows credentials with blank passwords.  The account has not been updated.  If this account existed previously, it's old password will be used and logon may fail.  If this is a new account, the action account will be used instead.  The name of the account has been withheld for security purposes.  

Appendix:

Security Account Matrix – Operating System

Account:	OS Permissions – Management Server	OS Permissions – Operations DB SQL Server	OS Permissions – Data Warehouse DB SQL Server	OS Permissions – SSRS/SCOM Reporting Server
User account to install or update OpsMgr**	Group Membership: Administrators	Group Membership: Administrators	Group Membership: Administrators	Group Membership: Administrators
DAS Account (SDK/Config)	Group Membership: Administrators   User Rights Assignments: Generate security audits Log on as a service	none	none	none
Management Server Action account	Group Membership: Administrators   User Rights Assignments: Log on as a service	none	none	none
Reporting Data Reader account	User Rights Assignments: Log on as a batch job	none	none	User Rights Assignments: Log on as a service
Reporting Data Write account	none	none	none	none
Domain Computer Account hosting a Web Console Role (DOMAIN\SERVERNAME$)	none	none	none	none
Domain Global Group associated with Operations Manager Administrators user role in OpsMgr Administrations Security settings	Group Membership: Administrators	none*	none*	Local Admin*

Security Account Matrix – SQL

Account:	SQL Login – Server Role (Operations DB SQL Server)	SQL Login – Server Role (Data Warehouse SQL Server)	SQL Login – Server Role (SSRS/SCOM Reporting Server)	SQL DB User Mapping (MSDB, OperationsManager) Operations DB SQL Server	SQL DB User Mapping (OperationsManagerDW) Data Warehouse SQL Server	SQL DB User Mapping (Master, MSDB, ReportServer, ReportServerTempDB) SSRS/SCOM Reporting Server
User account to install or update OpsMgr**	sysadmin	sysadmin	sysadmin	none	none	none
DAS Account (SDK/Config)	public	public	none	MSDB: db_owner public SQLAgentOperatorRole SQLAgentReaderRole SQLAgentUserRole OperationsManager: ConfigService db_accessadmin db_datareader db_datawriter db_ddladmin db_securityadmin public sdk_users sql_dependency_subscriber	apm_datareader db_datareader OpsMgrReader public	none
Management Server Action account	public	none	none	MSDB: db_owner public SQLAgentOperatorRole SQLAgentReaderRole SQLAgentUserRole OperationsManager: db_datareader db_datawriter db_ddladmin dbmodule_users public	none	none
Reporting Data Reader account	none	public	public	none	apm_datareader db_datareader OpsMgrReader public	master: public RSExecRole msdb: public RSExecRole SQLAgentOperatorRole SQLAgentReaderRole SQLAgentUserRole ReportServer and ReportServerTempDB: db_owner public RSExecRole
Reporting Data Write account	public	public	none	apm_datareader apm_datawriter db_datareader dwsynch_users public	apm_datareader apm_datawriter db_owner OpsMgrWriter public	none
Domain Computer Account hosting a Web Console Role (DOMAIN\SERVERNAME$)	public	public		apm_datareader apm_datawriter public	apm_datareader apm_datawriter public
Domain Global Group associated with Operations Manager Administrators user role in OpsMgr Administrations Security settings	public*	public*	SA	db_datareader public	db_datareader OpsMgrReader public	N/A (SA)

References

• https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key
• https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview
• https://docs.microsoft.com/en-us/system-center/scom/support-group-managed-service-accounts?view=sc-om-2019
• https://support.microsoft.com/en-us/help/4533415/update-rollup-1-for-system-center-operations-manager-2019
• https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/cc731241(v=ws.11)
• https://docs.microsoft.com/en-us/system-center/scom/provide-security-rights?view=sc-om-2019
• https://docs.microsoft.com/en-us/system-center/scom/database-changes?view=sc-om-2019
• https://docs.microsoft.com/en-us/system-center/scom/service-level-changes?view=sc-om-2019
• https://kevinholman.com/2019/03/08/scom-2016-security-account-matrix/

Page History:

2022.08.17: Updated guidance and examples for the “New-ADServiceAccount -DNSHostName” parameter.