OpsMgr Self Maintenance Management Pack Updated to Version 2.1.0.0

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

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:

image

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

image

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:

image

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:

image

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

5 comments

  1. Tao, I like where you have taken this management pack. I would like to make the following suggestions.
    – When alerts are closed, instead of an empty string, put “Closed by Self Maint MP” or even create an override for for custom text.
    – Add an override for the lastModified/CreateDate for the alert closure so that one can choose whether to use the LastModified Date or CreateDate. For me, the last modified makes more sense. I think you may have done this with the 2012 MP but not in the 2007 MP.

    I modified the 2.0.0.0 MP to use last modified and update the comment. But alas… my problem is I want to include your updates (i.e.2.1.0.0) but now that I modified my copy… I won’t be able to without losing my changes. Such is the risk of modifying a management pack.

    I am most happily re-doing my changes in the new management pack (if for nothing else) for the addition of the closed monitor-generated alerts rule. I actually have been wanting to write a rule that goes one step further but I haven’t yet. the rule would detect this and instead of raising an alert, reset the health of the monitor. If the issue still exists, then it will be raised again. If it is not an issue, the alert wasn’t needed in the first place. Perhaps I am over simplifying this BUT we are more likely to have people closing things that should still have an open alert than we are to have a reset monitor hide an existing condition.

    If I finally come up with such a rule, if you are intested… I’ll share.

    Craig

    1. Hi Craig, Thanks for the feedbacks. Adding a custom comment when closing the alerts sounds like a good idea. I’ll add that in the next release :). I purposely didn’t update the 2007 version because of the age of that product and I simply don’t have time to maintain 2 versions.
      With regards to the alert for closing monitor generated alerts, I thought about what you’ve suggested when I was writing it, I didn’t want to over complicate things. the rule I wrote runs a very simple and effective query via the SCOM SDK to get just a summary. SCOM admins can always use an alert view to get the details. automating the process of resetting health can take a very long time, therefore I didn’t want to add it in the workflow.

      Thanks again for your suggestions.

      Cheers
      Tao

Leave a Reply

%d bloggers like this: