Change Management for Microsoft Operations Manager 2005 Management Packs

Note on IT

Published: December 2, 2004

In Microsoft Operations Manager (MOM) 2005, processing rules define monitoring logic. To streamline rule management in MOM management packs, the Microsoft Information Technology (Microsoft IT) group established a consistent means of tracking and comparing changes to these rules.

Introduction

This Note on IT explains how the Microsoft IT group manages changes to rules in Microsoft® Operations Manager (MOM) 2005 management packs. Although this Note on IT specifically covers how Microsoft IT performs change management for management packs, organizations can also apply this process to custom rule sets. This document assumes that readers are either MOM architects or technical implementers and are already familiar with MOM 2005, including the creation and changing of processing rules and processing rule groups.

Microsoft Operations Manager 2005 Deployment white paper

Management packs serve as containers and distribution vehicles for deploying the configuration information that organizations use to manage computers and applications. Microsoft offers a wide range of management packs that cover many different technologies and applications. Organizations and third parties may also develop their own management packs. Each management pack varies in complexity and can include tens of rules to hundreds of rules. Although management packs are often applied directly out of the box, organizations may want to make changes to fit the needs of their environments.

Note   For a listing of available management packs, see the online Management Pack and Product Connector Catalog.

If organizations need to make changes to MOM management packs, they need a consistent approach to making, documenting, and comparing changes. Having a consistent change management approach can improve the usability of an organization's rule structure by ensuring that any changes are self-evident and self-explanatory.

An organization will benefit from having a strong change management in the following situations:

• Changes to a management pack might be rolled back.
• An upgrade is being carried out, and the IT organization wants to compare two versions of the management pack.
• Someone in the organization made a change in the past, and the organization wants to know the reason for the change.

For the purposes of change management for management packs, Microsoft IT has instituted:

• A process for backing up and archiving copies of a management pack.
• A formalized structure of rules and standards for creating and changing rules.
• A rule deployment policy.
• A standard method for reconciling the differences between two versions of the same management pack.

The following sections of this document provide more detail and prescriptive guidance on how Microsoft IT performs change management tasks.

Note   For security reasons, the sample names of forests, domains, internal resources, organizations, and internally developed applications and files used in this document do not represent actual names used within Microsoft and are for illustration purposes only. In addition, the contents of this document describe how Microsoft IT runs its enterprise data center. The procedures and processes included in this document are not intended to be prescriptive guidance on how to run a generic data center and may not be supported by Microsoft Customer Support Services.

Backing Up and Archiving Management Packs

Change management requires a central storage point for backing up and archiving management packs.

Creating a Centralized Management Pack Storage Point

The storage point should be on a shared network resource, preferably on a MOM management server. Management packs will be exported as .akm files and stored on this server. A good candidate for hosting the storage point is the management server that hosts the MOM database.

The MOM 2005 installation folder (by default, C:\Program Files\Microsoft Operations Manager 2005) contains a folder named Management Packs for storing the current versions of the installed management packs. Microsoft IT also creates a folder named Archive under C:\Program Files\Microsoft Operations Manager 2005\Management Packs to store older versions of management packs.

If an organization's environment is a multiple-tier MOM environment, in which multiple management groups share management packs, Microsoft IT strongly urges the organization to perform all rule creation and archiving on the top-tier management server. This way, all other systems can pull the most recent management pack from one location.

In the example MOM environment shown in Figure 1, the top tier contains only one management server named \\MOM-DB-TOP. The two lower-tier management groups are geographically dispersed, contain one management server each, and contain all of the agents.

Figure 1   Multi-tier MOM 2005 environment

In the environment shown in Figure 1, the suggested location for the storage point for managing changes to management packs would be as follows:

• Hosting server: \\MOM-DB-TOP
• Storage point root: C:\Program Files\Microsoft Operations Manager 2005\Management Packs
• Archive location: C:\Program Files\Microsoft Operations Manager 2005\Management Packs \Archive

Using a Consistent Naming Convention

In addition to having a central location to store the .akm files, Microsoft IT uses a uniform naming convention for the .akm files. The naming convention clearly identifies each management pack, and when that management pack was backed up. By concatenating the name of the technology that the management pack monitors with a date stamp—that is, NameOfTechnology_YYYYMMDD-HHHH.akm—an organization can create file names that are easy to understand and easy to sort. For example, a management pack for Microsoft Systems Management Server (SMS) 2003, archived on July 7, 2004 at 1:30 P.M., would be named MicrosoftSMS2003_20040730-1330.akm.

Exporting the Rule Set After Making Changes

Microsoft IT uses the following process when archiving a management pack:

1. Make the necessary changes to the management pack in accordance with the change policies discussed later in this document under "Document Changes to Rules for Change Management."
2. Save each top-level processing rule group that contains changed rules to the storage root folder as follows:
   1. Open the Management Pack Import/Export Wizard in the MOM 2005 administrator console.
   2. Click Export Management Packs.
   3. On the Select a Rule Group page, select the topmost processing rule group that contains some or all of the rules that were changed.

      Note   During the management pack export process, the wizard prompts the administrator to select the processing rule group that should be exported. The wizard then puts the contents of that processing rule group and all subgroups in an .akm file, with the processing rule group selected in the wizard as the new topmost group regardless of what that group's level was in the previous rule hierarchy. For that reason, Microsoft IT suggests that regardless of where an administrator makes changes in a processing rule group hierarchy, he or she should export management packs only from the topmost processing rule group.

   4. Select the appropriate views and tasks to export with the management pack.
   5. On the Management Pack Name page, click Browse.
   6. In the Open dialog box, browse to the storage point root location.
   7. In the File box, type the name to give to the .akm file according to the naming convention.
   8. Complete the wizard to save the file to the storage point folder.
3. If a previous version of the management pack file just exported already existed, move the previous export of the management pack to the Archive folder under the storage point.

Developing a Policy for Creating and Changing Rules

Because management packs are developed to cover a wide range of scenarios, the need for changes is usually minimal. However, if an organization must make changes to a management pack, or if an organization is working with an internally developed management pack, it must have clear guidelines for how to create and change rules. The following guidelines, based on the experience of Microsoft IT, cover how an organization should structure rules, and how an organization should document changes to ease future comparison and investigation.

Structuring Rules for Change Management

Rules in MOM are organized into a hierarchical structure that contains processing rule groups, which in turn contain processing rules. As is the case with management packs, hierarchies of processing rule groups logically group rules by feature or function. Maintaining this structure is important for ease of navigation and comparison, ensures that importing future versions of the management pack will not overwrite customizations, and takes advantage of the existing structure of management packs. Following are guidelines that Microsoft IT uses for structuring rules for change management.

Leave the Original Management Pack Intact

To maintain the structure of the management pack for the purposes of documentation and comparison, an organization should always leave the original rules and the structures of processing rule groups intact. For this reason, rather than change an existing rule, Microsoft IT recommends creating a copy of that rule, changing the copy, and disabling the original. The only change that an organization should make to an existing rule or processing rule group from a management pack is to disable it.

Create the New Rules in the Same or a Replica Processing Rule Group Hierarchy

When an organization needs to supplement management packs, there are two possible approaches to take:

• Make changes in an existing management pack
  An administrator finds the appropriate processing rule group in the management pack and adds the new or changed rule directly into the existing processing rule groups. When changing existing rules, the administrator makes a copy of the existing rule in the same processing rule group, disables the original, and makes changes to the copy, adding a rule name tokenization that distinguishes it from the original rule.
• Make changes in a separate and duplicate hierarchy for processing rule groups
  An administrator first creates one processing rule group at the topmost level of the hierarchy of processing rule groups and gives the group a descriptive name, such as "Custom Rule Set." Under that top-level processing rule group, the administrator creates a replica of the processing rule group hierarchy for which he or she has changed rules, and then stores the new rules and changed copies of existing rules in that hierarchy. Microsoft IT recommends that the administrator add text to the beginning of the processing rule group names and the rule names to easily distinguish them from the originals.

Documenting Changes to Rules for Change Management

An organization that needs to change rules should take measures to ensure that individuals who need to perform tasks in the future can understand how and why rules were changed. Microsoft IT recommends the following steps that an administrator can take when changing rules in a management pack:

1. Identify the processing rule to be changed and document its name and its full path.
2. Disable the original rule.
3. Make a copy of the original rule, either in the existing folder or in the replica processing rule group hierarchy used for storing changes and additions.
4. Change the name of the rule to remove the string "Copy of" and to add the text that will distinguish the new rule from the original.
5. Make changes to the new rule.
6. Document the changes in the Company Knowledge Base area on the Knowledge Base tab in MOM. Figure 2 shows an example of the Knowledge Base tab.

   

   Figure 2   Knowledge Base tab in MOM

The template for documentation of rule changes in the Company Knowledge Base area of the Knowledge Base tab in MOM is as follows:

• Date: current date
• Change Made: brief description of what was added or changed
  • Change 1
  • Change 2
• Reason: brief description of why the rule was added or changed
• Detail: full explanation for the change
• Rules Added: full list of any new rules created, including full processing rule group path to the rule
• Rules Changed: full list of any existing rules changed, including full processing rule group path to the rule
• Change Made By: name or alias of the person committing the rule change
• Change Requested By: name or alias of the requestor of the rule change

Developing a Rule Deployment Policy

Another policy that an organization needs to consider for managing changes to management packs is to define how rules are deployed. Deployments include rolling out new rules, in addition to rolling back rules when changes need to be reversed.

Note   For more information about the mechanics of the import and export functions for management packs, including specifics of the Replace existing Management Pack option versus the Update existing Management Pack option of importing management packs, see Chapter 6, "Deploying MOM 2005 Management Packs," in the Microsoft Operations Manager 2005 Deployment Guide. The deployment guide can be downloaded at http://www.microsoft.com/mom/techinfo/productdoc/default.mspx. For the processes described in the following sections, only the Replace existing Management Pack option is used for importing management packs. The Update existing Management Pack option is useful for importing upgrades to existing management packs.

Overwriting an Existing Rule with Updated Rules

In most instances, when deploying changes to management packs, administrators should overwrite the existing rules with the updated rules. This action ensures that all updates override any existing versions of the rules. The following sections provide the steps to take in a stand-alone (single-tier) environment and a multi-tier environment, respectively.

Stand-Alone Environment

In a stand-alone environment, an administrator typically makes changes in the production management group, so the changes are automatically applied to that group. After the administrator makes all changes, he or she should always back up the management pack.

If the organization uses a separate management group as an environment for creating rules, the administrator should export the management pack from that management group, and then import the management pack into the production management group by using the Management Pack Import/Export Wizard. On the Select Management Packs page of the wizard, the administrator should:

• Click the Replace existing Management Pack option.
• Clear the Backup existing Management Pack check box.

When the import is complete, the administrator should back up the management pack.

Multi-tier Environment

In a multi-tier environment, an administrator should make all changes in one central location on the top-tier management server. After committing the configuration changes on the top tier, the administrator should back up the changed management pack.

Then, from each lower-tier system, the administrator should import the management pack from the storage point by using the Management Pack Import/Export Wizard. On the Select Management Packs page of the wizard, the administrator should:

• Click the Replace existing Management Pack option.
• Clear the Backup existing Management Pack check box.

No backup is required for the lower-tier systems.

Merging Existing Rules with Updated Rules

In some cases—such as upgrading an existing management pack to a new version provided by the vendor of the management pack—it is appropriate to retain certain customizations. When an administrator imports a management pack by using the Update existing Management Pack option on the Select Management Packs page of the Management Pack Import/Export Wizard, the management pack will retain the following:

• User-added company knowledge on vendor shipping rules
• User modifications to the default state of rules (enabled or disabled)
• User-added custom rules

When Microsoft IT merges two versions of a management pack, it uses the Update existing Management Pack option instead of the Replace existing Management Pack option.

Rolling Back a Management Pack Deployment

Rolling back a management pack deployment entails getting the previous build of the management pack .akm file from the archive and importing it into the applicable management groups. On the Select Management Packs page of the Management Pack Import/Export Wizard, the administrator should:

• Click the Replace existing Management Pack option.
• Clear the Backup existing Management Pack check box.

Reconciling Differences Between Two Versions of a Management Pack

The last key aspect of change management is being able to analyze what has changed from one version of a management pack to the next. Tools introduced in the MOM 2005 Resource Kit simplify the process of reviewing the changes made between two management packs.

Note   The MOM 2005 Resource Kit can be downloaded at http://www.microsoft.com/mom/downloads/2005/reskit/default.mspx.

An administrator can take the following steps to generate a comparison report between two versions of the same management pack:

1. Export the original management pack from the environment as an .akm file or, if it has already been exported, make a note of the location and file name.
2. Export the changed management pack from the environment as an .akm file or, if it has already been exported, make a note of the location and file name.
3. Convert both .akm files to Extensible Markup Language (XML) format by using the Convert Management Packs to XML tool (MP2XML.exe) from the MOM 2005 Resource Kit. The syntax for the MP2XML tool is:

   MP2XML [InputAKMFile] [OutputXMLFile]

   For example, to convert an .akm file named MicrosoftSMS2003.akm to XML, the command would be:

   MP2XML MicrosoftSMS2003.akm MicrosoftSMS2003.xml

4. Generate a comparison report by running the MpDiff.Console.exe tool from the MOM 2005 Resource Kit against the two management pack XML files as follows:
   • Use the original (older) management pack as the source and the changed (newer) management pack as the target.
   • Send the results to an output file by using the /out command-line parameter. The syntax for this command is:

     MpDiff.Console.exe /src:SourceMpFile.xml /tgt:TargetMpFile.xml [/out:<outfile.xml>] [/v:u|c|a|d] [/createLock:FileName] [/lock:FileName] [/schema:on|off]

     For example, using the MicrosoftSMS2003.xml file as an example, the command would be:

     MpDiff.Console.exe /src:MicrosoftSMS2003_20041004-1215.xml /tgt:MicrosoftSMS2003-RTM.xml /out:MicrosoftSMS2003-Diff.xml

5. Open the output XML file. Ensure that the XML style sheet named DiffOutToHTML.xslt, which was included with the installation of the MOM 2005 Resource Kit, is in the same folder as the output file.

The output XML file displayed through the XML style sheet has the following format:

• Each component type (for example, Knowledge Base, processing rules, and computer groups) appears in its own table.
• Each table has the following six columns:
  • Functional. How the functional attributes of an object changed.
  • Informational. How the object changed with respect to its informational aspects (description, and in some instances name).
  • Organizational. How the object changed with respect to its location in the relevant organizational structure.
  • Deployment. How the object changed with respect to which computer groups it is applied to.
  • ID. The globally unique identifier for the object.
  • Name. The name of the object.
• Each row that has a status of anything other than Unchanged displays—when an administrator clicks the leftmost field—the details of how the rule was changed. In the instances of Added and Deleted, this detail row is empty.

Figure 3 shows an example of the comparison report.

Figure 3   Comparison report

Table 1 can help an administrator understand what changes were made to a management pack. Each status may indicate one of a number of different meanings.

Table 1   Likely Meanings of Statuses in the MpDiff Output File

Conclusion

Change management is important in any environment where MOM management packs are customized, extended, or authored. A management pack change management process helps to ensure that changes are documented and can be identified for rollbacks and upgrades. Microsoft IT keeps an archive of previous versions of the management packs it develops. When any change is made to a management pack, the previous version of the management pack is saved to this archive. Using tools available in the MOM Resource Kit, administrators can compare management pack versions and report on changes that have been made. While the change management process at Microsoft may not meet the needs of every organization, it can serve as a model to assist organizations in developing their own change management process.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information through the World Wide Web, go to:

http://www.microsoft.com

http://www.microsoft.com/services/microsoftservices/howmsdoesIT.mspx

http://www.microsoft.com/technet/itsolutions/msit/default.mspx

For any questions, comments, or suggestions on this document, or to obtain additional information about Microsoft IT Showcase, please send e-mail to:

showcase@microsoft.com

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This Note on IT is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Microsoft grants you the right to reproduce this White Paper, in whole or in part, specifically and solely for the purpose of personal education.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2004 Microsoft Corporation. All rights reserved.

This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. Microsoft, Windows, Windows Server, and Microsoft Operations Manager are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.