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 207 that render the install incomplete in silent 206 mode - which is a serious design error. This 205 problem is described here:

• : Uninstall from Control Panel is different from Remove from .msi (Silent vs Interactive Installation - technicalities 204 and practicalities)

• There is also a section on it in this general description of common MSI problems seen in the real world (Common MSI Problems - general problems 203 and anti-patterns)

Short Version: How to parameterize msi file from electron builder - using PUBLIC PROPERTIES and 202 transforms to customize an installation 201 of an MSI package.

• Here is sort of an escalation model of how I deal with bad or difficult deployment packages
• Itninja.com Software Packaging Tips Library
• What is the best tool kit to transform .msi into .exe?

Configuring MSI Installations

When it comes to installing 200 an MSI silently, what you need to do is 199 to configure the setup either from the msiexec.exe 198 command line, or by applying what is referred 197 to as a transform to the original MSI file. Both 196 these options are described below in separate 195 sections.

If the MSI file is well-designed 194 you will be able to set PUBLIC PROPERTIES 193 (they are always UPPERCASE) from the msiexec.exe 192 command line or by using a transform file 191 to modify the original MSI. These operations 190 are described below. Public properties are 189 easiest to find in the MSI file's "Property table". Use the MSI tool of your choice to open the *.msi file and 188 navigate to the Property table. There are 187 also some free MSI tools you can use to generate transforms 186 and view (and edit) MSI files: How can I compare the content of two (or more) MSI files? (links towards 185 bottom).

Well-designed MSI setups are fully 184 configurable via these public properties. Badly 183 designed MSI files are not. Badly designed 182 MSI files are best to tweak using transform 181 files (which can make substantial changes 180 to the whole MSI file to apply at install 179 time). Setting public properties can only 178 change whatever is configurable by public 177 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 176 is a very effective tool for corporate deployment 175 and is extensively used.

A couple of links 174 for safe-keeping:

• Can the resulting command line be determined after running an .msi installer?
• How to build MSI package on a linux server?
• Microsoft Installer command line string parameter not working?
• Change Program Name and Shortcut Title during installation

MSI "Features"

MSI is often counterintuitive 173 and somewhat complicated under the hood. However, to 172 over-simplify an MSI file contains one or 171 more "Features" - and these features collectively 170 constitute the "bits of the application" as you put it. Features, in 169 turn, consist of "Components" - which are 168 the atomic units of installation for the 167 whole software - but this is a very technical 166 detail - this answer is about the user-exposed 165 bits of MSI - the features.

Screen Shots: What Features look like in a real MSI package (screen shots).

You can generally 164 find a list of these features by running 163 the setup interactively, and navigate to 162 the customize install dialog (not always 161 present). Features that show up here are 160 the "user configurable" parts of the application 159 that can be chosen for exclusion or inclusion 158 (some are mandatory). You can also find 157 these features by opening an MSI with a 156 capable tool as mentioned above (you can 155 also see links in section 2 below).

Typical 154 features are: Core or Program, Dictionaries, Samples, Plug-Ins, Spell Checker, SDK & Developer Tools (for 153 dev tools), etc... Some features are mandatory 152 (must be installed) - examples above would 151 be Core and Program, others are optional and are not 150 needed for the application to launch (like 149 the dev tools features above). It is possible 148 to make the application install features 147 "on demand" - for example spell 146 checkers when the user initiates a spell 145 check.

In my experience most users want the whole application installed. Many users are very annoyed if Windows 144 Installer pops up unexpectedly and starts 143 installing spell checker components. Frankly 142 very understandable. However, rarely used modular components interesting 141 only to a few users could be made into optional components - especially 140 if system administrators may not want the 139 feature available on their network. This 138 is certainly the case for developer tools - these should 137 not be available to regular users. They tend 136 to be all the rope people need to shoot 135 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 134 (2) transform files.

1: msiexec.exe command line:

The simplest and light-weight way 133 of controlling what features are installed 132 during an installation, is to specify your 131 feature selection using the msiexec.exe command line. There 130 is a whole family of properties used for 129 feature configuration. But, in most cases 128 it is sufficient to specify ADDLOCAL:

msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" /qn

The above command 127 line specifies that the features "Program" and 126 "Dictionaries" should be installed locally 125 (feature names are cases-sensitive!). This is generally enough, but you can 124 also specify any features that you want 123 to remove using the REMOVE property in a 122 similar fashion. A special switch is ADDLOCAL=ALL which 121 will install all features in the MSI on 120 the local disk (provided there is not additional 119 logic in the MSI to override this). ADDLOCAL property on MSDN.

A very 118 common thing to define by public properties 117 is the license key for the application. The following command 116 line specifies to install the features "Program" and 115 "Dictionaries" and to apply the serial key 114 "1234-1234":

msiexec.exe /i myinstaller.msi ADDLOCAL="Program,Dictionaries" SERIALKEY="1234-1234" /qn

As is implied in the 113 description above, the list of customizable properties for each setup is always different. You can find most properties 112 listed in the MSI file's Property table, but 111 it is also possible that some properties 110 can be set that are not defined in the Property 109 table. In most cases this relates to properties 108 being set only from the setup GUI (indicates 107 a setup design error in most cases). All 106 properties should be defined in the property 105 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 104 is quick to do, and answers can be quick 103 if they have standard answer templates. Companies with control of their deployment will always be able to provide this. In 102 my view the ideal way is a one-page PDF 101 which describes different deployment settings. Frankly, give 100 them some heat if they can't provide this 99 ;-).

2: Transforms:

MSI files are essentially SQL-databases wrapped in COM structured storage files (file system within a file). Transform 98 files are "partial databases" constructed 97 via installation tools such as Orca (SDK link), Installshield or Wise, Advanced Installer, etc... (link 96 to descriptions of the different tools). These 95 transforms can customize or override almost 94 all settings or database fields in an MSI 93 - including what "parts of the application" (features) are 92 installed. After creating a transform you 91 specify its application to the MSI at the 90 msiexec.exe command line:

msiexec.exe /i myinstaller.msi TRANSFORMS="mytransform.mst" /qn

Windows Installer 89 will then merge the MSI and the transform 88 before installation starts. This is the 87 approach used by large organizations who want full control 86 of how the MSI gets installed. TRANSFORMS property on MSDN.

As mentioned 85 above this is the option that allows all settings 84 in an MSI to be modified. Substantial fixes 83 can be applied to badly designed MSI files 82 to allow reliable deployment. This is done 81 by "application packagers". Their 80 job is to tune all setups to work within 79 the corporate standard. They can be among 78 the most knowledgeable MSI specialists around 77 - they see a lot of weird stuff in MSI files.

Many 76 tools can be used to create a transform, here 75 is a description of such tools inside the 74 more technical context of comparing MSI 73 files. Just jump straight to the list of 72 free tools at the bottom: How can I compare the content of two (or more) MSI files?

Anti-Patterns Vs The Corporate Benefits of Windows Installer:

Windows Installer has many design quirks and may be particularly annoying for developers. Admittedly 71 there are some issues that border on anti-patterns.

Potential Anti-Patterns

• Difficult multi-instance installations
  • Relatively common requirement, especially for service installations
• counter-intuitive file overwrite rules (symantec)
  • strange rules, especially for non-versioned files
  • an insane feature to force overwrite all files (REINSTALLMODE = amus)
    • can downgrade shared files system-wide
    • can cause inconsistent version estate since an old package can be installed after a newer one and downgrade only some of the shared files
    • can downgrade or wipe-out settings in non-versioned files (and registry settings)
    • can cause a significant increase in the number of requested reboots due to attempts to needlessly replace in-use files of the same version.
    • there are several further issues that are quite specific. One day I will write them all up
• unexpected reset user data in the registry after upgrades
  • This is extremely problematic. If you experience this it is not you, it is the technology
  • Often seen with service credentials logins and serial keys
  • Some techniques to avoid this problem
    • avoid writing ANY HKCU registry keys from your setup, write them from your application instead. Your setup will now never interfere with them - it has no knowledge of the values at all.
    • putting registry data in a feature of its own (should prevent problems on self-repair)
    • install registry data via a component with empty component GUID (will then not ever be rewritten during repair or self-repair)
    • set component flag to never overwrite if key-path exists.
    • write HKLM data (such as license keys) to the registry using a custom action instead (this has other problems, but will give you complete control of when data is written - in what installation mode)
    • make darn sure you keep a stable registry key path. Set a flag value KeyPath = 1 and never change it - and crucially - don't change the component GUID either
    • never set REINSTALLMODE to "amus" - certainly not hard code that value in the property table.
    • there are further tricks and rules of thumb, if only I could remember them all off the top of my head :-).
• complex upgrade mechanism
  • minor upgrades has a lot of limitations and restrictions
  • major upgrades have other challenges (reset registry data, missing files after install, self-repair for COM files after install, etc...)
• lackluster GUI features
  • not rocket science, but somewhat complex
  • lacking events and features to implement a properly smooth GUI
• shockingly complicated patching
  • extremely difficult to use effectively
  • not recommended for use except as a "hotfix" - i.e updating a couple of files or fixing a specific MSI file error in the installed setup's uninstall sequence.
  • Some patching comments:
    • Windows Installer "Error 1308. Source file not found" when uninstalling patch in sequence scenario
    • MSP vs. MSI packaging. Which to use for patches?
• extremely complicated implementation of custom actions
  • complex sequencing
  • complex conditioning
  • complex impersonation / partial running with elevated rights
  • overall extremely error prone.
• the lackluster implementation of per-user setups
  • conceptually dubious (folder redirects, unpredictability, impossibility of making setups in the real world support both per-user and per-machine installs)
  • complex to upgrade, uninstall and patch. Allows products to be installed multiple times for different users AND also per-machine
  • I have to admit - on a subjective note - that I deem the current implementation of per-user setup a full on deployment anti-pattern. I never use it and insist not to unless forced to.
• unexpected self-repair
  • 1) Self-repair - explained.
  • 2) Self-repair - finding real-world solutions.
  • 3) Self-repair - how to avoid it in your own package.
• the lack of built-in features to write to XML files
• poor features for IIS installs
  • part of the issue is the file overwrite rules for unversioned files (unpredictable results possible).
  • IIS may need a brand new deployment technology altogether to be honest - a way to define handling of non-versioned files in a totally predictable fashion - with sensible, real-world options. Perhaps auto-backup of force-replaced non-versioned files, enforcing of groups of consistent text files ("assemblies") that have to be correct version all of them, etc...
  • also several other issues with the complex configuration of IIS and virtual folders and sites
• sloppy enabling of "check exit code" on custom actions can cause packages that are not possible to upgrade or uninstall (without serious tweaking)
  • major upgrades may fail and trigger rollback for something insignificant
  • a minor upgrade can be used to fix the uninstall sequence or the faulty conditioning
• there are a few more...
  • In fact I wrote up a sprawling summary of commonly seen anti-patterns often seen in real-world MSI packages themselves (erroneous use of the technology): How do I avoid common design flaws in my WiX / MSI deployment solution?
  • I can stand by all the content, but the format is not great - it is a messy brain dump, but sometimes that seems to be the only way to get things done. Take it for what it is.
  • Overuse of custom actions is another MSI problem. There is a core of complexity behind this, but overall the problem is that people don't use fully functional pre-existing solutions in MSI or via extensions such as WiX (or commercial tools such as Installshield or Advanced Installer). Here is a summary: Why is it a good idea to limit the use of custom actions in my WiX / MSI setups?

The issue of 70 high complexity of implementing custom actions (custom installation logic), could be argued 69 to be unavoidable and the act of writing 68 a custom action should be powerful and capable 67 once needed - and hence complicated. Rarely 66 should custom actions be needed if the technology 65 itself offers what is commonly used for 64 deployment. In other words you should use 63 built-in MSI features rather than custom 62 actions if they are available, or WiX or 61 third party deployment software extension 60 when available.

The WiX framework (open source) and commercial tools alike 59 (Installshield, Advanced Installer, etc...) have 58 implemented features to extend Windows Installer 57 to deal with missing features such as the 56 lack of an upgrade mechanism for XML files, share 55 creation and management, creation of users 54 and groups, advanced IIS configuration, COM+ installations, changing 53 ACL permissions, setting firewall rules, persisting 52 installation properties, etc... There should be less and less need to implement your own custom actions. Always 51 use the features that are already tested 50 by thousands of other users if you can (millions 49 of users even - and these extensions have 48 been written by the best deployment experts 47 available - do you think you can do it better 46 on your own?).

The Corporate Benefits of Windows Installer (very significant)

It requires a specific mindset 45 to approach Windows Installer. However, it 44 provides a number of crucial corporate benefits that were almost entirely 43 lacking in previous installation technologies. The corporate benefits of using MSI files is 42 recommended reading. Particularly for those 41 who think Windows Installer is more trouble 40 than it is worth.

To summarize the linked 39 article in brief, the core corporate benefits of MSI over previous deployment technologies are (in my opinion):

• the reliable silent running (with standardized, completely suppressible GUI)
• the implicitly available uninstall (a nightmare with older deployment tecnologies)
• the verbose logging (can be helpful, though really verbose indeed)
• the reliable remote management (in effect the overall benefit altogether - the combined effect of all other listed benefits of sorts)
• the elevated install rights (no messy temporary admin rights)
• the standardized command line (a hugely beneficial feature - no more chasing hidden command line options)
• the installer's semi-transparent nature (open format, except compiled CAs which are black box)
• the rollback support (computer state management, prevent partial deployments, fail and roll back changes)
• the admin install (essential for corporate repackaging, extracts all files in a standard way)
• the standard package customization approach (transforms) (basically allows complete customization for corporate deployment)

That's 38 just to cherry pick the most important ones 37 (after many years doing corporate deployment). In all honesty these features make all the difference in the world (for corporate deployment) and truly makes MSI great to use despite all its flaws.

The Twilight Years Of Windows Installer

As 36 Windows Installer hits its twilight years, we 35 can only hope that the deployment technologies 34 of the future will preserve these great 33 corporate deployment benefits and deal with 32 the mentioned anti-patterns in a way that 31 benefits everyone, and developers in particular.

Deployment is a crucial part of development. Failing to get your great software successfully installed for your potential end users may be the most expensive mistake to make in software development overall. How 30 can you succeed if the user never sees your 29 software fully functional?

Windows Installer's 28 complexity must be handled better (reduced), and 27 its crucial benefits must be preserved properly 26 in whatever paradigm comes next.

A reasonably 25 good: summary of Windows Installer.

Cloud Platforms

With all this said; as computing 24 in general moves to cloud-platforms, the 23 world of deployment is likely to change 22 considerable in unpredictable ways. However, as 21 the famous saying goes: the more things 20 change, the more they stay the same. Deployment 19 needs to deal with all legacy technology 18 that will be in use in companies for decades 17 to come. Here is a piece on why deployment 16 seems to get more complicated and not less 15 complicated - despite all the marketing: What is the benefit and real purpose of program installation?.

It 14 will be interesting to see what the future 13 of deployment will be - in the years to 12 come. Perhaps we will see simplified deployment 11 for home computers, and corporate deployment 10 will become more complicated than ever? In 9 the future most deployment will probably 8 be a database deployment task more than 7 a file and folder deployment task. Server 6 deployment can be extremely complicated 5 as of now with database scripts, user and 4 group creation, share setup and ACL permissioning, performance 3 counters, firewall rules updates, AD queries 2 and updates, COM+ and message queue configuration, service 1 installation, etc... - the whole nine yards.

Think of the user interface with MSI as 13 optional. This means no answers should be required as the 12 developer has sensible defaults in place 11 so that things don't break.

We distribute 10 our software in MSI format to corporate 9 customers, I also provide them with documentation 8 on the basics of Orca (orca.msi is distributed with 7 the Windows Installer SDK) and how to customize certain fields 6 we have listed in the Property table for their installation. Such 5 as serial number, registration details and 4 a few other settings.

In response to the 3 original question about msiexec command line options just run MSIEXEC /? to set 2 properties on the command line you would 1 use something like

MSIEXEC /I test.msi SOMEPROPERTY="Some value" PROP2="something else"

How to configure silent MSI setup

An MSI installation can be configured on 33 the command line by setting the properties 32 that the installer uses. There are pre-defined 31 Windows Installer properties such as the 30 ALLUSERS property. This property defines 29 whether an installation will be done in 28 the context of the current user or the machine.

Information 27 on the available properties can e.g. be 26 obtained from an install log which can be 25 created using msiexec's /l option

msiexec /I mysetup.msi /l*vx log.txt

How to create MSI files

There are 24 many ways to create MSI files. An MSI file 23 is basically a database consisting of various 22 tables containing all necessary setup information 21 and installation dialogs.

Microsoft offers 20 a simple tool call Orca which enables you to 19 edit existing MSI files and allows you to 18 find out which properties can be set to 17 configure an installation. Theoretically 16 it is also possible to create new MSI files 15 using this tool but it is a very cumbersome 14 way to go.

If you are looking for a free 13 and open source solution I would recommend 12 you to have a look at the WiX toolset available on 11 SourceForge or the Nullsoft . All setup 10 information is done via XML files which 9 are then converted into an MSI installer. WiX 8 is stable (although still tagged beta) and 7 can be used in production. Actually it will 6 be integrated in the upcoming version of 5 Visual Studio 2010.

Of course there are also 4 commercial solutions available, InstallShield 3 being the market leader (also being the 2 price leader) and Visual Studio probably 1 being the most wide-spread tool.