Have you ever wondered what actually happens during each phase of the Enrollment Status Page (ESP) and each step within a phase?  Or maybe more simply, what exactly is it tracking?  If you look at a composite picture of the ESP UI (showing all sections expanded – something impossible to do while the ESP is active) you can see all the pieces:

At the highest level, the three phases are:

• Device preparation.  This covers a fixed set of tasks related to joining AD or AAD, enrolling in Intune, and figuring out what needs to be tracked before the ESP can say the device has been successfully provisioned.
• Device setup.  All device-targeted policies (and sometimes some user-targeted ones too) are delivered during this phase, and some of them are tracked.
• Account setup.  All user-targeted policies are delivered during this phase, and some of them are tracked.

In between the “Device setup” and “Account setup” phases, you will see the first sign-in animation (FSIA), what used to be called the “rainbow” screen (it’s now just shades of blue).  And in some cases, you’ll also need to manually sign in again after the “Device setup” phase completes:

• Any time the device reboots during “Device setup.”  We can’t store credentials across reboots for security reasons.
• Any time you are performing a Hybrid Azure AD Join.   The first time, you provide credentials to authenticate to Azure AD.  The second time, you are specifying credentials to authenticate to Active Directory.

I’m going to focus on the behavior with Windows 10 1903; what you see in Windows 10 1803 and 1809 may be slightly different.

So let’s review the detailed steps:

• Device preparation
  • Securing your hardware.  In the case of self-deploying mode, this step performs the TPM attestation process needed to join the device to Azure AD using a device token (a secure mechanism to ensure only properly-registered devices can join your Azure AD tenant).  For all other scenarios, this step does nothing.
  • Joining your organization’s network.  When joining Azure AD, this step tracks the actual Azure AD join process.  When joining Active Directory, this step does nothing as the join occurs prior to the ESP loading.
  • Registering your device for mobile management.  In the Azure AD join case, this step does nothing because the Azure AD join triggers an automatic MDM enrollment.  In the Hybrid Azure AD Join case, the MDM enrollment occurs prior to the ESP loading.
  • Preparing your device for mobile management.  During this phase, ESP is waiting to receive a list of policies that it is supposed to track.  That includes the categories listed below: security, certificates, network connections, and apps.  This can take a little while because that list of policies may require installing additional policy providers.  For more on that, see my previous blog.
• Device setup
  • Security policies.  You would think that the ESP would track all security policies – they’re generally small and quick to apply (although some can cause a reboot).  But in reality, you’ll always see this say “0 of 1” and then quickly advance to “1 of 1.”  It’s not really tracking security policies at all.  We should really fix that…
  • Certificates.  If you have targeted any SCEP-issued certificates to the device, this step will track the progress of those certificate enrollments.
  • Network connections.  If you have targeted any Wi-Fi profiles to the device, this step will track them being applied.
  • Apps.  This is generally where most of the time will be spent, waiting for apps to be installed.  This can include single-file MSI apps (LOB apps), Win32 apps (using Intune Management Extensions), and Office 365 ProPlus.  Because the Intune Management Extensions (IME) is an MSI itself, you’ll see that included in the count as well.  Since you can filter this list as part of the ESP settings (telling ESP to wait for a subset of the targeted apps), the counts might be smaller than the number of targeted, required apps.  But the policies for those are are still delivered to the device at the same time and are likely still getting installed, just not tracked.  Also note that when performing white glove pre-provisioning with an assigned user, Intune will also include user-targeted, required, device-context apps in the device apps list (a good thing, as it lets you install the user’s apps before they get the device).  And lastly, PowerShell scripts are currently not tracked either.
• Account setup
  • Joining your organization’s network.  In the Hybrid Azure AD Join case, this step is waiting for the Hybrid Azure AD Join device registration process (where AAD Connect syncs the device from AD to AAD) to complete.  If that process (which runs every 30 minutes) completes before the user signs into AD, everything is ready to go – Hybrid AADJ is complete and the user has an Azure AD user token.  (If the device app installs take close to 30 minutes, that’s pretty likely.)  But if the AD user signs in before AAD Connect has done its thing, this step will wait for that to happen and then force the user to enter the Azure AD credentials.  (Without that extra prompt, the MDM client wouldn’t be able to ask Intune for user policies until the user signs out and back in again.)  In an Azure AD Join case, this step does nothing.
  • Security policies.  Just like in the device setup phase, this is only tracking one “dummy” policy, so you’ll see it immediately go to “1 of 1.”  Sigh.
  • Certificates.  If you have targeted any SCEP-issued certificates to the user, this step will track the progress of those certificate enrollments.  (Be careful if you are targeting any Windows Hello for Business certs, because Windows Hello for Business won’t be set up until after ESP completes.  We are working on away to not block on WHfB certs to keep ESP from failing in this particular scenario.)
  • Network connections.  If you have targeted any Wi-Fi profiles to the user, this step will track them being applied.
  • Apps.  Just like with device-targeted required apps, except here we take care of any user-targeted required apps.  This will include MSI apps, Win32 apps, Office 365 ProPlus, and UWP apps.  As device-targeted apps, the list can be filtered as part of the ESP policy, and PowerShell scripts are not tracked.

Simple, right?