Tag Archives: MimboloveFeatured

OpsMgr Self Maintenance Management Pack

Written by Tao Yang

OMSelfMaintMPIcon26/10/2015 Update: It has been identified the unsealed override MP was not included in the download, and also there was a small error in “Known Issue” section (section 8) of the MP guide. Therefore I have just updated the download which now included the override MP and updated MP guide. However, if you have already downloaded the version, and only after the override MP, you can download it from HERE.

18/09/2015 Update: A bug has been identified in version, where the newly added Data Warehouse DB staging tables row count performance collection rules is causing issues with the Exchange Correlation service from the of Exchange MP (Please refer to the comment section of this post) because the rule category is set to “None”. I have updated the category of these performance collection rules in both the Self Maintenance MP and the OMS Add-On MP. Please re-download the MP (version if you have already downloaded it and you are using Exchange MP in your environment.


I can’t believe it has been 1 year and 3 month since the OpsMgr Self Maintenance MP was lastly updated. This is partially because over the last year or so, I have been spending a lot of time developing the OpsMgr PowerShell / SMA module OpsMgrExtended and am stilling working on the Automating OpsMgr blog series.  But I think one of the main reasons is that I did not get too many new ideas for the next release. I have decided to start working on version 2.5 of the Self Maintenance MP few weeks ago, when I realised I have collected enough resources for a new release. So, after few weeks of development and testing, I’m pleased to announce the version 2.5 is ready for the general public.

What’s new in version 2.5?

  • Bug Fix: corrected “Collect All Management Server SDK Connection Count Rule” where incorrect value may be collected when there are gateway servers in the management group.
  • Additional Performance Rules for Data Warehouse DB Staging Tables row count.
  • Additional 2-State performance monitors for Data Warehouse DB Staging Tables row count.
  • Additional Monitor: Check if all management servers are on the same patch level
  • Additional discovery to replace the built-in “Discovers the list of patches installed on Agents” discovery for health service. This additional discovery also discovers the patch list for OpsMgr management servers, gateway servers and SCSM servers.
  • Additional Agent Task: Display patch list (patches for management servers, gateway servers, agents and web console servers).
  • Additional Agent Task: Configure Group Health Rollup
  • Updated “OpsMgr 2012 Self Maintenance Detect Manually Closed Monitor Alerts Rule” to include an option to reset any manually closed monitor upon detection.
  • Additional Rule: “OpsMgr 2012 Self Maintenance Audit Agent Tasks Result Event Collection Rule”
  • Additional Management Pack: “OpsMgr Self Maintenance OMS Add-On Management Pack”

To summarise, in my opinion, the 2 biggest features shipped in this release are the workflows built around managing OpsMgr Update Rollup patch level, and the extension to Microsoft Operations Management Suite (OMS) for the management groups that have already been connected to OMS via the new OpsMgr Self Maintenance OMS Add-On MP .

I will now briefly go though each item from the list above. The detailed documentation can be found in the updated MP guide.

Bug Fix: Total SDK Connection Count Perf Rule

In previous version, the PowerShell script used by the “Collect All Management Server SDK Connection Count Rule” had a bug, where the incorrect count could be collected when there are gateway servers in the management group. i.e.


As shown above, when I installed a gateway server in my management group, the counter value has become incorrect and has increased significantly. This issue is now fixed.

Monitoring and Collecting the Data Warehouse DB staging tables row count

Back in the MVP Summit in November last year, my friend and fellow MVP Bob Cornelissen suggested me to monitor the DW DB staging tables row count because he has experienced issues where large amount of data were stuck in the staging tables (http://www.bictt.com/blogs/bictt.php/2014/10/10/case-of-the-fast-growing). Additionally, I have already included the staging tables row count in the Data Warehouse Health Check script which was released few months ago.

In this release, the MP comes with a performance collection rule and a 2-state performance threshold monitor for each of these 5 staging tables:

  • Alert.AlertStage
  • Event.EventStage
  • ManagedEntityStage
  • Perf.PerformanceStage
  • State.StateStage

The performance collection rules collect the row count as performance data and store the data in both operational DB and the Data Warehouse DB:


The 2-State performance threshold monitors will generate critical alerts when the row count over 1000.


Managing OpsMgr Update Rollup Patch Level

Over the last 12 months, I have heard a lot of unpleasant stories caused by inconsistent patch levels between different OpsMgr components. In my opinion, currently we have the following challenges when managing updates for OpsMgr components:

People do not follow the instructions (aka Mr Holman’s blog posts) when applying OpsMgr updates.

Any seasoned OpsMgr folks would know wait for Kevin Holman’s post for the update when a UR is released, and the order for applying the UR is also critical. However, I have seen many times that wrong orders where followed or some steps where skipped during the update process (i.e. SQL update scripts, updating management packs, etc.)

OpsMgr management groups are partially updates due to the (mis)configuration of Windows Update (or other patching solutions such as ConfigMgr).

I have heard situations where a subset of management servers were updated by Windows Update, and the patch level among management servers themselves, as well as between servers and agents are different. Ideally, all management servers should be patched together within a very short time window (together with updating SQL DBs and management packs), and agents should also be updated ASAP. Leaving management servers in different patch levels would cause many undesired issues.

It is hard to identify the patch level for management servers

Although OpsMgr administrators can verify the patch list for the agent by creating a state view for agents and select “Patch List” property, the patch list property for OpsMgr management servers and gateway servers are not populated in OpsMgr. This is because the object discovery of which is responsible for populating this property only checks the patch applied to the MSI of the OpsMgr agent. Additionally, after the update rollup has been installed on OpsMgr servers, it does not show up in the Program and Features in Windows Control Panel. Up to date, the most popular way to check the servers patch level is by checking the version of few DLLs and EXEs. Due to these difficulties, people may not even aware of the inconsistent patch level within the management group because it is not obvious and it’s hard to find out.

In order to address some of these issues, and helping OpsMgr administrators to better manage the patch level and patching process, I have created the following items in this release of the Self Maintenance MP:

State view for Health Service which also displays the patch list:


An agent task targeting Health Service to list OpsMgr components patch level:


Because the “Patch List” property is populated by an object discovery, which only runs infrequently, in order to check the up-to-date information(of the patch list), I have created a task called “Get Current Patch List”, which is targeting the Health Service class. This task will display the patch list for any of the following OpsMgr components installed on the selected health service:

Management Servers | Gateway Servers:


Agents | Web Console (also has agent installed):


Object Discovery: OpsMgr 2012 Self Maintenance Management Server and Agent Patch List Discovery

Natively in OpsMgr, the agent patch list is discovered by an object discovery called “Discovers the list of patches installed on Agents”:


As the name suggests, this discovery discovers the patch list for agents, and nothing else. It does not discover the patch list for OpsMgr management servers, gateway servers, and SCSM management servers (if they are also monitored by OpsMgr using the version of the Microsoft Monitoring Agent that is a part of the Service Manager 2012). On the other hand, this discovery provided by the OpsMgr 2012 Self Maintenance MP (Version is designed to replace the native patch list discovery. Instead of only discovering agent patch list, it also discovers the patch list for OpsMgr management servers, gateway servers, SCSM management servers and SCSM Data Warehouse management servers.

Same as all other workflows in the Self Maintenance MP, this discovery is disabled by default. In order to start using this discovery, please disable the built-in discovery “Discovers the list of patches installed on Agents” BEFORE enabling “OpsMgr 2012 Self Maintenance Management Server and Agent Patch List Discovery”:


Shortly after the built-in discovery has been disabled and the “OpsMgr 2012 Self Maintenance Management Server and Agent Patch List Discovery” has been enabled for the Health Service class, the patch list for the OpsMgr management servers, gateway servers and SCSM management servers (including Data Warehouse management server) will be populated (as shown in the screenshot below):



As shown above, the patch list for different flavors of Health Service is properly populated, with the exception of the Direct Microsoft Monitoring Agent for OpInsights (OMS). This is because at the time of writing this post (September, 2015), Microsoft has yet released any patches to the OMS direct MMA agent. The last Update Rollup for the Direct MMA agent is actually released as an updated agent (MSI) instead of an update (MSP). Therefore, since there is no update to the agent installer MSI, the patch list is not populated.


Please do not leave both discoveries enabled at the same time as it will cause config-churn in your OpsMgr environment.

Monitor: OpsMgr 2012 Self Maintenance All Management Servers Patch List Consistency Consecutive Samples Monitor

This consecutive sample monitor is targeting the “All Management Servers Resource Pool” and it is configured to run every 2 hours (7200 seconds) by default. It executes a PowerShell script which uses WinRM to remotely connect to each management server and checks if all the management servers are on the same UR patch level.

In order to utilise this monitor, WinRM must be enabled and configured to accept connections from other management servers. The quickest way to do so is to run “Winrm QuickConfig” on these servers. The account that is running the script in the monitor must also have OS administrator privilege on all management servers (by default, it is running under the management server’s default action account). If the default action account does not have Windows OS administrator privilege on all management servers, a Run-As profile can be configured for this monitor:


In addition to the optional Run-As profile, if WinRM on management servers are listening to a non-default port, the port number can also be modified via override:



All management servers must be configured to use the same WinRM port. Using different WinRM port is not supported by the script used by the monitor.

If the monitor detected inconsistent patch level among management servers in 3 consecutive samples, a Critical alert will be raised:


The number of consecutive sample can be modified via override (Match Count) parameter.

Agent Task: Configure group Health Rollup

This task has been previously released in the OpsMgr Group Health Rollup Task Management Pack. I originally wrote this task in response to Squared Up’s customers feedback. When I was developing the original MP (for Squared Up), Squared Up has agreed for me to release it to the public free of charge, as well as making this as a part of the new Self Maintenance MP.

Therefore, this agent task is now part of the Self Maintenance MP, kudos Squared Up Smile.

Auditing Agent Tasks Execution Status

In OpsMgr, the task history is stored in the operational DB, which has a relatively short retention period. In this release, I have added a rule called “OpsMgr 2012 Self Maintenance Audit Agent Tasks Result Event Collection Rule”. it is designed to collect the agent task execution result and store it in both operational and Data Warehouse DB as event data. Because the data in the DW database generally has a much longer retention, the task execution results can be audited and reported.


This rule was inspired by this blog post (although the script used in this rule is completely different than the script from this post): http://www.systemcentercentral.com/archiving-scom-console-task-status-history-to-the-data-warehouse/

Resetting Health for Manually Closed Monitor Alerts

Having ability to automatically reset health state for manually closed monitor alerts must be THE most popular suggestion I have received for the Self Maintenance MP. I get this suggestions all the time, from the community, and also from MVPs. Originally, my plan was to write a brand new rule for this purpose. I then realised I already have created a rule to detect any manually closed monitor alerts. So instead of creating something brand new, I have updated the existing rule “OpsMgr 2012 Self Maintenance Detect Manually Closed Monitor Alerts Rule”. In this release, this rule now has an additional overrideable parameter called “ResetUnitMonitors”. This parameter is set to “false” by default. But when it is set to “true” via overrides, the script used by this rule will also reset the health state of the monitor of which generated the alert if the monitor is a unit monitor and its’ current health state is either warning or error:


OpsMgr Self Maintenance OMS Add On MP

OK, we all have to admit, OMS is such a hot topic at the moment. Hopefully you all have played and read about this solution (if not, you can learn more about this product from Mr Pete Zerger’s survival guide for OMS:http://social.technet.microsoft.com/wiki/contents/articles/31909.ms-operations-management-suite-survival-guide.aspx)

With the release of version, the new “OpsMgr Self Maintenance OMS Add-On Management Pack” has been introduced.

This management pack is designed to also send performance and event data generated by the OpsMgr 2012 Self Maintenance MP to the Microsoft Operations Management Suite (OMS) Workspace.

In addition to the existing performance and event data, this management pack also provides 2 event rules that send periodic “heartbeat” events to OMS from configured health service and All Management Servers Resource Pool. These 2 event rules are designed to monitor the basic health of the OpsMgr management group from OMS (Monitor the monitor scenario).


In order to use this management pack, the OpsMgr management must meet the minimum requirements for the OMS / Azure Operational Insights integration, and the connection to OMS must be configured prior to importing this management pack.

Sending Heartbeat Events to OMS

There have been many discussion and custom solutions on how to monitor the monitor? It is critical to be notified when the monitor – OpsMgr management group is “down”. With the recent release of Microsoft Operations Management Suite (OMS) and the ability to connect the on-premise OpsMgr management group to OMS workspace, the “OpsMgr Self Maintenance OMS Add-On Management Pack” provides the ability to send “heartbeat” events to OMS from

  • All Management Servers Resource Pool (AMSRP)
  • Various Health Service
    • Management Servers and Gateway Servers
    • Agents

The idea behind these rules is that once the resource pool and management servers have started sending heartbeat events to OMS every x number of minutes, we will then be able to detect when the expected heartbeat events are missing, thus detecting potential issues within OpsMgr – thus monitoring the monitor.

The heartbeat events can be accessed via the the OMS web portal (as well as using the OMS search API):

i.e. the AMSRP heartbeat events for the last 15 minutes:


Dashboard tile with threshold:



For the heartbeat event rule targeting the health service, I have configured it to continue sending the heartbeat even when the Windows computer has been placed into maintenance mode (not that management servers should ever been placed in maintenance mode in the first place Smile).

I’m not going to take all the credit for this one. Monitoring the monitor using OMS was an idea from my friend and fellow MVP Cameron Fuller. as the result of this discussion with Cameron and other CDM MVPs, I ended up developed a management pack which sends heartbeat events from AMSRP and selected health service (management servers for example) to OMS. This management pack has never been published to the public, but I believe Cameron has recently demonstrated it in the Minnesota System Center User Group meeting (http://blogs.catapultsystems.com/cfuller/archive/2015/08/14/summary-from-the-mnscug-august-2015-meeting/)

Please refer to the MP guide section 7.1 for detailed information about this feature.

Collecting Data Generated by the OpsMgr 2012 Self Maintenance MP

Other than the heartbeat event collection rules, the OMS Add-On MP also collects the following event and performance data to OMS:

  • Data Warehouse Database Aggregation Outstanding dataset count (Perf Data)
  • Data Warehouse Database Staging Tables Row Count (Perf Data)
  • All Management Server SDK Connection Count (Perf Data)
  • OpsMgr Self Maintenance Health Service OMS Heartbeat Event Rule
  • Agent Tasks Result Audit (Event Data)

The above listed data are already being generated by the OpsMgr 2012 Self Maintenance MP, The OMS Add-On MP fully utilise Cook Down feature, and store these data in OMS in additional to the OpsMgr databases.

i.e. Agent Task Results Audit Event:


SDK Connection Count Perf Data:


Please refer to the MP guide section 7.2 for more information (and sample search queries) about these OMS data collection rules.


There are simply too many people to thank. I have mentioned few names in this post, but if I attempt to mention everyone who’s given me feedback, advise and helped me testing, I’m sure I’ll miss someone.

So I’d like to thank the broader OpsMgr community for adopting this MP and for all the feedback and suggestions I’ve received.

What’s Next?

Well, my another short time goal is to create a Squared Up dashboard for this MP, and release it in Squared Up’s upcoming community dashboard site.

Speaking about the long time goal, my prediction is that the next release is probably going to be dedicated to OpsMgr 2016. I am planning to make a brand new MP for OpsMgr 2016 (instead of upgrading this build), so I am able to delete all the obsolete elements in the 2016 build. I will re-evaluate and test all the workflows in this MP, making sure it is still relevant for OpsMgr 2016.


You can download this MP from my company’s website HERE

Automating OpsMgr Part 1: Introducing OpsMgrExtended PowerShell / SMA Module

Written by Tao Yang


The OpsMgrExtended PowerShell and SMA module is a project that I have been working on since August last year. I am very glad that it is now ready to be released to the community.

This module is designed to fill some gaps in the current OpsMgr automation solutions provided natively in System Center 2012 suite. This module can be used as a System Center Service Management Automation (SMA) Integration Module, as well as a standalone PowerShell module.

Currently, the following products are available when comes to creating automation solutions for OpsMgr:

  • OpsMgr native PowerShell module
  • OpsMgr Integration Pack for System Center Orchestrator
  • OpsMgr portable Integration Module for System Center Service Management Automation

In my opinion, each of above listed serves their purpose, but also have some limitations.

OpsMgr PowerShell Module
An OpsMgr native component that can be installed on any computers running PowerShell. With the System Center 2012 R2 release, this module offers 173 cmdlets. However, most of them are designed for administrative tasks, it is lacking features such as creating management pack components (i.e. rules, monitors, etc.).

OpsMgr Integration Pack for System Center Orchestrator

Microsoft has released a version of this IP for every release of OpsMgr 2012. However, the functionalities this IP provides is very limited.


As you can see, it only offer 8 activities. It also requires the corresponding version of the OpsMgr operational console to be manually installed on each Orchestrator runbook server and runbook designer computer before you can executing runbooks which utilise these activities. The requirement for the operations console introduces some limitations:

  • You cannot install multiple versions of OpsMgr operations console on a same computer. – This means if you have multiple versions of OpsMgr (i.e. 2012 and 2007), you MUST use separate Orchestrator runbook servers and runbook designer computers for runbooks targeting these systems.
  • If you also need to install OpsMgr agents on these runbook servers, you can ONLY install the agent that is the same version of the operations console. – This means if you do have both OpsMgr 2007 and 2012 in your environment, the runbook servers for your OpsMgr 2007 management groups cannot be monitored by OpsMgr 2012 (unless you implement less efficient agentless monitoring for these runbook servers).

OpsMgr SMA Portable Integration Module

When SMA was released as part of System Center 2012 R2, it was shipped with an OperationsManager portable module built-in to the product.


The portable modules are not real modules. They are like the middle man between your runbooks and the “real” Integration Modules. It takes your input parameters and call the activities from the real module for you. i.e.


In order to use the OperationsManager-Portable module in SMA, you must firstly manually install the “real” OpsMgr 2012 PowerShell module on all the SMA runbook servers. One of the great feature that SMA offers is being able to automatically deploy Integration Modules to all runbook servers once been imported into SMA. But for the portable modules, this is not the case, as you must manually install the “real” modules by yourself. The other limitation is, it still only just offers whatever is available in the native OpsMgr 2012 PowerShell module.

With all these limitations in mind, I have developed a brand new custom OpsMgr PowerShell / SMA Module OpsMgrExtended to fill some of these gaps.


OpsMgrExtended Introduction

Back in January 2015, I have presented a work-in-progress version of this module in the Melbourne MVP Community Camp. At that time, I said it was going to be released in few weeks time. Unfortunately, I just couldn’t dedicate enough time on this project and I wanted to add few additional functions in this module, I only managed to finalise it now (5 months later). My presentation has been recorded, you can watch it and download the slide deck from my previous post: http://blog.tyang.org/2015/01/23/microsoft-mvp-community-camp-2015-session-sma-integration-module-opsmgrextended/

OpsMgr SDK Assemblies

The core component of all above mentioned native solutions is the OpsMgr SDK. All of them requires OpsMgr SDK assemblies to be installed onto the computer running the scripts and runbooks separately. This is done via the install of the OpsMgr Operations console and the PowerShell console. When you install the Operations Console or the PowerShell console onto a computer, the OpsMgr SDK assemblies are installed into the Global Assembly Cache (GAC) on this computer.

To make OpsMgrExtended module TRULLY portable and independent, I have placed the 3 OpsMgr 2012 R2 SDK DLLs into the module base folder. The PowerShell code in the OpsMgrExtended module would try to load the SDK assemblies from the GAC, but if the assemblies are not located in the GAC, it would leverage the 3 SDK DLLs that are located in the module base folder. By doing so, there is NO requirement for installing ANY OpsMgr components before you can start using this module.

Why Using OpsMgrExtended?

“If you think you will do a task twice – automate it!

When comes to automation, this is my favourite quote, from Joe Levy, a program manager in the System Center Orchestrator team. I have been managing large OpsMgr environments for many years. At my last job, I was pretty much the single point of contact for OpsMgr. Based on my own personal experience, there are a lot of repetitive tasks when managing OpsMgr infrastructures. This is why few years ago I spent few months of my spare time and developed the OpsMgr Self Maintenance MP. This MP was targeting the administrative workflows which normally carried out by OpsMgr admins.

Other than the day-to-day tasks the Self Maintenance MP has already covered, I still find a lot of repetitive tasks that do not fall into that category. for example, management packs development. I have been writing management packs for few years. Based on my own experience and the feedbacks I got from the community, I believe a lot of OpsMgr customers, or the broader community are facing the following challenges:

MP development can get very hard, and there are not many good MP developers out there.

Most of the SCOM administrators in your organisation would fall into the “IT Pro” category. MP development can get very complicated and definitely a skillset more suitable for developers  rather than IT Pro’s. There are simply not many MP developers out there. I’ve been heavily involved in the OpsMgr community for few years now, I can confidently state that if I don’t know ALL the good MP developers in the OpsMgr community, I think I know most of them. So trust me when I say there are not many around. Sometimes, I would imagine, world would be a better place if MP Development skills are as popular as ConfigMgr OSD skills (which pretty much every System Center specialist I know has got that written down on their CV’s).

It is hard to learn MP development

I’m not saying this skill is very hard to learn. But I don’t believe there are enough good & structured materials for people who wants to pick up this skill. When I started writing management packs, I was really struggling in the beginning. My friend and fellow Melbourne based MVP Orin Thomas once said to me, that he believes if you want people to start using your products, you need to make sure you invest heavily in developing trainings. I think what Orin said was spot on. I believe this is one of the main reasons that there are not many good MP developers around.

Too many toolsets

For beginners, you can use the OpsMgr operational console to write some really basic management pack elements. Most of the OpsMgr specialist who claims they can write management packs probably would use either the OpsMgr 2007 R2 Authoring Console, or the 3rd party product Silect MPAuthor. They are user-friendly, GUI based authoring tools and there are relatively easy to learn. Then for seasoned MP developers, they would normally use Visual Studio Authoring Extension (VSAE) – which is just a extension in Visual Studio, no GUI, you need to REALLY understand the management pack XML schema to be able to use this tool. not to mention Visual Studio is not free (Using it to author MPs for commercial purpose or for large organisations does not qualify you for using the free Community edition). It is hard to explain when someone completely new in this area ask me “what tool do people use to write management packs?”

How about PowerShell?

Most IT Pros should by now already very familiar with Windows PowerShell. Wouldn’t it be nice if I can use PowerShell to create OpsMgr monitors and rules? For example, if I need to monitor a Windows service, how about use a cmdlet like “New-ServiceMonitor” to create this service monitor in my OpsMgr management group?

Well, this is one of the areas I’m trying to cover in the OpsMgrExtended module.

When I was managing a large OpsMgr environment in my previous job, as much as I like developing management packs, sometimes, I still consider it as repetitive tasks. Every now and then, people would come to me and asked me to monitor service X, monitor perf counter Y, collect events Z, etc. I’ve done it once, I’ve learnt how to do it, I don’t want to do it over and over again, simply because I’m not a robot and I HATE repetitive tasks! Not to mention all the ITIL overhead that you have to put up with (i.e. testing, managing Dev, Test, Production environments, change management, release management, etc.). When there is a monitoring requirement, why can’t my customer simply fill out a request and whatever he / she needs to create gets automatically created? – Same way a normal end user would request for a piece of software to be installed on his / her PC? I don’t have to be involved (neither do I want to) when every time someone needs to get something created in OpsMgr. I’d rather spend my time working on some more complicated solutions Smile.

Another good example would be, over a year ago, I was helping a colleague from another team setting up a brand new OpsMgr 2012 environment to monitor couple of thousand servers within our organisation. My colleague has spent a lot of time, back and forth with the Windows server support team to identify their requirements. In the end, after I waited a long period of time, they finally gave me a spreadsheet which consists of 20-30 services they need to monitor. Imagine for most of the OpsMgr administrators who has never used VSAE before, this would take a lot of time and maybe a lot of copy-paste to accomplish when using Authoring Console, MPAuthor or even NotePad++. For me, although I used VSAE and I knew how to develop custom snippet templates in VSAE, still took me like 20-30 minutes to develop such snippet template, then generated MP fragment, built MP, testing, pushing to Production etc. And since our customers has already identified their requirements, I shouldn’t need to be involved at all if we have an automation solution in place.

As I demonstrated in my 2015 Melbourne MVP Community Camp presentation (demo 2, start from 28:05, link provided above), I have designed a set of tasks for customers to request new monitors:

  1. New New blank unsealed MP
  2. Create a unit monitor in a “Test” management group
  3. Created a SMA runbook that runs daily and populates the MP list of my Test MG onto a SharePoint List
  4. When customers have tested the newly created monitor and happy with it, he / she can go to the SharePoint List, locate the specific MP where the monitor is stored, and use a drop-down box to copy the MP to the production environment.

This process has covered the entire process of creating, testing and implementing the new SCOM monitoring requirements without getting OpsMgr administrators involved at all!

What functions / activities are included in this release of OpsMgrExtended

In the first release of this module, I have included 34 PowerShell functions (if you watched the presentation recording, there were 29 back in January, I’ve added few more since). These functions can be grouped into 3 categories:

SDK Connection Functions

  • Import-OpsMgrSDk
    • Load the SDK assemblies. It will firstly try to load them from GAC, if the assemblies are not in GAC, it will load them from the SDK DLLs from the module base folder.
  • Install-OpsMgrSDK
    • Install the OpsMgr SDK DLLs from the module base folder to the GAC
  • Connect-OMManagementGroup
    • Establish connection to the OpsMgr management group by specifying a management server name (and optional alternative username and password).

Administrative Tasks

  • Approve-OMManualAgents
    • Approve manually installed OpsMgr agents that meet the naming convention.
  • Backup-OMManagementPacks
    • Backup OpsMgr management packs (unsealed and sealed).
  • Add-OMManagementGroupToAgent
    • Configure an OpsMgr agent to report to a specific management group using WinRM.
  • Remove-OMManagementGroupFromAgent
    • Remove a management group configuration from an OpsMgr agent using WinRM.
  • Get-OMManagementGroupDefaultSettings
    • Get OpsMgr management group default settings via OpsMgr SDK. A System.Collections.ArrayList is returned containing all management group default settings. Each setting in the arraylist is presented in a hashtable format.
  • Set-OMManagementGroupDefaultSetting
    • Set OpsMgr management group default settings.

Basic Authoring Tasks

  • Get-OMManagementPack
    • Get a particular management pack by providing the management pack name or get all management pack in an OpsMgr management group using OpsMgr SDK.
  • New-OMManagementPack
    • Create a new unsealed management pack in an OpsMgr management group.
  • Remove-OMManagementPack
    • Remove a management pack from an OpsMgr management group.
  • Copy-OMManagementPack
    • Copy an unsealed management pack from a source OpsMgr management group to the destination. management group.
  • New-OMManagementPackReference
    • Add a management pack reference to an unsealed management pack.
  • New-OM2StateEventMonitor
    • Create a 2-state event monitor in OpsMgr.
  • New-OM2StatePerformanceMonitor
    • Create a 2-state performance monitor in OpsMgr.
  • New-OMPerformanceCollectionRule
    • Create a performance collection rule in OpsMgr.
  • New-OMEventCollectionRule
    • Create an event collection rule in OpsMgr.
  • New-OMServiceMonitor
    • Create a Windows service monitor in OpsMgr.
  • New-OMInstanceGroup
    • Create an empty instance group in OpsMgr using OpsMgr SDK. The group membership must be populated manually or via another script.
  • New-OMComputerGroup
    • Create an empty computer group in OpsMgr using OpsMgr SDK. The group membership must be populated manually or via another script.
  • New-OMConfigurationOverride
    • Create a configuration (parameter) override in OpsMgr using OpsMgr SDK.
  • New-OMPropertyOverride
    • Create a property override in OpsMgr using OpsMgr SDK.
  • New-OMOverride
    • Create an override in OpsMgr using OpsMgr SDK. This function would detect whether it’s a property override or configuration override and call New-OMPropertyOverride or new-OMConfigurationOverride accordingly.
  • Remove-OMGroup
    • Remove an instance group or computer group in OpsMgr using OpsMgr SDK.
  • Remove-OMOverride
    • Remove an override in OpsMgr.
  • Get-OMDAMembers
    • Get monitoring objects that are members of a Distributed Application in OpsMgr using OpsMgr SDK. By default, this function only retrieves objects one level down. Users can use -Recursive parameter to retrieve all objects within the DA hierarchy.
  • New-OMAlertConfiguration
    • Create a new OpsMgrExtended.AlertConfiguration object that can be passed to the New-OMRule function as an input. This object is required for the New-OMRule function when creating an alert generating rule.
  • New-OMModuleConfiguration
    • Create a new OpsMgrExtended.ModuleConfiguration object that can be passed to the New-OMRule function as an input.
  • New-OMRule
    • Create a rule in OpsMgr by specifying data source modules, optional condition detection module, write action modules and also alert configuration when creating an alert generating rule. This function can be used to create any types of rules in OpsMgr.
  • New-OMWindowsServiceTemplateInstance
    • Create a Windows Service monitoring template instance in OpsMgr.

Advanced Authoring Tasks

  • New-OMTCPPortCheckDataSourceModuleType
  • New-OMTCPPortCheckMonitorType
  • New-OMTCPPortMonitoring

Last year, when I asked few OpsMgr focused MVPs for advice and feedbacks, my buddy Dieter Wijckmans suggested me to create a function that creates a TCP Port monitoring template instance. When I had a look, I did not like the MP elements created by this template. As I explained in my MVP Community Camp presentation (Demo 3, starts at 47:13 in the recording), I didn’t like the module type and monitor types created by the TCP Port monitoring template because many values have been hard coded in the modules and the monitor types did not enable On-Demand detections. Therefore, instead of creating an instance of this template using SDK, I’ve taken the hard route, spent a week, written 1,200 lines of PowerShell code, recreated all the MP elements the way I wanted.

When you use New-OMTCPPortMonitoring function from this module, it creates the following items:

  • Class Definition for TCP Port Watcher and various groups
  • Class Relationships
  • Class and Relationship Discoveries
  • Data Source Module Type
  • Monitor Type
  • Performance Collection Rule
  • 4 Unit Monitors and a dependency monitor
  • Discovery Overrides

The monitors created by New-OMTCPPortMonitoring supports On-Demand detection (which can be triggered by clicking the “Recalculate Health” button in Health Explorer), and I have variablised the data source module type and monitor type, so they can be reused for other workflows.

Establishing Connections to OpsMgr Management Groups

Configuring SMA Integration Module

When using this module in SMA, you may create a connection object to your OpsMgr management group.



  • Connection Type: Operations Manager SDK
  • Name: Name of this SMA connection object
  • Description: Description of this SMA connection
  • ComputerName: One of the OpsMgr management servers
  • UserName: A Service Account that has OpsMgr administrator access
  • Password: Password for the service account


Connecting in Normal PowerShell Scripts

When this module is used as a normal PowerShell module, all the functions that require OpsMgr management group connections support the following 3 parameters:

  • SDK: One of the OpsMgr management servers
  • -Username (optional): Alternative account to connect to OpsMgr management group.
  • -Password (optional): the password for the alternative account.


Getting Help and More Information

I have included help information for every function in this module. You can access if using Get-Help cmdlet.

i.e. Get-help New-OMRule –Full


Once imported in SMA, you can also see the description for each function in the WAP Admin portal:



Getting Started

I have written many sample runbooks for this module. Initially, my plan was to release these sample runbooks together with the module. Then I had a second thought, I think instead of releasing these samples now, I will make this a blog series and continue writing posts explaining how to use this module for different scenarios. I believe by doing so, it will help readers better understand the capability this module brings. I will name this series “Automating OpsMgr” and consider this is Part 1 of this series.

System Requirements

The minimum PowerShell version required for this module is 3.0.

The entire module and sample runbooks were developed on Windows Server 2012 R2, Windows 8.1, OpsMgr 2012 R2 and PowerShell version 4.0.

I have not test this module on OpsMgr 2012 RTM and SP1. Although the SDK assembly version is the same between RTM, SP1 and R2, I cannot guarantee all functions and upcoming sample runbooks would work 100% on RTM and SP1 versions. If you have identified any issues, please let me know.

I have performed very limited testing on PowerShell 5.0 Preview. I cannot guarantee it will work with PowerShell 5.0 100%. But if you manage to find any issues on PowerShell 5.0, please let me know.


Where Can I Download this Module?

This module can be downloaded from TY Consulting’s web site from link below:


I’m releasing this module under Apache License Version 2.0. If you do not agree with the term, please do not download or use this module.

Because this module requires OpsMgr 2012 SDK DLLs, and I am not allowed to distribute these DLLs (refer to System Center 2012 R2 Operations Manager EULA Section 7 Scope of License, which can be located on the OpsMgr 2012 R2 DVD under Licenses folder).


Therefore, once you’ve downloaded this module, you will need to manually copy the following 3 DLLs into the module folder:

  • Microsoft.EnterpriseManagement.Core.dll
  • Microsoft.EnterpriseManagement.OperationsManager.dll
  • Microsoft.EnterpriseManagement.Runtime.dll

These DLLs can be found on your OpsMgr management server, under <OpsMgr Install Dir>\Server\SDK Binaries:


Copy them into the module folder:


If it’s intended to be used in SMA, you will need to zip the folder back after DLLs been copied to the folder, then import the module in SMA.

Looking back, this has has been a very long journey – I have written around 6,800 lines of code for this module alone, not including all the sample runbooks that I’m going to publish for this blog series. I hope the community would find it useful, and please feel free to contact me if you have any new ideas or suggestions.

This is all I have for the Part 1 of this new series. In the next couple of days, I will discuss how to use the OpsMgrExtended module to create ConfigMgr log collections rules for OMS (As I previously blogged here.)

Updated ConfigMgr 2012 (R2) Client Management Pack Version

Written by Tao Yang


It’s only been 2 weeks since I released the last update of this MP (version Soon after the release, Mr. David Allen, a fellow System Center CDM MVP contacted me, asked me to test his SCCM Compliance MP, and possibly combine it with my ConfigMgr 2012 Client MP.

In the ConfigMgr 2012 Client MP, the OVERALL DCM baselines compliance status are monitored by the DCM Agent class, whereas in David’s SCCM Compliance MP, each DCM Baseline is discovered as a separate entity and monitored separately. Because of the utilisation of Cook Down feature, comparing with the approach in the ConfigMgr 2012 Client MP, this approach adds no additional overhead to the OpsMgr agents.

David’s MP also included a RunAs profile to allow users to configure monitoring for OpsMgr agents using a  Low-Privileged default action account.

I think both of the features are pretty cool, so I have taken David’s MP, re-modelled the health classes relationships, re-written the scripts from PowerShell to VBScripts, and combined what David has done to the ConfigMgr 2012 Client MP.

If you (the OpsMgr administrators) are concerned about number of additional objects that are going to be discovered by this release (every DCM baseline on every ConfigMgr 2012 Client monitored by OpsMgr), the DCM Baselines discovery is disabled by default, I have taken an similar approach as configuring Business Critical Desktop monitoring, there is an additional unsealed MP in this release to allow you to cherry pick which endpoints to monitor in this regards.

What’s New in Version

Other than combining David’s SCCM Compliance MP, there are also few other updates included in this release. Here’s the full “What’s New” list:

Bug Fix: ConfigMgr 2012 Client Missing Client Health Evaluation (CCMEval) Execution Cycles Monitor alert parameter incorrect

Added a privileged RunAs Profile for all applicable workflows

Additional rule: ConfigMgr 2012 Client Missing Cache Content Removal Rule

Enhanced Compliance Monitoring

  • Additional class: DCM Baseline (hosted by DCM agent)
  • Additional Unit monitor: ConfigMgr 2012 Client DCM Baseline Last Compliance Status Monitor
  • Additional aggregate and dependency monitors to rollup DCM Baseline health to DCM Agent
  • Additional State View for DCM Baseline
  • Additional instance groups:
    • All DCM agents
    • All DCM agents on server computers
    • All DCM agents on client computers
    • All Business Critical ConfigMgr 2012 Client DCM Agents
  • Additional unsealed MP: ConfigMgr 2012 Client Enhanced Compliance Monitoring
    • Override to enabled DCM baseline discovery for All DCM agents on server computers group
    • Override to disable old DCM baseline monitor for All DCM agents on server computers group
    • Discovery for All Business Critical ConfigMgr 2012 Client DCM Agents (users will have to populate this group, same way as configuring business critical desktop monitoring)
    • Override to enabled DCM baseline discovery for All Business Critical ConfigMgr 2012 Client DCM Agents group
    • Override to disable old DCM baseline monitor for All Business Critical ConfigMgr 2012 Client DCM Agents group
  • Additional Agent Task: Evaluate DCM Baseline (targeting the DCM Baseline class)

Additional icons

  • Software Distribution Agent
  • Software Update Agent
  • Software Inventory Agent
  • Hardware Inventory Agent
  • DCM Agent
  • DCM Baseline


Enhanced Compliance Monitoring

Version has introduced a new feature that can monitor assigned DCM Compliance Baselines on a more granular level. Prior to this release, there is a unit monitor targeting the DCM agent class and monitor the overall baselines compliance status as a whole. Since version, each individual DCM baseline can be discovered and monitored separately.

By default, the discovery for DCM Baselines is disabled. It needs to be enabled on manually via overrides before DCM baselines can be monitored individually.


There are several groups can be used for overriding the DCM Baseline discovery:


Scenario Override Target
Enable For All DCM Agents Class: ConfigMgr 2012 Client Desired Configuration Management Agent
Enable For Server Computers Only Group: All ConfigMgr 2012 Client DCM Agents on Server OS
Enable For Client Computers Only Group: All ConfigMgr 2012 Client DCM Agents on Client OS
Enable for a subset of group of computers Manually create an instance group and populate the membership based on the “ConfigMgr 2012 Client Desired Configuration Management Agent” class

Note: Once the DCM Baseline discovery is enabled, please also disable the “ConfigMgr 2012 Client DCM Baselines Compliance Monitor” for the same targets as it has become redundant.

Once the DCM baselines are discovered, their compliance status is monitored individually:



Additionally, the DCM Baselines have an agent task called “Evaluate DCM Baseline”, which can be used to manually evaluate the baseline. This agent task performs the same action as the “Evaluate” button in the ConfigMgr 2012 client:


ConfigMgr 2012 Client Enhanced Compliance Monitoring Management Pack

An additional unsealed management pack named “ConfigMgr 2012 Client Enhanced Compliance Monitoring” is also introduced. This management pack includes the following:

  • An override to enable DCM baseline discovery for “All ConfigMgr 2012 Client DCM Agents on Server OS” group.
  • An override to disable the legacy ConfigMgr 2012 Client DCM Baselines Compliance Monitor for “All ConfigMgr 2012 Client DCM Agents on Server OS” group.
  • A blank group discovery for the “All Business Critical ConfigMgr 2012 Client DCM Agents” group
  • An override to enable DCM baseline discovery for “All Business Critical ConfigMgr 2012 Client DCM Agents” group.
  • An override to disable the legacy ConfigMgr 2012 Client DCM Baselines Compliance Monitor for “All Business Critical ConfigMgr 2012 Client DCM Agents” group.


In summary, this management pack enables DCM baseline discovery for all ConfigMgr 2012 client on server computers and switch from existing “overall” compliance baselines status monitor to the new more granular compliance baseline status monitor which targets individual baselines. This management pack also enables users to manually populate the new “All Business Critical ConfigMgr 2012 Client DCM Agents” group. Members in this group will also be monitored the same way as the server computers as previously mentioned.

Note: Please only use this management pack when you prefer to enable enhanced compliance monitoring on all server computers, otherwise, please manually configure the groups and overrides as previously stated.


New RunAs Profile for Low-Privilege Environments

Since almost all of the workflows in the ConfigMgr 2012 Client management packs require local administrative access to access various WMI namespaces and registry, it will not work when the OpsMgr agent RunAs account does not have local administrator privilege.

Separate RunAs accounts can be created and assigned to the “ConfigMgr 2012 Client Local Administrator RunAs Account” profile.

RunAs Account Example:


RunAs Profile:


For More information about OpsMgr RunAs account and profile, please refer to: http://technet.microsoft.com/en-us/library/hh212714.aspx

Note: When assigning a RunAs Account to the “ConfigMgr 2012 Client Local Administrator RunAs Account” profile, you will receive an error as below:


Please refer to the MP documentation section “14.3 Error Received when Adding RunAs Account to the RunAs Profile” for instruction on fixing this error.

New Rule: Missing Cache Content Removal Rule

This rule runs every 4 hours by default and checks if any registered ConfigMgr 2012 Client cache content has been deleted from the file system. When obsolete cache content is detected, this rule will remove the cache content entry from ConfigMgr 2012 client via WMI and generates an informational alert with the details of the missing cache content:


Additional Icons:

Prior to this release, only the top level class ConfigMgr 2012 Client has its dedicated icons. I have spent a lot of time looking for icons for all other classes, I managed to produce icons for each monitoring classes in this release:



Note: I only managed to find high res icons for the Software Distribution Agent and the Software Update Agent (extracted from various DLLs and EXEs). I couldn’t find a way to extract icons from AdminUI.UIResources.DLL – where all the icons used by SCCM are stored. So for other icons, I had to use SnagIt to take screenshots of these icons. You may notice the quality is not that great, but after few days effort trying to find these icons, this is the best I can do. If you have a copy of these icons (res higher than 80×80), or know a way to extract these icons from AdminUI.UIResources.dll, please contact me and I’ll update them in the next release.


BIG thank you to David Allen for his work on the SCCM Compliance MP, and also helping me test this release!

You can download the ConfigMgr 2012 Client MP Version HERE.

Until next time, happy SCOMMING!

ConfigMgr 2012 (R2) Client Management Pack Updated to Version

Written by Tao Yang

4th October, 2014: This MP has been updated to Version Please download the latest version from this page: http://blog.tyang.org/2014/10/04/updated-configmgr-2012-r2-client-management-pack-version-1-2-0-0/.

OK, after few weeks of hard work, the updated version of the ConfigMgr 2012 (R2) Client MP is finally here.

The big focus in this release is to reduce the noise this MP generates. In the end, besides the new and updated components I have introduced in this MP, I also had to update every single script used by the monitors and rule.

The changes since previous version (v1.0.1.0) are listed below:

Bug Fixes:

  • Software Update agent health not rolled up (dependency monitors was missed in the previous release).
  • SyncTime in some data source modules were not correctly implemented
  • Typo in Pending Software update monitor alert description
  • The “All ConfigMgr 2012 Client computer group” population is incorrect. It includes all windows computers, not just the ones with ConfigMgr 2012 client installed.
  • Many warning alerts “Operations Manager failed to start a process” generated against various scripts used in this MP. It has been identified the issue is caused by the OpsMgr agent executing the workflows when the SMS Agent Host service is not running. This typically happened right after computer startup or reboot because SMS Agent Host service is set to Automatic (Delayed). All the scripts that query root\ccm WMI namespace have been re-written to wait up to 3 minutes for the SMS Agent Host to start (if it’s not already started). Hopefully this will reduce the number of these warning alerts. The updated scripts will also try to catch such condition so the alert indicates the actual issue:



Additional Items:

  • A diagnostic task and a recovery task for the CcmExec service monitor. The diagnostic task detects if the system uptime is longer than 5 minutes (overrideable), if the system uptime is longer than 5 minutes, the recovery task will start the SMS Agent Host service. Both the service monitor and the recovery task are disabled by default. –If you decide to use this service monitor and the recovery task (both disabled by default), it would help to reduce the number of failed start a process warning alerts caused by stopped SMS Agent Host service.
  • Monitor if the SCCM client has been placed into the Provisioning mode for a long period of time (Consecutive Sample monitor) (http://thoughtsonopsmgr.blogspot.com.au/2014/06/sccm-w7-osd-task-sequence-with-install.html)
  • The Missing CCMEval Consecutive Sample unit monitor has been disabled and replaced by a new monitor. The new monitor is no longer a consecutive sample monitor, it will simply detect if the CCMEval job has missed 5 consecutive cycles (number of missing cycles is overrideable). This new monitor is designed to simplify the detection process and to address the false alerts the previous consecutive monitor generates.
  • Monitor CCMCache size. Alert when the available free space for the CCMCache is lower than 20%. Some ConfigMgr client computers may be hosted on expensive storage devices (i.e. 90% of my lab machines are now running on SSD). Therefore I think it is necessary to monitor the ccmcache usage.  This monitor provides an indication on how much space has been consumed by ccmcache folder.
  • Agent Task: Delete CCMCache content


Updated Items:

  • Pending Reboot monitor updated to allow users to disable any of the 4 areas that the monitor checks for reboot (Pending File Rename operation is disabled by default because it generates too many alerts):
    • Component Based Serving
    • Windows Software Update Agent
    • SCCM Client
    • Pending File Rename operation
  • The Missing CCMEval monitor is disabled and superseded.
  • All consecutive samples monitors have been updated. The System.ConsolidatorCondition condition detection module has been replaced by the <MatchCount> configuration in the System.ExpressionFilter module (New in OpsMgr 2012) to consolidate consecutive samples. It simplifies the configuration and tuning process of these consecutive sample monitors.
  • Additional events logged in the Operations manager event log by various scripts. – help with troubleshooting. Please refer to Appendix A of the MP documentation for the details of these events.


Upgrade Tip

This version is in-place upgradable from the previous version. However, since there are additional input parameters introduced to the scripts used by monitors and rule, you may experience a large number of “Operations Manager failed to start a process” warning alert right after the updated MPs have been imported and distributed to the OpsMgr agents. To workaround this issue, I strongly recommend to place the “All ConfigMgr 2012 Clients” group into maintenance mode for 1 hour before importing the updated MPs. To do so, simply go the the “Discovered Inventory” view, and change the target type to “All ConfigMgr 2012 Clients”, and place the selected group into maintenance mode.


Special Thanks

I’d like to thank all the people who has provided the feedback since the last release and spent time helped with testing this version. I’d like to specially thank Stanislav Zhelyazkov for this valuable feedbacks and the testing effort. I’d also like to Thank Marnix Wolf for his blog post which has helped me built the Provisioning Mode Consecutive Sample monitor in this MP.



Download ConfigMgr 2012 (R2) Client Management Pack

OpsMgr 2012 Self Maintenance Management Pack

Written by Tao Yang

This blog has been a bit quiet lately because of 2 reasons: FIFA World Cup and I’ve been updating the OpsMgr 2012 Self Maintenance MP. 🙂

What’s new in version

  • Corrected spelling mistake in Management Server maintenance mode watcher display name
  • Updated knowledge article for OpsMgr 2012 Self Maintenance Detect Manually Closed Monitor Alerts Rule
  • Additional Monitor: OpsMgr 2012 Self Maintenance Management Server Default Action Account OpsMgr Admin Privilege Monitor
  • Additional Monitor: OpsMgr 2012 Self Maintenance Management Server Default Action Account Local Admin Privilege Monitor
  • Additional Rule: OpsMgr 2012 Self Maintenance Obsolete Management Pack Alias Detection Rule
  • Additional Agent Task: Get Workflow Name(ID)
  • Additional Agent Task: Reset Monitor Health State
  • Additional Agent Task: Remove Obsolete MP References

Additional Monitors to check if management servers action account has local admin on management servers and OpsMgr privileges

I often get emails from people who are having issues configuring workflows in the Self Maintenance MP. I found one of a common issues is that the default action account for management servers does not required privileges. Therefore I created 2 monitors in this release to monitor if the MS action account has local administrator and OpsMgr administrator privileges.



Additional Rule: OpsMgr 2012 Self Maintenance Obsolete Management Pack Alias Detection Rule

As I mentioned in my previous post PowerShell Script: Remove Obsolete References from Unsealed OpsMgr Management Packs, I’ve created a rule that detects obsolete MP references in unsealed management packs. The difference between the stand alone script (from previous post) and this rule is, this rule would only detect obsolete MP references, it will not try to remove them. Operators can use the “Remove Obsolete MP References” agent task manually remove them (or using the standalone script I published earlier).


Additional Agent Task: Remove Obsolete MP References

This task targets All Management Servers Resource Pool and can be used in conjunction with the Obsolete Management Pack Alias Detection Rule to delete obsolete MP references from unsealed management packs.


Additional Agent Tasks: “Get Workflow Name(ID)” and “Reset Monitor Health State”


Previously, few people have suggested me to provide a method to reset all instances of a particular monitor. Recently, Cameron Fuller showed me a script from Matthew Dowst’s blog post and suggested me to add this into the Self Maintenance MP.

The script from Matthew’s blog resets health state of all instances of monitors with a given display name. In my opinion, this is not granular enough as there are monitors sharing same display name, we can not use display name to uniquely identify a particular monitor.



Therefore, when I was writing the script for the Reset Monitor Health State agent task, I used monitor name instead of display name. However, since the monitor name is actually not viewable in the Operations Console, I had to create another agent task to get the name of a workflow (monitors, rules and discoveries).

i.e. let’s use the “Computer Browser Service Health” monitors as an example.

Get the monitor(s) using SCOM PowerShell Module:


In my environment, there are 2 monitors that have the same display name. the actual monitor name is highlighted in the red rectangles. the names are unique. It is actually the MP element ID in the management pack where the monitor is coming from:


So in order to use the “Reset Monitor Health State” task, operators firstly need to identify the monitor name (MP element ID), then paste it into an override field of the task. To make it easier, we can use the “Get Workflow Name(ID)” agent task to get the name:


Then copy and paste the monitor name into the “MonitorName” override parameter of the “Reset Monitor Health State”:




Where to find the detailed information for these additional items?

I have only covered a very high level overview of these additional workflows in this post. the detailed information can be found in the updated MP documentation (From Section 5.2.24 to 5.2.29):


Please make sure you read each section before enabling / using each workflow!


I’d like to thank Cameron Fuller, Bob Cornelissen and Raphael Burri for the suggestions and testing effort. Also, thanks Matthew Dowst for the original scripts in his posts.

Lastly, if you have suggestions or issues / questions that are not documented in the documentation, please feel free to contact me.


Management Pack for the SCOM 2012 Maintenance Mode Scheduler

Written by Tao Yang

I’ve been working on a SCOM management pack during my spare time over the last couple of weeks. This management pack provides some basic monitoring for the SCOM 2012 Maintenance Mode Scheduler Version 2 developed by Tim McFadden (http://www.scom2k7.com/scom-2012-maintenance-mode-scheduler-2/).

The purpose of this MP solution is to help this web-based maintenance mode scheduler integrate better within SCOM. The solution contains 2 management pack files. The following items are included:

Class definitions and discoveries for the SCOM 2012 Maintenance Mode Scheduler.

The monitoring MP defines 2 classes. a Microsoft.Windows.ComputerRole based class called “SCOM 2012 Maintenance Mode Scheduler”, which has many properties defined representing various application settings.


There is also an unhosted class called “SCOM 2012 Maintenance Mode Scheduler Event Collector”. This class runs an event collection rule which collects the new schedule jobs creation events even when the Maintenance Mode Scheduler computer is in maintenance mode.

Automatically delete any finished maintenance mode schedules

A rule runs once a day and executes a script to scan through all Windows Scheduled Tasks created by the maintenance mode scheduler and deletes any tasks that does not have a Next Run Time (i.e. tasks that only runs once and it has already be executed). For auditing purposes, when deleting each old (finished) task, an event is also written to both SCOM operational and Data Warehouse databases.

The purpose of this rule is to eliminate the needs for manual clean-up of old scheduled tasks created by the maintenance mode scheduler.

Event Collection rule for new schedule job creation events (Event ID 711)

When the Maintenance Mode Scheduler is configure to write auditing events to Windows event log, a event collection rule can be utilized to collect these events and store them in SCOM databases.

image image

Monitor the credential of SCOM Data Access Account configured in the maintenance mode scheduler.

A monitor that checks if the credential of the SCOM Data Access Account configured in SCOM 2012 Maintenance Mode Scheduler is still valid. This is to ensure SCOM operators get notified if the Data Access account password has been changed, or the account has been locked out, disabled or deleted.

Monitor if the SCOM Data Access Account has local administrator privilege on the computer hosting the maintenance mode scheduler.

A monitor that checks if the SCOM Data Access Account configured in SCOM 2012 Maintenance Mode Scheduler has local administrator privilege on the computer hosting the scheduler. Windows local administrator access is required to create Windows Scheduled task.

Console task to launch the SCOM 2012 Maintenance Mode Scheduler web site using the default web browser.


New scheduler jobs event report


Maintenance Mode Scheduler dashboard (Provided by the SCOM 2012 Maintenance Mode Scheduler Dashboard management pack).


This dashboard contains:

  • Maintenance Mode Scheduler state widget
  • PowerShell Grid widget that lists new schedule jobs events
  • PowerShell Web Browser widget that displays the Maintenance Mode Scheduler web page.

Maintenance Mode Scheduler State view


New Jobs Event View


Deleted Jobs Event view



I’d like to thank Tim McFadden for producing such a good maintenance mode tool for SCOM 2012, and also the valuable feedbacks and suggestions provided for this management pack.


For me, while I was writing this MP, I’ve accomplished few of my “firsts”:

  • First time writing scripts for IIS (as this is a web based application).
  • First time writing reports in VSAE (I have to say for me, it is much easier than using old Authoring console)
  • First time using the new PowerShell widgets from the SCOM 2012 R2 UR2 updates (well, they’ve only just come out).

So I was really enjoying it, although it took a lot longer than what I expected (due to the IIS scripting challenges I had).

I hope this management pack would help the community to better adopt and integrate the SCOM 2012 Maintenance Mode Scheduler into their SCOM 2012 environments.

The Management packs and documentation can be downloaded HERE. Please make sure you read the documentation before importing the MPs. there are few pre-requisites for the MPs.

Lastly, as always, please feel free to contact me if you have issues / questions / suggestions.

ConfigMgr 2012 (R2) Clients Management Pack Released

Written by Tao Yang

ConfigMgr 2012 Client MP IconTime flies, I can’t believe it’s been over 7 months since I posted the beta version of the ConfigMgr 2012 client MP for testing. I haven’t forgotten about this MP (because it’s one of the deliverables for the System Center 2012 upgrade project that I’ve been working on for the last 12 months or so). Today, I finally managed to finish updating this MP, it is ready for final release (Version

I didn’t manage to get many feedbacks since the beta version was released. so it’s either a good thing that everyone’s happy about it, or it’s really bad that no one bothered to use it 🙂 . I would hope it’s because that everyone’s happy about it 🙂

Anyways, below is a list of what’s changed.

Display Name for the ConfigMgr 2012 Client Agents are changed.

in beta version, the display names various client agents(DCM agents, Hardware Inventory agents, etc.) were hardcoded to the client agent name:


I don’t believe it is too user friendly when working in the Operations Console, so in this version, I’ve changed them to be the actual computer name:


Bug Fix: Incorrect Member Monitors for various client agents dependency monitors.

I made a mistake when writing the client agents dependency monitor’s snippet template in VSAE. As the result, all dependency monitors (for availability, performance, configuration and security health) had client agents availability health aggregate monitors as member monitors.


This is now fixed. the correct member monitor is assigned to each dependency monitor.


ConfigMgr 2012 Client object is no longer discovered on cluster instances.

When I was working on the beta version, the development management group that I was using did not have any failover clusters. I didn’t realise the ConfigMgr 2012 Client object is being discovered on cluster instances (virtual nodes) until I imported the MPs into our proper test environment. So this is something that has been overlooked. It is fixed now, it will not discover ConfigMgr 2012 Client (and any client agents) on clusters.

The “ConfigMgr 2012 Client All Programs Service Window Monitor” is now disabled by default.

I’m not too sure how many environments will have a maintenance window (service window) created for all clients. Therefore I’ve disabled this monitor. this is to ensure it will not flood SCOM by generating an alert for each ConfigMgr client. If it is required for all or a subset of ConfigMgr clients, it can be enabled via overrides.

Few spelling mistakes in alerts descriptions are corrected.

Finally, since the beta version was released prior to System Center 2012 R2 release, I have also tested the this MP on ConfigMgr 2012 R2 environment, it is 100% compatible without any modifications.

It can be downloaded HERE. As always, please feel free to contact me if you have any issues or suggestions.

12th April, 2014 Update: Stanislav Zhelyazkov found the override MP packed in the zip file is not correct. It did not have any references to other sealed MP. Not sure what happened when I preparing the zip file. Anyways, If you intend to use the unsealed override MP, please use this one instead.

OpsMgr 2012 Self Maintenance Management Pack Update (Version

Written by Tao Yang

I have been extremely busy lately. Although I had few new ideas for the OpsMgr 2012 Self Maintenance MP for a while, I couldn’t find time to update it. This weekend, I managed to find some spare time and updated this management pack.

What’s new?

Updated the Close Aged Rule Generated Alerts Rule

Awhile back, someone suggested me to add a comment to the alert when it’s being closed by this rule. I think it’s a good idea, so I’ve updated this rule. now any alerts closed by this rule will have a comment “Closed by OpsMgr 2012 Self Maintenance Management Pack”:


New Agent Task: Get Management Groups configured on an agent

This new task is targeting the agent class, it displays the management groups that are configured on the OpsMgr 2012 agents:


Note: Since there is already a state view for agents built-in in OpsMgr 2012, I did not bother to create such a view in this management pack. You can find the “Agents By Version” state view under Operations Manager\Agent Details:


New Rule: Auto approve manually installed agents if their computer names and domain names match configurable regular expressions

By default in OpsMgr, there are 3 possible options for manually installed agents:

  • Reject all
  • Automatically Approve all
  • Manually Approve by OpsMgr administrators

The “OpsMgr 2012 Self Maintenance Approve Manual Agents Rule” runs on a schedule and approve manually installed agents of which computer name and domain name match the configurable computer name and domain name regular expression. This rule presents 2 benefits:

1. Allow OpsMgr to automatically approve agents based on preconfigured naming convention. It eliminates the needs for administrators to manually approve agents.

2. Agents approvals are staged. This prevents large number of agents are approved at once. In a large OpsMgr environment, this is particularly important as approving a large number of agents at once could consume a lot of system resources on management servers to transfer management packs and process the initial discovery workflows submitted from the agents.

This rule can be customized using overrides:

  • IntervalMinutes: How often (in minutes) does this rule run.
  • AgentNameRegex: Regular Expression for acceptable Agent computer names
  • AgentDomainRegex: Regular Expression for acceptable Agent domain names
  • MaxToApprove: Maxinum number of manually installed agents to be approved at a time.
  • SyncTime: What time does this rule run.
  • TimeoutSeconds: Timeout in seconds for the PowerShell script inside the rule.

This rule will approve manually installed agents (up to the number configured for MaxToAPprove) if both agent’s computer name and domain name match configured regular expressions.

An information alert is generated if the rule has approved at least one (1) agent(s).


The list of approved agents is shown in Alert Context:


As shown in above alert, in my lab, I have configured the rule to approve any agents that have “CLIENT” as part of the computer name and the the domain name is exactly “corp.tyang.org”. It found 2 agents pending approval, since MaxToApprove value is set to 2, both agents are approved.

Note: the rule uses case insensitive match (PowerShell –imatch operator). If you need help with building your regular expression, this article is a good starting point:

PowerShell: Working With Regular Expressions (regex)

I wrote this rule for the upcoming OpsMgr agents migration at work. As part of the System Center 2012 upgrade project that I have been working on over the last year or so, we will be migrating around 30,000 agents from 2 OpsMgr 2007 R2 management groups to 3 OpsMgr 2012 R2 management groups. I still remember the pain we have gone through couple of years ago when we added over 20,000 desktop computers into OpsMgr 2007 R2. at that time, to save us time manually approve these agents, I temporarily made the configuration change to allow OpsMgr to auto approve all manual agents. Although we have staged the agent rollout in ConfigMgr, we still had issues in OpsMgr as the management servers just couldn’t keep up with the load and most of the agents where showing Not Monitored with a green circle even days after been added to the management group.

So I would think this rule is like the bouncer standing in front of the night club. it will only allow someone you like to come in, and it also controls how many you will let in at once (so the night club don’t get too crowded). It will also make sure agents don’t get added to the wrong management group when there are multiple management groups in the environment.

I would also use this rule in conjunction with the auto balancing management servers rule from the same management pack, so after the agents are approved, they are balanced across multiple management servers.

New Monitor: Detect if each individual management server is in maintenance mode

This new monitor is called “OpsMgr 2012 Self Maintenance Local Management Server in Maintenance Mode Monitor”. Previously, I wrote another monitor in this MP called “OpsMgr 2012 Self Maintenance Management Servers in Maintenance Mode Monitor”.

Writing a workflow to detecting if someone is in maintenance mode could be tricky in OpsMgr. because if you are in maintenance mode, you would unload all workflows and therefore it would not run the maintenance mode detection workflow. This is why when I wrote the original monitor, I targeted the monitor to run on “All Management Servers Resource Pool”. However, it has a limitation that it will only generate alerts when more than 50% of members of “All Management Servers Resource Pool” is healthy and not in maintenance mode.

With the new monitor, I was inspirited by Kevin Holman’s recent blog article How to create workflows that wont go into Maintenance Mode (Thanks Kevin!). As Kevin explained in his blog article, in order to make this monitor to run on each individual management server and continues to run even when its Windows Computer object has been placed into maintenance mode, I have created an unhosted class called “OpsMgr 2012 Self Maintenance Management Server Maintenance Mode Watcher”. This object is discovered on each management server and it is not hosted by the Windows Computer. By doing so, this monitor will continue to run even when the management server’s Windows Computer object has been placed into maintenance mode.

A recovery task is also associated to this monitor (disabled by default). When enabled, it will automatically end the maintenance mode for the management server.

As the standard for the Self Maintenance MP, all workflows are disabled by default. Therefore, the object discovery for the Maintenance Mode Watcher class, this monitor itself and associated recovery task are all disabled by default.

Note: In order to utilise this monitor, the object discovery and the monitor itself will need to be enabled via overrides. Optionally, the recovery task can also be enabled if you want the monitor to automatically end the maintenance mode for the management servers.

Object Discovery:




Recovery Task:


Note: I purposely did not create a state view for the Maintenance Mode Watcher objects. I don’t want normal operators to see these objects (so they can place the watcher objects into maintenance mode directly).

When I placed All 3 management servers in my lab into maintenance mode:


The maintenance mode watcher objects became unhealthy:


An alert was generated for each management server:


From the screenshot above, you can see that other alerts were generated for various resource pools heartbeat failures because all management servers are in maintenance mode. In this scenario, the old monitor that targets the “All Management Servers Resource Pool” would not work.

When I enabled the recovery task, the management server has been taken out of maintenance mode automatically:


As shown in above screenshot, I placed a management server into maintenance mode for 30 minutes (as shown in the MaintModeDetails), because I configured the monitor to run every 1 minute, on 11:57PM local time, (within 1 minute of the maintenance mode start time), the monitor detected the management server was in maintenance mode, and the recovery task has ended the maintenance mode.

Note: Please enable this recovery task with caution. i.e. If the monitor is configured to run every 5 minutes, you will never be able to place a management server into maintenance mode for more than 5 minutes. It may not always be desired.

The updated MP and documentation can be downloaded HERE.

As always, please feel free to contact me if you have any feedbacks.

OpsMgr Self Maintenance Management Pack Updated to Version

Written by Tao Yang

I’ve updated the OpsMgr Self Maintenance MP for OpsMgr 2012 again this weekend. the latest version is now

The following is what’s new in this version:

Bug fix for the MP backup rule

The alert parameter and alert message was configured incorrectly. when the alert is generated for the failed backup, the error from the script was not displayed in the alert description:


This is now fixed, the alert description is correctly displayed:


New Rule: Detect Manually Closed Monitor-Generated Alerts

As any OpsMgr operators /administrators should know, monitor generated alerts should not be closed manually. There are many articles on the Internet in regards to this behaviour (so I won’t repeat it). Last week there was an incident at my work that made me came out with the idea of creating this rule. This rule runs on a schedule and check if there are any monitor-generated alerts that have been closed since its last execution. It would generate a warning alert if it detects this behaviour:


The alert description contains a list of users who has closed monitor-generated alerts (along with the alert count for each user). To investigate further, OpsMgr administrators can simply create an alert view for closed alerts to find out details of these alerts:


This version of the MP and the documentation can be downloaded HERE.

OpsMgr Self Maintenance Management Pack Version

Written by Tao Yang

I have published the OpsMgr Self Maintenance Management Pack Version 1.0 on this blog few months ago. Over the last couple of month, I’ve been working on the version of this MP during my spare time.

It has taken a lot longer than I thought because it was hard for me to find blocks of spare time to sit down and work on it. It is now complete and the list below is what has been added / changed in the version

  • A rule that detects user-defined overrides in the Default MP


  • A rule that configures failover management servers for Windows agents.
  • Agent Task: Check Data Warehouse Retention



  • 2 monitors that monitor Data Warehouse Hourly and Daily aggregation process. (Adopted from Michel Kamp’s blog post: http://michelkamp.wordpress.com/2013/03/24/get-a-grip-on-the-dwh-aggregations/)
  • Data Warehouse Database Aggregation Process Performance Collection Rule. This rule collects number of outstanding data sets that are yet to be processed by DW hourly and daily aggregation process. (This rule uses the same data source as above mentioned monitors.)
  • Bug Fixes:
    • The Remove Disabled Discovery Objects rule in the OpsMgr 2012 version of the MP were configured incorrectly in version 1.0 and it was using the script designed for OpsMgr 2007 R2.
    • The scripts used in the balancing agents rules (in both OpsMgr 2012 and OpsMgr 2007 versions) had a spelling mistake in one of the variables.
  • Updated the Close Aged Rule Generated Alerts Rule with an additional configurable option. The original rule uses the TimeRaised property of the alert. It now can be configured to use LastModified date if desired.


  • State Views:
    • RMS Emulator
    • Management Servers
    • All Management Server Resource Pool
    • Unhealthy Health Service Watchers
  • Performance View for the performance collection rule mentioned above for Data Warehouse Data sets.


Due to time constrains and the age of OpsMgr 2007 R2, I have decided not to update the OpsMgr 2007 version of the MP. However, the bug in the balancing agent rule mentioned above has been fixed in the OpsMgr 2007 R2 version. Other than this bug fix, all of above mentioned changes have only been updated in the 2012 version.

Since the Version 1.0 of the MP has been released, I have received many positive feedbacks. Some of the additions / changes came from suggestions from the community.

Cameron Fuller mentioned this MP in his MVP Pro Speaker presentation. One thing Cameron mentioned was to add state views for various classes that agent tasks are targeting – to make it more user friendly for OpsMgr operators to run agent tasks.

Ian Blyth emailed me and suggested to update the “Close Aged Rule Generated Alert Rule” to include an option for using LastModified date instead.

Dan Kregor suggested me to create a view for “grey agents” – Hence Unhealthy Health Service Watchers state view.

I’ve asked Michel Kamp if it is OK to include the DW aggregations workflows from his blog post in this MP. Michel was happy for me to use his idea. So special thanks to Michel for his excellent post. Since Michel did not post the finishing piece of his MP workflows in the blog post, I have make some changes from his blog post:

  • The PowerShell script from Michel’s post requires SQL Server module. I have removed such requirement in the script in this MP.
  • The Data Source module from Michel’s post contains a condition detection member module to map property bag value to performance data. I have taken this condition detection module out of data source module so I can configure the “On-Demand Detection” for the monitor type. – Which is an addition to Michel’s monitor type module.

The “Get DW Retention” agent task simply calls the dwdatarp.exe. Dwdatarp.exe is embedded as a binary resource in the MP. therefore this version of the management pack comes with a .mpb (Management Pack Bundle) file.

I have documented detailed configurations of all workflows in the documentation of this MP, including a list of all event log entries generated by scripts within this MP. There is also a known issue when creating your own override MP in OpsMgr operations console. This issue and workaround is also documented in the documentation.

Please click HERE to download the Management Packs and the documentation.

As always, please feel free to contact me if there are issues or suggestions.