Windows Autopilot self-deploying mode

by

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

WA-SD-CreateProfileOn the Create profile blade, provide the following information and click Create;

  • Name: Provide a unique name for the Windows Autopilot deployment profile;
  • Description: (Optional) Provide a description for the Windows Autopilot deployment profile;
  • Convert all targeted devices to Autopilot: Select Yes to automatically convert Intune managed devices to Autopilot;
  • Deployment mode: Select Self-Deploying (preview), as that deployment mode provides the functionality that is needed for this post;
  • Join to Azure AD as: Azure AD joined is selected by default and grayed-out, as it’s the only configuration option supported for Windows Autopilot self-deploying devices;
  • Out-of-box experience (OOBE): See 4b.

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.

  • Language (Region): Select the Language that should be automatically configured during the Windows Autopilot self-deploying experience. This configuration will only be performed when the device is on a wired network connection (with Internet);
  • Automatically configure keyboard: Select Yes to automatically configure the keyboard based on the selected Language. This setting is only available when a Language is configured and this configuration will only be performed when the device is on a wired network connection (with Internet);
  • End user license agreement (EULA): Select Hide to hide the EULA during the Windows Autopilot self-deploying experience;
  • Privacy Settings: Select Hide to the hide the privacy settings during the Windows Autopilot self-deploying experience;
  • Hide change account options: Select Hide to hide the change account options during the Windows Autopilot self-deploying experience;
  • User account type: Select Standard to only make any user on the device a standard user. With the exception of global administrators and company administrators;
  • Apply computer name template (Windows Insider Only): Create a computer name, according to the configured template, for devices at initial startup;
— WA-SD-OOBE

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.

20181104_165048

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.

65 thoughts on “Windows Autopilot self-deploying mode”

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

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

  6. Peter,
    Forgive me, I’ve just realised I forgot to thank you for your earlier replies! Very bad form. 🙂
    all the best,
    f.

  8. @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.

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

Leave a Comment

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