Troubleshooting Guide

Use this guide to diagnose common SSRS Reports Migration Wizard issues. Most migration problems involve permissions, target-server configuration, data-source connectivity, or credentials.

1. Data-Driven Subscriptions Fail to Import #

Data-driven subscriptions may fail to import when the target report server cannot connect to the data sources used by the report.

Common causes #

• Required database drivers or client providers are missing on the target server, such as an Oracle provider.
• The connection string, server name, database name, or connection identifier is invalid for the target environment.
• Data-source credentials are missing, incorrect, expired, or unavailable to a background subscription process.
• The target server cannot reach the database because of firewall, DNS, routing, or authentication restrictions.
• The SQL Server Agent service is not running on the SQL Server instance hosting the ReportServer database.

Resolution #

1. Open the Migration Wizard’s Manage Connection Properties screen and verify every data source.
2. Confirm that the target server has the required database drivers and can connect to each database.
3. Validate connection strings and database permissions using the same account configured for the report.
4. For subscriptions, use a supported non-interactive credential configuration, normally stored credentials or a correctly configured execution account.
5. Confirm that SQL Server Agent is running on the target SQL Server instance.

2. “The user data source credentials do not meet the requirements to run this report or shared dataset” #

Error message: The user data source credentials do not meet the requirements to run this report or shared dataset. Either the user data source credentials are not stored in the report server database, or the user data source is configured not to require credentials but the unattended execution account is not specified.

This means SSRS cannot execute the report in a background context using the configured data-source authentication method. Subscriptions and other unattended operations cannot rely on credentials entered interactively by a user.

Common causes #

• The data source uses credentials supplied by the user rather than stored credentials.
• Windows Integrated Security is configured, but the report server service account or execution context does not have database access.
• The data source uses No Credentials, but an unattended execution account has not been configured where required.
• Stored credentials were not entered correctly on the target server or could not be re-encrypted for the target environment.
• The configured account lacks the required permissions on the database, views, stored procedures, or other referenced objects.

Resolution #

1. Open the affected report or shared dataset’s data-source properties on the target server.
2. For subscriptions, configure Credentials stored securely in the report server and enter an account with the required database permissions, if permitted by your security policy.
3. If using Windows Integrated Security or No Credentials, configure and validate the appropriate unattended execution account in Report Server Configuration Manager.
4. Check that the account can execute all required queries, views, and stored procedures.
5. If the report uses multiple data sources, validate every data source—not only the one shown in the first error.

3. HTTP 500 Error When Retrieving Shared Schedules #

Error message: Response status code does not indicate success: 500 (Internal Server Error)

Important: In this scenario, the HTTP 500 response can indicate missing SSRS site-level permissions. It does not necessarily mean that the report server has crashed or needs to be restarted.

Shared schedules are system-level SSRS objects. Folder-level permissions alone are not sufficient to enumerate or create them.

Required permissions #

Resolution #

On the source server:

1. Open the SSRS Web Portal.
2. Go to Site Settings → Security.
3. Ensure the migration account has a system role that permits reading shared schedules. System User is generally sufficient for read access; System Administrator can also read them.

On the target server:

1. Open the target SSRS Web Portal.
2. Go to Site Settings → Security.
3. Ensure the migration account has System Administrator permissions required to create shared schedules.

Note: System User may be sufficient on the source for reading schedules, but it is not sufficient on the target when the migration must create shared schedules.

Continue without shared schedules #

If your organization cannot grant the required system permissions, the wizard can offer the option to continue without shared schedule migration when you select subscription migration. Subscriptions can still be migrated, but shared schedule assignments will not be recreated.

4. Reports or Datasets Fail After Migration #

If reports or shared datasets migrate successfully but fail when opened on the target server, check the target environment before repeating the migration.

• Verify that every migrated data source exists and is associated with the correct report or dataset.
• Check connection strings, database names, authentication method, and stored credentials.
• Confirm that the target report server can reach the database and that the account has the required permissions.
• Install any required database drivers or providers on the target server.
• Review the SSRS execution log and Windows Event Viewer for the underlying provider or authentication error.

5. Migration Permissions and Access Checklist #

• Use an account with sufficient folder-level permissions to read source items and create or update target items.
• Grant system-level permissions when migrating shared schedules or other system-level objects.
• Ensure the account can access the SSRS Web Service endpoints from the computer running the wizard.
• Check firewall, proxy, DNS, TLS, and network connectivity between the wizard, report servers, and data sources.
• Run the wizard with the same Windows account and network context that you intend to use for the migration.

6. Retrieve Detailed Errors from SSRS Report Server Logs #

When the wizard reports a generic error, retrieve the detailed error from the source or target report server. Check the source when reading or exporting reports, subscriptions, schedules, or data sources; check the target when creating or updating migrated items.

Step 1: Identify the affected report server #

1. Record the exact time of the failure, including the time zone.
2. Identify whether the failure occurred while connecting to or reading from the source, or while creating/updating items on the target.
3. Record the report server URL, report server product/version, migration step, and affected item.

Step 2: Open the SSRS log folder #

On the affected report server, locate the SSRS log directory. The default location is commonly:

C:\Program Files\Microsoft SQL Server\MSRS<version>.<instance>\Reporting Services\LogFiles

The exact folder depends on the SQL Server/SSRS version and instance name. You can also locate it from Reporting Services Configuration Manager or search the server for the Reporting Services\LogFiles directory.

Step 3: Review the relevant log files #

• ReportServerService_*.log — Report server service activity, report execution, subscriptions, data-source access, and server-side exceptions.
• Microsoft.ReportingServices.Portal.WebHost_*.log — Web portal activity and portal-side errors, when available.
• HTTPERR, IIS, or Windows Event Viewer logs — Useful for HTTP, hosting, authentication, service, or connectivity failures.

Step 4: Search around the failure time #

1. Open the newest log file in a text editor with administrator access if required.
2. Search for the failure time, report name, folder path, subscription name, correlation/activity ID, or terms such as ERROR, WARN, Exception, Unauthorized, Access denied, timeout, and database.
3. Read several lines before and after the matching entry. The first visible error may be only a wrapper; the inner exception often contains the actual cause.
4. Repeat the search on the other report server if the migration involves both source and target operations.

Step 5: Correlate the log entry with the migration action #

Step 6: Collect logs safely for support #

• Collect the relevant log file name, timestamp, error message, inner exception, and correlation/activity ID.
• Include whether the entry came from the source or target server.
• Include the wizard version, SSRS version, migration mode, and affected item.
• Redact passwords, connection-string secrets, access tokens, usernames where sensitive, and report data before sharing logs.
• Do not send the entire log directory unless requested; provide the smallest relevant excerpt that preserves the surrounding context.

7. Before Contacting Support #

Collect the following information so the issue can be diagnosed quickly:

• Source and target report-server products and versions.
• Whether the migration is server-to-server or server-to-file.
• The exact error message and migration step where it occurred.
• Whether the issue affects one item or all reports, datasets, subscriptions, or schedules.
• Relevant SSRS logs, provider errors, and screenshots with passwords and secrets removed.

Security reminder: Never send passwords, connection strings containing secrets, access tokens, or exported files containing sensitive credentials in a support request. Redact sensitive values before sharing diagnostic information.