10.1 How GPOs Work

Group policies are very simple to understand, but their uses can be quite complex. Each GPO can consist of two parts: one that applies to a computer (such as a startup script or a change to the system portion of the registry) and one that applies to a user (such as a logoff script or a change to the user portion of the registry). You can use GPOs that contain only computer policies, only user policies, or a mixture of the two.

10.1.1 How GPOs Are Stored in Active Directory

GPOs themselves are stored in two places: Group Policy Configuration (GPC) data is stored in Active Directory, and certain key Group Policy Template (GPT) data is stored as files and directories in the system volume. They are split because while there is definitely a need to store GPOs in Active Directory if the system is to associate them with locations in the tree, you do not want to store all the registry changes, logon scripts, and so on in Active Directory itself. To do so could greatly increase the size of your DIT file. To that end, each GPO consists of the object holding GPC data, which itself is linked to a companion directory in the system volume that may or may not have GPTs stored within. The GPT data is essentially a folder structure that stores Administrative Template-based policies, security settings, applications available for software installation, and script files. GPT data is stored in the System Volume folder of DCs in the Policies subfolder.

Third-party developers can extend GPOs by incorporating options that do not reside in the normal GPT location.

The GPO objects themselves are held as instances of the groupPolicyContainer class within a single container in Active Directory at this location:

CN=Policies,CN=System,dc=mycorp,dc=com

Through a process known as linking, the GPOs are associated with the locations in the tree that are to receive the group policy.^[1] In other words, one object can be linked to multiple locations in the tree, which explains how one GPO can be applied to many Organizational Units, sites, or domains as required.

^[1] The GPC data part of a GPO is an object in Active Directory. This object, like all others, has attributes. One of the attributes of a GPO is a multivalued attribute called gPLink that stores the DN of the containers that the GPO is linked to.

Let's consider the groupPolicyContainer class objects themselves. Take a look at Figure 10-1; we are using one of the Windows Support Tools utilities, ADSI Edit, to show the view of the Policies container and its children.

Figure 10-1. GPOs in the Policies container

Here you can see 10 groupPolicyContainer objects shown with their GUID as the cn field. The displayName attribute of these objects holds the name that administrators of Active Directory would see when using one of the normal tools to view these objects. Each GPO also has a gPCFileSysPath that holds the full path to the corresponding directory in the system volume.

If you were to look under the Policies container on a default installation, you would find only two children. These children would correspond to the Default Domain Policy^[2] and the Default Domain Controllers Policy, the only GPOs created automatically by the system on installation.

^[2] The default settings for these two policies can be found in Microsoft's Windows 2000 Group Policy white paper located at http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp.

The Default Domain Policy is also associated with a special system container created on installation and located at:

LDAP://CN=Default Domain Policy, CN=System, dc=mycorp, dc=com

Looking at Figure 10-1, you see that the eighth GPO down the list has more children within the User container than all the other GPOs. That's because it is a policy to deploy an MSI application to users. In fact, this GPO also has under the Classes container 80 entries that we haven't displayed. This particular policy is the one described in the introduction to a previous chapter. It applies the Administrator tools MSI file during an administrator-equivalent logon to install the tools on whatever workstation the administrator happens to log onto. When the administrator logs off, it completely uninstalls the tools so that no subsequent users have access to them at that client computer.

10.1.2 How GPOs Are Used in Active Directory

Any GPO is initially created as a standalone object in Active Directory. Each object can then be linked one or more times to three different container types: Sites, Domains, and Organizational Units. GPOs for domains and Organizational Units are held in the domain relating to their application, but creating a GPO for a site stores that GPO in the forest root domain by default; administrators can change this if they wish.

In the normal state of affairs, what you as an administrator would do is open up the properties of the Site, Domain, or Organizational Unit, then create a GPO and link it to that location. For all intents and purposes, it appears that you have created a GPO at that location in the tree, rather than what really happened, which was that the system created the GPO as a standalone object in the Policies container and then linked it to that container.

To apply a GPO to a set of users or computers, you simply create a GPO in Active Directory and then link it to a Site, Domain, or Organizational Unit. Then by default, the user portion of the GPO will apply to all users in the container and its children, and the computer portion of the GPO will apply to all computers in the container and its children.

Thus, if we were to create a policy and link it to a site or domain, all computers and users of that site or domain, respectively, would get the policy. If we were to create a policy and link it to an Organizational Unit, all users and computers in that Organizational Unit and all the users and computers within Organizational Units beneath that Organizational Unit and so on down the tree would get the policy.

To identify the links on a GPO, you simply look at the Links tab of the GPO's properties in the Group Policy Object Editor (GPOE). Figure 10-2 shows the results of a scan for the locations in the domain where the Default Domain Policy GPO has been linked. It seems that Mycorp has chosen to link the Default Domain Policy to a location farther down the tree as well, the Users Organizational Unit within the finance Organizational Unit, within the mycorp.com domain.

Figure 10-2. Identifying GPO links

We want to make three major points here:

• GPOs apply only to sites, domains, and Organizational Units.

• A single GPO can be linked to multiple locations in the tree.

• GPOs by default affect all of the users and computers in a container.

This generates further questions. If multiple policies apply to different locations in a tree, can multiple GPOs apply to the same container, and if so, what takes precedence? Why would you want to apply one GPO to different parts of the tree? In addition, how can we stop the GPO from applying to the entire set of users and computers in the container? Let's consider each of these questions to understand policies better.

10.1.3 Prioritizing the Application of Multiple Policies

Let's say that we set a GPO for all users in a site to run a logon script that executes a news system local to that site. Let's also say that we set a domain GPO to set a series of Kerberos security settings for each user. Finally, we have two user logon scripts that we need to run in a specific order for specific Organizational Units in that domain. GPOs for larger containers get applied before GPOs for smaller containers. That means that any GPOs on the site get applied first, followed by any GPOs on the domain, followed by any GPOs on the Organizational Units that a user or computer resides in. This process is known as SDOU. If multiple GPOs are linked to a single site, domain, or Organizational Unit, the administrator can prioritize the order in which the GPOs are applied to that container. So in this scenario, the site news system runs first, then the Kerberos settings are applied, and finally the two logon scripts are applied in the order determined by the administrator. We know that each computer and user will exist in one site and one domain. However, while each object will exist in only one Organizational Unit as well, there is an Organizational Unit hierarchy to be considered. And there is the domain tree hierarchy, too.

To account for this, the GPOs for the site that the object resides in are applied first in prioritized order. No other sites have any influence over this. Then, the GPOs for the domain that the object resides in are applied in prioritized order. GPOs applied to parent domains in the domain tree have no influence on objects in domains lower down the tree. Domain trees do not impact GPO application at all. The Organizational Unit structure, however, has a significant bearing on what happens with GPOs. GPO links are inherited down the tree. So while a child Organizational Unit can have its own GPOs linked to it, it also will inherit all of its parent's GPO links. These Organizational Unit GPOs are applied in order according to the Organizational Unit hierarchy once the site and domain GPOs have been applied.

There are exceptions. You can block inheritance, force an override, and even define ACLs on objects. We'll cover all these later in this section.

For example, Paul Burke has the following DN to his account (see Figure 10-3):

cn=PaulBurke,ou=Databases,ou=Gurus,ou=Financial Sector,dc=mycorp,dc=com

Figure 10-3. Graphical representation of the location of the Paul Burke user

The site GPOs are applied first, and the mycorp.com domain GPOs are applied next. Then come the GPOs on the Financial Sector Organizational Unit, the GPOs on the Gurus Organizational Unit, and the GPOs on the Databases Organizational Unit. From this, it's fairly easy to see how Organizational Unit hierarchy design has a significant effect on GPO precedence.

Remember that GPOs have a computer part as well as a user part. When a computer boots, any site GPOs that have computer settings are applied in prioritized order. This is followed by any domain GPOs with computer settings, and so on down the Organizational Unit hierarchy until any GPOs on the Organizational Unit that the computer resides in are applied. During boot up, the user portions of these GPOs are ignored. Later, when a user logs on, the same process applies, this time with the user settings. The computer settings are ignored during user logon.^[3]

^[3] This is the default case. There is a setting that you can use to force a different mode of operation. We'll explain this later when we cover loopback mode.

10.1.4 Standard GPO Inheritance Rules in Organizational Units

Any unconfigured settings anywhere in a GPO can be ignored since they are not inherited down the tree; only configured settings are inherited. There are three possible scenarios:

• A parent has a value for a setting, and a child does not.

• A parent has a value for a setting, and a child has a nonconflicting value for the same setting.

• A parent has a value for a setting, and a child has a conflicting value for the same setting.

If a GPO has settings configured for a parent Organizational Unit, and the same policy settings are unconfigured for a child Organizational Unit, the child inherits the parent's GPO settings. That makes sense.

If a GPO has settings configured for a parent Organizational Unit that do not conflict with a GPO on a child Organizational Unit, the child Organizational Unit inherits the parent GPO settings and applies its own GPOs as well. A good example of this is two logon scripts; these scripts don't conflict, so both are run.

If a GPO has settings configured for a parent Organizational Unit that conflict with the same settings in another GPO configured for a child Organizational Unit, the child Organizational Unit does not inherit that specific GPO setting from the parent Organizational Unit. The setting in the GPO child policy takes priority, although there is one case in which this is not true. If the parent disables a setting and the child makes a change to that setting, the child's change is ignored. In other words, the disabling of a setting is always inherited down the hierarchy.

10.1.5 Blocking Inheritance and Overriding the Block in Organizational Unit GPOs

It is possible to force the settings of a GPO to be applied as the final settings for a child.

Blocking inheritance is a fairly simple concept. If you block inheritance to a specific Organizational Unit, GPOs linked to parent Organizational Units up the tree are not applied to objects in this specific Organizational Unit or its children.

LGPOs (Local GPOs, discussed shortly) are processed even when Block Policy Inheritance is checked.

Refer back to Figure 10-3. If we decide to block inheritance at the Databases Organizational Unit, Paul Burke will receive only GPOs directly defined on the Databases Organizational Unit. If we decide to block inheritance at the Gurus Organizational Unit, Paul Burke will receive only GPOs on the Databases Organizational Unit and those inherited from the Gurus Organizational Unit. The Organizational Unit that you block inheritance at stops any higher-level GPOs from applying to the branch starting at the blocked Organizational Unit. In fact, we can block inheritance on any of the Organizational Units within the mycorp.com domain. For example, blocking inheritance on the Financial Sector Organizational Unit makes sense if we want to block site-level GPOs from applying.

This can cause problems. For example, let's say that you have delegated control over an Organizational Unit branch to a group of administrators and allowed them access to manipulate GPOs on that branch. You may be applying GPOs to Organizational Units farther up the hierarchy that you wish this delegated branch to receive. However, your branch admins have the ability to block inheritance of these parent Organizational Unit policies of yours. The branch administrators also have the ability to configure a setting that conflicts with one you set in a parent GPO; the branch administrator's child setting will take precedence in conflicts.

To prevent this, you can check the No Override box on an individual GPO. This allows administrators to force GPOs to be inherited by all children of an Organizational Unit. However, it has one further effect: it prevents GPO settings in child Organizational Units from overriding conflicting settings in a parent OU.

Let's say that we change a registry setting using a GPO on the Financial Sector Organizational Unit. Unfortunately, another administrator then sets the same registry setting (among many others) to a conflicting value on the Gurus Organizational Unit and also blocks inheritance at the Databases Organizational Unit. By default, the registry setting will be correctly applied only to the Financial Sector Organizational Unit, as the Gurus Organizational Unit receives the different setting (child overrides parent on conflicts due to inheritance rules), and the Databases Organizational Unit doesn't inherit either policy. To fix both problems, we could set the original Financial Sector Organizational Unit policy to No Override. It then prevents the specific setting on the GPO on the Gurus Organizational Unit from modifying it without affecting any of the other GPO settings. Our GPO also is forced down past the Block Inheritance set up at the Databases Organizational Unit.

If you are making use of No Override on a policy, we suggest that you consider setting up an ACL on that policy to restrict the abilities of others to edit that GPO, leaving just a core group of administrators with the relevant permissions. This will ensure that the GPO is not changed without the knowledge of the core group.

10.1.5.1 Summary

• If Block Inheritance has been checked for a child-level GPO, and No Override has not been checked for any parent GPOs, the child GPO will not inherit any policies from any parent GPOs farther up the hierarchy.

• If No Override has been checked for a parent-level GPO, the child-level GPO will inherit all of the parent's configured policies, even if those policies conflict with the child's policies, and even if Block Inheritance has been set for the child.

10.1.6 When Policies Apply

We've already said that the computer portion of a GPO applies during boot up and the user portion of a GPO applies during logon. However, that isn't the only time that a policy can apply. The policies also can be set to refresh periodically after a certain time interval. How often this occurs and what conditions are attached to this refreshing are specified under the System\Group Policy key under the Administrative Templates section of the computer and user sections of a GPO.

Set the refresh value to 0 to have the policy continually apply every seven seconds. This is very useful for a test environment but obviously not for a live service.^[4]

^[4] There is a chance that this will be taken out of the final version of the product.

For Windows 2000 or earlier clients, you also can manually refresh policies on a client using the SECEDIT.EXE tool with the command SECEDIT /refreshpolicy. Windows Server 2003 has a utility called GPUPDATE that can accomplish the same thing.

Refreshing is very useful for users who do not shut down their computers or log off from the system for days. In that case, GPOs apply in the normal way, but at very irregular intervals over long periods. Consequently, setting up policy refresh means that you can manage to apply those settings to such users at whatever interval you decide.

You may think that refreshing should be fairly straightforward—a policy refreshes or doesn't refresh—but there is quite a bit more to it. The problems come when you attempt to refresh settings that could potentially affect a currently logged-on user and cause her machine to behave in an unusual or unstable manner. Let's consider a few examples:

• We decide to use a GPO to deploy Office 2003, which comes with its own MSI files for use with the Application Deployment GPOs. The deployment goes well, but we later decide that we need to change a few registry keys governing the way Office operates. We add these into the appropriate parts of the GPO so that new users receive them and so that rolling out these new registry keys to users currently running Office will not cause the running application to fail. We have to be careful as to whether we want the registry keys to apply during a refresh or during the next logon or boot up of the machine (depending on whether the keys are user or computer registry settings).

• We have deployed an application using an MSI file that has insinuated itself into all users' registries. Unfortunately, there is a serious problem with the application and we want to remove it, so we remove it from the list of deployable applications. Users who are not logged on now will have the application auto-uninstalled when they next log on, but what about currently logged-on users? If the policy is set to auto-refresh, the application will attempt to uninstall itself while users are logged on, even if some of them are using the application at the time.

• We decide to add a new logon script to a GPO so that users are alerted about the number of new mail messages. If this policy is set to auto-refresh, the system may detect that this logon script is new and automatically run it against any logged-on clients. Users who logged on at 9:00 A.M. and receive a logon script message at 3:00 P.M. welcoming them to the system and telling them they have new mail could be confused.

These examples show the problems with refresh. What if you do want refresh to occur? Consider the following example.

We decide that we want a script that alerts users about system changes. This script fires up a dialog box that explains various changes to the system during a critical upgrade, for example. It could even auto-open a browser window to an intranet web page holding important changes. We need this script to run once during logon and then every time the page changes. Every time we make a system change, we remove and re-add the logon script for the specific GPO that we wish to apply to all affected users. We then specify that the GPO should refresh periodically. The script is then run whenever we require it to do so, and all users who are logged on at the time will have an alert message pop up on their screens, generated by the script running again on their client.

All of these items and more are configurable in the GPO. The point is that if you do turn on refresh, make sure you go through both areas of the GPO thoroughly to make sure that the specific items being refreshed will not cause problems for logged-on users.

10.1.7 Local Group Policy Objects

Windows 2000 and later machines have their own Local Group Policy Objects, known as LGPOs or Local Security Policies. LGPOs are applied prior to any GPOs on the site, but they have restrictions in that they can contain only security settings, software policies, and scripts. File deployment and application deployment are not available in LGPOs.

LGPOs are applied before site GPOs. This is normally represented by the string LSDOU.

While GPOs consist of two parts, the Active Directory object and the templates in the system volume (SYSVOL), LGPOs consist of only the template portion. These templates cannot be stored in the system volume because the concept does not exist on the local machine. Instead, the LGPO templates are stored in %systemroot%\System32\GroupPolicy. These ADM files can be added to and extended in the same way as standard GPOs.

While LGPOs are very useful in environments in which no DCs exist and Windows NT system policies failed to deliver, their use in enterprise organizations is likely to be quite limited. In some cases, LGPOs will be useful if an administrator requires a machine-specific policy to execute before all others or if a domain client is not to execute any domain GPOs, but mostly their use is confined to standalone environments.

LGPOs are processed even when Block Policy Inheritance is checked.

If conflicts occur on a domain client with an LGPO and subsequently applied Active Directory GPOs, the Active Directory GPO prevails over the original LGPO.

If you have a requirement for a domain client not to execute domain GPOs, you need to change a setting in the LGPO that will make a registry change on that local client when it is next booted. This key is checked both when the client boots and when a user logs onto the domain. If the key is properly set, the user and computer will have only the LGPO applied, and any domain GPOs will be ignored.

10.1.8 How Existing Windows NT 4.0 System Policies Affect GPO Processing

Windows NT 4.0 system policies were useful in making sure that a setting was applied with a specific value somewhere in the registry. These policies dotted the registry with settings throughout its structure and were known as tattooing the registry. Once these settings were applied, to unset them the administrator had to either edit the registry or create another policy to force the different settings to the system. By default, ordinary users also had the ability to change registry settings in the user portion (HKCU) held in their profile, so they could easily unset values that the administrator wished to be firmly set.

To counteract this and bring all the policy settings under one roof, so to speak, Windows 2000 and later were designed so that the GPOs exist as registry keys and values in locations that are restricted to administrator access. These locations are:

• HKEY_CURRENT_USER\Software\Policies

• HKEY_LOCAL_MACHINE\Software\Policies

• HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies

• HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies

The first two keys are the preferred locations for all new policies. An administrator can specify that a value be set in a user's registry and then reset on a regular basis. Any settings that users have set themselves will be overwritten by the proper administrator-set values. However, administrators can still import any ADM files and modify keys throughout the registry as they wish. It is up to administrators to make sure that the policy is reapplied regularly or is in a part of the registry to which the user has no access, unless they wish the user to be able to change the registry permanently.

10.1.9 When to Use Windows NT System Policies

During an upgrade, Windows NT system policies that reside in the NETLOGON share will be transferred to domain controller's NETLOGON share (now known as the SYSVOL). However, only Windows NT and Windows 9x downlevel clients will use these policies; Active Directory clients will not use them. Active Directory GPOs do not affect downlevel clients at all.

Windows NT System Policies Windows NT provided a tool called System Policy Editor (POLEDIT.EXE) that was installed with the resource kit. This was a very basic graphical tool that allowed you to manage three types of policies: computer, user, and group. By default, the only two policies were Default User and Default Computer. Do not confuse the Default User policy with the Default User profile; they are not the same thing at all. If you decided that your entire organization would have only one set of policies for everyone, you would simply modify the Default User and Default Computer policies. Whenever a client booted in your organization, it would retrieve the Default Computer policy and lock itself down (or unlock itself) according to that policy. Whenever a user logged on to that client, the Default User policy would apply and lock or unlock the settings for that account. The default policies basically allowed you to lock down the desktop settings of the machine based on a series of template files, also known as ADM files. It was always possible to create your own ADM files or modify the existing ones with settings that corresponded to registry changes you wanted to make. If you created a new file, you just imported it into the tool and could then start applying the policy. If you did not want just one policy for every computer and user in your organization, you could create policies for individual users, computers, or groups. When a client booted or a user logged on, the system would determine, according to a set of rules, which of the policies would apply to that computer or user. Only one policy was ever applied to a user or computer.

If you have downlevel clients that need policies applied to them, whether these policies already exist or need to be created from scratch, you need to fall back on the old system policies that were provided for use on these systems. You cannot use the Group Policy Object Editor to administer these older policies, so you will need to use the old System Policy Editor (poledit.exe) tool that has been reissued with Windows 2000 and later clients to manipulate such policies. The POL files generated by the System Policy Editor will still need to be placed in the NETLOGON share as they were under previous versions of Windows NT.

There is one benefit to administrators who have been using system policies to administer downlevel clients for some time; while the system policies themselves are not transferable, GPOs can be extended using ADM files of the exact format. This means that administrators can migrate their old template files over from system policies to GPOs as required.

If you have any system policy functionality that you wish to apply to your Windows 2000 or later clients, you will have to reimplement your system policies as GPOs because system policies are not upgraded when migrating to Active Directory.

We don't intend to cover system policies any more here since there are a number of white papers and other documents within Microsoft's Knowledge Base at http://support.microsoft.com that do the job very well. The best way to find them is to search for the string "System Policies."

How Policies Apply to Clients with Different Operating Systems If you have a Windows NT 4.0 client in a workgroup or a domain, the only policies that can apply are downlevel Windows NT 4.0 policy (POL) file policies. If you have a standalone Windows 2000, Windows XP, or Windows Server 2003 client or member server, policies are evaluated in the following order: Downlevel Windows NT 4.0 policy (POL) file Local GPO If you have a Windows 2000 or later client or member server in a mixed-mode or Windows Server 2003 Interim domain, policies are evaluated in the following order: Downlevel Windows NT 4.0 policy (POL) file Local GPO Site GPOs in priority order Domain GPOs in priority order Organizational Unit GPOs in priority order, applied in a hierarchical fashion down the tree ending with the Organizational Unit that the computer or user resides in As this extends the LSDOU process to include Windows NT 4.0 system policies, this process is commonly written as 4LSDOU. If you have a Windows 2000 or later client or member server in a Windows 2000 native-mode or Windows Windows Server 2003 domain, policies are evaluated in LSDOU order.

10.1.10 Combating Slowdown Due to GPOs

If you apply too many policies, there will be slowdowns. But there are no good guidelines for how many policies to apply. We can tell you that in a lab environment, we saw a slowdown when we started applying more than 12 policies. Unfortunately, that data is of absolutely no use to you. Read on to see why.

10.1.10.1 Limiting the number of GPOs that apply

The problem with trying to test the impact of GPOs on speed of the client during boot up and logon is possible only by direct testing. We would not advocate taking our value as a hard and fast rule. Each policy has to be identified, opened, read to see if it applies, actually applied, and finally closed before moving on to the next policy. This process, which is done automatically by the system, will take time. So executing 3 policies of 20 changes each will be slower than implementing 1 change of 60. We arrived at the value of 12 by using a series of tests with large and small policies in the test domain in our lab environment. Without knowing what settings were in the policies, the layout of the network, the specification and bandwidth capabilities of our clients and servers, and so on, that data is of little use to you. Even if we provided it, there is little chance that it would be similar to your layout, so you'll need to do your own testing to work out what's acceptable. Lab test simulation is really the best way to get a feel for how much the policies that you want will impact your clients.

Microsoft has its own take on designing your Active Directory for GPOs. They recommend that you should not have Organizational Unit structures more than 10 deep so that policies do not take too much time during logon. This advice is still only half helpful, and we'll come back to it in the design section later.

10.1.10.2 Block Inheritance and No Override

If you use either Block Inheritance or No Override, you incur extra processing. For this reason you should be cautious in their use.

10.1.10.3 Disabling parts of GPOs

There is another way to speed up policies. Let's say that you have an Organizational Unit that has three policies on it: a computer startup script, a computer shutdown script, and a user logon script. Let's also say that you have a need for three policies rather than one, perhaps because they are applied elsewhere in the Organizational Unit hierarchy as well. When a user in your Organizational Unit logs on, the system will attempt to apply any user settings from all three GPOs. We know that two of the policies have no relevance whatsoever to a user. Wouldn't it be a nice touch to have some way to tell the system not to bother processing the user portion for GPOs that deal only with computer data and vice versa. In fact, this is a very simple process. Just look at the properties of a GPO and check one box or the other in the General tab, as shown in Figure 10-4.

Figure 10-4. Disabling part of a GPO

With all the settings in a GPO, browsing both user and computer parts of the tree to see if each part was empty and whether any changes had been made would normally be a lengthy process. However, Microsoft has thought of this, and as Figure 10-4 shows, the revisions indicate exactly how many changes have been made to the GPO. This guides you in whether to disable or enable parts of a GPO.

GPOs with no revisions in a section are skipped; disabling part of the policy stops the need to check the revision level and thus can partially speed up the process.

10.1.10.4 Limiting cross-domain linking

It is possible for an administrator of one domain to create a GPO and for it to be applied to an SDOU in another domain. For example, if the administrator of othercorp.com is given access to centralized setup GPOs within mycorp.com, he can link the mycorp.com GPOs to SDOUs in the othercorp.com domain.

Cross-domain linking is possible only because GPO links are held in the GC.

While this is feasible, it is not normally recommended due to network bandwidth considerations, since the objects in Active Directory and the templates in the system volume need to be read on the remote domain. Normally it's better to consider duplicating the GPO in the second domain instead of cross-domain linking to it. However, if the links between the domains are as fast and reliable as the links within the second domain that is to receive the policy, and if the domain holding the GPO can apply it to the user or computer fast enough to make the administrator happy, there is nothing stopping you from doing this.

10.1.10.5 Limiting GPO application across WAN links

This shouldn't be a problem if you set up your sites' configuration correctly, but you need to be aware of the implications, nonetheless.

Data on GPOs linked to site objects is copied to all DCs in a forest because site information is part of the Configuration container that is replicated to all DCs in all domains in the entire forest. So any GPO linked to a site object is applied to all machines in that site regardless of which domain in the forest they are in.

However, while multiple domains receive the link information, those same domains do not receive the entire GPO itself. Instead, the GPO resides in one domain, and clients in the site read the GPO from that domain as required.

In the normal course of events, this shouldn't be a problem since a site is supposed to be an area of well-connected subnets. A site hosts three domains—Domain A, Domain B, and Domain C; Domain A holds the site GPO itself, and clients of all three domains will access the GPO from Domain A. However, if Domain B was mistakenly down a slow WAN link of some kind, the machines in Domain B would be accessing the GPO across that slow link. If you use site GPOs and the site spans slow WAN links (which it shouldn't do), you will cause GPOs to be accessed across those links.

10.1.10.6 Use simple queries in WMI filters

If you have a WMI filter applied to a GPO, a WMI query will be run before the GPO is applied to a user or computer. If the WMI query is very complex, it could significantly impact the time it takes to process the GPO. If you have multiple GPOs that contain a WMI filter, you need to pay special attention to the impact those queries will have.

10.1.11 The Power of Access Control Lists on Group Policy Objects

The real problem with all the information we've given you so far is that a policy appears to apply to all users and/or computers in whatever container it is linked to. There is a way of changing that, which is why they're now called group policies rather than just policies.

As each GPO is an object in Active Directory, and all objects have Access Control Lists (ACL) associated with them, it follows that it must be possible to allow and deny access to a GPO using that ACL. With ACLs it is possible to allow and deny access to GPOs based on security group membership. It is also possible to go to an even finer-grained detail and set access control for an individual computer or user. Figure 10-5 shows us that the system security group called Authenticated Users will be able to read and apply the Group Policy. If we unchecked the Apply Group Policy checkbox, the Authenticated Users group would not receive this policy.

Figure 10-5. Access control entries for a GPO

This is a significant feature of GPOs and one that you can use heavily to your advantage. Let's take a simple example, in which we create a single GPO to roll out an internal application and link it to the Finance and Marketing Organizational Units in one domain. Now all users in the Finance and Marketing Organizational Units will receive that application via the GPO on logon. Let's also say that a certain subset of users from both Organizational Units are not to receive this application. All we need to do is create a security group to hold that user subset and set up an Access Control Entry (ACE) to the Application Deployment GPO and check the Deny Apply Group Policy checkbox. Now, every user that we make a member of that new security group will not receive the policy.

Deny always overrides Allow. Let's say a user or computer is a member of four security groups. If a GPO has an ACL that contains an ACE for the individual user or computer with Read and Apply rights, an ACE for three of the security groups that have Read and Apply rights, and an ACE for the fourth security group that has Apply rights denied, the GPO will not be applied.

This has practical applications, too. At Leicester University we maintain a separate Organizational Unit structure for our computer objects. On our open-area lab machines, where students from anywhere around the university can log on, we maintain tight security. Each computer in that lab has a corresponding computer account object in an Organizational Unit that represents that lab. Two GPOs are created and linked to that single Organizational Unit; one GPO locks down that machine tightly, and the other GPO unlocks it. In other words, we set two completely conflicting GPOs to act on the same Organizational Unit. Normally that would be plain silly, but we then use two security groups that already exist to give one security group access only to the lockdown GPO and one security group access only to the unlock GPO. Whenever we create computer accounts in that Organizational Unit, we place the computers in the lockdown security group. That means the computers in that security group automatically receive the lockdown policy. If we decide that we need to do work in that lab and wish a particular client, or all clients, unlocked, all we do is make the relevant computers members of the unlocked security group and finish off by rebooting them or waiting for a refresh. As long as we never place a computer object in both groups, we have a client that is either locked or unlocked depending on its group memberships.

This is a good demonstration of how you can make use of conflicting GPOs on a single Organizational Unit based solely on permission granted by the ACLs to those GPOs, one of the most important aspects of GPOs.

10.1.12 Loopback Merge Mode and Loopback Replace Mode

Loopback mode is a specially configured GPO option that allows you to apply the user portion of a GPO to a user based on the computer he is logging on from. For example, imagine we have a suite of public kiosks in the foyer of our organization to give outsiders information about the company. Company employees can also use these devices if they want to check email quickly on their way in or out. Since literally anyone in the building can use the kiosks, we need a lot of security. We don't want those kiosks to allow company employees to have all the privileges and permissions that they normally would at their desktop devices; we want them to be able to use only email. What we can do is tie a set of user restrictions into the user portion of a GPO that sits on the Organizational Unit that holds the computer objects. Then employees are locked down at the kiosks and nowhere else. This effectively allows us to restrict what employees can do to their own settings on a per-machine basis.

Many administrators can see the use of this setting in certain environments and for certain situations. Take a lab of machines in a university where staff accounts are to be locked down like student accounts while the staff members are in the lab, but not when they are at their private machines. As a final example, consider that the Finance Organizational Unit users have a lot of deployed applications specific to Finance. These applications are to work only when accessed from the finance computers and not from anywhere else. So you would put them as deployed applications into the computer section of GPOs that apply to the Finance Organizational Unit. However, if you also deployed to finance users (via the user portion of a GPO) applications that were supposed to roam with the users everywhere except in sales and marketing, you could use loopback mode to stop the applications from being advertised specifically in those two Organizational Units.

Loopback mode can be found in the Group Policy settings of the computer portion of any GPO (i.e., Computer Configuration Administrative Templates System Group Policy User Group Policy loopback processing mode). If you open that item, you get the dialog box shown in Figure 10-6, which allows you to switch between the two modes of loopback operation: merge mode and replace mode.

Figure 10-6. Setting loopback mode

When a user logs on to a machine that uses loopback merge mode, the user policies are applied first as normal; the user portion of any GPOs that apply to the computer are applied in sequence, overriding any of the previous user policies as appropriate. Replace mode, by contrast, ignores the GPOs that would apply to the user and instead applies only the user portions of the GPOs that apply to the computers. Figure 10-7 illustrates this.

Figure 10-7. Loopback mode processing

In Figure 10-7, the domain mycorp.com spans two sites, Main-Site and Second-Site. Marketing computers exist in Main-Site, and finance computers in Second-Site. Policy A applies to Main-Site only, Policy B applies to the entire domain, and C, D, E, and F apply to the Organizational Units as indicated. Policy G applies to Second-Site.

Table 10-1 summarizes the position. When loopback is not turned on, the only real difference comes from the site policies (A or G) that are applied. When you turn replace mode on for all the GPOs, it becomes more obvious what will happen. In each case, the policy relating to the user is applied first in order, followed by the entire set of policy items that would apply to a user residing in the computer location. Take the example of a finance user logging on at a marketing computer in the main site. The Finance user first has the user portion of the site policy that she is logging on from applied (A), followed by the user portion of the domain policy (B), the user portion of the Accounting Organizational Unit (E), and the user portion of the Finance Organizational Unit (F). After this, the user portion of the site (A) is applied again, followed by the user portion of the domain policy (B), the user portion of the Business Organizational Unit (C), and finally the user portion of the Marketing Organizational Unit (D).

Table 10-1. Resultant set of policies for Figure 10-7

Loopback mode in use	Organizational unit that user resides in	Where computer resides	Resultant set of policies
No	Marketing	OU=marketing (main site)	ABCD
No	Finance	OU=finance (second site)	GBEF
No	Marketing	OU=finance (second site)	GBCD
No	Finance	OU=marketing (main site)	ABEF
Merge	Marketing	OU=marketing (main site)	ABCDABCD
Merge	Finance	OU=finance (second site)	GBEFGBEF
Merge	Marketing	OU=finance (second site)	GBCDGBEF
Merge	Finance	OU=marketing (main site)	ABEFABCD
Replace	Marketing	OU=marketing (main site)	ABCD
Replace	Finance	OU=finance (second site)	GBEF
Replace	Marketing	OU=finance (second site)	GBEF
Replace	Finance	OU=marketing (main site)	ABCD

Remember that later policies can override earlier policies, so the user portion of the policies applying to the location of the computer will always override previous policies if there is a conflict. With policy order ABEFABCD, D can override C, which can override B, which can override A, which can override F, and so on. Also, in all these cases, if any of the computer GPOs do not have any defined settings in the user portion, the policy is ignored.

Loopback replace mode is used when the user portion of the GPOs that apply to a computer are to be the only ones set. For the finance user logging on to a computer in marketing in the main site, the only policies that get applied to that user are ABCD, the user portions of the GPOs that apply to the marketing computer.

Administrators must be aware that loopback mode can impose a significant amount of extra load on the processing at the client, especially when using loopback in its merge mode.

10.1.13 WMI Filtering in Windows Server 2003

Microsoft has added a powerful new GPO filtering option in Windows Server 2003 Active Directory called Windows Management Interface (WMI) filtering. With WMI filtering you can associate a WMI query with a GPO, which will run for each user and computer that the GPO applies to. A WMI filter can utilize any WMI-based information that is accessible from the client's machine, including computer hardware and configuration, user profile, and environment settings. This presents a lot of options for targeting GPOs to clients that have certain properties. For example, let's say you want to apply a certain GPO if a client is accessing your network over VPN. Depending on which VPN software the client is running, your WMI query could check for the existence of a process or service or even an IP address range. If the query returns true, the GPO will be applied; if it returns false, it will not be applied. Figure 10-8 shows the screen in the Group Policy Object Editor that allows you to configure a WMI filter.

Figure 10-8. WMI filter setting

Windows 2000 clients ignore WMI filtering. It only applies to Windows XP and later systems.

10.1.14 How GPOs Work Across RAS and Slow Links

GPOs and even user profiles can still work across slow links, and a lot of the configuration is left in the hands of the administrator. Administrators can specify what speed is used in the definition of a slow link. For computers and users, the following policy areas need looking at:

Computer Configuration Administrative Templates System Group Policy Group Policy Slow Link Detection

User Configuration Administrative Templates System Group Policy Group Policy Slow Link Detection

In both cases, the default setting is 500 KBps, but administrators can set any KBps connection speed time that they wish. This speed is used against a slow-link-detection algorithm; if the speed is above the value, the link is fast; a speed below the value indicates a slow link.

This is the algorithm in pseudocode:

Ping server with 0KB of data : Receive response#1 as a time in 
  milliseconds (ms)
If response#1 < 10ms Then
   Else
        milliseconds
   End If
Ping server with 0KB of data : Receive response#1 as a time in 
  milliseconds
If response#1 < 10ms Then
   Else
           milliseconds
   End If
Ping server with 0KB of data : Receive response#1 as a time in 
  milliseconds
If response#1 < 10ms Then
   Else
           milliseconds
   End If
   
'Average the total speed of (response#2-response#1)
Difference-in-milliseconds = Total-Speed/3
'If we know 4KB (32,768 bits) was moved in a certain number of 
  milliseconds, 
'then we need to calculate the number of bits moved per second 
  (not per ms)
Bits-per-second-value = (32768 * 1000/Difference-in-milliseconds)
'Eight bits is a byte, so calculate bytes/second
bps-value = (Bits-per-second-value * 8)
'Calculate kilobytes/second to compare against GPO value
Kbps-value = bps-value / 1024

User profiles work in a similar manner. The following setting supports both checking the performance of the filesystem and checking the speed of the user profile server in both kilobytes per second and milliseconds. This was included by Microsoft to get past problems where the user profile server was not IP capable; in this case, it checks the filesystem performance instead:

Computer ConfigurationAdministrative TemplatesSystemGroup Policy Slow network connection timeout for user profiles

The following GPOs are applied across slow links:

• When a user dials in from a RAS connection, both computer and user GPOs are applied.

• When a user logs in using the "Logon using dial-up connection" checkbox on the logon screen, user policies are applied.

• When the computer is a member of the same domain as the RAS server or is in a domain with a trust relationship to the one the RAS server is in, both are applied.

GPOs are not applied:

• When the logon is done using cached credentials which then include a RAS connection.

• To computers that are members of a different domain or workgroup.

By default in all these cases, security settings (i.e., IP security, EFS recovery, etc.) and Administrative Template settings are the only ones to be applied by default; folder redirection, disk quotas, scripts, and software installation policies are not applied. You can't turn off registry settings you have to apply. You can, however, alter the default state of any of the others, including the security settings, using the relevant sections of those GPOs.

10.1.15 Summary of Policy Options

That's a lot of information on GPOs. Let's summarize what we've covered about the workings of GPOs so far:

• GPOs exist in a split state. The configuration data for the GPO, known in shorthand form as GPC data, is held in the AD object itself. The template files and settings that tell the GPO what its capabilities are, known in shorthand form as GPT data, are stored in the SYSVOL.

• Individual GPOs can be linked to multiple sites, domains, and Organizational Units in Active Directory as required.

• GPOs can contain policies that apply to both computers and users in a container. The default operation of a GPO on a container is to apply the computer portion of the GPO to every computer in that container during boot up and to apply the user portion of the GPO to every user in that container during logon. GPOs also can be set to refresh periodically.

• Multiple GPOs linked to a particular container in Active Directory will be applied in a strict order according to a series of priorities. The default-prioritized order corresponds to the exact order in which the GPOs were linked to the container. Administrators can adjust the priorities as required.

• While GPOs exist only in a domain environment due to their dependence on Active Directory, individual domain or workgroup computers can have local GPOs, known as LGPOs, defined for them.

• Windows NT 4.0 system policies also can apply to standalone Windows NT or later clients or to mixed-mode or Windows Server 2003 Interim domain clients.

• GPOs are inherited down the Organizational Unit hierarchy by default. This can be blocked using the properties of an OU, domain, or site. Administrators can also set a checkbox that allows a policy to override all lower settings and bypass any blocks.

• Loopback mode allows the administrator to specify that user settings can be overridden on a per-machine basis. Effectively, this means that the user parts of policies that normally apply only to computers are applied to the users as well as (merge mode) or instead of (replace mode) the existing user policies.

• A new feature in Windows Server 2003 Active Directory called WMI filtering allows you to configure a WMI query that can be used as additional criteria to determine whether a GPO should be applied. If the filter evaluates to true, the GPO will continue to be processed; if it evaluates to false, the GPO will not be processed. This is a powerful feature because you have the vast amount of WMI data available to determine whether GPOs should be applied.

• A number of things can slow down processing on a client, including attempting to process many policies one after the other. Use of loopback, especially in merge mode, can significantly impact this. Attempting to apply GPOs across domains can also lead to slowdowns depending on the network speed between the domains. Finally, complex queries in WMI filters can also have a negative impact on GPO processing.

• Policies are applied in a strict order known as 4LSDOU. This notation indicates that Windows NT 4.0 system policies are applied first, followed by any LGPO policies, followed by site GPOs, domain GPOs, and finally any Organizational Unit GPOs hierarchically down the tree. At each point, the policies are applied in prioritized order if multiple policies exist at a location.

• When policies are to be applied to a client, the system identifies the entire list of policies to be applied before actually applying them in order. This is to determine whether any blocking, overriding, or loopback has been put in place that could alter the order or application of the policies.

• ACLs can be used to limit the application of GPOs to certain individual users or computers or groups of users or computers. Specifically setting up the ACLs on a GPO to deny or allow access means that you can tailor the impact of a policy from the normal method of applying the GPO to all users or computers in a container.

• If you use the GPOE MMC interface and look at the properties of an individual GPO, four tabs are displayed on the property page. The General tab shows you summary details on the policy and allows you to disable the computer or user part of the policy if you require. The Links tab allows you to find all locations in Active Directory that have links to that GPO. The Security tab allows you to limit the scope of the GPO on a container via ACLs. Finally, the WMI Filter tab allows you to configure a WMI filter to be used for GPO processing.

• Finally, both user profiles and policies can be applied across a slow link, but the speed that the system uses to determine whether a link is slow is configurable by the administrator within an individual GPO. In addition, while security settings and administrative templates normally are applied by default, the exact settings that will apply across a slow link when one is detected are configurable by the administrator as well. The only exception is that administrative templates will always be applied; the administrator has no control over this.