5 thoughts on “Resolve all alerts for a specific management pack

  1. curtmcgirt

    interesting. I don’t know of anything, but I’m sure it can be scripted, so here goes.

    my first reaction is that for alerts generated by monitors, you’d probably want to reset the health of those monitors as well as –or instead of– closing the alerts.

    the alerts don’t tell you what management packs they are in, but they tell you the GUID of the rule or monitor that caused them. now, assuming you follow awesome naming convention practices, your management pack ID should be in the ID of all your rules and monitors, and you can close the alerts based on the rule or monitor ID/name.

    if you don’t follow awesome naming convention practices, there are other options. once you identify the rules and monitors, they both have a method called “getmanagementpack”.

    so as an example, let’s close all open alerts created by rules in the management pack with displayname “EMC Storage Integrator Monitoring”, and list the names of the alerts we close.

    $rulealerts=get-scomalert | where {$_.ismonitoralert -eq $false -and $_.resolutionstate -ne 255}
    foreach ($rulealert in $rulealerts) {
    $rule=Get-SCOMRule -id $rulealert.monitoringRuleId
    if ($rule.GetManagementPack().DisplayName -eq “EMC Storage Integrator Monitoring”) {
    $rulealert.ResolutionState=255
    $rulealert.name}
    }

    for monitors, there are a couple of ways… we can find all unhealthy instances of classes monitored by monitors in a management pack and reset them, or we can parse through all alerts like we did with rules. I also like to assume that every monitor in the world closes its alerts when its health is reset. here’s the first way, for the same MP:

    $mpmonitors=Get-SCOMMonitor | where {$_.getmanagementpack().displayname -eq “EMC Storage Integrator Monitoring”}
    foreach ($mpmonitor in $mpmonitors)
    {
    $monitoredclass=get-scomclass -name $mpmonitor.target.Identifier.Path
    $unhealthyinstances=get-scomclassinstance $monitoredclass | where {$_.HealthState.value__ -gt 1}
    foreach ($unhealthyinstance in $unhealthyinstances){
    $unhealthyinstances.ResetMonitoringState($mpmonitor)
    }
    }

     

    you could spruce these up with parameters and whatnot, but I think they will accomplish what you want (that is to say, they worked in my testing, but your mileage may vary 🙂 ).

     

  2. Scombag Post author

    Curt you are the man!, this is awesome, thanks for your rapid response. I am sure many people will find this very useful, myself included.

  3. Scombag Post author

    The rule script was listing the rules but not closing them, a colleague of mine took a look and amended the script as follows to get it working, he also added some additional code to output if no alerts are present

    #Operations Manager module import
    Import-Module OperationsManager
    write-host “Getting all alerts generated by Rules for the INSERT MP NAME” -foregroundcolor magenta

    $rulealerts = get-scomalert | where {$_.ismonitoralert -eq $false -and $_.resolutionstate -ne 255}
    $i = 0
    foreach ($rulealert in $rulealerts) {
    $rule = Get-SCOMRule -id $rulealert.monitoringRuleId

    if ($rule.GetManagementPack().DisplayName -eq “INSERT MP NAME”) {
    $i++
    “Closing alert rule – ” + $rulealert.name + “….”
    $rulealert | set-scomalert -ResolutionState 255
    }
    }
    if ($i -eq 0){
    write-host “No open rules for INSERT MP NAME found at this time” -foregroundcolor yellow
    }

  4. curtmcgirt

    ah.  “$rulealert.ResolutionState=255” changes the resolutionstate column to ‘closed’ if I view the alert in powershell, but apparently doesn’t actually update the alert in scom. I found some other articles online that use this method, and I just needed to follow it up with $RuleAlert.Update(“”) to actually get it to update the alert in scom.

    if ($Rule.GetManagementPack().DisplayName -like “*EMC*”)
    {
    $RuleAlert.ResolutionState = 255
    $RuleAlert.Update(“”)
    }

    i’m not sure why the Update method requires an argument, but oh well.

    there’s also a “Resolve-SCOMAlert” cmdlet we could have used.

    $RuleAlert | Resolve-SCOMAlert

     

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.