Intune Win32 Detection Script Works Locally but Fails as SYSTEM: How to Fix It

A Win32 app detection script can return the expected result in an administrator’s PowerShell window and still report Not detected in Intune. The usual reason is not that Intune changed the script. The script is running with a different identity, profile, environment, and working directory.

For a System Win32 app, the Intune Management Extension runs the install and detection workflow in the System context. A check that depends on the signed-in user’s HKCU, mapped drives, profile variables, or an interactive prompt can therefore pass during testing and fail during deployment.

This runbook isolates that context mismatch without immediately rebuilding the package.

Quick Fix checklist

1. Confirm the app’s Install behavior and whether the assignment is device- or user-targeted.
2. Read AppWorkload.log and AppActionProcessor.log around the same deployment attempt.
3. Identify the exact detection artifact: file, folder, MSI product code, registry value, or script output.
4. Test the detection script under SYSTEM, not only as a local administrator.
5. Remove mapped drives, relative paths, interactive commands, and assumptions about the signed-in user.
6. Use absolute machine paths and the correct HKLM or HKCU boundary for the app’s install context.
7. Return a deterministic success or failure exit code.
8. Sync one test device and verify a fresh detection result before changing assignments.

For a structured second pass, use the free Intune App Failure Analyzer. It is browser-based and client-side; the tool accepts error codes, install commands, detection rules, install context, registry view, and IME/AppWorkload logs. Treat its output as triage guidance and verify the result on the device.

Why the obvious diagnosis is wrong

The portal status Failed does not prove that the installer failed. Microsoft documents that Win32 app processing includes installation followed by detection. If the post-install detection rule does not find the expected evidence, the app can be reported as not detected even when an executable exists on disk.

The context mismatch commonly looks like this:

• The installer writes to C:\Users\Alice\AppData\Local, but the System detection process checks the System profile.
• The script reads HKCU, but HKCU under System is not the signed-in user’s hive.
• The script uses Z:\ or another mapped drive that exists only in the user’s session.
• The script uses $env:USERPROFILE or $PWD as if they describe the interactive tester.
• The script launches a GUI or waits for user input.
• The script writes a success message but exits with a failure code, or returns success on both branches.

An administrator account is not equivalent to SYSTEM. Test the identity that will execute the rule.

Read the client evidence first

Microsoft documents the IME logs at:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Start with the app name or app ID, then correlate timestamps across:

Log	What to establish
AppWorkload.log	Whether the app reached install and post-install detection
AppActionProcessor.log	The applicability and detection decision
AgentExecutor.log	Script execution, command details, and script errors
IntuneManagementExtension.log	Check-in, policy processing, and reporting

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

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

If the workload log shows installation completed and the action processor records a not-detected result, stop changing the installer. Validate the script’s evidence and execution context.

Reproduce the detection check as SYSTEM

In a lab or controlled test device, use PsExec to open a System PowerShell session:

psexec.exe -i -s powershell.exe

Inside that window, confirm the identity and environment before running the detection script:

whoami
$env:USERNAME
$env:USERPROFILE
Get-Location

The identity should be nt authority\system. Run the exact command configured in Intune, using the same script path and arguments. Do not substitute an interactive admin test.

For a production-safe script, make the check machine-oriented and explicit:

$Path = 'C:\Program Files\Contoso\Agent\ContosoAgent.exe'
$MinimumVersion = [version]'5.4.0.0'

if (-not (Test-Path -LiteralPath $Path)) {
  exit 1
}

$Version = [version]([System.Diagnostics.FileVersionInfo]::GetVersionInfo($Path).FileVersion)
if ($Version -ge $MinimumVersion) {
  Write-Output 'Installed'
  exit 0
}

exit 1

The script has one job: return success when the required artifact is present and valid, and failure otherwise. Keep logging separate from the detection decision so a diagnostic write cannot accidentally change the result.

Fix identity and path mistakes

User profile paths

If the application is intentionally per-user, choose User install behavior and design the detection rule around the intended user profile. If the app must be available to every user or before sign-in, package it for System installation and detect a machine-wide artifact instead.

Do not detect a device-targeted app by hard-coding one user’s profile:

C:\Users\Alice\AppData\Local\Contoso\app.exe

That may pass on one test account and fail on every other device.

Registry hives

For a machine-wide install, check the documented HKLM location. For a per-user install, verify that the chosen Intune context can access the intended user’s HKCU. Also account for 32-bit registry redirection on 64-bit Windows.

Related: HKLM vs. HKCU Detection Rules in Intune Win32 Apps.

Working directory and environment

Use absolute paths. Do not rely on the current directory, mapped drives, a user’s PATH, or interactive profile scripts. If the installer creates a marker file, place it in a stable machine location and document its ownership and lifecycle.

Verify the smallest fix

After correcting the script or detection rule:

1. Save the rule revision in Intune.
2. Sync one test device.
3. Confirm the new policy revision reached the client in IntuneManagementExtension.log.
4. Check AppWorkload.log and AppActionProcessor.log for a new detection evaluation.
5. Confirm the portal result changes for that same attempt.

Do not change the installer, assignment, detection rule, and device state simultaneously. One controlled change preserves the evidence trail.

Prevention checklist

• Test System-context scripts as SYSTEM, not only as an administrator.
• Keep device detection independent of user profile state.
• Use absolute paths and stable machine-wide markers.
• Validate native and redirected registry views where relevant.
• Make installed and not-installed exit codes explicit.
• Record the install context beside every detection rule in the package worksheet.
• Capture AppWorkload.log, AppActionProcessor.log, and AgentExecutor.log during pilot deployment.
• Remove usernames, tenant identifiers, and other sensitive data before sharing logs.

Microsoft sources

1. Win32 app management in Microsoft Intune
2. Troubleshoot Win32 app issues
3. Intune Management Extension for Windows
4. Add, assign, and monitor a Win32 app

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.