Over the past few months I have had the opportunity to implement Remote Desktop Services in Azure.  The strategy of this project was to go beyond a “lift and shift” mentality of an RDS deployment to an infrastructure that will scale on demand and provide for rapid deployment of new resources as needed.  In this post I give a high-level view of the RDS services deployed and the Azure services used to support them.

Running RDS in Azure provides a high degree of availability compared to hosting in a conventional data center.  For example, Azure has native features such as Availably Sets and Load Balancing services to limit interruptions from planned and unplanned outages.  Azure also has network resilience built in.  Hosting a reliable externally available RDS environment on-premises requires redundant internet connections, BGP and underlying Routing and Switching infrastructure.  In Azure, simply provision an external IP and the rest is built in.

The illustration in this post provides a visual of the Azure services used in this project and how they relate to each RDS service.  More detail is provided below.

RD Web and RD Gateway

To start with, the Remote Desktop Web (RD Web) service provides a web-based landing page for users to log into and access services published to them.  The RD Gateway acts as a middleman between Web to RDP services, tunneling RDP traffic over port 443.  Providing RDP services over the internet without exposing the RDP port.

Azure Load Balancer –  Standard Windows Network Load Balancing (NLB) will not work with Azure.  Instead, Microsoft Azure offers software load balancers with all VM (except for “Basic” VM’s).  Load balancers provide HA by redirecting traffic to active nodes if one becomes unavailable.  Azure Load Balancers provide HA on the RD Web/RD Gateway servers and the Connection Brokers in this implementation.

** Please note, A reader pointed out that the correct name for the service below is Azure AD Application Proxy.  That is different from the Application Gateway**

Azure AD Application Gateway Proxy– It is common practice to expose the RD Web page to the internet for external access, relying on forms-based authentication to protect the site.  The Azure AD Application Proxy is used to provide an extra layer of security to the RD Web Page.  The Azure AD Application Proxy is a cloud-based proxy service.  It works by installing an agent on a server inside your network.  This agent makes an outbound connection to the Azure AD Application Proxy services, establishing a two-way connection.  Internal services can be published in the Application Proxy services and made available externally without opening ports on a firewall.

An added benefit to the Azure AD Application Proxy is it can use Azure AD authentication services as a “pre-authentication” to the RD Web server.  This way, Azure AD authentication, including MFA if enabled, is required prior to accessing the RD Web page.

RDS Connection Broker

The connection broker acts as a traffic cop for RDP sessions.  It monitors active connections to the session hosts and directs new connections accordingly.  It also reconnects disconnected sessions to the same server, preventing orphaned connections.

Azure SQL –  Multiple Connection Brokers provides HA, but requires a central database.  Azure SQL Server provides this central database for the Connection Broker cluster.  Microsoft has outlined the steps to use Azure SQL for a Connection Broker Cluster here.

Session Host Auto Scale – It costs money to run servers on Azure.  However, it doesn’t cost money when they are shut down and in the deallocated state.  With that in mind, a higher number of smaller, less expensive VM’s as Session Host servers were provisioned.  These servers can be powered on and deallocated as usage increase and decrease, providing a cost savings.

Microsoft provides an auto scale script here that runs on the Connection Broker and brings Session Host Servers online as demand increases and shut them down when the need decreases.  To do this, the script needs to log into Azure to control the Session Hosts power state.  The script can be configured with user name and password credentials, or a more secure certificate option.  The certificate option uses an Azure AD Service Principle login, storing the certificate in the Azure Automation certificate store.  This provides additional security as it is not necessary to store your credentials in the script.

Session Hosts

The Session Host is the resource users interact with as a remote desktop or published application.  As mentioned previously, these can be shut down and powered on as needed by the auto scale script.  This can be a problem however when it’s time to patch the servers.  An Azure Automation Runbook is used to start all Session Hosts during their patch window.  The Runbook uses the Azure Key Vault to store the credentials used to log into Azure and start the VM’s.  Azure Auto Shutdown is used at the end of the patch window to shut down and deallocate the VM’s.

Azure ARM Template Deployment

Azure ARM Templates are used to deploy all VM’s in this environment.  Although not unique to RDS, it is worth a mention.  ARM templates provide a way to quickly deploy a large number of VM’s.  One feature of ARM Templates called Copy Index allows for creating multiple VM’s in parallel.  Templates are used to rapidly scale out the number of session hosts in this project.

Passwords for items such as local computer and Domain Join accounts are secured in Azure Key Vault.  The ARM template references those secrets during the deployment.  This prevents storing credentials directly in the template file.

Azure Desired State Configuration is used to finish server setup tasks.  This service can add roles and services, copy file, set the time zone and make many other configuration changes.  Azure ARM Templates and DSC cut the deployment time down to a fraction of what a traditional server deployment takes.

More information on ARM templates and DSC can be found here.