SCOM: One More Use for Custom Resolution States – A “Closed by Operator” State

I had previously written a post about using customization of SCOM’s resolution states to generate an additional notification, on-demand, in order to send the event to a helpdesk software system.  Another resolution state customization that I have found useful facilitates the opposite effect, preventing notifications. 

Unlike those generated by monitors, alerts generated by rules in System Center Operations Manager are not linked to an object’s health state, and are not closed automatically.  Rather, they must be closed manually (in the console or with a script) or deleted after a set period of time (database grooming).  While it is typically desirable for notifications to be generated when alerts generated by monitors are closed, as an indication of the conditions resolution, this is not usually desirable for alerts generated by rules, as the notification would just indicate that an operator closed the alert.   This is particularly true if operators are not managing the console 24/7. 

If notification subscriptions are scoped to classes or groups (and not individual rules/monitors), an easy way that I have found to prevent notifications when rule-generated alerts are closed is by adding a custom resolution state with the name: “Closed by Operator” and a value such as 254 and then modifying the Open alert views in the Operations Console to filter on resolution status less than 254 (instead of “not equal to 255”).  This has the effect of logically assigning two potential closed states for alerts, the system default Closed state of 255 and the “Closed by Operator” state of 254.   In the Operations Console, operators can right click an alert, choose Set Notification State and choose “Closed by Operator,” clearing the alert from the open alert views, and not generating a notification. 

Figure 1


About Kristopher Bash
Kris is a Senior Program Manager at Microsoft, working on UNIX and Linux management features in Microsoft System Center. Prior to joining Microsoft, Kris worked in systems management, server administration, and IT operations for nearly 15 years.

2 Responses to SCOM: One More Use for Custom Resolution States – A “Closed by Operator” State

  1. Thanks. I am looking for something similar. I want to introduce a new status say something like “Cleared”, and want to retain the history of the alert. In the sense, if the same alert condition is true again, I want the alert to be reopened, and the repeat count to be incremented. Is that possible? Can you check this out and let me know?

  2. Will says:

    Hi, I would like to know if there is a way to perform the following using these custom resolution states:

    I have a 3rd party application that accepts XML input to generate a ticket (it’s a Helpdesk call logging system). This is generated by a subscription from within SCOM for a fault. This current works successfully to generate a ticket in the call logging system. What I would like to do in the event of an update to the SCOM alert; or the closure of a SCOM alert to feed this to the ticket and update/close it in the call logging system. I suspect that this would need the id number of the ticket in the call logging system to update/close as required. What do I need for the call logging system to write back to SCOM with a “reference” or “ticket number” and then for SCOM to use that number to update / close tickets in the call logging system?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: