Out of Office Hours

Autopilot v2, a.k.a. Autopilot device preparation, was announced on May 22, 2024, it wasn’t really done yet. From the original annoucement (highlight added by me):

See what’s to come

We’re eager to share some of the capabilities coming to the new Windows Autopilot device preparation experience! We’ll update you with release dates soon of the following features:

• Customize OOBE and rename devices during provisioning based on organizational structure.
• Self-deploying and pre-provisioning mode.
• Additional admin-specified configurations delivered before allowing desktop access.
• Enhanced optional desktop onboarding experience inside the Windows Company Portal app.
• The ability to associate a device with a tenant.

Not sure about what they consider “soon” but here we are a year later and we’ve seen none of these items. What has happened in this past year? There were fixes for some bugs (e.g. local Administrators on non-English devices; reboot handling), but that’s really been about it — and no timelines have ever been offered.

I guess my “second thoughts” were misplaced. I thought the APv2 architecture, where more of the logic is performed by the “bootstrapper agent,” which in this case in the Intune Management Extension (which is updated frequently), would enable faster delivery of new features. Certainly that hasn’t happened yet.

On the positive side, it’s been relatively stable. On the negative side, I haven’t run into many customers that are actually using it. (That’s likely also why third-party MDMs haven’t been pushing to adopt this themselves — customers aren’t asking for it.)

What about the new features that were released? Let’s do a quick runthrough.

• A new UI admin experience. Yes, it’s nice that you don’t have two places to configure things (APv1 profile + ESP — a remnant of internal Microsoft org structures and politics), but otherwise, this isn’t something you mess with much, so it’s a minor improvement.
• Enrollment time grouping. In my tests, this generally cuts about 45 seconds off of the “thinking” time before the Intune Management Extension can start installing apps. Perhaps it makes the process more consistent than APv1, but otherwise, the savings are minimal.
• Reporting with near-real-time information. The new report is good (and what the old APv1 report, which is stuck in perpetual preview, should have been). I wouldn’t call it “near real time” though, as I typically see it lag behind by 5 minutes or so.
• Preventing non-blocking apps and scripts from installing during OOBE. This is probably the best improvement, and really should be added to APv1 too.
• A new UI client experience. It’s prettier and more user-friendly, so that’s good. But the announcement said it will provide “clearer indications of how close the setup process is to completion” and that’s nowhere near true: the percentages aren’t accurate (they just mark the passage of time — what is it with Microsoft and progress bars?), and it went from too much (mostly useless) information in ESP to not enough useful information in APv2. How hard would it to give a count of apps (e.g. “Installing app 1 of 5”) or the name of the current app (e.g. “Installing Office”)? Just a simple message under the progress circle would be enough.
• Expanding Autopilot to government clouds. If you are using Intune in a non-public government cloud, then yes, this finally lets you do Autopilot provisioning.

There were also discussions about no longer needing registration, but really you just need to do a different type of registration: creating corporate device identifiers instead of registering hardware hashes. If you register devices yourself, creating corporate device identifiers is slightly easier, and certainly much faster (no need to wait for Autopilot profiles to be applied). But if you used to have OEMs register devices for you, guess what? They can’t create corporate identifiers for you (although there’s no reason they couldn’t if Microsoft updated the OEM registration APIs to enable that — maybe that’s on the roadmap?).

Microsoft would likely deny it, but there are still remnants in the original announcement of the plan to replace APv1 with APv2:

We’re offering the reliability of it and innovations of device preparation in tandem until the experience can be totally unified with the new, more capable architecture.

Or at least “until it can be unified” shows a desire to merge the two into one. Personally, I wonder if that will ever happen.