Applying Change and Configuration Management
Applying Change and Configuration Management |
|
In the chapters "Testing Applications for Compatibility with Windows 2000" and "Defining Client Administration and Configuration Standards," you were asked to evaluate your organization's applications for compatibility with Windows 2000, and to categorize them as mandatory or optional:
Before you can use IntelliMirror to distribute your software applications, you need to make sure they are configured properly for deployment with Windows 2000.
Applications that take advantage of Windows Installer will use Windows 2000 application support features most efficiently. Windows Installer is a new installation service that consists of:
An operating-system-resident installation service In the past, every application provided its own executable setup file or script. Therefore, each application had to ensure that the proper installation rules (such as file versioning rules) were followed. Furthermore, few best-practice guidelines were available for developers authoring the setup routines. As a result, installation or removal of a given application often broke existing applications on the computer. The Windows Installer Service ensures that critical setup rules are implemented by the operating system. To follow those rules, applications merely need to describe themselves in the standard Windows Installer format.
A standard format for component management The Windows Installer service views all applications as three logical building blocks: components, features, and products. Components are collections of files, registry keys, and other resources that are all installed or uninstalled together. When a given component is selected for installation or removal, all of the resources in that component are either installed or removed. Features are the pieces of an application that a user can choose to install, and typically they represent the functional features of the application itself. When a user chooses Custom in a setup program, the pieces of the application they are able to select for installation correspond roughly to features. A Windows Installer product represents a single product such as Microsoft® Office. Products consist of one or more Windows Installer features. Each product is described to the Windows Installer service in the form of a single Windows Installer package (.msi) file.
A management API for applications and tools The Windows Installer application programming interface (API) enables tools and applications to enumerate the products, features, and components installed on the computer, install and configure Windows Installer products and features, and determine the path to specific Windows Installer components installed on the computer. Applications that are written to leverage the Windows Installer service gain the advantages of roaming user support, on-demand installation, and runtime resource resilience.
Applications that have been natively authored to take advantage of Windows Installer technology will support:
Note
Many software vendors and in-house development groups are updating their applications to take advantage of Windows Installer capabilities. For more information about the Windows 2000 application specification, see the MSDN link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources.
It is not always possible to natively author applications. In particular, you might have older applications for which you do not have the resources to natively author Windows Installer packages. You can still benefit from Windows Installer features by repackaging these applications for use with Windows 2000.
You can repackage files using a repackaging tool such as WinInstall LE, a program that comes with Windows 2000 Server.
The changes between the original application and the customized application image are then converted into a Windows Installer package.
Repackaged files allow you to benefit from some Windows Installer features, meaning they can be advertised and repaired, and will install with elevated privileges. (Advertising and other distribution options are discussed in "Software Management Options" later in this chapter.) However, a repackaged application will not benefit from the Windows Installer architecture, which means the repackaged application will install as if the product had just a single (large) feature.
You can also make other applications available to users using their existing setup programs. To do this, you need to use a text editor, such as Notepad, to create a ZAP (.zap) file. ZAP files, which are similar to INI files, are placed in the same folder on the software distribution point as the original setup program that it references. Because you are publishing the existing setup, the user's experience will not be better than the existing setup. If the existing setup does not support clean and complete removal of the software, for example, then publishing the existing setup will not improve the software removal experience. By managing software files with the ZAP file format, the application will appear in Add/Remove Programs in Control Panel, and users will be able to install the application from this location.
Note
The user will still need to have the same administrative privileges as required by the older application in order to complete this type of installation.
For more information about managing older applications, see "Software Management" in the Microsoft® Windows® 2000 Server Resource Kit Distributed Systems Guide.
In the past, administrators who wanted to customize the behavior of an installation had to repackage the application by directly modifying the setup script to achieve the desired results. If many different setup scripts required similar changes, they needed to repeat those efforts for each script.
With Windows 2000, you do not need to customize Windows Installer packages in order to customize the installation for your organization. Instead, you can create a transform and use this transform to customize the package. The Windows Installer service transform modifies the Windows Installer package file at deployment, and therefore dynamically affects installation behavior.
You can transform or customize Windows Installer packages to handle a variety of customizations. For example, a transform can be used to install selected features in a predefined location so that users do not have to decide what features to install or where to install them. You can also use a transform to modify the path of a given component, as long as the component exists in the package being modified.
Whereas existing installers typically give the user a binary choice between "installed" and "not installed" for a given feature, the Windows Installer features can be set to one of four states:
Transforms should be stored in the same network shares as the Windows Installer packages that they customize. Transforms are applied at deployment, and they cannot be applied to an application that has already been installed.