I’ve had a few questions about how to do this right in recent weeks, so I thought I would provide some additional guidance. I pointed out a problem in customizing the alert description with performance counter data, so please read that section carefully. I’d be interested to hear if your results vary from my findings.
I’d talked in the past about the issues with the Exchange 2003 queue monitoring focused on the fact that the default monitors (shown in figure 1) are 2-state baselining threshold monitors, which, after 7 days of good Exchange performance, raise alerts too quickly when the queue values move from zero (0).
I propose that these should be replaced in most environments with a recurring threshold monitor to provide a more predictable notification pattern in conditions of Exchange queuing.Shown in figure 1 are the queue monitors I have found to be the noisiest of the lot. When you target your view to the Exchange Queue class, you’ll see more than just these – let the alert noise in your environment guide your decisions in disabling any self-tuning monitors in favor of the recurring threshold monitor.
Figure 1. Exchange 2003 2-state baselining monitors for Exchange Queues
Recommended Alternate Configuration
I suggest using the recurring threshold monitor to setup two alert levels for each of the Exchange 2003 queues shown in figure 1 – one for warning and one for critical. I start with 25 (warning) and (50 critical) and adjust from there based on the environment. HOWEVER, let the needs of your situation rule in this regard
. 
Figure 2. Recurring threshold monitor in OpsMgr
To Configure:
-
Begin by finding the problematic queue monitors shown in figure 1 and documenting the performance counters they use. In the Authoring space, scope your view to Exchange Queue and search on the word “queue”.
-
In the Operations console, browse to the Authoring space and select Monitors.
-
Right click and select New Monitor à Unit Monitor àWindows Performance Threshold à Single Threshold à Consecutive samples over threshold
-
Before clicking Next, make sure you select a custom management pack in which to save these monitors.
-
On the General Properties screen, provide a monitor Name and Description, and set the target to object type Exchange Queue.
-
On the Performance Object, Counter and Instance screen, enter the performance counter, object and instance you documented in step 1. Set the desired Object, Counter and Instance.
-
On the Threshold Comparison Settings screen, set the desired threshold that represents the warning or critical threshold in your environment. (Again, I suggest monitors for each – one with a warning level and the other with a critical based on what you feel is appropriate in your environment). See figure 3 below as an example.
-
On the Configure Health screen, set the Health State for condition true (which represents the threshold breach) to Warning or Critical as appropriate.
-
On the Configure Alerts screen, check the “Generate Alerts” option and set the appropriate severity based on your configuration on the previous screen.
- Click Create and you’re done. If you created the monitor as disabled (MS best practice), then configure an override to enable for the group of Exchange servers as appropriate in your environment.The result should look similar to what you see in the example in figure 3. Adjust the number of samples and the threshold to suit your environment.
Figure 3. Threshold Comparison Settings
Customizing the Alert Description – IMPORTANT
There seems there may be a bug in the implementation of the recurring threshold monitor when you attempt to display the current queue value in the alert description. Normally when working with a Windows performance counter in a monitor, you would add the following xml string to the alert description field to present the current value of the counter:
$Data/Context/Value$
However, when we tried this in a recurring threshold monitor, the number returned was the number of polling samples (shown in figure 3) rather than the expected value of the performance counter we were sampling in the event. That being said, it may make sense to be sure there is a collection rule for each queue counter you update to present the value of the counter in a Performance View.
Check out the System Center Solutions Contest now in progress at the System Center Virtual User Group for a chance to win an Xbox 360, Zune 2 or other great prizes.
