Blog TalesMonitor the Default Management Pack

Jonathan Almquist

In which we search far and wide to bring you the best of the Microsoft blogs. Here's one from Jonathan Almquist on his Operations Manager blog.

Code download available at: TNonlineAprAlmquist.BlogTales2009_06.exe(153 KB)

A colleague, Kevin Holman, wrote about best practices concerning the Default Management Pack, and how to clean it if it happens to get messy, which you can see in last month's Blog Tales column. Unfortunately, it seems almost inevitable that the Default MP will become cluttered in time. This mostly comes down to educating staff on being careful not to save anything to the Default MP. Hopefully, this mistake will not be so easily made in future releases of OpsMgr.

In Kevin's post, he had an idea of monitoring the Default MP. Essentially, send a notification or raise an alert if the number of overrides stored in the Default MP should exceed a threshold. This threshold is a number you decide is acceptable. One way to determine your threshold is to check where you're at now. Run the following query against the OperationsManager DB:

select count(*) as NumberOfOverrides from AllOverrideView aov 
inner join ManagementPackView mpv on aov.managementpackID = mpv.Id 
where mpv.name = 'Microsoft.SystemCenter.OperationsManager.DefaultUser'

If you currently have more than 2, you may want to check what is in there and do an initial cleanup. Given an acceptable number of overrides (let's just say 2), we can set our threshold and generate alerts when this is exceeded. For brevity, I have created a sample MP (monitordefaultmp.zip) that you can download. This sample sync's at midnight, and queries the OperationsManager DB for the number of overrides in the Default MP. It compares this number with the threshold you have set in the rule parameters, and raises a Warning alert in the Operators Console. Of course, you can expand on this workflow and add a notification or change the severity if you like.

To import my sample Management Pack

If you want to get this going quickly by just importing, you can use my sample MP.

The script write action rule is not enabled by default. After importing, go into the Authoring space of the Operators Console. Click Rules > Scope to Root Management Server > search for string Default > Right-click "Monitor Default MP Write Event" rule > Overrides > Override the Rule > For all object of type: Root Management Server.

Check the Enabled parameter, and set to True.

Check the Arguments parameter, and enter your threshold, Operations Manager database server name, and Operations Manager database name.

Note: Arguments are space delimited.

To create the rules in your own custom MP using the attached script

If you want to create these rules in your custom MP, follow these instructions and use the downloaded script for your script write action rule.

First we'll create a rule that executes the query on the OpsDB, and creates an event in the Operations Manager event log for us to match and generate alerts. Create a new rule > Timed Commands > Execute a Script. Save into your custom Management Pack. Perhaps you have a MP that you've already been creating some custom monitoring or tasks.

Enter a rule name and select Root Management Server for your Rule Target.

Configure the schedule to run once a day. Synchronize the rule, so that it will always run at the same time. If a synchronize time is not specified, the rule will automatically sync to the time when the workflow became active on the agent. This means the rule will sync at the time it was initially delivered to the agent...and subsequently synchronized to the time when the agent Health Service is restarted.

Paste the MonitorDefaultMp script that you downloaded into the script pane. Keep the same file name for consistency. The filename here doesn't affect functionality of the rule, but the filename within the script is used in event data and needs to match NT Event alert expressions later in this walk-through. Click on Parameters.

Type in your determined threshold, the Operations Manager DB Server Name and the Operations Manager DB Name. The parameters are space delimited.

You're finished with this rule. Click create and let's move onto the alert generating rule.

This rule will match the event in the Operations Manager event log and generate an alert. Create a new rule > Alert Generating Rules > Event Based > NT Event Log (Alert). Save to the same MP.

Type in a rule name, select the Alert category and target Root Management Server.

Specify the Operations Manager log.

Build the expression as follows. This is where we need to match parameter 1 to our script name. This script name is actually specified in the log event method from within the script. If you take a look at the script, you'll see the script name specified. This is what's being matched. This is why it's important we keep these script names consistent throughout. Otherwise, it's more difficult to build an efficient expression.

Lastly, we'll specify the alert information. I recommend Event Description...that'll give you all the info you'll need. I specified Warning for severity, as I thought it was better suited for this type of alert.

Finally, this is the result.

This is what you'll see in the Operations Manager event log.

If you want to test this and see results quickly, specify a threshold value of 1 in the parameters, uncheck the synchronization time and configure the schedule to run every 1  minute.

Jonathan Almquist is a Premier Field Engineer, based out of Minneapolis, MN. He's been in the IT industry since 1999, with the most recent years primarily focused on the Operations Manager platform. He provides guidance to enterprise customers in the United States, as well as contributes to the Operations Manager community through his blog and other technical forums. In his free time, Jonathan enjoys spending time with his wife and son, while finding enough time to run the paths throughout the beautiful Minnesota lakes and woods.