Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

What are the advantages of using .msi files over regular setup.exe files?

I have the impression that deployment is easier on machines where users have few permissions, but not sure about the details.

What features does msiexec.exe have that makes deployment more easy than using setup.exe scenarios?

Any tips or tricks when deploying .msi applications?

share|improve this question
add comment

6 Answers

up vote 20 down vote accepted

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 them.
  • State management is maintained so Windows Installer provides an a way to let administrators see if an application is installed on a machine.
  • Ability to rollback if an installation fails.

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

share|improve this answer
add comment

I have worked in development as a release manager and as an application packager in large corporations. I find that the best real-world features of MSI are:

  • 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. These 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 standard format. The installer GUI is also standardized with built-in features to support silent installation and uninstallation which can be triggered remotely.
  • Management and reporting - Windows Installer maintains a comprehensive database of all items a product has installed. 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.
  • 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.
  • 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.
  • 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. 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.

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.

N.B: See elsewhere in the thread for a quick rundown of the common design problems with MSI files. 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.

share|improve this answer
add comment

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):

  • 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.
  • upgrade problems relating to user data being overwritten or reset
  • 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.
  • 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
  • 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.

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.