Configuring software deployment

The following excerpt, courtesy of APress, is from Chapter 4 of the book "Active Directory Field Guide" written by Laura E. Hunter. Click for the complete book excerpt series or purchase the book.

Configuring Software Deployment

You can also use Group Policy to deploy line-of-business applications throughout your Active Directory network. This installation can take place silently, without the need for user intervention or assigning elevated privileges to your users at the desktop level. Software that's installed via Group Policy is self-healing, which means that any application files that become corrupted or deleted will be replaced automatically by the Group Policy Object. Depending on the needs of your environment, Group Policy software deployment can allow a user's applications to follow him no matter where he logs on to the network from, or ensure that a specific set of tools is available on a particular machine no matter who logs on to it. In this section, we'll look at some of the most useful options available to you in using Group Policy to deploy software.

Creating an Installation Package

As long as you have an .MSI installer for the application you want to deploy, doing so through Group Policy is pretty much a snap. If your application does not have an .MSI file associated with it, though, you are still not entirely out of luck. You can create a .ZAP file that will still allow you to deploy the software, with the following caveats:

The installation process can't take advantage of elevated privileges for installation. So if your users are only members of the Users group and they need Administrator access to perform the installation, the deployment will fail.

The program can't be installed on the first use of the software—we'll talk about how .MSI does this in a moment.

You won't be able to install a feature on the first use of the feature, similar to how Microsoft Word can leave the Thesaurus function uninstalled, but you can copy it to the user's workstation the first time she tries to use it.

Most problematic of all, you can't roll back an unsuccessful installation, modification, repair, or removal of a .ZAP file the way you can with .MSI.

NOTE: With more and more applications complying with the Microsoft Logo Program, this is a much smaller concern now than it was even when Windows 2000 was first released.

To create a software installation package for an .MSI installer, follow these steps:

1. Open the GPO that you want to use from the GPMC console.
2. Navigate to User Configuration ➤ Software Settings ➤ Software Installation from either the Computer Configuration or User Configuration node. (You can also deploy software to computers instead of users; we'll talk about that in the "Understanding Deployment Options" section next.)
3. Right-click the Software Installation node and select New ➤ Package. Browse to the location of the .MSI file and click OK.

CAUTION: Since your network clients will need to access the .MSI file in order to perform the installation, be sure that it's located on a shared network drive and assigned the appropriate NTFS permissions.

4. The next screen gives you a choice of how you want to deploy the software: Published, Assigned, or Advanced. We'll go over the differences between these options next; for now select Published, which will install the application the first time a user clicks a file associated with it. (Double- clicking a .DOC file would launch the Microsoft Word installer, for example.)
5. Click OK to finish. The GPO Editor will take a moment to refresh itself, and then you'll see your software package listed in the Software Installation window. From here you can right-click the package and select Properties to change any deployment options.

Understanding Deployment Options

When deploying software, you need to make two major decisions:

Do I want to publish this software package, or assign it?

Do I want to deploy this software to a user object or a computer object?

In this section we'll look at the differences between these choices, as well as some more advanced options available for software deployments.

Publishing Applications

Publishing an application will make that application available to your users at their next login. Once you've published an application, a user can install or uninstall it by using the Add/Remove Programs applet in Control Panel. The installer will also launch through document invocation, that is, when the user tries to view or edit a file that requires the published application to open. This is a good way to roll out applications that might not be used consistently across your network, since you won't be performing the actual installation unless (and until) the user actively requires the software. Using Group Policy will still ease the installation process for your users since they won't need to remember share names or instructions for manually installing software.

NOTE: You can deploy published applications only to user objects, not computers. It makes a lot of sense since, after all, what are the odds that your workstation will decide of its own volition that it needs to install Microsoft Word one day?

You have a few additional options available to you when publishing a software package. When you right-click the package and go to Properties, you'll see the screen shown in Figure 4-6 by clicking the Deployment tab.

Figure 4-6

As you can see, the option to install the app when a user double-clicks the appropriate file extension is enabled by default. Two other options that you can enable are

Uninstall this application when it falls out of the scope of management: Let's say that user JSmith is contained in the Accounting OU of your domain and has the PeachTree accounting package installed via Group Policy. If JSmith moves to Marketing, and the Marketing OU does not have the accounting software published to it, then the application will be uninstalled from JSmith's workstation. This is useful in ensuring that sensitive applications do not remain installed on a workstation if the user no longer has a need for them.

Do not display this package in the Add/Remove Programs control panel: Just like it sounds, this ensures that a published application will only be installed through document invocation. You may enable this option to prevent applications from being installed unnecessarily by curious users.

Assigning Software

In addition to publishing an application, you can also assign it to either a computer or a user object. By assigning an application to a computer object, the application will be automatically installed the next time the computer boots up: this requires no document invocation or user intervention of any kind. Once the program has been installed, only an administrator will be able to uninstall it (either manually or through Group Policy). Like a published application, an assigned application is self-healing so that it can automatically repair or replace any damaged or erased program files.

Assigning an application to a user takes one of two forms. In the default scenario, the user will see a shortcut to the application on her Desktop or Start menu. However, the app won't actually be installed until the first time she double-clicks the shortcut or uses document invocation. And since the installation takes place silently, a user can easily be confused when he tries to launch the program and nothing seems to happen. It's important to be aware of this fact, since "I double-clicked the Excel icon and my machine has been hung up for like two minutes" can be a common help desk phone call in this situation.

While this was the only way of assigning software to a user in Windows 2000, Windows Server 2003 provides the Install application at logon option, which will perform an install as soon as the user logs on. Similar to the help desk calls you might experience from the default scenario, though, this option may greatly increase your users' logon times while the installation process is running. As with anything else, good communication with your users and support staff will help to make this operation as smooth as possible.

You'll typically assign software to computer objects for critical applications that need to be present on any computer on your network: antivirus software is a favorite use of this feature. Simply add the antivirus software's .MSI file to the Default Domain policy, and every machine in your network will receive the installation the next time they reboot.

CAUTION: Installing applications with large source files can create congestion in your network traffic, especially if a large number of users request the installation at the same time. (At 9 a.m. when they arrive at the office, for example.) Be sure to take this into account when deciding which programs to assign to your users and computers.

Deploying Custom Applications and Upgrades

For applications with many different parts, such as Microsoft Office, you can even configure the installation file so that it only installs the components you want. The remaining components can be left out entirely, or you can allow them to be installed on their first use: the first time a user requests the Word spell-checker, for example. To customize your applications in this way, you'll use a transform file with the .MST extension. You'll specify these .MST files on the Modifications tab of the software package's Properties sheet, which you saw in Figure 4-6.

Finally, once you've deployed a software package through a GPO, you can use a newer installer to upgrade that package using the Upgrades tab of the Properties sheet. An upgrade package can either be optional or mandatory, and the upgrade will take place the next time the user logs on or the machine boots up.

NOTE: Unlike other Group Policy settings that will refresh in the background every 90 minutes by default, software installation policies will only take effect at startup or logon. This is to prevent such catastrophes as a GPO trying to upgrade or uninstall a user's copy of Outlook while she's still trying to use it, for example.