Monitoring Servers based on Server Name in SCOM

Most organizations have a standard naming scheme that they use based on server type, location, or department. For instance, the letters “DC” suggests a domain controller, “Mail” or “EX” suggests exchange, “SQL” suggests SQL servers, and “DR” could suggest disaster recovery (for location, not role). Based on these name standards we may want to manage the servers differently: do we really care about excessive network utilization on backup devices, or minor alerts on development systems?

Creating a group based on name is easy – simply create a group with dynamic criteria based on the name – but then applying overrides and monitors to it contains many issues. If you apply a monitor to the group, then when one of the systems in the group errors, the group will report the error without any detail on which machine caused it. To resolve this, I decided to create classes of servers based on their names.

Step 1: Create a Local Application class

In the SCOM Authoring Console, select the Service Model tab and the Classes node

Select New | Windows Local Application

Enter appropriate ID and Name, there are no Key Properties so that can be left blank

Step 2: Create a Discovery for the class

Select the Health Model tab and choose the Discoveries node

Select New | Registry (Filtered)

Enter in the ID and Name, for Target select Windows Computer or some similarly generic group

Leave Schedule and Computer as they are for now

On the Registry Probe Configuration step, click Add and select the following:

• Object Type: Value
• Key: ComputerName
• Path: SYSTEMCurrentControlSetControlComputerNameActiveComputerNameComputerName
• Attribute Type: String

On the Build Event Expression step, click Insert and select the following:

• Parameter Name: Values/ComputerName
• Operator: Matches regular expression
• Value: (?i)dc.*

On the Discovery Mapper step, select the Class ID created in step 1, and select the Principal Name attribute.

Step 3: Export to SCOM and test

A few notes:

• The path on the Registry Probe Configuration includes the path and attribute. My first round assumed that the Key property was appended to the Path property and it took me a while to identify my failure
• The Value in the expression uses (?i) which is a regex expression stating to ignore case. This may or may not be needed in all environments
• The dc.* in the event expression means that all computers whose names start with the letters “DC” will be included. This should change based on your naming schemes
• Class types other than Local Application may work for this as well, this is just the most familiar to me for now
• A WMI discovery can be done instead of a registry discovery if your systems are all W2k3 or greater. The reason for this is because prior OS’s cannot handle the LIKE clause in the WMI query you need to run.
• The Schedule defaults to 1/hour. This is helpful for the initial deployment, but you may want to decrease it to several hours or a day to limit overall performance