Hello everyone. Please remember that I am not on the technical side but I’m going to explain this the best i can…
We have struggled with this issue for awhile. We have a customized MES as I’m sure many do. The way that I understand how that is pushed to everyone’s machines is updating the version in the system configuration file. That works fine as we have software that can deploy that, BUT, whenever we do an update or an upgrade we find that the customization won’t work until you open MES on the machine. In other words, if we deploy the custom sys config file to their machine before they open Epicor or MES, it won’t allow the user to open MES at all. We find that we have to open MES without the custom sys config file, then push it, and then it works beautifully. Hopefully that makes sense. This obviously isn’t very convenient when we do an upgrade because we have several hundred users and we have to manually communicate in order to confirm they have opened it before we can push the customization.
Do any others have this issue or what are we doing wrong?
I think I understand your question, but it’s a bit confusing considering there are usually a few other things at play. A lot of folks also use Remote Desktop services for MES, but you didn’t mention that. And is your customization a regular UI customization or an additional DLL or something else?
A regular UI MES customization can be deployed using the “MESMenu” element in the sysconfig file - is that how you are doing it? If you are, then you really can just alter the version number of the Patch entry near the bottom of the sysconfig file and all clients will get a new file upon startup without doing anything else. The MES client is really the regular client just with a different startup default form so it should work fine. Now, you may have the ‘/skip’ param on your MES icon which means it will not check for a new file and that would defeat what you are trying to do. That would require touching all the clients or using Active Directory Group Policy or some mechanism to get new Icons distributed - which could also be a way to distribute a customization that required any custom files/dlls…
Also, Updates and Upgrades are handled differently. And Update/Patch is done via the sysconfig file and is automatically delivered to all the clients. An upgrade (say to v11) is a new client installation and you must manually update your sysconfig files for any special stuff like a MES custom menu item. And an upgrade would require having some mechanism to distribute the new client/icons to each computer. (We build an MSI file and distribute it using Active Directory Group Policy an dother people have scripts and other magic )
Hope that helps as I can’t be more specific without knowing a few more details.
Hi Mike! Thanks for your questions. I’m sure I left out important details.
We don’t use Remote Desktop and if some users do, they’re remoting into their computer from say a laptop. I’m not sure if that is what you mean by that question? We don’t remote desktop into the server to use Epicor if that’s what you mean. Our MES and Epicor is installed on the local machine. Our customization is a regular UI customization.
A little background info on what we’re doing currently… we’re on 10.2.400 and going to 10.2.700. I understand that a patch is different BUT we also did just have this issue with a patch we installed so that’s why I generalized updates/upgrades. We do have the software available and use AD and group policy. But like I said, for some reason we have to manually open Epicor first and then push the custom sys config file. Otherwise it just will not open. It’s a little hard to explain but I was hoping others may have had this issue?!
@MDiekhuis I think the issue is ownership of the folder contents and the ability to update them. We used to have this as an issue when an administrator would install and open Epicor then a normal user would not be able to because they could not update the sysconfig. We found that adding domain users with modify permissions to the Epicor program folder would prevent the ownership issue.
I wonder if it’s the order of events. Since opening the client during an upgrade/patch will overwrite the sysconfig files, you can’t really deploy it first, as it will get overwritten. But if they are the same it shouldn’t matter, so I’m thinking there should be an error message from the client when it tries to start with the previously copied sysconfig file. You say it won’t allow them to open it - but what does it actually do?
Currently battling the same hassle with every update/patch. Have you obtained any more info on this?
I am about to reach out to Epicor for answers as it makes no sense to overwrite the local config file and force me to visit a dozen shop floor PCs every few weeks.
You have to move the custom mes menu setting to the user settings portion of the config file. There is a KB article on it with step by step instructions.
)