Advertisement

SCCM 2012 R2 Upgrade Breaks 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 .

About Author 

Anoop is Microsoft MVP and Veeam Vanguard ! He is a Solution Architect on enterprise client management with more than 13 years of experience (calculation done on the year 2014) in IT. He is Blogger, Speaker and Local User Group Community leader. His main focus is on Device Management technologies like SCCM 2012,Current Branch, Intune. He writes about the technologies like SCCM, SCOM, Windows 10, Azure AD, Microsoft Intune, RMS, Hyper-V etc...

    Find more about me on:
  • googleplus
  • twitter
  • facebook
  • linkedin
  • youtube
Posted in: CM2012, ConfigMgr (SCCM), SCCM 2012, SCCM 2012 R2, System Center 2012 Configuration Manager