General Consultant Discussion

We are upgrading to Sage 100 Advanced 2017. Client's IT is preparing a new Remote Desktop server based on Windows Server 2016. He has successfully installed the Sage 100 Advanced Client 2017 on the server in a remote session and it connects to the Sage server just fine. He published the client app through the server manager interface and added the proper command line parameters. It seems to start OK but never gets to the login prompt. The remote session is active but it shows the client is disconnected. He believes all settings and permissions are set correctly. Has anyone seen this behavior before? Other published apps work fine, including Office 365 Word and Excel. He's using the web interface to activate the remote app. He has also tried IE and Chrome with the same results on both. It works on Server 2012 R2. We are running an older version of Sage client on a Windows 2008 server with remote desktop for production. It's never shown this behavior and works perfectly. Has anybody come across this?

This sounds like the Sage client is launching and closing. Have they tried removing the published app altogether, and trying to republish, and re-checking the argument line to make sure there is no typo there? (though come to think of it, if there is a typo, Sage would still open, with the empty white screen). Just something worth trying. It does sound like something that is specifically with the Sage published app if it all works outside of that app. One other thing to try, what happens if you login with the user trying to launch the remote app through actual RDP session, and launch Sage, using the same exact parameters set in the published app.

I think I read something like this on Sage City. It could be remote app on Windows Server 2016 is not quite ready for prime time.

Have they allocated sufficient resources? Guessing it might be a VM and they sometimes get under resourced.

I heard that in Server 2016 the RDS, unlike prior versions, for configuring remote apps (published apps) it does not have a way of setting the Start In directory (the path to mas90\Home) that you can specify the command line only. I know in the past it was important to set the Start In folder otherwise an Error 12 could occur client side (even if the error itself did not show) and you would never get to the point of seeing the Sage login prompt. I'm assuming here that running a RDP session for Sage 100 through an actual desktop works okay.

Any additional caveats for Server 2016. IT guy wants to go with Server 2016. I will be installing v2017 Adv on it. Thoughts before I green light it??

Just completed a v2017 Adv upgrade in May. No issue other than the Remote Desktop app experience.

@AlnoorCassim, I just ran into the error 12 on a citrix box. Actually the Citrix box publishes the app out to another citrix box, and that command line path is objectionable due to the special characters in it. I couldn't tell, were you saying there's no resolution/work around on that?

Rhonda at the time yes the person I was speaking with said there was no resolution/workaround other than to run with an actual desktop but we were pretty certain it was b/c the Start In folder could no longer be specified in Server 2016. But if you're saying the Error 12 is b/c of objectionable characters like the ""*"" in ""*client"" (a great discovery) then here are some ideas to test: 1) Knowing *Client means the _Client program under the Home\Lib folder change the line to be like this: C:\\Sage\WkstnSetup\Mas90\Home\pvxwin32.exe -hd ..\Launcher\sota.ini ..\Home\Lib\_client -ARG ""SERVER"" ""PORT"" ""Sage 100"" 2) Point the app to a .BAT file instead and break it out in the .BAT like this: C: CD \Sage\WkstnSetup\Mas90\Home pvxwin32.exe -hd ..\Launcher\sota.ini *Client -ARG ""SERVER"" ""PORT"" ""Sage 100"" REM Alternative way: pvxwin32.exe -hd ../Launcher/sota.ini ../Home/Lib/_client -ARG ""SERVER"" ""PORT"" ""Sage 100"" REM Replace SERVER and PORT appropriately

I edited my reply under ""REM alternate way"". I typed in with forward slashes b/c the display in SocialCast was omitting 1 of the backslashes. In the end back or forward slashes doesn't matter.

Great idea! I'll update after the customer tests one of these. Regarding #1, it actually objected to the quote marks too. But I'll test full desktop and/or bat file.

Seems like the batch file might work... https://sagecity.na.sage.com/support_communities/sage100_erp/f/98/p/101848/288161#288161

I don't beleive we have this problem with Citrix publishing but we do have batch files for all customers for varying reasons.