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 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.