Microsoft announced RDP Multipath as generally available on the 23rd July 2025 and the phased rollout is now complete as of November 2025. RDP Multipath is fully deployed for Azure Virtual Desktop (short AVD) and Windows 365 (short W365). Below I’ll walk through what changed, why it matters, what you need to check, and exactly what to do to get ready for this neat feature.
What Is RDP Multipath?
Summary of the change and why it matters
Multipath is now active by default for eligible AVD and W365 sessions everywhere. Because redundant UDP connections are kept on standby, you’ll see fewer session drops and faster, more consistent audio/video and interactive performance. Multipath also leverages Microsoft’s edge infrastructure (RDP Gateways and TURN relays) so sessions can use service edges close to users and Microsoft’s high‑speed backbone for the bulk of the round trip — another win for latency and reliability. There’s no per‑user configuration needed beyond having Shortpath and supported clients in place, which makes this largely an operational readiness task rather than a user rollout.
Platform & prerequisites
Multipath requires RDP Shortpath as the primary transport; it uses STUN and TURN candidates discovered by ICE. Supported client versions are Microsoft Remote Desktop Client (short MSRDC) 1.2.6353 and later or Windows App 2.0.559.0 and later.
If users connect exclusively over WebSocket/TCP, they won’t get Multipath benefits until they use a supported client and Shortpath transport.
How to prepare (do this now)
Do these steps to make sure your users actually benefit:
- Update clients: Deploy MSRDC >= 1.2.6353 and Windows App >= 2.0.559.0 to all endpoints that will connect to AVD or W365.
- Ensure RDP Shortpath is configured as the primary transport in your AVD or W365 environment.
- Allow outbound UDP for STUN and TURN from corporate sites, branch offices, VPN egress points and cloud egress locations. Use the WindowsVirtualDesktop service tag in NSGs/firewalls where possible to simplify rules.
- Optimize egress: Prefer local internet egress, so traffic hits Microsoft’s edge quickly; avoid hair‑pinning through central virtual appliances.
- Bypass deep inspection for Shortpath/Multipath traffic — TLS inspection and DPI add latency, CPU load and can reduce reliability.
- Keep legacy TURN/ACS allow rules until you validate traffic has stabilized (avoid accidental drops during transition).
Verify and validate from real endpoints
You can confirm Multipath is in use in two quick ways:
- End users see an RDP Multipath indicator in the connection bar of the Remote Desktop app.
- Administrators can view Multipath and connection reliability details in Azure Virtual Desktop Insights.
What to watch for / remediation
- WebSocket/TCP‑only sessions: These won’t use Multipath. Plan to move those users to supported clients if they need the reliability boost.
- Blocked UDP/STUN/TURN: Blocked or hair‑pinned traffic forces Multipath to fail or fall back to TCP. Open/adjust egress rules and UDRs as needed.
- Inspection/hair‑pinning through virtual appliances: Bypass Multipath traffic to avoid added latency and potential packet reshaping that can trigger failovers.
- Monitoring: Use AVD Insights to find egress points or regions with low Multipath success rates and prioritize fixes there.
Conclusion
RDP Multipath is a clear operational win: more resilient sessions, smoother audio/video, and near‑instant failover across UDP paths with no user disruption. Most of the work is operational, update clients, ensure RDP Shortpath and UDP egress are allowed, but when you do, your users will notice the difference.