Proxy server guidelines for Azure Virtual Desktop
This article will show you how to use a proxy server with Azure Virtual Desktop. The recommendations in this article only apply to connections between Azure Virtual Desktop infrastructure, client, and session host agents. This article doesn't cover network connectivity for Office, Windows 10, FSLogix, or other Microsoft applications.
What are proxy servers?
We recommend bypassing proxies for Azure Virtual Desktop traffic. Proxies don't make Azure Virtual Desktop more secure because the traffic is already encrypted. To learn more about connection security, see Connection security.
Most proxy servers aren't designed for supporting long running WebSocket connections and may affect connection stability. Proxy server scalability also causes issues because Azure Virtual Desktop uses multiple long-term connections. If you do use proxy servers, they must be the right size to run these connections.
If the proxy server's geography is far from the host, then this distance will cause more latency in your user connections. More latency means slower connection time and worse user experience, especially in scenarios that need graphics, audio, or low-latency interactions with input devices. If you must use a proxy server, keep in mind that you need to place the server in the same geography as the Azure Virtual Desktop Agent and client.
If you configure your proxy server as the only path for Azure Virtual Desktop traffic to take, the Remote Desktop Protocol (RDP) data will be forced over Transmission Control Protocol (TCP) instead of User Datagram Protocol (UDP). This move lowers the visual quality and responsiveness of the remote connection.
In summary, we don't recommend using proxy servers on Azure Virtual Desktop because they cause performance-related issues from latency degradation and packet loss.
Bypassing a proxy server
If your organization's network and security policies require proxy servers for web traffic, you can configure your environment to bypass Azure Virtual Desktop connections while still routing the traffic through the proxy server. However, each organization's policies are unique, so some methods may work better for your deployment than others. Here are some configuration methods you can try to prevent performance and reliability loss in your environment:
- Azure service tags with Azure Firewall
- Proxy server bypass using Proxy Auto Configuration (
.PAC) files - Bypass list in the local proxy configuration
- Using proxy servers for per-user configuration
- Using RDP Shortpath for the RDP connection while keeping the service traffic over the proxy
Recommendations for using proxy servers
Some organizations require that all user traffic goes through a proxy server for tracking or packet inspection. This section describes how we recommend configuring your environment in these cases.
Use proxy servers in the same Azure geography
When you use a proxy server, it handles all communication with the Azure Virtual Desktop infrastructure and performs DNS resolution and Anycast routing to the nearest Azure Front Door. If your proxy servers are distant or distributed across an Azure geography, your geographical resolution will be less accurate. Less accurate geographical resolution means connections will be routed to a more distant Azure Virtual Desktop cluster. To avoid this issue, only use proxy servers that are geographically close to your Azure Virtual Desktop cluster.
Use RDP Shortpath for managed networks for desktop connectivity
When you enable RDP Shortpath for managed networks, RDP data will bypass the proxy server, if possible. Bypassing the proxy server ensures optimal routing while using the UDP transport. Other Azure Virtual Desktop traffic, such as brokering, orchestration, and diagnostics will still go through the proxy server.
Don't use SSL termination on the proxy server
Secure Sockets Layer (SSL) termination replaces security certificates of the Azure Virtual Desktop components with certificates generated by proxy server. This proxy server feature enables packet inspection for HTTPS traffic on the proxy server. However, packet inspection also increases the service response time, making it take longer for users to sign in. For reverse-connect scenarios, RDP traffic packet inspection isn't necessary because reverse-connect RDP traffic is binary and uses extra levels of encryption.
If you configure your proxy server to use SSL inspection, remember that you can't revert your server to its original state after the SSL inspection makes changes. If something in your Azure Virtual Desktop environment stops working while you have SSL inspection enabled, you must disable SSL inspection and try again before you open a support case. SSL inspection can also cause the Azure Virtual Desktop agent to stop working because it interferes with trusted connections between the agent and the service.
Don't use proxy servers that need authentication
Azure Virtual Desktop components on the session host run in the context of their operating system, so they don't support proxy servers that require authentication. If the proxy server requires authentication, the connection will fail.
Plan for the proxy server network capacity
Proxy servers have capacity limits. Unlike regular HTTP traffic, RDP traffic has long running, chatty connections that are bi-directional and consume lots of bandwidth. Before you set up a proxy server, talk to your proxy server vendor about how much throughput your server has. Also make sure to ask them how many proxy sessions you can run at one time. After you deploy the proxy server, carefully monitor its resource use for bottlenecks in Azure Virtual Desktop traffic.
Proxy servers and Microsoft Teams media optimization
Azure Virtual Desktop doesn't support proxy servers with media optimization for Microsoft Teams.
Session host configuration recommendations
To configure a session host level proxy server, you need to enable a systemwide proxy. Remember that systemwide configuration affects all OS components and applications running on the session host. The following sections are recommendations for configuring systemwide proxies.
Use the Web Proxy Auto-Discovery (WPAD) protocol
The Azure Virtual Desktop agent automatically tries to locate a proxy server on the network using the Web Proxy Auto-Discovery (WPAD) protocol. During a location attempt, the agent searches the domain name server (DNS) for a file named wpad.domainsuffix. If the agent finds the file in the DNS, it makes an HTTP request for a file named wpad.dat. The response becomes the proxy configuration script that chooses the outbound proxy server.
To configure your network to use DNS resolution for WPAD, follow the instructions in Auto detect settings Internet Explorer 11. Make sure the DNS server global query blocklist allows the WPAD resolution by following the directions in Set-DnsServerGlobalQueryBlockList.
Manually set a device-wide proxy for Windows services
If you're specifying a proxy server manually, at a minimum you will need to set a proxy for the Windows services RDAgent and Remote Desktop Services on your session hosts. RDAgent runs with the account Local System and Remote Desktop Services runs with the account Network Service. You can set a proxy for these accounts using the bitsadmin command-line tool.
The following example configures the Local System and Network Service accounts to use a proxy .pac file . You'll need to run these commands from an elevated command prompt, changing the placeholder value for <server> with your own address:
bitsadmin /util /setieproxy LOCALSYSTEM AUTOSCRIPT http://<server>/proxy.pac
bitsadmin /util /setieproxy NETWORKSERVICE AUTOSCRIPT http://<server>/proxy.pac
For a full reference and other examples, see bitsadmin util and setieproxy.
You can also set a device-wide proxy or Proxy Auto Configuration (.PAC) file that applies to all interactive, Local System, and Network Service users. If your session hosts are enrolled with Intune, you can set a proxy with the Network Proxy CSP, however, Windows multi-session client operating systems don't support Policy CSP as they only support the settings catalog. Alternatively you can configure a device-wide proxy using the netsh winhttp command. For a full reference and examples, see Netsh Commands for Windows Hypertext Transfer Protocol (WINHTTP)
Client-side proxy support
The Azure Virtual Desktop client supports proxy servers configured with system settings or a Network Proxy CSP.
Azure Virtual Desktop client support
The following table shows which Azure Virtual Desktop clients support proxy servers:
| Client name | Proxy server support |
|---|---|
| Windows Desktop | Yes |
| Web client | Yes |
| Android | No |
| iOS | Yes |
| macOS | Yes |
| Windows Store | Yes |
For more information about proxy support on Linux based thin clients, see Thin client support.
Support limitations
There are many third-party services and applications that act as a proxy server. These third-party services include distributed next-gen firewalls, web security systems, and basic proxy servers. We can't guarantee that every configuration is compatible with Azure Virtual Desktop. Microsoft only provides limited support for connections established over a proxy server. If you're experiencing connectivity issues while using a proxy server, Microsoft support recommends you configure a proxy bypass and then try to reproduce the issue.
Next steps
For more information about keeping your Azure Virtual Desktop deployment secure, check out our security guide.
Feedback
Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback.
Submit and view feedback for