Skip to content
September 16, 2026 • Mid-Level (3-5 years) How-To

Intune Win32 App Dependency Not Installing: Check the Relationship Before Repackaging

A Win32 app can remain unavailable or fail while its dependency is missing. Use Intune assignment, automatic-install, context, and IME evidence to repair the dependency chain.

Methodology

Practical guidance for working engineers, with a bias toward steps you can verify and repeat.

• What it covers: the exact problem, workflow, or decision
• What to verify: logs, settings, outcomes, or pass/fail checks
• What to avoid: risky changes without rollback or validation
• What to expect: prerequisites, caveats, and role fit

Intune Win32 App Dependency Not Installing: Check the Relationship Before Repackaging

A Win32 app that will not install is not always an installer problem. Intune can hold the parent app behind a dependency that is missing, incorrectly related, or not configured for automatic installation. Repackaging the parent app first can hide the real failure boundary.

The fastest diagnosis is to treat the deployment as a relationship: identify the parent app, identify every dependent Win32 app, then prove which dependency Intune evaluated first and what happened on the device.

Quick Fix checklist

  1. Open the parent Win32 app in Intune and record its dependencies, install behavior, and assignment.
  2. Confirm each dependency is a Win32 app. Intune does not support a Win32 dependency on a single MSI line-of-business app or a Microsoft Store app.
  3. Check whether Automatically install is enabled for the dependency.
  4. Confirm the dependency’s install context matches the device workflow: System applies to all users of the device; User applies to one user.
  5. Check the dependency’s requirements and detection rules independently from the parent app.
  6. Sync one test device and correlate AppWorkload.log with IntuneManagementExtension.log.
  7. Fix the first dependency boundary that fails, then retest the parent app.

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 claim an analyzer finding that is not in your input.

How Intune dependency evaluation works

A dependency defines that one app requires another app to be installed first. Microsoft states that the dependent app must be installed before Intune installs the parent app. A dependency can also be configured for automatic installation; when enabled, Intune installs it even if the dependent app is not separately assigned to the user or device.

That creates several distinct failure states:

  • The relationship is absent or points to the wrong app.
  • The dependency exists, but automatic installation is disabled and the dependency has no applicable assignment.
  • The dependency is targeted but is not applicable because its requirements do not match.
  • The dependency installs, but its detection rule still says it is absent.
  • The dependency succeeds, but the parent app has a separate command, context, or detection failure.

The parent app’s visible status cannot distinguish these states by itself.

Step 1: inspect the relationship in Intune

In Apps > All apps, open the parent Win32 app and review its Dependencies page. Record:

  • parent app name, app ID, and version;
  • every dependency and its app ID;
  • whether Automatically install is set to Yes;
  • each dependency’s install behavior and assignment;
  • whether the dependency is itself dependent on another Win32 app.

Microsoft documents a maximum of 100 dependencies, including nested dependencies and the app itself. Keep the chain understandable. A large or circular-looking design is harder to diagnose than a small, explicit prerequisite set.

Do not use the parent app’s install status as proof that a dependency installed. Microsoft notes that the install status of a dependent app is displayed in Intune only when that dependent app is targeted to the user or device. Check the dependency’s own device status or use client logs when it is automatically installed but not directly assigned.

Step 2: validate the dependency on its own

Open the dependency and test it as if it were the only app in the deployment.

Requirements

Confirm the operating-system architecture, minimum operating-system version, disk space, and any custom requirement script. An app that is Not applicable will not satisfy the parent relationship, even if its installer works interactively.

Install command and context

Run the exact silent command in the same identity used by Intune. A dependency installed in System context must not rely on a user’s mapped drive, profile folder, or HKCU value. A dependency intended for one user may behave differently when installed for all users.

Detection

Intune requires all configured detection rules to be met. Check the exact file, MSI product code, registry hive, data type, and 32-bit or 64-bit registry view. A dependency can be present while its configured detection says it is absent, leaving the parent blocked.

A simple local evidence capture for a machine-wide file looks like this:

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

Use the actual artifact and rule from Intune. Do not substitute a similarly named file.

Step 3: read the device timeline

Microsoft documents the Intune Management Extension log directory as:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Start with AppWorkload.log and correlate the dependency name or app ID with AppActionProcessor.log and IntuneManagementExtension.log.

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Terms = 'Prerequisite','dependency','Detection','NotDetected','return code'
Get-ChildItem $LogRoot -Filter '*.log' |
  Select-String -Pattern $Terms -SimpleMatch |
  Select-Object Path, LineNumber, Line

Build a timeline rather than relying on one line:

BoundaryEvidence to find
Policy arrivedIME check-in and policy-processing entries
Dependency was evaluatedApp workload/action entries for the dependency
Dependency installedcommand execution and return code
Dependency was detecteddetection result for the configured artifact
Parent became eligiblea later parent evaluation after dependency success

If the dependency never appears after a controlled sync, investigate assignment, filters, check-in, and policy timing before changing its installer. If it appears as NotDetected, fix the dependency’s detection rule or install context. If it returns an installer error, repair that command or package first.

The obvious diagnosis that can be wrong

“The parent app fails, so the parent package is broken” is often the wrong first conclusion. The parent may never have reached installation because Intune was waiting for a prerequisite. Conversely, a dependency may have succeeded while the parent failed its own detection rule.

Do not change the parent package, dependency relationship, install command, and detection rules in one edit. That removes the evidence needed to identify whether the failure was applicability, dependency ordering, installation, detection, or reporting.

Verified repair sequence

  1. Choose one test device and capture the current parent and dependency status.
  2. Correct the dependency relationship and enable automatic installation when the dependency is required but should not need a separate assignment.
  3. Fix the dependency’s requirements, silent command, context, or detection rule based on the first failing log boundary.
  4. Sync the test device and wait for a new dependency evaluation.
  5. Confirm the dependency is installed and detected in the intended context.
  6. Confirm the parent is evaluated after the dependency succeeds.
  7. Only then troubleshoot the parent’s command, return code, or detection rule.

Prevention checklist

  • Keep prerequisites as separate Win32 apps with explicit names and owners.
  • Document whether each dependency is automatic and whether it is System or User context.
  • Test nested dependencies on a clean device, not only on a machine with old software.
  • Test every detection rule under the production identity and registry view.
  • Capture dependency and parent app IDs with the pilot logs.
  • Pilot relationship changes on one device before broad reassignment.
  • Sanitize tenant IDs, usernames, device names, and internal paths before sharing logs.

Bottom line

When an Intune Win32 app will not install, inspect its dependency chain before repackaging. A missing relationship, non-automatic dependency, inapplicable prerequisite, failed detection rule, or context mismatch can stop the parent for different reasons. AppWorkload.log and IntuneManagementExtension.log show which boundary actually failed.

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

Microsoft sources

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

#Microsoft Intune #Win32 apps #app dependencies #Intune Management Extension #AppWorkload.log
Was this helpful?

Comments

Comments are coming soon. Have feedback? Reach out via the About page.