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 188.8.131.52?
- 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.