SCOM – Why we create management packs for overrides, how it affects targeting and more…

1.  Overrides from sealed MPs create dependencies/references in the unsealed MP: 

For example, I have created a new unsealed management pack named TEST which contains overrides from the SQL Server 2012 MP.  Configuring these overrides creates a reference in the TEST MP for the SQL Server 2012 MP.  To test, I navigate to the “Administration” view and find the SQL Server 2012 MP in the “Management Packs” section and attempt to delete it, resulting in the error below:

Pic1

When you target an override for a rule/monitor from a sealed MP to a group or object in a new unsealed override MP, a dependency is created.  This dependency is created because an entry for the sealed management pack is added to the “References” section (amongst other possible locations) in the unsealed MP xml code  This dependency makes it so that you cannot delete the sealed MP without deleting or editing the xml of the unsealed MPs that contain these reference dependencies.

See the image below for the actual code created in the TEST management pack (see below). We can remove the reference to resolve this issue is the override that caused the reference has been deleted.

Pic2

2.  Targeting for custom rules/monitors:  

When creating a custom rule/monitor, you can only target groups that were created in the same MP, assuming it is unsealed.  When configuring the rule/monitor, groups in other unsealed MPs will not even appear in the “Target” search!  The workflow must target a group in the same unsealed MP, or a group in another sealed MP (all Microsoft MPs are sealed).

In the first scenario, I am creating a custom monitor named “Test Monitor” in the TEST MP.        In addition, I created a new group called “TEST GROUP”, also in the TEST MP.  Notice on the “Select Items To Target” page that TEST GROUP is available for targeting.

Pic3

In the second scenario, I am creating the same custom monitor with the intention of targeting the same group, only this time I will choose another MP named “Bad Test” (Yes, I am incredibly original!).  On the “Select Items To Target” page, notice that “TEST GROUP” is not an option for targeting.  Huh!?  This is because the group was created in an unsealed MP, and therefore can only be targeted by workflows from the same unsealed MP or a sealed MP.

Pic4

Just to confuse things a bit, you CAN target a group in an unsealed MP to override a rule/monitor contained in a sealed MP.  For example, I can target my “TEST GROUP” for an override from the SQL 2012 MP (see image below).  However, best practice is to only use ONE management pack per sealed technology MP to avoid creating a code mess from too many dependencies and comply with best practices.

Pic5

To further expand on this point, I have worked with engineers that wanted to migrate hundreds of MPs from SCOM 2007 R2 to SCOM 2012 during a side by side migration.  Normally this would be a relatively easy process, but due to the mess created from targeting overrides to a large amount of random unsealed MPs and the default MP we had to spend hours cleaning up references and code to avoid migrating misconfigured and unused workflows.  In my opinion it’s worth the small amount of work up front  to prevent getting stuck in a messy situation down the road.

3.  Organization:  

It is simply easier to organize overrides, custom rules/monitors and groups into MPs based on application.  If I want to create custom workflows to target a particular application, I will create a management pack where I will store all of my workflows, overrides, groups, etc.  If the application is retired or no longer needs to be monitored, I can simply delete the MP(s).  Additionally, I will be able to better track where my monitoring workflows reside, which can be tough.

4.  Workaround – Groups in sealed MPs: 

You can target a group in a sealed MP from any workflow whether it is contained in a sealed or unsealed MP.  This provides a possible a workaround by creating a sealed MP containing the groups we need to target most often.

Let’s say that I have a solid naming convention and want to create dynamic groups of servers based on DNS Host Names that I can target from any workflow, in any MP, regardless of whether it is sealed or not.  This certainly can be done!  To accomplish this, I create a custom MP called “Groups”.  In my “Groups” MP, I create a dynamic group of “Windows Computer” objects for each of my applications or other requirements.  I then export the “Groups” MP, and run the MPSeal.exe utility to seal the MP (see below).  After re-importing the “Groups” MP, I can now target all contained groups from any workflow in any unsealed MP, without creating dependencies/references!

Great post about using the MPSeal.exe utility:  http://blogs.technet.com/b/jonathanalmquist/archive/2008/08/19/seal-a-management-pack.aspx

Advertisements

One thought on “SCOM – Why we create management packs for overrides, how it affects targeting and more…

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s