Silent install switches for common installers

What is a silent install switch and why does Intune need one?

When you run an installer normally it opens a wizard: Next, accept the license, choose a folder, Finish. A silent switch suppresses that wizard and supplies the answers up front. Vendors expose these switches so that administrators can script deployments through Configuration Manager, Group Policy, or Intune.

The Intune Management Extension (IME) runs your install command in the background, typically as the local SYSTEM account, with no interactive desktop to click. If the installer waits for any prompt, the process never exits, the IME eventually treats it as a failure, and the user sees nothing. That is why every Win32 app you create needs an install command whose switches guarantee a fully unattended run. The companion guide on Intune install and uninstall commands covers where these strings go on the Program tab; this article focuses on choosing the switches themselves.

How do MSI quiet parameters work?

MSI packages are the easiest case because the quiet behaviour is standardised by Windows Installer, not by each vendor. You drive an MSI through msiexec.exe, the built-in Windows Installer engine. The two arguments that matter most are the UI-level flag and the restart flag.

A clean Intune install command for an MSI looks like the example below. Use /qn rather than /qb so nothing flickers on the user’s screen, and add /norestart so the reboot decision stays with Intune’s restart behaviour rather than the installer.

msiexec /i "package.msi" /qn /norestart

MSIs also accept public properties in NAME=VALUE form to set licensing, install folders, or feature selection without editing a transform, for example ALLUSERS=1 for a per-machine install. When an install fails, re-run it with verbose logging so the MSI engine writes every action and error to disk:

msiexec /i "package.msi" /qn /norestart /l*v "C:\Windows\Temp\install.log"

Which silent switches do common EXE installers use?

EXE installers are harder because the switch is decided by whatever toolkit the vendor used to build the setup, not by Windows. The good news is that a handful of toolkits cover the vast majority of real-world EXEs, and each has a predictable silent argument. The table below maps the common toolkits to their typical switches.

Because the same flag does not work everywhere, never assume /quiet is universal. A common failure is shipping setup.exe /quiet to an Inno Setup installer that actually needs /VERYSILENT; the install runs interactively on a desktop that the user cannot see and never completes.

How do I find the silent switch for an unknown installer?

When the vendor does not document a switch, work through this sequence:

1. Run the installer with a help flag from a command prompt, such as installer.exe /? or installer.exe /help. Many toolkits print their supported switches.
2. Identify the toolkit. Right-click the EXE and check file properties and the temporary files it extracts; Inno, NSIS, InstallShield, and WiX leave recognisable signatures, which then tells you the switch from the table above.
3. Check the vendor’s enterprise or deployment documentation, which almost always lists the supported unattended command.
4. If nothing is documented, monitor the process with Process Monitor while you click through the wizard to learn what it writes, then wrap the install in a script or the PowerShell App Deployment Toolkit so you control the flow.

How should I test the command the way Intune runs it?

A command that works double-clicked in your user session can still fail under Intune, because Intune usually runs as SYSTEM with no interactive desktop. Testing in the wrong context is the single most common reason an app "works on my machine" but fails after assignment. The choice of SYSTEM versus the signed-in user is itself a deployment decision covered in System vs User context in Intune.

To reproduce Intune’s environment, open an elevated command prompt as SYSTEM (for example with PsExec -s -i cmd.exe from the Sysinternals suite) and run your exact install command there. Then read the exit code immediately, because Intune maps that code to success or failure:

installer.exe /VERYSILENT /NORESTART
echo Exit code: %ERRORLEVEL%

Confirm three things during the test: no window or prompt appeared, the process actually exited instead of lingering, and the exit code is one you expect (commonly 0). If the command returns instantly but nothing installed, the switch was probably wrong and the installer printed usage text and quit.

How do silent switches interact with return codes and restarts?

A silent install does not finish the story. Intune reads the installer’s exit code and compares it to its return-code table. By default 0 and 1707 mean success, 3010 means a soft reboot is required, 1641 means the installer initiated a hard reboot, and 1618 means another install is in progress so Intune should retry. This is why /norestart matters: many installers that need a reboot return 3010 instead of restarting the machine themselves, which lets Intune honour your restart behaviour setting rather than rebooting a user mid-task. The full mapping is explained in the guide on return codes and install behavior.

Finally, a silent install completing successfully is not the same as Intune marking the app installed. After the command exits, Intune evaluates your detection rules (MSI product code, a file, a registry value, or a custom script). If the install succeeded but the detection rule points at the wrong path or version, Intune will report the app as not installed and may retry. Treat the silent switch and the detection rule as a matched pair.

What are the most common silent-switch mistakes?

Most failures come from a small set of avoidable errors. Building your packages around predictable, tested commands, as described in best practices for packaging Win32 apps, prevents nearly all of them.

• Assuming /quiet works for every EXE when the toolkit needs /S, /VERYSILENT, or /s /v"/qn".
• Omitting /norestart, so the installer reboots the device instead of letting Intune control restart behaviour.
• Testing only in the user session and never as SYSTEM, hiding context-specific failures.
• Forgetting to quote paths that contain spaces, which breaks the command silently.
• Pairing a correct silent switch with a detection rule that checks the wrong version or path.