Sage 100

Go Live on 2014 Std to 2018 Advanced. Running App Server as a service. 18 T/S users (on 2 terminal servers - Windows 2008 R2) + 6 workstations. Sage server is 2012 R2. Per Sage KB doc formerly known as SS3003-ABC, have increased heap size to 8192 & restarted service. Users are still getting Windx timeout errors. How high can this number go? Is there anything on the terminal server side that can be addressed or is this strictly a server issue? Really want to run as service. @GeorgeKhairallah @AlnoorCassim @JimWoodhead @SteveIwanowski

I'm assuming you're referring to this: * HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\ SharedSection=1024,20480,768? In our environments, I change this to SharedSection=1024,20480,4096. I have this working for a 50 users environment. As a general rule: - I would not change this to more than 4096. - The 4096 needs to be adjusted on a trial and error basis, depending on what software is on the server. If it's a basic Sage server, I can confirm that this value should work. Also, what is the specific WindX error you are getting? Do you still get it if you turn off the firewall on the Sage server? If you have the firewall on, you need to make sure to open up high TCP ports. (TCP/30000-65535) from the Session Host. Not having those will also cause a Windx error.

We confirm the issue is service memory limits by running as an Application for a while first.

@GeorgeKhairallah message is ""Connection timed Out waiting for your application to start. Please contact your Administrator, as there may be a configuration error on the server. The server side process failed to start or respond. Turned off server firewall. We originally had the value 4096 but bumped it up when these messages appeared. High TCP ports are open.

Hmm.. does this happen when you hit a certain threshold of users logged in? ... Based on the content of the message, I would suspect you would get this regardless of the number of users logged in, in which, we may be looking at the wrong solution altogether. Also, when the users are getting this message, do you get the same message if you try to login directly on the Sage server? (Just for kicks: You do have DEP disabled, A/V Exceptions in place?)

You made the change on the Sage App Server, right (sorry I had to ask)? The general rules of @GeorgeKhairallah are correct. I'm saying that as the original Sage author of SS3003-A. 8192 is dangerous because some Windows services could fail - on reboot you'll see an error referring you to the Application or System Event Log. The premise behind needing a high number to begin with is to support X number of pvxwin32.exe tasks to run concurrently. Think of it as the number of screens the users can open from their Launcher including the Launcher itself. (Those people with the setting to hide their Windows taskbar are the worst because they will often have 20 instances of S/O Entry and such open not even knowing it). If you're at 4096, that can support at least 250 concurrent instances of pvxwin32.exe running on the server. The question is do you actually have that many at the time the timeout error appears? I'm guessing you don't and something else is amiss. I would do 1 or both of the following next 2 steps: 1) @KevinMoyes suggestion to just run App Server as a desktop application instead of service, temporarily. See if they no longer report Timeout error. It answers question if the services heap size (the 3rd number) had needed the further adjustment. 2) In User Maintenance / Prefs, do you have Spawn Task box checked currently for the users? If not and you want to check the box for all users, do it all at once when all users are out of the system as it requires restarting the Launcher anyway.

Actually, @AlnoorCassim brings up a good point. Usually, when we have this issue with the heap size, I actually make the change on both Sage application server, and the ""Workstation"", in this case, being each of the terminal server session hosts, as the pvxwin32.exe will spawn as many times as there are screens on the session host, thereby causing a limitation there as well.

Spawn Tasks checked for each user in User Maintenance. We switched to running as application, but are still seeing timeouts

Are you absolutely positive that there is nothing in the way of blocks between the terminal servers and the application server? (It almost sounds like something is preventing the communication to the Sage application server. ) ... you can try to use paping (https://code.google.com/archive/p/paping/downloads) to do a continuous ping to the Sage app server port and see if that ever drops, or causes a failed connection. ?

Now making changes to heap size on TSs

Make sure you reboot after the change.

Will do, thanks.

Well, IT discovered a bad network cable, which he replaced . . .

Thanks for all the assistance. Still fighting this battle, however. IT checked with another reseller, with whom he has Sage clients, who suggested he disable ""Spawn Tasks"" for all users. That didn't go well. Passed along @GeorgeKhairallah paping suggestion link. I'm recommending running as an app, but that hasn't happened yet. Stay tuned . . .

Too bad they won't even try to run as app JUST to rule out the issue....

I cc'd the business owner in my last email . . .

Update: they are now stable. A combination of un-checking the ""Spawn Tasks"" for everyone and rebooting the server and all other computers after the registry changes were made all around are what IT explains finally resolved their issues.