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.
Categories: Windows Autopilot
Crisp Explanation of the ESP…Michael When are you planning for the Next OOF Q&A….Cause the Session clears a lot of Doubts and Confusions.
LikeLiked by 1 person
“We should really fix that” , “Sigh” 🙂
Really appreciate the honesty and deep dive insight of the ESP.
Timely post, we are trying to migrate an 7 year old E3 tenant to M365B with ALL new computers, on the Account Setup phase it goes to Failed. In Intune all the new computers are showing Install Pending for the Office Desktop Suite app and none of the computers will ‘sync’ from the AAD work account. We have tried resetting the computers, they show up in AAD/Intune but then fail to reconnect and stay sync.
We can’t disable ESP in Intune which would be a nice troubleshooting test, maybe there is a PowerShell command to remove the ESP Profile??
You’re using Intune now and migrating to Microsoft 365 Business? I’m not as familiar with the options in Microsoft 365 Business – last I checked it has no options for ESP. But you should still be able to go back into Intune to turn it off.
LikeLiked by 1 person
The tenant was E3 standard, so no Intune with that license, Add M365B license which include W10P-Business edition, MS Office -Business (painful as Intune appears to not know about Office – en Business only Pro Plus) and EM+S (somewhat limited but getting less so).
Once the M365B licenses are on the tenant a Setup Wizard shows up on the Home page of the admin center, by walking thru the wiz, it adds the policies 1. Device policy for W10, Application policy for Android and iOS and 2 Application policies for W10 with and W/O enrollment. These all have be adjusted for MAM and WIP, really the only mostly usable policy is the Device policy.
In Client Apps a Office Desktop Suite is added.
In the Admin Center you create a AutoPilot Profile, get the csv’s upload and assign.
MS Support has reviewed all the above and feel they are correct. Now they want ESP to be disable, but the M365B wiz creates the profile and there is no way to disable or remove as it is marked ‘default’.
This isn’t the first time we have had a failure migration from an E3 tenant to M365B but the first time MS Office is failing to fulling install (left in Install Pending) and the ESP Account Settings are popping up each time the user logs in.
With the help of MS support, we determined that the dmwappushservice was missing from the W10 image. What is missing in this issue is an Intune troubleshooting tool. It took over a week to solve this and a client progressively becoming unhappy with us and Office 365.
Thanks for the great explanation.
Do you know if PowerShell scripts can be tracked in the future?
LikeLiked by 1 person
It’s something we’re looking at, no timeframe as of yet.
Thanks for your reply.
Here’s a fun for you. We have an open ticket with MS right now because enrollments have started failing. They’ve instructed us to turn off ESP which, for whatever reason seemed to fix the problem for unknown reasons which support can’t explain. Their solution is to just leave it off. Not acceptable to us since we want that in place. As we’re dealing with this via support, I’m troubleshooting perhaps something else that might have changed in the environment. I’m curious if Conditional Access policies have any impact here. Specifically, the blocking of Guest access and the requirement of MFA?
I don’t see how ESP is related to enrollment issues, since ESP appears after enrollment. Can send me your case number?
LikeLiked by 1 person
We were thinking the same thing. Our enrollments were hanging on account setup –> security policies. We opened Ticket #:16050651, and were instructed to disable the ESP, as a troubleshooting step, I believed to determine whether or not enrollment would still hang at any step without the ESP.
I asked several time for logs related to the ESP. I’ve checked the registry and event viewer logs, you detailed here, but was unable to find anything: https://blogs.technet.microsoft.com/mniehaus/2018/05/15/troubleshooting-improvements-in-windows-autopilot/
LikeLiked by 1 person
I have been testing autopilot with 1903 and the device seems stuck Account Settings security policies. Only after the set “Show time limit error when installation” i can continue
LikeLiked by 1 person
What exactly does it say? “Joining your organization’s network” shows “Complete” and “Security policies” shows Identifying?
Microsoft updated us on our ticket on this exact same issue and said we need to move the compliance policies workload from Configuration Manager to Intune. https://docs.microsoft.com/en-us/sccm/comanage/how-to-switch-workloads
We’ve always had this workload set to ConfigMgr, and we were not seeing this issue about two weeks ago, so that explication doesn’t make a ton of sense.
Microsoft still hasn’t given a resolution on this and sent the case to the product group. The ESP gets to the account setup –> security policies and hangs (I believe on identifying) until it times out after 60 minutes and then reports a failure.
Can you send me the case number? Do you see an error on just “Security” or do all four categories show the same error? (As “security policies” tracks pretty much nothing, it should never time out. But if the Intune sync doesn’t complete, then all four categories will all show errors.) If this is a Hybrid AADJ scenario, this can mean the AAD Connect sync never completed for the device.