In past blog posts, I walked through the user-driven scenarios – both user-driven Azure AD Join and user-driven Hybrid Azure AD Join.  Now on to scenario #3, self-deploying mode.  In many ways, this seems like a simple scenario.  But there are some interesting twists.

First, let’s talk about the requirements, from the official documentation (which, now that I read through it again, needs to be re-worked – will add that to the to-do list):

• You need to use a physical machine; virtual machines are not supported.  This is because the device must have a discrete or firmware TPM; emulated TPMs in virtual machines are not allowed.
• The device must support TPM 2.0 and TPM attestation.  That sounds easy enough, but there are complications, as I previously noted. 
• Windows 10 version 1903 or higher should be used.  (While this feature was originally introduced in Windows 10 1809, it wasn’t reliable enough to be used in production scenarios – too many random TPM failures.  As a result, we changed the requirements to 1903 or above.)
• Azure AD company branding must be configured.  (Some Windows Autopilot scenarios work with this.  Self-deploying mode is not one of those scenarios.)

The rest of the setup should be fairly routine if you’ve done any work with Windows Autopilot.  First, create a self-deploying mode Autopilot profile:

Notice that there are only a few settings:

• The “Language (Region)” setting.  If this is configured, it can automatically select the language and locale that the device should use, skipping all of those OOBE pages.  But that only works if the device is already connected to a network (e.g. Ethernet-connected) so that the Autopilot profile can be downloaded before you would otherwise need to navigate through those pages (e.g. to get to the Wi-Fi connection page).  Notice that we now have a much longer list of languages/region settings in the list now (after many of you complained):

• A second setting that lets you specify to “Automatically configure keyboard.”  Why is this separate?  Well, in some locales, there can be multiple keyboard layout options and you might want to let someone manually choose.  But if you set this option to “Yes” then it will automatically choose the default keyboard layout for the chosen language/region.
• A device name template, which works just like user-driven Azure AD Join (supporting %SERIAL%, %RAND%, and constant characters).
• A choice as to whether the user should get admin rights.

Next, you need to assign that self-deploying profile to an Azure AD group, then you need to add the Azure AD device object (created when you register a device with Windows Autopilot).  Give it some time to make sure Intune takes care of telling the Windows Autopilot service to apply the profile, then you’re ready to deploy.  Of course you might want to assign other apps and policies to the device too, especially if you want the device to be a kiosk or digital sign.  If you assign a kiosk profile, a local account will automatically be created and configured to automatically sign in; otherwise, the device would just be a shared device and would end up at the Windows logon screen, where any user in the Azure AD tenant would be able to sign in.

So let’s walk through the client-side experience.  First, the device will boot up.  If you’ve specified language/region settings and to automatically configure the keyboard layout, and if the device is connected to Ethernet, the first thing you’ll see is this:

That’s a good sign, as it indicates that the device was able to connect to the internet, download the Autopilot profile, and see that it’s self deploying and includes language/region and keyboard settings.  OK, so what’s next?  That would be the device enrollment status page (ESP):

A few notes to call out here:

• If you’ve only targeted ESP settings to Azure AD groups, you won’t see your settings being used – the settings are only used for users, not for devices.  You would need to target settings using the default ESP settings, which target “All users and all devices.”
• Because the ESP is critical for self-deploying mode to complete, even if you don’t enable ESP at all, you’ll still see it show up – we force it to show up with a set of default settings.
• Notice that there’s no account setup?  That’s because this is a user-less scenario, so there are no user settings to monitor.  So don’t expect things that depend on user settings (Company Portal, Conditional Access, etc.) to work in all self-deploying cases.  (We’ve been working on user-device affinity rules to help with user assignment in these cases.)

During the device preparation step, a few steps are performed:

• The TPM attestation process is performed.  This allows the device to prove that it’s not an imposter, so Azure AD will then provide it with an Azure AD device token that can be used to join the device to Azure AD and enroll in Intune.  (If it fails, it will be tried again, and again, and again – eventually, it will give up and report a timeout error, usually after about 12 minutes.  But the error won’t clearly indicate that it was a TPM attestation problem – but always check that by looking at the microsoft-windows-moderndeployment-diagnostics-provider-autopilot.evtx log.)
• The device will join Azure AD using the device token.
• The device will enroll in Intune using the device token.  This is another problem area:  If there were a user signing into the device, that user would have Intune enrollment URLs associated with it, since you can target Azure AD auto-enrollment settings to groups of users.  But for a device, you can’t assign Azure AD auto-enrollment settings to a group of devices.  Instead, Azure AD has to figure out itself what URL should be used.  That’s easy enough if there is exactly one MDM app defined in your Azure AD settings.  If you see more than one entry in Azure AD, the self-deploying enrollment will fail with a 0xC1036501 error:

You can delete the extra entry (typically “Microsoft Intune Enrollment,” which is apparently used in some Conditional Access scenarios, although if you are doing auto-enrollment with any other MDM services, they would be listed here too) to get past this problem.

During the device preparation phase, all device-targeted apps, policies, and certs will be deployed to the device.  (Note that right now not all policies are tracked by the ESP, so if you aren’t deploying any apps or certs, it is possible that device ESP will finish before all policies are applied.  That could cause issues with simple kiosk configurations, e.g. automatically signing in as a local account and launching the Edge browser.

Assuming no errors were received during the device ESP, the process will either finish (no kiosk configuration) or automatically sign in and display the configured single-app or multi-app kiosk configuration.  (You can go all the way back to this 2018 blog for more details on how to set up kiosk.  Things have probably changed some since then though.)

A few additional notes:

• Pay attention to the Windows Autopilot known issues list, especially if you are seeing TPM attestation issues with brand-new devices.  This has details on important Windows 10 1903 fixes related to TPM attestation.
• If you are deploying kiosks or digital signs using Intune, there is an available Intune device-only subscription license that can be used.  See the Intune licensing documentation for more around that.
• The Windows Autopilot white glove scenario uses self-deploying mode behind the scenes (more details on that scenario in a future post).  So it would be helpful to try out a self-deploying mode deployment first, joining a device to Azure AD, as a “warm-up” for performing a white glove deployment (just like completing a user-driven deployment without white glove is a good warm-up for completing the white glove process).
• If you run into errors in a self-deploying mode deployment, be sure to include TPM details in the captured logs.  You can grab those using “MDMDiagnosticsTool.exe -area Autopilot;TPM -cab c:\autopilot.cab” from a command prompt (open by pressing Shift-F10).
• Would you want to have a self-deploying device join Active Directory?  If so, let us know by adding votes to the Intune Uservoice item talking about that.