Connection resiliency is the quiet theme of the September 2026 Azure Virtual Desktop update. Three new entries landed on Microsoft’s What’s New page, and all three extend the same idea: keep the session alive when the network wobbles. RDP Multipath — the feature that maintains multiple transport paths and fails over automatically — has now reached macOS and Azure Government, and RDP Shortpath via TURN relay has arrived in Azure Government as a public preview.

This edition of the AVD What’s New series covers those three items specifically; the other September 2026 announcements (Display Protection, AVD Hybrid GA, Windows update management guidance, and RemoteApp pinning) were covered in the previous post.

What’s New in September 2026

Here is what changed, straight from the What’s New page:

  1. RDP Multipath with UDP support for Windows App on macOS Beta — RDP Multipath with UDP transport paths is now available with Windows App on macOS Beta, version 11.3.8 (3048).
  2. RDP Multipath in Azure Government — RDP Multipath with redundant UDP transport paths is now generally available in Azure Government; the phased GA rollout of redundant TCP transport paths has started.
  3. RDP Shortpath with TURN relay in Azure Government — RDP Shortpath via TURN is now in public preview in Azure Government, introducing a dedicated TURN relay IP range of 20.140.236.0/22 over UDP port 3478.

Each of these is a meaningful step, and together they tell a clear story: Microsoft is standardizing on UDP-based transports and pushing them out from the commercial cloud into sovereign clouds and additional endpoint platforms.

RDP Multipath, Refreshed

If you have not touched RDP Multipath yet, the short version: traditional RDP relies on a single TCP reverse-connect transport, and when that path degrades, the user feels it. RDP Multipath changes that by keeping multiple transport paths open, monitoring each one, and moving traffic to a healthier path when conditions change — without dropping the session.

There are two flavors:

  • Multiple UDP transport paths — several UDP paths are maintained simultaneously. This is the newer, higher-performing model and depends on RDP Shortpath to establish the UDP data flow.
  • Redundant TCP transport paths — standby TCP paths provide resilience in environments where UDP is restricted.

Microsoft is explicit that the two features are complementary: RDP Shortpath should be configured as the primary transport protocol to get the most out of RDP Multipath. Shortpath establishes the direct or relayed UDP flow; Multipath manages and fails over between paths.

The availability picture, per Microsoft’s documentation, now looks like this:

EnvironmentMultiple UDP pathsRedundant TCP paths
Azure public cloudGenerally availableGenerally available
Azure GovernmentGenerally availablePhased rollout started

New: RDP Multipath on macOS Beta

The first item is a platform expansion. RDP Multipath with multiple UDP transport paths is now supported on Windows App for macOS Beta, version 11.3.8 (3048). This brings macOS users the same resiliency benefits that Windows users already have, by enabling multiple UDP transport paths with RDP Shortpath for public networks.

In practical terms, that means a macOS user on a flaky home or hotel connection gets the same automatic path-transition behavior: RDP Multipath continuously monitors available paths and can move traffic to an alternate path when network conditions change, reducing session interruptions.

Two caveats worth stating plainly:

  • This is a Beta client, so treat it as an evaluation path, not a production guarantee.
  • Requirements are the same as RDP Shortpath for public networks — the environment must permit outbound UDP to the required endpoints. If UDP is blocked, you fall back to TCP and lose the Multipath benefit.

For reference, the client support picture across platforms is now:

  • Windows App on Windows — RDP Multipath from version 2.0.559.0; version 2.0.1069.0 or later adds the latest enhancements (multiple UDP and redundant TCP paths).
  • Windows App on macOS Beta — version 11.3.8 (3048) adds multiple UDP transport paths.
  • Other platforms — not currently supported.

New: RDP Multipath Reaches Azure Government

The second item is arguably the more consequential for regulated customers. RDP Multipath with redundant UDP transport paths is now generally available in Azure Government. Any feature that reaches GA in the sovereign cloud matters, because Azure Government does not inherit Azure public cloud features automatically — parity is earned, not given.

Alongside that, Microsoft has started the phased GA rollout of redundant TCP transport paths in Azure Government. “Phased” means you should not assume it is live everywhere yet. Until the rollout completes, customers who want to try redundant TCP can do so by using the validation ring — the opt-in deployment ring Microsoft uses to expose new capabilities ahead of full availability.

For agencies, contractors, and partners running AVD in Azure Government, this is the practical mechanics:

  1. Redundant UDP paths — generally available now. If your session hosts and networks permit UDP, you get improved resiliency with no new client requirements beyond a supported Windows App build.
  2. Redundant TCP paths — phased rollout. Try early via the validation ring; otherwise it arrives as the rollout expands.
  3. Config — ensure RDP Shortpath is configured as the primary transport to maximize the benefit, and validate outbound UDP connectivity end to end.

New: RDP Shortpath via TURN Relay in Azure Government

The third item completes the picture and is the most operationally specific. RDP Shortpath via TURN is now in public preview in Azure Government. TURN — Traversal Using Relays around NAT — provides a relayed UDP connection when a direct connection is not possible.

To understand why this matters, recall how RDP Shortpath works over public networks. RDP first establishes a TCP reverse-connect transport, then attempts UDP. Public-network Shortpath comes in two forms, in order of preference:

  1. Direct UDP via STUN — the client and session host discover each other’s public address and port and connect directly.
  2. Relayed UDP via TURN — when a direct path is impossible, traffic is relayed through an intermediate TURN server.

TURN is the safety net for the scenarios that break direct connections: symmetric NAT, double NAT (common behind secure web gateways and proxies), carrier-grade NAT, and networks that restrict UDP to specific destinations. Without TURN, those users simply fall back to TCP and lose the performance and resiliency benefits of Shortpath. With it, they keep a UDP path — just relayed rather than direct.

The Azure Government specifics:

  • Dedicated relay range: 20.140.236.0/22, over UDP port 3478. This is a dedicated range for AVD and Windows 365 in the sovereign cloud.
  • Availability: public preview, validation ring only for now.
  • Firewall/NSG rule: both the session host subnet and the client network must be allowed outbound to 20.140.236.0/22 on UDP 3478.

For comparison, the Azure public cloud uses a dedicated TURN relay range of 51.5.0.0/16 (UDP 3478), now deployed across dozens of Azure regions and reserved exclusively for AVD and Windows 365 rather than shared with Azure Communication Services.

If you operate strict egress controls in Azure Government — and most organizations do — this is the item to action: add the new relay range to your allow-list before you enable the preview.

How to Verify You’re Actually on UDP

Resiliency features only help if traffic actually uses them. Two quick checks:

  • Session host event log: Applications and Services Logs → Microsoft → Windows → RemoteDesktopServices-RdpCoreCDV → Operational, filter for Event ID 135. A Shortpath connection reports: “The multi-transport connection finished for tunnel: 1, its transport type set to UDP.”
  • Log Analytics: query the WVDConnections table and read the UdpUse column:
    • 1 — RDP Shortpath for managed networks
    • 2 — RDP Shortpath for public networks via STUN (direct)
    • 4 — RDP Shortpath for public networks via TURN (relayed)

On the client side, the Connection Information dialog in Windows App shows whether the transport is UDP, UDP (Private Network), or UDP (Relay).

What This Means for Your Deployment

A few practical takeaways:

  1. UDP is now the strategic transport. Every one of these announcements leans on RDP Shortpath. If your firewall or proxy blocks UDP, you are leaving the biggest resiliency gains on the table — audit outbound UDP to the required ranges (including the new 20.140.236.0/22 for Azure Government).
  2. Azure Government customers should plan a validation-ring pilot. Redundant UDP is GA, redundant TCP is phased, and TURN relay is in preview. A small validation-ring host pool is the lowest-risk way to validate all three before broad rollout.
  3. macOS matters more than it used to. Bringing Multipath to macOS Beta signals that Apple endpoints are no longer an afterthought. If you have Mac users on AVD, start testing the Beta client now.
  4. Pair Shortpath and Multipath deliberately. Configure RDP Shortpath as the primary transport and let Multipath manage failover. One without the other is half the benefit.
  5. Document the verification steps. A short runbook covering Event ID 135 and the UdpUse values will let your help desk confirm whether a user is actually benefiting.

Looking Ahead

The trajectory here is unmistakable: Microsoft is treating connection resiliency as a first-class part of the AVD platform, and it is bringing the same UDP-based transport model to sovereign clouds and to macOS. Expect to see the phased TCP rollout complete in Azure Government and the TURN relay preview graduate over the coming months.

For now, the actionable items are concrete: update macOS Beta clients to 11.3.8 (3048), confirm UDP egress (including 20.140.236.0/22 UDP 3478 for Azure Government), and pilot the validation ring if you want early access. Resilience is cheap to enable and expensive to wish you had.


For ongoing coverage of Azure Virtual Desktop updates, follow the AVD What’s New series and connect with us on X at https://x.com/kkaminsk.