If you’ve been managing Windows 365 Cloud PCs, you’ve probably noticed that connection quality can vary significantly depending on where your users are working from. Sometimes connections are lightning fast; other times, they feel sluggish. The secret to optimal connectivity lies in understanding how modern RDP transport works, specifically the roles of STUN and TURN in RDP Shortpath.
In this article, I’ll walk you through how these technologies work, why they matter, and how to configure them centrally using Microsoft Intune now that centralised RDP Shortpath configuration is generally available (announced January 28, 2026). First, we will explain these features, as you might not be aware of them, and then discuss best practices.
What Is RDP Shortpath and Why Should You Care?
Traditional RDP connections to Windows 365 Cloud PCs travel through Microsoft’s RD Gateway over TCP. While reliable, this path can introduce latency and isn’t always optimal for real-time interactive workloads. RDP Shortpath changes the game by providing UDP-based transport paths that significantly improve connection performance and reliability.

Think of it this way: TCP is like sending a certified letter through multiple post offices; it’s reliable but slow. UDP via RDP Shortpath is more like a direct phone call, faster and more responsive, especially for the real-time nature of remote desktop sessions. Many protocols are increasingly favouring UDP for performance over TCP.
RDP Shortpath uses Interactive Connectivity Establishment (ICE) to intelligently find the best network path between the client and your Cloud PC. There are three modes available:

How STUN Works: The Direct Path
STUN (Session Traversal Utilities for NAT) is the preferred method for public internet connectivity because it enables direct peer-to-peer communication between your client device and the Cloud PC.
Here’s the connection flow:

STUN Connection Flow
What’s happening here?
- Your client device contacts Microsoft’s STUN server (UDP port 3478) to discover its own public IP address and port
- The Cloud PC does the same thing
- Armed with each other’s public endpoint information, both sides can establish a direct UDP connection
- All RDP traffic flows directly between client and Cloud PC—no middleman
Why this matters: STUN provides the lowest latency and best performance because traffic takes the shortest possible path. There’s no relay, no extra hop—just direct communication.
The catch: STUN only works when both the client and Cloud PC are behind NAT types that allow direct connectivity (cone NAT, restricted cone NAT, port-restricted cone NAT). If either side is behind a symmetric NAT or highly restrictive firewall, STUN won’t work.
How TURN Works: The Reliable Fallback
TURN (Traversal Using Relays around NAT) kicks in when STUN can’t establish a direct connection. Instead of peer-to-peer communication, traffic is relayed through Microsoft’s TURN servers.

TURN Connection Flow
What’s happening here?
- Both the client and Cloud PC connect to Microsoft’s TURN relay infrastructure
- The TURN server allocates relay endpoints for both sides
- All RDP traffic flows through the TURN relay—client to relay to Cloud PC and back
Why this matters: TURN ensures connectivity even in challenging network environments: – Behind symmetric NAT (common in corporate networks and mobile carriers) – Behind restrictive firewalls that block peer-to-peer UDP – In complex network topologies that prevent direct routing
The trade-off: TURN adds an extra hop, resulting in slightly higher latency than STUN. However, it’s still significantly better than TCP fallback because UDP is inherently better suited for real-time interactive workloads.
The Connection Fallback Flow
When a user connects to their Cloud PC, the system automatically attempts connections in order of preference:

Connection Fallback Flow
The system is intelligent about this; it doesn’t just try once and give up. It continuously evaluates network conditions and switches paths when conditions change. This is why keeping all modes enabled is so important.
Why Centralised Configuration Changes Everything
Before January 2026, RDP Shortpath behaviour had to be configured manually or via scripting on each individual Cloud PC. In large, distributed environments, this caused:
- Inconsistent configurations across your fleet
- Increased operational overhead for IT teams
- Unpredictable connection behaviour for end users
The new centralised policy capability through Microsoft Intune eliminates these headaches:
- No per-device manual setup: Policies deploy configuration automatically
- Predictable, enforced behaviour: Consistent settings across all managed Cloud PCs
- Granular control: Selectively enable or disable modes based on security requirements or network readiness
Configuring RDP Shortpath via Microsoft Intune
Here’s how to configure RDP Shortpath centrally:
Step 1: Create a Configuration Profile
- Sign in to the Microsoft Intune admin centre (https://intune.microsoft.com)
- Navigate to Devices > Configuration profiles
- Click Create profile
- Select:
- Platform: Windows 10 and later
- Profile type: Settings catalogue
Step 2: Configure the RDP Shortpath Settings
- Click Add settings in the configuration settings
- Browse to: Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Azure Virtual Desktop > RDP Shortpath
- Note: The Settings Catalogue uses “Azure Virtual Desktop” in the path, but these settings apply to Windows 365 Cloud PCs as well.
- Add the following settings:

- Configure the following settings.
| Setting | Recommended Value |
|---|---|
| RDP Shortpath for managed networks using NAT traversal | Enabled |
| RDP Shortpath for public networks using NAT traversal (STUN) | Enabled |
| RDP Shortpath for public networks using Relay (TURN) | Enabled |
Step 3: Assign to Device Groups
- Click Next to reach Assignments
- Select the device group containing your Windows 365 Cloud PCs
- Complete the profile creation wizard
Step 4: Restart Cloud PCs
Critical: Policy changes require a Cloud PC restart to take effect. Plan a maintenance window or coordinate with users.
My Configuration Recommendations
For Most Organisations: Enable Everything
Microsoft recommends, and I strongly agree, keeping all three modes enabled. Here’s why:
Managed Networks: Enabled
STUN: Enabled
TURN: Enabled
This configuration allows the system to automatically select the optimal path based on real-time network conditions. Your users working from home on residential internet might get direct STUN connections. Those on mobile hotspots behind carrier-grade NAT will fall back to TURN. Either way, they get the best possible experience without manual intervention.
High-Security Environments
If your organisation has strict requirements about traffic paths:
Managed Networks: Enabled (if VPN/private connectivity exists)
STUN: Consider disabling (if direct internet paths are not permitted)
TURN: Enabled (for reliable fallback)
Warning: Disabling STUN will degrade performance for remote workers. Only do this if the security policy absolutely requires it.
Troubleshooting Connectivity Issues
When diagnosing connection problems, temporarily isolating path options can help:
Managed Networks: Enabled
STUN: Enabled
TURN: Disabled (temporarily)
Important: Microsoft explicitly warns that disabling TURN reduces successful connection rates and can force TCP fallback. Only disable TURN temporarily for troubleshooting, then re-enable it.
Network Prerequisites
Before deploying your Intune policy, ensure your network meets these requirements:
| Requirement | Direction | Protocol/Port |
|---|---|---|
| UDP traffic allowed | Both | UDP (various) |
| STUN server access | Outbound from Cloud PC | UDP 3478 |
| Microsoft TURN relay endpoints | Outbound | UDP |
Key points: – UDP must be allowed on both client and Cloud PC networks – If UDP is blocked entirely, connections fall back to TCP regardless of your policy settings – STUN/TURN Microsoft endpoints must be reachable from your Cloud PCs
How to Verify Your Configuration
After deployment:
- Check Intune compliance reports to verify policy application
- Review Windows 365 monitoring in the Intune admin centre for connection quality metrics
- Examine connection logs to confirm UDP transport is being used (vs. TCP fallback)
- Gather user feedback, and they’ll notice the difference when Shortpath is working
Wrapping Up
RDP Shortpath with STUN and TURN represents a significant improvement in how we connect to Windows 365 Cloud PCs. By understanding the technology and configuring it correctly, you can deliver a dramatically better experience to your users, especially those working remotely or in challenging network environments.
The key takeaways:
- STUN = Direct = Best performance (when network conditions allow)
- TURN = Relayed = Reliable fallback (keep it enabled!)
- Enable all three modes unless you have a specific reason not to
- Use Intune for centralised management instead of per-device configuration
- Remember the restart requirement after policy changes

