Section 4.1. Management Pack Life Cycle

4.1. 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.