How to remove OMS and Advisor management packs


When testing OMS (Previously called Advisor) with SCOM, there is one side effect:  Once connected, the OMS rules import management packs into your management group with no notification or change control process for you.  Furthermore – if you want to remove OMS Management packs from a SCOM management group, there is a rule that will actually re-download them while you are trying to delete them!  This makes OMS very difficult to remove by default.

Brian Wren posted a method to control this behavior here, and I will demonstrate the same.


First, create a new management pack to store our temporary overrides – called “OMS Temp Overrides”

Then in the console, go to Authoring > Rules, and set your scope only to “Operations Manager Management Group”

Disable the following two rules:



This will stop new OMS/Advisor packs from coming down automatically.


Now you can start removing the packs as needed from your management group.    You can use PowerShell to do this in bulk, but it will fail for any MP’s with dependencies.  Here is a simple example:

Get-SCOMManagementPack -name "*advisor*" | Remove-SCOMManagementPack

Get-SCOMManagementPack -name "*IntelligencePack*" | Remove-SCOMManagementPack

get-SCOMManagementPack -name "Microsoft.EnterpriseManagement.Mom.Modules.AggregationModuleLibrary" | Remove-SCOMManagementPack

Be VERY careful using the above statements – they are provided as examples only.  Make SURE they return only the ones you wish to remove and not any custom packs you created that happen to match the naming scheme.

Now – that should leave you with just the following MP’s:




Delete your temp Override MP you created, then (quickly) delete the above MP’s in the order above.

That’s it.


If you want to bring OMS back into a Management Group – simply import the Advisor Packs in whatever current UR (Update Rollup) you are on, such as these from UR9:


Comments (10)

  1. gcodin says:

    Very good article Kevin, as always!

  2. vildauget says:

    Thank you, Kevin! This operation was painful – even with this guide to follow. Without, I wouldn’t be able to remove it. Overrides and references all over, and autodownloaders to add. I also needed to use the following guide as well to kill references that got stuck in the mess:

    Thanks again!

  3. Tina says:

    Please this is urgent. How do I remove multiple management packs from SCOM 2016.

  4. Tina says:

    Please this is urgent. How do I remove multiple management packs from SCOM 2016.

  5. Larry says:

    If we are NOT leveraging any OMS integrations with SCOM, can we simply not delete the following MP files from the Management Group?
    – Microsoft.SystemCenter.Advisor.Internal.mpb
    – Microsoft.SystemCenter.Advisor.mpb
    – Microsoft.SystemCenter.Advisor.Resources.ENU.mpb
    My concern with keeping them around is that new, undesirable, workflows might be included in a future version of these files, and I’ll have to revisit this issue once more, by creating new overrides. Also, if we change our minds in the future, the files are always available in the latest UR.

    1. Kevin Holman says:

      @larry –

      Yes – you can remove these MP’s, especially if a customer doesn’t want to connect SCOM to OMS. Even these MP’s are running workflows on ALL systems in the management group even if you DON’T use OMS, as evidenced by the errors seen on Windows Server 2003 machines.

      1. Dan Arstill says:

        What if I have SCOM and OMS connected and I need to decom or remove a server or bring a new server in, what is the process for that?

  6. Dan Arstill says:

    Do I just uninstall and then install the MP’s on the new server and then connect from the console?

  7. josh says:

    Hey Kevin,

    I ran into an issue where trying to remove the Microsoft System Center Advisor Management Pack. It showed that there was a dependency on the Management Pack Microsoft.SystemCenter.SecureReferenceOverride. Removing this Management Pack cleared out the profile settings for the Data Warehouse Account and the Data Warehouse Report Deployment Account.

    This happened in both my test and production SCOM environments – is this dependency common?

    1. Kevin Holman says:

      DO NOT delete Microsoft.SystemCenter.SecureReferenceOverride. EVER.

      This MP is built in and contains associations to all RunAs account profiles. You NEED it. 🙂 SCOM will break badly without it. In order to clean up your issue – the right way is to ensure there are no longer any Advisor RunAs profiles populated, then export the Microsoft.SystemCenter.SecureReferenceOverride mp, edit it, and remove the reference/dependency from the XML, and reimport. Same process as:

Skip to main content