In this multipart blog series, I will go over step-by-step on how to build a fully redundant Microsoft Remote Desktop Services 2012/2016 farm in conjunction with a Netscaler VPX front end. This series isn’t really meant for the average home or casual users but more so for system administrators looking at a low cost solution in providing their workforce with the ability to connect back to their corporate network to consume remote apps and desktops. I am writing this series at the same time I am completing these very steps in my work lab so this blog also serves as a note for me when I do have to implement it in production at a future date. In this very first post we’ll go over what components are needed in your infrastructure to build such a farm redundantly. I have scoured and poured over a lot of different articles on how to put this lab together so I’m just piecing them all here in hopes that it will help other administrators out when trying to do something similar! This lab is also excellent if your company is looking for a Citrix XenApp alternative. Although Citrix XenApp is the leader in remote access technologies, there are many out there, including us, that cannot justify paying the extra cost. This is especially true if you aren’t taking advantage of all the extra bells and whistles Citrix has to offer either because it adds an additional layer of complexity or simply because they aren’t needed at all.
Part 1: RDS Components Explained and Requirements for Lab
Ideally for this lab, all Windows server should be Windows Server 2016 but my lab here will have a Windows Server 2012 R2 for both my domain controller and session host. This shouldn’t be a problem as a Server 2012 R2 session host will be able to join a 2016 RDS farm without problems. However, the reverse is not true. Also keep in mind that although a session collection must contain Windows Server of the same version, you can however create different collections for each of the different Windows Server session host OS. Microsoft also recommends that your RD Licensing server role also be on Server 2016 as it has the ability to dish out user CAL’s for all prior version of Windows. This is a non-factor in our lab because by default, Windows will allow you to remote into the session hosts without any user CALs for quite some time before you’ll be rejected. Once our lab has completed, we’ll be easily able to connect to our farm on any device that supports the RDP client such as PC’s, Mac’s as well as Android and IOS based devices like tablets and phones.
Let’s get started!
Below are the VMs and components needed with a brief description of their role along with the internal IP address being used in my lab.
Virtualization Platform = VMware vSphere
You most likely could utilize the free Microsoft Hyper-V to lab this out as well. I was actually at first using VMware Workstation on my home lab computer but decided to use work resources instead due to SSD space running out.
Active Directory Domain Name = lab.local
This is my internal domain name.
ADFS.lab.local / 10.40.77.201
This is my domain controller. In a production environment, you’ll obviously have at least two but a single DC is enough for this lab to showcase the redundant capabilities of RDS itself.
RDWS01.lab.local / 10.40.77.205
This server serves as my RD Gateway, RD Web Access and Connection Broker. In addition, this server will also be the management server where I will be managing all of the other roles on the other servers in the RDS farm. We do this by adding the other servers to be managed in Server Manager.
The gateway is an optional piece in the RDS farm setup but if you’ll want external users to connect to your farm, you’ll definitely want to use a gateway. By using one, clients will actually connect to the gateway via port 443 and not your usual RDP port of 3389. This makes it much more secure and easier to configure since wherever the users are located, chances are port 443 will be allowed on the external firewall. Do remember that all client traffic will actually pass through the gateway once their session has been established.
The web access portion allows users to get access to resources by signing into a secure website. Once authenticated, the users will see a list of resources that they are allowed to access. Administrators familiar with Citrix can think of the web access portion as the Storefront or Web Interface equivalent.
The connection broker is the central piece that keeps track of clients session states. When you have a session host farm consisting of dozens of Windows Server, a single user could be using any one of them. When they disconnect and reconnect, the connection broker consults its data and will redirect the user back to their original server so that they can continue working right where they left off. This piece is also responsible for determining which session host to direct a user to when they first try to access resources.
RDWS02.lab.local / 10.40.77.206
This server serves as my secondary RD Gateway, RD Web Access and Connection Broker.
CBSQL.lab.local / 10.40.77.207
This server serves as my SQL server for the database needed to create the highly available connection broker role. In addition I will be using SQL 2016 with SP1 Standard Edition as the database. This will also work on the SQL 2012 Standard edition. I have not tried this lab with any version of SQL Express nor will I recommend you doing so.
RDS01.lab.local / 10.40.77.211
This server serves as my first session host and is the server that will host the remote apps and session desktops for your users.
RDS02.lab.local / 10.40.77.212
This server serves as my second session host.
Netscaler VPX 12 Freemium Edition / 10.40.77.215
This will be my Netscaler’s IP (NSIP) used for the management of the Netscaler VPX appliance itself. Although the Netscaler technically is an optional component in an RDS Farm, it is highly recommended that you use some sort of front end device to perform the load balancing of the gateway servers and connection brokers rather than relying on Windows Network Load Balancing and DNS Round Robin, respectively. Since this is only a lab, feel free to explore other load balancers once you get your lab up and running smoothly. Once you use a dedicated front end load balancer, you’ll never want to go back. The only negative is that the learning curve can be quite steep depending on what you are trying to accomplish as well as adding to your overall project cost should you decide to move into production. The one awesome part concerning the Netscaler in our lab here should you take it into production is that no extra licenses are needed! You’ll only have to worry about purchasing the right edition based on maximum bandwidth needed to support your environment.
With the newest version of Netscaler 12 VPX, the Express/Free version is now called the Freemium edition (although the license mode is still Express). This version is completely free of charge to use in production but is limited obviously in features available but more importantly, is limited to only 20Mbps bandwidth. You are able to fully follow this tutorial using this Freemium edition without having to worry about licenses! You can even use this Freemium edition of Netscaler in production to host a small group of session servers for a small group of users all without paying a single penny. And yes, you can even use this edition to setup HA mode!
Netscaler VPX 12 Freemium Edition / 10.40.77.216 (optional)
This will be the Netscaler’s IP (NSIP) for the secondary HA node. If your primary node is offline for any reason, this secondary node will take over all the IP’s (except the NSIP) and configuration settings of the primary node. This secondary node will then serve as the new primary node while the other Netscaler will then be considered the new secondary. This secondary node is optional for this lab but once you see how simple it is to configure a Netscaler HA pair, it wouldn’t make sense for you to not put this in your lab. You’ll get to see firsthand how awesome it is when utilizing a Netscaler HA pair fronting your RDS farm!
This will be the IP used as the Netscaler’s Subnet IP address (SNIP) to connect back to our back-end RDS farm servers.
RDCB.lab.local / 10.40.77.208
This will be the IP used by the Netscaler as the virtual server hosting the connection broker load balancing front end. Rather than configuring for DNS Round Robin, our HA connection broker name will resolve to this single IP address and the Netscaler will take care of loading balancing the requests to our two servers. DNS Round Robin has no failure detection mechanism so if one of the servers fail, it will still route requests to that server. Netscaler and other load balancers have logic built into them so that when it detects a server is down, it will stop routing requests to that server immediately.
This will be the IP used by the Netscaler as the virtual server hosting the front endpoint for all external client connections. This is where the magic happens.
Public IP Address NAT’ed to Main Virtual Server
In my case, my main virtual server would be the 10.40.77.220 IP on the Netscaler.
Port Forwarding TCP 443 and UDP 3391 (optional)
You will need to forward these two protocols and ports to your main virtual server. Although UDP 3391 is optional, it is highly recommended that you do this to allow a much better and smoother remote user experience.Because UDP is a connectionless protocol, it has less overhead than TCP and therefore is able to provide a better remote session experience for users. This is especially true if the remote users are connecting to your farm over a slow WAN link.
Publicly Trusted SSL Certificate (optional)
This certificate will secure the external namespace used for the connection point of RD Web Access as well as the RD Gateway server. Although optional, it is highly recommended that you purchase a publicly trusted certificate to save you the work and hassle of having to install the untrusted certificate on your test machines. Because we are building a HA connection broker which will utilize a separate namespace, you can choose to either purchase a SAN certificate to secure two names on a single SSL certificate or do what I did to save money by using the public certificate to secure just the external name, which is more important of the two, and utilizing a self-signed certificate to secure the connection broker name. You can purchase a cheap three year SSL certificate for just $15 over at https://cheapsslsecurity.com and choosing the Comodo Positive SSL option. You will be able to reuse this certificate for future labs so your money is not wasted after this experiment has ended!
Publicly Registered Domain Name
You will need your own personal domain name for testing purposes as we will need to create a DNS record pointing our public IP address used for this lab to the name used in our SSL certificate. For security purposes, I will not be showing the pubic IP address nor the external name I used for my lab.
As you can see, there’s quite a lot of pieces that goes into creating this redundant RDS farm! It definitely can be daunting at first but I honestly think it’s not too bad once you explore the individual pieces by itself. The most beastly component of this lot is definitely the Netscaler. It can be as complicated as you want it to be or as simple as well. Luckily, our lab falls into the “simple” category as it will only take us less than 10 minutes or so to configure.
In the next article, we’ll begin building out RDS pieces such as the gateway, web access and the connection broker.