The C2WTS turns the claims token into a Windows token and hands it back to the SharePoint worker process.SQL does not know what that is, so we must use the Claims to Windows Token Service (C2WTS) to turn that claim into a Windows token. Inside of SharePoint, the user is a “claim”.You will NOT see any network calls directly from the client to SSRS. This is done by the SharePoint worker process (W3WP.exe).The web part must contact the SSRS server to execute the report.The client can use either NTLM or Kerberos to authenticate to SharePoint.The client browses the SharePoint page that contains the Report Viewer web part.That’s where things typically go wrong, and where it takes and understanding of how it works in order to properly troubleshoot it. Now that we have the web part in place, we can focus on configuring the infrastructure that is required to make it work. Then edit the web part and point it at one of your reports:Īt this point, the web part is likely to throw the following error because we haven’t yet configured the necessary infrastructure to allow it to work.įor more information about this error navigate to the report server on the local server machine, or enable remote errors“. Then you’ll need to deploy the SQL Server Reporting Services Report Viewer web part on a SharePoint site: Īnd add SQL Server Reporting Services Report Viewer web part to a SharePoint page: You can read more about the SharePoint-to-SSRS integration story and find a link to download that farm solution here: The SSRS Report Viewer web part comes as part of a custom farm-level solution. Installing SharePoint, SQL and SSRS are beyond the scope of this post, so let’s pretend you already have those set up, and we’ll start from there.
As such, the SharePoint integration with SQL Server Reporting Services (SSRS) is pretty much limited to getting the Report Viewer web part to work. Starting with SQL Server 2017, there’s only one installation mode for Reporting Services: Native mode.
0 kommentar(er)
