Intune Win32 App Not Applicable: Fix Requirements and Applicability Mismatches

A Win32 app that never starts downloading is easy to misdiagnose. Admins often change the install command or detection rule, but Not applicable usually means Intune decided the device did not meet the app’s requirements before installation was attempted.

That distinction matters. An app can be correctly packaged, assigned, and visible in Company Portal while still being skipped because the device architecture, operating system, disk space, or requirement rule does not match the client.

This guide shows how to prove the first failing boundary and correct the smallest configuration error.

Quick Fix checklist

1. Record the app assignment, intent, device, architecture, OS build, and reported status.
2. Confirm that the device is actually in scope and has received the current app policy.
3. Inspect AppWorkload.log for applicability and detection activity.
4. Compare every configured requirement with the device’s real state.
5. Check whether a custom PowerShell requirement script works in the deployment context.
6. Only change detection or repackage after the logs show that applicability passed.
7. Sync one test device and confirm a fresh result before broad reassignment.

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 in the browser. It does not replace checking the affected device or the policy configuration.

What “Not applicable” actually tells you

Microsoft’s Win32 app troubleshooting guidance separates applicability from installation and detection. The Intune Management Extension logs app check-ins, installs, applicability, and detection in AppWorkload.log.

A useful model is:

assignment and policy scope
  -> requirements and applicability
  -> download and install command
  -> detection
  -> reporting

If the client stops at requirements, there may be no installer exit code to fix. A successful manual install does not prove the Intune assignment is applicable, and an existing executable does not prove the current app policy should install on that device.

Check assignment before changing requirements

Open the Win32 app in the Intune admin center and inspect the affected device’s installation details. Record:

• whether the assignment targets a user or device;
• whether the intent is Required or Available;
• assignment filters and exclusions;
• app dependency relationships;
• the policy revision or last check-in time;
• the exact status text and error code, if one is shown.

A device outside the assignment, excluded by a filter, or waiting for a newer policy can look like a requirements failure. Prove that the current policy reached the device before editing the app.

Compare built-in requirements with the device

In the Win32 app configuration, review the requirements for operating system architecture, minimum operating system, disk space, and other configured conditions. Then collect the same facts locally:

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

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

$env:PROCESSOR_ARCHITECTURE

Do not compare a friendly Windows name alone. A minimum OS version may exclude a device because of its build, and an architecture setting can exclude a 32-bit client even when the installer itself would run.

Also check whether the requirement is using a value that changes between hardware models or Windows releases. A hard-coded registry or file requirement can reject a valid device when the vendor changes the marker.

Custom requirement scripts are evaluated in a different context

A custom PowerShell requirement script must return the result Intune expects. Test the script with the same identity, bitness, paths, and environment used by the deployment. A script that works in an administrator’s interactive session can fail under the Intune Management Extension because it depends on a user profile, mapped drive, current directory, or unavailable environment variable.

For a machine-targeted app, prefer deterministic machine-visible evidence such as a versioned file, MSI product code, or HKLM value. Avoid a requirement that depends on one employee’s HKCU data unless the app is intentionally user-scoped.

Log the result while testing, but remove temporary logging before broad deployment if it exposes sensitive data.

Read the IME logs in order

The standard log directory is:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Start with AppWorkload.log, then inspect supporting logs around the same timestamp:

Log	What it helps prove
AppWorkload.log	app check-in, applicability, install, detection, and reporting
AppActionProcessor.log	applicability and detection processing
IntuneManagementExtension.log	policy retrieval, check-in, and reporting
AgentExecutor.log	execution of PowerShell install or requirement scripts

Use a narrow search instead of searching for failed alone:

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Terms = 'Contoso','NotApplicable','applicability','requirement'

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

Replace Contoso with the app name or identifier that appears in your logs. The goal is to identify whether the client evaluated a requirement and why it stopped, not to collect every unrelated error in the folder.

Why the obvious diagnosis can be wrong

The app is visible, so it must be assigned

Available apps can be visible to users without being required on the device. Visibility is not proof that the current assignment has passed applicability.

The installer works manually, so Intune is broken

Manual execution tests the installer under your interactive identity. It does not test assignment scope, Intune requirements, system context, or the current policy revision.

Detection is wrong

Detection is evaluated after installation. If AppWorkload.log shows the app was rejected as not applicable, changing the file or registry detection rule cannot make that run install. Fix the requirement or assignment boundary first.

A stale file proves the app is applicable

A leftover executable from an older package may exist even when the current app’s architecture, OS, or custom requirement does not match. Compare the configured rule with current device evidence.

Verified fixes by failure boundary

• Assignment or filter mismatch: correct the group, filter, exclusion, or intent, then sync a controlled device.
• OS or architecture mismatch: broaden the requirement only if the installer is supported on that platform; otherwise assign a compatible package.
• Disk-space requirement: remediate storage and retest rather than suppressing a safety requirement blindly.
• Custom script mismatch: make the script deterministic, return the documented result, and test it in the production context.
• Dependency or policy timing: confirm the dependency is applicable and that the device received the newest policy before changing the package.
• Detection failure after applicability passes: move to the HKLM vs. HKCU detection rules guide and compare the actual artifact.

After a configuration change, sync one device and watch for a new AppWorkload.log sequence. Do not judge a fix from an old portal state.

Prevention checklist

• Keep a package worksheet with assignment scope, requirements, install context, and detection artifact.
• Test built-in requirements on representative OS builds and architectures.
• Run custom requirement scripts in the same context as the deployed app.
• Avoid user-profile and mapped-drive dependencies for device-targeted apps.
• Keep requirements stable and tied to supported vendor facts.
• Capture AppWorkload.log when piloting a new package.
• Change one boundary at a time so the original cause remains identifiable.
• Link requirements to a supported installer matrix; do not broaden them just to make a status change.

Bottom line

When an Intune Win32 app is Not applicable, start before the installer. Prove assignment scope, policy freshness, requirements, and script context in that order. Once applicability passes, investigate installation and detection separately.

The Intune App Failure Analyzer can organize the error code, install command, detection rule, install context, registry view, and IME/AppWorkload logs you already have. Use it as a browser-based triage aid, then validate the fix on the affected Windows device.

Microsoft sources

• Troubleshoot Win32 app issues - Microsoft Intune
• Add, assign, and manage Win32 apps in Microsoft Intune
• Intune Management Extension for Windows

Related: The Intune Win32 App Installed but Says Failed, System vs. User Install Context in Intune Win32 Apps, and How to Read Intune Management Extension and AppWorkload Logs.