The following best practices for working with management packs are described below:
- Group customizations into separate management
- Seal model management packs.
- Create your own custom management packs when
- Export custom management packs.
- Work across multiple management groups.
Group Customizations into Separate Management Packs
Group customizations into separate management packs as follows:
- Store model extensions and presentation
extensions in separate management packs.
It is recommended that you store the following objects in a model management pack:
- New classes and class extensions, including
properties and corresponding icons
- New lists
- Combination classes
- Child EnumerationValues that should not be
- Forms for viewing and editing objects of the
defined classes, and the respective assembly resources
- New classes and class extensions, including properties and corresponding icons
- Group customizations by the solution that you
are developing. For example store incident management-related
customizations and settings separately from change
management-related customizations and settings.
- Group customizations based on usage
considerations. For example, store customizations that you need to
test and deploy as a unit in the same management pack.
Seal Model Management Packs
Seal management packs that contain base classes and other model objects, on which other definitions in other management packs depend on. Sealing a management pack prevents it from being modified. Also, it is important to seal a management pack so its definitions are synchronized with the data warehouse database during import. This allows you to later add customizations (in another management pack) such as presentations that depend on the base objects from the sealed management pack.
Create Your Own Custom Management Packs When Possible
Some of the solution-specific, pre-imported, unsealed management packs (“Configuration” management packs) contain customizable elements for the specific solution. In some cases you must store your customizations in those pre-imported management packs to ensure that the management pack adheres to the dependency rules. For example, templates that use list values defined in a “Configuration” management pack must be stored in that same management pack. This is because the list values that are used are defined in another unsealed management pack and dependency on unsealed management packs is not supported.
However, whenever possible it is recommended that you create new management packs to store your customizations. Creating your own management pack simplifies transportation of the management pack, and can simplify an upgrade.
For example, when you extend a solution by adding objects such as views, tasks, groups, queues, and form customizations-objects that have dependencies on other objects that are defined in sealed management packs. In this case, you should create a new management pack to store the custom objects.
Export Custom Management Packs
Periodically, export your customized management packs from the Service Manager database, and store the backup file on a hard drive. This will ensure that custom management packs are synchronized with the management packs in the Service Manager database, and will also allow you to restore the customizations to the Service Manager database if needed.
Working Across Multiple Management Groups
Ensure that you do not make different customizations to the same management pack in different management groups. To implement customizations across multiple management groups, you can import the same customized management pack in the other management groups.
For example, if you want to have the same enumerations in multiple management groups, you need to make the change in one management group, and then copy the custom management pack to the rest of the management groups. That way the version and identify of the management pack is identical in all the management groups.