SCOM Auto Resolve
Some of my rules are waiting for 30 days to close (as I'd expect since they don't change the health as a monitor does) but some are closing after 7 days following the setting - "Resolve all active alerts when the alert source is healthy after". Question, is, I thought rules have nothing to do with healthy/unhealthy according to this article (http://technet.microsoft.com/en-us/library/hh457603.aspx) so why would it determine a rule is healthy especially if it is just alerting on an event log? This setting states that the alert has to be "healthy" to close after 7 days. What does a rule have to do with health?
July 31st, 2014 2:45pm
Some of my rules are waiting for 30 days to close (as I'd expect since they don't change the health as a monitor does) but some are closing after 7 days following the setting - "Resolve all active alerts when the alert source is healthy after". Question, is, I thought rules have nothing to do with healthy/unhealthy according to this article (http://technet.microsoft.com/en-us/library/hh457603.aspx) so why would it determine a rule is healthy especially if it is just alerting on an event log? This setting states that the alert has to be "healthy" to close after 7 days. What does a rule have to do with health?
Free Windows Admin Tool Kit Click here and download it now
July 31st, 2014 2:45pm

Hi,

Please refer to the links below:

How grooming and auto-resolution work in the OpsMgr 2007 Operational database

http://blogs.technet.com/b/kevinholman/archive/2012/03/23/2644996.aspx

How to Close an Alert Generated by a Monitor

http://technet.microsoft.com/en-us/library/hh212689.aspx

August 1st, 2014 8:56am

Xin,

I'm quite aware of how grooming and auto resolution work in SCOM. The question was, why are RULES (not monitors) closing after 7 days which means they are changing the health state? I don't see anything built into the rules that would determine a state change. I didn't think rules had anything to do with health (as do monitors) as is mentioned in the Technet article I referenced.



  • Edited by Matt MS Friday, August 01, 2014 2:22 PM none
Free Windows Admin Tool Kit Click here and download it now
August 1st, 2014 2:18pm

Xin,

I'm quite aware of how grooming and auto resolution work in SCOM. The question was, why are RULES (not monitors) closing after 7 days which means they are changing the health state? I don't see anything built into the rules that would determine a state change. I didn't think rules had anything to do with health (as do monitors) as is mentioned in the Technet article I referenced.



  • Edited by Matt MS Friday, August 01, 2014 2:22 PM none
August 1st, 2014 2:18pm
Everyday we get alerts at  4 AM which I'm aware is due to the auto resolution rule executing a script. So alerts are closed based on the Automatic Alert Resolution settings in the global alert settings. Question is, one of them refers to closing all active alerts when the alert source is healthy after 7 days. I have several rules that are closing with this auto resolution setting. I thought only a monitor was capable of changing health states where a rule doesn't affect health. If that is true than why are rules auto closing after 7 days as if they had once changed the health to unhealthy and than somehow health returned to normal and 7 days after that they are closing. Doesn't that only apply to monitors?
Free Windows Admin Tool Kit Click here and download it now
August 4th, 2014 8:44pm

There are two settings for alert resolution. Check whether you have the first setting configured for 7 days, or the default 30 days.

August 4th, 2014 10:46pm
The first setting is configured for 7 days. The question isn't the time but more why are rules closing by themselves?
Free Windows Admin Tool Kit Click here and download it now
August 5th, 2014 3:48pm
This setting applies to all alerts, not just monitor-generated alerts. The second setting applies to monitor-generated alerts.
August 5th, 2014 6:46pm

I meant the second setting actually

"Resolve all active alerts when the alert source is healthy after"

Any ideas?

Free Windows Admin Tool Kit Click here and download it now
August 5th, 2014 8:28pm
Yes, the second setting is for monitors. Specifically, it is for monitors that do not have an auto-resolve setting.
August 5th, 2014 10:37pm

there are two options in auto alert resolution in SCOM
1) Resolve all active alerts in the new resolution state after:
  configure all active alerts with a resolution state of New to be changed to Closed after a specific number of days.
2) Resolve all active alerts when the alert source is healthy after:
configure all active alerts with a resolution state of New to be changed to Closed after a specific number of days when the alert source is healthy.


The impact of setting the alert resolution state to Closed depends on whether the alert was generated by a rule or a monitor. If you close an alert that was generated by a rule and the issue continues or occurs again, another alert will be sent. Closing an alert that was generated by a rule when the issue is not fixed is not a problem, because the rule will generate another alert.However, an alert that is generated by a monitor is sent only when the state for the monitor changes from healthy to some other state (warning or critical). If you close an alert that is generated by a monitor when the issue is not fixed, no other alerts will be sent. The auto alert resolution setting, both options, in SCOM affects both monitored-generated and rule-generated alert.
By default, option 1 is 30 days and option 2 is 7 days.
a) An alert is generated by monitor, with manual reset, which change the alert source from healthy to warning or critical state and the problem is solved at 6th day. The alert is still in New resolution state and it change into closed state after 7 days.
b) An alert is generated by monitor, with manual reset, which change the alert source from healthy to warning or critical state and the problem is not solved after 30 days. The alert is still in New resolution state and it change into closed state after 30 days, closed by the option 1) setting. The same alert will not generated again until the alert source is changed back to healthy state.
c) An alert is generated by rule, which do not change the alert source state and the problem is not solved. The alert source is in health state at 7th day and as a result the alert resolution state is changed into closed state at 7th day. Afterward, another new alert will generated because the problem is not solved.
d) An alert is generated by rule, which do not change the alert source state and the problem is not solved. The alert source is in critical state and as a result the alert resolution state is changed into closed state after 30 days. Afterward, another new alert will generated because the problem is not solved.
Roger

Free Windows Admin Tool Kit Click here and download it now
August 6th, 2014 3:05am

there are two options in auto alert resolution in SCOM
1) Resolve all active alerts in the new resolution state after:
  configure all active alerts with a resolution state of New to be changed to Closed after a specific number of days.
2) Resolve all active alerts when the alert source is healthy after:
configure all active alerts with a resolution state of New to be changed to Closed after a specific number of days when the alert source is healthy.


The impact of setting the alert resolution state to Closed depends on whether the alert was generated by a rule or a monitor. If you close an alert that was generated by a rule and the issue continues or occurs again, another alert will be sent. Closing an alert that was generated by a rule when the issue is not fixed is not a problem, because the rule will generate another alert.However, an alert that is generated by a monitor is sent only when the state for the monitor changes from healthy to some other state (warning or critical). If you close an alert that is generated by a monitor when the issue is not fixed, no other alerts will be sent. The auto alert resolution setting, both options, in SCOM affects both monitored-generated and rule-generated alert.
By default, option 1 is 30 days and option 2 is 7 days.
a) An alert is generated by monitor, with manual reset, which change the alert source from healthy to warning or critical state and the problem is solved at 6th day. The alert is still in New resolution state and it change into closed state after 7 days.
b) An alert is generated by monitor, with manual reset, which change the alert source from healthy to warning or critical state and the problem is not solved after 30 days. The alert is still in New resolution state and it change into closed state after 30 days, closed by the option 1) setting. The same alert will not generated again until the alert source is changed back to healthy state.
c) An alert is generated by rule, which do not change the alert source state and the problem is not solved. The alert source is in health state at 7th day and as a result the alert resolution state is changed into closed state at 7th day. Afterward, another new alert will generated because the problem is not solved.
d) An alert is generated by rule, which do not change the alert source state and the problem is not solved. The alert source is in critical state and as a result the alert resolution state is changed into closed state after 30 days. Afterward, another new alert will generated because the problem is not solved.
Roger

I'm pretty sure your scenario "c" is not correct, as this setting only applies to monitors. The first setting applies to rule and monitors. Rule-generated alerts are not state machines, so they do not know when the source is hea
August 9th, 2014 2:50am
There must be some logic in the rules included with certain management packs (HP Proliant, for example). A hard disk fails and we see an alert is created from a rule (this rule is looking at a log in event viewer for the failed hard disk). Seven days later (and after the drive is replaced) the alert auto resolves when the database task runs at 4 AM. Again, this is from a rule not a monitor and seems to close after 7 days like it has been healthy for that long.
Free Windows Admin Tool Kit Click here and download it now
August 19th, 2014 4:31pm
Now we are talking about 3rd party MP's and connectors. These could have their own auto-resolve settings that do not conform to SCOM settings.
August 20th, 2014 2:36am

there are two options in auto alert resolution in SCOM
1) Resolve all active alerts in the new resolution state after:
  configure all active alerts with a resolution state of New to be changed to Closed after a specific number of days.
2) Resolve all active alerts when the alert source is healthy after:
configure all active alerts with a resolution state of New to be changed to Closed after a specific number of days when the alert source is healthy.


The impact of setting the alert resolution state to Closed depends on whether the alert was generated by a rule or a monitor. If you close an alert that was generated by a rule and the issue continues or occurs again, another alert will be sent. Closing an alert that was generated by a rule when the issue is not fixed is not a problem, because the rule will generate another alert.However, an alert that is generated by a monitor is sent only when the state for the monitor changes from healthy to some other state (warning or critical). If you close an alert that is generated by a monitor when the issue is not fixed, no other alerts will be sent. The auto alert resolution setting, both options, in SCOM affects both monitored-generated and rule-generated alert.
By default, option 1 is 30 days and option 2 is 7 days.
a) An alert is generated by monitor, with manual reset, which change the alert source from healthy to warning or critical state and the problem is solved at 6th day. The alert is still in New resolution state and it change into closed state after 7 days.
b) An alert is generated by monitor, with manual reset, which change the alert source from healthy to warning or critical state and the problem is not solved after 30 days. The alert is still in New resolution state and it change into closed state after 30 days, closed by the option 1) setting. The same alert will not generated again until the alert source is changed back to healthy state.
c) An alert is generated by rule, which do not change the alert source state and the problem is not solved. The alert source is in health state at 7th day and as a result the alert resolution state is changed into closed state at 7th day. Afterward, another new alert will generated because the problem is not solved.
d) An alert is generated by rule, which do not change the alert source state and the problem is not solved. The alert source is in critical state and as a result the alert resolution state is changed into closed state after 30 days. Afterward, another new alert will generated because the problem is not solved.
Roger

I'm pretty sure your scenario "c" is not correct, as this setting only applies to monitors. The first setting applies to rule and monitors. Rule-generated alerts are not state machines, so they do not know when the source is hea
Free Windows Admin Tool Kit Click here and download it now
August 29th, 2014 2:22am
Ok, hopeless. Let me look into this further, and I will update the thread. It would be easy enough to look at the stored procedure, but it's even easier for me to adjust my retention setting and find out. I'll keep you posted.
August 29th, 2014 2:44am
Are these special rules from a 3rd party management pack that close after 7 days as Roger pointed out above? I thought rules were stateless so being healthy for 7 days only applies to monitors. However only some of my rules close after 30 days, but many after 7. There must be logic built into these management packs and the 7 day auto close only applies to the built in default rules. But the rule Roger is talking about above is from the System Center Core Monitoring MP which is a default MP.
Free Windows Admin Tool Kit Click here and download it now
June 20th, 2015 12:54pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics