What Is Remote Desktop Modern Infrastructure?

Microsoft is developing a deeply re-factored version of the Windows Server Remote Desktop Services infrastructure, leveraging the power of Windows Server, Azure PaaS, and Azure AD. This looks so good, I can almost forgive them for killing off Azure RemoteApp. And I probably will, after this goes GA in mid-2018.
 

 

RDS Today

With my ever-growing involvement in Azure, one might expect that I would be less involved with RDS; the opposite is true! RDS is often the answer when I have a customer that wants to move legacy clients/data to the cloud. That’s easy enough when it’s a very small business but once they get to mid-large, RDS starts to require a lot of complexity and machines.
The information below is from a slide that Microsoft shared at Ignite 2017. This is actually the most modern way that one can deploy a scaled out RDS farm in Azure today. It will be taking advantage of Azure SQL to host the Connection Broker database, instead of a cluster of Azure virtual machines running SQL Server. In this deployment, if you want high availability (and you would), then you would have:

• Two load-balanced RD Web servers
• A pair of load-balanced RD Gateway servers.
• Connection broker
• A farm of session hosts for desktop/app publishing
• A file server to host user profile disks (UPDs)

All of the above is deployed into virtual machines connected to a single network (possibly over multiple subnets) in a completely domain-joined environment.

 
If a service provider was providing a multi-tenant service, then the only true way to secure it would be to deploy this stamp out over and over again.
 

 

RDS Modern Infrastructure (RDSMI)

Coming in preview in early 2018, is a re-imagining of RDS infrastructure. I was at the first session to describe this and maybe it was jetlag, but I thought “that’s interesting”. I went back over the materials to prepare this article and I was much more excited about the potential of RDSMI and what it could mean for my customers. To be honest, the nerd in me just wants to play with it!

• The session hosts are deployed into a separate network from the RDS infrastructure.
• The session hosts are joined to Azure AD Domain Services (AADDS). AADDS can be synchronized with on-premises Active Directory via Azure AD/Azure AD Connect.
• The RDS infrastructure is not domain joined. In fact, it’s not even installed in virtual machines. RDSMI uses Azure Web Apps instead of virtual machines. Scaling out is now easy – a slider control or auto-scaling.
• Clients authenticate with the farm by signing into AADDS. This opens up the easy possibility of AAD Premium features such as Multi-Factor Authentication. A token is returned and used to authorize a connection via the RDSMI.
• A new RDS Diagnostics role correlates events from around the system to simplify troubleshooting.

Note that the session hosts could be deployed in Azure or on-premises with either site-to-site VPN or ExpressRoute connectivity to the in-Azure RDSMI.

 
The separation of the session hosts from the RDSMI via domain join and firewall increases security but it also means that the RDSMI can be securely used for a multi-tenant deployment. An additional farm of session hosts can be deployed and connected to a different AADDS domain. The following diagram from Ignite depicts a solution that a hosting company could use to host many tenants with a shared RDSMI architecture.

 

 
The preview of RDSMI is due to start in early 2018 with GA sometime later in the year. I’m looking forward to trying this solution out because I think it’s going to be easy to set up, more secure, and will enable highly available/scaled-out solutions at much lower costs.