How to run an msiexec silent install: commands and switches

Windows Installer (MSI) packages are easy to install on one device, but a Windows Installer silent install across hundreds of devices needs the right command. Fortunately, as Windows Installer packages share a standard set of msiexec options, the core commands are the same for every MSI.

With that in mind, you can run msiexec silent install commands across multiple devices. However, as the saying goes, the devil is in the details. Display level, restart behavior, logging, and more can affect an MSI silent install and determine whether it succeeds or fails. And if it fails, nothing appears on screen, so the exit code and log are the only record of what went wrong.

So, how can we properly run MSI silent installs? Let’s explore the switches you need to know, how to install and uninstall silently, how to fix common failures, and more, so you can effectively run MSI silent installs with ease.

The msiexec install command for a silent MSI install

First, let’s look at the msiexec install command and what each part of it means. To cmd install MSI packages, open an elevated Command Prompt and run this msi install cmd:

msiexec /i "C:\Installers\App.msi" /qn /norestart /l*v "C:\Logs\App-install.log"

Of course, if you don’t understand command-line syntax, this means nothing to you. So let’s break it down into more comprehensible pieces:

• /i installs the package. This is the initial command that starts off the process; be sure to put the full path afterward in quotes so any spaces in folder names don't break the command.

• /qn indicates that the command should run with no user interface. You can also use /quiet as an equivalent option.

• /norestart stops Windows Installer from restarting the device after the installation completes, even if the package asks for one. This helps prevent the installation from interrupting work by suddenly rebooting the end users’ devices.

• /l*v writes a verbose log to the path given. Keep in mind that the folder it leads to must already exist.

Make sure you run the command from an elevated Command Prompt, so it doesn’t need to ask for permissions. A silent install can't show a UAC prompt to ask for admin rights; otherwise, it wouldn't be silent.

What if you’re running PowerShell? There’s a similar script for that, with a few key differences:

$p = Start-Process msiexec.exe -ArgumentList '/i "C:\Installers\App.msi" /qn /norestart /l*v "C:\Logs\App-install.log"' -Wait -PassThru $p.ExitCode

In this case, the -Wait parameter holds the script until the install finishes, and -PassThru returns the exit code.

MSI switches for silent and unattended installs

Next, let’s break down the MSI switches you’ll need to know for silent and unattended installs. Microsoft documents the full list in its standard installer command-line options. Keep in mind that msiexec options aren’t case-sensitive, so whether you enter /QN or /qn, the end result will be the same. The /quiet switch is what most people mean by an msiexec quiet install, and Microsoft treats it as the same thing as /qn.

We can break the switches down into three groups: Display, Restart, and Logging. Each is an important part of the installation process and determines how the command runs.

If you’re deploying across fleets, /qn (or /quiet) with /norestart is a common pairing, while restarts are handled by the deployment tool. You’ll also want to use /passive for installations where the user should see progress.

Keep in mind that msiexec has no /s or /silent switch, although EXE installers do. EXE installers also lack a shared standard, so they can be a bit more complicated.

How to set MSI properties and transforms in a silent install

When you want to customize an application package, you’ll want to know how to set MSI properties and transforms. Unless the command line sets these customizations, a silent install will use the package defaults, so knowing what to set is important.

When you set properties, these will go after the switches as PROPERTY=VALUE. Keep in mind that Windows Installer treats property names as uppercase, but the value retains its case, and values that contain spaces should go in quotation marks. As property names will vary by package, you’ll want to check the vendor’s deployment documentation for them.

For instance, setting MSI properties may look something like this:

msiexec /i "C:\Installers\App.msi" /qn INSTALLDIR="D:\Apps\App" /l*v "C:\Logs\App-install.log"

Then we have transforms. A transform (.mst file) holds a set of changes to the package so they can be applied directly rather than adding to the command line. You can use the TRANSFORMS property to add them like so:

msiexec /i "C:\Installers\App.msi" TRANSFORMS="C:\Installers\App.mst" /qn /l*v "C:\Logs\App-install.log"

How to silently uninstall an MSI

When you want to silently uninstall an MSI, that should be just as simple as installing it. Often, IT teams need to remove packages, whether to make room for a version change, clean up devices, or remove a failed install.

The /x command removes a package while accepting the same display, restart, and logging switches as install commands. This works with either the original MSI file or the product code, though the latter helps when the original MSI is no longer on the device.

A silent uninstall command should look like this:

msiexec /x "C:\Installers\App.msi" /qn /norestart /l*v "C:\Logs\App-uninstall.log"

Or:

msiexec /x {PRODUCT-CODE-GUID} /qn /norestart /l*v "C:\Logs\App-uninstall.log"

How to read msiexec exit codes

When you’re working with msiexec, you’ll want to understand the exit codes. When msiexec finishes a task, it returns an exit code that scripts and deployment tools read to see whether the installer worked, something went wrong, or a reboot is required. Microsoft lists every code in its MsiExec error messages reference.

The msiexec exit codes are:

In some cases, a script will treat any non-zero code as a failure. In these cases, it will flag 3010 and 1641 codes as failures, even though the app installed properly. As such, you’ll want to check the success code before marking an install as a failure; sometimes it just takes a restart to complete the installation.

Why a silent MSI install fails and how to fix it

Sometimes silent installs fail. When this happens, you’ll want to know why and how to fix it. While a failed silent install doesn’t show the user anything, you can investigate these for more information:

1. The install wasn't run with admin rights

A silent install still needs admin rights to run, but it can’t prompt users if permissions are missing. Make sure you run the installs from an elevated Command Prompt or a deployment tool with admin rights so you don’t have to worry about missing permissions.

On Windows 10, Error 1925 can indicate missing admin rights.

2. The log folder doesn't exist

Windows Installer won’t create the folder for a log file. If the path in /l*v points to a folder that doesn’t exist, the log file will fail. Make sure you’re logging to a folder that always exists, or create a folder if necessary.

3. Another installation is already running

Windows Installer can only run one installation at once. If you get exit code 1618, that means the installer is busy with another application. Fortunately, that means you just need to wait for the other install to finish, then retry the installation.

4. The install hit a fatal error

If the install encountered an error, the exit code alone won’t explain what it is. In this case, you’ll want to check the verbose log for more details. This is why you want to include /l*v in every silent install command, so you can check the logs should something occur.

Running an msiexec silent install across many devices

If you’re managing multiple remote devices across a company environment, you’ll need a way to silently install applications and updates. The same app may need to reach hundreds of devices, so a command that works on one test machine is only the start.

You can run an msiexec silent install across multiple devices in several ways, including:

Deploying an MSI through Microsoft Intune

If you’re using Microsoft Intune, you can use it to deploy an MSI in two different ways.

Intune can deploy an MSI as a line-of-business (LOB) app, which accepts only one command-line argument. If you need more, then you’ll want to use Win32 app management, where the MSI is wrapped into a .intunewin file and your msiexec command becomes the app’s install command.

Keep in mind that mixing Win32 and LOB app installs during Windows Autopilot enrollment can lead to installation failures, since they both use the Trusted Installer service at the same time.

Running installs remotely with scripts or endpoint management

If you’re not using Intune, you can run commands through PowerShell, remote access sessions, or an endpoint management tool. For instance, Splashtop AEM (Autonomous Endpoint Management) can run scripts and automate patch management across managed endpoints, including silent installs and updates scheduled for convenient times. For a full walkthrough, see our guide on how to silently install software on remote computers.

Where the work piles up

Running the command is the easy part. The number of apps and the work required for each can make it difficult.

Each app needs its own properties and transforms, must be tested on a clean device, needs a way to confirm the install works, and so on. This has to be repeated for every new version. Without automation, that creates a constant stream of manual work, and an untested package can lead to failures across devices.

Splashtop Agentic Packr automates that packaging and testing work for every app and version.

Build tested silent install packages with Agentic Packr

Building, testing, and silently installing packages doesn’t have to be a time-consuming manual process. With Splashtop Agentic Packr, you can take the burden off of IT teams with intelligent, automated packaging and installation.

Splashtop Agentic Packr is an AI-powered app packaging tool that analyzes installers, builds packages with install logic included, and tests them on a clean virtual machine. It also writes the detection rules that confirm each install worked. Each package undergoes checks and security scans to ensure it works properly, with a QA scorecard and logs so IT teams can review everything before it’s published.

Whenever a new update comes out, Splashtop Agentic Packr can build the updated package automatically, saving IT teams the need to manually handle every release. Splashtop Agentic Packr can build Intune packages and publish them to Intune, or bundle installs to run through SCCM or manually on any Windows device, making it a flexible tool for silent installs and updates. It also lets you control what end users see, including restart prompts, install deferrals, and grace periods.

Splashtop Agentic Packr builds and tests the packages, and Splashtop AEM can run deployments and scripts across your endpoints.

See how Splashtop Agentic Packr builds, tests, and publishes silent install packages for every app.