Autopilot: Delay Win32 App Installation

In this blog, I’ll show you how to delay app installations or PowerShell scripts that are set as required, ensuring they only run after a certain amount of time has passed once Autopilot enrollment is complete.

1. Delay App installation

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 assignment 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 and possibly delay the app installation.

As shown above, you will need to define the data on 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.

Please Note: This should be resolved and shouldn't give this behavior!

To ensure the app isn’t installed during Autopilot, we have several options available.

1. You can configure the app to be available, allowing end-users to install it on their own.

2. We could change the app’s availability to ensure it’s 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 is enrolled, the app is installed after the device has been working for a minimum of 1 hour.

2. The First Idea: Delay Apps

Let’s start with my first idea. When using my Google Fu, I stumbled upon this wonderful idea that Mark Thomas wrote to delay apps during Autopilot Enrollment.

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 making a few minor adjustments and experimenting with it, I took it for 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 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 enrollment of personal devices to be 100% sure that ONLY autopilot devices/corporate devices can be used.

The 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 delayed app was finally started installing!

4. Some important information

• 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 currently testing to determine the optimal time frame for installing the apps, which will take approximately 1 hour and 30 minutes.
• As the installation hasn’t failed or succeeded, there is no 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 app installation for some hours. Hopefully, this blog will show you the options you have to prevent the app from being installed instantly.