SCOM 2012 RC – Side-by-Side Migration Phase 4 – Importing unsealed Management Packs

Important! 2012 RC is not supported in a production environment unless you are in the Microsoft TAP program for Operations Manager. This blog post is to be considered an experience report, and not an official guideline.


  • Intro
  • Running Inventory
  • Preparations
  • Cleaning up Inventory
  • Export Management Packs marked as ExImport
  • Verifying MonitoringObjectIds of Overrides targeting Instances and Groups containing explicit members
  • Import Management Packs marked as ExImport
  • Import all other unsealed Management Packs
  • Verifying Management Pack inventory
  • Configuration Changes


Note: This is a rough overview on my personal experience for this task and due to the nature of the subject it mustn’t be applicable to other environments. You might find a few ideas though that might be helpful.

This task is a bit chaotic due to the nature of unsealed Management Packs and I can’t go as much into detail as I’d want to simply because this is different in every environment and for every Management Pack. Migrating unsealed Management Packs from one Management Group to another isn’t simply done by exporting all of them and importing them into the other. While this would be theoretically possible it isn’t recommended due to a few pitfalls:

  • Not all unsealed Management Packs are mine, some of them are from Microsoft such as the Default Management Pack which already exists in the new environment
  • Groups with explicit members and Overrides targeting instances instead of classes – they target MonitoingObjectIds which might not exist or are different in the new environment
  • Management Packs which are used for customizations may change after I have moved them into the new environment (new Overrides, changes to Group Members)

Due to these dependencies I need to find a process that helps me organizing this task while keeping it dynamic enough to adapt.

Note: At this point all sealed Management Packs are already available in the new environment. Covered in my last blog post: SCOM 2012 RC – Side-by-Side Migration Phase 3 – Installing sealed Management Packs

All scripts mentioned throughout this blog post are available in the attached zip file as a reference.

Previous Blog Posts on my Migration

Logical steps Overview


Running Inventory

What I want to do is getting a list of all unsealed Management Packs and determine how I expect them to be moved into the new environment.

For this I wrote a script (UnsealedMPInventory.ps1) that gives me a list of all unsealed Management Packs  with their version number and a note which is then exported into a text file (C:\temp\unsealedmanagementpacks.txt).



This list is essential for all tasks below.


Most Management Packs will be exported and imported into the new environment except for a few which are obsolete or which have configurations relevant only to the old environment.

Keep in mind that most rules will still work the way they did in the old environment, this can be problematic in some cases, for instance Active Directory Integration Rules, Notification Subscriptions or Configuration Automations you built yourself.

The only rule of thumb I can provide is:

  • Know what your Management Packs are doing
  • Be sure that you want them to do it in the new environment

Cleaning up Management Packs

In some cases you might have a Management Pack that contains a reference that is not available anymore in the new environment or that contains rules/overrides that aren’t relevant in the new environment. In this case, you will have to clean up the Management Pack in some XML Editor once you have exported it. This is a rather complex subject that would deserve its own blog post and I can’t cover that here.

Jonobie Ford wrote a blog post on how to remove references in the Default Management Pack (would apply to other unsealed MPs too):

You might also have the same dependency issue with the Microsoft.SystemCenter.SecureReferenceOverride Management Pack which is covered here:

As for removing Rules/Monitors/Overrides – just a quick overview:

  • Create a Backup of the MP
  • Identify the Rule/Monitor/Override you want to remove
  • Find its Id in the MP
  • Remove all referencing objects to that Id from the MP
  • Remove the Rule/Monitor/Override
  • Try to import it – in case you missed a reference or you malformed the XML you will receive an Error when importing the Management Pack occasionally helping identifying what the problem is

Unsealed Microsoft Management Packs

If you have a fresh SCOM 2012 Installation you will notice that there already is a Default Management Pack, as well as a Notifications Internal Library (Notification Subscriptions are stored here) and a Microsoft.SystemCenter.SecureReferenceOverride (used for some RunAs  Profiles).
Can you overwrite them by exporting the one from 2007 and importing them to 2012? Yes. Will it work? I wouldn’t bet on it.

Note: I asked Microsoft what happens during the Upgrade from 2007 to 2012 with the Microsoft Management Packs, and according to them the upgrade upgrades the schema of the Management Packs. All objects created in them should still work in 2012 therefore.

Note: I tested what happens when you import a 2007 Default Management Pack or Notification Internal Library in a 2012 environment, they seemingly still work but some rules or objects that are targeted might not exist anymore. I recommend you really review these Management Packs and calculate if it wouldn’t be more wise to start with them from zero.

Default Management Pack

In SCOM 2007 the Default Management Pack is where one might have dropped all of his custom Monitors or Rules as when you create one, it suggests that you store it in there. Aside from that, if you have Active Directory Integration, all rules for it are stored in here as well.
I don’t use the Default MP for any customizations but I have AD Integration rules stored in it. What happens when I import them into 2012? They will work and will try to configure the Service Connection Point in AD but with the name of the new Management Group… for which there is no container yet therefore it will only throw errors.

I don’t want the new environment to use the old AD Integration rules, thus I have 2 options: Remove the Rules, don’t import the Default MP.
Since I only have AD integration rules in it I will not migrate it.

Notifications Internal Library (in 2012 it still has the version 6.1.7221.0)

In this Management Pack, all configurations regarding Subscriptions are stored. This includes Subscribers, Channels and how the messages are formatted.

While the old rules should still work properly (no warranties from my side), you have to keep in mind that there were some changes in how Notifications are sent –

According to this the mails will be sent by any server that is part of the Notification Resource Pool. However, my own investigations have shown that when you create new rules in 2012 they still target the Notification Subscription Server class and the only instance in there is RMS Emulator Server.

Also when I set the Notifications Resource Pool to exclude the RMS Emulator, mails are still sent by it.

Bottom line:

As far as I can tell Notifications should still work the same as they did in 2007 R2. When you export the Notifications Internal Library and import it you will find all Channels/Subscribers/Subscriptions in 2012.

Since I only have a hand full of Subscriptions I will walk down the secure path and create them by hand in the new environment instead of migrating the Management Pack.

The behavior regarding the Notifications Resource Pool might only be applicable to 2012 RC.

This Management Pack contains Secure Reference Overrides. Now what are Secure Reference Overrides (let’s call them SORs)?

SORs are not configurations for RunAs Profiles relatively the association of a RunAs Profile and a RunAs Account. It’s used for Overriding these settings.

The only Overrides I could find in that MP were from when I changed the account with which AD Integration rules are distributed, and when I discovered Unix Agents using a specific account. Therefore these overrides seem to be created by some of SCOMs wizards.

Unfortunately I couldn’t find any proper article on this subject explaining when this Management Pack is used. Maybe someone else can enlighten us?

I only have 4 Overrides in there, 2 for AD Integration and 2 for some Unix workflows – and since I don’t need these in the new environment I won’t migrate the MP

Client Monitoring Overrides Management Pack (in 2012 it still has the version 6.1.7221.0)
The Client Monitoring Overrides Management Pack is used for customizations for AEM rules (Agentless Exception Monitoring). Since I don’t use that feature I can’t say anything about this Management Pack – only that I won’t migrate it.
Other Unsealed Management Packs
This perfectly depends on what the Management Pack is doing and if you still want it to do the same thing in the new environment.

I know what most of my unsealed Management Packs are doing as our in-house MPs are all sealed, and unsealed Management Packs are only used for Overrides and a few specific rules and monitors.
Since I don’t know what all of them are doing I will simply export all of them to some location:
#2007 Shell
Get-ManagementPack | where {$_.Sealed –eq $false} | Export-ManagementPack –Path “C:\temp\review”

And then I go through each Management Pack using some XML Reader, Notepad or Internet Explorer.

What I want to check is:
– In case the Management Pack contains customizations that I need to move the way they are into the new environment, I will want to export and import it.
– In case the Management Pack contains customizations that only work for the current environment, I will not export and import it.

Cleaning up Inventory

Once I have figured what I want to do with my unsealed Management Packs I take the C:\temp\unsealedmanagementpacks.txt file which was created by the UnsealedMPInventory.ps1 script.

Note: This text file is used by other scripts mentioned in this blog post and is essential for the way I approach the migration.

I update the note for each Management Pack to reflect what I want to do with it. For my matter, I need 5 states for verifying the MP Inventory of my new environment:

  • ExImport: means I want to export the MP and import it in the new environment
  • Import: means I want to import the MP but from a different location
  • Obsolete: means that the Management Pack in question is obsolete and I don’t want it in my new environment
  • Updated: means there’s already an updated version (higher version number) of that Management Pack which I expect in the new environment (mainly needed for unsealed Microsoft MPs)
  • Ignore: won’t be processed in the verification script


Note: I recommend doing that with Excel as it’s rather annoying doing it with notepad.

Export Management Packs marked as ExImport

Note: This assumes that you have created and updated the C:\temp\unsealedmanagementpacks.txt file.

Create folder C:\temp\eximport
Run ExportExImportManagementPacks.ps1

This will export all Management Packs that are marked as ExImport in the C:\temp\unsealedmanagementpacks.txt file.

Copy them over to a 2012 Management Server into the folder C:\temp\ExImport

Verifying MonitoringObjectIds of Overrides targeting Instances and Groups containing explicit members
Note: This is only applicable for Management Packs that are marked as ExImport in the UnsealedManagementPacks.txt file.

Why doing this?

Consider you created an Override that disables the Diskspace Check on a certain disk, on a certain server. The Disk has the Id 00000000-0000-0000-0000-C00000000000

You move that Override into the new environment and the Id 00000000-0000-0000-0000-C00000000000 is suddenly a totally different kind of object on a different server – such as a Web Site. This not only means that the Override doesn’t work the way I want it to work, it also disables a certain Monitoring Feature where it shouldn’t.

While this is unlikely to happen, I still want to verify that I don’t have any conflicts – and in case there is a conflict, I want to know about them so I can fix them.

Note: MonitoringObjectIds are, according to my observation, based on the class and the fullname of the instance. Therefore Disk F: of Server A should still have the same Id in the new environment.


I wrote a script (MonitoringObjectIdInventory.ps1) which takes all Management Packs in the UnsealedManagementPacks.txt file that are marked as ExImport.

It then gets all Overrides and Groups in these MPs and checks if an Override targets an Instance or if a Group contains explicit members.
If that’s the case, it creates a line for each matching Override/Group containing information on the actual object that is targeted by an Override or that is contained in a Group.

It takes all these lines and adds them to a text file c:\temp\MonitoringObjectIdList.txt.

Verifying Ids

Note: This can be done before and/or after Management Packs were imported. Means that you don’t have to import the Management Packs in order to verify the Ids.

I run the VerifyMonitoringObjectInventory.ps1 script in my old environment first as I want to know if some of the Groups/Overrides maybe already target Objects that don’t exist anymore (zombies). In that case I fix those Groups and Overrides first and run the inventory again.

I then copy the inventory file over to my 2012 Management Server under c:\temp\MonitoringObjectIdList.txt and run the VerifyMonitoringObjectInventory.ps1
It processes each entry in the inventory and checks if the objects exist and if they are still the same in the new environment.

Green = Same
Yellow = Object doesn’t exist yet
Red = Object is different in the new environment


Note: In my case this list is mostly yellow as I haven’t got many agents reporting to the 2012 SCOM yet.

In case there is a conflict you have to fix it by removing the explicit member from a group or deleting the override.
The script will give you the information you need to track down the Override or the Group and its Member.

Copy the name, open the Management Pack file (xml), search for it in the Language Pack section to find the Display Name of it.
In the Operations Console go to Authoring, search for the Display Name and delete the Override.

Copy the name, open the Management Pack file (xml), search for it in the Language Pack section to find the Display Name of it.
Note down the new name of the conflicting Object.
In the Operations Console go to Authoring, search for the Display Name and open the properties of the Group.
Go to the Explicit Members tab and remove the conflicting object.

Import Management Packs marked as ExImport
All of these Management Packs should be under c:\temp\eximport on the server where you ran the ExportExImportManagementPack.ps1 script.

Copy them over to the server from which you will import them, launch the Console\Administration\Right-Click Management Packs –> Import Management Packs


Click Add – Add from disk…


Locate the Management Packs, select them and click Open.

And before you hit Import, review the Import list and fix any errors:


Also be careful about Management Packs marked with the blue information-symbol.

Import all other unsealed Management Packs

Not much I can say about this – Check the unsealedmanagementpacks.txt file and import all Management Packs that you marked as Import.

Verifying Management Pack inventory

Once you have imported all Management Packs, copy the unsealedmanagementpacks.txt file to C:\temp on the server from which you will run the verification script (VerifyUnsealedMPInventory.ps1)

The script will do the following, depending on the upgrade notes:
Import: Check if the Management Pack is imported and if there is any difference in the version
Updated: Check if the Management Pack is imported with a higher version number
ExImport: Check if the Management Pack is imported and if there is any difference in the version
Obsolete: Verify that the Management Pack is not imported
Ignore: Ignore the Management Pack

Result colors
Green = Everything is fine
Red = There’s a conflict (Obsolete Management Pack is imported or version number isn’t higher for a Management Pack marked as Updated)
Yellow = Management Pack is not imported yet or the version is different

Output of VerifyUnsealedMPInventory.ps1


Fix any errors (or adjust the inventory file), and run the script until everything is green.

Configuration Changes
Since my old environment is still live, I will have to make sure to make all changes relevant to both environments, in both of them – otherwise I may have to start over.

Rule of thumb: If you make any changes to unsealed Management Packs, make sure you do the same changes in the new environment.

2 thoughts on “SCOM 2012 RC – Side-by-Side Migration Phase 4 – Importing unsealed Management Packs

  1. Wojtek

    Hi Andreas,

    Thank you very much for the series of articles about Side by Side migrations – we find those very useful.

    Could you please correct/update the links to the scripts and images, as it seems that those are no longer valid (for instance in the Phase 3 article those are working, but in Phase 4 – not).

    Thank You.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.