This paper describes Windows 2000 Software Installation and Maintenance, one of the key Change and Configuration Management features. Administrators can use Software Installation and Maintenance to manage software throughout the software's lifecycle to reduce their organization's Total Cost of Ownership for Windows 2000 Professional.

On This Page

Introduction
Software Installation and Maintenance Overview
Phases of Software Management
Software Installation and Maintenance Architecture
Common Software Installation and Maintenance Scenarios
For More Information
Appendix A: Creating and Customizing Windows Installer Packages
Appendix B: Software Installation and Maintenance Glossary
Appendix C: Certified for Windows 2000
Appendix D: The Zap File Format
Appendix E: Microsoft Systems Management Server
Appendix F: Frequently Asked Questions

Introduction

Windows 2000 Software Installation and Maintenance allows administrators to manage software for their organization and reduce their organization's Total Cost of Ownership (TCO). Administrators use Software Installation and Maintenance to centrally manage the software that is available to the users in their organization, and to ensure that users have the software they require for their jobs.

Software Installation and Maintenance is a key Windows 2000 IntelliMirror™ feature. The following table (see table 1) highlights the Windows 2000 Change and Configuration Management and IntelliMirror features, benefits, and the technologies that enable the features.

Table 1 Windows 2000 Change and Configuration Management

What This Paper Contains

This paper presents background and architectural information about the IntelliMirror Software Installation and Maintenance feature. It is intended for Information Technology planners and administrators who want to understand how their organization can benefit from using this feature.

This paper does not provide information on how to use Software Installation and Maintenance. For information on how to use the feature, refer to the Windows 2000 Server online Help, and the Software Installation and Maintenance Walkthrough, both of which are available from the Microsoft Windows 2000 Server Web site and TechNet.

This paper does not provide information on how to use Software Installation and Maintenance in conjunction with Microsoft Systems Management Server. For more information on Microsoft Systems Management Server, see Appendix E.

Prerequisite Information

The IntelliMirror Software Installation and Maintenance feature relies on both the Windows 2000 Active Directory™ service and Group Policy. Readers will find the concepts in this paper easier to understand if they are familiar with both Active Directory and Group Policy. For information on these subjects, refer to the white papers available from the Windows 2000 Server technology center http://www.microsoft.com/windows2000/ on TechNet.

Software Installation and Maintenance Overview

Administrator Benefits

By using Software Installation and Maintenance, administrators can ensure that users have the software they need for their jobs, without requiring the administrator or technical support personnel to visit each computer to install it. Administrators can centrally manage:

• Initial deployment of software, including productivity applications, in-house or Line of Business (LOB) applications, and operating system service packs.

• Upgrades of existing software to a new version or replacement software, including Windows 2000 operating system upgrades.

Administrators can deploy software as either assigned or published. Assigned software is deployed to all users who must have the software to perform their jobs. Software can also be assigned to computers. Published software is made available to users who might want to use the software, allowing users to decide whether to install it. For more information on assigning and publishing software, see the section "The Targeting Phase."

Organizational Benefits

With Software Installation and Maintenance, administrators can ensure that the software users require to perform their jobs is always available. Administrators can customize how software is deployed; for example, they can deploy only the software that users require, or they can deploy just the features of the software users require.

Because Software Installation and Maintenance utilizes Active Directory, Group Policy, and Windows Installer, additional benefits are provided. For example, if a user inadvertently deletes an assigned application, it will continue to be available. If users roam from one computer to another, their assigned software is always available for them to use.

Administrators use Group Policy to control what software users can install and from which media. For instance, administrators can set a policy that prevents users from installing software from local media such as a CD-ROM or diskette.

By leveraging Windows Installer, Software Installation and Maintenance allows the administrator to limit the security level of users – users do not have to be administrators of their Windows 2000 Professional computer to install software. This means that users are only granted the appropriate level of permissions (and no more) for them to do their job.

End User Benefits

Users benefit by having access to their required software, and because of the reliability and resilience provided by Windows Installer, users have an easier and more consistent experience.

Users can get the software they require from the Add/Remove Programs in the Control Panel. They can also manage the software on their computer from this location, including installing, repairing, modifying, or removing it.

Software Installation and Maintenance addresses another end-user scenario. Users frequently receive documents by e-mail attachment. If the software associated with the document is not installed on the user's computer, when they try to open this document, they are presented with the Open with dialog box, and they have to determine which of their currently installed software programs might be able to open the document. In Windows 2000, when the user double-clicks on the attachment, Software Installation and Maintenance installs the software that the administrator specified should be used to open and edit the document, and then Windows 2000 opens it.

Phases of Software Management

Administrators typically have to manage several phases of software deployment, including preparation, distribution, targeting or scope of management, and installation.

The software deployment phases may differ from those used by your organization; however, for the purpose of this paper, the phases listed above will be used.

The Preparation Phase

The main task of the preparation phase is to prepare the software for distribution, targeting, and installation.

Windows 2000 Software Installation and Maintenance leverages Windows Installer, which requires the use of Windows Installer packages (.msi files) for the software. The Windows Installer is a base service of the Windows Operating System and is available with Windows 2000, and for Windows NT® 4.0, Windows 98, and Windows 95.

Windows Installer Packages and Transforms

A Windows Installer package contains all the information necessary to describe to Windows Installer how to set up an application in every conceivable situation: various platforms, different sets of previously installed products, earlier versions of a product, and numerous default installation locations. Some applications such as Microsoft Office 2000 provide their own .msi files; these are referred to as natively authored Windows Installer packages.

You can obtain Windows Installer packages in a couple of ways. The author or publisher of the software can supply a natively authored Windows Installer package. For example, Microsoft Office 2000 provides a Windows Installer package (.msi file). Alternatively, administrators can repackage software for use with Windows Installer. Many organizations repackage software to customize it; this process may entail using Microsoft Systems Management Server. Repacking for Windows Installer is fundamentally the same as using any repackaging tool, but the output of Windows Installer repackaging process is a package that can be used by both Windows 2000 Software Installation and Maintenance and Microsoft Systems Management Server.

For additional information on Windows Installer, including information on how packages are authored and repackaged, see Appendix A: Creating and Customizing Windows Installer Packages.

It is also possible to customize an .msi package to suit your particular requirements. For example, an organization may decide that they do not want to use all of the features of the software, and they need to customize the software to remove the unnecessary features. Consider the scenario where an organization decides that they do not want to distribute clip art with their presentation software, or that they have a customized dictionary that they want to distribute with a word processor.

In the past, to customize the installation of software, administrators had to modify the setup instructions by editing the setup information file (.sif), or they had to repackage the software to meet their requirements.

The Windows Installer supports a robust model of customization by allowing the administrator to create a transform (.mst file). A transform is a specialized Windows Installer package that when associated with Windows Installer at deployment time modifies the original Windows Installer package.

Transforming the software is a more efficient method than editing the software installation instructions or repackaging the software to eliminate unwanted features. The Windows Installer architecture was created with the idea of creating transforms for software in mind.

Microsoft Office 2000 includes a Custom Installation Wizard (CIW) that provides administrators with a high degree of control over the installation of Office 2000. The output of the Custom Installation Wizard is a transform. Administrators can use the Custom Installation Wizard to customize which features are installed, when they install, the (target) location where the files install, and other aspects of the Office 2000 installation and configuration.

The key point is that Windows Installer gives administrators more control over the software installation process, eliminating the need to edit the original author's setup instructions or repackage the application. For additional information on transforms, see Appendix A: Creating and Customizing Windows Installer Packages.

Windows 2000 supports the customization of software using Group Policy. In this scenario, the application is written to use Group Policy, and provides Group Policy settings for the software that administrators can activate. For example, an application could provide a policy setting that controls whether a user can save data in a location other than the My Documents folder. For more information on developing software that provides Group Policy settings, see the information in Appendix C: Certified for Windows 2000.

During the development of the Software Installation and Maintenance feature, customers in the Joint Development Program (JDP) requested a way to make existing software appear in the Add/Remove Programs in the Control Panel. Administrators can make a ZAP (.zap) file that describes the existing setup program to Windows Installer, and allows administrators to manage the existing setup with Software Installation and Maintenance. A .zap file is a text file (similar to .ini files) that provides information about how to install a program, the application properties, and the entry points that the application should install.

Additional information on ZAP files, and their limitations, is documented throughout this paper and in Appendix D: The ZAP File Format.

The Distribution Phase

The main task of the distribution phase is to get the software copied to software distribution points (SDPs), which are network locations from which users can get the software they require.

To create a software distribution point, you must set up network shares for the software, apply the appropriate permissions so that users can access the software, and then replicate the software (including the executable programs, Windows Installer packages, and any transforms) to the software distribution points. Typically, these software distribution points are physically located throughout the organization so that users can always get the software from a distribution point that is close to their office.

Note: Windows 2000 Software Installation and Maintenance does not directly address the distribution phase. Administrators must perform separate steps outside of the scope of Software Installation and Maintenance to create and manage these software distribution points. Administrators may choose to leverage other Windows 2000 services, such as the Distributed File System (Dfs), to manage the distribution phase.

Best Practice Microsoft Systems Management Server (SMS) version 2.0 supports a robust distribution model that administrators can use with Windows 2000 Software Installation and Maintenance.

The Targeting and Scope of Management Phase

During the targeting phase, administrators must determine which software users should get based on the users' specific job requirements.

The scope of management for Software Installation and Maintenance is defined by Group Policy, which in turn is tied to Active Directory. Administrators use the Software Installation Microsoft Management Console (MMC)¹® Management Console (MMC) is an ISV-extensible, common presentation service for management applications. MMC is included in the Windows® 2000 operating system, ans will also run on the Windows NT® 4.0, Windows 95, and Windows 98 family of operating systems. MMC provides a common host environment for snap-ins, provided by Microsoft and third-party software vendors. Snap-ins provide the actual management behavior; MMC itself does not provide any management functionality. The MMC environment provides for seamless integration between snap-ins. snap-in, an extension of the Group Policy snap-in, to deploy software to groups of users and computers managed by Group Policy objects (GPOs) that are associated with these Active Directory containers: sites, domains, or organizational units (OUs). Any user or Windows 2000-based computer that is contained in one of these Active Directory containers is a potential target for software that is managed by Software Installation and Maintenance.

Because of the relationship to both Group Policy and the Windows 2000 Active Directory, the Software Installation and Maintenance feature was designed specifically for Windows 2000. This feature relies on the technology within Windows 2000 Server to manage software on Windows 2000 Professional.

In contrast, the scope of software installation and maintenance using Microsoft Systems Management Server (SMS) is a dynamic collection, which is typically hardware or software inventory based. This means that administrators can use SMS to manage software for users and computers running Windows 2000, Windows NT 4.0, Windows 95, and Windows 98. For more information on Systems Management Server, see Appendix E.

As part of the targeting phase, it is useful to consider issues related to the software life cycle, discussed next.

The Software Life Cycle

Administrators must be able to manage software throughout the software's life cycle. The software life cycle addresses key issues for the administrator, allowing the administrator to manage software evaluations, rollouts, and upgrades between software versions. Using Software Installation and Maintenance, administrators can manage software throughout its life cycle, shortening the time it takes to deploy the software to users, and increasing users' productivity.

Windows 2000 Software Installation and Maintenance was designed with the following software life cycle in mind (see figure 1):

Version One: Deployed

The software life cycle begins when an administrator deploys version one of the software. Users learn and begin using the software. This is considered a steady or known state that administrators would like to preserve—the software is deployed and users are productive.

Version Two: Release and Evaluation

Because of either changes to business requirements, or the availability of a new version of the software with improved productivity features, administrators have to consider deploying the new version of the software.

Before deploying a new version, administrators typically conduct an evaluation or test phase. During the test phase, they deploy the software to a small group of users. This test phase allows the administrator to learn about any deployment issues and to validate that the improved productivity of the new software can be realized within their organization.

To evaluate the software, administrators designate a small group of users who currently use the existing version of the software to begin using the new version. Administrators evaluate compatibility issues with existing workflow; identify any training, conversion, and support requirements; and determine what will be required to deploy the application and gain the productivity improvements for their organization.

During the evaluation, the majority of the organization will continue to use the currently deployed version of the software.

Version Two: Rollout

Although it would be preferable to roll out the new version of the software to everyone at once after testing is completed, business requirements usually prevent this approach.

A more typical scenario is to gradually upgrade users from version one to version two. As an example, consider an organization that has successfully tested a new spreadsheet application, and would like to roll it out. However, it is tax season and it would be disruptive for the finance department to make the change at this point. Therefore, administrators may move everyone except the finance group to the new version. After tax season is over, the finance department can upgrade to the new version.

Because rollouts often occur over a long period of time, any deployment solution must support a granular rollout of the new application to groups of users.

What to Do with Version One?

After rolling out the new version of the software to their organization, administrators have to consider what to do with the older version.

The software deployment life cycle gives administrators two choices at this point:

• Force an upgrade to the new version: when there is no longer a valid business reason for users not to upgrade to the new version, supporting two versions may add an unwarranted support burden. Administrators need to be able to mandate that everyone upgrade to the new version. Requiring everyone to upgrade allows administrators to remove the old version of the software from the software distribution points.

• Leave the existing version in a non-supported state: there may be cases where some users in the organization don't want to upgrade to the new version of the software, and it is not considered a burden to the organization to allow both versions to be available. In such cases, administrators may leave version one in a non-supported mode, that is, users can still use version one, but no support will be provided for it. If the users delete the old version, they will have to install the new version as the replacement. New users, who had never installed the previous version, can only install the new version.

Version Two: Deployed

At this point the administrator is back to the steady state; a version of the software is deployed that users can use to perform their job.

Windows 2000 Software Installation and Maintenance helps the administrator support the steady state. Assigned applications are resilient—users cannot delete them by mistake, and Windows Installer can repair damaged applications.

Version One: Removed

The last state in the software deployment life cycle is when version one of the software has to be removed. The administrator must back up the software and archive it so that if it ever becomes necessary to use the software to reconstruct business records created with the software, the organization can do so.

Patches and Fixes

From the perspective of the software deployment life cycle, a patch or Quick Fix Engineering (QFE) service pack is just a specialized case of another version, and is handled in this lifecycle as if it were an upgrade of another version.

Throughout this lifecycle, targeting is one of the administrators' key tasks. Administrators have to manage who has the software during the test cycles on through normal deployment, the introduction of patches and upgrades, and ensure that when software is no longer needed, it is removed and archived.

Software Installation and Maintenance was designed to provide the administrator with a powerful, policy-based mechanism to target software to the users who need it.

Installation Phase

The installation phase represents the steady state of the software on the computer. Administrators want the software installed correctly on the users' computers. To manage this steady state, software is:

• Installed. This includes copying the necessary files, initial configuration of the registry, and the creation of the desktop and Start menu shortcuts that allow users to find and use the software.

• Modified. This involves adding or removing features after the initial installation. For example, after the initial installation of word processing software, a user could decide to install the spell-check feature. Note that this differs from configuration, where users specify how they want the software to appear, for example, which toolbars will be displayed.

• Repaired. This involves keeping the software in a working state without regard to what happens. For example, if a user deletes the executable file for their spreadsheet, and then chooses the spreadsheet from the Start menu, the executable file would be reinstalled automatically, thereby repairing the software.

• Removed. This 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.

Software Installation and Maintenance allows an administrator to manage the installation phase using Windows Installer and Group Policy.

For additional information on Windows Installer, refer to Appendix A: Creating and Customizing Windows Installer Packages.

Software Installation and Maintenance Architecture

Overall Architecture

This section provides information on the Software Installation and Maintenance architecture. It discusses the architecture in terms of the software deployment phases that were introduced in the preceding section.

Windows 2000 Software Installation and Maintenance requires Windows 2000 Server, Active Directory, Group Policy, and Windows 2000 Professional. For specific details on the architecture of Group Policy and the Group Policy Object, refer to the Group Policy white paper.

Windows 2000 Server Components

Table 2, below, describes the server components of Software Installation and Maintenance.

Table 2 Software Installation and Maintenance server components

Component	Overall Function	Software Installation and Maintenance Function
Active Directory	A hierarchical collection of objects including domains, sites, Organizational Units (OUs), users, computers and printers that allow an organization to manage these resources.	Provides the scope of management mechanism to locate people and computers, and stores Software Installation and Maintenance information through Group Policy.
Group Policy	Allows an administrator to centrally manage users and computers within Active Directory. Administrators can specify policy options for registry-based settings, scripts, software installation, Internet Explorer maintenance, folder redirection, remote installation services, and security settings.	Administrators deploy applications within a Group Policy Object (GPO) that is associated with an Active Directory container such as a site, domain, or OU. To deploy applications, administrators use the Software Installation and Maintenance extension of the Group Policy snap-in.
Microsoft Management Console	A common management infrastructure for hosting administrative and management tools.	Hosts the Group Policy and Software Installation and Maintenance snap-ins.

The Preparation Phase

Typically, administrators will not perform the preparation phase on servers. Rather, administrators or developers create packages or repackage software for Software Installation and Maintenance on a computer running Windows 2000 Professional.

The Distribution Phase

Administrators create a software distribution point on Windows 2000 servers, and ensure that the software that they want to deploy is available on that software distribution point.

To set up the software distribution point, administrators do the following:

• Create the necessary network folders.

• Share the network folders for users to access.

• Copy the software to the network shares.

• Grant users read access to the network shares

Note: Most software comes with an administrative setup that prepares the software for installation from a software distribution point. The administrative setup expands any compressed files, allows for entry of a software key, and any other preparation. For example, to install Microsoft Office 2000 to a software distribution point, run setup with the /a parameter.

Assigning software to computers works best if the software distribution point is a Windows 2000 server, and is in the same Active Directory forest as the targeted computer. This has to do with issues related to authentication of the computer (machine account object). For more information on assigning software to the computer, see the section "The Targeting Phase," below.

The Targeting Phase

Administrators use Group Policy to set the scope of management for software installation; this determines which users will get the software. Administrators use the Software Installation snap-in extension of Group Policy to deploy software to users or computers managed by a Group Policy Object (GPO) associated with a site, domain, or OU. To do this, administrators start the Group Policy snap-in focused on a GPO they want to manage, and then set Software installation options (accessed under the Software Settings node) under either the Computer Configuration or the User Configuration node of the Group Policy snap-in.

The following example shows a Group Policy MMC console focused on a GPO called HQ Policy. Administrators use the Software installation node under Software Settings to set options for software deployment for either the Computer Configuration or the User Configuration nodes.

Windows 2000 Software Installation and Maintenance also allows administrators to target software as either assigned or published.

Administrators assign software when users must have the software to perform their jobs. For example, if everyone requires e-mail, administrators can assign an e-mail program.

Best Practice Assign software when you want it to be resilient, that is, no matter what the user does, the software will always either be installed or available to be installed.

If several people use a computer, and everyone who uses the computer uses a particular application, then that application is a candidate for assignment to the computer

Administrators can publish software that users may find useful to perform their job. For example, administrators could choose to publish project management software, allowing users to decide whether to install the project management application. Software can be published only to users, not to computers.

Given that software can be either assigned or published, and targeted to users or computers, the administrators have to use a workable combination.

Table 3, below, contrasts publish and assign.

Table 3 Publish and Assign compared

Scenario	Publish to Users	Assign to Users	Assign to Computers
After the administrator deploys the software, it is available for installation after:	The next logon. (If an application is deployed in a GPO that is already applied to the user from a previous logon, that application is available for installation in that logon session.)	The next logon.	The next time the computer starts (reboot).
Typically, users install the software from:	The Add/Remove Programs in Control Panel.	Start menu shortcut. Desktop shortcut. Add/Remove Programs in Control Panel.	The software is already installed.
If the software is not installed and the user opens a file associated with the software, will the application install?	Yes.	Yes.	The software is already installed.
Can the users remove the software using the Add/Remove Programs in Control Panel?	Yes. Users can choose to reinstall the software from Add/Remove Programs in Control Panel.	Yes. The software will be available again immediately for installation from the desktop.	No. Only the local administrator can remove the software. A user can run a repair on the software.
Supported installation file types:	Windows Installer packages (.msi files), and ZAP files.	Windows Installer packages (.msi files)	Windows Installer packages (.msi files)

The actual steps that an administrator performs to either assign or publish software are substantially similar. The administrator does both from within the Software Installation snap-in. For information on these tasks, see the Windows 2000 Server online Help file for the Software Installation snap-in, and the "Step-by-Step Guide to Software Installation and Maintenance" http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/instmain.mspx, both of which are available from the Windows 2000 Server Web site.

Administrators assign or publish software by using both the Group Policy and the Software Installation snap-in. Typically the tasks involved include some or all of the following steps:

1. Open Active Directory Users and Computers snap-in and navigate to Active Directory container (domain or organizational unit) that contains the users or computers for which you want to manage software.

   For example, to manage software for an OU called Accounts in a domain called reskit.com, you would double-click Active Directory Users and Computers, double-click reskit.com, and then right-click Accounts OU.

2. Open the Group Policy snap-in to create a new (or edit an existing) Group Policy Object (GPO).

   Using the example in step 1, to open the Group Policy snap-in, right-click the Accounts OU, select Properties from the context menu, and then in the Accounts Properties dialog box, click the Group Policy tab. Then in the Accounts Property page, click the Group Policy tab, select New and type a name to create a new GPO, or select a GPO form the Group Policy Object Links list box, and click Edit. This opens the Group Policy snap-in.

3. In the Group Policy snap-in, select either the User Configuration or the Computer Configuration node, double-click Software Settings, and then right-click Software Installation. This opens the Software Installation snap-in.

   For example, to manage software for users, in the Group Policy snap-in, under User Configuration, double-click Software Settings, right-click Software installation, and then select New from the context menu.

4. Select Windows Installer package (.msi file) that you want to deploy from the software distribution point.

5. Configure the software for management (associate any transforms and create any upgrade relationships).

6. Assign or publish the software.

The Software Installation snap-in generates an application advertisement script (.aas file) and stores this script in the appropriate locations in Active Directory and the Group Policy Object.

For more information on how Group Policy Objects are managed and stored within Active Directory and the Sysvol folder, see the white paper, "Introduction to Windows 2000 Group Policy" http://www.microsoft.com/windowsserver2003/techinfo/overview/gpintro.mspx.

Windows 2000 Professional Components

Installation Phase

The Installation phase occurs on Windows 2000 Professional desktops. Table 4, below, describes the client components of Software Installation.

Table 4 Client components of Software Installation

Component	Overall Function	Software Installation and Maintenance Function
Computer startup	Loads the operating system, the shell, and other programs.	Applies computer group policy. Calls the Application Management extension if there is computer-assigned software.
Winlogon	Allows users to log on to their computers	Applies user group policy. Calls the Application Management extension if there is user-assigned software.
Software Installation client-side extension (appmgmts.dll)	Client-side extension of Software Installation and Maintenance. Client-side extensions are dynamic link libraries (DLLs) that are responsible for implementing Group Policy at the client computers.	Communicates with Active Directory, the Group Policy object, and Software Installer to assign or publish software.
Windows Installer	An operating system service for software installation.	Advertises, installs, repairs, and removes software.
Add/Remove Programs in Control Panel	Used to manage software on the local computer.	Lists published and assigned software so that users can install, modify, and remove software from their computers.

Published Software

When administrators publish software for a user, the published software does not appear to be installed on the user's computer. This means there is no information about the software on the computer, either in the registry, shortcuts on the desktop, or the Start menu.

The user can install the published software from Add/Remove Programs in the Control Panel. When users open Add/Remove Programs in the Control Panel and select Add New Programs, they see a list of all of the software that is published and assigned to them. Users will see only the list of software that the administrator has determined they require for their jobs. If there is a large amount of software, then the user can sort the software based on administrator-defined software categories.

When users select the software they want to install from the list of published software in the Add Programs pane, Add/Remove Programs gets the information required to install the software from Active Directory and uses the information to get Windows Installer package for the software. The Windows Installer then installs the software based on the information contained in the package.

After users install published software, it behaves like assigned software until the users remove the software using Add/Remove Programs, or the administrator removes the software using the Software Installation snap-in.

User-Assigned Software

User-assigned software appears to be installed on users' computers; in other words, there is information about the software on users' computers. The Software Installation extension (appmgmt.dll) to Winlogon advertises the software in the computer's registry and by using shortcuts on the desktop or the Start menu.

To the user, it appears as if the software is already installed. An entry for the software appears on the Start menu. Users typically install user-assigned software by selecting the software from the Start menu.

Typical Installation of User-Assigned Applications

When a user selects the software from the Start menu, Windows Installer uses the shortcut information to get the software's Windows Installer package. The Windows Installer then installs the software based the information contained in the package.

Assigned software is resilient. If a user removes assigned software using Add/Remove Programs in the Control Panel, then installation information that advertises the software in the registry and applies the shortcuts to the Start menu and desktop is immediately reapplied. The user can reinstall the software the next time they select it.

Computer-Assigned Software

The preceding description illustrates what happens when software is assigned to a user. An administrator can also assign software to a computer. In this case the software is installed for all the users who use the computer the next time that the computer reboots. This means the next time that the Software Installation portion of Group Policy for the computer is applied. While Group Policy is applied at various times, Software Installation policy can only be applied when it is safe to do so.

When the computer restarts (boots) the Software Installation client-side extension provides the information about the software to install from Active Directory to Windows Installer, and Windows Installer then installs the software.

With assigned software, whether it is assigned to the computer or the user, the administrator knows that users can always use or install the software.

Document Invocation: Auto-Install

Regardless of whether software is assigned or published, users can trigger the software installation process by invoking a document associated with the software.

Users might receive a document as an attachment to an e-mail message. The users may never have installed the software associated with the document on their computers, but the software is either published or assigned for them. Currently, if users double-click on an attachment to open or invoke it, and there is no software associated with the application on their computer, they get the Open with dialog box, which lists all the software on their computer. They have to know which software to select to successfully open the file.

With Software Installation and Maintenance, if a user double-clicks on the attachment to open it, and there is information for the assigned software on the user's computer, then Windows Installer installs the software and opens the document. If there is no software for that document type installed on the computer, and no assigned software information on the computer, then Windows 2000 Professional looks to Active Directory to see if there is published software associated with the attachment.

When the administrator publishes software using the Software Installation snap-in, information about the published software is stored in Active Directory. If there is published software in Active Directory for the user, Windows Installer uses that information to install the software for the user, and then opens the document for them.

Assigned Software: Summary

To summarize, administrators can assign the software that users require to perform their jobs. They can assign software to either users or computers.

User-assigned software is:

• Advertised on the local computer when a user logs on to Windows 2000 Professional.

• Installed the first time a user starts the software (from the Start menu, or by document invocation), or a user may choose to install it from Add/Remove Programs in the Control Panel.

• Resilient—if a user removes assigned software, it is advertised again and available for installation. The software is always available for users.

Computer-assigned software is:

• Installed when the computer starts.

• Can be removed by the local computer administrator from the Add/Remove Programs in the Control Panel.

Published Software: Summary

Administrators can publish software that may be useful to users. Published software is:

• Not present on the computer. There is no information about the software on the user's computer before it is actually installed; instead, the information about the software is available from Active Directory.

• Installed when a user selects the software from Add/Remove Programs in the Control Panel, or by document invocation.

• Not resilient—users can remove published software by using the Add/Remove Programs in the Control Panel. The shortcuts for the software and the registry information will not be automatically reapplied on their computer.

Software Life Cycle: Pilots

Regardless of whether an administrator wants to assign or publish software, it is likely that they will want to set up a software test phase or a pilot. During this phase, administrators can set up a small group of users that evaluates the software before they deploy the application to the rest of their organization.

Administrators can manage software evaluation in the following ways:

• Evaluate the software outside of the corporate managed environment, for example, in a laboratory or test network environment.

• Create a Group Policy Object (GPO) to manage the evaluation, and assign or publish the software to users who are managed by that Group Policy Object.

• Edit the security descriptors or Discretionary Access Control Lists (DACLs) on an existing GPO or on the assigned or published package to control who can install the package for evaluation.

• Manage the state of the software by changing whether the software is assigned or published, visible or hidden, and whether or not auto-install is set. These parameters can be managed in the property pages of the Software Installation snap-in for each package.

Best Practice A simple pilot can be managed by publishing the new version of the software, but not setting the software to Auto-Install. This way, users in the pilot can install the new version for the pilot from the Add/Remove Programs in the Control Panel.

Software Life Cycle: Upgrades

An essential part of the software life cycle phase involves upgrading software. Several events in the life cycle of the software can trigger an upgrade. For example:

• The original developer of the software may release a new version with new and improved features.

• The organization may choose to use a different vendor's application.

Administrators must be able to manage the software upgrade process. Regardless of whether the original software was assigned or published, the upgrade portion of the application life cycle is similar.

Two types of upgrades exist:

• A mandatory upgrade happens immediately. This means that everyone who has installed the existing version of the software will be upgraded to the new version. In the case of already installed user-assigned or published software, this happens the next time the user logs on. In the case of computer-assigned software, this happens the next time the computer restarts. After the administrator creates the upgrade, users who have never installed the existing version of the software can only install the new version (the upgrade).

• A non-mandatory upgrade does not happen immediately. This means that 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 in the Control Panel. Users who never installed the existing software can install either the existing or the new version. At some point, the administrator may decide that the non-mandatory upgrade should become mandatory. From that point on, the new version of the software will behave like a mandatory upgrade.

Best Practice Administrators may want to offer the upgrade as non-mandatory first, giving users an opportunity to choose when the upgrade happens. Later, the upgrade can be made mandatory.

Windows Installer supports the concept of a declared upgrade relationship, where one package has information about which other packages it can upgrade. This requires natively authored (rather than repackaged) Windows Installer packages. The Software Installation snap-in can use this declared upgrade relationship in the package to assist an administrator in managing upgrades.

The Software Installation snap-in detects the upgrade relationship. It automatically establishes an upgrade between the existing or base software package and the new or upgrading package when the administrator adds the upgrading package to the Group Policy Object where the base package is managed.

Initially, most software being managed with the Software Installation snap-in will be repackaged. This will impact upgrades in the following ways:

• A repackaged Windows Installer package will not have information about which software it can upgrade. Therefore, administrators will have to manually create upgrade relationships in the Software Installation snap-in.

• Because the new software package—whether natively authored or repackaged—does not have information about how the existing repackaged software was installed, it will not always be able to cleanly migrate² from the existing software to the new version. The administrator will have to make some remove-and-replace type upgrades; that is, the upgrade will remove the existing software, and then replace it with the new software.

• During an upgrade, the removal of repackaged software may leave components on the desktop, even if the component is not shared or needed. This is due to the restrictions that are inherent in any repackaging process.

Software Life Cycle: Software Removal

At some point, users will no longer require software, and administrators will decide to remove it.

The following choices may affect the removal of software:

• Administrators may decide that the existing software should not be supported and that technical support should be provided only for the latest version of the software. You could remove the software (from management) without forcing the (physical) removal of the software from the computers of users who are still using the software. This means that these users could continue to use the software until they remove it themselves. In this scenario, after the removal, no one would be able to install the older version of the software.

• Administrators may decide that the software should no longer be used. That is, users will no longer be able to install the software, nor run the software. In this scenario, you want to enforce the removal of the software from user's computers.

Best Practice When administrators remove software, they should allow sufficient time for users to either log on or restart their computer so that the software is removed before they remove the Group Policy Object that contained the software.

Common Software Installation and Maintenance Scenarios

This section highlights the basic user scenarios that Windows 2000 Software Installation and Maintenance supports. Because each organization has its own unique business requirements, administrators will have to determine the best way to implement Software Installation and Maintenance within their organization.

Supporting Knowledge Workers

One User: One Computer Stationary Worker

In many organizations, each user has their own computer and they do not work on other computers. Typically, this computer is a desktop computer, connected to the network with a consistent, high-speed connection.

Administrators may want to make these users their base, and define a standard operating environment (SOE) that will include standards on how the operating system will be installed and configured, how Group Policy will be used to further configure and manage the environment, and which software is needed.

If the computers have the necessary hardware³ to take advantage of the Remote OS Installation feature of Windows 2000, the administrator can include the necessary application software with the operating system image, and then the software is copied onto the computer with the operating system. For more information on this topic, see the section "Using IntelliMirror and Remote OS Installation Together," later in this paper.

If the computers do not have the necessary hardware to take advantage of the Remote OS Installation, then the administrator can use the Software Installation snap-in to assign the software to the computers. They do this by editing the GPO that manages the computers and using the Software Installation snap-in under the Computer Configuration node of the Group Policy namespace to assign the software to the computers.

In this scenario, assigning the software to the computer may be the best choice, as the software will be installed during startup of the computer.

Administrators could also choose to transform Windows Installer package for the software to support running the software from a network share, thereby reducing the amount of software copied across the network. Note that the software (like Microsoft Office 2000) has to be written in a manner that specifically supports being run from a network environment, and the administrator should take into account the effect that this choice might have on network traffic.

Best Practice Administrators can use the Microsoft Office 2000 Custom Installation Wizard to create a transform that allows users to run Microsoft Office 2000 from a network share, with a minimal computer footprint for the software.

Mobile Workers: The Traveling Professional

In many organizations, users' jobs require that they travel extensively. A key point about mobile workers is that while they log on to the same computer, their computer sometimes connects by a high-speed line, and sometimes by a low speed, or dial-up, line.

Best Practice By default, Software Installation and Maintenance policy is not applied over a slow link. Thus, users who connect to their organizations network by slow links may not see changes to software policy. This can be changed by Group Policy. For more information on slow links, see the Software Installation and Maintenance section of Appendix F.

Administrators may want to create a variation on their standard operating environment to support mobile users. Administrators may find it best to manage these computers in their own GPO, and then use the Software Installation snap-in to publish software to these users by focusing the snap-in on the User Configuration node of the Group Policy snap-in.

Administrators need to customize or transform any Windows Installer packages for the software that these users need to install the key features of the software locally (on the hard drive of the user's computer).

As well, administrators might want to allow mobile workers to keep some software available on local media while they are traveling. For example, if a traveling professional makes a lot of presentations, bids, and quotes, it may make sense to allow them to have Microsoft Office 2000 on CD, so that if they ever need the source files to install or repair a feature while they are not connected to the network they can use the source media.

Administrators can do this by using the Microsoft Office Custom Installation Wizard to set the installation source of the Microsoft Office Windows Installer package to first look to the network software distribution point, and then look to local media.

Note: A Group Policy called Disable media source for any install exists in the Group Policy snap-in under the User Configuration\Administrative Templates\Windows Components\Windows Installer node. Verify that this policy is disabled if you want users to be able to install from local media.

Shared Computers: The Factory or Business Floor

In many organizations, users share computers. This is quite common on the factory floor, or in a business such as a bank, where tellers have the same job function, but may work at a different counter (and therefore computer) on different shifts.

In these environments, the software is often task-based, and while users change, the software does not (although the software may track who is logged in for transaction auditing).

Administrators may want to group these users or computers in a manner that would allow them to be managed from a single GPO, and then use the Software Installation snap-in to assign the software to the computers (either by the Computer Configuration or the User Configuration node of the Group Policy namespace). Assigning this type of software to the computer makes the software available for every user of that computer.

A key consideration is that software assigned to the computer installs when the computer restarts, and if computers restart between shifts, the time it takes to install the software will affect the total startup time of the computer. This increase in the startup time only occurs if new software has been assigned or the existing software is upgraded.

Best Practice Administrators should look into leveraging Remote OS Installation in shared computer environments, but it is particularly useful in the computer lab scenario, described below. If administrators ever have to rebuild the lab, they can do so in a quick and efficient manner.

Shared Computers: The Computer Lab

In many organizations, users share computers in a lab environment, typically for a short period of time (for example, while they are taking a class). This scenario differs from the previous shared computer scenario in that each user might use different software.

It is also likely that these computers do not move. Therefore, this is a case where using a site to manage software makes sense, although grouping the computers into a single OU also works. The key is to choose a method that allows you the right level of granularity for applying Group Policy and Software Installation and Maintenance.

Depending on the requirements, administrators might decide to assign software to the computer. This can work well if the software is written to keep user information (such as configuration information and saved files) separate from software information (such as the executable files).

Another way to manage this environment is to assign the software to the user, each with their own unique logon id. In this scenario, the software that the user requires would install when they log on, and users would only have the software that they are supposed to use.

Best Practice A Windows Installer package should be assigned or published no more than once in the same Group Policy object. For example, if you assign Microsoft Office to the computers affected by a Group Policy object, then do not also assign or publish it to users who will log into the affected computers.

The Roaming Worker

In many organizations, people move or roam from one location to another to perform their job. For example, a receptionist for one department may relieve another receptionist for breaks. A key point about roaming workers is that while they log on to different computers to perform their job, typically, the computer is connected by a high-speed or LAN connection.

If the users who roam from one computer to another have the same organizational role—for example, they are all receptionists—then assigning the software to the computer may be the best alternative. Thus, the software would already be installed for everyone that needs to use it.

If the users who roam from one computer to another have a different organizational roles, but roam to the same computer, then assigning the software to the user, or publishing the software may make the most sense. If you assign the software to the user, the software will install the first time they select it from the Start menu. If you publish the software, it will be available for the person to install from Add/Remove Programs in the Control Panel.

Moving Out of Scope

Administrators have to consider that they might move users or computers out of the scope of management. That is, they might have a user in an Active Directory container such as an organizational unit, and that organizational unit has a Group Policy object linked to it that assigns software to the user. If the administrator moves the user to a different organizational unit, then the Group Policy object that used to assign software to the user may no longer apply, and a different Group Policy object with different managed software may apply.

There are several parameters within the Software Installation snap-in to allow the administrator to manage these transitions.

The first parameter allows the administrator to remove software when it falls out of the scope of management. For example, administrators assign Microsoft Word within a GPO and they specify that the software should be removed if it falls out of the scope of management. A user that is managed by this GPO installs Microsoft Word and uses it. Then the user moves to a new department, is moved from one OU to another in Active Directory. As a result, the GPO with Microsoft Word assigned in it no longer applies. The next time this user logs on to their computer, Microsoft Word is removed.

If a different Microsoft Word (with a different transform) is assigned in the second GPO, then the administrator still wants the first Microsoft Word removed and the different Microsoft Word installed.

By default, the Uninstall this application if it falls outside of the scope of management check box on the Deployment tab of the Software Properties dialog box in the Software Installation snap-in is cleared (unchecked). Therefore, Word would be available, regardless of the fact that the user moved.

The second parameter allows the administrator to remove a version of the software that is already installed, if they are going to install a Software Installation and Maintenance-managed version.

In this scenario, if a user had already installed an unmanaged version of Microsoft Word and now the Software Installation and Maintenance feature is going to install a managed version of Microsoft Word, then the unmanaged version would be removed and the managed version would be installed.

Staging Computers: Bringing New PCs into the Organization

A lot of time is spent preparing computers when the organization first acquires them. Without regard to which Original Equipment Manufacturer (OEM) the organization purchases computers from, and how the OEM prepares the computers, many organizations take new computers, format the hard drives, and then configure the computer according to their standard configuration.

To reduce the costs of staging computers, administrators can use the Windows 2000 Remote OS Installation feature to stage and standardize their computers, and can install the organization's key software at the same time.

As an example, consider an organization that wants to bring in new computers and customize both Windows 2000 and Office 2000. To do this, administrators should do the following:

1. Set up and configure Remote OS Installation.

2. Use the Group Policy snap-in to create the appropriate Group Policy Object to manage the computers in the organization.

3. Create a software distribution point for Office 2000.

4. Customize (transform) Office 2000 the way they want it configured.

5. Use the Software Installation snap-in to assign Office 2000 to the computers in the appropriate GPO. If you assign the software to the user, the computer-assigned version can be uninstalled, and the user version advertised and then installed on first usage.

6. Install Windows 2000 on a computer, and configure the operating system as desired. The target computer does not have to have the same hardware, but it must use the same Hardware Abstraction Layer (HAL) as the computers that will install from the image. (The use of image in this context refers to a copy of all the operating system files).

7. Add the computer to the Active Directory container where it will live when it is deployed. This container has the GPO with Office 2000 assigned to the computer associated with it.

   Note: Care must be taken to configure this computer with software from the GPO where the computer will live when it is deployed. Otherwise the software may be removed and reinstalled if a different policy is applied to the computer.

8. Start the computer and Software Installation and Maintenance will install Office 2000 (software assigned to the computer installs when the computer starts).

After Office 2000 has been installed, the administrator takes the computer with Windows 2000 and Office 2000 on it and uses the RIPrep tool of Remote OS Installation to build a Remote OS Installation image, and then puts this image on the Remote OS Installation server.

After the Remote OS Installation image is available, a user getting a new computer that supports Remote OS Installation only has to connect the peripherals (keyboard, mouse, monitor), connect to the network (plug a cable between the network card and the hub), and turn on the computer. The computer will find the Remote OS Installation server and download the Windows 2000 operating system and the software. When the computer restarts after remotely installing Windows 2000, Software Installation and Maintenance detects that the Office 2000 is already on the computer, and then will only update the advertisement information. This update of the advertisement information only takes a few seconds.

Note: When users log on to the computer, and select the first Office 2000 application, they will see Windows Installer start. Why is this? Office 2000 is already installed, but Office 2000 properly separates installation from user configuration. The Windows Installer will start each time a new user starts Office 2000 to finish a small amount of user configuration. This will happen with Office 2000 regardless of whether Office 2000 is assigned to the user, assigned to the computer, published, or installed with Remote OS Installation.

The key point is that, using Remote OS Installation and Software Installation and Maintenance together, administrators can efficiently deploy both the operating system and other software, and bring the software into a state where it can be managed by Software Installation and Maintenance for future updates or removal.

Management Transitions

There are several scenarios where administrators will have to manage the transition of users and computers from a non-managed environment to a managed environment. For the purposes of this paper, a non-managed environment is any situation where the organization is using any non-Group Policy IntelliMirror-based software management solution. In this context, using Microsoft Systems Management Server represents a non-managed scenario. A managed scenario is one where an organization uses Group Policy and Software Installation and Maintenance to manage their software.

Consider the scenario where administrators need to roll out Microsoft Office 2000 on a Windows NT 4.0-based computer. They know that in the future they will deploy Windows 2000 and they want to be able to manage Microsoft Office 2000 with the IntelliMirror Software Installation and Maintenance feature. They know that in the future they will move computers with the unmanaged Office 2000 into the managed environment, and they want to ensure that they do not have to remove and then reinstall Office 2000.

In essence, this is similar to the Staging a New Computer case. Administrators want to install Office 2000 in a manner that allows it to be managed in the future. The key is to use a Windows Installer package and transform for Office 2000 that will be exactly the same as Windows Installer package and transform combination administrators will use when it is being managed.

Thus, if administrators can create the software distribution points now for use in the future, they can successfully transition the software.

To create software distribution points

1. Create the software distribution points that they will use, and install the software with Windows Installer packages and transforms.

2. Install the software using Windows Installer with the following parameters.

   C:\>msiexec /I \\servername\share\software.msi TRANSFORMS =  
    \\servername\share\software.mst /qb 
   

   Where software.msi is Windows Installer package to be installed, and software.mst is the transform to be applied at deployment time.

3. When administrators have their Active Directory and Group Policy infrastructure in place, they can assign the software in the appropriate GPO, using the same software distribution point, Windows Installer package, and transform.

4. Move the computer into an Active Directory container with the GPO, or link the GPO with the Active Directory container holding the computer.

Administrators should use the same Windows Installer package, the same transform, and the same software distribution point. In this case, the software will not be uninstalled and then installed again, but rather, the Application Management extension will detect that the software is the same, and it will only do what is necessary to continue to manage the software in the future.

Customizing Software

During the preparation phase, administrators typically customize software in two ways. First, they determine which features of the software add value in their organizations. Second, they add additional in-house templates, documents, and files with the software.

Best Practice In the past administrators repackaged software to customize it for their organization. Administrators should not repackage a Windows Installer package, instead, it is recommended that they create a transform and use that to customize the package.

Customizing Features: Native Windows Installer Packages

The best way to customize the installation of features for Software Installation and Maintenance is to leverage Windows Installer transform support. For example, Microsoft Office 2000 provides the Custom Installation Wizard, which allows administrators to tightly manage the configuration of Microsoft Office 2000.

Administrators should design their customizations so that the key features that users need (for example, in the case of Office 2000, Word may be a key feature), install during the first installation. Less used features, such as Redline support, or Document Translators, could install on first usage. Other features, such a Clip Art, may not be installed at all.

Administrators should also consider transforming the software in such a way that users can install features when they need them from Add/Remove Programs in the Control Panel.

Best Practice Management of the software distribution points can be complex. Administrators will find it easier if they store transforms at the same software distribution point (in the same share and folder) as the Windows Installer package that they customize.

Customizing Features: Repackaged Windows Installer Packages

While it is technically possible to transform repackaged software, administrators may find it just as easy to customize the repackaged software between the before and after snap-shots. As long as you are taking the time to repackage the software, make it work the way you need it at the same time.

Distributing Additional Files: Distributing Frequently Changing Files

Many organizations need to distribute additional files with software. For example, the organization may want to distribute a sales quote template with Microsoft Word, and a customized bidding spreadsheet with Microsoft Excel. These types of files could be bundled with the executable and other source files for the software when the administrator creates the package. Or, they could be included as a transform.

However, these files are often more volatile than the software files. Therefore, administrators may want to package these files in their own Windows Installer package. This package should have its own product code, and should be upgraded on a different schedule than that of the application. The package with the additional files will install faster than reinstalling the entire application.

Best Practice Create these additional file and template packages using one of the available native authoring tools for Windows Installer packages. It is a simple process to build a package to just distribute files, and the files can be compressed into Windows Installer package.

Managing Existing Software

Managing new software in the future should become easier as most software publishers will begin to support the Certified for Windows 2000 specification, and will distribute their software with Windows Installer packages and customization support.

In the short-term, the question becomes how to distribute software for which the publisher does not provide a Windows Installer package.

There are two ways to address this issue: using .zap files, and repackaging. Table 5 contrasts these methods.

Table 5 ZAP files and repackaging contrasted

	.Zap Files	Repackaging
Advantages	Easy to create Fast Application displays in Add/Remove Programs in the Control Panel	Benefits from Windows Installer features Can be run without user intervention Can be assigned or published User does not have to be (local) administrator to install Can automatically repair itself if key files are damaged or missing
Disadvantages	Runs existing setup, therefore will require user intervention Does not benefit from Windows Installer features May require user to have (local) administrator privileges to install Cannot automatically repair itself if key files are damaged or missing	It is time-consuming to build and test packages

Best Practice Use the Certified for Windows 2000 guidelines when you develop your in-house or line-of-business (LOB) applications to ensure that they perform well with Windows 2000 and applications that use Windows 2000.

Publishing Existing Setups: .Zap Files

Administrators can use Software Installation and Maintenance to publish existing setup programs. This means that the published software will appear in the Add/Remove Programs in the Control Panel, and that users will be able to install it from this location.

Because the administrator is publishing the existing setup, the experience for the user installing the software will be no better than using the existing setup. That is, if the user installing the software has to be a local administrator on the computer to install the software, then they have to be a local computer administrator to install the published existing setup. If the existing setup does not support clean and complete removal of the software, then publishing the existing setup will not improve the software removal experience.

The main disadvantage of using the existing setup is that it does not support management, especially management of the software lifecycle including pilots and upgrades. Another disadvantage is that you do not get the features of Windows Installer, including feature fault-in, repair, and clean removal when the software is no longer needed. Feature fault-in can be explained as follows. One of the checks that Windows Installer performs is whether a product feature or component is installed. If a feature is advertised, it is not installed yet, and an on-demand installation of that feature (or feature fault-in) can occur when a user tries to use that feature. For example, Office 2000 has many features such as a Spell Checker, Thesaurus, and so on. These can be configured to fault-in when a user tries to use them. Large applications, with features that may not be required by all users, can be configured so that components that are used infrequently will install on-demand rather than by default.

Best Practice One reason to do repackaging versus publishing existing setups is that Windows Installer packages can be installed automatically with elevated privileges.

For more information on .zap files, see Appendix D: The ZAP File Format.

Repackaging

A variety of tools are available that will allow administrators to repackage software into a Windows Installer package. The Veritas Software WinInstall LE program ships with Windows 2000 Server, and supports repackaging software as Windows Installer packages.

For additional information on creating Windows Installer packages, see Appendix A: Creating and Customizing Windows Installer Packages.

Maintaining Software

Patches and Quick Fix Engineering Fixes

From time to time, publishers of software provide patches. Software patches usually fix a single problem, and the amount of testing that is done on a patch varies.

After administrators have tested a patch and decided to deploy it, they copy the patched files to the software distribution point, replacing the older files. The software publisher who distributed the patch either supply a new Windows Installer package (.msi file), or a Windows Installer patch (.msp file). If they supply a new Windows Installer package, administrators simply replace the existing package at the software distribution point with the new package. If they supply a Windows Installer patch, administrators follow the supplied directions to apply the patch (.msp) to the existing package.

After the files at the software distribution point have been updated with the patched versions, administrators open the Software Installation snap-in within the Group Policy object where they are managing the existing software. Then they click on the software that they just patched at the software distribution point, and select Redeploy from the context menu. This causes the patched files to be copied to the users who have installed the software the next time Group Policy is applied.

Service Packs

Service packs don't differ significantly from patches. Service packs typically roll up several patches, and these patches have been tested. Service packs are usually distributed less often than patches, but more often than full upgrades.

If the service pack only updates a small number of files, the recommendation is to distribute and manage it like a patch. If the service pack updates a large number of files, the recommendation is to distribute and manage it like an upgrade.

In either case, follow the instructions supplied by the publisher of the patch and test this in a lab or with a small number of users before rolling it out to all users and computers that are managed by a Group Policy Object.

The plan for future Windows 2000 Service Packs is to distribute them in a manner that will allow them to be managed by the IntelliMirror Software Installation and Maintenance feature.

Upgrades

Upgrades typically involve major changes to the software. That is why they have new version numbers; a substantial number of files change for an upgrade.

The publisher of the software supplies a Windows Installer package for the new version, and that package should define which existing versions of the software the new package can upgrade. It should also contain instructions on how to perform the upgrade (which existing files can remain in place, which existing files should be deleted, and which new files need to be installed).

To begin the upgrade, administrators place the software application files with Windows Installer packages and transforms on the software distribution point, and then assign or publish the new version, using the Software Installation snap-in and then defining an upgrade relationship between the new and existing version. If the application being upgraded is known to the Windows Installer package of the upgrading application, then the Software Installation snap-in can automatically detect and create the upgrade relationship.

Administrators have to decide whether an upgrade is mandatory (immediately takes effect for all users who have the existing version installed) or optional (users can install the new version when they are ready to do so).

Software Installation and Terminal Server

Table 6 shows the interaction of the IntelliMirror Software Installation and Maintenance feature with Microsoft Terminal Server.

Table 6 The interaction of the IntelliMirror Software Installation and Maintenance feature with Microsoft Terminal Server

	Terminal Server
Software Installation	Remote Administration	Application Server
User Assigned	Software installation and maintenance works in the same manner that it does on Windows 2000 Professional.	Will not get applied; software will not be installed.
Computer Assigned	Software Installation and Maintenance works in the same manner that it does on Windows 2000 Professional.	Domain users with roaming user profiles may roam to an application server. Their application shortcuts will follow them. If the application server has the same application installed, the shortcuts will work. If the application is not installed, the shortcut will do nothing.
Published to Users	Supported for both Windows Installer packages and .zap Files.	Will not get applied; software will not be installed.

When installing the software on a Terminal Server Application Server, the administrator should follow the guidelines and directions that accompany Terminal Server, rather than attempting to assign software to the Terminal Server.

Software Installation and Maintenance and Multiple Language Issues

While Windows 2000 Professional has many locale and language settings, from the perspective of Software Installation and Maintenance, only the system locale matters. This is because the system locale impacts the code pages that are available, and code page availability, more than any other factor, affects how a multiple language or language-specific application behaves.

Applications or products typically support one language, and the supported language is expressed in Windows Installer package for the product. This is referred to as the product language in the rest of this section.

To determine whether to install a product of a particular language on Windows 2000 Professional with a particular system locale, Software Installation and Maintenance does the following:

• Checks to see if the Ignore Language parameter was set in the Software Installation snap-in for the managed package. If Ignore Language is set, the package is either advertised or installed, regardless of whether the system locale and product language match.

• If the system locale and the product language match, the package is installed (as appropriate for user assigned, computer assigned, or published).

• If the package language has been configured as English or Neutral, then this package will be applied to the target regardless of the target systems' locale setting. The locale affects the way programs display dates, times, currency, and numbers. You usually select the locale that matches your location, such as English (United States) or French (Canada). Note that the package can also be configured as Exact Match.

The following points should be kept in mind:

• Roaming between computers with different locales may produce unexpected results.

• Use caution when deploying applications with different product languages (for example, an English and German version of the same application) in the same Group Policy Object if the two applications have the same product code. If the two applications have the same product code, only one of them will be installed for users or computers. If you need to make the same application available to users in multiple languages, they must have different product codes.

Software Installation and Maintenance and Backup

Administrators must ensure that they back up any software distribution points they create to manage the deployment of software, packages, and customizations.

Software Installation and Maintenance relies on Group Policy, and Software Installation and Maintenance and Group Policy store information in both Active Directory and the Sysvol folder of domain controllers. Therefore, any backup and restore strategy has to take this into account and backup and restore both in a synchronized fashion.

For More Information

For the latest information on Windows 2000 Server, Change and Configuration Management, and IntelliMirror, see the Windows 2000 Server Web site.

Table 7 Additional Resources

For information on:	See:
Writing software that leverages Group Policy	The Application Specification for Windows 2000 http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnw2ksrv/html/w2kserve.asp.
Group Policy and Group Policy Objects	Windows 2000 Server online Help http://www.microsoft.com/windows2000/en/server/help/ and the Group Policy White Paper http://www.microsoft.com/windowsserver2003/techinfo/overview/gpintro.mspx.
Using the Group Policy snap-in and understanding the scope of management for Group Policy	The Group Policy Walkthrough at http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/grpolwt.mspx.
Remote Installation	Windows 2000 Remote Installation Services (RIS) Step-by-Step Guide at http://www.microsoft.com//technet/prodtechnol/windows2000serv/howto/remoteos.mspx.
The Windows Installer	The Windows Installer White Paper http://www.microsoft.com/technet/prodtechnol/windows2000pro/evaluate/featfunc/wispro.mspx.
The WinInstall LE Repackager	The WinInstall LE Repackager Walkthrough at http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/winstall.mspx

Appendix A: Creating and Customizing Windows Installer Packages

The technical information on Windows Installer is available in the Microsoft Developer Network (MSDN) http://msdn.microsoft.com/developer/. Specifically, Windows Installer technical information, including Windows Installer package schema, the details of Windows Installer Application Programming Interface (API), and sample packages and code are available in the Microsoft Platform Software Development Kit (SDK) http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sdkintro/sdkintro/devdoc_platform_software_development_kit_start_page.asp.

When to Natively Author Windows Installer Packages

For the best installation experience, organizations should natively author Windows Installer packages. Natively authored Windows Installer packages support all Windows Installer functions, including just-in-time feature installation, feature repair, and installation with elevated privileges.

To create native Windows Installer packages for their software, organizations must have:

• Access to all the source code, executable files, dynamic link libraries, and other resources

• An understanding of the application, and the registry entries, shortcuts, and other information that is needed for the application to run correctly

For example, an organization has in-house software that allows people to arrange their business travel. The organization has all the files for the software, and the developers understand how the software should be installed on users' computers. In this case, the organization could choose to natively author a Windows Installer package for the software.

For best results, the creation of the installation package and the software should be done simultaneously. That is, the creation of the setup should not be an afterthought at the end of the development cycle, but rather, the installation of the software should be a part of the overall architecture of the application.

For more details on the development considerations of integrating Windows Installer into software's architecture, see the article titled "Gain Control of Application Setup and Maintenance with the New Windows Installer" http://www.microsoft.com/msj/0998/windowsinstaller.aspx, in the September 1998 Microsoft Journal.

Well-functioning software requires more than just a Windows Installer-based installation. For additional information on state separation (keeping application data and user data separate), see the Certified for Windows 2000 information in Appendix C.

For more information on tools for natively authoring Windows Installer packages, see:

http://www.installshield.com

http://www.wisesolutions.com

http://www.microsoft.com.

Earlier in this document, it was suggested that Administrators could use Windows Installer to distribute files, templates, and other organizational data. Administrators can easily create these packages with a native package-authoring tool.

The following flow chart illustrates when to author native packages, repackage, or use Windows Installer package.

Repackaging Software

It is not always possible to natively author packages. For example, organizations may have software for which the publisher does not supply a Windows Installer package. Alternatively, the organization may have older software for which they do not want to create Windows Installer packages.

Repackaging allows an organization to benefit from Windows Installer. While repackaged applications are not as granular as natively authored applications (typically they have one large feature per product), the software can be advertised, repaired, and will install with elevated privileges.

The VERITAS WinInstall LE ships on the Windows 2000 Server distribution media (in the \valueadd folder). A walkthrough on how to repackage software with this tool will be available at: http://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/instmain.mspx.

Information on the full version of this repackager tool is available from: http://www.veritas.com/

Note: A beta version of a 'step-up' utility to convert Microsoft Systems Management Server Installer packages to Windows Installer packages is now available. For more information on the Installer Step-up Utility for Microsoft Systems Management Server, see