Applications vary significantly in size and complexity. Some have large storage requirements and take forever to install (thanks AutoCAD), while others are small and install in seconds. Some can even run in a portable mode, which can then be launched from a flash drive.
Regardless of whether you’re installing a massive productivity suite or a small portable application, installations generally come in two forms, an EXE or an MSI file.
What’s the Difference Between MSI and EXE Files?
Most sysadmins will look at an MSI file or an EXE file and instantly know that the file will either install something or run something. When downloading programs from the web, you’ll often have the choice to download the files as an EXE or an MSI. While they share some similarities in their purpose, there are many differences between them. The key difference I want to focus on is that EXE files are highly customizable by the developer, while MSI installers are standardized.
When you install an MSI file, you can be assured that certain parameters will exist, such as the silent parameter /quiet or /qn. You can get a list of the supported parameters in PowerShell or CMD by typing msiexec.exe /?. This command will display the usage statement.
EXE’s, on the other hand, can be configured however the developer sees fit. They may include a usage statement, or they may not. They may have used different silent switches like /silent, /s, or /S, or they may or may not accept installation parameters at all. Because EXE’s aren’t standardized like MSI files, deploying them to our users becomes more difficult, especially if we need to ensure the installation runs silently and doesn’t restart end-user computers.
Since we can’t rely on all EXE files using the same installation parameters, we need to do some detective work to ensure our installations go off without a hitch. So grab your deerstalker cap and your gourd Calabash pipe, because the game is afoot, Watson.
Displaying the usage statement is my go-to method for finding silent installation parameters. The problem is that not all EXE files are created equal, and not all EXE files include a usage statement. Thankfully, viewing the usage statement, if one exists, is pretty straightforward. Here are a couple of different methods you can use to view the usage statement.
The first, and my preferred method is to drag the executable file into the Run window. Open the folder containing the EXE file and launch the Run window by typing run into the Windows 10 search bar and hitting enter. Next, drag the EXE file into the Open field of the Run window. Doing so will bring up the path to the executable. Add /? to the end of the path, making sure to include the space before the backslash and click OK.
After clicking OK, you may be prompted with a User Account Control window. If a UAC prompt opens, click Yes.
After clicking Yes, if the EXE comes with a usage statement, it should then be displayed. If the EXE doesn’t come with a usage statement, the application may just start to install. Here is the usage statement for the Silverlight executable.
An alternative to using the Run window is to use CMD or PowerShell. If you grew up with Mavis Beacon and love typing, you could launch CMD or PowerShell and type out the path to the executable file followed by /?. If you’re like Lex and don’t like typing, there are easier ways of doing things. Just as with our example using the Run command, you can also drag and drop the file into the CMD or PowerShell window and append the /? to the end of the path.
Make sure you don’t launch CMD or PowerShell with Admin rights, or this won’t work.
Another trick you can use if you don’t like to drag your files everywhere is to hold the Shift key and right-click on the executable, and click Copy as path. Then you can just paste the path in Run, CMD, or PowerShell and add /? to the end of the path.
Is there anything Google can’t do? Probably, but the list of things it can’t do gets shorter and shorter every day. Today, it informed me how many licks it takes to get to the center of a Tootsie Pop. If you were wondering, it takes 364 licks. It can also be a good source of information for install parameters. Simply search Google for “silently install (application_name)” and you’ll find loads of information to help you out. As an example, I searched for “silently install Firefox,” which lead me to this support page, which contained this information:
This information is usually pretty easy to find for most mainstream applications. However, this isn’t always the case. That’s when you need to resort to method number three, using a program designed to return silent switches.
Universal Silent Switch Finder (USSF) is about as accurate a program name as I’ve ever seen. If you haven’t guessed already, Universal Silent Switch Finder attempts to detect the silent switch or parameter for an executable. Simply launch the program and point it to an executable file, and it’ll take care of the rest.
Full disclaimer, I’ve had mixed results using USSF. Some apps simply don’t have a silent switch option, in which case USSF was never going to find anything. Another possible explanation for my mixed results could be that USSF hasn’t been updated in quite some time. Regardless, when you need to find a silent parameter, and you’ve already tried the other resources, USSF is worth a shot.
One more option when finding silent parameters is to extract the executable using 7-Zip to see if any other MSI or EXE files within the executable can help us get the application installed silently. If you have 7-Zip installed, you can explore the contents of an executable by right-clicking on the EXE file and selecting 7-Zip > Open archive.
If you’ve exhausted all of your resources and still can’t find a silent install option for an application you need to deploy, there is a last resort option you can consider. AutoHotKey is an application that can automate tasks by mimicking clicks and button presses. It can launch EXE files minimized and still run through interactive menus without requiring user interaction. This process is scripted in AutoHotKey, after which it can be deployed to end-users.
Again, this is a last resort option. If you’re not familiar with AutoHotKey, things can go south quickly if the script you deploy isn’t perfect. Check out this video to learn more about AutoHotKey and see this process in action.
Having the ability to install applications silently is necessary for any deployment on a network. I can’t imagine the chaos that would ensue if an interactive application deployment was pushed out to hundreds of users that required their input. PDQ Deploy requires deployments to run silently for this very reason.
If you’re tired of tracking down silent parameters and building packages, let PDQ Deploy do it for you. PDQ Deploy takes the guesswork out of deployments by providing pre-built packages for hundreds of the most common applications available today. Check it out with a free trial of PDQ Deploy or schedule a demo to learn more!