OpsMgr 2007: Using the Performance Views in Monitoring to Troubleshoot Blank Performance Reports

It happens again and again in System Center Operations Manager 2007: The dreaded blank report. Your boss is breathing down your neck for performance data but all you get is a white page.

This can occur for a variety of reasons, including (but not necessarily limited to) the following:

1. The wrong type of object was selected as the report target.

2. The corresponding performance collection rule or the script that generates the performance data is not enabled for the report target.

3. There are functional problems on the agents.

4. One or more management servers are unable to insert data into the OperationsManagerDW database (see KB945946 for one cause of this problem).

5. Data is stuck in the staging tables in the OperationsManagerDW database.

For this blog, let's focus on Cause 1 and save the other items for later posts. Cause 1 is probably the most common and is also the easiest to diagnose and correct.

The important thing to remember is that performance reports typically have corresponding performance views in Monitoring. The performance views display the current data from the OperationsManager database, while the performance reports display historical data from the DW database. Performance views are useful when troubleshooting reports because the data displayed in the performance views is collected by the same rules that collect the data for the reports. Therefore, you can use the performance views to verify that the data is being collected. Additionally, the legends in the performance views will list the Path and Target for the objects that generate the data. Once you know this, you know which objects to select when configuring reports.

Here is an example: You want to run the Exchange Information Store Usage report from the Exchange 2003 Management Pack. You open the report, click the Add Object button and type the name of your Exchange 2003 backend server as the search string. A list of matching items is returned. The items are of various types. You see a Windows Computer, an Exchange Routing Group and an Exchange 2003 Role object. You should select the Exchange 2003 Role object, correct? Wrong. Selecting this one returns a blank report. So, which one should you choose? The answer is "none of the above."

To find the correct object for the Exchange Information Store Usage report, go to Monitoring and open the Information Store Performance Data view. The path for this view is Microsoft Exchange Server/Exchange 2003/Components/IS Performance Data. In the IS Performance Data view, the Target is always "Information Store" and the Path is always the name of a server that runs the IS service. If you check the box for any row in the legend, the performance data for that counter on that Information Store is displayed in the chart. If a line appears in the chart, the data is being collected.

If Target in the performance view is always Information Store, that means you have to select Information Store objects when you run the Exchange Information Store Usage report. Any other type besides Information Store will return a blank. To select an Information Store as the report target, open the report, click Add Object, type "Information Store" for the search string and click Search. A list of every Information Store will appear. The Path in the search results will be the server name that hosts the Information Store.

The same principles apply for most other reports. To troubleshoot the Exchange SMTP Usage report, go to Monitoring and open the SMTP Performance Data view under Microsoft Exchange Server/Exchange 2003/SMTP. You will see that Target is always "SMTP". To troubleshoot the "SQL Database space report" from the SQL Server 2005 MP, go to Monitoring and open the Database Free Space performance view under Microsoft SQL Server/Performance. You will see that Target is always a database name. And remember that the Target in the legend will be the search string and the target that you must use when configuring the report parameters.

Michael Sadoff | Support Escalation Engineer