Jump to content

Windows Installer

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by 220.237.33.21 (talk) at 05:49, 27 April 2008 (3.1 ships with XP SP3). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

The Windows Installer (previously known as Microsoft Installer, codename Darwin[1]) is an engine for the installation, maintenance, and removal of software on modern Microsoft Windows systems. The installation information, and often the files themselves, are packaged in installation packages, loosely relational databases structured as OLE Structured Storage Files and commonly known as "MSI files", from their default file extension. Windows Installer is a significant improvement over its predecessor, Setup API: several new features, such as a GUI framework, the automatic generation of the uninstallation sequence and the powerful deployment capabilities, made Windows Installer a viable alternative to stand-alone executable installer frameworks such as older versions of InstallShield and WISE (later versions of both products are based on Windows Installer) and NSIS.

Microsoft encourages 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 as rollback and versioning (which prevents DLL hell) depend on a consistent internal database for reliable operation.

Logical structure of packages

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

Products

A single, installed, working program (or set of programs) is a product. A product is identified by a unique GUID (the ProductCode property). A product is not the same as a package: a single MSI package might install multiple different products. For example, an MSI might install French and English versions of a program, each of which is a different product.

Components

A component 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 contain files, 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 of Merge Modules (although, for this to work correctly, different components should not share any sub-components).

Key paths

A key path is a specific file, registry key, or ODBC 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 term key 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 as self-healing or self-repair. No two components should use the same key path.

Features

A feature 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

The user 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 the Remove button in the Add 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 the Finish or Install 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 of sequences of actions, which query the installation database to build an internal script 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 Installer service (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 using Group 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[2]. 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). This mechanism can lead to the surprising situation whereby a failed uninstall leads to the application being re-installed.

Other features

Windows Installer can advertise a product rather than actually installing it[3]. The product will appear installed to the user, but it will not actually be installed until it is run for the first time (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.

Installation on demand

Similar to advertisement, it consists in the installation of features as soon as the user tries to use them[4].

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[5]. 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.

Miscellaneous

Windows Installer allows applications to run directly from a network 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 supports patches (.msp files) and other customizations of packages through manipulations (transforms or .mst files) of a package's relational database. Version 2.0 onwards, it supports digital 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 of InstallShield); and the format for file archives is the well documented cabinet file format.

Windows Vista

Windows Installer 4.0, which was shipped with Windows Vista, incorporates new capabilities to take advantage of Vista's User 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.

Diagnostic logging

Windows Installer supports detailed logging as a powerful diagnostic tool[6]. Logging can be enabled in the following ways:

  • Command-line: If installing an MSI package from the command-line, the /L switch can be used to enable logging. For example, the following command installs Package.msi and outputs verbose logging to c:\Package.log:
msiexec /i Package.msi /l*v c:\Package.log
  • Windows Registry: The following registry value can be used to enable verbose logging:
Key: HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer
Value Name: Logging
Type: REG_SZ
Data: voicewarmup

The resulting log is named MSI###.log (where "###" is a unique random identifier) and is placed in the user's Temp directory (the 'temp' directory location is per-user, and is pointed to by the environment variable %temp%).

  • Group Policy: The following Group Policy setting can be used to manage logging on multiple systems:
Computer Configuration -> Administrative Templates -> Windows Components -> Windows Installer -> Logging.
  • Windows Installer API: If installing an MSI package programmatically, the MsiEnableLog function call can be used to create a log file and set the logging level for the life of the calling process.
  • MsiLogging property: Windows Installer 4.0 introduces the MsiLogging property, which can be set to a list of flags indicating what information to log. The flags are similar to the flags that can be added to the /L switch to msiexec.exe or to the Logging policy setting. If MsiLogging is used, the MsiLogFileLocation property will be set to the location of the log file.

Although verbose logs are very useful for diagnosing Windows Installer problems, they can be very long and difficult to read without practice. A quick way to find the location of a problem in the log is to open it in a text editor (such as Notepad) and search for the phrase "Return Value 3". This entry commonly appears in logs close to the point where a critical error has occurred. The Windows Installer SDK provides a tool called WiLogUtl, which parses and annotates Windows Installer log files.

To output debug information in the log file, pass "x" on the command line or add it to the Logging registry value. For example, the following command installs Package.msi and outputs debug, verbose logging to c:\Package.log:

msiexec /i Package.msi /l*vx c:\Package.log

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.

Disadvantages

During installation, a copy of the .MSI package is copied to the user's temporary directory prior to installation, even if the same package is stored locally. InstallShield products create an additional copy of the MSI in the temporary directory if the install package is localized.

To prevent requiring the original installation source, Windows Installer packages and patches are cached in the %WinDir%\Installer directory (hidden by default). If the package builder chooses to use Installation on Demand or Repair feature in the package, the entire package (except for localization messages) and a stub .MSI package are copied to the %WinDir%\Installer directory.

A machine may be configured via group policy to create logs of all installation operations, such logs being created in the Windows temporary directory. These log files may be quite large with a full verbose log for a large package constituting several tens of megabytes. The log files can be useful for diagnostics, but if a user performs install related operations (install, uninstall, modify, repair or patching) with Windows Installer often, the space consumed by the logs can get out of hand. The logging policy is disabled by default, but some setup bootstrap programs may enable logging to assist customers in debugging installation problems. Microsoft does offer a tool called WILogUtl.exe to assist in processing Windows Installer log files[8].

MSI installation files tend to be larger in size than equivalent .zip or .rar files (or self-extracting .exe) as the file's internal database is not compressed.[9]

Versions

Version Shipped with [10] Redistributable
1.0 Office 2000 -
1.1 Windows 2000 Windows 95/98/NT 4.0 SP6
1.2 Windows Me -
2.0 Windows XP RTM/SP1, Windows 2000 SP3, Windows Server 2003 Windows 95/98/Me/NT 4.0 SP6/2000 below SP3
3.0 Windows XP SP2 Windows 2000 SP3/SP4, Windows XP RTM/SP1, Windows Server 2003
3.1 Windows Server 2003 SP1, Windows XP Professional x64 Edition, Windows XP SP3 Windows 2000 SP3/SP4, Windows XP RTM/SP1/SP2, Windows Server 2003
4.0 Windows Vista, Windows Server 2008 -
4.5 (pre-release)[11] Out-of-band release Windows Vista, Windows Server 2008, Windows XP SP2 and later, and Windows Server 2003 SP1 and later

See also

References

  1. ^ when setup isn't just xcopy
  2. ^ Rollback Installation
  3. ^ Advertisement
  4. ^ Installation-On-Demand
  5. ^ Administrative Installation
  6. ^ Windows Installer Logging
  7. ^ Internal Consistency Evaluators - ICEs
  8. ^ WILogUtl.exe
  9. ^ Why can I futher compress an MSI with a compressed CAB?
  10. ^ Released Versions of Windows Installer
  11. ^ What's New in Windows Installer 4.5
Retrieved from "https://en.wikipedia.org/w/index.php?title=Windows_Installer&oldid=208471074"