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:
Hi Kevin,
The following Management Packs are part of the SCOM core Management Packs, do they import when we install the SCOM? Could you please confirm.
Microsoft System Center Advisor Internal
Microsoft System Center Advisor
Microsoft System Center Advisor Resources (ENU)
Yes, those are imported as part of the initial SCOM install.
Thanks for the procedures Kevin, but on the last step I can’t delete Microsoft System Center Advisor because of a dependency with Microsoft.SystemCenter.SecurReferenceOverride. Any idea how to address that? Thanks!
Interesting, that’s very rare and I am not sure why you would be facing that. For APM MP’s that’s typical.
You will need to export your secure reference MP and manually edit it to remove the reference and any items using the reference. You can look at my APM blog for examples on how to do that. https://kevinholman.com/2017/08/05/reinstalling-your-scom-agents-with-the-noapm-switch/
Many thanks to Kevin for this valuable knowledgebase!.
It worked out perfectly with the removal of all Advisor and Intelligence Management Packs.
The removed MPs are the cause of the performance event with Event Log ID: 2115 on all SCOM management server..
Some MPs cannot be removed. It seems Microsoft has created many more dependent MPs that are not retrieved when performing the GET ? Please have a look. Thanks
When deleting these MPs in preperation for an upgrade to SCOM 2022 as noted in the checklist. Does the actual upgrade put them back?