Intune install and uninstall commands

What are install and uninstall commands in Intune?

When you package an app with the Microsoft Win32 Content Prep Tool into a .intunewin file, the wrapper does not know how to launch the installer inside it. You tell Intune that on the Program tab. The install command is the command line the IME executes to add or update the app; the uninstall command is the command line it executes when the app is assigned with the Uninstall intent, or when an Available app is removed from Company Portal.

Two ideas are worth fixing in your mind from the start. First, these commands run non-interactively as a background process — there is no desktop, no one clicking Next, and no one to dismiss a dialog. Second, the command exit code is not what marks the app as installed. Detection decides the final installed/not-installed state. The command must succeed and the detection rule must then report the app as present.

Why must the commands run silently?

Because the IME runs the command with no interactive user attached, any installer that opens a window, asks a question, or waits for a click will simply hang. Eventually the install hits the time limit you set on the Program tab and is reported as failed. A “setup window appeared” symptom almost always means the silent switch was missing or wrong for that installer.

• For MSI packages, use msiexec with a quiet flag such as /qn (no UI) and pair it with /norestart so the installer never reboots the device on its own.
• For EXE installers, use the vendor-documented silent switch. Common forms are /S, /silent, /quiet, or /verysilent, but the correct one depends entirely on the packaging toolkit the vendor used.
• For wrapped scripts, run the script with no profile and a bypassed execution policy so it cannot be blocked or prompted, and make sure the script itself emits no UI.

Picking the right switch is its own topic — see silent install switches for common installers for how to find and verify them.

Where do you set the commands? The Program tab

The Program step holds the install command, the uninstall command, the install behavior (context), the device restart behavior, the installation time limit, and the return code map. Keep these values minimal and tested before assigning the app to anyone beyond a pilot group.

How do the install and uninstall commands differ?

It is a common mistake to assume the uninstall command is just the install command in reverse. It rarely is. An MSI installs from a file path but uninstalls by product code; an EXE may install with setup.exe but remove itself through a separate uninstaller written into Program Files; a scripted package needs a dedicated removal script. Always author and test the uninstall path on its own, because it runs on a machine where the original .intunewin source files may no longer be in the same place.

For a quiet MSI removal, reference the product code rather than the original installer:

msiexec /x "{00000000-0000-0000-0000-000000000000}" /qn /norestart

System vs User: which install context should you use?

Install behavior controls the account the command runs as. The default and most common choice is System, which runs as the local SYSTEM account and installs the app device-wide regardless of who is signed in. Choose User only when the installer writes per-user data and genuinely needs the signed-in user’s profile — and remember that User context requires a user to actually be signed in for the command to run.

Context is one of the first things to check when a command works during a manual test but fails through Intune. A command you tested in an interactive admin prompt runs very differently as SYSTEM with no desktop. See System vs User context in Intune for the full comparison.

Working directory, quoting, and relative paths

The IME extracts your package to a temporary working folder and runs the command from there, so files you included in the package source are available next to the command using a relative path. This is why you can call install.ps1 or install.cmd directly without an absolute path — but it also means any file referenced by the command must actually be inside the .intunewin, not on a network share that SYSTEM cannot reach.

• Wrap any path containing spaces in double quotes, including paths to executables and to files passed as arguments.
• Reference packaged supporting files with relative paths such as .\install.ps1 rather than absolute paths.
• Do not assume a working directory other than the one Intune sets; if you need a specific folder, set it explicitly inside a wrapper script.
• Avoid mapped drives and per-user environment variables in System context — they may not exist for SYSTEM.

CMD vs PowerShell wrappers

Sometimes a single command line is not enough — you need to copy a file, write a registry value, stop a service, or handle errors. Wrap that logic in a script and call the script from the Program tab.

Use a CMD wrapper for short, linear sequences. Call it so it runs and exits:

cmd.exe /c install.cmd

Use a PowerShell wrapper when you need conditional logic, validation, or controlled error handling. Run it without a profile and with execution policy bypassed so it cannot be blocked, and pass the exit code back to Intune:

powershell.exe -NoProfile -ExecutionPolicy Bypass -File .\install.ps1

Inside the script, end with exit 0 on success and a non-zero code on failure so Intune sees the real result rather than PowerShell’s own exit code. PowerShell launched this way runs 64-bit on a 64-bit client by default; only force 32-bit when the app truly requires 32-bit registry or file system redirection.

How does the command result connect to return codes and detection?

When the command finishes, Intune compares its exit code against the return code map on the Program tab. The defaults are sensible for most installers, and you should leave them in place unless your installer uses non-standard codes.

A success code is necessary but not sufficient. Even after a clean exit, Intune runs the detection rule to decide the reported state, so an install can exit 0 yet still show as failed if detection does not match. Plan the reboot codes alongside the Program tab’s restart behavior — see restart behavior and exit codes in Intune and return codes and install behavior for how 3010 and 1641 should be handled. Remember too that requirement rules run before the command at all, so an app that never installs may be filtered out by a requirement, not by a bad command.

What are the most common command mistakes?

Most command failures trace back to a handful of recurring issues. Work through these before touching detection rules or assignments.

When you need to see exactly how the command behaved on a device, the IME logs are the source of truth — see Intune Management Extension logs for which file records each step.