source: https://blog.aspex.be/en/rdmi-update-rdmi-compared-with-rds

Introduction

As we have posted in our previous blog (Next generation architecture & HTML5 for RDS Hosting), ASPEX and Microsoft are still working closely together to test and improve the Remote Desktop Modern Infrastructure or RDmi.

We also talked about RDmi on two conferences:

• first time on our Technical Partner event, on December 12th 2017
• second time on ITPROud, the latest IT Conference for IT Pro’s, on March 14th 2018

Microsoft allowed us to give these presentations under NDA to all attendees, including a live demo of RDmi!

In this post, we will show you what you have missed from the conferences (without the information covered by the NDA), the key differences between the classic RDS and RDmi, and how an RDmi will look like in the near future.

Classic RDS

In the image below, you can see the way you can deploy an RDS environment on Azure as it is available today. In the deployment, we have the following components:

• Base Setup:
  • Azure Resource Group
  • Azure Virtual Network (VNet) Preferably multiple subnets, secured with Network Security Groups (NSG)
  • 1 or more VMs for Active Directory Domain Services (AD DS) or Azure Active Directory Domain Services (Azure AD DS)
  • 1 or more VMs for File Server These will contain the User Profile Disks (UPD) or Roaming Profiles, User Data, etc
• RDS Setup:
  • 1 or more VMs with the RDS Gateway (RDGW) role, which can be combined with the RDS Web (RDWeb) role
  • Azure External Loadbalancer (LB) in front of the Gateway VMs
  • 1 or more VMs with the RDS Connection Broker (RDCB) role
  • 1 Azure SQL Database for the Connection Broker database or If you have a SQL server in your deployment, you can use your SQL Server
  • 1 or more VMs as RDS Session Host (RDSH), depending on the requirements of the deployment

All VMs from the Base Setup, and the RDS Setup, are all domain joined in the single domain from the Client Tenant.

When a user is connecting, he will be using an inbound connection from the Internet over HTTPS (port 443) to the Azure LB and RDS Gateway. The Gateway will then connect to the RDS Session Host, defined by the RDS Connection Broker, over the RDP port (port 3389).

The disadvantage is the inbound connection, because you will need to open up your Client Tenant and NSG, allowing the Internet to connect to your RDS Gateway/Web servers. Another disadvantage is the big footprint: you will need at least 5 VMs for a non-High Available (HA) setup, and 10 VMs to be HA.

RDmi: the changes

Microsoft has redesigned RDS from the ground up, focussing on 3 key areas:

• Security
  • By using the capabilities of Azure AD (Conditional Access policies, Multifactor Authentication, etc)
  • By isolating the infrastructure roles (Gateway, Web, connection broker and others) from the desktop and app deployment
  • …
• Cloud Readiness
  • By innovations in the existing RD infrastructure roles
  • By taking advantage of the elasticity and scale capabilities of Azure
  • By introducing the new Diagnostics role
  • …
• Windows apps on ANY device
  • By the flexibility to run on cross-platform desktop and mobile operating systems using apps
  • By introducing the HTML5 webclient (more on this later on in our next blogposts)!

RDmi: overview

In the image below, you can see the deployment of RDmi on Azure. First, you start with the deployment of the Client Tenant with these components, which are similar to the RDS deployment:

• Base Setup:
  • Azure Resource Group
  • Azure Virtual Network (VNet) Preferably multiple subnets, secured with Network Security Groups (NSG)
  • 1 or more VMs for Active Directory Domain Services (AD DS) or Azure Active Directory Domain Services (AADDS)
  • 1 or more VMs for File Server These will contain the User Profile Disks (UPD) or Roaming Profiles, User Data, etc
• Client RDS Session Host Setup:
  • 1 or more VMs as RDS Session Host (RDSH), depending on the requirements of the deployment

As with the RDS deployment, all VMs from the Base Setup and the Client RDS Session Host Setup, are all domain joined in the single domain from the Client Tenant.

The first difference between RDS and RDmi is that you need to setup AD Connect on your AD DS (if you don’t use AADDS). Due to the usage of Azure AD, you get a higher level of security (Conditional Access policies, Multifactor Authentication, etc).

The second big change is that the remaining RD infrastructure roles are no longer installed in the Client Tenant, but in a completely separated Tenant: the ASPEX Infra Tenant. So its no longer domain joined. This tenant can be shared across multiple Client Tenants, but can also be dedicated for one Client Tenant.

Another major change is the way the RD roles are created: these are no longer services installed on a VM, but they are Azure Web Apps in the ASPEX Infra Tenant, providing scalability and high-availability by default.

RDmi: Forward Connect

By default, the RDmi will use a forward connection to the Session Hosts in the Client Tenant as it was in the RDS deployment (as shown in the image below). This means that when a user is connecting, he will be using a inbound connection from the Internet over HTTPS (port 443) to the RD Gateway role in the ASPEX Infra tenant . The Gateway will then connect to the RDS Session Host in the Client Tenant, defined by the RD Connection Broker, over the RDP port (port 3389).

Therefor, the Client Tenant needs to allow inbound connections on the NSG to the Session Hosts. The inbound connections can be filtered to the outbound IPs from the Gateway role in the ASPEX Infra Tenant, but this is not always manageble and reliable.

The solution? Reverse Connect

RDmi: Reverse Connect

To improve security in RDmi, Microsoft has developed Reverse Connect as you can see in the image below. This means that the Session Host will setup an outbound connection using HTTPS (port 443) to the RD Gateway role in the ASPEX Infra Tenant. Therefor, no inbound connections are required anymore on the Client Tenant. This outbound connection is established at the moment a user is connecting. How this is done will be explained in future blogposts.

RDmi: The (near) future

At this moment, you still need 1 or more VMs for AD (if you cannot use Azure AD DS) and 1 or more VMs for Fileserver. This will change in the near future as AADDS will grow, and an update to Azure Files will make it Domain joinable. This means you can join your Azure Files to your domain, and set ACLs on your files and folders. So you will no longer need VMs for your AD DS and FileServer, these will be PAAS services on Azure.

More information and updates will come up on our blog in the next weeks