Installation Phase

The main task accomplished during the installation phase is managing the state of the software on the computer. Software can be installed, modified, updated to a new version, or removed.

• Installation involves the initial installation of the software, including copying the necessary files, configuring the registry, and creating any shortcuts that allow users to find and use the software.

• Modification involves adding or removing features after the initial installation. For example, after the initial installation of a word-processing application, a user might decide to install the spelling checker feature.

• Repair involves keeping the software in a working state without regard to what happens on the computer. For example, if a user deletes the executable file for a spreadsheet application, and then chooses the application from the Start menu, the executable file is reinstalled automatically thereby repairing the software.

• Removal involves completely and safely removing the software from the computer when it is no longer needed, including the removal of all the files, registry entries, and shortcuts.

Fundamentally, the Installation Phase occurs on Windows 2000 Professional desktops. In order to better understand the installation process, the Windows 2000 Professional components related to software installation and maintenance are listed in Table 23.10.

Table   23.10 Windows   2000 Professional Components

For more information about Windows 2000 Professional enhancements, see the Microsoft ® Windows ®  2000 Professional Resource Kit .

Note

Windows 2000 software installation and maintenance uses Windows Installer during the installation phase, as it is the best method for deploying software and maintaining software in a managed state. Windows Installer is a base service of the Windows operating system; therefore, it is available on Windows 2000, Windows NT 4.0, Windows 98, and Windows 95.

Change Control Procedures

Good change control procedures assist in managing the impact of software installation and maintenance changes within the organization, and additional troubleshooting that might be required. It is recommended that you not assign, publish, patch, upgrade, or remove a large number of applications at any one time or session. For example, it might not be good practice to publish a large complex application such as Office, and another application at the same time. Small changes are more manageable.

Software State Information

At any time during the installation phase, you can view the current state of the software that you are managing by referring to the following information that is displayed in the Software Installation snap-in: Name, Version, Deployment state, Auto-install, Upgrade Type, Upgrading, Locale, Platform, Source, and Modifications.

Figure 23.8 shows the deployment state for the User Configuration, Software Settings for several applications.

Figure 23.8 Software Settings

The deployment status is updated when a new application is deployed or an upgrade or service pack is released.

Note

Systems Management Server supports other installation methods and clients. Other methods of software installation can leave computers in an unmanaged state.

Updating Software by Using Patches and Upgrades

From time to time, publishers of software provide patches or hot-fixes, service packs, and software upgrades.

Typically hot-fixes address a single problem, and not everyone has encountered the problem. The same is true of a patch, which also typically patches or fixes a single problem. You need to determine whether or not your organization needs the patch and if so, whether you are going to manage it. Usually, when you deploy patches, service packs, or minor software updates, you re-advertise the package to everyone who was granted access to the original application.

Service packs do not differ much from hot-fixes or patches. Typically service packs roll up several patches, and the patches have been tested together. Therefore, service packs are distributed less often than patches, but more often than full upgrades.

• If the service pack updates only a small number of files, it can be distributed and managed like a patch.

• If the service pack updates a large number of files, it can be distributed and managed like an upgrade.

Patching Applications

After you have tested a patch or service pack and decide to deploy it, replace the older files by copying the new files to the software distribution point.

The publisher of the software who distributed the patch or service pack either supplies a new Windows Installer package (.msi) or a Windows Installer patch (.msp). If they supply a new Windows Installer package, replace the existing package with the new one. If they supply a Windows Installer patch, use this file to update the existing package. The supplier of the Windows Installer patch includes instructions about how to use the Windows Installer patch to update the Windows Installer package.

To redeploy an assigned or published package

1. Open the Software Installation snap-in.

3. Locate the Group Policy object that originally deployed the application.

5. Click the package name, or browse to locate the package.

7. Right-click All Tasks .

9. Click Redeploy Application .

The patched or updated files are copied to the users who have installed the software, and the software is re-advertised to everyone who was granted access to the original application.

Important

Use caution when patching applications. If the product code in the Windows Installer package of the base application (the application that is already deployed) is the same as the product code of Windows Installer that is supplied with the patch, you can patch the software and then use the Software Installation snap-in to redeploy the software. If the product code in the Windows Installer package of the base application is not the same as the product code of Windows Installer that is supplied with the patch, it is recommended that you use the Software Installation snap-in to upgrade the base application with the patch.

Patches do not change the friendly name of an application. If you want the new friendly name to be displayed, you must perform an upgrade of the base application to apply the patch. For example, you have a patch that changes the friendly name of the application. The current friendly name is Microsoft Office and the new friendly name of the patch is Microsoft Office — Service Release One. If you patch an application by updating the files on the software distribution point, and then use the Software Installation snap-in and redeploy the application, the name in the Software Installation snap-in and in Add/Remove Programs is still the friendly name of Microsoft Office. To change the name to Microsoft Office — Service Release One, you need to perform an upgrade.

If you need to change the file name extensions that are to be associated with a managed application, upgrade the base application. For example, if you receive a patch to an application that changes the number of associated file name extensions, this includes adding new file name extensions or deleting some file name extensions, you need to upgrade the application and not only redeploy.

Upgrading Applications

Upgrades typically involve major changes to the software and usually have new version numbers. A substantial number of files might change for an upgrade. You can use the Software Installation snap-in to establish the procedure for upgrading from an existing applications to the current release.

In most instances, the publisher of the software supplies a Windows Installer package for the new version. That package defines what existing versions of the software the new package can upgrade. It also contains instructions about how to perform the upgrade — for example, which existing files can be left in place, which existing files must be deleted, and which new files need to be installed. The Windows Installer package schema and design accounts for a declared upgrade relationship in which one package knows which other packages it can upgrade. A declared upgrade relationship requires natively authored (rather than repackaged) applications. The Software Installation snap-in can use this declared upgrade relationship to manage upgrades.

Either a native Windows Installer package detects the upgrade candidate or you can choose the candidate, which allows, for example, one vendor's application to be replaced by another's. No special user action is required; when a user logs on next, the application is available as assigned or published.

However, initially most applications that are deployed with the Software Installation snap-in are repackaged applications, which impacts upgrades in the following ways:

• A repackaged application's Windows Installer package does not have declared upgrade relationships. Therefore, you have to manually create upgrade relationships, which the Software Installation snap-in support.

• Because the new application package (whether natively authored or repackaged) cannot detect how the existing repackaged application was installed, it is not always able to cleanly migrate from the existing application to the new application. To upgrade you have to remove the existing application, and then install (replace it) with the new application. As more and more applications become available with natively authored packages, upgrades are able to migrate from the existing application to the new application.

• 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, even if the component is neither shared nor needed.

Note

In most cases, when a repackaged application is upgraded, the existing application is removed and the new version is installed resulting in the loss of user preferences and individual settings.

However, if you replace one native Windows Installer package with another, this problem does not occur because a native package only replaces files that need to be replaced and does not automatically remove all registry entries and other locations where user preferences might be stored.

It is recommended that you pilot or test an upgrade before putting it into production. In the pilot phase, users can be given the new version of an application and retain the original. You begin the upgrade by using the Software Installation snap-in to assign or publish the new version and define an upgrade relationship between the new and existing version. Regardless of whether the original application was assigned or published, there are two options for upgrading:

• A required upgrade happens immediately. Everyone who has installed the existing version of the application is upgraded to the new version. After the upgrade, users who have never installed the existing version of the application can install only the new version.

• An optional upgrade does not happen immediately. Everyone who has installed the software can continue to use the existing version. Users who want the new software immediately can install it from Add/Remove Programs . Users who never installed the existing application can install either the existing or the new version. At some point, you might decide that it is best that the optional upgrade become mandatory or required. The new version of the application works like a required upgrade from that point on.

Note

At first, you might want to offer the upgrade as an option, giving users an opportunity to choose when the upgrade happens. Later, the upgrade can be required.

Figure 23.9 shows Excel 2000 as the required upgrade path for Excel 97.

Figure 23.9 Microsoft Excel 2000 Properties to Upgrade Microsoft Excel 97

In Figure 23.9, Microsoft® Excel 2000 is the required upgrade path for Microsoft® Excel 97. If a future version of Excel is released and you add it to the Software Installation snap-in, make sure that you create an upgrade relationship between that future version and Excel 97, and between the future version and Excel 2000. If you only set the upgrade relationship between the future version and Excel 2000, users who still have Excel 97 installed must upgrade to Excel 2000 before they can upgrade to a future version. Because client computers can handle any number of active applications being chained together by required upgrades, the computer would sequentially request upgrades until it achieved the current release, which is not optimal.

Removing Software

At some point, users no longer require an application, so you decide to remove the application. The following choices, set within the Software Installation snap-in, might affect the removal of software:

• Optional Removal. You decide the existing software is not supported and that Help desk support is provided only for the latest version of the software.
  You can remove the software from management without forcing the (physical) removal of the software from the computers of users who are still using the software. Users can continue to use the software until they remove it themselves. In this scenario, no one is able to install the older version of the software from the Start menu, by using Add/Remove Programs , or by document invocation.

• Forced Removal. You decide that it is best that the software no longer be used. That is, users cannot install nor run the software. With forced removal, the software is automatically removed from a computer, either the next time the computer is turned on (when the software is assigned to the computer) or the next time the user logs on (when the software is assigned to the user).

Note

When you originally deploy the software, if you want the application to be removed when a Group Policy object is no longer applicable, select the Uninstall this application when it falls out of the scope of management option. Use this option with caution. For more information about this option, see "Targeting Phase" earlier in this chapter.