The Ballad of Buster ExitCode’s

In one of my earlier blogs, I was talking about how the IME installation flow, and how the global retry schedule was working. I showed you how the retry schedule looks at the ExitCode to determine if the app was installed successfully or not.

Troubleshooting failed Intune Win32 Apps installation | IME (

Trigger IME to retry to install a failed Win32app | Intune (

I decided to remove the “ExitCode” part of those blogs and dedicate a separate blog to it. I will divide this blog into multiple parts

  1. The ExitCode
  3. File/Registry Detection Rule
  4. MSI Detection rule

1. The ExitCode

If you have read that other blogs you know by now how we could trigger the reinstallation. If you understand how the installation flow works it becomes way easier to look at some Win32 Installation issues. Let’s take a look first at, the Win32app installation ExitCode

This exit code from the above picture will be used to determine if the Win32App has been installed successfully. When looking at the Win32App installation flow, you will notice that this is done at the Post Detection Phase as I showed you earlier.

But besides the important ExitCode itself how does it detect if the Win32App has been successfully installed? It all depends on how you configured your detection rules while you uploaded your nice Win32App!

There are many options to choose from, MSI, Registry, File/Folder, or just your own custom-cooked PowerShell script to detect the app after and before installation.


As shown above, there are multiple detection rules available. I will start with the PowerShell Detection Rule first.

When looking at detection rules and a custom PowerShell script the STDOUT comes into play. First, let’s take a look at how the STDOUT looks inside the IME log when the install fails

LOG[[Win32App] Checked Powershell script exitCode: -1 EnforceSignatureCheck: 0 RunAs32Bit: 0 InstallExRunAs: 0, result of applicationDetected: False]

When the app is installed the Intune Agent will check the results/exit code from the script. The Intune agent will read the values that were written to the STDOUT stream. When the PowerShell detection script exits with everything EXCEPT a nice zero value, the script will fail and the Win32 App will be marked as not detected.

If the PowerShell script exists with a nice zero value (0) everything is okay and the Win32 App will get marked as detected and installed. But if the script exits with 1, everything is NOT okay! When this exit code 1 is given when using proactive remediations, the remediation part will kick in

3. File/Registry Detection Rule

Now we have seen the ExitCode, and the STDOUT, let’s take a look at the File and registry Detection Rule. That’s somehow a little bit easier… it just checks if the path exists you configured in the detection rule.

For example, a simple File-Based detection rule to make sure OneDrive (x64) is detected after installation

After the installation, it will check the path you configured in the detection rule if it exists.

The same goes for the Registry detection rule. In this example, I have configured a Registry detection rule to detect if the Office 365 Apps are installed

You could wonder why I used this example. I decided to use a Win32App to deploy the Office365 Apps to our devices

Deploy the Office 365 Apps in Intune with a Win32App (

If it detects the file path successfully it will save the Installation Status Service report in the registry:


As shown above, the Win32App is successfully detected and the ErrorCode will be zero

4. MSI Detection Rule

It is always best practice to convert your MSI to a Win32App because mixing those could lead you into trouble. When you want to make sure your MSI converted to a Win32app is detected successfully you could also use the MSI detection rule. As shown below I am using the Teams MSI product code as example

It’s very easy to found out the MSI Product code on an existing device by using PowerShell

$Installer = New-Object -ComObject WindowsInstaller.Installer; $InstallerProducts = $Installer.ProductsEx("", "", 7); $InstalledProducts = ForEach($Product in $InstallerProducts){[PSCustomObject]@{ProductCode = $Product.ProductCode(); LocalPackage = $Product.InstallProperty("LocalPackage"); VersionString = $Product.InstallProperty("VersionString"); ProductPath = $Product.InstallProperty("ProductName")}} $InstalledProducts

If you want to fetch the MSI product code from a not installed app, you could use the Applocker File information command.

Get-AppLockerFileInformation -Path 'c:\install\supportcenterinstaller.msi' | select -ExpandProperty Publisher | select ProductName,BinaryVersion,BinaryName


Knowing where to look for the Win32App ExitCode is very important as it could tell you a lot about how the installation itself and if it was successful or if it didn’t work!

It Did Not Work Not Working GIF - It Did Not Work Not Working Failed -  Discover & Share GIFs

Leave a Reply

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

1  +    =  10