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.