Terminal Server Questions

[SAFCasper]

Yep, as @Sky-Knight said everything is wrapped in HTTPS. When you tell an RDP client to use a gateway it automatically assumes port 443 is to be used

Similar to typing https://www.google.com:443 into a browser. It works but is redundant because 443 is already assumed.

 

[HCHTech]

@HCHTech You're chasing squirrels.

You just need to reset the published names, the cluster figures all that out. And yes, when you're done it's all RDP proxied over https, so you're only forwarding TCP 443 in from the world.

Set-RDPublishedName

Seems to be the powershell command to do this, it seems it was removed from the Server 2016 GUI? and never put back in 2019?

It absolutely feels like chasing squirrels - good call.

So I found, downloaded and ran the Set-RDPublishedName powershell script. My collection link now has the FQDM in the relevant sections:

==========
full address:s:rds.[mydomain].com
gatewayhostname:s:rds.[mydomain].com
workspace id:s:rds.rds.[mydomain].com
use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.LAB_Collection
use multimon:i:1
alternate full address:s:rds.rds.[mydomain].com
==========

I've rebooted the gateway and the RDSH servers, but the something is still wrong.

If I download the RDP from the RDWeb page and run it with the VPN connected, I get prompted for credentials to connect to rds.[mydomain].com, I enter them, only to get the "The remote resource cannot be reached" error. By editing the RDP connector, I can see that the RD Gateway server is pointing to the FQDM, the login is set for "Ask for password", and the "Bypass RD Gateway for local addresses" box is checked. The "Use my RD Gateway credentials for the remote computer" box is also checked.

If I try to run that same RDP without the VPN connected, I get prompted for credentials like before, I enter them, and get the same "The remote resource cannot be reached" error. I've gone through the event logs again, but as usual, don't find anything that leads me to any conclusion.

As before, it all works from within the network just RDPing to the IP address of the gateway.

It also works from within the network if I edit the Connect From Anywhere advanced settings in a basic RDP window to specify the rds.[mydomain].com for the server name, and uncheck the "Bypass RD Gateway for local addresses". This tells me the gateway is doing its job. If it weren't for the fact that I could get to the RDWeb login page with a browser, I would say that the firewall rule is the culprit. Since that works, it has to be with the RDP configuration somewhere, doesn't it?

Honestly, I think I'm going to have to tear it all down again and built it up from scratch. I've had about enough of the squirrel-chasing.

 

[Sky-Knight]

That's not a bad idea... this time make sure the RDS servers are using PUBLIC NAMES, BEFORE you run the wizards.

It's been a long while since I had to argue with a 2012 R2 instance I had to convert from a local name to a public one... and I don't recall that mess being terribly easy. And it was a single RDS Session Host, with Desktop Web Access running and doing all the lifting. You're labing a cluster... AD needs to configure a TON of stuff here.

Also, that script may or may not work for Server 2019, it was written for 2012/2016... I wasn't intending you to run it, but instead trying to aim you at the settings you need to change in the admin panel. The entire cluster needs changed, or nothing works. And you need the management tools to do that lifting otherwise you're going to be adjusting IIS on every single Remote Desktop Gateway, AND connection broker.

That's a pathway to make your hair fall out.

 

[HCHTech]

That's not a bad idea... this time make sure the RDS servers are using PUBLIC NAMES, BEFORE you run the wizards.

Ok, just so I'm clear - define "using public names" - I thought the wizard was where you would specify the single public FQDM, and that was only for the gateway. Before I run the RD setup wizard, that server would be accessible publicly only because of the traffic forwarding rule in the firewall, whose destination is an IP address. From inside the network, it would of course be accessed by it's local host (netbios) name. The RDSH server was never setup to be directly publicly accessible, and from my reading, shouldn't have to be.

In my desired setup I have 3 servers, the DC, the AppServer (which has all of the RD roles except session host) and the RDSH server, which is the session host. The only one that gets hit directly from outside is the AppServer since it has the web access and connection broker roles. Are you saying that both the AppServer and RDSH server need to have public DNS names (as both would have A records on Cloudflare, who has my DNS)? I'm being a little intentionally obtuse here just so I understand exactly. This merry-go-round was fun for the first several spins, I'd like this next one to the the last, if you know what I mean.

 

[Sky-Knight]

@HCHTech, Yes, they all should have public names. They won't all be publicly accessible... but they all need public names. I don't say this because I know they have to be that way, I say this because the basic design assumption for all Microsoft stuff these days is based on it, and when you violate that you wind up with the wizard not doing the lifting for you.

So I'm assuming that use of public names in the entire RDS infrastructure will enable the wizards to get you to a working configuration faster, and are more likely to maintain that working configuration for years to come so you get to keep your hair.

Which means you build an AD DNS zone for your public name space, and you put stuff in there to support all that internally. Which does create a headache, because you'll forever be stuck manually synchronizing the public dns zone and the private one. And you will screw that up from time to time and make headaches for yourself. But that's ONE KNOWN and consistent headache you can learn how to handle and be done with it forever. As opposed to who knows how many other little unknown headaches that comes from using technology outside it's design philosophy.

KISS principle... stick to the defaults... THAT is what's telling me to make all RDS stuff publicly named. And so far, it's served me well. I haven't setup anything on 2019 yet, but I have done a couple of RDS 2016 installs that way, and they're happily running today. Or at least, I assume they are... pandemic cost me those clients so I don't know for certain. But both were ~3 years old before that and I never touched them after deployment other than the occasional reboot because Windows.

 

[HCHTech]

So I'm assuming that use of public names in the entire RDS infrastructure will enable the wizards to get you to a working configuration faster, and are more likely to maintain that working configuration for years to come so you get to keep your hair.

Which means you build an AD DNS zone for your public name space, and you put stuff in there to support all that internally. Which does create a headache, because you'll forever be stuck manually synchronizing the public dns zone and the private one. And you will screw that up from time to time and make headaches for yourself. But that's ONE KNOWN and consistent headache you can learn how to handle and be done with it forever. As opposed to who knows how many other little unknown headaches that comes from using technology outside it's design philosophy.

Ok, good enough. The last AD I setup for a client I did that way. I'm don't have any evidence that it's "better" than the old way, but I guess "It's still working" is enough evidence.

I did wipe everything out and start over this evening - I created the server VMs and updated them, and found a stopping place after adding AD & DNS to the DC. I did choose ad.[mydomain].com for the domain name as opposed to the old-school ".local" method like I did the last time, so here's hoping you're right. It makes sense that the wizards would prefer the new way of doing things - it doesn't make sense that those same wizards wouldn't warn you off of the old way, considering how much history those methods had behind them.

 

[Sky-Knight]

@HCHTech Yeah... but when MS training and certification changes, I think they "assume" we know. They don't hand hold on that level, never have.

 

[trevm999]

Just the RD Gateway and RD Web would need to be available via public DNS. The Connection broker could be public DNS so that you can use a trusted certificate for it, since the cert on that server will be checked after the RD Gateway.

 

[trevm999]

I've never run the session broker on the rd Gateway before, so maybe that could cause some strangeness.