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.
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.
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.
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 mapping. This is important, as it will determine how things will be evaluated from this point on.
Same thing 6 hours after the initial sync….
Finally, 8 hours after the initial sync, the Subgraph reevaluation interval will now be expired.
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.
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 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.
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.
Scenario 2
Failure exit code part of Return Codes
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 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.
It will fail again, sleep for 5 more minutes, then Execute retry #2.
Once retry #2 will fail as well, it will sleep again for 5 more minutes, and then it will Execute retry #3.
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
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?
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.
