Windows Installer: Benefits and Implementation for System Administrators

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.

Figure 1: Contents of a 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

Figure 2: Relationships of Components, Features, Products, and Resources

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 https://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 https://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 https://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: https://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 https://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 https://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 https://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=https://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.

• Unembedded transforms. Unembedded transforms are stored separate from the .msi file of the original package. Unembedded transforms are cached separately on the client computer. You can use unembedded transforms in combination with secured or unsecured transforms.

• Secured transforms. Secured transforms are recommended for security reasons. If an application is installed at an elevated level, either per-user or per-computer, a user with low rights can modify an unsecured transform and use it to make changes to the computers that have elevated privileges. Secured transforms are stored locally on the client computer in a location where, on a secure file system such as NTFS, the user does not have write access. Such transforms are cached in this location during the installation or advertisement of the package. During subsequent installation-on-demand or maintenance installations of the package, Windows Installer uses the cached transforms.

To specify secured transform storage, set the TransformsSecure policy, or set the TRANSFORMSSECURE property, or pass the @ or | symbol in the transforms list.

Important: You cannot combine unsecured transforms and secured transforms in the same TRANSFORMS list.

If a user removes the product, Windows Installer removes all secured transforms for that product from that user's computer. If Windows Installer finds that a secured transform is not locally available, it then attempts to restore the transform cache from a source. Secure transforms can be secure-at-source or secure-full-path:

• Secure-At-Source transforms that are missing from the local transform cache are restored from the root of the source of the .msi file.

• Secure-Full-Path transforms that are missing from the local transform cache are restored from the original full path specified by the transform list.

Unsecured transforms

Unsecured transforms have not been secured as described in Secured Transforms in the preceding list. When a package is installed or advertised as a per-user installation, and the package has unsecured transforms, Windows Installer saves the unsecured transforms in the Application Data folder in the user's profile. This enables a user to maintain a customization of a product while roaming from computer to computer.

When the package is installed or advertised as a per-computer installation, and the package uses unsecured transforms, Windows Installer saves the unsecured transforms in the %windir%\Installer folder.

If the cached copy of the transform becomes unavailable, Windows Installer can restore the transform cache using a source listed in the SOURCELIST property. Windows Installer uses the same method to search for a transform source as it uses to search for an .msi file.

To apply unsecured transforms when installing a package, pass the transform file names in the TRANSFORMS property or in the command-line string, and do not begin the string with the @ or | characters. Do not set the TransformsSecure policy or the TRANSFORMSSECURE property.

Important: You cannot combine unsecured transforms and secured transforms in the same TRANSFORMS list.

Applying a Transform to an .msi File

You can apply a transform to an .msi file by one of two methods: dynamic and static.

• Dynamic method. Place the transform on the same share as the .msi file, and configure installation options to reference that transform. You can use this method where multiple sets of customizations exist for users in an organization and where the application vendor might need to update or patch the original .msi file. Keeping the customizations separate from the original package helps to isolate them from changes to the original .msi.

• Static method. Run the transform against an administrative image of an application to permanently change the .msi of the administrative image. The customizations the transform initiates are persistent until the administrative image is deleted and recreated. Because of this, applying a transform by this method is does less often.

Most often you apply a transform to the base .msi file dynamically at deployment time. By applying the transform at installation, the administrative image's *.msi file is unchanged, even though you have tailored the installation of the application to meet the needs of the organization. The customizations that the transform initiates are persistent until the user uninstalls the application and subsequently reinstalls it.

Administrators can use multiple sets of transforms to provide the most appropriate installation of a program to diverse groups of users. One common example of this is when an administrator uses one transform to add an organization's templates to the installation of the application for all employees, and then uses a second transform, based on an employee's job, to determine which features to install.

You can also apply a transform to an administrative image's base .msi file before installing the application on client computers. This requires that the administrator applying the transform has read and write permissions to the .msi file of the administrative image.

Important: During the installation, Windows Installer registers a list of transforms required by the product. Windows Installer must apply these transforms to the installation package of the product when configuring or installing the product. If a listed transform is unavailable, and if the transform source resiliency cannot restore it, the installation fails.

Modifying Windows Installer Packages

You can transform or modify a Windows Installer package to handle a variety of customizations. In addition to controlling which features are installed, you can control where they are located — either on the local computer's hard disk or on a file server.

You can also use the tools you use to create an .msi package to help you create an .mst file. For example, InstallShield's AdminStudio enables you to create and modify transforms. AdminStudio also allows you to either create your own .mst file or edit one that already exists. For more information about InstallShield's AdminStudio, see "Windows Installer Administration Tools" later in this paper.

The Group Policy-based software deployment technology of Windows Server 2003 and Windows 2000 Server can apply transforms to Windows Installer packages. However, you can distribute a transform with its respective *.msi by using any software distribution technology that can pass a command line to a system.

Transforms Versus Group Policy

Transforms customize the installation of an application. Subsequent to an installation, the user can change the initial settings of the application. However, you can prevent or minimize the modifications a user performs on an application by using the Group Policy Microsoft Management Console (MMC) snap-in and Active Directory. You can use transforms to install an application that includes a specific set of default settings that the user can later change. If an application provides policy using an administrative template (.adm) file, it is better to use the .adm file than to use a transform to customize those settings.

For information about using Group Policy to perform software installation of Windows Installer applications, see "Deploying and Managing Software Using Group Policy" in this paper.

Preparing Non-Windows Installer-Based Applications for Installation

Options are available for installing applications that do not natively use Windows Installer for installation. Every option has its advantages and disadvantages.

If your organization maintains non-Windows Installer-based applications, and you want to improve their distribution and installation, consider the following recommendations for preparing those applications:

• Check with the application manufacturer or internal development group to see if either plans to develop a native Windows Installer implementation of the program.

• If a native Windows Installer package for the program is not available from the application manufacturer, use a software distribution method that supports the application's native setup program. Most software distribution technologies, such as Systems Management Server (SMS), provide features to enhance the installation of non-Windows Installer-based applications

  The Group Policy-based software deployment technology of Windows Server 2003 and Windows 2000 Server offers some support for non-Windows Installer-based applications by using Software Installation Settings (.zap) files. Using .zap files requires that the logged-on user have permissions to install the application. For more information about using .zap files with the software deployment component of Group Policy, see "Group Policy-based Software Deployment" in the Distributed Services Guide of the Windows Server 2003 Resource Kit.

• Reauthor the setup program of the application to create a native .msi. This might be the most effective and efficient method to gain all the benefits of Windows Installer. It might also be the best method if the application is simple, or you have thorough knowledge of its structure and of the application setup on the Windows platform using Windows Installer. For more information about reauthoring applications, see "Reauthoring Applications for Windows Installer" in the subsections that follow.

As a last resort, you can repackage the setup program of an application as an .msi file. This might be the only method that allows you to gain some of the benefits of Windows Installer and Group Policy-based software distribution. Repacking is an advanced operation, and it is recommended that you pursue the preceding options before considering repackaging an application. For more information about repackaging applications, see "Repackaging Non-Windows Installer-Based Applications for Windows Installer" later in this paper".

Note: Repackaging a Windows Installer-based application is not supported.

Reauthoring Applications for Windows Installer

When you reauthor an application, you create an application that adheres to the Windows Installer format. You essentially redevelop the setup portion of the software to take full advantage of the advanced capabilities of Windows Installer.

If you plan to reauthor an application that does not contain a Windows Installer package, you need the following:

• All executable files, DLL files, and other resources. For all but the simplest applications, you need the source code to understand the logic and behavior of the original setup program.

• An understanding of the application and the registry entries, shortcuts, and other information needed for the application to run correctly.

• An authoring tool that supports creating Windows Installer packages.

Some authoring tools help developers create new Windows Installer packages, but the procedures can be resource-intensive and costly. If you determine that the application plays a key role in the future of the company, you must weigh the benefits and the costs of reauthoring versus repackaging the application.

For example, an organization has developed a custom application that allows employees to arrange their own business travel. Because the application was developed internally, the organization has all the files for the software, and the developers understand how the software must be installed. Senior IT management has determined that the application plays an important role in the organization, and therefore the benefits of redeveloping the application outweigh the costs. This application is ideal for reauthoring for Windows Installer. As an interim solution, during the redevelopment process, you can repackage the application. Package authoring tools that developers can use to create native Windows Installer packages are available from a various tool vendors. Such authoring tools include, but are not limited to:

• Microsoft® Visual Studio® Installer

• Microsoft Visual Studio .NET

• InstallShield for Windows Installer by InstallShield Software Corporation

• Wise for Windows Installer by WISE Solutions, Inc.

Tip When developing an application, it is recommended that you introduce the Windows Installer technology during the planning phase. By developing the application to use Windows Installer, you can take full advantage of Windows Installer capabilities.

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

For more information about reauthoring applications, see the Windows Installer Software SDK.

Repackaging Non-Windows Installer-Based Applications for Windows Installer

Repackaging is not a function or feature of Windows Installer. Vendors provide tools to enable you to repackage applications in a variety of formats.

Organizations have repackaged applications for years largely for the purpose of customization. Transforms, however, eliminate the need to repackage Windows Installer-based applications for customization. In fact, repackaging an application that already uses Windows Installer for installation and maintenance would be very difficult, and is not supported.

Some organizations prefer to repackage existing applications to gain the benefits of Windows Installer and the Group Policy-based software deployment technology of Windows Server 2003 and Windows 2000 Server. The cost of repackaging in labor, time, and reliability is often underestimated. Repackaging also requires a thorough knowledge of the application's installation program of the Windows Installer setup on the Windows Platform.

Repackaging a Windows Installer package involves taking a snapshot of a clean computer (including the registry settings, files, and system settings), installing the software, and then taking a post-installation snapshot of the computer. The repackaging software detects the difference between the two snapshots and creates the necessary installation instructions to reproduce the installation. Any registry changes, files changes, or systems settings that occur during the capture process are included in the installation. Typically, from 30 to 40 processes run on a Windows XP Professional or Windows 2000 Professional computer at any given time. Thus, any one of those processes can modify a system during the installation, and the modification shows up in the repackaged application.

You can improve the reliability of repackaged applications by running them on computers that have identical hardware and software. Some common causes of failed installation or poor functionality of repackaged applications includes differences such as:

• All systems are running the same operating systems, but differ in the optional operating system components installed.

• First and second editions of Windows 98

• Service pack version

• Windows 2000 Professional and Windows 2000 Server

  Windows XP Professional and Windows Server 2003

• Different versions of shared components, such as Internet Explorer.

• Different versions of other installed applications, such as Microsoft Office.

Important: Repackaging applications into the Windows Installer format has limitations and might not be supported by the application manufacturer. Check with each application manufacturer.

Microsoft supports authoring and customizing applications that natively use Windows Installer for installation and maintenance; however, it does not support applications repackaged as .msi files. The repackaging software manufacturer provides this support.

Common Challenges of Repackaging Applications

The following information can prepare to you deal with the most common challenges of repackaging applications.

Repackaging includes irrelevant or unrelated information

Repackaging, by design, includes information in the .msi that is not part of the application. For instance, a message beep from an unrelated process might be included in a repackaged application if the process causes a message-beep to occur at the time of the capture. Another example is if you leave an unrelated folder open in Windows Explorer at the time of the capture, the repackaged application would include the entry pointing to the selected folder. While these examples are relatively harmless, others can disrupt the stability and functionality of a system.

It is possible for a highly skilled and experienced technician to eliminate extraneous or detrimental information from a capture when repackaging applications for Windows Installer. Even then, it is a labor-intensive and therefore costly operation.

Installing features on-demand is not possible

Installing individual features on demand is not possible when an application has been repackaged. When you repackage an application, the resulting .msi package contains only one feature. That is, the .msi package installs either all or none of the application.

To take advantage of install on-demand functionality, an application must be developed with multiple features so those features can be installed individually instead of all at once. Whether these features rely on shared components, depends on the design of the application, and the developer must understand all the relationships among features and components.

Taking advantage of isolated components

To take advantage of isolated components, you must author a new .msi package or modify a repackaged application after it is created. For more information about isolated components, see "Preventing Conflicts Among Applications That Share Components" in this paper.

Missing information

A repackaged application does not include information if the reference computer on which the capture is made does not have an operating system, operating system component, Web browser, application, or application option installed on the targeted system.

Little to no resiliency

Typically, repackaging specialists create packages that self-repair by using Windows Installer. This type of resiliency can produce unexpected results and can be unreliable. Repackaging tools neither decipher component dependencies nor specify the keypath for an application.

Considerations for Repackaging Applications

If you decide that repackaging applications is the appropriate solution for your organization, you can avoid common problems by considering the following when you repackage an application:

Use a clean computer, meaning a computer that has only the operating system installed and no other software installed or removed. If the computer is not clean, the repackaging tool cannot detect any files or registry entries that the application requires. As a result, essential files might be left out of the repackaged .msi file, causing the application to break when you install it.

Close nonessential services and windows.

Create a package for each unique hardware and software configuration in your organization.

Caution: Do not edit the registry unless you have no alternative. The registry editor bypasses standard safeguards, allowing settings that can damage your system, or even require you to reinstall Windows. If you must edit the registry, back it up first and see the Registry Reference in the Microsoft Windows 2000 Server Resource Kit at https://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/InternetWorking.mspx?mfr=true.

Installing Software by Using Administrator-Level Privileges

Windows Installer allows you to install or advertise administrator-specified packages by using administrator-level privileges on Windows XP Professional, Windows 2000 Professional, and Windows NT 4.0 operating systems regardless of the privileges of the user logged on to the computer.

Per computer

You can use software distribution technologies to install an application on a computer by using administrator-level privileges in the All Users profile of the operating system. The following is a sample command-line argument that you might use to install an application in the All Users profile (per-computer) that does not include a user interface from an administrative share.

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

Per user

Windows Installer provides software distribution technologies with the necessary functionality to emulate a user who is logged on. Windows Installer also provides the functionality to install an application using administrator-level privileges while operating within the user's context, regardless of the user 's privileges. This functionality is known as installing with elevated privileges.

Currently, only the Group Policy-based software deployment technology, implemented in Windows Server 2003 and Windows 2000 Server, takes advantage of the functionality of providing elevated privileges on a per-user and per-computer basis. When other software distribution technologies begin implementing this functionality, the steps required to take advantage of this functionality will vary. For specific information about support for installing software on a per-user basis with elevated privileges, contact the manufacturer of the software distribution technology.

Situations that Demonstrate Using Administrator-Level Privileges

Situations 1, 2, and 3 demonstrate the relationship of:

• The privileges of a logged-on user.

• The privileges of the software installation agent of the software distribution technology.

• The ability of the software distribution technology to install with elevated privileges.

• The profiles to which applications can be installed.

Situation 1

The logged-on user has user privileges on the computer, and the software distribution technology's agent installed on the user's computer is running under a different context and has administrator-level privileges.

For software distribution technologies that take advantage of Windows Installer's ability to install applications by using elevated privileges, the capabilities to install an application at an elevated level per-computer and per-user follow:

• Installation for the logged-on user (per-user): Yes

• Installation for all users (per-computer): Yes

For software distribution technologies that do not include the functionality to take advantage of Windows Installer's ability to install applications with elevated privileges, following is a list of the capabilities of the software distribution technologies to install an application elevated per-computer and per-user

• Installation for the logged-on user (per-user): No

• Installation for all users (per-computer): Yes

Situation 2

The logged-on user has user privileges, and the agent is running within the logged-on user's context. The capabilities that the software distribution technologies use to install an application that is elevated per-computer and per-user follow:

• Installation for the logged-on user (per user): Yes

• Installation for all users (per computer): No

Without taking advantage of the ability of Windows Installer to install an application for each user who has elevated privileges, the application can only be successfully deployed per-user if it writes only to locations where the logged-on user has the appropriate permissions.

This requires that the application write only to locations that the logged-on user has permissions to access.

Situation 3

The logged-on user has administrative privileges on the system, and the installation agent is running within the logged-on user's context. The capabilities of the software distribution technology to install an application elevated per-computer and per-user follows:

• Installation for the logged-on user (per user): Yes

• Installation for all users (per computer): Yes

Microsoft Software Distribution Technologies

Any software-distribution technology that can pass a command line to a system can also take advantage of the Windows Installer technology. For information about non-Microsoft technologies, contact the appropriate manufacturers.

Group Policy-Based Software Deployment

A Group Policy-based software deployment component is built into the Windows Server 2003 and Windows 2000 Server operating systems, and it enables a set of powerful features designed to increase availability and reduce the overall cost of supporting users of Windows operating systems. By using the Group Policy-based software deployment component, software administrators can centrally install and manage software applications throughout an organization. This management system allows you to deploy, upgrade, patch, and remove software applications for groups of users and computers instead of managing each desktop separately. It gives users reliable access to the applications that they need to perform their jobs from any computer they use on the network. Windows Installer is a core component of the Group Policy-based software deployment technology.

Use the Group Policy-based software deployment component of Windows .NET and Windows 2000 to deploy and manage software in organizations, from small to medium in size, if the following conditions exist:

• You have deployed Active Directory.

• You have a solid base of Windows 2000 Professional or later client computers.

• You have determined that Group Policy provides the management features your organization requires.

For more information about the Group Policy-based software deployment component, see "Deploying and Managing Software Using Group Policy" in the Distributed Services Guide, and "Deploying a Managed Software Environment" in the Deployment Guide, both guides are components of the Windows Server 2003 Resource Kit.

Systems Management Server (SMS) Software Distribution

If your organization is from medium to large in size and you require more advanced features for managing software, consider using Systems Management Server (SMS). The advanced capabilities of SMS include inventory-based targeting, status reporting, server- and client-side scheduling, multiple site facilities, complex targeting, centralized hardware and software inventory, remote diagnostic tools, software metering, Windows XP and enhanced software deployment features. SMS also includes support for Windows 95, Windows 98, Windows NT version 4.0, Windows 2000, and Windows XP clients. Additionally, SMS does not require Active Directory.

When you use SMS to deploy Windows Installer setup packages, you gain advanced change and configuration benefits, which allow you to do the following:

• Verify that target computers meet setup requirements using the hardware and software inventory capability.

• Inventory hardware and software throughout your organization.

• Discreetly manage deployment to software-distribution shares, scheduling distributions so as to not degrade network performance to below acceptable levels.

• Evaluate software distributions (dynamically) to target users and computers based on a set of rules you define.

• Schedule software installations to keep network bandwidth use at desired levels.

• Use the software metering capability to track software usage by users, groups, workstations, time, or license quota, and to control the use of applications on servers and workstations. .

• Use the diagnostic and troubleshooting tools to track and repair performance problems on specific computers or throughout your network.

For more information about using SMS to deploy and manage applications in your organization go to https://www.microsoft.com/smsmgmt/deployment/deploymsi.asp.

Patching and Upgrading Software Applications

You can centrally update and maintain the software applications in your organization by using command-line arguments or by using the user interface of a software distribution technology. The software updates that you can perform include patching existing applications and implementing small updates, minor upgrades, and major upgrades.

Because an installation package contains all the information needed for an installation, as well as the files that make up the application, you can update information within the following parts of an installation package:

• The .msi file.

• The files of the application.

• The Windows Installer registration information.

Patching Software

A patch is an updated version for an application. You can obtain patches from the software manufacturers or internal developers of the original program. You can update an existing application without uninstalling the product. This preserves the customizations of the installation and potentially reduces the cost to make the change. The patch might change only a few bytes of a single application file, making it more efficient to distribute those few bytes, as opposed to uninstalling and redeploying the entire product. At the other extreme, a patch might change all of the files and registry keys in a product.

A patch package (.msp) does not include a database like a regular installation package. Instead it contains, at a minimum, one database transform (a transform that adds information to the database of its target installation's .msi package.) Windows Installer uses this information to apply the patch files that are stored in the cabinet file stream of the patch package.

Patch installation packages comprise the following parts:

• Summary information stream

• Transform substorage

• Cabinet file stream

Summary information stream

Each substorage has its own summary information stream, which contains at least the following:

• A GUID that uniquely identifies the patch. The GUID for this patch is appended to a list of GUIDs for earlier patches that are replaced by this patch.

• A list of product codes delimited by semicolons, specifying the valid product configurations to which the patch might be applied. targets for this patch.

• A semicolon-delimited list of transform sub-storage names, in the order they are to be applied (sub-storages are described in the following subsection).

• A list of sources delimited by semicolons for this patch.

• For a complete list of the summary properties see the Windows Installer SDK on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources/.

Transform sub-storage

Transforms can update the database of an application. A transform might be used to add or remove new files, registry entries, user interfaces, or customizations. Each such transform is included in a patch package as a sub-storage.

Two transforms are stored in a patch for each target database, and more than one pair of transforms can be stored in a patch if there are multiple targets. The first transform modifies the target to the new version. The second transform adds entries to the Patch, PatchPackage, Media, InstallExecuteSequence, and AdminExecuteSequence tables that provide file patching instructions to Windows Installer.

If the target of the installation is an administrative image, an administrator can have Windows Installer apply transforms during the creation of the image. These changes persist in the administrative image of the Windows Installer package of the application. If the target of the installation is a local installation versus an administrative image, Windows Installer reapplies the transforms each time a maintenance-mode or uninstall operation is invoked for the application.

Cabinet file stream

The cabinet file stream included in a patch can contain three types of files:

Patch files

Contain the information required to transform the previous version of the file into the new version. You can use a single patch file to update one or more old versions of a file.

New files

Are added to the application and are not present in the previous version.

Entire file

Replaces the previous version. In the rare case where the new version of a file is smaller than the patch that would be required to update the previous version of that file, you can include the new file in its entirety as a patch.

Important: Administrators must not deploy a patch that might add 64-bit components to a 32-bit application. This can cause failures on 32-bit clients because they cannot run 64-bit components.

Applying Patches to Installed Software

You can use the command-line option to apply a patch to software installed on a computer. The command-line option requires that you supply values for the REINSTALL and REINSTALLMODE properties when applying the patch. You do not need to recache the *.msi file, or the "v" argument, for REINSTALLMODE because the local copy of the *.msi, in the %windir%\installer directory, is not modified.

To patch installations directly on a local computer, run the following command:

msiexec /p patch.msp REINSTALL=[Feature list] REINSTALLMODE=omus

The parameters for REINSTALLMODE are defined in an earlier table, Table 4.

The original source of the installation is required when you apply a patch. However, if the original media are not available, you can use a network location. After you apply the patch, it is cached on the client computer so it can perform an installation-on-demand, a reinstallation, a repair, or a removal of the application.

To patch installations using an administrative image:

1. Create the administrative image, if it does not already exist, with the following command line:

msiexec /a <path to the MSI>\package.msi

2. Update the administrative image by running the following command-line option:

msiexec /a <path to administrative image> \package.msi /p <path>\patch.msp

3. This update changes the *.msi on the administrative image by directly applying the patch.

4. Update users' computers by running the installation of the application from the administrative image using one of the following command-line options:

msiexec /fvomus <path to administrative image>\package.msi REINSTALL=ALL msiexec /i <path to administrative image>\package.msi REINSTALL=ALL REINSTALLMODE=vomus

If you know all the features that the patch will affect, you can set REINSTALL to the complete list of features (delimited by commas) to affect only those features. This is likely to decrease the time the update operation takes. For more information about the REINSTALL property see the Windows Installer SDK, which is available from the Web Resources page at https://www.microsoft.com/windows/reskits/webresources/

Applying a patch to an administrative installation modifies the original *.msi. The "v" argument is required in this situation to cache the modified *.msi to the local system. Failure to cache the *.msi prevents the application from performing maintenance operations. The consequences of this are discussed in the following paragraphs.

Important: A patch changes the package code of an .msi file. To allow Windows Installer to perform maintenance operations such as adding, removing, or repairing an installation, the package codes for the installed application and the source must match. Therefore, a computer that still has the original package code installed cannot be maintained by using a patched administrative image until you update the computer.

If the deployment of the patched administrative image of an application is an update, not a new installation, and it takes a considerable amount of time to reach all target client computers, it is recommended you take one of the following actions:

• Create a new administrative image for the application and apply the patch to it. You can then distribute this new source to the appropriate systems. After you upgrade all systems, you can remove or patch the original administrative image to provide a redundant source.

• Patch the clients directly on a local computer, as described in "Applying Patches to Installed Software" in this paper. This method does not modify the .msi cached on the local system, and therefore the .msi in the administrative image and on the local system remain identical.

Either of the two preceding methods can prevent the application on the client computer and the source administrative image for the application from becoming unsynchronized. If the client computer and source administrative image for an application become unsynchronized, Windows Installer cannot perform maintenance operations for the application, such as adding, modifying, removing, or repairing an installation.

Important: To remove a patch that you have applied, you must remove the entire application, and then reinstall the application without the patch. There is no way to roll back the changes a patch applies to the original package.

Patching an Administrative Image

You can patch an administrative image by using the command-line option mentioned earlier. The resulting administrative image is the same as that produced by an administrative installation that uses a full-product CD that includes the update.

The changes made by the patch persist on the administrative image. However, these changes are not automatically propagated to existing installations. The application must be reinstalled by using a command with the following arguments: REINSTALL and REINSTALLMODE properties.

You can automate the process of patching multiple administrative images by using a software-distribution technology. For example, using Systems Management Server (SMS), you can update your distribution points from an updated source.

The application cannot be reinstalled from Add or Remove Programs in Control Panel. After the update is completed, an updated .msi file is cached on the client computer.

The most common problem during patching software occurs when you do not enter the REINSTALLMODE and the REINSTALL arguments on the command line. If these two are not specified, the patch is not applied.

Also, if the patch adds a new feature to the application, you must enter ADDLOCAL on the command line, specifying the feature name of that new feature. However, when you use ADDLOCAL to specify a feature name, do not specify REINSTALL= ALL. Instead, the REINSTALL argument must be a list of the features delimited by commas, which need to be reinstalled.

If features that were previously installed locally are now advertised after you apply a patch to an installation, it is a sign of one of the problems described in the preceding two paragraphs.

Upgrading Software

You can upgrade an existing application directly on a computer or distribute it by using a software-distribution tool. When used to process an upgrade, Windows Installer detects whether the application to be upgraded was previously advertised or installed, and then removes it when installing the newer version. Additionally, Windows Installer allows for some migration of feature states from previously installed applications.

During an upgrade, Windows Installer searches for upgradable products by querying the Upgrade table of the upgrade package. Windows Installer installs the new version of the product. If the installation software finds an older version of the product, it removes the previous version. This is similar to running the msiexec command with the /x argument.

At development time, the author of the application's setup program can choose to uninstall the previous version first, and then install the new version. This might be technically necessary, but is inefficient because Windows Installer must recopy all the reused (non-upgraded) files.

Upgrade actions are performed only when the product is first installed. The maintenance mode and uninstallation does not trigger these actions.

Types of Upgrades

There are three types of software renewal methods to consider when you update software in your organization:

• Small updates

• Minor upgrades

• Major upgrades

Manufacturers might provide updates and upgrades as a full installation package (.msi) or as a patch package (.msp).

Small Updates

A small update changes the .msi file and the application files without changing the "Product Code" or "Product Version." An update to one or two files, which is too small a change to warrant changing the product version, is considered a small update.

Minor Upgrades

A minor upgrade changes the application's product version but not its product code. Changing the product version enables the author to prevent downgrades, and enables the sequencing of packages to install. The product version is stored in the ProductVersion property.

The properties needed for installing small updates and minor upgrades are REINSTALL and REINSTALLMODE. When using the command line, use these entries to get the new version of the package cached on the system — if you do not, the existing cached version of the application is used.

The only difference between the small updates and minor upgrades is the requirement to differentiate between products. When using the command line, you need to set the REINSTALLMODE property or use the /v switch to cache the new package. You also must use the Add Local switch to install new features, especially when you do a minor upgrade.

Small updates and minor upgrades are essentially a reinstallation using a new package. Whichever type of upgrade you choose, the .msi package code changes to ensure the new package is used.

One fundamental concept to both of these types of software renewal methods is that you can neither add components to nor remove components from an existing feature. You can add new components only within new features.

A small update or a minor upgrade can affect applications in the following ways:

• Enlarge or reduce the feature component tree, without reorganizing the existing hierarchy of features and components described in the table of feature components.

• Add a new feature to the existing feature component tree.

• Remove a parent feature, including all the child features of each parent feature.

• Add a new component if the component is associated with a new feature.

• Change the tables, custom actions, and dialogs in the .msi file without changing the file name. (Renaming the *.msi modifies the package, which also changes the package code.)

• Add, modify, or remove files, registry keys, or shortcuts for components that are not shared among features.

However, the changes do not affect the following:

• The component code of any component.

• The name of a component's keypath file because this would require changing the component code.

• The name of the .msi file of the installation package.

If the software renewal modifies a version file, it must increment the version of the file in the File table. If the update removes resources, it typically updates the RemoveFile and RemoveRegistry tables to remove any unused files, registry keys, or shortcuts that have already been installed.

Important: An update can modify the resources of a shared component such as files, registry entries, and shortcuts, as long as the changes are backwards compatible. However, adding or removing files, registry entries, or shortcuts for a shared component is not recommended.

For information about the switches used to run a small or minor upgrade, see the Windows Installer SDK, which is available from the Web Resources page at https://www.microsoft.com/windows/reskits/webresources/.

Major Upgrades

A major upgrade changes both the product version and the product code—essentially, a new installation and, optionally, an application removal. The product code is a GUID and is the principal identifier for an application. It is stored in the ProductCode property in the Property table. A manufacturer can ship a major upgrade as a patch (an .msp file) or as a full product (an msi file). Major upgrades are possible only with Windows Installer version 1.1 or later.

During a major upgrade, Windows Installer searches the client computer for installed applications that are related to the pending upgrade. On detecting such an application, Windows Installer retrieves that application's version designation from the system registry. Windows Installer then uses information in the database of the upgrade to determine whether to upgrade the installed application.

In a major upgrade, the original installed version of an application might be uninstalled, or it might remain on the system and coexist with the newer version. The availability of this option depends on the implementation of each application: if an application does not function properly with different versions of the same product installed on the same system, the setup program will not offer the option for such an installation because it is likely that both versions of the application function unpredictably.

The following circumstances require that you perform a major upgrade:

• Installations of the original and updated products coexist on the same computer.

• The name of the .msi file has changed.

• The component code of an existing component has changed.

• A component has been added or removed from an existing feature.

• An existing feature has been made into a child of an existing feature.

• An existing child feature has been removed from its parent feature.

Table 25 provides a quick view of the significant differences among small updates, minor upgrades, and major upgrades.

Table 25 Significant Differences Among Small Updates, Minor Upgrades, and Major Upgrades

Type of Renewal	ProductCode Property	ProductVersion Property	Description
Small update	No change	No change	An update to one or two files that is too small to warrant changing the ProductVersion. The package code in the Revision Number Summary property does change. The manufacturer can ship the product as a patch package or as a full product installation package.
Minor upgrade	No change	Change	A small update that involves changes large enough to warrant changing the ProductVersion property. The manufacturer can ship the product as a patch package or as a full product installation package.
Major upgrade	Change	Change	A comprehensive update of the product warranting a change in the ProductCode property. The manufacturer can ship the product as a patch package or as a full product installation package.

Managing Windows Installer by Using Group Policy

You can manage the behavior of Windows Installer, being that it is an operating system component, by using Group Policy on computers running Windows 2000 Professional or later. In Windows Server 2003 and Windows 2000 Server, the Administrative Templates node of the Group Policy snap-in uses administrative template files (.adm) to specify the registry settings that you can modify by using the Group Policy snap-in user interface.

The Administrative Templates node includes all registry-based Group Policy data. This includes Group Policy settings for the Windows Server 2003 and Windows 2000 Server operating systems and the various services of these operating systems. It also includes Group Policy settings for individual applications. In Windows Server 2003 and Windows 2000 Server, you can use Group Policy to define configurations for organizational units (OUs) of users and of computers.

The Group Policy settings you create are contained in a Group Policy object (GPO). By associating a GPO with selected Active Directory service system containers — sites, domains, and OUs — you can apply these settings to the users and computers in those Active Directory containers. To create GPOs, use the Group Policy MMC snap-in included with Windows Server 2003.

Figure 3 shows the Windows Installer local Group Policy Computer settings available in the Group Policy MMC snap-in.

Figure 3: Windows Installer Local Group Policy Computer Settings

Figure 4 shows the Windows Installer local Group Policy User settings available in the Group Policy MMC snap-in in included with Windows Server 2003.

Figure 4: Windows Installer Local Group Policy User Settings

Troubleshooting Software Installations

When troubleshooting software installation-related issues, you must observe and identify symptoms of the problem. You must learn more about the circumstances under which problems occur and become familiar with system behavior when issues arise. Use the tools Windows Server 2003 provides to troubleshoot software installation-related issues.

For information about general troubleshooting strategies, see "Troubleshooting Concepts and Strategies" in the Microsoft Windows Server 2003 Resource Kit.

Validating Packages

It is strongly recommended that you run validation on every new or newly modified package before attempting to install it the first time. Most Windows Installer authoring tools contain the facility to perform package validation. To validate your packages using Orca, included with the Windows Installer SDK, click Validate on the Tools menu.

Most Windows Installer authoring tools use Internal Consistency Evaluators, also called ICEs, to perform package validation. ICEs are custom actions written in VBScript, or in JScript, or as a .dll or .exe. When you run an ICE, it scans the package's database to identify entries that are valid individually but might cause incorrect behavior in the context of the entire database.

ICE custom actions return four kinds of messages:

• Informational. Provide information from the ICE and do not indicate a problem with the database. Often the information is about the ICE itself, such as a brief description. These messages can also provide progress information while the ICE runs.

• Warnings. Report database authoring that causes incorrect behavior in certain cases. Warnings can also report unexpected side effects of database authoring For example, entering two separate conditions of the same property name spelled the same way but with a "case" difference in the letters of the name. Because Windows Installer is case-sensitive, it treats these as two different properties.

• Errors. Report database authoring that cause incorrect behavior. For example, duplicate component GUIDs cause Windows Installer to incorrectly register components.

• Failures. Report the failure of the ICE custom action. Failure is commonly caused by a database with such severe problems that the ICE cannot even run.

Event Logging

Event logging in Windows XP Professional, Windows 2000 Professional, and Windows NT provides a standard, centralized way for applications and the operating system to record important software and hardware events. The event-logging service stores events from various sources in a single collection called an event log. Windows Server 2003, Windows XP, Windows 2000, and Windows NT 4.0 include Event Viewer to view the logs and a programming interface to examine the logs.

Windows Installer also writes entries into the Event Log, which record events such as the following.

• Success or failure of the installation, removal, or repair of a product.

• Errors that occur during product configuration.

• Detection of corrupted configuration data.

• Information about the missing components that cause a repair of an application.

If a large amount of information is written, the Event Log file can become full and Windows Installer displays the "The Application log file is full" Message.

Note: Windows 95- and Windows 98-based computers have no built-in Event Log. On these systems, Windows Installer logs the same event information but writes it to a file in the %temp% folder called Msievent.log.

Internal Logging

Windows Installer records errors and events in its own internal error log (file name.log) and in the Windows Server 2003 Event Log. The diagnostic information Windows Installer writes to these log files can help you and users understand why an installation fails.

The type of logging that Windows Installer performs is determined when you set the logging mode. You can use various means to enable the logging mode:

• The MsiEnableLog function

• The EnableLog method

• The /L command-line option of Msiexec.exe

• The registry

Enable Logging by Using the Command-Line Option /L

Using the /L command-line option of Msiexec.exe, you can specify exactly what gets logged and where. Table 26 describes the arguments for logging using command-line option /L:

Table 26 Arguments for Logging Using Command-Line Option /L

Argument	Effect
I	Status messages
W	Non-fatal warnings
E	All error messages
A	Start up of actions
R	Action-specific records
U	User requests
C	Initial UI arguments
M	Out-of-memory or fatal exit information
o	Out-of-disk-space messages
p	Terminal properties
v	Verbose output
+	Append to existing file
!	Flush each line to the log
*	Log all information except for the v option. To include the v option, specify "/l*v".

To create a normal log file for a command-line installation, append /L* LOGFILE.NAME to your Msiexec command line. This gives you a normal log file with all arguments selected except v. For a verbose log, which contains much more detailed information, append "/L*v LOGFILE.NAME" to your Msiexec command line instead.

The following syntax is a normal log command-line example:

Msiexec /i Testdbsetup.msi /l* msi.log

The following syntax is a verbose log command-line example:

Msiexec /i Testdbsetup.msi /l*v Msi.log

The following syntax enables verbose logging during an installation without any user interface. The log file is "program.log" and is placed in the root of drive C.

msiexec /qn /l*v c:\program.log /i \\server\share\setup.msi

Enable Logging by Using the Registry

If you keep the logging capability turned on at all times, or you log an installation that is not run from the command line, such as an on-demand or self-repair installation, set the following value under the HKEY_LOCAL_MACHINE \SOFTWARE \Policies \Microsoft \Windows \Installer key.

**Value Name:**Logging

**Value Data:**icewarmup

To create a verbose log, set the registry value to icewarmupv instead.

Use this policy only if you have not enabled logging by the "/L" command-line option or MsiEnableLog. If Group Policy is set in this case, a log file is created in the Temp directory with the random name: .msi*.x.LOG.

Reading a Windows Installer Log File

For example, take the log file created by Office 2000 Premium.

The Office 2000 Setup.exe uses the following command line to launch the installation:

C:\WINDOWS\SYSTEM\msiexec.exe  /I <install path>\data1.msi /Lpiwae
"C:\WINDOWS\TEMP\Office 2000
Premium Setup(0002)_MsiExec.txt"

Table 27 includes the logging arguments used in the preceding command.

Table 27 Log File Arguments

Argument	Effect
p	Terminal properties
i	Status messages
w	Non-fatal warnings
a	Start up of actions
e	All error messages

By default, Office 2000 does not do verbose logging. However, you can instruct it to do verbose logging by using a command-line entry such as the following:

<path>\setup.exe /l*v c:\Officelog.txt

When actions are completed successfully, you see a return value of 1 (one) for the action. For example, the following excerpt is from a non-verbose Office 2000 log:

=== Logging started: 5/17/99 13:55:41 ===
Action start 13:55:41: INSTALL.
Action start 13:55:41: CheckOSandSPAction.
Action ended 13:55:41: CheckOSandSPAction. Return value 1.

Return values are also specified in verbose logs along with more details. The following excerpt from a verbose log corresponds with the same actions as the preceding example:

Action start 11:28:42: INSTALL.
MSI (c) (D6:6E): UI Sequence table 'InstallUISequence' is
present and populated.
MSI (c) (D6:6E): Running UISequence
MSI (c) (D6:6E): Skipping action: ResumeInstall (condition is false)
MSI (c) (D6:6E): Doing action: CheckOSandSPAction
Action start 11:28:42: CheckOSandSPAction.
MSI (c) (D6:6E): Creating MSIHANDLE (1) of type 790542 for thread 110
Action ended 11:28:42: CheckOSandSPAction. Return value 1.

When an action cannot be completed until the next computer restart, you typically get a return value of 4. For example:

Action 14:18:30: InstallMMCExe.
Action 14:18:33: ForceReboot.
Action ended 14:18:33: ForceReboot. Return value 4.
Info 1101. Error reading from file: ScriptsDisabled. System error 2.
Verify that the file
exists and that you can access it.
Action 14:18:35: RollbackCleanup. Removing backup files
Action ended 14:18:37: INSTALL. Return value 4.
Action ended 14:18:38: ExecuteAction. Return value 4.
Action ended 14:18:38: INSTALL. Return value 4.

Table 28 includes a list of possible return values.

Table 28 Possible Return Values

Value	Description
0	Action not invoked; most likely does not exist.
1	Completed actions successfully.
2	User terminated prematurely.
3	Unrecoverable error occurred.
4	Sequence suspended, to be resumed later.

Running Client and Server Processes Under Windows NT

Under Windows NT, Windows Installer runs the installation as two distinct processes: client and server. The client process runs the UI in the user context (collects user information and displays the UI). The server process runs as a Windows NT service and performs the main installation (executes the script). Both processes occur on the same computer. Both processes are logged to the same log file.

Note: Windows 9X has only one process acting as both client and server.

It is easy to see where the server process starts in a verbose log. A line appears that starts with the following:

   MSI (c) (4C:1D): Switching to server

This informs you that the installation is passing to the server side. The server side performs the installation functions, such as copying files, and writing registries . Next, the server side properties appear, such as the following, which are from a verbose log:

MSI (s) (DA:E4): User policy value 'TransformsSecure' is 0

Or -

MSI (s) (DA:E4): User policy value 'TransformsAtSource' is 0

You can identify the server properties by the "(s)". In a nonverbose log, you do not have a "switching to server" statement, but you can identify server-side properties because each starts with "Property(S)." For example:

Property(S): ProductName = Microsoft Office 2000 Premium

Or -

Property(S): ProductVersion = 9.00.2720

After the server-side properties are logged, Windows Installer returns to client side and logs the client-side properties. Logged client-side properties begin with the text "MSI (c)" in verbose logs and with "Property(C)" in non-verbose logs.

To view an actual Windows Installer log file that has annotations explaining certain important output lines, see "Appendix: An Annotated Windows Installer Log File" in the later in this paper.

Strategies for Troubleshooting

If you use a UI for software installation, and the installation fails, an error message identifies the cause. If verbose logging is enabled, you might find additional information about the error in the log. The log file can help you determine the cause of the problem.

If an error is an "Internal Error," you can find documentation about the specific error code in the Windows Installer SDK. Typically, internal errors result from a problem with the package or with the Windows Installer service.

Error messages

Start by searching for "error" in Windows Installer log file. If the word "error" is followed by a number, you can find the meaning of the error message in the "Microsoft Windows Installer Error Messages" topic in the Msi.chm Help file included with the Windows Installer SDK.

In the log file, using the error number, you can determine what section the error occurs in, such as a registry write or a file copy.

Because Windows Installer does not display all error messages, and messages some do not appear in the logs, you might need to use an alternative tactic to locate the problem. Unusual breaks in time stamps in the log statements might help you to determine the cause of the problem.

Remember that a verbose log provides more details, such as why a particular file was or was not copied. For example:

MSI (s) (8B:82): Executing op:
 SetTargetFolder(Folder=D:\WINNT\inf\)
MSI (s) (8B:82): Executing op:
SetSourceFolder(Folder=G:\Windows\inf\)
MSI (s) (8B:82): Executing op:
FileCopy(SourceName=agtinst.inf,
DestName=agtinst.inf,Attributes=8192,FileSize=7766,,,
InstallMode=25427968,PerTick=32768,
IsCompressed=0,,VerifyMedia=1,,)
MSI (s) (8B:82): File: D:\WINNT\inf\agtinst.inf;
 Overwrite; Existing file is unversioned and unmodified

Rollbacks

Because Windows Installer setups are transaction-based, a rollback occurs if setup is not completed. Search for the string "rollback" in the setup log. Ignore the line that says "removing rollback files"; rollback files are removed at the end of a successful setup.

The following excerpt is from a log for an incomplete installation:

1: exsec32.dll 2: C:\Program Files\Common Files\System\Mapi\1033\
Internal Error 2925. C:\Program Files\Common
Files\System\Mapi\1033\exsec32.dll,
 -
2147024865
Action ended 12:25:04: InstallFinalize. Return value 3.
Action 12:25:08: Rollback. Rolling back action:
Rollback:

Apparently, the rollback is occurring as a result of the error with the exsec32.dll file. You can find the error number (Internal Error 2925) in the "Microsoft Windows Installer Error Messages" topic in the Msi.chm Help file included with the Microsoft Windows Installer SDK.

Computer restarts

Unless computer restarts are intentionally suppressed, initial installations on Windows NT 4.0, Windows 95, and Windows 98 might require a computer restart. Make sure that the installation continues after you restart the computer.

Action start 16:47:38: ForceReboot
Action 16:47:38: GenerateScript. Generating script operations for action:
Action 16:47:38: ForceReboot.
Action ended 16:47:38: ForceReboot. Return value 4

Windows Installer Administration Tools

Windows Server 2003 provides many tools that help you deploy and maintain software in an organization. Windows Installer-based tools include Windows Installer Group Policy Settings, Windows Installer SDK tools, tools from the operating system CD, and others.

Windows Installer Group Policy Settings

The Group Policy settings listed in Table 29 play a role in installing software. You can access the Group Policy settings for software deployment in two locations in the Group Policy Object Editor MMC snap-in: Computer Configuration\Administrative Templates\Windows Components\Windows Installer and User Configuration\Administrative Templates\Windows Components\Windows Installer. Table 29 lists the Windows Installer Group Policy settings for Windows Server 2003 and a description of each.

Table 29 Windows Installer Group Policy Settings

Windows Installer Group Policy Setting	Description	Considerations
Always install with elevated privileges (Per user and per computer)	Directs Windows Installer to use system permissions when it installs any program on the system.	This setting appears both in the Computer Configuration and User Configuration folders. To make this setting effective, you must enable the setting in both folders. Skilled users can take advantage of the permissions this policy setting grants to change their privileges and gain permanent and unrestricted access to local files and folders. The User Configuration of this setting is not guaranteed to be secure.
Search order (Per user)	Specifies the order in which Windows Installer searches for installation files.	By default, Windows Installer searches the network first, then removable media (floppy disk drive, CD-ROM, or DVD), and finally, the Internet. To change the search order, enable the setting, and then type the letters representing each file source in the order that you want Windows Installer to search.: -- n represents the network; -- m represents media; -- u represents URL, or the Internet. To exclude a file source, omit or delete the letter representing that source type.
Prohibit rollback (Per user and per computer)	Prohibits Windows Installer from generating and saving the files it needs to reverse an interrupted or unsuccessful installation.	Prevents Windows Installer from recording the original state of the system and sequence of changes it makes during installation. Also prevents Windows Installer from retaining files it intends to delete later. As a result, Windows installer cannot restore the computer to its original state if the installation is not completed. This setting reduces the amount of temporary disk space required to install programs. Because an incomplete installation can render the system or a program inoperable, do not use this setting unless essential. This setting appears in the Computer Configuration and User Configuration folders. If the setting is enabled in either folder, it is considered be enabled, even if it is explicitly disabled in the other folder.
Disable media source for any install (Per user)	Prevents users from installing programs from removable media.	If a user tries to install a program from removable media, such as CD-ROMs, floppy disks, and DVDs, a message appears, stating that the feature cannot be found. This setting applies even when the installation is running in the user's security context. If you disable this setting or do not configure it, users can install from removable media when the installation is running in their own security context, but only system administrators can use removable media when an installation is running with elevated system privileges, such as installations offered on the desktop or in Add or Remove Programs.
Disable Windows Installer (Per computer)	Prevents users from installing unmanaged software on their desktops or permits users to install only those programs offered by a system administrator.	This setting affects Windows Installer only. It does not prevent users from using other methods to install and upgrade programs.
Remove browse dialog box for new source (Per computer)	Prevents users from searching for installation files when they add features or components to an installed program.	This setting disables the Browse button beside the Use feature from list in the Windows Installer dialog box. As a result, users must select an installation file source from the list the system administrator configures. This setting applies even when the installation is running in the user's security context. If you disable this setting or do not configure it, the Browse button is enabled when an installation is running in the user's security context. However, only system administrators can browse when an installation is running with elevated system privileges, such as installations offered on the desktop or in Add or Remove Programs.
Prohibit patching (Per computer)	Prevents users from using Windows Installer to install patches.	Patches can be vehicles for malicious programs. This setting applies only to installations that run in the user's security context. By default, users who are not system administrators cannot apply patches to installations that run with elevated system privileges, such as those offered on the desktop or in Add or Remove Programs.
Disable IE security prompt for Windows Installer scripts (Per computer)	Allows Web-based programs to install software on the computer without notifying the user.	By default, when a script hosted by an Internet browser tries to install a program on the system, the system warns users and allows them to select or refuse the installation. Disabling the IE security prompt suppresses the warning and allows the installation to proceed. This setting is designed for enterprises that use Web-based tools to distribute programs to employees. However, because this setting can pose a security risk, apply it cautiously.
Enable user control over installs (Per computer)	Permits users to change installation options that typically are available only to system administrators.	This setting bypasses some of the security features of Windows Installer. It permits installations to finish that are otherwise stopped due to a security violation. The security features of Windows Installer prevent users from changing installation options typically reserved for system administrators, such as specifying the directory into which files are installed. If Windows Installer detects that an installation package has permitted the user to change a protected option, it stops the installation and displays a message. These security features operate only when the installation program is running in a privileged security context in which it has access to directories denied to the user. This setting is designed for less restrictive environments. It can be used to circumvent errors in an installation program that prevent software from being installed.
Enable user to browse for source while elevated (Per computer)	Allows users to search for installation files during privileged installations.	This setting enables the Browse button on the Use feature from dialog box. As a result, users can search for installation files even when the installation program is running with elevated system privileges. By default, only system administrators can browse during installations with elevated privileges, such as installations offered on the desktop or displayed in Add or Remove Programs. Because the installation is running with elevated system privileges, users can browse through directories that their own permissions do not allow. This setting does not affect installations that run in the user's security context. Also, see the Disable browse dialog box for new source setting.
Enable user to use media source while elevated (Per computer)	Allows users to install programs from removable media, such as floppy disks and CD-ROMs, during privileged installations.	This setting does not affect installations that run in the user's security context. By default, users can install from removable media when the installation runs in their own security context.
Enable user to patch elevated products (Per computer)	Allows users to upgrade programs during privileged installations.	This setting permits all users to install patches, even when the installation program is running with elevated system privileges. Patches can be vehicles for malicious programs. By default, only system administrators can apply patches during installations with elevated privileges, such as installations offered on the desktop or displayed in Add or Remove Programs. This setting does not affect installations that run in the user's security context. By default, users can install patches to programs that run in their own security context. Also, see the Disable patching setting.
Allow administrator to install from a Terminal Server session (Per computer)	Allows Terminal Server administrators to install and configure programs remotely.	By default, system administrators can install programs only when system administrators are logged on to the computer on which the program is being installed. This setting creates a special exception for Terminal Servers. This setting affects system administrators only. Other users cannot install programs remotely.
Cache transforms in secure location on workstation (Per computer)	Saves copies of transform files in a secure location on the local computer.	This setting is designed for enterprises that must take special precautions to prevent unauthorized or malicious editing of transform files. By default, Windows Installer stores transform files in the Application Data directory in the user's profile. When a user reinstalls, removes, or repairs an installation, the transform file is available even if the user is on a different computer or isn't connected to the network. If you enable this setting, the transform file is saved in a secure location on the user's computer instead of in the user profile. Because Windows Installer requires the transform file to repeat an installation in which the transform file was used, the user must be using the same computer or be connected to the original or identical media to reinstall, remove, or repair the installation. This setting is designed for enterprises that must take special precautions to prevent unauthorized or malicious editing of transform files.
Logging (Per computer).	Specifies the types of events that Windows Installer records in its transaction log for each installation. The log, Msi.log, appears in the Temp directory of the system volume. When this setting is enabled, an administrator can specify the types of events Windows Installer records.	When you enable this setting, you can specify the types of events you want Windows Installer to record. To indicate that an event type is recorded, type the letter representing the event type. You can type the letters in any order and list as many or as few event types as you want. To disable logging, delete all of the letters from the box. If you disable this setting or do not configure it, Windows Installer logs the default event types, represented by the letters "iweap." You can activate one or more of the following types of logging modes: i -Status messages w - Non-fatal messages e- All error messages a - Start up of actions r - Action-specific records u - User requests c - Initial UI arguments m - Out of memory p - Terminal properties v - Verbose output o - Out of disk space However, if you do not configure it, Windows Installer logs the default event types represented by the letters: "iweap"

For more information about these Group Policy settings, select each setting in the Group Policy Object Editor snap-in UI to read the detailed descriptions and considerations.

Caution: Configuring and linking a GPO can affect the computers and users on your network in unexpected ways. For example, these settings can change configurations that you have created by using other snap-ins. To prevent unexpected results, you must set up a test environment that is identical to the production environment. Configure the policy and observe its behavior before configuring the policy in the production environment.

Windows Installer Software Development Kit (SDK) Tools

The Windows Installer SDK is essential for .msi file developers. It includes the following:

• Windows Installer documentation (msi.chm)

• Database validation tool

• Orca.exe, a database table editor

• Database tools created by using VBScript

• Sample databases

• Code samples, include and library files

Table 30 lists some of the tools that you can find in the Windows Installer SDK under the Tools directory. Help on these tools can be found in the MsiTool.hlp file.

Table 30 Windows Installer SDK Tools

Windows Installer SDK Tools	Descriptions
Orca.exe	Allows you to open a Windows Installer database as a database and examine or make changes to it, for example with Notepad.
MSIFiler.exe	Informs custom.doc to update the files around it.
WiFilVer.vbs	Updates the file table sizes and version from source file tree. This is much like MSIFiler.exe.
MSITran.exe	Generates or applies a transform file and can be used to view the transform file. Compares two databases (such as ms.db and custom.db) and generates the transform file.
MSIZap.exe	Allows you to get Windows Installer back to a clean state. This support tool helps Windows Installer maintain the configuration data about all applications.
WiDiffDB.vbs	Lists the differences between two databases (CSCRIPT only).
WiFeatur.vbs	Lists features and their composition in an installation software database.
WiGenXfm.vbs	Generates a transform from two databases, or compares them.
WiLstPrd.vbs	Lists products, product properties, features, and components installed on a computer.
WiPolicy.vbs	Manages installation software Group Policy settings (alternative to set policy).
WiUseXfm.vbs	Applies a transform to an .msi database.

For more information about the Microsoft Platform SDK or to download a free copy, see the Microsoft Platform SDK link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources/.

You do not need to buy external toolkits to develop an .msi file or build Windows Installer packages because the required tools are available in the Windows Installer SDK. However, using an administration tool can simplify your job and shorten development time for Windows Installer packages. Microsoft has been working with InstallShield Software Corporation and Wise Solutions, Inc. to develop these types of toolkits.

Microsoft Authoring Tools

Microsoft provides package-authoring tools that developers can use to create Windows Installer installation packages. These tools include Microsoft Visual Studio Installer (VSI) and Microsoft Visual Studio .NET.

Note: Most authoring tools for Windows Installer provide debugging tools, which can help you understand and troubleshoot an installation problem. For more information abut authoring tools, see the setup documentation of the specific authoring tool.

Microsoft Visual Studio Installer (VSI)

Visual Studio Installer (VSI) 1.1 is a Microsoft tool that allows you to create Windows Installer installation packages. It is available free of charge to registered users of Microsoft Visual Studio 6.0. It seamlessly integrates into the Visual Studio shell, and automatically handles file dependencies in a manner similar to the Visual Basic (VB) Package and Deployment wizard. VSI does not support custom installation dialogs, custom user interfaces, or the running of custom scripts and applications after Windows Installer completes the installation (such as displaying readme.txt file or starting a Web browser for registration.) For these tasks you need a more powerful authoring tool such as InstallShield Professional Windows Installer Edition, or Wise for Windows Installer.

Visual Studio Installer Version 1.1 includes the following features:

• Support for side-by-side resource installation. Allows you to install multiple versions of a DLL that now only your application can use. Previously, these DLLs were shared resources only. Therefore, isolating DLLs in this way ensures a more robust application. Additionally, applications that require different versions of the same shared DLL resource can be installed on the same computer. Setups created with Visual Studio Installer 1.1 create a local file resource in the same directory as the application you are installing along with the isolated versions of the DLLs.

• Updated Merge Modules. Match the updated resource files of Visual Studio 6.0 Service Pack 5 that can be redistributed. VSI 1.0 is still available for download for users who want to use the Merge Modules that match Service Pack 3. For information about downloading the Merge Modules, see the Microsoft Visual Studio Installer link from the Web Resources Page at https://www.microsoft.com/windows/reskits/webresources/.

• Support for Windows Me. Visual Studio Installer 1.1 and setups created by Visual Studio 1.0 or by Visual Studio 1.1 run on the Windows Millennium Edition operating system.

Microsoft Visual Studio .NET

Like Microsoft Visual Studio Installer (VSI) 1.1, Microsoft Visual Studio .NET allows you to create Windows Installer installation packages. Visual Studio .NET contains the next generation of the VSI toolset, including features that are not available in Visual Studio Installer 1.1, such as the ability to author custom actions and install .NET assemblies.

Visual Studio .NET provides updated Merge Modules to match the updated redistributable resource files of Visual Studio .NET, including one for the .NET Framework.

Microsoft Visual Studio .NET runs only on the Windows 2000 and Windows XP Professional operating systems; however, you can run setups that you create by using Visual Studio .NET on Windows Me.

For more information about Microsoft Visual Studio .NET, see the Microsoft Visual Studio .NET link from the Web Resources Page at https://www.microsoft.com/windows/reskits/webresources/.

Other Authoring Tools

Many manufacturers provide package-authoring tools that developers can use to author, reauthor, or repackage applications. Some non-Microsoft authoring tools follow:

• InstallShield Professional -Windows Installer Edition by InstallShield Software Corporation

• InstallShield Express 3 by InstallShield Software Corporation

• InstallShield Tuner for Windows Installer by InstallShield Software Corporation

• Wise for Windows Installer by WISE Solutions, Inc.

InstallShield

InstallShield Software Corporation creates products that distribute and manage digital content by using packaged applications, enterprise networks, and the Internet. The products in this section are targeted to Windows Installer package developers.

InstallShield Professional - Windows Installer Edition

• InstallShield Professional Windows Installer Edition helps developers create setup packages that are compliant with Windows XP Professional, Windows 2000 Professional, Windows NT 4, Windows Me, Windows 98, and Windows 95. The Professional Edition is no longer bundled with the InstallShield Professional - Standard Edition. InstallShield Professional – Windows Installer Edition includes many features such as:

  • Repackaging capabilities

  • An .msi file debugger

  • Source code control integration

  • A visual dialog editor

  • An automation interface

  • Release management tools to create multiple releases from a single project, such as evaluation, standard, and advanced.

For more information about InstallShield Professional - Windows Installer Edition, or to download a free evaluation copy, see the "InstallShield Professional - Windows Installer" link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources/.

InstallShield Express 3

InstallShield Express 3 lets developers create installations for Windows Installer. No scripting experience is necessary, and users can use it without instruction. It is targeted to users who have uncomplicated installation needs. Like InstallShield Professional – Windows Installer Edition, it produces Windows Installer (.msi) files. In addition to a checklist, drag-and-drop interface, and the traditional Express features, InstallShield Express 3 features include:

• Support for many technologies such as the Visual Basic run-time engine, by the use of over 40 built-in merge modules.

• Three file-dependency scanners: the Visual Basic project scanner, a static-file scanner, and an active-dependency scanner. The active-dependency manager is a new feature that identifies all the files the application calls by running the application and then allowing developers to select files they might want to add to the project from a list.

• PackageForTheWeb, a tool to compress and digitally sign applications for Web distribution.

• The dialog text editor, which enables developers to modify dialog text to meet specific user interface requirements.

• Dynamic file linking, which automatically includes files at build time based on predefined paths and wildcard characters.

• An upgrade path to InstallShield Professional - Windows Installer Edition, enabling developers to meet more advanced requirements.

For more information about InstallShield Express 3, see the InstallShield Professional - Windows Installer link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources/.

InstallShield Tuner for Windows Installer

InstallShield Tuner for Windows Installer allows administrators to take any Windows Installer setup package from an Internet service vendor (ISV) or internal developer and customize it before deployment. InstallShield Tuner for Windows Installer performs the same function as the Office 2000 Custom Installation wizard for all Windows Installer applications, which enables you to specify the features, registry entries, and shortcuts to be installed on all users' systems. This process avoids the time-consuming, error-prone steps typically associated with repackaging. This is especially important now that repackaging has can break future patches and is considered an inappropriate action for applications that are already in the Windows Installer format.

InstallShield Tuner for Windows Installer features facilitate common tasks such as:

• Performing prevalidation on the Windows Installer package to ensure internal validation before customization.

• Determining how features are installed and limiting the features that can be installed.

• Adding files to the installation package.

• Creating or modifying shortcuts in the installation package.

• Adding or modifying registry keys.

• Setting values of properties defined in the installation package as being necessary.

• Performing validation of the customized package.

For more information about the InstallShield line of products, see the InstallShield for Windows Installer link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources/

Wise for Windows Installer 3.0

Wise for Windows Installer lets you create Windows Installer packages, merge modules, transforms, software patches, and project files. You can perform these functions by using the Debugger for Windows Installer; a Macro Editor to help you streamline setup tasks; and a Setup Editor that lets you edit all standard and custom Windows Installer tables for complete control over your installations.

Wise for Windows Installer Professional includes:

• Installation Expert. Provides a graphical user interface for creating Windows Installer packages.

• Setup Editor. Provides the advanced tools needed to fully customize an installation, including advanced table validation for the Windows Installer database.

• Debugger for Windows Installer. Allows you to step through an entire installation to isolate and resolve problems.

• InstallTailor. Creates a transform quickly and easily by simulating an installation and capturing the selections made during the installation.

• Windows 2000 Verification wizard. Checks an installation for Windows 2000 compliance.

For more information about the Wise for Windows Installer 3.0 products, see the Wise for Windows Installer link on the Web Resources page at https://www.microsoft.com/windows/reskits/webresources/.

Top Issues Related to Installing Software

The following explanations include some of the top issues and resolutions related to installing software by using Windows Installer.

Modifying the Source Causes Error 1706

• Identifying a problem by its symptoms. When you attempt to access a Windows Installer package (.msi) for an installed application, you might receive a "1706. No valid source could be found for [product name]" error message.

• Determining possible causes. The error message appears if the original installation source is uncompressed, and the current source is compressed or vice versa. For example, if an administrator performs an administrative installation by using a package that has a word count summary property of 2 or 3, users who initially installed the application from the administrative image cannot reinstall it from the original media source.

• Performing diagnostic tests to confirm a problem and apply a solution. This behavior is by design.

A setup can stall if MsiInstallProduct is called from a service.

• Identifying a problem by its symptoms. When you install an application by using the MsiInstallProduct function from a service, such as the client agent of a software distribution tool, that is developed to use the Windows Installer setup engine, the application might not install and the setup program might stall. This occurs when you launch the setup program from a service that is configured to run under the system account, and the system account is not set to interact with the desktop.

• Determining possible causes. This issue is the result of an attempt to use the Windows Installer setup engine in any of the following user interface modes:

  • Full

  • Basic

  • Reduced

These modes are unsupported by a service that has not been set to interact with the desktop because Windows does not allow the graphical user interface (GUI) to be presented in this context.

• Performing diagnostic tests to confirm a problem and apply the solution. This behavior is by design. However, if you need to install programs that must use the GUI during setup, set the service options for the System account to Allow Service to Interact with Desktop. This setting works if a user is currently logged on to the computer, and the computer is not locked.

If you do not need a GUI during the setup, install the application in quiet mode by passing the /q flag to the Msiexec.exe file, or by first calling the MsiSetInternalUI() function with the INSTALLUILEVEL_NONE flag.

Assigning or Publishing Applications in Active Directory Can Result in an Error

• Identifying problem by its symptoms. Using a Microsoft Windows Installer-based installation program when you assign or publish an application to the Windows 2000 Server or Windows Server 2003 Active Directory, you might receive the following error message: "The size of this object exceeds the maximum size set by the Administrator."

• Determining possible causes. This error is due to a size limitation in the database code that is used in the Windows 2000 Active Directory. This is currently a limitation that is usually exposed by repackaged installation programs.

• Performing diagnostic tests to confirm a problem and apply the solution. When you attempt to distribute multiple applications in a single installation package, this error might occur. Distributing each application separately is likely to resolve this issue. There is no registry key or Windows 2000 Server or Windows Server 2003 Active Directory setting that you can use to increase the size for the record limit.

An Attempt to Run a Windows Installer Package Fails

• Identifying a problem by its symptoms. Symptoms of this behavior are that Windows Installer installs successfully, however, an attempt to run a single Windows Installer package or several different Windows Installer packages, result in failure.

  Important: If the engine does not install correctly, you cannot run an .msi file.

• Determining possible causes. The registration of the engine is corrupted.

• Performing diagnostic tests to confirm a problem and apply the solution. If you cannot run several Windows Installer packages successfully, the registration of the engine is corrupted. Therefore, you must correct the registration of Windows Installer, by unregistering and reregistering the Windows Installer service. This action shuts down and reregisters the service, which assures that the Windows Installer engine functions properly. To unregister and reregister the Windows Installer service, run the following commands from the following command prompts:

  "msiexec /unregister" (without the quotation marks)

  "msiexec /regserver" (without the quotation marks)

• If correctly registering the engine does not resolve the problem, you can remove the engine files and do a clean reinstallation. For procedures to perform this, see Windows Server 2003 Help. If you cannot run a single Windows Installer package successfully, contact the vendor of that package for support on that particular product's installation.

Determining the Differences Between Two Windows Installer Packages

You can determine the differences between two Windows Installer packages by creating a transform (.mst) file. A transform file provides a method for recording changes to a package without having to make alterations to the original packages. After you create the transform file, you can display its contents to determine the differences.

Appendix A: An Annotated Windows Installer Log File

This sample log file represents an installation of the application DrawServer. Throughout the log file, captions provide information about the entries. However to conserve paper, several lines of the log file do not appear in the printed version, which is approximately 44 pages.

To print the entire log file in Word

1. On the Tools menu, click Options, Print tab, and then select Hidden Text.

The beginning portion of this log file states the process start time, build type, and version:

=== Verbose logging started: 8/23/99  13:40:31  Build type: SHIP UNICODE
1.02.0527.05
Calling process: C:\WINNT\system32\msiexec.exe ===

The following section of the log file reveals the command line passed to msiexec.exe.

MSI (c) (B4:98): Resetting cached policy values
MSI (c) (B4:98): ******* RunEngine:
******* Product: drawserver.msi
******* Action:
******* CommandLine:

The following section of the log file shows that Windows Installer searches the computer for installed products.

MSI (c) (B4:98): No info for thread 598
MSI (c) (B4:98): Searching for item Products\(NULL) in per-user managed key
MSI (c) (B4:98): Found item Products\(NULL)
MSI (c) (B4:98): Setting info for thread 598, in index 0
MSI (c) (B4:98): Searching for item Products
\04001F95680E2D11E8D80001B4B269CC
in per-user managed key
MSI (c) (B4:98): Found item Products
\04001F95680E2D11E8D80001B4B269CC
MSI (c) (B4:98): Getting info for thread 598, from index 0
MSI (c) (B4:98): Searching for item Products\(NULL) in per-user managed key
MSI (c) (B4:98): Found item Products\(NULL)
MSI (c) (B4:98): Setting info for thread 598, in existing index 0
MSI (c) (B4:98): Cloaking enabled.
MSI (c) (B4:98): End dialog not enabled
MSI (c) (B4:98): Original package ==> \\server\share\drawserver.msi

Windows Installer caches the original package locally in the TEMP directory.

MSI (c) (B4:98): Package we're running from ==>
C:\DOCUME~1\leslief\LOCALS~1\Temp\1470d1fd.msi
MSI (c) (B4:98): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user managed key
MSI (c) (B4:98): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user non-managed key
MSI (c) (B4:98): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-machine key
MSI (c) (B4:98): Did not find item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
MSI (c) (B4:98): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user managed key
MSI (c) (B4:98): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user non-managed key
MSI (c) (B4:98): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-machine key
MSI (c) (B4:98): Did not find item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
MSI (c) (B4:98): Machine policy value 'TransformsSecure' is 0
MSI (c) (B4:98): User policy value 'TransformsAtSource' is 0
MSI (c) (B4:98): Transforms are not secure.
MSI (c) (B4:98): Product Code passed to Engine.Initialize:

The following section of the log file shows that a transform changes the product code.

MSI (c) (B4:98): Product Code from property table before transforms:
'{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}'
MSI (c) (B4:98): Product Code from property table after transforms:
'{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}'

The following section of this log provides information about how this package runs and whether it is assigned or published. If neither assigned nor published, the user run the product by using user privileges.

MSI (c) (B4:98): Note: 1: 2262 2: AdminProperties 3: -2147287038
MSI (c) (B4:98): Machine policy value 'DisableMsi' is 0
MSI (c) (B4:98): Machine policy value 'AlwaysInstallElevated' is 0
MSI (c) (B4:98): User policy value 'AlwaysInstallElevated' is 0
MSI (c) (B4:98): Running product
 '{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}' with user privileges:
  It's not assigned.
MSI (c) (B4:98): TRANSFORMS property is now:
MSI (c) (B4:98): SHELL32::SHGetFolderPath returned: C:\Documents and
Settings\leslief\Application Data
MSI (c) (B4:98): SHELL32::SHGetFolderPath returned: C:\Documents and
Settings\leslief\Favorites
MSI (c) (B4:98): SHELL32::SHGetFolderPath returned: C:\Documents and
Settings\leslief\NetHood
MSI (c) (B4:98): SHELL32::SHGetFolderPath returned: C:\Documents and
Settings\leslief\My Documents
MSI (c) (B4:98): SHELL32::SHGetFolderPath returned: C:\WINNT\Fonts

The following section of this log file tells whether rollback is disabled by the user or by computer policy.

=== Logging started: 8/23/99  13:40:32 ===
MSI (c) (B4:98): Machine policy value 'DisableRollback' is 0
MSI (c) (B4:98): User policy value 'DisableRollback' is 0

The following section of this log file reveals the action Windows Installer performs. In this example, Windows Installer executes the INSTALL action (the INSTALL sequence tables).

MSI (c) (B4:98): Doing action: INSTALL
Action start 13:40:32: INSTALL.
MSI (c) (B4:98): UI Sequence table 'InstallUISequence' is present and populated.
MSI (c) (B4:98): Running UISequence
MSI (c) (B4:98): Doing action: LaunchConditions

The client performs each action in the UISequence. The log file reflects the action performed and its return value.

The note in the following section of log file indicates error 2262 occurred, indicating that a table can not be found. Additionally, each action provides a return value. A return value of "1" indicates success; "2" indicates the user cancelled; "3" indicates an unrecoverable error;"4" indicates a suspended installation. You can see when each action starts and ends, and what happens during the action. Typically, on the client computer, most start and end lines are hidden.

Action start 13:40:32: LaunchConditions.
MSI (c) (B4:98): Note: 1: 2262 2: LaunchCondition 3: -2147287038
Action ended 13:40:32: LaunchConditions. Return value 1.
MSI (c) (B4:98): Doing action: SetupInitialization
Action start 13:40:32: SetupInitialization.

The following section of the log file is not a true internal error, but it is an internal message. The error number 2898 indicates that the user interface handler created the Tahoma8 style, using the Tahoma font and the 1 character set. In the debug version, the error strings in the log also appear with text.

Internal Error 2898. Tahoma8, Tahoma, 1
Internal Error 2898. VerdanaBold14, Verdana, 1

The following section of the log file shows that Windows Installer is creating the User Interface dialogs.

Action 13:40:32: SetupInitialization. Dialog created

The actions in the following section have false conditions, which prevent them from occurring.

Action ended 13:40:32: SetupInitialization. Return value 1.
MSI (c) (B4:98): Skipping action: AppSearch (condition is false)
MSI (c) (B4:98): Skipping action: CCPSearch (condition is false)
MSI (c) (B4:98): Skipping action: RMCCPSearch (condition is false)
MSI (c) (B4:98): Doing action: ValidateProductID
Action 13:40:32: InstallWelcome. Dialog created

In the following section, error 2826 indicates that an item extends beyond the bounds of the given dialog, or License Agreement. This is a minor error, but it is useful to catch anything you do not see that you expect to see.

Internal Error 2826. LicenseAgreement, DlgLine, to the right
Internal Error 2898. MSSansBold8, Tahoma, 1
Action 13:40:33: LicenseAgreement. Dialog created
Internal Error 2826. CustomerInformation, DlgLine, to the right
Internal Error 2898. Tahoma8__UL, Tahoma, 0
Action 13:40:35: CustomerInformation. Dialog created
Internal Error 2826. SetupType, DlgLine, to the right
Action 13:40:37: SetupType. Dialog created
Internal Error 2826. ReadyToInstall, DlgLine, to the right
Action 13:40:38: ReadyToInstall. Dialog created
Action ended 13:40:39: InstallWelcome. Return value 1.
MSI (c) (B4:98): Skipping action: SetupResume (condition is false)
MSI (c) (B4:98): Skipping action: MaintenanceWelcome (condition is false)
MSI (c) (B4:98): Doing action: SetupProgress
Action start 13:40:39: SetupProgress.
MSI (c) (B4:98): Note: 1: 2262 2: CustomAction 3: -2147287038
Internal Error 2826. SetupProgress, DlgLine, to the right
Action 13:40:39: SetupProgress. Dialog created
Action ended 13:40:39: SetupProgress. Return value 1.

For the installation to take place, you must switch from the client side to the server.

MSI (c) (B4:98): Doing action: ExecuteAction
Action start 13:40:39: ExecuteAction.

The execution mutex is taken to ensure only one install happens at a time. The following shows Windows Installer switching to the server and pass all the safe properties to it.

MSI (c) (B4:98): Grabbed execution mutex.
MSI (c) (B4:98): Switching to server: TARGETDIR="C:\" SOURCEDIR=
"C:\Documents and
Settings\leslief\My Documents\Setup 101\Labs\DrawServer\" INSTALLDIR=
"C:\Program
Files\Microsoft MSTE\DrawServer\" COMPANYNAME="Microsoft"
 USERNAME="Leslie Franks" CURRENT
DIRECTORY="C:\Documents and Settings\leslief\My Documents\Setup 1
01\Labs\DrawServer"
CLIENTUILEVEL="0" CLIENTPROCESSID="948"
ACTION="I
NSTALL" EXECUTEACTION="INSTALL"
ROOTDRIVE="C:\" SECONDSEQUENCE="1"
ALLUSERS="1"
ADDLOCAL=DefaultProgram,ExtraShapes,Star,Rectangle

The server restarts with the original package because the package is initially cached to the client accessible TEMP directory, an unsecured location, and therefore could have been modified.

MSI (s) (D8:F0): Resetting cached policy values
MSI (s) (D8:F0): ******* RunEngine:
 ******* Product: \\server\share\drawserver.msi

The properties passed from the client to the server form part of the command line for the server.

******* Action: INSTALL
******* CommandLine: TARGETDIR="C:\" SOURCEDIR="
C:\Documents and
Settings\leslief\My
Documents\Setup 101\Labs\DrawServer\" INSTALLDIR="
C:\Program Files\Microsoft
MSTE\DrawServer\"
COMPANYNAME="Microsoft" USERNAME="Leslie Franks"
CURRENTDIRECTORY="C:\Documents and
Settings\leslief\My Documents\Setup 101\Labs\DrawServer"
CLIENTUILEVEL="0"
CLIENTPROCESSID="948" ACTION="INSTALL"
EXECUTEACTION="INSTALL" ROOTDRIVE="C:\"
SECONDSEQUENCE="1" ALLUSERS="1"
 ADDLOCAL=DefaultProgram,ExtraShapes,Star,Rectangle
MSI (s) (D8:F0): No info for thread F0
MSI (s) (D8:F0): End dialog not enabled
MSI (s) (D8:F0): Original package ==> \\server\share\drawserver.msi

Windows Installer caches the package to its own directory, which is a secure location with restricted access in the computer.

MSI (s) (D8:F0): Package we're running from ==>
C:\WINNT\Installer\699e1c.msi
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user managed key
MSI (s) (D8:F0): Searching for item Products\
7CFE0E592B8AF3647A420BCB5141AAF0
in per-user non-managed key
MSI (s) (D8:F0): Searching for item Products\
7CFE0E592B8AF3647A420BCB5141AAF0
in per-machine key
MSI (s) (D8:F0): Did not find item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user managed key
MSI (s) (D8:F0): Searching for item Products\
7CFE0E592B8AF3647A420BCB5141AAF0
in per-user non-managed key
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-machine key
MSI (s) (D8:F0): Did not find item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
MSI (s) (D8:F0): Machine policy value 'TransformsSecure' is 0
MSI (s) (D8:F0): User policy value 'TransformsAtSource' is 0
MSI (s) (D8:F0): Transforms are not secure.
MSI (s) (D8:F0): Product Code passed to Engine.Initialize:           ''
MSI (s) (D8:F0): Product Code from property table before transforms: '
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}'
MSI (s) (D8:F0): Product Code from property table after transforms:  '
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}'
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0 I
n per-user managed key
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user non-managed key
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-machine key
MSI (s) (D8:F0): Did not find item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user managed key
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user non-managed key
MSI (s) (D8:F0): Searching for item Products\
7CFE0E592B8AF3647A420BCB5141AAF0
n per-machine key
MSI (s) (D8:F0): Did not find item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
MSI (s) (D8:F0): Note: 1: 2262 2: AdminProperties 3: -2147287038
MSI (s) (D8:F0): Machine policy value 'DisableMsi' is 0
MSI (s) (D8:F0): Machine policy value 'AlwaysInstallElevated' is 0
MSI (s) (D8:F0): User policy value 'AlwaysInstallElevated' is 0

The following section of the log file shows that on the server side, the user running the installation is an administrator and has chosen to install the product per-computer instead of per-user. Thus, the installation will run with elevated privileges. Information like is critical for understanding why certain events occur on one computer and not another.

MSI (s) (D8:F0): Product installation will be elevated because user is
admin and product
is being installed per-machine.
MSI (s) (D8:F0): Running product '
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}'
with elevated
privileges: Product is assigned.
MSI (s) (D8:F0): Engine has iefSecondSequence set to true.
MSI (s) (D8:F0): TRANSFORMS property is now:
MSI (s) (D8:F0): SHELL32::SHGetFolderPath returned:
C:\Documents and
Settings\leslief\Application Data
MSI (s) (D8:F0): SHELL32::SHGetFolderPath returned:
C:\Documents and
Settings\leslief\Favorites
MSI (s) (D8:F0): SHELL32::SHGetFolderPath returned:
C:\Documents and
Settings\leslief\NetHood
MSI (s) (D8:F0): SHELL32::SHGetFolderPath returned:
C:\Documents and
Settings\leslief\My Documents
MSI (s) (D8:F0): Machine policy value 'DisableRollback' is 0
MSI (s) (D8:F0): User policy value 'DisableRollback' is 0
MSI (s) (D8:F0): Doing action: INSTALL
Action start 13:40:40: INSTALL.
MSI (s) (D8:F0): Running ExecuteSequence
MSI (s) (D8:F0): Doing action: LaunchConditions
Action start 13:40:40: LaunchConditions.
MSI (s) (D8:F0): Note: 1: 2262 2: LaunchCondition 3: -2147287038
Action ended 13:40:40: LaunchConditions. Return value 1.
MSI (s) (D8:F0): Skipping action: AppSearch (condition is false)
MSI (s) (D8:F0): Skipping action: CCPSearch (condition is false)
MSI (s) (D8:F0): Skipping action: RMCCPSearch (condition is false)
MSI (s) (D8:F0): Doing action: ValidateProductID
MSI (s) (D8:F0): Doing action: SetODBCFolders
MSI (s) (D8:F0): Doing action: InstallValidate
Action start 13:40:40: InstallValidate.

Verbose logging provides a lot of information about each feature and what happens to it. The following shows features, the current state of each, what the requested state is, and what will happen to it. Following that is a similar list on the component level. This information is very helpful in understanding why a component does not do what you expect.

MSI (s) (D8:F0): Feature: DefaultProgram; Installed: Absent;
   Request: Local;   Action: Local
MSI (s) (D8:F0): Feature: ExtraShapes; Installed: Absent;
   Request: Local;   Action: Local
MSI (s) (D8:F0): Feature: Star; Installed: Absent;
  Request: Local;   Action: Local
MSI (s) (D8:F0): Feature: Rectangle; Installed: Absent;
   Request: Local;   Action: Local
MSI (s) (D8:F0): Component: Global_Default_Executables;
Installed: Absent;   Request: Local;   Action: Local
MSI (s) (D8:F0): Component: Star_DLL; Installed: Absent;
 Request: Local;   Action: Local
MSI (s) (D8:F0): Component: Rectangle_DLL; Installed: Absent;
  Request: Local;   Action: Local
MSI (s) (D8:F0): Component: __Global_Default_Executables65;
Installed: Null;   Request: Local;   Action: Local
MSI (s) (D8:F0): Note: 1: 2262 2: BindImage 3: -2147287038

Several tables do not exist, so the actions associated with them do not execute. These tables are hidden in the printed version of this log file.

MSI (s) (D8:F0): Note: 1: 2262 2: ProgId 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: PublishComponent 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: SelfReg 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: Extension 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: Font 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: Class 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: RemoveFile 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: RemoveFile 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2205 2:  3: _RemoveFilePath
MSI (s) (D8:F0): Note: 1: 2262 2: IniFile 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: MoveFile 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: DuplicateFile 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: ReserveCost 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: BindImage 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: ProgId 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: PublishComponent 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: SelfReg 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: Extension 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: Font 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2262 2: Class 3: -2147287038
MSI (s) (D8:F0): Note: 1: 2205 2:  3: #_PatchCache
MSI (s) (D8:F0): Note: 1: 2228 2:  3: #_PatchCache 4: SELECT
`TempCopy` FROM `#_PatchCache` ORDER BY `Sequence`
MSI (s) (D8:F0): Note: 1: 2727 2:
MSI (s) (D8:F0): Note: 1: 2727 2:
Action ended 13:40:40: InstallValidate. Return value 1.
MSI (s) (D8:F0): Doing action: InstallInitialize
Action start 13:40:40: InstallInitialize.
MSI (s) (D8:F0): BeginTransaction: Locking Server
MSI (s) (D8:F0): Server not locked: locking for product
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-user managed key
MSI (s) (D8:F0): Searching for item Products\
7CFE0E592B8AF3647A420BCB5141AAF0
in per-user non-managed key
MSI (s) (D8:F0): Searching for item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
in per-machine key
MSI (s) (D8:F0): Did not find item Products
\7CFE0E592B8AF3647A420BCB5141AAF0
MSI (s) (D8:F0): Searching for item Products\
7CFE0E592B8AF3647A420BCB5141AAF0
in per-user managed key
MSI (s) (D8:F0): Searching for item Products\
7CFE0E592B8AF3647A420BCB5141AAF0
in per-user non-managed key
MSI (s) (D8:F0): Searching for item Products\
7CFE0E592B8AF3647A420BCB5141AAF0 I
n per-machine key
MSI (s) (D8:F0): Did not find item Products\
7CFE0E592B8AF3647A420BCB5141AAF0

Several actions run but do not execute any changes. Each starts and ends, returning a "1". In the printed version of this log output the "Action start" and "Action end" are hidden unless something is changed.

Action ended 13:40:40: InstallInitialize. Return value 1.
MSI (s) (D8:F0): Doing action: AllocateRegistrySpace
Action start 13:40:40: AllocateRegistrySpace.
Action ended 13:40:40: AllocateRegistrySpace. Return value 1.
MSI (s) (D8:F0): Doing action: ProcessComponents
Action start 13:40:40: ProcessComponents.
Action 13:40:40: GenerateScript. Generating script operations for action:
GenerateScript: Updating component registration
Action ended 13:40:40: ProcessComponents. Return value 1.
MSI (s) (D8:F0): Doing action: UnpublishComponents
MSI (s) (D8:F0): Doing action: UnpublishFeatures
MSI (s) (D8:F0): Doing action: StopServices
MSI (s) (D8:F0): Doing action: DeleteServices
MSI (s) (D8:F0): Doing action: UnregisterComPlus
MSI (s) (D8:F0): Doing action: SelfUnregModules
MSI (s) (D8:F0): Doing action: UnregisterTypeLibraries
MSI (s) (D8:F0): Doing action: RemoveODBC
Action start 13:40:40: RemoveODBC.
GenerateScript: Removing ODBC components
Action ended 13:40:40: RemoveODBC. Return value 1.
MSI (s) (D8:F0): Doing action: UnregisterFonts
MSI (s) (D8:F0): Doing action: RemoveRegistryValues
MSI (s) (D8:F0): Doing action: UnregisterClassInfo
MSI (s) (D8:F0): Doing action: UnregisterExtensionInfo
MSI (s) (D8:F0): Doing action: UnregisterProgIdInfo
MSI (s) (D8:F0): Doing action: UnregisterMIMEInfo
MSI (s) (D8:F0): Doing action: RemoveIniValues
MSI (s) (D8:F0): Doing action: RemoveShortcuts
MSI (s) (D8:F0): Doing action: RemoveEnvironmentStrings
MSI (s) (D8:F0): Doing action: RemoveDuplicateFiles
MSI (s) (D8:F0): Doing action: RemoveFiles
MSI (s) (D8:F0): Doing action: RemoveFolders
MSI (s) (D8:F0): Doing action: CreateFolders
MSI (s) (D8:F0): Doing action: MoveFiles
MSI (s) (D8:F0): Doing action: InstallFiles
Action start 13:40:41: InstallFiles.
GenerateScript: Copying new files
MSI (s) (D8:F0): Determining source type
MSI (s) (D8:F0): Resolving source.
MSI (s) (D8:F0): Resolving source to launched-from source.
MSI (s) (D8:F0): Setting launched-from source as last-used.
MSI (s) (D8:F0): SOURCEDIR ==> C:\Documents and
Settings\leslief\My Documents\Setup 101\Labs\DrawServer\MSI (s) (D8:F0):
SOURCEDIR product ==>
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}
MSI (s) (D8:F0): Note: 1: 2706 2: SourceDir
MSI (s) (D8:F0): Source type from package '\\server\share\drawserver.msi': 0
Action ended 13:40:41: InstallFiles. Return value 1.
MSI (s) (D8:F0): Doing action: DuplicateFiles
MSI (s) (D8:F0): Doing action: PatchFiles
MSI (s) (D8:F0): Doing action: BindImage
MSI (s) (D8:F0): Doing action: CreateShortcuts
MSI (s) (D8:F0): Doing action: RegisterClassInfo
MSI (s) (D8:F0): Doing action: RegisterExtensionInfo
MSI (s) (D8:F0): Doing action: RegisterProgIdInfo
MSI (s) (D8:F0): Doing action: RegisterMIMEInfo
MSI (s) (D8:F0): Doing action: WriteRegistryValues
MSI (s) (D8:F0): Doing action: WriteIniValues
MSI (s) (D8:F0): Doing action: WriteEnvironmentStrings
MSI (s) (D8:F0): Doing action: InstallODBC
MSI (s) (D8:F0): Doing action: RegisterTypeLibraries
MSI (s) (D8:F0): Doing action: RegisterComPlus
MSI (s) (D8:F0): Doing action: InstallServices
MSI (s) (D8:F0): Doing action: StartServices
MSI (s) (D8:F0): Doing action: SelfRegModules
MSI (s) (D8:F0): Doing action: RegisterUser
Action start 13:40:41: RegisterUser.
GenerateScript: Registering user
Action ended 13:40:41: RegisterUser. Return value 1.
MSI (s) (D8:F0): Doing action: RegisterProduct
Action start 13:40:41: RegisterProduct.
GenerateScript: Registering product
MSI (s) (D8:F0): Note: 1: 2706 2: SourceDir
MSI (s) (D8:F0): Note: 1: 2205 2:  3: #_PatchCache
MSI (s) (D8:F0): Note: 1: 2228 2:  3: #_PatchCache 4: SELECT
`TempCopy` FROM `#_PatchCache` ORDER BY `Sequence`
Action ended 13:40:41: RegisterProduct. Return value 1.
MSI (s) (D8:F0): Doing action: PublishComponents
MSI (s) (D8:F0): Doing action: PublishFeatures
Action start 13:40:41: PublishFeatures.
GenerateScript: Publishing product features
Action ended 13:40:41: PublishFeatures. Return value 1.
MSI (s) (D8:F0): Doing action: PublishProduct
Action start 13:40:41: PublishProduct.
GenerateScript: Publishing product information
MSI (s) (D8:F0): Note: 1: 2205 2:  3: #_PatchCache
MSI (s) (D8:F0): Note: 1: 2228 2:  3: #_PatchCache 4: SELECT `PatchId`,
`PackageName`,
`SourceList`, `TransformList`, `TempCopy`, `Existing`, `Unregister`,
`SourcePath` FROM
`#_PatchCache` ORDER BY `Sequence`
MSI (s) (D8:F0): Note: 1: 2706 2: SourceDir
Action ended 13:40:41: PublishProduct. Return value 1.

The following section of this log file shows the script running.

When a single operation in the script is executed, a line states, "Executing op.".

MSI (s) (D8:F0): Doing action: InstallFinalize
Action start 13:40:41: InstallFinalize.
MSI (s) (D8:F0): Running Script: C:\WINNT\Installer\MSI1AC.tmp
MSI (s) (D8:F0): Machine policy value 'DisableRollback' is 0
MSI (s) (D8:F0): Note: 1: 1402 2:
Software\Microsoft\Windows\CurrentVersion\Installer\Rollback\Scripts 3: 2
MSI (s) (D8:F0): Executing op:
Header(Signature=1397708873,
Version=102,Timestamp=655846677,LangId=1033,
,ScriptType=1,ScriptMajorVersion=21,ScriptMinorVersion=3)
MSI (s) (D8:F0): Executing op: ProductInfo(ProductKey=
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F},ProductName=DrawServer,
PackageName=drawserver.msi,
Language=1033,Version=16777216,Assignment=1,ObsoleteArg=0,)
MSI (s) (D8:F0): Executing op:
DialogInfo(Type=0,Argument=1033)
MSI (s) (D8:F0): Executing op: DialogInfo(Type=1,Argument=DrawServer)
MSI (s) (D8:F0): Executing op:
RollbackInfo(,RollbackAction=Rollback,RollbackDescription=Rolling back
action:,RollbackTemplate=,
CleanupAction=RollbackCleanup,
CleanupDescription=Removing backup files,CleanupTemplate=File: )
MSI (s) (D8:F0): Executing op: ActionStart(Name=ProcessComponents,
Description=Updating component registration,)
Action 13:40:41: ProcessComponents. Updating component registration
MSI (s) (D8:F0): Executing op: ProgressTotal(Total=3,Type=1,
ByteEquivalent=24000)
MSI (s) (D8:F0): Executing op:
ComponentRegister(ComponentId=
{4E701AC0-6936-49E5-B616-7006873E3E39},
KeyPath=C:\Program Files\Microsoft
MSTE\DrawServer\DrawServer.exe,State=3,,Disk=1,SharedDllRefCount=0)
1: {95E0EFC7-A8B2-463F-A724-B0BC1514AA0F} 2:
{4E701AC0-6936-49E5-B616-7006873E3E39} 3: C:\Program Files\Microsoft
MSTE\DrawServer\DrawServer.exe
MSI (s) (D8:F0): Executing op: ComponentRegister
(ComponentId={34E15DE0-30DB-44DF-B795-22F7F865D5E1},KeyPath=
C:\Program Files\Microsoft
MSTE\DrawServer\star.dll,State=3,,Disk=1,SharedDllRefCount=0)
1: {95E0EFC7-A8B2-463F-A724-B0BC1514AA0F} 2:
{34E15DE0-30DB-44DF-B795-22F7F865D5E1} 3:
C:\Program Files\Microsoft
MSTE\DrawServer\star.dll
MSI (s) (D8:F0): Executing op: ComponentRegister
(ComponentId={43DBBCFD-4DC5-4111-8C25-E702DBE04B78},
KeyPath=C:\Program Files\Microsoft
MSTE\DrawServer\rect.dll,State=3,,Disk=1,SharedDllRefCount=0)
1: {95E0EFC7-A8B2-463F-A724-B0BC1514AA0F} 2:
{43DBBCFD-4DC5-4111-8C25-E702DBE04B78}
3: C:\Program Files\Microsoft MSTE\DrawServer\rect.dll
MSI (s) (D8:F0): Executing op: ActionStart(Name=RemoveODBC,
Description=Removing
ODBC components,)
Action 13:40:41: RemoveODBC. Removing ODBC components
MSI (s) (D8:F0): Executing op: ODBCDriverManager()
MSI (s) (D8:F0): Executing op: ActionStart(Name=InstallFiles,
Description=Copying
new files,Template=File: ,  Directory: ,  Size: )
Action 13:40:41: InstallFiles. Copying new files
MSI (s) (D8:F0): Executing op: ProgressTotal(Total=586081,
Type=0,ByteEquivalent=1)
MSI (s) (D8:F0): Executing op: SetTargetFolder
(Folder=C:\Program Files\Microsoft MSTE\DrawServer\)
MSI (s) (D8:F0): Executing op: SetSourceFolder
(Folder=C:\Documents and Settings\leslief\
My Documents\Setup 101\Labs\DrawServer\program
files\Microsoft MSTE\DrawServer\)
MSI (s) (D8:F0): Executing op:
ChangeMedia(MediaVolumeLabel=Disk1,MediaPrompt=Please
insert the disk: 1,,BytesPerTick=32768,CopierType=0,,)
MSI (s) (D8:F0): Executing op:
FileCopy(SourceName=DrawServer.exe,
DestName=DrawServer.exe,Attributes=8192,FileSize=180336
,Version=1.0.0.1,Language=1033,
InstallMode=58982400,PerTick=32768,IsCompressed=0,
,VerifyMedia=1,,)

The script generated by Windows Installer is performing the operations needed to install a file. First it sets the target and source folders. Then it sets the appropriate media. Finally, the copy operation takes place. The following section explains why the file is being copied. It is useful to know when a file is not being copied as you expect. In this example, no file exists.

MSI (s) (D8:F0):
 File: C:\Program Files\Microsoft MSTE\DrawServer\DrawServer.exe;
To be installed;  No existing file
InstallFiles: File: DrawServer.exe,  Directory: C:\Program Files\Microsoft
MSTE\DrawServer\,  Size: 180336
MSI (s) (D8:F0): Note: 1: 2318 2: C:\Program Files\Microsoft
MSTE\DrawServer\DrawServer.exe
MSI (s) (D8:F0): Executing op:
FileCopy(SourceName=star.dll,DestName=star.dll,
Attributes=8192,FileSize=204911,Version=1.0
.0.1,Language=1033,InstallMode=58982400,
PerTick=32768,IsCompressed=0,,VerifyMedia=1,,)
MSI (s) (D8:F0):
File: C:\Program Files\Microsoft MSTE\DrawServer\star.dll;
To be installed;  No existing file
InstallFiles: File: star.dll,  Directory:
 C:\Program Files\Microsoft MSTE\DrawServer\,
Size: 204911
MSI (s) (D8:F0): Note: 1: 2318 2:
 C:\Program Files\Microsoft MSTE\DrawServer\star.dll
MSI (s) (D8:F0): Executing op:
FileCopy(SourceName=rect.dll,DestName=rect.dll,
Attributes=8192,FileSize=200834,,,
InstallMode=58982400,PerTick=32768,IsCompressed=0,,VerifyMedia=1,,)
MSI (s) (D8:F0): File:
C:\Program Files\Microsoft MSTE\DrawServer\rect.dll;
To be installed;  No existing file
InstallFiles: File: rect.dll,  Directory:
C:\Program Files\Microsoft MSTE\DrawServer\,  Size: 200834
MSI (s) (D8:F0): Note: 1: 2318 2:
 C:\Program Files\Microsoft MSTE\DrawServer\rect.dll
MSI (s) (D8:F0): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (s) (D8:F0): Executing op:
 ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 13:40:41: CreateShortcuts. Creating shortcuts
MSI (s) (D8:F0): Executing op: SetTargetFolder(Folder=23)
MSI (s) (D8:F0): SHELL32::SHGetFolderPath returned:
C:\Documents and Settings\All Users\Start Menu\Programs
MSI (s) (D8:F0): Executing op:
 ShortcutCreate(Name=Draw Server Test,Feature=DefaultProgram,
 Component={4E701AC0-6936-49E5-B616-7006873E3E39}
CreateShortcuts: Shortcut: Draw Server Test
MSI (s) (D8:F0): Executing op: SetTargetFolder(Folder=23)
MSI (s) (D8:F0): SHELL32::SHGetFolderPath returned:
C:\Documents and Settings\All
Users\Start Menu\Programs
MSI (s) (D8:F0): Executing op:
ActionStart(Name=RegisterUser,Description=Registering
user,Template=)
Action 13:40:42: RegisterUser. Registering user
MSI (s) (D8:F0): Executing op: UserRegister(Owner=Leslie
Franks,Company=Microsoft,ProductId=None)
RegisterUser: {95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}
MSI (s) (D8:F0): Executing op:
ActionStart(Name=RegisterProduct,Description=Registering
product,Template=)
Action 13:40:42: RegisterProduct. Registering product
MSI (s) (D8:F0): Executing op:
ChangeMedia(MediaVolumeLabel=Disk1,MediaPrompt=Please
insert the disk: 1,,BytesPerTick=0,CopierType=0,,)
MSI (s) (D8:F0): Executing op:
DatabaseCopy(DatabasePath=C:\WINNT\Installer\699e1c.msi,
ProductCode={95E0EFC7-A8B2-463F-
A724-B0BC1514AA0F},,,)
MSI (s) (D8:F0): Note: 1: 1402 2:
Software\Microsoft\Windows\CurrentVersion
\Installer\LocalPackages\7CFE0E592B8AF3647A420BCB
5141AAF0 3: 2
MSI (s) (D8:F0): Executing op:
ProductRegister(,VersionString=1.0.0.0000,
HelpLink=https://www.yourcompany.com,
HelpTelephone=555-555-1234,,InstallSource=
C:\Documents and Settings\leslief\My
Documents\Setup 101\Labs\DrawServer\,Publisher=Microsoft MSTE,URLI
nfoAbout=https://www.yourcompany.com,
URLUpdateInfo=https://www.yourcompany.com,,,NoRepair=1,
,,,,,,EstimatedSize=588)
RegisterProduct: {95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}
MSI (s) (D8:F0): Executing op: ProductCPDisplayInfoRegister()
MSI (s) (D8:F0): Executing op:
 ActionStart(Name=PublishFeatures,Description=Publishing
product features,Template=Feature: )
Action 13:40:42: PublishFeatures.
Publishing product features
MSI (s) (D8:F0): Executing op:
FeaturePublish(Feature=DefaultProgram,,
Absent=2,Component=m.p5ALaih?lFs(%f_nI6)
PublishFeatures: Feature: DefaultProgram
MSI (s) (D8:F0): Executing op:
FeaturePublish(Feature=ExtraShapes,
Parent=DefaultProgram,Absent=2,)
PublishFeatures: Feature: ExtraShapes
MSI (s) (D8:F0): Executing op:
FeaturePublish(Feature=Star,
Parent=ExtraShapes,Absent=2,Component=~h^~4XeR.=6uNLx=UTYq)
PublishFeatures: Feature: Star
MSI (s) (D8:F0): Executing op:
FeaturePublish(Feature=Rectangle,Parent=ExtraShapes,
Absent=2,Component=W@nm94qXv8osAx!S~FaN)
PublishFeatures: Feature: Rectangle
MSI (s) (D8:F0): Executing op:
ActionStart(Name=PublishProduct,Description=Publishing
product information,)
Action 13:40:42: PublishProduct. Publishing product information
MSI (s) (D8:F0): Executing op:
 IconCreate(Icon=A7F5384E.exe,Data=Binary4E.e)
1: A7F5384E.exe
MSI (s) (D8:F0): Executing op: ProductPublish(PackageKey=
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F})
1: {95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}
MSI (s) (D8:F0): Executing op:
SourceListPublish(,,DiskPromptTemplate=,,NumberOfDisks=1)
MSI (s) (D8:F0): Executing op: ProductPublishClient(,,)
MSI (s) (D8:F0): Executing op: SourceListRegisterLastUsed(SourceProduct=
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F},LastUsedSource=
C:\Documents and Settings\leslief\My Documents\Setup 101\Labs\DrawServer\)
MSI (s) (D8:F0): Entering CMsiConfigurationManager::SetLastUsedSource.
MSI (s) (D8:F0): Specifed source is already in a list.
MSI (s) (D8:F0): User policy value 'SearchOrder' is 'nmu'
MSI (s) (D8:F0): Machine policy value 'DisableBrowse' is 0
MSI (s) (D8:F0): Machine policy value 'AllowLockdownBrowse' is 0
MSI (s) (D8:F0): Adding new sources is allowed.
MSI (s) (D8:F0): Set LastUsedSource to:
C:\Documents and Settings\leslief\My Documents\Setup 101\Labs\DrawServer\.
MSI (s) (D8:F0): Set LastUsedType to: n.
MSI (s) (D8:F0): Set LastUsedIndex to: 1.
MSI (s) (D8:F0): Executing op: End(Checksum=0,ProgressTotal=658081)
MSI (s) (D8:F0): FEATURECACHE: Entering Invalidate
MSI (s) (D8:F0): User policy value 'DisableRollback' is 0
MSI (s) (D8:F0): Machine policy value 'DisableRollback' is 0
Action 13:40:42: RollbackCleanup. Removing backup files
MSI (s) (D8:F0): Unlocking Server
Action ended 13:40:43: InstallFinalize. Return value 1.
Action ended 13:40:43: INSTALL. Return value 1.

The following section of the log file shows the merging of all of the properties from the server to the installing application, and later the client.

Property(S): DiskPrompt = [1]
Property(S): TARGETDIR = C:\Property(S):
AppDataFolder = C:\Documents and
Settings\leslief\Application Data\Property(S):
CommonFilesFolder = C:\Program Files\Common Files\Property(S):
DesktopFolder = C:\Documents and Settings
\All Users\Desktop\Property(S):
FontsFolder = C:\WINNT\Fonts\Property(S):
ProgramFilesFolder = C:\Program Files\Property(S):
ProgramMenuFolder = C:\Documents and Settings
\All Users\Start Menu\Programs\Property(S):
RecentFolder = C:\Documents and Settings\leslief\Recent\Property(S):
SendToFolder = C:\Documents and Settings\leslief\SendTo\Property(S):
StartMenuFolder = C:\Documents and Settings
\All Users\Start Menu\Property(S):
StartupFolder = C:\Documents and Settings\
All Users\Start Menu\Programs\Startup\Property(S):
System16Folder = C:\WINNT\System\Property(S):
SystemFolder = C:\WINNT\System32\Property(S): T
empFolder = C:\DOCUME~1\leslief\LOCALS~1\Temp\Property(S):
TemplateFolder = C:\Documents and Settings\leslief\Templates\Property(S):
WindowsFolder = C:\WINNT\Property(S):
SOURCEDIR = C:\Documents and Settings\leslief\My Documents\Setup
101\Labs\DrawServer\Property(S): ProductName = DrawServer
Property(S): DialogCaption = DrawServer
Property(S): ProductVersion = 1.0.0.0000
Property(S): ProductID = None
Property(S): INSTALLDIR =
C:\Program Files\Microsoft MSTE\DrawServer\Property(S):
 VersionNT = 500
Property(S): Dir20 =
C:\Program Files\Microsoft MSTE\Property(S): VersionDatabase = 100
Property(S): CURRENTDIRECTORY =
C:\Documents and Settings\leslief\My Documents\Setup
101\Labs\DrawServer
Property(S): ACTION = INSTALL
Property(S): EXECUTEACTION = INSTALL
Property(S): ROOTDRIVE = C:\Property(S): SECONDSEQUENCE = 1
Property(S): ADDLOCAL = DefaultProgram,ExtraShapes,Star,Rectangle
Property(S): VersionMsi = 1.02
Property(S): WindowsBuild = 2072
Property(S): ServicePackLevel = 0
Property(S): ServicePackLevelMinor = 0
Property(S): WindowsVolume =
C:\Property(S): DATABASE = C:\WINNT\Installer\699e1c.msi
Property(S): OriginalDatabase = \\server\share\drawserver.msi
Property(S): UILevel = 5
Property(S): SourceDir =
C:\Documents and Settings\leslief\My Documents\Setup
101\Labs\DrawServer\Property(S): SourcedirProduct =
{95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}
Property(S): ProductToBeRegistered = 1
MSI (s) (D8:F0): MainEngineThread is returning 0
MSI (c) (B4:98): Back from server. Return value: 0
Action ended 13:40:43: ExecuteAction. Return value 1.
MSI (c) (B4:98): Doing action: SetupCompleteSuccess
Action start 13:40:43: SetupCompleteSuccess.
MSI (c) (B4:98): Note: 1: 2262 2: CustomAction 3: -2147287038
Action 13:40:43: SetupCompleteSuccess. Dialog created
Action ended 13:40:45: SetupCompleteSuccess. Return value 2.
Action ended 13:40:45: INSTALL. Return value 1.
Property(C): System16Folder = C:\WINNT\System\Property(C):
SystemFolder = C:\WINNT\System32\Property(C):
TempFolder = C:\DOCUME~1\leslief\LOCALS~1\Temp\Property(C):
TemplateFolder = C:\Documents and Settings\leslief\Templates\Property(C):
 WindowsFolder = C:\WINNT\Property(C):
 SOURCEDIR = C:\Documents and Settings\leslief\My Documents\Setup
101\Labs\DrawServer\Property(C):
 ProductName = DrawServer
Property(C): DialogCaption = DrawServer
Property(C): ProductVersion = 1.0.0.0000
Property(C): ProductID = None
Property(C): INSTALLDIR =
C:\Program Files\Microsoft MSTE\DrawServer\Property(C):
VersionNT = 500
Several client properties are hidden to keep the page count down.
Property(C): Dir20 = C:\Program Files\Microsoft MSTE\Property(C):
 NewFolder = NewFolder-NOTUSED
Property(C): DefaultUIFont = Tahoma8
Property(C): AgreeToLicense = Yes
Property(C): ProgressType0 = install
Property(C): _IsSetupTypeMin = Typical
Property(C): _IsMaintenance = Change
Property(C): ARPHELPLINK = https://www.yourcompany.com
Property(C): ARPHELPTELEPHONE = 555-555-1234
Property(C): DiskSerial = 1234-5678
Property(C): Display_IsBitmapDlg = 1
Property(C): ErrorDialog = SetupError
Property(C): InstallChoice = AR
Property(C): INSTALLLEVEL = 100
Property(C): Manufacturer = Microsoft MSTE
Property(C): PIDTemplate =
12345<###-%%%%%%%>@@@@@
Property(C): RebootYesNo = Yes
Property(C): Registraton = No
Property(C): ReinstallFileVersion = o
Property(C): ReinstallRepair = r
Property(C): SetupType = Typical
Property(C): ApplicationUsers = AllUsers
Property(C): ProgressType1 = Installing
Property(C): ProgressType2 = installed
Property(C): ProgressType3 = installs
Property(C): ReinstallModeText = ro
Property(C): ARPNOREPAIR = 0
Property(C): ARPURLINFOABOUT = https://www.yourcompany.com
Property(C): ARPURLUPDATEINFO = https://www.yourcompany.com
Property(C): ProductCode = {95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}
Property(C): ProductLanguage = 1033
Property(C): COMPANYNAME = Microsoft
Property(C): USERNAME = Leslie Franks
Property(C): PackageCode = {95E0EFC7-A8B2-463F-A724-B0BC1514AA0F}
Property(C): ProductState = -1
Property(C): PackagecodeChanging = 1
Property(C): CURRENTDIRECTORY =
C:\Documents and Settings\leslief\My Documents\Setup
101\Labs\DrawServer
Property(C): CLIENTUILEVEL = 0
Property(C): CLIENTPROCESSID = 948
Property(C): VersionDatabase = 100
Property(C): VersionMsi = 1.02
Property(C): WindowsBuild = 2072
Property(C): ServicePackLevel = 0
Property(C): ServicePackLevelMinor = 0
Property(C): WindowsVolume = C:\Property(C): GPTSupport = 1
Property(C): OLEAdvtSupport = 1
Property(C): ShellAdvtSupport = 1
Property(C): Intel = 6
Property(C): PhysicalMemory = 128
Property(C): VirtualMemory = 181
Property(C): MemoryBytes = 133746688
Property(C): TotalPageFile = 304
Property(C): TotalVirtualMB = 2047
Property(C): AdminUser = 1
Property(C): LogonUser = leslief
Property(C): UserSID = S-1-5-21-2127521184-
1604012920-1887927527-2733
Property(C): UserLanguageID = 1033
Property(C): ComputerName = leslief2
Property(C): SystemLanguageID = 1033
Property(C): ScreenX = 1024
Property(C): ScreenY = 768
Property(C): CaptionHeight = 19
Property(C): BorderTop = 1
Property(C): BorderSide = 1
Property(C): TextHeight = 16
Property(C): ColorBits = 16
Property(C): TTCSupport = 1
Property(C): Time = 13:40:45
Property(C): Date = 8/23/99
Property(C): AvailablePageFile = 183
Property(C): AvailablePhysical = 45
Property(C): AvailableVirtual = 2013
Property(C): TotalPhysical = 128
Property(C): TotalVirtual = 2048
Property(C): Privileged = 1
Property(C): DATABASE = C:\DOCUME~1\leslief\LOCALS~1\
Temp\1470d1fd.msi
Property(C): OriginalDatabase = \\server\share\drawserver.msi
Property(C): SourceDir = C:\Documents and Settings\leslief\
My Documents\Setup
101\Labs\DrawServer\Property(C): VersionHandler = 1.02
Property(C): UILevel = 5
Property(C): ACTION = INSTALL
Property(C): EXECUTEACTION = INSTALL
Property(C): ROOTDRIVE = C:\Property(C): CostingComplete = 1
Property(C): OutOfDiskSpace = 0
Property(C): OutOfNoRbDiskSpace = 0
Property(C): PrimaryVolumeSpaceAvailable = 0
Property(C): PrimaryVolumeSpaceRequired = 0
Property(C): PrimaryVolumeSpaceRemaining = 0
Property(C): ALLUSERS = 1

The installation is complete, and the logging stops. The following final segment lets you see if the operation was successful or not.

=== Logging stopped: 8/23/99  13:40:45 ===
MSI (c) (B4:98): Product: DrawServer -- Installation operation
completed successfully.
MSI (c) (B4:98): MainEngineThread is returning 0
=== Verbose logging stopped: 8/23/99  13:40:45 ===

Related Links

• The following table lists Windows Installer-associated topics and the locations where you can find more information about them.

Topics	Point Your Browser to:
Windows Installer Software Developer's Kit (SDK) - Online	https://www.microsoft.com/msdownload/platformsdk/sdkupdate/
Windows Installer Software Developer's Kit (SDK) - Download	https://www.microsoft.com/msdownload/platformsdk/sdkupdate/
Windows Installer Support Web Site	https://support.microsoft.com/support/default.asp?SD=SO&PR=wininst
Windows 2000 Change and Configuration Management (CCM) Deployment Guide	https://www.microsoft.com/windows2000/techinfo/reskit/deploy/CCM/default.asp
Introduction to Windows 2000 Group Policy-based Software Deployment	https://www.microsoft.com/technet/prodtechnol/windows2000serv/maintain/featusability/inmnwp.mspx
Step-by-Step Guide to Software Installation and Maintenance:	https://www.microsoft.com/windows2000/techinfo/planning/management/swinstall.aspx
InstallShield for Windows Installer by InstallShield Software Corporation	https://www.installshield.com
Microsoft Visual Studio .NET	https://msdn.microsoft.com/vstudio/default.aspx
Wise for Windows Installer by WISE Solutions, Inc.	https://www.wisesolutions.com
Systems Management Server (SMS)	https://www.microsoft.com/smserver/default.mspx
Installsite (Resources for Setup Developer):	https://www.installsite.org/
SWYNK.COM (Resources for Systems Management Server):	https://www.swynk.com/sms/

Acknowledgements

Brian Granowitz, Program Manager, Microsoft Corporation

Joy Miller, Technical Writer, Microsoft Corporation