Windows 2016 remote desktop collection not accessible externally

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?
pbhcpaIT DirectorAsked:
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

x
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Cliff GaliherCommented:
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.
0
pbhcpaIT DirectorAuthor Commented:
The RDWA generated shortcut is being used.
0
Cliff GaliherCommented:
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.
0
The Five Tenets of the Most Secure Backup

Data loss can hit a business in any number of ways. In reality, companies should expect to lose data at some point. The challenge is having a plan to recover from such an event.

Cliff GaliherCommented:
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.
0
pbhcpaIT DirectorAuthor 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.
0
pbhcpaIT DirectorAuthor 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.
0
pbhcpaIT DirectorAuthor 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.
0
Cliff GaliherCommented:
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.
0
Cliff GaliherCommented:
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.
0
pbhcpaIT DirectorAuthor 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.
0
Cliff GaliherCommented:
" 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.
0
pbhcpaIT DirectorAuthor Commented:
Thank you for your time, we'll see if someone else can provide suggestions.
0
pbhcpaIT DirectorAuthor 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.
0
pbhcpaIT DirectorAuthor 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.
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Remote Access

From novice to tech pro — start learning today.