What Windows administrator doesn't recognize the letters "msi"? The Windows Installer service (the msiexec.exe program) and its .msi file package component are the de facto technology for Windows application setup. You're probably familiar with the primary benefits of using a Windows Installer application setup package. First, if a problem occurs during setup, the .msi package undoes the part of the installation it performed and rolls back—or restores—the computer to its previous state, thereby avoiding damage to the application or system. Additionally, an .msi-packaged application can repair itself when a user deletes a file from it. Finally, Windows Installer lets you use Group Policy to install software on users' systems. Although you probably know the basics of Windows Installer, a more in-depth knowledge of how Windows Installer and its .msi packages work "under the covers" can help you create custom application setup packages and better troubleshoot application setups. We'll start with a high-level review of the Windows Installer technology, then explore the structure of .msi packages and how they interact with the Windows Installer service.
Windows Installer Technology
Microsoft first shipped the Windows Installer technology about 4 years ago and subsequently made Windows Installer a core part of the Windows 2000 Server OS. Windows Installer 2.0 is included in Windows Server 2003 and Windows XP and includes support for Microsoft .NET assemblies (the unit of installation in .NET). Microsoft makes Windows Installer available in two ways: in the Windows OS as the Windows Installer service and as a software development kit (SDK). The Windows Installer service is the engine that installs Windows Installer packages (i.e., .msi files). The SDK contains specifications and APIs that govern the format and function of .msi files. You can download the Windows Installer SDK, which is part of the Platform SDK, at http://www.microsoft.com/msdownload/platformsdk/sdkupdate/sdkinfo.htm. Developers and vendors of application-packaging tools such as InstallShield Software, OnDemand Software, and Wise Solutions (now part of Altiris) use the SDK to create application setup packages. Developers often use application-packaging tools, which repackage old application setups into the Windows Installer format, to hide from users much of the complexity of the Windows Installer technology.
Products, Features, and Components
An .msi file is a complex database of application-installation instructions that contains dozens of tables, hundreds of columns, and sometimes other embedded files. The database contains information such as OS requirements for installing the application, steps to perform during the installation, and even the dialog boxes to present during setup.
An .msi file comprises a three-part hierarchy. The highest level is the product—the software application itself. A product has a unique product code that's represented as a globally unique identifier (GUID). At the next level are features within the product. Features are referenced by name and represent product functions that a user can choose to install. Figure 1 shows an example of features within an application setup—in this case, Microsoft Office Access and Microsoft Office Excel within a Microsoft Office setup. A feature is the unit of installation within a Windows Installer package. That is, when Windows Installer installs a package, Windows Installer installs (or uninstalls) features rather than individual files.
In Figure 1, you can see that Excel has many subfeatures, such as Help and Spreadsheet Templates. For each feature, the user can decide, at installation time, which subfeatures are installed locally on the user's computer or run from a server, which are "advertised" to be installed on the first use (signified by a 1 on the icon for a given subfeature), and which aren't installed at all. (For an explanation of advertisements, see the sidebar "The Power of Advertisements," page 62.)
Features consist of components—the third level of the .msi file hierarchy. A component is the basic unit of a Windows Installer package and is the building block of an application. A component can be a file or set of files, a registry setting, a shortcut, or a resource (e.g., icons). A key path is associated with the component. The key path designates the file or setting that must exist for the component to be fully installed. The key path is the basis of the self-repairing nature of Windows Installer-based packages. When Windows Installer repairs an .msi packaged application, the Windows Installer service checks all key paths of all components in the application for completeness. If a key path for a particular component is missing, the Windows Installer service traces the component to the feature it belongs to and reinstalls the feature. Thus, the time needed to repair an installed application depends in part on the number of components in the application package and the number of components that exist within the feature that contains the broken component.
The Windows Installer Database
As I mentioned earlier, an .msi file is a set of setup instructions organized as tables in a database. The Windows Installer SDK defines each table and column. You can use the Orca database editor tool in the Windows Installer SDK to view and edit the contents of an .msi file. The setup .msi file for Orca is in the \bin directory under the Platform SDK installation directory (e.g., c:\program files\platform sdk\bin). After you've installed Orca, you can open any .msi file. When you open a file in Orca, you'll see a list of the file's tables in the left pane of the Orca interface. When you highlight a table, you'll see its rows and columns in the right pane.
Figure 2 shows the LaunchCondition table in the Windows Installer package for Group Policy Management Console (GPMC). In the right pane, the table describes the minimum OS and platform requirements to install GPMC. The Condition column is a set of conditions that must be met during installation. The Description column describes the minimum requirements for the set of conditions. When Windows Installer begins to install the application, Windows Installer determines whether the launch conditions are met before proceeding with the rest of the installation.