After you have read this enormous blog title, I guess you will know this blog will be about some weird behaviour during the ESP. I couldn’t find any documentation about the ESP, this could happen?
I will divide this blog into 4 parts.
1. Background information
I thought I already created a blog about this at some point, but I guess not. So here we go!
The Enrolment Status Page (ESP) keeps track of the device’s configuration progress and will show you the progress. When you configured the ESP, most of the time you could be pretty sure the device was ready for use. Before the user logged in all the apps and configurations would be installed and applied. The ESP tracks the installation of applications, network connections, security policies and certificates.
You can configure multiple ESP profiles or just change the default ESP page and assign it to the proper group. So first we are going to take a look at what we can configure before I show you the 3 stages.
When we look at the ESP you’ll notice some settings. It really depends on what situation you are in, but you could allow the user to reset the device, or you could decide if you want to allow the users to still use the device when an error occurs.
One of the best parts (and the most misunderstood part) is the: “block device use until their required apps are installed”.
As you have seen in the picture above, we are requiring 7 apps, but that doesn’t mean some other apps won’t be installed. Just read it again… block device use until these required apps are installed… it doesn’t say anything about the other apps. Let’s see what Microsoft has to say.
So just like I said above, if an app is assigned to a device/or user the Intune management extension will still try to install this app. And of course, this installation could fail or interfere with your truly ESP required apps.
The three ESP stooges which are tracked
Ow… wait did I say stooges? I meant the 3 ESP stages we need to know of.
· Device preparation
· Device setup
· Account setup
1.Securing the hardware
When you use Autopilot with user-driven mode this step isn’t required but when you are using self-deploying mode or Windows Autopilot for pre-provisioned deployment, it will be required.
At this first step in the device preparation, the device completes the Trusted Platform Module (TPM) attestation process and sends its hardware hash to Azure AD to prove its identity, so most of the times when your TPM has not the proper version or does not support attestation this stage would fail immediately.
2.Azure Ad join Process.
The device will join the Azure Ad, it will make use of the token it received in the first step. Please note when you are using user-drive mode this step is done before the ESP starts. It will be completed when the user has entered their credentials. And just like with the TPM, it’s required in self-deploying mode and white-glove deployment.
3.Intune (MDM) enrolment
At this step, the device is enrolled into Intune. So please make sure, just like with the first step your TPM is ready to go and up to date! Otherwise, you could end up with some errors you will need to troubleshoot.
4.Prepare the device for MDM
When the device arrives at this step, the device is going to calculate all the policies and apps that are required to be tracked. From Windows 10, version 1903 the device will also create the tracking policy for the SideCar agent and starts installing the Intune Management Extension.
You will notice it will start the identifying stage. The device is going to create a tracking policy for this phase and calculates if all apps and policies are targeted to the device context and triggers the installation.
- Security policies
The ESP does not track any security policies which are deployed to the device context. So it should be done within a few moments.2
2. Certificate profiles
During this step, it will try to install the SCEP certificates which are deployed in the device context.
3. Network Profiles
Only Wi-Fi profiles that are deployed in device context are installed. If the Wi-Fi profiles can’t be installed, the device will keep trying until a time-out occurs.
At this step all your Line of Business (LOB), Win32 Apps and Microsoft apps that are assigned to devices instead of users are installed. You will notice it will keep track of all the apps you configured as required in the ESP page.
Please note Microsoft tells us to not mix Win32apps and LOB apps. First, we need to know what part is responsible for which type of app.
The OMA DM agent is responsible for the LOB/Msi installations, and the Intune Management Agent is responsible for the installations of the Win32 Apps.
But both need to access the same trustedinstaller. So, this could fail. But not mixing up these apps? That could be very hard. In my opinion, just try it out for yourself. And please try not to assign all apps as required but as available. So, you could install these apps yourself.
Again, just like with the device setup you will notice it starts in the identifying stage. The device is going to create the tracking policy for this phase, calculates all the apps and policies targeted to the user context and triggers the installation.
- Join the Organization
When you make use of a hybrid Azure Ad Autopilot deployment at this point the device should have been Azure Ad joined. It could take up to 40 minutes to sync the device from the on premise AD with azure ad connect. When Azure Ad Connect didn’t yet sync the device, the primary refresh token is not obtained, and the user could not communicate with the service. When it fails to communicate it also fails to evaluate the targeted apps and policies. If this is the case, the account setup will be stuck on identifying until the ESP times out.
Maybe you want to use skipuserstatuspage when you are using hybrid azure ad autopilot.
2. Security Profiles
The ESP also doesn’t track any security policies deployed to the user context. But this doesn’t mean the policies are not installed! These policies are going to be installed in the background. You will always see (1 of 1) completed in the UI
3. Certificate profiles
During this step, it will try to install the SCEP certificates which are deployed in the user context.
4. Network Profiles
Only Wi-Fi profiles that are deployed in user context are installed. If the Wi-Fi profiles can’t be installed, the device will keep trying until a time-out occurs.
At this step, all of your Line of Business (LOB), Win32 Apps and Microsoft apps that are assigned to users instead of devices are installed. You will notice it will keep track of all the apps you configured as required in the ESP page.
2. The Problem
Now we have all the information we need right? I am going to show you what weird problem we encountered.
The customer had ordered 100 brand new Dell notebooks. We made sure all the notebooks were enrolled with Windows Autopilot for pre-provisioned deployment. So the only thing left for us to do was to hand out the devices and to finish the last step: Account setup.
And you can guess what happened… things all went south… About 1/5 of the devices were stuck on this screen.
After staring at this screen with the account setup for 20 minutes, we knew there was something wrong.
So… it succeeded to join the organization network, but it could not succeed in identifying the rest?
Because we don’t have any Wi-Fi/certificates or apps targeted to a user, we know these aren’t the issue… But what’s left? The only thing left are the security policies.
As I have shown in the account steps, the ESP doesn’t track security policies and only one subkey is created under
ESPTrackingInfo\Diagnostics\ExpectedPolicies for the dummy policy EntDMID.
So, getting much information about that step is going to be hard.
But it hangs on identifying. What’s happening?
The first thing to do… is press shift + f10 to open a cmd and elevate yourself so you have enough permissions to start troubleshooting. Of course, we began to search the event logs to see if we could find any errors which could be related to this problem. First, we opened the ModernDeployment-Diagnostics-Provider\Autopilot event log but found nothing useful there. No warnings/No errors.
So up we go to the DeviceManagement-Enterprise-Diagnostic-Provider Event log
The only thing we noticed was that after a couple of minutes when the account setup stage started, we receiver this error above.
It’s hard to tell if this had anything to do with the account setup page that got stuck. But searching this error showed me there could be a problem with the network connection. Let’s keep that in mind.
Let’s go further.
As you probably know, the ESP does not track PowerShell Scripts. So, to be sure we checked if there were PowerShell scripts assigned to users. But again, no PowerShell scripts could cause this issue.
Maybe the ESP is completed but could not communicate with the service? If we want to have more information about the ESP, please open the registry and open: HKLM\Software\microsoft\Windows\Autopilot\EnrollmentstatusTracking
The issue occurs at the account setup page so I guess we can skip the device part of the enrollmentstatustracking.
The same goes for the ESPTrackingInfo. This part is used to store diagnostic information for all applications and policies that are tracked by the enrolment status page. It will also show you the timestamps for when these apps and policies were installed.
This subkey below is created during the account setup phase if the device setup phase is completed successfully. It contains the installation state of Win32 apps that are deployed in the user context and the creation status of the tracking policy for the account setup phase.
So, it looks like everything is fine? I went back to the Event log and opened the system event log. Normally you don’t care about WindowsUpdate notifications in the event log until I noticed an error.
In a few seconds I was questioning myself, why was Windows Update launched, did I forget something? We didn’t create a Powershell script or a Win32 app to trigger this. I even noticed WindowsUpdate was triggering driver updates? It was updating the WiFi driver and the Intel Software which comes with it. This could have caused all network connections to disconnect.
I didn’t have the opportunity to create some event log screenshots about when the intel driver was updated. But opening MMC and device management showed me the same thing. I could switch back to an older WiFi driver.
That’s odd, because I was not expecting drivers to be updated. We made sure we did not allow driver updates with Windows Update for Business.
And if am not mistaken: updates download automatically and then install during automatic maintenance when the device isn’t in use or running on battery power.
If you want to read more about this, please check this blog:
So WuFB should not trigger this, what else could be triggering this? I wanted to know if my desktop and everything else was ready, so I decided to kill the Microsoft-Account process.
And look at the first thing I noticed!
The Microsoft Store is triggering those updates! Did I forget something? I can’t remember I have read this in any official documentation. Of course, we connected the Microsoft business store to make sure the company portal app would be installed on the devices.
This installation of the company portal was also shown in the event log.
After some googling I could not find anything useful. Except an article about updating UWP apps with the Microsoft store. This part below I found most interesting.
Comparing it to our situation. I guess when we entered the username and password to start enrolling the device it also silently signed into the Microsoft Store to trigger the Company portal installation and triggered the driver updates and UWP apps.
Store App Event log
Device Setup Manager Event log
Windows Update Client Event log
I guess that somehow caused the account setup to get stuck!
To be sure, I reinstalled the device again and went through the whole autopilot white-glove… excuse me… Windows Autopilot for pre-provisioned deployment, the first thing I did was opening the device manager.
At the beginning it was missing a lot, and I mean a lot, of drivers. The device was installed with the latest Windows 10 version available, but I guess there were still a lot of drivers missing. Within a few moments the Microsoft store triggered the installation/updating of the drivers.
And after a few minutes all the drivers were updated and installed and the Microsoft Store made sure we have all the Apps corresponding to it.
4. Fixing it
You really don’t want to stop the Microsoft Store from auto updating all the apps and drivers. Do you really want to have an outdated company portal app on all your devices? Disabling the whole Microsoft Store is also not a good option. But I have been talking about this subject in an older blog.
So I guess we have only one option left and it’s the same as Microsoft is advising when you need to skip the account setup part when you use azure hybrid autopilot.
We only need to create a CSP to make sure this stage is skipped:
After digging into finding some evidence that the Microsoft Store can be used for updates, I came across this one article:
So, I instead of telling myself there is no way the Microsoft Store could trigger it… I guess it can…
Normally we don’t skip the user status page instead, we make sure the user account page is not shown when another user logs in to the same device. But in this situation… we rather skip the page instead of disabling the store!
Want to read more? Try out a couple of these blogs: