Defining your naming conventions: The key to a structured SCOM environment

by Jonas Lenntun, on 03-Feb-2022 14:00:00


When it comes to sophisticated software like System Center Operations Manager (SCOM), where a structure is vital to maintain your environment, your naming conventions are the key to long-term success. 

Many different people are involved in the process of monitoring. To maintain documentation and procedures, you must define how you should name parts used in SCOM. Everything from the management group name to groups, management packs, override management packs, views, and folders.

This is the best-practice naming standard that OpsLogix recommends after numerous successful Operations Manager implementations. That involves not only how but also why we define them.

Management Group Name

Using a generation flag in your SCOM Management Group enables more flexibility depending on what upgrade path you might take in the future. Upgrading from an older SCOM version in place to the latest release might still be the same generation because you are just upgrading SCOM. 

A side-by-side migration when changing many components such as Operating System, SQL and SCOM version while rethinking and redoing the whole monitoring might be considered a generation shift.

Read more: Choose your Upgrade Path

We recommend the management group to be named using the following pattern:


Example 1:

Example 2:

Keep in mind that many third-party add-ons make use of the management group name for licensing.

Management Packs

When working with Management Packs, we usually categorize them according to their intended use. 

When importing sealed Microsoft or other third-party vendor management packs, you can't change the names, but we recommend a stricter naming policy for unsealed Management Packs. Management Packs that are used for custom overrides, custom monitoring, views, among others.


To separate the management packs used for overrides we use an underscore in the display name. The purpose is not to mix overrides with other purpose-built management packs.  

Over time, it's been clear that admins we work with like to go to the top to see all management packs for overrides, as they'll be at the top of the dropdown choices.

Download the Free CreateOverrideMP PowerShell script below. 


Type Value Comment
ID #Manufacturer#.#Product#.#Version#.Overrides  ID of the file
File #Manufacturer#.#Product#.#Version#.Overrides.xml File name
Name _#Manufacturer#.#Product#.#Version# - Overrides Display name for the override
Example _Microsoft SQL Server on Windows - Overrides Override MP for SQL Server Version Agnostic


Distributed Applications

Type Value Comment
ID Service.#GUID# GUID generated in SCOM
File Service.<GUID>.xml File name
Name Service #NameOfDA# Display name for the DA
Example Service ServiceNow | Global | Prod  Global ServiceNow in Production


Download the Free CreateDistributedApplication PowerShell script below. 


Custom Applications

Type Value Comment
ID #Manufacturer#.#Product#.#Version# ID of the file
File #Manufacturer#.#Product#.#Version#.xml File name
Name #Manufacturer# #Product# #Version# Custom display name
Example ServiceNow MID Server 3 Monitoring MP for v3 of ServiceNow MID ServerTypeValueComment


Download the Free CreateMonitoringMP PowerShell script below. 



Override Groups

We commonly use groups to activate or deactivate workflows for discoveries, health, alerting and performance collection. 

Avoiding object-based overrides provides a more robust and dynamic way of work with increased control.

To separate the groups used for overrides we use an underscore in the display name of the group and the purpose.

Example 1: 
_Microsoft SQL Server on Windows - Database Engine Monitoring (Disabled)

Example 2:
_Microsoft SQL Server on Windows - Database Engine Discovery (Disabled)

Every group should also include a clear description of its purpose and the appropriate type of object that will be affected.


Add SQL Engines that should not be monitored into this group (class: MSSQL on Windows: DB Engine)

Distributed Applications

We commonly use groups when working with Distributed Applications to add the correct objects to the Distributed Application. 

This allows for a more dynamic approach to membership management than working with explicit memberships.

Our Distributed Applications are created by a script and include three different types of groups. Functional, Components and Infrastructure.

Download the Free CreateDistributedApplication PowerShell Script below. 


Type Value Comment
Name #Service# | Functional Group Display name for the functional group
Name #Service# | Components Group Display name for the components group
Name #Service# | Infrastructure Group Display name for the infrastructure group
Example ServiceNow | Global | Prod | Functional Group Functional group for ServiceNow Global Prod


Other recommendations

We usually recommend defining for other places as well. These are some common scenarios to make use of.

  • Run As Accounts
  • User Roles
  • TCP Monitoring
  • Web Availability Monitoring
  • Web Transaction Monitoring
Topics:Best PracticesHow-toMonitoringSCOM