|
|
 |
|
|
|
Active Directory® for Microsoft® Windows® Server 2003 Technical Reference
|
|
|
Author
|
|
Stan Reimer and Mike Mulcare
|
|
|
Pages
|
480
|
|
Disk
|
N/A
|
|
Level
|
Int/Adv
|
|
Published
|
04/16/2003
|
|
ISBN
|
9780735615779
|
|
Price
|
$49.99
To see this book's discounted price, select a reseller below.
|
|
|
|
|
|
|
|
|
Chapter 12: Using Group Policies to Manage Software continued
Using Group Policies to Configure Windows Installer
Because most of the applications that you will install using group policies use the Windows Installer technology, you might also need to configure how Windows Installer applications are installed. Windows Server 2003 Active Directory provides several options for configuring how Windows Installer applications will be installed. Most of these settings can be configured by opening a GPO in Group Policy Object Editor and expanding Computer Configuration, then Administrative Templates, then Windows Components, and then Windows Installer. Figure 12-12 shows the interface. A few of the settings can be configured under User Configuration\Administrative Templates\Windows Components\Windows Installer. Table 12-2 explains the options that can be configured in both locations.
Click to view graphic
Figure 12-12. Configuring the Windows Installer settings for computer objects.
Table 12-2. Group Policy Setting Options for Windows Installer
| Setting | Explanation |
| Disable Windows Installer (Computer Configuration only) | Use this option to enable or disable the installation of software using Windows Installer. If you enable the policy, you can then disable Windows Installer completely, enable Windows Installer for all applications, or disable Windows Installer for those applications that are not distributed through group policies. |
| Always Install With Elevated Privileges (Computer and User Configuration) | Use this option to allow users to install applications that require access to directories or registry keys that the user would normally not be able to access. Enabling this option means that Windows Installer will use the system permissions to install software. |
| Prohibit Rollback (Computer and User Configuration) | Use this option to disable the default Windows Installer behavior of creating files that can be used to roll back an incomplete installation. |
| Remove Browse Dialog Box For New Source (Computer Configuration only) | Use this option to disable the Browse button when the user wants to install a new feature using Windows Installer. Enabling this option disables the Browse button, which means that the user can install features only from administrator-configured sources. |
| Prohibit Patching (Computer Configuration only) | Use this option to prohibit the user from installing patches to programs using Windows Installer. Enabling this option provides enhanced security because it prevents the user from installing patches that might modify system files. |
| Disable IE Security Prompt For Windows Installer Scripts (Computer Configuration only) | Use this option to turn off the warning that the client receives when installing software through a browser interface, such as Microsoft Internet Explorer. You might want to use this option if most of your software is distributed through a Web site. |
| Enable User Control Over Installs (Computer Configuration only) | Use this option to give the user more control over the application installation. If you enable this option, the installation process will stop at each installation screen so that the user can modify the settings. |
| Enable User To Browse For Source While Elevated (Computer Configuration only) | Use this option to browse for alternate installation sources if the application is being installed with elevated permissions. |
| Enable User To Use Media Source While Elevated (Computer Configuration only) | Use this option to allow the user to use removable media as the installation source if the application is being installed with elevated permissions. |
| Enable User To Patch Elevated Products (Computer Configuration only) | Use this option to allow the user to install patches when the installation is running with elevated permissions. |
| Allow Admin To Install From Terminal Services Session (Computer Configuration only) | Use this option to allow Terminal Services administrators to install and configure software using a Terminal Services session. |
| Cache Transforms In Secure Location On Workstation (Computer Configuration only) | Use this option to cache the transform files used to install a customized application on the local workstation. This transform file is required to repair or repeat the software installation. |
| Logging (Computer Configuration only) | Use this option to configure Windows Installer to increase the default level of logging for the software installation. |
| Prohibit User Installs (Computer Configuration only) | Use this option to manage whether the applications assigned to a user will be installed. If you enable this option, you can configure the setting so that only computer-assigned applications will be installed. This setting can be useful if the computer is a kiosk or a shared computer. This option only applies to clients with Windows Installer v2.0 (or later) installed. |
| Turn Off Creation Of System Restore Checkpoints (Computer Configuration only) | Use this option to modify the default behavior on computers running Windows XP Professional where a System Restore checkpoint is automatically created before any application is installed. |
| Search Order (User Configuration only) | Use this option to modify the default search order in which Windows Installer searches for installation files. By default, Windows Installer will search the network first, then removable media, and then an Internet URL. |
| Prevent Removable Media Source For Any Install (User Configuration only) | Use this option to prevent users from using Windows Installer to install any application from removable media. |
Planning for Software Distribution Using Group Policies
Using group policies to manage software can greatly decrease the amount of effort required to distribute and maintain software on client computers. However, taking advantage of this tool can be complicated, especially in a large company with many different software configurations for user desktops. Deploying group policies to manage software most effectively requires careful planning. This section outlines some of the things you should consider when doing this planning.
One of the factors that you must consider when deploying applications is whether to advertise the application to users or computers. In general, if most computers are shared computers, and every user requires a particular software package, you should assign the policy to computers. By assigning the policy to computers, the software is completely installed on the workstation the next time the workstation reboots and the software becomes available to all users. Assigning the software package to computers can also provide more options for managing network bandwidth. By using this option, you can configure a group policy during the day and then ask users (or use a remote tool) to reboot the workstations after regular working hours.
If only a few users require a software package, it is usually more efficient to assign or publish the application to user accounts. In some cases, a software package must be distributed to users in multiple OUs. The best way to distribute the software in such cases is to assign a group policy high in the Active Directory hierarchy and then filter the application of the GPO by security groups.
Another important decision to make when planning for software distribution is how many GPOs to use. At one extreme, you could use one GPO to distribute all software for a particular container, which will improve the client logon performance but could result in large and complicated GPO configurations. At the other extreme, you might choose to use many GPOs, with each GPO distributing a single application. In this case, the client logon performance might be affected because the computer has to read many GPOs. Companies use a variety of approaches to deal with this problem. One fairly standard approach is to create one GPO to install a standard set of applications that everyone needs and that is rarely modified. Additional GPOs are created for applications that are frequently updated (such as antivirus software) and for applications that are used by small groups of users.
You might also need to plan for software distribution across slow network links. Many companies have remote offices or remote users who connect to Active Directory using slow network connections. By default, the software distribution component of group policies is not applied when the client connects across a network connection that is less than 500 Kbps (kilobits per second). If the workstations on your network normally connect on a local area network (LAN) and only occasionally connect across a slow network connection, this default is probably acceptable. However, if you have network clients that almost always connect to the network across a slow network connection, you will need to prepare for these clients through some additional configuration.
One option is to leave the default software distribution as is but force a complete installation of the software when the user does connect to the LAN. You can use this option if the clients occasionally do connect to your LAN. If you have clients that never connect to the LAN, you might need to use means outside of Active Directory to distribute software. For example, you might choose to distribute software using removable media or through a secure Web site if the clients have a fast Internet connection and normally connect to Active Directory through a slow virtual private network (VPN) connection.
Most large companies have some form of automated process for building workstations. Companies can use disk cloning technology or Remote Installation Services (RIS) to rapidly build a standard desktop for a user. You can use this technology in combination with group policies to greatly optimize the distribution of software. For example, if you are using a disk cloning tool to build client workstations, you can build the client computer and then use a Group Policy to install a standard set of applications on the workstation. When this image is deployed to workstations, these applications can be managed using group policies. If you use RIS to install client machines, you can include the managed application in the RIS image for each department.
Perhaps the most important step in preparing to use a group policy to deploy software is to thoroughly test every software distribution before you deploy it. Most companies that use a group policy to distribute software maintain a distribution test lab that contains workstations that are representative of the workstations in the production environment. You can easily create a test OU in Active Directory and move these computer accounts and some test user accounts into this OU. Then use this test environment to test every software distribution.
Limitations to Using Group Policies to Manage Software
Although group policies provide powerful tools for managing software on client computers, there are still some limitations with the technology. These limitations are particularly apparent when comparing group policies to software management tools such as Microsoft Systems Management Server (SMS) or Intel LANDesk.
One of the most important limitations for many companies is that group policies can be used only to distribute software to Windows 2000 or Windows XP Professional client computers. Although this limitation is becoming less significant as more companies move to these latest operating systems, many large corporations still have Windows NT Workstation, Windows 95, or Windows 98 clients. If companies with these client computers want to use group policies to distribute software to newer clients, they must still maintain an alternative method for older clients.
A more significant limitation for companies that have the required clients is the lack of flexibility in group policies for scheduling a software installation. Applications are not advertised to the workstation until the user logs on again or until the computer reboots. The full-featured software distribution tools such as SMS provide other options. For example, you can configure SMS or LANDesk to start up a computer during the night using wake-on-LAN technology, install the software, and shut the computer down again. Or the software distribution can be scheduled at any time during the day and the user does not need to log off or necessarily even be aware that the software distribution is occurring.
Another limitation with using a group policy to distribute software is that it does not support the network's multicasting capabilities. Most network traffic is unicast traffic, that is, traffic that flows between two specific computers. With multicasting, a server can send out one stream of network traffic and multiple client computers can receive the same data. Because each software distribution is initiated by a client action, software distribution using a group policy cannot use multicasting. Using multicasting can save a great deal of bandwidth. For example, if you have several thousand clients in your company and you must distribute an urgent antivirus update, you will use up all the bandwidth on even the fastest network if you use a unicast solution. With multicasting, the software package is sent out only once and all the clients on the network will receive the update.
Yet another limitation with using group policies to distribute software is the lack of reporting features. Active Directory does not have any way to determine whether a piece of software was successfully installed on a workstation, and it has no way of reporting the success or failure of the installation.
Using a group policy to distribute software also has a limitation in that it cannot discriminate which clients should receive a software package other than through the assignment of the GPO at the container level or through filtering based on groups. More full-featured software distribution tools such as SMS and LANDesk create an inventory of all client computers. This inventory includes computer attributes such as hard disk space, CPUs, and RAM, as well as software installed on the computers. You can then use this inventory to discriminate which client computers will get a specific software package. For example, you might choose to install the latest version of Office only on the workstations that have adequate hard disk space and RAM.
Another important software distribution issue for some companies is dealing with disconnected clients. Some companies have large numbers of client computers that connect to the corporate network only occasionally and then only through a dial-up or VPN connection. A full-featured software distribution tool can deal with these clients in a number of ways. One option is to provide a Web site that can be used to install the software and manage the software after installation. Another option is to provide very intelligent management of the software distribution when the client is connected. For example, you can distribute software to all dial-up clients but strictly limit the amount of bandwidth the software distribution process can use. The software distribution process can also detect when the network connection is broken and restart the software distribution at the point where the connection was broken the next time the user connects to the network.
As can be seen from this list of limitations, using group policies to manage software does not provide all the functionality that you might want in a software distribution tool. However, for a small- to medium-sized company that is running Windows 2000 or Windows XP Professional on most desktops, group policies can solve many software distribution issues. For many companies, the price of using group policies is certainly right—especially when compared to the fairly expensive client licensing costs of using one of the other tools.
Summary
Group policies in Windows Server 2003 Active Directory provide powerful tools for deploying and managing software on workstations. Using group policies and Windows Installer technology, you can deploy software to workstations and then manage that software throughout the software life cycle. This chapter provided details on how to use group policies to deploy and manage software.
Previous
Last Updated: April 15, 2003
|
