We recently moved an Epicor 10 instance from a physical server in a client’s facility to a third-party VMware-based cloud. The server has more than enough resources – 4 CPUs, 6 Cores each, 224GB RAM, fast disk.
The RDP/Terminal servers we moved to cloud are running great, and the Epicor client on these servers have no issues. However, there are some employee workstations that run Epicor directly on their workstations. Epicor runs fine for these employees at startup, however if they idle for 10 minutes to an hour or more, the client becomes unresponsive for several minutes when they first start working again.
We’ve done a number of tests through PDT, and even had Epicor support validate the entire system, but even they were unsure of what was causing this.
An interesting test would be to make a dashboard with an auto refresh period of 10 minutes. Load that dashboard on a local client machine and let it sit idle. After an hour or so, is that client still responsive? If so, up the refresh time, rinse and repeat.
If it never times-out, maybe leaving that dashboard open during the session would be a work around.
That test was to see if a lack of communication between the client program (on the local workstation) and the server was the issue.
Does it require “using” the client (opening forms, running reports, etc…) to keep from becoming unresponsive?
Or does simply bringing the client program into focus (like grabbing the title bar and drag window around) keep it from freezing?
I’m nor super familiar with a cloud based setup, but I assume the endpoint binding is Http (or Https) based, and not Net.TCP. And I recall that Http connections have time settings. If there’s no activity, the socket is freed up for another connection to the server.
Yes, correct. If the user constantly uses epicor there is no issue. If they get up to use the restroom or otherwise don’t engage for an undetermined period of time (5 to 10 minutes) then we will see the issue.
Your assumption actually is incorrect. We are on 10.0 and we are using Net.TCP since https was not introduced until 10.1
Unfortunately our level of customizations prevents our 10.2 upgrade from being a “quick” fix. We are working towards that but it’s not going to happen soon.
I’ll look up this TcpKeepAlive setting and see what I can do with it
Mark, we installed certificates this week and went to deploy the feature, however the options to enable it are not present in 10.0. Upon further inspection we noted that it was introduced in 10.1
If you ahve any instructions to enable SSL in 10.0 I’m all ears
We were Epicor Dedicated Tenants at the time, so it was a supported configuration. They set up another app server and we updated our .sysconfig files to point there using the correct binding. That was it.
The way multiple app servers communicated in 10.0 was a bit flakey though. I’d create a BPM in the SSL app server and users in the net.tcp wouldn’t see it until the system was restarted. So be careful.
REST did not appear until 10.1.500,.600 but SSL app servers were available in 10.0.700.
FWIW - we’re “on prem” but the servers (APP and SQL) are in our data center in Georgia, with our users in PA, TX, OK and WY. The apps are set to use Windows binding (which uses net.tcp).
The majority use E10 via RD App, but some have it installed locally. I believe there is a VPN connection to the datacenter from each of the offices.
And we actually see more problems with RD apps, as the TS is set to disconnect after 15 minutes of in activity.
P.S. - We’re currently on 10.2.300, but had this same setup with 10.1.400. We had a similar setup with 8.03, but the only reliable thing that worked was 100% using RD Apps
If we update to UsernameSslChannel do we need to change anything in our client configuration files? As far as i can tell we should be able to leave them as net.tcp configurations as this channel falls under the net.tcp options.
I assume once we update this test server (we are scheduling some downtime) the option to choose our certificate will appear and that should be all we need to do to enable SSL.
