In previous posts, I demonstrated how to create a group of Windows Computer objects and how to create a group of any type of instance. These are the building blocks for creating even more sophisticated groups using expression filters, as I’ll demonstrate in this post.
The reason I wanted to post this demo is because this is a very common request from customers and in the forums. It’s such a common request because we need these types of groups for multiple purposes; like overrides, views and notifications. We have so many problems creating these types of groups because the groups UI in the Operations Console simply isn’t designed to handle more complex formulas for the group calculation module to consume.
The UI for creating groups in the UI can handle the most common types of groups, since we can follow the hosting path all the way up to and through Windows Computer, and reference properties of all hosting types and classes along the way. This is great if we want to create a group of IIS Web Sites with URL’s matching abc*.com that are hosted on Windows Computers with a Principal Name containing xyz.
But what do we do if we want to go the other way around? In other words, if we want to create a group of Windows Computers that host an IIS Web Site with URL’s matching abc*.com and hosted on Windows Computer with a Principal Name containing xyz, we’ll need to step up our authoring skills. It simply isn’t possible to do this in the Operations Console, because IIS Web Site does not host Windows Computer. We realize this limitation in the UI, since we can only access properties UP the hosting path, not DOWN.
There is good news, though. Just because the groups UI has limitations, doesn’t mean we cannot create this elegantly in the Authoring Console or directly in XML.
I’ll use a similar scenario as mentioned above. I want a group of Windows Computers that host IIS Web Sites with a Description starting with Virtual*.
We start by opening the Authoring Console and creating a new Management Pack (or open the MP that you want to store this new group in). I have already done this, and am now looking at the MP properties in the following screenshot.
First thing you’ll want to do is add a reference to the management pack that contains the class that hosts the objects you’ll be referencing in your group calculation formula. In this example, we will need to reference the IIS Web Site class, which is defined in the Windows Server Internet Information Services Library (Microsoft.Windows.InternetInformationServices.CommonLibrary).
After you have added the reference, copy the Alias (highlighted in below screenshot) of the management pack you’ve referenced and paste into notepad. You’ll need it later.
Now we’ll create a new Computer Group class.
Copy the ID of the new class (highlighted in below screenshot) and paste into notepad. You’ll need this ID later.
Now create a new custom discovery.
Notice that I name the new discovery identical to the class name, and append “Discovery” to the end. This is just good practice, which helps to keep the namespace organized and makes it much easier to reference discoveries to classes and vise-versa when looking at management packs. This might not seem beneficial in such a small MP, but when your MP starts growing with 10-20 classes and discoveries, you’ll be happy you practiced this.
Target the new singleton class, which is your group. Singleton class, by the way, is a special kind of class, which is managed by the RMS and usually represents a group. Incidentally, this is why targeting groups directly in monitoring workflows doesn’t work as expected, because the singleton class “resides” on the RMS.
Add object discovery details. This will be the Windows Computer class.
On the Configuration tab, click Browse for Type, then find and add the Group Populator module and give it a name (any name is fine).
Close the error dialog.
Here’s the tricky part…
When your editor opens, highlight everything except the top line.
Now replace the highlighted XML with the following…
If you’ve been following this demonstration exactly, with the same ID’s, system names and Aliases, then you don’t need to change anything here. If you have been using different names, ID’s and Aliases, here is a description of all the red text above that you’ll need to replace with your stuff. I’ll describe each item in the order it is displayed above.
This is the Computer Group class ID that we copied earlier after creating our class. You should have copied this ID into notepad earlier.
This is the Alias of the Microsoft.Windows.Library management pack. We reference this MP to populate our group of Windows Computer objects. You can find this Alias by looking at the References tab under File > Management Pack Properties.
This is the Alias of the Microsoft.SystemCenter.Library management pack. We reference this MP in order to use the Group Populator module. You can find this Alias by looking at the References tab under File > Management Pack Properties.
This is the Alias of the management pack we’re referencing in our group calculation formula. We reference this MP in order to get to the Description property on the IIS Web Site class for our string matching in the Group Calculation formula. You can find this Alias by looking at the References tab under File > Management Pack Properties. You should have also copied this to notepad earlier.
This is the property we’re using in the expression filter of our group calculation formula. This property is discovered on the IIS Web Site instance.
Tip: Use the GetClassPath script to easily view all properties of the entire hosting and based class path. This has been especially helpful and a real time saver for me while authoring management packs.
This is the pattern we’re matching against the Description property on the IIS Web Site discovered object.
Okay. Now that we understand all these parameters and hopefully have them input correctly, we can save our work and import our new management pack. Once the RMS receives the new MP and Group Calc processes the request, we should see our new group in the Operations Console under the Authoring space.
You can reproduce this method of grouping Windows Computer objects for virtually any class and discovered property, as long as a Windows Computer instance hosts the object we’re using in our group calculation formula somewhere up the class path. The easiest way to find out whether we can create a group using this method is to use the GetClassPath script mentioned above. Simply input the class name that hosts the object containing the property you want to use in filtering for your group calculation formula (more details about usage on the source page).
As long as you see that the class in which you want to use for filtering is hosted/based somewhere in the class path by Microsoft.Windows.Computer (as in the yellow highlighted text in the screenshot above), you should be good to go. Just find a property that you want to use for matching strings, and follow this guidance to get results like the group below.
I hope this helps in making your SCOM implementation a successful one! As always, feel free to leave comments and ask questions.