Install Reporting Services and Internet Information Services Side-by-Side (SSRS Native Mode)
Applies To: SQL Server 2016 Preview
You can install and run SQL Server 2016 Reporting Services (SSRS) and Internet Information Services (IIS) on the same computer. The version of IIS that you are using determines the interoperability issues you must address.
Applies to: Reporting Services Native mode
IIS 6.0, 7.0, 8.0, 8.5
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.
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 2016 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 2016 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 2016 Reporting Services (SSRS) as a named instance, include the instance name when creating a virtual directory.