Dear All, I added some servers in SCOM 2012 and SCOM raised the alerts according to the Management Pack. I closed alerts in 'Active Alerts' view. And I still can find them in Health Explorer. However, SCOM will not re-raise them in Active Alerts view. What I want to do now is that when I closed alerts, SCOM will still raise them according to the monitior states in Healthy Explorer. If the state is NOT healthy, I wish SCOM will keep raising the alerts even I manually closed it. I know SCOM raise the alerts when the monitoring state changed, if I can let SCOM raise the alerts when the monitoring state is not 'Healthy'? How can I achieve this?

As far as I know, scom will raise alert again even though you close the alert and the health state is not healthy. You may try to refresh the view after one minutes or reopen the operation console with clear cache option Roger

No. I meet the problem for a long time in my test enviroment. Rules can always be closed in the console as rules don't affect state. I have searched a lot on TechNet before I raised the question, you can take a look on this article:http://social.technet.microsoft.com/Forums/en-US/operationsmanagergeneral/thread/231e96ab-732f-445c-85d7-71d85c699c80 I am also curious about if SCOM2012 have fixed the problem(health state not sync with alert state).

Hi, there is no changes in this behavior in OpsMgr 2012. System will rise an alert ONLY when: - State was changed AND - Monitor is configured to alert you for this state (changed)http://OpsMgr.ru/

Ok. I see. So if any plans can be done to solve the problem: health state not sync with alert state? I still want to use 'Active Alerts' view to show all active alerts, but not check the computer from health explorer one by one... Thanks.

You can use a custom scripts: http://www.systemcentercentral.com/BlogDetails/tabid/143/indexid/19345/Default.aspx http://opsmgr.ru/Lists/Posts/Post.aspx?ID=290 (the post is in Russian)http://OpsMgr.ru/

You can use a custom scripts: http://www.systemcentercentral.com/BlogDetails/tabid/143/indexid/19345/Default.aspx http://opsmgr.ru/Lists/Posts/Post.aspx?ID=290 (the post is in Russian)http://OpsMgr.ru/

Yeah, I see the first one and it is a useful method to take these alerts back. But if another way can keep the opertaion in your script automatically? or the only way is to use a scheduler job to keep it run regularly?

There are two methods to achieve your goal. First is described above. Second is also script-based, but you should create a command notification subscription for closed alerts. When alert is closed this subscription will run a script and check is it an alert generated by a monitor AND closed manually (not by System). Second method could be a resource intensive task depending on how many alerts were closed at given time.http://OpsMgr.ru/

Hi Xianghua Cai, Two methods are not so effective...and why.. 1. As a simple method you're better to use the first method by Alexey (run custom script by scheduler), but it is not automatic (runs not ofter alert is closed) as you said.. and you should not unload it from memory as each time you need load powershell operationsmanager module which takes some time to load and consumes some resources . Because of this you can experience some additional delays. 2. The second method.. command channel for closed alerts, if you try to use it as is, you can encounter the following situation suppose you try to close about 20 or more alerts (generated by monitors) at the same time. Account which is used in Notification account Profile will try to start 20 separated powershell processes..but by default it's limited to 5 simultaneous processes ...so you'll miss some alerts which monitors must be reseted and they won't be reseted at all. Yes you can tune up the value of simultaneous processes by changing AsyncProcessLimit but you encounter the situation when your MS tries to run 20 separated powershell processes with scom powershell module.. each takes 100-200 MB and hang in memory during longer time as much more modules need to be loaded. So your MS loses a lot of memory and CPU resources ..about 2-4 GB (it's for 20 alerts only!!!). Think twice if you decide this method..Better to keep one process in memory (with all needed powershell modules, sometimes you need use other powershell modules in one script you know..) that helps to process all inf. from Scom command channel.

Hi Xianghua Cai, Two methods are not so effective...and why.. 1. As a simple method you're better to use the first method by Alexey (run custom script by scheduler), but it is not automatic (runs not ofter alert is closed) as you said.. and you should not unload it from memory as each time you need load powershell operationsmanager module which takes some time to load and consumes some resources . Because of this you can experience some additional delays. 2. The second method.. command channel for closed alerts, if you try to use it as is, you can encounter the following situation suppose you try to close about 20 or more alerts (generated by monitors) at the same time. Account which is used in Notification account Profile will try to start 20 separated powershell processes..but by default it's limited to 5 simultaneous processes ...so you'll miss some alerts which monitors must be reseted and they won't be reseted at all. Yes you can tune up the value of simultaneous processes by changing AsyncProcessLimit but you encounter the situation when your MS tries to run 20 separated powershell processes with scom powershell module.. each takes 100-200 MB and hang in memory during longer time as much more modules need to be loaded. So your MS loses a lot of memory and CPU resources ..about 2-4 GB (it's for 20 alerts only!!!). Think twice if you decide this method..Better to keep one process in memory (with all needed powershell modules, sometimes you need use other powershell modules in one script you know..) that helps to process all inf. from Scom command channel.

Another option using Orchestrator (as you are using SCOM 2012, you are licensed for Orchestrator 2012): http://blog.scomfaq.ch/2012/05/05/reset-monitor-using-scom-2012-and-orchestrator-a-must-have-runbook/Regards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

Another option using Orchestrator (as you are using SCOM 2012, you are licensed for Orchestrator 2012): http://blog.scomfaq.ch/2012/05/05/reset-monitor-using-scom-2012-and-orchestrator-a-must-have-runbook/Regards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/

Yes Orchestrator is also can be used.. but the problem is not solved as we have no activity in scom IP to reset monitors and we have to link the same script to reset monitor.

Correct - my thought was more to offload the work from SCOM command channels. Cheers GrahamRegards Graham New System Center 2012 Blog! - http://www.systemcentersolutions.co.uk View OpsMgr tips and tricks at http://systemcentersolutions.wordpress.com/