Preparation Phase
During the preparation phase, you determine how to centrally manage the software that is going to be available to users in your organization. To prepare for the deployment of new software in your organization, you must do the following:
Analyze your organization's software requirements by using your overall organizational structure within Active Directory and your available Group Policy objects.
Gather or create Windows Installer packages, or if necessary, determine the existing setup programs for the software that you want to install.
.gif "important-icon")
Important
It is your responsibility to acquire the appropriate number of licenses for the software that you deploy.
Analyze Software Requirements
Use the Windows 2000 Server components listed in Table 23.3 to assist you in documenting your overall organizational structure and the groups of users to whom you are going to deploy software. These components include Active Directory, Group Policy, and the Software Installation snap-in.
Table 23.3 Windows 2000 Software Installation Server Components
Component |
Overall Function |
Software Installation and Maintenance Function |
|---|---|---|
Active Directory |
The directory service included with Windows 2000 Server. It stores information about objects on a network and makes this information available to users and network administrators. Active Directory gives you an intuitive hierarchical view of the network and a single point of administration for all network objects. |
With Group Policy, provides the scope of management mechanism to locate users and computers and stores software installation and maintenance information. |
Group Policy |
A tool that allows you to centrally manage user and computer settings, software policies, scripts, application deployment, and security settings within Active Directory. |
Allows you to deploy applications within a Group Policy object that are associated with an Active Directory container such as a site, domain, or organizational unit. |
Software Installation snap-in |
An MMC snap-in that you use to assign or publish applications to users or computers. For more information about Software Installation, see "Software Installation" earlier in this chapter. |
Used to centrally manage the installation and maintenance and upgrade of applications. |
.gif "note-icon")
Note
You can use Microsoft® Systems Management Server (SMS) as an additional tool to assist with analyzing your existing organizational structure, including collecting details on software that is currently installed on existing systems. For information about how to use SMS to analyze your network infrastructure, see "Using Systems Management Server to Analyze Your Network Infrastructure" in the Microsoft ® Windows ® 2000 Server Resource Kit Deployment Planning Guide. The results of this analysis can help you to determine what network infrastructure changes that you might need to make prior to managing software with Windows 2000.
Active Directory
Plan your organization's Active Directory with software installation and maintenance and Group Policy in mind. In Active Directory, you create domains and typically base them on functional divisions. Another common reason to create a separate domain is because of bandwidth restrictions over a wide area network (WAN). If many of your users connect over slow links, you need to define an appropriate deployment strategy for those users. Domain design can influence or be influenced by the bandwidth necessary for your software management strategy.
Important
Because you manage software by using Group Policy, make sure to review the structure of Active Directory and determine which Group Policy objects apply to each Active Directory container, site, domain, and organizational unit.
For more information about Active Directory, see Windows 2000 Server Help. ** For information about expanded guidelines for domain planning, see "Active Directory Logical Structure" in this book.
Group Policy
Companies benefit from Group Policy–based centralized administration because both users and computers have the applications that users need to do their jobs, no matter what computer they are using.
By using Group Policy, you specify requirements for your users' environments, and then you can rely on Windows 2000 to continually manage these requirements. You can use the software installation and maintenance technology built into Group Policy to centrally manage software, whether it is assigned to users and computers or published to users. For example, by using Group Policy, you can tightly manage task-oriented desktops and assign specific software, thus creating a resilient and tamper-proof environment. If you need a more adaptable environment for roaming users, you can set Group Policy to provide the flexibility to install applications from the server or another location such as a CD or other form of removable media.
Group Policy security settings filter the users or computers that receive specific software. As a best practice, separate user and computer restrictions by organization-wide concerns and department or organizational unit concerns. This helps determine which Group Policy settings you apply at the site level and which you apply at the domain and organizational unit level.
Table 23.4 describes strategies and considerations for applying software deployment policies by using Group Policy and Active Directory. Use the strategies that meet your business goals.
Table 23.4 Strategies and Considerations for Software Deployment
Strategy |
Consideration |
|---|---|
Create organizational units based on software management needs. |
Allows you to target applications to the appropriate set of users. Group Policy security settings are not required to target the appropriate set of users. |
Deploy software high in the Active Directory tree. |
Makes it easy to provide all users in an organization with access to an application. Reduces administration because you can deploy a single Group Policy object rather than having to re-create that object in multiple containers that are lower in the Active Directory tree. |
Deploy multiple applications with a single Group Policy object. |
Reduces administration overhead by allowing you to create and manage a single Group Policy object rather than multiple Group Policy objects. The logon process is faster because a single Group Policy object deploying 10 applications processes faster than 10 Group Policy objects deploying one application each. Appropriate in organizations where users share the same core set of applications. |
Avoid publishing or assigning one application multiple times in the same Group Policy objects or in a series of Group Policy objects that might apply to a single user or computer. |
Makes it difficult for you to determine which instance of the application applies to the user or computer. |
Keep in mind that when you manage software installation and maintenance, Group Policy can be applied sequentially at the following levels within Active Directory:
Site
Domain
Organizational Unit (OU)
Note
There is no support for Group Policy that is installed on client computers that are running Windows NT 4.0 or earlier, Windows 98, or Windows 95; therefore, software installation and maintenance supports the management of software on Windows 2000 Professional.
Gather or Create Windows Installer Packages
After you have analyzed your organization's software requirements, you can gather or create your Windows Installer packages. You can only assign or publish software by using Software Installation if the file type fits one of the following categories:
Native Windows Installer package (.msi) files that are developed as a part of the application and take full advantage of Windows Installer.
Repackaged application (.msi) files that you use to repackage applications that do not have a native Windows Installer package in much the same way that you repackage software today to customize installations.
An existing setup program — an application (.zap) file — that installs an application by using its original Setup.exe program. (These files can only be published.)
Native Windows Installer Packages
Native Windows Installer packages provide the best overall software installation and maintenance experience. Native Windows Installer packages are developed as a part of the application and take full advantage of Windows Installer. 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. Native Windows Installer packages support on-demand installation, meaning that you can set individual application features so that they do not install until the user actually uses them. For example, Help files are not installed until the user attempts to gain access to Help within the application. These packages also support self-repairing applications if an application is corrupted. For example, if a user accidentally deletes Winword.exe, Microsoft® Word recognizes that a critical file is missing and reinstalls it. Tools are available from a variety of third-party tool vendors that developers can use to create Windows Installer packages. For more information about creating Windows Installer packages, see "Windows Installer" earlier in this chapter.
Repackaged Windows Installer Packages
Repackaged Windows Installer packages provide the next best software installation and maintenance experience. You can repackage applications that do not have a native Windows Installer package in much the same way that you repackage software today to customize the installation. The only difference in repackaging software with a Windows Installer repackager is that the output of the repackaging operation is a Windows Installer package rather than a package in a proprietary format. Repackaged applications work in the same way that native Windows Installer packages do. However, a repackaged Windows Installer package contains a single product, and all components and applications associated with that product, that is installed as a single feature. Native Windows Installer packages contain a single product that is made up of many features that can be individually installed.
Using Existing Setup Programs
In some situations, you might not be able to justify developing a native Windows Installer package or repackaging the application to create a Windows Installer package. To publish these existing software applications, you need to define the Setup.exe or Install.exe files into a .zap file to deploy them.
A .zap file is a text file that contains instructions about how to publish an application. You can use .zap files for applications to be phased out within a few months. A .zap file does not support the features of Windows Installer. For example, if an application requires a user to have administrator privileges to install it, preparing the application as a .zap file and publishing it still requires the user to have administrator privileges, whereas you can control these privileges in a Windows Installer package. When you deploy an application by using a .zap file, the application is installed by using its original Setup.exe program. The software is published so that users can select it only by using Add/Remove Programs in Control Panel.
Customizing Software
After you have your software in the necessary package format, you might decide that you want to customize the software for your organization. For example, you might want to remove unnecessary features from an application, such as clip art, and add customized templates. In the past, if you wanted to customize the installation of software you had to either adjust the setup program instructions, which was both difficult and problematic, or repackage the software after it was installed. The Windows Installer package format addresses this customization issue by allowing you to transform the original package. With Windows Installer, you can create a transform . A transform is a specialized Windows Installer package that when associated with a Windows Installer package at deployment time modifies the original Windows Installer package.
You can use the following file types to modify an existing Windows Installer package:
Transforms (.mst files), also called modifications, provide a way for you to customize the installation of an application by using software installation and maintenance. You can use transform files to deploy the specific features of the software to match the needs of the users. For example, you can include or exclude specific features of an application to provide a set of features that users require to do their jobs. For more information about transforms, see "Customizing Windows Installer Packages" later in this chapter.
Software patches, service packs, and some software update (.msp) files, including bug fixes, can be distributed by using the .msp file type and can be used to update an existing .msi file. An .msp file is a package modification that provides instructions about applying the updated files and registry keys in the software patch, service pack, or software update.
You cannot deploy an .mst or .msp file alone by using software installation and maintenance; the file must modify an existing Windows Installer package.