Software Installation and Maintenance

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 https://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)1® 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):

Figure 1: The Software Life Cycle

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.

Figure 2: An administrator's view of the distribution phase

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" https://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" https://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.

Figure 3: Publishing software for a user

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.

Figure 4: Assigning software to users

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.

Figure 5: Installing an assigned or published application by document invocation

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 migrate2 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 hardware3 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 https://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 https://www.microsoft.com/windows2000/en/server/help/ and the Group Policy White Paper https://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 https://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/grpolwt.mspx.

Remote Installation

Windows 2000 Remote Installation Services (RIS) Step-by-Step Guide at https://www.microsoft.com//technet/prodtechnol/windows2000serv/howto/remoteos.mspx.

The Windows Installer

The Windows Installer White Paper https://www.microsoft.com/technet/prodtechnol/windows2000pro/evaluate/featfunc/wispro.mspx.

The WinInstall LE Repackager

The WinInstall LE Repackager Walkthrough at https://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) https://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) https://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" https://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:

https://www.installshield.com

https://www.wisesolutions.com

https://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.

Figure 6: Deciding between native packages, repackaging, or using 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: https://www.microsoft.com/technet/prodtechnol/windows2000serv/howto/instmain.mspx.

Information on the full version of this repackager tool is available from: https://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 https://www.microsoft.com/smserver/techinfo/deployment/20/deployosapps/install_stepup.asp.

Administrators who do not want to repackage an application can always publish the software by creating a .zap file for the application. You can create a .zap file with any file editor such as Notepad. For an example .zap file, see Appendix D.

The .zap file resembles an .ini file. It is a text file that contains sections, and includes parameters and their values.

The following example shows all that is required in a .zap file to publish Microsoft Excel 97.

[Application]
FriendlyName = "Microsoft Excel 97"
SetupProgram="\\server\share\Excel 97\setup.exe"

Customizing Installations

Windows Installer applications support customization by means of transforms. Typically, the publisher of the software will supply a mechanism to create transforms. For example, Microsoft Office 2000 supplies a Custom Installation Wizard that builds them.

Native authoring tools and repackager tools can be used to create transforms.

Best Practice In the past, administrators often customized the software by repackaging it. Do not try to repackage applications that use Windows Installer. Rather, use transforms for additional customization.

Appendix B: Software Installation and Maintenance Glossary

Advertisement

The process of making an application that supports Windows Installer appear installed on the desktop, by installing the shortcuts for the application on the Start menu or desktop, and by populating the registry with the application information.

Advertisement Script

The output of the Software Installation snap-in, which advertises an application that supports Windows Installer. The advertisement script is stored in Active Directory.

Assigned

One of the modes of targeting supported by Software Installation and Maintenance. Administrators can assign the software that users require to perform their jobs. Administrators can assign software to users and to computers. User-assigned applications are advertised on the desktop; they appear to be installed on the user's desktop, but they get installed the first time that the user starts the application, typically from the Start menu. If a user deletes an assigned application, it will be re-advertised. Computer-assigned applications are installed the next time that the computer restarts.

Package

A Windows Installer database (file) that contains the instructions to manage the state of the software on a computer.

Published

One of the modes of targeting supported by Software Installation and Maintenance. Administrators can publish software to users. Published applications are not advertised on the desktop; there is no physical appearance of published applications on the user's desktop. Users install published applications from the Add/Remove Programs in the Control Panel or by activating a file type associated with an application.

Repackaging

The process of preparing software for distribution by taking a snapshot of a clean computer, then installing the software and taking a post-installation snap-shot of the computer. The repackaging software takes the difference of the two snapshots and creates the necessary installation instructions to reproduce the installation.

Software Installation snap-in

The Microsoft Management Console (MMC) that an administrator uses to manage software.

Transform

(Verb) The process of modifying or customizing a Windows Installer package.

(Noun) A Windows Installer customized package that, if associated with another Windows Installer package at deployment time, results in a customized installation.

Windows Installer

The Windows Installer is a Windows operating system-based service that can install, modify, repair, and remove software. The Windows Installer includes the operating system-based service, a package format, and an application-programming interface (API) that allows both the operating system and applications to interface with the service to install, modify, or repair the software.

Appendix C: Certified for Windows 2000

To assist developers to create manageable applications, Microsoft has published guidelines in the Certified for Windows 2000 program.

In designing and developing Windows 2000 IntelliMirror, every effort was made to support existing software. However, the ability to limit the TCO with this software is limited by the architecture of the software itself. For example, this software typically was not written to exploit new technology such as Windows Installer, and rarely separates user data and application data.

For additional information on writing software that leverages IntelliMirror and Group Policy, see the "The Application Specification for Windows 2000" https://msdn.microsoft.com/certification/appspec.asp.

Appendix D: The Zap File Format

Administrators can publish applications that use their existing setups by using the ZAP file format. The following sample ZAP file publishes Microsoft Excel. Use a text file editor, such as Notepad, to create the following text file. Then, save the file as Excel.zap in the network folder that contains the Excel 97 setup program.

Note: The .ZAP file created with Notepad may actually have a name of filename.zap.txt. Make sure that the extension of a ZAP file is .zap rather than .txt.

Comments are indicated by any line that starts with ';'. They explain the purpose of each entry in the file.

The underscore ( _ ) is a continuation symbol; these lines should appear together on one line.

Note that many entries in this file are optional.

; ZAP file for Microsoft Excel 97
[Application]
; Only FriendlyName and SetupCommand are required,
; everything else is optional
; FriendlyName is the name of the application that
; will appear in the software installation snapin
; and the Add/Remove Programs in Control Panel.
; REQUIRED
FriendlyName = "Microsoft Excel 97"
; SetupCommand is the command line that we use to
; run the applications setup. If it is a relative
; path, it is assumed to be relative to the
; location of the ZAP file.
; Long file name paths need to be enclosed in quotes. ; For example:
; SetupCommand = "long folder\setup.exe" /unattend
; or
; SetupCommand = "\\server\share\long _
; folder\setup.exe" /unattend
; REQUIRED
SetupCommand = setup.exe
; Version of the application that will appear
; in the software installation snap-in and the
; Add/Remove Programs in Control Panel.
; OPTIONAL
DisplayVersion = 8.0
; Manufacturer of the application that will appear
; in the software installation snap-in and the
; Add/Remove Programs in Control Panel.
; OPTIONAL
Publisher = Microsoft
; URL for application information that will appear
; in the software installation snap-in and the
; Add/Remove Programs in Control Panel.;
; OPTIONAL
URL = https://www.microsoft.com/office
; Language for the application, in this case US
; English.
; OPTIONAL
LCID = 1033
; Architecture, in this case, Intel.
; OPTIONAL
Architecture = intel
; the [ext] [CLSIDs] and [progIDs] sections are
; all optional
[ext]
; File extensions for which this application
; will "auto-install". They are not required if you
; do not want the application to auto-install. This
; entire section is OPTIONAL.
; Note: You can place a dot in front of the file
; extension. Text after the first = is optional and
; ignored, but the first = is required (or the whole
; line will be ignored).
XLS=
XLA=
XLB=
XLC=
XLM=
XLV=
XLW=
[CLSIDs]
; CLSIDs that this application will "auto-install"
; for. This entire section is OPTIONAL.
; Format is CLSID with LocalServer32,
; InprocServer32, and/or InprocHandler32 (in a
; comma separated list) after the =.
{00024500-0000-0000-C000-000000000046}=LocalServer32
{00020821-0000-0000-C000-000000000046}=LocalServer32
{00020811-0000-0000-C000-000000000046}=LocalServer32
{00020810-0000-0000-C000-000000000046}=LocalServer32
{00020820-0000-0000-C000-000000000046}=LocalServer32
{00020820-0000-0000-C000-000000000046}=LocalServer32
[progIDs]
; progIDs that this application will "auto-install"
; for. This entire section is OPTIONAL.
; format is a CLSID, with the corresponding progid
; listed after the = sign
{00024500-0000-0000-C000- _
000000000046}=Excel.Application
{00024500-0000-0000-C000- _
000000000046}=Excel.Application.8
{00020821-0000-0000-C000-000000000046}=Excel.Chart
{00020811-0000-0000-C000-000000000046}=Excel.Chart.5
{00020821-0000-0000-C000-000000000046}=Excel.Chart.8
{00020810-0000-0000-C000-000000000046}=Excel.Sheet.5
{00020820-0000-0000-C000-000000000046}=Excel.Sheet.8
{00020820-0000-0000-C000-000000000046}=Excel.Sheet
{00020820-0000-0000-C000-000000000046}=Excel.Template
{00020820-0000-0000-C000-000000000046}=Excel.Workspace

Appendix E: Microsoft Systems Management Server

IntelliMirrorTM, Remote OS Installation, and Microsoft® Systems Management Server (SMS) work together to offer a full complement of Change and Configuration Management features for Windows-based systems. This is a guide designed to help administrators select the right solution to configure and maintain users' desktops in their corporate computing environments.

IntelliMirror and Remote OS Installation are included as part of the Microsoft Windows 2000 operating system. IT administrators can use these features to manage Windows 2000 Professional users through centrally administered policies. Systems Management Server 2.0 complements IntelliMirror and Remote OS Installation, providing additional, scaleable options to support a full range of Windows-based computers and more complex environments.

Table 8 shows how each of these can be used separately or in combination to provide specific management functions.

Table 8 Putting IntelliMirror, Remote OS Installation, and Systems Management Server to optimal use

Management Function

Remote OS Installation

IntelliMirror

SMS

Install Windows 2000-based desktop images

Yes

 

 

"Follow Me" user environments (persistence of data, software, and settings)

 

Yes

 

Basic disaster recovery for Windows 2000-based systems

Yes

Yes

 

Inventory, advanced deployment, troubleshooting and diagnostic tools

 

 

Yes

Manage environments that are not Windows 2000-based

 

 

Yes

Comprehensive Change and Configuration Management for Windows

Yes

Yes

Yes

The Value of IntelliMirror

Using IntelliMirror, administrators can give users Follow Me functionality for their desktop environments. This gives users consistent access to their personal computing environments from any computer running Windows 2000 Professional, even if the computer is subsequently disconnected from the network.

IntelliMirror also gives administrators centralized control of each user's desktop resources, by applying Change and Configuration Management policies based on the requirements and location of users. The Windows 2000 Professional operating system uses these persistent policies to dynamically reconfigure and repair the desktop configuration of the logged-on user. This helps administrators reduce the support overhead associated with maintaining users' desktop environments, and simplifies the task of protecting user-generated corporate data.

At the core of IntelliMirror are three separate management functions:

• User Data Management: Policy settings that define the properties and locations of users' files, documents, and other information so that users' data is available both online and offline from any computer.

• Software Installation and Maintenance: Policy settings that define the installation, configuration, repair, and removal of applications, service packs, and software upgrades.

• User Settings Management: Policy settings that define both customizations and any restrictions that should be applied to the operating system, desktop environment, and applications for each user, including language settings, custom dictionaries, desktop configuration, and other user preferences and restrictions.

IntelliMirror features can be used on their own or teamed with other management features. For example, to augment the installation and maintenance functions of IntelliMirror in multi-LAN environments, IntelliMirror can be teamed with the Windows 2000 Distributed File System (Dfs) to provide a network of distribution servers. In more complex multi-LAN environments the User Data Management and User Settings Management functions of IntelliMirror can be used in conjunction with Systems Management Server to provide a broad range of features for Windows-based desktops.

The Value of Remote OS Installation

The Remote OS Installation feature works during initial startup, before the resident operating system has been loaded. It allows computer hardware that is connected using a LAN to find a networked computer running Windows 2000 Server, and request installation of a fresh copy of Windows 2000 Professional, appropriately configured for that user and that computer. The ability to automatically install the operating system by policy, without the need for additional technical support, can significantly reduce the IT support overhead in bringing new computers online and in reinstalling operating systems on computers in the field.

Remote OS Installation uses a Windows 2000 Server-based computer as a remote source, serving as the network equivalent of a CD-based installation of Windows 2000 Professional or a pre-configured Windows 2000 Professional desktop image. These work in the following manner:

• CD-equivalent installation: Similar to setting up a computer by using the Unattended Install options available on the Windows 2000 Professional CD. However, rather than residing on a CD, the source files are placed on Windows 2000 Servers and made available across the network.

• Pre-configured desktop image: Allows a network administrator to clone a standard Windows 2000-based desktop configuration, complete with OS configurations, desktop customizations, and locally installed applications. Once configured, the cloned image is stored on computers running Windows 2000 Server. On request, the server downloads these images to new computers. The new computer's hardware does not have to be identical to that of the computer on which the image was created, because the Windows 2000 Professional operating system support for Plug and Play can adjust for hardware differences.

Using IntelliMirror and Remote OS Installation Together

IntelliMirror and Remote OS Installation provide IT administrators the key management functions necessary for configuring and maintaining users' Windows 2000 Professional desktop environments in a Windows 2000 Server-based environment. One use of this is to provide a basic level of disaster recovery.

When used together, IntelliMirror, and Remote OS Installation offer benefits such as reducing the costs incurred in setting up new computers running Windows 2000 Professional. As well, together they provide dynamic configuration and repair, making it easy for users to log on anywhere in the network. Also, they provide better recovery from computer failures. Recovery capabilities include remote installation of operating system files in the event of operating system failure, repairing of application files in the event of a user inadvertently deleting managed application files, and protection of user data and settings by use of folder redirection and offline folders.

Whether a user is adding or replacing a computer, or returning a repaired computer to the network, Remote OS Installation provides the services to reload the operating system, while IntelliMirror provides the services to quickly regenerate applications and restore user data and personal computer settings.

The Added Value of Systems Management Server

In simple network configurations, where subnets are interconnected at LAN speeds, the combination of IntelliMirror and Remote OS Installation provides the features required to maintain a well-managed network of computers running Windows 2000 Professional in a Windows 2000 Server environment. However, as enterprises become more distributed and complex, IT administrators need to supplement this basic set of functions with advanced planning, deployment, and diagnostic tools. Systems Management Server provides these tools. Used together, IntelliMirror, Remote OS Installation, and Systems Management Server provide a comprehensive range of functions to track, maintain, and manage all Windows-based desktop computers in Windows NT-based and NetWare-based environments.

Specifically, Systems Management Server 2.0 adds the following management functions:

• Planning Tools: Systems Management Server uses Windows Management Instrumentation (WMI) and inventory scanning utilities to upload detailed hardware and software inventory information into a Microsoft SQL Server™–based repository. Additionally, Systems Management Server includes tools that can monitor and report on application usage, and check for product compliance such as Windows 2000 readiness, or Euro currency support. These planning tools help administrators to understand the configuration of their environment, complete audits and compliance checks, monitor and restrict application use, and plan for operations such as new software deployments and upgrades.

• Deployment Tools: Using Systems Management Server, administrators can schedule and synchronize the deployment of software to Windows-based computers. This distribution is fully integrated with inventory to allow sophisticated targeting, while also allowing detailed status reporting on the progress and success of each scheduled deployment. Systems Management Server is WAN-aware, allowing administrators to define what percentage of inter-site bandwidth can be used for management tasks. With Systems Management Server, an administrator can distribute and install software in the background to one, ten, or thousands of computers, even when no users are logged on.

• Diagnostic Tools: Systems Management Server provides a range of remote diagnostic tools to help manage desktops and servers without onsite visits. These include tools such as remote control and remote reboot, a Network Monitor with real-time and post-capture "experts" to analyze network conditions and performance, and a server health monitoring tool, which can track critical performance information on Windows NT®-based servers and Microsoft BackOffice® systems.

Which Software Deployment Method Should I Use?

In addition to their other functions, IntelliMirror, Remote OS Installation, and Systems Management Server each have a software deployment component. Each offers different capabilities, as follows.

Remote OS Installation is used specifically to deploy Windows 2000 Professional or company-standard Windows 2000 Professional-based desktop images. Remote OS Installation will reload the operating system or desktop image even where the existing system configuration is non-operational. (Note: The Microsoft System Preparation Tool used with a third-party cloning tool provides similar desktop image replication.)

IntelliMirror uses a pull model for software deployment. This provides a highly dynamic solution that makes software available to users as it is needed, installing software just in time. However, for a satisfactory end-user experience, IntelliMirror typically requires high-speed LAN connectivity between the client computer and the distribution server where the installable software is held.

Systems Management Server uses a push model to deploy software to computers or to distribution points, where it can then be locally pulled down onto a computer either by the user or through use of IntelliMirror. Using Systems Management Server, IT administrators can coordinate and schedule software deployments, allowing single- or multiple-phase rollout of software and even arranging for off-hours distribution and installation. Using the push model, Systems Management Server provides IT administrators with the ability to control and synchronize software deployments over multiple sites, helping to reduce compatibility issues that may otherwise occur.

Which Combination of Management Solutions Do I Need?

IntelliMirror, Remote OS Installation, and Systems Management Server (SMS) can be used either separately or together. Table 9, below, provides recommendations for the optimal combination of these for a given corporate computing environment.

Table 9 Comparing and management solutions

Client OS mix

Network Type

 

Single LAN/simple multi-LAN with LAN speed interconnects

Complex multi-LAN/multi-site systems

Windows 2000-based systems

Intellimirror Remote OS Installation

SMS Intellimirror Remote OS Installation

Mixed Windows environments, including Windows 2000-based systems

SMS Intellimirror Remote OS Installation

SMS Intellimirror Remote OS Installation

Windows 3.1 Windows for Workgroups Windows 95 Windows 98 Windows NT 3.51/4.0 based environments

SMS

SMS

Appendix F: Frequently Asked Questions

Windows Installer

This section addresses questions pertaining to Windows Installer.

What is Windows Installer?

Windows Installer is a Windows-based service that can install, modify, repair, and remove software. The Windows Installer includes the operating system-based service, a package format, and an application-programming interface (API) that allows both the operating system, and applications to interface with the service to install, modify, or repair the software.

Which Windows versions will have Windows Installer?

Windows Installer will be available for Windows 2000 Professional, Windows NT version 4.0, Windows 98, and Windows 95.

What software will use Windows Installer?

Microsoft Office 2000 will be the first software that Microsoft ships that will use Windows Installer. Other software from both Microsoft and other software publishers will also use Windows Installer in the near future.

How do I build a Windows Installer based installation?

If you are a developer, if you have access to the source code for the software, and you understand how the software should be installed, then you will want to natively author a Windows Installer package. There is a variety of tools available for natively authoring a package. For additional information on Windows Installer native authoring tools, visit these Web sites:

https://www.installshield.com/

https://www.wisesolutions.com

If you are an administrator, and you have existing software with a non-Windows Installer-based setup, then you can use a repackaging tool to create a Windows Installer package. Repackaging typically involves taking a snap-shot of a clean computer, running the software's existing installation program, modifying the files and registry entries for any customizations, and then taking a second snap-shot. The repackaging tool can then create a Windows Installer package from the difference between the two snap-shots. For additional information on Windows Installer repackaging tools, see https://www.veritas.com.

How can I deploy Windows Installer packages?

Windows Installer does not need information pertaining to how you get a package to the workstation.

For example, if you want to distribute your software on CD-ROM, you would burn a CD that contains Windows Installer package, the necessary files for the software, and an Autoplay.inf file to automatically call Windows Installer if the software is not found when the CD is inserted into the computer.

If you are deploying software to many users in a large organization, you could use a tool such as Microsoft's Systems Management Server (SMS). Microsoft SMS version 2.0 can deploy Windows Installer-based software to Windows 2000 Professional, Windows NT version 4.0 and 3.51, Windows 98, and Windows 95.

If you are deploying software to many users in a large organization, and all of the workstations are using Microsoft Windows 2000 Professional and Microsoft's Active Directory, then you can use the new Software Installation and Maintenance feature of Windows 2000 Professional to deploy Windows Installer-based software.

Can I customize a Windows Installer package?

You can transform or customize a Windows Installer package to handle a variety of customizations. For example, you can control which features are installed, and where they are installed (either on the local computer's hard drive or on a file server to run-from-the-network).

Many of the customizations that administrators used to perform by repackaging software will be better handled by transforming Windows Installer package.

Why use Windows Installer?

The Windows Installer works by managing the state of the installation. Because Windows Installer knows the state of the software, it can ensure that the software is installed correctly. If a problem occurs during installation, Windows Installer can also roll back the installation, ensuring that the computer is left in a working state.

The management of state also allows people to modify the installation, adding or removing features post-installation. This also supports repairing the software in the case where a key or necessary file is damaged. Using state to manage the installation also allows for complete removal of the software when it is no longer needed.

If I repackage an application on Windows NT 4.0, can I use the package on Windows 2000?

It is best to repackage applications on the version of the operating system on which they will be installed. Repackaging works best when the target computers are close to the reference computer. The main reason for this is that the setup that you are repackaging will often behave differently on different operating systems (for example, installing additional components, not installing others), and the package will only reflect the behavior for the operating system on which you repackage.

Can you double-click a Windows Installer package (.msi file) to install it?

Yes, if Windows Installer service is already on the platform.

Can you double-click on a Windows Installer package transform (.mst file to apply the transform to a package.

No. Transforms are associated with a package at deployment time, not at installation; that is, the association is made when the advertisement script is created.

An administrator has four applications they need to repackage. Is it better to make them one big package or four separate packages?

Four separate packages, so that Windows Installer service has the ability to better manage the installation state in the case of an installation failure. For example, if the installation of a package fails, Windows Installer can undo the installation. If four applications are in one package, and the first three install, and then there is a failure with the fourth package, all four will be removed.

Does a Windows Installer package have to have an executable file?

No, you can use Windows Installer to distribute files such as templates.

Software Installation and Maintenance

This section answers questions about Software Installation and Maintenance.

Can you use Software Installation and Maintenance with another software management tool?

Yes, there is no reason why an organization cannot use a variety of tools, such as Software Installation and Maintenance with Microsoft Systems Management Server. However, administrators need to take care that they don't target a single user with a single application from both systems.

Can you publish software so that it only shows up in the Add/Remove Programs in the Control Panel of some computers?

You cannot publish software to computers.

An administrator publishes software in an existing Group Policy Object (GPO). Users see the software in Add/Remove Programs in the Control Panel, even though they have not logged on since the software was published. Is this expected behavior?

Yes. Because the computer already has information about this GPO (it exists), the Add/Remove Programs sees the newly added application. The computer does not have any information about a new GPO until the user logs on.

Does Software Installation and Maintenance support metering?

There is no metering tool included with Software Installation and Maintenance. However, Software Installation and Maintenance should work properly with metering solutions (such as Microsoft Systems Management Server).

An administrator deploys a word processor with a transform that removes the spell check feature. Will the user see the spell check feature in the application?

It depends on how the application is written. Application developers should provide the appropriate visual clues to indicate whether a feature is installed or disabled, or can be installed on demand.

An administrator deploys a word processor to a user with spell check, and deploys the word processor to another user with a transform that removes the spell check. Both users log on to the same computer. What happens?

If the word processor was written to exploit Windows Installer (natively authored), then each user will get the application with the appropriate feature.

An administrator repackages a word processor with the spell check feature and deploys it to one user. Then they repackage the word processor without the spell check and deploy it to another user. They both log on to the same computer. What happens?

If the repackaged software installs to the same directory, then users may not have the features they should.

An administrator deployed software to users within a GPO that is associated with a site. What happens if a user roams outside of that site?

If the administrator deployed the software with the Remove this software if the GPO no longer applies option selected, the software will be removed.

If the administrator deployed the software without the Remove this software if the GPO no longer applies, the software would be in a non-managed state. If the user deletes the software, he or she would have to reinstall it.

An administrator installed Office 2000 on a computer with Windows NT 4.0. They upgrade the software to Windows 2000. How do they bring the software into a state where it is managed by Software Installation and Maintenance?

Note: If the application is published to the user, then the existing installation will only be converted to a managed state if the user chooses to install it via Add/Remove programs.

If administrators want to avoid the possibility of having an unmanaged installation of the application on the client computer, then they should select the option Remove previous installs of this product for users, if the product was not installed using Group Policy-based installation. This option is located on the Advanced Deployment option for the application. In this case, the existing application will be removed and the one deployed will be advertised when the user next logs onto the computer.

Which is best: to deploy software to install all features at initial installation, or install each feature on first usage?

In using Software Installation and Maintenance at Microsoft during development, administrators found that they had to carefully balance which features they installed initially and which features install on first use. If they installed most features on first usage, initial installation was very quick, but users became annoyed as features continually installed, as they were needed. On the other hand, if all features were installed at initial installation, installation time could be considerable.

An administrator deploys two different versions of software to users. What will happen?

Administrators should be careful not to deploy two different versions of the same software in the same GPO. If they do, there should be an upgrade relationship between the two versions.

How do I deploy software to users in a language other than English?

The Windows Installer supports locale; that is, you can create a specific package for a specific language. The Software Installation and Maintenance feature will then only install that package on a computer with that language (the administrator can also select ignore language to force all users to get a package without regard to language).

How do I set slow link detection for Software Installation and Maintenance?

Group Policy manages slow link detection for Software Installation and Maintenance. The specific group policies are:

• Policy

• Computer Configuration

• Administrative Templates

• System

• Group Policy

• Group Policy slow link detection

• Software Installation policy processing

• User Configuration

02/00

1	Microsoft
2	The use of migration in this context refers to an in-place upgrade, replacing only changed files, while preserving all other aspects of the application's configuration and personalization.
3	PC 98 Hardware Specification or higher. For more information on the hardware and network card requirements for Remote OS Installation, see the Remote OS Installation walkthrough, available from the Windows 2000 Server Web site.