Sage 100

Slow since upgrade to 2018. Sage 100 2016 on server ran fine. Screens are taking a very long time to open. This is advanced over a WAN. A 4 ping reply was 7ms to 52ms. What is a reasonable expected reply for a WAN? What is a reasonable screen response time. In a LAN I expect Sage 100 screens to open in 2 - 4 seconds. On the server, I am getting 2-3 second screen openings. Workstations are taking 15 + (read + as alot more). No antivirus on the server.

I am not technical enough to opine, but I am certain we had to increase the sizing of our standard server build with 2018 as compared to previous versions. 52ms seems slow.

Howdy, Larry! Do you have ""Spawn tasks on server checked"" in the user maintenance? Try that - it may speed this up considerably.

I have had this problem on 2017 and 2018. I have spent over 5-6 hours on the phone with Sage trying to troubleshoot the issue. They keep escalating the case and I feel like we have gotten no where. I will update if they have a fix.

On page 4 of the 2018 SPM, under ""Miscellaneous Notes"" it states ""unacceptable ping speeds are over 40 milliseconds "". I tend to double or triple the recommended minimum standards. You should be looking at 25-30 ms (bare minimum) for decent performance over the WAN.

I am looking today and on average getting about 20 - 25 ms. My screens are opening in 25 seconds. Not acceptable.

Is the speed issue occurring at all workstations? I had a strange speed issue a month or so ago. It was eventually tracked to a bad video driver. The user had two monitors and after the video drivers were updated the Sage 100 performance improved dramatically. This solution was arrived at after all of the usual suspects were eliminated: Antivirus exclusions, real time AV, DNS configuration, etc.

Is it the same server (2016 and 2018 are on same box) or did you migrate to a new server with 2018. We just had this exact issue but the new server they moved to had broadcom network adapters using hyper-v where there is a known issue, their IT resolved that and things went back to normal.

We have a client that upgraded to Sage 100 2017 Standard, and its a dog compared to 4.5 they came from.

Same workstation, same server, same vm, moving from 2016 to 2018. Sage says should be the same performance.

Ha! I'm sorry, did I laugh out loud?

Just wondering, when you're referring to WAN , is this WAN over a VPN connection? or straight up internet connection? IMHO, doing the latter, is a pretty bad idea, I've done quite a bit of experimentation on this. The best I could run reliably is an C/S ODBC which is ok, but the Sage client itself has too many variables that could cause lags. I'm sure you've seen this article before, but as you can see, even Sage explicitly states that WAN Connections aren't supported : https://support.na.sage.com/selfservice/viewContent.do?externalId=10472&sliceId=1 With that said, if this setup is the only way to go, I would tend to concur with @ChrisMengerink , if the new server has moved hardware (or even VMs which are using a different underlying Network Adapter. I would play with MTU, TCP Offload, etc...

@LarryBradford in your test, does switching your own User ID to the Classic Launcher load screens faster? Also to validate what @GeorgeKhairallah said, b/c of cost many companies with WANs purposely use shared internet connections between their buildings instead of dedicated ""point-to-point"" connections (typically with VPN based routers). Shared internet is not only slow but inconsistent. And hard to convince CTOs to spend the money for Pt2Pt. I had your situation with a hospital client with layers of politics and IT. I even had them escort me into their building where the Finance (Sage) server was located to show the 1 ms response time from their laptops compared to the 20 ms from the other building. They were convinced then but in order to touch MTU and similar settings for troubleshooting, it required sign-off and significant delay from the next level IT group (upward daisy chain of minions). Found out they had 10+ Citrix XenApp server VMs running in their data center anyway for other purposes and managed by an IT hosting group. And that turned out to be the answer. If client is sizable company maybe they may have Citrix or RDS/TS already running ??

^^ brace yourself for 4 hours of ""well why doesn't O365 require this? O365 runs fine. Sage is a dog. That can't be the solution"" -- replay this 3 to 5 times until IT agrees to consider.

Even if you manage to get dedicated bandwidth and the screens are loading faster, there may still be issues with latency while users are printing. Because Crystal is client side, once the printing starts, the bandwidth can be rapidly consumed. Citrix is a great solution if they have several off site users.

This is a WAN over a VPN through the internet and not a dedicated point to point. The argument that is killing me right now is 2016 worked fine. We stripped the 2016 client and it is not that easy to set back up over a WAN because the client takes 2 hours to install.

One thing you can also try for testing is to do TCP pings instead of ICMP to the sage server, and see if the results are the same? At least rule out that aspect of the connection, and make sure that there are no lost packets on continuous pings. By the way, for a P2P connection: 5ms-57ms seems like a high ping, and a fluctuation of 5 to 57 is actually very high jitter, so I would have them do some testing on the config of that VPN connection.