Windows deployment with the next generation of Windows Autopilot

In its current form, the new Autopilot doesn't fully live up to the expectations of a true "v2." It seems more like an enhanced User Status Page with additional features. 

The "Device Preparation Policy" appears reminiscent of the "Policy Sets," that none uses, with hopes of adding objects that run solely during Autopilot, but it likely just delays desktop access until all policies are applied.

The removal of the hardware hash requirement is touted as a feature, but it raises a critical question: How do you attach a device to a tenant? This concern is addressed in the "See What's to Come" section, highlighting a significant oversight in the current implementation.

The "Self-deploying and pre-provisioning mode" in the list of missing features highlights a fundamental flaw in Microsoft's vision: expecting users to install apps and configurations themselves, patching to the latest level, or handling a device that isn't ready to go. This concept clashes with real-world challenges like slow internet connections, unreliable user handling, and the need for devices to arrive pre-provisioned and ready for immediate use, underscoring the crucial role of pre-provisioning.

Microsoft reassures that "The features you know and love in Windows Autopilot aren't going anywhere!" This is crucial because replacing the existing Autopilot with the new version would be catastrophic.

The new Autopilot is essentially just a User Status Page on steroids.

Despite the concerns, there is hope that the "Device Preparation Policy" could effectively decouple provisioning from normal operations. Ideally, if apps can be added in a sequential order and run accordingly, it would significantly streamline the process. Wishful thinking? Perhaps. But we shall see how it unfolds.

Good news. It would be awesome if there was also the ability to run scripts, install apps, edit registry keys only during the autopilot process. Another excellent possibility is to be able to insert priority in the steps exactly as it is possible to do in a task sequence..

Thanks for this update.

Please also have some option enabled to customize the device naming in case of Hybrid AD joined devices. Today we are struggling to rename the Hybrid Joined devices through Autopilot as Intune offers very limited options to rename unlike the AAD Join Autopilot Profile.

Currently we are using scripts to rename the Hybrid Joined devices post Autopilot which is lot of additional work and effort. 

Also, we need to have a granular status reporting for both Autopilot ESP and overall Autopilot Deployment status as installing custom commands during provisioning like autopilotdiagnostics etc. are lot of additional work.

Thanks, everyone for the feedback in comments.  The Autopilot team wanted to give the posts some time to build up as to post a single response to address the questions, so here’s the first round of responses (and we’ll continue to monitor the feedback over time).  Given there were some repeat questions, below we’ll consolidate answers into a single list, appreciate everyone taking the time to post.

1. Is this a new version of Autopilot (v2)?
   1. Autopilot Team: This is a new profile type for Autopilot, you shouldn’t think about it a new version of Autopilot, v2 or otherwise.  We went down this path to expand Autopilot coverage for customers in government clouds who heretofore couldn’t use Autopilot via the registration dependency.  This addresses that.  Concurrently we are addressing other common pain points from all customers with this new profile such as troubleshooting and reporting, admin and user experiences, and reliability (to name a few).  Also, this release of the device preparation profile is just the beginning, and we’ll continue evolving it over time as the blog states in “what’s to come.”  Your feedback shaping the future while we have the hood open on this new profile type is welcome and encouraged.
2. How are we going to do registration now, this is fundamental to our organization using Autopilot?
   1. Autopilot Team:  The “what’s to come” section of the talks briefly to future looking capabilities such as device association to a tenant.  This will be the scenario-equivalent of today’s device registration process and is under active development (no ETA available yet).  Additionally, the current Autopilot flow will continue to exist, as again, this isn’t a v2 to replace v1, rather a new profile type that will continue to evolve and improve over time.
3.  What’s the support plan or new innovation coming for Hybrid AD Join scenarios for this new profile?
   1. Autopilot Team: We have no plans to support Hybrid AD Join with the new profile, but the existing Autopilot flows will continue to support Hybrid AD Join.  As is outlined in docs, this is not a recommended approach to Autopilot generally.
4. Are you going to add the ability to orchestrate/sequence applications and policy?
   1. Autopilot Team: We get this question a lot and are currently digging into the scenarios for which precise sequencing vs. dependency modeling is required.  We continue to gather feedback as to prioritize, so please do pass along your scenarios that require sequencing to help us prioritize.
5. What about pre-provisioning and self-deploying modes?
   1. Autopilot Team: Our goal (over time) is to support these modes and have general parity with this profile to existing Autopilot capabilities (aside from the previous point on Hybrid AD Join, which we are not planning to add to the new profile.
6. What about OEM flows for tenant binding (e.g. today’s registration)?
   1. Autopilot Team: We are working with the OEMs to assure they have a process to use the tenant binding solution that we’re actively developing with the intent that they will have the process in place when we GA this capability for the new profile.

What version of Windows will these changes work with?  Do they require Windows 11 24H2?  Does it require any specific updates?  Since this is designed to work with the OEM-preloaded OS version, it's important to understand when the OEMs will have the needed client-side bits loaded on new devices.

I hope the device hashes are NOT going to be removed. We also heavily depend on them, allowing users to enrol whatever device they want is NOT what we want. We need to strictly control what devices get inside and allow users to access applications.

For example, law requirements: if an employee uses his own device and we install monitoring software on it we are in VERY big trouble, however, if the device is company-owned it's OK. Doing all the checks post-enrollment doesn't make sense, you want us to implement some hash checking and calculating on our own?

Can we get easier control of Language and region settings?

Great news. Hopefully there will be some improvements to the Hybrid Autopilot process. Waiting for AAD Connect to sync during a deployment is really painful. 

For all that ask which about Windows versions, Device Preparation supports:

• Windows 11, version 23H2 with KB5035942 or later.
• Windows 11, version 22H2 with KB5035942 or later.

No Windows 10 support

Great that is now official.

One question, what about new devices? I thought that this new solution would remove the need to add hardware hashes to add new devices or is this what 'The ability to associate a device with a tenant.' means?

Thks