I have worked in development as a release manager, build engineer, setup developer and as an application packager in large corporations. I find that the best conceptual and real-world features of MSI are (see the "plainer language" section below for the short version):
- Transparency (Open installer format)- An MSI can be reviewed and inspected. This is a huge issue for large corporations. With the exception of compiled custom actions an MSI file is a "white box". If the setup changes something crazy such as the system-wide network settings, you can actually see it.
- Customizability - An MSI can be customized via transforms to fit an organization's needs and standards whilst still allowing interoperability with the vendor's installer updates. You don't change the installer itself, you create your customization in a separate, organization-specific file called the transform. You are free to disable custom actions and in general anything in the installer, and "black box" custom actions can be approved by contacting the vendor for explanation or even monitored during installation using setup capture technologies to verify what is happening. The transform files are also sometimes used to localize an MSI file to different languages. Several transforms can be applied to a single MSI.
- Standardization - MSI does not lend itself to "allowing anything". It provides a comprehensive framework for the installer, which crucially also includes the uninstall - all in a standard format. The installer GUI is also standardized with built-in features to support silent installation and uninstallation which can be triggered remotely. These features alone constitute a massive improvement over previous installation technologies which treated uninstall and silent running haphazardly.
- Management and reporting - Windows Installer maintains a comprehensive database of all items a product has installed in the registry (HKEY_CLASSES_ROOT\Installer - never change anything here directly! Inspection only - that goes for experts too). You can reliably determine if a product is installed, what features were installed, and what file versions were installed. In addition you can get a list of any patches that have been applied to the base product, if any. You can access this database via API's supporting Win32, COM or .NET using a variety of scripting, configuration and admin tools.
- Security - following from the comprehensive installation database it is possible to detect security vulnerabilities in the installed products. MSI also encompasses "elevated rights" principles which allows a restricted user to trigger the install of a product that requires admin privileges to install. This is part of the "advertisement feature" which allows an administrator to make installers available to users without actually installing them on all workstations. There is no need to mess with temporary rights to get things working.
- Validation - MSI files can be checked with validation rules to ensure it is in compliance with a number of internal consistency rules (referred to as ICE). Corporations can create their own ICE checks to enforce special corporate rules and requirements. This helps greatly with QA. The reason validation is possible is due to the self-referencing nature of relational databases. The database has to be internally consistent and compliant with its own schema with regards to foreign keys, data types, field width, schema version, etc...
- Resiliency - The admin install feature of Windows installer provides a standard way to extract the source files from an MSI. These source files can then be put on a share and be available to all workstations for installation. This ensures repair, uninstall and modify operations complete without requesting the installation media on CD or similar. This is particularly important for patching and update operations which may require access to the old versions source files in special circumstances.
- Rollback - The installation of an MSI file will normally trigger the creation of a restore point. Furthermore all files and registry items replaced or overwritten during the installation will be saved and restored if the install fails to complete. This ensure that the workstation is left in a stable state even if the install should fail. As you might expect poorly designed MSI files can violate the built-in features of Windows here, see my other post in this thread for more details. There are ways to disable rollback and speed up installation. Not generally recommended, but here are details on the MSIFASTINSTALL property and DISABLEROLLBACK.
- Patching & Updates - though highly complex, patching in Windows installer is fully managed and registered on the system so that a systems security state can be determined by checking what has been installed. Updates are standardized to a few basic variants, and this allows updates to be performed with a higher degree of certainty provided you are able to handle the complexity involved. Deployment systems will be able to report what updates failed and why.
- Logging - Windows Installer provides a standardized logging feature which is greatly superior to previous incarnations, though almost excessively verbose. Log files can be deciphered using log analyzers, and custom log levels can be used to eliminate generating too large log files with unnecessary information. For debugging purposes verbose logging is extremely useful. See Rob Mensching's blog for a good manual way to read an MSI log file.
Not everything is superb about Windows Installer. Its complexity can be baffling at times, but for large corporations MSI files are vastly superior to any other form of deployment when you take into account the list of benefits above.
In plainer language the really important benefits with MSI are: uninstall is always available, logging is great, what the file does is semi-transparent, setup customization is done in a standardized way (transforms), and deployment via management tools works well. In the real world I have found less successful aspects to include patching (very complex), MSI-GUI (plain features, quite complex, lacks flexibility) and overall complexity of dealing with the technology for beginners (high complexity of basic operations at times - for example upgrades, GUI and many interacting details cause unexpected results, etc...). It is its own installation paradigm and very unorthodox. At times you feel you are dealing with SDK-level complexity for even basic operations - again upgrades in particular. Luckily newer tools from Installshield and AdvancedInstaller shield quite a bit of complexity by abstracting a good GUI on top of the details.
To understand the new "paradigm" it is important to understand that MSI is intended as a declarative description of what is going to happen on the target system, rather than a fixed sequence of events. I suppose you can think of it as a huge SQL-statement. For example you declare items you want added or modified to an INI file. As the installation runs changes are tracked and rollback is available so that changes can be reverted if the installation fails. This really works like "automagic", and is reliable when done right. It is a huge headache for experienced MSI developers to see people rely on complex, unreliable custom actions for functionality that is better implemented with built-in MSI features. Almost all MSI errors are caused by this.
N.B: See elsewhere in the thread for a quick rundown of the common design problems with MSI files - it is very incomplete, but should be worth a read. I didn't want to add that to this reply since it isn't 100% related, but for real world use it is a crucial topic.