Software Installation and Maintenance

Previous Topic Next Topic

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.

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

Component Overall Function Software Installation and Maintenance Function
Computer Start-up Loads the operating system, shell, and other programs. Applies computer Group Policy so that computer-assigned software is installed.
WinLogon Allows a user to log on to his or her computer. Applies user Group Policy so that assigned applications are advertised.
Application Management Extension (appmgmt.dll) Client-side extension of software installation. Communicates with Active Directory, Group Policy, and Windows Installer to assign or publish software.
Windows Installer Enables the client for managing software. Advertises, installs, repairs, and removes software.
Add/Remove Programs in Control Panel Allows users to manage software on their computer. Lists published and assigned applications so that users can install, modify, and remove software from their computers.

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


note-icon

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
Enlarge figure

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-icon

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.

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.
  2. Locate the Group Policy object that originally deployed the application.
  3. Click the package name, or browse to locate the package.
  4. Right-click All Tasks.
  5. 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-icon

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:


note-icon

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:


note-icon

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
Enlarge figure

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:


note-icon

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.

© 1985-2000 Microsoft Corporation. All rights reserved.