VIDEO: Reset And Recalculate Health State

  • Article

Our TechNet web site and especially its video section went finally live with a training video I did some time ago. That video demonstrates functionality and differences between tasks which could change a health state after being spawned from within “Health Explorer”.

Brief description:

Reset State – In OpsMgr 2007 SP1 this task causes unit monitor state change to healthy regardless of its current state. This means that state change “Healthy (green) -> Healthy (green)” is possible as well.

Recalculate State – In OpsMgr 2007 SP1 this task always succeeds, but really works just for monitor implementing monitor type which defines on-demand detection. In my video I tried to show how one could use educated guess and recognize if there is on-demand detection without inspecting XML and particular monitor configuration by simply looking at the initial state change in “Health Explorer”. On-demand detection is present pretty much every time there is “Not Monitored -> X” and X is not healthy (green) or when X is green and the initial state change context is different than “monitor was initialized for the first time … ”

Here is direct link, enjoy and post question to this blog if some answers are needed.

Additional Note:

Implementation of Reset State from OpsMgr2007 RTM is equal to implementation of Recalculate State from OpsMgr2007 SP1.

Comments

  • Anonymous
    June 27, 2008
    Thanks for the article.  Do the web application monitors use on-demand detection?  If I recalculate the health of a failing web application monitor that is testing for specific content on a page, it appears to reset the health to green until the next scheduled test of the web application monitor runs.  I was expecting it to force a run of the web application monitor on-demand and report its status.  The context of the state change to healthy is "The monitor has been requested to recalculate state".

  • Anonymous
    July 15, 2008
    Web application monitors use resetting on-demand detection as you correctly observed. The reason is that their author choose not to implement module probing for current state but rather piped triggering module directly to runtime. In that case runtime is "forced" to set the state to green because it was not provided any other health state to use. It partially has historical reasons too. As I tried to explain in my article, with RTM version of OpsMgr, we only displayed “ResetHealth” and author wanted to fulfill such request.