E10 Client Upgrade Woes (How to upgrade major versions)

Experts' Corner
,
1

We’re working on upgrading our pre-production environment from 10.2.200.x to 10.2.300.x

In doing so, we’ve noticed that nothing changes on the server to allow existing deployed 10.2.200 clients to upgrade to 10.2.300.

How are you folks handling this?

We figured out that we could do 1 of 2 things:

  1. Deploy a new sysconfig file at every workstation that changes the DeploymentServer to the new share for 10.2.300
  2. Change the sysconfig in the 10.2.200 deployment share to reference the 10.2.300 share. This will mean every client will potentially update twice… Once to pull the new sysconfig from 10.2.200 and again for a new sysconfig at 10.2.300

I had hoped the client upgrade would be more seamless than this, so I guess we’re hoping we did something wrong?

2

Replace the 10.2.200 SysConfig files in the \10.2.200 deploymentDeploymentFolder with those from the 10.2.300 SysConfigFiles as long as the actual app server names are the same…

That should do it,it’ll download the new sysconfigs which are pointing to the new deployment place then it’ll go get the right stuff from the right place.
That’s how we did it works fine and it doesn’t cause a double download.
(test it out before going into production with it)

3

We’ll have to try that

Who would be the appropriate person to talk to around having that added to the Release Upgrade document? The only section that exists right now is to install a new client, and that really doesn’t make any sense for an upgrade.

4

@aidacra Probably has the “right” approach (which may or may not be what I did) however it did work… There’s a documentation lady somewhere inhere… @Mark_Wonsil who is the Epicor Edu / Document person? I think you know

1 Like
5

PS: Make sure your ClearClientSettings is set to Core… it’ll make your life easier later.

6

@Staci_Stahr_Cummings can set you up. She rocks.

If you ever have issues within in-app help, there’s a link at the bottom and that goes to Staci’s group. I believe the direct email address is: documentation@epicor.com

2 Likes
7

I’m assuming you mean clearClientDir? Set to Core on ours and I don’t think we changed it, so that may be the default (or maybe it changed to be the default in 300?)

That being said, and maybe slightly offtopic, is there a “Best Practice” set of settings for sysconfig files that everyone should at a bare minimum evaluate? There are a ton of things in there for specific use cases, but I figured there must be some subset that y’all have hit along the way as a recommendation

1 Like
8

It is pretty much company and deployment specific but the Administration Guide goes into DEEP dive in most of those settings.

1 Like
9

Thanks @Mark_Wonsil! Yes - I am “the documentation lady”. I’ll get to the bottom of this to get the Upgrade Guide updated.

Thanks Everyone!

3 Likes
10

You rock! I was about to send an email off to you and your team, but I see I won’t have to :smiley:

3 Likes
11

The Client Auto-Deployment basic workflow for a Release update is:

Epicor.exe (or Epicor64.exe) starts and picks up the specified Client Sysconfig file - for this write-up, “MyEpicor.Sysconfig” and referenced as the CL_Sysconfig.

Epicor.exe extracts the “deploymentServer uri” value from the CL_Sysconfig and then appends “\Client\Config” and attempts to fetch the file “MyEpicor.Sysconfig” from that path. If the file does not exist (and several attempts to read it are made using different Upper and Lower case versions), an attempt is made to fetch the “Default.Sysconfig” file from the path. Assuming we are successful at retrieving a file, that will be referenced as the DS_Sysconfig.

Epicor.exe compares the “version” value from the CL_Sysconfig with the “version” value from the DS_Sysconfig. If different, the Auto-Update processing starts else the login form is presented.

From this point forward, Epicor.exe uses the configuration settings from the DS_Sysconfig to continue the Auto-Update.

Epicor.exe (in the newer versions) goes through a series of file permission gymnastics to see if the user needs to have elevated Administrative rights to do the Auto-Update. If necessary, Administrative rights are requested and the user is told why Admin rights was needed.

Epicor.exe creates a Temp directory and copies all the local Client\Config *.Sysconfig files into the temp directory.

Epicor.exe extracts other deployment related settings from the DS_Sysconfig file (clearClientDir, etc.) and actions on those.

Epicor.exe extracts the “deploymentServer uri” value from the DS_Sysconfig and appends “\Client” and fetches “AutoUpdate.exe” and several other files needed for the Auto-Update processing and those are written to the local Client directory. Of interest here: any Auto-Update related changes made to the newer version of Epicor.exe do not take effect until the next Auto-Update sequence. Someone upgrading from 10.1.400 to 10.2.300 will be asked for Administrative Rights to do the Client Update because Epicor.exe in 10.1.400 required those rights for the update to proceed.

Epicor.exe invokes AutoUpdate.exe passing the DS_Sysconfig information and Epicor.exe terminates.

AutoUpdate.exe (now the latest version) continues the Client Update as directed by the information in the DS_Sysconfig - Zip file / XCopy / Customizations.

At the conclusion of the Update, the Local Sysconfig files in the Temp Directory are copied back into the Client\Config directory and the settings - except those in the “userSettings” section are updated to match those found in the DS_Sysconfig file.

AutoUpdate.exe invokes the now current version of Epicor,exe and AutoUpdate terminates.

As you can see from the above (and as referenced by @josecgomez), it is possible to move to a completely different Deployment Server by replacing the appropriate Client\Config\named.Sysconfig file in the current deployment with the updated sysconfig from the newer version. No other files in the original Deployment Server (as referenced from the original CL_Sysconfig) will need to be updated.

10 Likes
12

Question on this method from @josecgomez: Although this is a super simple way to update clients when going to a new release, is there any reason to be concerned about the process not updating the area, per @Rich?

For instance, we are about ready to go from 10.2.100 to 10.2.400 and I’ve been testing this method with Pilot (works great)! However, I noticed that the local client is missing a few config settings that appear in the default 10.2.400 config area (for instance, additional commented notes, a default for DocStar, enableVideoHelp, EOBSharedMemory).

Will Epicor be looking for these fields in the config and throw errors if missing?

13

Do you have an existing sysconfig with the same name on the server? If I read @Rich correctly, you may want to delete that file and let it find the default.sysconfig and then it should sync them at the end so all of the settings are correct. Does the default.sysconfig file have the same settings you mention regarding DocStart and etc?