10.1.600.3 Auto Update Error

Hello,

I’m wondering if anyone is getting this error when the auto update occurs? No, the client is not open. I have to manually delete the cache folder (C:\ProgramData\Epicor\ServerName) in order to make the update work.

Happened to me as well for the .3 update – I would run the Epicor shortcut as administrator and it would update – seems to be fixed in later releases

This has to do with a BOSecMRUList.xml file, I believe. I remember this error in Epicor 9. I would look at securities for this folder. The file should be like BORUList_John.Doe.xml. Check the users Epicor folder on his computer. Make sure the user has full rights.

Keep us informed.

Jonathan

Your .sysconfig file is set to clear the client cache during the update, which by default is a Windows managed location and requires elevation.

A few ways to approach this:

  1. disable the clearing of client cache with every update by changing the clearDNS value to Never from always in the client sysconfig. NOT RECOMMENDED TO DO BECAUSE I ADVOCATED FOR SO LONG TO GET THIS INCLUDED AND I’M REALLY REALLY REALLY BIASED
  2. Specify an AlternativeCacheFolder location that isn’t in a Windows managed location e.g. c:\programdata, c:\program files / c:\program files (x86). C:\epicor\clientcache is a nice location for those that install the client on C and has already granted the end users the appropriate access rights to the Epicor client folder. NOTE: you can include Windows variables in the path.

Configurations that should allow the client to autoupdate without admin rights on the Windows client machine (all of the below need to be setup) as of 10.1.600.5:

  • The Client folder is not under a Windows managed folder structure and the user has read/write permissions to the client folder structure.
  • The AlternateCacheFolder is specified and does not resolve to a Windows managed folder and the user has read/write permissions to the folder structure.
  • The optimizeAssemblies node specified in the client sysconfig file is set to false.

.

3 Likes

We had the same type of issue in E9 if the IT admin team did the install and did not give domain users write access.

If you delete the folder as an admin and then open Epicor as a user then the user owns the directory and can write to the folder.

Greg

Thanks for the nice explanation Nate!