Daily Archives: 28/06/2015

Automating OpsMgr Part 2: SMA Runbook for Creating ConfigMgr Log Collection Rules

Written by Tao Yang


This is the 2nd instalment of the Automating OpsMgr series. Previously on this series:

Few weeks ago, I have also published a post: Collecting ConfigMgr Logs To Microsoft Operation Management Suite – The NiCE Way, which demonstrated how to use an OpInsights integrated OpsMgr management group and NiCE Log File MP to collect ConfigMgr client and server logs into Microsoft Operation Management Suite.

The solution I provided in that post included few sealed management packs and a demo management pack which includes few actual event collection rules for ConfigMgr log files. However, it requires some manual XML editing outside of whatever MP authoring tool that you might be using, which could be a bit complicated for IT Pros and non management pack developers. The manual XML editing is necessary because the log collection rules use a Write Action module called “Microsoft.SystemCenter.CollectCloudGenericEvent” to send the event data to the OpInsights workspace. This write action module is located in the “Microsoft.IntelligencePacks.Types” sealed management pack. This management pack is automatically pushed to your OpsMgr management group once you’ve configured the OpInsights connection.

When using management pack authoring tools such as VSAE, if you need to reference a sealed management pack (or management pack bundle), you must have the sealed MP or MP bundle files (.mp or .mpb) handy and add these files as references in your MP project. But since the sealed MP “Microsoft.IntelligencePacks.Types” is automatically pushed to your management group as part of the OpInsights integration, and Microsoft does not provide a downloadable .mp file for this MP (yes,I have asked the OpInsights product group). There was no alternatives but manually editing the XML outside of the authoring tool in order to create these rules.

Our goal is to create potentially a large number of event collection rules for all the ConfigMgr event logs that ConfigMgr administrators are interested in. In my opinion, this is a perfect automation candidate because you will need to create multiple near-identical rules, and it is very time consuming if you use MP authoring tools and text editors to create these rules (as I explained above).


I am going to demonstrate how to create these event collection rules using a SMA runbook which uses The OpsMgrExtended PowerShell module. In order to implement this solution, you will need the following:

  • An OpsMgr 2012 SP1 or R2 management group that has been connected to Azure Operational Insights (OMS)
  • A SMA infrastructure in your environment
  • Microsoft ConfigMgr 2012 management pack version 5.0.7804.1000 imported and configured in your OpsMgr management group
  • The ConfigMgr components of which you need to collect the logs from must be monitored by the OpsMgr (including ConfigMgr servers and clients). These computers must be agent monitored. Agentless monitoring is not going to work in this scenario.
  • NiCE Log File MP imported in your OpsMgr management group
  • OpsMgrExtended module imported into SMA and an “Operations Manager SDK” SMA connection object is created for your OpsMgr management group – Please refer to Part 1 of this series for details
  • The “ConfigMgr Logs Collection Library Management Pack” must also be imported into your OpsMgr management group – Download link provided in my previous post.


Runbook: New-ConfigMgrLogCollectionRule

When executing this runbook, the user must specify the following parameters:

  • RuleName: the internal name of the OpsMgr rule
  • RuleDisplayName: the display name of the OpsMgr rule
  • ManagementPackName: The internal name of the management pack (must be an existing MP in your OpsMgr management group)
  • ClassName: The target class of the rule. It must be one of the following values:
    • “Microsoft.SystemCenter2012.ConfigurationManager.DistributionPoint”
    • “Microsoft.SystemCenter2012.ConfigurationManager.ManagementPoint”
    • “Microsoft.SystemCenter2012.ConfigurationManager.SiteServer”
    • “Microsoft.SystemCenter2012.ConfigurationManager.Client”
  • LogDirectory: The directory where the log is located (i.e. “C:\Windows\CCM\Logs”)
  • LogFileName: The name of the log file (i.e. “UpdatesStore.Log”)
  • EventID: The Event ID that you wish to use when converting log file entries to Windows events
  • EventLevel: Windows event level. Must be one of the following values:
    • ‘Success’
    • ‘Error’
    • ‘Warning’
    • ‘Information’
    • ‘Audit Failure’
    • ‘Audit Success’
  • IntervalSeconds: How often does the rule run

On line 16 of the runbook, I’ve coded the runbook to retrieve a SMA connection object called “OpsMgrSDK_TYANG”:


This is because my SMA connection object for my OpsMgr management group is named “OpsMgrSDK_TYANG”. You will need to change this line according to how you’ve created your SMA connection:



You can also further simplify the runbook in the following possible areas:

  • Hardcoding the destination management pack in the runbook
  • Hardcoding the interval seconds (i.e. to 120 seconds)
  • Create a switch statement for the target class, so instead entering “Microsoft.SystemCenter2012.ConfigurationManager.Client”, users can simply enter “Client” for example.
  • Create a switch statement for the LogDirectory parameter. for example, when the target class of “Client” is specified, set LogDirectory variable to “C:\Windows\CCM\Logs”.
  • Automatically populate Rule name and display name based on the target class and the log file name.
  • Build a user’s request portal using System Center Service Manager or SharePoint List (This would be a separate topic for another day, but Please refer to my previous MVP Community Camp presentation recording for some samples I’ve created in the past using SharePoint Lists).

Lastly, needless to say, you can also execute this PowerShell workflow in a standalone PowerShell environment (or convert this PowerShell workflow into a regular PowerShell script). When running it outside of SMA, you will need to use another Parameter Set for the “New-OMManagementPackReference” and “New-OMRule” activities. So instead of using –SDKConnection Parameter, you will have to use –SDK (and optionally –Username and –Password) to connect to your OpsMgr management group. To Change it, please modify the following lines:

Change Line 16 to $SDK = “<Your OpsMgr management server>”

Change Line 47 to:


$NewMPRef = New-OMManagementPackReference -SDK $SDK -ReferenceMPName “Microsoft.Windows.Library” -Alias “Windows” -UnsealedMPName $ManagementPackName

Change Line 117 to:


New-OMRule -SDK $USING:SDK -MPName $USING:ManagementPackName -RuleName $USING:RuleName -RuleDisplayName $USING:RuleDisplayName -Category “EventCollection” -ClassName $USING:ClassName -DataSourceModules $USING:arrDataSourceModules -WriteActionModules $USING:arrWriteActionModules -Remotable $false


After I filled out all the parameters:




And executed the runbook:


The rule was successfully created:


And shortly after it, you should start seeing the log entries in your OMS workspace:




I have demonstrated how to use the OpsMgrExtended module in a SMA runbook to enable users creating large number of similar OpsMgr management pack workflows.

Given this is only part 2 of the series, and the first example I have released, maybe I should have started with something easier. The reason I’ve chosen this example as Part 2 is because I am going to present in the next Melbourne System Center, Security, & Infrastructure user group meeting next Tuesday 7th July among with 3 other MVPs (David O’Brien, James Bannan and Orin Thomas). I am going to demonstrate this very same scenario – using OpInsights to collect SCCM log files. So I thought I’ll make this the 2nd instalment of the series, so people who attended the user group meeting have something to refer to. In this sample runbook, I’ve used a relatively more complicated activity called New-OMRule to create these event collection rules. This activity is designed as a generic method to create any types of OpsMgr rules. I will dedicate another blog post just for this one in the future.

Lastly, if you are based in Melbourne and would like to see this in action, please come to the user group meeting in the evening of 7th July. It is going to be held at Microsoft Melbourne office in South Bank. the registration details is available on the website: http://mscsig.azurewebsites.net/.