Freigeben über

Control management pack updates between MS OMS and Operations Manager

  • Artikel

Summary: Learn how to disable automatic management pack updates from MS OMS to Operations Manager and limit updates to a specific time window.

Hi all, Brian Wren here. I usually spend my time writing documentation for TechNet and Azure.com, but I’ve been hearing about an issue from a few customers that I wanted to address. We’re going to get some detailed documentation out on this, but a quick blog entry should suffice in the meantime.

When you connect a management group in System Center Operations Manager (SCOM) to Log Analytics in Operations Management Suite (OMS), several management packs are automatically installed in your management group. In addition to a core set of management packs to support the connection and basic data collection, others will be installed for different solutions that you’ve added to your OMS workspace. You can have a look at the entire list by doing a search for Advisor under Management Packs in the Administration workspace.

Screenshot of results for search for Advisor in Operations Management Suite workspace.

After initial installation, SCOM will regularly check OMS for updates to these management packs and automatically download and import them when they’re available. This works well in many environments because your integration between SCOM and OMS is automatically kept up to date with no effort on your part. This can be a problem though in environments that have low bandwidth or stringent change control processes. In these cases, you may want to turn off this automatic updating so that bandwidth is not consumed at peak hours and changes are not made outside your approved time window.

This update process is controlled by the following two rules.

  • Microsoft.SystemCenter.Advisor.MPUpdate

Updates the base OMS management packs. Runs every 12 hours by default.

  • Microsoft.SystemCenter.Advisor.Core.GetIntelligencePacksRule

Updates management packs for solutions in your workspace. Runs every 5 minutes by default.

You can easily disable automatic updates by creating an override to disable those two rules. You can reverse the override to enable them again and allow the updates to run, and you should enable them periodically to keep your management group up to date.

Override the update rules

You’re probably already familiar with creating an override in SCOM, but if not, I’ll go ahead and walk through it here.

Both of those rules are targeted at a class named Operations Manager Management Group (Microsoft.SystemCenter.ManagementGroup if you’re working under the covers). You can view them in the Operations Console with the following steps:

  1. Select Authoring workspace > Rules.
  2. Click Change Scope in the top-right.
  3. Select View all targets.
  4. Type management group to filter the list and select Operations Manager Management Group.

You should get a list of all rules targeted at the management group class, and you can see the two rules that interest us.

Screenshot of management pack objects scoped to Operations Manager Management Group.

Create an override to disable each rule with the following steps:

  1. Right-click the rule and then select Overrides > Override the Rule > For all objects of class: Operations Manager Management Group.
  2. Select the Enabled property and change its override value to False.
  3. Select an existing destination management pack to store the new override or create a new one.

Screenshot of an override that disables a rule.

You can follow the same process to set the value to True when you want to enable the rule again.

Since the MPUpdate rule runs every 12 hours, you will probably want to decrease this time if you’re going to enable it for a short period. Otherwise it may not have a chance to run during the time you have it enabled. For example, you might change its frequency to every 10 minutes (600 seconds) and enable it for an hour or so.

Screenshot of the Override Properties and the frequency parameter.

Automate the overrides

It’s not difficult to enable and disable the rules to control the MPUpdate process, but there are quite a few clicks required. It would be helpful if we could automate it with a single command. Eventually, I’d like to get this logic into a management pack so could control it entirely within SCOM. In the meantime, though, we should be able to use a Windows PowerShell script to control those overrides.

Russ Slaten posted a great script to create overrides a couple years ago that’s perfect for this. This script will allow you to specify the rule to override, the property and desired value, and the management pack to store the override. It will even create that management pack if it doesn’t already exist.

The following example uses that script to enable the MPUpdate rule and store the override in a management pack named OMS.Overrides.

CreateOverride.ps1 –ManagementServer scom01.contoso.com –ManagementPackID OMS.Overrides –WorkflowID Microsoft.SystemCenter.Advisor.MPUpdate –ContextID Microsoft.SystemCenter.ManagementGroup –PropertyName Enabled –PropertyValue True –Enforced False

Screenshot of results of a script that enables the MPUpdate rule and store the override.

Schedule the script

It would be helpful to schedule this script to run at certain times so we can have updates occur only during a certain time window. For example, we might want to have the updates disabled by default, enable them at 1 AM each night, and disable them at 2 AM.

As I mentioned before, I’ll hopefully get this functionality into a management pack at some point. A simple method, though, is to schedule the script to run as a scheduled task on a management server. You could technically run it on any machine with the Operations Manager console binaries installed, but a management server makes sense since that’s what the script has to connect to anyway.

You can create a scheduled task in Windows by using Task Scheduler, which you access from Administrative Tools. The Scripting Guys wrote a great blog post on exactly how to Use the Windows Task Scheduler to Run a Windows PowerShell Script, and that’s exactly the method I’ll use.

Because we need to run the script for each rule, and we need to give it a pretty long list of parameters, I created two additional scripts to encapsulate the long command lines.

Screenshot of parameters in the EnableOMSUpdates.ps1 script. Screenshot of parameters in the DisableOMSUpdates.ps1 script.

That simplifies the argument that I need to pass to powershell.exe in the action for my schedule task. You can’t see it too well in the screenshot below, but the argument is –file "c:\scripts\DisableOMSUpdates.ps1" .

Screenshot of the –file "c:\scripts\DisableOMSUpdates.ps1" argument in the Edit Action dialog box for a scheduled task.

Create a scheduled task each for enable and disable to run at the appropriate time, and you’re ready to go.

Screenshot of the Enable and Disable scheduled tasks.

I invite you to follow me on Twitter and keep an eye on our new Monitoring documentation where we’ll be presenting a variety of scenarios using OMS and Operations Manager together.

Brian Wren

OMS Documentation Team

Comments

  • Anonymous
    March 21, 2016
    I have done production work with OMS/SCOM few months ago and we have experienced this issue. It was a disaster and I had to quickly reboot all my Management servers and disable proxy.
    • Anonymous
      March 22, 2016
      We heard different feedback from customers having issues with this which is why we wanted to get the information out there. As I mentioned in the post, we're getting it into our core documentation on integrating OMS and SCOM soon.