Install 10.2.600

Very excited to be heading to 10.2.600! However, we have around 50 end users; 30 are MES, the other 20 are regular users. With that being said, I would like to push out the install to all the computers and NOT have to do it manually. I have seen some say PowerShell, others silent install, and not sure the best method to use. Has anyone done this successfully, where they did not have to touch the pother computers? If so, what method did you use and can you share what you used?

When we went from 10.2.300 to 10.2.400 I didn’t touch a single device. I scripted the install. As part of our custom install script it removes the old client, updates .NET if needed, installs the new client, adds shortcuts, copies our custom DLLs, add DMT if the user should have it, and sends the user a message that Epicor was updated/installed.

2 Likes

@chaddb - that sounds perfect, but are you that confident? I find myself second guessing the ‘what if’ scenario where my production upgrade doesn’t go as smoothly as my DEV/Test upgrade and I have to fall back at the last minute.

We’re working on the process now and decided to do two scripts. One will run soon and that will install the client in it’s own/new/unique directory like “C:\Epicor\ERP10.2.600Client” (and do the other stuff like .Net), but ti will not remove the old client. After the upgrade is successful and some initial login/testing is done by me, then we can run the second script that will remove the old client…

@chaddb How did you accomplish this? Is the script something you can, or willing, to share? Even if only privately?

It’s just a an option in the script. So we can run the script to just deploy the new client along side the old client. We can also just run the script to remove a client. All the options are there. So if something went wrong we could rollback. But by that point we have tested the upgrade many times. So not been an issue here.

That how we organize our clients. The script adds them to a version folder. That way we can run multiple versions.

2 Likes

Understood. Seems your script is more complex than I assumed :slight_smile:

:upside_down_face: I’m not walking around deploying Epicor.

1 Like

update the deployment folder in the config for your old version on the server and the auto update will do the rest.
If say you are on 500 going to 600. Copy the config from your 600 deployment to your 500 deployment folder. It will see the version change from client 500 to server 600 and then go get all the client stuff from the 600 deployment folder (because that is where the config is pointing)

Just be sure all of your clients have .Net 4.8 installed or it will crash and burn.

Sounds like an easy way as well. Does that work in the other direction?

I’ve never tried either direction because I like the idea of a clean install for each new version of the client - and this sounds like more of a overwrite with residual files left in there…

It actually does a bang up job and wipes out the entire client folder. (Though it doesn’t clear the client cache and that can bite you in the rear end)
One thing I like to do is move the client cache for each new install, that way yo ensure a clean cache off the get go

do I recall correctly that there a switch in the file for clearing the client folder - maybe I didn’t really understand the usefulness of that combined with faking the client into doing a self-upgrade :slight_smile: Shame it doesn’t do the cache - That could surely mess things up.

Now, since 600 has its own deployment folder and we need to dump the cache, couldn’t the script
dump the cache first, then grab the sysconfig from 600 and copy it locally and then start the client so it does the upgrade?

It will replace anything cached with a different version on the assembly however… if you are naughty like me and update your custom client deployed assemblies and say “bah! version numbers who needs them”… you may get stuck with your old assemblies… and it may break a lot of stuff. So… as a precaution, set a new cache location in the config and you don’t have to worry about being a good citzen.

1 Like

So, all i need to do is copy the config files? Interesting! I will try this in test and see how it goes. Anything I should watch out for?

Make sure if you have any custom deployments that you get those included in the config at the bottom, and that you do as jose suggested and tell the config to drop the cache in a different folder than default, maybe one deeper like “/600” or something from the default to make sure you have a clean slate.

Overall no gotchas really, we have done it for the last 3 hundred patches and it works great!

2 Likes

I don’t think I have any custom deployments as I am not even sure what that is. :roll_eyes: :roll_eyes: Anyway, That sounds easy enough.

@jgiese.wci @josecgomez This morning I was told I needed to push the update up to this Friday. SO…can you give me more info on the custom deployments “included in the config at the bottom” and moving the client cache?

I researched a bit and, correct me if I am wrong, but the client cache is the -880 folder, correct? If so, do I just delete that folder and Epicor rebuilds…

You can do that or you can just set an alternate cache location and it will start a new cache.
image

2 Likes

If you use Country Specific modules, or any custom CSG work like Document Sender, then there will be extra lines at the bottom where your patch version entry is.

Gotcha. Then I just need to move those over and adjust the version, correct?