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!
Unfortunately this did not work for me. I’m running Project 2007 Server sp2 on top of MOSS 2007 Enterprise sp2 on one VMware ESX 4.1 virtual server (guest OS is 64-bit Windows 2008 sp2) with SQL 2008 R2 as the backend on another virtual server (guest OS also 64-bit Windows 2008 sp2). I’ve followed every piece of advice I could find on technet, MSDN BLOGs, etc., and I still get the same “Error: Your permissions on the server computer do not allow you to administer this Analysis server”. I even gave the SSP, App Pool, and Farm domain accounts full rights on the OLAP directory on the drive where SSAS is installed…to no avail. I’ve done the build process successfully before on Windows 2003, so I suspect that there is a security issue on Windows 2008 as you have surmised. The Analysis Repository DB is on the SQL 2008 R2 box, not in an MS Access DB in a “DSO” directory, so I followed the steps for the “1st option” (to use SQL Server). If you have any ideas please feel free to share.
Thanks!
I feel your pain on that one, on most large 2007 deployments on Windows 2008 I had similar issues, hence the blog above.
It’s been a while now but I do recall the key was with access to that C:MSOLAP.UPD file (or D: if that’s where SSAS is installed, etc), if you’ve tried my suggestion above then perhaps using Sys Internals PROCMON on the SQL server will answer the question of what is attempting and failing on that server. I do recall PROCMON would specifically show the failed access requests by the Project Server.
In my previous experience that was the last resort that eventually led me to the cause of this issue in most cases.
Martin