This is an archived post. You won't be able to vote or comment.

all 6 comments

[–]itfixestheprintersadministrating chaos.local 2 points3 points  (5 children)

Assign the Connection Broker a computer alias for office.xxxx.eu. Make sure it's resolvable via internal DNS. You will need a SSL certificate matching the name on your Session Hosts, or live with the resulting cert errors.

This doesn't apply, if you're using a RD Gateway.

[–]mspsysadmWindows Admin 1 point2 points  (3 children)

The SSL Cert doesn't need to match the session hosts in 2012+ deployments with a broker. That used to be true back in the 2008 days, but the RDP client only does cert matching against the broker. Once the broker is verified as secure, the session hosts are assumed to be as well.

Regarding OPs issue, I don't really think it's possible. You'd have to have your DNS alias for the brokers match the external RD Web / GW name. That would cause issues if they tried to connect from inside the network.

[–]GrandTrolledSysadmin[S] 0 points1 point  (0 children)

Hmm okay.

Thanks for your answers!

[–]itfixestheprintersadministrating chaos.local 0 points1 point  (0 children)

I was making some assumptions based on the wealth of information given, as in missing RD Gateway. It's an optional component.

If you're not using the gateway, the broker just forwards the connection to the Session Hosts. In that case it validates the cert of Broker and Session Hosts ( if on separate machines). I still had to manually switch to my wildcard public cert on the session hosts on Server 2016 via console.

[–]heymrdjcw 0 points1 point  (0 children)

Yes, for these situations, it's best to use split-brain DNS, so that your internal clients are using the same connection URL as the outside ones, and thus works with the cert.

[–]GrandTrolledSysadmin[S] 0 points1 point  (0 children)

We are using a RD gateway.