RDS Farm 2016 creation with High Availability and Autoscaling – Part 1

With this new blog post, our partner Hugo Margallo will detail how to build a Windows Server 2016 farm using the roles of Remote Desktop Services and deploying them on a hierarchical cloud infrastructure of 4 servers.

A minimum installation of RDS with high availability could be done with 3 computers, but I will use 4 so that the roles are more defined, so that my domain controller will not have any RDS roles, although I can monitor the farm.

I will divide this entry into 3 parts as a result of the large amount of content and extension of the topic and will be published progressively during these three following weeks. In the first blog post, the configuration of the first aspects of the farm and the set-up for the optimal deployment of the farm will be explained, the second part will focus on its functionality and operability; and finally, in the third and last blog entry I will configure the certificates necessary for safe operation and, in addition, I will explain the scripts that can be used to make the farm self-climbing automatically.

A complete installation of RDS would require machines with the “RD License server” role, which would provide the necessary licenses to the equipment, but we will not go into detail because it is less relevant than the other roles.

The infrastructure consists of the following equipment:

  • EnimbosDC: It is the domain controller “enimbos.local“. It will be in charge of installing the necessary roles in the rest of the teams and will carry out the deployment. Everything can be managed and monitored from here. It will also have the role of “Certificate Authority” of the domain. All certificates will be authorized by this machine and will be reliable within the domain itself.
  • EnimbosBroker1: It will be in charge of managing the connections of the external equipment to the RDS hosts. To do this, it will use balancing functions and will work in high availability with EnimbosBroker2. All connections will be directed to one of the two computers using a common DNS running with Round Robin. Specifically, this equipment will also work as a Samba file server that will share certain routes to facilitate file transfer and autoscaling functions, as we will see later.
  • EnimbosBroker2: It will handle the same functions as EnimbosBroker1 with the addition that it will also serve as a web server to offer the RDP file to all domain users through a URL to login.
  • EnimbosHost1: It will be the first of the “Session Host” to which domain users can connect remotely. This equipment will always remain active regardless of the growth or decrease of the RDS farm.

The other teams will be added and removed through scripts that provide autoscaling and all will have the role of “Session Host“, just like EnimbosHost1.

1.Domain Controller Creation

Once we access the EnimbosDC equipment remotely, we must access the Server Manager and install the “Active Directory Domain Services” role as shown in the following screenshot (we must not install any features, only roles):

Click “next” in all the steps of the wizard and check that the server can restart if necessary. Then, we must look at the following message:

If we click on it, we start the promotion assistant for the domain controller team. The first thing the wizard will ask us is whether we must join an existing domain, create another domain or a forest (the main domain from which the rest of the domains start). As we start from scratch, we will select the “bosque” option and call it “enimbos.local”. Of course, this team will also perform the functions of DNS server, so we leave that box checked, only worrying about choosing the functional level of the forest and the domain, which will be in our case Windows Server 2016.

Next we have to enter the password of the directory services restoration mode, which will be “Enimbosblog2018 #”, although for now it is irrelevant.

We will not indicate the creation of a DNS delegation, so we proceed to enter a NetBios name, which in this case we can leave the default one (ENIMBOS), as well as the routes that the domain controller will use for the management of all Active Directory computers and users.

Finally, we only have to check in the assistant if the options we have chosen are exactly as we want them and launch the prerequisite check, that if we have not passed anything, it will give us the approval and we can proceed to the promotion of the equipment.

Note: The user with whom we have run this wizard (which must have administrator privileges), will become the domain administrator user.

2. Join computers to the domain

We need the rest of the equipment that is part of the RDS farm to be in the same domain. The steps to follow are the same for all machines, so I will only show it in the case of EnimbosBroker1.

The first thing will be to allow the domain “enimbos.local” to be resolved by the DNS, so you have to indicate as DNS server the ip of the domain controller, and that we can do it through the control panel, in the configuration of IPv4:

The IP configured as an alternative DNS ( belongs to Google, and will offer us Internet access through the resolution of all WWW domains.

We can verify that it works correctly by pinging “enimbos.local“.

Now that we can resolve the domain name, the next step is to specify that you must join it. To do this, from the control panel / System, we click on the option to change the configuration of the device and in the “Name of the device” tab, choose “Change“. By default, we will see that the equipment belongs to a Workgroup. We must check the domain box and specify “enimbos.local”. When the connection is established by LDAP, the following will be to enter the domain administrator credentials and, if everything went well, we will see a welcome message and we will have to restart the computer, which we can do now or later.

Now EnimbosBroker1 is in domain and we must do the same with the rest.

3. RDS Deployment

To start the deployment we must log in to the domain controller and access the Server Manager. Once there, we must add new domain computers to the “server pool“. To do this, click on “Add Server” in the Manage tab of the Server Manager, and select the computers by name (it can also be done by the IP) as shown in the following screenshot:

If everything went well, in the “All Servers” option on the left menu of the Server Manager we can see the selected computers and have “Online” status, indicating that they can already be managed from there.

To start the deployment, we must first install the corresponding roles on each machine, although it can be done more easily by clicking on “Manage” and “Add roles and Features”. We will see in the wizard that we can directly select to make an installation of Remote Desktop Services.

In the following screens we must choose the option “Standard Deployment” and “Desktop deployment based on session”. Once both options are chosen, we proceed to select which role each machine will have, with EnimbosBroker1 being the first “Connection Broker”, EnimbosBroker2 the “RD Web” (later it will also be a broker) and EnimbosHost1 the first RDSessionHost.

If everything went well, we can see on the left of the Server Manager the option “Remote Desktop Services” and, when clicking, we will be shown a general scheme of the farm indicating the computers that belong to it, as shown in the following screenshot:

The next step will be to configure the brokers in high availability.

4. High availability configuration

Two requirements are essential to configure high availability: a DNS address shared by the two brokers and a SQL Server database that maintains the data. For the first we must access the “DNS Manager“, which can be found in “Tools” (upper right corner of the Server Manager) and then in DNS.

Once inside, we must deploy our domain controller (“ENIMBOSDC” in this case), then the “Forward Lookup Zones” folder and finally “enimbos.local“, which is the name of our domain. Once inside, we will see entries referring to the names of our teams. To add a new entry we must right click on the white background in the right window and select “New Host (A or AAAA)”. There we only have to put the name of our entry dns (“brokerha” in this case) and the first broker’s ip. Then, we must repeat the same step but for the IP of the second broker (the name must be the same), which in our case will be the IP of the team “EnimbosBroker2“, which for now is only RDWeb.

We must also ensure that the DNS server is going to use Round Robin balancing for the proper functioning of high availability (this only applies to two DNS entries that share name but different IP). To do this we click with the second button on our domain controller in the menu on the left, select “properties” and in the “Advanced” tab we must check that the “Enable Round Robin” box is checked. With this we have a certain balance.

Now let’s look at the database. In this case I have set up an RDS in Amazon Web Services (it’s what Amazon calls cloud database managers, nothing to do with the farm) with SQL Server Express, but it could perfectly be a database hosted on the controller domain or other network accessible machine.

First, access that database manager (using SQL Management Studio itself) and create a new database specific to brokers, which I will call “broker” dry and that will be perfectly accessible and modifiable by my SQL Server user by default, called “Enimbos.”

Now we must return to the Server Manager, specifically the RDS scheme.

Click the second button on the drawing of the broker in the scheme and select “Configure High Availability”

In the wizard we must specify “Shared Database”, the full dns address of the two brokers, that is, brokerha.enimbos.local and the connection string, which will depend on the ODBC driver that we have installed in the brokers and the user and base of data that we have created, being in this case as follows:

Driver={SQL Server};Server=tcp:enimbosblog-rds-db.cvpdkpgzesjl.eu-central-1.rds.amazonaws.com,1433;Database=broker;Uid=Enimbos;Pwd=EnimbosBlog2018#;TrustServerCertificate=yes

We can find out the ODBC driver we have by giving “Tools” and “ODBC data Sources (64 bits)”. In the Drivers tab we will see at least one called SQL Server, but we can install others by downloading them from the Microsoft website. It is necessary that the name of the driver be specified with the exact name.

If everything went well, we can now select the “Add RD Connection Broker Server” option with the second mouse button on the broker and we would start a wizard similar to the RDS deployment but having to select only a new broker.

Note: we must allow access to the database, so we will have to configure the firewall on port 1433 (by default) and, in case of using cloud services, the corresponding entry rules in the security group.

So far everything necessary to achieve a complete configuration of the fundamental aspects of an RDS 2016 farm and generate a total set-up to perform an optimal Farm deployment. During the next blog post we will develop everything concerning the RDS farm functionality and operability, do not miss it and stay tuned for our news and social media profiles on LinkedIn and Twitter.

Related Posts