Alerts from monitors not auto resolving and stay in console
Hi, I've seen some alerts which stay in the console indefinately and only resolve when I run health explorer and recalculate health. An example (though I don't think its a unique case) is the APP-V MP - Data Store Access - Diagnoser - Application monitor which is set to autoresolve = True. When this alert fires, the health state of the machine (and the alert) remains unhealthy until I manually recalc health. Is there any way to build into the monitor, or regular 'housekeeping' task to recalc health of an agent. I have seen posts that say not to programatically resolve alerts beyond a time period but rather let autoresolve/DB grooming take care of it. My problem is that its affecting our internal KPI's if these 'new' alerts remaining in the console (and agent state stays unhealthy) even when the issue is resolved and 'should' automatically have resolved. Has anyone else had simialr issues and workarounds for any monitors not autoresolving?... Thanks
October 19th, 2010 5:59pm

Is the monitor set to auto-resolve? Only monitors which are set to auto-resolve will resolve the alert generated by the monitor when the condition is healthy again. And If the alert is generated by a rule the alert will never be resolved automatically. Certifications: MCSA 2003|MCSE 2003|MCTS(4*)| MCTIP:SA
Free Windows Admin Tool Kit Click here and download it now
October 19th, 2010 6:21pm

Hi, From what I understand, your problem is not just the alert not resolving, but also the monitor state not going back to healthy. Check the frequency of the monitor to see how often it executes and if it is set to a really high value. The monitor state will not change if the monitor does not re-check health. The "autoresolve" parameter would be for the alert. What this means is that when the monitor goes back to healthy, the alert would autoresolve. 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
October 19th, 2010 11:02pm

Shadowman, yes the alert is from a monitor and has the autoresolve parameter set to TRUE. Shreedevi, I had tried to find the frequency of the monitor but its not a parameter in the overrides and I can't find and reference to frequency in the monitor properties or looking at the XML of the unit monitor using MPViewer tool. The only thing I did notice in XML (I've copied the header of it below) is the TypeID="Windows!Microsoft.Windows.SingleEventLogManualReset2StateMonitorType" - Is this saying its actually a minitor which requires manual reset? UnitMonitor ID="Microsoft.AppVirtualization.Server.45.VirtualApplicationServer.DataStoreAccess_Diagnoser" Accessibility="Public" Enabled="true" Target="Microsoft.AppVirtualization.Server.45.VirtualApplicationServer" ParentMonitorID="Microsoft.AppVirtualization.Server.45.VirtualApplicationServer.DataStoreAccess.HealthState" Remotable="true" Priority="Normal" TypeID="Windows!Microsoft.Windows.SingleEventLogManualReset2StateMonitorType" ConfirmDelivery="false"> <Category>EventCollection</Category> Thanks...
Free Windows Admin Tool Kit Click here and download it now
October 20th, 2010 10:51am

Hi, Regarding the monitor types, please also refer to:: Common Monitor Types http://technet.microsoft.com/es-es/library/dd362754.aspx UnitMonitorType http://msdn.microsoft.com/en-us/library/ee533935.aspx I would also like to share the following with you for your reference: Manually Resetting a Monitor http://blogs.technet.com/b/brianwren/archive/2007/08/22/manually-resetting-a-monitor.aspx Hope this helps. Thanks. Nicholas Li - MSFT 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.
October 22nd, 2010 10:44am

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

Other recent topics Other recent topics