I was testing reports for SQL Server Reporting Services on a new computer, but the results were blank and no relevant error messages were logged by SSRS.
Investigated by using procdump to log exception messages from the IIS worker process with:
procdump.exe -f "" -l -e 1 ReportingServicesService.exe
Part of the result was:
[13:22:13] Exception: E0434F4D.System.Security.SecurityException ("Request for the permission of type 'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.")
[13:22:13] Exception: E0434F4D.System.Security.SecurityException ("Request for the permission of type 'System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed.")
I knew that the reports performed HTTP/web service calls from VB code, so I had to modify rssrvpolicy.config to allow this.
It can be done by:
1. Appending a named permission set with both execution and web permission like:
<PermissionSet class="NamedPermissionSet"
version="1"
Name="ExecutionAndWebPermission"
Description="A special permission set that grants execution and web permission for specific site(s).">
<IPermission class="SecurityPermission" version="1" Flags="Execution" />
<IPermission class="WebPermission" version="1">
<ConnectAccess>
<URI uri="http://localhost/Test/ReportingUtilityService.svc"/>
</ConnectAccess>
</IPermission>
</PermissionSet>
2. Modifying the CodeGroup with Name=”Report_Expressions_Default_Permissions”
From:
PermissionSetName="Execution"
To:
PermissionSetName="ExecutionAndWebPermission"
3. Restarting Reporting Services.
I decided to verify that this was the issue before performing the changes.
Therefore I attached WinDbg (x64) to ReportingServicesService.exe and configured event filters to break on CLR exceptions.
Refreshed the report again and the first exception was thrown.
Checked the exception with:
!PrintException
The result was a very detailed (and useful) message, that confirmed the suspected issue:
Exception object: 0000000460198410 Exception type: System.Security.SecurityException Message: Request for the permission of type 'System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' failed. InnerException: <none> StackTrace (generated): <none> StackTraceString: <none> HResult: 8013150a SecurityException Message: The action that failed was: Demand The type of the first permission that failed was: System.Net.WebPermission The first permission that failed was: <IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1"> <ConnectAccess> <URI uri="http://localhost/Test/ReportingUtilityService\.svc"/> </ConnectAccess> </IPermission> The demand was for: <IPermission class="System.Net.WebPermission, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1"> <ConnectAccess> <URI uri="http://localhost/Test/ReportingUtilityService\.svc"/> </ConnectAccess> </IPermission> The granted set of the failing assembly was: <PermissionSet class="System.Security.PermissionSet" version="1"> <IPermission class="System.Security.Permissions.SecurityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Flags="Execution"/> <IPermission class="System.Security.Permissions.StrongNameIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" PublicKeyBlob="..." Name="expression_host_..." AssemblyVersion="1.0.0.0"/> <IPermission class="System.Security.Permissions.ZoneIdentityPermission, mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" version="1" Zone="MyComputer"/> </PermissionSet> The assembly or AppDomain that failed was: expression_host_..., Version=12.2.6020.0, Culture=neutral, PublicKeyToken=null The method that caused the failure was: System.Object CallWebService(System.String, System.String) The Zone of the assembly that failed was: MyComputer
After modifying rssrvpolicy.config and restarting Reporting Services the issue was resolved.