Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

I've got a SharePoint 2010 Enterprise multi-tenant setup integrated with a new SSRS 2008 R2 instance in SharePoint-Integrated mode and have FINALLY managed to get everything working. However, there seems to be a major limitation I'm hoping someone here could figure a (better) workaround for.

I use BIDS to publish all of my reports to the sites, (it errors during publishing but uploads the reports anyways), I get this error trying to access any of them on the SharePoint site:

Report Server has encountered a SharePoint error. ---> Microsoft.ReportingServices.Diagnostics.Utilities.SharePointException: Report Server has encountered a SharePoint error. ---> Microsoft.SharePoint.SPException: Access denied.

You do not have permission to perform this action or access this resource. ---> System.Exception: For more information about this error navigate to the report server on the local server machine, or enable remote errors

This is because I've set the UserAccountDirectoryPath so that the client can only see people from their OU. Since the SSRS service account isn't in that client's OU it doesn't see the account as being valid and gives an access denied error.

Here's my temporary hack:

  • Move the reporting service account into the tenant's OU.
  • Load a report or the data source from SharePoint...everything works!
  • Remove the reporting service account from the tenant's OU and it still works!

My second hack:

  • Remove the UserAccountDirectoryPath.
  • Load a report or data source definition from SharePoint.
  • Add the UserAccountDirectoryPath back in.

There must be someone out there who uses SSRS with the UserAccountDirectoryPath attribute.

How do you get the site to recognize the SSRS service account, why does it need to in the first place, and why does it still work after adding the OU path restriction back in??

UPDATE: I've decided to just remove the UserAccountDirectoryPath. We are managing the user accounts anyways so it's just causing more problems than it's worth.

share|improve this question
    
AD uses a weird form of caching - I don't fully understand it myself but I know if you do something that changes the schema, and something accesses it using that schema, and another change happens, there's some delay before the second change takes effect. –  James Love May 24 '13 at 16:36

1 Answer 1

Do this in PowerShell:

$w = Get-SPWebApplication http://yourwebapp
$w.GrantAccessToProcessIdentity("DOMAIN\SSRSServiceAccount")

That's it. Every time I've gotten a "RS has encountered a SharePoint Error" this has resolved it.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.