We’re running into issues using Epicor with Windows 10 UAC, particularly whenever our users need to perform client updates. Whenever this occurs, Windows 10 UAC prevents the AutoUpdate.exe from being launched by Epicor.
With Epicor 9, we found we could work around this by having our Epicor shortcuts point directly to the AutoUpdate.exe, which would launch if needed and then launch Epicor afterwards. When we try doing this in Epicor 10 though, we get an error message instead stating “The server’s ’ ’ file could not be found”.
Does anyone know if it is still possible to launch AutoUpdate.exe directly in Epicor 10 still, or of another work around for running client updates on Windows 10?
Tienes que darle permiso a la carpeta de epicor 10 que esta en C:\Epicor, aparte de eso tienes que ir al acceso directo y hacer click con el boton derecho Propiedades/Compatibilidad/compatible con el OS.
Por ultimo te recomiendo q hagas esto para que no te suceda al cambiar de bases de datos: PRODUCCION=C:\Epicor\ERP10.1Client\Client\Epicor.exe /Skip “/config=Epicor10.1.sysconfig” y TEST=C:\Epicor\ERPTest10.1Client\Client\Epicor.exe /Skip “/config=EpicorPilot10.1.sysconfig”.
One of my co-workers helped me translate Andrès’ message, and it definitely helped. We had only been focusing on the client-side setup, but the issue was that the “Default.sysconfig” file needed to be both on the client PC and the server. After copying the “Default.sysconfig” file to the server’s config folder, we could run AutoUpdate by itself, which would then launch the Epicor 10 client afterwards. We did not have to change any of the compatibility settings in this case.
Regarding the other suggestion, we prefer to let our users automatically take the updates in Epicor 9, and with Epicor 10 we’ve been hoping to maintain this. I know that using /skip in the shortcut is typically the recommended solution for this, but we’re hoping to use this work-around in the meantime to allow our users to continue automatically pulling updates to the client.
The majority of our shortcuts still point at the MfgSys.exe file in Epicor 9, and the Epicor.exe file in Epicor 10. On our Windows 10 PCs though, we don’t have much in the way of customizability for how UAC is configured, and as long as UAC is enabled on these PCs we’ve found that we cannot get the MfgSys.exe or Epicor.exe file to automatically launch AutoUpdate.exe.
In this scenario, we’ve created separate shortcuts for our users which point to AutoUpdate.exe in Epicor 9. We’ve also trained them that if they’re prompted for an update on start-up of Epicor 9, they have to launch the “Update” shortcut. With Epicor 10, the same set up works but you apparently need to ensure that the “default.sysconfig” file is available both in the client and server config folders. Alternatively, I found this morning that you can point AutoUpdate.exe at a config file, so long as the file exists in the same location on both PCs. For instance, I have a shortcut that targets:
The second half of that specifies the config file location on the server, and I’ve mapped a D drive to point at a similar folder structure on my PC. This was just a test at this point, if we were to use this for our users we’d likely created a folder structure on the server to mimic the client folder structure, and copy a config file to that location.
Interesting. I wonder if you’re seeing the same issue that I do. My users get the auto update start if required, but it’s prompting UAC elevation because the users don’t have admin rights on their local PC.
When your users click AutoUpdate.exe, does it prompt them for admin rights?
@markdamen it sounds like we have the exact same issue. Our users get the UAC escalation prompt when trying to launch their client while an update is needed. When we launch AutoUpdate.exe instead, it bypasses the UAC escalation, takes the client update from the server, and then opens the login window for the client.
@Hally we have a single client installed for each instance, and separate Test, Pilot, Production, etc. using shortcuts pointing at different config files.
We recently ran into another issue using AutoUpdate.exe in Epicor 10.1.500.14. We have the configuration files set up correctly, but now after AutoUpdate.exe has downloaded the full Release Client, the application will throw this error:
“The file ‘C:\Epicor Software\E10Client\Epicor.ServiceModel.dll’ is currently locked. Hitting Cancel will cause AutoUpdate to exit.”
We have the option to retry or cancel, but the file never unlocks when retrying and the AutoUpdate process is the only one running.
aidacra
(Nathan your friendly neighborhood Support Engineer)
17
For science, if you rename the C:\Epicor Software\E10Client\Epicor.ServiceModel.dll file before the autoupdate is triggered, does the process complete or does the file that the autoupdate reports is locked simply different?
Actually tried this myself yesterday, as well as deleting the file. In both cases, the Epicor.ServiceModel.dll file is recreated in the folder before AutoUpdate.exe starts to download the release client. The locking message ends up being the same.
If you delete the file while the release client is downloading (apparently it’s not locked at that point), AutoUpdate.exe hits an unhandled exception at the point of trying to lock the file and results in a Windows error (the kind you can send to Microsoft).
aidacra
(Nathan your friendly neighborhood Support Engineer)
19
FYI: The SCR to not require elevated privileges during a client autoupdate was completed soon enough to be included in the GA release of 10.1.600. The autoupdate will now only force elevation if the user doesn’t have write access to the client folder.
