Implications when using groups from a sealed MP for overrides

There was an interesting discussion about putting all groups for overrides in a sealed MP. At first, you might think it’s a great idea because you can reuse the same groups in different MPs and to be honest, when I started with SCOM 2007 several years ago, I was also tempted to design overrides and groups in such a way.

The Basics

The previously mentioned discussion also links to a blog post about where to put those groups in. This post perfectly describes the behavior of objects in unsealed MPs and the behavior of referencing objects in sealed MPs:

When you create a group, you save it to an unsealed management pack. However, an element in an unsealed management pack, such as a group, cannot reference an element in a different unsealed management pack, such as an override or a view. If you are going to use a group to target an override or scope a view, you must either save the group to the same unsealed management pack as the override or view, or you must seal the management pack that contains the group.

If you save the group to the same unsealed management pack as the override or view, you can only use that group for overrides and views that are also contained in that unsealed management pack.

If you seal the management pack that contains the group, you can reference that group from other unsealed management packs. However, you cannot easily change any group settings in the sealed management pack or add new groups to the sealed management pack.

Before you create any groups in Operations Manager, you should plan what groups you will need, the purpose each group will serve, and how to save the group in a manner that will allow it to be used for its intended purpose.

The above is valid for SCOM 2007, SCOM 2007 SP1, SCOM 2007 R2 and upcoming SCOM 2012 and it just hits the spot. When you read this you might still consider using all your groups for overrides from a sealed MP. I’m not saying that this is wrong. There are situations where you need to do that but in my experience these situations are very rare and very special. Anyway, to find out how to seal an MP, take a look at David Allen’s blog post:http://wmug.co.uk/blogs/aquilaweb/archive/2009/07/21/sealing-a-management-pack-in-r2.aspx

The Danger of having one single sealed MP for Overrides

Let me outline what implications this has, especially when you need to maintain those groups:

• Once you’ve sealed an MP containing groups, you cannot edit those groups in the operations console. You cannot change explicit membership, dynamic membership rules, etc.
• You cannot easily remove the sealed MP with your groups from your management group. To remove it you also need to remove all override MPs which are using those groups
• You need to be careful modifying the sealed group MP. You cannot change a group ID. This will break update compatibility. You also cannot easily remove a group from your MP. Adding new groups is no problem though.
• When you want to remove a group, you first need to export and edit all your override MPs which are referencing the group and remove all overrides which are using this group. Only after re-import of the modified override MPs, an update of the sealed MP without the group will work.
• You need to keep your unsealed MP around and when you want to modify your sealed MP you always edit the unsealed MP. Since you cannot have both installed in one management group, you most likely need to modify your MP in the authoring console. Creating and modifying groups in the authoring console is by far not that easy as in the operations console.
• Always increase the version number before you seal your modified MP and update your MP in the management group. If you do not do that, you might end up with groups not being updated, etc.
• As stated above, you cannot easily remove the sealed group MP, so you just update your existing one in the management group.

As you can see, sealing group management packs has its challenges.

Best Practice for Overrides

In SCOM you need to plan carefully and think about structuring your MPs, naming conventions and organization. As a best practice you should always create a dedicated override management pack for each sealed custom or 3rd party management pack.

For example, if you use the Active Directory management pack, create a management pack called “Active Directory Overrides” (or “Overrides – Active Directory” depending what naming convention you prefer) to store all the overrides in that management pack. It’s important to keep a consisting naming convention for the MP naming as it will help you later to find your stuff. Create those override MPs for each sealed MP you import – best would be right after the import! Microsoft is even considering to ship their MPs with empty override MPs from the start which may help users to follow this pattern right away.

Most sealed MPs have already their own groups (based on application discovery) which can be used for your overrides. If you need custom groups for Active Directory overrides, you need to create them in the same override MP as the overrides (see “The Basics” above). At first this might let you think that this is counter productive. The group you create in this MP will not be available in other unsealed MPs. And you’re right if you think “what if I need the same group in another override MP because these are the same servers?”. Yes. you need to create the same group again in the other override MP – but this is a good thing! Consider, you want to remove an MP permanently because you do not have the application anymore. Having the application MPs and overrides MPs stringed together allows you to easily remove or update an application MP in your management group – without affecting anything else. It’s a self-containing set of objects, completely independent from the other MPs.

This makes maintenance and lifecycle management of applications and management packs much more easier!

And one more thing: DO NOT EVER USE THE DEFAULT MANAGEMENT PACK! (I think this is already a well known fact…)