Windows Autopilot

Inside Windows Autopilot user-driven mode with Azure AD join

We’ve already talked about device registration and the initial Windows Autopilot profile download.  That’s all prep work for the “real” provisioning process performed by Windows Autopilot.  Now let’s look at the provisioning process itself, starting from where those other blogs left off:

  • If the Windows Autopilot profile specified a naming template, the name will be calculated and applied and then the device will reboot.  (Autopilot supports %SERIAL% and %RAND:x% macros for naming.  See the Intune docs on that.)
  • If no user was pre-assigned to the device (see the Azure AD network requirements):
    • The Azure AD sign-in page will be displayed, showing the organization’s branding (custom logo, org name, help text) as described previously.  (If you see any other screens before this, e.g. to choose between home and work/school, to accept a EULA, etc. then the device does not believe it is registered with Windows Autopilot.  You’re going through the standard OOBE flow at that point.)  The user can then type in their e-mail address (technically, their Azure AD UPN).
  • If a user was pre-assigned to the device:
    • The Azure AD sign-in page will be skipped (although if using ADFS or another federation provider, you might still see where it can be typed in).
  • The Azure AD password page, or if you are using a federated identity provider (e.g. ADFS) the web page that it provides, will be displayed so the user can provide their password.
  • The device will then try to join Azure AD.  If you have enabled MFA for Azure AD Join, you will be prompted to complete that process.
  • If you have configured automatic MDM enrollment, the Azure AD Join will trigger the Intune enrollment.  (If you don’t configure automatic MDM enrollment, the device won’t be managed.  See the Intune network requirements.)
  • If you have enabled the Enrollment Status Page (ESP), it will appear to process the device preparation steps.  The most significant of these steps is the last one, “Preparing your device for mobile management.”  For this step, the client device is waiting for a response from the MDM service to tell it what needs to be done.
  • Once the device preparation steps complete, the “Device setup” phase starts.  This will initially show “Identifying” until the MDM service (Intune) tells it what policies need to be applied and tracked.  These are then processed by the client device until all have been processed.  If any of them fail, the ESP will report the failure (with options to reset or continue anyway, if you’ve enabled those in the ESP settings).
  • Once all the device setup steps have completed, the user will automatically be signed in using the credentials that were typed in.  If by chance any of the apps or settings applied during the “Device setup” phase caused a reboot, then we can’t automatically sign in (as the credentials aren’t saved to disk – that would be a security issue); the user would have to type in their credentials again.
  • After the user is signed in, the first sign-in animation (FSIA) will be shown.  This can take a few minutes, while Windows takes care of installing provisioned, in-box UWP apps and other one-time tasks.
  • After the FSIA completes, the ESP will be shown again, this time to process user-targeted settings via the “Account setup” phase.  This will initially show “Identifying” while waiting for the MDM service (Intune) to send the list of user policies and apps to the device.  These are then processed by the client device until all have been processed.  If any of them fail, the ESP will report the failure (with options to reset or continue anyway, if you’ve enabled those options in the ESP settings).
  • As soon as these complete, the user can see the desktop.  The process is complete.

A few notes:

  • If you install Office 365 ProPlus from Intune, a policy is pushed to the device (tracked by the ESP in Windows 10 1809 and later) that causes the built-in Office CSP to download the Office setup bootstrapper; it then kicks off the Office install.  The status of this is reported back to the ESP.  (Right now, this doesn’t use Delivery Optimization, but the Office team is working on that.)
  • If you install any Win32 apps through Intune, leveraging the Intune Management Extensions, you may notice that the device ESP initially shows something like “0 of 1” apps.  That one app is likely the Intune Management Extensions.  Once that’s installed, the numbers may change (on Windows 10 1903 at least, as earlier versions don’t support tracking Win32 apps).  Intune Management Extensions does use Delivery Optimization (DO), so you will see DO-related network traffic.  (See the network requirements for DO too.)
  • If you have enabled Enterprise State Roaming, you may see traffic syncing settings from the cloud down to the device. 
  • Checks for standard Windows updates (e.g. cumulative updates, feature updates) don’t happen until the next normal background check, typically outside of the configured “Active Hours” window.
  • Updates for in-box apps are deferred for a period of time to ensure that they don’t negatively impact the logon experience.
  • Reboots are quite likely as policies are being applied (and if those happen at the wrong time, they can disrupt app installs, especially long-running ones like Office). Some things that can cause reboots:
    • Applying a new product key to change the Windows 10 SKU.  (This isn’t actually required as the SKU can be changed without a reboot, but it happens anyway.)
    • Unlocking an S Mode device.
    • Applying policies that install Hyper-V or other virtualization-based security features.
    • Apps.
  • The Enrollment Status Page by default waits for all apps, but you can configure a subset of those apps by specifying a list in the ESP settings in Intune.  This list acts as a filter – any apps not included in that last will install in the background without ESP waiting; any extra apps in that list that aren’t even deployed to the device will be ignored.
  • The Enrollment Status page waits for a subset of policies.  We’re working on defining exactly what that list contains, and expanding that list to cover pretty much everything you might want to wait for before allowing the user to access the device.

This is the simplest scenario overall; they get much more interesting from here.  Note that doing a white glove deployment significantly alters this flow too, so that becomes a topic of its own.

Categories: Windows Autopilot

5 replies »

  1. Hi Michael, is there any way to detect the end of the account setup phase, e.g. by checking a registry value?
    We need this as during device setup we install a customer software installation engine which itself launches setup programs.
    We want don‘t them to interfere with the setups launched by the MSI CSP and the Intune management extension.


  2. Hello, I seem to have issues and questions about this phase:

    “Once all the device setup steps have completed, the user will automatically be signed in using the credentials that were typed in. If by chance any of the apps or settings applied during the “Device setup” phase caused a reboot, then we can’t automatically sign in (as the credentials aren’t saved to disk – that would be a security issue); the user would have to type in their credentials again.”

    For some reason (since I think 1809 released) we haven’t been able to get the device to automatically login to the user account automatically, it has since always backed out to the login screen even if a restart doesn’t occur. It has the username filled in but it will literally prompt for a password explicitly. The original login to start the device configuration prompts for ADFS credentials as that is what we have setup, password hash sync is not enabled as we’re trying to not use passwords. If the idea is go passwordless the process needs to ultimately never ask for a password that doesn’t exist. Also that second login screen won’t allow the use of ADFS, and since it happens before windows hello for business kicked in there’s then absolutely no way to login to the machine.

    The Intune policy for passwords is set to ‘not configured’. Prior to version 1809 it did automatically log the user account in and they could create a PIN to login thereafter, unless a reboot happened. If a reboot did happen during setup they wouldn’t be able to log in again since it required a password.

    My questions are, what would be causing this to happen and how do we get rid of the password requirement? We want to go passwordless, which seems like it should be working considering we don’t have the passwords synced in Azure. But the autopilot process keeps requiring we use a password at some point.

    And most importantly, the second login screen that gives you no other option but to login with a username and password, will this be updated to allow support of logging in using a fido2 key or the passwordless authenticator or anything else other than just a password? To go full passwordless it’s assumed it’d be required for this login screen to change, can’t require a password to login when it’s not there. So any and all login prompts need to be passwordless enabled prior to windows hello for business can be setup for a PIN, which seems to happen last at the end of the entire autopilot process. If anything happens before then that interrupts the flow and the user can’t login again and the entire process is broke.


    • There are two possibilities: (a) a policy is configured that prevents autologon (we believe Device Lock policies can do this), or (b) a policy is causing the device to reboot (likely at the end of device ESP) and we can’t preserve the credentials across the reboot.

      We haven’t tried the whole end-to-end Azure AD join/authentication process with a FIDO2 key. I don’t have a lot of faith in it working for Hybrid Azure AD Join at this point, but it could for Azure AD Join. I have a key, just haven’t had a chance to try it yet.


      • It seems I was incorrect about one thing, when the machine gets the device configuration from Intune setting this OMA-URI:


        I actually can use a FIDO2 key to login at the normal Windows 10 login screen, which also works if the Autopilot process is interrupted, allowing me to continue into account setup. I also discovered that we can use the Authenticator app for passwordless sign in from the Autopilot welcome screen, and if I authenticate in that manner then it automatically logs in to the user account for the user account setup phase. Our normal authentication method (before I turned on phone-sign in abilities for my account) was ADFS, and it seems that authenticating with ADFS to do the initial Azure AD join breaks the account login process.

        On related notes, I can’t figure out a way to start the entire Autopilot enrollment process using a FIDO2 key specifically, only the Authenticator phone-sign in method. Hoping that does come soon, as I’m currently having fun with this key and Azure AD accounts. Likewise, hoping for more consistency for its use across the Windows 10 OS… currently can’t run as another user with the key; currently can’t select which Azure AD account stored on a key to login to the OS with (it seems to default to whatever was the last account that was added to the key, that’s the account you’ll login to windows with); and also the ability to connect to Windows Virtual Desktops with it… Browser logins with various Azure AD accounts to the Azure admin portals with the FIDO2 key is extremely awesome though, love it.