Scripting Deployment and Administrative Tasks
Reporting Services supports the use of scripts to automate routine installation, deployment, and administrative tasks. Deploying a report server is a multi-step process. You must use several tools and processes to configure a deployment; there is no single program or approach that can be used to automate all the tasks.
Not every step should be automated. In some cases, performing a step manually or through a graphical tool is the simplest and most effective approach. For example, if you want to deploy a large number of reports and models, it is better to copy the report server databases rather than write code that recreates report server environment.
Some steps require custom code. For example, configuring the URLs for the Web service and Report Manager can be automated, but only if you write custom code that makes calls into the Report Server Windows Management Instrumentation (WMI) provider. If you do not want to write code, you must use the Reporting Services Configuration tool to perform the step.
To run script that configures a report server, you must be a local administrator on the computer that you are configuring. For more information, see How to: Configure a Report Server for Remote Administration.
This topic describes recommended approaches for automating specific steps. Several programs and programmatic interfaces are mentioned; descriptions of each one are provided later in this topic.
The following table summarizes the installation and configuration tasks that are necessary for deploying a report server. You can use the table to match a specific task to an approach that allows you to automate or perform the task unattended.
Install Reporting Services.
You can run setup from the command line to perform an unattended installation.
You can use Setup to both install and configure a report server, but only if you specify the default configuration option and your system meets all the requirements for this installation type. If you cannot install the default configuration, you must perform a files-only installation. For more information about installation options, see Considerations for Installing Reporting Services.
Configure the service account.
The service account is initially configured through Setup. To automate changes to the service account as a post-Setup task, you must write custom code that makes calls into the Report Server WMI provider. There are no command-prompt utilities or script templates for configuring the service account programmatically.
If coding requirements prevent you from automating this step, you can easily configure the account manually by running the Reporting Services Configuration tool. For more information, see How to: Configure a Service Account for Reporting Services.
Configure the Report Server Web service and Report Manager URLs.
You must write custom code that makes calls into the Report Server WMI provider. There are no command line utilities or script templates for configuring the URLs.
If you want to avoid writing code, you can configure the URLs manually by running the Reporting Services Configuration tool. For more information, see How to: Configure a URL (Reporting Services Configuration).
Create the report server database.
You must write custom code that makes calls into the Report Server WMI provider. There are no command-prompt utilities or script templates for creating the report server databases and RSExecRole.
If you want to avoid writing code, you can create the database manually by running the Reporting Services Configuration tool. For more information, see How to: Create a Report Server Database (Reporting Services Configuration).
Configure the report server database connection.
If you are changing the connection string, account or password, or the authentication type, run the rsconfig utility to configure the connection. For more information, see Configuring a Report Server Database Connection and rsconfig Utility.
You cannot use rsconfig.exe to create or upgrade the database. The database and RSExecRole must already exist.
Configure a scale-out deployment.
Choose from the following approaches to automate scale-out deployment:
Backup encryption keys.
Choose from the following approaches to automate encryption key backup:
Configure Report Server E-mail.
Write custom code that runs against the Reporting Services WMI provider. The provider supports a subset of the e-mail configuration settings.
Although the RSReportServer.config file includes all the settings, do not use the file in an automated manner. Specifically, do not use a batch file to copy the file to another report server. Each configuration file includes values that are specific to the current instance. Those values will not be valid on other report server instances.
For more information about the settings, see Configuring a Report Server for E-Mail Delivery.
Configure the unattended execution account.
Choose from the following approaches to automate unattended processing account configuration:
Deploy existing content on another report server, including the folder hierarchy, role assignments, reports, subscriptions, schedules, data sources, and resources.
The best way to re-create an existing report server environment is to copy the report server database to a new report server instance.
An alternative approach is to write custom code that recreates existing report server content programmatically. However, be aware that subscriptions, report snapshots, and report history cannot be recreated programmatically.
Some deployments can benefit from using both techniques together (that is, restore a report server database, and then run custom code that modifies the report server database for a specific installation).
For more information about relocating a report server database, see Moving the Report Server Databases to Another Computer. For more information about creating report serer environment programmatically, see the section "Using Script to Migrate Report Server Content and Folders" in this topic.
The following list summarizes the programs and interfaces that can be used to automate deployment and maintenance tasks:
The Setup program can be run in unattended mode to install and sometimes configure report server components. You must use the Files-Only installation option to have Setup configure a report server instance.
The Reporting Services WMI provider and Reporting Services command line utilities can be used for local and remote server configuration.
The Reporting Services WMI provider exposes classes, properties, and methods that allow you to configure all aspects of a Reporting Services installation including specifying the service account, configuring URLs, creating and configuring the report server database, or configuring a report server for e-mail delivery. You must write custom code or script to use the WMI provider. For more information, see Reporting Services WMI Provider.
An alternative to writing code is to use the command line utilities (rsconfig.exe and rskeymgmt.exe). You can write batch files that run the utilities. You can use the utilities to automate some but not all configuration tasks.
The report server script host tool (rs.exe) can run custom Microsoft Visual Basic code that you might write to re-create or move existing content from one report server to another. With this approach, you write script in Visual Basic, save it as an .rss file, and use rs.exe to run the script on the target report server. The script you write can call the SOAP interface to the Report Server Web service. Deployment scripts are written using this approach because it allows you to re-create a report server folder namespace and content, and re-create role-based security.
You can write scripts that duplicate a report server environment on another report server instance. Deployment scripts are generally written in Visual Basic and then processed using the report server script host utility.
Use scripts to copy folders, shared data sources, resources, reports, role assignments, and settings from one server to another. You write a script for one report server instance, and then run it on another server to re-create the report server namespace. If you have multiple report servers in your Reporting Services deployment, you can run the script on each server individually to configure all servers in the same way.
The following list describes the steps for migrating reports from one server to another.
Set your script variable to the URL of the source report server.
Set the URL to point to the destination server.
By using a combination of get and create methods, you can perform similar steps to migrate settings, folders, shared data sources, and resources. For more information about the methods available to you, see Technical Reference (Reporting Services).
Scripts run under the Microsoft Windows credentials of the user running the script unless credentials are explicitly set.
For more information about how to format and run a script file, see Scripting with the rs Utility and the Web Service.
You can write scripts that set system properties on the report server. The following Visual Basic .NET script shows one way to set properties. This example disables the RSClientPrint ActiveX control, but you can replace EnableClientPrinting and False with any valid property name and value. To view a complete list of server properties, see Report Server System Properties.
To use the script, save it to a file that has an .rss extension, and then use the rs.exe command prompt utility to run the file on the report server. The script is not compiled, so it is not necessary to have an installation of Visual Basic. This example assumes that you have permissions on the local computer that hosts the report server. If you are not logged on under an account that has permissions, you must specify account information through additional command line arguments. For more information, see rs Utility.
Public Sub Main() Dim props(0) As [Property] Dim setProp As New [Property] setProp.Name = "EnableClientPrinting" setProp.Value = “False” props(0) = setProp Try rs.SetSystemProperties(props) Catch ex As System.Web.Services.Protocols.SoapException Console.Write(ex.Detail.InnerXml) Catch e as Exception Console.Write(e.Message) End Try End Sub