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
Provide adequate notice to the users that the software will be updated or upgraded by a specified date.
Obtain the Windows Installer package file.
Locate the software distribution point server and share where the original package resides.
Apply the update or upgrade to the original package.
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
In the Software Installation section of the Group Policy object, right-click the managed software.
Click Properties.
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.
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.