I’m not a good developer. I know this as a fact because I started my career as a developer. Now I develop when I need to but in general I would put my coding skills at one half a step above a hack in most situations. Now-a-days you can tell who is and who isn’t a developer by the answer to this question:

"Can you open Visual Studio and do something with it without having a panic attack or closing it out in frustration?"

If you answer to this question is affirmative, you are a developer in my books.

If you answer to this question is negative, you and I are on the same page.

Let’s say that I wanted to monitor my Windows Media Center to send me alerts when errors occurred which I should be aware of (or hey, alert me when the newest Walking Dead, Gotham or Flash episode finished recording). I could add this monitoring to Operations Manager as long as I have an Operations Manager agent on the system and I create monitoring to watch for that condition. Historically I would do this through the Operations Manager console and utilize the existing class structure so we’ll start approaching this requirement using the OpsMgr console only.

 OpsMgrFun01.png

Creating the management pack without a custom class structure

In Operations Manager, we have learned over the years that we can add functionality through a management pack pretty quickly. This can be done by finding the appropriate class, creating a disabled rule or monitor targeted at that class, and enabling the rule or monitor for a group which you define. This is quick and easy and gives you monitoring for what you are looking for. Let go through an example of this:

First we create a management pack in the Operations Manager console (Monitor MC Test in this example)

 

Next we create a unit monitor with a simple event detection based upon a windows event reset.

We choose our management pack that we created. For our unit monitor we add a name, choose the target (in this case Windows Operation System just to make it easy to show impacts of using this approach to creating the monitor without a custom class) and we uncheck the box "Monitor is enabled" as we don’t want this monitor to activate for all objects of Windows Client – just for the ones that we will specify in our group.

We can browse to our event log on the remote system and identify the healthy and unhealthy conditions we are looking for. In this example, we are looking for an event id number of 0 from the source of MCUpdate with an Informational event level when it’s healthy and a warning event level when it’s unhealthy (the screenshot below is part of a later blog post where I will review all of the events which I am monitoring as part of this management pack).

An example of the conditions that we are looking for is shown below for the warning event (unhealthy condition).

Once we create this monitor, the next step is to create a group which contains the objects that we want to enable the monitor for.

Then we create an override to enable this monitor for the group.

We are now monitoring for this condition on the appropriate server as we can see from the health explorer for the Windows Operating System for the system that the group contains:

However, if we check the health explorer for an unrelated object (not contained in the group that we used to activate the monitor) we see that the monitor is here as well just unmonitored:

Benefits: There are benefits to this approach, and this is a common approach. These include:

  • Quick and easy to put together.
  • You never even needed to leave the Operations Manager console or learn any other tools to author your management pack.

Negatives: There are however several negatives to this approach. These include:

  • This clutters the health explorer for all items in the class
  • Issues identified in the monitor impacts the health of the object
  • It’s difficult to determine what is monitored and where
  • Since there is no custom class for your object you can’t put the monitor or rule on a dashboard in Operations Manager so you must use the object in the class that you assigned the monitor to (within OpsMgr, this isn’t necessarily valid in third party dashboarding solutions and will be discussed later in this blog series).

 

Creating the management pack with a custom class structure

By creating a class structure instead of using the approach listed above we gain additional functionality and remove several of the negatives above.

Benefits: There are significant benefits to this approach (hey, no matter what you gotta have class right?). These include:

  • Still quick and easy to put together.
  • The health explorer is not cluttered because we are creating our own class for this new monitoring
  • Since we have created our own custom class, we can put objects of that class in a dashboard (which we will discuss later in this blog series)
  • It is easy to identify what objects are monitored as we can easily identify what instances of the class exist (see the Discovered Inventory screenshot below)

The screenshot below shows the health explorer for the custom class which was created to provide monitoring for Windows Media Center.

Summary: There are significant benefits to creating your own classes when you want to monitor custom functionality with Operations Manager.

In this blog series I will go through the full process to create your own management pack which monitor Windows Media Center as an example for how simple this process is and how much benefit you can gain for your custom applications. In the next post of this blog series I will go through the easiest way I have found to discover resources and add custom classes in Operations Manager.