Hi Guys,
We recently upgraded to 10.2.600 and tested the client upgrade again. When we upgraded to 10.2.500 some clients required elevated rights and we could not determine why. With 600 it seems to be the same issue.
The user has modify rights on the client folder but still they are being prompted for elevation. Do they need full rights or is there something else that could be causing the client to require elevated rights?
Starting several releases ago, the Client is supposed to tell you “why” it needs elevated permissions when it is asking for them. In order to do that, the upgrade process has to try a number of operations prior to actually doing the upgrade. If the process is not telling you “why” it needs additional rights, please place a call with Tech Support and provide the full details.
Thanks for the feedback. That is also as I had it.
I also found this article, KB0050644, which actually hit the nail on the head. It seems like the cache folder is in a Windows managed folder and therefore it needed elevated rights to upgrade. I entered a value, “%appdata%”, in the AlternateCacheFolder which should make the difference.
%appdata% is still a Windows Managed folder.
The Client Cache Folder and needing elevated permissions on upgrade relate to the location and shared environments. For the location, move it from the default to a location that is not Windows managed. For a shared environment, make sure an element of the cache folder is tied to the Windows User ID.
The default Client Cache folder location was selected in the Windows XP days before UAC and was designed for a single user or for a shared system with only a single user at a time. The location was actually Microsoft specified if you applied for the “Certified for Windows” logo (which Epicor applied for and received).
The AlternateCacheFolder node came into being due to issues with Shared environments - term servers, Citrix - where multiple simultaneous client instances could exist and shared cache folders and files did not work too well.
Thanks for the feedback Richard. I did some testing and it seems like the %appdata% path works and does not cause the upgrade to require admin rights. If I run into further problems I will try move this to another non-Windows managed folder.