Silent install EXE: how to find and use the right switches

Silent installs help roll out applications and updates across devices without interrupting users or requiring every employee to manually approve and install it. However, IT teams may run into difficulties when trying to run a silent install from an EXE installer.

MSI installers share a set of silent switches through msiexec, which makes silent-install commands easier to deploy, but EXE installers lack that consistency. The switch will vary based on the tool that built the installer, so while the /S command may work on one EXE, it could do nothing on the next. The switches in this guide work the same way on Windows 10 and Windows 11.

With that in mind, let’s explore silent install EXE commands, some common switches, how to identify the installer framework, and how to handle silent installs and the obstacles they may face.

Common switches to silently install EXE files

The silent install switch you need will depend on the framework that built the EXE. While there are several variations out there, it is possible to identify the installer framework and silent install command early on.

Common silent install switches include:

Even once you’ve found your silent install switch, be sure to test it before attempting to deploy across multiple devices. A wrong switch can leave an install stuck on a prompt no one can see, so a single-machine test is worth the time.

Step 1: Identify which tool built the installer

Before anything else, you’ll want to identify the framework the installer uses. An EXE installer is typically a wrapper built with a packaging tool, such as InstallShield, NSIS, or Advanced Installer. Each tool has its own switches, so identifying it helps narrow the options to one or two.

You can identify the tool in a few ways:

• Run the installer with /? or /help: A help window is often the easiest way to identify the tool, as many installers list their options or name the tool. Microsoft’s WinGet documentation recommends running an installer with -? to discover its silent switches.

• Look at the setup wizard: The setup wizard can often name the packaging tool. You can launch it normally, then check the title bar, branding, or About text to see if it’s listed there. Be sure to cancel before installing, since there are a few more steps you’ll want to follow first.

• Check the app's WinGet manifest. If the app is in the Windows Package Manager community repository, you can check its manifest records. This often includes an installer type, such as Inno, Nullsoft, WiX, Burn, or MSI.

If none of these methods work, you can check the vendor’s deployment documentation for more information.

Step 2: Find the silent install switches for the EXE

Next, you’ll need to find what the silent install switches are. There are a few ways you can approach this, including:

Check the vendor's deployment documentation

Vendors often include silent install options, especially if they support enterprise deployment. Checking the documentation can point you directly to the silent install switch, so it should be the first place you check. The documentation will often tell you what the switch is and may also include custom options the vendor added, such as license keys or feature selection.

Read the installer's help output

If the documentation isn’t clear, you can check the installer’s help output. To do this, run the EXE with /? or /help from a command prompt, and if a usage window appears, it should list the supported options. If it doesn’t have a help output, you’ll need to cancel the installation and try another method.

Look up the app's WinGet manifest

If an app is in WinGet’s community repository, it’s required to support silent installation. You can search the winget-pkgs repository on GitHub to find the installer type and silent switches recorded for that app.

Try Universal Silent Switch Finder as a last resort

If all else fails, the Universal Silent Switch Finder is a free legacy utility that inspects an EXE and suggests a switch for its installer type. However, it has limitations: its original site is no longer available, and it can’t find switches for custom installers that don’t use a known framework. As such, if you need to use it, make sure you download it from a trusted source and test the suggested command.

Silent install switches by installer framework

Now let’s look at some of the silent install switches you may encounter. Knowing the type of installer framework you’re using can make it easier to identify the install switches you need, so this list can help make finding the switches easier:

InstallShield silent install

The InstallShield silent install method can depend on the project type that built the setup.exe. This includes:

• Basic MSI projects: These run setup.exe /s /v"/qn" without using a response file. No space is allowed between /v and its value, so /v"/qn" works but /v "/qn" doesn’t. You can also pass MSI properties inside the /v quotes, for example: setup.exe /s /v"/qn INSTALLDIR=D:\Destination".

• InstallScript and InstallScript MSI projects: These need a response file. Run setup.exe /r once to record your answers in a setup.iss file, then run setup.exe /s to play them back silently. For these, you’ll want to use /f1 to set the response file path and /f2 to set the log path, with both as absolute paths.

Inno Setup

For Inno, you can use the /SILENT command to hide the wizard but still show a progress window, or /VERYSILENT to hide everything. You can also suppress message boxes with /SUPPRESSMSGBOXES or prevent automatic restarts with /NORESTART.

For example, a silent install using Inno could look like: setup.exe /VERYSILENT /SUPPRESSMSGBOXES /NORESTART /LOG="C:\Logs\app.log".

Keep in mind that some message boxes can’t be suppressed, and /DIR= needs a fully qualified path to work.

NSIS (Nullsoft)

With Nullsoft, you can use the /S command to run a silent install. Keep in mind that NSIS options are case-sensitive, so the S must be uppercase. You can set the install folder using /D= as the last option without quotes (even if the path has spaces).

For example, you can run setup.exe /S /D=C:\Program Files\App.

Installer authors can override these defaults, so if a vendor’s documentation provides different commands, you’ll want to use those.

WiX Burn bundles

Burn bundles are EXEs that chain several packages, typically MSIs. Be sure to run the bundle with /? to confirm its options, since they can be customized.

A WiX Burn bundle may look like: setup.exe /quiet /norestart /log C:\Logs\app.log.

Advanced Installer EXEs

Advanced Installer EXEs can use /exenoui to hide the wrapper’s interface, followed by msiexec options to apply the command to the MSI inside. This could look something like: setup.exe /exenoui /qn /norestart.

How to install an EXE silently from the command line and PowerShell

Command line and PowerShell are two of the most common ways to install an EXE. If you want to run a silent install, you can do so by following a few simple steps:

From Command Prompt

To silently install an EXE from the command line, run Command Prompt as an administrator when the install applies to all users. From there, change to the installer’s folder and run the EXE with its switches. Be sure to put the path in quotes whenever it contains spaces.

Keep in mind that some setup.exe files hand off to a second process and return to the prompt before the install finishes. In these cases, you’ll want to use start /wait so the prompt waits until the install finishes. InstallShield Basic MSI setups also accept /w.

From PowerShell

If you’re using PowerShell, you can use Start-Process with -ArgumentList, -Wait, and -PassThru, then read the exit code from the returned process object. Microsoft recommends passing all arguments as a single ArgumentList string, including any required quote characters.

For instance, a PowerShell command may look something like:

$p = Start-Process -FilePath "C:\Installers\setup.exe" -ArgumentList "/VERYSILENT /SUPPRESSMSGBOXES /NORESTART" -Wait -PassThru

$p.ExitCode

Handle restarts and exit codes before you deploy

Many updates or installations require a reboot to complete successfully. However, silent installs can complicate this. If a silent install reboots a user’s computer mid-workday, it can cause interruptions. At the same time, if the installation reports success when the device still needs a reboot, it can also cause issues and leave pending updates marked as completed.

This brings us to exit codes. An exit code is the number an installer returns when it finishes, which scripts and deployment tools read to identify if the install succeeded, failed, or needs a restart. These codes are standardized for MSI-based installations (0 for success and 3010 for success with a restart required) but can vary with EXE frameworks.

There are a few key points to keep in mind when handling restarts and exit codes:

• Inno Setup can reboot without warning: If a restart is needed and /NORESTART isn't used, the /SILENT command will still show a "Reboot now?" prompt, whereas /VERYSILENT restarts the machine without asking. You’ll want to pair /VERYSILENT with /NORESTART to ensure it’s installed without interruption, although users will still need to restart if the install requires it.

• Inno Setup returns 0 even when a restart is needed: Sometimes an installation is reported as completed even if it still needs a restart. You can add /RESTARTEXITCODE=3010 to the command so your deployment tool can see when a restart is pending.

• InstallShield Basic MSI and Advanced Installer setups pass msiexec options through: Adding /norestart inside the msiexec portion of the command can suppress restarts, so the device doesn’t reboot unexpectedly while the user is at work.

• Test the exit code on one machine. Make sure to test the command before deploying the update. Run the command from PowerShell, read the exit code, and confirm what it returns for success and for a pending restart before you configure your deployment tool.

In Intune, exit codes map to return code types, and what each code does depends on the app’s device restart setting. With “Determine behavior based on return codes,” a hard reboot code restarts the device immediately, while a soft reboot code tells the user a restart is needed. As such, you’ll want to make sure the code your installer returns matches what Intune expects.

Troubleshoot common EXE silent install problems

You may encounter some issues or difficulties when attempting a silent install. Common EXE silent install problems include:

The installer ignores the silent switch

If the installer ignores the silent switch, it may mean the switch belongs to a different framework, or the case is wrong. Be sure to double-check the vendor’s documentation, confirm the framework, and make sure everything is spelled correctly. For instance, NSIS accepts only uppercase /S, so if you forgot to capitalize, that would make a difference.

The install hangs and never finishes

Sometimes, if the install doesn’t finish, it means it’s waiting for input that no one can see. For instance, if an Intune install waits past its timeout (60 minutes by default), it’s marked as failed. Common causes include a few Inno Setup message boxes that /SUPPRESSMSGBOXES can’t hide, and InstallShield prerequisites that /s doesn’t make silent.

The install fails when a path has spaces

This is another instance where a typo in the command can make all the difference. Frameworks often have different quoting rules, and using the wrong type of quotation marks or spaces can make an installation fail. For instance, NSIS’s /D= must come last and can’t use quotes, even when the path has spaces, whereas InstallShield needs escaped quotes inside the /v value.

There's no log to show what went wrong

What if something goes wrong and there’s no clear indication of why? If you didn’t turn logging on before testing, you may not be able to determine the cause. Make sure you turn on logging before you test and connect the logs to an existing folder. This uses the /LOG="path" command for Inno Setup, /debuglog"path" for InstallShield setup.exe, and /log for WiX Burn bundles.

The EXE has no silent install option

Some EXEs don’t offer a silent install option at all. When this happens, check whether the vendor offers an MSI version of the installer that supports standard silent switches. If they don’t, you may need to repackage the EXE, which requires a bit of specialist work.

Deploy a silent EXE install with Microsoft Intune

If you’re using Microsoft Intune, there are a few Win32 app settings you’ll want to get right when deploying a silent EXE install. Intune deploys EXEs as Win32 apps, with the installer and supporting files wrapped into a .intunewin file. The file is then uploaded with an install command, uninstall command, and detection rules. Since Intune doesn’t support interactive installations, the install command must be fully silent.

These commands include:

• Install command: the EXE name followed by its silent switches, as tested. Note that Intune can also accept a PowerShell script in place of a command line.

• Uninstall command: when and how to uninstall the application. Keep in mind that environment variables aren't expanded here, so you’ll want to use a wrapper script if the uninstall needs them.

• PowerShell in command fields: if a command calls powershell.exe, Intune launches the 32-bit version of PowerShell, which Windows redirects to 32-bit system folders. To run 64-bit PowerShell instead, use %SystemRoot%\Sysnative\WindowsPowerShell\v1.0\powershell.exe.

• Install behavior: when setting install behavior, you’ll want to choose System for installs that need admin rights. If a user-context install requires admin privileges the user doesn't have, it will fail.

• Timeout: Intune waits 60 minutes by default before marking the install as failed, but this can be adjusted to as much as one day.

• Return codes: Intune adds default codes when you create the app. You can add custom codes your installer returns, such as the /RESTARTEXITCODE value set for Inno Setup. A retry code makes Intune try three times, with each attempt spaced five minutes apart.

• Detection rules: at least one rule is required so Intune can confirm the app is installed. Be sure to use a file, registry, or script rule, since EXEs don't have an MSI product code.

Why EXE silent installs get hard across an app catalog

At this point, it may feel like EXE silent installs are more complex than they should be. Each EXE needs its framework identified, switches confirmed, restart and exit code behavior tested, detection rules written, and so on. Then, when a new update comes out, the process begins anew.

Repeat this for every single app, and research and testing can become a hefty workload.

AI-powered packaging tools can take on much of that work, even across large environments.

Splashtop Agentic Packr is an AI-powered application packaging tool that automates the path from installer to Intune. The AI agent reads the installer, builds the package, and tests it before anything reaches users, and admins can review the results first.

With Splashtop Agentic Packr, you can:

• Analyze installers and build packages: Splashtop Agentic Packr automatically analyzes installers and builds a PSADT package with the install logic, so admins don't need to write install scripts for every new app. Because packages are built on PSADT, admins can open, review, and adjust them as needed.

• Test before rollout: Every package is tested on a clean virtual machine and security scanned to ensure it works as intended. Admins receive a QA scorecard and logs to review before publishing, so they have the final say.

• Set detection rules and Intune packaging: Splashtop Agentic Packr writes detection rules, builds the Intune package, and publishes it to Intune.

• Detect new versions: When new app versions are released, Agentic Packr detects them and builds updated packages automatically, saving IT teams even more time.

Additionally, you can use Splashtop Agentic Packr with Splashtop AEM (Autonomous Endpoint Management) to improve the deployment even further. Splashtop Agentic Packr can build and test the packages, which Splashtop AEM can then automatically deploy across devices throughout an organization.

Spend less time on switches and more on rollouts

Every EXE framework has its own switches, restart behavior, and more. Identifying each one and getting them right can make silent installs difficult, but it’s also necessary to ensure each one is safe to deploy.

Splashtop Agentic Packr turns installers into tested, Intune-ready packages without manual scripting, so IT teams spend less time researching and testing each new app and update.

Want to see how Splashtop Agentic Packr can turn installers into tested, ready-to-deploy packages? Learn more and see it in action today.