views:

654

answers:

1

Hi,

I've got a rendering extension for reporting services which uses the ReportExecution2005.asmx service to execute a number of "subreports" and then puts the results in a powerpoint presentation.

A typical usage scenario would be to go to the Report Manager, select my "Powerpoint" report, which is used only as a placeholder for parameters to be passed to the "subreports". I then select my extension from the list of export formats and click Export, which runs the extension and it gives me back my pptx file.

This works fine on both our live and test servers. But I've run into a very weird problem trying to set up another test server.

Any call made by the extension to the webservice returns with "401 Access Denied" (no further substatus information available).

Things I've tried without success: - allow physical access to the folder structure of the ReportServer virtual directory to everyone. And I mean literally everyone - ASPNET, NETWORK SERVICE, Everyone, the account I usually use to log in, which is an admin and owner of the folder - use reporting manager to set up the security on the reporting services side. Again, every conceivable user/group account which could be involved was given every conceivable role. - allow anonymous access to the ReportServer web app. - enabled impersonation on the ReportServer web app. - hardcoded the user credentials to use when calling the webservice (by default it just uses System.Net.CredentialCache.DefaultCredentials)

I also made a little test website which consumes the ReportExecution service in exactly the same way as the RenderingExtension, and from the website, the web server authenticates fine and allows me to call the web service, so obviously the problem doesn't lie with the web service security setup itself.

Starting to pull my hair out. As a last resort, I'm about to reinstal Reporting Services, but in the mean time (or if that doesn't help) - if anyone has encountered something similar, I'd greatly appreciate any input.

A: 

Hi,

I have seen similar behavior when migrating an ASP.NET project which called the ReportExecution2005 web service. When running on my local box, everything was Ok. When I migrated it to our development server, I started getting 401 errors. In our case, Kerberos needed to be configured on the development server to delegate credentials to the SSRS box.

You might want to verify that the new server will delegate it's credentials to the SSRS machine and see if that makes any difference.

Hope this helps,

Bill

Bill Mueller