Deploying the RD Gateway Service Role in a 2012 / 2012 R2 RDS Farm

Applies to: Windows Server 2012 and 2012 R2

For any RDS farm, there is a very good chance users will be accessing the farm from a remote location outside of the corporate network. When doing so, it is critical to secure their connection, especially when corporate data is being accessed. In order to secure a user’s connection into a RDS farm, a RD Gateway server will be required. The RD Gateway enables authorized remote users to connect to resources in an internal corporate or private network, from any Internet-connected device that can run the Remote Desktop Connection (RDC) client. The network resources can be RD Session Host servers, RD Session Host servers running RemoteApp programs, or computers with Remote Desktop enabled.

The following will cover the steps needed in deploying a RD Gateway Server into a 2012 / 2012R2 RDS farm. Before deploying the RD Gateway Server, the RDS farm should already be built and configured. Please check out the following for more information on deploying a 2012 / 2012R2 Remote Desktop Services (RDS) farm.

Requirements:
Existing 2012 RDS Farm
SSL Certificate along with its private key.
Designated domain joined Windows 2012 / 2012 R2 server
 

Within Server Manager, highlight the Overview section of the Remote Desktop Services node. Inside the deployment section, click on the RD Gateway button.

1

A wizard will come up which will ask you to select the RD Gateway server. Find the designated server, add it, and hit next. Here our designated server is RDGWY01.

2

It will then ask for the FQDN which will be used to connect to the RD Gateway Server. This must match the FQDN listed on the SSL certificate which will be used for the deployment. Enter the FQDN and hit Next. In our example, our SSL certificate and RD Gateway FQDN is remote.demolab.int.

3

Confirm the settings and hit Add.

4

Once completed, click on the configure certificate link in order to install the SSL certificate.

5

On the Manage Certificate window, highlight the RD Gateway Role service and click on the button “Select existing certificate”.

6

The certificate we will be using for our RD Gateway is located in the directory \\dc01\d$\Certs. Click on the browse button.

7

Locate and select the certificate and hit the open button.

8

Enter the password for the certificate and check the box “Allow the Certificate to be added to the Trusted Root Certification Authorities store on the destination computers”.  Hit OK.

9

Back on the deployment properties screen, hit apply.

10

Once it is applied successfully, close the deployment properties window and the RD Gateway wizard.

11

Congratulations! You have successfully deployed the RD Gateway server for your 2012 /2012 R2 Remote Desktop Farm.

© 2014 Eddie Kwasnik “the Wolf” All Rights Reserved

, , , , , ,

  1. #1 by Has on April 13, 2014 - 3:49 pm

    Hi,
    Thanks for this great guide. Can you please advise where on the network the RDS Gateway should be placed? For Server 2008R2, if you placed it in the internal LAN, you had to place TMG in front of it (I’ve seen TMG placed in the DMZ and in the LAN). As TMG (and UMG) are being retired, what options do we have for placing the RDS GW in the internal LAN? For example, can Server 2012R2′ s secure application publishing help in any way?
    Thanks,
    Has

    • #2 by Eddie Kwasnik on April 14, 2014 - 2:45 pm

      Great question. One of the things Ive always had problems with, is the fact the RD Gateway has a requirement of being domain joined. This is needed in order to process the RD Gateway CAP and RAP policies. By using a server like UAG or TMG, it gives an added set of protection. With 2012 R2 as far as I am aware of, there is no requirement to place a TMG or UAG server in front of the RD Gateway server.

      For the clients I’ve worked with, I went over the different firewall rules and security concerns needed for both scenarios and based on their company’s security requirements allowed them to make the decision of the location of the RD Gateway server. Either location is still a concern since the server is still domain joined. The easiest is to have it within the LAN since there are fewer firewall rules to make, but it doesn’t make it the most secure. Another alternative is to incorporate a device similar to Big-IPs F5 device with the RDS environment.

  2. #3 by aspiringmaniac169.jimdo.com on May 7, 2014 - 8:42 pm

    L’eոsemble de cces ρosts sont sincèrement instructifs

  3. #4 by Joe Sparks on June 9, 2014 - 4:28 pm

    I did all this and the cert error has went away, but I can not get access from the outside. I put the GW in the DMZ and created the necessary rules, joined it to the domain and can even remote in to manage. I then assigned a public IP to it and created a DNS entry on our ISP. I did a nslookup on the name and it resolved but when I try and get to the site using a brower from an external ISP I get a “This Page Can’t Be Displayed” it would be better if I at least got an IIS error. Any idea’s?

    • #5 by Eddie Kwasnik on June 9, 2014 - 10:43 pm

      Did you install the rd web access role on the gateway? If not, add the role to the gateway server.

      • #6 by Joe Sparks on June 9, 2014 - 11:24 pm

        No I did not, I will do that tomorrow

        Sent from my Windows Phone ________________________________

    • #7 by IvanN on July 6, 2015 - 5:35 pm

      Joe, were you able to resolve your issue and if yes, how? We’re in exactly same situation right now as yourself and when we install the Web Access role (which we’re not sure if required) we are able to get to the site (rdweb), but it’s blank without any collections and we believe that’s because we have a separate Web Access server on the inside subnet along with the rest of the RDS environment (broker, session hosts). Appreciate your input.

      • #8 by Joe Sparks on July 7, 2015 - 1:34 pm

        No I did not get it figured out and then I got put on a different project. If you find out what it was I would be very interested in hearing the solution

  4. #9 by Dennis on October 23, 2014 - 5:27 pm

    Hi Eddie, I echo the sentiments of others: great tutorial you have put together – it is good to follow a tutorial with lots of screenshots.

    I am undecided whether to deploy the RD Gateway. If AD DS access is needed from the DMZ to process CAP and RAP then you may as well place the gateway on the LAN, but then I think, well, if the gateway is on the LAN then I may as well allow access from outside directly to the RD broker. Out of interest, what is Microsoft’s recommendation here?

    Cheers, db.

    • #10 by Eddie Kwasnik on October 24, 2014 - 8:52 am

      Dennis, thanks for the kind words! Microsoft will recommend using an RD Gateway. I recommend it as well. Using the RD Gateway server will help protect your environment, not only by securing your user’s session but as well as it will be the only machine exposed to the outside.

      Eddie

      • #11 by Dennis on October 30, 2014 - 11:17 pm

        Thanks Eddie. I have deployed RDG successfully. Two more questions:

        – I configured mstsc by adding in my gateway in Advanced tab > Settings, and I connect to my office PC. What DNS name do I use to connect to my load-balanced farm? Am I supposed to connect to the RDCB or a round-robin DNS name of the farm?

        – What do I need to configure so that from RDWA (“Connect to a remote PC”) I can connect to internal PCs from external? I can connect from internal (same LAN as RDG) but not external – “Remote Desktop can’t find the computer “xyz”.

        Many thanks!

  5. #12 by Julian on January 26, 2015 - 2:25 pm

    Hey! Thank you very much for you’re very good Tutorial. I do everything and it works great, but how can I use the Gateway now as a User? I want to use RemoteApp via rdweb in the INTERNET for my clients, how can I do that? The Tutorial ends a little to early for me 🙂

    • #13 by Eddie Kwasnik on January 27, 2015 - 2:53 pm

      Thanks! Do you have your RD Gateway accessible via the internet?

  6. #14 by Lars-Göran Bäck on November 10, 2015 - 1:09 pm

    Hi! and thanks for a good article. IvanN had a problem that he did’nt get the Collections visible then connecting through Gateway. We have the same problem.We have also installed Webbaccess on our Gateway server, in addition to a “internal” dedikated webbaccess. im not sure about that configuration. We also use Secure envoy for 2 faktor, and that Works, i get athenticated and get my SMS and then it takes a good while until i Reach the webaccess server With no Collections.

  7. #15 by A. Thomsen on February 4, 2016 - 1:48 am

    Hello,
    Thanks for the guide. We have successfully deployed a 20 server RDS farm within our organisation, however we still haven’t deployed the GW since we are unsure where to place. We need to have a secure network, since we are running a national hospital. We working redundant RDWeb, session brokers and SQLs. We have about 15 RSH seerver which will increase in number. Currently, of course, all of these servers are on our internal LAN. Today, users get access via Cisco VPN directly to our RemoteApp (depoyed via GPO) or via RDweb (via browser). We want users to be able to get access without VPN. I don’t want the GW and RDweb on the same servers. Should we create additional RDweb servers on the DMZ along with GW servers? We are consindering a locked down ReadOnly DC server in the DMZ.

    Regards,
    Annfinn

    • #16 by IvanN on March 9, 2016 - 12:45 pm

      Please see my update to this thread. If additional info needed let me know.

  8. #17 by IvanN on March 9, 2016 - 12:36 pm

    Hi guys, IvanN here with an update on how we got it working. So the challenge as we thought it would be was not the Gateway, but the RODC in the DMZ. We ended up building multiple RODCs in the DMZ subnet (for each domain of users that would authenticate through the gateway). I’ll have to say this was the most painful experience I’ve ever been through, but now we can say it is secure (user access, firewall, etc…). Web access HAS to be installed on the Gateway, but it simply becomes a second web access portal on top of the one we built internally. The reason why when we accessed the Gateway and the collections were blank, is because the web access portal on the Gateway was dis-joint from the main RDS configuration (RD broker), as soon as we added the web access role to the Gateway – voila, it all started working (slow, but working). The slowness was being caused by the authentication process (we had RODC for the parent domain, but not child domains). Once we built child domains RODCs in the DMZ and granted appropriate access to the Security Groups within the Gateway everything started working quite fast. We now actually have two farms with one being in the PCI compliant network (really, really restricted) and even that one is working quite fast for us.
    One thing I’d like to mention is how surprised I was to learn that almost no-one out there has configuration that we do (even thought this is Microsoft recommended configuration for RDS access through gateway), because when we contacted Microsoft, they couldn’t reference a single ticket that they had with any other company where the setup was with Gateway+RODCs.
    If you need additional information, message me directly and I’ll try to provide more details. Annfinn – I’ll have to say that the road that you’re stepping on is a long and painful one, but if I can help I’ll certainly try. IvanN

  9. #18 by sri on October 3, 2016 - 11:31 am

    query: RD Gateway has a requirement of being corporate domain joined? irrespective of I place it perimeter network / corporate network .is it right?

  10. #19 by AMH on July 4, 2017 - 6:38 pm

    Hello,

    Thanks for the great article , I have a farm with 2 RDSH , one RDCB/RDWEB , one RDGW. I have setup a NAT on my firewall for 443 to the RDCB/RDWEB server , from inside the network I have no issues accessing the resources but from outside , I get the error that remote desktop gateway server is temporarily unavailable , is there any additional ports that need to be open?

    I greatly appreciate any help in advance,

Leave a comment