Support Tip: No reports show up in the console after installing a System Center 2012 Configuration Manager Reporting server

Hi everyone, Prabhat Joshi here. After installing and configuring a System Center 2012 Configuration Manager Reporting server, you may find that you are unable to find any reports in the Reporting workspace in the Operations console. When checking the srsrp.log file you may also see the following error:

STATMSG: ID=7403
Failures reported during periodic health check by the SRS Server

When browsing to the Report Manager URL (e.g. http://<SQLserverName>/Reports) you will receive the following error message:

HTTP Error 404.0 - Not Found
The resource you are looking for has been removed, had its name changed, or is temporarily unavailable.

This can occur if there is a port conflict on the server. In our case, there was a named SQL instance as well as the default instance that we were using (MSSQLSERVER) and both were configured to use port 80 on "All Available Networks".

If you find yourself in this situation, here’s one thing you can do to resolve the issue:

1. Change the Default Instance (MSSQLSERVER) configuration to use port 8080 in the Report Manager Configuration and restart the Report Manager Service.

2. Add TCP port 8080 to the Incoming Firewall rules.

3. Reinstall Reporting services.

Once you do this you should see all of your reports and Reporting services should function as expected.

Troubleshooting Additional Causes

This issue can occur due to multiple reasons so an understanding of entire process that involves integration of SQL reporting services with Configuration Manager can be helpful. Here are the steps I go through along with some additional troubleshooting tips:

1. Install SQL server reporting services.

2. Configure a DB.

3. Check the server. If none of the reports are deployed to the report server, browsing to a working report server URL should simply show the reporting services version (e.g. if it’s SSRS 2008 R2 RTM, the version displayed would be 10.50.1600.1)

4. If you get any errors while browsing the report server URL, it’s highly likely that the report manager URL would also fail. If this is the case, the first thing to do is to verify the SSRS settings from SSRS configuration manager, This would include verifying things such as the service account, ports used, connectivity to the SSRS database from SSRS configuration manager, URL reservation, etc.

To further dig into any issues, you can also check the reporting services log files for more information. The default location for these files is <drive>:/Program Files/Microsoft SQL Server/<Instance ID>/Reporting Services/LogFiles but the location may be different in your environment. A good log to check is ReportServerService_<timestamp>.log. It logs all errors and it will provide a complete call stack that should explain why we got an error message.

Additional Information

- Assuming that the report server and report manager URL are working, if a change is required with respect to SSRS (e.g. service account username or password or both) a recommended practice is to take a backup of the current report server and report server tempdb from SQL server as well as A backup of the encryption keys from SSRS configuration manager before making any changes.

- If you use the wizard from Configuration Manager to install your Reporting services point, you can check the progress by looking in sitecomp.log and checking for "rolesetup.exe SMSSRSRP".    Later in the process, you can check srsrpsetup.log and srsspMSI.log to see the install, and then as long as that competes OK, information is passed on to srsrp.log where can see the process of reports being copied over to the reporting database.

- In ConfigMgr 2007 , when you use the Copy Reports Wizard, a log file named ConversionReport.xml containing the results of the copy reports operation is generated in the folder \SMS\AdminUI\AdminUILog on the computer from which you launched the wizard.

Prabhat Joshi| Senior Escalation Engineer | Microsoft

Get the latest System Center news onFacebookandTwitter:

System Center All Up: http://blogs.technet.com/b/systemcenter/
System Center – Configuration Manager Support Team blog: http://blogs.technet.com/configurationmgr/
System Center – Data Protection Manager Team blog: http://blogs.technet.com/dpm/
System Center – Orchestrator Support Team blog: http://blogs.technet.com/b/orchestrator/
System Center – Operations Manager Team blog: http://blogs.technet.com/momteam/
System Center – Service Manager Team blog: http://blogs.technet.com/b/servicemanager
System Center – Virtual Machine Manager Team blog: http://blogs.technet.com/scvmm

Windows Intune: http://blogs.technet.com/b/windowsintune/
WSUS Support Team blog: http://blogs.technet.com/sus/
The AD RMS blog: http://blogs.technet.com/b/rmssupp/

The Forefront Endpoint Protection blog : http://blogs.technet.com/b/clientsecurity/
The Forefront Identity Manager blog : http://blogs.msdn.com/b/ms-identity-support/
The Forefront TMG blog: http://blogs.technet.com/b/isablog/
The Forefront UAG blog: http://blogs.technet.com/b/edgeaccessblog/