As an aside, other considerations when publishing a shortcut on a server that will be accessed by more than one user (Citrix, RemoteApp, RDS server, …)
-
Make sure to use alternate client cache.
By default, all users share the same client cache location. On a shared machine, the alternate client cache should be used to “unique-ify” the folder structure so every user has their own cache folder. We allow the use of Windows global variables so you can make the cache folders unique per Windows user which is my preference. This will avoid a number of issues; trust me. -
Autoupdate should be disabled for all published shortcuts for users who aren’t local admins.
In 10.1.600 we are planning a rewrite of the autoupdate process to not require a user be a local admin, but, even when that happens, this recommendation would still hold in this use case. Autoupdate can’t succeed when there is any user who has a client session launched on that machine and in a RemoteApp/RDS server situation, the autoupdate can’t/won’t force all of those sessions to terminate on that server.
NOTE: there are ways around triggering the autoupdate without being a local admin, but, it involves disabling UAC and some other less than ideal security changes on the server so I really wouldn’t recommend trying to work around it.
Recommendation on updating this clients then? Well, one could do something like one of following(notify your users before this happens please and thank you):
- Publish a shortcut for just admins pointing to a batch file (or your scripting mechanism of choice). In said script, issue a taskkill /f /im epicor* and afterwards trigger an autoupdate by calling c:[pathtoclient]\epicor.exe /config=[pathtoclient]/config/[appservername].sysconfig /update
OR
- Create your own “push” client update script that moves the updated client files from the Epicor server to the RemoteApp server after applying an update. Still have to take into account users having client files locked on the server.