Administering the Report Server Web Service and Windows Service

A report server runs as a Windows service and as a Web service. The services work together and support different aspects of report server functionality:

  • The Report Server Windows service performs initialization, reversible encryption, database maintenance tasks, and all scheduling and delivery. The service runs in the background. It performs end-to-end processing for reports that run on a schedule (specifically, it creates report snapshots and runs subscription reports).
    Because it performs all encryption operations, the Report Server Windows service must be running whenever you specify or use encrypted values. Specifying stored credentials, running a report that uses stored credentials, and publishing a report to a report server (data source information is encrypted) are all operations that require the Report Server Windows service.
  • The Report Server Web service performs end-to-end processing for reports that run on demand. It is also provides the primary programmatic interface for applications that integrate with a report server. Report Manager, Report Builder, and SQL Server Management Studio are examples of applications that require the Report Server Web service.

In most cases, you will want to run the services together so that you can use all of the functionality provided in Reporting Services. However, if the deployment model you are implementing has very narrow requirements, you can run just the Report Server Windows service if all report processing is configured as scheduled operations. Similarly, you can run just the Report Server Web service if you only want interactive, on-demand reporting.

To make either service unavailable, run the SQL Server Surface Area Configuration Tool and select the Surface Area Configuration for Features option. You cannot turn off the Report Server Windows service completely; it provides initialization and encryption functionality that is required for server operations. However, you can turn off scheduled and event processing.

The Report Server Windows service is registered and configured during Setup. It runs under whatever account you specify. We recommend a least-privilege domain user account that has permission to logon to the network or NetworkService, but you can use a local account if the report server database runs on the same computer as the report server. The Report Server Web service runs under the ASP.NET identity by default. If you modify service account settings, be sure to use the Reporting Services Configuration tool so that dependent settings are updated with the new values. For more information about account configuration, see Connections and Accounts in a Reporting Services Deployment and Configuring Service Accounts and Passwords in Reporting Services.

The Report Server Windows service requires the SQL Server Agent service. SQL Server Agent service must run under a domain account if you configured the report server to connect to SQL Server using a domain account and Windows authentication (as opposed to a SQL Server login or Service Account). When the report server runs as a domain user, the report server creates SQL Server Agent jobs that are owned by that domain account. Before SQL Server Agent can route a task to the Scheduling and Delivery Processor, SQL Server Agent must have permission to access job information for jobs owned by a domain account. If SQL Server Agent happens to run as a local user account, the service will not have permission to access domain account information, and report subscription and delivery will subsequently fail.