| title | description | author | ms.author | ms.date | ms.service | ms.subservice | ms.topic | ms.custom | helpviewer_keywords | |||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
Install Reporting and Internet Information Services side-by-side |
Install Reporting and Internet Information Services Side-by-Side |
kfollis |
kfollis |
09/25/2024 |
reporting-services |
report-server |
install-set-up-deploy |
|
|
[!INCLUDEssrs-appliesto] [!INCLUDEssrs-appliesto-2016-and-later] [!INCLUDEssrs-appliesto-pbirsi]
[!INCLUDE ssrs-previous-versions]
You can install and run SQL Server Reporting Services (SSRS) and Internet Information Services (IIS) on the same computer. The version of IIS that you're using determines the interoperability issues you must address.
| IIS version | Issues | Description |
|---|---|---|
| 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 the [!INCLUDEssRSWebPortal] helps you avoid this conflict. Detailed information about this scenario is provided in this article. |
Before you can address interoperability issues between IIS and [!INCLUDEssRSnoversion], 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:
| Example | Request |
|---|---|
https://123.234.345.456:80/reports |
Receives all requests that are sent to https://123.234.345.456/reports or https://<computername>/reports if a domain name service can resolve the IP address to that host name. |
https://+:80/reports |
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. |
https://123.234.345.456:80 |
Receives any request that specifies https://123.234.345.456 or https://<computername> if a domain name service can resolve the IP address to that host name. |
https://+:80 |
Receives requests that aren't already received by other applications, for any application endpoints that are mapped to All Assigned. |
https://*:80 |
Receives requests that aren't already received by other applications, for application endpoints that are mapped to All Unassigned. |
One indication of a port conflict is that you see the following error message: 'System.IO.FileLoadException: The process can't access the file because it's 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.
| Application | URL reservation | Description | Request receipt |
|---|---|---|---|
| Report Server | https://+:80/ReportServer |
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 https://<computername>/reportserver. |
| Web portal | https://+:80/Reports |
Strong wildcard on port 80, with Reports virtual directory. | Receives all requests on port 80 that specify the reports virtual directory. The [!INCLUDEssRSWebPortal] receives all requests to https://<computername>/reports. |
| IIS | https://*:80/ |
Weak wildcard on port 80. | Receives any remaining requests on port 80 that aren't received by another application. |
Interoperability issues between IIS and Reporting Services occur when IIS Web sites have virtual directory names that are identical to names 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 report server instance installed in the default configuration, where the URL reservation also specifies port 80 and the [!INCLUDEssRSWebPortal] application also uses "Reports" for the virtual directory name.
Given this configuration, a request that is sent to https://\<computername>:80/reports gets received by the [!INCLUDEssRSWebPortal]. The application that is accessed through the Reports virtual directory in IIS will no longer receive requests after the report server instance is installed.
If you run side-by-side deployments of older and newer versions of [!INCLUDEssRSnoversion], you're likely to encounter this routing problem. You see this problem because all versions of [!INCLUDEssRSnoversion] use "ReportServer" and "Reports" as virtual directory names for the report server and the [!INCLUDEssRSWebPortal] applications, increasing the likelihood that you 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 aren't already used by an IIS Web site on the same port as Reporting Services. If there's a conflict, install Reporting Services in "files-only" mode (using the Install but don't 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 see the error message: System.IO.FileLoadException: The process can't access the file because it's 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 [!INCLUDEssRSCurrent] as a named instance, include the instance name when creating a virtual directory.