Intune Win32 App Not Offered: Check Requirements Before Repackaging

When a required or available Win32 app does not appear on a Windows device, many administrators rebuild the .intunewin file first. That is only useful when the client reached content download or execution. If an Intune requirement rule says the device is not applicable, the install command may never run.

This runbook separates not offered, not applicable, and install or detection failure so the repair matches the evidence.

Quick triage checklist

1. Confirm the assignment target, intent, and whether the device or user is in scope.
2. Record the configured requirement rules: operating system architecture, minimum OS, disk space, and custom requirement script behavior.
3. Compare those rules with the affected device, not with the packaging workstation.
4. Check AppWorkload.log and AppActionProcessor.log in C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
5. If the app is applicable, then inspect download, install-command, return-code, and detection evidence.
6. Sync one test device and confirm the app state changes before changing the package.

For a structured second pass, use the free Intune App Failure Analyzer. It is a browser-based, client-side beta that accepts error codes, install commands, detection rules, install context, registry view, and IME/AppWorkload logs. Treat its output as an aid to organize evidence, then verify the conclusion on the device.

Why the obvious diagnosis can be wrong

A missing Company Portal entry is not proof that the installer is broken. Intune evaluates assignment and applicability before it can download and execute a Win32 app. A device can therefore be correctly excluded by a requirement rule while the package itself is valid.

The reverse is also possible: an app can be applicable and assigned, but fail later during download, command execution, or detection. Do not infer the stage from the absence of a shortcut.

Check assignment before the package

In the Intune admin center, open the Win32 app and review its assignments and monitoring views. Confirm:

• the affected user or device is in the intended group;
• the assignment is not excluded by another group;
• the intent is Required or Available as intended;
• the device has checked in recently;
• the app is supported on the target Windows edition and architecture.

A group-membership or exclusion problem is a control-plane problem. Repackaging cannot fix it.

Compare requirements with the device

Win32 app requirements can include operating system architecture, minimum operating system, disk space, and custom requirement rules. Capture the actual device values with PowerShell:

Get-CimInstance Win32_OperatingSystem |
  Select-Object Caption, Version, OSArchitecture

Get-CimInstance Win32_LogicalDisk -Filter "DeviceID='C:'" |
  Select-Object DeviceID, FreeSpace, Size

Then compare the values to the app configuration. Pay particular attention to architecture and minimum-version comparisons. A rule that is correct for an x64 pilot device can exclude an ARM64 or older Windows device.

For a custom requirement script, verify the script’s exit behavior and output contract in a test environment. A script that returns the wrong result, cannot read its required data, or depends on a user session can mark the device not applicable even though the installer would work.

Read the client evidence

On the device, inspect:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppActionProcessor.log
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\AppWorkload.log
C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\IntuneManagementExtension.log

Search for the app name, app ID, and words such as requirement, applicability, not applicable, download, install, and detection. AppActionProcessor.log is useful for the client-side applicability and action decision. AppWorkload.log helps establish whether the app progressed into workload processing. The IME log helps confirm policy retrieval and check-in.

If the records stop at applicability, fix assignment or requirements. If they show content and command execution, move to installer return codes and detection rules. If detection is the boundary, compare the configured rule with the installed file, MSI product code, registry value, or script result.

Verified fix pattern

Make the smallest change supported by the evidence:

• Correct the assignment or exclusion when scope is wrong.
• Correct the architecture, OS version, or disk-space requirement when the device is valid for the app.
• Repair a custom requirement script so it returns the documented result consistently and does not depend on an interactive user.
• Leave the package unchanged when the package was never reached.
• Repackage only after client logs prove a content or installer defect.

After the change, sync a single test device, wait for policy processing, and verify the new client decision. For an Available assignment, confirm the app becomes discoverable; for a Required assignment, confirm the install progresses to execution and then detection.

Prevention checklist

• Keep a written requirement matrix for each Win32 app and supported device architecture.
• Test custom requirement scripts under the same security context used by Intune.
• Include one older supported Windows build and each supported architecture in pilot testing.
• Save the relevant IME logs before changing an assignment or package.
• Treat not applicable as a requirements or scope investigation, not an installer failure.
• Re-check detection rules separately after a requirement change.

Related guidance

Continue with System vs. User Install Context in Intune Win32 Apps and How to Read Intune Management Extension and AppWorkload Logs when the device is applicable but the deployment still fails.

Microsoft sources

• Add and Assign Win32 Apps to Microsoft Intune
• Troubleshoot Win32 Apps in Microsoft Intune