On any Operations Manager administrators daily to-do list should be alert review and rule tuning.

Effective alert tuning means that every alert should ideally have its place. This does not always work out, but you definitely want to have a bucket for classifying most common possibilities. Generally this is done with custom alert resolution states (only NEW and CLOSED exist by default).

The underlying philosophy is that consistent evaluation of alerts, and appropriate disposition leads to 1) a higher percentage of actionable alerts over time, 2) remediation of lingering service issues in the environment and 3) greater respect for Operations Manager and the importance of the monitoring function by IT support staff and service owners 4) and theoretically, better tuned (and thus better performing) IT services.

Here is an example of a very basic, yet effective system for daily processing alerts. For each active alert:

1. Resolve alert if condition no longer exists (transient failures)
2. Remediate the issue represented in the alert
3. Escalate to next support tier or SME (using custom resolution state)
4. Tune the source rule or monitor as appropriate if the alert is not actionable. This may involve threshold or disable overrides.
5. Bug - I have a custom resolution state I use flag potential bugs to investigate and/or report back to MS.
6. Other - Some alerts I have to flag with a resolution state for later investigation on my part, such as with runtime script failures.

Some organizations use custom resolution states to assign alerts to service owners or teams (e.g. - a resolution state of ‘Assign to Exchange team’). This is fine, but at the end of the day, this method does not prompt immediate action from the service administrator - and let’s face it, occasionally a more direct approach is warranted.

That’s why I love the Alert Forward Task MP (from Cameron Fuller), which is the MP that allows you to forward an alert via e-mail to an address you supply when you launch the task.

I have modified the version I use just a bit. I modified the script to include Please Investigate: in front of the alert name in the subject line. The From: address is a shared mailbox for the Opsmgr admin team. When I find a legitimate alert that needs to be investigated (particularly one that has been ignored or missed by service administrator for several days, weeks or months), I simply click the forward alert via e-mail task and send a friendly reminder. (Hey, what’s up? It’s me. You know, that alert you’ve been ignoring?)

I find this action always launches discussion, and frequently leads to collaboration between myself and the service administrator, and often quick resolution of important issues. If you don’t use custom resolution states and the Alert Forward Task MP today, I definitely encourage you to consider how these tools can improve both the effectiveness of your monitoring initiatives and have a positive impact the quality of your IT service delivery.