|
|
|
|
|
|
|
|
|
|
|
| Active Directory® for Microsoft® Windows® Server 2003 Technical Reference |
|
|
|
|||||||||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||||||||||
Chapter 12: Using Group Policies to Manage Software
- Windows Installer Technology
- Deploying Software Using Group Policies
- Configuring Software Package Properties
- Setting the Default Software Installation Properties
- Installing Customized Software Packages
- Updating an Existing Software Package
- Managing Software Categories
- Configuring File Extension Activation
- Removing Software Using Group Policies
- Using Group Policies to Configure Windows Installer
- Planning for Software Distribution Using Group Policies
- Limitations to Using Group Policies to Manage Software
Chapter 12 Using Group Policies to Manage Software
Chapter 11, "Introduction to Group Policies," provided an overview of the basic features of, and how to deploy and manage, group policies in Microsoft Windows Server 2003 Active Directory. This chapter and the next chapter detail what you can actually do with group policies. This chapter discusses using group policies to manage software on client computers. Chapter 13, "Using Group Policies to Manage Computers," discusses several other ways that you can manage user desktops using group policies.Managing software on client computers is one of the most important tasks that you will perform when managing a corporate network. The software installed on client computers includes the tools that users must have to get their work done. In many companies, a desktop computer will have a regular office suite of applications, such as Microsoft Office, as well as a wide variety of business-specific applications. In most companies, the standard client computer also requires a file compression application, antivirus software, and other applications.
Managing the software on user desktops can be a very labor-intensive task if an administrator must visit each desktop every time a new software package needs to be installed or upgraded. In a large company, just dealing with application errors can require several full-time administrators. In some cases, software updates must happen on a nightly or weekly basis. Many companies update their antivirus software at least weekly.
Using group policies to manage software can significantly reduce the effort required to manage user desktops. In fact, one of the biggest cost savings to be gained from deploying Active Directory directory service and group policies is in the area of software management.
Managing software in a corporate environment consists of much more than simply deploying the software. Many companies have a clearly defined software life-cycle management process that includes purchasing or building and testing the application, piloting the application to a small group of users, wide-scale deployment of the application, maintenance of the application after deployment, and finally, the removal of the application. Group policies in Active Directory can make most of these tasks more efficient.
Windows Installer Technology
In most cases, software management through group policies relies on the Microsoft Windows Installer technology. Windows Installer technology is used to install, manage, and remove software on Windows workstations. Windows Installer technology consists of two components:
- A software installation package file (.msi file) The .msi package file contains a database of information that contains all the instructions required to install and remove applications.
- The Windows Installer service (Msiexec. exe) This service manages the actual installation of software on the workstation. The service uses a dynamic link library (DLL) named Msi.dll to read the .msi package files. Based on the content of the software installation package file, the service then copies application files to the local hard disk, creates shortcuts, modifies registry entries, and performs all the tasks listed in the .msi file.
Using the Windows Installer technology has a number of benefits. One of the most important benefits is that any application can be largely self healing. Because the .msi file contains all the information needed to install the application, the same file can be used to repair an application that has failed. For example, if an application fails because a critical file has been deleted, the application will fail to start the next time the user selects the application. If the application has been installed using Windows Installer, the same .msi file that was used to install the application will be used to repair the application by reinstalling the missing file. The .msi file also enables cleaner uninstalls of applications.
Most software manufacturers now provide a .msi software installation package file with all new software. This is known as a native Windows Installer file. If the software includes a .msi file, you can use that file to install the software.
Creating a .msi file
In some cases, you might not have a native Windows Installer file. You might have an older application that does not have a native installer package. If you want to use Windows Installer technology to deploy the application, you can create a .msi file to distribute the software.To create an .msi file, perform the following steps.
- Create a clean installation of the operating system where you are going to create the installation software package file. No additional software should be installed on the operating system. The operating system that you use for this computer should be the operating system that will be running on the computer where you will be installing the application. If you want to install the application on both Windows 2000 and Windows XP Professional, usually you must create two separate .msi files.
- Use a software packaging tool to take a snapshot of the operating system before you install the software. There are several software packaging tools available from vendors such as Wise.
- Install the application on the workstation. Normally, you will use the native software installation process.
- After you have installed the application, customize the application as you want. For example, you might want to create or remove shortcuts, add templates to a custom location, or customize the toolbar on the application. In some cases, you must open the application at least once to fully install all the components.
- Use the software packaging tool to create a second snapshot of the workstation. This process creates the .msi software installation packaging file.
Once you have created the .msi file, you can use the Group Policy Software Installation process to distribute the software to the workstations.
Deploying Software Using Group Policies
After you obtain or create the Windows Installer file, you can deploy the application using group policies in Windows Server 2003 Active Directory. Group policies provide a means to advertise or make the application available for installation to workstations or users. After you configure the appropriate group policy, the next time the computer boots up, or the next time the user logs on, the fact that the new software package is available is advertised to the computer. The application is then ready to be installed on that computer.Before you can advertise an application to users on the network, you must copy the software installation files, including the .msi file, to a network share that is accessible to all users. When you create the network share, you must ensure that all users or computers have appropriate access to the share. If you are assigning applications to computers, the computer accounts must have Read access. If you are assigning or publishing applications to users, the users must have Read access. (See the next section for details about assigning applications versus publishing applications.)
Deploying Applications
After creating the network share and copying the installation files to the share, you are ready to implement the Group Policy Objects (GPOs) that will advertise the application to the clients. You can create a new GPO or modify an existing GPO. The first choice that you have to make when configuring the GPO is whether you want to advertise the application to computers or to users. If you decide to advertise the application to computers, you will use the Computer Configuration\Software Settings container in the Group Policy Object Editor, and the application will be installed on the workstation the next time the workstation is rebooted. If you decide to advertise the application to users, you will use the User Configuration\Software Settings container in the Group Policy Object Editor, and the application will be available to the user the next time the user logs on.
When you use a group policy to install applications, you have two choices for how the application will be advertised to the client. The first option is to assign the application, which can target either a computer or a user. The second option is to publish, which makes an application available, but only to user accounts.
When you assign an application to a computer, the application is completely installed the next time the computer is rebooted, which means that the application is installed for all users of a computer the next time they log on to that computer.
When you assign an application to a user, the application is advertised the next time the user logs on to the network. You can configure how the application is advertised, but most of the time, the application is added to the Start menu. The application is also added to the published applications list in the Add Or Remove Programs control panel. By default, the application is not installed when the user logs on but will be installed when the user activates the application from the Start menu or chooses to install the application through Add Or Remove Programs. You can also configure the install logic so that an application can be installed when the user tries to open a file with a file extension that is associated with the application. For example, if Microsoft Word is not currently installed on the user's computer, when the user double-clicks a file with a .doc extension, Word will automatically be installed. This process is often referred to as extension activation.
One of the new features in Windows Server 2003 Active Directory that is not available in Windows 2000 Active Directory is the option to completely install the software application when the user logs on rather than after user activation. Choosing this option means that the logon process will take longer to allow the application to be installed, but the application is then available to the client for use. This option is available only when the application is assigned to a user. Published applications cannot be completely installed until they are installed through Add Or Remove Programs or through extension activation. This option is also not applicable when the application is assigned to computers because the application is completely installed the next time the computer is rebooted.
When you publish an application to a user, the application is advertised the next time the user logs on to the network. In this case, however, the application is only advertised in the Add Or Remove Programs control panel. To install the application, the user must choose that option in Add Or Remove Programs. By default, published applications are also installed through extension activation.
In most cases, publishing an application is the best option if only some of the users require the application. For example, you might have a graphics application such as Microsoft Visio that only the network architects require all the time. However, some other users might need Visio. By publishing the application to the users, you are not installing the application on their desktops or adding it to their shortcuts, but you are making the application available for those who need it.
To advertise an application using a group policy, use the following procedure:
- Copy the software installation files to a network share. Configure the permissions on the share to ensure that all required users and computers have Read access to the installation files.
- Locate the container—a site, a domain, or an organizational unit (OU)—where you want to advertise the application and access the container properties. Click the Group Policy tab. Create a new GPO, or click Edit to modify the properties of an existing GPO.
- If you are advertising the application to user accounts, expand the User Configuration\Software Settings container in the Group Policy Object Editor, right-click Software Installation, select New, and then select Package. If you are advertising the application to computer accounts, expand the Computer Configuration\Software Settings container in the GPO, right-click Software Installation, select New, and then select Package.
- Browse to the network location, or type in the network path where the installation files are located. You must use a network location and not a local drive letter on the server because the network location is advertised to the client computers. Select the appropriate .msi file.
- When you select the .msi file, you are given a choice of how you want to advertise the software package. Figure 12-1 shows the options if you are advertising the application to user accounts. If you are advertising the application to computers, you can only assign the application.
- If you chose to assign or publish the application, click OK. If you choose the Advanced option, you are presented with the Properties sheet for the package. This Properties sheet is discussed in the section "Configuring Software Package Properties" later in this chapter.
Click to view graphic
Figure 12-1. Options for advertising the software package.
Once the GPO is configured, the application will be advertised to all clients in the container object. By default, the software installation component of a group policy is applied only when the user logs on (if the policy is applied to user accounts) or when the computer reboots (if the policy is applied to computer accounts). The GPUpdate command-line tool, which is included on all computers running Windows XP Professional and Windows Server 2003, can force a logoff or a reboot as part of the group policy update on the workstation. To force a logoff or a reboot, use the command gpupdate /logoff or gpupdate /reboot.
Using Group Policies to Distribute Non-Windows Installer Applications
In some cases, you might not want to go through the effort of creating a .msi file to install an application, but you might still want to use group policies to distribute an application. For example, you might have a simple application that must be installed on several workstations but that does not require any customization and is not likely to be upgraded. You can create and use a software installation settings (.zap) file to install this application.A .zap file is a text file that contains the setup instructions for installing an application. In most cases, the .zap file will contain only the following lines:
[Application]
FriendlyName = "applicationname"
SetupCommand = ""\\servername\sharename\installapplication.exe""
The FriendlyName value is the name that will be displayed in the Add Or Remove Programs control panel on the client computer. The SetupCommand value is the path to the installation file for the application. You can use a Universal Naming Convention (UNC) path or a mapped drive for the SetupCommand value. If the application provides a means to customize the installation by using setup parameters, you can include the parameters in the SetupCommand value, following the setup path's closing double quotation marks. For example, the value might be
SetupCommand = "\\servername\sharename\setup.exe" /parameter
Note that if the command line includes a parameter, the setup path uses a single set of double quotation marks instead of the two sets of double quotation marks required in the earlier example.
After you have created the .zap file and copied the application installation files to a network share, you can publish the application to users. The application is added to the list of available applications in the Add Or Remove Programs control panel. Users can then select the application to install. Applications that are distributed through .zap files cannot be assigned to either computers or users, and they will not install using extension activation.
Using a .zap file has several important limitations compared to using Windows Installer files. First, the installation of the application using the .zap file runs the normal installation program for the application, which means that you cannot customize the installation unless the application provides setup parameters to customize the installation. Further, the installation using .zap files cannot run with elevated permissions during the installation, which means that a user might need to be a local Administrator to install the application. Applications installed using .zap files are also not self-healing. If the application fails because a file has been previously corrupted or deleted, the user might have to run the original installation procedure again manually to reinstall the application. An application that has been installed using a .zap file also cannot be easily upgraded or patched. Because of these drawbacks, this software installation technology has limited usefulness and should be used only when you are installing a simple application that is not likely to be upgraded.
Configuring Software Package Properties
After you create the software package, you can modify the package properties. To access the package properties, right-click the package and select Properties. Figure 12-2 shows the Deployment tab. Table 12-1 describes the options available on this Properties sheet.
Click to view graphic
Figure 12-2. Modifying the deployment properties for a software package.
Table 12-1. Deployment Options for a Software Package
| Setting | Explanation |
| Deployment Type | Use this option to specify how the application will be advertised to clients. |
| Auto-Install This Application By File Extension Activation | Use this option to enable or disable the option to install software when the user opens a file of a selected extension. This option is not available if you assign an application. |
| Uninstall This Application When It Falls Out Of The Scope Of Manage ment | Use this option to control what occurs when the Group Policy no longer applies to the user or computer. For example, if the Group Policy is linked to user accounts in an OU, choosing this option means that the application will be uninstalled if the user account is moved out of the OU. |
| Do Not Display This Package In The Add/Remove Programs Control Panel | Use this option to control whether the application will be displayed in the Add Or Remove Programs control panel. |
| Install This Application At Logon | Use this option to completely install an application when the user logs on rather than wait for the user to initiate the installation. This option is not available when the application is published. |
| Installation User Interface Options | Use this option to control what is displayed for the user when the software is being installed. Selecting Basic means that only error messages and completion messages will be displayed. Selecting Maximum means that all software setup screens will be displayed. |
| Advanced | Use this option to configure additional settings for the software package. Options include installing 32-bit applications on 64-bit operating systems, installing the application even if it uses a different language than the destination operating system, and including Component Object Model (COM) components with the package so that the client can install the components from Active Directory. Figure 12-3 shows the interface. |
Click to view graphic
Figure 12-3. Using the Advanced Deployment Options page to configure group policy software installation.
Setting the Default Software Installation Properties
When you prepare to install software using group policies, you can configure the default settings for all software packages that are deployed using a specific GPO. You can access this interface by right-clicking the Software Installation container and selecting Properties. Figure 12-4 shows the interface.
Click to view graphic
Figure 12-4. Configuring the default software installation settings.
You can use this procedure to set the options that will be displayed when you create a new software package in this GPO. You can also set the default location for the software installation files and configure the installation's user-interface (UI) settings.
Installing Customized Software Packages
Sometimes a company might want to customize the installation of a software package even if it comes with a native Windows Installer package. For example, you might need to create a custom installation of your word processing application to include custom dictionaries or templates. Or you might need to customize the installation of Microsoft Office to install only Microsoft Word and Microsoft Excel on every desktop while deploying the full Office suite to only selected users. If you work for an international company, you might need to deploy the same application in multiple languages.You can customize the installation of a software package by creating a transform (.mst) file. The transform file contains instructions, in addition to the .msi file, that customize the installation. The easiest way to create a .mst file is if the software manufacturer has provided a tool to do so. For example, Microsoft includes a Custom Installation Wizard with the Microsoft Office 2000 Resource Kit and the Microsoft Office XP Resource Kit. When you start this Wizard, you have to select a .msi file, a name, and a location for the .mst file. Then the Wizard presents all the options for customizing the default installation of the software. You can customize almost every aspect of the installation, including removing previous versions of Office, customizing which components will be installed, and deciding where those components will be installed. You can migrate user settings if the installation is an upgrade of existing software, or you can custom-configure personal settings and security settings. You can add additional files to the installation (such as custom templates), add or remove registry keys, add or remove shortcuts to Office applications, and configure e-mail client settings.
After creating the transform file, you must create a new software package to deploy the custom installation. When you create the new software package, select the Advanced option when choosing the deployment method so that you can add the transform file before the package is completed. From the software package's Properties sheet, select the Modifications tab and then add the transform files. Figure 12-5 shows the Modifications tab.
Click to view graphic
Figure 12-5. Adding transform files to a software package.
When you apply the transform file to the software package, all clients within the scope of the GPO that install the application will install the customized version. You can include more than one transform file with the software package. If you do, the transform files are applied starting from the top of the list, which means that transform files that are applied later in the installation process might overwrite earlier modifications.
Updating an Existing Software Package
Another very useful feature that is available when you use group policies to install software is the option to update existing software packages. There are basically two ways to update existing software packages: patching or installing a service pack on an existing application, and upgrading an application to a new version. If you are running Microsoft Office 2000, installing Service Release 1 for Office 2000 is an example of the first type of update, but installing Office XP is an example of the second type of update.The two different methods for updating software require different procedures. If you are applying patches or a service pack to an existing application, you must first obtain a .msi file or a patch (.msp) file for the updated application. (Ideally, this file will come from the software manufacturer, but you can also create your own.) Copy the new .msi file and the other new software installation files into the same folder as the original .msi file, overwriting any duplicate files. Then redeploy the application. To do so, right-click the software package in the Group Policy Object Editor, select All Tasks, and then select Redeploy Application. The software package will be redeployed to all users and computers under that group policy.
If you are upgrading an existing application to a new version of the software, you will take a different approach. In this case, you must create a new software package to deploy the application. Then you can access the software package properties for the new application and select the Upgrades tab. Using the settings on this tab, you can create a link between the new software distribution package and an existing package. When you click Add from the Upgrades tab, you can choose which software package will be upgraded by this package. You can also configure whether the old application must first be uninstalled before the new application is installed. Figure 12-6 shows an example of upgrading Office 2000.
When you create the upgrade link, the Upgrades tab shows the new information. Figure 12-7 shows the interface. You can also use the Upgrades tab to make this a required upgrade. If you choose to make it a required upgrade, all software distributed by the previous GPO will be upgraded the next time the computer reboots or the user logs on. If you do not make it a required upgrade, the user can choose when to install the new application, either by activating the application from the Start menu or through the Add Or Remove Programs control panel. If you are using the same GPO for the upgrade software package as you used for the initial application, the original software package will show that the new package is upgrading it.
Click to view graphic
Figure 12-6. Upgrading an existing software package.
Click to view graphic
Figure 12-7. The Upgrades tab on a software package's Properties sheet.
Managing Software Categories
In a large organization, you might deploy dozens of applications using group policies. If you chose to publish most of these applications high in the domain hierarchy where the GPO applies to most users, users will see a long list of available applications when they open the Add Or Remove Programs control panel, which can lead to confusion. One way to minimize this confusion is to use software categories to present the users with a simpler view of the applications that they can install.When you use software categories, you can present the user with grouped lists of applications. For example, as Figure 12-8 illustrates, you can create a category for each group of business applications. If a user is in the Administration business unit, he or she can select the Administration category and from there choose which application to install.
Click to view graphic
Figure 12-8. Displaying software categories in Add Or Remove Programs.
Windows Server 2003 Active Directory does not come with any predefined software categories, so you can create any categories you want. To create categories, open any existing GPO, right-click Software Installation under either Computer Configuration or User Configuration, select Properties, and then select the Categories tab. Figure 12-9 shows the interface. Software categories do not apply to individual GPOs but do apply to all GPOs in the domain. After creating the software categories, you can associate each of the software deployment packages with a category.
Click to view graphic
Figure 12-9. Configuring software categories on a GPO.
Configuring File Extension Activation
One of the means by which a user can initiate the installation of an application is through file extension activation. In most cases, you will have only one application that is linked to any specific file extension. However, in some cases, you might have more than one. For example, you might be upgrading Word 2000 to Word XP, and for several months you might have both versions of the software available for installation. In this case, you can configure which of the application versions will be installed when a user initiates the install through file extension activation.To configure this option, in the Group Policy Object Editor, access the Software Installation Properties sheet under Computer Configuration or User Configuration. Select the File Extensions tab. Figure 12-10 shows the interface. The application that is listed first will be installed when the file extension is activated.
Click to view graphic
Figure 12-10. Configuring file extension activation.
Removing Software Using Group Policies
A group policy can be used to install applications, and it can also be used to remove previously installed applications. There are three options for using a group policy to remove software:
- Removing software as a preliminary step to installing a newer version of the software
- Removing software when the user or computer is moved outside the scope of management
- Removing software when you remove the software package
The first two options have been discussed earlier in the chapter. The last option requires some explanation. When you remove a software package from a GPO, you have a choice of how to manage the software that was installed by the GPO. Right-click the software package in the Software Installation listing, select All Tasks, and then select Remove. Figure 12-11 shows the dialog box that appears when you choose to remove a software installation package. If you choose Immediately Uninstall The Software From Users And Computers, the software will be uninstalled the next time the computer reboots or the user logs on. If you choose Allow Users To Continue To Use The Software,But Prevent New Installations, the application will not be removed from the workstations but users will no longer be able to install the application using this GPO.
Click to view graphic
Figure 12-11. Configuring the removal of software when removing a software package.
Last Updated: April 15, 2003
| Top of Page |