Alright, folks – Windows Virtual Desktop is now in Public Preview in Azure, so now is the time to dig in and start playing with it! I’ve had the privilege to be working with it in Private Preview, so I’m starting a blog series covering the “under the hood” internals that make WVD different than traditional Remote Desktop Services.
Classic Remote Desktop Services deployments (let’s hope WVD is better than New Coke), whether run on-premises or in Azure on IaaS virtual machines, typically require the use of separate VMs to host the infrastructure roles, such as Remote Desktop Web Access, Remote Desktop Gateway, and the Remote Desktop Connection Broker. What Microsoft has done with Windows Virtual Desktop is to abstract away these traditional Windows Virtual Desktop roles into “black box” web services that they control and maintain as part of Azure. As a result, all you are responsible for are the session hosts that serve up the apps/desktops into which your employees or customers connect.
BTW – in Classic Remote Desktop Services, these logical groupings of session hosts were called RDS collections. In WVD, they are now called host pools. You can provision, tear down, and re-provision these host pools via a limited wizard in Azure, through ARM templates in Azure, or via specialized PowerShell commands. I’ll touch upon these concepts more in upcoming articles.
That being said, in Classic Remote Desktop Services, if a Remote Desktop Gateway was deployed, a client would connect to the gateway over TCP Port 443, authenticate, and then the Gateway would create a secure session inbound to a session host (after consulting with the Connection Broker) over the traditional RDP port 3389. In Server 2012 and later, the RDS Gateway could also use UDP port 3391 to enable dual transport for much better connection quality over higher latency or less-reliable networks.
In Windows Virtual Desktop, things are different. My colleague and fellow MVP Freek Berson alluded to as much in his recent blog article. The RDS/WVD client still connects to the Azure Windows Virtual Desktop Gateway Service over port 443, but then using “black box magic” via agent software on the target session host:
1.) The Windows Virtual Desktop Gateway and Broker Services contact the session host in the host pool that should receive the new client connection, and
2.) That session host establishes a reverse connection back to the client through the Azure WVD Gateway Service. In this way, the Azure WVD Gateway Service is acting as a reverse proxy of sorts.
Arguably, this architecture is somewhat more secure than classic RDS, since the connection comes from the session host back TO the client through the WVD Gateway after authentication and validation by the Azure WVD Infrastructure. Also, in Classic RDS deployments, admins often forget to be appropriately restrictive with their CAPs (Connection Authorization Policies) and RAPs (Resource Authorization Policies) on their RD Gateways, setting up a scenario where just about any Windows host running RDP can be accessed once any domain user was authenticated through the RD Gateway. In WVD, you have to explicitly indicate the users that will be permitted to connect to any given host pool during host pool creation.
One noticeable difference, now, is the lack of UDP traffic between the client and server. This has direct implications on how robust WVD can be over higher latency connections whereby remote workers in one part of the world attempt to connect to WVD resources in a distant Azure region. I have a feeling Microsoft’s answer to this will be “place your host pools in the Azure geographic region most suitable for your clients” and/or “create as many host pools in different regions as required to serve your clients.” However, that adds both architectural complexity and cost, so it is my hope that RDP dual transport featuring UDP will eventually come to WVD. Until then, it may make sense to continue to set up Classic RDS in Azure with the traditional infrastructure role services under YOUR direct control as opposed to deploying WVD, since dual transport with TCP/UDP will still work in those circumstances.