Autopilot: Only fail selected blocking apps in technician phase.

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 read this blog.

This blog will explain everything you want to know about this new ESP function called “Only fail selected blocking apps in technician phase.”

1. Introduction

On 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 that we configure in the ESP. This option is called: Only fail selected blocking apps in technician phase”

If you think that sounds familiar, yep!! It does sound familiar because this feature was already 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 blocked in the ESP policy, the system will make 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 test this new feature, 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 AppLockIn Processor 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 “Only fail selected blocking apps in technician phase” feature brings a more forgiving ESP flow. It ensures only the apps marked as blocking will cause the technician phase to fail. All (yes all!) other required apps are treated with best effort, if they fail, ESP still moves on. This helps reduce unnecessary failures and speeds up Autopilot provisioning