Intune Win32 App Not Installing on One Device: Check Assignment Filters Before Repackaging

A Windows app that installs everywhere except one device creates a tempting packaging diagnosis. Administrators often rebuild the .intunewin file, change the install command, or replace detection rules before checking whether the device was ever eligible for the assignment.

That order is backwards when the affected device has no meaningful install activity in the Intune Management Extension logs. An assignment filter can narrow an app assignment by device properties, or exclude matching devices. The result is a targeting problem, not an installer failure.

This runbook shows how to prove which boundary failed and when to change the assignment instead of the package.

Quick fix checklist

Confirm the app assignment targets the affected user or device group.
Open the assignment and record whether the filter mode is Include filtered devices or Exclude filtered devices.
Compare the filter properties with the affected device’s current OS version, manufacturer, ownership, and other properties used by the rule.
Check the app’s Requirements separately. A device can pass the assignment filter and still be not applicable because a requirement rule fails.
Review C:\ProgramData\Microsoft\IntuneManagementExtension\Logs for the app and the policy evaluation time.
Only after eligibility is proven, investigate the install command, detection rule, install context, and return code.
Sync one test device and confirm that the assignment result changes before broadening the production assignment.

For a structured second pass, use the free Intune App Failure Analyzer. It is a browser-based, client-side beta. It accepts error codes, install commands, detection rules, install context, registry view, and IME/AppWorkload logs. It does not replace the Intune assignment view: paste the exact targeting evidence and verify every conclusion against the device and Microsoft documentation.

The symptom that points to targeting

Treat these as targeting clues rather than proof of a broken installer:

the same package installs on comparable devices;
the affected device does not appear in the app’s device installation status;
there is no download or install attempt for the app in AppWorkload.log;
the device recently changed ownership, OS version, manufacturer record, or enrollment state;
changing the assignment group appears to help without changing the package.

The obvious diagnosis can be wrong because “not installed” does not mean “installer failed.” Intune evaluates assignments and applicability before it runs the Win32 install command. A filter mismatch can prevent the app from reaching the installation stage at all.

How Include and Exclude filter modes change the result

Microsoft documents two assignment filter modes:

Include filtered devices in assignment: devices matching the filter receive the app assignment; devices that do not match do not receive it.
Exclude filtered devices in assignment: devices matching the filter do not receive the app assignment; devices that do not match remain eligible for the assignment.

The same filter expression therefore has opposite operational meaning depending on the mode. Read the mode and expression together. Do not infer behavior from a filter name such as Windows 11 pilot or Exclude kiosks.

For example, a filter such as:

(device.manufacturer -eq "Contoso")

in Include mode intentionally limits the assignment to matching devices. In Exclude mode it removes matching devices from the assignment. A device with a stale or unexpected manufacturer value can land on the wrong side of either rule.

Step 1: prove that the device is in the assignment scope

In the Intune admin center, open Apps > All apps > the Windows app > Properties > Assignments. Record:

the group and assignment intent;
whether the group contains the user or device;
any assignment filter;
the filter profile type, such as managed devices;
the filter mode;
the filter expression and its properties.

Then check the affected device in Devices > All devices. Compare the properties used by the filter. Microsoft describes assignment filters as dynamic targeting based on properties such as OS version, manufacturer, and ownership. A group membership check alone is not enough when a filter is attached.

Do not use a portal screenshot as the only evidence. Record the exact expression and the current device property values in the incident notes so a later inventory refresh can be distinguished from a real assignment change.

Step 2: separate assignment filters from app requirements

Passing the assignment filter does not guarantee installation. Win32 apps also have requirements that are evaluated before installation. Microsoft supports requirement rules based on operating system, architecture, file system information, registry values, and PowerShell scripts.

Use this decision split:

No assignment eligibility: fix the group, filter mode, filter expression, or device property source.
Assigned but not applicable: inspect OS, architecture, requirement registry/file checks, and requirement scripts.
Applicable with an install attempt: inspect content, command line, exit code, and execution identity.
Installed but failed detection: inspect the configured detection rule, path, hive, registry view, and context.

A requirement rule and an assignment filter can both look like “the app was skipped,” but they are different controls. Changing a detection rule cannot repair an assignment filter that excludes the device.

Step 3: use IME logs as a boundary check

On the device, inspect:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Start with AppWorkload.log and search for the app name, app ID, or another unique string from the policy. Then inspect AppActionProcessor.log for applicability and detection decisions. Use IntuneManagementExtension.log to check policy retrieval and reporting.

A simple search command is:

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Search = 'Contoso','<app-id>'

Get-ChildItem $LogRoot -Filter '*.log' |
    Select-String -Pattern $Search -SimpleMatch |
    Select-Object Path, LineNumber, Line

Replace the placeholders with values from the actual app. If there is no app-specific activity after a policy sync, stay in the assignment and applicability layer. If the log shows an install command, the filter already allowed the app far enough for installer troubleshooting.

Avoid searching only for failed. A downstream reporting line can hide the first meaningful boundary. Build a short timeline: policy received, applicability evaluated, content processed, install command executed, detection evaluated, and result reported. The exact wording varies by IME version, so use the sequence as an evidence model rather than a fixed string match.

Verified fix patterns

The device should be included but is excluded

Correct the filter mode or expression, then sync one test device. If the filter is shared by several assignments, create a narrowly scoped replacement rather than changing a production filter without checking its other consumers.

The device property is wrong or stale

Confirm the current device record and enrollment state. Do not hard-code a workaround into the package for an inventory or ownership problem. After the device property refreshes, re-evaluate the assignment before changing the installer.

The assignment is correct but a requirement fails

Fix the requirement rule or remediate the missing prerequisite. For a registry or file rule, verify the exact path and 32-bit/64-bit setting. For a script rule, validate its exit code, output, execution identity, and whether it is configured to run as a 32-bit process or with logged-on credentials.

The app reaches the install stage

Only now move to packaging analysis. Compare the install command, silent switches, return code mapping, install context, detection rule, and relevant IME/AppWorkload entries. Related runbooks cover system versus user install context, HKLM versus HKCU detection, and reading IME and AppWorkload logs.

Prevention checklist

Name filters for their mode and intent, not only their target population.
Keep an assignment record showing group, filter, mode, and app intent.
Test Include and Exclude behavior with one known-match and one known-nonmatch device.
Monitor device properties used in filters after enrollment, ownership, and OS changes.
Keep assignment filtering, requirements, install commands, and detection rules as separate troubleshooting layers.
Capture an IME log timeline before repackaging a Win32 app.
Re-test a single device after every targeting change, then confirm the portal status and local logs agree.

Intune Win32 App Not Installing on One Device: Check Assignment Filters Before Repackaging

The Win32 Deployment Doctor