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.
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: