Call4Cloud | MMP-C | Autopilot | Device Preparation

Autopilot: Delay Win32 App Installation

Patch My Pc | install & update thousands of apps

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
Configuring the Win32app as required app during Windows Autopilot.

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

We are missing the option to delay the installation in the installation deadline settings of the win32app

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

Graphical user interface, text, application  Description automatically generated

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.

Graphical user interface, text, application, email  Description automatically generated

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

Graphical user interface, text  Description automatically generated with medium confidence

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

Text  Description automatically generated

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?

Graphical user interface, text, application, email  Description automatically generated

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. Graphical user interface  Description automatically generated

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.

Graphical user interface, text, application, email  Description automatically generated

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”

Graphical user interface, text, application  Description automatically generated

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

Graphical user interface, text, application  Description automatically generated

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

Text, letter  Description automatically generated

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.

Your Time Starts Now GIFs - Get the best GIF on GIPHY

9 thoughts on “Autopilot: Delay Win32 App Installation

  1. I have bad experiences with the availability assignment settings. They preloaded the installers on all devices, manual installs from company portal did not work and after the deadline the install would be succesful, then failed again and kept looping. There was no fault in my detection rule. Just IME going crazy.

  2. Hey Rudy,

    Looks like we’re testing and the app is reported back as not meeting requirements, see here : <![LOG[[Win32App] Applicability is ScriptRequirementRuleNotMet for app 61028a8e-75b2-4f29-9015-7df2f468ff93, report compliance message and skip further processing]LOG]!;
    However, the actual installation kicks-in a day or so after, did you experience the same behavior?
    Thanks,
    Kind regards,
    Vasile

  3. Would it possible to devise a similar check to make sure an app is deployed only after the user has signed in for the first time? I’m sure there must be some file/folder or regkey that gets created or modified when that happens.

    1. Would you be able to look at the set of directories in C:\Users and only proceed if there is a non standard folder created?

  4. Hi,

    Is this possible to achieve once a device has a registered\activity date in Azure AD? To then install the application after these values appear?

    Thanks in advance.

  5. I see that when you got it to work you logged into a user to grab logs. I am trying to do this purely by System context, without any user logging in.

    The issue I seem to be having is that the app is showing as “Not Applicable” in the installation details (because of the delay script returning false most likely).

    Will this check ever happen again without a user logging in? I have tried syncing via the intune portal and restarting the machines a few times and the status never changes from “Not Applicable”

Leave a Reply

Your email address will not be published. Required fields are marked *

  +  24  =  33

Proudly powered by WordPress | Theme: Wanderz Blog by Crimson Themes.