Ability to turn off alerts not able to be closed in SCOM 2019
We need to be able to disable the feature preventing alerts from being closed if the monitor is in an unhealthy state.
As it currently stands integration with a Service desk such as Netcool is problematic as if the alert is closed in the service desk when the writeback happens to SCOM the chain breaks as the alert cannot always be closed in SCOM.
If you close an alert generated by a monitor (from the Operations Console “Active alerts” view) which is in a unhealthy state then the following message will be displayed and the alert will not be closed:
“Alert(s) in the current selection cannot be closed as the monitor(s) which generated these alerts are still unhealthy. For more details on the alerts which could not be closed, view the “Alert Closure Failure” dashboard in the Operations Manager Web Console”
We are reviewing this change and would like to know the kind of problems faced by customer. Please reach out to the below email address with more details —> email@example.com
Appreciate your feedback.
Patrick Seidl (s2) commented
This is a nightmare. By when do you finally fix it?
This definitely needs to be remedied.
Kevin Holman commented
I just had more customer feedback. They are impacted by this issue, when they place servers into Maintenance Mode. Their operations process is to close the alerts once the server is in MM. However, we only allow alert closure when the alert source is "healthy" and SCOM 2019 UR1 with Hotfix is blocking their ability to close alerts manually for agents that are placed into Maintenance Mode. This is just another reason why we need to be able to disable this new feature in SCOM 2019 for customers whose operations processes don't easily leverage the design change.
Completely agree with you here. It is a pain with the integration for Service Desks and in our case, we use an Orchestrator solution which fails to update the alert due to the restriction.
But...and I keep pondering on this, whilst I can easily add a runbook, or an action within the existing runbook to reset the monitor, at the end of the day this is only really going to be useful if the issue has definitely been fixed and it is something like a manual reset monitor.
If people are just closing incidents to clear their view, not only is it just going to come back, but it will cause many state changes.
The resolution surely has to be to fix the issue. Of course as mentioned, this does leave the manual reset monitors.
I've tried educating people till I am blue in the face, but people don't like seeing incidents in their queue and in some cases driven by closures :-(
I agree it needs looking in to, but still not sure myself what the best way would be to approach this so that it is not a blocker, but also not going to be impacting to SCOM
José Costa commented
Nearly one year later and no addon or fix to make this optional has been deliverable. Might as weel forget this or in case you've got integrations hurt by this then might as well forget SCOM altogether...
Bob Cornelissen commented
I do love this feature, as somebody who works with dashboarding a lot. And people close all kinds of alerts without the issue being solved and all dashboards stay red. And now they are red without an alert that belongs to it.
However I do also see how connected tools do not have a function to reset health (which should close the alert). Those third party tools should get a way of doing that, so they can change their product connectors to solve this issue (which should work for SCOM 2012R2/2016 etc as well if possible).
It would be helpful is dashboarding tools, including SCOM itself in console and web console has tasks available on an alert coming from a monitor to immediately reset health.
Of course there is always the common case of people closing alerts and resetting health to monitors if needed even if the issue is not solved yet, but that is a matter of training.
Tomas Thönell commented
Maybe give us the choise to reset the monitor when closing instead of refusing it all together?
We monitor hundreds of Citrix servers which are constanly being recycled/restaged, so pop in and out of SCOM regularly. Now the console is full of heartbeat failure alerts which I am no longer able to get rid of!
Ralf Kermes commented
I agree with Mr. Holman.
We must have the Choice to close the Active Alerts generated by a Monitor manually.
Additionally in view of collaboration between SCOM and our Ticket System.
Patrick Seidl (s2) commented
YES, the new feature is great in theory but not practical.
It should be possible to disable it and it would be great to finally reset a monitor on alert closure.
I don't say this should go, it should be improved.
@MSFT: read the comments after "fixing" this: https://systemcenterom.uservoice.com/forums/293064-general-operations-manager-feedback/suggestions/9356712-a-way-to-reset-monitors-automatically-when-alert-i
Mark Slootweg commented
I agree with Michel van der Zijden. The ticketing system should be an administrative tool only. Tickets should be closed when the underlying problem is solved (the monitoring alert in scom).
Michel van der Zijden commented
I'm strongly against removal/changing of this great feature. An alert, triggered by a monitor, should never be closed while the monitor is still in an unhealthy state. You should fix the problem (or tune the monitor) after which the alerts closes. I think this functionality, of not being able to manually close monitor alerts, is one of the great additions of SCOM 2019.
We are working with a ServiceNow integration and have found the health states to be an issue as well.
We have chosen to not allow the event management tool to close monitors but to either reset health or mark them as resolved.
Alerts in a resolved state for an extended amount of time should be reviewed.
I think that instead of SCOM erroring out when an alert triggered by a monitor is closed it should perform the health reset.
Pedro Tedim commented
I can't understand why some people here say they would downvote this request, or that it doesn't make sense for them, etc...
The request is for "Ability to turn off alerts not able to be closed in SCOM 2019", meaning it would be something controlled by the SCOM admin either to turn that on or Off...
Please implement this as this is the biggest pain in our day to day work with SCOM, we lose dozens of hours a week with this alone
Howard Brown commented
I would downvote this if it were possible. We educate our users here (and have through previous iterations of SCOM), so they understand the difference between a monitor and a rule. Letting users close monitors when the object stays unhealthy was always a huge pain for us, and caused a lot of support issues. However, I can see how this would be a pain in SquaredUp (we're not up to 2019 yet, we're still building the migration strategy from 2012 R2). I would think if you are using SquaredUp, and since they already determine whether an alert is a monitor or rule generated alert to change the alert icon, that it would be easy to change the function of the close button and make it a reset button - but that's a SquaredUp feature request, and not something for SCOM itself.
Scom Guy commented
This feature is terrible. We send alerts to our ticketing system and we have a SquaredUp instance where our customers can close tickets out when they deem necessary. However, this now blocks that workflow and I'm not about to tell them that now, you first have to log into here, and then go here to reset the health, and then you can go back and close the alert. I'm sure there was a reason for this feature, but I don't think it should have been forced upon. There should have been the option somewhere in the Mgmt Console to enable/disable. Not a good start for SCOM 2019 IMO.
I'm a main SCOM guy in our shop. We do not like this change one bit. Sure, we had custom script running that resets unhealthy monitors for closed alert. But still current design where You have close menu option and then a seconds later warning box that i cannot actually close the alert.. Its infuriating, its like close alert functionality was removed. We greatly dislike this feature, but i understand why it was implemented. Still would like to be able to turn it off. Even with unsupported hack.
I stand by my suggestion that closed monitors trigger a reset... I know there's issues with that from a performance standpoint, but I think it makes more sense to just rearchitect and accept it.
Kevin Holman commented
This is going to be critical. Not all customers will like or benefit from this change. Many customers are happy about this - but it will be a deployment blocker to others. This must be something that can be switched on or off in Alert closure behavior - or we will break the Alert Lifecycle policy of customers who have invested deeply into integrations for alerts to ticketing systems, in my opinion.