I ran into an interesting issue the other day, and wanted to document it as I’ve never seen this particular error, nor was I able to find any documentation on it. We were getting the following error on every report execution within SharePoint 2013:
ERROR: Throwing Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: ,
Microsoft.ReportingServices.ReportProcessing.ReportProcessingException: Cannot create a connection to data source ‘DataSource’. —> System.IO.FileLoadException: Could not load file or assembly ‘Microsoft.ReportingServices.SemanticQueryEngine, Version=188.8.131.52, Culture=neutral, PublicKeyToken=89845dcd8080cc91′ or one of its dependencies. Access is denied.
at Microsoft.ReportingServices.Library.RSService.CreateDataExtensionInstance(String extensionName, Guid modelID)
at Microsoft.ReportingServices.Diagnostics.DataExtensionConnectionBase.OpenDataSourceExtensionConnection(IProcessingDataSource dataSourceObj, String connectString, DataSourceInfo dataSourceInfo, String datasetName)
at Microsoft.ReportingServices.OnDemandProcessing.RuntimeDataSource.OpenConnection(DataSource dataSourceObj, DataSet dataSetObj, OnDemandProcessingContext pc, DataProcessingMetrics metrics)
Since this pointed to a permissions issue, my natural instinct was to grab a Process Monitor trace. Unfortunately, Process Monitor neither showed that there were any Access Denied errors, or even any attempts to hit a path to that assembly, ‘Microsoft.ReportingServices.SemanticQueryEngine’.
The location to that assembly is here in SharePoint 2013:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\WebServices\Reporting\bin\Microsoft.ReportingServices.SemanticQueryEngine.dll
Even with Full Control to that path for Everyone, we’re still failing.
We could stop and start the SSRS Service Application without issues, so we know that the SSRS account permissions were valid. So what was the issue?
As we were failing for every report execution, it couldn’t have been a data source issue, unless every one of those data source permissions were faulty, which is unlikely. We could verify permissions for the user account easily by running any program as a different user.
My only other thought was to check the Execution Account. Once we deleted the Reporting Services Execution Account from the configuration in Central Administration, all reports started working.
Now, I have run into errors with using Execution Accounts more often than I would like. It is used for unattended executions like Subscriptions to retrieve image files from remote servers. This is rare, as I have never once seen a use for it, but I have seen plenty of times that this will give a login error. Either due to changes in the account, or a break in the permission chain somewhere in the application. So if you see these errors, try removing the Execution Account from the configuration.