Microsoft's September 14, 2026 Azure Virtual Desktop announcement introduces three wildcard domains that Windows App will begin using for client-side service traffic in early October 2026. Organizations applying network controls to user devices should allow the required endpoints before activation. Read the Azure announcement.
The important distinction is client-side. Microsoft says these domains already appear in cloud-side connectivity requirements, but completing that earlier update does not establish that a laptop's firewall, proxy, VPN, DNS filter, or Secure Web Gateway permits the new traffic.
The Three Domains to Check
The announcement specifies outbound HTTPS on TCP port 443 for:
*.windows.cloud.microsoft — general Windows cloud service traffic.
*.service.windows.cloud.microsoft — service traffic requiring optimization.
*.windows.static.microsoft — static content, installation, and update assets.
Microsoft warns that unavailable or interrupted endpoints can affect sign-in, resource discovery, connection establishment, or active sessions. The stated timing is early October, not a published exact cutover day. Required domains and rollout timing.
My recommendation is to copy the exact domain patterns into the change record, then check how each network product interprets wildcard rules. Do not silently simplify the list because two entries appear to overlap. Preserve the documented requirements and validate the resulting policy behavior.
A Cloud-Side Change Does Not Validate a User Device
The Azure Virtual Desktop endpoint reference maintains separate sections for session hosts and end-user devices, as well as separate cloud-specific lists. Its end-user table includes the three domains above and other dependencies, including Microsoft authentication and existing AVD service endpoints.
For this change, start with the path taken by a device running Windows App. A useful inventory should distinguish office access, remote access through a VPN, and access controlled by an endpoint security agent or cloud web gateway.
For example, an office firewall rule might be correct while an always-on endpoint filter still blocks the destination after the user goes home. Conversely, a home connection might work while a corporate proxy disrupts it. Treat these as separate test paths, not contradictory reports from the same environment.
Do Not Replace the Full Connectivity Baseline
Microsoft's endpoint guide says there is no AVD IP-address list that substitutes for the required FQDNs. It also points out that dependencies for other services, such as Microsoft Entra ID, need their own review. Endpoint and dependency guidance.
My recommendation is to add the new requirements to the maintained connectivity baseline without removing existing entries merely because this announcement lists only three domains. This is a targeted change notice, not a complete inventory of everything a working desktop session needs.
Use the table for the cloud your organization actually uses. Do not copy commercial-cloud domain patterns into a sovereign-cloud policy without checking its corresponding documentation.
Review Inspection With the Network Owner
Microsoft's proxy guidance recommends avoiding SSL termination for AVD traffic and explains that proxies can affect long-running connections, latency, and reliability. It also warns that not every third-party proxy configuration is compatible. AVD proxy considerations.
That calls for a scoped review with the network and security owners, not a blanket removal of inspection from unrelated traffic. Record the approved treatment for these destinations, the affected devices, and the evidence that the intended connection reaches Microsoft successfully.
Where policy requires a proxy, include that path in the pilot. Testing from an unrestricted administrator workstation does not demonstrate that an employee's managed device will work.
Use the Right Evidence for the Right Side
The Azure Virtual Desktop Agent URL Tool validates connectivity from a session host. Microsoft also notes that it checks particular endpoints, not whether all required wildcard entries have been permitted. Agent URL Tool scope.
A passing host-side tool result is useful, but it is not acceptance evidence for a Windows App device policy. For the client-side change, my recommendation is to combine policy review with client-side connection tests and relevant DNS, firewall, and proxy observations.
A wildcard itself is not a concrete hostname to resolve or open in a browser. Validate the policy pattern and the real service destinations used by the client rather than treating a failed lookup of a literal asterisk as a service outage.
Practical Cloud Engineer Takeaway
Open a small, explicit network-change work item now. My proposed acceptance checklist is:
Confirm the exact three domain patterns and outbound TCP 443 requirement in each applicable policy.
Test representative managed devices on office, VPN, and remote-access paths.
Verify Windows App sign-in, resource listing, desktop or RemoteApp launch, and reconnection.
Keep timestamps, client version, network path, and observed failure stage with each result.
Confirm that existing connectivity requirements remain in place.
Give the help desk a named escalation owner and a short guide to distinguishing identity errors from network failures.
These are recommended checks, not tests I have performed in a customer environment. A successful session before activation is not proof that every future endpoint has been exercised; retain explicit policy evidence and repeat the relevant checks as the rollout reaches your clients.
Who Should Care?
Azure Virtual Desktop administrators, Windows App deployment owners, endpoint-security teams, network engineers, and service desks supporting tightly controlled user devices.
Bottom Line
This is a small destination-list change with a potentially large support impact. Complete the client-side review before the rollout, and keep its evidence separate from the earlier cloud-side work.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments