In part 1, I went over the various components needed to flesh out our redundant Microsoft Server 2016 RDS farm. Here in Part 2, we’ll begin to install the three most crucial pieces which includes the gateway, web access and connection broker role. Microsoft has made it extremely simple to get your farm up and running in minutes. Yes, literally minutes. That was one of the things that shocked me the most when I first attempted this lab. Citrix XenApp 6.5 was a pretty straight forward installation for what we needed it to do in our environment but Microsoft RDS 2012 and 2016 is even more simple. Let’s begin!
Part 2: Installation of Gateway, Web Access and Connection BrokerI will be assuming at this point that you have your domain controller installed and configured as well as having your two session hosts all prepped and ready to go. All future servers will be joined to the domain and I will be using the default domain Administrator account for all installation scenarios.
Installing Connection Broker, Web Access and Session Hosts
The installation is wizard driven and Microsoft made it so easy that only a couple of clicks is all that’s needed to get your RDS farm up and running. First, what we need to do is determine which server you’ll want to use as the management server for your farm. Basically, you’ll use this server to configure certain settings related to the farm but more importantly, it’s also the server where you’ll be creating the session collections for your users. In my example, I will be using RDWS01.lab.local as my management server. To begin, we first must add all of the other servers that will hold the roles we need into Server Manager. In my example, I just need to add my two session host servers as well as both of my servers that will hold the gateway, web access and connection broker roles.
We’re now ready to begin the actual RDS installation. Click on Manage –> Add Roles and Features. In the Installation Type, choose “Remote Desktop Services installation”.
For deployment type, choose “Standard deployment” option.
For deployment scenario, choose “Session-based desktop deployment”.
Specify your RD Connection Broker server. You will only be allowed to choose one server to hold this role for now. When we have completed our requirements to building a highly available connection broker role, we will then be able to add our second connection broker server but not before then.
Specify your RD Web Access server. Oddly, you’re also only able to choose one server here for this role although adding a second server requires no other prerequisites from what I can tell. We will add the second server after this wizard installation completes.
Specify your session host servers.
At the confirmation screen, enable the checkbox to restart the servers if a reboot is required and hit Deploy.
Once the deployment has succeeded, head over to the Remote Desktop Services tab and under the Deployment Overview section, you’ll get to see which pieces have been configured (grayed out) and which one’s have not (green + symbol).
The very next thing we’ll want to do is add our second web access server by right-clicking on the relevant icon and choosing “Add RD Web Access Servers”. We would then choose our second server.
Installing the Gateway and SSL Certificate
Our next step is to install the RD Gateway feature. Click on the green + icon for the RD Gateway icon to begin the wizard and select your gateway servers to be included.
In the certificate screen, enter in the external facing name you wish to use for your gateway. This FQDN is what you would use for the Common Name on the certificate request we will be creating next. Once the gateway role has been installed, the green + symbol should then disappear in the Deployment Overview section.
At this point, we have our four main RDS pieces installed. What we need to do next is generate our SSL certificate CSR so that we can obtain a certificate from a publicly trusted certificate authority. To do so, we head over to IIS Manager. In Server Certificates, you’ll want to select the “Create Certificate Request” link and fill in the info according to your requirements. Your “Common name” would be the FQDN that users will connect to when accessing your farm from the Internet. Once your certificate authority of choice has issued your certificate, you can complete the request in IIS Manager by clicking on the appropriate link and pointing to the certificate file.You can purchase a three year SSL certificate for as low as around $15 by using www.cheapsslsecurity.com and selecting the Comodo Positive SSL option. I’ve used them for past projects and labs and it is very easy to setup. I would not use them to secure my production servers but lab demos is definitely fine. There is also the Let’s Encrypt initiative which allows anyone to get a free SSL certificate! The certificate is only good for 90 days but renewals are free. This blog is actually secured with a certificate from Let’s Encrypt! At the moment I haven’t tried to use this initiative yet so maybe a future blog post I will go over on how to do it.
Once we have that installed in IIS, we should now export the private and public keypair. Double click on your newly installed certificate, go to the Details tab and hit the “Copy to File” button to begin the Certificate Export Wizard. Select the “Yes, export the private key” option. On the next screen, accept the default selected option but make sure that you don’t select the option to delete the private key if the export is successful! Next, choose to protect your keypair by specifying a strong password. Finally, specify location to save the keypair. Once the export is successful, we can then proceed to securing our web access and gateway roles. Also, I recommend you storing this PFX file in a safe external location as you’ll be able import and reuse this certificate on a different server in the future.
Back in the Deployment Overview, select the TASKS menu and then “Edit Deployment Properties”. Select Certificates. At the moment, none of the roles have a certificate binded to them. So, select RD Web Access and click “Select Existing Certificate” button. Browse to your newly exported certificate, specify the password used and then select the option box. Hit the Apply button to apply the certificate to the role. You must apply each certificate separately to each role even if you are reusing the same certificate. Once the web access role is done, perform the same steps but for the RD Gateway role.
Creating a Session Collection
The last step is creating a session collection. This is basically a template of sorts that specifies the resources, whether that be remote applications or session based desktops, a user or group have access to in your RDS farm. These resources are what a user will see once they have successfully signed in via RD Web Access. To create a collection, simply right-click on the RD Session Host icon and selecting the appropriate option.
Give the collection a name, specify which session host servers will host the apps or desktops, select your user groups, disable “user profile disks” and then confirming your selections.
What we have done here is create a pooled session desktop for our user group. They will be able to login to either of my two session host servers. At this point, your RDS farm is actually all but configured for testing internally. Login by using the URL of https://localhost/rdweb. You should then see the familiar RD Web Access login page. Login with a user account that has been granted access to the session collection we’ve just created and you should then see the pooled session desktop icon available for use.
By default, local address in your internal network will bypass the RD Gateway when connecting to the session host servers. If you don’t want this behavior and want to force all user traffic to go through the gateway, then in the RD Gateway page in Deployment Properties you’ll want to uncheck the “Bypass RD gateway server for local addresses” option.
At this stage, our RDS farm has been created successfully with a publicly trusted SSL certificated binded to the gateway and web access role. In part 3, we’ll begin configuring our Netscaler HA pair along with making our connection broker highly available by using a dedicated SQL database!