Client deployment questions

Epicor ERP 10
1
  1. The new Install Guide says to launch the setup program from
\\<server>\Epicor\ERP10\ERP10.2.300.0\ClientDeployment\ClientInstaller

But there is also an installer in the updates directory

\\<server>\Epicor\ERP10\ERP10.2.300.0\Updates\ERP10.2.300.23\ClientDeployment\ClientInstaller

But if you choose the one with the updates path, you get:

image

Now I could change the share location in the installer window, by removing \Updates\ERP10.2.300.23 from the path, and it installs just fine.

So is there a difference between the installers?

  1. When installing the client on a workstation, youā€™re always given the option for an install with ā€œAUTO_ā€ prepended to the App name. Like:

image

the only diff in the sysconfig files is the line

    <deploymentType value="zip" options="xcopy|zip" />

vs

    <deploymentType value="auto" options="xcopy|zip" />

I assume they have to do with how the client gets updated.

Whatā€™s the difference, and which one should users run regularly?

1 Like
2

Iā€™m fairly certain the ClientDeployment folder contains the executable program for a first time installation.
Users donā€™t need to run anything regularly; If an update is applied to the App Servers, the client software (during regular sign-on) will automatically download ONLY those updated files required to get to the new version. So thatā€™s the functional difference.
Regarding the technical reasoning behind the folder structure/naming convention, I havenā€™t had a need to decipherā€¦ others may have.
I imagine this is significant if youā€™re trying to push updates out to clients as opposed to the built-in mechanism of updates on-demand/at sign-on.

3

My initial concern about which ClientDeployment\ClientInstaller to use was that Iā€™m doing a new install of 10.2.300, and part of the setup is to install the updates (to 10.2.300.23), prior to the initial pushout out of the client.

And anything difinitive on the deploymentType value="zip" vs "auto" ??

A guess would be whether the updates are pushed down, file-by-file, vs pushing the ZIP file to the client and doing the unzipping locally.

4

Iā€™m a bit out of my depth here - particularly with the contents of the config files. However, Iā€™ll share my experience with many upgrades and installations. Youā€™re aware the update is performed at the server, then when the client logs in, it downloads only the needed files - file by file. The only time Iā€™ve ever seen a zip file being transferred to the client, is during the initial installation of the client software.

I canā€™t recall which version it was, but going from one update to another caused the client to copy updated files for 2 or 3 minutes, while the initial installation is usually 10 minutes or more (on my network, my PC configurations).

I sense you are planning something quite a bit more elaborate than Iā€™ve done here, so I have no tips on pre-loading client software.

We recently went to .400 and I opted to perform a complete re-installation - server and clients, as was renaming App servers to names that would be meaningful and independent of version numbers (no more E10 server after we migrate to E11). Now its just Live, Test, Train, and Pilot.

For this exercise, I performed my installation on a separate server and installed the client software on all PCs. At switchover, a login scripts copied the appropriate Icons (shortcuts) to the desktops and off we went.

1 Like
5

It actually sounds like weā€™re doing the same thing.

Currently:

  • Version 10.1.400 installed between two boxes
    • AppSrv1(Win 2012 R2)
    • SQLSrv1(Win 2012 R2 / SQL 2014)
  • (2) Apps deployed
    • LIVE (for production)
    • UAT (for testing)
  • both Apps share the same SSRS settings (RDL locations, Report DB, etcā€¦)
  • both Apps share the same client installation

The goal is:

  • Upgrade to 10.2.300, on new servers
    • AppSrv2(Win 2016)
    • SQLSrv2(Win 2016 / SQL 2016)
  • Have (3) Apps
    • PRD_102300 - Production
    • UAT_102300 - User Acceptance Testing - for users to test customizations and update prior to full scale deployment
    • TST_102300 - Development environment
  • Separating SSRS by App (each App will have its own directory for reports)
  • Separating Client installations by App (each App will have its own directory for client files)
    • C:\Epicor\ERP10.1Client\PRD
    • C:\Epicor\ERP10.1Client\UAT
    • C:\Epicor\ERP10.1Client\TST

But Iā€™m starting to wonder about the value of separating the SSRS and client installation stuff.

Iā€™m the only one that would ever be in the TST_102300 App, and most users would rarely ever need to use the UTA_102300 App. And when they did, I could just tell them they should not be in it while they have PRD open.

6

One thing I always do, is to make an Environment specific theme and set it as the default

The Green and Orange really standout to let people know theyā€™re not in the live DB

image
image.png846Ɨ426 36.1 KB

And that color appears on all forms.

Hereā€™s the ISL file for the green one.

UAT.isl (33.3 KB)

7

Thatā€™s pretty cool. We have multiple Companies, so I use a different color scheme for that oft-occuring situation. My users are rarely in multiple environments, although I encourage the use of Test. And no one wants to spend any time in Train - weā€™ve customized heavily, so much of the basic training material in not applicable.

1 Like
8

I only thought about making separate folders for the files on the client, because there could be times when the UAT environment was updated (like after updating from 10.2.300.23 to .28), and Iā€™m concerned that the client files might not cooperate between two different versions.

9

Its a good thoughtā€¦ but I donā€™t know if you can update the server from .23 to .28, discover a problem on the client side, and choose to run a .23 client. My experience tells me that it will attempt an update of the client whenever it finds a version discrepancy.

The only folder separation Iā€™ve done is as follows:

  1. Epicor wants to install the client in C:\Epicor\ERP10.2Client
    Iā€™d like to make this default folder available to the NEW installation, soā€¦

  2. I renamed the existing client folder to C:\Epicor\ERP10.2.200Client\

  3. I had to update the existing shortcuts:
    C:\Epicor\ERP10.2.200Client\Client\Epicor.exe /config=Epicor10.sysconfig

  4. Then I installed 10.2.400. which installed into the default ERP10.2Client folder.

The two lived side by side, until I was ready to transition the company at which point I switched shortcuts on every desktop via login script.

*** OOOOhhhh!!! You mean you might want one environment (Test) to be on a different version.
Good point. In that case, you would definitely want separate installation folders. Accommodate by updating the shortcut to point to the appropriate environment folder - as youā€™ve shown. Thatā€™s a great idea.

10

This is exactly what Epicor SaaS does. Within the Epicor folder, there is a folder for each environment. In our case, there is only ever two versions on our system. Live is always the current version and Pilot may contain a newer patch/upgrade version for UAT. Like @Andrew mentioned, we have short-cuts for each environment.

1 Like
11

I have a ā€˜discovery callā€™ tomorrow with my CAM to start gathering info for the push I intend to make towards SaaS. Iā€™m hoping he can turn me loose on a Test or Demo site, so I can start collecting info I can use to advocate for a move to SaaS. Techie benefits like folder/environment separation wonā€™t help me in said advocacy (mgmt wonā€™t be as impressed as I am), but I sure do like it!

12

A ,23 to .28 update doesnā€™t change everything on the app server. And you can have the different Apps/environments running at different .xx versions. You choose the version in App Configuration

image

So it is quite possible (and normal) to have app PRD running on 10.2.300.23, and app TST running on 10.2.300.28.

13

Yep. totally understood. I belatedly understood your intent to run different versions.