Help! My company has written their own custom management packs and they are sealed but we can’t find the key or the unsealed versions of the management packs we have written! If this is you this blog post may be your BFF very soon. This situation can quickly become extremely challenging to work through as a custom written sealed management pack may reference another custom written sealed management pack and an unsealed management pack may also refer to one or more of the custom written sealed management packs. The result is in one word: Confusing. If I were to explain it two words it would be: Confusingly ugly.

If you are reading this and you know where your key is that you sealed them and where you original management packs are – good for you. Stop reading now and go document it somewhere. My recommendation is to create a SharePoint document library with the MP’s, sealing keys and other important information. Once you have made this document library, create a web page view for it in Operations Manager at the top of the monitoring pane so it’s easy to find all of this and you will avoid having to read the rest of this blog post in the future.

If however you are in this situation or you want to understand what’s involved, the high level process we will discuss in this blog post are as follows:

  1. Exporting the custom management packs that you have in your environment which are sealed to an unsealed (XML) version.
  2. Resealing your management packs with a new key.
  3. Optionally how to create an MP repository for all MP’s that Microsoft provides and are available in your environment.
  4. Changing custom management packs which depend on the newly re-sealed MPs
  5. Re-importing the newly re-sealed management packs

Let’s start with an explanation of the error that we were seeing when attempting to add custom written non-sealed management packs.

The graphic below shows how the management packs should work in terms of sealed and unsealed management packs and their dependencies.

Sealed MPs.png

If we re-seal the management packs (the two Custom Sealed MP’s on the left) with the new key, the custom unsealed management packs are no longer finding what they are looking for because the unsealed management pack while it has the same name and version it doesn’t have the same public key token so it’s not really there even though it looks like from the Operations Manager console it should work fine.

 

 

Wisdom from Vincent:

When I was figuring out how to tackle this issue I reached out to several folks including Vincent who works at OpsLogix (I figured if I have a tough MP question, go to a solid MP developer). His insights were right on target and between his thoughts and my friend Larry I was able to put this all together. Vincent’s thoughts are below:

When you seal a management pack with a snk key, a public key token is calculated. Now when you seal a management pack with a different snk key, the calculated public key token will also change.

If you make a management pack dependent on a sealed management pack, the reference to the sealed management pack also includes the public key token.

In the case of your client I think you should seal the management pack(s) with the new key. Then get the public key token for the management pack(s) that are sealed with the new key, and use/change these in the reference of the dependent management packs.

To see other good stuff from Vincent De Vries see his blogs at http://blog.opslogix.com and http://mpalchemy.wordpress.com!

 

What do we see if we attempt to re-seal these management packs and use them?

What we saw was when we attempted to add one of our custom written unsealed management packs which referenced a custom sealed management pack it would error and say that the management pack was missing. This was still generating an error even after we verified that the custom sealed management pack was loaded in the environment and did have the correct version.

The screenshot below shows that the custom sealed management pack is loaded and the version is correct.

Again, while it looks like the correct dependent management pack is loaded it actually is not due to the key difference.

 

Exporting your custom sealed management packs:

The following is a simple PowerShell script to export all custom built sealed management packs which are not from Microsoft: (if you have third party management packs in your environment which are sealed you will want to exclude them as well with another | where {$_.Name -notlike "*VendorName*"}

Operations Manager 2007: get-ManagementPack | where {$_.sealed} | where {$_.Name -notlike "*Microsoft*"} | where {$_.Name -notlike "*System*"} | where {$_.Name -notlike "*ODR*"} | Export-ManagementPack -Path "c:\mps\input"

Operations Manager 2012: get-scomManagementPack | where {$_.sealed} | where {$_.Name -notlike "*Microsoft*"} | where {$_.Name -notlike "*System*"} | where {$_.Name -notlike "*ODR*"} | Export-SCOMManagementPack -Path "c:\mps\input"

Copy all of your custom written management packs in XML form to the c:\mps\input directory so you know which ones you are going to reseal.

 

How to reseal your own custom built management packs with a new key:

Setting up the folder structure

First, on the RMS create a c:\mps folder and subfolders for c:\mps\input, c:\mps\key. You can also create c:\mps\mp c:\mps\output but these are optional. Also transfer a copy of the MPSeal, FastSeal and sn program as well as a sample PowerShell script provided from Jonathan Almquist’s blog (http://blogs.technet.com/b/jonathanalmquist/archive/2008/08/19/seal-a-management-pack.aspx). An example of one of the command script contains is shown in the creating the keys section of this blog post.

 

Creating the keys:

sn -k c:\mps\key\PairKey.snk

sn -p c:\mps\key\PairKey.snk c:\mps\key\PubKey

sn -tp c:\mps\key\PubKey

 

Sealing the management packs:

The old way to seal management packs is using mpseal so we’ll start there. See Jonathan’s blog post for details (http://blogs.technet.com/b/jonathanalmquist/archive/2008/08/19/seal-a-management-pack.aspx) but from a high level open a command prompt to the c:\mps directory, update the command script for the appropriate management pack names and let it run!

To seal the MP using mpseal:

mpseal c:\mps\input\myexportedMP.xml /I "c:\mps\mp" /Keyfile "c:\mps\key\PairKey.snk" /Company "Catapult" /Outdir "c:\mps\output"

 

With the release of FastSeal however this is much easier.

To seal the MP using FastSeal:

FastSeal c:\mps\input\myexportedMP.xml /Keyfile "c:\mps\key\PairKey.snk" /Company "Catapult"

FastSeal appears to remove the requirement to have all of the management pack dependencies downloaded and it is also much quicker to use the mpseal. For information on FastSeal see http://www.systemcentercentral.com/forums-archive/topic/mpseal-fails-with-the-management-pack-was-not-found-in-the-store/ and http://scsmnz.net/sealing-a-management-pack-using-fastseal-exe/.

An example of using FastSeal is shown below:

To download FastSeal go to Downloading FastSeal from this link: http://blogs.technet.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-03-30-25-60/FastSeal.zip.

 

Optional step: Downloading the Microsoft management packs:

The following step is only required if you use mpseal not FastSeal. This is a good trick when you need to edit management packs in authoring tools and you need the management packs which they are dependent on.

Log into the Operations Manager console, in the administration pane, management packs. Download management packs, searching with no criteria to download all available management packs. Download these to the c:\mps\mp folder.

NOTE: While this step may be overkill, but it’s a really good idea to have a full copy of the MP catalog available somewhere locally. When Microsoft updates a management pack any historical version of those management packs is no longer available online and there is currently no publicly available repository which stores all of the management packs with their various historical versions (though this would be a huge value add to the Operations Manager community if anyone wants to tackle it!)

IMPORTANT: As a last step, copy any available MP files from the Operations Manager installation media (in the ManagementPack folder) to c:\mps\mp. Do this last to override whatever else was gathered with what is on the installation media.

 

Changing custom management packs which depend on the newly re-sealed MPs:

Management packs which are written and are dependent upon the newly sealed management packs will require a slight alteration. The following blog post explains that this token information is made available when resealing a management pack.

http://systemcentertech.com/2012/09/24/locating-the-public-key-token-for-a-management-pack/

 

Or use the following once the management pack has been sealed:

To find the public key token using following command, after the sealing use sn –Tp <managementpack>. The command shows us the public key token which is what we need to make our changes in other management packs.

Edit each management pack which depends upon the original re-sealed management pack to change the public key token from the old public key token to the new public key token. A sample of the XML where the public key tokens are stored is shown below:

 

Re-importing the newly re-sealed management packs

After each custom management pack has been re-sealed and the unsealed custom management packs have been updated with the new public key token the test to validate that changes were done correctly only requires an attempt to import the management packs into Operations Manager. If there are issues with the public key tokens, they will error when you attempt to add them as they did at the beginning of this blog post.

 

Summary: While this process was not exactly a fun one it did prove to provide an interesting insight into how to handle this particular situation. So if you are in this situation (which I hope that you are not) I hope that you find this blog post helpful – if so post a comment to let me know!

Thank you to Matt Dowst for his help with the PowerShell script for management pack exports, Jonathan Almquist for his blog post on re-sealing management packs (http://blogs.technet.com/b/jonathanalmquist/archive/2008/08/19/seal-a-management-pack.aspx), Vincent at OpsLogix for his knowledge of this challenge, and Larry Brown for being an incredible sounding board, SME and friend to talk with on this topic.

 

Additional reading:

http://marthijnvanrheenen.wordpress.com/2012/12/06/scom-2012-sp1-sealing-a-management-pack-gives-error-could-not-load-management-pack-microsoft-systemcenter-library/

http://kevingreeneitblog.blogspot.com/2012/01/scom-2012-creating-your-very-own-custom_7617.html