I am testing the setup of a small RDweb server to host QuickBooks for some remote sales users (4 users). For the most part, I have everything installed on one virtual server (using 2012r2 "Quick Start" session host deployment with the additional Licensing and Gateway server roles added to the same server).
Everything works excellent with one exception. External clients cannot launch published apps without having port 3389 open on the firewall, even with the gateway role installed and the 'Deployment Properties' set to use the gateway. They can properly connect to the RDweb site and view the published apps. The only way it works is open the firewall port (at which time I can disable the gateway or leave it configured and it works either way). Internally, everything works accordingly. I have followed the steps outlined on many sites and have combed though the forum here to no avail.
Error received (summarized but is a well documented error):
remote desktop can't connect to the remote computer: 1- Your user account is not listed (it actually is) or 2- You might have specified the remote computer in NetBios format . . etc.
This is an existing SBS 2011 environment with additional virtual servers setup to host QuickBooks as outlined below:
Current setup:
- Used Quick Start to install Remote Desktop Services in hosted sessions mode
- Installed the additional roles for Licensing and Gateway server on same server
- Configured wild card public certificates on all four services (Connection Broker(2), Web Access and Gateway)
- Configured internal DNS to properly lookup our external FQDN of this server (ex. quickbooks.contoso.com points to quickbooks.contoso.local
One thing I noticed (just now) when I launch a published app and the firewall has port 3389 closed, a dialog box pops up directly after launching the app that warns about running a RemoteApp program and mentions the Remote Computer and the Gateway Server as both the same (which it is); however, I would have assumed one would have listed the internal server's name while, instead, both are listed as the external FQDN. Either way, internal DNS should still allow it to properly route . . no? I don't know . . I'm sure I am just missing something in a routing configurations somewhere. The gateway service is not properly looking up the RDweb service and then seeming not routing the encapsulated RDP session through HTTPS. . .. is my guess . .
I was reading about the "set published name" commandlet; however, I am not experiencing a certificate name mismatch; however, the certificate name does show up as *.contoso.com versus the actual name. I may just be grasping as straws now . . :)