Introduction
Operations Manager is very flexible about creating dynamic groups based on membership formulas. Such groups can easily be created in the console’s authoring pane and may contain just about any object, SCOM has discovered. For advanced grouping algorithms the management pack XML will have to be written/edited by hand since the GUI wizard does not support contains/contained type rules. If you are not so comfortable with writing management pack XML code, the semi-GUI based method could be used:
1. Prepare the groups using the autoring wizard
2. Export the resulting management pack
3. Edit and add the formulas as required using your favourite XML editor
4. Reimport the management pack
Such groups can serve for overrides, console views, console scopes, alert subscriptions and much more. All in all very powerful and flexible. This logic can be applied not only to the groups visible in the operator GUI. The group populator comes in particularly handy when designing dynamic distributed applications. Populating distributed application elements works just the same.
Grouping options
The membership of a dynamic group is defined by applying at least one of the following methods. All of them can be freely combined and nested:
- Object’s class membership (MonitoringClass)
- Properties of an object (Property)
- Properties of an object’s host (HostProperty)
- Children of an object (Contains / NotContains)
- Parents of an object (Contained / NotContained)
- Each dynamic group may be defined by more than a single membership rule.
Contains/Contained evaluation performance
However; adding many dynamic groups to your SCOM could have a negative impact on the performance of the Root Management server. All groups are (internally) hosted by the RMS and it does all the dynamic group membership calculation. I have seen dramatic performance degradation even on mid-sized SCOM installations. Eventually this led to the GroupPopulator module (Microsoft.SystemCenter.GroupPopulator) being way behind the discovery process.
After some investigation it turned out that the use of the Contains/Contained expressions was causing the problem. Group calculation has to walk down (contains) or up (contained) the hosting and containment relationships for every object of the grouping class in order to decide if it is to become a member of the dynamic group or not. In a deep class hierarchy this query can become quite heavy.
If using that type of dynamic inclusion rules, there are two simple points to watch out for.
-
Choose grouping class (MonitoringClass) as specific as possible
Select the grouping class (MonitoringClass) so that the group calculator does not have to evaluate too many objects. Avoid using System.Entitywhenever feasible. If your group must contain objects of different classes, rather use several membership rules (MembershipRule).
-
Set maximal query depth (maxDepth) attribute
All four (not)contained/(not)contains rules do support limiting the search depth of the query. The optional attribute maxDepth is used for that. Whenever possible think about how deep the module must look for and set the maxDepth attribute to that value. Quite often a “1″ might be sufficient – for example to query for direct members of an object. Above examples all have the attribute set.
Real world examples
A very useful and neat example to show what can be done by using dynamic groups, was published by Tim McFadden. In his post he explains how to create a group that contains both server and health watcher objects. Great for using in subscriptions in order to receive alerts about failed health services as well. Tim uses two membership rules (one for the windows computers, the other one for the health service watchers) and does show how contained/contains can build up onto each other. The result could look like this: HealthServiceContainment.Group.DiscoveryRule.xml
Brian Wren writes about how to programmatically create groups that can make use of dynamic grouping formulas.
Brian also has a detailed post on how to create dynamic component groups for distributed apllications.
To create groups based on the AD security group membership of an agent system, follow Steve Rachui’s how-to.
Remark on MPVerify
Unfortunately the current version of MPVerify.exe (SP1) is unable to check if the inner logic of group calculation discovery rules is valid. The same is true for MPSeal.exe. It is crucial that even after successfully checking or sealing a management pack, you go back to your RMS’ event log to look for any warning or error messages thrown by the GroupPopulator.
- Event ID 4509 (The constructor for the managed module type “Microsoft.EnterpriseManagement.Mom.DatabaseQueryModules.GroupCalculationModule” threw an exception)
Happy grouping!
