My mama always said Autopilot is like a box of best efforts. You never know what you’re gonna get.

Suppose you are interested in how a new (or maybe old) Enrollment Status Page (ESP) function will improve the experience when the Win32Apps are installed during the Autopilot technician phase. In that case, you will need to make sure you will read this blog.

This blog is going to show you everything you want to know about this new ESP function: called: “Only fail selected blocking apps in technician phase (preview)”

1. Introduction

In the Week of February 19, 2024, Intune Service release 2402 was released.

What’s new in Microsoft Intune | Microsoft Learn

In this service release, Microsoft mentioned the fact that we now have a new option available we configure in the ESP. This option is called: Only fail selected blocking apps in technician phase (preview)”

If you think that sounds familiar, yep!! It does sound familiar because this feature was already out there and announced in March 2023.

So yeah, it’s the same thing but this time it’s in preview? Did they mess up the year? But let’s move on, shall we?

This ESP addition is going to give us the option to define some blocking apps (IsSelectedApp) in the ESP

When we configure these blocking apps, we define which apps must be installed on the device when it is enrolled (this is preferable with Autopilot). Only these applications will be installed during enrollment.

If we configure the option to only fail selected blocking apps in the technician phase, we activate the best-effort ESP feature. When this feature is enabled and Autopilot is utilized in the technician phase (Pre-Provisioning), ESP will attempt to install all the required Win32 apps assigned to the device.

In this scenario, the ESP (in fact, the Intune Management Extension) will make the best effort to install all blocking apps and the other required apps. For apps not designated as blocking in the ESP policy, the system will perform a best-effort attempt to install them. With the best-effort feature enabled, it will report the status as completed even when the app fails to get installed.

To get to know more about this best-effort feature, I added a new Win32 app and started the Autopilot Pre Provisioning.

2. Best Effort / Allow Non-Blocking App Installation

To find out how this new feature was working, I created a new Win32App to remove some duplicate shortcuts on the device.

To make sure the app is deployed, I configured it as a required app for all devices.

To get the ESP best-effort function kicking in, I made sure I did NOT add the app to the list of blocking apps (IsSelectedApp: False)

Besides adding the app as required, I also made sure I messed up the detection rule to make sure that the app would fail during the pre-provisioning.

After assigning the app I also made sure I configured the option to only fail selected blocking apps in the technician phase. (Graph: AllowNonBlockingAppInstallation)

With the new Broken Win32app configured, I started the Autopilot pre-provisioning. Once the device started deploying, I opened the Intune Management Extension (IME) log with the CMTrace tool and I opened IME Win32AppPlugin.dll with the dotpeek tool and IDA on my own device.

Microsoft.Management.Clients.IntuneManagementExtension.Win32AppPlugIn.dll

If we delve deeper into this IME Log, we quickly discover that the ESP will attempt to retrieve some information (Policies) about the Win32 apps assigned to the device.

As shown above, we will notice that the policies contain the ESPConfiguration. This configuration mentions if the app needs to InstallWithBestEffort and if the app IsSelectedApp.(blocking app) We will also spot that behavior in the DLL I pointed out earlier.

With all the Apps processed and ready to be installed, the ESP knows if it needs to install the app with the best effort (InstallwithBestEffort) and which apps are selected in the policy (IsSelectedApp). Once it checks all of the apps, the AppLockInProcessor will kick in.

The AppLockProcessor will start processing the tracked apps. From there on the win32apps will be installed one by one. As mentioned above, I made sure I messed up the detection rules of the app.

The ESP will normally report the state as an error but because of the best-effort feature is enabled and because of the app is NOT a selected app (blocking app) it will report the app as completed.

Cool, right so, even when the app is not properly detected it will still be reported as completed in the device ESP. From there on when the user logs in for the first time after the device is sealed, the ESP will try to retry the installation once more.

3. FirstSync and the ESP Phase

As we explore the Best-Effort function, it’s essential to also briefly examine how the ESP determines whether the device is in a device session or undergoing user enrollment. Surprisingly, this process is quite straightforward.

Once the device starts the Autopilot enrollment, the Intune Management Extension will try to determine the device phase by fetching the GetlogonId (SID) From the FirstSync registry key

The IME will try to find the FirstSync registry key, which is shown below.

So, in the example above, our user logged in and started the Autopilot enrollment. If we are using Autopilot Pre-Provisioning, there is no real user logged in and with it, no LogonID is created in the FirstSync registry node.

As shown above, this is what we get when our device is undergoing Autopilot PreProvisioning.

4. The Flow

Conclusion:

The EspApplockInProcessor will check if the “best-effort” feature is enabled when enrolling our device. Enabled would indicate a willingness to proceed with the ESP phase even if certain app installations fail. It identifies applications selected in the ESP policy and marks them as having a “best-effort” feature enabled.

Applications not selected in the ESP policy but meeting specific conditions are tracked and processed during ESP. When best-effort is enabled, it treats failures as if the app installations succeeded.

The “best-effort” feature allows the ESP process to continue despite potential Application installation failures. This will give a more resilient approach to application management during the ESP phase.