Fix Windows 365 Azure network connection health check failures

Since April 2026, Windows 365 Azure network connection (ANC) health checks return an Error instead of a Warning when the Cloud PC subnet can't reach *.service.windows.cloud.microsoft, *.windows.cloud.microsoft or *.windows.static.microsoft, and that error blocks new Cloud PC provisioning. To fix it, allow those wildcard FQDNs on port 443 through every firewall, proxy and secure web gateway in the path without TLS inspection, make sure the subnet has an explicit outbound method such as a NAT gateway, and then select Retry on the connection in the Intune admin center.

Who this is for and what you will have

This guide is for administrators who provision Windows 365 Enterprise or Flex Cloud PCs into their own Azure virtual network and see an ANC stuck in Checks failed, or warnings that turned into errors. It covers the endpoint enforcement change and every other documented health check. At the end you will have:

• An understanding of what changed in 2026 and why it surfaces now.
• A subnet with explicit, inspection-free outbound access to the required endpoints.
• A test routine you can run from a VM on the Cloud PC subnet.
• A fix for each failed check, from DNS and domain join to permissions and IP space.

What changed in 2026

Two changes landed close together and often show up as the same symptom.

Endpoint enforcement (week of April 6, 2026). Microsoft's What's new page for Windows 365 Enterprise states that ANC health checks return an Error instead of a Warning if these required endpoints aren't reachable, blocking new Cloud PC provisioning until resolved. The Azure Virtual Desktop required FQDN list gives the port, purpose and service tag for each:

No new endpoints were added, and existing Cloud PCs and Microsoft-hosted network deployments aren't affected. If your connection showed Checks successful with warnings because of these endpoints before April, it now shows Checks failed.

Private subnets by default (March 31, 2026). For Azure API versions released after March 31, 2026, subnets in new virtual networks have defaultOutboundAccess set to false, which makes them private. VMs in private subnets have no implicit internet path. Microsoft's ANC architecture guidance states that ANC Cloud PC provisioning fails on private subnets without an explicit outbound configuration, because provisioning, agent updates, Windows activation and RDP brokering all need outbound access. Existing virtual networks aren't changed, so this mostly affects networks built recently with templates, Terraform or the portal (which already defaults to private subnets).

How ANC health checks work

An ANC is an Intune object that tells provisioning policies which subscription, resource group, virtual network and subnet to use, plus the AD domain details for hybrid join. Windows 365 validates it by creating a temporary Azure VM in your subnet, running the checks, and deleting the VM. Key behaviors:

• Checks run every one to six hours and a full check can take up to 30 minutes.
• During the first check after creation, the ANC can't be assigned to a provisioning policy.
• For hybrid join ANCs, each run creates a disabled computer object named like CPC-Hth in the target OU. Don't delete the watchdog account the service creates there.
• ANCs that stay unused for a period of time become Inactive, which pauses checks until you reactivate them.

The statuses you will see:

Prerequisites

• The Intune Administrator or Windows 365 Administrator role to view details and retry checks. Creating or editing an ANC also needs at least the Reader role on the subscription that holds the virtual network.
• Access to the Azure subscription, virtual network, route tables, network security groups and firewall that serve the Cloud PC subnet.
• A test VM in the same subnet as the Cloud PCs. Microsoft repeatedly recommends testing from a VM on that subnet, because that is exactly where the health check VM runs.
• For hybrid join, the AD domain join account details and access to a domain controller.

Step 1: Read the failed check

1. Sign in to the Microsoft Intune admin center.
2. Go to Devices > Windows 365 (under Provisioning) > Azure network connection.
3. Select the connection, find each check with a failed or warning state, and select View details for the technical reason.
4. Note the subnet's IP availability count on the same page, which Microsoft added in March 2026 for capacity planning.

Fix the checks in the order the rest of this guide follows; outbound connectivity problems often cause DNS, domain join and endpoint failures at the same time.

Step 2: Give the subnet explicit outbound access

Check whether the Cloud PC subnet is private:

$vnet = Get-AzVirtualNetwork -ResourceGroupName "rg-cloudpc-network" -Name "vnet-cloudpc"
$vnet.Subnets | Select-Object Name, DefaultOutboundAccess

A value of False means the subnet is private and needs one of these explicit methods (an empty value or True means default outbound access is still available):

• A NAT gateway associated with the subnet. Microsoft calls this the recommended method for most scenarios, and Windows 365 guidance prefers it for long-lived RDP and VPN or SWG traffic.
• Azure Firewall or another network virtual appliance, reached through a user-defined route (UDR) of 0.0.0.0/0.
• Outbound rules on a Standard public load balancer.

A common Windows 365 pattern sends 0.0.0.0/0 to Azure Firewall and adds a more specific UDR for the WindowsVirtualDesktop service tag with next hop Internet, so RDP bypasses the firewall. In a private subnet, a next hop of Internet breaks unless the subnet also has an explicit outbound method, so pair that route with a NAT gateway.

Step 3: Allow the required endpoints without inspection

Required endpoints must be reachable from the virtual network and from the Cloud PCs, and firewalls, NSGs, proxies, secure web gateways and TLS inspection must not block or interfere with them. Microsoft's guidance is explicit: avoid TLS inspection on the ANC virtual network, don't put a proxy between the Cloud PC subnet and the internet, and route required endpoints to an egress point in Azure rather than back through on-premises.

If you use Azure Firewall, use application rules with these FQDN tags:

Then add network rules for the endpoints the tags can't cover because they use nonstandard ports:

If you use a third-party firewall or a secure web gateway, add the three enforced wildcards explicitly, along with *.infra.windows365.microsoft.com, the registration endpoints and the Intune and AVD session host endpoints from Microsoft's lists. Microsoft notes that service traffic entries must be allowed as wildcards, and that many endpoints can't be expressed as IP ranges, so use FQDN-based rules.

Also confirm nothing on the network or the image intercepts the Azure platform addresses 168.63.129.16 and 169.254.169.254. Microsoft states that traffic to them must not be intercepted, proxied or redirected.

Step 4: Test from a VM on the Cloud PC subnet

Wildcard FQDNs can't be tested directly, but you can confirm the firewall path to the other required endpoints that have fixed host names:

$targets = @(
    @{ Host = "login.microsoftonline.com";             Port = 443 },
    @{ Host = "enterpriseregistration.windows.net";    Port = 443 },
    @{ Host = "global.azure-devices-provisioning.net"; Port = 5671 },
    @{ Host = "azkms.core.windows.net";                Port = 1688 }
)
 
foreach ($t in $targets) {
    $r = Test-NetConnection -ComputerName $t.Host -Port $t.Port -InformationLevel Detailed
    "{0}:{1} -> {2}" -f $t.Host, $t.Port, $r.TcpTestSucceeded
}

Any False result points to a missing firewall rule, NSG rule or outbound path. A success here doesn't prove the wildcard rules are complete, so also review the rule set itself for the three enforced wildcards. If TLS inspection is enabled anywhere in the path, these TCP tests can pass while the service still fails, so check the inspection policy too.

For hybrid join connections, confirm name resolution of your AD domain from the same VM:

Resolve-DnsName -Name "_ldap._tcp.contoso.com" -Type SRV
Resolve-DnsName -Name "contoso.com"

Fixes for every other failed check

DNS can resolve Active Directory domain. The health check resolves the domain name and looks for _ldap._tcp.<domain> SRV records. Set the virtual network's DNS servers to custom internal servers that resolve AD DS records, in the same region if possible, and make sure the subnet routes to them. If your AD domain name also resolves publicly (for example contoso.com), the DNS servers must return internal records.

Active Directory domain join. Confirm the join account can join computers to the OU in the ANC, isn't limited by the default of 10 computer joins per user, and that the subnet can reach a domain controller. Test with Add-Computer -DomainName contoso.com -OUPath "OU=CloudPCs,DC=contoso,DC=com" -Credential (Get-Credential) from a VM on the subnet. A recent password change on the join account also causes this failure. If the details show Internal Server Error or InternalServerErrorUnableToRunDscScript, check domain controller line of sight, endpoint access, and that WinRM isn't restricted to specific IP addresses by Group Policy or Intune for the provisioning policy's groups.

Microsoft Entra device sync (warning). The computer object must reach Entra ID within 90 minutes or provisioning fails; Microsoft recommends under 30 minutes and no more than 60. Check the Entra Connect sync interval and server health. A warning right after a sync cycle with no provisioning failures needs no action.

Azure subnet IP address usage. Each Cloud PC consumes an IP and a vNIC. Leave room for three provisioning retries per Cloud PC, remove orphaned vNICs, and use a dedicated subnet. CanNotDelete locks at the resource group level or above stop vNICs from being cleaned up, so remove those vNICs by hand before retrying. Microsoft's architecture guidance suggests 1.5 to 2 times the maximum Cloud PC count in address space.

Azure tenant readiness. The subscription must be enabled and no Azure Policy assignment may block creation of Windows 365 resources, such as region or SKU restrictions. Exclude the Cloud PC resource group and virtual network from policies that block vNIC creation.

Azure virtual network readiness. The virtual network must be in a supported Windows 365 region.

First party app permissions. The Windows 365 service principal needs Reader on the subscription, Windows365 Network Interface Contributor on the resource group and Windows365 Network User on the virtual network. Classic subscription administrator roles don't count.

Intune enrollment restrictions allow Windows enrollment. The default device type enrollment restriction must allow the Windows (MDM) platform for corporate enrollment.

Localization language package readiness. The OS and Microsoft 365 language packages and the localization download link must be reachable. Make sure your firewall rules allow the language pack download locations for the Windows image versions you provision.

UDP connection check. The network must allow UDP through STUN or the TURN relay; allow 51.5.0.0/16 on UDP 3478.

Single sign-on configuration. For hybrid joined Cloud PCs with SSO, a Kerberos server object must exist in AD and sync to Entra ID.

Environment and configuration are ready. This covers infrastructure issues such as service timeouts or resources changed during a run. Retry the checks, and open a support case if the failure persists.

Retry and confirm

1. In Devices > Windows 365 > Azure network connection, select the connection and choose Retry.
2. Wait for Running checks to finish, up to 30 minutes.
3. Confirm Checks successful, or Checks successful with warnings where the only warning is Entra device sync.
4. Check the provisioning status of users whose Cloud PCs failed while the ANC was unhealthy.

Changes to an ANC only apply to Cloud PCs provisioned afterwards; existing Cloud PCs keep their original settings unless you reprovision them, which is destructive.

Consider the Microsoft-hosted network

Microsoft recommends the Microsoft-hosted network for most new deployments and reserves ANC for hybrid join, direct network-level access to on-premises subnets, or customer-managed network controls. On-premises apps can be reached from Microsoft-hosted Cloud PCs through Microsoft Entra Private Access or another Zero Trust network access solution, an approach described in the Zero Trust remote access architecture. A tenant can run both models side by side per provisioning policy. For the broader platform choice, see Windows 365 vs Azure Virtual Desktop.

Checklist

• Cloud PC subnet has an explicit outbound method; DefaultOutboundAccess checked.
• *.service.windows.cloud.microsoft, *.windows.cloud.microsoft and *.windows.static.microsoft allowed on TCP 443 as wildcards.
• Windows365 and MicrosoftIntune FQDN tags plus nonstandard-port network rules in place.
• No TLS inspection or proxy on Cloud PC traffic; 168.63.129.16 and 169.254.169.254 untouched.
• DNS resolves the AD domain and SRV records from the subnet.
• Join account permissions and OU limits verified; WinRM not IP-restricted.
• Subnet has spare IPs and no locks blocking vNIC cleanup.
• Service principal roles present at subscription, resource group and virtual network scope.
• Health check retried and showing successful.

References

• What's new in Windows 365 Enterprise
• Azure network connection health checks in Windows 365
• Troubleshoot Azure network connections
• Azure network connection overview
• Network requirements for Windows 365
• Windows 365 Cloud PC connectivity requirements
• Use Azure Firewall to manage and secure Windows 365 environments
• Required FQDNs and endpoints for Azure Virtual Desktop
• Windows 365 Azure Network Connection (Azure Architecture Center)
• Default outbound access in Azure
• Windows 365 requirements
• Test-NetConnection
• Resolve-DnsName
• Add-Computer