Rediger

Del via

Migrate a Reporting Services Installation (Native Mode)

  • Artikel

This article provides step-by-step instructions for how to migrate one of the following supported versions of a Reporting Services native mode deployment to a new SQL Server Reporting Services instance:

  • SQL Server 2016 (13.x)

  • SQL Server 2014 (12.x)

  • SQL Server 2012 (11.x)

  • SQL Server 2008 R2 (10.50.x)

  • SQL Server 2008 (10.0.x)

  • SQL Server 2014 (12.x)

  • SQL Server 2012 (11.x)

  • SQL Server 2008 R2 (10.50.x)

  • SQL Server 2008 (10.0.x)

For information on migrating a Reporting Services SharePoint mode deployment, see Migrate a Reporting Services Installation (SharePoint Mode).

Migration is defined as moving application data files to a new SQL Server instance. The following are common reasons you must migrate your installation:

  • You have a large-scale deployment or uptime requirements.

  • You change the hardware or topology of your installation.

  • You encounter an issue that blocks upgrade.

Native mode migration overview

The migration process for Reporting Services includes manual and automated steps. The following tasks are part of a report server migration:

  • Back up database, application, and configuration files.

  • Back up the encryption key.

  • Install a new instance of SQL Server. If you use the same hardware, you can install SQL Server side by side with your existing installation if it was one of the supported versions.

    Tip

    A side-by-side installation may require that you install SQL Server as a named instance.

  • Move the report server database and other application files from your existing installation to your new SQL Server installation.

  • Move any custom application files to the new installation.

  • Configure the report server.

  • Edit RSReportServer.config to include any custom settings from your previous installation.

  • Optionally, configure custom Access Control Lists (ACLs) for the new Reporting Services Windows service group.

  • Remove unused applications and tools after you confirm that the new instance is fully operational.

There are restrictions on the editions of SQL Server that host the report server database. Review the following article if you reuse a report server database that was created in a previous installation.

Fixed database name

You can't rename the report server database. The identity of the database is recorded in report server stored procedures when the database is created. Renaming either the report server primary or temporary databases cause errors when the procedures run, invalidating your report server installation.

If the database name from the existing installation isn't suited for the new installation, you should consider creating a new database that has the name, and then load existing application data by using the techniques in the following list:

  • Write a Visual Basic script that calls Report Server Web service SOAP methods to copy data between databases. You can use the RS.exe utility to run the script. For more information about this approach, see Scripting and PowerShell with Reporting Services.

  • Write code that calls the Windows Management Instrumentation (WMI) provider to copy data between databases. For more information about this approach, see Access the Reporting Services WMI Provider.

  • If you have just a few items, you can republish reports and shared data sources from Report Designer, Model Designer, and Report Builder to the new report server. Recreate the role assignments, subscriptions, shared schedules, report snapshot schedules, custom properties that you set on reports. You can also recreate them on other items, model item security, and properties that you set on the report server. Be prepared to lose report history and report execution log data if you follow these actions.

Before you start

Even when you migrate rather than upgrade the installation, consider running Upgrade Advisor on your existing installation to help identify any issues that could affect migration. This step is especially helpful if you migrate a report server that you didn't install or configure. By running Upgrade Advisor, you can learn about custom settings that might not be supported in a new SQL Server installation.

In addition, you should be aware of several important changes in SQL Server Reporting Services that affect how you migrate your installation:

  • The web portal replaced Report Manager.

  • For SQL Server 2008 (10.0.x) and newer versions, IIS is no longer a prerequisite. If you migrate a report server installation to a new computer, you don't need to add the Web server role. In addition, steps for configuring URLs and authentication are different from the previous release, as are techniques and tools for diagnosing and troubleshooting problems.

  • Report Server Web service, the web portal, and the Report Server Windows service run under the same account. All three applications read configuration settings from RSReportServer.config file.

  • The web portal and SQL Server Management Studio are designed to remove overlapping features. Each tool supports a distinct set of tasks.

  • ISAPI filters aren't supported in SQL Server 2008 (10.0.x) Reporting Services and later versions. If you use ISAPI filters, you must redesign your reporting solution before migration.

  • IP address restrictions aren't supported in SQL Server 2008 (10.0.x) Reporting Services and later versions. If you use IP address restrictions, you must redesign your reporting solution prior to migration or use a technology such as a firewall, router, or Network Address Translation (NAT) to configure addresses that are restricted from accessing the report server.

  • Client Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL), certificates aren't supported in SQL Server 2008 (10.0.x) Reporting Services and later versions. If you use client TLS certificates, you must redesign your reporting solution before migration.

  • If you use an authentication type other than Windows-Integrated authentication, you must update the <AuthenticationTypes> element in the RSReportServer.config file with a supported authentication type. The supported authentication types are NTLM, Kerberos, Negotiate, and Basic. Anonymous, .NET Passport, and Digest authentication aren't supported in SQL Server 2008 (10.0.x) Reporting Services and later versions.

  • If you use custom cascading style sheets in your reporting environment, they can't be migrated. Manually move them following migration.

For more information about changes in SQL Server Reporting Services, see the Upgrade Advisor documentation and What's new in SQL Server Reporting Services (SSRS).

Backup files and data

Before you install a new instance of Reporting Services, be sure to back up all of the files in your current installation.

  1. Back up the encryption key for the report server database. This step is critical to migration success. Further on in the migration process, you must restore it for the report server to regain access to encrypted data. To back up the key, use the Report Server Configuration Manager.

  2. Back up the report server database by using any of the supported methods for backing up a SQL Server database. For more information, see the instructions on how to back up the report server database in Moving report server databases to another computer (SSRS native mode).

  3. Back up the report server configuration files. Files to back up include:

    1. Rsreportserver.config

    2. Rswebapplication.config

    3. Rssrvpolicy.config

    4. Rsmgrpolicy.config

    5. Reportingservicesservice.exe.config

    6. Web.config for the Report Server ASP.NET application.

    7. Machine.config for ASP.NET if you modified it for report server operations.

Install SQL Server Reporting Services

Install a new report server instance in files-only mode so that you can configure it to use nondefault values. For command-line installation, use the FilesOnly argument. In the Installation Wizard, select the Install but do not configure option.

Select one of the following links to view instructions on how to install a new instance of Reporting Services:

Move the report server database

The report server database contains published reports, models, shared data sources, schedules, resources, subscriptions, and folders. It also contains system and item properties, and permissions for accessing report server content.

If your migration includes a different Database Engine instance, you must move the report server database to the new Database Engine instance. If you use the same Database Engine instance, skip to section Move Custom Assemblies or Extensions.

To move the report server database, follow these steps:

  1. Choose the Database Engine instance to use. SQL Server Reporting Services requires that you use one of the following versions to host the report server database:

    • SQL Server 2016 (13.x)

    • SQL Server 2014 (12.x)

    • SQL Server 2012 (11.x)

    • SQL Server 2008 R2 (10.50.x)

    • SQL Server 2008 (10.0.x)

    • SQL Server 2014 (12.x)

    • SQL Server 2012 (11.x)

    • SQL Server 2008 R2 (10.50.x)

    • SQL Server 2008 (10.0.x)

  2. Start SQL Server Management Studio and connect to the Database Engine.

  3. Create the RSExecRole in the system databases if the Database Engine has never hosted a report server database. For more information, see Create the RSExecRole.

  4. Follow the instructions in Moving the Report Server Databases to Another Computer (SSRS Native Mode).

Remember that both the report server database and the temporary database are interdependent and must be moved together. Don't copy the databases; copying doesn't transfer all of the security settings to the new installation. Don't move SQL Server Agent jobs for scheduled report server operations. The report server recreates these jobs automatically.

Move custom assemblies or extensions

If your installation includes custom report items, assemblies, or extensions, you must redeploy the custom components. If you don't use custom components, skip to section Configure the Report Server.

To redeploy the custom components, follow these steps:

  1. Determine whether the assemblies are supported or need recompilation:

    • Custom security extensions must be rewritten by using the IAuthenticationExtension2 interface.

    • Custom rendering extensions for SQL Server 2008 (10.0.x) Reporting Services must be rewritten by using the Rendering Object Model (ROM).

    • HTML 3.2 and HTML OWC renderers aren't supported in SQL Server 2008 (10.0.x) Reporting Services and later versions.

    • Other custom assemblies shouldn't require recompilation.

  2. Move the assemblies to the new report server \bin folder. In SQL Server, the report server binaries are located in the following location for the default report server instance:

    \Program files\Microsoft SQL Server\MSRS13.MSSQLSERVER\Reporting Services\ReportServer\bin

  3. Modify the configuration files to add entries for your custom component. The entries vary depending on the kind of assembly you use. For instructions on where to place files and add configuration entries, see the following:

    1. Deploying a custom assembly

    2. How to deploy a custom report item

    3. Deploy a data processing extension

    4. Deploy a delivery extension

    5. Deploy a rendering extension

    6. Implement a security extension

Configure the Report Server

Configure URLs for the Report Server Web service and web portal, and configure the connection to the report server database.

If you migrate a scale-out deployment, take all of the report server nodes offline and migrate each server one at a time. After the first report server is migrated and successfully connects to the report server database, the report server database version is automatically upgraded to the SQL Server database version.

Important

If any of the report servers in the scale-out deployment are online and have not been migrated, they might encounter an rsInvalidReportServerDatabase exception because they use an older schema when connected to the upgraded.

If the migrated report server is configured as the shared database for a scale-out deployment, you need to delete any of the old encryption keys from the Keys table in the ReportServer database, before configuring the report server service. If the keys aren't removed, the migrated report server tries to initialize in scale-out deployment mode. For more information, see Add and remove encryption keys for scale-out deployment and Configure and Manage Encryption Keys (Report Server Configuration Manager).

The scale-out keys can't be deleted by using the Reporting Services Configuration Manager. The old keys must be deleted from the Keys table in the ReportServer database using SQL Server Management Studio. Delete all rows in the Keys table. This action clears the table and prepares it for restoring the Symmetric key only, as documented in the following steps.

Before deleting the keys, you should back up the Symmetric Encryption key. You can use the Reporting Services Configuration Manager to back up the key. Open the Configuration Manager open, select the Encryption Keys tab, and then select Backup. You can also script WMI commands to back up the encryption key. For more information on WMI, see ConfigurationSetting method - BackupEncryptionKey.

  1. Start the Report Server Configuration Manager and connect to the Reporting Services instance you installed. For more information, see What is Report Server Configuration Manager (Native mode)?.

  2. Configure URLs for the report server and the web portal. For more information, see Create a Native Mode Report Server Database (Report Server Configuration Manager).

  3. Configure the report server database, selecting the existing report server database from your previous installation. After successful configuration, the report server service restarts, and once a connection is made to the report server database, the database automatically upgrades to SQL Server Reporting Services. For more information about how to run the Change Database Wizard that you use to create or select a report server database, see Create a Native Mode Report Server Database (Report Server Configuration Manager).

  4. Restore the encryption keys. This step is necessary for enabling reversible encryption on preexisting connection strings and credentials that are already in the report server database. For more information, see Back up and restore SQL Server Reporting Services (SSRS) encryption keys.

  5. If you installed report server on a new computer and you use Windows Firewall, be sure that the TCP port on which the report server listens is open. By default, this port is 80. For more information, see Configure a firewall for report server access.

  6. If you want to administer your native mode report server locally, you need to configure the operating system to allow local administration with the web portal. For more information, see Configure a native mode report server for local administration (SSRS).

Copy custom configuration settings to the RSReportServer.config file

If you modified the RSReportServer.config file or RSWebApplication.config file in the previous installation, you should make the same modifications in the new RSReportServer.config file. The following list summarizes possible modifications for the previous configuration file. The list also provides links to additional information about how to configure the same settings in SQL Server 2016.

Customization Information
Report Server E-mail delivery with custom settings Email settings in Reporting Services native mode (Report Server Configuration Manager).
Device information settings Customize rendering extension parameters in RSReportServer.Config

Windows Service group and security ACLs

In SQL Server 2016 (13.x) Reporting Services or later (SSRS), there's one service group, the Reporting Services Windows Service group, which is used to create security ACLs for all the registry keys, files, and folders that are installed with SQL Server Reporting Services. This Windows group name appears in the format SQLServerReportServerUser$<computer_name>$<instance_name>.

Verify your deployment

  1. Test the report server and web portal virtual directories by opening a browser and entering the URL address. For more information, see Verify a Reporting Services Installation.

  2. Test reports, and verify they contain the data you expect. Review data source information to see whether the data source connection information is still specified. The report server uses the report object model when processing and rendering reports, but it doesn't replace SQL Server 2008 (10.0.x), SQL Server 2008 R2 (10.50.x), SQL Server 2012 (11.x), or SQL Server 2014 (12.x) constructs with new report definition language elements. To learn more about how existing reports run on a new version of your report server, see Upgrade Reports (SSRS).

Remove unused programs and files

After you successfully migrate your report server to a new instance, you should perform the following steps to remove programs and files that are no longer necessary.

  1. Uninstall the previous version of Reporting Services if you no longer need it. This step doesn't delete the following items, but you can manually remove them if you no longer need them:

    • The previous Report Server database

    • RsExec role

    • Report Server service accounts

    • Application pool for the Report Server Web service

    • Virtual directories for Report Manager and the report server

    • Report server log files

  2. Remove IIS if you no longer need it on this computer.

Next steps

More questions? Try asking the Reporting Services forum