Autopilot in the real world — what they don't tell you in the docs

Windows Autopilot is one of those technologies that sounds like magic when Microsoft demos it: box arrives, user turns it on, signs in with their Microsoft credentials, device provisions itself into a corporate-managed state. No IT involvement, no imaging, no re-boxing.

That's real. I've implemented it. It works. But between the demo and working production deployment, there's a significant gap that nobody warns you about properly.

The network requirements nobody mentions clearly

Autopilot relies on Azure services during the out-of-box experience. If those services are unreachable (because of a proxy, a firewall, a content filter, or just a flaky hotel wifi), the device won't complete Autopilot provisioning.

The list of required endpoints is documented. Reading it carefully will tell you that you need to allow access to a significant number of Microsoft endpoints before any authentication has occurred: before the device has a certificate, before it's in your network, before a user has signed in. That's a challenge for environments with strict proxy authentication or whitelist-only firewall rules.

I've had Autopilot deployments fail in customer environments not because of any problem with Intune or Azure AD, but because the network team had a default-deny egress rule and nobody had put the Autopilot endpoints on the whitelist. Debugging this is painful because the failure mode during the OOBE is not informative.

Practical fix: Test Autopilot from a completely fresh, unmodified network connection early in the project. If it works there and not in the office, you have a network problem.

Hardware hash registration is a process problem, not a technical one

Autopilot requires devices to be pre-registered in your Azure AD tenant using their hardware hash, a unique identifier that lets Azure recognise the device before the user signs in. Hardware hashes can come from:

• Your hardware vendor, if you arrange it when ordering
• Running a PowerShell script on existing devices
• Manual upload via Intune

The challenge is that this is an ongoing operational process, not a one-time setup. Every new device needs to be registered before it can be Autopilot provisioned. Building this into your procurement process (working with your hardware supplier to automatically register devices against your tenant) is essential for at-scale deployment. Without it, someone manually runs a script on every new device, which defeats much of the point.

The Enrollment Status Page is a source of pain

The Enrollment Status Page (ESP) is what users see while the device is provisioning: the progress indicators that show apps being installed, policies being applied. Enabling the ESP is recommended because it prevents users from interfering with a partially provisioned device. But it also means that if anything in the app installation chain fails or takes too long, the user sits staring at the ESP.

App installation timeouts are the most common cause of ESP failures. Win32 apps that take a long time to install, or have complex dependencies, will regularly breach the default timeout values. The defaults can be extended, but diagnosing which specific app is causing the failure requires looking at the Intune management extension logs, which users can't access themselves.

What makes it actually work well

The organisations I've seen get Autopilot working smoothly have a few things in common:

• They have a very small, curated set of required apps in Intune, five to ten at most for the initial provisioning phase
• They've sorted out their network requirements before go-live, not during it
• They have a solid app packaging process so apps are reliable and don't fail on first install
• They've done thorough testing with representative hardware before rolling out to the whole estate

The technology is sound. The operational requirements are real. Get those right and it's one of the better experiences I've delivered.