Sequence tables are the heart of an .msi database and list the actions that Windows Installer must perform during an installation and the order in which it must perform them. For example, a sequence table tells the Installer engine to first check the launch conditions specified in the LaunchCondition table, then to copy the source files to the destination directory and make a set of registry entries. Sequence tables come in three types: Admin, Advertisement, and Install. The type of sequence table that Windows Installer uses depends on the type of installation it performs. Table 1 describes the three sequence table types.
Each sequence table type has two associated tables. One table—InstallUISequence—defines the UI dialog boxes that should be displayed in an interactive (i.e., user-driven) installation. The other table—the so-called "execute sequence" table (i.e., InstallExecuteSequence)—defines the steps necessary to perform the installation.
A sequence consists of a set of predefined standard actions that are included in Windows Installer and are listed in the InstallExecuteSequence table's Action column. The standard actions perform a variety of tasks—such as copying files, checking for newer versions of the software, and determining how much disk space is available for the installation. The SDK documentation and Orca give you a detailed look at what a particular Windows Installer package is up to. You can also use Orca to create custom actions that perform tasks that the standard actions in a Windows Installer package don't perform. A custom action might be a DLL that you write or even VBScript code that performs tasks such as checking Active Directory (AD) for certain values before continuing an installation.
The Property table is another important part of an .msi database. Properties are constants that you can define to control an installation's behavior. You can think of properties as environment variables for an .msi file. A frequently used property in Windows Installer packages is ALLUSERS, which tells the installation how application configuration information is stored—either per user or per machine. Property names are case sensitive, and you can provide them at the command line at installation time (as I explain later) or by using a transform (which I describe in the next section).
Transforms, Patches, and Merge Modules
When you obtain an .msi file from a vendor, chances are the .msi file won't do everything you need to deploy the package in your environment. For example, you might want to deploy the package silently using a software-distribution tool or install only certain features. Transforms are useful in such cases. A transform is a special type of .msi database file and usually has an .mst extension. Transforms apply to an application's setup at installation time. Essentially, they modify the default values in an .msi package to control the installation behavior as it occurs. The modified values aren't actually saved in the .msi file; they simply control what happens during a specific installation.
In contrast to transforms are patch files, or .msp files. Typically, a vendor issues a patch file when it wants to update a product but not issue a major release—security patches are good examples of a patch file. Installing a patch file permanently modifies the copy of the .msi file that's cached on the user's workstation. You should also apply any patch files to the application's source package to ensure that subsequent new users obtain the updated files.
Yet another variation of the .msi file is the merge module, or .msm file, a set of components that are frequently reused in application setups. For example, various third-party applications might use Microsoft Data Access Components (MDAC). Instead of reauthoring a setup for these shared components in every new .msi package, application packagers can reuse merge modules that the shared-component vendor provides. Merge modules are simplified .msi database files that contain only the features and components that application setups must share. Often, the actual component files are embedded in the .msm file itself, which lets application packages easily share merge modules. The .msm files are then merged into the main application Windows Installer package at package-authoring time.
When you author a new setup package, you can include the application files within the .msi file. Typically, files are included as embedded cabinet (.cab) files, which are compressed collections of files similar to .zip files. Including a .cab file in an .msi file is usually practical only if the .cab file isn't overly large. For example, Office has separate .msi and .cab files because the Office .cab files comprise several hundred megabytes. However, for smaller applications, including all required files for the application within the .msi file makes the file portable and easy to distribute to users. If you have an .msi file that includes an embedded .cab file, you can use the Windows Installer SDK's msidb.exe tool to extract the .cab file.
The Windows Installer Service
Windows Installer packages have a mutually dependent relationship with the Windows Installer service: Neither can exist without the other. Windows installs the Installer service by default on all post-Win2K versions of the OS; you can install a redistributable version—that is, a standalone version of the Installer service and related DLLs—on Windows NT Server 4.0 and Windows 9x. The Installer service runs in the context of the privileged LocalSystem user account. To start the Windows Installer service, you double-click an .msi file (e.g., in Windows Explorer); starting the service spawns a new Installer process (msiexec.exe) under the context of your user credentials. After Windows Installer has finished installing an application, the Installer service shuts down until the next time you use it.
The Windows Installer service provides a set of functions that are handy for deploying software, especially when you use them with the Software Installation feature in Group Policy. Chief among these functions is privilege escalation. When a typical nonadministrative, nonpower user tries to install an application on his or her computer by double-clicking an .msi file, the user's default privileges probably won't be sufficient to complete the installation. However, when you deploy the application through Group Policy's Software Installation feature, the Windows Installer service executes the installation using its LocalSystem security context.
Prev. page
1
[2]
3
next page 
