This week a new blog post about Windows Autopilot. More specifically, Windows Autopilot self-deploying mode. Autopilot self-deploying mode is really useful for devices that are function specific, like for example kiosk devices. The biggest benefit is that a device with a wired network connection (with Internet) can be completely configured without any user interaction. Simply connect the device to the wired network and power it on! Real zero touch provisioning! In this post I’ll provide the configuration steps to create that experience, followed by some known errors and the end-user experience.
Configuration
Let’s start with a few important requirements and limitations:
- The device must run Windows 10, version 1809 or later;
- The device can only be Azure AD joined (Active Directory join is not supported);
- The device must be a physical device with TPM 2.0 (virtual machine is not supported);
Now let’s continue by looking at the available configuration options. In this case I’ll look at the different available configurations options and the related impact of those configuration options. The following four steps walk through the steps to get create a new Windows Autopilot self-deploying profile (including the available settings). That deployment profile can be assigned to an Azure AD group that contains devices.
1 | Open the Azure portal and navigate to Microsoft Intune > Device enrollment > Windows enrollment to open the Device enrollment – Windows enrollment blade; |
2 | On the Device enrollment – Windows enrollment blade, select Deployment Profiles in the Windows Autopilot Deployment Program section to open the Windows Autopilot deployment profiles blade; |
3 | On Windows Autopilot deployment profiles blade, select Create profile to open the Create profile blade; |
4a |
Note: The Self-Deploying (preview) deployment mode, defines the available Azure AD settings and the available out-of-box experience (OOBE) settings. |
4b |
On the Out-of-box experience (OOBE) blade, provide the following information and click Save.
|
— | ![]() |
Note: The Autopilot settings can only be downloaded when a network connection is in place. That’s the reason why a wired network connection should be in place. When a wired network connection is not available, it’s required to configure the region, the keyboard and a Wi-Fi.
Known errors
During the testing of Windows Autopilot self-deploying, I ran into multiple errors. More information about an error can always be found in the Event Viewer, at Application and Services Logs > Microsoft > Windows > Provisioning-Diagnostics-Provider > AutoPilot (thank you for the reminder Sandy!). The errors that I’ve seen on screen are documented and explained in the table below. If you’ve seen errors that are not on this list, let me know and I’ll add them.
Error | Description |
0x800705B4 | This error means that the device is either a virtual machine, or does not have TPM 2.0, and is not capable of running Autopilot self-deploying. |
0x801c03ea | This error means that the device is TPM 2.0 capable, but that the TPM still needs to be upgraded from 1.2 to 2.0. |
0xc1036501 | This error means that the device cannot do an automatic MDM enrollment, because there are multiple MDM configurations in Azure AD. |
End-user experience
As always, let’s end this post by having a look at the end-user experience. The end-user experience will provide a welcome message (see below) after receiving the Autopilot deployment profile and an automatic restart. An easy differentiation between the Autopilot user-driven experience and the Autopilot self-deploying experience, besides the interaction, is the logo that’s used. At this moment the Autopilot user-driven experience uses the square logo of the Azure AD company branding and the Autopilot self-deploying experience uses the banner logo of the Azure AD company branding.
Note: From and administrator perspective, an Autopilot self-deploying device can be easily recognized by the Management name of the device. It contains a GUID instead of a username.
More information
For more information about enrolling Windows devices by using Windows Autopilot self-deploying mode, please refer to the documentation named Windows Autopilot Self-Deploying mode.
Hi Jason,
Is there nothing in common? App deployment type, device type, log information, etc.?
Regards, Peter
Great post. Really helped me get my Intune Autopilot deployment setup and working.
I’ve been using it for a few months now without any issues but yesterday I Autopilot’d 5 devices and every single one, after going through the deployment stages, went to a Black screen with just the mouse cursor.
I’ve already run the process on 15 devices last week without issue so I’m reasonably confident it’s nothing to do with the configuration. Every device is a Surface Pro 4 so it cannot be a hardware spec related issue either!
I tried reboots, different combinations of button presses etc (as suggested by a comment above) but it had no effect. I did find though that by initiating an Autopilot Reset from the device screen in Intune, the device then picks up and carries on.
I just thought I’d post this in case anyone else has the issue… or finds the cause! Thx
Thank you for sharing that information, Mike!
I have today found that you can just hit the ‘Sync’ button for the device rather than the ‘Autopilot Reset’ option.. this saves a bit of user time.
Thank you for that addition, Mike!
Peter,
Forgive me, I’ve just realised I forgot to thank you for your earlier replies! Very bad form. 🙂
all the best,
f.
Not a problem, Fergus!
@Mike Halsey
I just got some Surface devices (pro 7/laptop 3) and both have the black screen after the user gets the machine and completes the MFA part (this is a device with White Glove).
Shutting down the machine and turning it on again will load Windows and you can logon and complete the enrollment.
Hi Patrick,
Do you see anything in the Event Viewer?
Regards, Peter
Hi Peter,
because a hard shutdown worked for me, I did some other checks first before I was able to continue with this issue.
So I did not check anything locally yet, but I found out that there are possible reasons why this error can occur. Like when there is a Interactive logon message (and we have this) or a custom Startmenu layout XML.
Also MS says that some DeviceLock settings can give ESP issues.
When I skip the white glove key-combo, the machine will not hang.
I will try to do something with the Interactive Logon message first and run a 2nd machine, and check the logs on the first “sealed” machine.
Peter,
maybe you can edit my last post and add this URL in it:
https://microsoftintune.uservoice.com/forums/291681-ideas/suggestions/40310866-support-for-the-logon-message-added-in-the-intera
I guess this is my issue (assumption:))
Ok for me it is solved now by disabling the Interactive Logon Message.
Thank you for all the information, Patrick!
We moved the setting from a Device assigned profile to a user assigned profile (with only the message in it, so other settings are still based for the device).
Thank you for the update, Patrick!