Over the last few years, Windows 365 has churned out a ton of great features like Windows 365 Boot and Switch. Now, we are focusing on optimizing the connect from client device to your Cloud PC with RDP Shortpath. Today, we will cover:

• How Does RDP work?
• What is RDP Shortpath?
• How Does RDP Shortpath Work?
• How RDP Shortpath Applies to Windows 365
• Configuring RDP Shortpath
• Troubleshooting RDP Shortpath

How Does RDP Work?

Before we talk about the enhancements, it might be wise to discuss how exactly the RDP protocol itself works. Specifically, let’s use AVD as an example of how RDP works today:

1. The client subscribes to the AVD workspace.
2. Entra authentication occurs and returns the token to return the resource available to the user.
3. The client sends that token to the AVD feed subscription service and the service validates the token.
4. the service sends back the list of available desktops and apps to the client with a digitally signed connection config.
5. The client stores connection config for each resource in a .rdp file.
6. When a resource is selected, the client uses that .rdp file to establish a TLS 1.2 connection to the RD Gateway leveraging Azure Front Door.
7. The latency of all gateway is evaluated and organized into groups of 10 milliseconds. The lowest latency gateway and potentially the lowest number of existing connections is selected.
8. The gateway validates the request and requests the AVD broker to orchestrate the connection.
9. The broker identifies the session host and uses the previously established comm channel to initialize the connection.
10. The RD stack initiates a TLS 1.2 connection to that gateway instance the client is using.
11. Once the client and session host are connected, the gateway will start relaying data between the endpoints. The connection will establish the base reverse connect transport to facilitate the RDP connection with a nested tunnel using TLS.
12. Once done, the RDP handshake will commence, which involves validating the gateway certificate and ending in using the session host certificate for the tunnel.

A few notes about RDP in general to consider:

• RDP runs over TCP/IP typically, but some aspects can leverage UDP.
• Sending and receiving data through RDP basically leverages the OSI model standard for LAN networking.
• Data transfer passes through the protocol stacks i.e. (data is sectioned, directed to a channel through MCS (Multipoint Communication Service), encrypted, wrapped, framed, packaged onto the network protocol, addressed, and sent over the network to the client device.

What is RDP Shortpath?

Okay, so now that I covered the mess that is RDP, let’s discuss RDP Shortpath.

RDP Shortpath unlike its friend above establishes a direct UDP-based connection between the Windows App or RD App (ick) and the session host directly in AVD or a Cloud PC in Windows 365.

We prefer a UDP-based transport because its more reliable and has more consistent latency. I know its a funny statement and Reddit is already giving me a hard time over it. The combination of UDP and a more direct path to your host IS more reliable overall. You can see below how the update to the connectivity strategy has significant benefits, but let’s talk about how it can be used.

We can leverage RDP Shortpath in a few ways:

• Private connections can use a direct UDP connection between client and host (where you enable the RDP Shortpath listener and allow the inbound ports), which typically will be over VPN or a different private network. Alternatively, you might also leverage Simple Traversal Underneath NAT (STUN), which eliminates the port requirements.
• Public networks leverage a direct connection via STUN between client and session host/Cloud PC or an indirect connection also over UDP using Traversal Using Relay NAT (TURN) with a relay between the client and session host.

The protocol chosen is based on something called URCP or “Universal Rate Control Protocol” which provides fair link utilization to ensure low delays and loss levels. This becomes incredibly important over the variety of networks that could be used e.g. Wi-Fi, hotspots, cellular networks, and more.

URCP provides a framework for rate control as it learns network parameters and automatically adapts a “utility maximization-based rate control framework” to ensure strong performance regardless of network. If you’re crazy, feel free to read this report on URCP here.

So, the TLDR is RDP Shortpath is good because:

• URCP enhances UDP to maximize performance by automatically learning characteristics of the network and using the right protocol leveraging a rate control mechanism (adapts to changing channel conditions to select optimal bitrate for data transfer).
• Reduces round-trip latency by simplifying the route to connect to your AVD Session Host/Cloud PC, which also improves connection reliability and user experience.
• On managed networks, it brings QoS (Quality of Service) for RDP and lets you limit outbound network traffic with configurable session throttle rates.

How Does RDP Shortpath Work?

Today, I will focus on how it works for public networks. As I mentioned earlier, to enhance success they have direct and indirect connection types.

Before we go into that, let’s quickly discuss the two technologies (STUN and TURN):

• STUN assists devices in a private network identify their public IPs and the type of NAT they sit behind. It helps discover each device’s IP address which is very helpful with peer-to-peer connections like WebRTC or RDP Shortpath. This is a great way to work around current NAT limitations. Below is an example of STUN:

TURN is an alternative when STUN isn’t optimal. TURN is useful with complicated network setups or restrictive environments. TURN essentially uses a relay server to facilitate the communication between client and server. TURN guarantees communication with a reliable flow of data.

Okay, now that is established let’s discuss how RDP Shortpath works with public networks.

On a direct connection, STUN is used to create the UDP connection between client and session host/Cloud PC. It requires the client to be able to communicate with a public IP and negotiated port. STUN powers the self-discovery of the public IP address behind the gateway. A key thing to note is you MUST allow UDP, or it will not work. As you can see below, the communication leverages WebSockets.

With indirect connections, TURN is used instead to relay traffic through an intermediate server as mentioned above. TURN is used because the client device cannot talk to its session host/Cloud PC. TURN still relies on a public IP and port so it can be allowed on the network.

When neither can be used, you will see a fallback to the less desirable TCP-based reverse connect transport. The Interactive Connectivity Establishing (ICE) will coordinate managing the protocol used to optimize the connection process. The RDP sessions use dynamically assigned UDP ports, which can be fine-tuned, and we will discuss later (restricting to which ports you want to allow). It’s good to note that public networks like MHNs (Microsoft-Hosted Networks) don’t require any additional configuration.

We’ll finish up here with explaining the new optimized connection sequence:

1. The session host will scan all network interfaces assigned to the session host (even VPN or Teredo).
2. The windows service “Remote Desktop Services” allocates UDP sockets on each interface and stores the IP and port pairings in the candidate table as a local candidate.
3. he RD services service will use each UDP socket allocated trying to reach the AVD/W365 STUN Server on the public internet (UDP packet is sent over UDP/3478)
4. the STUN server will respond with its public IP and port for any successes and is stored in the candidate table as a reflexive candidate.
5. Once all candidates have been gathered, the session host/Cloud PC uses the reverse connect transport to send the candidate list to the client.
6. The client will perform its own candidate gathering and then sends it to the session host/Cloud PC.
7. Once the exchange is done, both parties will try to connect with the gathered candidates simultaneously.
8. If the STUN fails for ANY reason like a block, it will try an indirect connection with TURN.
9. After the initial connection, the client and session host/Cloud PC may establish their data flows. RDP will select the fastest network path.
10. The client establishes a secure connection using TLS over reliable UDP with the session host/Cloud PC and initiates the RDP Shortpath transport.
11. Once done, all Dynamic Virtual Channels (DVCs) move to the new transport like remote graphics, input, and device redirection.

The last thing to mention is as of today TURN is only available in:

• Australia Southeast
• Central India
• East US
• East US 2
• France Central
• Japan West
• North Europe
• South Central US
• Southeast Asia
• UK South
• UK West
• West Europe
• West US
• West US 2

For additional info or information on how managed networks work, read their article here.

How RDP Shortpath Applies to Windows 365

I wanted to briefly cover how Windows 365 applies to RDP Shortpath as the Microsoft docs are more so written for AVD. Let’s start with requirements:

• Cloud PC must allow UDP outbound to all public IPs and STUN server IP ranges on UDP/3478 (Stun is 20.202.0.0/16)
• Client PC must allow UDP outbound to the public IP addresses assigned to the NAT gateway for the Azure Hosted Network, but if its MHN (Microsoft Hosted Networks) it must cover all public IPs.

In addition, it only works on the Windows App for Windows, macOS, iOS, and iPadOS. The RD app will work as long as it’s on version 1.2.3488 or greater for Windows, macOS, iOS, iPadOS, and Android.

The connection process is slightly different:

1. The RDP connection creates the TCP-based reverse connect transport through the gateway.
2. If RDP Shortpath is enabled on the Cloud PC, it will create a UDP socket for all viable NICs
3. To validate connectivity, the service will try to connect to the Windows 365 STUN server on UDP/3478 (this will establish the external IP of the NAT router)
4. The Cloud PCs candidate table lists the public IP and port that is reachable. That info is passed to the connecting client through the established TCP session.
5. The client sends its list of reachable public IPs and ports to the Cloud PC
6. Once the exchange is done, both parties will try to connect simultaneously using STUN. Any issues will fail down to TURN.
7. Once done, it validates that it’s using the fastest path. If so, all Dynamic Virtual Channels (DVCs) move to the new transport like remote graphics, input, and device redirection.

Configuring RDP Shortpath for Windows 365

As I said previously, if you’re using MHNs and public networks there is nothing to do. We will cover a few items

If you’re using an Azure Network Connection, you should configure this Admin Template in the Settings Catalog and deploy it to your Cloud PCs:

I also strongly recommend enabling Teredo support on your devices to enhance the experience:

Set-NetTeredoConfiguration -Type Enterpriseclient

An optional, but recommended step is to limit the port changes for STUN and TURN, which you can do via Intune as well. This tends to help with adoption and support from your InfoSec team because you can more tightly control the ports being used:

That’s the beauty of things. That is all you need to configure. We will finish things up with troubleshooting.

Troubleshooting RDP Shortpath

The first place I start with troubleshooting is the awesome avdnettest.exe, where you just double-click on it and it will tell you if everything looks healthy:

The second thing you want to check is see if UDP is enabled on the Cloud PC with this code:

$regKey = Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services"

If ($regKey.PSObject.Properties.name -contains "SelectTransport" -eq "True") {
    If (($regkey | Select-Object -ExpandProperty "SelectTransport") -eq 1) {
        Write-Output "The RDP transport protocols setting has changed. Its value is: Use only TCP."
    } elseif (($regkey | Select-Object -ExpandProperty "SelectTransport") -eq 2) {
        Write-Output "The default RDP transport protocols setting has changed. Its value is: Use either UDP or TCP."
    }
} else {
    Write-Output "The RDP transport protocols setting hasn't been changed from its default value. UDP is enabled."
}

Hopefully you get lucky, and it resolves to this: The RDP transport protocols setting hasn’t been changed from its default value.

Next, we will make sure UDP is enabled on Windows devices and make sure it returns the same result as the previous command:

$regKey = Get-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client"

If ($regKey.PSObject.Properties.name -contains "fClientDisableUDP" -eq "True") {
    If (($regkey | Select-Object -ExpandProperty "fClientDisableUDP") -eq 1) {
        Write-Output "The default setting has changed. UDP is disabled."
    } elseif (($regkey | Select-Object -ExpandProperty "fClientDisableUDP") -eq 0) {
        Write-Output "The default setting has changed, but UDP is enabled."
    }
} else {
    Write-Output "The default setting hasn't been changed from its default value. UDP is enabled."
}

If you do run into any of those issues, you just need to check your group policy/Intune config for these settings and set them to “Disabled” (I avoid “Not Configured” because it’s not always consistent):

• For Intune policy: Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > Turn Off UDP On Client.
• For Group Policy: Computer Configuration > Policies > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Connection Client > Turn Off UDP On Client.

The other thing you should do is also verify RDP Shortpath is working, which you can do by checking the “Connection Information” button and expanding it as you can see below:

STUN will look like this:

TURN will look like this: