Defining your naming conventions: Key to a structured SCOM environment

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:

#PREFIX#-SCOM-#GENERATION#-#ENVIRONMENT#

Example 1:
CONTOSO-SCOM-G1-PROD

Example 2:
ACME-SCOM-G2-DEV

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.

Overrides

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. 

Distributed Applications

Download the Free CreateDistributedApplication PowerShell script below. 

Custom Applications

Download the Free CreateMonitoringMP PowerShell script below. 

Groups

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.

Example:

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. 

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