A user complained that PerformancePoint was not configured correctly.
“See? SharePoint told me so!”
You check the logs and find this on the application server running the PerformancePoint service.
And corresponding in the SharePoint ULS log on the same server.
The user "DOMAIN\User" attempted to access an item in the following location: http: //SharePointServer/Data Connections for PerformancePoint/1_.000
Verify that the location exists and that the user has the "Read Items" permission.
Exception details: Microsoft.PerformancePoint.Scorecards.BpmException: The item 'http://SharePointServer/Data Connections for PerformancePoint/DataSource.rsds' is not a valid PerformancePoint Data Source. Check to make sure the content type of this item is correct.
However you can also find things related to Claims to Windows Token Service in ULS log.
SPSecurityContext.WindowsIdentity: Could not retrieve a valid windows identity for NTName='DOMAIN\User', UPN='User@DOMAIN'. UPN is required when Kerberos constrained delegation is used. Exception: System.ArgumentException: Token cannot be zero.
The following data source cannot be used because PerformancePoint Services is not configured correctly.
Data source location: http: //SharePointServer/Data Connections for PerformancePoint/5_.000 Data source name: New Data Source
Monitoring Service was unable to retrieve a Windows identity for "DOMAIN\User".
Verify that the web application authentication provider in SharePoint Central Administration is the default windows Negotiate or Kerberos provider.
If the user does not have a valid active directory account the data source will need to be configured to use the unattended service account for the user to access this data.
The best hint at the gremlin in the system is the error “Token cannot be zero” from the Claims to Windows Token service. The SharePoint system attempts to change the claims token to a windows token, but the service is just returning null. Basically this is a permissions error for the Claims to Windows Token Service identity.
If you read the SharePoint 2010 Kerberos Guide, particularly the chapter on configuring PerformancePoint, you would understand that there is a relationship between PerformancePoint and Claims to Windows Token Service. Too bad it doesn’t tell you how to fight system gremlins, but not to worry… that’s why I’m here.
The domain account you are using needs a few things to be able to successfully run the Claims to Windows Token service.
- Local administrator on the application server running PerformancePoint
And in Local Security Policy (secpol.msc)
- Act as part of the operating system
- Impersonate a client after authentication
- Log on as a service (the service account will probably already be here if it is running a service)
I found two gotchas in this particular environment.
- Windows group policy removed the Claims to Windows Token service account from local administrator. Contact your friendly Windows/Active Directory administrator for assistance on this.
- After the permissions are applied the Claims to Windows Token service account needs to be restarted in order to apply the permissions. If you do not restart the service, your user will still be getting the error message!
Shnuggets 