Windows 2016 remote desktop collection not accessible externally

pbhcpa
pbhcpa used Ask the Experts™
on
Hello! We're moving from 2008R2 to 2016 for RDS and we'd like to open it to a test group to iron out any issues before switching. Our '08R2 farm is still operational and working. We've created a 2016 RDSH collection with 1 RDCB, 1 RDGW and 3 RDSH servers. The 3 RDSH servers are in a collection called rdfarm.

The issue: We can successfully connect to the collection internally by using the RDP shortcut downloaded from RWA however, it does not work outside our office. When attempting to connect from a home PC, it shows the correct FQDN but then an error is returned that remote desktop can't connect to the remote computer due to remote access is not enabled, the remote comuter is turned off or the remote computer is not available on the network.

A couple of notes about our deployment:

1) The GW & RWA services are on the same machine.
2) We will not be using RWA for our users, just RDP for connecting externally.
3) Our internal domain is .local, so we have split DNS. We have a forward zone for both rdfarm.domain.com (A record for the IP of rdcb1) and rdgw1.domain.com (A record for the IP or rdgw1).
4) We're using a wildcard cert from GoDaddy and it's trusted on both the GW & CB. It's been installed on all 3 RDSH servers as well.
5) The collection name has been set in the registry of the CB.
6) The firewall rule is this
      rdfarm.domain.com:443->rdcb1

Things we've checked:

1) Port scan shows that port 443 is open and accessible from the IP and FQDN for the collection externally.
2) A packet capture shows traffic is coming in through our firewall to rdcb1.

Any suggestions on what we could check to see why the RDP connection is unsuccessful?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Distinguished Expert 2018

Commented:
If you aren't using the RDWA shortcut externally, the RDCB has no way to know which collection you want to connect to (even if you only have one collection, it won't make an assumption) and therefore it won't redirect your request.which generates that error.

The RDP files that RDWA generates include a collection name in the file. This property CANNOT be manually entered in the GUI.
pbhcpaIT Director

Author

Commented:
The RDWA generated shortcut is being used.
Distinguished Expert 2018

Commented:
Your firewall rule is wrong as well. Pointing 443 to the CB does nothing. You are trying to bypass the GW, which defeats the purpose of the GW. And the CB doesn't listen on 443.
Become a CompTIA Certified Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

Distinguished Expert 2018

Commented:
And step/point 5 simply doesn't make sense to me. In a properly set up environment, you don't set anything manually in the registry. The RDCB does intelligent load balancing and will redirect to individual machines as needed. Setting the farm name in the registry just doesn't make sense.
pbhcpaIT Director

Author

Commented:
Thank you for your input. Before responding to your points, I'm going to go back over the several different documents we followed for setting this up.
pbhcpaIT Director

Author

Commented:
Regarding step 5, we found in the documentation that the registry setting was only needed if you were doing SQL HA load balancing with your connections brokers. We've removed that but we're pretty sure it wouldn't affect our ability to connect externally.

We're still looking for where it was documented to point to the CB vs the GW. We thought that was strange too since our original '08R2 farm points to the GW.
pbhcpaIT Director

Author

Commented:
After making the recommended changes pointing to the GW instead, we now get this if we attempt to connect internally or externally with the RDP shortcut from RWA after entering our login credentials:

2018-09-13-15_39_48-M7.png
The user account is a member of the group specified in the CAP/RAP policies. There is a corrected forward zone in DNS for the FQDN (rdfarm.domain.com) that includes an A record pointing to the internal IP of the GW (10.10.40.13).

The firewall record is now: rdfarm.domain.com:any->rdgw1:443.
Distinguished Expert 2018

Commented:
Those three possibilities are pretty accurate.  

1) Could be a policy issue with the CAP/RAP policies (I always recommend keeping defaults first, then customizing *AFTER* you have the platform working.  Right now you have no way of verifying if this *EVER* worked.)

2) See #1.  Policies can be created in a way that specifically exclude machines that have trust issues (SSL related often)

3)  Could be testing with a server out of date on patches.  Or a client out of date on patches.  In particular, there are the Oracle remediation patches from March that need to properly match.
Distinguished Expert 2018

Commented:
And just to clear this up, even internal connections start out using the Gateway.  There is a checkbox to bypass the gateway for internal connections, but that still needs to establish the connection (via the gateway) to determine if the redirect is internal or external.  So this is purely a gateway/client configuration issue and yes that does impact internal connections.
pbhcpaIT Director

Author

Commented:
Thank you very much for your responses. I'm going to respectfully disagree with it being a CAP/RAP policy issue because I didn't state that I changed the CAP/RAP policies, I was just clarifying the membership of the user we are testing with just to be thorough and it was working internally prior to the changes I listed. For further clarification, the only change that was originally made in each policy during the initial setup was to the user groups and that was from Domain users to RDSLicensedUsers, which is the group we use to manage user access in our current RDS farm.

Bypassing the gateway for internal addresses is not checked.

All servers in this farm are current on Windows updates. There is no other software installed on any of them besides Notepad++. The test PC, which is a Windows 10 Pro machine, is current on updates as well.
Distinguished Expert 2018

Commented:
" I'm going to respectfully disagree with it being a CAP/RAP policy"

Agree.  Disagree.  Whatever.  I didn't say it *was* a problem.  Given the error you posted, I said it was a *POSSIBILITY.*

" I didn't state that I changed the CAP/RAP policies, "
" the only change that was originally made in each policy "

Right.  So you made changes.  You may or may not have made them or reverted them properly.  And you clearly followed bad guidance earlier.

In short, this is a forum. I can look at what was posted and make some LIMITED guesses and advice.  You have a few choices:

1) Take the advice as given and try to figure it out.
2) Hire a consultant who can actually LOOK at these things instead of guess.
3) Do your own thing and take pot-shots at volunteers helping.


If this is a new setup not yet in production, I might advice to hit the self-destruct button then start over without registry entries, changed policies, or bad documentation that has you forwarding ports to the RDCB.  Find the official docs and follow them for a clean trusted install.

Other than that, I believe I've hit the edge of what can be recommended over a forum given there are clearly multiple misconfigured items and a resistance to consider the possibilities of the cause.  Maybe another expert will chime in.  But I have nothing currently left to offer.
pbhcpaIT Director

Author

Commented:
Thank you for your time, we'll see if someone else can provide suggestions.
pbhcpaIT Director

Author

Commented:
Since this has not become an actual production environment yet and it was noted that we possibly followed some incorrect documentation, we rebuilt the farm from scratch following only these 2 documents:

https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/rds-deploy-infrastructure
http://www.jschweg.com/2016/12/properly-configuring-ssl-certificates-for-remote-desktop-services/

After doing this, we cannot access it internally. Here is the current error:

2018-09-19-08_52_23-RD-Web-Access---.png
Updated notes about our deployment:

rdgw - remote desktop gateway
rdcb - remote desktop connection broker

1) We are testing with the RDP shortcut downloaded from RDWA.
2) No CAP/RAP policies have been modified.
3) The GW & RWA services are on the same machine.
4) We will not be using RWA for our users, just RDP for connecting externally.
5) Our internal domain is .local, so we have split DNS. We have a forward zone for both rdfarm.domain.com (A record for the IP of rdgw) and rdcb.domain.com (A record for the IP of rdcb).
6) We're using a wildcard cert from GoDaddy and it's trusted on both the GW & CB. It's been installed on all 3 RDSH servers as well.
7) We have a public DNS A record for rdfarm.domain.com.
8) The firewall rule is this
      rdfarm.domain.com:443->rdgw

Any input on what to look at would be appreciated.
IT Director
Commented:
Since there were no further responses, we opened a case with Microsoft. The tech verified all of the settings and confirmed they were correct. After 1.5 hours of combing through logs and testing different items, it turns out that on the gateway, there was an error 201 in the Event Viewer (under Application and Service logs | Microsoft | Windows | Terminal Services-Gateway | Operational) that read: "The user "domain\username", on client computer "IP Address", did not meet connection authorization policy requirements and was therefore not authorized to access the RD Gateway server. The authentication method used was: "NTLM" and connection protocol used: "HTTP". The following error occurred: "23003". This led the technician to research it. He reached out to AD services at Microsoft and they told him about NPS, which we don't use but is enabled on a GW server.

The fix? Click Start | Administrative Tools | Network Policy Server. Right-click on "NPS (Local)" at the top left of the tree and left-click on "Register server in Active Directory".

The technician even admitted he wasn't familiar with this setting and if another team he consulted hadn't told him to check it, he wouldn't have. He said they told him an oversimplified version of an answer is that it registers the server to manage RAP/CAP policies in conjunction with AD.

Maybe this will help someone else if they run into this issue.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial