Welcome this week’s edition of having fun with Operations Manager and Windows Media Center. In the first part of this series we discussed why it is beneficial to create your own class structure. In the second part of this series we discussed a wizard driven method to create your own class structure and discovery. In the third part of this series we showed how the health model works in Operations Manager and a processes to gather information which you will need to effectively monitor your application. In today’s blog post we will discuss the process to add rules and monitors through the Operations Manager console to your new management pack and show how to also monitor services.

This blog post will specifically cover how to add monitoring which is relevant to the application including:

  • Rules
  • Monitors
  • Services

Now that we have created our management pack in MP Author and we have identified what rules and monitors we want to create it’s time to get in there and start creating them. As discussed in the second part of this blog series there are a variety of methods which you can also use to create your own rules and monitors (and to monitor your services). These include:

  • Visual Studio Authoring Extensions (VSAE)
  • 2007 Authoring Console
  • XML
  • MP Author by Silect
  • Operations Manager console: This is my preferred approach to write rules and monitors due to my familiarity with it. We will need to do some cleanup later as a result of this choice but it still seems the easiest way to add this type of functionality if you have experience working with creation of your own rules and monitors in the console.

The Operations Manager console is now on the list as we already have the class structure that we need for our management pack. So we start by importing the management pack that we created in the second part of this series into Operations Manager. After this is imported we can use the Excel spreadsheet that we generated when gathering our information in the third part of this blog series (shown below).


Creating the rules:

We start our authoring in the Authoring pane, and we begin by using the Wizard to add a new rule to for one of the specific events that we had identified (using the Alert Generating Rules \ Event Based \ NT Event Log (Alert) rule type. We will want to make sure that we choose our custom management pack to store our custom rules.

For the general tab we want to start the rule name with a unique identifier (Media Center in this example) and a description of what the rule will indicate (No TV Signal). Walking through the wizard we will need to know what eventlog this is coming from (Media Center), what event number (8), what source (Recording) and information explaining what is relevant about this event (No signal). We target this rule to the custom class that we created (MonitorMediaCenter.MediaCenterr.Application) and we enable this new rule by default since we have created our own class that this is targeted to.

We can browse to the event log on the system (as shown below) or we can just type it in directly in the text box.

Once we have chosen the event log we can move onto the event details.

For this example we are looking to match Event ID 8, from a source of Recording with an event level of Warning as shown below.

On the last screen we configure our alerts. For this example we want to make the alert name easy to understand and I also prefer to preface the alert with a unique string (Media Center in this case) indicating what management pack is creating the alert.

After configuration of the alerts, clicking create finishes the process of creating our first rule for our custom management pack! Now, rather/rinse/repeat for the rest of the rules that you identified from the earlier blog post.


Creating the monitors:

Now that we have created our rules we can move into the slightly more complex step of creating our own monitors. As with our rules, we need to know the event log, source, event id and event level for both healthy and unhealthy conditions. Additionally and we want to store these monitors in our custom management pack. As with the rule we create the monitor in the authoring pane but we choose the option to create a new Unit Monitor.

For this example we know that we have both a healthy condition and an unhealthy condition – both of which are indicated by windows events. So we are using the Windows Events \ Sample Event Detection \ Windows Event Reset monitor.

We again use a unique identifier for the start of the monitor name (Media Center) followed by a description of what is being monitored (MCUpdate issue). The target is our custom class, under the availabity parent monitor and we want this monitor to be enabled by default for our custom class.

We can browse to or manually enter the log file name (Media Center in this example) for the unhealthy event first.

Then we indicate the event expression for the unhealthy event, the log file for the healthy event, and then finally the event expression for the healthy event as shown below.

We next define the health model for this so that the first event (unhealthy) indicates either a warning or critical condition (warning in this example) and we define the second event (healthy) to indicate a healthy condition.

As the last step we configure the alert so that it generates an alert for this monitor, includes our custom name (Media Center) and we define both priority (Medium) and severity (Critical). This means that for our health model the object will be in a warning state, but this particular condition will raise a critical alert. In general these should match (warning and warning) but for this example I chose a critical level for the alert so I would be more likely to notice it when reviewing my alerts as part of the management pack development process (this was later tuned to a warning severity).

As with the rules, we now lather/rinse/repeat for each of the rest of the monitors identified in our Excel spreadsheet.


Monitoring the services:

Now that we have created our rules and monitors we can now monitor services which we discovered earlier in this blog series. As with the rules and monitors that we added previously, these are added in the authoring pane of the Operations Manager console. Create a new Unit Monitor. For our services we choose a different type of monitor (Windows Services \ Basic Service Monitor). We could also have done this through using the Windows Service management pack template but I chose not to for these as I was not interested in monitoring either CPU or memory used by these services).

To make these easy to find again we start with the custom name for our management pack (Media Center) and then provide a description of what we are monitoring (Receiver Service). We target our custom class, use the availabity parent monitor and leave the monitor set to enabled for our class.

We have to choose the service and provide details next (the easiest way to find this is to browse to the computer with the service and then choose the service off of the list of available services on that computer).

And then we configure health for the service as shown below (this can be configured as warning but in this example I used the default of critical).

And we configure the alert as shown below.

We repeat this process for each of the services which were identified as important for our application. The end result is a series of rules and monitors which should now notify us of relevant conditions for our application. The monitors combine to provide our health model as shown below.


Summary: By adding the relevant rules and monitors we now have both an effective health model for our application and the start of our alerts which we will use as part of this management pack!

In the next part of this blog series we will look at creating views and adding our custom object to a dashboard.