About URL Reservations and Registration
URLs for Reporting Services applications are defined as URL reservations in HTTP.SYS. A URL reservation defines the syntax of a URL endpoint to a Web application. URL reservations are defined for both the Report Server Web service and Report Manager when you configure the applications on the report server. URL reservations are created for you automatically when configure URLs through Setup or the Reporting Services Configuration tool:
Setup will create URL reservations using default values. If Setup installs the default configuration, it will reserve two URLs; one of the Report Server Web service and another for Report Manager. You can use the Reporting Services Configuration tool to add more URLs or modify the default URLs that Setup creates.
The Reporting Services Configuration tool will create a URL reservation based on the URL you specify in the Web Service URL or Report Manager URL pages in the tool.
Both Setup and the tool will also assign permissions on the URL to the Report Server service, check for duplicate instances, and add the URL reservation to HTTP.SYS. Never create or modify a Reporting Services URL reservation directly using HttpCfg.exe or other tool. If you skip a step or set an invalid value, you will encounter problems that might be difficult to diagnose or fix.
Note
HTTP.SYS is an operating system component that listens for network requests and routes them to a request queue. In this release of Reporting Services, HTTP.SYS establishes and maintains the request queue for the Report Server Web service and Report Manager. Internet Information Services (IIS) is no longer used to host or access Reporting Services applications. For more information about HTTP.SYS functionality, see HTTP Server API on MSDN.
In This Topic
This topic introduces the URLs, URL reservations and registration, default values, and deployment-specific recommendations that you should follow if you create or modify URLs for different server configurations. The following sections are in this topic:
URLs in Reporting Services
URL Reservation and Registration
Default URLs
Authentication and Service Identity for Reporting Services URLs
URLs for Local Administration
URLs for Scale-out Deployment
URLs for SharePoint Integrated Mode
For more information about URL construction and usage in a Reporting Services installation or troubleshooting reservation or registration errors, see Configure Report Server URLs in SQL Server Books Online.
URLs in Reporting Services
In a Reporting Services installation, you can access the following tools, applications, and items through URLs:
Report Server Web service
Report Manager
Report Builder
Reports that have been published to a report server
Other published URL-addressable items, such as models and shared data sources, should not be accessed through URLs as stand-alone items. The report server does not display those items in a meaningful format when viewed in a browser window.
Note
This topic does not describe URL access to Report Builder or to specific reports that are stored on the report server. For more information about URL access to these items, see Access Report Server Items Using URL Access in SQL Server Books Online.
URL Reservation and Registration
A URL reservation defines the URLs that can be used to access a Reporting Services application. Reporting Services will reserve one or more URLs for the Report Server Web service and Report Manager in HTTP.SYS, and then register them when the service starts. URLs to Report Builder and reports are based on the Report Server Web service URL reservation. By appending parameters to the URL, you can open Report Builder or reports through the Web service. Reservations and registration is provided by HTTP.SYS. For more information, see Namespace Reservations, Registration, and Routing on MSDN.
URL reservation is a process by which a URL endpoint to a Web application is created and stored in HTTP.SYS. HTTP.SYS is the common repository of all URL reservations that are defined on a computer and defines a set of common rules that guarantee unique URL reservations.
URL registration occurs when the service starts. The request queue is created and HTTP.SYS begins routing requests to that queue. A URL endpoint must be registered before requests that are directed to that endpoint are added to the queue. When the Report Server service starts, it will register all URLs that it has reserved for all enabled applications. This means that the Web service must be enabled in order for registration to occur. If you set the WebServiceAndHTTPAccessEnabled property to False in the Surface Area Configuration for Reporting Services facet of Policy-Based Management, the URL for the Web service will not register when the service starts.
URLs are unregistered if you stop the service or recycle the Web service or Report Manager application domain. If you modify a URL reservation while the service is running, the report server will recycle the application domain immediately so that the old URL can be unregistered and the new one put into use.
A few simple examples illustrate the concept of a URL reservation and how it relates to URL addresses used for Reporting Services applications. A key point to notice is that the URL reservation has different syntax than the the URL you use to access the application:
URL Reservation in HTTP.SYS |
URL |
Explanation |
|---|---|---|
http://+:80/reportserver |
http://<computername>/reportserver http://<IPAddress>/reportserver https://localhost/reportserver |
The URL reservation specifies a wildcard (+) on port 80. This puts into the report server queue any incoming request that specifies a host that resolves to the report server computer on port 80. Notice that with this URL reservation, any number of URLs can be used to access the report server. This is the default URL reservation for a Reporting Services report server for most operating systems. |
http://123.45.67.0:80/reportserver |
http://123.45.67.0/reportserver |
This URL reservation specifies an IP address and is much more restrictive than the wildcard URL reservation. Only URLs that include the IP address can be used to connect to the report server. Given this URL reservation, a request to a report server at http://<computername>/reportserver or https://localhost/reportserver would fail. |
Default URLs
If you install Reporting Services in the default configuration, Setup will reserve URLs for the Report Server Web service and Report Manager. You can also accept these default values when you define URL reservations in the Reporting Services Configuration tool. Default URLs will include an instance name if you install SQL Server Express or if you install Reporting Services as a named instance.
Important
The instance character is an underscore character (_).
URL reservations include a port number. The following operating systems will allow multiple Web applications to share a port:, , , and.
Windows Server 2012
Windows Server 2008 R2
Windows Server 2008
Windows 7
Windows Vista
Instance Type |
Application |
Default URL |
Actual URL reservation in HTTP.SYS |
|---|---|---|---|
Default instance |
Report Server Web service |
http://<servername>/reportserver |
http://<servername>:80/reportserver |
Default instance |
Report Manager |
http://<servername>/reportserver |
http://<servername>:80/reportserver |
Named instance |
Report Server Web service |
http://<servername>/reportserver_<instancename> |
http://<servername>:80/reportserver_<instancename> |
Named instance |
Report Manager |
http://<servername>/reports_<instancename> |
http://<servername>:80/reports_<instancename> |
SQL Server Express |
Report Server Web service |
http://<servername>/reportserver_SQLExpress |
http://<servername>:80/reportserver_SQLExpress |
SQL Server Express |
Report Manager |
http://<servername>/reports_SQLExpress |
http://<servername>:80/reports_SQLExpress |
Authentication and Service Identity for Reporting Services URLs
Reporting Services URL reservations specify the service account of the Report Server service. The account under which the service runs is used for all URLs that are created for the Reporting Services applications that run in the same instance. The service identity of the report server instance is stored in the RSReportServer.config file.
The service account has no default value. However, specifying a service account is required during Setup and is specified in URLReservation in RSReportServer.config even if you install the server in files-only mode. Valid values for the service account include a domain user account, LocalSystem, or NetworkService.
Anonymous access is disabled because the default security is RSWindowsNegotiate. For intranet access, report server URLs use network computer names. If you want to configure Reporting Services for Internet connections, you must use different settings. For more information about authentication, see Authentication with the Report Server in SQL Server Books Online.
URLs for Local Administration
You can use https://localhost/reportserver or https://localhost/reports if you specified a strong or weak wildcard for the URL reservation.
The https://localhost URL is interpreted as http://127.0.0.1. If you pegged the URL reservation to a computer name or single IP address, you cannot use localhost unless you create an additional reservation for 127.0.0.1 on the local computer. Similarly, if localhost or 127.0.0.1 is disabled on your computer, you cannot use that URL.
Windows Vista and Windows Server 2008 include new security features to minimize the risk of accidentally running programs with elevated privileges. Additional steps are necessary to enable local administration on these operating systems. For more information, see Configure a Report Server for Local Administration on Windows Vista and Windows Server 2008.
URLs for Report Server in SharePoint Integrated Mode
If a stand-alone report server is configured to run within a larger deployment of a SharePoint product or technology, URL and virtual directory construction will be affected in the following ways:
URLs for reports and other items are addressed through the SharePoint Web application URL. For URL access to specific reports, always use a fully qualified URL that includes the site path, the document library, the item name, and a file name extension (such as .rdl for a report). You must specify fully qualified URLs when you reference shared data sources and models in reports, and when you specify a target server and folders for publish operations to a report server.
The file name extension is used to distinguish between different types of report server items. Valid extensions include .rdl for report definitions, .smdl for report models, and .rsds for shared data sources that are created for a SharePoint site.
Although SharePoint products and technologies have URL reservations defined for them, you can ignore the reservation when publishing to the server. For SharePoint Web applications, URL reservation is an internal operation.
For single server deployments where an integrated report server and SharePoint technology instance are installed on the same computer, you cannot use https://localhost/reportserver. If https://localhost is used to access the SharePoint Web application, you must use a non-default Web site or a unique port assignment to access a report server. Furthermore, if the report server is integrated with a SharePoint farm, localhost access to a reports server will not resolve for nodes in the deployment that are installed on remote computers.
The URL reservation and endpoint for Report Manager cannot be configured for a report server that runs in SharePoint integrated mode. If you do configure it, it will no longer work after you deploy a report server in SharePoint integrated mode. Report Manager is not supported in this mode.
If you integrated a report server scale-out deployment to run within a larger deployment of a SharePoint product or technology, load balance the report server nodes and define a single virtual server URL to the scale-out deployment. Report Server integration settings only allow you to specify a single report server URL. In the case of a scale-out deployment, the URL must be the access point for the server nodes in the scale-out deployment.