After an Installation of Reporting Services with the configuration complete, there is no guarantee you will be able to connect to Reporting Services straight away. So this article will discuss issues connecting to Report Server and Report Manager and give you some advice on how to resolve these issues.
The first sign of a connectivity issue is when a DBA first runs Report Manager from their browser. There are a whole host of errors which could return however; hopefully you will be able to resolve them with the help of this article.
Check the Report Server Web Service is working correctly
The Report Server Web Service is the heart of Reporting Services. There is a log file created for the Web Service however; it is only created if all the pieces required to get there are up and running, so first we need to check IIS.
I am going to provide a list of areas to check and it is worth ensuring you have read my previous blogs on IIS and IIS Security.
Event Log
Check out the System and Application event logs, many IIS and Application Pool failures are written there.
IIS Admin Service
Make sure the IIS Admin Service is running. You need this service in order to run web sites and configure IIS.
Report Server Application Pool
Using IIS Manager check the Application Pool whish is used by the Report Server is running. You can confirm the Application Pool used by Report Server by looking at the Properties of the ReportServer web site. It will be at the bottom of the Virtual Directory tab.
Once known click on the Application Pools link and verify the pool is running on the right hand pane.
Report Server Website
Using IIS Manager click on the Web Sites link and verify the Reporting Services web site is running on the right hand pane.
Connection URL
You need to understand what the Connection URL to the Report Server Web Service is. This is really important because an incorrect URL maybe the only issue.
From IIS Manager click on the Web Sites link and look at the right hand pane. There are various columns and the important ones are Host Header Value, IP Address, Port, and SSL Port. Depending on what values you have here will depend on the URL used to connect to the Report Server.
There may be multiple entries with different values and in order to see all of them you need to look at the Properties of the web site and click on the Advanced button next to IP Address.
The different columns are used as follows:
· IP Address: This gives you the range of IP Addresses that are allowed to be used when connecting to Report Server. If set to All Unassigned then it is listening on any IP address.
e.g http://nnn.nnn.nnn.nnn/ReportServer or use the hostname for that IP Address.
· Port: This is the Port number that the Web Site is listening on. By default HTTP listens on port 80 however; any value other than 80 needs to be specified in the URL string.
e.g http://server:880/ReportServer is using port number 880 instead of 80
· SSL Port: This column will only be populated if the web site is using the Secure Socket Layer. By default HTTPS listens on port 443 however; any value other than 443 needs to be specified in the URL string.
e.g https://server:555/ReportServer is using port number 555 instead of 443.
· Host Header Value: Rather than connect to the web site using the server name, you might want to connect using a completely different name. You see this all the time on the Internet with names such as www.microsoft.com. This DNS name will point to the server where the Report Server is running.
· e.g http://www.mydomain.com/ReportServer
Reporting Services Databases
Reporting Services stores all its information in a SQL Server database and we need to ensure SQL Server is running with no problems, so check the SQL Server Errorlog and Event log on that server. As long as the installation was successful all the access for the SQL accounts will have been done however; you will see logon failures in the Reporting Services log files.
Local Connectivity Test to Report Server
We are ready to test we can connect but before we do that I want to quickly review the pieces of the Reporting Services puzzle. When you connect to Report Manager it will send SOAP requests to the Report Server Web Service to retrieve the information to display. So straight away we can see that if Report Server Web Service is not working, nor will Report Manager. The Reporting Services Windows Service does not play any part at this stage.
Our first test needs to be done on the web server itself so logon to the web server where Reporting Services is installed and open Internet Explorer.
You now need to connect to the Report Server Web Service. The URL you use will depend on the information you discovered in the Connection URL section above so you may have to use HTTPS or add a port number. Another point to bare in mind is that when you connect to a Web Service it has to read the WSDL file which basically means the first connection takes a little while so hang in there. As long as your keep your browser open the subsequent connections will be quick.
Try the following connections
· Try connecting using localhost as the server name
· Try connecting using IP address 127.0.0.1
· Try connecting using the machine name
· Try connecting using the machines IP address
· Try connecting using the Fully Qualified Domain Name of the server
· Try connecting using a Host Header Name
Connection Fails
If any of the above tests fail you need to review the following. These are not all the same checks as above so please review them.
· If localhost fails and 127.0.0.1 works it means the localhost entry needs to be added to the HOSTS file in C:\WINDOWS\System32\Drivers\etc
· Check if the C:\WINDOWS\System32\Drivers\etc\HOSTS file does not have incorrect entries
· Using NSLOOKUP verify your DNS entries have the right IP Addresses for the server names and Host Header Values.
· Check the server has the correct domain name suffix added if you are not specifying it.
· Make sure that the URL you specify only hits one web site. For example one web site could be listening on localhost and port 80 and the other may be listening on any IP address and port 80. A quick way to check this is to Stop the other website and try again.
· Hopefully if the Application Pool has communicated with the Report Server there may be a Report Server log file to view since this file is only created when a connection is first established. If you installed using the default installation path which is a recommended thing to do because articles like mine make reference to them, your log files will be created in folder C:\Program Files\Microsoft SQL Server\MSSQL.1\Reporting Services\LogFiles. The file will be called ReportServer_<timestamp>.log and by default a new file is created every day at midnight and will be kept for 14 days.
Take a look at this file and see if you can spot any errors. They are usually easy to spot because they always appear after a timestamp with the prefix of ERROR:
· Another issue may be Security related and rather than repeat myself please refer to my previous blog on IIS Security which explains how Reporting Services is configured from an IIS perspective.
· If you are connecting using SSL then make sure you are not getting any Security Alert messages indicating there is an issue with a certificate. Any issues will need to be resolved with your local web team.
Hopefully if you reach here then you have successfully connected to the Report Server.
Remote Connectivity Test to Report Server
Unless the Local Connectivity test is successful the Remote Connectivity test will not succeed.
So what we want to do now is perform a Remote Connectivity test on either your workstation or laptop or from another server. We can repeat all the tests except the localhost or 127.0.0.1 tests since these always refer to the machine where Internet Explorer is running.
Try the following connections
· Try connecting using the machine name
· Try connecting using the machines IP address
· Try connecting using the Fully Qualified Domain Name of the server
· Try connecting using a Host Header Name
Connection Fails
If any of the above tests fail you need to review the following:
· Check the C:\WINDOWS\System32\Drivers\etc\HOSTS file does not have incorrect entries
· Using NSLOOKUP verify your DNS entries have the right IP Addresses for the server names and Host Header Values.
· Check the server has the correct domain name suffix added if you are not specifying it.
· Make sure that the URL you specify only hits one web site. For example one web site could be listening on localhost and port 80 and the other may be listening on any IP address and port 80. A quick way to check this is to Stop the other website and try again.
· Hopefully if the Application Pool has communicated with the Report Server there may be a Report Server log file to view since this file is only created when a connection is first established. If you installed using the default installation path which is a recommended thing to do because articles like mine make reference to them, your log files will be created in folder C:\Program Files\Microsoft SQL Server\MSSQL.1\Reporting Services\LogFiles. The file will be called ReportServer_<timestamp>.log and by default a new file is created every day at midnight and will be kept for 14 days.
Take a look at this file and see if you can spot any errors. They are usually easy to spot because they always appear after a timestamp with the prefix of ERROR:
· We need to ensure there are no IP Address and Domain Name Restrictions. Using IIS Manager look at the properties of the Reporting Services web site and click on the Directory Security tab. Now click Edit next to the IP Address and Domain Name Restrictions. If there are any entries added then check to ensure your IP address is not one of them.
Connectivity Tests to Report Manager
If Report Server is working it is now time to test Report Manager. Exactly the same tests are required and exactly the same connectivity failure checks can be performed. The Report Manager has its own log files in the same folder as the Report Server log files in the format ReportServerWebApp_<timestamp>.log
Before you being the tests you need to be aware of how Report Manager determines how to connect to Report Manager.
Within the Report Manager Virtual Directory is a file called RSWebApplication.config. Within this file is a section starting at <UI> are two parameters we are interested in:
· <ReportServerUrl>
· <ReportServerVirtualDirectory>
These two values are mutually exclusive which means we can only supply a parameter to one of them at any one time.
If the Report Server and Report Manager share the same website on the same machine then all you need to do is supply the Virtual Directory name to the <ReportServerVirtualDirectory> parameter and leave <ReportServerUrl> empty.
E.G <ReportServerVirtualDirectory>ReportServer</ReportServerVirtualDirectory>
If the Report Server and Report Manager do not share the same website on the same machine then you need to supply a <ReportServerUrl> parameter and leave <ReportServerVirtualDirectory> empty. This would be the URL you use to successfully do a Remote connectivity test so it may include SSL or non default port numbers, etc.
E.G <ReportServerUrl>http://WebServer.Mydomain.com/ReportServer</ReportServerUrl>
A word of advice is to always specify a fully qualified domain name when not using Host Header Values. This will reduce the number of errors when doing non default installations.
Report Manager is an ASP.NET application which needs access to the Report Server Virtual Directories and follows the same security issues as any regular user. Refer to my previous blog on IIS Security for more information.
So this brings me to the end of this article so look out for more. I have quiet a few planned on SSL, Double Hop Authentication, Encryption, to name a few. Also any feedback or emails are welcome.