Take control of OMS with SCOM

OMS is Fantastic, but I do have a couple hurdles to clear when its implemented at an enterprise scale.  (If you’ve got questions on what cool things you can do with OMS any of your favorite SCOM Bloggers are bound to have a post or more on it.)

Before deploying OMS to an Enterprise Operations Manager Environment I’ve got a couple questions I would like to answer:

  • How do I discretely Control when and where the Solutions Run?
  • How to I know about the MP changes that will come to my environment?
    • Control them?
    • Alert on Them?
    • Get more information on them?

How do I discretely Control when and Where the Solutions run?

Overrides, Obviously, but that’s much easier said than done.  So how should we implement these overrides?  I’ve taken a stab at an OMS Administration Pack that hopes to simplify this.  Read this post for more, but the rough outline is below.  Every time a new management pack arrives from OMS the pack takes the below steps:

  1. Create an empty unsealed override pack named after the OMS Pack that Arrived.
  2. Add Two groups to the Unsealed Pack (Singletons with no dynamic members)
    1. Solution ABC – Enable Group
    2. Solution ABC – Disabled Group
  3. Create 3 Overrides in this new pack
    1. Disable Rule Workflows at the Class Level
    2. Enable Rule Workflows for the Context of the Enable Group
    3. Disable and Enforce Rule Workflows for the Context of the Disabled Group

Now all that’s needed is to place computers or sub-groups in the respective Enable and Disable groups to limit your billing and collection were intended.

How to I know about the MP changes that will come to my environment?

The Management Pack I mentioned earlier tries to tackle this challenge as well.  Included in the lists of packs is a Monitoring Pack and Discovery Pack.  These two pair together to pull a list of Management Packs directly from the OMS servers with the current published version.  Class instances are produce for each of these packs and the below alerts and tasks help manage the installation.

  • Overrides disable the Automatic Download Rules
  • The OMS MP Class Monitors and alerts on 3 items
  • Version Mismatch between OMS Catalog and Installed
  • Missing Pack based on OMS Catalog
  • Pack that needs to be Deleted based on OMS Catalog
  • The Raised Alert includes targeted tasks for the following:
  • Install MP from OMS
  • Download MP from OMS
  • Scheduled Install Time in the Future for the OMS MP
  • Remove MP from On-Site Management Group

Hopefully this is has some appeal, for more on the pack and to download it, click here.

OMS Administration Management Packs

Below is a breakdown of a set of Open Source Management packs I’ve been working on to provide more enterprise granularity to OMS when it is connected through SCOM.  The Code is posted at GitHub and I’m working to keep the issues updated and get fixes in when possible.

Check out the GitHub below, Release.zip has built packs inside:


From a 10,000ft view, when enabled, the flow of the pack is as follows:

  1. Overrides are placed on the Advisor and Intelligence Update Rules to prevent downloads
  2. A Discovery pulls a List of MPBs and MPs down, A class structure representing available and assigned packs is created.
  3. A Data Collection Rule pulls down the Current Version and Pack Assignment status from OMS
  4. The OMS MP Class Monitors and alerts on 3 items
    1. Version Mismatch between OMS Catalog and Installed
    2. Missing Pack based on OMS Catalog
    3. Pack that needs to be Deleted based on OMS Catalog
  5. The Raised Alert includes targeted tasks for the following:
    1. Install MP from OMS
    2. Download MP from OMS
    3. Scheduled Install Time in the Future for the OMS MP
    4. Remove MP from OnSite Management Group
  6. Once the Management Packs behind the solution come down the MP Overrides are created:
    1. An unsealed MP is Created at the Solution Level
    2. MP Includes an ‘Enable – Solution’ Group
    3. MP Includes a ‘Disable – Solution’ Group
    4. All Rules and Monitors are Disabled at the Class Level
    5. All Rules/Monitors are Enabled for the Context of the Enable Group
    6. All Rules/Monitors are Disabled with an Enforced override for the Context of the Disable Group
  7. For further granularity in monitoring UI based rule templates have been included to create the following OMS Collection Rules: This isn’t working properly yet.
    1. WMI Perf and Events
    2. Windows Events and OCI Perf
    3. Script Events and Script Perf


The Functionality now Exists to allow a User to enable a specific solution for a sub group of computers and then disabled if for a select few (HR maybe?).


On to the Pack design and how things work under the covers.

All actual ‘Work’ and data processing is done by SCOM Rules or Tasks.  A UI has been included to simplify the administration of these rules, under the covers this UI only modifies the Overrides in a Specific unsealed pack.

–          Security/Certs

The Pack defines 3 Run-As Profiles.  One for each of the Certificate and Proxy Credentials to Connect to OMS and one for the SDK workflows to access the management group.

For the discoveries to work properly the 4 OMS classes and the RMS Emulator class need to be added to the OMS Admin Certificate profile.  There is a Task that targets the RMSEmulator and will automate this work.

–          Reporting

There is an included reporting MP but it doesn’t offer any great functionality(yet).  The back does define a new DataSet through the standard process in the XML.  The DataSet does have Raw and Daily aggregations as well as configured Grooming and Deletion Stored procedures.  Both Staging and Processing stored procedures are primarily shells but have error handling and all of the regular bells and whistles included.

When complete I would like to have a report produced of what the new pack does and how it differs from the current version.

–          Querying

To minimize the number of queries against OMS and maximize the flexibility only two queries are made, one for the Discovery and one for All other monitoring.  Data from these queries flow through a dedicated windows event log that is created with the pack.  It defaults to 4mb and overwrites circularly.  Cookdown and some other options would work as well but this provides a quick and easy diagnosis point for errors.

–          Data Processing Workflows

To simplify re-use and readability I tried to make everything code driven in PowerShell for easy reading/editing.  The only exception is the UI which was compiled in .NET and included into the MPB.

Additionally in an effort of simplicity most items that do heavy work (MP Generation, MP Downloads/Installs) are event triggered Rules that monitor the custom created log.  This allows flexibility in the tasks, targets, and who can call the jobs.  This was initially created to overcome some hurdles with MP Resources being used on the DA.

–          Alerting

4 Alerting workflows are available, with the 3 preferred being the State monitors for the OMS MP Class.

–          Tasks

With the Exception of the MP Deletion Task and the Run-As Profile creation all Tasks generate events that trigger the aforementioned rules.

–          Templates

All Templates appear in the UI Menu and Function the same as the Built in ‘Create a Rule’ interface, with the major difference that data skips the OLTDB and SCOM DW and goes straight to OMS.

–          UI

There is a Dashboard under an OMS Admin folder on the monitoring tab that shows the health and current alerts for the solutions.  It also includes a connection to the OMS Interface.

The UI Below shows under OMS on the Administration Tab, once you connect to your management server it will read the Unsealed pack and populate the respective properties.  I’d suggest enabling the Manual Deployment Mode and the Group Creation for testing.  Things have worked great on the most recent tests.