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.