Menu Close

SCOM 2022 – QuickStart Deployment Guide – using gMSA accounts


There is already a very good deployment guide posted on Microsoft Docs here:

If you are not using gMSA accounts, I have a previous quickstart for SCOM 2022 using domain accounts here:  SCOM 2022 – QuickStart Deployment Guide – Kevin Holman’s Blog

The following article will cover a basic install of System Center Operations Manager 2022.   The concept is to perform a limited deployment of SCOM, only utilizing as few servers as possible, but enough to demonstrate the roles and capabilities in SCOM.  For this reason, this document will cover a deployment on 3 servers. A dedicated SQL server, and two management servers will be deployed.  This will allow us to show the benefits of high availability for agent failover, and the highly available resource pool concepts.  This is to be used as a template only, for a customer to implement as their own pilot or POC, or customized deployment guide. It is intended to be general in nature and will require the customer to modify it to suit their specific data and processes.

This also happens to be a very typical scenario for small environments for a production deployment.  This is not a detailed architecture guide nor intended to displace the need for a complete and thorough design guide.

Server Names\Roles:

  • DB1          SQL Database Services, Reporting Services
  • MS1         Management Server Role, Web Console Role, Console
  • MS2         Management Server Role, Web Console Role, Console

Windows Server 2022 will be installed as the base OS for all platforms.  All servers will be a member of the AD domain.

SQL 2022 CU10 will be the base standard for all database and SQL reporting services.


High Level Deployment Process:

1.  Create the following accounts and groups, according to your naming convention:

  • DOMAIN\gMSA-SCOM             SCOM gMSA Service Account
  • DOMAIN\gMSA-SQL              SQL gMSA Service Account
  • DOMAIN\SCOM-RepExec          SCOM SSRS Reporting Execution Account
  • DOMAIN\SCOM-Admins          Global Security Group containing SCOM Administrator user accounts
  • DOMAIN\SCOM-Computers    Global Security Group containing SCOM Computer objects for gMSA
  • DOMAIN\SQL-Computers     Global Security Group containing SQL Computer objects for gMSA

2.  Add the gMSA-SCOM account to the “SCOM-Admins” global group.

3.  Add the domain user accounts for yourself and your SCOM Admin team to the “SCOM-Admins” group.

4.  Install Windows Server 2022 to all server role servers.

5.  Install Prerequisites and SQL 2022 CU10.

6.  Install the Management Server and Database Components

7.  Install the SCOM Reporting components.

8.  Deploy Agents

9.  Import Management packs

10.  Set up security (roles and run-as accounts)



1.  gMSA:  Prepare the KDS root key in AD to support gMSA in Active Directory.

This step is required to be handled by a Domain Admin in your domain. 

If this is the first gMSA being created in the domain, the Domain Administrator will need to create a KDS Root Key for the domainThis is a one-time configuration for the domain.  If this was already completed you should not re-create this.

Using PowerShell: 

Add-KdsRootKey -EffectiveImmediately

2.  gMSA:  Create Global Groups required for gMSA permissions on computers

This step is required to be handled by a Domain Admin in your domain.

Using the naming from the High Level Overview, create two Global Security groups in AD:

  • SCOM-Computers
  • SQL-Computers


Once these are created, add DB1, MS1 and MS2 to the SCOM-Computers group, and add DB1 to the SQL-Computers group.

The Computer that will host SCOM reporting needs to be able to retrieve the gMSA password, so this is why we add DB1 to the SCOM-Computers group.




3.  gMSA:  Create the gMSA accounts in AD.

This step is required to be handled by a Domain Admin in your domain. 

This will create the gMSA accounts and grant access for specific computers to be able to retrieve the gMSA account password when needed.

New-ADServiceAccount -Name gMSA-SCOM -DNSHostName -PrincipalsAllowedToRetrieveManagedPassword SCOM-Computers -KerberosEncryptionType AES128,AES256 New-ADServiceAccount -Name gMSA-SQL -DNSHostName -PrincipalsAllowedToRetrieveManagedPassword SQL-Computers -KerberosEncryptionType AES128,AES256

Next, grant the new gMSA accounts the right to update their own SPN:

dsacls (Get-ADServiceAccount -Identity gMSA-SCOM).DistinguishedName /G "SELF:RPWP;servicePrincipalName" dsacls (Get-ADServiceAccount -Identity gMSA-SQL).DistinguishedName /G "SELF:RPWP;servicePrincipalName"

4.  Create the Global Security group “SCOM-Admins”. 

Add the gMSA-SCOM service account and your domain user accounts for your SCOM administrators to this group.


5.  Create the SCOM-RepExec account.

This account will be used for SSRS Report Execution, since SCOM requires this account for reporting, and SSRS cannot leverage a gMSA account for this requirement.

6.  Install Windows Server 2022 to all Servers.

7.  Join all servers to a domain.

8.  OPTIONAL:  If your organization enforces TLS 1.2, you must ensure the prerequisites for TLS 1.2 have been met on all Management Servers.  TLS 1.2 from Microsoft Docs

9.  Install all available Windows Updates to ensure the servers are patched and secure.

10.  Add the “SCOM-Admins” domain global group to the Local Administrators group on each server INCLUDING the SQL server used for Reporting.

11. Install IIS on any management server that will also host a web console:

Open PowerShell (as an administrator) and run the following:

Add-WindowsFeature NET-WCF-HTTP-Activation45,Web-Static-Content,Web-Default-Doc,Web-Dir-Browsing,Web-Http-Errors,Web-Http-Logging,Web-Request-Monitor,Web-Filtering,Web-Stat-Compression,Web-Mgmt-Console,Web-Metabase,Web-Asp-Net,Web-Windows-Auth –Restart

If this step fails – you may need to provide the –Source parameter, to the installation media source, such as “-Source \\server\share\sources\sxs”

12.  Install the RSAT AD Tools

This step is required to be able to add gMSA accounts to a computer.  Install these on DB1, MS1, and MS2.

Add-WindowsFeature -Name 'RSAT-AD-Tools'

13.  Reboot EACH server, including the SQL server at this point. 

This is to ensure that the group membership for the gMSA account is active.

14.  Install the gMSA account to the computer

Log on to all three servers.  Open PowerShell and run the following command to install the gMSA account on DB1:

#Install the SQL gMSA service account to the computer Install-ADServiceAccount -Identity gMSA-SQL #Verify the gMSA account Test-ADServiceAccount -Identity gMSA-SQL

Next, install the SCOM gMSA account on the two management servers, MS1 and MS2 and the SQL server for Reporting, DB1

#Install the SQL gMSA service account to the computer Install-ADServiceAccount -Identity gMSA-SCOM #Verify the gMSA account Test-ADServiceAccount -Identity gMSA-SCOM

15. Install SQL 2022 CU10 to server DB1

  • Setup is fairly straightforward. This document will not go into details and best practices for SQL configuration. Consult your DBA team to ensure your SQL deployment is configured for best practices according to your corporate standards.
  • Run Setup, choose Installation > New SQL Server stand-alone installation…


  • Accept and configure your license, uncheck Azure Extension for SQL server.
  • When prompted for feature selection, install ALL of the following:
    • Database Engine Services
    • Full-Text and Semantic Extractions for Search


  • Note:  Reporting Services is not part of SQL DB Engine install.  This is a separate download, we will cover that later.
  • On the Instance configuration, choose a default instance, or a named instance.
  • On the Server configuration screen, set SQL Server Agent to Automatic.
  • Browse to find your gMSA-SQL account we created previously for the SQL Server Agent and Database Engine.  Leave the passwords blank.
  • Check the box to grant Volume Maintenance Task to the service account for the DB engine.  This will help performance when auto-grow is needed.


  • On the Collation tab – you should leave the default which is SQL_Latin1_General_CP1_CI_AS
  • On the Server Configuration tab – ADD your personal domain user account and/or a group you already have set up for SQL admins.
  • On the Data Directories tab – set your drive letters correctly for your SQL databases, logs, TempDB, and backup.
  • Choose Install, and setup will complete.
  • You will need to disable Windows Firewall on the SQL server, or make the necessary modifications to the firewall to allow all SQL traffic.  See:  Configure Firewall for SQL
  • When you complete the installation – you might consider also downloading and installing SQL Server Management Studio Tools from: DOWNLOAD SQL Management Studio

16.  Apply SQL 2022 CU10 (or whatever the latest Cumulative update available is).  SCOM 2022 supports SQL 2022 with the latest CU, and we recommend installing the latest CU.  At the time of this article being written, CU10 was the latest.

  • There are no special instructions for CU10, simply apply the update accepting defaults.
  • REBOOT the SQL server.

SCOM Step by step deployment guide:

1. Install the Management Server role on server named MS1.

  • Log on using your personal domain user account that is a member of the SCOM-Admins domain global group, and has “sysadmin” role level rights over the SQL instance.
  • Run Setup.exe (AS AN ADMINISTRATOR)
  • Click Install
    • If you see a message about not having administrator rights, make sure you run Setup.exe “as an administrator”
  • Select the following, and then click Next:
    • Management Server
    • Operations Console
    • Web Console
  • Accept or change the default install path and click Next.
  • You might see an error from the Prerequisites here. If so – read each error and try to resolve it.
  • On the Proceed with Setup screen – click Next.
  • On the specify an installation screen – choose to create the first management server in a new management group.  Give your management group a name. Don’t use any special or Unicode characters, just simple text.  KEEP YOUR MANAGEMENT GROUP NAME SHORT AND SIMPLE, and DO NOT put version info in there.  I typically use “SCOM1” as this is short, simple, and readily expandable in the future to additional management groups. Click Next.
  • Accept the license.  Next.
  • On the Configure the Operational Database screen, enter in the name of your SQL database server name and instance. In my case this is “”.  If I had used a named instance, this would look something like “” Leave the port at default unless you are using a special custom fixed port.  If necessary, change the database locations for the DB and log files. Leave the default size of 1000 MB for now. Click Next.
  • On the Configure the Data Warehouse Database screen, enter in the name of your SQL database server name and instance. In my case this is “”. If I had used a named instance, this would look something like “”  Leave the port at default unless you are using a special custom fixed port.  If necessary, change the database locations for the DB and log files. Leave the default size of 1000 MB for now. Click Next.
  • On the Web Console screen, choose the Default Web Site, and leave SSL unchecked. If you have already set up SSL for your default website with a certificate, you can choose SSL, or configure this later.  Click Next.
  • On the Web Console authentication screen, choose Mixed authentication and click Next.
  • On the Accounts  configuration screen, change the accounts to the gMSA-SCOM account for ALL services, formatted as DOMAIN\gMSA-SCOM$.  Click Next.


  • On the Diagnostics and Usage Data – click Next.
  • On the Microsoft Update screen – choose OFFNext.
  • Click Install.
  • Close when complete.  Don’t worry if you see the Management Server have a yellow warning.  That’s just a reminder to license SCOM as it always installs as EVAL.
  • Open the event log OperationsManager.  Check for errors or warnings. 
  • Open the console > Administration > Management Servers.  Make sure MS1 is present, shows to be monitored and healthy, and that the Version and Action account are discovered.

2.  (Optional)  Install the second Management Server on server named MS2.

  • Log on using your domain user account that is a member of the SCOM-Admins group, and has System Administrator (SA) role rights over the SQL instances.
  • Run Setup.exe
  • Click Install
  • Select the following, and then click Next:
    • Management Server
    • Operations Console
    • Web Console
  • Accept or change the default install path and click Next.
  • Resolve any issues with prerequisites, and click Next.
  • Choose “Add a management server to an existing management group” and click Next.
  • Accept the license terms and click Next.
  • Input the servername\instance hosting the existing Ops DB. Select the correct database from the drop down and click Next.
  • Accept the Default Web Site on the Web Console page and click Next.
  • Use Mixed Authentication and click Next.
  • On the accounts screen, choose Domain Account for ALL services, and enter in the the gMSA-SCOM account for ALL services, formatted as DOMAIN\gMSA-SCOM$.  Click Next.
  • On the Diagnostic Data screen – click Next.
  • On the Microsoft Update screen – choose OFFNext.
  • Click Install.
  • Close when complete.

3. (Optional) Install SCOM Reporting Role on the server named DB1.

Log on using your domain user account that is a member of the SCOM-Admins group, and has ”sysadmin” role level rights over the SQL instance.

Install SQL 2022 Reporting Services

  • Download SQL 2022 Reporting Services from DOWNLOAD
  • Run SQLServerReportingServices.exe
  • Select “Install Reporting Services
  • Input a product key for your license.  (You can get your key by running setup from your SQL database media – make sure you use STD or ENT edition whichever you choose to deploy)
  • Accept the License agreement
  • Install Reporting Services Only
  • Choose a Path, and select Install.
  • Choose “Configure report server”.  You must immediately configure the Report Server.
  • Connect to the local server
  • Select “Web Service URL” and click Apply
  • Select “Database” and click “Change Database
  • Action:  Create a new report server database and click Next
  • Database Server:  Make sure your Server name is correct with a named instance if you used one, and click Test Connection then click Next
  • Database: Accept “ReportServer” for default name and click Next
  • Credentials: Accept default Service Credentials and click Next
  • Summary:  Click Next, then Finish when completed.
  • Select “Web Portal URL” and click Apply
  • Select “Email Settings” and configure your SMTP server and a return address in order to be able to use emailed reports in SCOM, and click Apply.
  • Now that configuration is done, click Exit

Validate SSRS is working:

  • Open a Web Browser on the server.
  • Browse to http://localhost/reports/
  • You MUST see an empty SQL Reporting Services “Home” screen before continuing to install SCOM reporting role.

Install SCOM Reporting Role on the SSRS SQL server DB1.

  • Locate the SCOM media. Run Setup.exe (AS AND ADMINISTRATOR).
  • Click Install.
  • Check the box for Reporting Server and click Next
  • Accept or change the default install path and click Next.
  • Resolve any issues with prerequisites, and click Next.
  • Accept the license and click Next.
  • Type in the FQDN of a management server, and click Next.
  • Choose the correct local SQL reporting instance and click Next.
  • Enter in the gMSA-SCOM account for all services when prompted, formatted as DOMAIN\gMSA-SCOM$.  You MUST input the same account here that you used for the OM DW Reader account when you installed the first management server.  Click Next.
  • On the Diagnostic Data screen – click Next.
  • Turn Microsoft Updates OFF for SCOM, Next.
  • Click Install.
  • Close when complete.

Configure the SSRS Report Execution account

  • Because SSRS does not support a gMSA for the Report Execution account, we must use a domain account for this.
  • Open the Local Security Policy.  This account requires the Allow Log On Locally user right.  If you restrict this from all Users, add this account now to the SSRS server security policy.
  • Open Report Server Configuration Manager.
  • Select the Execution Account on the left side.
  • Change the account credential from the gMSA account to our domain service account DOMAIN\SCOM-RepExec and input the password, and click Apply.
  • Open SQL Management Studio and connect to the SQL DB Engine on DB1.
  • Add DOMAIN\SCOM-RepExec as a SQL Login, and on the User Mapping screen, map this account to the OperationsManagerDW, ReportServer, and ReportServerTempDB databases.
  • On ReportServer and ReportServerTempDB, add the RSExecRole database role membership.
  • On the OperationsManagerDW database, add the OpsMgrReader role.


  • NOTE:  Additional rights will be granted automatically to the user mapping once you click OK.

Configure Report extensions

  • Open SQL Management Studio on a server where you have this installed, or install it locally.
  • Connect to Reporting Services and type in DB1\SSRS for the server name, and connect.
  • Right Click DB1\SSRS and choose Properties.
  • Select Advanced
  • Scroll down to “AllowedResourceExtensionsForUpload
  • Add “*.*” to the end of the list of allowed extensions.  You will need to add a comma as well separating this entry from the previous.

You have a fully deployed SCOM Management group at this point.

Open/Reopen the SCOM consoles, ensure you have a Reporting tab now, and within an hour you should see all the reports populated in the console.

Look for any health issues or alerts, and review the SCOM event logs on both management servers for errors or warnings that are continuing after this point.

Known / Common issues:

1.  Errors trying to publish reports to SSRS.  When using SSRS 2022, you might see errors on a management server for event ID 31567 with description “Failed to deploy reporting component to the SQL Server Reporting Services server” and “extension is not allowed”.  This is because of a security restriction in SSRS.  The workaround is to open SQL Management Studio, connect to your Reporting Services instance, open the Properties of the instance, Advanced, and add *.* to the comma separated list for “AllowedResourceExtensionsForUpload

2.  AD integration is broken out of the box in SCOM 2022.  You might see events such as:

Log Name:      Operations Manager
Source:        Health Service Modules
Event ID:      11460
Description:  There was an error while updating Management Group container.
Exception: System.DirectoryServices.ActiveDirectory.ActiveDirectoryObjectNotFoundException
Message: The specified domain does not exist or cannot be contacted.

This is caused by the fact that NT Authority\System is now exposed in the Operations Manager Administrators user role.  It was always present in previous versions of SCOM, but hidden.  Now that it is exposed, it will break AD integration.


    Remove this, and AD integration works fine.  I do not recommend removing this UNLESS you need to use AD integration and have this issue.

    3.  SCOM 2022 RTM has a bug that left two agent update files in \Program Files\Microsoft System Center\Operations Manager\Server\AgentManagement\amd64 directory.

    You need to delete the following two files:

    • KB3117586-amd64-Agent.msp
    • KB9999999-amd64-Agent.msp

    4.  The sysmessages and Event Logs about Data Warehouse errors contain Chinese characters instead of English

    There is a bug in SCOM 2022 RTM that has not been fixed.  When you install SCOM, there are sysmessages added to the master database for the SQL instance.  For the Data Warehouse SQL server, these sysmessages contain Chinese characters by mistake.


    To correct this issue, please download and execute the SQL script for the Data Warehouse at:  SCOM 2016, 2019 and 2022: Event 18054 errors in the SQL application log – Kevin Holman’s Blog





    What’s next?

    Once you have SCOM up and running, these are some good next steps to consider for getting some use out of it and keep it running smoothly:

    1.  Configure SCOM Security

    • You must add your SCOM-Admins Global group to allow “Log on as a service” right on Management Servers, in order to push agents.
    • Add your SCOM-Admins Global Group to the SCOM Administrators User Role.  Ensure you, your team, and the SCOM DAS and Action accounts are members of this group FIRST.  Then, remove BUILTIN\Administrators from the Operations Manager Administrators – User Role, to secure your SCOM installation.

    2.  Apply the latest Update Rollup.

    • At the time of this blog posting UR2 is the latest Update Rollup for SCOM 2022.  You should always find and apply the most current CUMULATIVE update rollup.

    3.  Set SCOM License.

    4.  Optimize SQL Server for growth and performance

    • Make sure you SQL server data, log, and TempDB files are on a disk that is formatted with a 64 KB Allocation Unit size.  Best practices
    • Pre-size the OpsDB:  When we installed each database, we used the default of 1GB (1000MB). This is not a good setting for steady state as our databases will need to grow larger than that very soon.  We need to pre-grow these to allow for enough free space for maintenance operations, and to keep from having lots of auto-growth activities which impact performance during normal operations.  A good rule of thumb for most deployments of OpsMgr is to set the OpsDB to 50GB for the data file and 25GB for the transaction log file. This can be smaller for POC’s/LAB’s but generally you never want to have an OpsDB set less than 10GB/5GB.  Setting the transaction log to 50% of the DB size for the OpsDB is a good rule of thumb.
    • Pre-size the Data Warehouse:  You will need to plan for the space you expect to need using the sizing tools available and pre-size this from time to time so that lots of smaller auto-growths do not occur.  The sizing helper is available at:  DOWNLOADYou do not need to pre-size out terabytes of space, but there is nothing wrong with growing the DB manually a couple hundred gigs if you KNOW you will be using that much space soon.
    • Limit SQL MAX memory reserving memory for the OS.
    • Set Power Management plan in OS to “High Performance”
    • (Optional) Create a high performance TempDB: (This is already configured by default in SQL 2016 and later) Optimizing TempDB Performance
    • (Optional) Optimize MAXDOP: Optimizing MAXDOP
    • If you have a SQL Always On scenario – the secondary replicas need a SQL script run on them:

    5. Set up SQL maintenance jobs.

    6.  Configure Data Warehouse Retention.

    7.  Optimize your management servers registry

    8.  Enable Agent Proxy as a default setting

    9.  Configure Administration Settings per your requirements:

    • Database Grooming
    • Automatic Alert Resolution
    • Heartbeat configuration (modify only if required)
    • Manual Agent Installs (Reject, Review, or Accept)

    10.  Backup Unsealed Management packs

    • You need to set this up so that in case of a disaster, or an unplanned change, you will have a simple back-out or recovery plan that wont require a brute force restore of your databases.  I have seen this save many a customer’s bacon when they had this available, and cause them great pain when it wasn’t.

    11.  Deploy an agent to the SQL DB server.

    • This process has not changed from OpsMgr 2012, so you would use the typical mechanism to push or manually install. You can also refer to: SCOM Agent Deployment
    • You could also deploy any additional agents at this point.

    12.  Import management packs.

    13.  Configure Notifications:

    14.  Deploy Unix and Linux Agents

    15.  Configure Network Monitoring

    16.  Configure SQL MP RunAs Security:

    17.  Continue with optional activities from the Quick Reference guide:

    18.  (Optional) Configure your management group to support APM monitoring.

    19.  (Optional) Deploy Audit Collection Services

    20.  Learn MP authoring.

    1 Comment

    1. Denis

      Great article, Kevin!

      I have only one concern
      Here is described what “Group Managed Service Accounts (gMSAs) are not supported as a report server service account.”

      However, I can confirm – it’s working
      But, I have struggling with switch SCOM Reporting from NTLM to Kerberos in this configuration…

    Leave a Reply

    Your email address will not be published.