A browser test is not a network test: how proxies and TLS break-and-inspect kill Autopilot

A device arrives on a corporate site. It gets an IP address. It gets DNS. An engineer proves the network is fine by opening a browser on the machine next to it. The Intune portal says the Autopilot profile is assigned. The new device boots into the out-of-box experience. It shows a generic Microsoft sign-in page with none of your branding. Then it either sits there or falls over with a vague error. Nothing was misconfigured in Intune. The network is the problem, and the browser test was the wrong test.

The problem: internet access is not the same as Autopilot access

The failure is frustrating because every obvious check passes. The device has a link light. DNS resolves. A laptop on the same VLAN browses the web without complaint. In the Intune admin center the device is listed under Windows Autopilot devices with a profile status of Assigned. And yet the out-of-box experience does one of these things instead of running your deployment.

• It shows the standard consumer-style sign-in page with no tenant branding, because the profile never arrived and Windows does not know which tenant this device belongs to.
• It shows the local account creation flow, which is the giveaway that Windows thinks this is an unmanaged device.
• It reaches the sign-in page, accepts credentials, and then fails during Microsoft Entra join or during mobile device management enrolment.
• It sits on a spinner for several minutes and then produces a timeout-shaped error with no useful detail.

The Autopilot event log tells a much clearer story than the screen does. Microsoft documents the channel at Applications and Services Logs › Microsoft › Windows › ModernDeployment-Diagnostics-Provider › Autopilot. A network failure looks like repeated warnings and no success.

There is a second, quieter symptom. Microsoft documents that Autopilot profile settings are cached in the registry. One of those values is IsAutopilotDisabled. Set to 1 it can mean the device is not registered. It can also mean that "the Windows Autopilot profile couldn't be downloaded because of network connectivity or firewall issues, or network timeouts". One registry value, two very different root causes. Admins read it as "not registered", re-register a device that was already registered fine, and lose a day.

Why it happens: three separate middlebox failures

There is not one cause here. There are three, and they fail in different places, which is why the symptoms look inconsistent between sites.

1. The endpoint set is narrower and stranger than "allow port 443"

Microsoft's baseline guidance for Autopilot networking is blunt. Resolve internet DNS names, and allow access to all hosts on port 80, port 443, and UDP port 123. Most enterprises cannot do that, so they build an allowlist instead. The allowlist is usually where it goes wrong, because two of the required names are not obviously Microsoft-cloud-shaped.

The Windows Autopilot Deployment Service itself uses two URLs: https://ztd.dds.microsoft.com and https://login.live.com. That second one catches people out constantly. It is a consumer Microsoft account endpoint, and it frequently ends up on a block list for good reasons in a corporate environment. The profile request is authenticated with a device token obtained through the Microsoft Account Sign-In Assistant service, so blocking consumer identity blocks Autopilot. Microsoft makes the dependency explicit elsewhere too. It documents that setting the Microsoft Account sign-in assistant device restriction to disabled "turns off the Microsoft Sign-in Assistant service (wlidsvc)". It then states plainly that "Windows Autopilot requires this service to get the Windows Autopilot profile".

After the profile lands, three more services take over, each with its own endpoint set. Microsoft Entra ID validates the user and joins the device. Intune enrols it. And for self-deploying and pre-provisioning modes, TPM attestation runs against per-vendor URLs that differ by silicon manufacturer.

2. TLS break-and-inspect breaks certificate-based authentication

A break-and-inspect proxy terminates the TLS session, decrypts it, inspects the payload, then opens a second TLS session onward to Microsoft. To the client, the certificate for manage.microsoft.com is no longer issued by a public certification authority. It is issued by your inspection CA.

This works for browsers on managed machines for one reason only. Your inspection root is already in the machine's Trusted Root store, put there by Group Policy or by Intune. A device in OOBE has never received a policy from you. Nothing has run. The trust store contains the roots that shipped with Windows and nothing else. So the same middlebox that is invisible to your fleet is a hard certificate error to the device you are trying to provision.

Even if the root were trusted, some of this traffic still cannot survive interception. Microsoft is explicit about it in two places. The Intune network endpoints documentation states that "SSL traffic inspection isn't supported for '*.manage.microsoft.com', '*.dm.microsoft.com', or the Device Health Attestation (DHA) endpoints". And the Microsoft Entra hybrid join documentation carries a warning worth reading twice. If your proxies intercept SSL traffic, "ensure that traffic to https://device.login.microsoftonline.com and https://enterpriseregistration.windows.net are excluded from TLS break-and-inspect. Failure to exclude these URLs might cause interference with client certificate authentication, cause issues with device registration, and device-based Conditional Access."

Client certificate authentication is the key phrase. Device registration presents a certificate to prove the device's identity. A proxy that terminates TLS terminates that mutual authentication with it. No client-side setting makes this work, because the thing the proxy is breaking is the proof of identity itself.

3. An authenticated proxy has nobody to authenticate as

This is the failure that produces the most confused tickets, because it only affects part of the flow. A user can sign in at the OOBE credentials page, and then enrolment fails, which looks like a licensing or permissions problem.

The mechanism is context. Microsoft states it directly for device registration: "Because Windows 10 or newer computers run device registration by using machine context, configure outbound proxy authentication by using machine context." Machine context means the SYSTEM account and the machine's own network stack, not the interactive user's credentials. In OOBE there is no interactive user at all until the sign-in page appears, and in self-deploying mode there is never one. A proxy that answers with HTTP 407 and expects a username has nothing to prompt.

Intune says something similar from the other direction: "For some tasks, Intune requires unauthenticated proxy server access to manage.microsoft.com, *.azureedge.net, and graph.microsoft.com." The Microsoft 365 connectivity principles also list "routing connections through network infrastructure applying its own authentication such as proxy authentication" among the configurations known to cause problems.

And there is no client-side policy lever during OOBE

The instinct is to fix this on the device. It does not work, and Microsoft says so. The Autopilot requirements page states that "deploying proxy settings for Windows Autopilot should be configured on the proxy server itself" and that "implementing proxy settings via Intune policy isn't fully supported as it might cause issues and unexpected behavior with privileged access deployments". Intune policy arrives after enrolment, which is after the part that is failing.

What Microsoft does support is proxy auto-discovery. For Autopilot with Microsoft Entra hybrid join, the requirement is stated as a prerequisite: "If using Proxy, Web Proxy Auto-Discovery Protocol (WPAD) Proxy settings option must be enabled and configured." For device registration generally, Microsoft says you can use WPAD "to enable Windows 10 or newer computers for device registration with Microsoft Entra ID", or configure WinHTTP proxy settings by Group Policy on machines that are already domain joined.

How to verify: test each endpoint from the OOBE context

Two rules make this tractable. Test from the context that fails, which is machine context, not a signed-in user's browser. And look at the certificate issuer for each endpoint, not at whether something responds.

The endpoint set to test

Every hostname below comes from Microsoft documentation. The third column is the constraint that matters, and it is the column most allowlists ignore.

Reading the certificate issuer, from the machine itself

At the OOBE screen, press Shift + F10 to open a command prompt, then start PowerShell. The point of the following is not reachability. It is to see who signed the certificate.

The certificate check itself is short, and it is the single most useful thing you can run. Open a socket, complete a TLS handshake with validation deliberately bypassed, and print the issuer of what came back.

If $cert.Issuer names your organisation, your firewall vendor, or an internal certification authority, you have found the answer. That endpoint is being broken and inspected, and for manage.microsoft.com that configuration is documented as unsupported.

Microsoft's own read-only test scripts

Two Microsoft-published scripts save time here, and both are read-only. Test-DeviceRegConnectivity tests login.microsoftonline.com, device.login.microsoftonline.com and enterpriseregistration.windows.net under the system context. Microsoft explicitly notes that it "checks for SSL/TLS handshake and report as failure if any". Its own FAQ answers the important question plainly: "Does this script change anything? No. It just retrieves data." Test-IntuneAFDConnectivity.ps1 covers the Azure Front Door address ranges Intune uses, and Microsoft's troubleshooting notes for it name the cause we are chasing. An unreachable service endpoint may mean "a DNS, proxy, or HTTPS inspection issue is preventing connection to the Intune service FQDN".

The Autopilot diagnostics registry surface

Everything the deployment service told the device is cached here. This is the same key on every Windows client, and it is worth reading before and after any proxy change. Parent key, stated once.

The Autopilot event ID catalog

These are the events Microsoft publishes for the Autopilot channel. Channel, stated once.

The diagnostic pattern to look for is a pair. Event 164 says Windows believes it has internet. Event 160 says the download started. If you see 164 and 160 but never 161 or 153, Windows is reaching the internet and still cannot complete the profile request. That is exactly the signature of a middlebox in the path, and it is the case a browser test can never reproduce. Other event IDs do appear on real devices without being in Microsoft's published table, so do not build alerting on undocumented IDs.

The fix: bypass lists on the proxy, not policy on the client

Work through these in order. The first two are the ones that actually resolve the failure described here.

Step 1: exclude the documented endpoints from TLS inspection

This is a change on the proxy or firewall, made by the network team, not in Intune. Here is the minimum set with the source for each.

Microsoft's broader recommendation goes further than that documented minimum. For every required Microsoft 365 endpoint it says to "bypass Microsoft 365 domains from TLS decryption, traffic interception, deep packet inspection, and network packet and content filtering". Treat the named list as the floor, not the ceiling.

Your tenant region matters for two of those rows. To find it, open Tenant administration, then Tenant status. Read Tenant location under Tenant details. Then use the endpoint list Microsoft publishes for that region.

Step 2: make the required endpoints reachable without proxy authentication

Add the Autopilot, Entra and Intune endpoint set to the proxy's unauthenticated bypass, or configure machine-context authentication with your proxy vendor. Microsoft's wording is the one to take to the network team. Device registration runs in machine context, so outbound proxy authentication must be configured using machine context. If the vendor cannot do that, an unauthenticated bypass for those hostnames is the only workable answer during OOBE.

Step 3: give OOBE a way to discover the proxy

Configure WPAD so the device can find the proxy with no policy applied. Microsoft's Autopilot hybrid join prerequisite states it as a requirement. The device registration guidance offers WPAD, or GPO-deployed WinHTTP settings for machines that are already domain joined. A WPAD entry can be published through DHCP option 252 or through a wpad host record in DNS.

Step 4: confirm the profile really is assigned

Rule out the boring cause before escalating to the network team.

1. Sign in to the Microsoft Intune admin center.
2. Select Devices, then select Windows under By platform.
3. Select Enrollment under Device onboarding.
4. Under Windows Autopilot, select Devices.
5. Find the device and check the profile status column. If it reads anything other than Assigned, you have an assignment problem and not a network problem.
6. Also check whether the record shows Fix pending or Attention required. Microsoft documents both as indicating a hardware change on the device, which is a separate failure mode with its own remediation.

Step 5: turn on the diagnostics page so the next failure is legible

On Windows 11 user-driven deployments you can open a diagnostics view during provisioning, but only if the Enrollment Status Page profile allows it.

1. Open the Enrollment Status Page profile that applies to the devices you are provisioning.
2. Set Show app and profile configuration progress to Yes.
3. Set Turn on log collection and diagnostics page for end users to Yes.
4. Save, then during the next deployment press CTRL + SHIFT + D or select View Diagnostics.
5. Make sure lgmsapeweu.blob.core.windows.net is not blocked, or the automatic diagnostics upload fails and you lose the logs from the failed run.

Proof it worked: a clean certificate chain and event 153

The companion script is Test-AutopilotNetworkReadiness.ps1. It resolves each documented endpoint, opens a socket, completes a TLS handshake, and compares the presented issuer against a list of well-known public certification authorities. Anything issued by something that is not a public CA is reported as interception. It is read-only, needs no PowerShell modules, and exits non-zero if any required endpoint is not clean.

The block below is a real run on a clean network path, with the hostname and account name redacted.

A broken path looks like the next block. This one is illustrative. It was constructed to show the shape of the output on a network with break-and-inspect and an authenticated proxy. No such path was available to run against.

Once the exclusions are in place, the Autopilot channel tells you it worked without anyone having to sit and watch the screen. The sequence you want is acquisition starting, then a successful retrieve, then the state change.

Three checks close the loop. The event log shows 161 and 153. The registry key shows a populated CloudAssignedTenantDomain and IsAutopilotDisabled at 0. And the readiness script reports zero interception across the required set. If all three agree, the network path is genuinely clean. Any remaining failure is a real Intune or Entra problem, worth investigating on its own terms.

Community deep dives worth reading

References

• Windows Autopilot requirements, Networking tab. The deployment service URLs, the service-by-service endpoint breakdown, the TPM attestation URLs, and the statement that proxy settings should be configured on the proxy server itself.
• Network endpoints for Microsoft Intune. The Intune core service and Autopilot dependency endpoint sets, the unauthenticated proxy requirement, and the statements that SSL traffic inspection is not supported for the Intune, Defender, Endpoint Privilege Management, Store API and attestation endpoints.
• Configure Microsoft Entra hybrid join. The device registration URL list, the TLS break-and-inspect exclusion warning, WPAD guidance, and the machine-context proxy authentication requirement.
• Windows Autopilot troubleshooting FAQ. The Autopilot event ID table, the diagnostics registry key and values, the diagnostics page steps, and the policies known to conflict with Autopilot.
• Microsoft 365 network connectivity principles. The guidance to bypass Microsoft 365 domains from TLS decryption and interception, plus the list of network scenarios known to cause connectivity issues, including proxy authentication.
• Windows Autopilot device preparation requirements. The equivalent networking requirements for device preparation, which uses a different endpoint set for the profile stage.
• Test Device Registration Connectivity. Microsoft's read-only script that tests the three device registration endpoints under system context and reports SSL or TLS handshake failures.
• About implementing WPAD. Archived, but still the reference Microsoft links for WPAD. It covers DHCP option 252, DNS records, and the Windows Server DNS global query block list.

The companion script for this post is Test-AutopilotNetworkReadiness.ps1 in the Windows Autopilot scripts collection. It is read-only by design. It opens sockets, reads certificates, reads registry values and reads event logs. It writes nothing, changes no configuration, and installs no modules.