The Ultimate Windows 365 Network Validation Script

Network connectivity is one of the most common reasons a Windows 365 deployment doesn't go to plan. Provisioning fails, health checks turn red, or users connect but the experience is incosistent.

In most cases, a firewall or proxy is blocking something it shouldn't be. The challenge is that Microsoft's network requirements are spread across four different documentation pages, covering Windows 365, Azure Virtual Desktop session hosts, end user devices, and Intune. There is no single place to validate everything at once, and manually working through each table row by row is slow and where things inevitably slip through the cracks.

I've built a free, open-source PowerShell script to handle that for you.

Credit to Shannon Fritz whose original gist inspired the approach and structure behind this.

What It Does

Test-W365NetworkHealth tests connectivity to every required endpoint across all four Microsoft documentation sources:

• Windows 365 service endpoints (provisioning, IoT hubs, registration)
• AVD session host endpoints (required and optional)
• End user device / client endpoints
• Intune and Windows Autopilot endpoints

It runs in one of two modes:

• Mode 1 – Cloud PC / Host Network: Run this directly on the Cloud PC or a VM in the same Azure VNet. Tests everything the Cloud PC needs to reach.
• Mode 2 – Client Device Network: Run this on the physical device used to connect to the Cloud PC. Tests what the end user's machine needs.
• Mode 3 – Both: Runs all tests in sequence.

Results are colour-coded in the console and you can export to CSV for documentation or ticketing.

What Gets Tested

The script handles four types of entries:

[ OK ] - TCP connection succeeded
[FAIL] - TCP connection blocked or timed out
[SKIP] - Wildcard endpoint (e.g. *.wvd.microsoft.com) - cannot be TCP tested; flagged for manual DNS verification
[INFO] - UDP or IP range entry (e.g. 51.5.0.0/16 UDP/3478 for RDP Shortpath) - flagged for firewall/NSG verification

At the end, the script produces a full summary listing every failure, every wildcard, and every UDP/IP range entry that needs manual attention.

A Note on Intune Endpoints

One thing worth calling out specifically: Microsoft's documentation includes a caution that the previously available PowerShell scripts for retrieving Intune endpoint IP addresses and FQDNs no longer return accurate data from the Office 365 Endpoint API. That API is deprecated for this purpose.

Running the Script

From a PowerShell 7 prompt (simplest - recommended):

irm https://bowker.cloud/w365check | iex

From a CMD prompt or Run dialog:

pwsh -ExecutionPolicy Bypass -Command "irm https://bowker.cloud/w365check | iex"

From Windows PowerShell 5.1:

powershell -ExecutionPolicy Bypass -Command "irm https://bowker.cloud/w365check | iex"

Run locally with a specific mode:

.\Test-W365NetworkHealth.ps1 -Mode 1
.\Test-W365NetworkHealth.ps1 -Mode 2 -OutputPath C:\Temp\results.csv
.\Test-W365NetworkHealth.ps1 -Mode 3 -EndpointsCSV .\Endpoints.csv

The Endpoints CSV

The script loads its endpoint list from a companion Endpoints.csv file, which is hosted in the same GitHub repository. When run via irm | iex, it downloads the CSV automatically. If that fails, it falls back to a built-in default list.

The CSV is the source of truth - over 200 entries are structured with category, endpoint, port, protocol, test mode, wildcard notes, and a direct reference link back to the relevant Microsoft documentation page. If Microsoft update their requirements, the CSV can be updated independently of the script.

What's Covered

The endpoint list is built directly from these four Microsoft documentation sources:

• Network requirements for Windows 365
• Required FQDNs and endpoints for Azure Virtual Desktop – Session Hosts
• Required FQDNs and endpoints for Azure Virtual Desktop – End User Devices
• Network endpoints for Microsoft Intune

That includes the Azure Certificate Authority endpoints for closed networks, all Windows Autopilot dependencies, every IoT hub region, and the full set of Intune Win32 app CDN nodes.

Limitations and Caveats

This script performs direct TCP socket tests. Before acting on the results, there are a few things worth understanding about how it works and where the blind spots are.

Proxy servers are not tested. TCP socket connections bypass WinHTTP and WinInet proxy settings entirely. If your environment routes outbound traffic through a proxy, the script could show [OK] for an endpoint that would fail in real usage because the proxy is blocking or SSL-inspecting it. Microsoft explicitly states that SSL inspection is not supported for several Intune endpoints if you're running a proxy with SSL inspection enabled, validate those endpoints separately.

VPN split tunnelling affects results. The script tests from whatever network path is active at the time of running. On a full-tunnel VPN, you're testing the corporate egress path. With split tunnelling configured, Microsoft 365 and Azure traffic may bypass the VPN and go direct - the results won't reflect what happens when the VPN enforces a different routing policy.

User context vs system context. The script runs in user context. Some endpoints particularly during Autopilot OOBE, Windows Update, and TPM attestation are only accessed in system context. User-context connectivity doesn't guarantee system context can reach the same endpoints if per-user proxy PAC files or user-specific firewall rules are in play.

Run it from the right place. Results are only meaningful if you run the script from the network you're trying to validate. Mode 1 should be run on the Cloud PC or a VM in the same Azure VNet. Mode 2 should be run on the physical client device on the end user's network.

Get It

Everything is available on GitHub:

https://github.com/bowkercloud/windows365

The repo contains the script and the CSV. Raise an issue if you spot something missing or if Microsoft update their documentation and something needs adding. Happy troubleshooting!