Deploying Reporting Services and Internet Information Services Side-by-Side
You can install and run SQL Server 2008 R2 Reporting Services and Internet Information Services (IIS) on the same computer. The version of IIS that you are using determines the interoperability issues you must address.
IIS 6.0 and 7.0
Requests intended for one application are accepted by a different application.
HTTP.SYS enforces precedence rules for URL reservations. Requests that are sent to applications that have the same virtual directory name and that jointly monitor port 80 might not reach the intended target if the URL reservation is weak relative to the URL reservation of another application.
Under certain conditions, a registered endpoint that supersedes another URL endpoint in the URL reservation scheme might receive HTTP requests intended for the other application.
Using unique virtual directory names for the Report Server Web service and Report Manager helps you avoid this conflict.
Detailed information about this scenario is provided in this topic.
By default, IIS 5.1 reserves port 80 for its exclusive use. If you install SQL Server 2008 R2 Reporting Services on 32-bit Windows XP (SP2), the default port for the Reporting Services URLs will be port 8080:
On the 64-bit platform, the default port for Reporting Services URLs is port 80. IIS 5.1 uses HTTP.SYS in the 64-bit version of Windows XP SP2, allowing port 80 to be shared by both applications.
Before you can address interoperability issues between IIS and Reporting Services, you must understand URL reservation precedence rules. Precedence rules can be generalized into the following statement: a URL reservation that has more explicitly defined values is first in line to receive requests that match the URL.
A URL reservation that specifies a virtual directory is more explicit than one that omits a virtual directory.
A URL reservation that specifies a single address (by way of an IP address, a fully qualified domain name, a network computer name, or a host name) is more explicit than a wildcard.
A URL reservation that specifies a strong wildcard is more explicit than a weak wildcard.
The following examples show a range of URL reservations, ordered from most explicit to least explicit:
Receives all requests that are sent to http://123.234.345.456/reports or http://<computername>/reports if a domain name service can resolve the IP address to that host name.
Receives any requests that are sent to any IP address or host name that is valid for that computer as long as the URL contains the "reports" virtual directory name.
Receives any request that specifies http://123.234.345.456 or http://<computername> if a domain name service can resolve the IP address to that host name.
Receives requests that are not already received by other applications, for any application endpoints that are mapped to All Assigned.
Receives requests that are not already received by other applications, for application endpoints that are mapped to All Unassigned.
One indication of a port conflict is that you will see the following error message: 'System.IO.FileLoadException: The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020).'
Given the precedence rules outlined in the previous section, you can begin to understand how URL reservations defined for Reporting Services and IIS promote interoperability. Reporting Services receives requests that explicitly specify the virtual directory names for its applications; IIS receives all remaining requests, which can then be directed to applications that run within the IIS process model.
Strong wildcard on port 80, with report server virtual directory.
Receives all requests on port 80 that specify the report server virtual directory. The Report Server Web service receives all requests to http://<computername>/reportserver.
Strong wildcard on port 80, with Reports virtual directory.
Receives all requests on port 80 that specify the reports virtual directory. Report Manager receives all requests to http://<computername>/reports.
Weak wildcard on port 80.
Receives any remaining requests on port 80 that are not received by another application.
Interoperability issues between IIS and Reporting Services occur when IIS Web sites have virtual directory names that are identical to those used by Reporting Services. For example, suppose you have the following configuration:
A Web site in IIS that is assigned to port 80 and a virtual directory named "Reports".
A SQL Server 2008 R2 report server instance installed in the default configuration, where the URL reservation also specifies port 80 and the Report Manager application also uses "Reports" for the virtual directory name.
Given this configuration, a request that is sent to http://<computername>:80/reports will be received by Report Manager. The application that is accessed through the Reports virtual directory in IIS will no longer receive requests after SQL Server 2008 R2 report server instance is installed.
If you are running side-by-side deployments of older and newer versions of Reporting Services, you are likely to encounter the routing problem just described. This is because all versions of Reporting Services use "ReportServer" and "Reports" as virtual directory names for the report server and Report Manager applications, increasing the likelihood that you will have a "reports" and "reportserver" virtual directories in IIS.
To ensure that all applications receive requests, follow these guidelines:
For Reporting Services installations, use virtual directory names that are not already used by an IIS Web site on the same port as Reporting Services. If there is a conflict, install Reporting Services in "files-only" mode (using the Install but do not configure the server option in the Installation Wizard) so that you can configure the virtual directories after Setup is finished. One indication that your configuration has a conflict is you will see the error message: System.IO.FileLoadException: The process cannot access the file because it is being used by another process. (Exception from HRESULT: 0x80070020).
For installations that you configure manually, adopt the default naming conventions in the URLs that configure. If you install SQL Server 2008 R2 Reporting Services as a named instance, include the instance name when creating a virtual directory.
Windows XP SP2 provides the HTTP.SYS component that is required by Reporting Services. However, even though HTTP.SYS is available on the operating system, IIS 5.1 does not use it. Instead, IIS 5.1 accepts all requests on port 80 or on whatever port it is configured to use. Because there is no URL reservation for IIS 5.1 in HTTP.SYS, there is no central management of the request queue that allows the Reporting Services Web applications to receive requests on the same port.
For this reason, the default configuration for a report server that is installed on 32-bit Windows XP SP2 is to use port 8080 for the Report Server Web service and Report manager. The following table shows the URL reservations for the Web service and Report Manager:
Using a non-default port on the URL reservation for Reporting Services applications means that there is no URL conflict for side-by-side scenarios with older versions of Reporting Services.
If you have an older and newer report server instances installed on the same computer, the default URLs will be http://<servername>/<reportserver> for the Reporting Services 2005 report server that is accessed through IIS, and http://<servername>:8080/<reportserver> for the SQL Server 2008 R2 Reporting Services report server.