Autopilot: Delay Win32 App Installation

In this blog, I’ll show you how to delay the installation of Win32 applications or PowerShell scripts that are set as required, making sure they only run after a certain amount of time once Autopilot enrollment is finished.

1. Introduction

Before I show you what I did to get it working, I must explain something. First, let’s examine our existing assignment option when we deploy a new app in Intune. Looking at assignments options, we have these assignment options to deploy an app to our devices

• Required
• Available
• Scheduled as required

Taking a closer look at the availability and the installation deadline, we could specify a specific date and time to install the app

As shown above, you will need to define the data at which the app will be scheduled to be installed. I want to make sure the app is installed on all devices but NOT when the device is being enrolled with Autopilot. Of course, you could define some required apps that need to be installed during ESP but that doesn’t mean other apps won’t be installed.

To make sure the app isn’t installed during Autopilot, we have got some options at our disposal.

1. You could configure the app as available so end-users could install the app on their own.

2. We could change the App availability to ensure that the app is downloaded on a specific date, but that’s not what I want.

3. You could configure a Win32app requirement rule to determine if the process: Microsoft Account Sign-in page (WWAHOST.exe) is running

You could do so by using this PowerShell Script as a Requirement rule. When WWAHost is still running, it will output False. If WWAHost isn’t running anymore, the output will be True

$ProcessActive = Get-Process "WWAHost" -ErrorAction silentlycontinue
$CheckNull = $ProcessActive -eq $null
$CheckNull

But that was not enough! I wanted to ensure that each time the device gets enrolled, the app is installed AFTER the device is working for a minimum of 1 hour.

2. The First Idea

Let’s start with my first idea. When using my Google Fu I stumbled upon this wonderful idea that Mark Thomas wrote

Targeting Intune Win32 Apps And PowerShell Scripts Based On The Enrollment Date HTMD Blog (anoopcnair.com)

This approach uses the FirstScheduleTimestamp in the Microsoft\enrollments registry key

If you didn’t write the script yourself, in my opinion, you need to play with it first to get a good understanding of what it does. So I changed it a little bit so I could understand exactly what it does and when it breaks.

After changing some little parts and playing with it, I did a test drive. As shown below it was telling me the enrolment date was 07/05/2022 8:44

Mmm, that’s quite odd… because, at that point, I was still taking a shower. The enrollment date has to be more like 10:45

Also when taking a nice good look at the IME logs it also mentions 10:46

Okay, sounds like a time difference of 2 hours. Of course, I could just add it or take a better look at the script itself, but I was wondering if there isn’t a simpler option to fetch the Enrollment date

Update: Mark Thomas mentioned that the date is stored as UTC in the registry so you need to convert it to local time by using .ToLocalTime()

3. The Second Idea

After ditching my first idea, it hit me: Why not use the creation time of the IntuneManagementExtension folder?

This folder will only be created when a device is enrolling into Intune (when you have WIn32apps/PowerShell scripts in place) We are also blocking the enrolment of personal devices to be 100% sure ONLY autopilot devices/corporate devices can be used.

This script below is just as I want it to be, simple!

$AppInstallDelay = New-TimeSpan -Days 0 -Hours 1 -Minutes 0

$ime = Get-Item "C:\Program Files (x86)\Microsoft Intune Management Extension"  | select Name,CreationTime 
$EnrolmentDate = $ime.creationtime

$futuredate = $EnrolmentDate + $AppInstallDelay


#checking date and futuredate
$outcome = ((Get-Date) -ge ($futuredate))  
$outcome

When adding a new App in Intune, you could also add a Script as a requirement rule.

After clicking on “add,fir” you will be asked to select the script file and the output data type. As shown below I selected the “Boolean” data type and made sure the “Operator” was configured to “Equals” and the corresponding “Value” to “True/yes”

After finishing the app creation, I wiped my test device and I made sure the enrollment date was correct

As shown above, the device was enrolled into Intune around 11:23 and the PowerShell script result is False

I guess we now need to wait an hour until the requirement rule is met because Intune is also mentioning the App as not applicable.

After waiting some time and rebooting the device to trigger the detection, the requirement rule was met and the app finally started installing!

4. Some important informaiton

• In this blog/example, I used a 1-hour delay to make sure I wasn’t crossing/passing the Intune sync schedule. Otherwise, we need to wait 8 hours before the device finally decides to checks in 🙂

• I am testing right now to use 1 hour and 30 minutes to determine at which time frame the apps will get installed.
• As the installation hasn’t failed or succeeded, there isn’t an exit code. Without an exit code that IS NOT zero, the GRS would kick in, but as there isn’t an exit code yet, the Global re-evaluation scheme isn’t used as it seems.

Conclusion

Sometimes, you need to delay the app installation for some hours. Hopefully, this blog will show you the options you have to do so to make sure the app ISN’T installed instantly.