Windows Installer

This article is about theMicrosoft Windows component. For the installation of the operating system itself, seeWindows Setup.

Windows Installer

Before the introduction ofMicrosoft Store (then named Windows Store), Microsoft encouraged third parties to use Windows Installer as the basis for installation frameworks, so that they synchronize correctly with other installers and keep the internal database of installed products consistent. Important features such asrollback andversioning depend on a consistent internal database for reliable operation. Furthermore, Windows Installer facilitates the principle of least privilege by performing software installations by proxy for unprivileged users.

Logical structure of packages[]

A package describes the installation of one or more fullproducts (Windows Installer does not handle dependencies between products) and is universally identified by a GUID (the PackageCode property). A product is made up ofcomponents, grouped intofeatures.

Products[]

A single, installed, working program (or set of programs) is aproduct. A product is identified by a unique GUID (the ProductCode property), providing an authoritative identity throughout the world. The GUID, in combination with the version number (ProductVersion property), allows for release management of the product's files and registry keys.

Apackage includes the package logic and other metadata that relate to how the package executes when running. For example, changing anEXE file in the product may require the ProductCode or ProductVersion to be changed for the release management. However, merely changing or adding a launch condition (with the product remaining the same as the previous version) would still require the PackageCode to change for release management of the MSI file itself.

Components[]

Acomponent is the minimal part of a product—each component is treated by Windows Installer as a unit: the install developer cannot, for example, use a condition to specify to install just part of a component. Components can containfiles,directories,COM components,registry keys, shortcuts, and other data. The end user does not directly interact with components.

Components are identified globally by GUIDs, thus the same component can be shared among several features of the same package or multiple packages, ideally through the use ofMerge Modules (although, for this to work correctly, different components should not share any sub-components).

Key paths[]

Akey path is a specific file, registry key, orODBC data source that the package author specifies as critical for a given component. Because a file is the most common type of key path, the termkey file is commonly used. A component can contain at most one key path; if a component has no explicit key path, the component's destination directory is taken to be the key path. When an MSI-based application is launched, Windows Installer checks the existence of these critical files or registry keys (that is, the key paths). If there is a mismatch between the current system state and the value specified in the MSI package (e.g., a key file is missing), then the related feature is re-installed. This process is also known asself-healing orself-repair. No two components should use the same key path.

Features[]

Afeature is a hierarchical group of components—a feature can contain any number of components and other features (a feature contained in another feature is called a "subfeature"). Many software packages only involve one feature. More complex installation programs usually display a "custom setup" dialog box at run time, from which the end user can select which features to install or remove.

The package author defines the product features. A word-processing program, for example, might provide features for the main program executable, the program's help files, and optional spelling checker and stationery modules.

Setup phases[]

User interface[]

Theuser interface phase typically queries the target system and displays an installation wizard and enables the user to change various options that will affect the installation.

However, the user interface sequence should not make any changes to the system. Three reasons for this are as follows.

1. A user can install an MSI package in quiet mode, bypassing this phase entirely, by running the msiexec.exe command-line utility with the /qn (or /qb or /qr) option and specifying on the command line all the information that the wizard would normally gather. Therefore, any actions that occur in the user interface sequence will not be performed during a silent installation.
2. Similarly, clicking theRemove button in theAdd or Remove Programs panel runs a product's uninstaller with a basic user interface, again with the result that any actions that occur in the user interface sequence will not be performed.
3. Actions that make system changes should not be scheduled in the user interface sequence as the user interface sequence runs with user privileges, and not with elevated privileges, as described in the following section.

Actions in the user interface sequence of a normal installation are defined in the InstallUISequence table. Similarly, there is an AdminUISequence in which you can place dialog boxes and actions to display and perform from within an administrative installation wizard.

Execute[]

When the user clicks theFinish orInstall button in a typical MSI installation wizard, installation proceeds to the Execute phase, in which software components are actually installed. The Execute phase makes system changes, but does not display any user-interface elements.

Execute phase happens in two steps:

Immediate mode. In this phase, Windows Installer receives instructions, either from a user or an application, to install or uninstall features of a product. The requests cause the execution ofsequences ofactions, which query the installation database to build an internalscript describing the execution phase in detail.

Deferred mode. In this phase, the script built in immediate mode is executed in the context of the privileged Windows Installerservice (specifically, the LocalSystem account). The script must be executed by a privileged account because of the heterogeneity of the scenarios in which a setup operation is initiated—for example, elevated privileges are necessary to serve on-demand installation requests from non-privileged users. (In order to run with elevated privileges, however, the package must be deployed by a local administrator or advertised by a system administrator usingGroup Policy.)

Execute sequence actions for a normal installation are stored in the InstallExecuteSequence table. An MSI database can also contain AdminExecuteSequence and AdvtExecuteSequence tables to define actions to perform for administrative and advertised installations.

Rollback[]

All installation operations are transactional.^[3] For each operation that Windows Installer performs, it generates an equivalent undo operation that would undo the change made to the system. In case any script action fails during deferred execution, or the operation is cancelled by the user, all the actions performed until that point are rolled back, restoring the system to its original state. Standard Windows Installer actions automatically write information into a rollback script; package authors who create custom actions that change the target system should also create corresponding rollback actions (as well as uninstallation actions and uninstallation-rollback actions). As a design feature, if applied correctly this mechanism will also rollback a failed uninstall of an application to a good working state.

Other features[]

Advertisement[]

Windows Installer canadvertise a product rather than actually installing it.^[4] The product will appear installed to the user, but it will not actually be installed until it is run for the first time by triggering an entry point (by means of a Start menu shortcut, by opening a document that the product is configured to handle, or by invoking an advertised COM class). A package can be advertised by an administrator using Group Policy or other deployment mechanism, or by running the msiexec executable with the /jm (for per-machine advertisement) or /ju (for per-user advertisement) switch. It should also be noted that some MSI packages authored in Installshield may prevent the use of these and other Native MSI features.

What is not known by most is that the user must have administrator privileges to complete this advertised installation. In most workplaces, end users are not administrators and this method of distribution will fail. Microsoft created a workaround via Group Policies to "Elevate user privileges" during MSI installations. Administrators have since seen this GPO setting as a security hole since any MSI would automatically gain administrator privileges.

Installation on demand[]

Similar to advertisement, it consists in the installation offeatures as soon as the user tries to use them.^[5] Again, depending on how the features need to be installed, the end-user may have to be an administrator on the PC for the feature to install.

Administrative installation[]

An administrative installation creates an uncompressed source image for a product, typically to be used for installing or running an application from a network location.^[6] An administrative installation is not a typical installation, in that it does not create any shortcuts, register COM servers, create an Add or Remove Programs entry, and so on. Often an administrative installation enables a user to install the product in such a way that its features run from the uncompressed installation source.

Administrative installations are also useful when creating a Windows Installer patch, which requires uncompressed images of the earlier and current versions of a product in order to compute binary file differences. An administrative installation is performed by running the msiexec executable with the /a switch.

Custom Actions[]

The developer of an installer package may write code to serve their own purpose, delivered in a DLL. This can be executed during the installation sequences, including when the user clicks a button in the user interface, or during the InstallExecuteSequence. Custom Actions typically validate product license keys, or initialise more complex services. Developers should normally provide inverse custom actions for use during uninstallation.

Msiexec provides a way to break after loading a specified custom action DLL but before invoking the action.[2]

Merge Modules and Nested Executables[]

A Windows Installer package may contain another package to be installed at the same time. These are ideally provided as a .msm file component, but may also be a separate executable program which will be unpacked from the installer package during the InstallExecuteSequence and can be run immediately. The file can then optionally be deleted before the end of the InstallExecuteSequence, and so is ideal for using with older installers.

Miscellaneous[]

Windows Installer allows applications to run directly from anetwork share, without the need for a local copy (run from source); it can repair broken installations by restoring damaged or deleted files,registry entries and application shortcuts; it supports per-user installation of applications; it can resolve component identifiers into paths, allowing applications to avoid hard-coded file paths; and it natively supportspatches (.msp files made out of patch creation properties) and other customizations of packages through manipulations (transforms or .mst files) of a package's relational database. Version 2.0 onwards, it supportsdigital signatures and version 3.0 onwards,delta compression for patches.

It is also unique among installation software frameworks for Windows in that it is highly transparent. The full API and all command-line options are documented; packages are freely viewable and editable, both with free tools and programmatically (as opposed to the proprietary and even weakly encrypted packages ofInstallShield); and the format for file archives is the well documentedcabinet file format.

Windows Vista[]

Windows Installer 4.0, which was shipped withWindows Vista, incorporates new capabilities to take advantage of Vista'sUser Account Control architecture. MSI packages can be marked as not requiring elevated privileges to install, thus allowing a package to install without prompting the user for Administrator credentials. Windows Installer also works in conjunction with the Restart Manager; when installing or updating an application or system component with "full" user interface mode, the user will be displayed a list of affected applications that can be shut down, and then restarted after files have been updated. Installer actions running in silent mode perform these application restarts automatically. System services and tray applications can also be restarted in this manner.

Developing Installer Packages[]

Creating an installer package for a new application is non-trivial. It is necessary to specify which files must be installed, to where, with what registry keys. Any non-standard operations can be done using Custom Actions, which are typically developed in DLLs. There are a number of commercial and freeware products to assist in creating installers; for example Visual Studio,InstallShield,Installaware,Wise Installer, Advanced Installer andWiX. To varying degrees, the user interface and behaviour in less common situations such as unattended installation, may be configured. Once prepared, an installer package is "compiled" by reading the instructions and files from the developer's local machine, and creating the .msi file.

The user interface (dialog boxes) presented at the start of installation can be changed or configured by the setup engineer developing a new installer. There is a limited language of buttons, textfields and labels which can be arranged in a sequence of dialogue boxes. An installer package should be capable of running without any UI, for what is called "unattended installation".

ICE validation[]

Microsoft provides a set of Internal Consistency Evaluators, or ICEs, that can be used to detect potential problems with an MSI database.^[7] The ICE rules are combined into CUB files, which are stripped-down MSI files containing custom actions that test the target MSI database's contents for validation warnings and errors. ICE validation can be performed with the Platform SDK tools Orca and msival2, or with validation tools that ship with the various authoring environments.

For example, some of the ICE rules are:

• ICE09: Validates that any component destined for the System folder is marked as being permanent.
• ICE24: Validates that the product code, product version, and product language have appropriate formats.
• ICE33: Validates that the Registry table is not used for data better suited for another table (Class, Extension, Verb, and so on).

Addressing ICE validation warnings and errors is an important step in the release process.

Versions[]

To check which version is currently installed, typemsiexec /? into the WindowsRun box or command prompt.

Tools[]

References[]

External links[]

• Windows installer start page
• Windows Installer Team Blog at MSDN.
  • Windows Installer 4.5 expected around Q2-2008 (blog)
• InstallSite.org "Resources for Setup Developers": This site publishes a usefulreleased MSI version matrix.
• Windows Installer 4.5 Software Development Kit standalone version, XP & Vista
• Windows Installer 5.0 Software Development Kit standalone for 5.0 not available, only the version integrated with Windows 7 SDK
• Windows Installer at Wikipedia

	Wikipedia (article:Windows Installer) This page usesCreative Commons Licensed content fromWikipedia (view authors).