Free tool · Runs in your browser

Intune Win32 Install Command & Return Code Builder

Most failed Win32 deployments trace back to one line: the install command. Choose the installer behind your package and get the exact silent install and uninstall strings, a log path you can open on the device, and the warnings that go with that installer, such as the quoting rules for NSIS and InstallShield or the 64-bit PowerShell path. Below the builder, a reference table explains which return codes Intune treats as success, a restart or a failure.

Nothing you type leaves the browser. Test every command as SYSTEM on a pilot device before you assign the app. Switches are defined by the installer’s author, so confirm them against the vendor’s documentation.

Command lineInstall command

msiexec /i "ContosoApp.msi" /qn ALLUSERS=1 REBOOT=ReallySuppress /L*v "%ProgramData%\Microsoft\IntuneManagementExtension\Logs\Contoso-App-Install.log"

Command lineUninstall command

msiexec /x "{12345A67-89B0-1234-5678-000001000000}" /qn REBOOT=ReallySuppress /L*v "C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\Contoso-App-Uninstall.log"

Install log

%ProgramData%\Microsoft\IntuneManagementExtension\Logs\Contoso-App-Install.log

Uninstall log: C:\ProgramData\Microsoft\IntuneManagementExtension\Logs\Contoso-App-Uninstall.log

Next Step

Next Step: Build Your Detection Rule

The install command only tells Intune how to run the setup. Intune decides whether it worked from the detection rule, so build one that matches what this installer really leaves behind.

Open the Win32 detection script generator Install failed? Look up the error code

REBOOT=ReallySuppress stops msiexec restarting the device itself. When a restart is still needed msiexec exits 3010, which Intune treats as a soft reboot.
The verbose log is written by the Windows Installer service as SYSTEM, in the same folder as the Intune Management Extension logs, so one folder holds both sides of a failed install.

Intune Win32 return codes and restart behavior

After the install command exits, Intune compares the exit code with the app’s return code list, then applies the Device restart behavior setting. The codes below are the ones that come up most in packaging work.

Intune Win32 return codes and their code type
Return code	Intune code type	What it means
0	SuccessAdded by default	The installer finished and reported success.
1707	SuccessAdded by default	Windows Installer: the operation completed successfully.
3010	Soft rebootAdded by default	Success, but a restart is needed to finish. The next Win32 app can still install first.
1641	Hard rebootAdded by default	Success, and the installer has started a restart. The next Win32 app waits until the device restarts.
1618	RetryAdded by default	Another installation is already running. Intune tries three times, five minutes apart.
1603	FailedNot in the default list	Windows Installer fatal error. Not in the default list, so Intune records Failed; read the verbose log.
60001	FailedNot in the default list	PSADT: an error occurred in the deployment script. A real failure, so leave it as Failed.
60012	FailedNot in the default list	PSADT: a UI prompt timed out or the user deferred. Add it as Retry only if a deferral should be retried.

Any exit code that is not in the list is treated as Failed. You can add codes or change a code’s type on the Program page under “Specify return codes to indicate post-installation behavior”.

What “Device restart behavior” does with 3010 and 1641

How each device restart behavior setting handles hard and soft reboot return codes
Device restart behavior	1641 (hard)	3010 (soft)
Determine behavior based on return codes	Restarts the device immediately.	Tells the user a restart is needed. No forced restart.
App install may force a device restart	Tells the user a restart will happen in 120 minutes.	Tells the user a restart is needed.
No specific action	Suppresses restarts for MSI-based apps.	Suppresses restarts for MSI-based apps.
Intune will force a mandatory device restart	Restarts after every successful install.	Restarts after every successful install.

How “Determine behavior based on return codes” treats 3010 and 1641. With this setting Intune lets the exit code decide. A 1641 hard reboot restarts the device immediately and holds back the next Win32 app until it has restarted. A 3010 soft reboot only tells the user a restart is needed, and the next app installs first. If a restart in the middle of a user’s day is unacceptable, make the installer return 3010 rather than 1641: REBOOT=ReallySuppress does that for MSI packages.

Restart codes can disappear before Intune sees them. An installer that restarts silently, an Inno Setup run without /RESTARTEXITCODE=3010, or PSADT with reboot pass-through switched off all exit 0, so Intune records a clean success. Check the exit code in AppWorkload.log before you trust the restart setting.

Retry is not a fast retry. A Retry code makes the agent try the install three times, waiting five minutes between attempts, which suits 1618 (another installer running) but not a PSADT deferral that a user may leave for days. Intune does not list 1603, 60001 or 60012 by default, so each is recorded as Failed unless you add it.

Use the commands in a Win32 app

Pick the installer type, then replace the example file names, product code and paths with the values from your package. Use a device where the app is installed to confirm uninstaller paths and product codes.
Copy the install command into the Install command box on the app’s Program page, and the uninstall command into the Uninstall command box.
Run IntuneWinAppUtil.exe on a source folder that holds every file the commands name: the installer, any .mst transform, the .iss response file or the wrapper script.
Set Installation time required to cover the slowest device, and set Device restart behavior to match how the installer reports restarts (see the table below).
Add any extra return codes, build a detection rule, and prove the install, the detection and the uninstall on a pilot device before you assign the app.

Choosing a packaging approach

A command line is the simplest option when the vendor documents silent switches. When a deployment needs prerequisites, user messaging, cleanup of an older version or a log you control, a wrapper such as PSAppDeployToolkit earns its keep. The Intune Win32 app packaging tools compared guide covers where PSADT, Advanced Installer and the commercial packaging tools fit.

Whichever route you take, Microsoft states that Intune does not support interactive installations, so a package must install without prompts as SYSTEM.