
Please read the first and second articles in this blog series if you have not already.
AVD Connections By Default Are TCP ONLY At the Moment. RDP Shortpath (UDP Support) Remains in Public Preview, And Is Less Flexible and More Cumbersome to Setup Compared to the Remote Desktop Gateway in RDS.
When AVD was originally architected, Microsoft chose to implement connections via a reverse proxy method. Basically, AVD clients connect to the distributed PaaS AVD Gateway service, which then pings the agent on a AVD host (the host in the hostpool selected by the AVD Broker PaaS role) to establish a reverse connection back to the client through the Gateway. As such, all connections are TCP only. For more mechanics on how this works, please read my earlier blog post on the topic.
Of course, TCP only RDP connections have a lot of drawbacks. For those of you as old, well, let’s say as seasoned as I am, you may remember the pre-RDP v8.0 days where all RDP connections were TCP only. Those days … those days sucked! TCP has built in congestion avoidance algorithms, so higher latency and lossier networks trigger those algorithms, which lead to “back off” or “timeout” intervals. When you’re trying to use RDP, that results in you clicking the mouse or typing something and then waiting a few seconds before you see that input post on the terminal server you’re working on. It’s frustrating.
Now, your Microsoft Azure sales rep will probably answer, “That’s why we have TONS of Azure regions around the world, so you can place your WVD hosts super close to your end users, so latency or lossy connections over TCP won’t be a problem.” However, if your company has multiple offices throughout a country, or even the world, this means you’ll be most likely be standing up more virtual machines, in more Azure regions, than you would if you just had a single high availability RDS infrastructure deployed that utilized a Remote Desktop Gateway. Why?!!
In classic RDS, you set up one or more Remote Desktop Gateway servers that receive incoming RDP connections from external users to your collections of terminal servers. Think of Remote Desktop Gateway as a highly optimized VPN specifically for RDS.
Back in Windows Server 2012 R2, Microsoft introduced dual transport for Version 8.0 of the RDP protocol, so it could now utilize both TCP AND UDP for sending/receiving data. This was a gamechanger, as now RDP could be leveraged for higher latency and lossy connections across continents- because UDP would overcome the poor connections and distance. Consequently, when Microsoft built the Remote Desktop Gateway server for Windows Server 2012 R2 and later operating systems, they designed it to route and marshal both TCP and UDP traffic to/from Remote Desktop Servers using ports 443 and 3391 respectively.
So, to sum it up, in classic RDS you theoretically could stand up one highly available RDS deployment in one region of the world, that could be used by RDP clients just about ANYWHERE in the world, with an acceptable user experience. All because of dual TCP/UDP transport, AND the ability of the Remote Desktop Gateway to handle and route both methods of transport.
Now, Microsoft realizes this current shortcoming in AVD, and so has created something called RDP Shortpath, which is currently in Public Preview. At its essence, RDP Shortpath is a way for the AVD client to see if there is a way for it to make a DIRECT connection to the AVD host, so that it can open up a side channel for UDP communications, improving the performance of the AVD experience.
Unfortunately, the only ways for this to work, more or less, is for you to establish either a separate VPN between the WVD client system and the Azure VNet containing the WVD host pools, OR to add a static IP to EACH AND EVERY WVD host that is publicly accessible on the Internet. Yikes!! Choosing EITHER of these options INCREASES total WVD costs, because you’re either paying for the Azure VPN OR you are paying for the static IPs. Do you see a trend? Microsoft will build a solution or workaround for you, but it will almost ALWAYS COST YOU MORE. Yet, they already have the technology in the classic RDS Gateway role to support both TCP/UDP. Thus, if you are an organization of any decent size, it makes MUCH more sense to continue to run Classic RDS, either in a private cloud/colocation facility OR in the public cloud like Azure, to reduce your infrastructure costs (fewer VMs total) AND reduce the need for VPNs or for static IPs.
Update October 2022: RDP Shortpath over Public Networks is nearing General availability, whereby administrators can configure AVD VMs so that the AVD client can attempt to establish a UDP side channel with them for better connection quality. Unfortunately, RDP Shortpath over Public Networks still has numerous limitations when compared to the Remote Desktop Gateway built into RDS, such as:
- Incompatible with Double NAT / Carrier Grade NAT configurations
- May not work if user has UPnP disabled on their home/office router
- Incompatible with some VPN solutions
- Incompatible with cloud packet inspection services
- Often requires additional firewall configuration / registry configuration on EVERY session host to work
Updates in AVD – Do You Feel Lucky, Punk?
In Part 2 of this blog series, I alluded to issues with updates when running Windows 10 multisession in Azure Virtual Desktop, as compared to running classic Remote Desktop Services with Long Term Servicing Channel (LTSC) versions of Windows Server. Let’s dive into that further.

Currently, there are two issues, as I see it, with updates in Azure Virtual Desktop.
The first issue is that at present you don’t have control over when Microsoft pushes updates to the WVD Infrastructure Agent and SxS Network Stack components on the Windows 10 multisession hosts you have running in your host pools. Why is this a big deal?
When Microsoft pushes these WVD agent updates to your session hosts each and every month, if the update fails to take place successfully, it can bring your hosts down completely, and you may have to either attempt to resolve the issue yourself on EACH host OR simply redeploy new hosts and reload applications. Neither of these is a desirable scenario, as it results in extra work for you and downtime for your users. See this thread for more gory details. I don’t know about you, but I don’t want to lose sleep every single month worrying about WVD agent stack updates getting botched.
Microsoft’s solution for this? The ever so euphemistically named validation host pool, of course. Basically, you designate one of your host pools as a validation host pool, and that host pool will be the guinea pig that gets the monthly updates first. If it goes down after these updates get pushed, only SOME of your users will be affected! That’s great right? You get to pay EXTRA compute costs in the form of additional VMs in an additional host pool to Microsoft in order to Q&A their WVD agent update process, and you still get to scramble when some of your users potentially go down. No thanks.
Update October 2022: Microsoft has introduced a feature in AVD that allows you to schedule updates of the AVD agent, SxS network stack, and Geneva monitoring agent on a per-host pool basis. Their goal with this is to allow you to specify that you want updates to take place during non-peak hours when there are fewer users working in your AVD host pools. This is arguably better than before, when you had zero control over updates, but you cannot *suspend* agent updates completely until a desired time, AND if your AVD hosts are turned off during non-peak times (which they probably will be since you’re trying to save money – we’ve already talked about how expensive Microsoft IaaS compute is), the updates will eventually kick in by force when those VMs are next powered on, which could very likely be during the morning login storm rush. Plus, Microsoft can always update your agents immediately for security purposes or any other reason they deem critical. Which could theoretically bring down your host pools.
Another issue that has come up is how to best perform major updates to Windows 10 multisession. Some AVD customers ran into big problems last year when they did in place upgrades to Windows 10 Build 2004, as this broke the AVD agent/network stack components mentioned above and users could not connect. The affected organizations had to then scramble to reinstall the AVD network stack manually on all affected session hosts.
Bottom line, the AVD team at Microsoft is running so fast to introduce new features, they are working on the car’s engine while the car is in motion. This has caused issues in the past with both the forced push updates to the AVD infrastructure agent and network stack components that allow the AVD hosts to communicate with the AVD infrastructure and user clients, and 2.) has caused compatibility issues with in-place major updates to new Windows 10 builds.
Leave a Reply