One of the main functions of group policies in Windows 2000 is to enable change control, defining the actions that users can take and the rights and permissions they have within the enterprise and on their local computers. Group policies in Windows 2000 facilitate and provide a means for managing both change control and distributed security. They enable you as a system administrator to enforce restrictions that can prevent system changes and the resulting chaos that could ensue.
Another important use for group policies is to enable automated software installation. In this Daily Drill Down, we’ll explore the issues surrounding software deployment using group policies.
Overview of software installation
Automated software installation through group policies requires several components to function, one of which is Windows Installer. Because automated installation relies on group policies, clients must be running Windows 2000. Don’t forget that group policies are not supported on Windows 9x and Windows NT systems.
In addition, publishing applications for automated installation requires careful planning and several steps in order to accomplish it successfully. We’ll cover all of these issues, but first let’s take a look at Windows Installer.
Windows Installer and other packaging tools
You’ve no doubt used Windows Installer at one time or another to install an application, such as Office 2000. Windows Installer is Microsoft’s latest mechanism for performing software installation and removal. In addition to performing software installation, Windows Installer can perform application repair and reinstallation, perform targeted installations of specific features, and perform other “smart” installations. Windows Installer also performs smart removal, removing individual features or removing an application’s files, shortcuts, and registry entries.
Many applications, particularly those from Microsoft, are designed to use Windows Installer. The Installer defines the application and installation options through a package, which is an MSI file included with the application. The package functions as a relational database that contains all of the information necessary for the Installer to install and remove the application under different situations, such as performing a custom install, upgrading over an existing installation, removing the entire application, and so on.
An MSI file includes tables that define the application’s features for advertisement to the user during the installation process, the files associated with various features, information about where to install the application and its files, and so on. The data in the package is the key to the Installer’s ability to install application features on demand, also called “just-in-time” installation. If a feature isn’t installed, the Installer checks the package, determines how to install the feature, and automatically installs it. A package can include the CAB files (compressed archives) necessary to install the application or can point the Installer to the appropriate location on CD, disk, hard drive, network share, and so on for the files.
There are several applications you can use to create and/or modify Windows Installer packages. Which application you choose depends on whether you need to author new packages or simply modify existing ones. The following list summarizes the most common applications:
- Veritas WinINSTALL LE: This version of WinINSTALL is included with Windows 2000 Server. You’ll find additional information about WinINSTALL at Veritas’s Web site.
- InstallShield: InstallShield offers several versions and the ability to install cross-platform from a single installation package. You’ll find more information about InstallShield here.
- Wise Solutions:Wise Solutions offers several applications that enable you to create and modify installation packages.
- Microsoft Visual Studio Installer: This component of Microsoft’s Visual Studio development environment enables you to create and manage Installer packages. You’ll find more information about Visual Studio Installer at Microsoft’s MSDN Web site.
The route you take to package an application for automated deployment through group policies depends on whether you’ve developed the application yourself or need to install applications developed by others. In the former case, you will use an application that enables you to create a new installation package. If you’re installing an application from another company or developer, you’ll more than likely use an application to repackage the existing Installer package, making modifications as necessary to tailor the installation options to your users’ needs.
You also can use repackaging applications to create new Installer packages as well as modify existing ones. When creating a new installation package through repackaging software, you first start with a clean system on which only the operating system—and no other applications—is installed. You then take a snapshot of the system to record its registry, files, and other system state data. Then, you install the application and take a second snapshot afterward. The repackager determines the difference between the two snapshots and creates an Installer package that installs the application, applying registry entries, files, and other changes introduced by the installation.
If you choose to use a repackager, there are certain steps you should take to ensure trouble-free installations:
- Start with a clean system: This is a critical consideration. If you don’t start with a clean system, you’ll end up with other changes in the package (such as registry keys and settings) not intended for the application, potentially causing havoc on the target system after installation.
- Remove shortcuts created by the installation prior to the second snapshot: Typically, the application creates shortcuts to the application’s executable file(s) during installation. If you don’t remove the shortcuts prior to the second snapshot, you’ll end up with two sets of shortcuts, one installed by the Installer and the other added by the program’s installation process. Also, you should remove shortcuts to the application’s uninstall feature that are created by the application installation and instead rely on the user to use the Add/Remove Programs object in Control Panel to remove the application.
- Don’t restart the system prior to the second snapshot: In some cases, restarting the system introduces registry and other changes. Create the snapshot prior to restarting, and if the package doesn’t work, then repackage the application again, this time restarting prior to creating the second snapshot.
Customizing installer packages with transforms
You can think of transforms as exceptions that are applied to an Installer package at installation. Transforms are stored as MST files and enable you to tailor the installation to specific needs. For example, you might create a transform to use with the Microsoft Office installation package that installs certain applications and omits others that your users don’t need. You might use transforms to control which aspects of a feature are installed, such as converters, clip art, and so on, and where the application is installed.
Transforms are particularly useful for applying group-specific criteria to installations. For example, you might use one transform to install a particular application for the sales department with specific options and another transform to install the same application with different options for the support department. You might also use transforms to install additional files such as custom templates during the application-installation process.
You create transforms using the same authoring and packaging tools you use to create Installer packages. As you’ll learn a little later, you associate transforms with Installer packages when you publish the packages. How you create the transforms depends on the authoring tools you use, so include transforms in your consideration and evaluation of packaging tools and become as familiar as possible with them prior to starting your application-publishing process.
In addition to MST files, you can use software update (MSP) files to apply service packs, application patches, and application updates. Like MST files, MSP files modify an Installer package and work in conjunction with the package, not in place of it.
Using ZAP files
For those applications that don’t include their own Installer package file and that you don’t want to repackage, you can use a ZAP file. A ZAP file is a text file, much like an INI file, that contains entries that define the application’s source, setup executable, and other installation parameters. You use the ZAP file to publish the application’s installation parameters to Active Directory (AD), making the application available to users subject to the group policy objects (GPOs) that apply to them.
Rather than use the Windows Installer, these applications use their native setup mechanism. For that reason, they can’t take advantage of elevated privileges for installation, be installed on first use, add features on first use, or perform repair and rollback functions. Because creating ZAP files can be a tedious process, I recommend repackaging applications whenever possible.
The bottom line
Before you begin developing Installer packages or go too far with your automated application-installation plans, take the time to become as familiar as possible with the packaging tools you’ll be using. Each packaging tool can have its own issues, so taking a little bit of time up front will allow you to quickly address any problems or special considerations the tool may have. Once you’re comfortable with creating Installer packages and transforms, you’re ready to take the next step and begin publishing software for distribution.
Preparing for software distribution
You’ll need to rely on a handful of technologies to implement automated application distribution through group policies. First, you’ll need a mechanism to create the Installer packages, as explained previously. Active Directory (AD) is another important part of the puzzle. Group policies work within the framework of AD, and the installation information for your distributed applications will reside in AD. You publish the Installer packages to AD to make them available to users across the enterprise, subject to the group policy objects (GPOs) that apply to the users.
The GPOs are the mechanisms that enable you to apply application-installation control based on the user’s domain, organizational unit (OU), and so on. Because distributed application installation relies on AD and group policies, you’re limited to performing distributed application installations on Windows 2000 clients. Although Windows NT and Windows 9x clients can access AD through add-on client software, they don’t support group policies—a key component of your application-publishing strategy.
As you begin to plan your application deployment scheme, take a look at your AD’s structure and how it will affect or be affected by application publishing. For example, users who reside in domains that are served by slow links will have different requirements from users who reside in domains that are local to your distribution points or that are connected by high-bandwidth links.
Another important aspect of the planning process is to determine your users’ application needs and compare those needs against domain, OU, and group membership, against which ones are roaming users and which ones use the same computer all the time, and so on. You can then adjust your AD’s structure or refine your distribution plans to accommodate those needs and requirements. After a careful review, you’ll be able to decide where to create the GPOs in AD to serve each user’s applications needs and which policies to apply in each.
For example, consider creating OUs specifically for the purpose of publishing applications or adjust your existing OU membership for that purpose. OUs are a convenient means of targeting GPOs, thereby targeting specific applications or groups of applications to users who need them. Also take a close look at common application needs and deploy common applications high in the AD tree (such as at the site or domain level) to grant a broad range of users access to those common applications. This makes sense from an administrative standpoint because you can use a single GPO to publish those common applications to a majority of users, cutting down on the number of GPOs you need to create and manage.
Also examine your users’ needs in the context of multiple applications, where possible. Rather than deploy each application through its own GPO, deploy multiple applications through a single GPO in situations where multiple users have the same core application requirements. Doing so cuts down administrative overhead by enabling you to create and manage fewer GPOs. Performance is better as well, as the clients have to process fewer GPOs at logon. Also keep in mind that you can create a single GPO and link that GPO to multiple containers in AD, enabling you to use a single GPO to deploy applications at various levels in AD. This broadens the deployment but still minimizes administration.
As you’re designing your AD/GPO structure, also consider how multiple GPOs will affect users in terms of application deployment. You should avoid publishing the same application multiple times in the same GPO or publishing applications in multiple GPOs that affect the same user. Minimizing the number of places where applications are published simplifies administration and makes it much easier to determine which instance of an application applies to a given user.
After you finish defining the AD structure and deciding how GPOs will define application deployment and be linked to objects in AD, start creating or obtaining the Installer packages to be published in AD. These include the package (MSI) files, transform (MST) files, and update (MSP) files, as well as ZAP files for those applications that won’t use Windows Installer but instead will use their own setup programs. Once you have those in hand, you’re ready to start publishing them to AD. And as you’re putting together your applications and files, don’t forget to obtain the software licenses you’ll need prior to deploying the applications.
Setting up distribution points
One of the final steps in preparing to deploy applications is to create the distribution points from which users will install the applications. Before you reach this phase, you should have finalized any AD structural changes required by your deployment plans and put together the package files you’ll be publishing to AD. With that information in hand, you’ll be able to determine where the application distribution points should reside, considering client access issues, bandwidth considerations, and so on.
Where you locate the distribution points depends in large part on your network’s structure and how clients access the server or servers on which the distribution points reside. In a small network where all affected clients have access to the same server, you can create a single share to function as the distribution point. As the number of users and servers increases, however, you’ll need to employ other techniques to keep the process manageable. For example, you might use Microsoft’s Distributed File System (DFS) to build a distribution topology that enables users across the enterprise to easily access distribution points as needed. Keep in mind that creating the distribution points and making the applications available there is not a function of Windows Installer. Rather, it is purely a network administration function.
After you create the share that will serve as a distribution point, create individual folders under the share to contain each application. Then, copy the application’s files and its related Installer package files to its folder. How you place the files in the directory depends entirely on the requirements of the application. Some applications provide an administrative installation option specifically for the purpose of creating the folder structure in the distribution share necessary for installing the application.
Finally, apply permissions to the distribution share as needed to control access. Administrators should have read and write permissions, and users should have only read permission. Apply other permissions as needed according to your security requirements and network structure.
Evaluating other distribution methods
Because the focus of this Daily Drill Down is the application deployment offered by Windows 2000 through AD and group policies, that is naturally the first choice for distributing software. Taking advantage of those features, however, requires that all of the target clients be running Windows 2000. The reality is that you probably have a range of platforms to support across multiple domains and connections, and you can’t rely on this option alone. So, you should also consider how you will address the needs of your non-Windows 2000 users.
For example, in some cases you might decide to simply burn CDs for distribution to selected users who need specific applications, particularly if those users are located across slow links where a pull (client-side-initiated) installation just isn’t feasible. So, you create the Installer package and place it on the CD along with the installation files for the application and any support files, such as MST or MSP files, and an Autoplay.inf file that calls Windows Installer when the CD is inserted. The Installer checks the user’s system and, if the application is not already installed, starts the installation process.
Microsoft System Management Server (SMS) is another option for non-Windows 2000 clients and users who connect over slow links. SMS provides a push (server-side-initiated) installation and is useful when you need to deploy applications to a large number of users and want to carefully control how and when the deployment takes place. For example, you might want to use SMS for the sole purpose of performing a phased deployment during off hours. SMS is also the method of choice for determining client installation requirements before deployment and to implement licensing and metering requirements, as the software-deployment features in Windows 2000 don’t support those tasks.
Also, if you have a mixed-platform network running NetWare as well as Windows, you can employ ZENworks. ZENworks for Desktops is a very powerful utility that allows you to do such things as deploy applications, inventory software and hardware, do remote control, and deploy policy packages.
You probably spend a lot of your time deploying new applications or updating and fixing old ones on your network. This can become a very time-consuming chore. Fortunately, you can use group policies to help deploy applications on your network. In this Daily Drill Down, I’ve shown you how to prepare to deploy applications.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.