CHAPTER 5
Management packs

One of the first things customers realize when implementing Microsoft System Center 2012 Service Manager (if they didn’t know already from using Operations Manager) is the need to structure, name, and manage Service Manager management packs.

Most Service Manager configuration changes are contained, transferred, configured, authored, and customized through the use of management packs, so properly structuring and naming them are of the utmost importance before beginning to create new ones.

Management pack general guidance

The following guidelines can help you develop a standard and structured method for naming and combining modifications to create custom management packs. Note that these are only guidelines and not rules you must follow:

▪ Where possible, do not store anything in the Service Manager out-of-the-box (OOTB) unsealed management packs. Best practice is always to change these to custom management packs using the naming conventions detailed in the next section.

▪ When extending classes, keep extensions separate from form modifications so the form can be removed (deleted) from Service Manager without impacting the class or data records. Class extension management packs must be sealed as a prerequisite for transferring the data in them into the Data Warehouse.

▪ Form management packs must be sealed when they reference a class extension. Furthermore, the Form management pack also must be sealed for templates to be created from it.

▪ Be sure to mark or indicate management packs that include manual edits, either by name or description, so that it’s clear that the management pack was manually edited.

Management pack naming guidance

The following commonly used naming convention follows Service Manager management pack naming conventions. These examples are from Service Manager 2012.

▪ ServiceManager.IncidentManagement.Configuration.XML Unsealed Management pack for incident related configuration settings (OOTB lists).

▪ ServiceManager.IncidentManagement.Library.MPB Management pack bundle for all sealed incident management packs.

While not required, following a naming convention consistently can certainly be helpful in the administration and configuration of Service Manager. It is therefore recommended that a similar naming convention be adopted within your organization when you make changes to management packs and when you create management packs during configuration.

When you develop your own naming convention, a good naming convention for Service Manager might be CC.MMMMMMM.FFFFF.NNN.NC where:

▪ CC Company/organization (short two or three characters), for example MS for Microsoft.

▪ MMMMMMM Module (process), management function, service, or tech area. Some possible standard abbreviations are IR, CR, SR, PR, HumanRs, CustSvc, Network, Desktop, Server, and so on. You should standardize this list across your implementation and organization.

▪ FFFFF Function or purpose of modifications, for example email, notification, workflow, views, config, tasks, service, and so on. You should standardize this list across your implementation and organization as well.

▪ NNN Additional coding specific to the modification (optional).

▪ NC Add "NC" if the management pack has been modified via XML edit and may create issues if modified via the console. This way it can be immediately noted that the management pack is not to be edited or modified from the console. The suffix NC should be added to only the management pack display name and not to its internal name. It is more difficult (and sometimes impossible) to change the internal name of the management pack, and it will always be visible in the console while the internal name may not be.

Bundling modifications

Choosing between putting everything in a single management pack or using numerous management packs with individual modifications in each will not keep you from making bad decisions. Neither a single management pack nor thousands of management packs is the correct answer; the best approach is somewhere in the middle. Consider the following when deciding on the best approach:

▪ Who will be authoring the management packs? Will different groups have their own set of management packs to manage?

▪ How will modifications be promoted into the production environment? By release package? Larger multi-function modifications have greater risk in a release implementation.

▪ Some management pack modifications may require change management; others may not (adding list value).

Some types of changes that might be bundled into a single management pack include:

▪ Process roles

▪ Process role views by process (may require type projections)

▪ Process role tasks by process

▪ Technical, service, or process groups and queues

▪ Service level objectives, metrics, and calendars

▪ Module enumeration list items

▪ Service/support group form templates (dictate activities to be assigned)

▪ Service offering, its request offerings, service request and incident templates

▪ Workflow plus notification (must be together because they are stored together)

▪ Views that use a folder or a type projection that isn’t in a sealed management pack (must be located in the same management pack)

Some examples, then, of an incident class extension might include:

▪ MS.Incident.ClassExtension (sealed)

▪ MS.Incident.ClassExtension.Form (sealed, for use with new class extension)

▪ MS.Incident.ClassExtension.Configuration (unsealed, to be used for capturing configuration settings such as enumerated lists of the class extension)

Some items that should be in their own sealed management pack (not bundled) for use across the system might include:

▪ Type projections, so they can be referenced freely by any view in any management pack

▪ Custom images, to be referenced remotely by the views

▪ Folders, if you want to split up the views inside that folder between different management packs

Naming and bundling views and view folders

Views provide a way to limit, sort, group, and display work items and configuration items within Service Manager. Aside from forms, views is where most system users select, observe, and take action on information within Service Manager. Therefore, management pack names and display names may be different. While management pack names for views should follow naming standards as indicated earlier, views should have user-friendly names that make sense and are understandable to the audience acting within the processes.

Folders and type projections should be placed in sealed management packs so that type projections can be referenced by views and e-mail templates and don’t need to be duplicated elsewhere. Folders should also be in sealed management packs so they can store views from different management packs in that folder.

Naming and bundling templates

The number of templates increases as procedures mature in the Service Manager environment. As a result, ruthless standardization and normalization is recommended to reuse and modularize templates across as many groups as possible. However, there will be differences among teams because templates may also be edited by respective teams, rather than by Service Manager administrators, so the team's management packs will need to be imported separately when updated. For example, a management pack for all service requests and form templates to the network team might be MS.ServReq.Template.NetworkSupport.

Naming and bundling service offerings and request offerings

Service offerings and request offerings (which mimic a one-to-many relationship) should be contained in management packs aligned with a service offering management pack. For example:

▪ MS.Services.NetworkSupport Management pack for all internal service offerings and request offerings of the network team

▪ MS.Services.DataCenter Management pack for all internal service offerings and request offerings associated with data center services

The request offering and associated template must be in the same management pack. Although not required, containing the request offering and the service offering in the same management pack is best practice.

Naming and bundling groups and queues

Groups and queues are variously based on process, service, technology, and priority/service level. Some examples include:

▪ MS.Incident.Queues All incident queues defined

▪ MS.Incident.Groups All incident groups defined

▪ MS.Configuration.Groups All configuration item groups (e.g., would include where "Global Operators" would be stored)

Naming and bundling console tasks

Tasks are held in management packs separately from user roles. Store tasks in a sealed management pack by themselves, and name them based on the object they affect. For instance:

▪ MS.SR.ConvertToIR Console task to convert a service request to an incident.

▪ MS.System.ExportAllMPs Console task to export all management packs.

Naming and bundling notification templates and subscriptions

Since notification subscriptions are dependent upon notification templates, they should be maintained together by module. For example:

▪ MS.Incident.Notifications Notification subscriptions and templates for incident management

▪ MS.ServiceRequest.Notifications Notification subscriptions and templates for service request management

Sealing management packs

The following items should be in their own sealed management pack for the reasons indicated:

▪ Custom classes These should be sealed so you can:

• Report on new classes

• Build forms for new classes

• Create views, templates, notifications, and other configurations for new classes

▪ Custom forms These should be sealed so you can create templates from them. Also note that although you don’t have to build a custom form for a custom class since Service Manager will provide a generic form that contains all the properties, most of the time you’ll want or need to create your own.

▪ Class extensions These should be sealed so the new properties/relationships can be reported and so you can add them to a customized form.

▪ Existing form customizations These should be sealed so you can create templates for them.

▪ Type projections These can be referenced by views, e-mail templates, and other items. It is often best to let these be accessed by any management pack in the system so you don’t need to duplicate them.

▪ Management pack bundles When you bundle a management pack, you are adding a .dll, image, or other reference file along with the import. If you do not seal the management pack, you won’t be able to reference these resources from outside the management pack. This is most commonly an issue with images. If you bundle an image with an unsealed management pack, only that unsealed management pack can reference that image for use. Also, if you need to export that unsealed management pack to make changes to the XML, you cannot reimport it without re-bundling it with the image first. Therefore, it is best to import just a blank, sealed management pack bundled with the image, then reference that image in your unsealed view management pack.

▪ Folders Sometimes it makes sense to store a folder in a sealed management pack because it will let you store views from different management packs in that folder.

▪ Data warehouse extensions These need to be sealed to extend the data warehouse. If they are unsealed, the MPSyncJob won’t synchronize them with the data warehouse databases and your extensions will not be created.

Sealing management packs requires a strong name assemblies (SNK) file that contains a unique key pair consisting of a private and public key. For more information on SNK files, see http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx.

To seal a management pack you can use either the Authoring tool that comes with Service Manager or the FastSeal.exe tool. For more information on using the Authoring tool, see the step-by-step guidance at http://technet.microsoft.com/da-dk/library/hh495605.aspx. For additional information on sealing management packs and to download the Fastseal.exe tool, see http://blogs.technet.com/b/servicemanager/archive/2009/12/25/sealing-management-packs.aspx.

To use FastSeal you might first need to make some changes to the XML. If the management pack has a category, you will need to make sure you add a line for the public key token. Here is an example of a category for a management pack with a public key token:

<Category ID="Category.xyz" Value="EnterpriseManagement!XYZ">
<ManagementPackName>MS.Change.FormCustomization</ManagementPackName>
<ManagementPackVersion>7.0.65 5 5.0</ManagementPackVersion>
<PublicKeyToken>31bf3856ad364e35</PublicKeyToken>
</Category>

Sometimes you will have to use FastSeal, for example if your management pack breaks any of the Authoring tool's rules.

Updating a sealed management pack

If you have an unsealed version of a management pack, you can make changes to the management pack and then seal it with the same SNK file used to seal the original management pack. Make sure the version number of the new sealed management pack is greater than or equal to the existing sealed/imported management pack; the authoring tool will do this automatically when you seal it. Once this is done, you will be able to import the new sealed management pack and replace the existing sealed management pack. Note that Service Manager will still warn about potential data loss on import, due to the older version being installed.

If you don’t have the current unsealed management pack, but you have the SNK file that you used to seal the original management pack, you can export the sealed management pack from the console to generate an unsealed XML version of the management pack. You can then use the unsealed management pack to make changes, reseal it, and import it as explained above.

There are some cases when neither of these methods will work, for example with form customizations. With these types of management packs you must delete the existing management pack before importing the updated management pack. Note that anything stored in a management pack will be deleted when the management pack is deleted. This is especially important with regard to class extensions because any data stored in the class extensions will also be deleted and can't be recovered even if you reimport the management pack. That is why you must always keep forms and class extensions in separate management packs.

Versioning management packs

Management pack versioning can be challenging because it has to be done manually, and most users of Service Manager seem uninterested in doing this. The key to controlling the version numbers of management packs is defining what each segment of the version number means to your organization and then staying consistent with this. You can use industry standards for this purpose, but management packs are not source code, so coming up with your own definitions that are specific to Service Manager is usually a better option. A typical versioning model might look like this:

1. Major Follows version number of the Service Manager environment (7 for 2010 and 2012)

2. Minor Major changes (not really relevant since this number won’t change much for most clients)

3. Build Changes (add/remove functionality)

4. Revision Bug fixes

You can change the version of the management pack in the authoring console or by directly editing the XML. You will find <Version> in the management pack in the section named Identity as follows:

<Identity>
  <ID>ServiceManager.IncidentAssignmentChanges.Notification</ID>
  <Version>7.0.5244.0</Version>
</Identity>

Backing up management packs

It's always a good idea to keep a backup of all your work. As far as backup of management packs is concerned, the sample script below demonstrates how to back up all unsealed management packs in your environment. Note that this should not be used for disaster recovery purposes since this needs to be performed at the database level and therefore should not require reloading of management packs.

import-module smlets

# format directory name into yyyy-mm-dd format
$directory = get-date -uformat %Y-%m-%d

# Create Directory in MP backup path
New-Item -type directory -path "C:CustomMPBackup$directory"

# Store unsealed management pack into variable
$MP = Get-SCManagementPack | where {$_.Sealed -eq $False}

# Export unsealed management packs to the directory
$MP | Export-SCManagementPack -TargetDirectory "C:CustomMPBackup$directory

The above script can be configured to run on a daily basis as a task in the console and simply places all unsealed management packs into a subdirectory named with the current date.

Renaming management pack filenames

To have meaningful filenames, you might need to rename the filename itself and also the three instances where it appears in the XML. Be sure to delete the old management pack from your dev/test system before renaming it.

In addition to the filename itself, the following sections of the management pack will need to be in sync with the filename (which cannot have spaces, special characters, and so on);

▪ Manifest ID

▪ Category

The following example shows where you’ll need to change the management pack ID and Name multiple times when you rename a management pack:

<Manifest>
  <Identity>
  <ID>ManagementPack.76e90f21466e4b35b1e1544df625fa78</ID>
  <Version>7.5.1561.1</Version>
  </Identity>
  <Name>SendMail.Configuration</Name>
  ...

  ...

  <Categories>
  <Category ID="Category.26203af0ebac40b4a64f75905b4f0bee. . . . .>
  <ManagementPackName>ManagementPack.76e90f21466e4b35b1e1544df625fa78/>
  <ManagementPackVersion>7.5.1561.0</ManagementPackVersion>
 </Category>