Microsoft® Windows® Installer is a base service of the Microsoft Windows operating system that enables you to manage the state of software applications. The managed state of an application includes installation, modification, upgrade, or removal. Windows Installer provides you with consistent and reliable methods to customize installations, update and upgrade applications, and resolve configuration problems. It can also manage shared resources, enforce consistent file version rules, and diagnose and repair applications at runtime. This advanced level paper is intended for system administrators familiar with managing applications.

On This Page

Introduction
Overview of Windows Installer
New Technologies in Windows XP Professional and Windows Server 2003
Windows Installer Technology
Packaging Applications for Windows Installer
Customizing Windows Installer Applications
Installing Software by Using Administrator-Level Privileges
Microsoft Software Distribution Technologies
Patching and Upgrading Software Applications
Managing Windows Installer by Using Group Policy
Troubleshooting Software Installations
Windows Installer Administration Tools
Appendix A: An Annotated Windows Installer Log File
Related Links
Acknowledgements

Introduction

If you manage the software in your organization, you already know that installing, tracking, and maintaining a variety of software applications can often become a complex task. This is because most setup programs do not adequately manage shared resources to enforce consistent installation rules, provide easy customization, help you decide which pieces of an application users might need, or help you diagnose and repair configuration problems.

Microsoft® Windows® Installer is a base service of the Microsoft Windows operating system that enables you to manage the state of software applications. The managed state of an application includes installation, modification, upgrade, or removal. Windows Installer provides you with consistent and reliable methods to customize installations, update and upgrade applications, and resolve configuration problems. It can also manage shared resources, enforce consistent file version rules, and diagnose and repair applications at runtime.

Overview of Windows Installer

Prior to Windows Installer, software applications used various setup technologies, each of which contained unique installation rules for each application. At times, the applications did the wrong things at setup time. For instance, an earlier version of a particular file might be installed over a newer version of that same file. Some setup technologies made it difficult to maintain accurate reference counts on shared components for the many applications installed on a computer. As a result, installing or removing certain applications might break other applications.

Using Windows Installer, the operating system implements all of the proper installation rules. To adhere to those rules and to avoid the problems described in the preceding paragraph, an application needs only to describe itself in a Windows Installer package. Windows Installer then performs the installation tasks for each application, which can help you prevent or minimize common installation problems.

Adding, Upgrading, or Deleting an Application Can Damage Other Installed Applications

Prior to Windows Installer, adding, upgrading, or deleting an application can break other existing applications on a computer — or worse, it can break the operating system. There are many causes of this type of problem, and Windows Installer takes steps to minimize them. A few of the ways Windows Installer solves such problems are detailed in the following subsections.

Providing consistent and reliable version rules

Traditionally, software manufacturers delivered a unique setup program for each application. When an application was added, modified, upgraded, or removed from a system, the setup program enforced its own rules, such as providing version-control directives. Because each setup program provided its own rules, interactions among two or more applications sometimes caused conflicting results. For example, newer versions of shared files might be replaced with older ones. As a result, applications that required the newer version of the file were not successfully and completely installed. A failed installation could cause other applications not to function.

You can avoid this problem by taking advantage of Windows Installer. Windows Installer provides consistent and reliable installation for all applications, which prevents newer files from being overwritten by older files.

Providing system-wide management of shared resources

Inter-application conflicts can occur when uninstalling one application removes files shared by other applications on the computer.

Windows Installer addresses this problem by keeping track of the resources that Windows Installer-based applications use. For example, several products include the Grid Control for Microsoft® Visual Basic®, which uses Windows Installer. After this control is installed, Windows Installer detects its presence. When you install other products that use the Grid Control, each product is added to the client list for the Grid Control. Windows Installer references these client lists when installing, upgrading, or removing components.

Windows Installer maintains and manages all setup and installation information about each product it installs. When you uninstall a product, Windows Installer does not remove any component that has other applications in its client list. This capability is available with other setup technologies, but it requires some complex coordination of several products from various manufacturers, which use numerous installation technologies. This process is not recommended because it is unreliable.

Windows Installer provides an additional advantage: The installation logic for Visual Basic for Applications (VBA) is encapsulated within a reusable Windows Installer module. Therefore, all software products that incorporate VBA, regardless of the software manufacturer, install and remove VBA as intended by the Visual Basic developer.

A Failed Attempt to Change the State of an Application Can Destabilize the System

In earlier setup technologies, a failure occurring during an attempt to change the state of an application might leave the application or the entire system unstable. Troubleshooting a failure of this type was quite labor-intensive.

Restoring the pre-installation state of a computer

Windows Installer keeps track of all the changes it makes to a computer. Therefore, if you attempt to add, modify, or remove an application and the action fails, Windows Installer restores the computer to its previous state. The restoration procedure is known as a rollback.

With earlier setup technologies, if an upgraded version of an application failed, neither version remained in a functional state. With Windows Installer, if an application upgrade fails, the system reverts the computer and its contents to its original state.

A custom action, such as calling functions written in VBScript or Jscript, is functionality launched by Windows Installer but not implemented or controlled by it. To maintain complete rollback capabilities for any application, the application developers must provide the functionality for the rollback of the custom action. In some cases, a custom action, such as changing the schema of a database, complete rollback is not always possible.

Customizing the Setup for Applications Can Be Complicated

Many organizations want to customize application installations to help them meet their unique business requirements. A simple customization might involve configuring the installation process to proceed without user input. This type of installation is commonly known as silent mode. A more complex situation might involve fully customizing the content of an installation by adding, removing, or changing files and other resources that are to be installed.

In the past, application manufacturers delivered a unique setup program for each application. In some cases, the setup program that was supplied with the application allowed a limited amount of customization (e.g. setup.inf format). However, IT personnel frequently had to manually customize and repackage applications that did not allow customization. The command-line interface to control the change of state for each application also varied, requiring administrators to spend time learning different managerial facilities for each program. For example, the command-line option to uninstall an application could have been: /u, /r, /x, -u, -r, -x, or something totally different. Installing an application per user or per computer sometimes required radically different procedures.

Windows Installer enables you to customize a broad set of applications in standard ways by using the following:

• Command-line options.

• Properties (variables) on the command line. Properties are variables that Windows Installer uses during an installation. A subset of these, called public properties, can be set on the command line.

• Transforms. A transform is a collection of changes you can apply to a base .msi file. You can customize applications by using Windows Installer transform (.mst) files. You configure transforms to modify a Windows Installer package to dynamically affect installation behavior according to your requirements. You associate transforms with a Windows Installer package (an .msi file) at deployment time.

Providing a standardized command-line interface

By providing a standard installation engine and packaging format for applications, the Windows Installer technology allows all applications using it to share the same Windows Installer properties and command-line options.

For example, for every application installed by Windows Installer, the command-line option to perform an installation without displaying a user interface is "/qn." To install the same application for all users of a computer, use the property ALLUSERS=1.

Providing a standard way of customizing applications

Windows Installer provides a standard packaging format for applications and a standard method for customizing applications. You can tailor an application to a particular group of users by taking the application's .msi file and customizing it by creating and using a transform that installs a selected set of features for that group of users. For example, for a group of users in the finance department, you might create a Microsoft® Office transform that installs a special set of finance tools in Microsoft® Excel. For a group of users in the marketing department, you might create a transform that installs a particular set of Microsoft® PowerPoint templates.

In most deployment situations, you need only to maintain a single .msi file for each application and a library of transforms that you can apply to such files. For more information about the standard Windows Installer package formats, .msi and .mst, see "Windows Installer Packages" and "Customizing Windows Installer Applications" later in this paper.

At its basic level, a transform file contains a set of differences between the base package (provided by the application manufacturer) and the customized package.

You can also use a transform to answer all installation questions for the user. This can eliminate the need for user intervention during the installation of an application while replacing the manufacturer's defaults with defaults appropriate for your organization. This is particularly useful in customizing and performing unattended installations.

The following are the most common application customizations that you can generate using transforms. You can:

• Specify the features to be installed.

• Define the level of user intervention permitted during an installation. This works in combination with the command-line options you set.

• Specify the answers to be provided to the Setup UI during the installation.

• Specify a location to install the files.

• Specify the placement of shortcuts.

• Add files to the installation.

• Specify the registry settings to be added or changed during the installation.

Distributing Software to Low-Rights Users Can Be Difficult

Users in an environment where they have very few rights are called low-rights users. You can restrict the rights of users of Windows XP Professional, Windows 2000 Professional, or Microsoft Windows NT by locking down their computers. To create this type of environment, exclude the low rights users from the Administrators and Power Users security groups on the workstation. This increases system stability and uptime. However, these users have insufficient rights to install software, which typically prevents you from distributing software to them.

Installing software that has elevated privileges controlled by the administrator

In the past, it was common for software distribution technologies to include an installation agent on the computers it managed. This installation agent enabled administrators to install software to the computer, the All Users profile, regardless of the privileges of individual users on the computer.

The Windows Installer service provides revolutionary functionality. It gives you elevated privileges that enable you to install and control software within a user's profile. Using administrator level privileges, you can use Windows Installer to install administrator-specified packages, in the context of a user who is logged on, regardless of the privileges of the individual logged on to the computer. Currently, only the Group Policy-based software deployment component of Windows Server 2003 and Windows 2000 Server takes advantage of this functionality.

Administrators can leverage Windows NT 4.0 System Policy and Windows Server 2003 and Windows 2000 Server Group Policy with Windows-based security to prevent users from installing applications not required for their jobs. This can help you reduce management costs substantially. For more information about installing applications by using elevated privileges, see "Installing Software By Using Administrator-Level Privileges" later in this paper.

Note: The function of installing software by using elevated privileges is not provided in Windows 95, Windows 98, and Windows Me because users have administrative rights assigned to them for their own computers.

Accidentally Deleting a File Could Require That You Reinstall the Application

Prior to Windows Installer, if a user required an application feature that was not installed initially, an administrator or the user had to re-run the setup program. Typically the user faced a time-consuming task of exiting the application, re-running the setup program, determining which feature is required, installing the feature, launching the application, and getting back to the starting point. Many users resorted to installing all features of the application during initial installation, which sometimes saved effort, but more often wasted disk space by storing unnecessary features.

On-demand installation

Using Windows Installer, you can configure applications to initially install a minimal subset of features. Later, when a user selects a feature for the first time, additional components, required by that feature are automatically installed. For example, you can configure Windows Installer to install a word processor application that has a minimal set of features. The first time a user attempts to access a mail merge function included with the original installation, Windows Installer installs the mail merge component.

You can modify the feature set that you want to install initially to balance disk usage, and the number of on-demand installs that a user can take advantage of.

New Technologies in Windows XP Professional and Windows Server 2003

Microsoft® Windows ®XP Professional and Windows® .NET Server introduce new features that can increase the security of information in your organization and also the usability and manageability of Windows Installer.

Windows XP Professional 64-Bit Edition

In the Windows XP Professional 64-bit edition, Windows Installer is implemented as a native 64-bit service. This service handles the installation of both 32- and 64-bit applications. Applications that are 64-bit are packaged in specially marked 64-bit Windows Installer packages. These packages enable installation of both 32- and 64-bit components.

The 32-bit packages installed in the Windows XP Professional 64-bit edition can run under the Windows on Windows 64-bit subsystem. However, packages that are designed for 64-bit edition cannot be installed in the 32-bit edition. Users must obtain a 32-bit version of the application to use on the 32-bit Windows edition.

Software Restriction Policies

The increased role of the Internet in business increases security threats to your network from viruses. Using Windows Server 2003's software restriction policies, you can protect your computer environment from suspect code by identifying and specifying the applications that are allowed to run. The system identifies each application by using a hash rule, a certificate rule, a path rule, or an Internet zone rule.

Windows Installer packages, patches, and transforms are affected by software restriction policies. The levels for configuring to allow users to run a piece of code are either "unrestricted" or "restricted." In particular, Windows Installer only runs packages that you set at the "unrestricted" level. If any transforms or patches are involved in an installation, you must set them to run at the "unrestricted" level for the installation to succeed.

If you configure a software restriction policy to run a package at a level other than "unrestricted," Windows Installer displays an error message explaining that a policy is in place that prevents this application from being installed. Windows Installer also logs an event in the application Event Log.

The system evaluates the software restriction policy when you first install an application, when you apply a new patch, or when Windows Installer needs to re-cache the installation package for an application. You can apply software restriction policy to all Windows Installer packages for administrators and non-administrators.

System Restore

System Restore is a feature of only the Windows XP Professional, Windows® Me, and Windows® XP Home Edition operating systems. Users can use System Restore to reverse harmful changes to their computer caused by installing or uninstalling applications. This feature enables the user to return the computer to an earlier state known as the restore point. Windows Installer automatically creates a restore point each time an application is installed or removed. Restore points identify the name of the application and the stage of the installing (or uninstalling) that application. The System Restore wizard helps a user return a computer to the state just prior to installing or uninstalling the application. You can prevent Windows Installer from creating restore points by setting the Disable Creation of System Restore Checkpoints policy.

For more information about configuring and managing Windows Installer, see "Managing The Windows Installer Service Using Group Policy" in this paper.

Windows Installer Technology

Windows Installer is an engine you can use to manage the state of an application. The state of an application includes installation, modification, upgrade, or removal.

Windows Installer is not a software distribution technology. Software-distribution technologies use Windows Installer to install and manage software applications. Currently, most software distribution technologies rely on Windows Installer's command-line capabilities to install and manage Windows Installer–based applications. The Group Policy-based software deployment component of Windows Server 2003 provides enhanced benefits to administrators by using the advanced functionality in Windows Installer.

The Windows Installer technology is made up of three elements that work together: the Windows Installer client, the Windows Installer service, and the Windows Installer package (an .msi file.)

Windows Installer Client

The Windows Installer client is any application that calls Windows Installer to perform a task. Some common clients include the following:

• The Windows-based shell.

• Add or Remove Programs in Control Panel of Windows XP Professional and Windows 2000 Professional.

• Windows Installer-enabled applications, such as Office 2000.

• Software distribution technologies, such as Systems Management Server (SMS) and the software installation component of Group Policy included with Windows Server 2003 and Windows 2000 Server.

The Windows Installer client is responsible for user interactions such as displaying the Setup user interface during an installation. For example, the Windows Installer client uses the Windows Installer service to change the computer state by copying files and writing registry changes. Earlier approaches required each application vendor to deliver a unique program for each installation state change for every application.

Windows Installer Service

The Windows Installer service uses information in a Windows Installer package file to manage all phases of installing a program-- add, change, upgrade, and remove. The Windows Installer service performs all installation-related tasks as needed by copying files onto the hard disk, making registry modifications, creating shortcuts on the desktop, and displaying dialog boxes to capture user installation preferences.

Note: The Windows Installer service is part of the Windows XP Professional, Windows 2000 Professional, and Windows Me operating systems and is available for the Windows 95, Windows 98, and Windows NT 4.0 operating systems.

Windows Installer Packages

Each Windows Installer package (.msi) file contains a database that stores all the instructions for the Windows Installer service and data required to manage the state of a program, such as adding, changing, or removing it from a computer. For example, an .msi file of an application can contain instructions for installing the application when a prior version of the application is already installed. The .msi file could also contain instructions for installing the software on a computer where that application has never been present. To simplify creating and customizing .msi files, setup program authoring tool vendors have developed various authoring tools for Windows Installer.

For more information about Windows Installer authoring tools, see "Windows Installer Administration Tools" later in this paper.

Typically, a Windows Installer package file is located in the root folder of the product CD or network image that contains the product files. The product files can exist as compressed files known as cabinet (.cab) files. Figure 1 illustrates an example of the contents of a typical Windows Installer package.

For more information about using package files, see "Packaging Applications for Windows Installer" later in this paper.

Categorizing Product Elements

Most existing installation software uses procedural scripts to deliver a collection of separate files, registry keys, and other resources. In contrast, Windows Installer categorizes the elements of an application or product into three containers: components, features, and products:

• A Windows Installer component is a collection of files, registry keys, and other resources that are installed or uninstalled together on the client computer.

• Windows Installer features are groupings of components. Features are the granular pieces of an application that a user can choose to install, and typically they represent the functional elements of the application, such as the spelling checker in Microsoft Word.

• A Windows Installer product can represent a single application such as Microsoft Project or a suite of applications such as Microsoft Office.

An installable resource is defined as a file, registry key, shortcut, or any other piece that installation software typically delivers to a computer. Within this section, an installable resource is called a resource.

Windows Installer Components

A Windows Installer component is the smallest and most fundamental of the three logical containers. When a user selects a component for installation or removal, all of the resources in that component are either installed or removed. Components are essentially the containers that are not exposed to the user.

A resource can be part of only one component. For example, no two components share the same file, whether they are part of the same product or parts of different products. To include a common file, two applications must include the same common component. Because of this restriction, components are typically small, consisting of a file and other resources that are tightly coupled with it, such as registration information.

One resource in a component can be designated as the keypath, which represents the path to that component. Typically, the keypath is a file, but other types of resources, such as a registry value, can be a keypath. When an application requests a path to a component, the Windows Installer service returns the keypath resource.

The Windows Installer service checks for the existence of the keypath resource when verifying that a Windows Installer component is properly installed. If for any reason the keypath resource is missing, the Windows Installer service treats that component as broken. For additional details, see "Providing Reliable Access to Source Media" later in this paper.

Windows Installer now supports the installation and management of Common Language Run-time assemblies and Win32 assemblies, which are basically new types of units of code, such as DLLs, COM objects, and device drivers, that an application can use. Developers of Windows Installer packages can opt to install either type of assembly in the global assembly cache or in an isolated location for a particular application.

Managing Applications at the Component Level

A component is globally unique, meaning that a single component is guaranteed to always contain the same set of resources in any application that includes it. To maintain global uniqueness, each component is assigned a globally unique identifier (GUID), known as the Component Code. The Component Code prevents collisions between components that must be distinct.

Unlike other installation technologies, the Windows Installer service does not directly manage files and other resources on the computer. Instead, the Windows Installer service manages applications at the component level, meaning that no resource is installed or removed unless the component (of which it is a part) is either installed or removed. So, setup developers can ensure that two resources, if grouped in the same component, are not installed or uninstalled separately.

Windows Installer components also overcome a traditional limitation of the operating system by allowing you to manage resources other than files. Installation software manages shared files by maintaining a shared reference count (refcount) in the system registry for each shared file, not by removing a file until that refcount reaches zero. However, this does not apply to other resources, such as registry keys, because there is no mechanism for maintaining a shared refcount for them.

Because the Windows Installer service maintains a shared count at the component level instead of at the file level, and because components are minute units, a proper refcount is maintained for all resources. The Windows Installer service removes a component only when no applications remain that depend on that component.

Windows Installer maintains component recounts in the form of a client list of product codes, instead of a numerical list. This means that Windows Installer can identify clients of the resource as well as keep reference counts current.

The Windows Installer service model for installation and removal is much simpler than that used by traditional installation software. Existing installation technologies lack the concept of components, use different procedures for installation and removal, and cannot perform a refcount of nonfile resources. As a result, they typically leave many resources on the computer after an application is uninstalled or removed. By contrast, the Windows Installer service is cleaner. Windows Installer service accurately tracks the resources a component installs, and thus can verify whether the component can be safely removed.

Windows Installer Features

A Windows Installer feature provides a convenient means for users to select a group of components to install. When a user chooses the Custom installation option in a Setup program, each program element that the user selects to install corresponds to a feature. A feature can also contain other features, which allows Windows Installer to organize applications hierarchically. For example, a Microsoft Word feature in Office might contain a subfeature such as Proofing Tools. When a user chooses to install Proofing Tools, all components associated with that feature are installed as well.

The Windows Installer service performs all management at the component level, eliminating the need for a feature to have exclusive ownership of its components. Two features in the same or different applications can share a given component without affecting Windows Installer management scheme. Thus, it is not necessary for a feature to be globally unique; so features do not have GUIDs.

Where older installation technologies typically give users a binary choice between "installed" and "not installed" for a given feature, Windows Installer enables features to be set to one of four states:

• Installed on Local Hard Disk. The files are copied to the hard disk of the local computer.

• Installed to Run from Source. The application accesses the files from the source, typically, a CD or a network share.

• Advertised. The files are left on the source, but can be automatically copied to the client computer the first time the user selects the feature.

• Not Installed. No files are copied.

Advertising a product merely installs desktop and Start menu shortcuts, file name extension associations, or OLE registration entry points to that product. When a user invokes the application from one of the entry points, the operating system contacts Windows Installer service to install the advertised product. After the installation is completed, the Windows Installer service returns the path for the newly installed application back to the operating system, which then launches the application. For more information about advertising, see "Installing Features on an As-Needed Basis" later in this paper.

Advertisements are a central piece of the assign-and-publish capabilities of the Windows Server 2003 Group Policy-based software deployment technology. For more information about assigning and publishing software by using the Group Policy-based software deployment component, see "Deploying and Managing Software Using Group Policy" in this paper.

Windows Installer Products

A Windows Installer product can represent a single product such as Microsoft® Visio®, Microsoft Office, or some other software application. Products consist of one or more Windows Installer features. Each product describes itself to the Windows Installer service in the form of a single .msi package file. Products do not directly own any resources, but they do have GUIDs known as Product Codes. These Product Codes

enable the Windows Installer service to uniquely identify applications that are clients of a given component, (by maintaining a list of client products for each component) and to quickly determine if a product is already installed on a particular computer.

For the purposes of this example, Figure 2 shows the relationships of a subset of components, features, products, and resources of an actual product. An actual product would contain more features and components, as well as subsets of each feature and component.

As Figure 2 shows, Product X contains four features. Features 1 and 3 contain Features 2 and 4, and each also contains an isolated component and pointers to resource files: for example, file.exe, file.dll and registry settings. Additionally, Feature 1 and Feature 3 share Component 3.

Packaging Applications for Windows Installer

Preparing or obtaining a Windows Installer package file for installation is called packaging the software. Each product has its own Windows Installer package file. In addition to storing information about managing the state of a program, a package file stores information about the relationships between features, components, and resources for a product. At installation time, Windows Installer opens the package file for a designated product and uses the information in it to determine the installation operations to perform for that product.

Depending on the application to be deployed, packaging software can be as simple as performing an administrative installation to prepare the application for later installation by clients from a network location. Packaging can also be as complex as reauthoring the entire application, or even repackaging the application, which involves capturing the required modifications when installing an application and replacing the application's native installation program with a customized setup.

You have a choice of approaches to obtain or create packages for Windows Installer.

• Using the application's native Windows Installer package. A native Windows Installer package contains a single product (for example, Microsoft Office 2000), which is made up of many features (for example, Word, Excel, or PowerPoint, and so on) that you can configure to install individually. These features contain components, such as the thesaurus or the spelling and grammar checker. When the user selects an uninstalled feature or component, the feature or component is automatically installed. This saves bandwidth during the initial installation, it gives users only the features and components that they need to do their jobs, and it can save space on users' local disk drives. These are just a few of the many advantages to using the native Windows Installer packaging format. Many authors of software develop applications to include modular native Windows Installer packages to take full advantage of Windows Installer capabilities.

• Reauthoring applications. If you have software applications that are not designed for Windows Installer, you can reauthor the setup to a Windows Installer package.

• Repackaging applications. If you have an application that is not designed for Windows Installer, as a last resort, you can repackage it into the .msi format so that you can use the features of Windows Installer to distribute the application. A repackaged application combines the entire feature set of the application into a single feature. Windows Installer can install the repackaged application; however, you lose the flexibility to efficiently customize the application.

Important: Prior to reauthoring or repackaging any applications in your organization, it is important to compare the benefits of each strategy with the costs involved. Reauthoring and repackaging are both advanced operations. There are tools for each operation that can help developers create the final Windows Installer package, but the procedures are still resource-intensive and can be costly.

For help to determine if you need to reauthor or repackage an application, see "Preparing Non-Windows Installer-Based Applications for Installation" later in this paper.

Of course, if you have several applications that do not contain native Windows Installer packages, and you know that your organization has little or no use for these applications in the future, you can create Software Installation Settings (.zap) files. A .zap file is a text file containing instructions on how to install an application (setup.exe).

When you create .zap files, you do not benefit from the capabilities of Windows Installer. You can wrap 32-bit or 64-bit setup.exe, or install.exe files, into a .zap file format that the software distribution technology can use to install the software.

For information about using .zap files with the Group Policy-based software deployment technology of Windows Server 2003, see " Deploying and Managing Software Using Group Policy" in this paper.

Configuring Windows Installer Packages

The modular design of a Windows Installer package enables you to configure the installation of the individual application features to occur on demand, when the user selects them. For example, you can configure spell checker in Microsoft Word to install when the user accesses it for the first time.

Windows Installer packages enable self-repairing applications. For example, if a user accidentally deletes Winword.exe, the next time a user attempts to open Word, Windows Installer recognizes that the keypath file (discussed earlier in this paper) is missing and reinstalls it automatically.

Managing software releases is becoming easier because more software manufacturers are packaging new software with Windows Installer to promote consistent and reliable customization of applications.

For more information about Windows Installer authoring tools, see "Windows Installer Administration Tools" later in this paper.

For more information about authoring applications, see the Windows Installer Software Developer's Kit (SDK) on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/.

For information about customizing a native Windows Installer application, see "Customizing Windows Installer Applications," later in this paper.

Supporting 32-Bit and 64-Bit Applications

In Windows XP Professional and Windows Server 2003, Windows Installer 2.0 continues to support and protect the investment you have made in 32-bit applications. At the same time, Windows XP Professional introduces support for 64-bit application installation specific to the Intel IA64 platform. Because the 64-bit technology is new, few 64-bit applications are available. However, business requirements for the 64-bit platform are growing rapidly.

A Windows XP Professional Windows Installer package must be specified as either a 32-bit or a 64-bit package. On a computer using a 64-bit operating system, the Windows Installer service is hosted in a 64-bit process that installs both 32-bit and 64-bit packages. Windows Installer version 2.0 installs three types of Windows Installer packages on a computer running a 64-bit operating system:

• 32-bit packages containing only 32-bit components.

• 64-bit packages containing some 32-bit components.

• 64-bit packages containing only 64-bit components.

Note: You cannot advertise or install a 64-bit application on a 32-bit operating system.

You can decide to make the 32-bit package visible to a 64-bit client. You might decide not to deploy a 32-bit package on a 64-bit client if that application functions poorly or not at all on 64-bit systems. You make your configuration determinations as you test the applications and system combinations in your test lab and during your pilot phase.

Important: Do not deploy a 32-bit application with the same Windows Installer Product ID as a 64-bit application. The 64-bit version of a product must have a separate Product ID.

Many new properties and attributes are valid in a 64-bit package to help the author install the application correctly. For information about these properties and attributes, see "64-bit Windows Installer Packages" in the Windows Installer SDK, which is available from the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/.

Customizing Windows Installer Applications

By using the command line or transforms, Windows Installer provides a consistent administrative interface to manage all applications that Windows Installer installs. You can perform management operations directly on an individual computer or entire enterprise by using a software distribution technology. There are two primary methods for customizing a Windows Installer application:

• Command- line arguments. A command-line argument specifies a variable name or other information the user must provide, such as a path and file name.

• Customization transforms. By applying a transform—a collection of changes you can apply to a base .msi file—Windows Installer can dynamically add or modify data in the installation database, customizing the installation of an application. You can benefit from using either command-line arguments or customization transforms to customize your native Windows Installer applications. However, while command lines are easy to implement, they do not offer all of the capabilities of a transform. The differences in functionality and implementation are discussed in the following sections

Customizing Applications by Using Command-Line Options

Windows Installer provides numerous command-line options and properties to customize the installation and management of an application. You can use multiple command-line options and properties simultaneously to get the result you want.

Some command-line options are mutually exclusive and cannot be used together. For a complete list of command-line options and possible interactions among them, see "Command-Line Options" in the Windows Installer SDK available from the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/.

Syntax of Command-Line Options

The following is an implementation of the most commonly used command-line options:

The executable file for Windows Installer is msiexec.exe. To change the state of a Windows Installer–based application by using a command-line option, the syntax is:

msiexec.exe  /command line option  argument

Where argument might be the path and name of a file.

If a command-line option requires an argument, the argument must follow directly after the option, separated by at least one space. Command-line options are not case sensitive.

Some common command-line options follow:

/I installs an application

/QB sets the level of user interface to basic

/L enables logging

Correct syntax:

msiexec.exe /i \\server\share\setup.msi  /qb   /l c:\msi.log

Incorrect syntax:

msiexec.exe  /I  /QB  /L C:\msi.log  \\Server\Share\Setup.msi

Unless specified otherwise, the following examples are for the program "setup.msi," assumed to be residing in the UNC path of \\server\share. The path can also be local, such as a CD-ROM, or it can be a remote mapped drive or an Internet location over HTTP.

Administrative installation

The /a option decompresses the application files and copies them to the specified location. Administrators commonly do this to create a software installation point on the network for the application, from which client installations can be performed.

msiexec /a \\server\share\setup.msi

Advertising an application

An advertised application is one for which Windows Installer provides the loading and launching methods but does not physically install the application. That is, Windows Installer does not install the necessary components until a user or application attempts to activate the advertised program. This concept is called install-on-demand. Table 1 shows the command-line arguments for advertising products.

Table 1 Command-line arguments for advertising products

Option	Arguments	Indicates
/j	[u|m]Package -Or- [u|m]Package /t Transform List -Or- [u|m]Package /g LanguageID	Advertises a product. This option ignores any property values entered on the command line. u - Advertises to the current user. m - Advertises to all users of the computer. g - Language ID t - Applies transform to advertised package.

The following example illustrates advertisement options. Switches are not case-sensitive.

msiexec /JM msisample.msi /T transform.mst /LIME logfile.txt

Implementation of advertisements by Windows Installer is dependant on the shell of the operating system of the client computer. Table 2 outlines advertisement support on different platforms.

Table 2 Advertisement Support on Different Platforms

Platform	Advertisement Support
Windows 2000 and later and Windows 98 and later.	Advertisements are supported.
Windows NT 4.0 and Windows 95	Advertisements are supported, only if this additional requirement is met: Internet Explorer 4.01 Service Pack 1 with Active Desktop installed. (It is not necessary to enable Active Desktop, just install it.)

Installing to the local computer

The /i command-line option installs applications to the local computer. In the following example, setup.msi is installed by using the default full-user interface.

msiexec /i \\server\share\setup.msi

Enabling logging

The /l command-line option enables logging. Logging is essential to troubleshooting the actions taken by Windows Installer. Table 3 shows the arguments used to control the level of logging.

Table 3 Arguments Used to Control Logging

Argument	Effect
I	Logs status messages
w	Logs non-fatal warnings
e	Logs all error messages
a	Logs startup of actions
r	Logs action-specific records
u	Logs user requests
c	Logs initial UI arguments
m	Logs out-of-memory or fatal exit information
o	Logs out-of-disk-space messages
p	Logs terminal Properties
v	Logs in verbose output
+	Appends to existing log file
!	Flushes each line to the log
*	Logs all information except for the v argument (to include the v argument, specify "/l*v")

The following example illustrates enabling verbose logging during an installation without user interface. The log file is called "program.log" and is placed in the TEMP directory.

msiexec /qn /l*v %temp%\program.log /i \\server\share\setup.msi

For more information about troubleshooting, see "Troubleshooting Software Installations" later in this paper.

Repairing an installation

The installation of an application can become damaged for any number of reasons, such as a file becoming corrupt when a sector on the hard disk goes bad. Even though applications installed by Windows Installer perform run-time checks and can repair themselves, they might require a more thorough repair in some instances.

The "/f" command-line option repairs an application. There are a number of arguments to control the type of repair. This option bypasses any property values you enter on the command line. The default argument list for this option is pecms. Table 4 explains the arguments for the /f command-line option, which shares the same argument list as the REINSTALLMODE property. Table 4 also shows the arguments for the /f command-line option that control the type of repair.

Table 4 Controlling the Type of Repair Using the /f Command-line Option

Argument	Effect
p	Rewrite all required user specific registry entries.
o	Rewrite all required computer-specific registry entries.
e	Overwrite all existing shortcuts.
d	Run from source and recache the local package.
c	Rewrite all required user-specific registry entries.
a	Rewrite all required computer- specific registry entries.
U	Overwrite all existing shortcuts.
M	Run from source and re-cache the local package.
S	Rewrite all required user-specific registry entries.
V	Rewrite all required computer-specific registry entries.

In the following example, if a file is missing, or if an equal or older version is present on the system, Windows Installer reinstalls the correct file for the "setup.msi." package. If there are missing or corrupted shortcuts or registry entries, Windows Installer does not repair them because no arguments in the command relate to shortcuts or registry entries.

msiexec /fe \\server\share\setup.msi

Source resiliency

Applications that rely on network resources for installation-on-demand might fail to find the proper source files if the source location changes or if it becomes damaged. Windows Installer provides source resiliency for features that are installed on demand by using a source list. The source list contains the source locations that Windows Installer searches for installation packages. The source location entries are in the form of a mapped drive letter, Universal Naming Convention (UNC) path, Uniform Resource Locators (URLs), or physical media such as compact discs. If one source fails, Windows Installer tries the next.

The application developer does not need to incorporate any special information into the Windows Installer package to ensure source resiliency. After the application is installed, Windows Installer adds the last successfully used source as an entry in the source list. By default, the Windows Installer package is initially installed from this location, and it is the same as the SourceDir property.

A system administrator can change the source list by applying a transform or by changing the SOURCELIST property by using the command line.

Windows Installer begins searching for a source by checking the most recently used source location in the source list. If this search fails, Windows Installer searches the list of network sources, then media sources, and finally URL sources. System administrators can change this search order by using the SearchOrder system policy. If these searches fail, Windows Installer might display a browse dialog box, allowing the user to search for the source manually. Displaying the browse dialog box is a configurable option that you can enable using system policies. The browse dialog cannot be displayed if the user interface level is set to None.

Typically, Windows Installer displays only a browse dialog box if the current user is an administrator or if the installation does not require elevated privileges. An administrator can control the display of the browse dialog box to users by using the DisableBrowse and AllowLockDownBrowse system policies. An administrator also controls whether users can install applications from sources located on media by using the DisableMedia and AllowLockDownMedia policies. The use of these system policies depends on the Windows Installer version. For more information about using system policies with Windows Installer, see the Windows Installer SDK, which is available on the Web Resources page at: http://www.microsoft.com/windows/reskits/webresources/.

Uninstalling an application

The /x option uninstalls an application. The following command line uninstalls "setup.msi", showing only a progress bar as a user interface.

msiexec /x \\server\share\setup.msi /qb

User interface level

Windows Installer allows application developers to write a user interface for the installation process, which has multiple levels of UI functionality. Because of this flexibility, the actual user interface presented during installation might depend on the application being installed.

Table 5 shows common user interface levels.

Table 5 Common User Interface Levels

Property Name	Command-Line Option	Description of User Interface Level
NONE	Qn	Completely silent installation
BASIC	Qb	Simple progress and error handling
REDUCED	Qr	Authored UI, wizard dialogs suppressed
FULL	Qf	Authored UI with wizards, progress, errors

There are several levels of user interaction during installation, and you can configure these levels by using command-line options. For a complete list of these options with detailed explanations of each, see the Windows Installer SDK on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/.

The following command line installs setup.msi with no user interface, accepting the default values provided by the application manufacturer.

msiexec /i /qn \\server\share\setup.msi

You can modify the default values by using either command line-properties or transforms.

Customizing Applications by Using Properties

Properties are variables that Windows Installer uses during an installation. A subset of these properties, called public properties, can be set on the command line. For a complete list, see the Windows Installer SDK and search for "properties." The Windows Installer SDK is available on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/.

Command-Line Syntax for Property Values

Any property value that is a literal string must be enclosed in quotation marks. The following are examples of the command-line syntax for some of the more commonly used properties:

msiexec /i A:\Example.msi INSTALLLEVEL=3

To clear a public property using the command line, set its value to an empty string.

msiexec /i A:\Example.msi PROPERTY=""

The following is an example of a complicated command line.

msiexec /i testdb.msi INSTALLLEVEL=3 /l* msi.log COMPANYNAME="Acme "
"Widgets"" and ""Gizmos."""

Administrative installation location

Table 6 presents the property TARGETDIR and a description of the property.

Table 6 TARGETDIR Property

Property Name	Description
TARGETDIR	Location to which the installation package is copied during an administrative installation.

The following example shows setup.msi on D:\ installed to \\server \share:

msiexec /a D:\setup.msi TARGETDIR=\\server\share

Installation options

Following are some properties commonly used to control feature installation. For a complete list, see the Windows Installer SDK on the Web Resources page at http://www.microsoft.com/windows/reskits/webresources/.

Windows Installer evaluates these properties in the order shown in Table 7 regardless of their sequence on the command line:

Table 7 Sequence in Which Windows Installer Evaluates Properties

Sequence	Properties
1.	ADDLOCAL
2.	REMOVE
3.	ADDSOURCE
4.	ADDDEFAULT
5.	REINSTALL
6.	ADVERTISE
7.	COMPADDLOCAL
8.	COMPADDSOURCE
9.	FILEADDLOCAL
10.	FILEADDSOURCE
11.	FILEADDDEFAULT

Note: Feature names listed in properties are case-sensitive.

Table 8 displays the property ADDLOCAL and a description of the property.

Table 8 ADDLOCAL Property

Property Name	Description
ADDLOCAL	List of features to be installed locally.

The value of the ADDLOCAL property consists of a list of features delimited by commas that are to be installed locally. The features must be present in the Feature column of the Feature table. To install all features locally, enter ADDLOCAL=All on the command line. If, within a feature, a particular component supports only run from source, that component is installed as run from source.

Important: Do not enter ADDLOCAL=All into the Property table because this generates a locally installed package that cannot be correctly removed.

Table 9 displays the property ADDSOURCE and a description of the property.

Table 9 ADDSOURCE Property

Property Name	Description
ADDSOURCE	List of features to be run from the source.

The value of the ADDSOURCE property is a comma-delimited list of features to be installed so as to run from their source location. The features must be present in the Feature column of the Feature table. To install all features to run from source, enter ADDSOURCE=All on the command line.

Important: Do not enter ADDSOURCE=All into the Property table because this generates a run-from-source package that cannot be correctly removed.

Combining ADDLOCAL and ADDSOURCE in the same command

You can use both ADDLOCAL and ADDSOURCE properties in the same command, but ADDLOCAL is always parsed before ADDSOURCE regardless of the sequence of these properties within the command.

Thus, all the features are first set to run-local, and then MyFeature is set to run-from-source if the command line specifies:

ADDLOCAL=ALL, ADDSOURCE = MyFeature

Important: Windows Installer evaluates these properties in the order listed earlier in Table 7, regardless of the order on the command line.

Table 10 presents the property ADVERTISE and a description of the property.

Table 10 ADVERTISE Property

Property Name	Description
ADVERTISE	List of features to be advertised.

The value of the ADVERTISE property is a comma-delimited list of features to be advertised. The features must be present in the Feature column of the Feature table. To install all features as advertised, enter ADVERTISE=All on the command line.

Important: Do not enter ADVERTISE=All into the Property table because this generates an advertised package that cannot be installed or removed.

Table 11 presents the property REINSTALL and a description of the property.

Table 11 REINSTALL Property

Property Name	Description
REINSTALL	List of features to be reinstalled.

The value of the REINSTALL property is a comma-delimited list of features to be reinstalled. Feature names are case-sensitive. The features listed must be present in the Feature column of the Feature table. To reinstall all features use REINSTALL=All on the command line.

If you set the REINSTALL property, you must also set the REINSTALLMODE property, to indicate the type of reinstall you want. When the REINSTALLMODE property is not set, all files currently installed are reinstalled, but only if the file on the computer is an earlier version or is not present. By default, no registry entries are rewritten.

Even if REINSTALL is set to ALL, only features already installed are reinstalled. Thus, if REINSTALL is set for a product that is yet to be installed, no installation takes place. REINSTALL is a vital property for performing such important tasks such as patching and upgrading software. For more information about using REINSTALL, see "Patching and Upgrading Software Applications" later in this paper.

ALLUSERS property for per-user and per-computer installations

ALLUSERS determines whether configuration information is stored individually for each user, or for all users logging on to the system.

Table 12 presents the property ALLUSERS and a description of the property.

Table 12 ALLUSERS Property

Property Name	Description
ALLUSERS	Determines whether configuration information is stored per user or for all users logging on to the system.

If the ALLUSERS property is null or is the default setting, Windows Installer attempts a per-user installation.

Per-User Installation

Per-user installation of an application means:

• The application is installed only for a particular user.

• Shortcuts are installed only to the profile of a particular user.

• Applications appear in Add or Remove Programs in Control Panel only if the applications are installed.

• The application might not install with elevated privileges. For more information, see "Installing Software By Using Administrator-Level Privileges" later in this paper.

• Icons and transforms are stored in %USERPROFILE%\Application Data\Microsoft\Installer\{ProductCode GUID} unless they are redirected to a different location.

The per-user property does not enable a user with elevated privileges to install an application. The per-user property successfully installs an application only if the user has sufficient privileges to install software for personal use. Some applications do not support per-user installations, and those that do, differ on the minimum amount of privileges a user needs to successfully install the application.

Software distribution tools can take advantage of Windows Installer Application Programming Interfaces (APIs) to install an application for a user, regardless of the privileges of the user.

Per-Computer Installation

Per-Computer installation of an application means that the application is available for all users of a computer. It also means:

• Shortcuts are installed to the All Users profile.

• Windows XP Professional, Windows 2000, and Windows NT always require and run at administrative access privileges on the computer.

• Icons and transforms are stored in %WINDOWS%\Installer\{ProductCode}.

Windows NT, Windows 2000 Professional, and Windows XP Professional

In Windows XP Professional, Windows 2000 Professional, and Microsoft® Windows NT®, Windows Installer performs a per-user or per-computer installation depending on the value of the ALLUSERS property.

If the ALLUSERS property is set to 1, Windows Installer attempts a per-computer installation. The per-computer installation succeeds only if the user has administrative access privileges on the computer.

If the ALLUSERS property is set to 2, Windows Installer first attempts a per-computer installation.

As previous stated, this per-computer installation succeeds only if the user has administrative access privileges on the computer. However, if the per-computer installation cannot be done, Windows Installer does a per-user installation instead. Windows Installer then changes the ALLUSERS property from 2 to null or 1, based on its determination to perform a per-user or a per-computer installation.

Windows 95, Windows 98, and Windows Me

In Windows 95, Windows 98, and Windows Me, the installation is either per user or per computer, depending on the configuration of the operating system. If Profiles are turned on, and the Start menu is per-user, Windows Installer does a per-user installation. If Profiles are turned on, and the Start menu is shared, Windows Installer does a per-computer installation. If Profiles are turned off, and the Start menu is shared, the installation does a per-user installation. Windows Installer always resets the ALLUSERS property to null or 1 based on whether it does a per-user or a per-computer installation.

Table 13 shows how the ALLUSER property affects the application installation on Windows NT, Windows 2000 Professional, and Windows XP Professional when combined with the permissions of the user performing the installation. For details on deploying applications to users with varied permissions, see "Installing Software By Using Administrator-Level Privileges" later in this paper.

Table 13 User Privileges and Administrator Privileges

Privilege level (Windows XP Professional, Windows 2000 Professional, and Windows NT)	ALLUSERS = "" (null, the default)	ALLUSERS = 1	ALLUSERS =2
User privileges	Per-user installation using folders in user's personal profile.	Not valid. Returns an error stating that the user does not have sufficient privileges to install the application.	Per-user installation using folders in the user's personal profile.
Administrator privileges	Per-user installation using folders in user's personal profile.	Per-computer installation using folders in the All Users profile.	Per-computer installation using folders in the All Users profile.

In the following example, \\server\share\setup.msi is installed to the default location that the application provides for all users of the computer. This requires the person performing the installation to have administrative access privileges to the computer.

msiexec /i \\server\share\setup.msi ALLUSERS=1

Customizing the Add or Remove Programs wizard

You can customize the application information that users see under Support Information in the Add or Remove Programs wizard in Control Panel. For example, you can direct users to the appropriate resources. Many display features of Add or Remove Programs are supported only in Windows 2000 and later versions.

Table 14 offers some ways you can use properties to customize the information that appears in Add or Remove Programs.

Table 14 Properties Used to Customize Information in Add or Remove Programs

Property Name	Description
ARPCOMMENTS	Provides the ability to include comments for an application in the Add or Remove Programs wizard.
ARPCONTACT	Provides contact information to display in the Add or Remove Programs wizard.
ARPHELPLINK	URL for this application's technical support.
ARPHELPTELEPHONE	Phone number to call for help on this application.
ARPNOREMOVE	Disables the option to remove this application. (ARPNOREMOVE is located in the Add or Remove Programs wizard in Control Panel.). For Windows XP and Windows 2000, this property also disables the Remove button for the product from Add or Remove Programs in Control Panel. In earlier versions of the Windows operating system, this property removes the product from the list of installed products on the Add or Remove Programs in Control Panel.
ARPNOMODIFY	Similar to ARPNOREMOVE but disables the ability to MODIFY the application.
ARPSYSTEMCOMPONENT	Completely hides the application from the Add or Remove Programs wizard.

An example of a complex command line follows:

msiexec /I \\server\share\setup.msi /qb /l*v c:\program.log ARPCOMMENTS="
These are the comments 
for Program. For additional product information see Home Page. For product 
support issues 
please see Contact" ARPCONTACT="Support Desk" 
ARPHELPLINK=http://www.program.com/home.htm 
ARPHELPTELEPHONE=425-555-1212 ARPNOREMOVE=1

This command line usessetup.msi to perform the following tasks:

• Initiate the installation.

• Set the installation UI level to Basic (typically, only a progress bar is displayed during installation).

• Enable verbose logging, to the file %temp%\program.log

• The application's entry in the Add or Remove Programs wizard in Control Panel changes Support Information in the following ways:

  • Customizes comments for Setup.msi.

  • Specifies a support contact for Setup.msi.

  • Directs users to an administrator-specified Web site for technical support.

  • Directs users to an administrator-specified phone number for product support.

  • Disables, in the Add or Remove Programs wizard, the ability to remove the application.

SOURCELIST

The SOURCELIST property is a list of network source paths or URLs delimited by semicolons, which indicates the locations of the installation package for the application. This list is appended to each user's existing source list for the application. Windows Installer locates a source by scanning the list of source paths, using the first accessible location it encounters. Only this source can be used for the remainder of the installation. Each path specified in the source list must specify a location that contains a complete source for the application. The entire directory tree at each source location must be the same and must include all required source files, including any cabinet files. Each location must have an .msi file with the same file name and product code.

Default value

Windows Installer checks the SOURCELIST property only if the product has not already been advertised or installed. In all other cases, Windows Installer uses the source list that exists in the registry.

Sources added using the SOURCELIST property are added directly to the end of the list for each type of source, so they always come after the default source specified by the SourceDir property.

For Windows Installer versions earlier than version 1.2, the SOURCELIST property is limited to a maximum of 26 network sources plus 26 URL sources. For Windows Installer version 2.0 and later, the number of sources in the SOURCELIST property is unlimited. For Windows Installer version 1.1 and later, MsiSourceListAddSource can be used to add network sources beyond the limit of 26.

System restarts

Windows Installer determines when a restart of the system is necessary and prompts the user to restart the computer at the end of the installation. For example, Windows Installer prompts for a restart if it needs to replace any files that were in use during the installation.

You can schedule or suppress system restarts by setting properties. Table 15 presents the properties that are used to handle system restarts.

Table 15 REBOOT Property

Property Name	Description
REBOOT	Suppresses certain prompts for a restart of the system.

Typically, you use this property when installing several products sequentially, with only one restart required at the end of the entire installation. This works fine if you are running Windows XP , Windows 2000, or Windows NT; however, it is less stable on Windows 95, Windows 98, and Windows Me because in-use files are not replaced until after the computer restarts. If the applications attempt to install the same file, and that file is in use, the last attempt made by one of the applications to install the file prevails, regardless of version.

If an application calls a file that requires a newer version where an older one exists, if the older version was in use during the installation and the computer has not yet restarted, unpredictable behavior can occur. This behavior can be as severe as a program failing.

Certain Windows Installer functions, which the application vendor might use, can tell Windows Installer to prompt the user to restart the system. Even without these functions, Windows Installer can detect some situations in which restarting a computer is necessary. For example, Windows Installer prompts for a computer to restart if it needs to replace any files that were in use during the installation.

Table 16 explains how you can suppress certain system-restart prompts by setting the REBOOT property.

Table 16 REBOOT Value Explanations

REBOOT value	Explanation
Force	Always prompt for a computer restart at the end of the installation. The UI prompts the user to restart at the end. If there is no user interface, the system restarts at the end of the installation.
Suppress	Suppress restart prompts at the end of the installation. During installation, Windows Installer prompts the user to restart whenever it encounters ForceReboot set by the application vendor. If there is no user interface, the system restarts at each ForceReboot. A restart at the end of the installation (caused, for example, by a user's attempt to install a file that is in use) is suppressed.
ReallySuppress	Suppress all restart prompts that ForceReboot initiates during the installation and also suppress all restart prompts at the end of the installation.

Necessary restarts occur automatically. Table 17 shows the property REBOOTPROMPT and describes the property.

Table 17 REBOOTPROMPT Property

Property Name	Description
REBOOTPROMPT	Suppresses the display of computer restart prompts to the user. Any restarts that are needed happen automatically.

Setting the REBOOTPROMPT property to Suppress (or S) allows Windows Installer to perform a computer restart, if necessary, without prompting the user.

Caution: Packages that contain forced computer restarts are strongly discouraged. The operating system attempts to minimize this occurrence for reasons that include, potential server downtime and risk of data loss.

Transforms and related properties

Transforms increase the flexibility of application installation by providing a way to customize the installation of a package without changing the package itself. This subsection discusses the properties related directly to transforms. For information about customizing applications by using transforms, see "Customizing Applications Using Transforms" earlier in this paper.

Transforms can be used to encapsulate the various customizations of a base package required by different groups of users. For example, in organizations where the finance and staff-support departments require different installations of a product, you can make the base package of the product available to everyone at one administrative installation point by distributing the appropriate customizations to each group of users separately as transforms. Table 18 presents the TRANSFORMS property and a description of the property.

Table 18 TRANSFORMS Property

Property Name	Description
TRANSFORMS	List of transforms to be applied to the .msi file.

The TRANSFORMS property is a list of the transforms Windows Installer applies when installing a package. Windows Installer applies the transforms in the same order as they are listed in the property. Transforms can be specified either as a file name or as a full path. To specify multiple transforms, use a semicolon (;) between file names or full paths.

The following example applies three transforms to a package, specifying file names only:

TRANSFORMS=transform1.mst;transform2.mst;transform3.mst

The following example applies three transforms, specifying full paths:

TRANSFORMS=\\server\share\path\transform1.mst;\\server2\share2\path2
\transform2.mst;\\server3
\share3\path3\transform3.mst

You can indicate that a transform file is embedded in an .msi file, as opposed to being a stand-alone file, by prefixing the file name with a colon (:). The following example indicates that transform1.mst and transform2.mst are embedded inside the .msi file and that transform3.mst is a stand-alone file.

TRANSFORMS=:transform1.mst;:transform2.mst;transform3.mst

Windows Installer requires that all transforms be listed in the TRANSFORMS property at every installation, advertisement, installation-on-demand, or maintenance installation of the package. The TransformsSecure policy, the TRANSFORMS property, and the first character of the TRANSFORMS string informs Windows Installer how to perform source resiliency of stand-alone transform files for this particular installation. Transforms embedded in the .msi file are not cached and are always obtained from the package.

You set the TRANSFORMS property by specifying the list of transforms on the command line; however, when using either the /jm or /ju command-line option, you must specify the transforms list using the /t option. For more information about specifying transforms on the command line, see "Syntax of Command-Line Options" earlier in this paper.

You cannot modify the transforms list after the Windows Installer package is installed. You can remove the transforms list only by removing the application.

Table 19 lists the TRANSFORMS properties and describes their effects, along with the TransformsSecure policy, on caching and source resiliency.

Table 19. Effects of TRANSFORMS Property and TransFormsSecure Policy

TRANSFORMS Property	TransformsSecure Policy	Effects on Caching and Source Resiliency
@[list of file names] Example: @transform1.mst;transform2.mst; transform3.mst	Not set.	Secure-at-source transforms. The source of the transforms must be located at the root of the source for the package. When the package is installed or advertised, Windows Installer saves the transforms on the client computer in a cache where the user does not have write access. If the local copy of the transform becomes unavailable, Windows Installer searches for a source to restore the cache. The method is the same as searching the source list for an .msi file.
|[list of paths] Example: |\\server\share\path\transform1.mst;\\server2\share2\path2\transform2.mst	Not set.	Secure-full-path transforms. The source of each transform must be at the full path passed to TRANSFORMS. The transform source does not have to be located at the source of the package. When the package is installed or advertised, Windows Installer saves the transforms on the client computer in a cache where the user does not have write access. If the local copy of the transform becomes unavailable Windows Installer can only restore the cache from the source at the specified path.
[list of file names] The first character is not @ or |. Example: transform1.mst;transform2.mst; transform3.mst	TransformsSecure or TRANSFORMSSECURE set to 1 -Or- TransformsAtSource or TRANSFORMSATSOURCE set to 1.	If TRANSFORMS is a list of file names, Windows Installer treats them as secure-at-source transforms. If TRANSFORMS is a list of full paths, Windows Installer treats them as secure-full-path transforms.
[list of file names] The first character is not @ or |. Example: transform1.mst;transform2.mst; transform3.mst	TransformsSecure and TRANSFORMSSECURE are not set -And- TransformsAtSource and TRANSFORMSATSOURCE are not set.	The source of the transforms must be at the root of the source for the package. When the package is installed or advertised, Windows Installer saves the transforms in the user's profile. This enables users to roam from computer to computer while maintaining their customizations. If the local copy of the transform becomes unavailable Windows Installer searches for a source to restore the cache. The method is the same as searching the source list for an .msi file
[list of paths] The first character is not @ or |. Example:\\server\share\path\transform1.mst;\\server2\share2\path2\transform2.mst.	TransformsSecure and TRANSFORMSSECURE are not set -And- TransformsAtSource and TRANSFORMSATSOURCE are not set.	Unsecured transforms. When the package is installed or advertised, Windows Installer saves the transforms in an unsecured location where the user has write access. If the local copy of the transform becomes unavailable Windows Installer might only restore the transform from the source at the path passed to TRANSFORMS.

You cannot use file names and paths together in the same TRANSFORMS list. You cannot specify secure and profile transforms together in the same list. You can include transforms embedded in the package in a list with other transforms. For example:

@transform1.mst;:transform2.mst

-Or-

\\server\share\path\transform1.mst;:transform2.mst

Note: The list delimiter for transforms is the semicolon, so semicolons must not be used in a transform file name or path.

In cases where you set the TransformsSecure policy or the TRANSFORMSSECURE property by using Windows Installer version 1.1, it is not necessary to pass the @ or | symbol when setting TRANSFORMS that use the command line. Windows Installer assumes the transforms are secure-at-source (if the list consists entirely of file names located at the source) or secure-full-path (if the list consists entirely of full paths). You still cannot mix the two types of transform sources.

Table 20 presents the property TRANSFORMSATSOURCE and a description of the property.

Table 20 TRANSFORMSATSOURCE Property

Property Name	Description
TRANSFORMSATSOURCE	Informs Windows Installer that the transforms for the product reside at the source.

When using Windows Installer version 1.0, setting the TRANSPORMSATSOURCE property to 1 informs Windows Installer that the transforms are located at the root of the source of the installation package. If this property is set for a transform, Windows Installer prefixes that transform's file name with the @ symbol in the transform list. The transform list is the value of the TRANSFORMS property. Windows Installer then locates the transform, and all subsequent transforms in the list at the root of the source by using the .msi file.

Setting this property is similar to setting the TransformsAtSource policy except that the scope is different. Setting TransformsAtSource policy applies to all packages installed by a given user. Setting the TRANSFORMSATSOURCE property applies to the package regardless of who the users are.

This property and policy are not available with Windows Installer version 1.1. Windows Installer version 1.1 interprets the TRANSFORMSATSOURCE property as though it were the TRANSFORMSSECURE property. If the @ flag is passed in the TRANSFORMS property, Windows Installer version 1.1 treats the transforms in the list as secure-at-source transforms.

Table 21 presents the property TRANSFORMSSECURE and a description of the property.

Table 21 TRANSFORMSSECURE Property

Property Name	Description
TRANSFORMSSECURE	Setting the TRANSFORMSECURE property to 1 informs Windows Installer that transforms are to be cached locally on the user's computer in a location where the user does not have write access.

Setting the TRANSFORMSSECURE property is similar to setting the TransformsSecure policy except that the scope is different. Setting TransformsSecure policy applies to all packages installed by a given user. Setting the TRANSFORMSSECURE property applies to the package regardless of who the user is.

The purpose of the TRANSFORMSSECURE property is to provide secure transform storage for traveling users of Windows XP Professional and Windows 2000 Professional. When this property is set, a maintenance installation, such as adding or removing a feature from an installed application, can only use the transform from the specified path. If the path is not available, the maintenance installation fails. A source for each secure transform must therefore reside at the location of the source of the installation package. Then if Windows Installer finds the transform is missing on the local computer, it can restore the transform from this source.

The TRANSFORMSSECURE property is not available with Windows Installer version 1.0.

Windows Installer version 1.1 interprets the TRANSFORMSATSOURCE property to be the same as the TRANSFORMSSECURE property.

User information

The PIDKEY property contains only the part of the product ID that the user enters manually as describes in Table 22.

Table 22 PIDKEY Property

Property Name	Description
PIDKEY	The product ID entered for the user.

Table 23 presents the USERNAME property and a description of the property.

Table 23 USERNAME Property

Property Name	Description
USERNAME	User for whom the installation is performed.

If you do not set the USERNAME property, Windows Installer sets it automatically by using values from the registry.

The COMPANYNAME property is the organization or company of the user for whom the installation is being performed.

Table 24 describes the COMPANYNAME property.

Table 24 COMPANYNAME Property

Property Name	Description
COMPANYNAME	Organization of user for whom the installation is performed.

You can enter a default value in the Property table. If the COMPANYNAME property is not set, Windows Installer sets it automatically by using values from the registry.

Customizing Applications by Using Transforms

A transform is a collection of specified changes in the form of .mst files, which you apply to a base Windows Installer package file at installation time. When you apply transforms to an .msi file, Windows Installer can dynamically add or modify data in the installation database, customizing the installation of the application. Transforms tailor the installation of an application. Although they are optional, you can use transforms for a variety of purposes including the following:

Encapsulating numerous customizations of a base package required by different groups

For example, in organizations where the Finance and Marketing departments require different installations of a product, you can make the product's base package available to everyone at one software distribution point by distributing the appropriate customizations to each group of users separately as transforms.

Adding new features to an existing application's package

One example is adding custom corporate-developed Microsoft Excel templates for the Finance group. However, if the templates change frequently, it is better to package and distribute them separately.

Customizing

This can involve configuring installations so that a particular set of features from a specified software application, or suite of software applications, is installed locally on the computer.

Note: You apply transforms as part of an initial installation. You cannot apply transforms to an application that is already installed.

Command-Line Options Versus Transforms

The major differences in functionality between customizing an application by using transforms, and customizing it by using the command line follow:

• A transform is persistent until the application is removed; as command-line actions apply only to the specific execution of the command line.

• Transforms can modify both public and private properties; command-line options for Windows Installer can only affect public properties. See the Windows Installer SDK for a complete list of public and private properties.

• Both transforms and Windows Installer command-line options can affect directories and files; only transforms can perform actions that affect the registry.

• The Group Policy-based software deployment technology of Windows Server 2003 and Windows 2000 Server requires that transforms be used for any customization of applications. You cannot use command-line arguments.

A few of the more common tasks you can perform on an application by using a transform instead of a command-line option follow:

• Specify the install state of a feature: Advertised, Run Locally, or Run From Source.

• Make a feature unavailable and invisible to the user.

• Add, modify, or remove shortcuts.

• Modify the upgrade behavior.

You can use transforms to modify information in any table in the Windows Installer Database. Additionally, you can use transforms to add or remove tables in the Windows Installer Database. Transforms can modify only those parts of an installation package that you place in a database table, such as information in the following: Summary Information Stream, substorage information, information in nested installations, or files in embedded cabinet files. For more information about substorages, see "Patching Software" later in this paper.

The four types of Windows Installer transforms are embedded, unembedded, secured, and unsecured.

• Embedded transforms. Embedded transforms are stored inside the .msi file of the package. This guarantees to users that the transform is always available when the installation package is available. If the installation source is read-only, such as a CD or a network share to which the person creating the transform has read-only access, this is not an option because you must be able to write to the source to embed the transform in the *.msi file. To add an embedded transform to the transforms list, add a colon (:) prefix to the file name. Embedded transforms are not cached separately on the client computer, because Windows Installer can always obtain the transform from the .msi file. .Embedded transforms might be used in combination with secured or unsecured transforms.