As part of your planning, you should think carefully about the policy objects you will use to deploy software. Although you might be tempted to use existing site, domain, or OU GPOs, doing so limits your flexibility in terms of how you can deploy software. To see why, consider the follow example: You need to deploy Office 2003 in the Sales OU. You edit the GPO for the Sales OU and configure Software Installation policy. Later you find out that you need to deploy the software to the rest of the organization. At this point, you can edit the GPO for each additional OU or change the way you are deploying software; changing the way you deploy software is probably the better option.

Rather than editing individual site, domain, and OU GPOs to deploy software, you can create GPOs just for software deployment. Then, when you need to deploy software to a site, domain, or OU, you simply link the software deployment GPO to the site, domain, or OU. With this technique, it is usually best to create one GPO for each software application or category of application you want to deploy. For example, if you need to deploy Microsoft Visio, you can create a GPO called Visio Deployment Policy, configure the GPO to deploy Visio, and then link the GPO to the appropriate sites, domains, or OUs in your organization.

When you create and configure the software deployment GPO, you must consider who will receive the software. By default, the policy will apply to all users or computers within the site, domain, or OU to which you’ve linked the GPO. Sometimes this isn’t the behavior you want. For example, say you want all developers in the organization to have a copy of Visio but that developers are spread throughout the organization. The dilemma becomes: how do you deploy Visio only to developers without having to do individual installations on each developer system. One way to do this is to use your organization’s security groups to filter the policy application. If you configure security filtering on your software deployment GPO so that only members of the Developers security group have the policy applied, Visio will be deployed only to developers.

Some situations are more complex, however. For example, you might want to deploy Visio only to computers with a certain configuration, such as only the Dell Dimension 8300 computers in your organization. In this situation (and any other time you want to limit policy application based on system configuration, operating system assignment, or hardware), you must use a WMI filter. You create a WMI filter that detects the computer manufacturer and model, and then you link the WMI filter to the software deployment GPO so that only computers with this configuration have the policy applied. The WMI filter would look like this:

RootcimV2;Select * FROM Win32_ComputerSystem WHERE Manufacturer="Dell Computer
Corporation" and Model="Dimension 8300"

In this example, you use WMI to examine the Win32_ComputerSystem object and select all computers that have the manufacturer set to Dell Computer Corporation and the model set to Dimension 8300. Be sure to test this type of filter in your environment before rolling out into production.

Tip

When you use WMI filters, two key objects you’ll work with are Win32_ComputerSystem and Win32_OperatingSystem. A handy tool for digging into these objects and examining all the related values is Netsh Diag. With Netsh Diag, you don’t need to know any thing about WMI to access properties and determine the values you can use for filtering. The Microsoft Windows Command-Line Pocket Consultant (Microsoft Press, 2004) provides techniques for working with Netsh Diag, Win32_ComputerSystem, and Win32_OperatingSystem.

Software Installation policies are only applied during foreground processing of policy and are not applied during background refresh of policy. You can deploy applications in several ways:

When you want to completely automate a software installation, you can use assignment as your deployment option. You can assign the software on either a per-computer or per-user basis. Assigning software per-computer means the software is completely installed the next time the affected computer is restarted. Because the software is installed on a per-computer basis, it is available to all users who log on to the computer.

When you assign an application to a user, the default installation mode when that user logs on is to advertise the application rather than fully install it. Advertisement, also known as install-on-first-use, is a Windows Installer capability that can be leveraged by Group Policy. Advertisement essentially lets you provide install-on-demand software for users, and when used in conjunction with Software Installation policy, it provides a means to distribute software to only those who need it. This can reduce the need to maintain software where it’s not required, and you also do not have to explicitly perform an action to distribute an application when the user finally needs it.

Advertisements work on the basic principle that an application isn’t installed unless the user requests something that requires the application—whether it’s a document or a bit of functionality. To take advantage of advertisements, a Windows Installer package must be authored to present aspects of the application as advertisements rather than as a full local installation.

An application can advertise itself in three ways:

Another option for user assignment is to install the application when a user logs on. The logon process takes longer because the application must be installed.

The final deployment option is to publish an application and make it available on a per-user basis. When you publish an application to a user, the application is advertised the next time the user logs on. Unlike the previously described advertisement approach, this technique is limited. The application is advertised in Add Or Remove Programs and is also available for install-on-first-use. This means a user can install the application manually using Add Or Remove Programs or activate the installation by trying to open a file associated with the application.

You can see evidence of an advertisement by looking at the properties on a shortcut for an application that has been advertised. For example, in Figure 9-2, we assigned Visio 2003 to a user via policy. Note the value of the Target Type on the properties of the shortcut that was installed for Visio. It indicates that when the user clicks on this shortcut, Visio will be installed.

Figure 9-2. Viewing an advertised Visio shortcut

Regardless of the targeting method you use, the steps for actually deploying software via policy are essentially the same. To help you decide whether to target your software deployment to a computer or to a user, see Table 9-1, which summarizes the advantages and disadvantages of computer assignment, user assignment, and user publishing.