RG01A – How to fix local cache error (updated 04-Dec-2009)
Here’s a solution to an annoying little problem which has been bugging more than a few people out there recently. This was originally posted in the Guru’s Forum but it seemed to make sense to make an article out of it. Here’s the skinny: You’ve just installed Workspace Manager 2008 for the first time and everything seems hunky-dory in the console. Then you try to log into a session as a user and get this little number (click it to enlarge):
It’s your credentials on the RES service which needs to be tweaked. We’ll show you how further down. For the benefit of the search engines, here’s the error message in text ; “Locally cached RES Workspace Manager settings were not found. Please contact your administrator. Workspace Manager cannot continue“. There is a KB article on this problem but it only says to try to reboot the machine. From practical experience in the field there may be another way to deal with this problem:
The problem may arise if you are using a SQL server with Windows Authentication only. Per default, the RES 
Workspace Manager agent service runs on each computer using LocalSystem credentials. That means the service would be unable to connect to the datastore, hence pull down a cached copy of the config data in the datastore. You can check if this is the case, by navigating to %programfiles%RES Workspace ManagerDataDBcache. Normally you should see the 4 folders as shown on the right.
If you only see the Transactions folder then, try the following:
- Start your Services control panel (services.msc) and edit the properties of the RES Workspace Manager service.
- On the Logon tab, change the Logon As to This Account and enter a valid domain account which has credentials to access the SQL database
- Restart the RES Workspace Manager service
The service configuration should look something like this, when you’re done:
Once the service has been restarted, you should see the additional folders start to appear in the DBcache folder. If not, then something more spooky is going on. Call Ghostbusters! :)
If the above solution works for you, but you need to change it on multiple target machines, here’s a building block for Wisdom which will do it for you. It will prompt you for the new credentials which the RES service should run with, and bounce it automagically.
Click here to download the Wisdom buildingblock: 
There is another likely reason why you are getting this error: You may have forgotten to configure a database connection on the target computer. Granted, it sounds kinda daft, but suppose you’ve just set up a new lab environment and you’ve installed Workspace Manager manually on a target computer. I emphasise manually, as you would normally not have this problem if you are doing an unattended setup. In order to finalize the manual installation you need to fire up the Workspace Manager console and configure the datastore connection (host, db, credentials, etc.). If you forgot this step and just set the shell to Workspace Manager and log in, you will also get the above error
Finally, you may want to have a look at RES KB article Q201762, which also have some solutions to this issue. Note, this article may require you to login with your SA credentials.
RESguru | 
April 26, 2009 18:18
Subscribe
By Airdeca, May 1, 2009 @ 08:12
Should you choose to use the RES Wisdom Building Block be sure to assign the ‘Log on as a service’ User Right to the domain user account manually because RES Wisdom doesn’t do that automatically (yet).
By RESguru, May 3, 2009 @ 20:24
Good one! Thanks for the update. Agree, it would be cool if Wisdom could do the rights assignment business, now that it does AD wrangeling anyway.
By Marcel, November 19, 2009 @ 06:56
If you don’t have Wisdom (shame on you!) you can also use this VBS script :
Option Explicit
Dim objWMIService, colServiceList, objService
Dim strComputer, strUser, strPassword, errReturn
strComputer = “.”
strUser = “TRAINING\Administrator”
strPassword = “password”
Set objWMIService = GetObject(“winmgmts:” & “{impersonationLevel=impersonate}!\\” & strComputer & “\root\cimv2″)
Set colServiceList = objWMIService.ExecQuery (“Select * from Win32_Service”)
For Each objservice in colServiceList
If objService.Displayname = “RES PowerFuse” Then
‘ Change service parameters
errReturn = objService.Change( , , , , , ,strUser, strPassword)
‘ Stop service
errReturn = objService.StopService
‘ start service
errReturn = objService.StartService
End If
Next
By Jeroen, May 16, 2011 @ 07:01
I have this exact same problem in a small 1 server – 1 client testing environment, although the fix in this article didn’t do the trick for me.
I already have those four folders in C:\Program Files\RES PowerFuse\Data\ and the credentials were already set correctly. Also the machine which has this problem is already connected with the datastore on the server. It used to work, but all of a sudden it doesn’t…
Any other thoughts which could help solve this problem?
Thanks in advance!
By RESguru, May 16, 2011 @ 10:34
Hi Jeroen, there are now 4 other cause/solutions in the RES KB article Q201762. Have you tried those? If not you may have found something we haven’t thought of. In that case please reach out to the merry folks at RES support. I’m sure they will be glad to help you find a solution to your problem.
Cheers,
Max