Windows Autopilot

Autopilot v2: My “second” thoughts

My first thoughts around Autopilot v2 (a.k.a. Autopilot device preparation) are scattered through a week of posts:

Summarizing those, along with my observations along the way, leads me to these thoughts:

  • This is the biggest change to Windows Autopilot since its inception. Unlike most of the previous changes, this is not just incremental functionality being added, but rather it is a re-thinking of how this should work overall.
  • It’s not done yet. In addition to the variety of known issues (and even more bugs that I’ve run into that aren’t in the known issues list) and coming functionality list (e.g. self-deploying, pre-provisioning, tenant binding), it really feels like a “preview” version, not something that was announced as “generally available.”
  • There are compromises being made. Autopilot v1 was all about simplification of OOBE; with v2 some of that simplification has been lost (e.g. some of the OOBE pages that were hidden have reappeared: EULA, personal vs. work/school, privacy/security settings). There’s also less functionality (e.g. computer naming), and reduced troubleshooting capabilities (dependent primarily on the Autopilot device preparation report for remote monitoring).
  • We’re likely on a multi-year journey to flesh this out. Companies like Microsoft talk about a “minimum viable product” (MVP) that offers enough functionality to be useful to customers, and they can add more features over time. The list, containing both “new” items added as a result of Autopilot v2 (e.g. reimplementing self-deploying, pre-provisioning), plus the existing list of customer asks (e.g. time zones, languages, etc.), amounts to a long list of work that will take time.

But that’s not what stands out the most to me. The most important change I see is the architecture that is being used. With the initial Autopilot v1 solution, most of the logic was baked into Windows, with input provided by the MDM service (e.g. Intune or WorkspaceOne, specifying apps and policies to track) as well as additional agents (e.g. Intune Management Extension, adding to that app list). How would new functionality be added? That would typically take a new release of Windows, which is on an annual release process — unless you get something added at the right point in time, it could take two cycles for it to be added, i.e. two years. There really wasn’t even a very practical way of delivering fixes (unless they were super-critical) to existing devices that already had a Windows image shipped on them.

So how is the Autopilot v2 solution different? What you see inside of OOBE is the user interface, but that UI isn’t doing much — it’s just a progress display (kind of like the SCCM task sequence progress UI). That “progress display” ships inside of Windows. But it’s being told what to do by a separate agent, the Intune Management Extension, that is doing all of the orchestration work. So once that IME agent is installed, it’s what is in control.

Why does that matter? Because the Intune Management Extension is updated frequently, probably at least once a month, and it could be updated even more frequently if bugs are found. It’s not built into Windows, so it’s not encumbered by the Windows servicing and OEM imaging processes. New functionality can therefore be delivered (and bugs fixed) whenever Intune feels like delivering them. (Presumably WorkspaceOne will eventually adopt the same setup.) So we won’t need to wait for 25H2 to add new features or address issues from 24H2. We won’t need to worry about what cumulative update is installed in OEM or custom images. As long as there are no changes needed in Windows itself (not yet guaranteed), improvements can be offered almost “at will.”

Of course on the flip side of that, it means things will constantly be changing, so let’s hope that nothing breaks along the way…

Leave a comment