Remote Desktop Service (RDS) has been improved in Windows Server 2016. RDS farm deployment has been simplified, especially for the Cloud. For example, you can now leverage Azure SQL to host the RD Broker database. This series of topics aims to show you how to deploy a high availability RDS farm in Microsoft Azure. I’ll describe how to deploy Microsoft Azure resources and how to configure the operating systems. This series consists of the following topics:
- Deploy a Windows Server 2016 RDS Farm in Microsoft Azure
- Create Microsoft Azure networks, storage and Windows image
- Deploy the Microsoft Azure Virtual Machines
- Configure Domain Controllers
- Deploy the RDS farm
- Configure File Servers for User Profile Disk (UPD)
- RDS final configuration
This topic introduces the RDS farm architecture overview.
Azure SQL for RD Broker database
Before Windows Server 2012R2, when you built HA RDS Farm, you had at least two RD Brokers in high availability. This mode required a SQL Server database in HA to avoid a single point of failure. If you deployed the RDS farm in Azure, you had two possibilities to deploy the RD broker database in HA:
- SQL Server with database mirroring (almost deprecated)
- SQL Server with AlwaysOn Availability Group (2x SQL Server Enterprise = uber expensive).
In Windows Server 2016, you can deploy the RD Broker database in the PaaS Azure SQL Server. So, you save money because you don’t need anymore two additional Azure VM and SQL Server licenses. In this series, we will leverage this new feature.
Personal Session Desktops
In Windows Server 2012 R2 there is two kinds of deployment. in Remote Desktop farm. The first is the session-based desktop deployment, which enables the user to connect to a remote server and get the desktop. All users share the same servers and so the same settings. Users can customize applications and settings are stored in User Profile Disk. You can also provide a Remote App RDP file to users and when the RDP session is opened, only the applications are shown to users. They don’t see any desktop and they can customize the applications. Users think that the application runs on their computers but it is in fact a RDP session.
The second model is Virtual Machines-based deployment. This solution is based on virtual machines and Hyper-V. When users open a virtual desktop, a VM is deployed and each user is isolated in their own virtual machine. This solution requires dedicated Hyper-V and so, can’t be deployed in Microsoft Azure.
Windows Server 2016 brings a new model called Personal Session Desktops. We can see this new model like a mix between Virtual Machines-based and Session-Based desktop deployment. Each user has his own personal desktop with specific user rights. It is great for Cloud deployment and you can provide Desktop as a Service.
In this series, I will implement classic session collection based on Remote Apps.
In this design, I have two sites: the On-Premise site and Microsoft Azure. In On-Premise site, I have an Active Directory forest called homecloud.net. I will deploy a Site-to-Site VPN between both sites to extend the on-Prem AD forest to Azure.
From Microsoft Azure perspective, I will have two kinds of servers: those reachable through a public IP and those are not reachable from a public IP. This is why I have two “zones”: DMZ and Internal. I’ll deploy all Remote Desktop roles:
- RD Access and RD Gateway share two Azure VM
- RD Broker and RD Licensing share two Azure VM. The RD broker database will be located in Microsoft Azure SQL.
- Two RD Host that will host Personal Session Desktops
- Two File Servers with Storage Spaces Direct for User Profile Disks
- Two Domain Controllers of homecloud.net.
Microsoft Azure resource requirements
To host this solution, several components will be required. In the next topics, I’ll show you how I have deployed all these resources. These resources belong to a resource group called RDSFarm. The following resources will be deployed:
Virtual network: to interconnect resources
- DMZ subnet: 10.11.1.0/24
- Internal subnet: 10.11.0.0/24
- Cluster subnet: 10.11.100.0/24
- Gateway subnet: 10.11.255.0/24
- Azure Gateway + Site-to-Site VPN connection
- Local Gateway
- Storage account
for VM diagnostics
- 2x Azure VM Domain Controllers with vNIC + OS Disk + 1x Data disks each + Availability Set
- 2x Azure VM RD Access (+ RD gateway) with vNIC + OS Disk + Load balancing (Public IP) + Availability Set
- 2x Azure VM File Servers with 2x vNICs (1x Internal + 1x Cluster), + OS Disk, 4x data disks each + Availability Set
- 2x Azure VM RD Broker (+ RD Licensing) with vNIC + OS Disk + Availability Set
- 2x Azure VM RD Host with vNIC + OS Disk + 1x Data Disk each + Availability Set
- 1x Azure SQL
- 1x Azure VM Image (Windows Server 2016 image)
Each type of Azure VM is in an availability set to ensure a 99,95% SLA. Regarding the VM disks (OS + data), I use the new managed disks. So, I don’t create a storage account for Azure VM disks. The storage account will be used for VM diagnostic logs. The On-Prem site will be connected to Microsoft Azure through a Site-To-Site VPN. So, an Azure and local gateways are required to connect both sites.
Active Directory design
In the On-Premise site, I have two Active Directory sites. Each site has two domain controllers and are “connected” by a replication link. This forest is extended to Azure through a Site-To-Site VPN. The domain controllers in Azure will be in a specific AD site called Azure. The Azure AD site will replicate only with Lyon-HyperV.
File Server design
To store the User Profile Disks, I’ll deploy a Storage Spaces Direct cluster in Azure. Thanks to S2D, I’m able to leverage Scale-Out-File Server (SOFS) which provides a distributed shares system. Storage Spaces Direct enables to deploy file servers in high availability. The User Profile Disk will be stored in this file server cluster.
Remote Desktop farm design
All the Remote Desktop components will be deployed. The RD Broker and the RD Gateway share two virtual machines located in DMZ subnet. These VMs will be connected to a load balancer with a Public IP. In internal network, there are two servers for RD Broker and RD Licensing and two RD Hosts (or more regarding the needs). A Microsoft Azure SQL database will be deployed to host the RD Broker database. The isolation between DMZ and Internal can be implemented with Network Security Groups.
In the next topic, I’ll show you how to deploy network resources in Azure thanks to a JSON template. Then I will create a Windows Server 2016 Datacenter image to deploy all VM from this image.