Fix Blank Reports in Operations Manager: A Troubleshooting Guide

Table of Contents

Blank reports are a frequent challenge encountered by administrators working with System Center Operations Manager. This issue can stem from a variety of underlying causes, making systematic troubleshooting essential. Understanding the common points of failure in the data collection and reporting pipeline is the key to resolving these problems efficiently.

This guide will delve into several of the most prevalent reasons why Operations Manager reports might appear blank. While other issues can lead to this symptom, addressing these common scenarios covers a significant portion of potential problems. Focusing on these specific areas provides a solid framework for diagnosis and resolution, helping you restore full reporting functionality within your SCOM environment.

We will discuss the following frequent causes for blank reports:
* Selecting the wrong type of entity as the report target.
* The performance collection rule or script responsible for generating data is not enabled for the target entity.
* Functional issues with the Health Service running on the monitored agent.
* Problems preventing management servers from inserting data into the OperationsManagerDW database.
* Data becoming stuck within the staging tables of the OperationsManagerDW database.

While this article covers the most common scenarios, complex or unique issues might require further investigation. For persistent problems not resolved by these steps, consulting additional resources or seeking expert assistance may be necessary. These five areas, however, represent a strong starting point for tackling the majority of blank report issues.

The Wrong Type of Entity Was Selected as the Report Target¶

Performance reports are often the most likely type to appear blank when a misconfiguration occurs, and the troubleshooting steps for them are generally applicable to other report types as well. The initial and crucial step in diagnosing such reports is to accurately identify the specific entity type and performance counter that the report is designed to display data for. This information is readily available within the Operations Manager console, specifically in the Monitoring pane. By navigating to the corresponding performance view, you can examine the legend which clearly lists the target entity name, the performance counter being collected, and the name of the performance collection rule gathering this data.

Consider troubleshooting the Exchange Information Store Usage report from an older Exchange management pack as an example. You would navigate to Monitoring and open the IS Performance Data view, typically found under a path like Microsoft Exchange Server/Exchange 2003/Components. The legend in this view is your guide; it shows that the target is always the Information Store object, and the path indicates the server hosting that service. If you select a counter in the legend and a data line appears in the chart, it confirms that data for that specific counter and Information Store entity is being collected successfully.

Based on this example, it’s clear that the Exchange Information Store Usage report is designed to display data only for Information Store entities. Selecting any other type of entity, such as an Exchange 2003 role object or a server object directly, will result in a report with no data, appearing completely blank. To correctly configure the report, you must choose Add Object, search specifically for “Information Store,” and then select the desired Information Store instances from the search results, using the path to identify the host server. This principle applies broadly across various reports: identify the correct target entity type as shown in the corresponding performance view’s legend and select only instances of that type when configuring the report parameters.

For instance, to troubleshoot the Exchange SMTP Usage report, you would check the SMTP Performance Data view under the Exchange management pack path, identifying SMTP as the required target entity type. Similarly, for the SQL Server Database space report from a SQL Server management pack, examining the Database Free Space performance view under SQL Server/Performance would show the database name as the target. Always remember that the Target name listed in the performance view legend is the specific entity type you need to search for and select when setting up the report parameters to ensure relevant data is included. Using this method helps prevent the fundamental error of requesting data for an entity type that the report’s underlying rules and counters are not configured to monitor.

The Performance Collection Rule or the Script That Generates the Performance Data Is Not Enabled for the Report Target¶

If you’ve confirmed that you are selecting the correct entity type for your report but the report remains blank, the next logical step is to investigate the data collection itself. You should revisit the relevant performance view within the Monitoring pane to see if data is being collected for the specific entity you are interested in. Two primary symptoms in the performance view can indicate a data collection problem: either the expected entity instance does not appear in the legend at all, or the entity is listed, but no data line is displayed in the chart when you select it. Both scenarios point towards a failure in the process of gathering performance data for that specific object.

If the expected entity is entirely missing from the performance view legend, it suggests that the entity itself might not have been discovered by Operations Manager. Discovery rules are responsible for identifying instances of specific application components or roles running on monitored agents. For example, if you expect to see an Information Store or a SQL Server Database Engine instance but it’s absent from the list, verify its discovery status. You can do this by creating a new state view in My Workspace scoped to that particular entity type; if the entity doesn’t appear in the state view either, the problem is one of discovery, not reporting, and should be troubleshooted as such by examining discovery rules and agent health.

Alternatively, a missing entity in the performance view legend or an entity with no data displayed could indicate that the performance collection rule for that specific counter is not enabled for the targeted entity. Some management packs, particularly older ones, come with performance collection rules that are disabled by default and must be explicitly enabled using overrides. The management pack guide for the application you are monitoring is an invaluable resource here, as it often details which rules are disabled by default and provides instructions on how to enable them. For instance, the Exchange 2003 management pack requires manual overrides to enable message tracking performance collection rules, without which reports like SMTP Out and SMTP In will lack data. Always consult the relevant management pack guide for necessary configuration steps and default rule states.

If the management pack guide doesn’t provide the answer, you need to manually check the performance collection rule in the Authoring pane of the console. Find the rule responsible for the performance counter identified in the performance view legend using the search tool in Authoring, making sure to scope your search correctly. Once you find the rule, check its properties to verify if it is enabled and if any overrides are affecting its target or status. For example, investigating inconsistent data for the Exchange Disk Usage report might lead you to the Average Disk Queue Length (All Disks) rule, where you could find it’s disabled by default or has overrides limiting its application to only a subset of servers, explaining why some Exchange servers are missing data in the related performance view and report. Adjusting the rule configuration or overrides to include all desired target entities is crucial for ensuring comprehensive data collection.

There Is a Functional Problem with the Health Service on the Agent¶

Sometimes, even if the expected entity is present in the performance view legend, you might still observe that no data is displayed when you select its corresponding check box. This specific symptom often points towards an issue with the Health Service component running on the monitored agent itself. The Health Service is responsible for executing workflows, including data collection rules and scripts, and transmitting collected data back to the management server. If the Health Service is not functioning correctly, it simply won’t be able to gather or send the necessary performance data, resulting in gaps or complete absence of data in performance views and reports.

Problems with the agent’s Health Service can manifest in various ways, such as the service not running, connectivity issues preventing the agent from communicating with its assigned management server, or the service experiencing internal errors. To start troubleshooting, verify that the System Center Management service (the Health Service) is running on the affected agent server. If it’s stopped, attempt to start it and check if data collection resumes. Increasing the time range in the performance view can also be helpful; looking at data over the past few days might reveal if collection suddenly stopped at a specific point in time, which could correlate with an event on the agent.

Crucially, you should examine the Operations Manager event log on the agent server experiencing the issue. Look for error or warning events logged by the HealthService source or Health Service Modules source. Specific events to watch for include those indicating that performance counters are missing or corrupt on the agent machine, as collection rules rely on these counters. Additionally, pay close attention to Health Service script events, such as 6026 or 6024. These events signal that the Health Service exceeded resource thresholds (like private bytes or handle count) and was automatically restarted, which can cause temporary interruptions in data collection and result in data gaps in views and reports. Resolving the underlying cause of these Health Service restarts (e.g., excessive workflows, memory leaks) is necessary to ensure consistent data collection.

Troubleshooting agent health involves reviewing not just the Operations Manager log but potentially the System and Application logs for related issues. Network connectivity between the agent and its management server should also be verified, ensuring firewalls are not blocking communication ports. Ensuring the agent is healthy and communicating properly is a prerequisite for reliable data collection and accurate reporting. If the agent is experiencing high CPU or memory usage, it might struggle to run collection workflows efficiently, also leading to data gaps.

Management Servers Are Unable to Insert Data into the OperationsManagerDW Database¶

Even if agents are successfully collecting performance data and sending it to their management servers, reports can still be blank if the management servers are unable to write this data into the OperationsManagerDW (Data Warehouse) database. This scenario can lead to inconsistent reporting, where data might appear for agents reporting to one management server but not for agents reporting to another, or data might be sporadically missing across the board. The Data Warehouse is the repository specifically used for long-term storage and reporting data, so issues here directly impact report availability.

The primary place to look for indications of Data Warehouse insertion problems is the Operations Manager event log on the management servers. One common and significant symptom is the occurrence of HealthService event ID 2115. This event is logged when a management server collects data (operational or reporting) but fails to insert it into the respective database. If the event description includes a workflow ID containing “DataWarehouse”, it specifically pertains to reporting data destined for the OperationsManagerDW. Troubleshooting this type of 2115 event should focus on database connectivity, performance, or permission issues between the management server and the Data Warehouse SQL Server. A specific cause for this error in older SCOM versions related to SQL Server configuration is well-documented and worth investigating if you encounter this event.

If you don’t immediately see 2115 events, configure a filtered view on the management server’s Operations Manager event log. Filter for warning and error events originating from the Health Service Modules source with the Data Warehouse category. These events are logged whenever any workflow related to the Data Warehouse fails on that specific management server. The details within the event description are crucial, as they often include the exact SQL Server error message returned during the failed insertion attempt, along with the name of the failing workflow. This information can pinpoint the nature of the database issue (e.g., login failed, table locked, disk full). The workflow name can also provide context; for example, a failure in the Microsoft.SystemCenter.DataWarehouse.CollectPerformanceData workflow directly impacts the collection and insertion of performance data used in reports.

Investigating Data Warehouse insertion failures involves collaborating with the SQL Server administrator if you are not one yourself. They can check SQL Server logs, monitor performance counters on the SQL server (CPU, memory, disk I/O), and verify database status, connectivity, and permissions. Ensuring network stability and resolving any SQL-related errors identified in the event logs are critical steps to restore the management server’s ability to write data to the Data Warehouse, thereby enabling reports to populate correctly.

Data Is Stuck in the Staging Tables in the OperationsManagerDW Database¶

Even if management servers can successfully connect to the OperationsManagerDW database and insert data, that data initially lands in temporary or “staging” tables. A separate set of processes, managed by specific Data Warehouse workflows (rules), is responsible for moving this raw data from the staging tables, aggregating it (e.g., into hourly or daily summaries), optimizing it, and grooming (deleting) old data according to retention policies. If these maintenance workflows fail or fall behind, data will accumulate in the staging tables and never make it to the aggregated tables used by most reports, resulting in blank or incomplete reports, especially for longer time ranges or aggregated views.

A key indicator that data might be stuck in staging is event ID 31552 logged in the Operations Manager event log on the management server, specifically if the event description lists the workflow name Microsoft.SystemCenter.DataWarehouse.StandardDataSetMaintenance. This rule, often referred to as the StandardDataSetMaintenance rule, is the primary engine for processing data within the Data Warehouse after it’s initially staged. It triggers stored procedures within the OperationsManagerDW database (with names starting like StandardDataset...) to handle staging processing, aggregation, optimization, and grooming for various data sets. Failures reported by this workflow can lead to data backlogs. The StandardDataSetMaintenance rule is designed to run frequently, typically every 60 seconds by default, to keep the data pipeline flowing. If you see related error events like 31553, it suggests a problem with processing a specific data set.

To directly check for performance data stuck in the staging tables, you can execute a simple SQL query against the OperationsManagerDW database. The Perf.PerformanceStage table holds raw performance data before aggregation. Running the following query and examining the DateTime column will show you the timestamps of the oldest records awaiting processing:

Use OperationsManagerDW
Select
   DateTime
From
   Perf.PerformanceStage
Order By
   DateTime

If this query returns records dating back more than a day or two, it’s a strong indication that data processing is not keeping up, and data is stuck in staging. For a more detailed view of the Data Warehouse maintenance status across different data sets, including performance data, you can use the following query:

Use OperationsManagerDW;
With AggregationInfo As
(
   Select
      AggregationType =
      Case
         When
            AggregationTypeId = 0
         Then
            'Raw'
         When
            AggregationTypeId = 20
         Then
            'Hourly'\
         When
            AggregationTypeId = 30
         Then
            'Daily'\
         Else
            NULL
      End
   ,AggregationTypeId, MIN(AggregationDateTime) As 'TimeUTC_NextToAggregate'\
   ,SUM(Cast (DirtyInd As Int)) As 'Count_OutstandingAggregations', DatasetId
   From
      StandardDatasetAggregationHistory
   Where
      LastAggregationDurationSeconds Is Not NULL
   Group By
      DatasetId, AggregationTypeId
)
   Select
      SDS.SchemaName,\
      AI.AggregationType,\
      AI.TimeUTC_NextToAggregate,\
      Count_OutstandingAggregations,\
      SDA.MaxDataAgeDays,\
      SDA.LastGroomingDateTime,\
      SDS.DebugLevel,\
      AI.DataSetId
   From
      StandardDataSet As SDS WITH(NOLOCK)\
      Join
         AggregationInfo As AI WITH(NOLOCK)\
         On SDS.DatasetId = AI.DatasetId\
      Join
         dbo.StandardDatasetAggregation As SDA WITH(NOLOCK)\
         On SDA.DatasetId = SDS.DatasetId\
         And SDA.AggregationTypeID = AI.AggregationTypeID
   Order By
      SchemaName Desc

This comprehensive query provides insights into each Data Set (like ‘Perf’ for performance, ‘State’ for state changes), its aggregation types (Raw, Hourly, Daily), the timestamp of the next data point to be aggregated (TimeUTC_NextToAggregate), and critically, the Count_OutstandingAggregations. A high value for Count_OutstandingAggregations (significantly more than 1-3) indicates that the aggregation process is falling behind for that specific data set and aggregation level. The query also shows retention policies (MaxDataAgeDays), last grooming times, and debug levels. Note that for data sets without aggregation (like Alerts or Events), they won’t appear in this list.

To specifically check the status of performance data processing, you can refine the query focusing on the ‘Perf’ schema:

Use OperationsManagerDW
Select
   AggregationDateTime,
   LastAggregationDurationSeconds
From
   StandardDatasetAggregationHistory AS AH
   Inner Join
      StandardDataSet As DS
      On AH.DatasetId = DS.DatasetId
Where
   DS.SchemaName = 'Perf'
Order By
   AggregationDateTime Desc

If the AggregationDateTime values are not recent, it confirms that the performance aggregation is not running or completing. High values in LastAggregationDurationSeconds suggest that the aggregation is running but taking an excessively long time, often due to SQL Server performance bottlenecks. These types of issues frequently point to problems with the SQL Server hosting the Data Warehouse, such as insufficient resources, poor disk performance, or database configuration problems. Reviewing SQL Server error logs and conducting a performance analysis of the SQL instance are essential steps here.

Another specific issue is indicated by DirtyInd entries in the StandardDataSetAggregationHistory table. A DirtyInd value of 1 means there is unprocessed data for that data set and aggregation type, but the aggregation procedure might not be processing all of it efficiently in each run. While aggregation might technically be occurring, it can’t keep pace with the incoming data volume if the procedure processes a limited number of rows per run (e.g., 100,000 rows for performance data by default). This can lead to a persistent backlog and ultimately incomplete reports. You can check for pending DirtyInd entries for the performance data set using this query:

Declare @DataSet as uniqueidentifier
Set
   @DataSet =\
   (\
      Select
         DataSetId
      From
         StandardDataSet
      Where
         SchemaName = 'Perf'
   )\
   Select
      *\
   From
      StandardDataSetAggregationHistory
   Where
      DataSetId = @DataSet\
      And DirtyInd = 1

If this query returns more than a handful (e.g., more than 4-5) of records, it indicates a backlog of unprocessed data. In such cases, manually running the maintenance procedure can help clear the backlog. Important: Before manually running maintenance or implementing the steps below, you must disable the default StandardDataSetMaintenance rule in the Operations Manager console to prevent it from interfering with your manual process. Go to Authoring, select Rules, change the scope to Standard Data Set, find the StandardDataSetMaintenance rule, and create an override to disable it specifically for the ‘Perf’ data set (or the data set you are troubleshooting). Wait for event 1210 on the management server to confirm the new configuration is applied before proceeding.

To manually run the StandardDataSetMaintenance stored procedure for a specific data set (like ‘Perf’), execute the following query against the OperationsManagerDW database:

Declare @DataSet uniqueidentifier
Set
   @DataSet =\
   (\
      Select
         DataSetId
      From
         StandardDataset
      Where
         SchemaName = 'Perf'
   )\
   Exec StandardDataSetMaintenance @DataSet

Run this query repeatedly until the DirtyInd query above returns only 1-3 entries, which is the normal state (one for each aggregation type). If you have a very large backlog (e.g., hundreds of DirtyInd entries or millions of rows in Perf.PerformanceStage), running the procedure manually might take a long time. For significant backlogs, you can use a loop to run the maintenance procedure multiple times with a short delay, giving the database time to process each batch. The following script runs the procedure 500 times with a 5-second delay between each execution:

Declare @i int
Set
   @i = 0
   Declare @DataSet uniqueidentifier
   Set
      @DataSet =\
      (\
         Select
            DataSetId
         From
            StandardDataset
         Where
            SchemaName = 'Perf'
      )\
      While(@i <= 500)\
      Begin
         Exec StandardDataSetMaintenance @DataSet
         Set
            @i = @i + 1 Waitfor Delay '00:00:05'
      End

Monitor the DirtyInd query result while this loop runs to see the backlog decrease. Once the backlog is cleared, remember to re-enable the StandardDataSetMaintenance rule override in the Operations Manager console that you previously disabled. Clearing the staging tables and ensuring data processing is up-to-date is often the solution when data collection appears functional but reports are blank for past time ranges.

Resolving blank reports in Operations Manager requires a systematic approach, starting from the report configuration and tracing the data flow back through collection rules, agent health, management server processes, and finally, Data Warehouse processing. By following these steps and examining the relevant event logs and database states, you can diagnose and fix most common causes.

Have you encountered blank reports in your SCOM environment? What troubleshooting steps did you find most effective? Share your experiences and tips in the comments below!