Software Installation through Group Policy works like this: You define one or more applications within a Group Policy object (GPO) in your Active Directory domain. When a user or computer processes that GPO, any applications that have been defined in Software Installation policy are installed. For example, if a GPO is linked to the Finance OU and you deploy Office using Software Installation policy, all users or computers in the Finance OU will get Office installed when that GPO is processed. Some qualifying conditions apply, and we’ll discuss them in this chapter, but essentially that is how it works.

Software deployed through Group Policy is referred to as managed software. Within the Group Policy, Software Installation policy is found under both Computer ConfigurationSoftware SettingsSoftware Installation and User ConfigurationSoftware SettingsSoftware Installation (Figure 9-1), which means you can deploy software on either a per-computer or a per-user basis.

Figure 9-1. Viewing the location of Software Installation policy

Generally speaking, per-computer applications are available to all users of a computer and per-user applications are available to individual users. The actual computers and users who have access to an application depend on the GPO you are working with. The access permissions on the application installer package and related installation files also can affect the deployment. If you are deploying software on a per-computer basis, the appropriate computer accounts must have Read access. If you are deploying software on a per-user basis, the appropriate user accounts must have Read access.

Note

Unlike most policies, Software Installation policies are only applied during foreground processing of policy and are not applied during background refresh of policy. Per-computer deployments are processed at startup and per-user deployments are processed at logon.

Before you deploy your software, you first need to have an installation package for the application you want to deploy. As discussed later in this chapter under "Deploying Software Through Group Policy," the installation package includes an installer file, which can be a Windows Installer package with an .msi extension or an application setup package with a .zap extension, and the application files that are needed to install the software.

The basic installation package can be customized in several ways. Typically, you’ll use transform files. These files, ending with the .mst extension, are used to modify the installation process so you can optimize the installation for various users or user groups. Transforms give you the ability to customize almost every aspect of a Windows Installer package for deployment. For applications that include a standard installer package, you might be able to obtain a utility for creating transform files. For most custom packages that you’ve created, however, you will likely have to rely on a third-party packaging tool to create transform files for those packages.

Note

Installation packages must be authored using the Windows Installer packaging format to take full advantage of policy-based installation and management. However, it is possible to deploy non–Windows Installer packages using Software Installation policy. The catch it that you don’t get any of the life-cycle management features using this method. See the "Deploying Software with Non–Windows Installer Packages" section in this chapter for more information.

Tip

Transform files are such a common method for customizing deployments of Office that Microsoft provides a customization utility in the Microsoft Office Resource Kit called the Custom Installation Wizard. You’ll learn more about this utility in the "Using Transforms to Customize an Office Deployment" section in this chapter.

In addition to the installation package itself, you need a distribution point on your network for making the package available to users and computers. This install location should be a network share that is available to the users and computers for which you are deploying the software. These users and computers must have at least Read permission on the share and the file system where the package and the related files reside. You should also consider the geographic location of the server hosting the share relative to the users and computers.

Tip

Plan the install location carefully. Once assigned, the install location cannot be changed in the GPO without redeploying the application.

Due to network latency or bandwidth issues, installation packages might need to be on a server in the same physical location or site as the users and computers. In some instances, you might want to consider using the Windows Distributed File System (DFS) service to geographically distribute these files across multiple server shares. Using DFS, you can create a logical directory structure that is independent of the location where the files are actually stored on the network.

Because DFS provides a virtual, rather than physical, file storage location, you never have to change the path to the package within the GPO. If you need to make a change, you can do so in DFS. For example, you might create a DFS root named \AppSvrdeployedapps and then create application-specific subdirectories under this share point. You can then locate the subdirectories on multiple servers and configure multiple physical links to the same logical directories. If one of these servers goes down or you have some other program, you can simply replace the link replica reference to point to a different server without ever having to change the package within the GPO.

Further, if you use Active Directory-integrated DFS, you gain several additional benefits:

Placing an installation package on a share is often a simple matter of copying the installer file and all of the necessary application files to your chosen install location. However, for some applications, especially Microsoft applications, a better solution is to perform an administrative installation to the share that you will be using to deploy the package.

Tip

For most Microsoft applications, you can initiate an administrative installation by passing the /a parameter to the setup.exe command.

The main reason for performing an administrative install rather than a straight file copy of an application’s setup files from the distribution CD-ROM is that you can directly patch an administrative install as future updates to the application become available. Once the administrative install is patched, you can use the Redeploy feature of Software Installation to have the updates applied to all target clients the next time policy is refreshed. This makes it much easier to keep an application package and the clients that have installed it up-to-date. The alternative—copying and executing the patch outside of Group Policy on each machine that requires it—is time consuming and labor intensive, so an administrative install usually makes much more sense.

Although Software Installation policy provides a versatile framework for deploying and maintaining software, the technology is better suited to department-level deployments than to enterprise-wide deployments. Why? Because some limitations apply to the technology that might affect your decision to use it for large scale deployments.

One key limitation is that policy can be used to distribute software only to computers running Windows 2000 or Windows XP Professional. While server versions of the Windows operating system might have the Windows Installer service, they cannot receive applications deployed through policy. Computers running Windows 95, Windows 98, or Windows NT Workstation also can’t receive applications deployed through policy. If your organization has client computers running any of these unsupported operating systems, you must deploy software using an alternative technology or technique. Microsoft Systems Management Server (SMS) and Intel LANDesk provide possible solutions.

The way in which deployed applications are sent over the network can be a limitation as well. With an enterprise solution such as SMS, you can schedule the application deployment and use multicasting. Scheduling the deployment allows you to install the application whenever you’d like, such as in the middle of the night when no one is on the network. Multicasting allows you to send one copy of the software over the network and have it be received simultaneously by multiple clients. This means you can potentially send an application once over the network and have it be received by all client computers on the network.

In contrast, with Group Policy, there is no scheduling or multicasting capability. Generally, client computers receive the deployed application when a specific, configurable event occurs, such as computer startup, user logon, or user activation, and you cannot otherwise control when the application is installed. Further, each client receives a separate copy of the deployed application that is sent over the network.

Another important limitation has to do with control over who receives a software package. Enterprise solutions such as SMS and Intel LANDesk feature built-in capabilities to limit which client computers get a particular software installation based on their configuration. You can, in fact, limit the deployment to computers that have a specific operating system or hardware configuration, as well as by previous versions of installed applications.

The key way to control who receives an application through policy is through the assignment of the GPO or through filtering. You can, for example, create a GPO, configure Software Installation policy, and then link the GPO to the Sales OU to have the GPO apply to all users in the Sales GPO. As discussed in Chapter 3 under "Filtering by Security Group, User, or Computer," you can apply a security filter so the GPO applies only to specific security groups within a site, domain, or OU. For more granular control, you can modify the security on the installer file itself, as discussed in the "Controlling Deployment by Security Group" section in this chapter.

You can also create a WMI filter to filter the application deployment based on operating system or hardware configuration, or based on existing applications that are installed. Although WMI filters can help you implement very advanced deployment scenarios, they can be tricky to use and they must be thoroughly tested before use. See the "Creating Software Deployment GPOs" section in this chapter for more details on using WMI filters.