A while back we built out some conference room kiosk’s (discussed at http://cameronfuller.spaces.live.com/blog/cns!A231E4EB0417CB76!1509.entry) which display the status of a conference room using an Outlook Web Access calendar. We have run into issues where the connection to the OWA server would be lost and/or when other issues would occur which would cause these to stop functioning. To address these situations, we recently started monitoring these with OpsMgr 2007 R2.
One of the cool new functions in OpsMgr 2007 R2 is the integrated Process Monitoring Template. Prior to R2, there were ways to monitor processes but they were a bit clunky (I can say this, I wrote one which is available in the OpsMgr 2007 Unleashed book!). To provide monitoring for these systems, we needed there to be a single instance of the iexplore executable running on each conference room system. When this was not the state of the system, the conference room system needed to be rebooted.
The first step was to deploy the OpsMgr agent to these conference room systems. Next we created a custom group which contained only the conference room systems. After that we needed to create a Process Monitor for these systems as shown in these screenshots. We started by opening the authoring pane and adding a process monitor (Authoring / Management Pack Templates / Add Monitoring Wizard).
(It’s not recommended to use the default management pack when creating these. Create your own MP here to store any process monitors you are creating).
We are checking for the iexplore process name in this example to a custom targeted group we created which contain only the conference room systems.
For this example, we needed to monitor a minimum of 1 process, a maximum of 1 process, and we started testing at 1 minute. Eventually this last value was increased to 20 minutes to provide time to reboot the systems if it was required. We were not concerned for how long the process was running as that was not applicable for monitoring a conference room monitor.
We were not concerned about CPU usage or memory usage for this monitor so we left it with the defaults.
This is what the summary page looked like when the creation process was completed.
Now that we were monitoring these systems and had the process monitoring in place we could see their status within the Monitoring pane of the OpsMgr console as shown above within the Windows Service And Process Monitoring / Process State section.
The next step was to provide a recovery which would reboot the conference room systems if they did not have a single instance of the iexplore executable running. To do this, we opened the monitor to the Diagnostic and Recovery tab and created a server reboot task which executed automatically when
So now when conference rooms stop responding correctly, OpsMgr identifies the situation and reboots them to put them into a healthy state!
Summary: Check out the new Process Monitoring templtates OpsMgr R2. Fully integrated, monitor based and works like a champ!