Essential Microsoft Operations Manager

Chapter 4. Administering Management Packs

The MOM 2005 components discussed so far provide the functional infrastructure of MOM. Each component plays a specific role in the management group. The agents interact with the managed computers, the management servers communicate with the database and manage the agents, the databases store collected data and configuration information, and the consoles allow interaction with MOM. But the picture is not yet complete. At this point, all the components of a management group are like the members of an orchestra. They are sitting where they are supposed to be in relation to one another, they have a conductor that coordinates the actions of the various instruments, they have tuned up, and the audience is waiting for them to perform. But no meaningful sounds are being made because they have no sheet music—the management packs. Management packs allow the management group to identify the applications on a computer, to group computers by function, and to determine the health of the applications on those servers. They then tell management group components how to notify the outside world of pertinent information, format the information for consumption, and offer tools for troubleshooting the application.

Tip

Install reporting services before you import management packs into the management group. By doing this, the report definitions can be imported at the same time.

Microsoft has publicly stated that every server that is a member of the Windows Server System grouping will have an associated management pack developed by the application product team. They have met this goal for the most part, although sometimes the release of the management pack lags well behind the release of the application.

In MOM 2005, management packs have grown up. Earlier versions of management packs were alert-oriented, but the MOM 2005 management packs are state-oriented. These management packs provide insight into the current state of an application or a server and each of its components. They do so in an easy-to-interpret red-, yellow-, and green-light fashion. You have already seen this in the State view in the Operator console in Chapters 1 and 3. The alert helps determine the health state of an application or server. Alerts need to be handled individually, but they are not the highest level of data that MOM 2005 produces.

In the future, under Microsoft’s Dynamic Systems Initiative, management packs may evolve into or be replaced by objects called system definition models (SDMs). These models will logically represent entire computer systems (e.g., hardware, OS, and applications) to developers and monitoring applications.

This chapter discusses the most common tasks involved with administering management packs. You will see how Leaky Faucet administers management packs, and some beneficial tools will be introduced. More extensive treatment will be given to the rules that the agents execute, as well as the components of management packs. From this you will learn how to modify existing management packs and rules for your environment and how to create a simple management pack from scratch.

How well MOM produces actionable, pertinent information and how much it raises your operational awareness depends on how the management packs are administered and how the rules in those packs are adjusted.

Management Pack Life Cycle

There are two types of management packs: those developed by parties outside your company (either by Microsoft or a third party, such as NetIQ or eXc Software); and those developed internally because there are no third-party management packs for the application. An application may not have a vendor-developed management pack because it is obscure and too small to warrant one, because it doesn’t have a service that can be monitored and doesn’t write to the event log, or because the software vendor just isn’t interested in developing one. Most likely, a management pack does not exist for an application if it was homegrown.

Once imported into MOM, both management packs follow the same life cycle. Managing the life cycle of management packs is what the rest of this chapter is about. Life cycle describes the process that the management pack goes through as you take it from its original vendor-created state and tailor it to your environment, first by testing it and modifying rules and then by using it in your production and preproduction environments. As the management pack is used and you troubleshoot alerts, you will capture those troubleshooting steps in the management pack. You will also likely change the thresholds for rules that generate alerts and the severity of those alerts. All of these management pack modifications mean that the management pack you are using today will not be the same as it was the day before, or as it will be tomorrow.

Most companies get into trouble with their management packs because of poorly implemented version control . Because companies don’t have a plan for managing change, they end up with multiple versions of the same management pack and don’t know which one has the most up-to-date rule sets and there is no record as to why the rules were changed. When a vendor update needs to be applied, it is unclear which existing version of the pack it should be merged with, so the existing version is overwritten and all customization is lost. In this regard, managing management packs is somewhat like maintaining code versions. There must be a solid management pack version control methodology and all the changes to the management pack rules must be documented.

Figure 4-1 shows a process that can be used for moving, modifying, and tracking versions of any given management pack. This workflow is the foundation for most of this chapter, and it will be referred to often. The workflow brings a management pack into the preproduction environment, tunes it, and deploys it into production. From there, it covers the evolution of the management pack in production and how to synchronize those daily changes back to the preproduction environment. Finally, the workflow shows how to integrate changes into existing versions of a management pack when the vendor provides an update.

Figure 4-1. Life cycle workflow of a management pack

The workflow focuses on maintaining control through the preproduction and production environments. The vendor column is included as another entry point for change.