Share via


SCOM Best Practices

1. Introduction

This guide applies to System Center Operations Manager 2016, 1801, 1807 and 2019.

This article contain best practices for System Center Operations Manager (SCOM) to use when designing, deploying and managing SCOM. The best practices are intended to be a resource for IT professionals, this might include designers, architects, developers, and testers who manage SCOM.

Many of these best practices come from Microsoft's experience with SCOM and the experience from customers worldwide.
It is also thanks to the big amount of feedback from users/customers out there providing helpful feedback at the SCOM uservoice page, so make sure to keep providing helpful feedback!


2. Management / Gateway servers

2.1 Installation Directory

Make sure to never install SCOM on your operating system drive, always install it on a separate drive.

2.2 Registry Tweaks

Kevin Holman (MSFT) has written a detailed blog post about recommended registry tweaks for the SCOM management servers.
Recommended registry tweaks for SCOM 2016 and 2019 management servers

2.3 User Accounts

Use separate accounts for each distinct role in SCOM:

    • System Center Configuration Service
    • System Center Data Access Service account
    • Data Warehouse Write account
    • Data Reader account
    • SQL Server Service Account

2.4 Permissions

We can refer to Kevin Holman's Excel-sheet over here SCOM 2016 Security Account Matrix (applies to SCOM 2016, 1801 & 1807).
A list of account permissions for SCOM 2019 will be released in the near future.


3. Database / Data Warehouse servers

The most important component in a SCOM environment is the database, which means it is extremely important to have configured the SCOM database and database servers according to best practices. Microsoft has also a documentation regarding the SQL Server design considerations, it is highly recommended to go through the documentation.
Every environment is different, the best practices below are intended for most common environments, make sure to consult your DBA team to ensure your SQL deployment is configured for best practices according to your corporate standards as well.

3.1 SQL Server disks

  • 64KB allocation unit size (NTFS).
  • Create 3 volumes for the following SQL files:
    • Data
    • Log
    • TempDB

3.2 SQL Server Memory

Make sure to avoid operating system starvation, always set a minimum and maximum memory for the SQL Server used by SCOM.

Recommended settings:

  • Minimum SQL memory = 8GB
  • Maximum SQL memory =
    • Collocated: leave a minimum of 4 GB for the OS
    • Remote: 75% - 90% of server memory
    • Always calculate memory to whole GB

3.3 Database Size

Make sure to pre-size the SCOM database, we need 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 SCOM is to set the SCOM database to 50GB for the data file and 25GB for the transaction log file.
Use the SCOM sizing helper tool to get an idea how big the database will be.

3.4 SQL Server Configurations

By default, every Windows Server will have a "Balanced" power plan, there is a noticeable difference in this, we want the server to be able to perform as best as it can which means we will need to change the power plan to High Performance.

  • Power plan: High Performance

4. Override Management Pack Naming Convention

When creating overrides in SCOM it is important that we identify in which management pack the workflow (monitor, rule, or discovery) is defined. 
We can find this information on the General tab of the workflow properties.

Let's say we want to create an override for a monitor that is targeting the “Microsoft SQL Server 2016 (Monitoring)", then we simply create anoverride management pack as follows: 

  • Microsoft SQL Server 2016 (Monitoring) (OVERRIDES)

Make sure that we do not use the Default Management pack for anything, preferably leave it untouched, or rename it to "DO NOT USE - Default Management Pack".


5. SCOM Antivirus Exclusions

Some organizations use antivirus software on their servers, and there's absolutely nothing wrong with that, in the case of SCOM there are a few exclusions that need to be made, or the antivirus software may have a big impact on the SCOM environment.

5.1 Exclusions by process executable

If exclusions are configured based on process executable, exclude the following processes:

  • Monitoringhost.exe

5.2 Exclusions by directories

Component Directory 
SQL Server Database server Exclude the directory containing the .ldf and .mdf files for the SCOM database, Report server database, master and tempdb databases
Management Server <DriveLetter>:\Program Files\Microsoft System Center\Operations Manager\Server\Health Service State
Gateway Server <DriveLetter>:\Program Files\System Center Operations Manager\Gateway\Health Service State
Agent <DriveLetter>:\Program Files\Microsoft Monitoring Agent\Agent\Health Service State

5.3 Exclusion of file type by extension

Component Directory
SQL Server Database server Exclude the file type extension .ldf and .mdf for all databases
Management servers, Gateway servers, Agents Exclude the file type extensions for .edb.chk and .log files

For more information, see Configuring antivirus exclusions for agent and components

PowerShell script for Windows Defender antivirus exclusions: 
https://github.com/LeonLaude/SCOM/tree/master/SCOM%20exclusions%20for%20Windows%20Defender


See Also