Tag Archives: MimboloveManagement Pack

OpsMgr Agent Task to Configure OMS Network Performance Monitor Agents

Written by Tao Yang

OMS Network Performance Monitor (NPM) has made to public preview few weeks ago. Unlike other OMS solutions, for NPM, additional configuration is required on each agent that you wish to enrol to this solution. The detailed steps are documented in the solution documentation.

The product team has provided a PowerShell script to configure the MMA agents locally (link included in the documentation). In order to make the configuration process easier for the OpsMgr users, I have created a management pack that contains several agent tasks:

  • Enable OMS Network Performance Monitor
  • Disable OMS Network Performance Monitor
  • Get OMS Network Performance Monitor Agent Configuration


Note: Since this is an OpsMgr management pack, you can only use these tasks against agents that are enrolled to OMS via OpsMgr, or direct OMS agents that are also reporting to your OpsMgr management group.

These tasks are targeting the Health Service class, if you are also using my OpsMgr 2012 Self Maintenance MP, you will have a “Health Service” state view, and you will be able to access these tasks from the task pane of this view:


I can use the “Get OMS Network Performance Monitor Agent Configuration” task  to check if an agent has been configured for NPM.

i.e. Before an agent is configured, the task output shows it is not configured:


Then I can use the “Enable OMS Network Performance Monitor” task to enable NPM on this agent:


Once enabled, if I run the “Get OMS Network Performance Monitor Agent Configuration” task  again, the task output will show it’s enabled and also display the configured port number:


and shortly after, you will be able to see the newly configured node in OMS NPM solution:


If you want to remove the configuration, just simply run the “Disable OMS Network Performance Monitor” task:


You can download the sealed version of this MP HERE. I’ve also pushed the VSAE project for this MP to GitHub.

OpsLogix VMware Management Pack Quick Overview

Written by Tao Yang

Recently, I have had chance to evaluate the OpsLogix VMware management pack. In this post, I will discuss my experience with this MP so far.

Setup and Configuration

Once the MP files are imported , you will be able to import the license from the licensing dashboard in the monitoring pane under the OpsLogix folder.


Once the license is imported, you can manually add the VMware vCenter server from the “VMWare IMP COnfiguration dashboard” located under OpsLogix\VMware folder:


I have create a service account in AD and give it admin rights in vCenter. I used this account to connect to vCenter on this dashboard.

Note: Please do not use an account with administrative privilege in your production environment. a normal user with top level read-only access will suffice.


The OpsLogix VMware MP also has defined a resource pool that you can use for monitoring vCenter:


By default, the resource pool membership is set Automatic (which means all management servers are a member of). you can change it to Manual membership and hand pick the management servers you want to be a member of this resource pool.

Alternatively, you can also pick another existing resource pool (or even create your own) in the OpsLogix VMware configuration dashboard. You can also use resource pools containing OpsMgr gateway servers to monitor your VMware environment.

Discovered Objects

This MP discovers and monitors the following components:

  • vCenter servers
  • Datacenters
  • Clusters
  • Datastores
  • ESX hosts
  • Virtual Machines
  • VM Networks
  • Various hardware components

Here’s the sample diagram view from my lab environment:


The MP ships with a top level Alert view for all alerts generated by the MP:


The MP collects data and queries the health state of the VMware components via the vCenter Managed Object Browser (MOB). I was impressed about how many performance counters are being collected by the MP. It also comes with a performance dashboard which you can view from the OpsMgr console:


I have been asked many times before that what exactly does this MP monitor / collect? To answer the question, I’ve used MPViewer and exported all the monitoring MPs to Excel and make this SpreadSheet that contains all the rules and unit monitors.

This MP does not require any additional servers to monitor the VMware infrastructure as it leverages a resource pool to query vCenter. In my lab environment, since I have installed vCenter server on a Windows server, I also installed the OpsMgr agent on the vCenter server, so the server itself is monitored by OpsMgr.

Hardware Monitoring

As mentioned previously, this MP also monitors the hardware components in your VMware environments. In particular, the following components are discovered and monitored:

  • Battery
  • Fan
  • Memory
  • Network cards
  • Power Supply
  • Processor
  • Storage
  • Temperature
  • Voltage

This covers all the essential fabric components (Compute, Network and Storage), as well as the other hardware components such as PSU, battery, and physical environments such as temperature and voltage. the screenshots below are some sample state views taken from a demo environment:








The reporting MP provides several availability reports for different VMware components:


i.e. ESX host availability report:


I’ve created a sample ESX host availability report, you can download it from HERE.

Note: all the reports shipped in this MP are linked reports, So if they don’t meet your requirements, you can always use other  existing reports in your management group (i.e. the performance reports from Microsoft Generic Report Library).

Squared Up Dashboard

I have created a Squared Up dashboard for this the OpsLogix VMware MP.

OpsLogix VMware Dashboard

If you are also Squared Up in your OpsMgr environment, you can download this dashboard and import this dashboard from Squared Up’s community site: https://community.squaredup.com/browse/download-info/opslogix-vmware/


If you’d like to know more about this MP, you can find the datasheet here: http://www.opslogix.com/wp-content/uploads/2014/08/VMware-MP-Datasheet-2016.pdf and the whitepaper here: http://www.opslogix.com/wp-content/uploads/2016/01/VMware-MP-White-Paper-2016.pdf

Small Bug Fix in OpsMgr Self Maintenance MP V2.5.0.0

Written by Tao Yang

Last night, someone left a comment on the my post for the OpsMgr Self Maintenance MP V2.5.0.0 and advised a configuration in the Data Warehouse staging tables row count performance collection rules is causing issues with the Exchange Correlation service – which is a part of the Exchange MP. This issue was previously identified for other MPs: https://social.technet.microsoft.com/Forums/en-US/f724545d-90a3-42e6-950e-72e14ac0bd9d/exchange-correlation-service-cannot-connect-to-rms?forum=operationsmanagermgmtpacks

In a nutshell, looks like the Exchange Correlation service does not like rules that have category set to “None”.

I would have never picked it up in my environment because I don’t have Exchange in my lab therefore no Exchange MP configured.

Anyways, I have updated the category for these rules in both the Self Maintenance MP as well as the OMS Add-On MP, changed them from “None” to “PerformanceCollection”. I have updated the download from TY Consulting’s website. The current version is now So if you are have already downloaded v. and you are using Exchange MP in your environment, you might want to download the updated version again from the same spot HERE.

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

Updated MP Author’s System Center 2012 Orchestrator Management Pack

Written by Tao Yang


Over the last week or so, I’ve been busy creating Squared Up dashboards for various System Center 2012 components, which will be made publicly available through Squared Up’s new community site. While I was creating dashboards for some System Center components, I realised how little do the native MP from Microsoft offers (i.e. Orchestrator and Windows Azure Pack).  Luckily, some awesome MP developers have recognised this and released additional MPs to fill the gaps. i.e

So in additional to creating Squared Up dashboards for the native System Center management packs, I have also created dashboards for above mentioned community MPs.

However, if you have used (or tried to use) Brian’s Orchestrator Runbook MP, you’d probably know the PowerShell scripts in the MP is not compatible with Windows Server 2012 R2 or PowerShell version 3 and later. The issue is raised in the Q and A section (in a function, you can not use return in try-catch-finally statement).

Updated MP

I have tried to implement this MP a while back at my previous job. Not only I tried to update the PowerShell scripts, in my opinion, I did not want to create another “Runbook Host” class (by creating few registry keys and values) for hosting runbooks. Therefore, I’ve made another update to this MP: I’ve removed “Runbbook Host” class, and configured the “Orchestrator Runbooks” objects to be hosted by the Orchestrator Management Server:


You can also see the hosting stack in Squared Up (the critical object on the top is the runbook, and the critical object at the bottom is the Windows Computer:


After I updated this MP  (must be over a year ago), I’ve never bothered to publish it. Few weeks ago, my fellow SCCDM MVP Adin Ermie had a requirement for a fixed version. That’s when I realised I worked on it last year. When I gave Adin my version, he has also found out I fixed some scripts, but not all of them. So I updated it again, tested it myself today, and made sure the runbooks are correctly discovered and monitored.

Upgrade Compatibility

If you have already imported the original MP in your management group, I am afraid my updated version will not be compatible for in place upgrade, because I have removed various elements from the original MP (class definition, discoveries, etc.), and I have also used another key to seal the MP. These changes made the updated MP not compatible for in-place upgrade. So, if you’d like to use my version, you will have to delete the original version from your management group first.

Configuring the Management Pack

From Brian’s original MP download, there is also a MP guide included. As stated in the original MP guide, you will need to create few registry keys and values for the Runbook Host as well as creating a Run As account that has access to the Orchestrator Web Service.

When using this updated MP, it is obvious that you do not need to create those registry keys and values anymore because the “Runbook Host” class has been removed. But you will still need to create this Run As account and assign it to the “Orchestrator Web Service Account” Run As Profile:


However, since I have removed the “Runbook Host” class, instead of distributing this Run As account to the health service hosting the “Runbook Host” class instance, you will need to distribute it to your Orchestrator management servers instead.

You may also want to monitor the “Monitor runbooks”. If this is the case, you will need to enable the “Runbook Running” monitor for the “MPAuthor Monitor Runbooks” group:



I have enabled this monitor in my lab, and the Squared Up dashboard I created ended up look like this:



Obviously, big thank-you would go to Brian Wren, for developing this MP and made the entire VSAE project available for everyone. I’d also like to thank my fellow SCCDM MVP Adin Ermie for testing it for me.


You can download my updated MP from the link below. Please feel free to contact me if you have any questions or issues.

OpsMgr Performance Collection Rules for OMS Near Real-Time Performance Data Collection

Written by Tao Yang

Update: 09/09/2015: I found a small error in the demo MP provided at the end of this post, where one of the perf collection rules had an extra condition detection module (which prevents the real-time perf data to be sent to OMS). I have just updated the MP and the download link.


Yesterday, the OMS product team has announced the availability of the Near-Real Time (NRT) Performance Data Collection in OMS. My buddy and fellow SCCDM MVP Stanislav Zhelyazkov has already wrote an article on his blog: Operations Management Suite – Performance Monitoring.

I won’t repeat what’s already been discussed in these 2 posts, but I’ll tackle it from the management pack authoring perspective, and sharing what I have discovered so far.

Note: If you haven’t read above mentioned 2 posts, I strongly recommend you to do so before continuing with this article.

Management Pack Under The Hood

By default, OMS has 8 performance counters configured for near-real time perf collection. You can see them in the settings section of your workspace:


As explained in both the official blog post from the OMS product team as well as Stan’s blog, you can add additional perf counters on this page, and it will be pushed to the OpsMgr management groups that are connected to this OMS workspace. I am fairly certain, the sample interval range is between 10-1800 seconds (minimum 10 seconds, maximum 30 minutes).

All the counters configured on this page are stored in an Unsealed management pack called “Microsoft System Center Advisor Log Management Collection” in your OpsMgr management group.


If you export this MP and open it using MPViewer, you will see there are 2 rules for each counter:



These rules are collecting the raw real time perf data:



As the name suggested, these rules are collecting the 30-minute aggregated data (As stated in the official blog post, the raw data retention is 14 days and the 30-minute aggregated data retention is same as your OMS data plan).


After Examining these 2 rules closely,  we can see the following:

01. Both rules are disabled by default

02. Both rules are not remoteable (won’t work for agentless machines)

03. Both rules are targeting the Windows Computer class (Microsoft.Windows.Computer)

04. Both Rules are using the same data source module with same input parameters (Microsoft.IntelligencePacks.Performance.DataProvider). This configuration enables OpsMgr agents to leverage the Cookdown feature to reduce the computer resource consumed by these rules.

05. Comparing with the raw data collection rule, the aggregation data collection rule has an additional condition detection module (which is used for data aggregation) and the aggregated data is submitted to OMS via a different write-action module (Microsoft.SystemCenter.CollectCloudPerformanceDataAggregated_PerfIP).

06. Since both rules are disabled by default, the MP also comes with overrides to enable these rules for the OMS managed computers:


Write Your own OMS Near-Real Time Perf Collection Rules

Now that we have discovered how are the near-real time perf data is collected in OpsMgr, I have spent some time today testing different rule configurations. Based on my own experience, my findings are:

01. Both raw data collection rule and aggregation data collection rule are required

Based on my testing, I found in order to submit near-real time perf data to OMS, I must create both raw data and aggregation data collection rules (as shown above). I tried with only one rule for the raw data, after few hours, I still couldn’t see the data in OMS. I then created another rule for the aggregation data, imported the updated MP in OpsMgr, after about 30 minutes, the data became visible from the search result.

02. Data source module “Microsoft.IntelligencePacks.Performance.DataProvider”

The rule must use the data source module “Microsoft.IntelligencePacks.Performance.DataProvider”, which is defined in management pack “Microsoft System Center Advisor Types Library” (Microsoft.IntelligencePacks.Types). This data source module consists of 2 member modules:


  • Data Source: System.Performance.DataProvider
  • Condition Detection: System.Performance.DataGenericMapper

I have tried to use System.Performance.DataProvider module directly in both raw and aggregation data collection rules, unfortunately this configuration does not seem to work. additionally, many 4502 events were logged in the Operations Manager log on the OpsMgr agent computer indicating the configuration for the aggregation data collection rule is incorrect.


03. The Rule target must be Windows Computer class (Microsoft.Windows.Computer).

Initially I have written few rules targeting SQL DB Engine class, waited few hours and I could only see the 30-minute aggregated data in OMS (collected by the aggregation collection rules). The data insertion is every 30 minutes and the perf graph could not be displayed in OMS (showed “No Data”). When I changed the target for both rules from SQL DB Engine to Windows Computer class, the raw data started to appear.

Having said that, I have also tried Windows Server Computer class (Microsoft.Windows.Server.Computer). This class is derived from Windows Computer class. This configuration also worked. So in my opinion, it is fair to guess the target class must be Windows Computer class or class that’s based on Windows Computer class.

Demo Management Pack “OMS Performance Demo MP”

I have created a MP during my experiments today. In the end, I have deleted all the rules that are not working in this MP and kept two sets rules for demonstration purpose:

  • Set #1:
    • Target: Microsoft.Windows.Computer
    • Perf Counter: Processor(_Total)\% Privileged Time


  • Set #2:
    • Target: Microsoft.Windows.Server.Computer
    • Perf Counter: SQLServer:Memory Manager(*)\Free Memory (KB)


You can download my demo MP from the link below:


This post is purely based on my own experiment, it may not be 100% accurate. Please use it with caution and test it in your test environment first!

OpsMgr Alert Console Task For Squared Up

Written by Tao Yang

I have just created 2 alert console tasks in OpsMgr for Squared Up:

  • View Alert in Squared Up
  • View Alert Source Object in Squared Up


These 2 tasks will open the selected alert and alert source object in Squared Up  respectively using your default browser:

Squared Up Alert View:


Squared Up Monitoring Object view (Alert Source Object):


the management pack containing these 2 tasks can be downloaded at the end of this article. In order to use this MP, you will need to modify 2 lines:


You need to open the unsealed MP (xml) in a text editor (such as Notepad++), and modify line 29 and 38 (as shown above). Please replace “http://Your-SquaredUp-URL” with the Squared Up URL in your environment. i.e.


You can download this MP from the link below:

OpsMgr Group Health Rollup Configuration Task Management Pack

Written by Tao Yang


In OpsMgr, groups are frequently used when designing service level monitoring and dashboards. The group members’ health rollup behaviours can be configured by creating various dependency monitors targeting against the group.

When creating groups, only instance groups can be created within the OpsMgr console. Unlike computer groups, instance groups do not inherit any dependent monitors from their base class. Therefore when an instance group is created in the OpsMgr console, by default, the health state of the group is “Not monitored” (Uninitialized):


In order to configure group members to rollup health state to the group object (so the group can be used in dashboards), one or more dependency monitors must be created manually after the group has been created. This manual process can be time consuming.

Squared Up has recognised this issue, and many of their customers have also asked for a way to simplify the process of configuring health roll-up for the groups (so the groups can be used in Squared Up dashboards).

Squared Up has engaged me and asked me to develop an agent task to configure group health rollup and make it available to the broader OpsMgr community.

The “OpsMgr group health Rollup Configuration Task Management Pack” provides an agent task to create dependency monitors for the selected groups using OpsMgr SDK.


Management Pack Overview

In order for the OpsMgr operators to easily navigate to the groups, this management pack provides a state view for all groups (System.Group class):


Although a set of required parameters are pre-configured for the agent task, the operators can also modify these parameters using overrides.

The following parameters can be customized via overrides:


  • Health Rollup Policy Possible values: ‘BestOf’, ‘WorstOf’,’Percentage’.
  • Worst state of the percentage in healthy state Integer between 1 and 100. Only used when Algorithm is set to ‘Percentage’.
  • Member Unavailable Rollup As Possible Values: ‘Uninitialized’, ‘Success ‘, ‘Warning’ and ‘Error’
  • Member in Maintenance Mode Rollup As ‘Uninitialized’, ‘Success’, ‘Warning’ and ‘Error’
  • Management Pack Name The Management Pack name of which the monitors going to be saved. Only used when the group is defined in a sealed MP.’
  • Increase Management Pack version by Specify if the management pack version should be increased by

NOTE: Please DO NOT select multiple instance groups at once.

After the task is executed against a group, 4 dependency monitors are created:

  • Availability Dependency Monitor
  • Configuration Dependency Monitor
  • Performance Dependency Monitor
  • Security Dependency Monitor




Security Consideration

Natively in OpsMgr, only user accounts assigned either authors role or administrators role have access to create monitors. However, users with lower privileges (such as operators and advanced operators) can potentially execute this task and create dependency monitors.

Please keep this in mind when deploying this management pack. You may need to scope user roles accordingly to only allow appropriate users have access to this task.


Thanks Squared Up for making this management pack free to the community.


This management pack can be downloaded from the link below:

Collecting ConfigMgr Logs To Microsoft Operation Management Suite – The NiCE way

Written by Tao Yang


I have been playing with Azure Operational Insights for a while now, and I am really excited about the capabilities and capacities it brings. I haven’t blogged anything about OpInsights until now, largely because all the wonderful articles that my MVP friends have already written. i.e. the OpInsights series from Stanislav Zheyazkov (at the moment, he’s written 18 parts so far!): https://cloudadministrator.wordpress.com/2015/04/30/microsoft-azure-operational-insights-preview-series-general-availability-part-18-2/

Back in my previous life, when I was working on ConfigMgr for living, THE one thing that I hate the most, is reading log files, not to mention all the log file names, locations, etc. that I have to memorise. I remember there was even a spreadsheet listing all the log files for ConfigMgr. Even until now, when I see a ConfigMgr person, I’d always ask “How many log files did you read today?” – as a joke. However, sometimes, when sh*t hits the fan, people won’t see the funny side of it. In my opinion, based on my experience working on ConfigMgr, I see the following challenges in ConfigMgr log files:

There are too many of them!

And even for a same component, there would be multiple log files (i.e. for software update point, there are wsyncmgr.log, WCM.log, etc.). Often administrators have to cross check entries from multiple log files to identify the issue.

Different components place log files in different locations

Site server, clients, management points, distribution points, PXE DPs, etc. all save logs to different locations. not to mention when you some of these components co-exist on the same machine, the log locations would be different again (i.e. client logs location on the site server is different than the normal clients).

Log file size is capped

By default, the size of each log file is capped to 2.5MB (I think). Although it keeps a copy of the previous log (renamed to .lo_ file), still, it holds totally 5MB of log data for the particular component. In a large / busy environment, or when something is not doing right, these 2 files (.log and .lo_) probably only holds few hours of data.  Sometimes, by the time when you realised something went wrong and you need to check the logs, they have already been overwritten.

It is difficult to read

You need a special tool (CMTrace.exe) to read these log files. If you see someone reading ConfigMgr log files using notepad, he’s either really really good, or someone hasn’t been working on ConfigMgr for too long. For majority of people like us, we rely on CMTrace.exe (or Trace32.exe in ConfigMgr 2007) to read log files. When you log to a computer and want to read some log files (i.e. client log files), you’d always have to find a copy of CMTrace.exe somewhere on the network and copy it over to the computer that you are working on. In my lab, I even created an application in ConfigMgr to copy CMTrace.exe to C:\Windows\System32 and deployed to every machine – so I don’t have to manually copy it again and again. I’m sure this is a common practice and many people have all done this before.

Logs are not centralised

In a large environment where you ConfigMgr hierarchy consists of hundreds of servers, it is a PAIN to read logs on all of these servers. i.e. When something bad happens with OSD and PXE, the results can be catastrophic (some of you guys may still remember what an incorrectly advertised OSD task sequence has done to a big Australian bank few years back).  Based on my own experience, I have seen support team needs to check PXE DP’s SMSPXE.log on as many as few hundred PXE enabled distribution points, within a very short time window (before the logs get overwritten). People would have to connect to each individual DP  and read the log files one at a time. – In situation like this, if you go up to them and ask them “How many logs have you read today?”, I’m sure it wouldn’t go down too well.

It would be nice if…

When Microsoft has released Operational Insights (OpInsights) to preview, the first thing came to my mind is, would be very nice if we can collect and process ConfigMgr log files into OpInsights. This would bring the following benefits to ConfigMgr administrators:

  • Logs are centralised and searchable
  • Much longer retention period (up to 12 month)
  • No need to use special tools such as CMTrace.exe to read the log files
  • Being able to correlate data from multiple log files and multiple computers when searching, thus make administrator’s troubleshooting experience much easier.



A line of ConfigMgr log entry consists of many piece of information. And the server and client log files have different format. i.e.

Server Log file:


Client Log File:


Before sending the information to OMS, we firstly must capture only the useful information from each entry, transform them into a more structured way (such as Windows Event log format), so these fields would become searchable once been stored and indexed in your OMS workspace.

No Custom Solution Packs available

Since OMS is still very new, there aren’t many Solution Packs available (aka Intelligence Packs in the OpInsights days). Microsoft has not yet released any SDKs / APIs for partners and 3rd parties to author and publish Solution Packs. Therefore, at this stage, in order to send the ConfigMgr log file entries to OMS, we will have to utilise our old friend OpsMgr 2012 (with OpInsights integration configured), leveraging the power of OpsMgr management packs to collect and process the data before sending to OMS (via OpsMgr).

OpsMgr Limitations

As we all know, OpsMgr provides a “Generic Text Log” event collection rule. But unfortunately, this native event data source is not capable of accomplish what I am going to achieve here.

NiCE Log File Management Pack

NiCE is a company based in Germany. They offer a free OpsMgr management pack for log file monitoring. There are already many good blog articles written about this MP, I will not write an introduction here. If you have never heard or used it, please read the articles listed below, then come back to this post:

SCOM 2012 – NiCE Log File Library MP Monitoring Robocopy Log File – By Stefan Roth

NiCE Free Log File MP & Regex & PowerShell: Enabling SCOM 2 Count LOB Crashes – By Marnix Wolf

SCOM – Free Log File Monitoring MP from NiCE –By Kevin Greene

The beauty about the NiCE Log File MP is, it is able to extract the important information (as I highlighted in the screenshots above) by using Regular Expression (RegEx), and present the data in a structured way (in XML).

In Regular Expression, we are able to define named capturing groups to capture data from a string, this is similar to storing the information in a variable when comes to programming. I’ll use a log file entry from both ConfigMgr client and server logs, and my favourite Regular Expression tester site https://regex101.com/ to demonstrate how to extract the information as I highlighted above.

Server Log entry:

Regular Expression:


Sample Log entry:

Execute query exec [sp_CP_GetPushRequestMachine] 2097152112~  $$<SMS_CLIENT_CONFIG_MANAGER><06-07-2015 13:11:09.448-600><thread=6708 (0x1A34)>

RegEx Match:


Client Log entry:

Regular Expression:


Sample Log entry:

<![LOG[Update (Site_9D4393B0-A197-4FC8-AF8C-0BC42AD2F33F/SUM_01a0100c-c3b7-4ec7-866e-db8c30111e80) Name (Update for Windows Server 2012 R2 (KB3045717)) ArticleID (3045717) added to the targeted list of deployment ({C5B54000-2018-4BD9-9418-0EFDFBB73349})]LOG]!><time=”20:59:35.148-600″ date=”06-05-2015″ component=”UpdatesDeploymentAgent” context=”” type=”1″ thread=”3744″ file=”updatesmanager.cpp:420″>

RegEx Match:


NiCE Log MP Regular Expression Tester

The NiCE Log MP also provides a Regular Expression Tester UI in the management pack. The good thing about this RegEx tester is, it also shows you what the management pack module output would be (in XML and XPath):


Now, I hope you get the bigger picture of what I want to achieve now. I want to use OpsMgr 2012, NiCE Log File MP to collect various ConfigMgr 2012 log files (both client and server logs), and then send over to OMS via OpsMgr. It is now time to talk about the management packs.

Management Pack

Obviously, the NiCE Log File MP is required. You can download it from NiCE’s customer portal once registered. This MP must be firstly imported into your management group.

Additionally, your OpsMgr management group must be configured to connect to a Operational Insights (or called “System Center Advisor” if you haven’t patched your management group in the last few months). However, what I’m about to show you is also able to store the data in your on-prem OpsMgr operational and data warehouse databases. So, even if you don’t use OMS (yet), you are still able to leverage this solution to store your ConfigMgr log data in OpsMgr databases.

Management Pack 101

Before I dive into the MP authoring and configuration, I’d like to firstly spend some time to go through some management pack basics – at the end of the day, not everyone working in System Center writes management packs. By going through some of the basics, it will help people who haven’t previously done any MP development work understand better later on.

In OpsMgr, there are 3 types of workflows:

  • Object Discoveries – For discovering instances and it’s properties of classes defined in management packs.
  • Monitors – responsible for the health states of monitoring objects. Can be configured to generate alerts.
  • Rules – Not responsible for the objects health state. Can be used to collect information, and also able to generate alerts.

Since our goal is to collect information from ConfigMgr log files, it is obvious we are going to create some rules to achieve this goal.

A rule consists of 3 types of member modules:

  • One(1) or more Data Source modules (beginning of the workflow)
  • Zero(0) or One(1) Condition Detection Module (optional, 2nd phase of the workflow)
  • One(1) or more write action modules (Last phase of the workflow).

To map the rule structure into our requirement, the rules we are going to author (one rule for each log file) is going to be something like this:

  • Data Source module: Leveraging the NiCE Log MP to read and process ConfigMgr log entries using Regular Expression.
  • Condition Detection module: Map the output of the Data Source Module into Windows event log data format
  • Write Action modules: write the Windows Event log formatted data to various data repositories. Depending your requirements, this could be any combinations of the 3 data repositories:
    • OpsMgr Operational DB (On-Prem, short term storage, but able to access the data from the Operational Console)
    • OpsMgr Data Warehouse DB (On-Prem, long term storage, able to access the data via OpsMgr reports)
    • OMS workspace (Cloud based, long term or short term storage depending on your plan, able to access the data via OMS portal, and via Azure Resource Manager API.)


Using NiCE Log MP as Data Source

Unfortunately, we cannot build our rules 100% from the OpsMgr operations console. The NiCE Log File MP does not provide any event collection rules in the UI. There are only alert rules and performance collection rules to choose from:


This is OK, because as I explained before, rules consists of 3 types of modules. An alert rule generated in this UI would have 2 member modules:

  • Data source module (called ‘NiCE.LogFile.Library.Advanced.Filtered.LogFileProvider.DS’) to collect the log entries and process them using the RegEx provided by you.
  • Write Action Module (called ‘System.Health.GenerateAlert’): Generate alerts based on the data passed from the data source module.

What we can do is to take the same data source module from such an Alert rule (and it’s configuration), then build our own rule with our condition detection module (called ‘System.Event.GenericDataMapper’) to map the data into Windows Event Log format, and use any of these 3 write action module to store the data:

  • Write to Ops DB: ‘Microsoft.SystemCenter.CollectEvent’
  • Write to DW DB: ‘Microsoft.SystemCenter.DataWarehouse.PublishEventData’
  • Write to OMS (OpInsights): ‘Microsoft.SystemCenter.CollectCloudGenericEvent’

However, to go one step further, since there are so many input parameters we need to specify for the Data Source module, and I want to hide the complexity for the users (your System Center administrators), I have created my own data source modules, and “wrapped” the NiCE data source module ‘NiCE.LogFile.Library.Advanced.Filtered.LogFileProvider.DS’ inside my own data source module. By doing so, I am able to hardcode some common fields that are same among all the rules we are going to create (i.e. the regular expression, etc.). Because the regular expression for ConfigMgr client logs and server logs are different, I have created 2 generic data source modules, one for each type of log – that you can use when creating your event collection rules.

When creating your own event collecting rules, you will only need to provide the following information:

  • IntervalSeconds: How often should the NiCE data source to scan the particular log
  • ComputerName: the name of the computer of where the logs is located. – This could be a property of the target class (or a class in the hosting chain).
  • EventID: to specify an event ID for the processed log entries (as we are formatting the log entries as Windows Event Log entries)
  • Event Category: a numeric value. Please refer to the MSDN documentation for the possible value: https://msdn.microsoft.com/en-au/library/ee692955.aspx. It is OK to use the value 0 (to ignore).
  • Event Level: a numeric value. Please refer to the MSDN documentation for the possible value: https://msdn.microsoft.com/en-au/library/ee692955.aspx.
  • LogDirectory: the directory of where the log file is located (i.e. C:\Windows\CCM\Logs)
  • FileName: the name of the log file (i.e. execmgr.log)


So What am I Offering?

I’m offering 3 management pack files to get you started:

ConfigMgr.Log.Collection.Library (ConfigMgr Logs Collection Library Management Pack)

This sealed management pack provides the 2 data source modules that I’ve just mentioned:

  • ConfigMgr.Log.Collection.Library.ConfigMgr.Client.Log.DS (Display Name: ‘Collect ConfigMgr 2012 Client Logs Data Source’)
  • ConfigMgr.Log.Collection.Library.ConfigMgr.Server.Log.DS (Display Name: ‘Collect ConfigMgr 2012 Server Logs Data Source’)

When you create your own management pack where your collection rules are going to be stored, you will need to reference this MP and use the appropriate data source module.

ConfigMgr.Log.Collection.Dir.Discovery (ConfigMgr Log Collection ConfigMgr Site Server Log Directory Discovery)

This sealed management pack is optional, you do not have to use it.

As I mentioned earlier, you will need to specify the log directory when creating the rule. The problem with this is, when you are creating a rule for a ConfigMgr server log file, it’s probably not ideal if you have to specify a static value because in a large environment where there are multiple ConfigMgr sites, the ConfigMgr install directory on each site server could be different. Unfortunately, the ConfigMgr 2012 management pack from Microsoft does not define and discovery the install folder or log folder as a property of the site server:


To demonstrate how we can overcome this problem, I have created this management pack. In this management pack, I have defined a new class called “ConfigMgr 2012 Site Server Extended”, it is based on the existing class defined from the Microsoft ConfigMgr 2012 MP. I have defined and discovered an additional property called “Log Folder”:


By doing so, we can variablise the “LogDirectory” parameter when creating the rules by passing the value of this property to the rule (I’ll demonstrate later).

Again, as I mentioned earlier, this MP is optional, you do not have to use it. When creating the rule, you can hardcode the “LogDirectory’’ parameter using a most common value in your environment, and using overrides to change this parameter for any servers that have different log directories.

ConfigMgr Logs Collection Demo Management Pack (ConfigMgr.Log.Collection.Demo)

In this unsealed demo management pack, I have created 2 event collection rules:

Collect ConfigMgr Site Server Wsyncmgr.Log to OpsMgr Operational DB Data Warehouse DB and OMS rule

This rule is targeting the “ConfigMgr 2012 Site Server Extended” class defined in the ‘ConfigMgr Log Collection ConfigMgr Site Server Log Directory Discovery’ MP, and collects Wsyncmgr.Log to all 3 destinations (Operational DB, Data Warehouse DB, and OMS).

Collect ConfigMgr Client ContentTransferManager.Log to OpsMgr Data Warehouse and OMS rule

This rule targets the “System Center ConfigMgr 2012 Client” class which is defined in the ConfigMgr 2012 (R2) Client Management Pack Version (which is also developed by myself).

This rule collects the ContentTransferManager.log only to Data Warehouse DB and OMS.

Note: I’m targeting this class instead of the ConfigMgr client class defined in the Microsoft ConfigMgr 2012 MP because my MP defined and discovered the log location already. When you are writing your own rule for ConfigMgr clients, you don’t have target this class, as most of the clients should have the logs located at C:\Windows\CCM\Logs folder (except on ConfigMgr servers).

Note: There are few other good example on how to write event collection rules for OMS, you may also find these articles useful:


What Do I get in OMS?

After you’ve created your collection rules and imported into your OpsMgr management group, within few minutes, the management packs would have reached the agents, started processing the logs, and send the data back to OpsMgr. OpsMgr would then send the data to OMS. It will take another few minutes for OMS to process the data before the data becomes searchable in OMS.

You will then be able to search the events:

Client Log Example:


Server Log Example:


As you can see, each field identified by the Regular Expression in NiCE data source module are structured in different parameters in the OMS log entry. You can also perform more complex searches. Please refer to the articles listed below for more details:

By Daniele Muscetta:

Official documentation:

Download MP

You may download all 3 management packs from TY Consulting’s web site: http://www.tyconsulting.com.au/portfolio/configmgr-log-collection-management-pack/

What’s Next?

I understand writing management packs is not a task for everyone, currently, you will need to write your own MP to capture the log files of your choice. I am working on an automated solution. I am getting very close in releasing the OpsMgrExtended PowerShell / SMA module that I’ve been working since August last year. In this module, I will provide a way to automate OpsMgr rule creation using PowerShell. I will write a follow-up post after the release of OpsMgrExtended module to go through how to use PowerShell to create these ConfigMgr log collection rules. So, please stay tuned Smile.

Note: I’d like to warn everyone who’s going to implement this solution: Please do not leave these rules enabled by default when you’ve just created it. You need to have a better understanding on how much data is sending to OMS as there is a cost associated in how much data is sending to it, as well as the impact to your link to the Internet. So please make them disabled by default, start with a smaller group.

Lastly, I’d like to thank NiCE for producing such a good MP, and making it free to the community. Smile

New MP: OpsMgr Health State Synchronization Library

Written by Tao Yang

Health SyncBackground

As I mentioned in previous blog posts, I will continue blogging on the topic of managing multiple OpsMgr management groups – a topic keeps getting brought up in the private conversations between us SCCDM MVPs.

Previously, I have written 2 posts demonstrated how to use Squared Up dashboard to access data from foreign management groups using their SQL and Iframe plugins. Now that I’ve covered the presentation layer (using Squared Up), I’d like to explore deeper in this subject.

I wanted to be able to synchronise the health state from a monitoring object managed by a remote management group into the local management group so it can be part of the health models users are building (i.e. be part of a Distributed Application, or simply a dashboard). I had this idea in my head for awhile now, over the last month or so, I finally managed to produce such a management pack that enables OpsMgr users to do so.


It is common to have multiple OpsMgr management groups in large organisations. When designing distributed application or creating custom dashboards, one of the limitations is that OpsMgr users can only select monitoring objects within the local management group to be a part of the Health Model. This becomes an issue when users want to design a Distributed Application or dashboard that include components monitored by different OpsMgr management groups.

The OpsMgr Health Synchronization Library management pack is designed to provide a workaround to this limitation. This management pack provides a template that enables OpsMgr users to create monitoring objects named “Health State Watcher” hosted by All Management Servers Resource Pool. Health State Watcher objects have monitors configured to query health state of monitoring objects located in a remote management group using OpsMgr SDK.


As shown in the diagram above, an instance of Health State Watcher can be created for each monitoring object of user’s choice from a remote management group. Each Health State Watcher object will periodically update its own health state based on the health state of the remote monitoring object it is watching for (every 5 minutes by default). As shown above, the Health State Watcher can query health state of any monitoring objects from remote management group (i.e. a Windows Computer object, a Distributed Application or any other types monitoring objects).

This management pack provides 4 unit monitors to the Health State Watcher class. They are used to query the health state of the Availability, Configuration, Performance and Security aggregate monitors of the remote monitoring object respectively.

Once the Health State Watcher objects are created and correctly configured, it can be used to display the health state of the remote monitoring object in a dashboard or distributed application hosted by the local management group.

How Do I Use this MP?

This management pack provides a management pack template for OpsMgr users to create the Health State Watcher instances from the OpsMgr operations console.


The following information must be provided when creating an instance using the management pack template:

  • Display Name
  • Description (Optional)
  • Unsealed Management Pack (where the MP elements will be saved)
  • One of the management servers from the remote management group
  • Monitoring Object ID of the monitoring object from the remote management group
  • Run-As account for SDK connection to the remote management group

Please follow the steps listed below to create a template instance.

1. Click the “Add Monitoring Wizard” from the Authoring pane under “Management Pack Template”


2. Choose “Cross Management Group Health State Monitoring” from the list


3. In General Property page, enter the display name, description and select an unsealed MP from the drop-down list:


4. In the Parameter Configuration Page, enter the following information:


  • Management server from the remote management group
  • Source Instance ID (monitoring object ID) of the monitoring object from the remote management group

Note: there are multiple ways to find the monitoring object ID in OpsMgr. Please refer to this article for possible ways to locate the ID: http://blog.tyang.org/2015/03/11/various-ways-to-find-the-id-of-a-monitoring-object-in-opsmgr/

  • Select the Run-As account that was created prior to running this wizard.

Note: The Run-As account must meet the following requirements:

    1. It must have at least Operator access in the remote management group
    2. It must be distributed to all management servers


    1. It must have logon locally access on all management servers. – This is a general requirement for all Windows Run-As accounts in OpsMgr. Although it will never be used to logon locally on the management servers, without this right, the workflows that are using this Run-As account will not work.


5. Confirm all information is correct in the Summary page, and click on “Create”.


6. After few minutes, the health state of the Health State Watcher instance should be synchronized from the remote monitoring object:

Overall state:


Health Explorer:


Source monitoring object (from remote MG):


Sample Distributed Application

The diagram below demonstrates how to utilize the health state watcher in a Distributed Application:


In the demo environment, the 2 domain controllers (AD01 and AD02) are being monitored by a management group located in the On-Prem network. There is another domain controller located in Microsoft Azure IaaS, and it is being monitored by a separate management group in Azure. A Health State Watcher object was created previously to synchronize the health state of the Azure DC Windows computer health.

Sample Dashboard (Using Squared Up)


As shown above, on the left section, the Health State Watcher object for the Azure based domain controller is pinned on the correct location of a World Map dashboard. The health state of individual domain controllers are also listed on the right.


The workflows in this MP are actually pretty simple, but it has taken me A LOT of time to finish this MP. This is largely caused by the template UI interfaces. Unfortunately, I couldn’t find any official guides on how to build template UIs using C#. I’d like to thank my friend and fellow SCCDM MVP Daniele Grandini (blog, twitter) for testing and helping me debugging this MP when I hit the road block with the template UI interface.

Where can I download this management pack?

As I mentioned in my previous post, from now on, any new tools such as management packs, modules, scripts etc. will be released under TY Consulting and download links will be provided from it’s website www.tyconsulting.com.au.

You can download this MP for free from http://www.tyconsulting.com.au/products/, however, to help me promote and grow my business, I am asking you to provide your name, email and company name in a form and the download link will be emailed to you by the system.

Lastly, as always, any feedbacks are welcome. Please feel free to drop me an email if you have anything to share.