A:
As you know, it is possible to create a Group Policy Object (GPO) that is shared between multiple organizational units (OUs), domains, or Active Directory (AD) sites. That is, you can link to a GPO from any number of these container objects. However there are some things to keep in mind when you do so, as doing so can cause some confusion.You can re-use GPOs within your AD forest across different sites, domains, and OUs. For example, as long as an OU administrator has the permissions to link a GPO to his or her OU, and as long as the administrator has permissions to read a GPO, he or she can link it and have users or computers in the OU start processing it. Doing so can be challenging because, although a GPO may be linked to from any number of container objects, it only physically exists in one place. Any changes that are made to a GPO impact every container object that has linked to that GPO. It’s important that you approach your GPO design with a firm grasp on who will be allowed to link GPOs to their container objects and who will be allowed to edit those GPOs. I recommend creating a clear distinction between “shared” GPOs and those that are created specifically for the use of a single or small set of container objects. Shared GPOs will need to have a more stringent change-control process and a clear set of rules about who can link to them and when.
There are a few things to keep in mind about shared GPOs as well. First, because a GPO only exists in one place, any changes you make to it, as I mentioned earlier, affect all those who have linked to that GPO This includes, most obviously, the permissions that have been set on that GPO. If an administrator creates a GPO with the express intention of using it to provide policy for the Finance Users group within the Finance OU, the administrator might decide to permission that GPO to only allow users in that group to process the policy (see Figure 4.14).
Figure 4.14: Viewing a GPO permissioned to allow only the Finance Users group members to process it.
As Figure 4.14 shows, the only group with the Read and Apply Group Policy permissions on this GPO (called Finance Users Lockdown) is the Finance Users group. Now, suppose the OU
administrator for the Sales OU would like to re-use this GPO and its settings on her own OU. She has the permissions to link the Finance Users Lockdown GPO to the Sales OU, and goes ahead and does so. The next time her Sales users log onto their Windows 2000 (Win2K) or Windows XP workstations, they will get policy from the Finance Users Lockdown GPO, right? No, because the permissions on that GPO only allow members of the Finance Users group to process it. Thus, the Sales OU administrator would either have to add her Sales users to the Finance Users group (probably not a great idea for future manageability) or modify the
permissions on the Finance Users Lockdown GPO to allow her Sales users group to have Read and Apply Group Policy permissions on that GPO.
In either case, the solution is not perfect. In the first case, you start to lose the meaning of your groups if you add Sales users to the Finance Users group simply to allow GPO processing. In the second case, there is no way to grant the Sales users group the ability to just modify permissions on the Finance Users Lockdown GPO to allow the Sales Admins group to also be able to process the GPO. You will need to grant Write permissions on the GPO to allow permission editing, and if you do grant that permission, the Sales Admins group can not only modify permissions but also modify the settings on that GPO (see Figure 4.15). If they don’t understand that the GPO is being shared by other OUs, many problems could arise.
Figure 4.15: Granting the Sales Admins group the rights to modify permissions on the Finance Users Lockdown GPO.
You would think that just by granting the Sales Admins group the Read Permissions and Modify Permissions rights, members would only be able to change permissions on the GPO.
Unfortunately, that is not the case. They can’t actually adjust GPO permissions until they are also granted the Write All Properties permission. I consider this a bug in the way GPO control is delegated!
Given the ramifications for sharing GPOs, what can you do? Well, the first and easiest thing to do is to avoid sharing GPOs! Doing so might seem like a lot of work up front, but it will prove its worth as you try to share more and more of your GPOs. You can use the capabilities of a tool such as FullArmor’s FAZAM 2000 to copy the contents and settings of one GPO to another if you want to re-use a particular GPO’s policies but don’t want to manual re-enter them again and again. If you decide to share some GPOs, make sure you know who you’re affecting each time you make a change to those GPOs. The easiest way to do so is to use the “links finder” capability within the Microsoft Management Console (MMC) Group Policy snap-in tool. The links finder is available from the Properties dialog box of any GPO. Simply select the Links tab, choose the domain in which you want to search for links to the selected GPO, and click Find Now. All containers that contain a link to the current GPO will be listed (see Figure 4.16).
Figure 4.16: Using the links finder to locate which container objects are linking to the selected GPO.
The bottom line is that sharing GPOs can save a lot of time, but can also create a lot of headaches if you don’t keep a tight rein on who can link to a GPO and who can edit it.
Q 4.8: Can I use the Group Policy Object-based software installation
feature to replace my existing software distribution tools?
A:
When administrators come across the software installation features in Group Policy, the first thing they wonder is whether they can use this feature exclusively and throw out their existing software distribution tool. Unfortunately, the answer I usually give when someone asks me about this opportunity is, “Not quite!”, and here’s why.The software installation feature in Group Policy is a big step up from the days of Windows NT 4.0, with which you had to use Systems Management Server (SMS) or a similar highly complex software distribution tool to deploy software to desktops and servers in your environment. Group Policy Object (GPO)-based software installation brings a fairly simple and straightforward AD- based deployment tool to those shops that have deployed Active Directory (AD) and Windows 2000 (Win2K) or Windows XP. The Group Policy software installation features truly provide some elegant features not found in other distribution tools:
• Supports per-machine and per-user installation of applications. Thus, you can deploy applications to machines or users based on the organizational unit (OU) they are in or the groups of which they are a member.
• Supports the concept of application advertisement. Advertising an application means that the application’s icons and shortcuts are installed but the full application isn’t actually installed until the user first uses it.
• Leverages privilege elevation to let a user run an application installation that the user ordinarily wouldn’t have sufficient privileges to do. This functionality is available only to “managed” applications that have been deployed using GPO-based software installation. • Leverages the Windows Installer technology to provide robust install, rollback, and repair
features. The software installation feature requires that you package your application installations using the .MSI format, but once you have, you get all the benefits that .MSI provides, including auto-repair of advertised application features and transformation of default packages using transforms. The software installation feature does support a format called .ZAP, which lets you publish to your users applications that have not yet been packaged using .MSI. However, the .ZAP format does not support privilege elevation, so you might not be able to use it for many of your users.
• Supports the concept of upgrade relationships. After you deploy an application using the Group Policy software installation features, you can automatically upgrade the
application to the next version. You can also remove applications that no longer apply. The software installation feature has good application lifecycle management capabilities, making it easier to manage the install, upgrade, and retire cycle that most applications go through.
However, the Group Policy software installation feature is missing some key functionality that most enterprise software distribution tools provide:
• No centralized way to report on the success or failure of an application installation across many machines. Because GPO-based software installation deploys software when a GPO is processed by a user or computer, there is no centralized place to go to determine whether a distribution “event” was 90 percent or 70 percent successful. You would have to cull the logs of each target machine to determine this information.
• Unlike most software distribution tools, there is no at-a-glance way to view which software has been distributed to which users and machines. Resultant Set of Policy (RSoP) tools, such as FullArmor’s FAZAM 2000, are your best bet for seeing which users and computers are receiving which applications.
• No inventory component within the software installation feature. Most software distribution tools, such as SMS, provide an inventory component that lets you look at which hardware and software is installed on machines under management.
• No support for software distribution across slow or dial-up links. Some software distribution tools support trickle-down installations of applications. The software installation feature not only does not support this functionality, but the software installation CSE will not, by default, process a GPO if a slow link is detected.
• No support for server-based software distribution. There are two modes of installation supported in software installation—assignment and publishing. Publishing is user- specific and requires that a user be logged onto a machine to trigger an installation. Assignment is user or machine specific. In the case of machine-based assignment, although a user does not have to be logged on to trigger the installation, the computer needs to be rebooted to do so. This reboot triggering mechanism is usually not acceptable in most server environments.
• No support for license metering or a way of limiting the number of users or computers that install an application (other than restricting an application by user or computer group).
If these limitations aren’t critical to you—if you’re working in a small to midsized environment in which Sneakernet is your only other software distribution tool option, GPO-based software installation is a great tool for automating the delivery and installation of software to your users. If you are in a large enterprise environment and are already using a tool such as SMS, GPO- based software installation can be a great compliment to your existing capabilities. Software installation-based publishing of applications to the Add/Remove Programs applet (see Figure 4.17) can be a great way to provide your users with a low-maintenance, self-service way of installing optional applications that your enterprise supports but doesn’t necessarily want to install on every desktop.
Figure 4.17: Viewing an application that has been published via GPO-based software installation to the Add/Remove Programs applet.
As you can see in Figure 4.17, I have published the Win2K Administration Tools to users that might need them (I could restrict this application to only appear for administrative users by permissioning the application within the GPO for a particular user group). The application isn’t