Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Azure Virtual Desktop (AVD) session hosts and Windows 365 Cloud PCs require connectivity to two Azure platform IP addresses. These addresses provide access to core infrastructure services that support provisioning, health monitoring, identity, and platform communication.
Traffic to these addresses operates at the Azure platform fabric level. It behaves differently from traffic to FQDN-based endpoints and must be handled accordingly.
This article explains what these IP addresses are, why they're essential, how they differ from other endpoints, and how to ensure connectivity is successful.
Overview
Azure Virtual Desktop session hosts and Windows 365 Cloud PCs require connectivity to the following IP addresses:
| Address | Protocol | Outbound Port | Purpose | Service Tag |
|---|---|---|---|---|
169.254.169.254 |
TCP | 80 | Azure Instance Metadata Service (IMDS) | N/A |
168.63.129.16 |
TCP | 80, 32526 | Session Host health monitoring | N/A |
Important
These addresses are used in all Azure regions and cloud environments, including Azure public cloud, Azure Government, and Azure China. Loss of connectivity to either address causes provisioning failures, health reporting issues, and service degradation.
Azure Instance Metadata Service (169.254.169.254)
Azure Instance Metadata Service (IMDS) is a REST API endpoint that provides information about a running virtual machine. Software inside the Virtual Machine (VM) uses IMDS to integrate with the Azure environment.
VMs use IMDS to retrieve:
VM identity and configuration data
Managed identity tokens for authentication to Azure services
Scheduled events and maintenance notifications
Metadata such as region, availability zone, VM size, and network configuration
The address 169.254.169.254 is a link-local IP address. It's non-routable and accessible only from within the VM. Requests to this address never leave the physical host. The Azure hypervisor intercepts and responds to the traffic locally.
IMDS operates at the hypervisor level. It isn't affected by network security groups, user-defined routes, or Azure Firewall rules. However, operating system configuration inside the VM, such as host firewalls or VPN clients, can block access.
Azure platform health monitoring (168.63.129.16)
The address 168.63.129.16 is a virtual public IP address used by Azure platform services to communicate with VMs. This address is also called the WireServer endpoint.
VMs use this address for:
Health monitoring and heartbeat communication from the Azure VM agent
DNS resolution when using Azure-provided DNS
DHCP communication for IP address assignment and renewal
Traffic to 168.63.129.16 traverses the Azure virtual network fabric. Azure platform routing applies special handling to ensure the address remains reachable in networks with restrictive security or routing configurations.
Differences from standard endpoints
Azure Virtual Desktop and Windows 365 also require connectivity to FQDN-based endpoints, such as control plane services, Microsoft Entra ID, etc. Traffic to those endpoints behaves like standard internet traffic to public IP addresses. Some of this traffic like RDP requires optimization in customer networks but generally can be treated like normal public endpoints.
Traffic to 169.254.169.254 and 168.63.129.16 however, behaves differently.
Azure-internal and non-routable. These addresses are part of Azure internal platform infrastructure. They aren't internet endpoints, don't resolve via public DNS, and can't be accessed from outside Azure or from on-premises networks.
They can't be proxied as proxy servers aren't able to reach these addresses. Attempts to send this traffic through a proxy will not be successful, whether via PAC files, Group Policy, or application proxy settings.
They can't traverse VPN tunnels or secure web gateways. VPN clients and secure web gateway agents that operate in full-tunnel or forced-tunnel mode capture all traffic from the VM. When they capture traffic to these addresses, connectivity fails because the addresses aren't reachable over VPN tunnels or third-party security infrastructure.
Partially protected by Azure platform routing. Azure networking includes protections to ensure connectivity to these addresses at the fabric layer. Default routes such as 0.0.0.0/0 and most network security group rules don't block this traffic. However, these protections don't apply to configuration inside the VM or to explicit network rules that target these addresses or their service tags.
It's therefore essential that you ensure the following configuration issues aren't present in your environment:
In-VM configuration issues
Most connectivity issues are due to configuration inside the VM rather than by Azure network-layer configuration.
VPN clients and secure web gateway agents
Organizations deploy VPN clients or secure web gateway agents on Cloud PCs and session hosts to enforce security policies. Examples include Zscaler Internet Access, Microsoft Entra Internet Access, PaloAlto Global Protect etc.
When these agents run in forced-tunnel mode, they redirect all traffic through a virtual adapter. This configuration can include traffic to Azure platform addresses, which breaks connectivity.
What to check:
Use split tunneling so Azure platform traffic remains local
Configure explicit bypass or exclusion rules for 169.254.169.254 and 168.63.129.16
Proxy and PAC configuration
Proxy settings applied via PAC files, Group Policy, WinHTTP, WinINET, or application-specific settings can cause the VM to proxy Azure platform traffic.
What to check:
PAC files return a direct connection for these addresses
Proxy bypass lists include both addresses
User-level and machine-level proxy settings are reviewed
Host firewall rules
Host-based firewalls or endpoint protection software may block outbound TCP traffic.
What to check:
Allow outbound TCP traffic to 169.254.169.254 on port 80
Allow outbound TCP traffic to 168.63.129.16 on ports 80 and 32526
Endpoint security and network filtering software
Antivirus, Endpoint Detections & Response (EDR), or Data Loss Prevention (DLP) tools may include network inspection features.
What to check:
Ensure these tools don't block or inspect traffic to these addresses
Add IP-based allow or exclusion rules where required
Azure Network-layer configuration issues
Network security groups
Azure defines service tags for these endpoints:
AzurePlatformIMDS for 169.254.169.254
AzurePlatformDNS for 168.63.129.16
Explicit deny rules targeting these service tags can interfere with connectivity.
What to check:
Remove deny rules targeting these service tags or addresses
Ensure restrictive deny-all outbound rules include explicit allow rules for these service tags
User-defined routes and network virtual appliances
Azure platform routing normally ensures reachability regardless of default routes. However, explicit routes or complex routing topologies can cause issues.
What to check:
No routes explicitly target 169.254.169.254 or 168.63.129.16
Firewalls or network virtual appliances in the path allow outbound traffic to these addresses and ports
Azure Network Connection health checks
Windows 365 Enterprise uses Azure Network Connections to provision Cloud PCs. Each connection includes automated health checks that validate network connectivity.
What health checks validate
Network fabric connectivity to Azure platform endpoints
Network security group configuration
Route table configuration
DNS resolution using Azure-provided DNS
What health checks don't validate
VPN clients or secure web gateway agents installed after provisioning
Proxy or PAC configuration applied via Group Policy or Intune
Host firewall rules or endpoint security software
Configuration applied inside the VM after assignment
A passing health check confirms that the Azure network allows platform traffic. It doesn't guarantee that Cloud PCs or session hosts can reach these endpoints after in-VM configuration is applied.
Summary
Connectivity to 169.254.169.254 and 168.63.129.16 is required for Azure Virtual Desktop and Windows 365. Blocking of these endpoints lead to provisioning and operational issues with both Windows 365 and Azure Virtual Desktop.
These addresses are Azure-internal platform endpoints. Traffic to these addresses must not be proxied, intercepted, or routed through VPN tunnels or secure web gateways.
Most connectivity failures are due to configuration inside the VM, such as VPN clients, proxy settings, host firewalls, or endpoint security software. Network-layer issues are less common but can occur when explicit rules target these addresses or their service tags.
Azure Network Connection health checks validate network-layer connectivity only. They don't detect in-VM configuration issues.