Might not be the most secure arrangement but If you have some users accessing your on-prem system using non domain joined machines over a VPN you will get the config files not found error if the logged in user account can’t access the Epicor network share which it probably cant being a foreign machine.
For those users you need to make sure the machine has their credentials in the credential manager to access the Epicor server network share. Just add an entry for the Epicor server using the users Domain account details. Once that is setup you should be able to access the config files at least.
I just want to make everyone aware of an extremely low cost and very secure option for new remote workers.
buy a Chromebook for $250 new, or $50 used
install the chrome extension Xtralogic RDP ($10/yr) [only one that supports a RDP gateway]
connect using Remote Desktop (RDP)
We have been a 100% terminal services (remote desktop) shop for 8 years. The transition to remote work was simple and no cost, because we already have terminal services up and running. The only expense is buying a few Chromebooks and that $10 license.
We ended up buying 100 used Chromebooks for $10 each from a local school. Some we deployed for remote workers but most we deployed on the shop floor so that each employee has their own keyboard/mouse to reduce transmission risks of COVID-19.
So now everyone has full mobile access to Epicor, no Windows or AV licenses to maintain, ChromeOS is secure, no additional Epicor installs to maintain (just one on the terminal server).
This is a myth that just won’t die. Opening up RDP is no more risk than opening up VPN. Both have a specific port they use, both are encrypted, both occasionally have a critical vulnerability that needs patched. The only risk to RDP is if you aren’t patching your servers, but that same risk applies to VPN.
We haven’t found a need for 2FA. Passwords are all 15+ characters with the usual complexity requirements. While both RDP and VPN are vulnerable to brute force, we use RDPGuard to block any kind of brute forcing.
What is the risk that you see that is somehow different from the VPN risks? They are identical to me, with the exception that an infected remote workstation can’t touch anything in RDP. If the infected remote workstation is on VPN, it’s scanning your network and propagating the infection
A VPN using a nonstandard port with 2FA is much harder to crack than a terminal server sitting on the open internet. With 2FA an attacker would have to first compromise a users phone and get the TOTP 2FA code. Once they have the code they would have to figure out the users password and VPN port. All that’s needed to compromise a terminal server, or any open server with RDP, is to guess the users password. It’s way to easy to find open RDP servers. Took less than a minute to find 3+ million.
It’s just as easy to use shodan to find VPN servers. All a shodan search tells us is how many people are using it, not whether each one is properly secured.
Be we aren’t really discussing VPN vs RDP anymore, are we? The security benefits that you talk about here are a result of 2FA, not from VPN. 2FA will make both VPN and RDP more secure, quite obviously.
Anyone can sit there and guess passwords for VPN or for RDP. But that’s what things like RDPGuard are for, so that their IP is blacklisted after too many guesses. Does everyone’s VPN have a smilar brute force blacklisting tool? Definitely not. Some do, many don’t.
No… not really. You can use nonstandard ports for RDP and 2FA.
To go back to the RDP security. There are many that add a firewall rule allowing traffic to their RDP/Terminal server. They don’t have account lockout policies or any filtering. If you don’t add some extra layer of security you’re taking on a lot of risk. I’ll agree that not everyone has a next-gen firewall to do that stuff.
Its worth mentioning that most people are unfamiliar with what a modern RDP gateway actually is. A Microsoft RDP gateway runs in IIS over port 443, encrypting incoming traffic over TLS1.2 like every HTTPS site does (and like most VPNs do), then it forwards the actual RDP connection to the appropriate server within the network over that encrypted tunnel. It’s really not any different from VPN, except that the remote computer never gets direct access to your network and therefore safer.
Another thing worth mentioning. If you’re going to open up ERP to the public, or any self-hosted service, you can use a AAR built on IIS for an extra layer of security. Works similar to the RDP gateway.
Good morning IT experts and all of my lovely far away colleagues,
thanks for your input @timshuwy, i have tried this suggestion and can not see any different mate, may be it is something in my WIFI or/and Laptop settings need changing ???
VPN/RDC keep freezes and losing connection, any other tips to improve this issue please?
If you have a stable VPN connection and you’re purely seeing the RDP session freeze then there may be something that can be done.
I’ve seen a few instances where RDP freezes up from time to time and while it’s only a few seconds to close/reconnect it gets annoying quickly.
One possible solution to one specific version of this problem is to disable UDP for RDP and force it to use a TCP connection.
In this case: On client: Local Group Policy Editor
→ Local Computer Policy
→ Computer Configuration
→ Administrative Templates
→ Windows Components
→ Remote Desktop Services
→ Remote Desktop Connection Client
→ Turn Off UDP On Client
→ Enabled
(solution stolen from windows 10 - Remote Desktop intermittently freezing - Super User which has other suggestions I certainly wouldn’t touch!)
Worst case it changes nothing and you put the setting back as it started
I know this is a very old post but I found a solution to the Deployment server issue:
Create a folder in your local client folder matching the Deployment folder name eg ERP11.2.300Deployment
In that folder, copy the Client\Config folder from the server into your Deployment folder, preserving the path (create Client folder and then copy Config folder into it)
Copy the ReleaseClient.Zip file from a server into the Deployment folder.
In the SYSCONFIG folder, point the deploymentServer setting to your local folder.
This fools Epicor to look at that and it works. You would need to manually download an updated ReleaseClient.Zip in the event of an upgrade to get this to install
