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.

35 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 🙂

  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?

  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.

  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.

  5. Hi Werner,
    Not sure what the difference would be between those Windows version in relation to the TPM attestation. Did you already create a support case with Intune support?
    Regards, Peter

  6. 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?

  7. The event viewer recorded zero events in the AutoPilot folder. I did tell it to collect the logs and I have those but have no way of viewing them or understanding them if I was able to view them most likely.

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

  9. 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…..

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

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

  12. 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!

  13. 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!

Leave a Comment

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