Windows Server 2003 : Using the Group Policy Software Installation Extension & Finding the Right Mix of Services

Using the Group Policy Software Installation Extension

The Group Policy Software Installation extension enables you to deploy applications to computers in the domain or forest using Group Policy and includes the capability to do the following:

• Publish applications so that users can view and install programs from the network

• Assign applications to users or computers so that the applications are installed automatically when users need them or on the next restart or logon

• Target applications to different groups using Group Policy

• View installation status using Group Policy Results

To deploy an application, create or edit the appropriate Group Policy Object (GPO) and add the application’s Windows Installer package to either the user or computer policy, depending on whether you want it to apply to users or computers. The next time the user logs on or the computer restarts, Windows applies the relevant policy to the user or computer depending on the package settings you specify in the GPO. (See Table 1.)

Windows Installer handles the automatic installation or removal of all programs, as well as any upgrades or repairs.

Microsoft 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 Windows Server 2003 on the network—or even off the network, in the case of laptops. The components of IntelliMirror are as follows:

• User Data Management Allows users to access their documents and data from any computer on or off the network (in the case of synchronized laptops). This is done by redirecting the My Documents folder to a network share and then using the offline folders feature to ensure the ability to access the data when offline.
  

• User Settings Management More simply known as roaming profiles, this feature allows users to log on to any computer on the network as if it were their own computer, with all their application and Windows settings intact.

• Software Installation and Maintenance Allows administrators to deploy applications automatically to users using Group Policy.

• Remote Installation Services (RIS) Allows users to start a computer with no functioning operating system from the network, logon, and then select an approved operating system that Windows installs automatically.

Finding the Right Mix of Services

Look at the following details of the technologies (and Table 2) to determine the best mix of services for your type of network:

• RIS (Remote Installation Services) permits a user to start a computer (with or without an operating system) from a RIS server over the network and then automatically install Windows 2000 Professional, Windows XP Professional, or Windows Server 2003. RIS works much like using unattended answer files and disk imaging, but with greater ease of use.

• Group Policy allows users to access their data, settings, and applications from any computer on the network running Windows 2000, Windows XP Professional, or Windows Server 2003. Group Policy distributes data, software, and settings using a pull approach, meaning that the client requests data from Active Directory as needed. This approach works best when connectivity between the client and the nearest domain controller or software distribution server is at LAN speeds.

• SMS manages the deployment of software and operating systems on complex networks and networks with sophisticated software management requirements. SMS controls the deployment schedule, and it provides software inventorying and license tracking, as well as planning and diagnostic tools. SMS can push software to clients using almost any version of Windows. It can also push software to distribution points from which Group Policy either installs the software or allows users to do so. SMS includes rich reporting and inventory capabilities so that you can determine which installations were successful. SMS requires a significant investment of resources to install and configure on a complex network, so it is appropriate only for networks with sophisticated software deployment and management needs.

• Microsoft Operations Manager (MOM) provides an overarching management layer to Microsoft servers (including SMS), allowing you to monitor the network and determine what tasks need to be done. MOM is a powerful tool to use when the network gets so large that you need a way to manage your management tools.

Natively Authored Windows Installer Packages

A native Windows Installer package created by the software manufacturer for use with Group Policy is usually the best option for deploying software. Deployment is relatively simple and requires no user intervention, and natively authored Windows Installer packages can repair themselves if a key file is inadvertently deleted or corrupted. You can also create transform files for some packages. For example, you can create a transform file to customize a Microsoft Office installation so that only Microsoft Word and Microsoft Outlook are installed rather than the entire suite.

Zap Files

The easiest way to deploy applications that are not natively authored for Windows Installer is to create a .zap file. A .zap file is a text file that points to the 32-bit or 64-bit setup program for the application and can optionally run automated setup scripts. (Microsoft Windows Small Business Server 2003 uses a similar approach to application deployment.)

Although .zap files are simple and easy to create, .zap files cannot do the following:

• Assign applications to particular users or computers, though you can use a .zap file to publish applications

• Install applications with elevated permissions (Windows Installer gives higher permissions to installation programs so that a local administrator account isn’t needed to install software.)

• Install applications automatically on first use

• Perform partial installations of applications, with advanced features installed when needed

• Perform a complete rollback of an unsuccessful installation or enable applications to repair themselves

Despite these limitations, most users find that using .zap files to deploy earlier applications is more reliable than repackaging applications, because .zap files make use of the original installation program. (It’s unlikely that you can write a better setup routine than the original, especially without access to more in-depth information about the program.)

Repackaged Applications

If an application does not use Windows Installer to install itself, you can automate setup using an installation script and a .zap file, as discussed earlier, or repackage it into a Windows Installer package. When you repackage an application, you take “snapshots” of a computer before the application is installed using a commercial authoring package and then again after installing the application. The authoring package compares the two snapshots to determine what changes the application made during setup and then bundles the changes into a new Windows Installer package.

Repackaged applications convey many of the advantages inherent in natively authored Windows Installer packages; however, a number of hazards are involved as well. If the client system differs from the reference system used to repackage the application, problems can occur because the repackaged application has only very limited means of resolving differences. Repackaged applications occasionally copy .DLL files to the wrong locations or they break shortcuts. Additionally, the All Users folder can potentially be deleted after uninstalling a repackaged application. Technically speaking, poorly tested repackaged applications can trash the system. Also, repackaged applications aren’t easily upgraded—uninstall the existing version to install the new version.

Although there are potential problems, repackaging applications is a powerful way to deploy software if the repackaged application is thoroughly tested in a lab and pilot rollout before widespread deployment.

Deciding Whether to Publish or Assign Applications

An application published in Active Directory becomes available from Add/Remove Programs for the users to whom the Group Policy Object (GPO) applies. (As described earlier, applications are published to users, not computers.) An assigned application, on the other hand, can be assigned to either users or computers and is installed without any 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.

Assign essential applications to users or computers so that these applications are always available, and publish optional programs to make it easy for users to find applications when they need them. Do not assign or publish an application to both computers and users. Table 3 summarizes the differences between publishing and assigning applications.

^[*] By default, Windows XP clients process Group Policy asynchronously as a background refresh during startup and logon, which shortens startup times but requires two restarts to install assigned software to computers, or two logons to install software to users.

Updating Applications Deployed via Group Policy

The Group Policy Software Installation extension does not explicitly support updating applications. To update Microsoft applications, use Windows Server Update Services (WSUS). To update applications that WSUS does not support, use a third-party patch management application that supports the necessary applications, deploy the patches via login scripts, or instruct users to install the software updates from a network share (assuming the users are local administrators).

There are two other noteworthy methods of updating applications using Group Policy. The simplest method is to update the administrative installation or setup files in the software distribution point, and then redeploy the application . However, this method can cause the client computers to become out of sync if users use the Install On Demand or Detect And Repair features before reinstalling the application. When using this method, promptly update Group Policy for all affected users and computers so that the application is reinstalled before it can get out of sync. Be prepared for a surge in network traffic as the computers reinstall the application from the network. When a client computer is out of sync with the software distribution point, Windows might prompt users for an installation CD and refuse to install the updated version. To resolve this condition, try logging off or restarting the computer, or use a local administrator account to uninstall the application and then reinstall it using Group Policy. You can also use the Install This Application At Logon setting when assigning applications to users.

Another way to update applications using Group Policy is to make a copy of the administrative install or folder in the software distribution point containing the setup files. Update this copy and then add the updated application to the GPO as an upgrade to the existing application. This enables existing clients to continue to access the original installation files until Windows applies the GPO and upgrades the application. When using this method, copy the original GPO and use the copy for testing and pilot deployment. (Make sure that the copy has a lower link order than the original so that Windows applies it instead of the original.) Once you verify that the upgrade works properly, disable the original GPO (and eventually delete it).

Whichever method is used to update applications, test the method thoroughly in a lab before implementing it on a production network, and perform pilot deployments of updates or staged rollouts to mitigate risk.