Software Installation and Maintenance |
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
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.
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.
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
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.
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.
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
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
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
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.
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
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
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
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
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
At some point, users no longer require an application, so you decide to remove the application. The following choices, set within the Software Installation
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.
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.