SCOM: One More Use for Custom Resolution States – A “Closed by Operator” State
August 25, 2009 2 Comments
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.
About Kristopher Bash
Operating-Quadrant 
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?
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?