Sage 100

2017 premium. Went live Tuesday. Users are getting lots of ""Error: ""Windx client connection: Connection Timed Out waiting for your application to start"" or ""The server side process failed to start or respond"""" Tried everything on KB 20320. What else can I try? Running the host as an app.

Is the SQL instance on the same server? If you're already running Sage as an app, I'd reboot to see if the problem goes away. If it does, then they'll probably need more hardware resources. or dial SQL back. What are the server specs (CPU/RAM)? How big are the databases (MAS companies)?

@SteveIwanowski Yes. The SQL instance is on the same server. Tough to reboot in the middle of the day but will do if that will make the issue go away permanently. Processor is an Intel Xeon ES-2650 v4 @ 2.20GHz (2 CPUs), 129 GB RAM.

Well, that's, uh, plenty of RAM :) Antivirus properly excluded? How many users? Are there any WAN users, or is everybody local?

For sure. 30 Sage users and another 30 ScanForce users in the warehouse with handheld computers. Some users accessing via Cirtrix Receiver. I will check with the AntiVirus.

Doug - I think KB 20344 may be in play - https://goo.gl/GeikaH - I was the original author of this article way back when but it's more shorter and easier to read now :) Is App Server running as a service? If so, adjust the 3rd value for the services heap size. Bump it up from 768 to 2304. Reboot of server is required to take effect. But if App Server is running as an app (desktop app) , it is still possible with this many users and if on Server 2008 R2 or less, that you may need to actually adjust 2nd value for the desktop heap size. In the article it says desktop heap size starts at 20480 but for older o/s's, it is 3072 if memory serves. You could bump it to 3584 or 4096 then reboot.

Thanks Alnoor. It is Server 2012 R2. I think I have it resolved. I started wondering if perhaps some portion of the 10Gbe link *wasn't* configured to run at 10Gbe. That would throttle the connection speed down to plain old gigabit Ethernet - fully saturated gigabit Ethernet, but still a much narrower pipe. It turns out that the MTU value on the switch the server was connected to hadn't changed its MTU. The switch saw that the connection was 10Gbe but was still throttling the frame size down to gigabit size. I had IT manually force the MTU to a much larger frame, increasing throughput by a factor of eight or nine. It already seems faster to me, and I've had no further complaints about WinDX errors.

Update. The changes to the network switch greatly reduced the WindX errors but didn't completely eliminate them. Last night we moved the log files to a separate physical disk. I hope that reducing the writes on the ""main"" disk will get rid of WindX.