Quick Download: https://github.com/thekevinholman/MCM
The old System Center Configuration Manager 2012 (SCCM) Management Pack is no longer available. Customers often used this to monitor current branch, and it still works well for the most part.
Now that it was pulled, there is a gap for customers who don’t have that old MP, or want something a little more relevant to Microsoft Configuration Manager deployment monitoring.
I have taken the old SCCM 2012 MP’s, and combined them into a single MP. It largely works the same way, but I made some enhancements based on things I saw in the field.
The biggest changes are around controlling noise for transient errors, and changing the alert source to the Unit monitors, as alerting from rollup monitors was a terrible design as a method to limit noise, because you also limit quality detailed alerts. Fixed some workflows that flat out didn’t work, and aligned the MP closer to best practices.
- MCM Client Class discovers sitecode and version properties
- Fixed errors on MCM client discovery that logged events
- Added MatchCount property to most monitors to support multiple consecutive samples to reduce noise
- Removed overrides that were muting alerts from unit monitors
- Added overrides to disabled alerts from the aggregate rollup monitors and dependency rollup monitors
- Added ScaleBy to Process based CPU Rules and Monitors so they actually work.
- Changed Max sample separation on Perf Collection rules from 10 to 4 so one data point will be collected every hour on any perf collection rules that are enabled.
- Deleted all Manual Reset Monitors and replaced with Rules.
- Deleted all Classes, Rules, and Monitors for Deprecated and Unsupported roles
- Renamed all Element ID’s to include the MP ID, and follow structured rules:
- Datasource ends with .DS and with Displaystring Datasource
- ProbeAction ends with .PA and with Displaystring Probe Action
- WriteAction ends with .WA and with Displaystring Write Action
- MonitorType ends with .MT and with Displaystring MonitorType
- Discovery ends with .Discovery and with Displaystring Discovery
- Rule ends with .Rule and with Displaystring Rule
- Monitor Ends with .Monitor and with Displaystring Monitor
- Aggregate Monitor ends with .AggregateRollup.Monitor
- Dependency Monitor ends with .DependencyRollup.Monitor
- Groups end with .Group and with Displaystring Group
- Task ends with .Task
- Removed all Override Displaystrings which were pointless
- Reduced frequency of MCM Client Discovery from 60 seconds to once a day.
- Created an override to disable the SMSExec service monitor for members of the Site Database Computers Group, since this was causing false alarms as Database servers are not typically Site server roles with SMSExec service present.
You can download this management pack here:
If you have any feedback or monitoring requests, I will be happy to consider them for future updates.
1. This MP does not support some of the high availability features new to ConfigMgr, so you might see alerts on passive nodes.
2. This MP primarily looks in the registry on ConfigMgr servers for issues reported by MCM. These might be out of date, and sometimes require a manual reset on the ConfigMgr server registry to clear the issue in SCOM. These keys are located at HKLM\SOFTWARE\Microsoft\SMS\Operations Management\Components. The “Severity” value determines the health state. 0 or 1 is Healthy, while 2 or 3 is unhealthy. You can review the “Time of last report” and if this is very old, you can consider resetting the Severity to “0” in the registry to set the monitor back to healthy, if you are sure the component is working in MCM. Sometimes these status message driven registry entries do not get updated back to healthy.
The first discovery that runs is “Site System Discovery”.
This targets the Microsoft Windows Server Operating System class. So make sure you have a Windows Server OS instance FIRST. This means you MUST have the Windows Server OS MP’s imported for every version of Windows Server that hosts a MCM server role.
Next, make sure you have enabled agent proxy as a default setting: HERE
This discovery discovers the “ConfigMgr Site System” instances. This discovery checks all Windows Server OS instances for this registry value: HKLM:SOFTWARE\Microsoft\SMS\Operations Management\Version and discovers instances if the value matches wildcard “5.*”. Use Discovered Inventory, and ensure you have discovered a ConfigMgr Site System instance for each server:
The next discoveries that run are “MCM Site Server Discovery” and “MCM Remote Server Discovery”. These discover instances of the “ConfigMgr Site Server” and “ConfigMgr Site System Server” respectively. The MECM Site Server Discovery inspects the registry on all ConfigMgr Site System instances, for SOFTWARE\Microsoft\SMS\Operations Management\SMS Server Role\SMS Site Server. If this registry key exists, it will discover a ConfigMgr Site System. Check discovered inventory for these:
Next, the MCM Hierarchy discovery runs against all instances of the ConfigMgr Site Server class. Also, the Central Site, Primary Site, Secondary Site, Site Services, and Standalone Primary Site discoveries all target the ConfigMgr Site Server class. These are registry or script based discoveries (.js)
Look on the OperationsManager event logs on MCM servers for clues if a discovery is not working.