UPDATE, July 2018: An extremely compressed summary of the below information is available on stackoverflow: The Major Benefits of MSI ("executive summary" - of sorts).

I have worked in development as a release manager, build engineer, setup developer and as an application packager and deployment engineer in large corporations.

This is a review of the best (and worst) conceptual and real-world features of MSI. The most common design problems found in MSI files are presented as a separate answer below. Not pretending to be complete - really just a messy "brain dump" - intended as "that stuff that can't be found in books" (probably for good reason).

I also want to suggest this MSDN article as a good read: Windows Installer: Benefits and Implementation for System Administrators.

Standardization:

In a word, MSI is about standardization, and about dealing with "deployment smells" of legacy installer technologies. A whole collection of bad installation architecture designs that caused repeated deployment problems.

Overall MSI provides a comprehensive, standardized framework for the installer, which crucially also includes the uninstall and built-in features and options for silent running with standardized GUI which can be triggered remotely.

These features alone constitute a massive improvement over previous installation technologies which treated uninstall and silent running haphazardly - perhaps the most important features for corporate deployment along with reliable remote package management via Active Directory or dedicated remote administration tools such as Microsoft SCCM (formerly SMS), IBM Tivoli, CA Unicenter and similar.

Someone duplicated a prior version of this answer. Maybe a quicker read?

Legacy Installers "Deployment Smells"

MSI actively discourages legacy deployment smells by design. These topics are discussed in later sections below, but as a quick list the most recognizable issues with legacy installers and older deployment technology were:

• 1) they sometimes downgraded and overwrite shared and versioned files with little concern for the dll-hell that resulted
• 2) there was often not a proper uninstall routine supplied with the installer, or it didn't complete properly and reliably - particularly if run silently. This is a very big issue for corporate SOE management
• 3) silent installation was rarely supported properly. Reliability was poor, and one often had to record a run of the install with dialog selections and this did not deal well with unexpected conditions such as error dialogs or warning dialogs that wasn't recorded in the original run
• 4) the installer kept no record of what was installed and hence there was no automatic way to verify files on disk to check if they still were the versions that were installed originally by the installer
• 5) they featured unpredictable, unreliable and nonstandard command line parameters for the installation executable
• 6) following from the nonstandard command line and the lack of standards it was difficult to customize installers with specific values needed for corporate deployment in a reliable and predictable manner
• 7) normal users could not run these installs, and one often had to mess around with temporary admin rights (use "run as" if that was sufficient, or log in as admin, install and then log out - this full login and profile generation was sometimes required for the install to complete)
• 8) the setup.exe installer would often not return a proper error code or success code, and sometimes it would exit immediately and kick of another process that would finish the install making it difficult to determine if the install was completed - especially via a batch file
• 9) most setup.exe files allowed files to be extracted, but not in a reliable, predictable fashion - you generally had to spend a lot of time finding the right switches to get it done
• 10) logging was generally poor and rather haphazard in some tools. Debugging with log files rarely produced clarity, but did help a bit
• 11) there was no transparency in what the installer was doing and no or unreliable rollback to undo changes after a failed install
• 12) there was no industry standard way of deploying shared runtime components whether they were operating system components, third party components or your own

The list goes on with plenty of other crucial and recognized deployment flaws. It was obviously in the world of corporate deployment that these problems surfaced most often, and it has resulted in the business of "application repackaging" where a legacy installer is captured with disk and registry scanning technologies in order to create a standards-compliant MSI file for reliable deployment.

Application repackaging is a specialist job and generally results in excellent quality MSI files if done right by knowledgeable people, but it is not possible to repackage all applications due to complex registration logic that must be run interactively for certain applications to work.

MSI Benefits - Short Summary

In plain language the really important benefits of MSI are (in no particular order):

• 1) uninstall is always available for every package unless it is actively disabled
• 2) this is the same for logging, which is great and standardized, though verbose (tools such as WiLogUtl.exe can be used to analyze the log files)
• 3) what an MSI file does is (semi-)transparent or "inspectable" for the most part. The exception is custom actions - (see transparency section below)
• 4) setup customization is done in a standardized way (transforms)
• 5) there is no need to mess with temporary admin-rights since the install runs elevated via Active Directory advertisement, group policy or remote administration. Some qualifications here. Also see this screen shot from the group policy object editor.
• 6) silent install / uninstall via management tools or using msiexec.exe works well
• 7) there is full rollback support for failed installs. If you install manually on the box there are some qualifications you need to know about.
• 8) the MSI file lends itself to both inspection and validation for consistency and logical validity since they conform to a database schema (see validation example)
• 9) updates are standardized types, though complex and often error prone for inexperienced packagers
• 10) the extraction of files from the msi is a built-in feature (check linked article for a good quick overview)
• 11) the Windows Installer command line, msiexec.exe, features very fine grained control of how the installation sequence should be performed, and all options work with all standards compliant MSI files (set log-level, run silently / interactively / semi-silently, set installation parameters, apply transforms etc...) .
• 12) merge modules is the MSI mechanism for delivering shared files with multiple MSI packages. It is a consumable module or bundle of installation logic mergeable with any MSI package at compile time. Wix has extended and improved on this concept with the use of Wix include files - a concept that in my opinion is superior to merge modules - especially for your own files (i.e not OS files)
• 13) the windows installer engine itself features a mechanism to prevent overwriting versioned or modified files on installation. This is controlled by a rather complex file replacement logic. Though efficient and good, the logic can end up being a problem in and of itself since many developers face the problem of not being able to overwrite their modified config files when upgrading. The solution to these problems are generally minor changes in application design to avoid common deployment anti-patterns - though that is a big discussion of its own.

In the real world I have found less successful aspects to include patching (very complex), MSI-GUI (plain features, quite complex, lacks flexibility), resiliency (may cause hard to debug repeating self-repair problems), and the overall complexity of dealing with the technology for beginners (high complexity of basic operations at times - for example upgrades, GUI and the many interacting details cause unexpected results etc...). The speed of the installation process has also slowed considerable due to the increased overhead of MSI. See some tips for improving MSI installation speed.

The rest of the text deals with some of these aspects of MSI in more detail.

Transparency (open installer format)

An MSI file is essentially a stripped down SQL-Server database stored as a COM-structured storage file - essentially a file system in a file or a collection of data streams. This is the file type used in Microsoft Office documents, and it yields a standard format that can be reviewed and inspected - 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 using the appropriate tools. The notable exception is compiled custom actions - which are black box. Windows logo requirements require custom actions to be annotated to explain what they are doing, but this is often ignored by setup developers. Hopefully the advent of Wix will improve this.

To determine what such compiled custom actions actually do in a technical sense, a setup capture is necessary. This is hardly ever done in my experience. It is more common to contact the vendor for information if the software needs approval for corporate deployment, and then it might be the application itself which prevents its use, and not just the setup.

Customizability (transforms)

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 (.mst file) (a database fragment or change transaction if you like). You are free to disable custom actions and in general change, override or disable anything in the installer, and you can even add new things, including files. The transform files are also sometimes used to localize an MSI file to different languages. Several transforms can be applied to a single MSI, here is a sample with truncated paths:

msiexec.exe /I "My.msi" /QN /L*V "C:\My.log" TRANSFORMS="C:\1031.mst;C:\My.mst"

Quick Parameter Explanation:

/QN = run completely silently
/L*V "C:\My.log"= verbose logging
TRANSFORMS="C:\1031.mst;C:\My.mst" = Apply transforms 1031.mst and My.mst.

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! 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 such as Microsoft SCCM, IBM Tivoli, CA Unicenter etc...

Security (temporary elevated rights)

MSI also encompasses "elevated rights" principles which allows a restricted user to trigger the install of a product that requires admin-rights 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. The installer itself must be correctly authored on several core accounts for this elevated rights concept to work correctly. The users may trigger the install of the product themselves, or the install might be controlled by a dedicated deployment system such as SCCM, Tivoli, Unicenter (larger companies normally). There is no need to mess with temporary admin-rights to get things working which is often the case with legacy installers.

The comprehensive installation database also ensures that you have full overview of installed patches and therefore a possibility to detect security vulnerabilities via automation and admin tools.

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 and the associated database schema. 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... Validation also goes beyond this and is capable of detecting genuine logical flaws and errors in the package, not just formatting and type flaws. For example it can detect files or file types that are being deployed to erroneous target destinations.

Resiliency (Self-repair)

The admin install feature of Windows installer provides a standard way to extract the source files from an MSI (here is some additional information on this topic). 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.

There are also common problems with this resiliency feature. Most administrators have experienced machines with cyclical self-repair cycles that never seem to stop. Follow the link for a long list of causes of this problem. And again, here is a shorter version that might be easier to read.

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, barring any changes done in custom actions.

Custom actions must implement their own rollback support for Windows logo compliance. This is often ignored, but involves creating a second custom action to undo the changes made by the main custom action.

Rollback ensures that the workstation is left in a stable state even if the install should fail. The actual rollback script is stored in a hidden folder directly on the system drive - generally C:\Config.MSI, and it contains files with the extensions .RBS and .RBF - Rollback Script Files. 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. This is a complicated feature, but here is a quick rollback overview.

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.

In a subjective view patching works well for 2 basic uses: 1) small hotfixes for delivered products, and 2) patching an installed product to fix its faulty uninstall sequence that prevents a products clean uninstall.

A patch is just a delivery mechanism for an update that is already working. As such it is just a container that is more complicated and error prone than the original setup itself. The number one rule for a patch is that it must be smaller than the original MSI or there is no obvious reason to deliver a patch at all. A patch can get huge quickly if it targets multiple product versions.

Logging (verbose indeed)

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 (essentially you search for "value 3" in the log file). Here is a sample command line that performs verbose logging:

msiexec.exe /I "C:\Installer.msi" /QN /L*V "C:\msilog.log"

This article from Robert Macdonald from the Windows Installer Team is highly recommended as a practical look at MSI logging: How to Interpret Windows Installer Logs.

Conclusion

Not everything is good 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.

New installer paradigm (the huge SQL statement)

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.

Custom Actions (the usual suspects)

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. A significant share of all MSI errors and rollback problems are caused by erroneous custom actions, and most other errors are caused by erroneous use of the MSI design (see separate answer for list of common MSI errors).

In addition to the built-in MSI features, more and more custom functionality is now available via new framework such as Wix - the XML way to compile MSI files, so there is less and less need for complex custom action logic for most operations.

MSI features full support for handling merging of ini file settings, fonts, environment variables, registry keys, COM information, shortcuts, file extensions, launch conditions, GAC installation, ODBC, etc...

WIX goes further with support for very advanced features such as SQL server extensions, IIS installations and configuration, performance counters, DirectX checking and other game related tasks, .NET native image generation, COM+, drivers, firewall rules, PowerShell extensions, application closing, management of users, groups, shares and much more. Somewhat involved to deal with, but much more reliable than your own custom actions.

Avoid Custom Actions At All Cost If Possible

To try to put it in perspective: these built-in and ready-made solutions are made by the best deployment experts available, and they are tested by thousands, tens of thousands or perhaps even millions of users (for built-in stuff in MSI itself). Do you really think you can do better making your own custom actions? Using a custom action should be a rare event, and it should be absolutely necessary to achieve something unique for the product you install. And you must write proper rollback support as well, which is quite involved.

Writing a custom action is almost always a mistake, but there are genuine cases when you really need the flexibility as well. As always it is important to pick your battles well. It might be a fun task at first, but you will likely be facing many unexpected problems and waste a lot of costly time. I mean this very seriously. I have written a suite of C++ custom actions for corporate use myself (to eliminate error prone VBScript custom actions) - it is no walk in the park, and though the coding may not be the most difficult in the world, the debugging and testing and hookup to an actual MSI file is nothing short of extremely involved. Some time researching what ready-made options are available will likely save you weeks of development work, and yield much greater deployment reliability.

Use the Application Launch Sequence

A very important point is that a lot of application configuration should happen on application launch when you have a predictable runtime context and good error handling available, and not in the setup which is only run once and features very complicated impersonation, sequencing, conditioning and runtime complexity.

Your setup should not configure the application, it should prepare the application for configuration on first launch. Specifically your setup should write all settings that require elevated rights - writing to HKLM, registering services, installing to per-machine paths and any such things that an application cannot write on its own with regular user rights.

If you are a setup developer you should offer to get involved coding the application launch sequence instead of writing setup custom actions. If nothing else, in order to avoid looking like you are trying to "pass the buck" to someone else. In this launch sequence you can write much more reliable and testable code which is easier to get help from QA personnel to test (they often don't understand deployment testing as well as application testing).

Setup Complexity

The core of setup complexity centers around the fact that errors are cumulative (you are managing a delivery process, not just a quick recompile), errors are very hard to debug (no access to the systems where the errors occur), and the target system states differ in just about every way imaginable. Please see this answer for a more thorough discussion of this complexity and how target systems may wary in a shocking number of ways: Windows Installer and the creation of WiX, and The Complexity of Deployment (see towards bottom).

WiX (best MSI solution for some purposes)

Read this WiX quick introduction for a description of the new XML-based way to compile MSI files. The text based source files provide much better source control than before. This is a free, open source toolkit that is highly recommended.

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.

Some core MSI information for sys-admins:

(pardon the shameless "promotion" - it is for easy access and retrieval)

Here are just a few links to topics that may be helpful to system administrators in their effort to control the deployment on their networks:

• How can I eliminate the huge, cached MSI files in C:\Windows\Installer? (high disk use by MSI)
• How to speed up MSI installations (just a couple of options)
• How to extract files from setup.exe (worth a read for any admin, probably old news)
• Different ways to uninstall an MSI (uninstall reference, popular - high number of views)
• How to bypass msiexec.exe when dealing with MSI packages (MSI automation and scripting)
• Why does MSI require the original .msi file to proceed with an uninstall? (common question)
• Why are there multiple msiexec.exe processes in the process list during installation? What are they all doing?

Special how-to topics:

• Forcing an upgrade of a file that is modified during its initial installation (common question)
• Is there anyway to get msiexec to echo to stdout instead of logging to a file (advanced topic, using external gui for MSI, more developer content)
• I want to install an MSI twice (instance transforms, or virtualize - seriously :-) ).
• How to update every user profile using ActiveSetup (somewhat dangerous, but useful)
• Common errors in MSI packages (more for developers, but also for system administrators)
• How to debug cyclical self-repair (important topic)

Conceptual Topics / Best Practice:

• What is the benefit and real purpose of program installation? (basics of deployment)
• Purpose of Administrative Installs (core MSI operation for system administrators)
• Why you should not use MSI for registry tweaks (recommended read)
• What installation product to use? (Strengths and weaknesses of different tools)
• Why self-registration is considered harmful in MSI

Just a few benefits:

• Can be advertised (so that on demand installation could take place).
• Like advertisement, features can be installed as soon as the user tries to use them.
• State management is maintained so Windows Installer provides a way to let administrators see if an application is installed on a machine.
• Ability to roll back if an installation fails.

I think to when I'm deploying software in an enterprise setting: deploying software via MSI is almost enjoyable. In contrast, I almost always find myself dreading deploying software when it's in another container.

For some additional info on manipulating MSI installations, type msiexec into the Run dialog.

This answer is very much a work in progress and a rough outline. Additions, questions and updates welcome. This list is by no means exhaustive. Add a comment with information about troublesome packages.

Typical Problems and Design Flaws Seen in MSI Packages

I must also warn that a lot of MSI files contain errors, sometimes serious ones, but trained application packagers will be able to detect this and in most cases eliminate the problem. I am adding this as a separate answer since it essentially answers a different question, but I feel it is relevant in the same thread.

The technical details involved in MSI are very complicated. At the basic level it is about decomposing your files and registry settings into components (atomic installation) and features (user selectable application parts to install, for example a dictionary feature). There are a number of best practice rule for splitting up the components, and errors in MSI files here are plentiful. These errors are generally handled by standardizing on the use of "major upgrades".

The actual installation is performed in a number of installation sequences, some with elevated rights. All of these things are defined in database tables, and this is where MSI is terribly complicated to understand and deal with. Spread throughout the installation sequences are standard and custom actions. The standard actions are Microsoft designed and need to take place (sequence can sometimes be modified). Custom actions are available to vendors to perform custom logic not covered by MSI itself. These can be in script or compiled form. Custom actions can be immediate (run at once, should not change the system but often does) or deferred (written into an excecution script that is then executed as a transaction and hence supporting rollback).

Typical errors in an MSI are (in no particular order - and presented as a real mess really):

• component creation errors (not following best practice). This can cause problems for patching and upgrades with mysterious symptoms such as missing files and settings or patches that bomb out with nonsensical errors. To oversimplify one should use one file per component unless the number of files is enormous.
• upgrade problems relating to user data being overwritten or reset. See more details below.
• incorrect scheduling of custom actions outside the "transacted section" of the installation sequences or custom actions of the wrong type are placed incorrectly. This often causes the actions to fail (no elevated rights) when run remotely via deployment systems and rollback is effectively crippled because only transacted actions are rolled back. The Windows Installer Transaction (think database transaction commit) runs between the standard actions InstallInitialize and InstallFinalize in the main installation sequence and runs with elevated rights. All changes to the system are to take place in this transaction - anything else is erroneous (but unfortunately quite common).
• use of immediate mode custom actions to make changes to the system outside the transacted install sequence. This breaks rollback support and will generally trigger security errors since immediate mode custom actions do not run with elevated user rights no matter where they are placed in the installation sequences.
• erroneous designs that cause repetitive cycles of self-repair to occur for no obvious reason. Here is another article on this subject, from installsite.org
• custom actions that do not obey the suppression of the GUI in unattended installation mode may show modal dialogs that causes deployment to fail completely when run silently. This issue along with the overall difference between silent mode and interactive mode is described in more detail here (somewhat verbose and long-winded): Uninstall from Control Panel is different from Remove from .msi
• some custom actions in erroneously authored packages are inserted only in the user interface sequence. This causes them not to be run in silent installation mode. This is serious for corporate deployment since silent install is used here almost exclusively. This problem can also affect uninstall meaning you may have to run the uninstall interactively for uninstall to ensure all cleanup custom actions run. Again, see the link in the previous bullet point for a longer description of user interface levels.
• the setup contains files that are not intended to be deployed in the location they are installing to. Typically system files that should be installed side-by-side in the winsxs assembly folder.
• slow installation speed is another "problem" that many report with MSI. Here are some tips on the subject. Overall Windows Installer features quite a bit of overhead due to the heavy registration requirements in the registry for what is being installed.
• overwriting of customized information or shared data files. This can happen if an INI file is installed via the File table and not the IniFile table for example. In the latter case it is treated like a "change transaction" in the former case it is a file replacement operation, which is generally wrong unless your INI file features nonstandard formatting or large comments sections that you want deployed with your file (common for certain developer tools).
• the complex rules for file overwriting can cause files to be overwritten unintentionally, or not updated at all - this is a classic MSI issue. Check this article for how you can force overwrite a file that won't upgrade. The rules can be slightly tweaked by custom settings for the REINSTALLMODE property set at msiexec.exe command line level (overwrite older versions, overwrite equal versions, overwrite any version etc...) and they work differently for data files and versioned files. Details in the SDK. Understanding this is critical, and it is a design often frowned upon even when understood.
• self registration of COM files during installation can trigger security warnings or cause problems in various ways. Check this article: Self-registration considered harmful.
• a variation on the file replacement issue is the case when a major upgrade (which uninstalls and reinstalls the product) uninstalls modified files, and reinstalls the default versions. In these cases the content looks reverted or overwritten when in actual fact it was uninstalled first and then reinstalled.
• services running with custom user credentials may lose their credentials during major upgrade scenarios as well as have settings file (appear to) revert to default (they were really uninstalled and reinstalled). Just for the record: in my opinion services running with user credentials is a design flaw in the first place.
• public properties are not passed properly from the client to the server process preventing custom actions from completing as expected. This involves updating the SecureCustomActionProperties property.
• Some applications are unable to run properly for other users than the one that installed the setup originally. This is a serious design error, but can generally be fixed by experienced application packagers using self-healing or ActiveSetup to add HKCU registry keys and userprofile files. This is a quite complex subject, and can require a bit of black art to get working. For the record: the real solution, in my opinion, is to change the application itself to be able to initialize all per-user settings based on default setting and templates copied from a per-machine location or based on application internal defaults (from the source code).
• Some MSI files mess up the security for installed files by setting full read/write rights for non-administrators here, there and everywhere. Other times the application stops working on newer versions of Windows due to lacking permissions. Application packagers face analysis of an application's custom permission needs quite often. Typically some extra permissioning is required in HKLM or somewhere in %ProgramFiles%
• Some Installshield setups back in the day would try to connect to the Internet during installation. This is horrible for corporate deployment scenarios where deployment is tightly controlled, and the installer will not ever be allowed to download new content directly from the Internet.
• Another networking problem is when setups try to show a GUI where people enter data that is validated across the Internet as they install, or just to show live content from their web-site. This is typically email addresses, contact information, license keys and such things. Connection can fail completely for many reasons, often due to missing proxy configuration in corporate environments (there is no direct connection to the Internet, all Internet traffic is routed through a specific cache server and each process needs to provide credentials to get through the firewall). Here is an article on the perils of validating licenses via the setup.
• Installshield used to install a runtime for its Installscript language. This prerequisite setup was generally included in the setup.exe, and it was a legendary source of problems. There were many versions, several incompatibilities, and a number of runtime errors used to occur. Since version 12 (or thereabouts) this runtime is now installed reliably, and it is either compiling to native or running sandboxed (I am not sure which, one or the other - probably sandboxed) in a reliable fashion. Older Installshield setups may display this deployment problem though. There is a legacy support site from Installshield for issues such as these: http://consumer.installshield.com/common.asp
• Several setups can display erratic installation behavior or intermittent bugs when run on machines set up for different languages than English, or even when you run localized (translated) versions of setups on English machines. This can be purely runtime failure, or cases when the localized dialog boxes feature cut off text or erroneous formatting or faulty translation or many other types of errors relating to language localization - a whole area of expertise on its own (translate text in images, translate the software itself, translate marketing material, deal with international support requests, adaptation to the language settings in the OS, etc...). Some languages need the whole application changed to account for their language peculiarities - typical problems are string macros and code page settings, the latter being less of an issue with the introduction of Unicode. See a sample screenshot from a translation tool.
• Almost all setups fail several of the built-in validation tests that are available to test the quality of MSI packages. See this article for a practical example of validation.
• Sometimes upgrades fail for an MSI due to the fact that only 3 digits of the MSI's version number are actually checked during major upgrade scans.
• The installation of INI files is a built-in feature of Windows Installer. Entries can be added, removed, merged or dealt with in any required fashion. However, it is quite common for INI files to be installed as a file instead of as segmented values. This can cause the INI file to be overwritten during reinstall, instead of being updated. A very common MSI problem.
• The above issue is also the case for .NET application's and their Config.xml files. In this case MSI does NOT have a built-in way to update the content in a detailed way, and you either need to code the update via a custom action or replace the whole file on install. Wix may have new features for this, but the Windows Installer engine does not have this built-in.

There are a number of more subtle errors and several larger, typical problems that I will have forgotten.

Check out the Windows Installer Best Practice article from MSDN.

Using MSI's also makes patching (MSP files) and upgrades easier. MSI's use the concept of unique Product and Upgrade codes which makes the whole process easier.

Some deployment systems (CA Unicenter Software Delivery is one example) can also understand MSI's in a special way, which allows them to integrate much better into the deployment system. For example you can feed an MSI into the software library of the deployment system and it will automatically detect the various features within the product and automatically allow much more granular custom actions (Local Install, Verify, Repair etc.) and logging.

Self-heal / repair is also a major plus for MSI's.

Also, check out open source Windows Installer XML, "a toolset that builds Windows installation packages from XML source code. The toolset supports a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages." This is used by MS to prepare several of its major software packages.

you can do transformations - in theory you can customize a lot, if program was packaged properly by vendor you can make fully automated deployment without any interaction with end user - which is very helpful when you want to standardize your windows environment and have more then handful of computers.

to see what people do with msis [ or unattended deployment ] visit for instance this site and it's forums.