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:
Keep in mind that many third-party add-ons make use of the management group name for licensing.
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.
|ID||#Manufacturer#.#Product#.#Version#.Overrides||ID of the file|
|Name||_#Manufacturer#.#Product#.#Version# - Overrides||Display name for the override|
|Example||_Microsoft SQL Server on Windows - Overrides||Override MP for SQL Server Version Agnostic|
|ID||Service.#GUID#||GUID generated in SCOM|
|Name||Service #NameOfDA#||Display name for the DA|
|Example||Service ServiceNow | Global | Prod||Global ServiceNow in Production|
Download the Free CreateDistributedApplication PowerShell script below.
|ID||#Manufacturer#.#Product#.#Version#||ID of the file|
|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.
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.
_Microsoft SQL Server on Windows - Database Engine Monitoring (Disabled)
_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)
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.
|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|
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