If you missed it this past week, let me first point you to the source: Windows deployment with the next generation of Windows Autopilot

So what did this blog tell you? Certainly that there are changes being made to Windows Autopilot, but what are those changes and when will they be available? Some of that has been spelled out (to a degree at least), but a good portion has been left in a “what’s to come list.” So let’s go through the items starting with the more imminent and well-defined ones.

A new enrollment status page UI

Let’s admit the truth: the old ESP UI that has been in place since very early in the life of Windows Autopilot (remember that Autopilot initially didn’t have an ESP and couldn’t block on anything) was not great. (OK, it kind of sucked.) It presented too much information to the end user, little of which was useful to them, and not enough information to the IT admin that would have been useful. Combine that with the “Windows 11 OOBE squeeze” where what used to be a full screen is now squished into a small rectangle on the right half of the screen and it only gets worse.

So the first change is very much welcomed: a brand new UI for ESP that gives a simple percentage complete:

When will that be available? A good question that the blog does not answer — it doesn’t show up on my tenant yet, but I would expect it to be “soon.”

That certainly addresses the first half of the problem by simplifying the end-user experience. While the IT admin experience was supposed to be addressed by the Autopilot Diagnostics page (Control-Shift-D, described in the documentation), I still find that to be lacking — I always end up falling back to the Get-AutopilotDiagnosticsCommunity.ps1 script. (I fully expect that script will need updates for the new ESP experience; I’m sure someone from the community will make those adjustments fairly quickly after this is generally available.)

A combined Autopilot + ESP profile

I find this one to be ironic. Way back when, we were debating whether the ESP settings should be added to the Autopilot profile, or if a different profile should be created specifically for ESP. You can see which won: they are separate profiles in Intune. But that’s more a story of org structures and politics than it is of user experience or technology. At the time, Windows Autopilot was in the Windows org, and Intune was not; ESP was seen as a feature that wasn’t dependent on Windows Autopilot (because, well, it’s not), so it could be used without Autopilot — it was not labeled as an Autopilot feature, even though everything thinks about it being one. So at the end of the day, the org structure won.

So here we are, years later, and everything is together in a single org, where that original decision can be reconsidered: let’s put them back together. For most people, this will make little difference as it’s not like you had a bunch of Autopilot or ESP profiles. So at some point, we’ll see the new experience:

When will this be available? Again, not yet, but I would expect it “soon” based on the blog post details.

There is another funny aspect of the “old”/current design: I’ve talked to a number of customers over the years that said “we’re deploying with Autopilot” but when I asked them about registered devices and Autopilot profiles, I found that they had none. Yet they insisted that they were deploying using Windows Autopilot. So what were they doing? Well, they were just going through OOBE, answering all the normal questions along the way, and specifying their AAD credentials. To them, that was Autopilot. And in some ways, they were right: it’s a more modern way of provisioning a device, getting it joined into Azure AD/Entra ID, but without the simplified OOBE, and often without even configuring ESP — everything would just get installed in the background after the user (quickly) reached the desktop. Autopilot or not, they were satisfied — at least until they started asking why they couldn’t do things that were in the Autopilot feature list: removing user’s admin rights, doing device pre-provisioning, doing Hybrid AADJ, skipping OOBE pages, etc.

So what exactly is Autopilot? Well, in my definition, when you include ESP in the scope of Autopilot, it’s two things:

• A way to simplify the OOBE experience (that Microsoft made too complicated in the first place) and customize it for org standard (messages, logo, admin rights, etc.).
• A way to block access to the desktop until key policies and apps have been deployed so that the user isn’t confused when nothing they expect to find is there yet.

Enrollment time grouping

This is one that gets a single sentence:

Adding devices to groups is simpler and faster. We’ve replaced dynamic grouping with enrollment time grouping, so devices get assigned apps policies and scripts more efficiently.

Dynamic grouping is effectively the time that Intune spends figuring out what policies and apps need to be deployed to a just-enrolled device. That’s what’s going on while ESP shows “preparing your device for management.” And it can take a while, mostly waiting for a list of Win32 apps that need to be installed (and PowerShell scripts that need to be executed). So this could be a great improvement, eliminating minutes of delays at the start of the process.

When will this be available? Again, not yet, but the blog implies “soon.”

Reporting

There has been an “Autopilot report” in the Intune portal that displays the status of devices provisioned using Autopilot. I’ve always found it funny that I can never remember where it’s at in the portal — I always have to look it up. You can find it under “Devices -> Monitor” toward the bottom of the list as “Windows Autopilot deployment status.”

In the past, this report was in “perpetual preview” — it turns out that it was fairly difficult for the Intune service to “reverse engineer” the status of the local device using information already contained in the Intune service, so getting this report to be accurate was challenging. Plus, the data wasn’t being processed in real-time, so this was more useful for after-the-fact analysis.

So the blog post now says “reporting is much more detailed and available in near-real time.”

I hope that means the device is now providing the status directly to the MDM service, rather than the MDM service trying to reverse-engineer the status, but this remains to be seen. As with the other announced features, this isn’t yet available in my tenant.

When will this be available? Again, from the blog, we can assume “soon.”

Everything else

The blog post finishes with a list of “what’s to come” at some point:

• 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.

Since those provide little detail, I think we need to read into them some to figure out what they mean. Based on previous Microsoft conversations and posts from MVPs like Rudy Ooms, I can provide a few guesses:

• Customize OOBE and rename devices during provisioning based on organizational structure. Today, all of this is done at the Autopilot profile level, and it would be a real pain to have a different profile for every combination of OOBE setting and naming pattern you wanted to use. (Fortunately, most customers just have one.) So this would involve some way of being able to target different settings to different groups of devices (or maybe users?).
• Self-deploying and pre-provisioning mode. This implies that somehow the “new setup” won’t support these, but since this is being implemented side-by-side with the “old setup” you can still do it with that “old setup.” (Really, the blog is super vague on this entire idea.)
• Additional admin-specified configurations delivered before allowing desktop access. I would assume that additional policies can be blocking. (Today, very few policies actually do block, but as long as you are deploying at least one app you wouldn’t notice since all of those policies are likely to be applied before that first app even starts installing.) But perhaps there could be other things too, e.g. PowerShell scripts?
• Enhanced optional desktop onboarding experience inside the Windows Company Portal app. This seems completely unrelated to Windows Autopilot. Instead, this sounds more like the personal device enrollment experience that you would use on an Android or iOS device: go to the app store, find the Intune Company Portal app, install it, sign into it, and be guided through the enrollment process to get the device registered in Azure AD/Entra ID and enrolled in Intune.
• The ability to associate a device with a tenant. Today, you associate a device with a tenant by uploading a hardware hash (or having an OEM or reseller do it for you). This implies that there will be a different way of doing that, without mentioning how or what that would look like. If you read Rudy’s blogs, there are some hints about this being done on the device itself, which is likely tied into why self-deploying and pre-provisioning mode are not supported yet with this “new setup.” There are lots of other questions raised around this too (e.g. what if I depend on group tags and dynamic groups today?).

I believe it’s safe to say that these changes will apply only to Windows 11 — Windows 10 is nearing its end of life. But don’t assume that it requires a new Windows 11 release (e.g. 24H2), as Rudy has already shown that at least some of the changes have been in Windows 11 builds for quite some time.

After a few years of seeing no significant changes to Windows Autopilot, it’s good to see some activity again. How will this all affect you? When will it affect you? What changes will you have to make? All of that remains to be seen. Let’s hope that the team will provide more details and clarity soon.