Managing app installs in, and around, Autopilot
If you’ve ended up here, you are probably facing some challenges with app deployments negatively affecting Autopilot. Rest assured you are not alone; Intune and Autopilot are always documented and presented in simple terms, with just a few elegant options to choose from… but without prior knowledge we can end up tripped up in the mud and back to searching the internet for obscure terms…
“Autopilot stuck Apps (# of # installed)”,
“App install failed autopilot enrolment status page”,
“Enrolment status page timeout”,
“Why is my Win32 app installing, it’s not in the Blocking list?”.
This blog will provide some advice on the subject of managing app installs during, and after, Autopilot. This is mostly a compilation of existing guidance from Microsoft blogs, and other resources from contributors, held together loosely with some tips!
App install scenarios
Let’s start with some terminology that can help distinguish between different Autopilot app install scenarios. Some of these will be familiar, whereas you might not have come across the others for any practical reason yet:
Blocking - a list of apps that MUST install (e.g. security software) during Autopilot.
You’ve heard of a ‘Required’ app assignment, but what about my expanded selection?
Required (at any time) - apps that are required on the device, but it is not important when they are installed - it could be during Autopilot or after it (e.g. large apps that would otherwise slow down the ESP),
Required (only after Autopilot) - apps that are required but must not install during Autopilot (e.g. apps with user-interaction required, such as setting a BitLocker PIN, which would fail to display the pop-ups),
Required (only during Autopilot) - slightly rarer - apps that are required but must only install during Autopilot. This could be a scenario where you might want to deploy an app, but only to brand new devices during Autopilot, without affecting existing devices (e.g. 64-bit Microsoft 365 Apps for Enterprise),
Available - apps that the user can install from Company Portal after Autopilot has completed (e.g. Notepad ++).
Examples of app install scenarios in and around Autopilot.
Blocking
Blocking apps are critically important to the system - they are your essentials. If a blocking app fails to install it is considered as Autopilot failing; an error is thrown to the user, requiring they start Autopilot again. When you choose to make an app blocking, remember that every app in this category will add time, and chance of total failure, to your Autopilot deployment - so keep this list to a minimum.
In order to add blocking apps, toggle ‘selected’ next to ‘Block device until required apps are installed if they are assigned to the user/device’ and then add your desired apps to the ‘Blocking apps’ section of the ESP settings page:
Remember that blocking apps must also be deployed as required to User or Device Azure AD groups for them to reach devices during the ESP.
IMPORTANT - When deploying required apps (to apply during Autopilot) to dynamic Azure AD device groups be sure to consider whether the device will be a member of the group at time of Autopilot. For example, if you deploy an app to a dynamic Azure AD group with membership rules based on properties that don’t exist on the device object yet (like DeviceTrustType = ServerAd) then it won’t receive the app during the ESP because it isn’t in the group quickly enough.
Required
Required app deployments is where the nuance starts to creep in. Part of this comes from the fact that Autopilot does not only process and install apps listed as blocking, but can install any required app during the ESP. If your Autopilot process takes a while to complete you might see this in action, as many other apps begin to install in the background:
“Apps do not install in any specific order – Adding apps to your list of blocking apps for the Enrollment Status Page does not mean that only those apps will install or that those apps will install first. Additional required apps may install in the background while the Enrollment Status Page is displayed that are not included in this list.” Selecting Required Apps for your Enrollment Status Page - Microsoft Community Hub
Just as required apps can sneak onto machines during the ESP, the same is also true in reverse; if you deploy an application as required and blocking to a large group, such as ‘Autopilot registered devices’, with the intention of only reaching new devices during the Autopilot ESP, you may also be incidentally targeting existing devices outside of Autopilot. This can be a problem.
If you have a requirement to prevent apps installing during the ESP, or conversely mandate that they only install within it, you’ll need to accomplish this another way.
Required (only after Autopilot) / (only during Autopilot)
My entry point into needing these options was trying to set a BitLocker PIN wrapped up in an Intune Win32 app. You need to make sure this kind of app (that requires user interaction) doesn’t apply during Autopilot, as the popup will be hidden behind the ESP.
The solution to this problem is explored in many blogs, mostly toying around with the idea of using an Intune Requirement Script to detect the device as still being within the ESP. Having tried a few of them, I found the most reliable and up-to-date method on Oliver Kieselbach’s blog, paying particular attention to the ‘changed approach’ section:
Post ESP Intune Win32 apps installations – Modern IT – Cloud – Workplace (oliverkieselbach.com)
Using Oliver’s Requirement Script:
It will determine whether the machine is in the ESP or not by using the Defender Security Center notification icon in the system tray, [Get-Process -Name SecurityHealthSystray].
Make sure you do not have the Defender Security Center icon hidden by default… (HKLM\SOFTWARE\Policies\Microsoft\Windows Defender Security Center\Systray\HideSystray = 1)
The possible returns ‘ESP-not-active’ and ‘ESP-active’ can be used as requirement rules to accomplish either situation - apply only after Autopilot / only during Autopilot.
By adding the requirement script to my BitLocker PIN Win32 app, with ‘ESP-not-active’ as the expected output, I was successfully able to make it show as ‘Requirements not met’ during the ESP. Soon after first login, the app retried and I was successfully able to interact with the pop-up.
Which apps should be Blocking, Required, Available?
When considering which apps should be mandatory (blocking), required, or merely available in Company Portal, you need to come to a few decisions. Discuss the situation with your user experience and security teams; you are looking to strike a balance between:
Keeping Autopilot’s runtime down, and blocking list short, to reduce chances of failure,
Allowing the user to work as quickly as possible after Autopilot,
Some organisations like to have Microsoft 365 Apps for Enterprise installed during the ESP,
Others are happy to ask the user to use Office.com while waiting for Microsoft 365 Apps for Enterprise to install later as a Required (at any time) app,
Creating a secure environment as soon as possible, with all the necessary security tools installed.
Additional guidance on the importance of selecting the right Required apps for Autopilot ESP: Selecting Required Apps for your Enrollment Status Page - Microsoft Community Hub