Before the release of Windows 2000, no clearly defined rules governed application installations on Microsoft platforms. Microsoft integrated Microsoft Windows Installer technology into Win2K to enforce standardized installation rules. Microsoft hopes that this centralized control of the installation process will eliminate the numerous problems that applications' varying installation routines create.

Two Core Components
At Windows Installer's core is the Windows Installer service (msiexec.exe). In addition to enforcing installation rules, the service provides a management API. This API is a common point of reference by which applications can locate appropriate file and directory paths. The API also helps ensure that applications install successfully, regardless of the inevitable path differences among an organization's computers.

The Windows Installer (.msi) package file is the other vital component of Windows Installer. For an application to work with the Windows Installer service (and to be eligible for the Windows Logo program), the vendor must package the application in an .msi format. The .msi package is a relational database for setups that use the Windows Installer service. The package's more than 70 interrelated tables contain installation instructions, program logic, and configurations for the application and its associated files, features, components, paths, and registry entries. In addition to these tables, an .msi package can contain embedded items such as application summary information and compressed cabinet format (.cab) files. For more information about Windows Installer, see Darren Mar-Elia, "Windows Installer Takes Control," InstantDoc ID 5380.

Features and Benefits
Why use Windows Installer technology if your traditional installation methods work fine and varying installation routines don't give you any problems? The Windows Installer service and .msi files combine to provide several features and benefits.

Transacted installations. Windows Installer records all .msi package installation actions to a transaction log. Until the installation completes successfully, Windows Installer also saves backup copies of files that the installation deletes and overwrites. These features ensure that installation leaves no individual action incomplete. Interrupted installations are also less likely to render your system unusable. If you experience a midroutine failure, the transaction log and the saved files let you roll back the PC to its preinstallation state.

Shared resource management. Because the Windows Installer service provides centralized installation management, the service can keep tabs on the resources (both files and registry settings) that applications use. This feature prevents DLL Hell, a problem that occurs when uninstalling an application deletes a .dll file that another application also uses.

On-demand installation. Also known as just-in-time (JIT) installation, this feature installs software as needed. Windows Installer supports on-demand installation at the feature level and at the product level.

Feature-level on-demand installation provides additional components to a previously installed product. For example, a user can choose Spelling and Grammar from Microsoft Word's Tools menu at any time to invoke an installation of these tools. Feature-level on-demand installation is available to all Windows platforms that support Windows Installer.

Product-level on-demand installation requires an Active Directory (AD) environment and Win2K clients. Administrators use this Windows Installer feature to assign or publish applications in AD. End users either automatically receive the application or can double-click a shortcut on their desktops to activate product installation.

Self-healing. When a user launches an application (or a feature within an application), the application queries the Windows Installer service for the installation path. Windows Installer then verifies that all the application's necessary components are correctly installed and automatically reinstalls missing or damaged components.

Source file resiliency. On-demand installation and self-healing depend on source files being readily available. By default, the Windows Installer service looks to the original installation path to find the source files for necessary installations and reinstallations. If the service doesn't find the correct source files, it refers to a backup list of source file locations that an administrator can specify in a transform. (You can use msiexec.exe command-line options to add source paths to the list.)

Clear product identification. Microsoft requires that developers use globally unique IDs (GUIDs), which consist of 32-character hexadecimal numbers, to identify product versions and upgrade codes. These IDs help prevent problems such as older product versions overwriting newer versions.

Patching. Windows Installer also uses GUIDs to identify whether an application installation requires a patch. The patching process is similar to the .msi package installation process. However, administrators typically initiate patching through AD. Your system retains the patches you apply so that Windows Installer can reapply the patch if the original application is ever reinstalled.

Roaming-user support. Microsoft designed IntelliMirror to efficiently deliver data and applications to roaming users. Windows Installer's product-level on-demand installation is crucial to IntelliMirror's ability to replicate users' workstation environments wherever users log on to the corporate network.

Administrative control. The Windows Installer service runs in the Local System account. This context lets administrators install applications that typically require administrator privileges without having to visit each desktop. In an AD environment, administrators can decide which applications they can install with these elevated privileges. In a Windows NT environment, an administrator has control only of whether the Windows Installer service runs with elevated privileges; the administrator can't apply elevated privileges on an application-specific basis.

Legacy OS compatibility. You can leverage most of Windows Installer's features and benefits without AD. You can also add Windows Installer technology to the NT and Windows 9x platforms. Thus, whatever your Windows platform, you likely can use Windows Installer to improve application reliability and reduce administrative overhead.

Upgrading Your Customization Methods
Before you can take full advantage of Windows Installer, you need to update your methodology and tools for customizing and packaging applications. Historically, administrators have customized installation packages in various ways. Before Windows Installer, a few applications provided customized installation tools or command-line options for controlling their installation routines. To customize the installations of most applications, you needed to write a custom script or use snapshot technology.

Many application deployment tools and standalone utilities offer snapshot technology that lets you capture the changes an application makes during setup (e.g., options you select, registry modifications setup makes) and records the changes to a script file that you can edit. However, snapshots are primarily a one-dimensional technology: They can capture what they "see," but they can't capture the numerous logical threads that most setup routines run behind the scenes. Furthermore, most snapshot utilities don't create .msi packages: If you take a snapshot of an .msi package installation, the result is a non-.msi package that has no Windows Installer functionality. (An exception is VERITAS Software's WinINSTALL Limited Edition—LE—tool, which comes on the Win2K server CD-ROM.) For this reason, you need to follow Microsoft's recommended procedures for customizing .msi package installations—that is, you need to use transforms.

Most administrators don't have the Windows Installer expertise to customize complex .msi packages without using a tool such as InstallShield Software's InstallShield Tuner. This tool lets you easily create and validate transforms while leaving .msi package complexities to developers.