Maintaining Software Using IntelliMirror

Administrators need to be able to manage software through the entire software life cycle. IntelliMirror software installation and maintenance was designed with the following software life cycle in mind:

1. The software life cycle began when you first deployed the software. Users have learned the software and are productively using it. Because this is a steady or known state, administrators would like to stay at this state.
2. However, because of changes in business requirements or the availability of a new, improved version of the software, you have to consider deploying the new version. You evaluate the new features and deploy them to a carefully chosen group of users during a pilot deployment. During the pilot, most users will continue to use the old version.
3. Assuming that the pilot is successful, the IT staff will gradually roll out the new software to the rest of the organization. This leaves two options for the older version:
   • Force an upgrade to the new version.
   • Leave the existing version in a nonsupported state.
4. Eventually, all users will be using the new version and there are few, if any, reasons for the old application to remain in circulation. At this point you probably want to remove it from the software distribution share, back it up, and archive it in case it is ever needed in the future.

Figure 24.4 illustrates this process.

Enlarge figure

Figure 24.4 The Software Life Cycle

This life cycle involves the following software management tasks:

• Installing
• Modifying
• Upgrading
• Repairing
• Removing

So far, this discussion of IntelliMirror software installation and maintenance has focused almost exclusively on installation. The following sections address modification, upgrades, and removal.

Patching Existing Software

Software publishers often provide patches to fix a very precise problem in their applications. You need to decide whether or not your organization needs the patch.

If you decide to deploy a patch with Windows 2000, you can copy the patch files to the software distribution point and replace the older files. The software publisher that distributes the patch should supply either a new Windows Installer package (an .msi file) or a Windows Installer patch (an .msp file). With the Windows Installer package, you can simply replace the existing package. Alternatively, you can use the Windows Installer patch to update the existing package.

You then redeploy the assigned or published package with the Software Installation snap-in. This causes the patched or updated files to be copied to the computers of the users who have installed the software.

Service packs typically include a number of patches that have been tested together. Thus, service packs are distributed less frequently than patches, but more often than full upgrades.

Note

If a service pack updates only a small number of files, distribute and manage it as you would a patch. If a service pack updates a large number of files, distribute and manage it like an upgrade.

Upgrading Existing Software

There are two types of upgrades in a network environment:

• Mandatory upgrades that occur immediately. This means that everyone who has installed the existing version of the application is upgraded to the new version, and users who have never installed the software can only install the upgraded version.
• Nonmandatory upgrades that do not occur immediately. Existing users can choose whether or not to upgrade, and new users can decide for themselves which version to install.

Initially, you might want to make new upgrades available on a nonmandatory basis so that users can upgrade when they want. Eventually, you might decide that the nonmandatory upgrade should become mandatory.

Windows Installer packages are based on a concept called a "declared upgrade relationship," in which one package knows which other packages it can upgrade. You can use the Software Installation snap-in to create this declared upgrade relationship. For example, one Microsoft® Word 2000 package could upgrade Microsoft Word 6.0, and Microsoft Word 7.0.

This declared upgrade relationship requires natively authored rather than repackaged applications. This means that you will have to manually create upgrade relationships for repackaged applications.

The new application package (whether natively authored or repackaged) might not be able to upgrade a non-natively authored application. In some cases, you will have to use software installation and maintenance to remove the existing application and replace it with the upgrade.

It might also not be possible to completely remove a repackaged application. Some components, such as desktop shortcuts, might have to be removed manually, even if they are neither shared nor needed. As more applications with natively authored packages become available, upgrades will be able to migrate the existing application to the new application.

Software Removal

At some point, almost all software is no longer needed and you need to decide what to do with it. You can simply stop providing support, even if users continue to use the outdated application. It would then be up to the users to remove the application when they no longer have a use for it. On the other hand, new users would be unable to install the software, whether from Add/Remove Programs, the Start menu, or by document invocation.

Alternatively, you can enforce the removal of the software from users' computers. To remove software, select the package in the Software Installation snap-in. Then, on the shortcut menu, click Remove. You can force the removal of the software the next time the user logs on (in the case of published or user-assigned software) or the next time the computer restarts (in the case of computer-assigned software). The software will be removed as long as the user, who might be out of the office or on vacation, logs on at least once during the next year.

© 1985-2000 Microsoft Corporation. All rights reserved.