This is the first post in a new series based around the basics of Microsoft Operations Manager (OpsMgr), providing entry level information on the core concepts, processes, methodologies  and techniques to assist those who are perhaps looking to further their knowledge of OpsMgr or are new to the product.

I know this is a strange place to start, however there is method to my madness. As a consultant, I am engaged by customers to not only implement OpsMgr, but also undertake health checks and other maintenance tasks on existing implementations. On far too many occasions, I have found that whilst the OpsMgr administrator(s) have constructed a well tuned and functional environment, they often fail to follow some very simple “best practice” policies that can potentially save them considerable time in the future.

One of the most common is a lack of policy around the Creation of Overrides. Rather than re-creating the wheel, you will find a link at the end of this post to an excellent Microsoft Technet article that covers Override Best Practice. There are 2 that I want to highlight here (see below), as these are often overlooked and are key to maintaining a healthy, manageable OpsMgr environment.

Store overrides in a separate management pack

 For each management pack that you use in System Center Operations Manager 2007, create an additional management pack in which to store overrides. For example, after you import the Active Directory management pack, create an Active Directory Override management pack. Then, store any overrides that you configure for the Active Directory management pack objects in the Active Directory Override management pack.

This should be a given, and is in most organisations. I know some will argue that maintaining X number of Custom Management Packs clutters the console and increases complexity. I’m not really sure how. A failure to follow this basic principal will ultimately lead to the following scenario:

You need to delete a Management Pack from your environment, however looking at the dependencies, you can see that Overrides exist in multiple MP’s, including the Default Management Pack. This will inevitably mean either a significant amount of lost time hunting down those rules and monitors, or other measures having to be taken.

All of this can be avoided of course, by simply creating a Custom MP for *EVERY* MP you import. A point of clarification though, using Active Directory as an example. You do not need to create a custom MP for Discovery and Monitoring, however I would recommend a custom MP for each version. This gives you the ability to easily remove (for example) the Active Directory 2000 (Monitoring) MP when no longer required.

Do not use the Disable command in the Overrides menu to create an override to disable monitors, rules, or object discoveriesWhen you want to disable a management pack object, do not use the Disable the ObjectName command on the Overrides menu. Instead, click the Override option to override the object. Then, follow these steps:

1. In the Override Properties dialog box, click to select the Override check box that corresponds to the Enabled parameter.
2. In the Override Setting column, click False.
3. In the Select destination management pack list, click the appropriate management pack in which to store the override.

Note This method lets you specify a management pack in which to create the override. However, if you click the Disable the ObjectName command, System Center Operations Manager 2007 creates the override in the Default management pack.

This one is not as clear cut and I have seen examples of this in EVERY environment I have been in. For me, Microsoft either need to include the ability to choose a custom MP when disabling from the Overrides menu, or remove the feature all together. All to often this has caused confusion and headaches for the OpsMgr Admin.

Here is the link to the Technet article… http://support.microsoft.com/kb/943239

As always, if you have found this article helpful, or would like to provide feedback, please leave a comment.