What’s the Big Deal?
As noted in part 1 of How to silently deploy an EXE, *.exe files are synonymous with software installation and are easily the most ubiquitous means of packaging software for distribution. This means that vendors and developers have had time to work out the kinks, settle in on an accepted industry standard, innovate, provide clear documentation, right?
If you consider dozens of disparate, proprietary or open-source, and poorly documented methods of packaging their software into a single executable a “standard,” then they’ve got that in spades!
Let’s do a quick bit of fun trivia:
Which one of the following switches can be used to indicate a silent install for setup.exe?
/s
/S
/silent
/verysilent
/s /a /s /sms /f1c:\temp\setup.iss
/s /a /s /v"/qb"
Ready?
The answer is:
All of the above! Or none of them. Or some of them in weird ways that make you stare at them and think “what have I done to deserve this?”.
If you’re down for a wild, wacky, and exciting learning experience, buckle up! If you just want to dive in and get to work without all the fluff, scroll down to the final example.
Quick Note:
Because the vast majority of installers we all use day-to-day are created with older
versions of these solutions, that’s where we’ll be focusing our attention. The Not So G(old) Standard - Installshield for MSI
InstallShield for MSI is InstallShield’s “answer” to Microsoft’s MSI standard. It allows for the creation of MSI files which can be released as-is, or released with an accompanying exe file. This method is referred to as a “Basic MSI” package. Here are the most common switches for this method:
/v Passes parameters to MSI package.
/s Causes setup.exe to be silent.
/l Specifies the setup language.
/a Performs administrative installation.
Also passes switches to underlying exe files
/j Installs in advertise mode.
/x Performs setup uninstall.
/f Launches setup in repair mode.
/w Setup.exe waits for the installation to finish before exiting.
/qn MSI parameter that causes everything but setup.exe to be silentComplicating the Standard
When dealing with an InstallShield for MSI exe, you combine custom switches with the standard MSI switches:
Setup.exe /s /v"/qn"Here’s the low-down:
All InstallShield custom switches need to come first, and /v has to be at the end.
/s and /v are usually all you’ll need, but not always.
/s tells Setup.exe to show no UI (be silent).
/v passes anything within the quotes to the underlying MSI via msiexec.
Note the lack of a space between /v and “” (the quotes) here - this is important. Usually.
Simple enough. Until it’s not. We all know exe files are basically just fancy archives. What happens if the initial setup.exe is actually just extracting a different exe that actually handles interacting with an MSI?
This is more common than you may think, with developers often using newer versions of InstallShield to repackage updates to existing products or including older redistributables with their products.
In a situation like that (let’s say there is 1 additional .exe extracted), you would need to provide the necessary switches for each subsequent .exe called:
Setup.exe /s /a /s /v"/qn"The first /s tells the installer (original exe) to extract and run silently. The /a tells the original exe to provide the remaining switches to the underlying exe. The second /s tells the second setup.exe to run silently.And finally, the /v"/qn" tells it to pass /qn to msiexec (for the MSI).
That’s it in a nutshell. As with all packages regardless of the framework, the complexity of switches will vary and you will always run into some packages that just cannot be completely silent.
Now to put it all together into a coherent and flexible package in Deploy.
Put it All Together
Here is an example below of how you would set this up in PDQ Deploy at the most basic level.
Setup.exe /s /v"/qn"Conclusion
There you have it. This is just one way that an EXE can be deployed, as long as it was made with InstallShield’s MSI offering, it does not have custom dialogue boxes that fail to follow standards, and the developer builds in proper automation support. And even then…well, that’s enough doom and gloom for now.
In the words of the unintentionally wise and topical Brian Fantana:
“60% of the time, it works every time”. Stay strong and remember, if you use PDQ Deploy your chances of success increase substantially!
