When you close an alert generated by a monitor or rule and the concering problem has nog been solved yet, is that alert generated again somehow? And what about resetting the health of a monitor when the corresponding problem still persists? Does the warning or critical state comes back somehow? Thanx in advance.

Hi, I guess you are talking about alerts generated by rules or monitors that dont auto resolve. The alert will not be regenerated unless the state change (or the rule detects the offending event again) happens again. Regarding monitor health, every monitor will execute on a frequency. So if you reset to healthy it when the problem is not resolved, it will go back to warning or critical state when it executes again. On another note, why do you want to reset the monitor health or resolve the alert? It is advisable to resolve alerts only when the problem is resolved. Thanks, ShreedeviThis posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

Maybe this helps you: Reset Health: If you execute this, the state would always go healthy regardless of what the current state is. This is because the SCOM server never contacts the client to find the current state, rather just sets the state to healthy. When the client runs the monitor on the next schedule or when a threshold is crossed, it would send the data to the server then. The server would change the state to warning or critical or would stay at healthy state if everything is working.<o:p></o:p> <o:p> </o:p> Recalculate Health: If you execute this, the current state is not changed to Healthy. The SCOM server will contact the client and retrieve latest information from the client and then update the state to the current state. If the monitor is critical right now, SCOM would not change that to Healthy right away. It would first contact the client and find the information first and then change the state appropriately. In most cases , Using either one would eventually crop the alert again once the client contacts to the server and delivers all the data.... -- Regards, Vik Singh -------------------------------------------------------------------------------- Please remember to click ??Mark as Answer? on the post that helps you, and to click ??Unmark as Answer? if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread. "Shreedevi Padmasini [MSFT]" wrote in message news:fe96993c-31f9-41db-b4fc-0b049515854e@communitybridge.codeplex.com... Hi, I guess you are talking about alerts generated by rules or monitors that dont auto resolve. The alert will not be regenerated unless the state change (or the rule detects the offending event again) happens again. Regarding monitor health, every monitor will execute on a frequency. So if you reset to healthy it when the problem is not resolved, it will go back to warning or critical state when it executes again. On another note, why do you want to reset the monitor health or resolve the alert? It is advisable to resolve alerts only when the problem is resolved. Thanks, Shreedevi This posting is provided "AS IS" with no warranties, and confers no rights. Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

And remember - recalc wont work for 99% of the monitors - this is only if there is an on demand probe as part of the monitortype.

I guess you are talking about alerts generated by rules or monitors that dont auto resolve. The alert will not be regenerated unless the state change (or the rule detects the offending event again) happens again. This will be the case for monitors and rules that do auto-resolve as well, right? I am asking these questions because I would like to know what happens when someone closes an alert by mistake.

Maybe this helps you: Reset Health: If you execute this, the state would always go healthy regardless of what the current state is. This is because the SCOM server never contacts the client to find the current state, rather just sets the state to healthy. When the client runs the monitor on the next schedule or when a threshold is crossed , it would send the data to the server then. The server would change the state to warning or critical or would stay at healthy state if everything is working.<o:p></o:p> I think you mean when the next schedule AND when a threshold is crossed. Right?

And remember - recalc wont work for 99% of the monitors - this is only if there is an on demand probe as part of the monitortype. Not sure what you mean here. Could you explain a bit more?

Hi Chris There are a number of threads that discuss this that may be of interest: http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/e6727191-26f7-4bd5-a761-edfbc39ca726 http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/0d436430-b057-4638-82a8-6506bc7f3e0d http://social.technet.microsoft.com/forums/en-us/operationsmanagergeneral/thread/167F300E-91CF-4A3F-B7F4-66E3353A6F35 In response to your 2 questions above 1) "I think you mean when the next schedule AND when a threshold is crossed. Right?" Correct. 2) "Not sure what you mean here. Could you explain a bit more?" - basically the recalculate health button is mainly eye candy. It won't work for 99% monitors due to the way they are authored. Hope it helps Graham Cheers Graham View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

Thanks Graham!