Troubleshoot MOM Reporting

  • Article

This section provides troubleshooting solutions for issues you might encounter while working with MOM Reporting.

How Do I Troubleshoot SQL Reporting Services?

Before troubleshooting specific errors or failures in SQL Reporting Services, it is helpful to prepare by taking the following steps:

  1. Define the problem.

  2. Gather necessary information.

Solution

To define the problem

  1. If possible, capture a screenshot of the error.

  2. Note the error number and/or error message text.

  3. Note whether the error is constant or intermittent.

  4. For installation errors, note how many times the installation failed.

To gather information needed for troubleshooting

  1. Collect all setup logs. These logs are located in the %Temp% directory and are named RSMSI**#.LOG and RSSTP#**.LOG, where # is a number that increases incrementally every time setup is launched.

  2. Determine installation source, by noting whether setup was launched locally or through Terminal Services.

  3. Determine what account was used to initiate the installation. Note group memberships of the account.

  4. Determine what options were selected during the installation of SQL Reporting Services.

  5. Determine the destination drive and directory chosen during installation.

  6. Determine the user accounts identified during installation to run the Reporting Services NT Service.

  7. Determine the user account specified for SQL connectivity. Note the permissions, rights, and group memberships assigned to that account.

Error: PreReqProp_Rosetta_Fix_CA_ERROR_WEB_SERVICE_FAILURE

This error can occur during the MOM Reporting Server installation. MOM reporting is dependent on SQL Server Reporting Services. The MOM Reporting Server installation program attempts to connect to the Web server on the SQL Server Reporting Services Server. If this connection is unsuccessful, the installation of MOM Reporting stops and this error message occurs.

Solution

Check Internet Information Services (IIS) Manager on the SQL Server Reporting Services Server to see whether it is installed and running. Also, if you have checked require client certificates on this Web server, verify that a valid client certificate is installed on the MOM Reporting Server.

MOM Reporting Installation Fails When Using SSL

MOM 2005 Reporting installation fails if you enable Secure Sockets Layer (SSL) on the IIS Default Web Site after SQL Server Reporting Services is installed. This also keeps SQL Server Reporting Services from functioning properly. SSL should be enabled through the Directory Security tab on the IIS Default Web Site Properties page before SQL Server Reporting Services is installed. However, if SSL was not enabled before installation, you can apply the following solution.

Solution

Use the following procedure to enable SSL after SQL Reporting Services is installed. This can correct the MOM 2005 Reporting installation failure.

To enable SSL after SQL Reporting Services installation

  1. On the MOM 2005 Reporting Server, navigate to %SYSTEMDRIVE%\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer.

  2. Open the file RSReportServer.Config for editing.

  3. Change the value for the SecureConnnectionLevel setting to 0. Save the change and close the file.

  4. Uninstall MOM 2005 Reporting.

  5. Reinstall MOM 2005 Reporting.

  6. Open the file RSReportServer.Config file that was previously edited.

  7. Change the value for the SecureConnectionLevel setting to 3. Save the change and close the file.

  8. Open SQL Server Enterprise Manager and navigate to the OnePoint database. In the navigation pane, click Tables.

  9. In the details pane, locate the ReportSettings table.

  10. In the table, change all occurrences of "http://" to "https://" in the URLs.

  11. On the MOM Reporting Server, stop and then start the ReportServer service.

Cannot Detect MOM Reporting Server

The MOM Reporting Server may not appear in the MOM 2005 Report Servers computer group. This occurs if the MOM Reporting database and the MOM Reporting Server are installed on separate computers. MOM 2005 creates the MOM 2005 Report Servers computer group during the installation of MOM 2005 Reporting. MOM 2005 discovers reporting servers and adds them to this group. However, if MOM 2005 Reporting Server and the Reporting database are installed on separate computers, the Reporting Server is not automatically added to the MOM 2005 Report Servers computer group.

Solution

To resolve this, manually add the Reporting Server to the MOM 2005 Report Servers computer group.

DTS Job Is Too Slow or Times Out

The SQL Reporting Server hosts a data warehouse based on SQL Server Reporting services. Data from the MOM database is periodically copied to the data warehouse by a Data Transformation Services (DTS) job. When the network is congested or the DTS job is too large for the network to handle, the DTS job can encounter slowdowns or can time out before completing. If this is the case, the problem may be fixed by increasing the time-out value or dividing the DTS package into multiple packages.

Solution

Run the DTS job again to see if the results are the same. The remote query time-out can also be increased from the default value of 600 seconds, or if needed, it can be set to 0 (unlimited). An alternative is to break the DTS package into smaller chunks and use the /latency parameter to run DTS multiple times.

Alerts Not Appearing in Reports

Alerts that are newly updated might not appear in reports generated by MOM 2005. Before transferring records from the OnePoint database to the Reporting database, the record is checked for stability. Records that have recently updated might not yet have committed to all tables in the OnePoint database. If less than five minutes have elapsed since the record was added to or updated in the OnePoint database, it does not transfer to the Reporting database until the next cycle. If the record is continuously updating, it never transfers and subsequently does not appear in any report.

Solution

If an alert does not appear in a report, first verify that the alert was not recently updated. Also, check the design of the alert to make sure it does not behave in a way that results in continuous updates, such as sending an alert based on a condition and then immediately retrying the condition.