This document is part of the Operations Manager Management Pack Authoring Guide. The Microsoft System Center team has validated this content as of Revision #2. We will continue to review any changes and periodically provide validations on later revisions as they are made. Please feel free to make any corrections or additions to this procedure that you think would assist other users.

For a basic overview of the contents of a management pack, see Structure of a Management Pack in the System Center 2012 - Operations Manager Authoring Guide.

Management Pack Schema

There is no performance advantage to either schema so there is no value in converting an existing management pack file to the new schema if it does not contain any elements specific to System Center 2012. Even if you create a new management pack, it is a best practice to create it using version 1.0 of the schema so that it can be used in either version of Operations Manager. If you want to include elements specific to System Center 2012, then you should create two management pack files. The first would be based on version 1.0 of the schema and contain all of those elements supported by Operations Manager 2007 R2. The second management pack file would be referenced by the first and contain only those elements specific to System Center 2012. See Management Pack References for more information.

Detailed knowledge of the schema is only required if the management pack is edited directly by using an XML editor. Each of the management pack authoring tools will either create a management pack file based on a particular schema or allow it to be selected by the author. The schemas supported by each of the authoring tools is shown in the following table.

Authoring Tool	Schema 1.0	Schema 2.0
Authoring Console	X
Visio Management Pack Designer	X
Visual Studio Authoring Extensions	X	X

When you export a management pack from the Operations Console, it will be formatted in the schema specific to that version of Operations Manager. Even you install a management pack using version 1.0 of the schema in a System Center 2012 Operations Manager management group, it will be exported in version 2.0.

Sealed Management Packs

When a management pack is sealed, it is converted to a binary file that has an MP extension. Either the sealed or the unsealed version of a management pack can be installed to a management group, but both cannot be installed at the same time.

Important: Sealing a management pack is not a valid strategy for hiding information from users. You can export any sealed management pack from the management group giving you full access to its XML code. A management pack should never contain sensitive information such as passwords.

Sealed management packs have the following characteristics:

The contents of sealed management packs cannot be modified. Changes must be made to the XML version of the file which is then sealed again with the same certificate. Such an update can only be installed in the same management group if the updated management pack is backward compatible.
Only sealed management packs enforce version control when an updated version of the management pack is imported into a management group. If the management pack is unsealed, the new version is always imported regardless of its backward compatibility. If the management pack is sealed, only a newer version of the same management pack can be imported and only if the newer version is backward compatible.
Management packs can only reference another management pack if the management pack that is referenced is sealed. This requirement ensures that a modification to a management pack cannot break other management packs that reference it. Because sealed management packs maintain version control, any referencing management packs ensures that updates to the sealed management pack are backward compatible.

When to seal a management pack

Management packs do not all have to be sealed. The behavior of sealed and unsealed management packs are identical once imported into a management group. The following criteria list when a management pack must be sealed:

Management packs that are referenced by other management packs must be sealed. You might want to create common elements such as groups or modules that are used by other management packs for different applications. The application management packs do not have to be sealed, but the management packs that contain the shared elements must be.
Any management packs sent to external customers must be sealed. In addition to ensuring that the customer cannot modify the contents of the management pack, it ensures that any modifications they make are made through overrides in a different management pack. This lets you provide updates to the management pack without affecting the customer’s modifications.
Management packs that are shared by multiple groups must be sealed. This ensures that each group makes any modifications through overrides in their own management pack. Each group cannot make modifications that affect the other group.

For the procedure to seal a management pack, see Sealing a Management Pack .

Management Pack Bundles

A management pack bundle is a collection of management pack files and other resources that are packaged into a single file with the extension .mpb. You import a management pack bundle into a management group using exactly the same method as importing a management pack.

Management pack bundles can only be used in System Center 2012. They cannot be installed in a System Center Operations Manager 2007 R2 management group. A management pack bundle can contain management pack files using the Operations Manager 2007 schema (version 1.0) since those management packs can be installed in a System Center 2012 management group. A single management pack bundle can contain a combination of management pack files using different version of management pack schema.

Reasons for Creating a Management Pack Bundle

Management pack bundles are required for management packs that use the System Center 2012 schema (version 2.0) and that include a binary resource such as an image. In management packs that use the Operations Manager 2007 R2 schema (version 1.0), images are converted into a character string and included in the XML of the management pack file.

Management pack bundles are also useful when you require a binary file to be deployed to the agent to support the functionality of the management pack. For example, you may have an executable that is called from the command line of a management pack monitor or rule. The executable file can be packaged into the management pack bundle in order to deploy it to the agent.

You can include multiple management pack files into a single management pack bundle for distribution. This has the advantage of requiring the user to import only a single file, but it can complicate updates since the entire management pack bundle must be updated even if an update is only required to a single contained management pack file.

Viewing the contents of a management pack bundle

There are multiple tools that can be used to view the contents of a management pack including the following:

MPViewer

MPViewer is a tool that allows you to view the contents of a management pack file. The latest version has been updated to include support for management pack bundles.

Test-SCManagementPack cmdlet

The Test-SCManagementPack cmdlet that is included with System Center 2012 Service Manager will list the management packs that are included in a bundle. Operations Manager does not include a cmdlet that will view a management pack bundle.

Microsoft.EnterpriseManagement.Packaging Namespace

The Microsoft.EnterpriseManagement.Packaging namespace in the System Center 2012 Service Manager SDK allows you to create and manage management pack bundles. This namespace is installed on System Center 2012- Operations Manager management servers and on any computer with the Operations Console. You can use Windows PowerShell to write a script that will inspect and list the contents of a bundle. An example of such a script is shown below.

#List contents of management pack bundle.

param ($filePath)

#Constants

$nsPackage =

"Microsoft.EnterpriseManagement.Packaging"

$classFactory  =

"Microsoft.EnterpriseManagement.Packaging.ManagementPackBundleFactory"

$classFS  =

"Microsoft.EnterpriseManagement.Configuration.IO.ManagementPackFileStore"

#Assemblies

$asPackage = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Packaging")

$bunFactory = $asPackage.GetType($classFactory)

#Create bundle reader and read mpb

$bunReader = $bunFactory::CreateBundleReader()

$fs = new-object $classFS

$mpb = $bunReader.Read($filePath,$fs)

#Step through each mp in the bundle

foreach ($mp in $mpb.ManagementPacks) {

#Check if mp is sealed

if ($mp.Sealed) { Write-Host

"Management pack file: "


$mp.Name

" (Sealed)"

else            { Write-Host

"Management pack file: "


$mp.Name

" (Unsealed)"

#Get the mp resources and their size

$streams = $mpb.GetStreams($mp)

if ($streams.count -gt 0) {

foreach ($stream in $streams) {

foreach ($resourceName in $stream.keys) {

Write-Host

"- Resource: "


$resourceName

" ("


$stream.Item($ResourceName).Length

")"

}

else {

Write-Host

"- No resources found."

}

Defining a Resource

For a resource to be included in a management pack bundle, it must have a Resource element in the Resources section of the management pack XML. The following table lists the different types of Resource elements.

Resource Type	Description
Assembly	Assemblies that do not get deployed to agents such as templates and widgets.
DeployableAssembly	Assemblies that get deployed to the agent.
DepolyableResource	File resource that gets deployed to the agent.
Image	Image resource.
ReportResource	Report resource.
Resource	File resource that doesn’t get deployed to the agent.

You must define a Resource element for each resource that a management pack will use. VSAE has a template for an Assembly resource, but you must add any others with a management pack fragment. The following tables lists the attributes of the different kinds of Resource elements.

Resource, Deployable Resource

Attribute Name	Description
Accessibility	Identifies whether the resource should be available to other management packs.
Comment	Optional comment describing the resource.
FileName	The name of the file.
HasNullStream	Should always be set to False.
ID	An identifier for the resource.

Assembly, Deployable Assembly

Attribute Name	Description
Accessibility	Identifies whether the resource should be available to other management packs.
Comment	Optional comment describing the resource.
FileName	The file name of the assembly.
HasNullStream	Set to True only if the assembly is already installed on client.
ID	An identifier for the resource.
QualifiedName	The qualified name of the assembly including the culture, public key token, and version.

Image

Attribute Name	Description
Accessibility	Identifies whether the resource should be available to other management packs.
Comment	Optional comment describing the resource.
FileName	The name of the image file.
HasNullStream	Should always be set to False.
ID	An identifier for the resource.

ReportResource

Attribute Name	Description
Accessibility	Identifies whether the resource should be available to other management packs.
Comment	Optional comment describing the resource.
FileName	The name of the file.
HasNullStream	Should always be set to False.
ID	An identifier for the resource.
MIMEType	The type of resource.

Examples

Following are examples of different Resource elements:

<DeployableAssembly

ID="Res.MyApplication.MyAssembly"

Accessibility="Public"

FileName="MyApplication.MyAssembly.dll"

HasNullStream="false"

QualifiedName=

" MyApplication.MyAssembly MyApplication.MyAssembly,
 Version=1.0.1000.0, Culture=neutral, PublicKeyToken=43ef5856dc534f28"

/>

<DeployableResource

ID="Res.MyExecutable"

Accessibility="Internal"

FileName="MyExecutable.exe"

HasNullStream="false" />

<Image

ID="Image.MyClass.DiagramIcon"

Accessibility="Public"

FileName="MyClass.DiagramIcon"

HasNullStream="false" />

<ReportResource

ID="Res.MyApplication.MyCustomReport"

Accessibility="Public"

FileName=" MyApplication.MyCustomReport "

HasNullStream="false"

MIMEType="application/octet-stream"/>

Creating a management pack bundle

There are multiple methods for creating a management pack bundle including the following:

Visual Studio Authoring Extensions

Visual Studio Authoring Extensions is the typical tool that is used to create management packs that are included in a management pack bundle. Resources to be included in the bundle can be added to the management pack project, and the tool can be used to create the management pack bundle itself. The VSAE though has the following limitations:

VSAE cannot be used to add multiple management packs to a management pack bundle.
VSAE can only bundle management packs based on System Center 2012 schema. It cannot include a management pack based on System Center 2007 R2 schema.

When you perform a build with VSAE of a management pack based on System Center 2012 schema, a management pack bundle is automatically created. It will include any resources that have a Resource element and that have been added to the project with their Build Action property set to Embedded Resource.

New-SCSMManagementPackBundle Cmdlet

The New-SCManagementPackBundle Windows PowerShell cmdlet that is included with System Center 2012 – Service Manager can be used to create a management pack bundle with multiple management pack files and included resources. Note that System Center 2012 – Operations Manager does not include this cmdlet, but it can be used to create a bundle for Operations Manager

Microsoft.EnterpriseManagement.Packaging Namespace

The Microsoft.EnterpriseManagement.Packaging namespace in the System Center 2012 Service Manager SDK allows you to create and manage management pack bundles. This namespace is installed on System Center 2012- Operations Manager management servers and on any computer with the Operations Console. You can use Windows PowerShell to write a script that will create a bundle that includes multiple management pack files and included resources. An example of such a script is shown below.

#Create management pack bundle

#Includes one or more management pack files and their resources.

#Resources must be located in the same folder as their management pack file.

param (

    $mpFiles, #List of management pack files to include in the bundle

    $mpbFile #Name of the bundle to create

    )

#Constants

$classMP   ="Microsoft.EnterpriseManagement.Configuration.ManagementPack"

$classMPResource ="Microsoft.EnterpriseManagement.Configuration.ManagementPackResource"

$classSignature ="Microsoft.EnterpriseManagement.Packaging.ManagementPackBundleStreamSignature"

$classFactory ="Microsoft.EnterpriseManagement.Packaging.ManagementPackBundleFactory"

$ioOpen = [System.IO.FileMode]"Open"

$ioRead = [System.IO.FileAccess]"Read"

#Assemblies

$asCore = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")

$asPackage = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Packaging")

$empty       = $asCore.GetType($classSignature)::Empty

$typeMP = $asCore.GetType($classMP)

$typeMPResource = $asCore.GetType($classMPResource)

$bunFactory = $asPackage.GetType($classFactory)

#Setup generic method to read resources from management pack file

$method = $typeMP.GetMethod("GetResources")

$genericMethod = $method.MakeGenericMethod($typeMPResource)

#Create the bundle

$bundle = $bunFactory::CreateBundle()

#Read through management pack files

foreach ($mpFile in $mpFiles) {



    #Add the mp file to the bundle

    if (Test-Path $mpFile) {

        Write-Host"Adding management pack file" $mpFile

        $mp = new-object $classMP $mpFile

        $bundle.AddManagementPack($mp)



        #Get the resources from the mp

        $resources = $genericMethod.Invoke($mp,$null)

        if ($resources) {

            $resources | %{

                #Look for resource file in same folder as mp

                $filePath = Join-Path (Split-Path $mpFile) $_.FileName

                if (Test-Path $filePath) {

                    #Get the stream for the resource and add to bundle

                    Write-Host"- Adding resource: " $filePath

                    $stream = new-object io.filestream $filePath,$ioOpen,$ioRead

                    $bundle.AddResourceStream($mp,$_.Name,$stream,$empty)

                }

                else {

                    Write-Host"- Resource not found: " $filePath

                }

            }

        }

        else {

            Write-Host"- No resources found."

        }

    }

    else {

        Write-Host"Management pack file not found: " $mpFile

    }

}

#Create a writer for the bundle and save to current folder if path not specified

$bundleWriter = $bunFactory::CreateBundleWriter(${PWD})

$mpbFinalPath = $bundleWriter.Write($bundle,$mpbFile)

Write-Host"Created bundle: " $mpbFinalPath

Referring to resources

Elements in a management pack that use a resource may require the path to that resource on the agent. This path can be retrieved with a $FileResource variable. The following example shows a command executor write action that runs an executable that is included as a resource in the management pack. The ID of the resource is Res.MyApp.exe.

<WriteAction ID="WA" TypeID="System!System.CommandExecuter">

<ApplicationName>$FileResource[Name="Res.MyApp.exe"]/Path$</ApplicationName>

<WorkingDirectory></WorkingDirectory>

<CommandLine></CommandLine>

<TimeoutSeconds>300</TimeoutSeconds>

<RequireOutput>true</RequireOutput>

<Files />

</WriteAction>