When /Reports isn’t /Reports
Hold on tight, this one gets a little confusing.
Say you have a SharePoint 2007 farm with SQL Server Reporting Services (SSRS) integrated with it. Your reports site in SharePoint is http://this.that.com/Reports. You create a new 2010 farm and migrate your 2007 content to it. For the 2010 farm you install SQL Reporting Services 2008r2 taking mostly the defaults for a SharePoint integrated report server and then you load up the http://this.that.com/Reports site to test the new SQL reporting install. Instead of seeing the SharePoint web you expect, you see this:
So what happened? To understand the cause of the problem you have to understand one key difference between SSRS 2008r2 and SSRS 2005. The 2005 version of SQL Reporting uses IIS to serve out information over http and https. SSRS 2008r2 (and just SQL 2008 for that matter) has its own web server component.
Typically on a SQL Reporting 2005 setup the /Reports directory for SSRS will end up in the “Default” IIS web application, the one that exists as soon as you install IIS and has the *:80 host header binding. What this means is, any request on port 80 will go to the Default web application unless there is a specific host name requested that is bound to a different web application.
Let’s look at an example. You have a machine with the name SPWF1 and an additional fully qualified domain name (FQDN) this.that.com assigned to it in DNS. With SSRS 2005 IIS is the only web server on the system. If 2 web applications are located on port 80, one the default with the *:80 host header binding, and the other a SharePoint web application with the this.that.com:80 host header binding, any http request (on port 80) that comes to IIS will have to pass one test before it gets connected to a web application. Is the request for http://this.that.com (the name bound to the SharePoint web application) or something else , the machine name or the machine ip address for example? On such a machine you could have a SharePoint web at http://this.that.com/Reports and a SQL reporting URL at http://SPWF1/Reports and IIS would automatically sort them out. Http://this.that.com/Reports would go to the SharePoint web application, any other request would go to the default web application.
That same server with SSRS 2008r2 would actually have 2 web servers, SQL Reporting Service’s own web server and IIS. The difference is, the web server built into SSRS doesn’t check the host header bindings in IIS. By default when you set up SSRS it will create http://<servername or FQDN> /Reports and /Reportserver URLs on port 80 with a *:80 binding. These URLs can be renamed ( /SSRS and /SSRSServer for example). SQL Reporting’s web server will completely ignore any requests that it doesn’t have a direct match for, so it shows no sign of itself if you browse to http://SPWF1 or http://this.that.com but if it has a direct match such as http://SPWF1/Reports or http://this.that.com/Reports it will grab the request before IIS gets to it. What this means for you is either you have to do one of two things. Make that SharePoint doesn’t have any URLs that would match the Report Server URLs, either by changing the default name of /Reports and /Reportserver, or by changing the host header binding in the SQL Server Reporting configuration tool from *:80 to something more specific, like the machine name or a totally different FQDN and make sure that all requests to the report server use that specific name. I told you it was a little confusing 🙂 . Leave any questions in the comments and I will try to answer them to the best of my ability.