We help IT Professionals succeed at work.

Windows 2016 remote desktop collection not accessible externally

727 Views
Last Modified: 2018-09-25
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

CERTIFIED EXPERT
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.
CERTIFIED EXPERT
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.
CERTIFIED EXPERT
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.
CERTIFIED EXPERT
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.
CERTIFIED EXPERT
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.
CERTIFIED EXPERT
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:
This one is on us!
(Get your first solution completely free - no credit card required)
UNLOCK SOLUTION

Gain unlimited access to on-demand training courses with an Experts Exchange subscription.

Get Access
Why Experts Exchange?

Experts Exchange always has the answer, or at the least points me in the correct direction! It is like having another employee that is extremely experienced.

Jim Murphy
Programmer at Smart IT Solutions

When asked, what has been your best career decision?

Deciding to stick with EE.

Mohamed Asif
Technical Department Head

Being involved with EE helped me to grow personally and professionally.

Carl Webster
CTP, Sr Infrastructure Consultant
Empower Your Career
Did You Know?

We've partnered with two important charities to provide clean water and computer science education to those who need it most. READ MORE

Ask ANY Question

Connect with Certified Experts to gain insight and support on specific technology challenges including:

  • Troubleshooting
  • Research
  • Professional Opinions
Unlock the solution to this question.
Join our community and discover your potential

Experts Exchange is the only place where you can interact directly with leading experts in the technology field. Become a member today and access the collective knowledge of thousands of technology experts.

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

OR

Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.