Skip to content
August 31, 2026 • Mid-Level (3-5 years) Error Reference

Fix Intune Win32 MSI Error 1618: Another Installation Is Already in Progress

Troubleshoot Intune Win32 MSI deployments that return error 1618 because Windows Installer is already busy, using IME logs, MSI evidence, and a safe retry workflow.

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

Fix Intune Win32 MSI Error 1618: Another Installation Is Already in Progress

An Intune Win32 app can fail even when the package, command line, and detection rule are correct. If the installer returns 1618, Windows Installer is reporting that another installation is already running. Microsoft names this result ERROR_INSTALL_ALREADY_RUNNING: complete the other installation before starting this one.

That is a device-state problem, not proof that the .intunewin payload is damaged. Repackaging first can hide the real cause and make the next retry collide with the same installer activity.

For a structured evidence review, use the free Intune App Failure Analyzer. It is a browser-based, client-side beta. Enter the error code, install command, detection rule, install context, registry view, and relevant IME/AppWorkload logs. It organizes the evidence; it does not inspect the endpoint or claim a result that is not in the data you provide.

Quick fix checklist

  1. Confirm the affected app’s installation details in Intune admin center > Apps > Windows > the app > Monitor > Device install status.
  2. Record the exact return code and failure time. Do not treat a portal status of Failed as the root cause.
  3. Collect AppWorkload.log, IntuneManagementExtension.log, and AppActionProcessor.log from C:\ProgramData\Microsoft\IntuneManagementExtension\Logs.
  4. Check Windows Installer activity and Windows Update activity around the same timestamp.
  5. Let the competing install finish, or remediate the stuck operation using your normal endpoint-change procedure. Do not kill an unknown installer blindly.
  6. Re-run the exact Intune command on one test device after the device is idle.
  7. Verify both the installer return code and the configured detection rule before expanding the assignment.

Why the obvious diagnosis can be wrong

A failed Intune status does not mean the app command is malformed. Intune launches the configured command through the Intune Management Extension, and the installer returns a result. If MSI is already servicing another package, the new command can fail before it evaluates your application payload.

Common collisions include:

  • another MSI deployment running at the same time;
  • Microsoft 365 Apps or another enterprise installer servicing the device;
  • a Windows Update or software-management action holding the installer boundary;
  • a previous installation that is still running or waiting on a hidden user interface;
  • multiple required app assignments arriving together during enrollment.

A second manual launch can make the incident worse by adding another competing request. First establish which process or management action owns the current installation activity.

Evidence to inspect

Intune client logs

The IME logs show what policy was received, which command was launched, and how the result was reported:

C:\ProgramData\Microsoft\IntuneManagementExtension\Logs

Search around the failure timestamp:

$LogRoot = 'C:\ProgramData\Microsoft\IntuneManagementExtension\Logs'
$Terms = '1618','ERROR_INSTALL_ALREADY_RUNNING','install','Contoso'

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

Replace Contoso with the application name. AppWorkload.log is the key app-processing log; IntuneManagementExtension.log helps establish policy and service timing; AppActionProcessor.log is useful when the app transitions into applicability or detection evaluation.

Windows Installer and update activity

Use the failure timestamp to correlate Windows Installer events with Windows Update and other software-management logs. The important question is whether another operation was active when the IME command started. Do not infer that from the app name alone.

For a controlled test, inspect active installer-related processes before retrying:

Get-Process msiexec -ErrorAction SilentlyContinue |
  Select-Object Id, StartTime, Path

The absence of a process at the time you check does not prove that no collision occurred earlier. Preserve the original logs and timestamps.

Verified remediation workflow

1. Stop creating package changes

Keep the package and detection rule unchanged while you isolate 1618. If the same command succeeds once the competing installation has finished, repackaging was not the fix.

2. Identify the competing operation

Check planned software deployments, Windows Update servicing, Microsoft 365 Apps updates, and any vendor updater scheduled at the failure time. On enrollment-heavy devices, review whether several required MSI-based apps were assigned together.

3. Allow a clean completion

If the other install is healthy, wait for it to finish and allow any required restart through your managed process. If it is stuck, follow your organization’s supported remediation procedure and collect evidence before changing installer state.

4. Retry one device with the same command

Do not change install switches and detection simultaneously. A valid retry proves only that the installer can run when Windows Installer is available. The deployment is complete only when Intune also reports the app detected.

5. Reduce future collisions

Stagger heavyweight required deployments during enrollment, avoid overlapping vendor updaters where possible, and use explicit dependencies when one Win32 app must be installed before another. Keep the dependency graph and assignments reviewable.

Prevention checklist

  • Record the exact installer return code, command, and timestamp.
  • Correlate AppWorkload.log with Windows Installer and Windows Update activity.
  • Use Win32 app dependencies for known ordering requirements.
  • Avoid launching the same MSI from both Intune and a separate software-management tool.
  • Pilot concurrent required-app assignments on a clean test device.
  • Keep install commands silent so a hidden UI does not hold the installer open.
  • Validate detection after every successful retry; 1618 is an install concurrency error, not a detection proof.

Bottom line

Intune Win32 MSI error 1618 means Windows Installer was already servicing another installation when the command ran. Prove the collision from timestamps and client logs, let the competing operation finish safely, then retry the unchanged command on one device. Repackage only if separate evidence shows a package problem.

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

References

#Microsoft Intune #Win32 apps #MSI #Error 1618 #AppWorkload #Windows Installer
Was this helpful?

Comments

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