Tristan's blog: [OpsMgr 2007R2] My best practice for creating overrides

After more that 16 months using SCOM, I've seen a lot of things concerning the configuration of the overrides on MPs and I think this post can be usefull to explain what to do to have a good way to apply overrides.

Microsoft has published a KB in 2007 - I've already post a word on this KB here but I would like to explain my feeling on how to do with overrides in a new post.

In order to have a proper view, you need first to define a naming convention :

For your Override MP

In my point of view, when you list the MP in the console (Administration pane) sorted by name, it's easier to retrieve OVR MP that have the same display name with a suffix that the MP to override.

For example :

Provided MP IDs : Microsoft.SQLServer.2000.Monitoring.mp

Provided MP display name : SQL Server 2000 (Monitoring)

Create an override MP with :

ID like Microsoft.SQLServer.2000.OVR

Display name like SQL Server 2000 (Monitoring)

/!\ Note : When you create an Override MP in the SCOM console, you're not able to keep the digit in the ID. It could bean issue when you have to create an override MP for a dedicated version of an application.

You can also create your override MP via SCOM console, export it and remove it from SCOM. Then open the exported XML file and change the ID.

Here is the view you'll have in SCOM if you apply this naming convention : simple and easy to retrieve the Override MP.

For the groups you'll create to apply overrides on

I use to create 2 groups by default in each override MP - One to enable all discoveries that target Computer/Agent and the second one to disable the discoveries that target Computer/Agent.

When discoveries are enabled by default in the provided MP, I use to disable them for the class to be able to only target computer/agent I want to monitor.

For having a good view of overrides groups in the console, applying a naming convention will help you as for the override MP naming.

For discoveries, you can use :

OVR - MPName - Enable Monitoring >> to enable discoveries

OVR - MPName - Disable Monitoring >> to disable discoveries (enforced) - use to be able to remove a monitored server by using the remove-disablemonitoringobject cmdlet

Short example : OVR - SQL Server 2005 - Enable Monitoring

For monitor or rules :

OVR - MPName - Rule or Monitor Name - OverrideThatIsDone

Short examples :

OVR - SQL Server 2005 - Collect Buffer Cache Hit Ratio Rule - Set Tolerance to 1

OVR - SQL Server 2005 - Service Pack Compliance Monitor - Disable

With a naming convention, you will see all overrides sorted by MP and you will be able to easily retrieve overrides apply to a MP with the search engine : Just search "SQL Server 2005" for example.

Be sure you create only one override MP by MP to override :

How to be sure that overrides are stored in the good overrides MP : You can do it within SQL or by creating a SCOM report.

You need also to use the AllOverrideView view that lists the properties below for each override :

      ,[Name]
      ,[CategoryId]
      ,[TargetId]
      ,[ParentType]
      ,[ModuleId]
      ,[ModuleName]
      ,[OverrideableParameterId]
      ,[OverrideableParameterName]
      ,[ContextId]
      ,[ContextObjectId]
      ,[Value]
      ,[Enforced]
      ,[ManagementPackId]
      ,[OverrideType]
      ,[MPIsSealed]
      ,[TimeAdded]
      ,[LastModified]

And execute a SQL query on this view to retrieve for each Sealed MP, what Unsealed MP is storing overrides and the overrides count.

Please have look on my post related to this : http://tetris38.blogspot.fr/2012/04/sql-scom-what-unsealed-mp-is-storing.html

Never store overrides in the "Default Management pack" :

First, Microsoft offers 2 way to disable a monitor or a rule. Never use the "Disable the Monitor/Rule" menu that will store the override in the default management pack and prefer use the "Override the Monitor/rule" menu and select "for the class" or "For the group". This will help you to store the override in the OVR MP that contains the group and it will ask you what OVR MP should store the override for the class.

Always override a monitor/rule for a group :

Applying override for a specific object is really not workable and It becomes very difficult to know which monitor is actually applied. The best is to create a group that can only be populated with the object type that is targeted by the rule/monitor to override. Once again, using SCOM console to create group does not allow you to choice the object type, or perhaps only when you populate the group at it's creation.. Have to check this. In my side, I prefer to create groups within the authoring console.

I would add that the groups used to override a specific rule or monitor should be populated by the same object type of the class where is implemented the rule/monitor.

Example : you have to create an override on the "Percentage of Committed Memory in Use" in the OS MP. This monitor is created in the class Windows Server xxxx Operating System . You can of courses create a group that contains Agent or Computer object and let the SCOM product detect the OS for the agent or server. It's in my mind more understandable to populate the group to override this monitor with Operating system object.

Cleaning up the default management pack:

The default MP is used to store specific information for the management group. The best practice is to NOT write any custom overrides or create monitors, rules or group to this MP.
Easy to write but the reality is other... sometimes, you can modifiy this MP by accident. The main issue is that dependency is created for this MP on any MP it refenrences when you store overrides or groups and we are not able to delete those MPs until the default MP is not clean up.

Here is also 2 links that explain how to remove dependencies on the default MP.

blogs.technet.com/momteam/archive/2007/05/03/removing-dependencies-on-the-default-management-pack.aspx

http://lab.technet.microsoft.com/en-us/magazine/dd627349

In short terms, to clean up the default MP, you must :