SSRS can still deliver reports into SharePoint, but only through SharePoint mode, which pairs a report server with the rssharepoint add-in and supports subscriptions for scheduled delivery. Microsoft removed SharePoint integration after SQL Server 2016, so new deployments should plan around native SSRS or a dedicated automation layer instead.
TL;DR:
- Legacy farms need the report server in SharePoint mode and the add in on every web front end; verify version compatibility before installation.
- Configure SMTP, sender address, formats, and schedules in Central Administration, then test delivery to yourself; check relay access, library write permissions, and paused status.
- Check active jobs in Central Administration, cancel stuck work there, and compare SSRS trace, SharePoint ULS, and Windows Event logs before restarting services.
- For migration, export report definitions and map every subscription’s recipients and schedule; test a native SSRS server before switching production delivery.
- Claims based authentication may require c2WTS and correctly configured delegation; align service account permissions across the report server, SharePoint, and data sources.
Table of Contents
- 1. What to install and where: report server, add-in, and farm placement
- 2. Configuring email and subscriptions in SharePoint mode
- 3. Viewing, canceling, and monitoring SSRS jobs
- 4. Authentication, permissions, and c2WTS notes
- 5. When to migrate and how to do it without breaking delivery
- 6. Production checklist from a BI automation perspective
- What the conventional advice gets wrong
- Replacing manual SSRS delivery with automated workflows
- FAQ
- Sources
1. What to install and where: report server, add-in, and farm placement
SharePoint-integrated SSRS depends on two components working together. The report server runs in SharePoint mode and acts as a shared service within the farm, while the rssharepoint add-in installs on every web front end (WFE) so SharePoint pages can render reports. Microsoft documents both pieces and their roles in the install guide for Reporting Services in SharePoint mode, which also confirms that this integration path stops after SQL Server 2016 and that Power View support ends after SQL Server 2017.
Scale-out farms need the add-in on each WFE, not just one, and the report server service should be provisioned and started before you try to configure subscriptions. Community threads on SSRS 2019 deployments consistently flag add-in and version mismatches as the first thing to check when a farm behaves inconsistently across nodes.
Before you install anything, run through a short checklist:
- Confirm your SQL Server, SharePoint, and SSRS versions fall within a supported combination compatible with SQL Server 2016 and earlier versions, as integration is not supported beyond that.
- Create or verify the service accounts the report server and add-in will use.
- Back up the SharePoint content databases and any existing report server databases.
- Document current web front ends so you know where the add-in needs to land.
Skipping the compatibility check is the single most common cause of a failed SharePoint-mode install.
2. Configuring email and subscriptions in SharePoint mode
Once the components are installed, subscription delivery depends on getting SMTP and Reporting Services settings right inside SharePoint Central Administration. Get these settings wrong and reports will render but never leave the server.
- Open the Reporting Services service application in Central Administration and set the outbound SMTP server, sender address, and default file formats.
- Create a standard subscription on the report, choosing a delivery schedule and output format such as PDF or Excel.
- For variable recipient lists or parameters, build a data-driven subscription that pulls recipient and parameter data from a query instead of a fixed list.
- Set the delivery frequency and confirm the subscription appears as active before relying on it.
Pro Tip: Send a test subscription to yourself first, with logging enabled, before rolling delivery out to a distribution list.
The most common pitfalls are an untested SMTP relay, a service account missing write permissions on the destination library, and subscriptions left in a paused state after a farm patch. Our guide to SSRS subscriptions walks through subscription types in more depth if you're setting these up for the first time.
3. Viewing, canceling, and monitoring SSRS jobs
When a subscription hangs or a report job runs long, you manage it from the same place you configured it: the Reporting Services service application inside SharePoint Central Administration. Microsoft's guidance on managing a running process covers viewing active jobs and canceling them, and it calls out that data-driven subscriptions need a separate cancellation step from standard subscriptions.
A practical troubleshooting pass looks like this:
- Check the job list in Central Administration first to confirm whether a report is still processing or has already failed.
- Cancel a stuck job through the service application rather than restarting the whole service.
- Cross-reference SSRS trace logs with SharePoint ULS logs for the same timestamp window.
- Check the Windows Event Log on the report server for authentication or timeout errors tied to the failed job.
Recurring failures across multiple subscriptions usually point to a shared cause, often SMTP throttling or an expired service account password, rather than a problem with any single report.
4. Authentication, permissions, and c2WTS notes
SharePoint-integrated SSRS can run on classic Windows authentication or claims-based authentication, and the two behave differently once delegation is involved. Windows auth passes credentials directly, while claims-based setups often need the Claims to Windows Token Service (c2WTS) to translate a claims identity back into a Windows token the report server can use. Microsoft's install documentation references c2WTS specifically for scenarios where delegation to a back-end data source is required.
Service accounts need consistent permissions across the report server, the SharePoint content database, and any data sources the reports query, plus constrained delegation configured correctly in Active Directory when claims are in play. When subscriptions fail with authentication errors, community troubleshooting threads on this exact problem are a faster starting point than guessing at permission changes.
5. When to migrate and how to do it without breaking delivery
Microsoft's own documentation is direct: SharePoint integration for Reporting Services is not available after SQL Server 2016, so any new SSRS deployment should not plan around it. If you're already running an older SharePoint-integrated farm, migration is a matter of when, not if.
A practical migration path starts with an inventory: export your report definitions, map every existing subscription (standard and data-driven) to its recipients and schedule, and stand up a native SSRS report server to test against before cutting over production traffic.
From there, most teams pick one of three directions:
- Move report hosting and subscriptions to native SSRS mode, which Microsoft continues to support.
- Replace native subscriptions with a dedicated automation tool that handles scheduling, formatting, and delivery outside SharePoint mode entirely.
- Run a hybrid setup temporarily, keeping some SharePoint delivery while new reports move to native mode.
After cutover, verify success with a short checklist: run test deliveries for every migrated subscription, confirm permissions resolve correctly in the new environment, and watch job logs for at least one full delivery cycle before decommissioning the old farm. Our piece on deploying SSRS data-driven subscriptions covers lightweight ways to rebuild those subscriptions on the other side.
6. Production checklist from a BI automation perspective
Teams that run SSRS delivery reliably treat it as infrastructure, not a one-time setup. That means scheduled backups of the report server database, a standing test subscription that alerts you the moment delivery silently stops, and a written runbook for the authentication and job-cancellation steps covered above.
Automation starts to matter once you outgrow basic subscriptions: bursting a single report to hundreds of personalized recipients, routing output to destinations beyond a mailbox, or needing automatic retries when a delivery fails. Our scheduling guidance in the enterprise SSRS scheduling guide reflects two decades of building these workflows, backed by our SOC 2 Type II certification for the controls behind them.
What the conventional advice gets wrong
Most guidance on SSRS-to-SharePoint delivery treats the deprecation notice as a footnote and spends the rest of the page on installation steps for a mode Microsoft has already retired for new work. That ordering is backward. The install steps still matter if you're stuck maintaining a legacy farm, but the first decision every team should make is whether SharePoint mode deserves any more investment at all.
The bigger blind spot is authentication. Teams spend days debugging permissions and c2WTS configuration that would not exist if the reports lived on a native server with a dedicated delivery tool instead. Claims-based delegation inside a SharePoint farm is a reasonable architecture for collaboration, but it's a heavy price to pay just to email a PDF on a schedule.
If you're planning new reporting infrastructure in 2026, prioritize a clean separation between where reports are authored and where they get delivered. That split is what actually prevents the authentication headaches and stuck subscriptions this article spends most of its time explaining how to fix.
— Christian Ofori-Boateng
Replacing manual SSRS delivery with automated workflows
When native subscriptions or a deprecated SharePoint farm can't keep up, PBRS for Power BI and SSRS gives us a way to schedule, format, and deliver SSRS reports without rebuilding farm infrastructure. We handle data-driven bursting, multiple export formats, and delivery to email, cloud storage, and other destinations beyond a single mailbox, with built-in monitoring so a failed delivery gets flagged instead of going unnoticed.
If your team is still debugging c2WTS errors to get a report out the door, explore PBRS for SSRS automation and see what a dedicated delivery layer replaces.
If your reporting mix also includes dashboards embedded in SharePoint pages, a partner guide on embedding Power BI in SharePoint is worth reading alongside your migration plan.
FAQ
Is SharePoint going away in 2026?
No, SharePoint itself continues as an active Microsoft product. What changed is SSRS's integration mode with SharePoint, which Microsoft stopped supporting after SQL Server 2016.
Is Microsoft discontinuing SSRS?
SSRS itself remains supported in native mode; it's specifically the SharePoint-integrated mode that Microsoft removed after SQL Server 2016. Teams on SQL Server 2016 or later should plan delivery around native SSRS or a dedicated automation tool rather than SharePoint mode.
Is SSIS being phased out?
SQL Server Integration Services is a separate product from Reporting Services and is not affected by the SharePoint-mode deprecation discussed here. Any questions about SSIS's roadmap should be directed to Microsoft's own SQL Server documentation rather than SSRS guidance.
How do I migrate SSRS reports to another server?
Start by exporting your report definitions and documenting every existing subscription, then install a native SSRS report server and test each report against it before switching production traffic. Our guide to getting started with SSRS reporting covers the baseline setup steps for a native deployment.
What delivery formats can SSRS send to SharePoint?
Standard and data-driven subscriptions in SharePoint mode typically support formats such as PDF and Excel, configured when you set up each subscription. Format availability depends on your report server configuration, so confirm supported renderers before scheduling production deliveries.