Sage 100

Setting up new Sage 100 2018.2 Premium on a Windows Server 2016 (Brand new - which means they haven't spent a lot of time configuring). When I run Sage 100 as **application or service** the remote user can initially log in to Sage but upon opening the second window (go to Vendor Maintenance, as an example) they get a Connection failure to host: [TCP]<server>:<port number>:NODELAY;STREAM I'm only in the testing phase with a single user account so I do NOT suspect the typical memory issue that might be seen with a larger number of users. If I go to User Maintenance and check off ""spawn tasks"" the problem goes away. This seems like a band-aid and I worry that it's going to be fine for the initial users but as soon as a new user comes on board the customer is going to forget to check the ""spawn. Naturally, I'm getting pushback from the IT folks who want me to do a deep dive on the history of Sage 100 and all engineered aspects of its interaction with Windows.... I have found this KB article ( https://support.na.sage.com/selfservice/viewContent.do?externalId=19875&sliceId=1 ) which suggests setting some exclusions for Windows Firewall - BUT it specifically mentions ports 49152 to 65535 and we are using port 9600. There are a half dozen try this / try that. None of which appear directly on point (aside from checking ""spawn tasks""). Is there a trick that I can tell the IT director for some type of exclusion on the server?

I haven't found anything solid yet, so I recommend and train them to check Spawn Tasks for any new users. This only seems to hit me in virtualized environments, so I always suspected it was something with the physical-to-virtual network interface transition or tagging that Sage 100 is susceptible to, but nobody ever wanted to pay me to find out for sure. :)

I believe it's the firewall one, just had this issue last week and worked with Carmen Cruz who provided the list below and said they should be done in order. IT group was very reluctant to do anything. I know they did the inbound rules for the firewall, DEP, increased RAM. In our case the no delay stream and Connection Timed Out started about a week after the upgrade. Changes for Server: Error Connection failure to host NO DELAY STREAM How to setup inbound rules for Firewall.pdf oAdditional Executables to create inbound rules for ?<drive letter>\..\MAS90\Launcher\Launcher.2016.exe ?<drive letter>\..\MAS90\Launcher\Launcher.old.exe How to setup exclusions in DEP (Data Execution Protection) for Windows.pdf How to enable or disable Sage Product Enhancement Program (PEP) for Sage 100 ERP.pdf How to Determine if Sage 100 ERP Advanced and Premium Application service has reached the Maximum Heap size allowed by Windows OS.pdf Windx client connection Connection Timed Out waiting for your application to start or The server side process failed to start or respond.pdf SS3003-ABC_Highlighted Heap Section.doc Cannot create a new session with a large number of users, SS3003-ABC.pdf How to exclude Sage 100 ERP from Antivirus scans.pdf AntiVirus Configurations Symantec 11 and regular Symantec.doc How to configure Symantec Anti.doc Symantec End Point 11 causes slowness in MAS90 MAS200 installation..doc Windows Defender Disable Windows Defender via Group Policy Windows 10 1709 Users UAC set to Never Local Administrators Icon change compatibility tab of Properties to ""Run As Administrator"" Note: Windows 10 final release changes have caused an up to 5-10 second delay on screens.

Thanks. In my case, the issue starts immediately when the first user tries to login via Terminal Server. There is nobody else in Sage as we are just getting up and going testing 2018.

Wayne in your case, where the Launcher loads successfully but the 1st task off the Launcher results in that error, it clearly means the Windows Firewall on the Sage server is the culprit. I know the KB article is all over the place and that's because so many factors can be at play. But in your case it's specific and there are only 2 ways to consider dealing with it (feel free to avoid reading the Tech Factoids): ------------------------------- 1) Enable Spawn Task in User Maintenance for all users. It's true that box is not checked by default for new users so if possible setup a K-Sync alerts to monitor the Sy_User table for AppServerSpawn <> Y to send an email. (BOI trick available too.) 2) Configure the Windows Firewall for an Inbound Rule to allow (pvxwin32.exe and pvxiosvr.exe) and since v2016 for an outbound rule as well (Launch32.exe, Launcher.old.exe, Launcher.2016.exe) _Tech Factoid A:_ When the box is not checked the App Server uses a program called _server (in \home\lib) to listen for requests. This program was created for v4.10 but uses older 3.x ""technology"" (similar to the old Host.exe) when listening for connections. It's a bit faster to load tasks from Launcher but requires the high ports to be open (which really means configure the Windows Firewall for Inbound and Outbound rules - see below) and doesn't support a feature called NAT (Network Address Translation - more on that if you want). _Tech Factoid B:_ When box is checked, it uses a program called 'server' in \home\lib\_Appserv. This is the native listening program that comes with the Providex App Server (when Mike King's team developed it way back when). It doesn't need Windows Firewall enabled and interacts better / stabler with the client (meaning the task you ran off the Launcher). However it loads tasks a little bit slower. But if you have any kind of imperfect connectivity on your network (like @SteveIwanowski mentioned with VMs but not limited to that), then check the Spawn Task box. In your case, because of the 1st task error, it's a slam dunk to check the box.

@JeremyFox may be able to add comments on the firewall issue. We ran into this last week and additional rules were needed on the server. He worked with Sage support and got it functioning. Workstations were not able to run Sage.

Thanks everyone - the above firewall settings fixed this issue.