SCCM Upgrade Breaks SSRS with UserTokenSIDs contains an error

SSRS with UserTokenSIDs contains an error
SSRS with UserTokenSIDs contains an error

Recently, We had a discussion in Facebook Group for SCCM ConfigMgr Professionals about SSRS reporting  issue after upgrading from SCCM 2012 SP1 to R2. Some of group members are reported the following  issue / error. However, I didn’t find this issue in any of my environments (I’ve 3 different environments) and the SSRS reports are working fine after ConfigMgr 2012 R2 upgrades. So I don’t know the exact reason for the following error in some environment.

System.Web.Services.Protocols.SoapException: The DefaultValue expression for the report parameter ‘UserTokenSIDs’ contains an error: Logon failure: unknown user name or bad password. 

Initially I suspected that there is something to do with  Domain functional level and Forest functional level. Tested the same with different functional levels Windows Server 2008 2 and Windows Server 2003. For both functional levels, it worked fine for me.

After some “RE search”, I found some interesting update done on SCCM 2012 R2 Configuration Manager Documentation Library @ November 2013. Also, technet page has been updated with new prerequisites for SCCM 2012 R2 SSRS report  service account. The SSRS service account should be the member of Windows Authorization Access (WAA) group and Read tokenGroupsGlobalAndUniversal allow permissions. More details @ technet page “To install the reporting services point on a site system“.

Added a note that the account that runs Reporting Services must belong to the domain local security groupWindows Authorization Access Group, and have the Read tokenGroupsGlobalAndUniversal permission set toAllow.

When you’ve SSRS related issue, you should try adding the above mentioned group and security settings. If that is not solving the issue, you can try something which is mentioned in the following technet thread.  Detailed discussion about SCCM 2012 R2 SSRS issue here.

Extract from technet forum :- Some interesting stuff  In our environment, we run all SQL services as a separate account, say domain\CMSQLSERVICE account (so if you looked at the services, you’d see SQL Server, SQL Server Agent & SQL Server Reporting Services all running as CMSQLSERVICE). We also run reporting as another account, say domain\CMSQLREPORTING account (SCCM console, Admin, Site Config, Servers & Sites, Reporting services point). Placing CMSQLREPORTING account into the Windows Authorization Access Group did not resolve the issue as I had thought. We then placed CMSQLSERVICE account in there & everything worked as intended.

You’ll be able to easily see the errors by looking on the reporting point / server with the SQL database for C:\Users\ACCOUNTRUNNINGSQLSERVICE\AppData\Local\Temp .


Please enter your comment!
Please enter your name here

This site uses Akismet to reduce spam. Learn how your comment data is processed.