Can you have both the prior version and the updated version of the Client on the same machine?
I’ve installed Update 10.1.400.23, have re-deployed our UAT (Test App) to use version 23, and left our Live company App at version .19.
When I launched the UAT company on my workstation, the client files were updated. After closing the UAT, and relaunching the Live company, the client files were updated again (I presume back to Rev .19).
Our users run the Client via a Citrix-like Web App (Not the Epicor Web Acces extension). If they were to launch the UAT, wouldn’t update the client files on the WebApp server?
And if someone else launched the Live company, wouldn’t that overwrite the client files again?
Hmmm … The regular users run the client via the remote app, which is running on the server hosting Epicor. Which seems to already divide the client files up by App instance.
So really nothing to do for them? I should just launch the UAT on the App Server, and then just the UAT client files will be updated?
aidacra
(Nathan your friendly neighborhood Support Engineer)
7
If all of your appservers on UAT are on the same Epicor version, just need to launch the shortcut from that server.
HIGH-LEVEL CLIENT INSTALL MECHANICS:
As of this moment (10.1.500.7/10.1.400.23) the Epicor on-premise client installer drops the client files into the same folder for all appservers on the same Epicor IIS website server regardless of whether or not the appserver processes are on the same Epicor version or not. That could present some admin issues if you wanted to have a production appserver at say 10.1.400.20, and a test appserver 10.1.400.22 by creating an appserver on that same production server - your end users would trigger an autoupdate every time they changed between live and test.
Takeaway: if someone wishes to use the standard Epicor on-premise client installer, all appservers on the same Windows servers should really be at exactly the same Epicor version to prevent this autoupdate behavior.
Bonus round: There is a long standing SCR to have one client install per appserver process to prevent this behavior but the downside is that each client folder would be ~1GB - that is the reason why this wasn’t implemented initially.
aidacra
(Nathan your friendly neighborhood Support Engineer)
8
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, …)
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.
