Last Updated on August 10, 2022 by rudyooms
This blog will show you how you could make sure some specific applications or PowerShell scripts that are configured as required are delayed so they will only be run AFTER at least a specific time frame. I decided to write this blog after getting a PM on Twitter asking if it was possible to delay App installations.
I will divide this blog into multiple parts
Before I am going to show you what I did to get it working I will need to do some explanation. First, let’s take a look at the existing assignment option we have when we are deploying a new app in Intune.
Looking at assignments options, we have these assignment options to deploy an app to our devices
*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 is going to 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 make sure 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 which was written by Mark Thomas
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 just hit me! Why not just 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” 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 isn’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
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
7 thoughts on “Autopilot Is Mine, All Others Pay Time”
great post as usual !
Super cool! I bet I’ll need it in the future.
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.
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?
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.
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?