Network Configuration for Azure Virtual Desktop (AVD) Session Hosts

Introduction: Why Network Architecture Defines the User Experience

When you deploy Azure Virtual Desktop (AVD), the performance and reliability of your environment depend almost entirely on your network architecture. While it is easy to focus on the virtual machine specifications or the operating system image, the reality is that a session host is only as good as the network path it takes to reach the user and the essential backend services. If your network configuration is flawed, users will experience input lag, screen tearing, audio stuttering, and dropped sessions, regardless of how powerful your virtual machines are.

Networking for AVD involves more than just plugging a virtual machine into a Virtual Network (VNet). It requires a deep understanding of how traffic flows between the user’s local device, the Azure control plane, and the session hosts themselves. As an administrator, you must balance security requirements—such as restricting access to the internet—with the functional requirements of the AVD service, which relies on a constant, low-latency connection to Microsoft services.

In this lesson, we will dissect the networking requirements for session hosts, examine how to design a resilient virtual network topology, and explore the specific configurations—such as Network Security Groups (NSGs), user-defined routes, and DNS settings—that ensure your AVD infrastructure remains performant and secure. By the end of this module, you will have the knowledge to build a network foundation that supports thousands of concurrent users without compromising on security or performance.

Understanding the AVD Traffic Flow

To configure your network correctly, you must first understand the three distinct types of traffic involved in an AVD deployment. Failing to distinguish between these can lead to misconfigured security rules that inadvertently block essential service communications.

1. Control Plane Traffic

The AVD control plane is managed by Microsoft. Your session hosts must communicate with this plane to register themselves, receive instructions, and report their status. This traffic is lightweight but critical; if the session host cannot reach the AVD management service, it will appear as "Unavailable" in the portal, and users will be unable to log in. This traffic flows over HTTPS (port 443).

2. Remote Desktop Protocol (RDP) Traffic

This is the traffic that carries the user's screen updates, mouse movements, and keyboard inputs. In a modern AVD deployment, this traffic often uses the RDP Shortpath protocol. RDP Shortpath attempts to establish a direct connection between the user's client and the session host over UDP. If a direct path is not available, the traffic falls back to the standard reverse-connect transport, which tunnels through the AVD gateway service.

3. Backend Resource Traffic

Session hosts rarely exist in a vacuum. They need to access file shares (like Azure Files for FSLogix profiles), Active Directory Domain Services (AD DS) or Microsoft Entra Domain Services, and internal line-of-business applications. This traffic is internal to your Azure environment or traverses your site-to-site VPN or ExpressRoute connection.

Callout: The Importance of Latency AVD performance is primarily measured by Round Trip Time (RTT). For a high-quality experience, Microsoft recommends an RTT of less than 150ms. However, for a truly fluid experience, especially with multimedia applications, you should aim for under 100ms. Network configuration—specifically minimizing the number of hops between the user and the host—is the most effective way to lower RTT.

Designing the Virtual Network (VNet) Topology

The VNet is the backbone of your AVD deployment. When planning your network, avoid the temptation to put your session hosts in the same VNet as your production database servers or other sensitive workloads. Instead, adopt a hub-and-spoke model.

The Hub-and-Spoke Approach

In a hub-and-spoke model, you centralize shared services—such as firewalls, domain controllers, and VPN gateways—in a "Hub" VNet. Your AVD session hosts reside in one or more "Spoke" VNets. This structure provides several advantages:

• Isolation: You can apply strict security policies to the session host subnet without affecting other parts of your infrastructure.
• Scalability: You can easily add more spoke VNets as your user base grows.
• Centralized Management: You manage cross-premises connectivity (VPN/ExpressRoute) in one place, reducing the complexity of routing tables.

Subnet Sizing and Planning

When planning your subnets, consider the maximum number of concurrent sessions you expect to host. Each virtual machine needs an IP address, but you should also account for potential growth and the need for IP addresses during maintenance tasks, such as when you run "drain mode" and power on new hosts to replace old ones.

Tip: Do not over-provision your subnets to the point where they become unmanageable, but always leave at least 20-30% overhead. A /24 subnet (256 addresses) is usually sufficient for a medium-sized host pool, but if you are deploying large scale-out scenarios, consider a /23 or /22 range.

Network Security Groups (NSG) Configuration

NSGs are your primary tool for controlling traffic at the subnet or network interface level. An incorrectly configured NSG is the number one cause of AVD connection failures.

Essential Inbound Rules

For AVD session hosts, you generally do not need to open any inbound ports from the internet. The AVD service uses a "reverse connect" mechanism, meaning the session host initiates the connection to the Azure service. The only inbound traffic you should allow is:

• Internal Traffic: Allow RDP (TCP/UDP 3389) or other necessary management ports only from your internal network (e.g., your management jump box).
• Load Balancer Health Probes: If you use a load balancer, you must allow traffic from the AzureLoadBalancer service tag.

Essential Outbound Rules

This is where most administrators struggle. Session hosts require access to a long list of fully qualified domain names (FQDNs) to function. If you are using a restrictive outbound policy, you must ensure the following are allowed:

• Azure Service Tags: Allow traffic to WindowsVirtualDesktop, AzureCloud, Storage, and AzureActiveDirectory.
• DNS Resolution: Ensure the hosts can reach your internal DNS servers or Azure DNS.
• Licensing and Updates: Allow access to Windows Update endpoints and Microsoft 365 activation servers.

Warning: Avoid "Allow All" Rules While it is tempting to create an outbound rule that allows all traffic to the internet, this is a significant security risk. Use Service Tags to restrict traffic to known Microsoft services. If your organization requires strict egress filtering, use a service like Azure Firewall or a third-party NVA to inspect traffic based on FQDNs rather than just IP addresses.

Implementing RDP Shortpath

RDP Shortpath is a feature that significantly improves performance by establishing a direct UDP connection between the client and the session host. To implement this, your network must support UDP traffic.

Prerequisites for RDP Shortpath

1. UDP Connectivity: The session host must be able to receive UDP traffic on ports 3390.
2. Path Availability: The user's client must have a direct network path to the session host.
3. Configuration: Enable RDP Shortpath in your AVD workspace settings via PowerShell or the Azure Portal.

Verification Process

After enabling RDP Shortpath, you can verify it is working during a user session. Open the "Connection Information" dialog within the Remote Desktop client. If Shortpath is active, the transport type will be listed as "UDP" rather than "TCP."

DNS Configuration: The Hidden Complexity

DNS issues are notoriously difficult to troubleshoot in AVD. If your session hosts cannot resolve the names of your domain controllers or your Azure Files storage account, the user login process will hang or fail completely.

Internal vs. External DNS

Your session hosts must be able to resolve both internal domain names (for domain joining) and public names (for accessing the AVD control plane).

• Azure Private DNS Zones: If you are using Azure Files for FSLogix profiles, you must link your VNet to a Private DNS Zone for the storage account. This ensures that the storage account FQDN resolves to a private IP address within your network, rather than a public one.
• Custom DNS Servers: If you use your own domain controllers for DNS, ensure your VNet is configured to use those IP addresses for its DNS settings.

Best Practices for DNS

• Always use Azure-provided DNS as a fallback if your custom DNS servers fail.
• Ensure that your DNS servers have conditional forwarders configured for the Azure internal domain (*.internal.cloudapp.net) to ensure proper resolution of Azure-native resources.
• Regularly test DNS resolution from a session host using the nslookup or Resolve-DnsName commands.

# Example: Testing DNS resolution for an Azure Files storage account
Resolve-DnsName -Name "yourstorageaccount.file.core.windows.net"

This command will return the IP address associated with the storage account. If it returns a public IP address instead of a private one, you have a configuration issue with your Private DNS Zone or VNet linking.

Managing Storage Traffic with Azure Files

FSLogix profiles are the standard for AVD user profile management. These profiles are stored on file shares, and the network performance between the session host and the file share directly impacts the "time to desktop" for the user.

Optimizing Network Paths to Storage

• Proximity: Ensure your storage account is in the same Azure region as your session hosts.
• Private Endpoints: Always use Private Endpoints for your storage accounts. This keeps the traffic on the Azure backbone and prevents it from traversing the public internet.
• Throughput: If you have a high density of users per host pool, ensure your storage account tier (Standard vs. Premium) is sufficient to handle the IOPS requirements.

Callout: Private Endpoints vs. Service Endpoints Service Endpoints allow your VNet to access Azure services over the Azure backbone, but the service still has a public IP. Private Endpoints provide a private IP address from your VNet to the service. For AVD, Private Endpoints are the gold standard for security and performance.

Troubleshooting Network Connectivity

Even with the best design, issues will arise. Having a systematic approach to troubleshooting is essential.

Step-by-Step Troubleshooting Guide

1. Check the Agent Status: Use the Azure Portal to check if the AVD agent on the session host is "Available." If it is "Unavailable," the host cannot communicate with the control plane.
2. Test Port Connectivity: Use the Test-NetConnection cmdlet to verify connectivity to critical services.

# Testing connectivity to the AVD agent service
Test-NetConnection -ComputerName "rdweb.wvd.microsoft.com" -Port 443

# Testing connectivity to a domain controller on port 389 (LDAP)
Test-NetConnection -ComputerName "10.0.0.4" -Port 389

3. Inspect NSG Flow Logs: If traffic is being blocked, NSG Flow Logs can tell you exactly which rule is dropping the packets.
4. Review Routing Tables: If you have forced tunneling (sending all traffic through an on-premises firewall), ensure that the AVD traffic is not being inadvertently blocked or dropped by your on-premises security appliance.

Comparison Table: Network Configurations

Best Practices Summary

• Use Hub-and-Spoke: Centralize your network management to reduce complexity and improve security.
• Prioritize Latency: Place session hosts in regions closest to your users.
• Enable RDP Shortpath: This is the single most effective configuration change to improve user experience.
• Use Private Endpoints: Keep all backend traffic, especially FSLogix profile traffic, off the public internet.
• Monitor with Network Watcher: Use tools like Connection Monitor to proactively alert on latency or packet loss issues.
• Keep Agents Updated: Network requirements for the AVD agent can change; keep your base images updated to ensure compatibility with the latest service protocols.

Common Pitfalls and How to Avoid Them

Pitfall 1: Over-Reliance on Forced Tunneling

Many organizations force all internet-bound traffic through an on-premises firewall for inspection. While this is great for security, it is often detrimental to AVD performance because it adds unnecessary hops to the traffic path.

• Solution: Use "Split Tunneling" or Azure Firewall to allow AVD-specific traffic to exit directly to the Microsoft cloud, while routing general internet traffic through your on-premises firewall.

Pitfall 2: Neglecting UDP for RDP

Some network administrators block UDP traffic by default, fearing it is "less secure" than TCP.

• Solution: UDP is essential for modern multimedia and real-time collaboration. Ensure your firewalls and NSGs explicitly allow UDP traffic on port 3390 for AVD session hosts.

Pitfall 3: Incorrect DNS Suffixes

If your session hosts are not correctly configured with the right DNS suffixes, they will fail to join the domain or fail to resolve internal resources.

• Solution: Ensure that your VNet DHCP settings are correctly configured to push the appropriate DNS suffix and that your domain controllers are properly registered in DNS.

Key Takeaways

1. Architecture Matters: A hub-and-spoke VNet topology is the industry standard for AVD, providing the best balance between security, scalability, and manageability.
2. Traffic Types: Understanding the difference between Control Plane, RDP, and Backend traffic is essential for writing effective Network Security Group (NSG) rules.
3. Performance Optimization: Implementing RDP Shortpath (UDP) is mandatory for achieving a low-latency, fluid user experience that rivals local desktops.
4. Security through Isolation: Use Private Endpoints for all backend services like Azure Files to ensure that sensitive data never touches the public internet.
5. DNS is Critical: Most "broken" AVD deployments are actually DNS configuration issues. Always verify your DNS resolution path as a primary troubleshooting step.
6. Proactive Monitoring: Use Azure Network Watcher to monitor latency and connectivity, rather than waiting for users to report performance issues.
7. Maintain Control: While it is tempting to simplify with "allow all" rules, strict egress filtering using Service Tags or FQDN-based firewall rules is necessary to maintain a secure environment.

By following these guidelines and maintaining a disciplined approach to your network configuration, you will ensure that your AVD infrastructure is not only secure and compliant but also delivers the high-performance experience that your users expect. Remember that in the cloud, the network is the computer; treat it with the same level of care and planning as you would any critical piece of hardware in your data center.