Smart IT for SMB: SCOM: Building Instance Groups from Groups of a Different Class

When I first started working with Operations Manager, one of the items that I struggled with was how to make a group from another group targeting a different class such as all Non-System Drives hosted on Windows 2008 Servers. This can just as easily be used to help segment your management environment among multiple groups or departments managing different aspects of your environment.
You may have multiple web development groups in your organization and each may use similar systems, IIS and Tomcat for example, but they may each desire different overrides for the same components. Segmenting their views of the environment is relatively simple through simple computer groups, but overrides need to be targeted at the actual object class. This is especially true if you have a group that wants overrides targeted at some logical disks, but not all.

There are a number of articles out there that talk through how to use the SCOM containment constructs to your advantage (See References at end of the article), but none that I found specifically talked about how to use groups, either instance or computer, as a part of the formula. While on the surface it appears the same principles should work, my first few attempts were anything but successful.

The first thing that you discover is like I have already hinted at, not all groups are created equal. There are many different kinds of groups and each one has their own containment relationship. This is critically important as the group population rules need to refer to the proper relationship entity or the workflow errors out. Luckily for us, most of the management packs I have seen use either the Computer Groups or the Instance Group constructs provided by the base System Center Libraries. Computer Groups are defined in the Microsoft.SystemCenter.Library management pack and are groups that may only contain computers. Computer Groups have a Relationship named Microsoft.SystemCenter.ComputerGroupContainsComputer defined. Instance Groups are defined in the Microsoft.SystemCenter.InstanceGroup.Library management pack and are groups that may contain any combination of any class. Instance Groups have a relationship named Microsoft.SystemCenter.InstanceGroupContainsEntities defined.

Now I am sure that you are asking yourself, "How did he find that out?" I assure you that it was not through any sort of divine intervention, centuries old enlightenment techniques, or voodoo. (no animals were harmed in the writing of this article)

It is a simple thing to lookup for any group (or any other type of object for that matter). Simply have the management pack defining the object open in the Authoring Console (Even if it is a sealed management pack, you can still use the Author Console to view its configuration, you just can't change it). From the Service Model tab, find your Group in the Classes list. (Yes, groups are treated as classes just like every other logical representation construct in SCOM) To find out what kind of group construct that your group is defined from, simply look at the "InheritedFrom" column of the main view or look at the Base Class selection on the General Tab of the properties window. To discover the relationship defined for your group, simply navigate to the Relationships Tab of the properties window for your group and all will be revealed.

Now that we know the containment details for our group, we can use the same steps to uncover the containment relationships for essentially any other object in the system and use those relationships to build our Group Populator configuration XML.

Let say we want to create a group of all logical drives that are not named "C:" on machines contained in a group Named "Production Webservers" because our web team only wants to see alerts on Non-System Drives. (AKA they want you addressing all the system drive problems) In a management pack that you control, you simply create a new Instance Group of whatever name you want in the Classes section of the Service Model Tab of the Authoring Console. Then navigate to the discoveries section of the Health Model tab of the authoring console and create a new Custom Discovery object named whatever you like. (Good naming consistency does help when you have to revisit these later) For the target of the discovery, select the Group Class you created earlier. On the Classes Tab, make sure that the relationship for your group class is defined in the "Discovered relationships and their attributes" window. For an Instance class, this should be Microsoft.SystemCenter.InstanceGroupContainsEntities.

Now for the dreaded Configuration Tab. Be Strong, you can do this.

For a type, select GroupPopulator. This will bring up a configuration window for the GroupPopulator object type. Enter $MPElement$ for the RuleID. Enter $Target/Id$ for the GroupInstanceID. (See 2 fields out of the way and we haven't had to sweat yet)

Now for the Membership Rules. For this, I am going to show the full XML and then explain where/how it is derived from.
<MembershipRule>
<MonitoringClass>$MPElement[Name="MicrosoftWindowsLibrary6172210!Microsoft.Windows.LogicalDisk"]$</MonitoringClass> <RelationshipClass>$MPElement[Name="MicrosoftSystemCenterInstanceGroupLibrary6172210!Microsoft.SystemCenter.InstanceGroupContainsEntities"]$</RelationshipClass>
<Expression>
<And>
<Expression>
<Contained>
<MonitoringClass>$MPElement[Name="MicrosoftWindowsLibrary6172210!Microsoft.Windows.Computer"]$</MonitoringClass>
<Expression>
<Contained>
<MonitoringClass>$MPElement[Name="MicrosoftSystemCenterInstanceGroupLibrary6172210!Microsoft.SystemCenter.InstanceGroup"]$</MonitoringClass>
<Expression>
<SimpleExpression>
<ValueExpression>
<Property>$MPElement[Name="SystemLibrary6172210!System.Entity"]/DisplayName$</Property>
</ValueExpression>
<Operator>Equal</Operator>
<ValueExpression>
<Value>Production Webservers</Value>
</ValueExpression>
</SimpleExpression>
</Expression>
</Contained>
</Expression>
</Contained>
</Expression>
<Expression>
<RegExExpression>
<ValueExpression>
<Property>$MPElement[Name="SystemLibrary6172210!System.Entity"]/DisplayName$</Property>
</ValueExpression>
<Operator>DoesNotMatchWildcard</Operator>
<Pattern>^C:$</Pattern>
</RegExExpression>
</Expression>
<Expression>
<RegExExpression>
<ValueExpression>
<Property>$MPElement[Name="SystemLibrary6172210!System.Entity"]/DisplayName$</Property>
</ValueExpression>
<Operator>MatchesWildcard</Operator>
<Pattern>^_:$</Pattern>
</RegExExpression>
</Expression>
</And>
</Expression>
</MembershipRule>

Relax. Breathe slowly and deeply. Don't Panic, we are going to tackle this together. Let's take it from the top.

The membershiprules section of the XML configuration, needs to contain one or more membership rules, so we start off with (and end with) the tags (<MembershipRule></MembershipRule> denoting a MembershipRule. The next line containing the <MonitoringClass> tag denotes what type of objects we are placing in our group. In our case, we want Logical Disk objects. Logical Disk objects are Management Pack elements, so we need to denote that by the $MPElement[Name=""]$ portion of the line. We can see that Logical Disks are named Microsoft.Windows.LogicalDisk by looking at the class definitions of the Windows OS Management packs. So where did the "MicrosoftWindowsLibrary6172210!" portion of the line come from? It turns out that you can have different definitions of the same class from different management packs, so you need to tell the Group Populator which definition you are intending to use, which is done by "aliases".

The easiest way I have found to uncover the alias being used by your management pack is to simply open the raw management pack XML file with a text editor and retrieving the Alias from the references section of the file near the top. In my case, the Windows Library Reference looks like this:
<Reference Alias="MicrosoftWindowsLibrary6172210">
<ID>Microsoft.Windows.Library</ID>
<Version>6.1.7221.0</Version>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Reference>

I now know that the alias for the Windows Library being used in my management pack is "MicrosoftWindowsLibrary6172210". This will vary from management pack to management pack on the same system, so get in the habit of looking it up. The only character in the line left undefined is the "!" character between the alias and the class definition and it is simply a delimiter to let the group populator know where the alias definition ends and the class name begins.

The line with the <RelationshipClass> tags simply defines which relationship definition we are using to define our group and is built using the info we learned earlier about our Group and is constructed in the same way as the <MonitoringClass> line.

We now need to restrict which logical disks end up in our group, which is done with <expression> tags using a sort of "backwards Reverse Polish Notation" of <operator> <operand> <operand> . Logical operators such as <AND>, <OR> and comparisons like <EQUAL>, <MatchesWildcard>, etc are fairly simple to understand and are explained in great detail elsewhere. The more interesting operators in this construct are the <Contained> and <Contains> operators. The contained and contains operators denote containment relationships either moving up or down the containment tree. Each rule is constructed of operands built in the same manner as we did the original <MonitoringClass> line.

Roughly translated, the membership rules defined in the XML above equate to:
All Logical Disks contained on Computers contained in a Group named "Production Webservers" with logical disk names that are 2 character names ending in a colon (_:$) and not named "C:"

The 2 character names portion of the rule needed to be included in my environment as it includes Windows Cluster servers and the logical disks used by the cluster appear as "GUID" strings on the passive node of the cluster.

Hopefully this example can help you to implement similar constructs in your environment and to better understand the Group Populator rules in general.