Deploying Windows Installer Setup Packages with Systems Management Server 2.0

  • Article
Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Microsoft® Windows® Installer is an installation technology that streamlines the application installation process and offers continued resiliency for applications, including the ability to install additional features on demand, automatically repair applications, uninstall applications cleanly, and roll back applications reliably. When you use Microsoft Systems Management Server 2.0 (SMS) to deploy Windows Installer setup packages, you gain additional change and configuration benefits.

On This Page

Introduction
General Deployment Scenarios
Advanced Deployment Scenarios
SMS 2.0 Software Deployment Overview
General Deployment Scenarios
Advanced Deployment Scenarios
Appendix: Automating Uninstall Options
For More Information

Introduction

Microsoft® Windows® Installer is an installation technology that streamlines the application installation process and offers continued resiliency for applications, including the ability to install additional features on demand, automatically repair applications, uninstall applications cleanly, and roll back applications reliably. When you use Microsoft Systems Management Server 2.0 (SMS) to deploy Windows Installer setup packages, you gain additional change and configuration benefits, including the following:

  • Software distribution to target users and computers that are dynamically evaluated based on a set of administrator-defined rules.

  • Hardware and software inventory to verify that target computers meet setup requirements. You can also audit hardware and software throughout your organization on an ongoing basis.

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

  • Diagnostic and troubleshooting tools to track and repair performance problems on target computers and throughout your network.

This technical paper explains how to use Systems Management Server 2.0 to deploy Windows Installer setup packages (.msi) throughout your organization. This paper first lists supported operating systems that you can install Windows Installer setup packages on. This paper then highlights general changes to the SMS 2.0 software distribution process that you must make when distributing Windows Installer setup packages. Finally, this technical paper walks you through specific deployment scenarios. These scenarios are divided into the following general and advanced deployment scenarios:

General Deployment Scenarios

  • Preparing client computers by installing Windows Installer.

  • Setting up the Package Source Directory.

  • Configuring general program changes for Windows Installer setup packages.

  • Deploying setup packages per user.

  • Deploying setup packages per system.

  • Configuring the user interface level (attended installations and unattended installations).

  • Deploying setup packages for installation on demand.

  • Generating install status MIF files.

Advanced Deployment Scenarios

  • Configuring resilient sources (multiple sources for installation and repair).

  • Working with program dependencies.

  • Configuring system restarts.

  • Automating program removal.

  • Validating platform requirements.

  • Simulating a Windows 2000 Publish.

  • Upgrading Windows Installer setup packages.

Note: The configuration requirements for many of the deployment scenarios outlined in this paper are interrelated. When reviewing required configuration settings for one scenario, be sure to consider the configuration options for related scenarios. For example, if you are configuring automated program removal, be sure to coordinate the settings depending on whether you are deploying packages per user or per system and whether you are configuring an attended or unattended installation.

Prerequisites

To use the instructions in this paper, you must be using SMS 2.0 with Service Pack 1 or a later service pack. You must also be familiar with the SMS 2.0 software distribution process. You can find more information about this topic in the following resources:

  • Microsoft Systems Management Server Administrator's Guide

  • Microsoft Systems Management Server 2.0 Administrator Help

  • Microsoft Systems Management Server Resource Guide

You should also have access to Windows Installer Help (MSI.chm). Although this paper discusses key Windows Installer features that are used to deploy setup packages using SMS, Windows Installer Help includes complete instructions on how to use Windows Installer. Rather than duplicating that content, this paper will refer you to specific topics in Windows Installer Help, where applicable.

When referring to Windows Installer features, it is important to note a difference in terminology between Windows Installer and SMS 2.0. For example, Windows Installer has a feature called advertising, which takes advantage of the ability to install applications on demand. This means that rather than installing the application itself on a computer, only the instructions for installing the application are installed, together with shortcuts to the application on the Start menu and on the desktop. When a user selects one of the shortcuts, then the application is installed on demand.

Note: The previous concept of advertising is very different from the advertisement concept used in SMS 2.0. To prevent confusion, the Windows Installer concept of advertising, also called install on demand, will be called install on demand in this technical paper.

Finally, do not use the instructions in this technical paper to deploy Microsoft Office 2000. Instead, see the white paper Instructions for Installing Microsoft Office 2000 with SMS 2.0 (O2kSMS20) at https://www.microsoft.com/office/ork/2000/journ/SMSWhitepaper.htm. For related papers about deploying SMS with Microsoft Office, see:

https://www.microsoft.com/office/ork/2000/appndx/toolbox.htm

Supported Operating Systems

Although SMS 2.0 supports a variety of client operating systems, Windows Installer setup packages can be installed only on the following operating systems:

  • Windows 95

  • Windows 98

  • Windows NT® 4.0

  • Windows 2000

Windows Installer setup packages cannot be installed on computers running 16-bit operating systems, including the following operating systems that are supported by Systems Management Server 2.0:

  • Windows NT 3.51

  • Windows 3.x

SMS 2.0 Software Deployment Overview

This section presents an overview of the SMS 2.0 software distribution process and highlights the changes that are necessary when deploying Windows Installer (.msi) setup packages.

After configuring your site for software distribution, typically you perform the following steps with SMS 2.0 for each software deployment package:

  • Set up a package source directory.

  • Create a package.

  • Create a program for the package.

  • Specify distribution points for the package.

  • Specify access accounts for the package (optional).

  • Create an advertisement.

You must perform these same processes when you distribute Windows Installer setup packages. However, when you set up the package source directory, you must perform a Windows Installer administrative installation of the source files. You must also pay special attention to the configuration options available when you create the program for the Windows Installer setup package because this is where you specify the Windows Installer command line and configure other options necessary for deploying Windows Installer setup packages. If you want to generate status reports, you must also modify package properties when you create the package.

In addition to performing an administrative installation of the source files and modifying configuration options during the standard SMS 2.0 software distribution process, you must plan your strategy for using resilient sources, if you choose. Resilient sources are administrative installation points that are available to the clients throughout the life of the applications. Windows Installer requires users to retain access to the source files throughout the life of the applications, so that advanced features, such as application repair and install on demand, can work.

If you choose to use resilient sources, which are optional, client computers will use those sources whenever the original distribution point becomes unavailable. Using resilient sources, in addition to distribution points, is a good way to build in fault tolerance. However, it adds an additional step to the SMS 2.0 software distribution process. For more information, see "Configuring Resilient Sources" later in this paper.

Finally, before you deploy Windows Installer setup packages, you must make sure that Windows Installer is installed on target computers. Windows Installer is included with Windows 2000. To learn how to install Windows Installer on computers running Windows 95, Windows 98, and Windows NT 4.0, see "Preparing Client Computers by Installing Windows Installer" later in this paper.

In summary, the following list itemizes the software distribution tasks for deploying Windows Installer setup packages using SMS 2.0:

  • Verify that Windows Installer runtime is installed on all target computers.

  • Set up a package source directory using Windows Installer's administrative installation.

  • Create a package.

  • Configure resilient resources (optional).

  • Create a program for the package, using Windows Installer command-line syntax.

  • Specify distribution points for the package.

  • Specify access accounts for the package (optional).

  • Create an advertisement.

General Deployment Scenarios

This section presents detailed instructions for the following common deployment scenarios:

  • Preparing client computers by installing Windows Installer.

  • Setting up the Package Source Directory.

  • Configuring general program changes for Windows Installer setup packages.

  • Deploying packages per user.

  • Deploying packages per system.

  • Configuring the user interface level (attended installations versus unattended installations).

  • Deploying setup packages for installation on demand.

  • Generating install status MIF files.

It is important to note that configuration options for deploying attended and unattended installations and for deploying setup packages for installation on demand must be coordinated with the configuration options for deploying packages per user and per system. Therefore, if you plan to configure the user interface level or to deploy setup packages for installation on demand, be sure to review the configuration options for deploying packages per user and per system.

Preparing Client Computers by Installing Windows Installer

Before you can install Windows Installer setup packages on an SMS client computer, the client computer must first have the Windows Installer installation service installed. Windows 2000 comes with Windows Installer already installed. To install Windows Installer on computers running Windows NT 4.0, Windows 98, or Windows 95, use the Windows Installer setup program (InstMSI.exe). You can download a copy of this setup program from the following Web location: https://www.microsoft.com/msdownload/platformsdk/instmsi.htm

You will be prompted to select the setup file for installing Windows Installer on Windows 95 and Windows 98 or the setup file for installing Windows Installer on Windows NT 4.0. Note that there are two different setup programs, even though these have the same file name. You can also use this setup program to update older versions of Windows Installer.

Note: If you are deploying SMS Installer-generated setup packages that have been migrated to the Windows Installer format by using the Installer Step-up Utility (ISU) for Microsoft Systems Management Server, verify that the correct version of Windows Installer is installed. ISU-migrated setup packages will not work properly with older versions of Windows Installer, such as the version that is included in the original version of Office 2000. Computers running Windows 95, Windows 98, and Windows NT 4.0 must have version 1.1 or later installed.

You can install the Windows Installer service on client computers prior to deploying Windows Installer setup packages. Or, you can create a program dependency when deploying a Windows Installer setup package so that the Windows Installer service itself is installed before the Windows Installer setup package is run. For more information about using a program dependency to install Windows Installer, see "Working with Program Dependencies" later in this paper.

You can use the SMS 2.0 software distribution process to deploy the Windows Installer setup package (InstMSI.exe). Because this setup package is a traditional executable setup package (.exe), you do not need to worry about Windows Installer program changes. However, installing Windows Installer requires administrative rights on the client computer. The Windows Installer setup package (InstMSI.exe) also supports the /q command-line option, which runs the setup program silently (without user input).

In addition to the software distribution options you would usually configure, be sure to use the following options when distributing the Windows Installer setup package (InstMSI.exe).

To install Windows Installer with SMS 2.0:

  1. Open the Program Properties dialog box for the package.

  2. On the General tab, enter the command line with the /q option. The following is an example:

    3. 



InstMSI.exe /q



    

  1. On the Environment tab, select the following Run mode option: Run with administrative rights.
    

    2. 

  2. On the Environment tab, make sure that Drive mode is set to Runs with UNC name.
    

    3. 

  3. On the Advanced tab, set the When program is assigned box to Run once for first user who logs on.
    

    4. 



Setting up the Package Source Directory


When you use SMS 2.0 to distribute a Windows Installer setup package, you must first set up the package source directory using Windows Installer's administrative installation. An administrative installation installs a source image of the application that is similar to a source image on a CD-ROM, but that can be installed directly from a network location. An administrative installation also prepares an application so that it can be run directly from the network location.


You perform an administrative installation by using the Windows Installer /a command-line option.


    MSIEXEC /a setup.msi




An administrative installation performs all actions (such as expanding compressed files) that are required to either install or run the package directly from the network location. The package author determines the exact operations to be performed for a package during an administrative installation.


In SMS 2.0, the location where you perform the administrative installation becomes the location of the package source directory. Any additional files, such as template files or transform files, should also be copied to this location. Additionally, any future modifications to the setup package (such as upgrading the source files) should be made in this location. The results of the administrative installation plus any modification you make are propagated to the specified distribution point servers. SMS 2.0 clients can then either install the package or run the package from the distribution point server.


Performing an administrative installation is an easy way to create a package source directory, and it also ensures that you can upgrade the setup package in the future. For more information on Windows Installer's administrative installation option, see Windows Installer Help.


Configuring General Program Changes for Windows Installer Setup Packages


This section details the configuration options you must use when you create the program for your Windows Installer setup package. Program configuration options for deploying software are specified on the Program Properties dialog box.


The primary difference you will experience as you configure general program options for Windows Installer setup packages is the use of Windows Installer command-line syntax. The executable program that interprets packages and installs products is Msiexec.exe. The command line that you enter on the General tab of the Program Properties dialog box must conform to the following format:


    msiexec options package.msi




The following table lists several command-line options. The command-line options are case sensitive. For a complete list of options, together with their explanations, see Windows Installer Help.


Table 1.1 Windows Installer Command-line Options











Installation Command


Action








/I


Installs or configures a product.






/x


Uninstalls a product.






/jm


Installs the install on demand shortcuts only. These shortcuts will be available to all users of the computer.






/ju


Installs the install on demand shortcuts only. These shortcuts will be available to the current user only.







For example, use the following syntax:


msiexec /I package.msi




In addition to using the command-line options, you can also use Windows Installer properties. Properties are global variables used during an installation. Properties are not required when you deploy Windows Installer setup packages with SMS, but they can help you tailor software distribution to meet your needs. When used, properties must be specified last:


msiexec options package.msi PROPERTY=VALUE




For more information about Windows Installer properties, see Windows Installer Help.


The following steps detail the options that must be set before you can deploy Windows Installer setup packages.


To deploy Windows Installer setup packages:


    

  1. Open the Program Properties dialog box for the package.
    

    2. 

  2. On the General tab, enter the command-line using Windows Installer command-line syntax.
    

    3. 

  3. On the Environment tab, make sure that Drive mode is set to Runs with UNC name.
    

    4. 



Note: If your setup package includes platform requirements that need to be validated, see "Validating Platform Requirements" later in this paper.


Deploying Setup Packages per User


You can deploy Windows Installer setup packages on a per-user basis by using the Windows Installer ALLUSERS property. The ALLUSERS property determines where the configuration information of the installed application is stored. However, this property is only interpreted by computers running Windows NT 4.0 or Windows 2000. The ALLUSERS property is not interpreted by computers running Windows 95 and Windows 98. Instead, Windows Installer performs a per-user or per-system install based on how the Windows 95 or Windows 98 computer is configured.


To deploy a package on a per-user basis on computers running Windows NT 4.0 or Windows 2000, set the ALLUSERS property to a null value. For more information about the ALLUSERS property, see Windows Installer Help. The following is an example of the command-line syntax used to deploy Windows Installer setup packages on a per-user basis:


msiexec.exe /I package.msi ALLUSERS=""




In addition to using the ALLUSERS property, there are several other program configuration options that must be set in the Program Properties dialog box. The following steps detail all of the options that must be set in order to deploy Windows Installer setup packages on a per-user basis.


To deploy packages per user:


    

  1. Open the Program Properties dialog box for the package.
    

    2. 

  2. On the General tab, specify the command line using Windows Installer command-line options and set the ALLUSERS property to a null value.
    

    3. 

  3. On the Environment tab, set the Program can run box to Only when a user is logged on and set the Run mode box to Run with user's rights.
    

    4. 

  4. On the Advanced tab, set the When program is assigned box to Run once for every user who logs on.
    

    5. 



Note: The settings on the Environment tab force the setup package to run in the logged-on user's context.


Note: Be sure to coordinate the settings for deploying packages per user with the settings for attended or unattended installations.


Deploying Setup Packages per System


You can deploy Windows Installer setup packages on a per-system basis by setting the Windows Installer ALLUSERS property to a value of "1". The following is an example of the command-line syntax used to deploy Windows Installer setup packages on a per-system basis:


msiexec.exe /I package.msi ALLUSERS="1"




In addition to the command line, there are several other program configuration options that must be set in the Program Properties dialog box. The following steps detail all of the options that must be set in order to deploy Windows Installer setup packages on a per-system basis. Note that the settings on the Environment tab depend on whether you are deploying the package as an attended or unattended installation. For more information on deploying attended and unattended installations, see the corresponding sections in this paper.


To deploy packages per system:


    

  1. Open the Program Properties dialog box for the package.
    

    2. 

  2. On the General tab, specify the command line using Windows Installer command-line options and set the Windows Installer ALLUSERS property to a value of "1".
    

    3. 

  3. On the Environment tab, select one of the following options, depending on whether you are deploying the setup package as an attended or unattended installation:
    

    If you are deploying an attended installation, set the Program can run list box to Only when a user is logged on. Then, set the Run mode option to Run with administrative rights.
    

    If you are deploying an unattended installation, set the Program can run list box to either Whether or not a user is logged on or Only when no user is logged on.
    

    4. 

  4. On the Advanced tab, set the When program is assigned list box to Run once for first user who logs on. This field might be grayed out, depending on the options you selected on the Environment tab.
    

    5. 



Note: The settings on the Environment tab force the setup package to run under the local Administrator account supplied by SMS.


Note: Be sure to coordinate the settings for deploying packages per system with the settings for attended or unattended installations.


Configuring the User Interface Level


Windows Installer provides package developers the capability to write an internal user interface (UI) that has multiple user interface levels. You can specify which user interface level is displayed to the user by using the /q command-line option. The following table lists the /q command-line variations and the associated user interface level that is displayed to the user. For more information about using the /q command-line option and on the various user interface levels, see Windows Installer Help.


Table 1.2 User Interface Command-line Options











Installation Command


Level of User Interface displayed








/q /qn


No UI






/qb


Basic UI






/qr


Reduced UI with a modal dialog box displayed at the end of the installation






/qf


Full UI with a modal dialog box displayed at the end







Because the internal UI must be written by the package author, the exact behavior of the reduced and full interface levels depends on the specific installation package in use.


Configuring Attended Installations


You can deploy an attended installation of a Windows Installer setup package by using the following command-line options: /qb, /qr, /qf. However, do not use the following command-line options: /q, /qn. The following is an example of the command-line syntax used to deploy an attended installation of a Windows Installer setup packages:


msiexec.exe /I package.msi /qb




In addition to the command line, there are several other program configuration options that must be set in the Program Properties dialog box. The following steps detail all of the options that must be set in order to deploy an attended installation of a Windows Installer setup package.


To configure an attended installation:


    

  1. Open the Program Properties dialog box for the package.
    

    2. 

  2. On the General tab, specify the command line using Windows Installer command-line syntax with one of the following command-line options: /qb, /qr, /qf.
    

    On the Environment tab, configure the following settings:
    

      

    • Set the Program can run list box to Only when a user is logged on.
      

      • 

    • Select the User input required check box.
      

      • 

    

    3. 



Note: An attended installation can only be performed when the Program can run setting on the Environment tab is set to Only when a user is logged on.


Note: Be sure to coordinate the settings for attended installations with the settings for deploying setup packages per user or per system.


Configuring Unattended Installations


To deploy an unattended installation, use either the /q or /qn command-line option. The following is an example of the command-line syntax used to deploy an unattended installation of a Windows Installer setup package:


msiexec.exe /I package.msi /q




In addition to specifying the command line, there are several other program configuration options that must be set in the Program Properties dialog box. The following steps detail all of the options that must be set.


To configure an unattended installation:


    

  1. Open the Program Properties dialog box for the package.
    

    2. 

  2. On the General tab, specify the command line using Windows Installer command-line syntax with one of the following command-line options: /q or /qn.
    

    3. 

  3. On the Environment tab, clear the User input required check box.
    

    4. 



Note: Be sure to coordinate the settings for unattended installations with the settings for deploying setup packages per user or per system.


Deploying Setup Packages For Installation on Demand


You can deploy setup packages using the Windows Installer install on demand feature (advertisement) by using the /ju or /jm command-line options. This feature installs only the portions of the application setup necessary to allow just-in-time installation of the application when it is activated by the user. Yet, the application appears to be already installed to the user.


If you use the /ju or /jm command-line options, Windows Installer ignores any property values entered at the command line. Use /ju to advertise to the current user. Use /jm to advertise to all users of a computer. For more information about these command-line options, see Windows Installer Help.


The following is an example of the command-line syntax used to deploy an a Windows Installer setup package on demand:


msiexec.exe /jm package.msi




Enter the command line on the General tab of the Program Properties dialog box.


Note: Be sure to coordinate the settings for deploying setup packages for installation on demand with the settings for deploying setup packages per user or per system.


Generating Install Status MIF Files


Using SMS, you can generate an install status MIF file to report the status of an installation. When installing a Windows Installer setup package, you must make configuration changes in two places. First, configure the rules that SMS uses to locate install status MIF files on the Reporting tab of the Package Properties dialog box. Second, specify the command-line syntax with the /m command-line option on the General tab of the Program Properties dialog box to have Windows Installer generate an install status MIF file.


To configure reporting:


    

  1. Open the Package Properties dialog box for the package.
    

    2. 

  2. On the Reporting tab, select Use these fields for status MIF matching.
    

    3. 

  3. In the MIF file name field, enter the MIF file name that will be specified on the command line.
    

    To specify the command-line syntax:
    

    4. 

  4. Open the Program Properties dialog box for the package.
    

    5. 

  5. On the General tab, in the Command line box, enter the command-line syntax with the /m option. Do not enter a MIF filename extension.
    

    6. 



The following is an example of the command-line syntax used to generate a status MIF file:


msiexec.exe /I package.msi /m MIFfilename




Note: If you deploy a setup package for installation on demand (using the /jm or /ju command-line options), Windows Installer will not generate an install status MIF file.


When the /m command-line option is used to deploy software to an SMS 2.0 client computer (a computer with ISMIF32.dll present), Windows Installer generates an install status MIF file that includes the following summary properties that correspond to the MIF fields:


Table 1.3 Windows Installer MIF File Data











MIF Field


Windows Installer Summary Property








Manufacturer


Author (manufacturer)






Product


Revision number (package code)






Version


Subject (product name)






Locale


Template






Serial Number


Not set






Description


Blank if successful. Error message if failed.







For more information about these Windows Installer summary properties, see "Summary Information Stream Reference" in Windows Installer Help.


Note: If the Windows Installer setup package might restart the computer, see "Configuring System Restarts" later in this paper.


Advanced Deployment Scenarios


This section presents detailed instructions for the following advanced scenarios:


    

  • Configuring resilient sources (multiple sources for installation and repair).
    

    • 

  • Working with program dependencies.
    

    • 

  • Configuring system restarts.
    

    • 

  • Automating program removal.
    

    • 

  • Validating platform requirements.
    

    • 

  • Simulating a Windows 2000 publish.
    

    • 

  • Upgrading Windows Installer setup packages.
    

    • 



Configuring Resilient Sources


Resilient sources are administrative installation points that are available to clients throughout the life of an application. Windows Installer requires users to retain access to the source files so that advanced features, such as application repair and install on demand, can work. Resilient sources also build in fault tolerance.


SMS 2.0 allows multiple distribution points to be assigned to a package and provides methods for clients to select a distribution point to use during SMS operations. By default, Windows Installer records the source location used for installation (the specific SMS distribution point) as the only source location for the package. If you choose to use resilient sources, which are optional, client computers will use those sources if the original distribution point becomes unavailable.


Windows Installer maintains a local list of source locations for each application, referred to as a source list. The entries in this list can be network locations, Uniform Resource Locators (URLs), or compact discs. When post-installation access to the package files is required, the locations in the source list are tried in the order that they are listed. If one of these sources fails, Windows Installer quickly and seamlessly tries the next.


Windows Installer adds the location used for the initial installation to the source list. By default, this is the only location added to the list. There are, however, several options for adding additional resources to the source list. These options allow you to use multiple SMS 2.0 distribution points for post-installation access to the package source files in case the original distribution point is unavailable or the source files are removed.


The following options can be used to add additional resources to the source list:


    

  • Source list entries can be written directly into the package.
    

    • 

  • Source list entries can be specified on the command line by using the SOURCELIST property. The SOURCELIST property is a semicolon-delimited list of network or URL source paths to the application's installation package. This list is appended to the end of each user's existing source list for the application.
    

    • 

  • Source list entries can be added at installation time by applying a Windows Installer transform. The transform includes the SOURCELIST property value that is set with the list of source paths. You specify the transform on the command line when installing the package.
    

    • 



If you use the second method to specify additional SMS distribution points as source locations on the installation command line, note that SMS 2.0 imposes a character limit of 511 characters for the command line. If the command line with the source list exceeds this value, use a transform to specify the SOURCELIST property.


For more information about using the SOURCELIST property and about creating a transform, see Windows Installer Help.


Note: In Windows Installer 1.0, you cannot modify the source list values after installation. In Windows Installer 1.1 (the version included with Windows 2000), you can use an application programming interface (API) to modify the source list after installation.


The methods previously described for creating a source list require that you know the full list of distribution-point paths before you advertise the package. By default in SMS 2.0, the exact path in which the package is placed on the distribution point is determined dynamically when the package is run. These factors can make it challenging to manage resilient sources throughout the life of an application. There are, however, several options for overcoming these challenges:


    

  • Use Windows NT share site systems and custom package folder names to control the package location on distribution points.
    

    • 

  • Use and externally manage drive-letter connections, specifying the source list entries as drive-letter paths (for example, N:\<path>), rather than UNC paths (for example, \\<Server>\<Share>).
    

    • 

  • Use and externally manage non-distribution point systems as resilient package sources with static package locations rather than distribution point paths.
    

    • 



Although these options provide a way of providing resilient source paths, they require significant work to manage. For example, you might have to maintain multiple programs and advertisements for a package to accommodate multiple source location lists and to ensure that clients only receive source locations that are physically near them. In addition, none of these options are substitutes for being able to easily adjust the source list values that are maintained by clients for installed packages when the source locations for a package are changed.


Note: SMS 2.0 client computers do not support Windows 2000 distributed file system (Dfs). Therefore, Dfs shares cannot be used for distribution points. However, Dfs shares can be used for externally managed resilient sources that are accessed directly by Windows Installer, rather than SMS 2.0.


Because of the logistical challenge of using resilient sources, it is important that you carefully plan your strategy for using them. Ideally, planning to use a single set of distribution point locations throughout the life of an application (or adding locations over time) is the best method for avoiding problems associated with accessing source files after an application has been installed. In addition, using this method, you do not have to specify additional sources when an application is initially deployed.


For more information about resilient sources, see "Source Resiliency" in Windows Installer Help.


Working with Program Dependencies


You can configure program dependencies when deploying Windows Installer setup packages under either of the following two conditions:


    

  • If there is only one Windows Installer setup package in the dependency chain and it is the last program that will run.
    

    • 

  • If the Windows Installer setup package is not the last setup package to run but will never require a restart.
    

    • 



The reason one of these conditions must be met is because the execution order defined by the program dependency cannot be guaranteed by SMS 2.0 when a program is dependent on a Windows Installer setup package that requires a restart. This is because Windows Installer setup packages can be written to run setup tasks both before and after a required computer restart.


Because SMS 2.0 considers a program to be finished when a computer is restarted, SMS 2.0 continues to run dependent programs after the computer restarts, even if a Windows Installer setup package is not yet finished. The results of this behavior can include the following possibilities:


    

  • The dependent program might fail because it relies on the Windows Installer setup package to be completed.
    

    • 

  • If the dependent program is also a Windows Installer setup package, it will fail because the Windows Installer service will return an error message indicating that an installation is already in progress.
    

    • 

  • If the dependent program is not a Windows Installer setup package, it might finish successfully; however, it will run while the Windows Installer setup package continues its post-restart setup tasks. Although the setup packages might not fail, the computer might be left in an unknown state because the defined execution order was not strictly followed.
    

    • 



However, if one of the two conditions listed above is met, the chain of dependent programs should be completed successfully. In fact, creating a program dependency is an excellent way to guarantee that Windows Installer itself is installed before running a Windows Installer setup package.


To install Windows Installer as a program dependency:


    

  1. Create a program for installing Windows Installer. See the instructions presented in "Preparing Client Computers by Installing Windows Installer" earlier in this paper.
    

    2. 

  2. Open the Program Properties dialog box for the Windows Installer setup package that you want to deploy.
    

    3. 

  3. On the Advanced tab, select the Run another program first check box.
    

    4. 

  4. Using the Package and Program drop down lists, assign the program for installing Windows Installer.
    

    5. 



Configuring System Restarts


If the Windows Installer setup package requires or might require a restart, you must configure SMS 2.0 to perform the restart, rather than Windows Installer. This ensures that a status MIF file is generated.


Because Windows Installer determines if a computer must be restarted at installation time (depending on the options that are installed and whether any files in use are replaced), the safest option is to assume that a restart is necessary.


Configuring SMS 2.0 to perform the restart, instead of Windows Installer, involves two steps. First, suppress Windows Installer from restarting the computer by using the REBOOT property and setting it to a value of "ReallySuppress":


msiexec.exe /I package.msi REBOOT="ReallySuppress"




The ReallySuppress value suppresses reboot prompts both during the installation and at the end of the installation. For more information about using the REBOOT property, see Windows Installer Help.


The second step is to configure SMS 2.0 to restart the computer. Use the following steps to configure SMS 2.0 to perform a restart.


To configure SMS 2.0 to perform a restart:


    

  1. Open the Program Properties dialog box.
    

    2. 

  2. On the General tab, specify the command-line and set the REBOOT property to ReallySuppress.
    

    3. 

  3. On the After running menu, click SMS restarts computer.
    

    4. 



Note: If the Windows Installer setup package is deployed using the /ju or /jm command-line options (for install on demand), no restart is performed.


Automating Program Removal


By default, Windows Installer creates a registry key for automatically adding and removing applications. Unless you use the ARPNOREMOVE Windows Installer property, any application installed by Windows Installer will be registered in Add/Remove Programs in Control Panel. This allows the application to be automatically removed using the SMS 2.0 program removal feature.


To use the automatic program removal functionality with SMS 2.0, configure the following program settings in the Program Properties dialog box.


To configure SMS 2.0 to perform a restart:


    

  1. Open the Program Properties dialog box.
    

    2. 

  2. On the Advanced tab, select the Remove software when it is no longer advertised check box.
    

    3. 

  3. In the Uninstall registry key edit box, enter the package code.
    

    4. 



Note: These instructions require you to know the package code. The package code is stored as a property in the summary information of a Windows Installer package. You can determine the package code by using the MSIINFO.exe tool that is included with the Windows Installer SDK to display the properties in the summary information.


While Windows Installer automatically registers the application with Add/Remove Programs in Control Panel and creates the necessary uninstall registry entry, there are two additional options that you might want to configure. First, you might want to provide an unattended removal option. Second, you might want to configure the application to be removed on a per-user basis. Instructions for configuring these options are included in the following sections. To learn how to automate some of the steps required to configure these two options, see the Appendix, "Automating Uninstall Options."


Configuring an Unattended Removal


By default, Windows Installer creates an UninstallString in the registry that initiates the Windows Installer (Msiexec.exe) /I command-line option. This option launches a user interface that gives users the option to repair an application or remove an application. Although this supports automated program removal, you might want to configure an unattended removal.


By default, SMS 2.0 first looks for and uses a QuietUninstallString registry entry, which removes an application silently, without user input. If a QuietUninstallString registry entry is not found, SMS 2.0 falls back to the default UninstallString registry value to remove the application.


To configure an unattended removal, add the QuietUninstallString registry entry to the package by using a transform. The transform must include the following syntax:


QuietUninstallString=MSIEXEC /q /x packagecode




The QuietUninstallString must be created under the same registry key as the default uninstall string:


HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion \Uninstall \packagecode


Finally, the transform must be specified on the command line for the program. For more information about creating a transform, see Windows Installer Help.


Configuring a Per-user Removal


By default, Windows Installer uninstalls an application for all users of a computer, even when performing a per-user removal. However, while the application is removed for all users of the computer, user-specific settings (such as shortcuts) are not removed because these are stored in a user's individual profile. Therefore, users with valid shortcuts can reinstall the application the next time they invoke the program through their individual profile settings.


In addition, when Windows Installer removes an application on a per-user basis, it also removes the uninstall configuration options SMS 2.0 uses to uninstall the application. Unless subsequent users reinstall the application by using their individual profile settings, there is no way for SMS 2.0 to completely remove the application (including user-specific settings) for all users of a computer.


You can, however, use SMS 2.0 to configure the uninstall options necessary to remove an application for all users of a computer, including user-specific settings. To do so, configure a dependent program that creates an external removal key for the package. This external removal key should also provide the QuietUninstallString registry value for a silent uninstall. Because only a QuietUninstallString value is provided in the external removal key, the external removal key alone will not cause the application to be displayed in Add/Remove Programs in Control Panel.


To configure a per-user uninstall option:


    

  1. Create a file named External.reg that contains the following entry:
    

    [HKEY_LOCAL_MACHINGE \SOFTWARE \Microsoft \Windows \CurrentVersion \Uninstall \packagecode]
    

    2. 



"QuietUninstallString"="MSIEXEC/x packagecode /q"



    

  1. Create a program to merge the registry file into the client registry. Open the Program Properties dialog box for this program and configure the following options:
    

    Set the configuration options for a per-system installation (see "Deploying Setup Packages per System" earlier in this paper).
    

    Set the configuration options for an unattended installation (see "Configuring Unattended Installations" earlier in this paper).
    

    On the General tab, enter the following syntax for the command line:
    

    REGEDIT /s "EXTERNAL.reg"
    

    2. 

  2. Open the Program Properties dialog box for the Windows Installer setup package that you are deploying. On the Advanced tab, set the following options:
    

    Select the Run another program first check box and enter the Package and Program for the External.reg program.
    

    Select the Remove software when it is no longer advertised check box.
    

    In the Uninstall registry key box, enter the package code.
    

    3. 

  3. Copy the External.reg file into the source files of the Windows Installer setup package that you are deploying. If necessary, update distribution points with the new file.
    

    4. 



When the package is installed, the program dependency will cause the external removal key to be written into the registry, along with the removal information normally created by Windows Installer. When program removal is triggered, SMS 2.0 finds and executes the QuietUninstallString value for the current user, removing the package. Because the external removal key is not created as part of the package installation by Windows Installer, it will not be deleted as part of the removal, allowing program removal for subsequent users to succeed.


Validating Platform Requirements


Both Windows Installer and SMS 2.0 provide a way to validate platform requirements before installing a setup package. However, the methods that are used are different and produce slightly different results.


Using SMS 2.0, you can specify platform requirements when you create a program for the setup package. Platform requirements are set in the Program Properties dialog box on the Requirements tab. When an advertised program is received on a client computer, SMS first checks to make sure the client computer meets the requirements. If a client does not meet the requirements, the program is not run and it is not displayed to users. Instead, the client rejects the offer and sends a status message indicating that the platform requirements were not met. In this case, the user at the client computer does not see the advertisement or the status message.


Using Windows Installer, setup authors can add conditional platform requirements that are validated as part of the installation process. Platform requirements can also be added through a Windows Installer transform. In either case, if you use SMS to distribute the setup package, SMS cannot validate these platform requirements before running the program. Instead, Windows Installer validates the platform requirements as part of the setup process. If a computer does not meet the requirements, the installation fails. In this case, the client sends a status message indicating that the installation failed.


Because Windows Installer cannot validate platform requirements before running a setup package, when using SMS 2.0 to deploy Windows Installer setup packages, it is best to use SMS 2.0 to specify platform requirements. Even if the Windows Installer setup package includes conditional platform requirements that will be validated, specifying these same requirements in the SMS program properties for the setup package will help avoid failed installations. Using SMS 2.0 to specify platform requirements also helps produce consistency with other SMS software deployments.


Simulating a Windows 2000 Publish


The software installation and maintenance features in Windows 2000 provide an installation option called publish, in which the package is registered for installation by document invocation and Add/Remove Programs. However, no shortcuts are created on the user's desktop or Start menu. For more information on this Windows 2000 installation option, see Windows 2000 Server Help.


You can achieve similar results when using SMS 2.0 to deploy setup packages. However, you must create two programs for the Windows Installer setup package. First, create an assigned (mandatory) advertise-only program with a transform that disables the creation of shortcuts during the advertisement process. When this program is run on the client, it enables installation through document invocation.


Second, create an optional program that will perform a standard installation. This allows the client to install the setup package through the Advertised Programs Wizard, along with all other programs that have been made available through the Advertised Programs Wizard.


When creating these two programs, be sure to configure the per-user/per-system options the same for both programs. When the two programs are received at the client, the first program runs through its assignment and enables installation through document invocation. The second program is available to users through the Advertised Programs Wizard. The user can either install the program by double-clicking on any of the package's supported document types, or by selecting the package through the Advertised Programs Wizard.


Upgrading Windows Installer Setup Packages


Windows Installer uses several methods for updating an application. For more information on these methods, see "Patching and Upgrades" in Windows Installer Help. This section explains how to upgrade a Windows Installer application in SMS 2.0 using a Windows Installer patch file (.msp).


These instructions assume that the original package source directory was created using Windows Installer's administrative installation feature (using the /a command-line option). For information on using the administrative installation feature, see "Setting up the Package Source Directory" earlier in this paper.


To completely upgrade a Windows Installer application, you need to complete two processes. First, apply the patch file to update the original source files (version 1) with the new source files (version 2), and update the package's distribution points to propagate the new version of the source files. Any clients installing the application after you upgrade the source files and update the package's distribution points will install the upgraded application. Second, upgrade existing clients by creating a new program in the existing package. Then, send an advertisement for this new program to a collection of clients that have installed the original version of the application. The rest of this section details the tasks involved in both of these processes.


To update source files on distribution points


    

  1. Apply the Windows Installer patch file to update the existing source files (version 1) for the application with the new source files (version 2). The original source files must have been installed to the package source directory using the Windows Installer /a command-line option which performs an administrative installation. The following command line is an example of the syntax used to update version1.msi with the new source files included in version2.msp:
    

    MSIEXEC /p version2.msp /a version1.msi
    

    2. 

  2. Replicate the updated source files to the distribution points that contain the original source files. To do this, use the SMS Administrator Console: right-click the original package, point to All Tasks, and then click Update Distribution Points. This removes the original (version 1) source files and replace them with the updated (version 2) source files on all distribution points that contain a copy of the package.
    

    After you complete these two steps, any new clients receiving the original advertisement for the application will automatically install the upgraded version (version 2). After you have updated the source files with the new version, you can then complete the next process of upgrading existing clients.
    

    3. 



To upgrade existing clients


    

  1. Create a new program in the existing package to perform the upgrade. To do this, configure the following options in the Program Properties dialog box:
    

      

    • On the General tab, specify a command line that will upgrade clients to the new version. Use the following combination of repair command-line options: /fvomus. For more information on these options, see "Command-line Options" in Windows Installer Help. The command line should reference the original setup package file (version1.msi) because this file was patched with the updated source files (version 2). The following is an example of the command line:
      • 

    

    MSIEXEC /fvomus version1.msi


    2. 




  - If the original program included configuration options for any of the following deployment options, be sure that the following options match in the new (upgrade) program: deploying packages per user or per system, generating install status MIF files, configuring resilient sources, configuring system restarts, and automating program removal.



    

  1. Create a new collection that includes clients that have installed the original version (version 1) of the application.
    

    2. 

  2. Advertise the new upgrade program (version 2) to the collection containing clients that have installed the original version (version 1) of the application.
    

    3. 



As with the original deployment, per-system upgrades should be run once per system. Per-user upgrades should be run once for each user on the computer that receives the advertisement for the upgrade program.


Appendix: Automating Uninstall Options


This appendix provides sample code, MSIREMOV.vbs, for a script that can be used to automate the uninstall options that are detailed in "Configuring an Unattended Removal" and "Configuring a Per-user Removal."


The MSIREMOV.vbs script extracts the package code from a specified Windows Installer package and automatically creates a registry file (.reg) that includes the necessary registry key entries to both uninstall applications silently and uninstall applications on a per-user basis. This registry file can be deployed as a dependent program to merge the necessary registry entries into client registries.


This script replaces the instructions included under "Configuring an Unattended Removal." It also replaces step 1 under "Configuring a Per-user Removal." After using this script, you must perform steps 2-4 under "Configuring a Per-user Removal" to complete the process required for configuring an unattended removal and a per-user removal.


MSIREMOV.VBS

' MSIREMOV.VBS

' Utility to create a registry merge file containing the entries necessary

' to support SMS per-user program removals for Windows Installer packages.

' The resulting registry file can be used as a dependent program: REGEDIT /S "filename.REG"

' Copyright (c) 2000, Microsoft Corporation

Option Explicit

Const msiOpenDatabaseModeReadOnly = 0

Const msiRevision = 9

Const msiSubject = 3

Const strRegHdr = "REGEDIT4"

Const strRegKey	 = "HKEY_LOCAL_MACHINE \SOFTWARE \Microsoft \Windows \CurrentVersion \Uninstall"

Const strRemovalString1 = """QuietUninstallString""=""MSIEXEC /x "

Const strRemovalString2 = " /q"""

Const strDisplayString1 = """DisplayName""="""

Const strDisplayString2 = """"

Dim strRegEntries : strRegEntries = strRegHdr & vbNewLine & vbNewLine

Dim intArgCount   : intArgCount = Wscript.Arguments.Count

Dim strMessage, strRevision, strSubject

' Evaluate command line arguments

If intArgCount <> 2 Then

 strMessage = "MSIREMOV.VBS" & vbNewLine &_

 	 vbNewLine & " 1st argument is the path to the storage file (installer package)" &_

                vbNewLine & " 2nd argument is the path and name of the .REG file to be created"

 Wscript.Echo strMessage

 Wscript.Quit 1

End If

 

' Connect to Windows Installer object

Dim objInstaller : Set objInstaller = Nothing

Set objInstaller = Wscript.CreateObject("WindowsInstaller.Installer") 

' Open summary information of specified file

Dim objSumInfo  : Set objSumInfo = objInstaller.SummaryInformation(Wscript.Arguments(0), 0) 

' Get Revision and Subject properties 

strRevision=objSuminfo.Property(msiRevision)

strSubject=objSuminfo.Property(msiSubject)

' Build registry update strings

strRegEntries = strRegEntries & "[" & strRegKey & strRevision & "]" & vbNewLine

strRegEntries = strRegEntries & strRemovalString1 & strRevision & strRemovalString2 & vbNewLine

strRegEntries = strRegEntries & strDisplayString1 & strSubject & strDisplayString2 & vbNewLine

' Write to specified file

Dim objFSO  : Set objFSO=CreateObject("Scripting.FileSystemObject") 

Dim objFile : Set objFile=objFSO.CreateTextFile(Wscript.Arguments(1), True) 

objFile.write(strRegEntries) 

objFile.close 

' Exit, return code = 0

Wscript.Quit 0




For More Information


For more information about SMS, check out our Web site at https://www.microsoft.com/smserver/default.mspx