See all of the top support solutions for our most common issues here
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.
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.
- 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 on Facebook and Twitter:
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/
In step 3 you say re-install Reporting Services. Do you mean the Reporting Services point role in SCCM or the actual instance of Reporting Services on the SQL server?
Craig, in step 3, please re-install Reporting Services point role in SCCM
We have the scenario where no reports show in the Console, however the reports show when accessing the SSRS web ast port 80. Could this be the build of SQL? The installation is as follows:
No CAS, SCCM 2012 SP1 Primary Server A configured to point to Reporting Services Role installed on Server B
Database for SSRS installed on C.
I read some anecdotal info that it might be SQL version, but where should I check the SQL version - A? B? Both?
Hi Anonymous, as per scenario mentioned by you, it looks like you need to check permissions for your account using which SCCM console is opened.
If you are able to see reports using Web manager/ Report manager URL, then they should reflect in the console.
But since SCCM 2012 has RBAC in it, hence this might be the reason why you are not able to see reports.
Please see in SCCM console your level of access, try and make yourself a full administrator and then check.
Regarding the sql version, there have been cases wher db engine is on a different version as compared to reporting engine and that has created issues, but this would not be the case here.