Choose Base Classes for Your Management Pack
The first thing you learn when writing a mangement pack is that you need this thing called "classes" to make your managment pack work. This is a confusing term, and often throws new authors for a loop because of the conceptual similarity to object oriented programming.
The similarities are pretty deep - and in fact the System Center team made an effort to make Operations Manager more "object oriented" in version 3 to try and get some of the gains that you get when designing a system in an object oriented way. These gains include "free behaviors" (simplifying development of management packs), easier management for your customer (due to the user interface in the Operators Console being able to report on the health of things rather than just tabular reports of alerts and symptoms. Classes, properties and inheritence are the artifacts that you need to learn about in order to get these gains.
One of the first choices you make when designing a class for your management pack is to decide on which base class it should inherit from. Base classes come from libraries of predefined behaviors that are supplied as part of the Operations Manager infrastructure. There are dozens and dozens of possible base classes, and you can even use our own classes as new base classes to derive other classes from - it gets confusing really quick however because the "class picker" in the authoring tools simply presents a list of all possible base classes. You essentially have to be an expert on the Ops Manager class library in order to be sure of what you get in the end.
For a management pack designer, having to be an expert to get started is a pretty daunting problem.
In this article we present simple list of "Do's" for choosing the right parent class to choose. In most cases the base class types listed here are going to be the ones you always want to use.
| Class Name | Library Reference | When to use | Benefits |
| Microsoft.Windows.ComputerRole | Microsoft.Windows.Library | If your product is classified as a server role then this is a good choice. Side Effects: Always gets a "Hosted" relationship to the computer the product is installed on. Always adds a column into the Computers View | Automatically rolls up health to the computer (real or virtual) that hosts the application. If you want your application to show up in the computer view as a column, and have automatic health roll up at the computer level, always choose this class first as the parent of your classes. |
| Microsoft.Windows.LocalApplication | Microsoft.Windows.Library | Choose this when the application or product runs on a windows computer and can be run with other applications on the same computer. In the case of a minor application that the customer typically would install on multiple computers but not dedicate computers or virtuals to, this is a good choice Side Effects: Has a "hosted" relationship to the computer. | This is another easy base class choice for most management packs for non-workload related products. Inherits from ComputerRole, so the health of the application will show up when the customer drills into the computer-role within a computer health view. |
| Microsoft.Windows.ApplicationComponent | Microsoft.Windows.Library | Choose this when the elements whose health you want to show to your customers is a part of a larger system that cannot be deployed and operated independently of other more standalone parts of your product. An example is the SQL Agent service, which doesn't make sense to deploy without the SQL Server product. Side Effects: Can roll up to either ApplicationComponent or ComputerRole easily. | Use this when you want to declare a hosted by relationship to other classes in your management pack (or that are public in other management packs), and want a automatic health roll up to the higher level classes in your class hierarchy. |
| System.Service or System.ComputerRole | System.Library | Choose one of these when you want to represent a logical element of your application with fine grain control over hosting relationships and health roll up. Side Effects System.Service allows your class to be used from within the distributed app designer at customer locations. System.ComputerRole has no known side effects. | If the three choices above don't make sense, consider this one next. |
| System.Perspective | System.Library | This is used to drive a roll up across multiple distributed elements of the application and represents an element of service that can be impacted by a number of classes that are physically deployed on separate computers. Side Effect: Always hosted on the Root Management Server. | Use this class when you want to project a roll up of health states for an element of service. A good example might be "availability" as a rolled up health state for a load balanced web site. If any of the instances represented by the perspective element are up, you can show that your service is up, even if some of the elements are not healthy. |
Common base class derivations for application/product elements
Other types of base classes exist for describing things like groups of instances, and groups of computers. Typically groups are used to give your customers the ability to constrain monitoring to a set of like elements, rather then let the domain wide discovery just start monitoring everything your mangement pack covers no matter what importance, relevance or status that has. Think of the case where you want to add monitoring to business critical web sites - but don't care to have the same level of operator attention paid to non-essential services.
A good practice is to always think about adding a group to your MP. This would let customers decide on sub-sets of computers or discovered classes. Customers can then use the group to limit the scope of the monitoring. If this is a goal, make sure you ship the appropriate discoveries as public accessibility and with the enabled property set to false. Doing this lets the customer easiliy create an override that enables the discovery only in the context of the group. If you ship the discovery enabled, importing the MP will cause the discovery to run and this limits the effectiveness of groups.
Another way to do this is by using script based discovery and having the discovery manage the group content. System.Service makes a good choice for this discovery populated type of group.
Having a computer group (or other group) that targets your classes then lets the customer decide which computers (or web sites, etc) matter by adding those to the group that you provide, and then adding creating an override on the Enabled property for the discovery property in that group.