RDmi is a milestone for the future of RDS. Here’s how it works

Before RDmi

As long as enterprise IT was organized around on-premises datacenters, the delivery of remote desktops and WinForm applications was straightforward: Farms (or collections) of Remote Desktop Session Host (RDSH) servers with all necessary Windows applications installed constituted so-called Remote Desktop Services host pools. Such a host pool provides authenticated and authorized users with access to interactive remote sessions. Remote Desktop Services (RDS) backend servers represent the infrastructure or control layer, responsible for session brokerage (including load balancing), authentication, authorization, resource assignment, web-based user access, network encryption, and license management.

Remote desktop client software allows users to connect to their interactive sessions from different kinds of endpoint devices. Add-on products developed by Citrix, VMware, Parallels, and other software vendors build on top and extend the core RDS functionality. All was good for many years.

But what if customers wanted to migrate their local or remote Windows desktops and applications to an Azure-centric world? Unfortunately, they discover that Microsoft missed out on providing a simple, fast, and cheap mechanism to transform existing line-of-business WinForm applications into native cloud apps. Oops!

Okay, let's switch to plan B and just move all Windows desktops and applications to an RDS Infrastructure-as-a-Service model hosted in Azure. This means that all RDS infrastructure and resource roles are implemented in Azure virtual machines. Despite the fact that Windows Server 2016 Remote Desktop Services included some nice improvements for better cloud compatibility, these changes did not go far enough to make RDS a first-class citizen in any Azure service model. In addition, the Azure price model is not suited to run a conventional RDS environment 7x24 at decent costs. Bummer!

And let’s not even think of plan C, based on Azure RemoteApp, better known as the ARA Disaster. The good news is that Microsoft seems to have learned from the mistakes of the retired ARA.

This is exactly why RDmi is needed.

RDmi concepts

RDmi was born in the cloud and runs in Azure. One of its fundamental design concepts is that the RD Session Hosts or Virtual Desktop VMs are deployed into one or multiple (virtual) networks that are completely separated from the RDS infrastructure layer. The refactored RD infrastructure services (RD Broker, RD Web, and RD Gateway) use Azure Web Apps as the underlying platform and none of them is domain joined. In addition, RDmi introduces the RD Diagnostics service which correlates events end-to-end, i.e., from RD client through infrastructure layer to RD Session Host. 

All RDmi infrastructure services benefit from the autoscaling features that are built into the underlying Azure Web App service. By defining two very simple rules, the RD infrastructure roles dynamically allocate or deallocate resources to match performance requirements. Another advantage of the RDmi design is that it can be securely used for multi-tenant deployment—a feature that independent software vendors and managed service providers have always wanted to have. It means that one infrastructure layer can be used in conjunction with multiple RDSH host pools assigned to different customers and their respective ADs.

Host pools contain RD Session Host or Windows 10 worker VMs, hosted in an Azure Infrastructure-as-a-Service model. As a prerequisite, a new RDmi guest agent must be installed on every worker VM that is a member of a tenant's host pool. As soon as the agent is running, it establishes and maintains an outbound WebSocket connection to the RD Broker service and registers as a member of a tenant-specific host pool.

As a result, the RD Broker service knows all members of each host pool and all related tenant assignments. Using this information, the broker is able to properly dispatch and orchestrate connections from clients to RD Session Hosts. Since RDmi is based on Azure AD, multi-factor authentication (MFA) can be enabled with a simple setting. This is an improvement since on-prem RDS roles are AD-based, which makes MFA difficult to set up.

An RDmi user connection is initiated when the client authenticates with the Azure Active Directory that belongs to a tenant's host pool. All optional Azure AD security features are enabled by default, such as certificates, MFA, and Intelligent Security Graph. On successful user login, the RDmi client receives an Azure AD token which it presents to the RD Web service. RD Web forwards this information to the RD Broker which determines the resource authorization for the user. Now, the user is presented with the available resources in the RDmi client user interface and selects one of them, for example, by clicking on the icon that represents a full remote desktop. The broker does some load-balancing magic and selects one of the available RD Session Hosts.

There is already an open, outbound connection from the selected RD Session Host to the infrastructure layer which was previously initiated by the guest agent. A second WebSocket connect is opened from the RD Session Host to the RD Gateway. This will be in addition to the initial WebSocket connection that provides the heartbeat back to the broker. Based on that, a bi-directional connection between client and RD Session Host is established and "tunneled" through RD Gateway, using HTTPS port 443. No other port needs to be open and the users can work interactively in a secure manner. The different host pools (= tenants) are completely separated from each other and none of them exposes an open inbound port to the outside world.

Why get excited about RDmi? 

There are a number of advantages when using RDmi:

• Running the RDS infrastructure layer on top of Azure Web Apps is potentially more cost effective than using virtual machines. However, note that currently, there is still no RDmi price model; only the current cost of Web Apps gives you a rough estimate.
• RD infrastructure layer and RD Session Host pools are completely isolated from each other, which increases security.
• Authentication and authorization is based on Azure Active Directory, plus federation.
• RDmi was designed to support multiple tenants and Azure subscriptions per RD infrastructure layer, which reduces cost for hosting providers with large numbers of small to medium-sized tenants.
• Each RD Session Host pool can have different AD configurations.
• RDmi is taking advantage of Web Apps auto-scaling functionalities and the general Azure elasticity.
• RDmi introduces a new diagnostics service to help troubleshoot connection problems.

Microsoft positions RDmi as an extensible platform. What this means is that Microsoft provides the base functionality for delivering Windows desktops and applications from Azure, and multi-tenancy and security are built-in right from the beginning. On top of that, RD PowerShell and a REST API can be used by ecosystem partners to extend RDmi. Examples are RD Session Host autoscaling, deployment automation, monitoring, or creating new management consoles.

Final thoughts

In our opinion, Remote Desktop modern infrastructure marks an exciting milestone. Its design has huge potential for enterprises, public administrations, and managed service providers that want to start hosting traditional Windows desktops and WinForm applications in Azure. We’re hoping that general availability of the first public release is not too far away. The only thing that we think is missing is the support of on-prem host pools—but maybe that's on the feature list of the next RDmi release.

The Microsoft RDS product group will be presenting RDmi and more in a session at the upcoming Inspire conference (session link here).

In our a follow-up article, you will learn about the RDmi deployment steps and what the administrator experience is.