MSI files are designed specifically to support silent installation as a built-in feature - you can always skip the GUI. However, some MSI files have design flaws that render the install incomplete in silent mode - which is a serious design error. This problem is described here:
Short Version: How to parameterize msi file from electron builder
- using PUBLIC PROPERTIES and transforms to customize an installation of an MSI package.
Configuring MSI Installations
When it comes to installing an MSI silently, what you need to do is to configure the setup either from the msiexec.exe command line, or by applying what is referred to as a transform to the original MSI file. Both these options are described below in separate sections.
If the MSI file is well-designed you will be able to set PUBLIC PROPERTIES (they are always UPPERCASE) from the msiexec.exe command line or by using a transform file to modify the original MSI. These operations are described below. Public properties are easiest to find in the MSI file's "Property table". Use the MSI tool of your choice to open the *.msi file and navigate to the Property table. There are also some free MSI tools you can use to generate transforms and view (and edit) MSI files: How can I compare the content of two (or more) MSI files? (links towards bottom).
Well-designed MSI setups are fully configurable via these public properties. Badly designed MSI files are not. Badly designed MSI files are best to tweak using transform files (which can make substantial changes to the whole MSI file to apply at install time). Setting public properties can only change whatever is configurable by public properties - as designed by the setup creator. Transforms can change almost anything in the whole MSI file.
In general, all corporate, silent deployment is done using transforms to "beat MSI files into shape" for the corporate standard. It is a very effective tool for corporate deployment and is extensively used.
A couple of links for safe-keeping:
MSI "Features"
MSI is often counterintuitive and somewhat complicated under the hood. However, to over-simplify an MSI file contains one or more "Features" - and these features collectively constitute the "bits of the application" as you put it. Features, in turn, consist of "Components" - which are the atomic units of installation for the whole software - but this is a very technical detail - this answer is about the user-exposed bits of MSI - the features.
Screen Shots: What Features look like in a real MSI package (screen shots).
You can generally find a list of these features by running the setup interactively, and navigate to the customize install dialog (not always present). Features that show up here are the "user configurable" parts of the application that can be chosen for exclusion or inclusion (some are mandatory). You can also find these features by opening an MSI with a capable tool as mentioned above (you can also see links in section 2 below).
Typical features are: Core or Program, Dictionaries, Samples, Plug-Ins, Spell Checker, SDK & Developer Tools (for dev tools), etc... Some features are mandatory (must be installed) - examples above would be Core and Program, others are optional and are not needed for the application to launch (like the dev tools features above). It is possible to make the application install features "on demand" - for example spell checkers when the user initiates a spell check.
In my experience most users want the whole application installed. Many users are very annoyed if Windows Installer pops up unexpectedly and starts installing spell checker components. Frankly very understandable. However, rarely used modular components interesting only to a few users could be made into optional components - especially if system administrators may not want the feature available on their network. This is certainly the case for developer tools - these should not be available to regular users. They tend to be all the rope people need to shoot themselves in the foot.
As mentioned above, there are generally two ways to customize an MSI installation: (1) using msiexec.exe custom command lines, or using (2) transform files.
1: msiexec.exe command line:
The simplest and light-weight way of controlling what features are installed during an installation, is to specify your feature selection using the msiexec.exe command line. There is a whole family of properties used for feature configuration. But, in most cases it is sufficient to specify ADDLOCAL:
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" /qn
The above command line specifies that the features "Program" and "Dictionaries" should be installed locally (feature names are cases-sensitive!). This is generally enough, but you can also specify any features that you want to remove using the REMOVE property in a similar fashion. A special switch is ADDLOCAL=ALL which will install all features in the MSI on the local disk (provided there is not additional logic in the MSI to override this). ADDLOCAL property on MSDN.
A very common thing to define by public properties is the license key for the application. The following command line specifies to install the features "Program" and "Dictionaries" and to apply the serial key "1234-1234":
msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn
As is implied in the description above, the list of customizable properties for each setup is always different. You can find most properties listed in the MSI file's Property table, but it is also possible that some properties can be set that are not defined in the Property table. In most cases this relates to properties being set only from the setup GUI (indicates a setup design error in most cases). All properties should be defined in the property table in a properly authored package.
Look for documentation on the vendor's download page and ask their support for any documents relating to silent installation or large scale deployment. It is quick to do, and answers can be quick if they have standard answer templates. Companies with control of their deployment will always be able to provide this. In my view the ideal way is a one-page PDF which describes different deployment settings. Frankly, give them some heat if they can't provide this ;-).
2: Transforms:
MSI files are essentially SQL-databases wrapped in COM structured storage files (file system within a file). Transform files are "partial databases" constructed via installation tools such as Orca (SDK link), Installshield or Wise, Advanced Installer, etc... (link to descriptions of the different tools). These transforms can customize or override almost all settings or database fields in an MSI - including what "parts of the application" (features) are installed. After creating a transform you specify its application to the MSI at the msiexec.exe command line:
msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn
Windows Installer will then merge the MSI and the transform before installation starts. This is the approach used by large organizations who want full control of how the MSI gets installed. TRANSFORMS property on MSDN.
As mentioned above this is the option that allows all settings in an MSI to be modified. Substantial fixes can be applied to badly designed MSI files to allow reliable deployment. This is done by "application packagers". Their job is to tune all setups to work within
