Patch Tuesday Blog | Tech Blog

Win32app Retry Interval – Demystified

By Liviu Barbat

Intune has been out in the wild for quite a few years now. Several IT Admins are using win32apps to get various software installed on their devices. Microsoft actually recommends the use of win32apps exclusively. However, when it comes to the installation failure of win32apps, the IntuneManagementExtension.log (IME) file and its retry schedule are still a tough nut to crack for many of us. In this blog post, we will test some scenarios where an application will fail with the same exit code, on the same device, but based on configuration, Intune will retry the installation on different intervals. This article will focus solely on the IME log file, although, when it comes to win32apps, ReevaluationScheduleManager, GRS, valuable information can also be found in the registry and Task Scheduler as well.

Key Takeaways

For these tests, we will:

  • Use the Patch My PC Publisher to create a win32app (Notepad++), and configure it to Manage a Conflicting Process.
  • Assign the app as Required to a test device.
  • Have a test device which will run non-stop, in order to not alter any results. Also, an older version of Notepad++ will be running on that device. By managing a conflicting process, and letting the installation time out, we will force the installation to fail with an exit code of 1602.

In case you are interested what this exit code translates to, the answer is “the user cancelled the installation”.

NOTE

We used the 1602 code as it is a common exit code to encounter. Other popular exit codes are 1603, 1612, 1624, and so on. View other popular exit codes at Microsoft.com

We will test 2 scenarios:

In the first scenario, we simply create the app and assign it as Required, and let it run to see what the Intune Management Extension (IME) log will tell us about the retry interval.

The Internet doesn't work

In the second scenario, we will edit the win32app program exit codes, add 1602, and mark it as Retry. We will then monitor the log again to see if the IME will behave differently.

The Internet doesn't work

Scenario 1

Failure exit code not part of the Return Codes

As mentioned in the Key Takeaways, in this first test, we simply let PMPC create the app, and we assigned it as Required to our test device.

Let’s open the IME logs and the PatchMyPCScriptrunner log to see what happens.

The Internet doesn't work

When the policy for this app is checked for the first time, the ReevaluationScheduleManager will inform us that it did not find any previous check-in time and that the Subgraph reevaluation will be treated as expired.

This means that this is the first time this app is evaluated, therefore the Intune Management Extension (IME) will attempt the installation. It will also set the Subgraph Reevaluation value at the time it’s currently being evaluated. IME will compare the date and time specified in the entry log, to see when it should retry the installation.

In our case, we can see that the log ran at 8:32:39 AM (device local time), but the subgraph reevaluation value was set at 2:38:39 PM (UTC). It’s important to note the different time zones to avoid confusion.

If we scroll down a bit, we will see that the PMPC ScriptRunner attempted the installation, but that it failed with exit code 1602. IME will then immediately pick this up and will return that there was an Error with IpExitCode: 1602 without mappingThis is important, as it will determine how things will be evaluated from this point on.

The Internet doesn't work
If we scroll some more, the log will tell us the previous evaluation check-in time. Microsoft sets this initially to 1/1/0001 12:00:00 AM so when the assignment is evaluated for the first time, it will compare against that date and time, the Subgraph re-evaluation will be expired no matter what, and the installation will occur. Given that it failed, it sets a new evaluation time, 8 hours later the same day (10:38:32 PM UTC). This is expected behavior, as described on learn.microsoft.com. IME will still run a sync every hour, by default, unless a sync is forced manually. When the sync runs, it will evaluate the win32app anyway, but the interval will not expire, until 8 hours later, when the evaluation time for the app is set.
The Internet doesn't work
If we are to look further down in this log file, we can see that the ReevaluationScheduleManager is running again 1 hour later, when the IME sync takes place (see screenshot below). This is when it will check whether the current run time is past the check-in time set earlier. We will also notice that the Subgraph reevaluation schedule is not expired.
The Internet doesn't work
Same thing 2 hours after the initial sync….
The Internet doesn't work
Same thing 3 hours after the initial sync….
The Internet doesn't work
Same thing 4 hours after the initial sync….
The Internet doesn't work
Same thing 5 hours after the initial sync….
The Internet doesn't work

Same thing 6 hours after the initial sync….

The Internet doesn't work
Same thing 7 hours after the initial sync….
The Internet doesn't work

Finally, 8 hours after the initial sync, the Subgraph reevaluation interval will now be expired.

The Internet doesn't work

From the screenshots above, we can tell that the ReevaluationScheduleManager did run every hour, and it always logged that the Subgraph reevaluation schedule is not expired, until 8 hours later, when it finally did.

Ok, so what happens now?

If we scroll a bit more, the IME log will inform us that the installation was attempted in the last 24 hours and there is no need to execute the installation now, just 8 hours later.
It will also tell us our application is still in GRS (Global Retry Schedule). The GRS start time will be the time the installation was attempted for the first time, at 2:38:41 PM UTC.

The Internet doesn't work
As we can see in the screenshot above, in the 2 bottom lines, highlighted in pink, the ReevaluationScheduleManager will reset its next check-in to the 8 hours from the current time, in UTC again:
The Internet doesn't work
From here on out, it will be familiar territory. The check-in time will be evaluated every hour, compared against the new UTC time reference (9/25/2022 6:38:37AM). 8 hours later, the check-in time will expire, GRS will be evaluated again, it will still not be 24 hours after the initial install attempt took place, so things will keep on repeating.
NOTE
If the IME sync is running 8 hours later, but with just a few seconds earlier than the full 8 hours, the check-in time will NOT be expired, so we will see IME check GRS only 9 hours later
The Internet doesn't work

The lines in the screenshot above are telling us that the IME log is running at 12:38:32 AM (6:38:32 AM UTC). However, earlier we saw that the next check-in was set to 6:38:37 AM UTC). Therefore, the subgraph reevaluation schedule interval is not expired, as it ran a few seconds too soon. Talk about timing, huh? 😊

Another hour later, the subgraph reevaluation schedule will then be expired, once more, it will find that it ran in the last 24 hours, so our app is still in GRS.

The Internet doesn't work
IME will then rinse and repeat, as the consistent fellow that it is. Finally, 24 hours later, GRS will be expired. Then, and only then, will the installation of our Notepad++ app be attempted again.
The Internet doesn't work
From this point forward, the installation continued to fail with the same exit code again and again. The same behavior re-occurred for the next 7 days, when I stopped my test.

Scenario 1 – Summary

Now that we have tested our first scenario completely, let’s make a Summary of it.
When an installation fails with an exit code which is not defined in the program details of our app in Intune, the retry will be only attempted 24 hours later.

The Internet doesn't work
The ReevaluationScheduleManager will check every hour to see if the subgraph check-in is expired. Every 8 hours, IME will check if the app is still in GRS. Based on timing, the retry will be made 24 hours later. It could also take place 25 or 26 hours later, as specified earlier. Therefore, in such a case, unless a retry is manually forced by fiddling with registry, Intune will retry the install every day.

Scenario 2

Failure exit code part of Return Codes

Now that we have seen what happens if we don’t manage the exit code, let us re-create the app, but this time, manage the exit code, so that Intune will know to retry if anything fails with 1602.
The Internet doesn't work

Once assigned, let us see what the IME log has in store for us.

As in Scenario 1, when it evaluates the Subgraph for the first time, it treats it immediately as expired. That way the app install would be attempted.

The Internet doesn't work

The installation was indeed attempted, but this time, the IME log simply says that the lpExitCode is 1602, as we can see in the screenshot below. As a reminder, in Scenario 1, the log entry was Error with IpExitCode: 1602 without mapping.

Therefore, IME now simply sets itself to sleep for 5 minutes due to our win32app. Once the 5 minutes are passed, the entry will show us that it will Execute retry #1.

The Internet doesn't work

It will fail again, sleep for 5 more minutes, then Execute retry #2.

The Internet doesn't work

Once retry #2 will fail as well, it will sleep again for 5 more minutes, and then it will Execute retry #3.

The Internet doesn't work
When this fails as well, it will not retry anymore. IME will only set a new evaluation check-in time, and from here on out, it’s Scenario 1 all over again, where it will retry every 24 hours.
The Internet doesn't work

Scenario 2 – Summary

Given that we just completed the test for our Scenario 2, let’s make a summary of it.

If the Exit Code is specified in the program details of a win32app to Retry, if the installation fails, Intune will retry the installation for a maximum number of 3 times, every 5 minutes.

If the installation will not complete successfully after the 3 fast retry attempts, then it will only retry every 24 hours, as the win32app will then enter GRS.

Bonus – Scenario 3

notepad++_failed_attempts

In our second test scenario, we have set the program exit code to be considered as a Retry. What if we specifically set it to be considered as failed?

notepad++_failed_attempts

The answer to that question is simple. We will have the same results as in Scenario #1.

Overall Summary and Flow Chart

If the program of an Intune app has an exit code specifically set to be considered as Failed, or is not specified at all, on the client side, the installation will retry every 24 hours.

A big difference can be seen when it comes to the retry interval, if the exit code is specifically set to be considered as Retry in the Return codes of an app, then the installation will be retried for 3 times, every 5 minutes. If Intune will fail to install the application in those attempts, according to the GRS, the install will retry every 24 hours.

It is also important to note that there are ways to force the installation to retry sooner than the 24 hours (even required assignments), but this article focused on the IME default behavior.

Finally, to make the entire process easier to visualize, the following flow chart should help in that regard.

The Internet doesn't work

Liviu Barbat

Liviu is a Romanian IT professional, with a passion for sharing his knowledge on ConfigurationManager and Intune with the community. His IT journey started with supporting the ConfigMgr Team to package applications and later became an ConfigMgr Admin. Afterwards he worked with Intune, managing Windows, MacOS, iOS, and Android devices. He currently works for Patch My PC as a Customer Success Engineer.

Liviu regularly blogs on his own website, liviubarbat.info.

Tech Blog

How to use PowerShell to install Windows updates & ensure long-term compliance

In this post I will walk you through how to install Windows updates and report on patch compliance using Windows PowerShell. We will be using:...

Mastering ConfigMgr Client Actions

In this blog post, we’ll take a deep dive into the various SCCM client actions, including when to use them, what they do, and which log files...
How to use Dynamic Azure AD Groups and Filters to Improve Targeting Feature Image

How to Use Dynamic Azure AD Groups and Filters to Improve Targeting

Creating Dynamic Groups in Azure AD is a helpful way to automatically add and remove members to a group. However, when using those groups for...
Update offline configuration manager environments January 2023 tech blog feature image

How to update Offline Configuration Manager Environments – Faster

If you've ever had a Patch My PC demo call or watched a Patch My PC video you've probably seen the Patch My PC demo environment. What you might not...

Writing a Better Network Tester

There are few things more frustrating in IT than troubleshooting weird network problems. Especially when those weird network problems, impact...

MEM Patching Optimizer (Project-Clippy)

MEM Patching Optimizer is a free tool from Patch My PC that helps analyze your WSUS & ConfigMgr environment for known issues and provides...

Getting started with Microsoft Graph and Win32apps

Have you have been using Intune for a while now, getting to grips with the cool features and “nuances”, and are now ready to dive a little bit...

How to use PowerShell to install Windows updates & ensure long-term compliance

In this post I will walk you through how to install Windows updates and report on patch compliance using Windows PowerShell. We will be using:...

Mastering ConfigMgr Client Actions

In this blog post, we’ll take a deep dive into the various SCCM client actions, including when to use them, what they do, and which log files...

How to Use Dynamic Azure AD Groups and Filters to Improve Targeting

Creating Dynamic Groups in Azure AD is a helpful way to automatically add and remove members to a group. However, when using those groups for...

How to update Offline Configuration Manager Environments – Faster

If you've ever had a Patch My PC demo call or watched a Patch My PC video you've probably seen the Patch My PC demo environment. What you might not...

Writing a Better Network Tester

There are few things more frustrating in IT than troubleshooting weird network problems. Especially when those weird network problems, impact...

MEM Patching Optimizer (Project-Clippy)

MEM Patching Optimizer is a free tool from Patch My PC that helps analyze your WSUS & ConfigMgr environment for known issues and provides...

Getting started with Microsoft Graph and Win32apps

Have you have been using Intune for a while now, getting to grips with the cool features and “nuances”, and are now ready to dive a little bit...