The latest news on Windows Autopilot

Published May 21 2019 10:01 AM 27.9K Views

Windows Autopilot is designed to change the way organizations deploy Windows devices. With the availability of Windows 10, version 1903, we have introduced additional capabilities to make that process even better.

First, there is the new Windows Autopilot white glove process, which lets IT technicians, partners, and even OEMs pre-provision devices before they are delivered to the user. Using this process, all device configuration tasks, including apps (machine-targeted or user-targeted), certificates, and policies, can be completed in advance, making it so that when the user gets the device, the device can be ready for productive use within a few minutes.

For more details about the Windows Autopilot white glove process, check out the new Microsoft Mechanics video:


The Windows Autopilot white glove process will be available in preview in the coming days. For a demo of Windows Autopilot white glove pre-provisioning, watch the latest Endpoint Zone episode with Brad Anderson and Simon May, which also includes a demo of the Windows Autopilot Companion app.


In Windows 10, version 1903, we've also enhanced the Enrollment Status Page so that it can track Win32 apps being installed by Microsoft Intune management extensions. We've changed the OOBE process so that Cortana no longer talks (with Windows 10, version 1903 Pro and above SKUs). And, we've added a new mechanism that will enable us to update the Windows Autopilot feature itself without waiting for a new Windows 10 release, through a Windows Update-driven mechanism.

In Windows 10, version 1809, we introduced Windows Autopilot user-driven mode for Hybrid Azure AD Join, in which devices are deployed into Active Directory, where they can continue to leverage capabilities like Group Policy while also being connected to Azure AD for single sign-on to Azure AD-based services such as Microsoft Intune, OneDrive for Business, and Office 365. We are pleased to announce that, based on customer feedback and deployment activity, this scenario is no longer in preview.

The Enrollment Status Page, introduced with Windows 10, version 1803, is also no longer in preview. With the addition of Office 365 ProPlus tracking with Windows 10, version 1809 and Win32 app tracking with Windows 10, version 1903, we believe the Enrollment Status Page should be enabled for all Windows Autopilot deployments, to ensure that devices are ready for productive use before users can access the Start menu.

Windows Autopilot self-deploying mode, which enables devices to be deployed without any user interaction or credentials being entered, was originally released as a preview feature with Windows 10, version 1809. Based on customer feedback related to TPM attestation challenges, we have made additional enhancements in Windows 10, version 1903 to improve TPM attestation so that, going forward, this scenario will only support Windows 10, version 1903 and above. Windows Autopilot self-deploying mode will remain in preview as we seek out customer feedback on these enhancements.

We also introduced Windows Autopilot for existing devices with Windows 10, version 1809, which enables devices running Windows 7 or Windows 8.1 to be migrated to Windows 10 and Azure Active Directory. Based on customer feedback, we will be adding additional support for Hybrid Azure AD Join to this scenario. Stay tuned for additional details.

To learn more about Windows Autopilot, be sure to check out these additional resources:

If you have any feedback or suggestions for Windows Autopilot, please submit your ideas via the Microsoft Intune UserVoice site.

Occasional Contributor

Great stuff Michael. Well done team! Will self-deploying AutoPilot profiles now be supported on Windows 10 1903 VMs?

Senior Member

Nice enhancements.
When will tenants see White Glove as an option?


I am trying to find the "Allow White Glove OOBE" option in Intune ->Device enrollment - Windows enrollment -> Windows Autopilot deployment profiles --> <Existing_profile_name> - Properties but couldn't see it anywhere.
I have also tried creating a new profile for both "User Driven" and "Self Provisioning" modes and still couldn't find the White Glove option.

Super Contributor

It says "The Windows Autopilot white glove process will be available in preview in the coming days.". Which can be days, weeks, months :)


We purposely said "days" because we hope that it will be available this week or next - the deployment is in process, but can take a while.


We still don't support VMs for self-deploying mode.


@Michael NiehausWhat is the difference between "White Glove " and "Self Deploying" mode?

Super Contributor

In my understanding: Self Deploying is such Autopilot option when admin or user just turns on Windows 10 PC and it goes through all steps (language, keyboard, etc.) automatically, also ESP and installing apps and settings i guess. So after turning it you only have to login with user credentials. White Glove option allows OEM, reseller, IT admin to turn it on, let ESP do its job (install apps, settings, etc.), then "reseal" it and give to the user. User doesn't have to wait for apps installation on ESP page and gets to login faster. Self Deployment just removes manual steps, but it would take same time as manual steps on a bad network and with lots of apps to install. White Glove adds a transit point to install everything before PC ends up in user's hands.


@Oleg K: So essentially the difference between White Glove and Auto Provisioning is that White Glove gives you the option of Resealing?

Super Contributor

Yes, it doesn't go all the way, only does the most time and bandwidth consuming step (apps download and installation). If you give a user a PC with Self Deploying profile, they won't have to select language, etc., but they still would have to wait for everything to download and install. I haven't tried this options myself, but i assume one can also do "white glove" by turning on PC with Self Deploying, wait for everything to install, then shutdown and give it to the user. Without the resealing part. I don't have experience with Autopilot other than videos, blogs and docs, so maybe i'm missing some nuances.


@Oleg Ki have played abit with the "Self Deploying" mode. it deploys machine targeted apps, profiles and configurations just like "White Glove". In "White Glove" because you can pre-assign the user to the device, i reckon you can therefore deploy user targeted apps, profiles and configurations as well before the user logs in for the first time.

Super Contributor

I see, so there is a difference in machine targeted and user targeted option. User targeted profile can have some more apps and settings, so White glove can help win some time in this case. And reseal. Which sounds fancy, but one can just shutdown the device. Maybe this can be important, if you want a user to select their preferred language, keyboard layout, connect to their wifi, so then showing all the steps after the reseal can be useful.

Not applicable

I want to do some testing with the self-deployment mode as well But no matter what Windows 10 build I try (Windows 10 1809, Windows 10 1903 or even Preview build 18343) I always get an error on the step "Securing your Hardware (0x800705b4)".

I'm using a Surface PRO 4 as a test device. Any ideas on what might be going wrong here? 



@Deleted the error code refers to missing TPM 2.0 chip. Hope you are meeting the requirements called out in this link:


The Surface Pro 4 is affected by the TPM firmware vulnerabilities.  See for details and link to the necessary firmware update to fix the issue.  (We do recommend using Windows 10 1903 rather than 1809 as the TPM attestation process is much more reliable.)


White Glove has now been rolled out:




@Michael Niehaus @Arnab Mitra @Oleg K how do we pre-assign a user to a device in White Glove autopilot provisioning? i am referring to the step in the following screenshot in this video: 



You can pre-assign a user via Intune.  Find the device in the Device Enrollment -> Windows Enrollment -> Devices, select it, and then click "Assign user."  

Assign user.png

Occasional Contributor
Hello Team, Looking forward to testing the Self-Deploying Autopilot deployment mode! Curious on how long it may be in preview before it is officially released as we are hesitant to rely on it for production? We are being cautious due to any changes or functionality problems that may be encountered down the road, but if it works in the lab any reservations necessary (i.e. known bugs to be worried about)? This feature would be a tremendous help to us since we need our devices ready to go before our end users get them since they end up in an environment with limited internet connectivity. Keep up the great work!
Senior Member

hello team, 


i tried to upload the csv file to the Microsoft Partner Center but the button add Device is missing. We are dependent on adding it by the MPC, since this is the only way to add devices without unpacking while having only the PKID. This is holding us back. Isn´t it possible anymore to add devices via MPC?





Senior Member

Hey, great post @Michael Niehaus 

We are currently migrating from one intune to another. 

Today I discovered why we have problems with our testing. Our json file (AutopilotConfigurationFile.json) has the version value of "2049", and according to the documentation this is only working with 1809 while our devices are still on 1803.


What we see is that a wipe from 1803 deletes the json file, while a wipe from 1809 keeps it. And this makes all the difference i'm afraid. 

Dropping the json file in immediately after the wipe from 1803 does not give any better results. 

I will go back tomorrow and test a json without any value in the version field (just in case) but I don't have high hopes for a solution. 


Do anyone know of a way to keep the file from deleting itself during wipe from a 1803 device? 
We are high strung these days as time has become a factor. Any suggestions is received with the greatest of appreciation. 




Hey @Michael Niehaus ,


I been testing Auto Pilot with Hybrid AD join using White Glove on 1903 (10.0.18362.239) and it "works" but not as I would expect. The Auto Pilot Screen stays on provisioning for a couple minutes, then it reboots and I am presented with a Green Success Screen with a time of 0 Hr and 0 Min. But no apps have been reported as installed. If i let it sit on the Success Screen for 10-20 min the apps do get installed. I have checked logs using MdmDiagnosticsTool.exe but i can't locate any clues. The main app I am obliviously worried about is Office 365, and its targeting my Dynamic Auto Pilot Group. Is this a bug or is there something i can look into? Thanks!

Senior Member

Hi Andrew.. make sure you have the "default" enrolment status page enabled to track app and profile installations.  I had the same issue (only with AAD joined devices).  For user-driven mode we created our own an ESP configs and assigned those to the appropriate user groups.  This is mainly so we can localise the text displayed if it fails into different languages.  I had never configured the default ESP configuration which is assigned to all devices and users.  White Glove only uses the default ESP configuration so if you haven't configured that then it will explain your issue :-).




Hi Team, i am testing White Glove service in a pilot setting. Can i use White Glove service together with Autopilot for existing devices? So with the autopilotconfiguration.json file?


No, to use white glove the device must be registered; using the AutopilotConfigurationFile.json won't work.

@Michael Niehaus, thank you for the clear answer. In the pilot we also want to do White Glove at the Vendor Site. Another requirement in this pilot is the use of Autopilot Hybrid Join. Is it possible to do a White Glove Hybrid Join at Vendor site without direct connection to customer site (on-premise domain controller/intune connector)?
The answer was found in docs: Because the OEM or vendor performs the white glove process, this doesn’t require access to an end-user's on-prem domain infrastructure. This is unlike a typical hybrid Azure AD-joined scenario because rebooting the device is postponed. The device is resealed prior to the time when connectivity to a domain controller is expected, and the domain network is contacted when the device is unboxed on-prem by the end-user.
Occasional Contributor
Hi, I'm trying to do a ROI for Autopilot vs the traditional way to deploy, pretty much for time spend with our ressources. Any study have been done?
Version history
Last update:
‎May 21 2019 12:44 PM
Updated by: