Intune Win32 apps: A Strategic Guide to Availability and Deadlines

Introduction

Throughout the years I’ve had to deploy a lot of apps and updates to the devices I manage. I used both Configuration Manager and Microsoft Intune. One of my favorite things about Configuration Manager was the ability to configure deployments with an available date and a deadline date. Whatever you deployed would show in the Software Center for the “available” period, and the user could initiate the installation themselves. If they didn’t, once the deadline date was hit, your deployment was enforced automatically.

With Intune, assignments can also be pushed with an available and deadline date configured. The caveat here is that required assignments, regardless of their scheduling, will not be shown in the Company Portal in the same way deployments used to show in the Software Center. In some cases, this can cause confusion.

In this blog post we are going to deploy an Update for Google Chrome win32 app, as required, to a device. We will also look into four different assignments scenarios with different scheduling.

The purpose of the assignment will be Install. The scenarios are:

• Scenario 1 – Win32 app is assigned with both available and deadline date set to ASAP.
• Scenario 2 – Win32 app is assigned with an available date ASAP, but the deadline X days later. The Google Chrome version is NOT already installed on the targeted device.
• Scenario 3 – Win32app is assigned with an available date ASAP, but the deadline X days later. The Google Chrome version is already installed on the targeted device.
• Scenario 4 – Win32app is assigned with an available date 1 day later after the configuration date. The deadline will be set to ASAP after the available date.

I’m a fan of Sherlock Holmes – movies, books, you name it. Up next, I’m going to put on my Deerstalker hat on and investigate the logs for each scenario. Let’s see how Intune handles the various scenarios.

To understand what happens on the client side, we are going to review the Intune Management Extension (IME) and AgentExecutor log files.

Note: If you’re not familiar with where these logs, they reside on the client side in %ProgramData%MicrosoftIntune Management Extension\Logs

If you are new to managing win32 apps in Intune, below you can find some introductory information. If you are an experienced admin, you can skip to the Four Scenarios below.

What are Win32 apps?

Intunе Win32 apps arе a handy tool in Microsoft Intunе that allow organizations to еasily install, control, and kееp track of rеgular Windows softwarе on thеir dеvicеs. This hеlps еnsurе that all thе softwarе usеd in thеir IT sеtup compliеs with thеir rulеs and stays up to datе. It’s a way for IT folks to еfficiеntly handlе thе softwarе on company computеrs.

Win32 apps offer a lot more flexibility and control over the software you deploy compared to the apps from the Microsoft Store, for instance. You can find more information about win32 apps, here.

How to create a win32 app in Microsoft Intune?

A summary of the process is:

1. Prepare your Windows app
   • Make sure you have the app setup file (EXE or MSI).
   • Create your custom PowerShell scripts to define pre or post-installation behavior.
   • Ensure the software installs with the desired behavior. You can manually run the install and scripts from a command prompt.
2. Create your app package file in the Microsoft Intune Admin Center
   • Download the win32 content prep tool. It is needed to convert your windows app to the IntuneWin format.
   • Go to the Microsoft Intune website and log in.
   • Find your way to “Apps” and then “Windows” and click on “Add” followed by “Windows app (Win32)”. Upload the file you converted to .intunewin format.
3. Set up how your app gets installed
   • Further configure your win32app. Enter app details – title, icon, description. Provide the install command, as well as the uninstall one.
   • Specify the detection method for your app. The detection method rules make sure Intune detects the software when it’s installed. For MSI based apps, the MSI product code can be used.
   • Decide whether the app should be assigned to users or devices.
4. Deploy your app
   • Assign the app to a group of users or devices.
   • Set a deadline for when the application should install on your windows pc(s).

How do I deploy a win32 app with Microsoft Intune?

Once the win32 app is created, all you have to do is assign it. There are multiple settings you can define with your assignment, such as: Required, Available, or Uninstall assignments. You’ll also be able to schedule when the assignment should take place.

The Four Scenarios

Back to the task at hand: deploying an Update for Google Chrome win32 app as required, to a device.

Scenario 1: Win32 app is assigned with both available and deadline date set to ASAP.

In this scenario we are going to deploy a win32 app with both the available and deadline date set to ASAP.

The Intune Management Extension log reveals that, once the win32 apps are evaluated, it gets the policy for our Update for Google Chrome.

In the Get Policies log line, we’ll find StartTime Date, as well as a Deadline Date. They are both timestamps and have the same negative value:

• StartTime: -62135596800000 (UTC timezone)

• Deadline: -62135596800000 (UTC timezone)

These values do not make a lot of sense, not to us humans anyway. Let’s see if we can get these into a more human-readable DateTime format.

To convert them from the milliseconds timestamp, we will use a PowerShell script. In that script, we will use “1970-01-01 00:00:00” as a date and time reference. This reference is known as the Unix Epoch – a fixed point in time that is commonly used for timestamps in computing. We can determine the time that has elapsed since that starting point.

Here is the PowerShell script that will help us convert the timestamp:

# Define the miliseconds strings
$startTimeTimestamp = '-62135596800000'
$deadlineTimestamp = '-62135596800000'

# Convert the timestamps to DateTime objects
$startTime = (Get-Date "1970-01-01 00:00:00").AddMilliseconds($startTimeTimestamp)
$deadline = (Get-Date "1970-01-01 00:00:00").AddMilliseconds($deadlineTimestamp)

# Display the results
Write-Host ("Start Time: {0}" -f $startTime)
Write-Host ("Deadline: {0}" -f $deadline)

The results are in:

The date and time 1/1/0001 12:00:00 AM represents the earliest representative date in programming environments.

Although not universally supported in all programming languages, in many Microsoft-based systems this is the commonly used way of representing the earliest date.

Based on those results, Intune will know that whatever the current date might be, it should immediately enforce our Chrome update. Therefore, it will download the content and install it.

As simple as that. Garçon, next scenario, please!

Scenario 2: Win32 app is assigned with an available date ASAP, but the deadline X days later. The Google Chrome version is NOT already installed on the targeted device.

This time we’ll have our win32 app assigned with an available date asap, but the deadline X days later. The latest Google Chrome update is NOT already installed on the targeted device.

We know what we are looking for now, so let’s jump to the log file. It reveals:

• Start time: 1692835200000 (UTC timezone)

• Deadline: 1693008060000 (UTC timezone)

NOTE: The win32 app assignment was configured in UTC time. Assignments can be configured in:

• UTC time

• Device Local time

My device is in the Mountain Time (US &Canada) timezone. Therefore, August 26th, 2023 12:01:00 AM UTC equals August 25th 6:01:00 PM device time.

In this particular case, the deadline is set for two days after the start date. However, if we scroll down, we’ll find something interesting.

Although the deadline is not hit, Intune will still run detection.

Because the version we deployed is not installed, it will be detected as such. Despite the deadline not being hit, the content is still downloaded in the cache.

The content will be downloaded after the available date.

NOTE: My content delivery optimization was set to be done in the background for this assignment.

Once the deadline arrives the installation of our update will take place using the pre-cached content it downloaded when Intune first evaluated this win32app.

Success! A few seconds later our update for Chrome is finally detected:

Scenario 3: Win32app is assigned with an available date ASAP, but the deadline X days later. The Google Chrome version is already installed on the targeted device.

This time we’ll have the win32 app assigned with an available date asap, but the deadline X days later. The latest version of Google Chrome is already installed on the targeted device. Here is my assignment configuration for this scenario:

Again, let’s take a look at the IME log and see what happens this time and how our Intune Win32 app for the Google Chrome update is evaluated:

Same story as the first two scenarios: the policy is retrieved. Let’s convert the time stamps using our PowerShell script (defined above in Scenario 1). Here is the Terminal output:

We’ll get our configured assignment scheduled for this our win32 app. But if we scroll more, we’ll see Intune running the detection anyway, despite the deadline not being hit!

Because the latest version is already installed on this device it is, of course, detected.

While this is accurate, it can cause confusion. Because the deadline was configured for two days later, it might give the false impression that the schedule was not respected by Intune.

Scenario 4: Win32app is assigned with an available date 1 day later after the configuration date. The deadline will be set to ASAP after the available date.

For our final scenario, the Google Chrome win32 app is assigned with an available date 1 day later after the configuration date. The deadline will be set to ASAP after the available date.

I’m sure you know the drill by now. Let’s take a look at the IME log file to see the values:

And, just to confirm our deployment schedule, if we convert the timestamp values with our PowerShell script (from Scenario 1) again we find:

Based on the previous scenarios, after August 19th, 2023, 11:00 AM device local time we should see:

• The content being downloaded, as the assignment is going to be past the Available Date.

• Then immediately installed, as the deadline date is in the past.

NOTE: My content delivery optimization was set to be done in background for this assignment.

And that’s exactly what happened, as revealed by the Intune Management Extension log in the 2 screenshots above.

Key takeaways

Let’s do a quick summary of the plentiful information discussed above:

• For any ASAP assignments, Intune sets the date to January 1st, 0001. It will thus ensure that whatever today’s date is, the assignment will take effect.
• If the content delivery optimization is set to be done in Background, the win32app’s content will be downloaded after the Available date.
• If you deploy an app with a Deadline date, Intune will run detection after the Available date.
  • If your application is already installed, it will Detect it and report it. This could cause confusion by making IT engineers think that the Deadline was not respected.