by Martin Laukkanen | Sep 3, 2011 | Project 2010, Troubleshooting
A customer of mine had this one after completing the upgrade to SP1 recently, basically all cube building would fail with the following error:
Your CBSRequest job failed. Its current state is FailedNotBlocking. It was 0% complete. It entered the queue at 09/02/2011 11:00:26.
[snip…]
The errors returned from the queue are as follows:
Error ID: 17007
Error ID: 26000
[snip…]
<class name="CBS message processor failed">
<error id="17007" name="CBSOlapDatabaseSetupFailure" uid="7d14c29d-a133-492b-baea-2e7c0bec444b" QueueMessageBody="Setting UID=00007829-4392-48b3-b533-5a5a4797e3c9 ASServerName=server ASDBName=FullCube1 ASExtraNetAddress= RangeChoice=0 PastNum=1 PastUnit=0 NextNum=1 NextUnit=0 FromDate=01/04/2010 00:00:00 ToDate=12/31/2011 00:00:00 HighPriority=True" Error="Error Setting Olap Database ‘FullCube1’ roles: Error: This method can only convert identity claims, and only when a logical conversion exists.
Parameter name: encodedClaim" />
This customer is using Claims-NTLM (ie AD users via Claims) for logins and that seems to be the cause of this issue. The give away is clearly in the error: “This method can only convert identity claims”.
Solution
Fortunately the solution turned out to be rather simple, it seems that SP1 does some additional checking when setting up the Cube Roles, as a result when users in the Project Server have issues then this error is caused.
A little more info can be seen in the ULS log:
09/02/2011 12:00:33.18 Microsoft.Office.Project.Server (0x17B0) 0x1A04 SharePoint Foundation Claims Authentication d01p Medium ConvertWindowsClaimToWindowsPrincipalName() encountered error: Some or all identity references could not be translated.
As it turns out a number of users in PWA have left the company and in this case as no AD-sync is used some of the accounts had been deleted from Active Directory but not updated in PWA server settings.
It seems also that accounts set as “inactive” also caused this error if they were in a group with the Global “View OLAP Cubes” permission.
The fix was to remove those user accounts from the PWA groups ‘Project Managers’, ‘Portfolio Managers’ and ‘Executives’ (and any others with the above permission).
Finally I just tested this in a non-Claims lab, and the problem doesn’t occur, in fact the cube log identifies and lists the invalid account then continues processing, so technically I would call this one a code defect.
Hope that helps someone else out there!
by Martin Laukkanen | Jan 26, 2010 | Project 2007, Reporting, Troubleshooting
On a number of occasions I have had problems with this particular file, worse still there doesn’t seem to be much official information on it available. The file is MSOLAP.UPD located in the root folder of the drive on which SQL Analysis Services (SSAS) is installed, the file does not exist usually and is not created during setup, however when a cube is built the file will be temporarily created and then removed. If you run a ProcMon you will see this everytime.
The problem occurs with Windows 2008 in which new security features restrict access to files in the root folders such as C: or D: which results in errors in the cube build.
Specifically:
“Error: Your permissions on the server computer do not allow you to administer this Analysis server.”
Typically this will occur when the Windows 2008 SSAS server is different to the Project Application Server, as you may imagine a remote process initiated from the App server accessing files in the root folder on the Windows 2008 drive.
The problem is exacerbated in large deployments when best practice security is used and the Project Server service account is different from both the SSP account and the MOSS Project Web Application Pool identity.
The solution I have found is a rather simple hack, basically pre-create the MSOLAP.UPD file in the root folder of the server drive where SSAS is installed, and ensure that the following three accounts have full permissions:
- MOSS PWA Web Site Application Pool identity
- Project Server Service Account (the account that runs the Queue Windows service)
- SSP Service account
AFAIK the first is the one used by the ProjectServerOlapCubeGenerator.exe to touch the MSOLAP.UPD file, so start with that if you need to.
Otherwise with that error message above the following should be taken into account:
The accounts used for building Cube include the SSP IIS Application Pool Account and the SSP service account.
- SSP Service account is used to connect to Analysis Services and trigger the cube build work, requiring access to the Repository, etc
- App Pool account is used to launch the ProjectServerOlapCubeGenerator.exe process which runs on the app server but also appears to remotely connect to the SSAS server. (need to confirm this)
- Finally the Project Server Service Account needs to be an SSAS admin.
Hope this post helps someone out there as I have often had this issue in large deployments and for a long time have done the above steps without even thinking twice about it!
