Moving VDI Deployments: Step 5 User Transition

This post is part of a series of posts showing how you might move an existing VDI deployment to Azure Virtual Desktop on Azure Stack HCI.

This post talks a little about the user experience and RDP Shortpath.

New Clients and URLs for User Access

One of the best things about using AVD is eliminating the need to deploy and manage all those pesky gateways and brokers (and if you are using Windows 10/11 Enterprise you shouldn’t need an RDS Licensing Server!).

Users of AVD and/or AVD on Azure Stack HCI will typically be using the Remote Desktop Client for Windows , one of the other Microsoft provided clients (Mac, iOS, Android), the web client, or a thin client.

What they will not be using any more will be the Remote Desktop client (MSTSC) built into Windows or your old RDWEB gateway – since the VMs are not part of your RDS deployment!

Logging in to the clients will be a little different for users, since they will now login with their User Principal Name (UPN) – often their Entra ID credentials used for Office 365… their e-mail address (user@domain.com) rather than their classic AD ID (Domain\User).

RDP Shortpath: Why you want it, and How to Get it!

RDP Shortpath is this magic like “thing” that allows your AVD-enabled VMs to negotiate the best path for routing RDP traffic to your end users. Without it your AVD-enabled VMs running on Azure Stack HCI would route all RDP traffic through the Azure-based gateway/broker infrastructure… which is fine UNLESS your users happen to be sitting on the same network as your HCI cluster… far far away from Azure!

With or without Shortpath enabled, a user’s request for a session will go to / through the AVD control plane in Azure. Once the user is connected with the VM with Shortpath enabled, the VM will try to connect directly to the user… cutting out the AVD control plane if possible. For HCI this is a big deal, since many of the users may be very near (in networking terms) to the VMs running on the HCI cluster.

The impact for the local user is fantastic – check out the latency of my AVD-connected session running on my local HCI cluster:

Shortpath cut the latency of my RDP experience down to ~1ms… can’t really get any faster! It also enabled delivery of the RDP traffic via UDP… making the packets discard eligible (very useful!).

Without RDP Shortpath, my RDP traffic would “round trip” from my “data center” (my house) down to the AVD control plane and back… adding about 40-60ms of latency to my experience.

It’s worth mentioning that not all access to my AVD VMs running on HCI can leverage RDP Shortpath. If (for instance) I were traveling and “off network”… like in a hotel hundreds of miles away… there would be no “better path” for the RDP traffic – it would have to go through the AVD gateway/broker infrastructure… which is fine, because at least I would have access!

Enabling Shortpath

Enabling RDP Shortpath for Public Networks is pretty strait forward – it can be done with a policy file or via GPO as per Configure RDP Shortpath – Azure Virtual Desktop | Microsoft Learn