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 :
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.
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.
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.
In short terms, to clean up the default MP, you must :
- Export the default MP - create a backup
- Identify the rules, monitor, group that have been created in it
- For each rule, monitor or group, recreate them in an other MP
- Delete them from the default MP
- Delete associated Displaung
- Identify the overrides that are stored in it
- For overrides recreate them in an other MP
- Delete them from the default MP
- Identify the views that have been created in it
- Each view must be recreated in an other MP
- Delete them from the default MP
- When step 1, 2 and 3 is done, delete all un-used references.
- Re-import the Default MP
Hope I'll add some other things here..... don't hesitate to comment !
New information added on 4/24/2012
Application models
This posting is provided "AS IS" with no warranties.
