Intune Win32 app deployment: the parts that actually break

Intune Win32 app deployment has one property that makes it harder to debug than it looks: the install usually works, and the reporting usually disagrees. A device runs the installer, the software appears under Program Files, and the admin centre still says Failed or Pending. The install command is rarely the fault. Detection logic, execution context and a log file that no longer holds the answer account for most of it. Every fact below was verified against Microsoft Learn on 11 September 2026.

None of it happens without the agent. Win32 content is downloaded, unpacked and executed by the Intune management extension, which Microsoft installs automatically the first time a PowerShell script or a Win32 app is assigned to a user or a device. A tenant with neither has no agent anywhere, and a device that never received one reports nothing rather than reporting a failure.

What Intune Win32 app deployment actually reports on

The installer exit code is not the app state. Intune decides whether an app is installed by running the detection rules, and the detection result is what the console shows. An installer can return 0, write every file it was meant to write, and still leave the app sitting at Failed because the rule that was supposed to find it looked in the wrong place.

Two behaviours in Microsoft’s guidance on adding and assigning Win32 apps to Intune matter more than the rest. The conditions for all detection rules must be met, so three rules are an AND and not an OR, and adding a second rule to catch an edge case quietly narrows the match instead of widening it. And when Intune detects that the app is not present, it offers the app again within approximately 24 hours, for required assignments only. That second behaviour is why a broken detection rule looks like an install loop: the device reinstalls a piece of software it already has, once a day, indefinitely.

The detection script rule that costs the most time

A custom detection script is judged on three channels at once. The app counts as installed when the script exits with 0 and writes a string to STDOUT. If any data reaches STDERR, the result is evaluated as not installed, even when the exit code is 0 and STDOUT has data. Microsoft states this plainly, and it is the single most expensive line in the documentation, because a non terminating error record from a cmdlet you did not think about is enough to poison an otherwise correct script.

Microsoft also recommends encoding detection scripts as UTF-8 BOM. A script that works in the ISE and fails on the client is usually an encoding problem rather than a logic problem.

1# Detection script. Intune reads three things: the exit code, STDOUT and STDERR.
2# Exit 0 with data on STDOUT means installed. Anything on STDERR means NOT
3# installed, even with exit code 0 and data on STDOUT.
4$target = "7.4.1"
5$exe    = "C:\Program Files\Acme\Agent\acme.exe"
6
7# -ErrorAction Stop keeps a non terminating error off STDERR. Silencing it is
8# not cosmetic here: a stray error record marks the app as not installed.
9if (-not (Test-Path -LiteralPath $exe)) { exit 1 }
10
11$found = [System.Diagnostics.FileVersionInfo]::GetVersionInfo($exe).FileVersion
12$found = $found.Trim()
13
14if ([version]$found -ge [version]$target) {
15    Write-Output $found
16    exit 0
17}
18
19exit 1

32 bit and 64 bit context, in four separate places

The same choice appears four times in a single app definition, defaults to 64 bit in three of them, and defaults to 32 bit in the one that catches everybody. Calling powershell.exe in the install or uninstall command launches a 32 bit PowerShell instance. To force the 64 bit host, Microsoft’s documented path is %SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe.

Set the install command and the detection rule to the same bitness on purpose. Most detection failures that survive a rewrite of the script are a mismatch between these two, not a fault in either one.

The numbers that decide your packaging

These are the documented limits as they stand today. They are worth knowing before you design a dependency chain rather than after, because two of them are graph limits and they are counted in a way that is easy to breach by accident.

Microsoft’s Win32 app management overview for Intune carries the size cap and the prerequisites. Note that the Intune documentation was reorganised earlier this year: the old /intune/intune-service/apps/ paths now return a 301 to /intune/app-management/deployment/, so most third party guides on this subject are still linking through a redirect.

Read the right log

Agent logs live in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs. The advice to open IntuneManagementExtension.log and search for the app name is now wrong, and it is wrong in the worst way, because the search succeeds and returns nothing. Microsoft’s Win32 app troubleshooting reference lists AppWorkload.log as the main app workload log, covering app check ins, app installs, applicability and detection. IntuneManagementExtension.log is now agent check in, policy request, policy processing and reporting.

1# Win32 app activity is in AppWorkload.log, not IntuneManagementExtension.log.
2# Searching the old file for an app name returns nothing on a current agent,
3# which reads exactly like an app that was never targeted.
4$logs = "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs"
5
6Get-ChildItem -Path $logs -Filter "AppWorkload*.log" |
7    Select-String -Pattern "Acme Agent" -Context 0,2 |
8    Select-Object -Last 40

One configuration item belongs with the logs because it produces failures that look like nothing else: antimalware scanning of the content folders. Microsoft asks for C:\Program Files (x86)\Microsoft Intune Management Extension\Content and C:\windows\IMECache to be excluded, and on x86 clients the same Content path under Program Files. A scanner holding a file open during extraction produces intermittent, machine specific failures that never reproduce on the test device.

The failure modes

Nearly every Intune Win32 app deployment problem that reaches a service desk is one of nine things, and the symptom rarely names the cause. The column on the right is what to check first, not the only possible explanation.

What I would do differently

My tenant is a lab with no enrolled devices, so I have not measured install success rates across a fleet and I am not going to pretend otherwise. What follows is judgement about design, and the documentation is the source for the mechanics.

Design the detection rule before the install command. The install command is usually decided by the vendor and takes ten minutes to find. The detection rule is the part you own, it is what the console reports on, and it is where almost all of the wasted time goes. Write it first and the rest of the app definition falls out of it.

Use one detection rule where one will do. The AND semantics mean each additional rule is another thing that can be false. A single file version check against the binary the product actually ships is more robust than a file check plus a registry check plus a script.

Prefer version comparison over equality. A rule that matches exactly one version reports every device on a newer build as not installed, and then reinstalls the older one over the top of it every day.

Keep dependency graphs shallow. The 100 app limit is counted across shared graphs, and a dependency relationship also blocks deletion of both apps until it is removed. Two levels is manageable. Four is a structure nobody will want to unpick in a year.

Raise the install timeout for anything that touches the internet during setup. The default 60 minutes is comfortable on a wired pilot device and marginal on a home connection, and the resulting failure is indistinguishable from an installer fault.

Last verified: 11 September 2026.