As soon you are implementing SCOM, you are faced with grouping your servers. Either you use the groups for views, overrides or just in subscriptions. Which ever might be your reason to group your windows computers, you will need to group your windows computer objects dynamically. One option which I recommend is grouping the objects based on registry keys. In SCOM you are able to run the attribute wizard and create an extended windows computer class . This extended class respectively the attribute will be used to build dynamic groups. Kevin Holman has written a years ago an excellent blog post which is still valid you can find it here.
As generating these attributes using SCOM wizard etc. is great for small environments, but as soon you have larger installations, you need a process or concept how you are going to deal with it in a daily operation. One problem you are facing is WHERE are you going to store all these attributes, classes and groups. One option is to store all these components in a unsealed management pack or the other option is in a sealed management pack.
This is CRITICAL. Spend some time making sure you are creating these attributes in the correct location. If you leave this MP unsealed XML…. then any groups you create that use these attributes, will have to be placed in this same MP. Then – if you use these groups for Overrides – those overrides will be force to go in this same MP. There is a “cardinal rule” in SCOM… objects in one unsealed MP cannot reference another unsealed MP. So – we cannot have a group in one unsealed MP, and then use that group for an override in another unsealed override MP.
So – we have two choices.
1. Keep an unsealed MP… and live with the fact that attribute, group, and override will all have to be placed here.
2. Create the attribute and the dynamic group in the MP, then seal it. Then – you can use this group in ANY of your override MP’s… for Exchange, SQL, etc…
I strongly recommend option #2 for this exercise… but you can make this decision for yourself. (Taken from Kevin Holman)
If you decide to go for option 2 you will have another problem. HOW do you create the attributes, groups and seal the management pack. One option, I think makes sense, is to use Visual Studio Authoring Extensions. Because you are able to structure your project easily using VSAE / management pack fragments, have built-in error checking and also you are able to seal the MP – all in one step.
Because of that problem and I like to play with VSAE, I created a solution which you could easily adapt, modify and extend as your project requires. Let’s have a look at the solution…
How it works
I defined two registry keys, one is for the SLA type and one is for the patch block type. E.g. SLA type defines the service level agreement type like SLA1 (there could be any value SLA2, SLA3 whatever). The patch block key defines, when the server will be patched in my case I set the value to PB1 (this could be also any value like PB2, PB3 etc.). I would like to dynamically group the servers which have SLA1 and PB1 in their registry defined. Therefore I defined the registry keys like…
- SLA1 – HKLM\SOFTWARE\scomfaq\SCOM\Patch_Block
- PB1 – HKLM\SOFTWARE\scomfaq\SCOM\SLA
The management pack contains two discoveries….
…which will discover the registry values and extend the Windows Computer class “Windows Computer Class (scomfaq Extended)” and add these registry keys values as attributes…
Using these two attributes, two groups are created…
…which have Dynamic Inclusion Rules defined according to the attributes, to dynamically group the Windows Computer objects…
This is basically how it works, now let’s have a look inside the Visual Studio Authoring Extensions solution.
There are 4 fragments in this VSAE project…
- scomfaq.attribute.discovery (template)
Registry key discoveries for the attributes
- scomfaq.dynamicgroup.discovery (template)
Contains the group discoveries for the attributes
Dynamic group instance definitions
Extended Windows Computer class and class attributes definitions
Let’s dive a bit deeper into the code. In the fragment scomfaq.windowscomputer.class is the extended class defined and it’s attributes…
On the next fragment scomfaq.dynamicgroup.instance I just defined two group instances which will contain the computers according to their SLA or Patch Block attributes set…
Since we have basically the classes / instances defined we are going to need the registry discoveries for the attributes and after that, the discoveries for the group population.
Let’s start with the registry discovery. As an example, I just will pick the discovery for the Patch Block attribute. The discovery for the SLA attribute will be basically the same. In Visual Studio just select the scomfaq.attribute.discovery and select the Data Source Configuration…
In this configuration I have the registry path for the attribute defined, the frequency and mapping of the attribute value to the extended class attribute (Note: The frequency interval is set very low to 120 seconds. This is just for testing! In production set it higher like 3600 seconds or more)…
To configure the dynamic group discovery / Dynamic Inclusion Rules is very similar to the step above. In Visual Studio just select the scomfaq.dynamicgroup.discovery and select the Data Source Configuration…
If you dig into the configuration you will see the group expression which defines the criteria for the group. In this case, it is PB1 which stands for Patch Block 1…
I don’t’ want to give you an authoring lesson, but I would like to show you, what the beauty is about VSAE. Because we probably need to add more and more attributes we are now easily able to copy/ paste parts from the fragments and edit as we need it. First you just need to add another line for an attribute in scomfaq.windowscomputer.class and another line for an additional group in scomfaq.dynamicgroup.instance according to the existing attribute respectively group definition. For the discoveries you can easily copy and paste a discovery either for the registry key (attribute) discovery or group discovery.
If you have copied your discoveries for the registry keys and groups, you have to modify the settings for each discovery in the property windows…
After you have added and modified all the necessary classes and discoveries you are ready to build your management pack by pressing F5.
In Visual Studio go to Project / [project name] Properties… there you will be able to provide the *.snk file to seal your management pack…
If you create your MP in VSAE like the sample above, you can easily prepare a kind of “template”, which a non-SCOM authoring guy can use to copy / paste code. Because of the repetitive steps almost any administrator can extend the MP after a short learning time without any deeper SCOM knowledge.
Emre Guclu has also written a blog post about extending a Windows Computer class using VSAE authoring but without adding any dynamic groups.
An excellent source for a VSAE authoring is Technet Wiki .
I hope you get my point and you will be able to adapt the idea / solution. The VSAE sample solution can be downloaded here .
3 Replies to “SCOM VSAE – Custom Dynamic Computer Groups Based On Server Registry Keys”
A fundamental problem with ‘extending’ Windows Computer is overrides will not be applied to any monitoring work flow that targets Windows Computer or any other type that uses it as a base or host class. It’s because these objects are now a type of Windows Computer, and the hosting relationship is broken.
just a small input: based on the following technet blog you should rather use PrincipalName of the windows.computer class as target than the NetworkName: http://blogs.technet.com/b/omx/archive/2014/03/05/principalname-and-networkname.aspx
Greetings from Berne 😉
Yes, absolutely correct, thx!