Autopilot Device Preparation – Evolution or optional add-on ?

It’s been a couple of weeks now since Autopilot Device Preparation hit our tenants and the dust is only just beginning to settle. There’s been some really great content produced on the topic already and I don’t want to repeat all that great work so please check these out (References added at the bottom). In fact thanks to others in the community we have some amazing insights into the technology. Now that I’ve had the time to test this out for myself, I wanted to add my own opinion, insights and tests into the whole discussion.

NOTE: To cover the topic in full I will be following up with a “How-To” video on the Cloud Management Community YouTube channel. So keep an eye out for that.

The Line-up:

  • The new Autopilot Device preparation enrolment flow
  • Lets take a view on Autopilot Device Preparation
  • What does the Autopilot comparison look like
  • What about the configuration experience
  • How is this monitored
  • Compare the enrolment experience using a side by side Autopilot test
  • My final thoughts

The new Autopilot device preparation enrolment flow

I first want to highlight the updates to the enrolment flow for Autopilot device preparation (ADP) as some big changes have been made. With ADP targeting users we now see some of the user setup screens before the end user login (at this point the device has no sight of Intune).

  • 1 – Power on the device and progress through the OOBE screens up to the login screen (Choose the keyboard, accept the license, name the device and select your account setup with either a personal or work account – This is for Windows Professional only)
  • 2 – Autopilot device preparation profile is downloaded assuming the user is a member of the assigned user group configured with the profile. There is now a new end user experience showing a real-time percentage progress. This has changed from the original Autopilot Enrolment Status Page (ESP).
  • 3 – The device is added to the Entra ID device group assigned to the ADP profile using real-time grouping
  • 4 – Intune pushes Applications and scripts and assigned to the profile down to the device
  • 5 – End user sees the Windows Home screen
  • 6 – Any other Apps, policies or settings assigned to the same user or device outside of the ADP profile are downloaded and installed in the background.

Lets take a view on Autopilot Device Preparation

So I raised the question here is Autopilot Device preparation an Evolution or optional add-on ? And I came to the conclusion that it simply has to be both. Now I don’t like to sit on the fence generally but let me explain my thoughts and findings below so you can make your own mind up.

Before we get into the meat of this though it has to be said that features released with intune are there to improve the experience and bring benefits to both IT Admins and end users and maybe people set their expectations too high. ‘Autopilot Device Preparation’ In my opinion should be called by its given name or ADP but not ‘Autopilot V2’ or ‘APV2’ as has been termed and used by others. I get that people need to identify ADP from the original Windows Autopilot but while there is overlap with the original Autopilot service, right now ADP only provides a new option to cover different user cases where as Autopilot V2 makes you think of a replacement and it’s definitely not that.

Yes under the hood it introduces new enrolment flows and its certainly the biggest change of Autopilot since its first release but this more than likely just a taster or start of how the technology will be developed going forward. I’m sure Microsoft will be going a lot further with this BUT currently it doesn’t entirely replace previous user cases and in terms of the end user experience you might ague that some of the simplification has taken a backward step (like bringing back some of the OOBE pages). In my opinion more is sometimes less particularly if it adds complexity. Complexity because it means you have to make more informed decisions but also it means there are more enrolment profiles to manage. Personally I would have preferred that Microsoft rolled up all the Autopilot user cases into a single new feature that replaces the existing features. Simple.

So why ‘Evolution’ OR ‘Optional add-on’ ? An evolution can generally be interpreted as meaning an improvement but an improvement with a considerable change and with ADP that change has to be the removal of Hardware Hashes. Remember Autopilot removed the need to pre-build and stage devices before sending them out to end users and the experience of enrolment was simpler by automating OOBE pages. That has introduced a HUGE change in the device provisioning Industry for sure and saved not only deployment costs but also simplified the process and end user experience. With the removal of Hardware Hashes this introduces the next generation of improvements to go even further by improving the enrolment flow. While technology is great by itself its only truly adopted if it improves or fills functional gaps with how the technology works in the real world. No Hardware hashes means less preparation and ultimately even more cost savings from OEM’s so thats a real world change. It also addresses the situation where motherboards are replaced and the hardware hash is no longer appropriate too.

The other side of the coin and view though is that the new way of provisioning Windows devices using ADP isn’t an all replacing solution. It only works with Windows 11 and you cant use pre-provisioning (White-glove) or hybrid- join scenarios so while there definitely some great new improvements, these are restricted. We also see the return of some setup pages such choosing a work/school account and device renaming when deploying Windows 11 Professional, steps previously removed to introduce simplification. For these reasons this is why ADP is both an evolution but also an additional option which with Windows 10 soon going end of life this will become even more important.

What does the Autopilot comparison look like

So if your looking to decide if an where you can use the new functionality there are a number of variables to consider. Lets check out the Microsoft documented options and differences between the original Autopilot deployment and ADP.

At a high level, Looking at the positives ADP now opens up enrolment for GCCH and DoD environments and where you want to complete enrolment for both Applications and scripts at the same time. You will get better monitoring although in my personal experience Its not near real-time as documented. If your looking to use Windows 10, self-deploying or pre-provisioning then stay with the existing Autopilot option.

What about the configuration experience ?

ADP introduced a new wizard approach which helps combine the required settings into a single profile. I do think this is helpful as it means less mistakes are likely to be made. It also uses enrolment time grouping, new technology that speeds up application and policy provisioning with the device enrolment. This is said to be a key benefit to ADP which is not only faster than the original Autopilot experience (which waits for the device to be added to a slower dynamic group before policies and applications can be deployed) but also more reliable. It also means devices are added to the security group during enrolment rather than after and will reduce post-enrolment latency.

PLEASE NOTE: When setting up the security device group you will need to add the service principle Intune Provisioning Client with AppId of f1346770-5b25-470b-88bd-d5744ab7952c as an owner.

The other point to call out is that there are some issues currently which you can track on the Microsoft Troubleshooting page, and these might just be enough to stop you using this in production right now especially when using it for multiple devices. Found Here. Rudy Ooms and Michael Niehaus have both been instrumental in discovering and looking under the hood at some of these.

After creating the new profile and selecting your security group, you have the option to add up to 10 Applications. Its these apps which you will get additional monitoring and be able to check their status. Presumably restricting up to 10 is more of a way of ensuring that these apps are manageable within the deployment. Be aware though that doesn’t mean you are restricted to only deploy 10 apps, its just that you can only select up to 10 within the ADP wizard.

When you move on to the ‘deployment settings’ notice that ‘Deployment mode’, ‘Deployment type’ and ‘Join type’ fields currently allow a single option. This to me is an indication that these will change in the future to add more options otherwise why add a drop down field. 

With ‘Out-of-box experience settings’ you can choose the: 

  • Minutes allowed before showing installation error
  • Custom error message
  • Allow users to skip setup after multiple attempts
  • Show link to diagnostics

After confirming your options here you can then choose up to 10 scripts you want to deploy. This introduces the added benefit of dual deployment of both scripts and apps together.

How is this monitored ?

From a monitoring and reporting perspective you now have a new capability built into Devices > Monitor > Windows Autopilot Device Preparation deployment. This gives you:

  • Out of the box granular reporting – Improved monitoring and troubleshooting. Out of the box monitoring and reporting with near real-time status of deployments, including:
    • Applications status
    • PowerShell scripts status
    • Deployment time.

With Autopilot device preparation monitoring application and PowerShell script status information this introduces improved troubleshooting and reporting. You can also track these as the device enrols which should provide near real-time status but refer below for my experience.

Compare the enrolment experience using a side by side Autopilot test

So now for the all important user experience. This is where it all comes together but does it meet the expectations ? I wanted to test this out so I recorded a side by side enrolment test, (the original Autopilot / Autopilot device preparation). For me I wanted to compare the overall enrolment experience. Is it faster, how many screens are there in comparison. It all counts as each organisation has to weigh up the expectations from the end user as well as the time to enrol. For reference I used two virtual Windows 11 Professional devices running on Mac Studio (with Parallels) enrolling them with the same user account into the same Intune tenant. The device on the left is using ADP and the second device on the right is using the original Autopilot profile where the Hardware hash has been imported and uses a default Enrolment Status Page (ESP).

Take note: Obviously this is isn’t a true scientific test and yes running enrolments side by side does mean you can’t respond to both devices simultaneously but it does reflect a real test.

The following videos therefore show two scenarios:

Test 1 – What is the experience for a simple enrolment with no deployed applications and scripts

What I expected was that ADP despite requiring additional end user input and even though there were no apps or scripts to deploy that the overall enrolment would be quicker. If you do watch the full video you will witness that:


  • ADP device enrolment took 6 minutes 23 Seconds to complete versus 5 minutes 11 Seconds with the original Autopilot profile
  • Original Autopilot end user interaction screens = 4 versus 15 with the ADP experience (Using Win 11 Professional – this is reduced with Win 11 Enterprise)
  • From an end user perspective with ADP you now have a new enrolment progress page updated in percentage terms rather than the previous ESP which I think is definitely an improvement as end users are not too bothered with the breakdown of progress, they just want to get up and running. (see video for the changed experience )

Test 2 – When you add two common Applications (Company Portal and Microsoft Office 365) how does this change the experience.

In this second test I again used the same virtual machines and ran the test side by side but this time included two common applications to deploy. Both of these were added to the ADP Profile with the dynamic device group being used for the original Autopilot enrolment. Both devices ran the Out-of-box experience after a wipe of the first test. So was how did they perform ?


  • As you can see in the video I ran a timer in the middle of the two devices to show progress. In terms of time to deploy the original Autopilot test ran for 11 minutes 36 seconds with both Applications being installed. The ADP device again took longer to complete with 13 minutes and 33 seconds.
  • Once enrolment was complete I checked the Intune status for both devices and the Original Autopilot device was showing that the apps were pending install despite showing as installed on the device. When checking the new Monitor report for ADP the applications were shown as ‘Unknown’ and ‘skipped’ although both were installed. We all know there can be lag with Intune updates but as the new monitor is meant to show near real-time updates I have to say this was a little disappointing.
  • The monitoring and reporting addition to ADP functionality also provides an update on the deployment time which as you will see below shows at 10 minutes. As per the timer used in the video above we know it did actually take longer so it would be interesting to know at which point Intune regards the enrolment as complete.

My final thoughts

Windows Autopilot has been a hot topic for a few years now and rightly so as it has played a key part in improving the whole Windows enrolment experience. Autopilot has helped instigate the move to the cloud for many companies, so when IT Admins see a change its no wonder they are keen to adopt it.

For me like i say I see this as the new option albeit using new flows and technologies. Its definitely a welcome addition to the Autopilot family as it opens up new user cases but it wont replace the original and there are a few issues to iron out before it should be used in production. I’m excited to see where this goes as it does seem to be just the starting point. Test this out thoroughly for yourself and please feedback with your results and experiences.


Rudy Ooms – Autopilot Device Preparation | Intune | MMP-C | Windows | EPM | WinDc (

Michael Niehaus – Out of Office Hours – Michael Niehaus’ technology ramblings (

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.