More than often, you would like to be able to just close an alert in the SCOM console. Easy, right? And it actually is. But simply closing an alert in the console may not have the same effects if you are dealing with alert generated by monitors or alerts generated by rules.
Because of the way SCOM works, you usually can safely close alerts that are generated by rules, since if the condition repeats, the alert will come back. However, with monitors, by simply closing the alert, you may not see the alert again, unless there is a state change, why may never ever happen again. This can be particularly dangerous if you have, for example, a disk space alert. If you close the alert and disk space continues to be consumed, you will never get a new alert until the state flips again.
At a first glance, it may not seem to be necessary, since monitor will close by themselves. However, there are two main reasons: First, people seldom know what is the difference between a monitor or a rule and don’t know exactly how to determine that (and they frankly don’t care). Second, I’ve seen some specific monitor that won’t close by themselves (manual reset) and even some EventLog based monitors that will fail to find the Unhealthy condition and therefore, you’ll have an eternal alert in your console.
My suggestion here is an Alert console task, that will figure out where the alert was generated by a monitor or rule, then determine the best way to get rid of the alert. Remember that either way, if the problem is still there,you’ll still get a new a alert when the problem comes back.
The steps are pretty simple.
Open your SCOM console and navigate to the Authoring area, select Tasks and create a new task:
Select an Alert Task
Select a management pack (it is common knowledge, but always worth mentioning: Never used the Default MP!)
Configure as below:
Now, create a folder on ALL your computer that have a console. This is needed because it is a Console tasks, so, it happens wherever the console is.
Here’s the script.
The usage should be simple:
And the output:
In case the alert was generated by a rule, should be the same:
Now the comments on the script itself. Basic SCOM connectivity:
Find the alert:
If it finds it and it was generated by a monitor, it will find the instance of the monitor for object and reset the health of that monitor, for that instance only:
If generated by a rule, it is safe to just close it (set the resolution state):
Hope this helps!