Just some background information before I jump into a problem I have encountered. I first noticed this issue one day while working and having sporadic internet outages but really did not pay any attention to it. My next encounter came during a customer engagement and this customer happens to have an “air gap” network.
The testing, shown in the attached video, happens in a dedicated Test environment but was also reproduced in several other environments.
The Server has Epicor 10.2.200 & 10.2.300 installed and each uses a DEMO database which is hosted on the same server as the application and uses SQL 2016. The server OS is Wndows 2016. Basically, everything including the client is run from the server for this test. In other testing split app server & SQL was used plus the client was on a workstation but I got the same result as what will be shown here.
With Internet access enabled, I was able to open both 10.2.200 and 10.2.300, as shown in the video, and launch the Change Log Report screen (the issue happens with any screen – this was just for an example). Once the screen opens – which is fast – I was able to immediately drag the screen around.
This test comes right after Test 1 and the only difference is that I shut down the interface that provides the Internet connectivity. You can see in the video that I issue the shutdown and immediately the continuous ping to google.com stops.
I then launch the 10.2.200 Change Log Report screen and it opens fast and I am able to move it around immediately.
I then perform the same test using 10.2.300 and while the screen immediately opens I have to wait up to 40 seconds, at least this first time before I can get the screen to activate. After the initial launch I can finally close it and then it, or any other screen, will take 10 seconds before they give me control. This goes on forever and never gets better until the Internet access is back.
Notes of Interest:
1 – If I simply remove the default gateway from the server – which will also disable Internet – it does cause the same problem (tested on several different environments) as long as certain conditions apply to routing. If I change the default gateway to just a bogus IP – same issue as shutting down the router interface.
2 – I disabled all CRL checks to make sure I was not running into issues with that
3 – I am in the middle of still troubleshooting but one thing that really caught my eye was this from ProcMon – not entirely sure what this call is quiet yet but will know soon. You will notice the process is Epicor that is encountering this TCP reconnect.
4 – Any version 10.2 and earlier works fine.
5 - A bunch of attempted Azure traffic
10.2.300 Feature.mp4 (3.3 MB)