Setting an override on a rule with PowerShell (OpsMgr snapin part 2)

I finished the works for two cmdlets now. The result can be downloaded at this location. In the last few days I learned a lot about PowerShell programming and the SCOM SDK 🙂 One of the results is a rename of the cmdlets and the use of the WriteVerbose and WriteObject methods.

The next two cmdlets are now available in the download:

• Get-RuleParameter – This cmdlet shows you the name of the overrideable parameters of a rule, so you don’t have to dive into the .xml files as shown in part 1.
• Set-RuleOverride – This cmdlet will set an override on a rule.

I hope the help file is sufficient to get you to the first use of the cmdlets. In my next post I will create examples on how to use these two cmdlets.

The following cmdlets are still in planning:

• Get-MonitorParameter
• Set-MonitorOverride

These cmdlets will not be created:

• Get-ObjectId – The Get-MonitoringObject cmdlet from Microsoft can be used to retrieve the object id.
• Enable-Monitor – This will be part of the Set-MonitorOverride cmdlet.
• Disable-Monitor  – This will be part of the Set-MonitorOverride cmdlet.
• Enable-Rule – This is now part of the Set-RuleOverride cmdlet
• Disable-Rule – This is now part of the Set-RuleOverride cmdlet

Setting an override on a rule with PowerShell (OpsMgr snapin part 1: Set-OverrideRule)

We wanted to use PowerShell to create an override on specific rules. Since Google is your best friend, we started searching… And that was a disappointment. We only found a handful of links that stated that they did what we needed but only 1 that actually did more than just enable or disable a rule. This script on devcentral.f5.com was the only script that could do what we wanted. I used this as a starting point for our own cmdlets, that I could re-use in our PowerShell scripts. This blog will tell you how the snapin works and how to install it. The current version of the snapin can be downloaded here. There are two files available for download, one with the compiled .dll and help file (both x64 and x86) and one with the Visual Studio project and source code.

This snapin is still a work in progress (only the first cmdlet is now created), so I will create a blog when a cmdlet is finished. The current planning of cmdlets to write is:

• Set-OverrideRule
• Set-OverrideMonitor
• Get-ObjectId
• Enable-Monitor
• Disable-Monitor
• Enable-Rule
• Disable-Rule
• Get-ParameterMonitor
• Get-ParamaterRule

Installing the snapin

To install the snapin, save the appropriate version (x64 or x86) to a directory of choice and execute from that directory:

%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\installutil.exe mkrOpsMgr.dll

Note that you must open the cmd.exe with “elevated” rights and that this is for the x64 version of the snapin. Now that the snapin is registered, you can load the snapin  by executing

add-pssnapin mkrOpsMgr

Set-OverrideRule

Now that the snapin is loaded, the cmdlet is available for use. Inside a PowerShell prompt run the

get-help Set-OverrideRule –full

command for the help file of the cmdlet. The easiest way to show you how this cmdlet works, is giving an example. The next example will override the rule “Collect Database Free Space (%)” from the SQL 2005 management pack for a specific server in my environment.

The example will override the “Frequency (seconds)” parameter and set it’s value to 5555.

Set-OverrideRule -RootManagementServer “RMS01” -ManagementPack $mp -ClassCriteria “DisplayName=’SQL 2005 DB'” -RuleCriteria “DisplayName=’Collect Database Free Space (%)'” -Parameter “IntervalSeconds” -Value “5555” -Target “f846dad3-c816-6e78-d29f-f4df1975cfee”

Oops, that looks overcomplicated! But don’t worry, it all makes sense 🙂

• -RootManagementServer – The easy one, this is the name of the root management server. We need this to connect to the SDK service on this root management server.
• -ManagementPack – This is the management pack that will be used to store the override. This management pack must exist, the cmdlet will not generate a new management pack. The value has to be an object, so you should retrieve a variable to this object with the get-managementpack cmdlet: $mp = get-managementpack | where {$_.Name -eq “jamaOverrideRuleTest”} And of course it needs to be an unsealed management pack, since we are going to write into this management pack.
• -ClassCriteria – This is a string, with the criteria to select the class (object / target) in which the rule is defined. This should return a single class. If multiple classes are returned, an exception is generated. The format of the string is explained in this msdn article.
• -RuleCriteria – A string with criteria, but this time it is used to select the rule we want to override. Again it must result in a single rule or an exception will be generated. The format of this string is explained in this msdn article.
• -Parameter – This is the actual parameter we want to override in the rule (IntervalSeconds in this example). Note that the Enabled parameter can not be set with this cmdlet, I will create a separate cmdlet for the enabled parameter (which is actually a property).
• -Value – The value we want for the override.
• -Target – This is the GUID of an explicit object (db, server, group, etc) as a string. When this value is given, the override will be set for this object only. Otherwise the override will be set for the rule.

Ok, great but wait…… How do I know which class and rule criteria to use and how can I find the parameter name??

The class criteria can be easily found in the GUI. If you use the “DisplayName”=” criteria, the class is the “Rule target” from the GUI.

And the rule criteria can be found also with the “DisplayName=” criteria, it is the rule name of the rule:

Don’t you love all those different names for the same object 🙂 ?

The only tricky one is the actual parameter, you have to look into the management pack itself to find the correct name. First find the Rule that corresponds with the display name:

The DisplayString element id, gives you the ID of the rule. Searching for that rule gives you:

Here you need the TypeID of the data source, which in turn will give you all available parameter names:

And that’s where you can find the required names for the parameter you are allowed to set. Or you must wait for the cmdlet Get-ParameterRule to be written 🙂