Upgrading Installed Applications

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

After you determine the type of software renewal method you plan to use, Group Policy simplifies the upgrade process.

Before you update the software in your organization, you must determine which of three types of software renewal methods is appropriate for your situation:

  • Small Upgrade

  • Minor Upgrade

  • Major Upgrade

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

Table 8.5   Comparing Upgrade Types

Type of Renewal Description ProductCode Property ProductVersion Property

Small update

An update to one or two .msi or application files that is too small to warrant changing the product version. The package code in the Revision Number Summary Property does change. This can be shipped as a patch package or as a full product installation package.

No change

No change

Minor upgrade

A small update that makes large enough changes to warrant changing the product version, but not the product code. By changing the product version, you prevent downgrades. You also enable package sequencing. This can be shipped as a patch package or as a full-product installation package.

No change

Change

Major upgrade

A comprehensive update of the product warranting a change in the product code. Essentially, it is a new installation; optionally, it is an application removal. This can be shipped as a patch package (.msp) or as a full product installation package (.msi); only possible by using Windows Installer version 1.1 or later.

Change

Change

Small Updates and Minor Upgrades

Small updates and minor upgrades (see Table 8.6) are essentially a reinstallation that uses a new package. Regardless of the type of software renewal you choose, the .msi package code changes to make sure that the new package is used.

Table 8.6 Comparing Small Updates with Minor Upgrades

Situation Renewal Method

A software renewal comes from the application manufacturer, and it does not include changes to the product version or product code.

A small update to the original package

A software renewal from the manufacturer changes the product version, but not the product code.

A minor upgrade to the original package

The only difference between small updates and minor upgrades is if you must differentiate between product versions.

Major Upgrades

During a major upgrade, Windows Installer searches the user’s computer for applications that are related to the pending upgrade. When it locates one, Windows Installer retrieves the version of the installed application from the registry. Windows Installer then uses information in the upgrade version’s database to determine whether to upgrade the installed application.

During a major upgrade, the installed version of an application might be removed, or might remain and coexist on the system with the newer version. This behavior, and its exposure to administrators, depends on the implementation of the application’s setup program. For example, multiple versions of an application that are installed on the same computer might prevent the version that you install from functioning properly.

If any of the following conditions and application changes applies to your organization, you must perform a major upgrade:

  • Coexisting installations of the original and updated products on the same computer

  • A change in an .msi file name

  • A change in the component code of an existing component

  • An addition or removal of a component from an existing feature

  • A change that causes an existing feature to become a child of an existing feature

  • Removal of an existing child feature from its parent feature

You do not need to change the product code when you add a new child feature that consists entirely of new components that are added to an existing feature.

To perform an update or upgrade

  1. Provide adequate notice to the users that the software will be updated or upgraded by a specified date.

  2. Obtain the Windows Installer package file.

  3. Locate the software distribution point server and share where the original package resides.

  4. Apply the update or upgrade to the original package.

  5. Inform the users that the updated software is now available.

It is important that you support both the newly installed update or upgrade and the software that you plan to retire soon. Be sure to maintain the previous distribution point until all users have upgraded. Eventually, you must remove the retired version of the software. For information about removing outdated software, see "Patching, Upgrading, and Removing Applications" later in this chapter.

Upgrading Software by Using Windows Installer and Group Policy

During a minor upgrade or a major upgrade, Windows Installer searches for upgradeable products by querying the Upgrade table of the upgrade package. The newer version of the product is installed. If Windows Installer finds an older version of the product, it removes the old version. The author of the application’s setup can choose to remove the old version, and then install the new version. The maintenance mode and removal do not trigger these actions because "remove existing versions of an application" is now automatic.

You can use the software installation extension of Group Policy to manually create upgrade relationships between the new package and the packages that the application replaces. This includes making a formal upgrade relationship between two similar products from completely different vendors. Again, you can either replace one vendor’s application with another, or you can upgrade a repackaged application. Of course, it is recommended that you pilot or test an upgrade before putting it into production.

For examples of upgrades that are deployed by using the software installation extension of Group Policy, see "Patching, Upgrading, and Removing Software Examples" later in this chapter.

For a more information about configuring upgrades, and for a procedure for upgrading applications by using the software installation extension of Group Policy, see Help and Support Center for Windows Server 2003.

If you plan to deploy repackaged applications by using the software installation extension of Group Policy, you must allow extra time for unexpected situations that require you to create upgrade relationships manually or to create a script to remove unwanted files.

Manually creating upgrade relationships

The Windows Installer package for a repackaged application does not have declared upgrade relationships. You must manually create upgrade relationships. You can configure these relationships by using the software installation extension of Group Policy.

To manually create an upgraded relationship

  1. In the Software Installation section of the Group Policy object, right-click the managed software.

  2. Click Properties.

  3. On the Upgrades tab, specify the packages that the selected package will upgrade and the packages in the current GPO that will upgrade this package.

  4. Click Add to select the packages.

Writing a script to remove files

During an upgrade, it might not be possible to completely remove a repackaged application. The removal of a repackaged application might leave components on the desktop, regardless of whether the component is shared or needed. You can create a script to remove the remaining files.