Windows Autopilot self-deploying mode

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.

71 thoughts on “Windows Autopilot self-deploying mode”

  1. Great post Peter. Good to mention you need wired connection otherwise internet connection comes too late to Connect to intune 🙂
    Was thinking how and why i got the keyboard and region questions 🙂

    Reply
  2. Hi there Peter,

    I exported the event logs and don’t actually see the TPM error event #171 as described here : https://docs.microsoft.com/en-us/windows/deployment/windows-autopilot/troubleshooting

    I do see event #153 ‘AutoPilotManager reported the state changed from ProfileState_Unknown to ProfileState_NotProvisioned.’

    To set the context – I am testing this with Offline Autopilot – I have an autounattend.xml placing the json .

    Any other events of interest I should be looking for in your experience?

    Reply
  3. Some further event logs now after a few re-tries – Event 176 – MSA TPM keystate has been updated. New server state = 3, new client state = 6, followed by 152, 182, 150, 183, and finally 177 ‘TPM attestation retry is being attempted. Current retry attempt 3 of 3 maximum’. This is a modern TPM 2.0 device as stated.

    Reply
  4. Yes I did – thank you for your time on all this. Microsoft basically told me it’s not fully supported in 1809 and is still a preview feature. They said to try the latest Preview build.

    Reply
  5. I am getting error code: Registering your device for mobile management (Failed: 6, 0x80180005). Using a Surface Pro (2017 model aka Pro 5 and also tried a Pro 4) both failed with the exact same error. These are not hybrid joined, straight up Azure AD AutoPilot with a bare bones 1903 image. It works just fine with a user driven profile but I want to set this up with the self deploying profile as these device will be shared among many so I would like to take advantage of the shared device guest mode the self deploying profile offers. Any ideas?

    Reply
  6. I am getting registering your device for mobile device failed 6, 0x80180005 error. Windows 10 build 1809.
    TPM 2.0

    Reply
      • So just to follow up. I reset the device and let it try one more time and it failed again but later on in the setup. I powered off and back and it tried one more time and completed without fail. Looks like Microsoft has some bugs still to work out. I have one working exactly like I needed it to after about 20 attempts and about a week of trying…..

        Reply
  7. I’m getting the same 0x80180005 error on an HP EliteBook x360 1030 G2 with TPM 2.0 and 1903.
    Frustrating, especially with the lack of meaningful errors in Intune.

    Reply
      • Tbh I’m not sure how I get any events if on failure it forces me to reset the laptop!
        Clearly I’m missing something, so prepared to be schooled, but I selected “Save logs” (or whatever the button is) and it seems like it saved a cab file from the successful (user-driven) deployment that happened after the failure.

        However, I did ask Mike Niehaus and he said it’s a failure to enroll into InTune (as opposed to the AAD join), so I wonder if the fact that in “AAD – Mobility (MDM and MAM) – Configure” I am allowing only a specific user group to autoenroll might have something to do with it.

        Going to test it tomorrow.

        Reply
  8. We are getting that same failed 6, 0x80180005 error using self-driven autopilot and are stuck on it. There are four errors in the event log that repeat over and over.

    MDM Enroll: Server context (dca58854-66bc-42e8-8082-8b089122133a).
    MDM Enroll: Server Returned Fault/Code/Subcode/Value=(EnrollmentServer) Fault/Reason/Text=(ZTD Profile was not found).
    MDM Enroll: Failed to receive or parse certificate enroll response. Result: (Unknown Win32 Error code: 0x80180005).
    MDM Enroll: Failed (Unknown Win32 Error code: 0x80180005)

    Not sure if we’re missing something or what. The device joins Azure AD fine but doesn’t enroll in Intune. We did manage to get one of these devices enrolled into Intune manually and this error doesn’t occur if the device is already enrolled. We plan to open a case with Microsoft as well but if you have any idea on this we’d appreciate the help!

    Reply
  9. Hi Peter,
    Thanks for the reply. Just wanted to let you know we figured this out. In our case there were a couple of issues that solved this for us.
    First, up until this point we were using the Microsoft Store for Business to assign a profile to our devices. After reviewing the Microsoft documentation for a self-deploying autopilot profile it says that this is not supported and to assign the profile through Intune. After doing this we got further but a different error showed up.
    The second error occurred because there was a policy to hybrid-join devices that was assigned too broadly. After looking around I found either hybrid join isn’t currently supported for self-deploying mode or there was an issue with hybrid join and using a variable (like %SERIAL%) for naming a device. I haven’t yet had a chance to see which of these was causing the issue. For our devices AAD-only join was ok so we narrowed the scope of the hybrid join profile and after that everything started working perfectly.
    Hope that helps someone!

    Reply
  10. Hi Peter, great blog! Could you please confirm that the option “Privacy settings = Hide” is not there anymore for “self deploying” mode? Keep getting this screen every time running self deploy, a little frustrating.

    Reply
  11. I have a Windows 10 1909 installed on HP G2 device with TPM 2.0. The device fails with the error 0x800705B4 Tried to reset the device multiple times but without luck. When I had collected the logs interestingly enough that I found no errors in neither events. I checked the following events:
    – microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin
    – microsoft-windows-moderndeployment-diagnostics-provider-autopilot
    – microsoft-windows-provisioning-diagnostics-provider-admin

    Unfortunately with no luck. I found this TpmHliInfo_Output file, and I thought for a second let me check the TPM. What’s interesting about this file is that I found that no valid EK Cert found. I have used a different wire that connects the PC directly to the internet. The deployment succeeded. I have then added the manufacturer’s domains and subdomains to the whitelists to allow the access to the manufacturer’s domains. This has surprisingly resolved the issue. I tested it on anothr machine and it worked.

    Reply
  12. @Bryan Haakensen; Where did you find the hybrid-join policy? I’m getting the exact same “failed 6, 0x80180005” error, with the same event viewer logs. Removed the variable in the computer name, and also deleted the computer from the Business store and added it again through InTune. I’m still stuck and kinda clueless on whats going wrong. 😉

    Reply
  13. I’ve got 400 or so self deployed devices out in the wild right now. They work well, but seem to have an issue picking up apps deployed as required to the device. Some install, some don’t seem to apply. No logs or anything. I use them on a user driven deployment and they work fine.
    It weird.

    Reply
  14. 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

    Reply
  15. 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.

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

    Reply
  17. @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.

    Reply
  18. 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.

    Reply
  19. Hi Peter,

    Thank you for your great blog, it has helped me many times.

    Now however, I have an issue that I haven’t managed to solve yet:
    I want to self-deploy Windows 10 (en-US language), but since the computers have a Swedish keyboard, this needs to be configured. I have tried everything i can think of, but the devices are still configured with a US-layout.
    I have a powershell script that sets the keyboard layout for the current user on login, but the Windows login screen is still having the US-keyboard.

    Letting the user choose the keyboard layout is not an option (the computers are lab classroom computers at an university). As we have a large number of international students, w we can not use Swedish only either.

    Do you know a way to solve this? Any suggestions are welcome!

    Reply
      • Hi Peter,

        Thank you for your reply. I know it is supposed to be that way, but unfortunately it doesn’t seem to work.

        The language/region in the deployment profile is set to Swedish, and Automatically set keyboard is set to yes, but after installing the device, it has a US keyboard layout on the logon screen.

        I’ll guess I will need to open a support case with Microsoft.

        Reply

Leave a Comment

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