Windows Installer Takes Control

Manage Windows software installations more efficiently

Last year, I wrote about the application-deployment (or software-installation) features of Windows 2000 (Win2K) in "Application Management in NT 5.0," April 1998. Software installation is a function of Active Directory (AD)-based group policies that lets you publish or assign applications to users within your AD domains. The engine behind software installation is the Windows installer service. The Windows installer (formerly Microsoft Installer—MSI) is a set of APIs, tools, and services that let you describe, install, and maintain applications within your Windows environment. In this article, I describe how the Windows installer works, how you can take advantage of the installer, and when you can use this service—it might be sooner than you think.

The Problem
In any Windows infrastructure with more than several hundred workstations, one of the big problems that administrators face is application deployment and configuration management. Windows applications are difficult to package, deploy, and maintain. Throw in the fact that you might have to deploy and maintain applications across hundreds or thousands of remote sites, and you begin to understand the clamor about thin clients and serverside application development. Therefore, a standard way to describe an application, such as binary files (executables, DLLs, OLE custom controls—OCXs), Registry entries, and user settings, is necessary. Also, applications need to recognize and respect shared components. For example, suppose I have two applications: one I've written inhouse and one I've purchased. I don't want to deal with application conflicts that exist because the vendor decided to include a newer version of a Visual Basic (VB) OCX than the version I use internally. I do want to install the standard application description to my workstation in one procedure (without user intervention) and be able to roll the application back if the installation fails. I want the ability to update or remove the application later without a lot of pain, and I want intelligent applications that fix missing or corrupted file components.

Inside the Installer
The installer technology includes the installer engine, which runs on the workstation or server, and APIs that expose information about an application's state (i.e., whether it's installed or uninstalled). The installer engine and APIs install, upgrade, and remove applications. Microsoft sometimes uses the names Windows installer and MSI interchangeably; however, MSI describes only the installer files' packaging format (i.e., an .msi application file).

Microsoft has placed the installer technology—specifically, AD's use of the installer technology within group policies—among Win2K's IntelliMirror features. The goal of IntelliMirror is to intelligently mirror, or reproduce, the user experience to any location. The user experience includes the user's data, environment, desktop preferences (i.e., user profile), and applications. To reproduce the user experience regardless of a user's network connections or computer, Microsoft came up with an efficient way to manage application installations and deliver them to the user. First, Microsoft developed a standard for writing clean applications. A clean application refers to an application that correctly places Registry entries, doesn't overwrite shared DLLs, doesn't put binaries and DLLs in some odd directory (i.e., other than the Program Files folder), and lets a user roam to other computers after application installation.

Second, to facilitate reproducing the user experience, Microsoft uses AD to deliver the clean applications securely to a user or computer via group policy. When you publish or assign an application with AD, the directory doesn't store the application binary files and Registry changes but rather references to the installation package. At each workstation, the installer engine interacts with the published or assigned application packages to install the packages in just-in-time (JIT) fashion. The engine runs as a regular Windows NT service. Running in service mode, the engine takes care of security context problems. For example, most applications require you to modify HKEY_LOCAL_MACHINE Registry keys with security restrictions to exclude nonadministrative users. In addition, an application might require a user to log on before the application can make profile changes (i.e., HKEY_CURRENT_USER). The installer engine, which ordinarily runs as a service using the Local System service account, handles these dual security context requirements. An active user's NT Explorer shell invokes the installer engine, which performs both user- and computer-specific installations that the MSI package defines.

Let's use an example of a Windows 2000 Professional (Win2K Pro) installation to examine the installer engine's dual-security role in distributing applications to either a user or computer via group policy. Suppose I edit a Group Policy Object (GPO) to assign in AD a Microsoft Word MSI package that gets applied to user Jsmith. (For more information about the AD's GPOs, see "Application Management in NT 5.0," April 1998.) The next time Jsmith logs on to the Win2K Pro machine, he'll see a Word shortcut on the Start menu, because the installer engine has placed an icon that points to the MSI package for Word (not the full application) on Jsmith's desktop. The Word MSI package, which can reside on a network server, contains the local machine (e.g., binary files in the Program Files directory and Registry changes to HKEY_LOCAL_MACHINE) and user profile changes.

When Jsmith executes Word, the Explorer shell sees that the application isn't installed and goes to the AD to get more information. The AD points the shell at the MSI package for Word on the server. The installer service reads the MSI package and performs the installation process that requires the elevated security privileges. The installer copies the necessary binary files and Registry settings to the local machine. (The installer can copy files and settings because it runs under the Local System service account.) Because Jsmith initiated the installation after logging on, a separate client portion of the installer engine makes changes to the user profile. Figure 1 illustrates the process of installing Word 2000 on a user machine.

MSI packages. Now let's examine the MSI packaging format to learn how MSI files provide more efficiency than other installation technologies provide. The installer keeps application descriptions in the MSI package. An MSI file is more than simply a binary stream of setup information. An MSI file is an OLE-structured storage database file, which is different from a typical binary file. An OLE-structured storage file contains data that resembles database tables. This way of storing data is richer than a binary data stream. Whereas applications ordinarily read binary files sequentially bit by bit, an application that reads OLE-structured storage files scans tables by name.

An MSI file can contain more than 30 tables. For example, MSI tables include the file table, which describes the files associated with the application; the feature table, which describes the application's available features; the component table, which describes the features' components; and the Registry table, which describes the Registry entries associated with a component. The MSI package can use the compressed cabinet (CAB) format to store files. Smaller applications often use CAB files. Larger applications often use an MSI file to control installation and CAB files to store binaries.

The MSI file format defines a hierarchical structure for describing and installing an application and its components. This hierarchy is key to the installer's ability to intelligently install, uninstall, and upgrade applications. The structure's highest layer is the product, which contains numerous features that in turn contain multiple components. Figure 2 illustrates how this hierarchy works when Word 2000 is the product. Word contains numerous features, such as the core functionality, the spell checker, and clip art. Each feature contains one or more components.

Don't confuse an MSI component with a COM component. An MSI component can contain COM components. MSI components comprise files, the Registry, and shell information related to the features. For instance, within a component you define whether an application places shortcuts on the user's Start menu or desktop. MSI components aren't always specific to one feature or product. You can have Word 2000 and Microsoft Excel 2000 share a component such as a runtime library. Therefore, MSI components use a 128-bit globally unique ID (GUID) to guarantee unique identity across products and features.

In Screen 1, a beta version of InstallShield's packaging utility designed for the installer shows the relationship between products, features, and components. For example, the product Widget contains one feature called Widget Core. The Widget Core feature contains two components: Widget Core and Widget Filters. As Screen 1 shows, files, Registry entries, shortcuts (shell objects), COM servers, and even NT services can make up a component.

Components are the smallest unit of installation within an MSI package and are the means to the installer's ability to self-heal applications. (Self-healing refers to an application's ability to detect when parts necessary for the application to run are missing or corrupted, then reinstall the missing or corrupted parts.) You can use a utility such as InstallShield to package your application and assign a key file or Registry entry within an MSI component. Note that a component can have only one key file or Registry entry, so you need to either choose the most crucial component element or break your component down into multiple smaller components. When the user installs the application, each component's key file or Registry entry is tracked in the Registry. If a user deletes the key file at some later date, the installer engine will detect the deletion and reinstall the component from the installation source.

Installer transform files. When you buy software such as Microsoft Office, you might run setup.exe to install a generic configuration, then customize the configuration. Alternatively, you might use the Office Setup wizards to customize the .stf file and control the Office setup installation. Using transform files, the installer technology lets you customize an MSI package at installation. Transform files (i.e., .mst files) install when .msi files install and let you make changes to the default vendor-provided installation. Transform files are most useful when you buy third-party software and want to use the vendor-provided MSI package but also want customizations specific to your business environment.

The installer engine. The installer engine, a set of DLLs and msiexec.exe, controls the installer's internal operations. Msiexec.exe performs the installation of the MSI files. You can run msiexec.exe as a service or interactively. When you assign or publish an application to a Win2K client using AD, the installer service initiates the installa-tion. If you double-click an MSI file in a folder through the Explorer shell, msiexec.exe runs interactively, the way any shell association runs. A Registry setting on a given machine controls the installer engine's ability to elevate the installation's security context whether you run an MSI file interactively or as a function of AD publishing and assigning. The Registry setting that controls this ability is in HKEY_LOCAL_MACHINESOFTWAREPoliciesMicrosoftWindowsInstallerAlwaysInstallElevated. You need to set the value equal to 1 to ensure that all MSI installations take advantage of the installer service's elevated security context.

How to Use the Installer Technology
To take advantage of the installer technology, you need to have an MSI package for each of your applications. You can purchase third-party applications that are Win2K Logo Program-compliant and therefore must ship with an MSI-based installation routine. Microsoft's Win2K Logo Program (http://msdn
.microsoft.com/developer/winlogo/win2000.htm) sets the standard for building and packaging clean applications, requiring a specific implementation for applications to receive certification. Microsoft recently consolidated the program's basic and gold levels into one level that requires an MSI package for logo compliance.

You might have many internally developed or custom applications (i.e., applications packaged using earlier installation utilities) that you need to make MSI-aware. You can use MSI to repackage legacy applications in a couple of ways. The easiest way is to take a snapshot of an application installation with an MSI-aware installer utility such as Seagate Software's WinINSTALL. A snapshot captures the changes an application makes to a workstation and stores the changes for future installations. If you want to quickly repackage a large number of applications for deployment via the installer, snapshots might meet your needs. When you take a snapshot, you have some control over what elements become features and what elements become components, but you can't take full advantage of the MSI format.

If you decide to spend the necessary time to analyze your applications and divide them into features and components that better use installer features, you can natively reauthor applications with an installer-capable packaging utility. For example, InstallShield, Seagate Software, and Wise Solutions are working on installer-aware upgrades to their flagship installation products.

When you natively reauthor an application setup, you need to consider the installer technology benefits and package your application accordingly. For example, if your application has a COM component that many other applications use, you might want to package that COM component's set of files and Registry entries as a standalone MSI component. Then, multiple MSI products or features can reuse that set of files and Registry entries. Suppose your application uses a certain function frequently but uses some other function infrequently. In this case, you might want to separate the functions into two MSI features and let the user install the infrequently used function on the fly. Although natively reauthoring an application setup can be time-consuming, reauthoring can confer benefits when you need to repair or upgrade your application.

Start Using the Installer
The installer technology works great for managing application deployments. And you don't have to wait for Win2K to obtain the installer. Microsoft will make the installer engine available for NT 4.0 and Windows 9x so that you can install Office 2000, which ships using the MSI format. A bootstrap program will come with the MSI file that loads the installer engine on your NT or Win9x workstation before you install Office 2000. Other applications can use the installer engine to install any MSI package in earlier version environments. I expect Microsoft to make a separate installer engine package available for download to environments using earlier versions of Microsoft applications, so you won't have to buy Office 2000 to use Windows installer technology.

Control Your Applications
The Windows installer application-installation technology has been a long time in coming. Start planning to move your application-installation packages to the MSI format. Talk with your packaging utility vendors to learn about your options, and decide which applications you want to natively reauthor and which applications you will repackage. In some cases, you might want to take old setup formats and import them directly into an MSI-capable tool.

The installer technology lets you better control software configuration and management in the Windows environment. If you rely on Windows applications to run your business, I recommend that you begin using this new technology as soon as possible.