If you've used the MOM 2005 Exchange availability report, you probably accepted the default parameters (which are exactly one week from the current time) and got a report that looked something like the following:
|Server||Database||Availability %||Success/ Expected||Exchange Unavailable %||DC unavailable for authentication %||Other Failures %||No Measurements %|
You're likely to be asking the question, "Why do I have no measurements nearly 10% of the time?" Doesn't that make the report essentially worthless? A better question to be asking is what exactly is Microsoft Operations Manager reporting here. What exactly does "No Measurement %" mean?
The Exchange availability report is based on a MOM script that regularly pings the Exchange Server and Global Catalog Servers, looking for a response. Every time the script fires (which is 12 times per hour), it will record the results in the MOM event log, with the following event IDs:
9980 Successful logon
9981 DC unavailable
9982 Exchange unavailable
9983 Other failures
When the report is launched, it looks at the start time and end time parameters and calculates the expected number of events. By default, the report runs for a one-week period, which is the equivalent of 2016 events. If the MOM server has 2016 events during that date range, the No Measurement % value will equal zero. If the event count is less than 2016, the No Measurement % column will be adjusted accordingly for the number of missing data points.
The reasons for missing data points fall into two categories:
- The data has not been populated into the reporting database. This could be caused by either the refresh job failing, or specifying a date range that exceeds the boundaries of data in the database (either the data hasn’t been copied over yet, or it has been archived out of the database).
- The MOM agent script failed to fire. This is unusual, but can be expected about 0.1 % of the time. This doesn’t mean that Exchange or AD is unavailable, just that MOM failed to test it (for whatever reason).
Consider some of the following versions of the same report, with varying time parameters. The following reports were run on September 26, 2006.
|9/24/2006 4:00 PM||9/25/2006 4:00 PM||288/288||0%||0%|
|9/25/2006 4:00 PM||9/26/2006 4:00 PM||107/288||0%||62.85%|
|9/25/2006 4:00 PM||9/26/2006 1:00 AM||107/108||0%||0.93%|
|9/18/2006 4:00 PM||9/25/2006 4:00 PM||2008/2016||0.10%||0.30%|
|9/17/2006 4:00 PM||9/25/2006 4:00 PM||2295/2304||0.09%||0.30%|
|9/10/2006 4:00 PM||9/25/2006 4:00 PM||4301/4320||0.23%||0.21%|
|9/8/2006 4:00 PM||9/25/2006 4:00 PM||4877/4896||0.20%||0.18%|
|9/6/2006 4:00 PM||9/25/2006 4:00 PM||5186/5760||0.18%||5.04%|
|9/5/2006 4:00 PM||9/25/2006 4:00 PM||5186/5760||0.18%||9.79%|
The results produced seem to confirm my initial assertions. After the 18TH day, my "No Measurement %" began to increase rapidly. It was also incredibly high (63%) for the previous 24 hours, yet 0% for the 24 hours preceding that. I went back 19 days and started running the report for one day at at time. What I found was that the report offered no data during any of those one day periods. If it is not obvious to you yet, the MOM reporting database is being cleaned out, gradually, holding approximately 18 days of history (in my case, your mileage may vary). In addition, it appears that the reason my numbers for "No Measurement" are so high on the default weekly report is that the report is that 15 hours have passed since the last time the database was refreshed, so I am missing approximately 180 counters (or 8.9% of the missing data).
My conclusion, therefore is as follows. If your No Measurement column is less than 1.0%, it is likely do to some type of systemic failure in the MOM agent that prevented it from running the script that collects the availability data. If your number is greater than 1%, you should check your date parameters to see whether they are in line with what is actually contained in the reporting database. Remember, the refresh runs (by default) at 1:00 AM each day, so you should never run the default date parameters for the report. If you are specifying valid date ranges, and the No Measurement % value is extrordinary high, you might have a refresh problem with MOM and you should immediately check the SQL jobs to ensure they are running properly.