As we’ve blogged about in the past, management pack can take a dependency on each other. To do this, you need to add a Reference element in the Manifest section of the management pack.
When a management pack (MP ‘A’) takes a references another management pack (MP ‘B’), you can then reference things in management pack ‘B’. For example, you could create a new class in MP ‘A’ which derives from a class in MP' ‘B’.
In order for an MP to be referenced (in this example above: MP ‘B’) the MP must be “sealed”. There are two primary reasons why the concept of “sealing” a MP exists:
1) Sealing a management pack turns an MP from an .xml file to a .mp file which is a binary representation of the management pack instead of a human readable XML file. This is not for the purpose of protecting intellectual property! It is solely to make it possible to digitally sign the file. Only binary files can be signed. Signing a binary assures the receiver that the file was signed by the provider of the file and that it hasn’t been modified since then.
2) Sealing a management pack also makes the management pack “read only”. Again, the primary reason for this is to prevent the file from being maliciously modified by someone in between the time the file was originally produced and when it was received by the customer. It also has the benefit of creating a certain file version with a specific set of contents in it which other MPs can depend on.
We will likely make this process of signing MPs part of the authoring console, but for now you can use this command line utility to seal management packs. It’s pretty simple – you can run fastseal.exe /? to see usage. Basically, you just point fastseal.exe to a .xml MP file and a .snk key file. It will generate a .mp binary file. The management pack import wizard in the administrator console or the cmdlet Import-SCSMManagementPack will accept either a .mp, mpb ( management pack bundle ), or .xml file.
Keep these rules in mind when dealing with MP references:
- A sealed management pack can reference another sealed management pack
- An unsealed management pack can reference a sealed management pack
- An unsealed management pack cannot reference another unsealed management pack
- A sealed management pack cannot reference an unsealed management pack
Or in other words… only sealed management packs can be referenced .
In closing… a few best practices regarding sealed/unsealed MPs…
1) If you are moving an MP from pre-production to production and you don’t want the configuration to be modified in production without going through a formal change request/test/release cycle, then you may want to seal the MPs before you put them in production.
2) If you are a partner building solutions that you are delivering to customers – you should seal most if not all of your management packs. This ensures a cleaner upgrade and also is a good security measure given the ability to sign the MPs.
3) Generally speaking, especially anything involved with modeling such as ClassTypes, RelationshipTypes, TypeProjections should be in a sealed MP so that they are not unexpected modified and so that they can be referenced by content in other MPs.
4) If you want to allow people to modify your MP after you have delivered it to them, then you should provide an unsealed version of the MP. For example, all of the MPs that I provide on this site are unsealed so that they can be read and modified by you as needed. Just keep in mind that if you put an unsealed MP out there you no longer have control over what is in that MP.
5) Management packs must be sealed in order to be syncronized from SCSM to the data warehouse. More information on the MP sync workflow here: http://blogs.technet.com/servicemanager/archive/2009/03/28/data-warehouse-anatomy-of-management...