Intune Win32 App Detection Passes on the Device but the Portal Still Says Failed

A Win32 app can be installed, match its detection rule, and still appear as Failed in the Intune admin center. That does not prove the installer needs to be repackaged. The portal result may belong to an earlier policy revision, an earlier detection attempt, or a different assignment and device record.

This is a reporting and evidence problem until the client timeline proves otherwise. The reliable fix is to correlate the current app policy, local detection result, IME workload logs, and the next device check-in.

Quick Fix checklist

1. Record the app name, Intune app ID, device, assignment, intent, and the portal timestamp.
2. On the device, confirm the exact artifact configured in the detection rule.
3. Check AppWorkload.log and AppActionProcessor.log for the latest policy revision and detection result.
4. Check IntuneManagementExtension.log for check-in, policy retrieval, processing, and reporting.
5. Sync one test device and wait for a new client result before changing the package.
6. If the new result still fails, compare the current rule with the client evidence in the same attempt.

For a structured first 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 organizes the evidence you provide; it does not inspect the endpoint or invent a portal result.

Why a local pass and a portal failure can coexist

A Win32 deployment has separate stages:

assignment and policy
  -> applicability
  -> content and install command
  -> detection
  -> client reporting
  -> portal display

A file on disk is not enough to prove the current deployment succeeded. It could be leftover content, a per-user installation, or an artifact created by a different package. But the reverse is also true: a portal Failed label is not enough to prove the current installer or detection rule failed.

The key question is whether the portal failure is newer than the client evidence you are examining. Compare timestamps and policy revisions before making a fix.

Step 1: capture the portal state precisely

Open the Win32 app and affected device in Intune, then record:

• the app ID and display name;
• the device and user involved;
• assignment group and install intent;
• reported status and error code, if present;
• the portal timestamp and policy or app version shown;
• whether the status is from the current assignment.

Do not compare a device-local result with a portal row from another device, another user assignment, or an old app revision. Duplicate assignments and supersedence can make the visible result look like one timeline when it is not.

Step 2: prove what the current detection rule sees

Use the exact artifact configured in Intune. For a file rule:

$Path = 'C:\Program Files\Contoso\Client\Contoso.exe'
Get-Item $Path -ErrorAction Stop |
  Select-Object FullName, Length, LastWriteTime, VersionInfo

For a machine-wide uninstall record:

$Roots = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)

Get-ItemProperty $Roots -ErrorAction SilentlyContinue |
  Where-Object DisplayName -like '*Contoso*' |
  Select-Object DisplayName, DisplayVersion, PSChildName, InstallLocation

A successful interactive check does not prove a System-context detection script will succeed. Re-run the check in the deployment identity and against the configured 32-bit or 64-bit registry view. A user-profile path or HKCU value may be invisible to a device-targeted System deployment.

Step 3: read the local timeline

Microsoft documents the IME logs under:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Start with AppWorkload.log, then correlate the same app and time in AppActionProcessor.log, AgentExecutor.log, and IntuneManagementExtension.log.

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Terms = 'Contoso','Detected','NotDetected','Detection','return code'

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

Use the logs to answer four separate questions:

Question	Evidence
Did the current policy reach the device?	IME check-in and policy-processing entries
Did the app action run?	AppWorkload.log install or evaluation entries
Did detection pass in the intended context?	AppActionProcessor.log and detection-script evidence
Did the client report the result?	IME reporting entries and a new timestamp

The exact log wording varies by IME version. Look for a coherent sequence, not one isolated line.

The common false diagnosis: “the installer is broken”

If the current client timeline shows the install completed, detection matched, and a result was reported, rebuilding the .intunewin file is not the first fix. Investigate stale portal data, policy scope, duplicate assignments, or a result from an earlier revision.

If the logs show NotDetected after the current install, the portal is probably reflecting a real detection failure. Check the path, MSI product code, registry hive, data type, registry view, version comparison, and execution context before changing the installer.

If there is no current workload activity after a policy change, do not infer a detection result from the presence of the app. Investigate check-in, assignment, filters, IME health, and policy timing first.

Verified repair sequence

1. Sync one controlled device

Use the Intune device action or the Windows Company Portal sync on a test device. Avoid broad reassignment while the evidence is ambiguous. A controlled sync gives you a new timestamp and a clean comparison point.

2. Confirm the new policy was evaluated

After the sync, capture fresh entries from IntuneManagementExtension.log and AppWorkload.log. Confirm that the current app identity and policy revision were processed. If the old result remains in the portal but the client has not processed the new policy, the repair is not yet tested.

3. Fix the first failed boundary

• No new policy activity: repair assignment, filters, check-in, or IME health.
• Applicability failed: correct requirements and scope.
• Install command failed: correct content, silent switches, dependencies, or exit-code handling.
• Detection failed: correct the artifact, path, hive, registry view, context, or comparison.
• Client reported success but portal remains failed: verify the device and assignment identity, then allow a fresh portal update before changing the package again.

Do not change the installer, detection rule, and assignment at the same time. That destroys the comparison needed to identify the original boundary.

Prevention checklist

• Record the app ID, policy revision, device, assignment, and timestamps for each test.
• Test detection in the same System or User context used in production.
• Validate native and 32-bit registry views when registry detection is involved.
• Use a stable artifact rather than a temporary installer file or shortcut.
• Keep install and detection evidence from the same deployment attempt.
• Pilot changes on one device before broad reassignment.
• Capture AppWorkload.log, AppActionProcessor.log, and IntuneManagementExtension.log during pilot testing.
• Sanitize tenant IDs, usernames, device names, and internal paths before sharing logs.

Bottom line

When local detection passes but Intune still says Failed, prove whether the portal is showing the current client attempt. Correlate policy revision, detection context, IME workload entries, reporting timestamps, and assignment identity. Only repackage after the current logs show an installer or content failure.

The Intune App Failure Analyzer is useful for organizing the error code, command, detection rule, context, registry view, and IME/AppWorkload evidence in the browser. It is a triage aid, not proof of the endpoint or portal state.

Microsoft sources

• Troubleshoot Win32 app issues in Microsoft Intune
• Intune Management Extension for Windows
• Troubleshooting Win32 app installations with Intune

Related: The Intune Win32 App Installed but Says Failed, How to Read Intune Management Extension and AppWorkload Logs, and Intune Win32 Detection Failed 0x87D1041C.