You can use the Windows 2000 Group Policy feature to deploy and manage software to entire groups of users or computers without having to go to each computer and install the software.
The following sections discuss the Software Installation and Maintenance component of Group Policy: what it is, how to set it up and change options, and how to work with software packages you want to deploy.
The Software Installation and Maintenance component of the IntelliMirror technologies (see the sidebar entitled "IntelliMirror Technologies" later in this chapter) is an extremely useful tool for administrators. It can be used to make applications available for installation from across the network (that is, to publish applications), to automatically install applications on certain computers or on the computers used by certain groups of users, or to uninstall applications installed using the tool.
The following sections give a quick overview of how Software Installation and Maintenance works and discusses how Systems Management Server (SMS) relates to it, how to choose an installation package type, and how to decide whether to publish or assign applications.
Software Installation and Maintenance leverages Group Policy and Windows Installer to permit the easy deployment and management of applications in the enterprise. To deploy an application, you create or edit the appropriate Group Policy object (GPO) and add the application's native Windows Installer package to the user or computer policy, depending on whether you want it to apply to users or computers. Group Policy then makes the application available to the users or computers to which the GPO applies.
The next time a user logs on or a computer is rebooted, the relevant policy is applied to the user or computer and the application is automatically installed, added to a list of installable programs in Add/Remove Programs, or installed on first use from the Start menu. Windows Installer handles the automatic installation or uninstallation of all programs, as well as any upgrades or repairs.
IntelliMirror Technologies
IntelliMirror is a set of technologies that allows users' data, settings, and applications to follow them to other computers running Windows 2000, Windows XP, or the Windows .NET Server family on the network—or even off the network, in the case of laptops. The components of IntelliMirror are described here:
There is a lot of confusion about how IntelliMirror relates to Microsoft Systems Management Server (SMS) 2 and the new Microsoft Operations Manager (MOM).
When choosing whether to use IntelliMirror, SMS, or MOM, it is important to look at the features and implementation of the technologies (as well as RIS, which is closely related to IntelliMirror). The following list describes these technologies, highlighting their differences, and Table 25-1 summarizes the best mix of services for your type of network:
Although most documentation insists that only SMS can perform managed Windows upgrades, you can also use IntelliMirror to perform them, as discussed in the section entitled Adding a Package to a Group Policy later in this chapter.
Table 25-1. Technologies to use based on network type and client environment
Client Type | Simple LAN with High-Speed Interconnections | Complex LAN or Multiple Sites |
---|---|---|
Windows XP, Windows 2000 | IntelliMirror, RIS | SMS, IntelliMirror, RIS, MOM |
Mixed Windows environment with some legacy systems | SMS, IntelliMirror | SMS, IntelliMirror, MOM |
Legacy Windows clients (Microsoft Windows 3.x, Microsoft Windows 95/98/Me, Microsoft Windows NT) | SMS | SMS, MOM |
Before deploying an application using IntelliMirror, you need to decide whether to use a native Windows Installer package (if one is available for the application), to repackage the application, or to use a zero administration for Windows (ZAW) applications package (a .ZAP file).
Natively Authored Windows Installer Packages Without a doubt the best option for deploying software is to use a native Windows Installer package. Natively authored Windows Installer packages are created by the software manufacturer and have (hopefully) been tested extensively to make sure they work right. They usually support on-demand installation, where software components are installed when the user first requests them. For example, when a user chooses the WordPerfect Help command from Microsoft Word 2002 or the Word 2000 Help menu, the feature is installed automatically, but not until that point (Java buffs can think of this as just in time feature installation). Natively authored Windows Installer packages also self-repair when a key file is inadvertently deleted or corrupted.
Additionally, some natively authored Windows Installer packages can be modified to customize the applications for deployment. For example, Microsoft Office XP and Office 2000, as well as Microsoft Internet Explorer, can be customized for deployment.
More Info
To customize a Microsoft Office installation, pick up a copy of the Microsoft Office Resource Kit (available from Microsoft Press), which includes an Installation Customization tool. Customizing Internet Explorer is covered in Chapter 30.Repackaged Applications If you don't have a Windows Installer package for the application, you have the option of repackaging an application using a commercial authoring package from InstallShield or WISE Solutions; or you can use a light version of Veritas Software's WinInstall program, which is included with Windows 2000 Server. WinInstall LE is discussed later in this chapter.
Repackaged applications convey many of the advantages inherent in natively authored Windows Installer packages; however, repackaging is no panacea for legacy applications. When you repackage an application, you take a "snapshot" of a computer before the application is installed and then again after installing the application.
You then compare the two snapshots. The differences between the snapshots are used to determine what changes the application made during setup. The changes are then bundled up in a new Windows Installer package. However, if the client system installing the repackaged application differs from the system used to repackage the application, there could be problems, because the repackaged application has only very limited means of coping with differences (and therapy just hasn't proven effective).
There are a number of unpredictable things that can happen as a result of repackaging applications: .DLL files can get copied to incorrect locations, shortcuts can be copied incorrectly or broken, and the All Users folder could potentially be deleted after uninstalling a repackaged application. Technically speaking, repackaged applications can trash your system.
If that weren't enough, repackaged applications lack the ability to perform on-demand installation of software components: you can either install the entire software program or not (although Windows Installer can install the whole program on demand, it can not install individual components of the program). Repackaged applications also can't be seamlessly upgraded. You have to uninstall the existing version to install the new version, possibly losing user settings and preferences.
Although there are a lot of potential problems involved with repackaging applications, it can still be a useful method of deploying software, as long as you take proper precautions (as discussed in this chapter) and thoroughly test the repackaged applications before deploying them.
Instead of repackaging applications, when possible, learn how to automate the installation of legacy applications using installation scripts, and then bundle this in a .ZAP file, as described next and later in this chapter.
More Info
For more information on the disadvantages of repackaging applications, see Microsoft Knowledge Base article Q264478..ZAP Files The last option for applications not natively authored for Windows Installer is to create a .ZAP file. A .ZAP file is basically a special text file that points to the setup program for the application and can optionally run automated setup scripts.
This approach has some limitations. Because legacy applications that aren't repackaged can't take advantage of the Windows Installer service, .ZAP files are unable to do the following:
Despite these limitations, most users will find that using .ZAP files to deploy legacy applications is more reliable than repackaging applications because .ZAP files make use of the original installation program (it's unlikely that you could write a better setup routine than the program's original author, especially without access to more in-depth information about the program).
When deploying applications using Group Policy, you need to decide whether to publish the applications in Active Directory or assign them to users or computers. When you publish an application in Active Directory, it becomes available from Add/Remove Programs for those users to whom the Group Policy object (GPO) applies (you can't publish applications to computers). Assigning an application to a user or computer (don't assign or publish to both) makes the application available without any special action on the user's part. (Assigned applications appear on the Start menu and are installed on first use, unless you specify that they should be fully installed at the next logon.) Table 25-2 summarizes the differences between publishing and assigning applications.
Table 25-2. Differences between publishing and assigning deployed applications
Published Applications | Applications Assigned to Users | Applications Assigned to Computers | |
---|---|---|---|
When after deployment is the software available for installation? | After the next logon. | After the next logon. | After the next reboot. |
How is the software installed? | Through Add/Remove Programs in Control Panel. | Automatically on first use (icons are present on the Start menu and/or the desktop) | The software is automatically installed on reboot. |
Is the software installed when a file associated with the application is opened? | Yes. | Yes. | The software is already installed. |
Can the user remove the software? | Yes, using Add/Remove Programs. (Reinstallation is also supported.) | Yes, although the software becomes available again after the next logon. | No, although soft-ware repairs are permitted. Local administrators can uninstall software. |
What package types are supported? | Windows Installer packages and .ZAP files. | Windows Installer packages. | Windows Installer packages. |
Software Installation and Maintenance is actually fairly simple to set up and configure. Basically, you create a network share, copy the applications into it, and then add the installation packages to the appropriate GPO. The sections that follow tell all.
To deploy applications on a large scale, first create a file share on the server you want to use as a software distribution point. To do so, use the following steps:
Consider using Distributed file system (Dfs) to manage the software distribution point. Dfs allows you to use load balancing, fault tolerance, and file replication on these folders, increasing the availability of applications for users. Dfs is covered in Chapter 17.
Before you can add or administer deployed applications, you need to open the Software Installation snap-in. To do so, follow these steps:
Figure 25-1. The Group Policy tab of a domain's Properties dialog box.
If you want to be able to assign applications to computers, you need to add Domain Computers to the Security tab of the GPO.
Figure 25-2. The Group Policy console.
Real World
Planning Ahead
It's important to plan ahead when deploying software using Group Policy. If you have multiple user groups that need access to different programs, you can create multiple GPOs and use the Security tab to apply each GPO only to the desired group. Or you can change the security settings for individual programs within a GPO so that only certain groups have access to the applications (as discussed later in this chapter).
You can also create OUs to control deployment. For example, you might want to make a test deployment to a single OU, and then simply add the GPO to the domain and remove it from the OU after testing is completed (you should do this so that the policies aren't redundant; you don't want the same applications in multiple policies that apply to a user).
Also try to keep the policies as high up in the Active Directory tree as possible. If all users in a domain need Word and Microsoft Excel, put those applications in a GPO that applies to that domain, not in a separate policy for each OU.
Make sure that you don't set the users' disk quotas too low or they might not be able to install applications that you assign or publish. Also keep in mind that users need to have room for the temporary files created during software installations.
You can configure a number of options that control how software packages are deployed and managed. These options determine how packages are added to the Group Policy, the amount of control users have over an installation, and the default application for a given file extension, as well as which categories you can use for grouping applications. The following sections cover these options in greater detail.
Software Installation and Maintenance settings for applications deployed to users and groups are not shared with applications that are deployed to computers. Each type of deployment maintains its own set of applications and settings.
To change the default location for installation packages, specify how new packages should be added, change the level of control users have over installations, or specify that applications should be automatically uninstalled when appropriate, follow these steps:
Figure 25-3. The General tab of the Software Installation Properties dialog box.
Table 25-3. Default behavior options when adding new packages
Option | What It Does |
---|---|
Display The Deploy Software Dialog Box | Displays a dialog box asking whether you want to publish (User Configuration only) or assign the application, or whether you want to customize the configuration. |
Publish (User Configuration only) | Automatically publishes the application, using the default settings. |
Assign | Automatically assigns the application, using the default settings. |
Configure Package Properties | Displays the application's advanced properties, allowing you to customize the configuration. |
Choosing the Uninstall The Applications When They Fall Out Of The Scope Of Management check box can lead to a user inappropriately losing an important application. For example, if a GPO is applied by site and a laptop user travels to a branch office, the user might lose software if the branch office's GPOs don't include the same software applications. To avoid this, be careful when choosing this option, especially if you apply Group Policy by site.
Don't delete a GPO immediately after using it to uninstall applications; the policy is applied only when users log on or computers are rebooted, so if you delete the GPO before these events occur, the applications won't be uninstalled.
If you deploy more than one application that is capable of handling a given file format, you might want to change which application is used by default to open files of a given format. To specify which file extensions should be opened by which applications, follow these steps:
Figure 25-4. The File Extensions tab of the Software Installation Properties dialog box.
Application categories are extremely useful when you have a large number of published applications. When applications are organized by category, persons who use Add/Remove Programs to install published applications on the network can choose to view only the applications in the desired category, instead of seeing an unsorted list of applications.
Before you can assign an application to a category (which is discussed later in this chapter), you need to set up a list of categories. To do so, follow these steps:
Figure 25-5. The Categories tab of the Software Installation Properties dialog box.
Categories apply to the entire domain, not just the Group Policy object with which you're working. For this reason, the domain administrator should handle category creation centrally.
Group Policy, by default, considers all connections slower than 500 Kbps (kilobits per second) to be slow links. When Windows detects a slow link, it disables the following policies:
To change the connection speed Windows considers slow, use the following procedure:
Figure 25-6. The Group Policy Slow Link Detection policy setting.
Figure 25-7. The Group Policy Slow Link Detection Properties dialog box.
Besides changing what speed Group Policy considers slow, you can enable or disable the processing of certain policy items over a slow network link. To do so, use the following procedure:
Figure 25-8. Enabling a policy item to process over slow connections.
Of course, software packages are what the Software Installation and Maintenance part of IntelliMirror is all about. After you've set up the GPO and configured the general software installation options, you're ready to start adding software packages and working with them. The following sections help you add packages to the GPO, change their properties, upgrade and modify packages, and remove obsolete packages.
Before users can easily access applications that you copy to the software distribution point discussed earlier in this chapter, you need to add the installation packages to the GPO (see the section entitled Deploying Service Packs later in this chapter for specific information about publishing and assigning Windows service packs).
To add a package to your GPO, follow these steps:
If you want to apply any modifications (transforms) to the package, you must do so when adding the package. Transforms cannot be added to deployed packages.
You can use Group Policy to assign Windows upgrades to computers or publish a Windows upgrade to users. To do so, first verify that each computer in the GPO has sufficient disk space and is compatible with the version of Windows to which you're upgrading. Then copy the entire Windows CD to the software distribution point and add the Winnt32.msi package to the appropriate GPO, just like any other piece of software. After adding the package you might want to modify its security settings so that the upgrade only applies to certain computers or groups, especially if you assign the upgrade.
Figure 25-9. The Deploy Software dialog box.
You will see the Deploy Software dialog box only if you selected the Display The Deploy Software Dialog Box option in the Software Installation Properties dialog box, as described earlier in the section entitled Setting Software Installation Options. Otherwise, the package you selected is automatically published or assigned.
Creating .ZAP Files for Legacy Applications
If you want to publish an application that doesn't come natively authored for Windows Installer (that is, it comes with a setup file containing the .MSI file extension), you can either repackage the application as described later in this chapter, or you can create a .ZAP file.
A .ZAP file is a text file that points to the setup program for a legacy application. To create a .ZAP file, type the following text, replacing the file and computer names as necessary:
[Application]
FriendlyName="Your Application's Name"
SetupCommand=""\\servername\sharename\foldername\setup.exe""
Many installers will permit the recording or creation of installation scripts, which can then be used to automatically install the program once setup is launched by the .ZAP file. To do this for a program that uses InstallShield to install, use the following procedure:
For more information on using .ZAP files, see Microsoft Knowledge Base Article Q231747. For more information on scripting program installations, go to the support Web site for the installer program (InstallShield, Wyse, and so on), and perform a search for "silent install."
Once you've added a software package to a GPO, you might want to change the package's properties to change the application's category, deployment type (assign or publish), or security settings. Use the following steps to change these and other settings:
Figure 25-10. The Deployment tab of a software package's Properties dialog box.
Upgrading applications can be a pain for administrators. The new version of Microsoft Office is released and suddenly everyone wants it (or maybe not). In the past, this has often led to version management nightmares when some users couldn't read files created by other users, among other problems.
Fortunately, IntelliMirror's Software Installation and Maintenance features help a lot, because administrators can automate much of the upgrade process (SMS can upgrade applications as well).
When you get a new version of an application, you can start by publishing it (both as an upgrade for users with an earlier version of the application as well as a full installation for computers and users without an earlier version of the application).
After a period of time, you can assign the application to users, requiring them to either upgrade or install the new version in parallel with the old version (if you make that option available). At this time you can also prevent new installations of the old version. Once all users have had a chance to get accustomed to the new version, you can remove the old software package and force it to be uninstalled from users' systems, completing the transition.
Use the following procedure to install upgrades. See the section entitled Removing and Redeploying Packages later in this chapter for information on how to complete the process and remove obsolete packages.
You might find it useful to apply a transform to the upgrade package—for example, to allow Microsoft Outlook 2000 users simply to upgrade to Microsoft Outlook 2002 without installing the rest of Office XP. To do this, see the next section, Applying Package Modifications.
Figure 25-11. The Add Upgrade Package dialog box.
Select the Package Can Upgrade Over The Existing Package option to use the new package to upgrade the older package, preserving the users' settings. Click OK when you're done.
Select the Uninstall The Existing Package, Then Install The Upgrade Package option when a real upgrade either isn't possible (in the case of upgrading to a different application) or isn't desirable (when the upgrade process works poorly). You also need to select this option when upgrading a repackaged application.
Figure 25-12. The Properties dialog box for an upgrade package.
Package modifications, also called transforms, allow you to customize an installation package without completely re-authoring it. For example, instead of offering Microsoft Office XP only in its complete configuration, you may want to offer users the choice to install only Microsoft Word and Microsoft Outlook. Or you might want to offer users Office XP with the latest service pack already installed.
Because transforms are merely a way to modify a package for deployment, not a mechanism for allowing a single package to present multiple options to users and administrators, you still need to add the package multiple times—once for each transform configuration you want available to users. For example, if you want to deploy Office XP in its entirety (and not customized for your organization), you'd first deploy the standard Office XP .MSI package from the Office XP CD-ROM. Then you'd deploy transforms of this installation to allow users to quickly select a customized installation of Office (for example, it might only install Word and Outlook instead of the entire suite).
To add a transform, first create the transform (this process varies by program; for Microsoft Office, use the Office Resource Kit), and then follow these steps:
To see the Deploy Software dialog box in step 5, you must have selected the Display The Deploy Software Dialog Box option in the Software Installation Properties dialog box, as described earlier in the section entitled Setting Software Installation Options.
Do not click OK in the Properties dialog box until you have configured all settings the way you want them. As soon as you click OK, the package is assigned or published in Active Directory and is immediately deployed, potentially affecting a lot of users. If, after clicking OK, you realize you made a mistake, you can fix it either by upgrading the incorrectly configured package with a correct one or by removing the package from Active Directory and all users.
Figure 25-13. Placing transforms in the correct order.
When an application has outlived its usefulness in your company, it's time to remove it from all systems—or at least to stop deploying it on new systems. There are also times when you might want to redeploy an application so that it is reinstalled on all clients. Use the following steps to perform these tasks:
Figure 25-14. The Remove Software dialog box.