You know the user. They’re in financial services, healthcare, or government. Their network team blocks UDP at the firewall because it’s harder to inspect than TCP, and the risk appetite is zero. They’ve heard you talk about RDP Shortpath and how it transforms the AVD experience — lower latency, better audio, fluid video, no session drops. And then they remind you, politely, that none of that applies to them.
Because their UDP is blocked. Has been for years. Probably always will be.
For these users, Azure Virtual Desktop has always meant one thing for connectivity: a single TCP tunnel punched through port 443 to Microsoft’s Azure Gateway infrastructure, via a mechanism called Reverse Connect. No shortcuts, no direct paths, no Shortpath. Just TCP — and if that one path hiccups, the session degrades or drops.
Microsoft just changed that. And it’s bigger than the announcement makes it sound.
First, a Quick Primer on How AVD Connectivity Actually Works
Before unpacking what’s new, it’s worth being precise about the layers involved — because the terminology gets muddled.
AVD has two fundamental transport modes:
RDP Shortpath (UDP): A direct or relayed UDP connection between the Windows App client and the session host. This uses STUN (Simple Traversal Underneath NAT) for direct peer-to-peer discovery, or TURN (Traversal Using Relays around NAT) when a relay is needed. UDP is faster, has lower latency, and handles packet loss more gracefully than TCP for interactive desktop traffic. This is what most people mean when they say “optimised AVD connectivity.”
Reverse Connect (TCP): When UDP is unavailable — blocked firewall, restrictive proxy, NAT that won’t play ball — AVD falls back to a TCP connection routed through Microsoft’s Gateway infrastructure on port 443. Every hop goes through Azure’s control plane. It works, but it’s a longer path, more sensitive to latency, and historically, it’s been a single connection with no redundancy.
RDP Multipath — introduced in public preview last year — added intelligence on top of this. Rather than just connecting on one path and hoping for the best, Multipath continuously evaluates multiple network routes simultaneously and keeps backup paths warm on standby. If the active path degrades, it silently switches to the next best option — no reconnection required, no session drop, often imperceptible to the user.
The original Multipath implementation focused on UDP paths. Multiple STUN routes, multiple TURN relays, intelligent failover between them. For organisations running RDP Shortpath over UDP, it was a genuine step forward in session resilience.
But for TCP-only environments? Nothing changed. You still had one TCP tunnel, and Multipath’s safety nets didn’t extend to you.
Until now.
What Redundant TCP Multipath Actually Does
Microsoft this week announced public preview of redundant TCP transport paths for RDP Multipath. The headline is short, but the implication is significant.
Here’s what it means in practice:
For environments where UDP is available, Multipath now maintains redundant UDP paths and standby TCP paths simultaneously. UDP remains the preferred and primary transport — it’s faster, and if it’s working, you want it. But when UDP paths degrade or fail, the system now has TCP paths pre-established and ready to take over instantly, rather than scrambling to establish a new connection under duress.
For environments where UDP is blocked entirely — the financial services firms, the government agencies, the healthcare organisations — this is the more significant change. These environments have historically relied on a single active TCP Reverse Connect path. Now, Azure Virtual Desktop can establish multiple standby TCP paths in parallel. If the active TCP tunnel becomes degraded or fails, the system automatically switches to the next available TCP path without requiring a reconnect.
Think about what that means operationally. A transient ISP hiccup, a brief VPN instability, a brief network path interruption — these used to manifest as a session freeze followed by a reconnect dialogue. With redundant TCP paths, the session moves silently to the next available path. The user might not notice anything at all.
Why This Matters More Than It Seems
The AVD connectivity story has always had an implicit two-tier problem.
Tier one: organisations that can open UDP ports and run RDP Shortpath. These users get low-latency, high-quality sessions with increasingly sophisticated resilience features. Microsoft has invested heavily here.
Tier two: organisations where network policy, compliance requirements, or legacy infrastructure means UDP isn’t an option. These users have always had a degraded experience by comparison — not because AVD couldn’t deliver quality, but because the transport architecture underneath it left them with fewer options.
Multipath’s original launch improved tier one significantly. Redundant TCP Multipath is the first meaningful improvement for tier two. And tier two is disproportionately large in the enterprise segments where AVD is growing fastest — regulated industries where network teams run tight ships.
This also matters for a subtler reason. Even in environments where UDP is available, there are scenarios where redundant TCP paths matter: a mobile device roaming between networks, a user on a hotel Wi-Fi that quietly blocks UDP, a VPN split-tunnelling configuration that misbehaves. Having TCP redundancy as a backstop makes the entire connectivity architecture more robust, not just for the edge cases.
The Technical Reality of “Silent Failover”
It’s worth being specific about what “automatic switching” means here, because it’s not magic.
RDP Multipath uses ICE (Interactive Connectivity Establishment) — the same protocol that video conferencing platforms have been using for years to negotiate optimal network paths between peers. ICE discovers and ranks available routes, keeps them evaluated continuously, and triggers a path switch when the active route falls below the threshold.
For TCP paths specifically, Multipath uses a mechanism called Rendezvous to establish Reverse Connect paths. Multiple Rendezvous connections are established to different relay endpoints, maintained on standby, and promoted to active status if the primary path fails. The session state is preserved throughout — the switch happens at the transport layer, not the application layer, so the desktop session itself continues uninterrupted.
This is the same basic architecture that makes modern video conferencing resilient. Teams, Zoom, and WebRTC-based applications have solved this problem. It’s taken longer for RDP — a protocol with very different characteristics — to get there. But it’s getting there.
How to Enable It and What You Need
This is currently in public preview, and there are two requirements:
Host pool side: You need to opt your host pool into the Validation ring. The feature is enabled by default for host pools in validation, with no additional configuration required.
Client side: Users must be running Windows App version 2.0.1069.0 or later on a Windows device. This is important — the classic Remote Desktop client doesn’t support this. Other platforms (macOS, iOS, Android) aren’t currently supported either. If your user population is Windows-heavy, you’re well-positioned. If you have significant macOS or Linux client usage, you’ll need to wait.
To verify Multipath is active, users can check the connection bar in their remote session — it will indicate RDP Multipath is enabled. Administrators can validate connectivity patterns in Azure Virtual Desktop Insights under the connection reliability use case.
If you want to test without the validation ring, you can also enable Multipath manually via registry on individual session hosts:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\RdpCloudStackSettings" /v SmilesV3ActivationThreshold /t REG_DWORD /d 100 /f
Users need to disconnect and reconnect after the registry change takes effect.
The Bottom Line
Redundant TCP Multipath isn’t going to transform your AVD environment overnight, and it doesn’t close the gap between TCP and UDP performance — UDP is still faster, and you should still strive to enable Shortpath where network policy allows.
But it quietly solves a problem that has affected some of the most demanding enterprise AVD environments for years: the fragility of single-path TCP connectivity in restrictive networks.
If you have customers or users in finance, healthcare, government, or any sector where the network team is conservative, and UDP isn’t on the table — put this on your radar, opt a test host pool into validation, and start building the evidence for a change.
The users who’ve always had the worst AVD connectivity experience are finally getting some of the resilience that everyone else has had for a while. That’s worth paying attention to.
More on AVD connectivity architecture at modern-euc.com. Follow me on LinkedIn for weekly EUC insights.
References:
Leave a comment