Designing Organization-wide Policies

Article
12/09/2009

By Alistair G. Lowe-Norris

Chapter 9 from Windows 2000 Active Directory, published by O'Reilly and Associates

This chapter takes a solid look at Group Policy Objects (GPOs) from two main perspectives:

How Windows 2000 GPOs actually work.
How to effectively structure your Active Directory using Organizational Units and groups so that you can make the best use of the GPOs required in your organization.

How Windows 2000 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.

How GPOs Are Stored in Windows 2000

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 would fill Active Directory with a huge volume of information for every GPO, which would make the system unwieldy. 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 Group-Policy-Container class within a single container in Active Directory at this location:

     LDAP://CN=Policies,CN=System,dc=windows,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.1rectory. This object, like all others, has attributes. One of the attributes of a GPO is a multivalued one called gPLink that stores Active Directory ADsPaths of the containers that the GPO is linked to. 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.

Let's consider the Group-Policy-Container class objects themselves. Take a look at FigureLabel,ExampleLabel,TableLabel]; I am using one of the Windows 2000 Resource Kit tools, ADSIEdit, to show the view of the Policies container and its children.

Figure 9-1: GPOs in the Policies container

Here you can see 10 Group-Policy-Container objects shown with their GUID as the Common-Name (cn) field. The Display-Name 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 an attribute called the GPC-File-Sys-Path 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 Policy2's Windows 2000 Group Policy technical white paper on their web site. and the Default Domain Controllers Policy, the only GPOs created automatically by the system on installation. The Default Domain Policy is also associated with a special system container created on installation located at:

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

Looking at FigureLabel,ExampleLabel,TableLabel], 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 80 entries under the Classes container that I haven't displayed. MSI applications tend to store large amounts of data in Active Directory. This particular policy is the one described in the introduction to the previous chapter https://www.oreilly.com/catalog/win2000ads/chapter/ch08.html. It applies the Administrator tools MSI file during an administrator-equivalent logon in order to install the tools on whatever workstation the administrator happens to log on. When the administrator logs off, it completely uninstalls the tools so that no subsequent users have access to them at that client computer.

How GPOs Are Used in Active Directory

Any GPO is initially created as a standalone object in Active Directory. Each object then can 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.

Now in the normal state of affairs, what you as an administrator would do is to open up the properties of the Site, Domain, or Organizational Unit, then create a GPO and link it to that location in one go. To 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 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.

So if I 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 I were to create a policy and link it to an Organizational Unit, then 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. FigureLabel,ExampleLabel,TableLabel] shows a scan for the locations in the domain Organizational Unit hierarchy to which mycorp.com has linked the Default Domain Policy. 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 9-2: Identifying GPO links

Figure 9-2: Identifying GPO links

I 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, then 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 applying to the entire set of users and computers in the container? Let's consider each of these questions to understand policies better.

Prioritizing the Application of Multiple Policies

Let's say that I 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 I set a domain GPO to set a series of Kerberos security settings for each user. Finally, I have two user logon scripts that I 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 as well.

To account for this, the GPOs for the site that the object resides in apply first in prioritized order. No other sites have any influence over this. Then, the GPOs for the domain that the object resides in apply 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 prioritized 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. I'll cover all these later in this section.

For example, Paul Burke has the following ADsPath to his account (see FigureLabel,ExampleLabel,TableLabel]):

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

Figure 9-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 potential.

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 with the user settings this time. The computer settings are ignored during user logon.3There is a setting that you can use to force a different mode of operation. I'll explain this later when I cover loopback mode.

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 that are 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 that are configured for a parent Organizational Unit that conflict with the same settings in another GPO configured for a child Organizational Unit, then 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.

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, then GPOs linked to parent Organizational Units up the tree are not applied to objects in this specific Organizational Unit or its children.

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

Refer back to FigureLabel,ExampleLabel,TableLabel] in the previous section. If I decide to block inheritance at the databases Organizational Unit, then Paul Burke will receive only GPOs directly defined on the databases Organizational Unit. If I decide to block inheritance at the gurus Organizational Unit, then 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, I 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 I 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 I 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, I could set my 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. My 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, I 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 it is not changed without the knowledge of the core group.

In 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.

When Policies Apply

I'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.4f the product.

You also can manually refresh policies on a client using the SECEDIT.EXE tool with the command SECEDIT /refreshpolicy option.

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 will apply in the normal way, just 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 the currently logged-on user and cause his machine to behave in an unusual or unstable manner. Let's consider a few examples:

I decide to use a GPO to deploy Office 2000, which comes with its own MSI files for use with the Application Deployment GPOs. The deployment goes well, but I later decide that I need to change a few registry keys governing the way Office operates. I add these into the appropriate parts of the GPO so that new users receive them and that rolling out these new registry keys to users currently running Office will not cause the running application to fail. I have to be careful as to whether I want the registry keys to apply during a refresh or during the next logon or boot up of the machine (depending on whether they are user or computer registry settings).
I 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 I want to remove it, so I 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.
I 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 0900 and receive a logon script message welcoming them to the system and telling them they have new mail at 1500 could be confused.

All of these show the problems with refresh. What if you do want refresh to occur? Consider this example:

I decide that I 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. I need this script to run once during logon and then every time the page changes. Every time I make a system change, I remove and re-add the logon script for the specific GPO that I wish to apply to all affected users. I then specify that the GPO should refresh periodically. The script is then run whenever I 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 are sensible.

Local Group Policy Objects

It is now possible for standalone or domain-member Windows 2000 workstations and member servers to hold their own Local Group Policies, known as LGPOs. LGPOs are applied prior to any GPOs on the site, but have restrictions in that they can contain only security settings, software policies, and scripts. File deployment and application deployment are not available in LGPOs.

As LGPOs are applied first 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, 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 with standard GPOs.

While LGPOs will be very useful in environments in which no DCs exist and Windows NT system policies really 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 will be 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, then the Active Directory GPO will prevail over the original LGPO.

If you do 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.

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 was 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.

In order to counteract this and bring all the policy settings under one roof, so to speak, Windows 2000 was 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, then reset on a regular basis. Any settings those users have set themselves will be overwritten by the proper administrator-set values. However, administrators still can 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 re-applied 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 it permanently.

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.

When to Use Windows NT System Policies

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

If you have downlevel clients that need policies applied to them, whether these policies already exist or need to be created from scratch, then you need to fall back on the old system policies that were provided for use on these systems. You cannot use the Windows 2000 GUI to administer these older policies, so you will need to use the old System Policy Editor (POLEDIT.EXE) tool that has been re-issued with Windows 2000 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 clients, you will have to reimplement your system policies as GPOs because Windows 2000 will not upgrade your system policies for use with Windows 2000.

I 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 https://support.microsoft.com/support

/ that can 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 client or member server, policies are evaluated in the following order:

Downlevel Windows NT 4.0 policy (POL) file
Windows 2000 local GPO

If you have a Windows 2000 client or member server in a mixed-mode domain, policies are evaluated in the following order:

Downlevel Windows NT 4.0 policy (POL) file
Windows 2000 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 client or member server in a native-mode domain, policies are evaluated in LSDOU order.

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. I can tell you that in my lab environment, I saw a slowdown when I started applying more than seven policies. Unfortunately, that data is of absolutely no use to you. Read on to see why.

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. I would not advocate taking my 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 three policies of 20 changes each will be slower than implementing one change of 60. I arrived at the value of 7 by using a series of tests with large and small policies in a lab environment. Whether there was one site GPO, one domain GPO, and five Organizational Unit GPOs or seven policies on one Organizational Unit and none anywhere else didn't seem to matter to the actual time taken to process the policies. However, the time factor is very important here and, again, it depends on the speed of your network, the speed of your client, the speed of your servers that are running as DCs, and so on. 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 five deep in order that policies do not take too much time during logon. This advice is still only half helpful, and I'll come back to it in the design section later.

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.

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. All you do is look at the properties of a GPO and check one box or the other in the General tab, as shown in FigureLabel,ExampleLabel,TableLabel].

Figure 9-4: Disabling part of a GPO

Figure 9-4: Disabling part of a GPO

With all the settings in a GPO, normally browsing both user and computer parts of the tree to see if each part was empty and whether any changes had been made would be a lengthy process. However, Microsoft has thought of this, and as FigureLabel,ExampleLabel,TableLabel] shows, the revisions indicate exactly how many changes have been made to the GPO. This can guide 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, thus can partially speed up the process.

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 for network bandwidth considerations, since the objects in Active Directory and the templates in the system volume need reading 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, then there is nothing stopping you from doing this.

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 will be applied to all machines in that site regardless of which domain in the forest they are in.

However, while multiple domains will receive the link information, those same domains will not receive the entire GPO itself. Instead, the GPO will reside in one domain and clients in the site will 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 for some reason were 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.

The Power of Access Control Lists on Group Policy Objects

The real problem with all the information 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 an Access Control List (ACL) associated with them; it follows that it must be possible to allow and deny access to GPOs 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. Take a look at FigureLabel,ExampleLabel,TableLabel]. This shows us that the system security group called Authenticated Users will be able to read and apply the Group Policy. If I unchecked the Apply Group Policy checkbox, then the Authenticated Users group would not receive this policy.

Figure 9-5: Access control entries for a GPO

Figure 9-5: Access control entries for a GPO

This is a significant feature of GPOs and one that you can heavily use to your advantage. Let's take a simple example in which I create a single GPO to roll out an internal application and link it to the finance Organizational Unit and the marketing Organizational Unit 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 I 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 I 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 will 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, then 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.

Loopback Merge Mode and Loopback Replace Mode

Due to overwhelming requests from the beta test sites, Leicester University included, Microsoft extended Group Policy to cope with a particular requirement that otherwise would have been very difficult. 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 I have a suite of public kiosks in the foyer of my organization to give outsiders information about the company. Company employees also can use these devices if they quickly want to check email on their way in or out. Since literally anyone in the building can use the kiosks, I need a lot of security. I don't want those kiosks to allow company employees to have all the privileges and permissions that they normally would at their desktop devices; I want them to be able to use only email. What I 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 me 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 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 applications to finance users (via the user portion of a GPO) that were supposed to roam with the users everywhere except in sales and marketing, you could use loopback mode to stop the applications 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. If you open that item, you get FigureLabel,ExampleLabel,TableLabel], which allows you to switch between the two modes of loopback operation: merge mode and replace mode.

Figure 9-6: Setting loopback mode

Figure 9-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; then 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. FigureLabel,ExampleLabel,TableLabel] illustrates this.

Figure 9-7: loopback mode processing

In FigureLabel,ExampleLabel,TableLabel], 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 the Second Site.

FigureLabel,ExampleLabel,TableLabel] 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 he 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 9- 1 Resultant Set of Policies for FigureLabel,ExampleLabel,TableLabel]

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 you want the user portion of the GPOs that apply to a computer to be the only ones set. So 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.

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 new Windows 2000 slow-link-detection algorithm; if the speed is above the value, then the link is fast, below the value indicates a slow link.

This is the algorithm in pseudocode, as it existed for beta 3.

Ping server with 0KB of data : Receive response#1 as a time in
  milliseconds (ms)
If response#1 < 10ms Then
          Exit as this is a fast link
Else
          Ping server with 4KB of data : Receive response#2 as a time in
     milliseconds
          Calculate Total-speed as response#2-response#1
End If
Ping server with 0KB of data : Receive response#1 as a time in
  milliseconds
If response#1 < 10ms Then
          Exit as this is a fast link
Else
          Ping server with 4KB of data : Receive response#2 as a time in
            milliseconds
          Calculate Total-speed as Total-speed + (response#2-response#1)
End If
Ping server with 0KB of data : Receive response#1 as a time in
  milliseconds
If response#1 < 10ms Then
          Exit as this is a fast link
Else
          Ping server with 4KB of data : Receive response#2 as a time in
            milliseconds
          Calculate Total-speed as Total-speed + (response#2-response#1)
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 Configuration\  Administrative Templates\System\Group 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.

Summary of Policy Options

That's a lot of information on GPOs. Let's summarize what I'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 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 system volume.
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/ 2000 clients or Windows NT/2000 mixed-mode 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 can 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 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.
Policies apply in a strict order known as 4LSDOU. This notation indicates that Windows NT 4.0 system policies apply 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 in order to determine if 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 MMC interface and look at the properties of an individual GPO, three 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, 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.

Using the Group Policy Editor Tool

Unfortunately at the present time, there is no programmatic way to manipulate GPOs via scripts. That's not to say that you can't interface to the objects using ADSI, but there has been no IADsGroupPolicy interface or similar to allow manipulation of the settings from a script. This isn't immediately surprising, since GPOs are quite complex and the actual interface would need to interface not only to Active Directory but also to the system volume if all GPO options were to become scriptable. Consider the introduction of ADM files and the publication of MSI-capable applications, and you have one large interface to come up with. I expect to see this rolled out in future versions of ADSI, but in the meantime, while scripting is out of the question, there is a way to programmatically add/edit/delete GPOs using fully compilable program code, such as C++. For more information, look up the IGroupPolicyObject interface defined in gpedit.h in the platform SDK for more details.

That leaves us with the GUI tool called the Group Policy Editor (GPE). This tool, however, can be accessed in a number of ways. As with all Windows 2000 tools, the GPE is an MMC snap-in that you use if you want to actually change a specific GPO or LGPO.

You can start a new or existing MMC and add the snap-in yourself if you like. If you do this, the snap-in will allow you to focus on only a particular GPO/LGPO. Each GPO/LGPO that you wish to change has to be loaded in as a separate GPE snap-in to the MMC; unfortunately, you can't tell the GPE to show you all policies in the tree, which would have been useful. However, in theory it is possible to save the console and start it from a command line with a parameter, in order to focus the GPE on a single GPO/LGPO of your choice. In practice, I've never got this to work on the beta builds that I've used, although I'm quite willing to admit that I may be getting the syntax wrong.

Managing LGPOs is done using the same GPE tool that you would use to manage GPOs. If you use the GPE from a workstation or server in a domain, then you can focus the snap-in to look at an LGPO on a local client. If you use the GPE on a standalone server or a workstation, then the GPE will automatically focus on the LGPO for that machine. No matter how the focus is shifted to look at an LGPO, the GPE will load only the extensions that are appropriate to the templates in use locally on that client. Domain-specific extensions are not loaded for LGPOs.

The GPE and Its Relationship with the PDC FSMO Role Owner

When you are editing GPOs, the GPE connects to and uses the FSMO PDC role owner. This ensures that multiple copies of the GPE on different machines are all focused on the same DC. This behavior may be overridden in two cases:

If the PDC is unavailable for whatever reason, an error dialog will be displayed, and the administrator may select an alternate DC to use.
Microsoft is also currently considering a GPE View menu option and/or a policy to allow the GPE to inherit from the DC that Active Directory Users and Computers MMC is focused on. This is likely to be most useful when there is a slow link to the PDC.

If GPOs are edited on multiple DCs, this could lead to inconsistencies because the last person to write to the GPO wins. For this reason, you should execute caution when multiple administrators regularly administer policies.

Starting an MMC and adding the GPE snap-in is not the normal method of accessing GPOs. In fact, there is a whole extended interface available from either Active Directory Sites and Services or Active Directory Users and Computers tool. If you open up the former, you can right-click any site and from the drop-down list select Properties, finally clicking the Group Policy tab on the resulting property page. If you open the latter, then you can right-click any domain or Organizational Unit container and follow the same steps. Ultimately, the Group Policy property page from any of these tools produces a window like FigureLabel,ExampleLabel,TableLabel] with a number of options. FigureLabel,ExampleLabel,TableLabel] itself is focused on the policies linked to the root of the mycorp.com domain. The following buttons are found on the Mycorp.com Properties menu:

Figure 9-8: Looking at the domain policies

Figure 9-8: Looking at the domain policies

New

This button allows you to create new GPOs and automatically link them to the container for this property page. Since FigureLabel,ExampleLabel,TableLabel] is the property page for the domain, any policies that are created and linked in here would be applied to the entire domain.

Add

This button allows you to link an existing GPO to the container for thisproperty page.

Edit

This button allows you to manipulate the currently selected policy in the display pane.

Delete

This button allows you to remove a policy. If do this, a dialog box will appear and ask if you wish to just remove the GPO's link to the container for this property page or to permanently delete the GPO.

Properties

This button allows you to bring up the properties of the GPO itself, i.e., the General, Links, and Security tabs in Figures 9-4, 9-2, and 9-5, respectively.

Options

This button allows you to set two specific options relating to the application of this GPO by bringing up a dialog box similar to that shown in FigureLabel,ExampleLabel,TableLabel].

No Override

This option allows you to force the settings of this GPO to apply no matter what other GPOs later attempt to block inheritance.

Disabled

This option allows you to completely disable the GPO's application to the current container. If you choose this option, any ACLs that you have set on this GPO to explicitly allow or deny application of this policy to individual users, computers, or groups will be ignored. This policy will not be applied under any circumstances.

Disabling the GPO is not the same as setting an ACE with the Apply Group Policy checkbox cleared for the group Authenticated Users. Denying the ability to apply group policy for a GPO to a group via an ACE is much more restrictive, as the restriction will apply to the GPO across all containers and not just for the one container, which is what the Options button allows you to do.

ads0909

Figure 9- 9 Domain Policy Options

Block Policy inheritance

This checkbox is used to indicate that policies from further up the 4LSDOU inheritance chain are not to be inherited by objects at this point and below. This is used when you want a particular level in the tree to define its own policies without inheriting previously defined ones above it. For example, a block at the site level blocks Windows NT system policies and LGPOs (i.e., 4L) from applying; a block at the domain level blocks 4LS; a block at an Organizational Unit level blocks 4LSD in addition to any other Organizational Unit parents above this level in the tree.

Up/Down arrows

These buttons allow you to prioritize multiple GPOs in the display pane. In FigureLabel,ExampleLabel,TableLabel] only one GPO is displayed, so these buttons are disabled.

GPE GUI Shortcuts

Some useful shortcuts supported by Explorer have been copied over to the GPE. For example, you can highlight a branch in the GPE and press * on the numeric keypad to automatically expand the entire tree at that point. You can press + and - on the numeric keypad to expand and collapse individual highlighted branches. You can also use the cursor keys to navigate up and down the list. The Tab key switches back and forth between the scope pane and the results pane.

One last point that is very useful: If you open up the GPE and double-click on any item, it brings up a floating property page window. There is nothing to stop you going back to the GPE and highlighting any other location in the tree, navigating using the cursor keys, and using the keys in the previous paragraph. Each item that you select, however, correspondingly modifies the floating property page. This means that you can see each item's description and options in the floating property page while navigating through the GPE as before.

Using GPOs to Help Design the Organizational Unit Structure

In EmphasisRomanparanum[ChapterStart] Citationparatext[ChapterTitle,ChapterTitleLeft], I described the design of the Active Directory Organizational Unit hierarchy. I also explained that other items have a bearing on that design. You see, there are two key design issues that affect the structure of your Organizational Units: permissions delegation and GPO placement. If you decide that your Active Directory is to be managed centrally rather than in a distributed fashion and that you will employ only a few GPOs that will be implemented mostly domain wide (rather than many GPOs on many Organizational Units), your Organizational Unit structure can be almost any way that you want it to be. It shouldn't make much difference whether you have 400 branches coming off the root or one container with every item inside it. However, if permissions over specific objects do need to be delegated to specific sets of administrators, then it will make more sense to structure your domain Organizational Units in a manner that facilitates that administration. This doesn't have to be the case, but it makes it much easier to use Organizational Units.

For example, if I have 1,000 users and 10 managers who each manages 100 users, I could put my 1,000 users in one Organizational Unit and then give the 10 admins permission to modify only their 100 users. This is a slow and daft way to run systems administration. What would be better would be to create 10 Organizational Units and put 100 users in each, giving each administrator permissions over his particular Organizational Unit. This makes much more sense, as the administrator can be changed very easily, it is easier to report on access, and so on. Sense and reducing management overhead are the overriding keys here; either solution is feasible, one is just easier to implement and maintain.

Permissions delegation is covered in more detail in EmphasisRomanparanum[ChapterStart] Citationparatext[ChapterTitle,ChapterTitleLeft] .

The same fundamental facts apply to GPOs. If you are going to need to apply multiple policies to multiple sets of users, it makes more sense and will be easier to manage if you set up multiple Organizational Units. However, this isn't always possible, for example, if the Organizational Unit structure that you have as an ideal conflicts with the one that you will need for permissions delegation, which again conflicts with the one you would like for GPO structuring.

Identifying Areas of Policy

I'm assuming that within your organization you will be writing a document that describes your plan for the security features you wish to use on your Windows 2000 system and exactly how those features will be implemented. Part of this document will relate to other security features of Windows 2000, such as Kerberos, firewalls, Active Directory permissions, and so on, but here we're concerned with GPOs.

First you need to identify the general policy goals that you wish to achieve with GPOs. There's no need to go into the exact details of each GPO setting and its value at this moment. Instead, you're looking at items like "Deploy financial applications" and "Restrict desktop settings." As you identify each general policy area, you need to note whether it is to apply to all computers or users in a site, to all computers or users in a single domain, or to a subsection of the user and computer accounts. If you aren't sure for some items, then put the items in more than one category. You end up with items like "Deploy financial applications to accountants in France" and "Restrict desktop settings in Southern Europe."

Once you have the general policy areas constructed, you need to construct an Organizational Unit structure that facilitates implementation of this policy design. At this point, you start placing computers and users in various Organizational Units, deciding if all objects in each container are to receive the policy or whether you will restrict application to the policy via ACLs. There are a number of questions you can ask yourself during this stage. To help with this, a loose set of guidelines follows the example in the next section.

Ultimately the document will need to specify exactly which GPO settings are to be applied, which groups you will set up for ACL permission restrictions, and what the Organizational Unit structure is going to be. It helps to explain justifications for any decisions you make.

To make the guidelines more meaningful, I'll show how you can structure a tree in different ways using a real-world example.

How GPOs Influenced a Real Organizational Unit Design

Leicester University needed an Organizational Unit structure that represented its user and computer population. The system needed to allow users from every department to roam anywhere on campus and log on to the system. User accounts were fairly generic across the system, with the main differences resulting only from membership in certain groups indicating the type of account the user had (staff, undergraduate, and so on). The main distinction came in the two sorts of machines that we maintain on campus: staff devices that exist in a number of staff member's offices, and open devices that exist in areas known as open area labs, which anyone could use. While staff machines always exist within a department, labs exist in certain locations and buildings throughout the university campus.

Having full Internet and drop-in access, we needed to make sure that these open area client devices were as secure as they could possibly be. This security had to extend to all users who logged on at the machines, whether they were staff or student. However, we also wanted to make sure that staff accounts were not locked down in their own departments. In other words, we wanted the user profiles of the staff users to be much more locked down only in the open area labs and nowhere else.

In terms of policies, we needed to apply quite a few. While the specifics aren't important here, we needed a number of policies to apply to different areas:

Area	Policies to Apply to
A	All computers and users in the domain
B	Users in specific departments
C	All clients (not servers)
D	All open area clients
E	All staff clients
F	Staff clients in specific departments
G	Open area clients in specific labs

With these requirements, we came up with a design. This was a lengthy process, but I'll try to break it down so that it makes sense. Let's take a look at the users themselves to start with.

Users were always members of a specific department, and this was how the university was structured in terms of its business, so it seemed logical to name the Organizational Units after the university departments. I should add, by the way, that Leicester University needed only one domain, the forest root domain in a single forest, for its organization; the Organizational Unit structure was much more important than the domain structure in this case. The overall Organizational Unit structure came out something like that shown in FigureLabel,ExampleLabel,TableLabel]. Each department is joined directly to the root of the domain, with the users (represented by the circles) being children of the departmental containers.

Figure 9-10: OU structure to hold user objects

Next, we needed an Organizational Unit structure that represented the distinct divisions of computers that existed throughout the university. There's no necessity to presume that your computers should go in the same Organizational Unit structure as your users, and that's how we approached the concept at Leicester. Initially, based on the policy areas, it seemed sensible to us to create an entirely new client tree that held only the machine accounts. This hierarchy ended up looking like the one in FigureLabel,ExampleLabel,TableLabel].

Figure 9-11: OU structure to hold computer objects

Here you can see the branch solely for the computer accounts, with two children that each hold lab locations or departments themselves. Notice how the staff machine branch of the tree looks remarkably like the user structure diagram from FigureLabel,ExampleLabel,TableLabel]. I'll come back to that in a minute. For now, let's see if we can successfully apply the policies properly to this hierarchy. Take a look at FigureLabel,ExampleLabel,TableLabel]; where the policies are shown using the letter notation from the earlier table. This screen looks very cluttered, but it simply depicts each policy area with indications of where the policy area is linked. The trapezoid is Microsoft's symbol for a GPO.

Figure 9-12: GPOs applied to the entire OU structure

Not every department and lab is listed in this screen. In a similar vein, I've linked the GPOs to only some of the Organizational Units, since that would be the case in reality. After all, if every department or lab were to receive a policy, then you might as well link the GPO to the parent.

The merits of collapsing the Organizational Unit structure

I've created a structure that is understandable and perfectly represents the business that we operate. That's a good achievement from this design. The next step is to consider whether the domain would be easier to manage if I merged the duplicated staff organizational units.

Take a look at FigureLabel,ExampleLabel,TableLabel]. This is the hierarchy if I do away with all the staff machine Organizational Units and put the staff computers directly into the departmental Organizational Units. Policy areas A and B stay the same. Policy area C has to apply to all clients so I can't use the clients Organizational Unit any more. I have two choices: link the policy to the domain and have it apply to all Organizational Units containing computers beneath the root or link the policy to each Organizational Unit under the root by hand. The latter solution also requires me to link the GPO to any new Organizational Units that I create under the root, if they are to receive the policy.

Figure 9-13: Another solution to the OU structure

The former is the easier solution to manage, so let's run with it and link policy area C to the domain root. Unfortunately, this means that the GPO is going to apply to any computer objects in the domain, including Organizational Units that we store servers in, such as the domain controllers Organizational Unit that exists under the root of the domain. We don't want this, so the only way forward here is to block policy inheritance at these server Organizational Units. You may see where this is going now. I've not only blocked policy area C from being inherited by these Organizational Units that contain servers, I've also blocked any other policies that may need to apply as part of policy area A. My only solution to fix this is to use my ability to force an override of policy area A down the tree. So much for a simpler solution. We now have at least one block in place (for the domain controllers Organizational Unit) and policies from area A overriding all blocks down the tree to make sure they get past the blocks I just set up. While this is a solution, it's starting to feel more complex than the one before. Isn't there a better way?

Yes, by making use of security groups. Forget about the blocks and inheritance for now and consider that instead I put all the computers that are not to get policy area C in a security group. I can then deny the Apply Group Policy permission to this particular security group, so that no members of the group ever have that policy applied to them. This is a much easier solution. However, it does mean that the administrators must remember that if a new computer is created that is not to receive the policy, it must be added to the group.

Policy areas D and G can still apply as they did before. Policy area F applies only to certain Organizational Units, so I just link F to the various departments under the root and carry on as before. However, I have more problems with E. Again, the choices are similar to the previous predicament: I could apply E to the department Organizational Units individually (remembering to do this for each new department I create), I could apply the policy to the domain root and use block inheritance–force override as before, or I could use groups again. The use of groups seems simpler, so let's go with that option. If I create a group for all the staff machines, I can just give the group permission to apply group policy to policy E in addition to removing the default permission for authenticated users to apply group policy. Now all users won't run the policy, by default, but members of the staff machines group will.

This is a different solution that now achieves the same goal. The solution that Leicester chose (the first design) required fewer groups and allowed a computer's or user's location in the hierarchy to dictate which policies were applied. The new solution that we've just worked through collapses the tree structure but instead makes more use of groups to indicate which policies are to apply.

In fact, this tends to be a rule: as you collapse a structure where a number of GPOs apply, you need greater control via groups or the use of block inheritance and overrides.

A bridge too far

I could go one stage further and remove the lab machines' Organizational Unit entirely. That would give me the same problems with policy area D that I had with E. The simpler solution is to add all lab machines into a group and allow only members of that group to access the policy.

You can continue on in this manner, removing Organizational Units and creating more groups until you actually end up with all objects in a single Organizational Unit under the domain. At that point, all the GPOs are applied to that Organizational Unit and you control access to the Organizational Units via groups. Prioritization of the order that the multiple GPOs would apply might be more of a nightmare in this situation.

I hope you can see that there are a number of options open to you when designing your Organizational Unit structure for GPOs. It doesn't really matter which method you choose, as long as you're happy with it. The Organizational Unit structure that Leicester adopted requires less maintenance, because you don't have to put an object in a group after creation; you just create it in the place in the tree that it is to receive policies from. That's less of an issue with the capabilities of ADSI, since the code to bind to the parent group and add the newly created object to that group is two extra lines of code.

We also created some other Organizational Units for specific functions. For example, one Organizational Unit holds all the groups that we ever created. That way, when we want to find a group, we know where it is. We also created a test Organizational Unit so that we could roll out policies and do testing with users and computers within test in the domain without affecting the existing user setup that was already in place.

It may appear that Leicester doesn't make much use of groups to control access to GPOs, but that's not the case. Just because we set the Organizational Unit structure up in a way that made sense to us doesn't mean that we shouldn't make good use of groups as well. Let me give you some examples. Look back at FigureLabel,ExampleLabel,TableLabel]. Policy areas D and G actually consist of a number of completely different and opposing GPOs that can affect all lab machines (D) or machines in specific labs (G). One group of settings entirely locks down the workstations in those labs from access to the hard disk and various control panels and places other security measures. Another raft of settings serves to unlock the machines entirely; in other words, this GPO is the complete opposite of the first. Further sets of GPOs allow us to put the lab into a mixture of the two states with some areas locked down and others remaining unlocked. These policies are applied as required to the specific lab Organizational Units, so that if all were to apply at the same time, it would be a complete fiasco. Instead, we use global security groups, one for access to each GPO, and make the computers from that lab members of each group.

To gain access to the policies, we move the computers from one group into another. If a client needs to be unlocked entirely, we move it to the unlocked group and reboot or wait until the policy refreshes. Similarly, if a user from zoology decides that he wants his machine locked down, we can apply the relevant GPOs to the zoology Organizational Unit, then place that machine in the global group that allows access to the GPO.

If we had a situation in which the client was either locked down or not locked down, we could have just used one group and had a lockdown state by default, with membership in the group implying an unlocked state or vice versa.

Loopback mode

I've held one important aspect of Leicester's GPO design until now, that of loopback mode. Leicester needs to use loopback mode in order to lock down both staff and students while they are in a lab environment. To do this successfully requires that the computer policies be separate from the user policies. When you add this requirement to the equation, it makes more sense to keep the lab part of the tree separate in some way from the other part of the tree. This will ensure that the user sections of the computer policies do not apply to any user accounts except during loopback mode. Both FigureLabel,ExampleLabel,TableLabel] and FigureLabel,ExampleLabel,TableLabel] have structures that will happily accommodate the requirement.

Guidelines for Designing GPOs

In this section, I provide guidelines that help you toward two critical design goals:

All policies should be applied quickly, so that users do not feel a significant impact by their processing.
All policies should be as easy as possible to administer and maintain.

With these two concepts in mind, let's take a look at the guidelines:

Design in a way that you feel comfortable

As shown in the example in the last section, it can be easier to do large designs by considering the user Organizational Unit and computer Organizational Unit structures separately. If you want to do them together and have a small enough network that you can easily do them together, that's fine. If not, try it the way we first did.

Restrict the number of policies that apply as best you can

In a perfect world, this wouldn't be important. But in the real world, the more policies you have, the more processing the client has to do in addition to its normal logon/boot up, the longer it will take to complete the process.

If you have multiple policies applying to an object from the same location in a tree, consider collapsing them into a single object, since this will process faster than multiple policies will. If the number of policies you are applying during a logon/boot up is larger than you can effectively get out to the client across the network or, more importantly, get the client to process, you need to consider reducing or collapsing the policies. If you need to apply a significantly large set of policies with many settings to log on that extends logon to five minutes, but feel that is acceptable to achieve this level of policy, that's fine.

When it comes down to it, only you know what you can accept, and you will need to do your own testing in this area to satisfy your constraints. If you have to have a client logged on in less than four seconds, you have to work within that constraint. I'm sure that Microsoft will release some guidelines on the matter after the launch of Windows 2000 as well. In the meantime, consider these points: Microsoft likes to recommend no more than five Organizational Units deep to make sure that you don't use too many GPOs. As we know, this isn't very helpful. Having one GPO applying at a site, one at the domain, and one at each of five Organizational Units means only seven GPOs. Having 10 applying at each level is 70. So it's not only how deep you nest your Organizational Unit structure that matters, it's how many policies you can apply. The unfortunate part, of course, is that it always comes back to how many settings you are applying in each policy.

The simple answer is that a faster machine with more RAM can apply more policies in less time than a slower PC with less RAM; consequently, for a network of heterogeneous clients, you will need to do testing on your own network to see how fast application of policies is and how much bandwidth that they take up. Sorry, but that's the way it is for now.

Use security groups to tailor access

While you can set up ACLs to allow or deny application of policy to an individual user or computer, it makes more sense to use groups to do this whenever you can. If you use groups, it lets you keep all policy access in one object and can make complex systems much more manageable.

Limit the use of block/force inheritance

You should be very cautious of blocking inheritance at locations in the tree unless you are quite sure that this is the right way to solve your problem. The repercussions from a simple blocking of inheritance can spiral quickly as you encounter areas of policy that need to override the block. Your well-designed system can become quite difficult to maintain if you block and override regularly. This is not to say that you should never use them, just exercise caution in their use.

Collapse the Organizational Unit design

If you wish, you can collapse your Organizational Unit design and make more use of groups (or even block inheritance/force override) to govern access to specific policies. These are both perfectly valid solutions, and you should use whichever you are more comfortable with. Remember the axiom that the more you collapse the Organizational Unit structure while maintaining or increasing the number of GPOs, the greater need for control via groups or block inheritance/force override.

Avoid using cross-domain GPO links

If you link GPOs across domains, the entire set of sysvol data as well as the object information itself needs to transfer over from the source domain whenever a user or computer needs to access it. So unless you have very fast links between the two domains with enough available bandwidth, you should duplicate the functionality of the GPO in the target domain instead of cross-domain linking.

Prioritize GPOs

Remember that it is possible to prioritize applications of multiple GPOs at the site, domain, or Organizational Unit level. This ordering of the application of policies allows you to add useful options to the administrator's toolkit. For example, if you need a group of users to reverse specific settings that are being applied by default as part of a larger set, create a new GPO with ACLs for this group that apply in the priority list to unset all the previous settings. This solution allows you to override a selection of previous settings without creating two GPOs, one with settings for everyone and one for just this group. The former allows you to add in settings to the main GPO and still have them apply to everyone, without needing to add them to the second GPO of the latter solution. Prioritizing GPOs can be very useful.

Increase processing speed

The main ways to increase processing speed are to reduce the number of GPOs that you apply, disable the computer or user portion of a GPO if it is not needed, or limit the use of block inheritance, force override, cross-domain linking, and loopback mode. All of these place an extra processing load on the client to some degree. A really bad mistake would be to use combinations of them.

Be cautious with Loopback mode

Loopback mode is a very useful tool but is another technology that you need to approach with caution. As a completely different set of policies replace mode) or a very large number of policies merge mode) will be applied to your users and since there are no Resultant Set of Policy (RSoP) tools in existence as I write this, you need to take great care to ensure that the policy received by a user is the one you expect.

In most cases, loopback merge mode will incur significant extra processing load on the client PC and extra bandwidth on the network. That's not to say it isn't useful, but you have to be very aware of the delays that could occur after its introduction. Loopback replace mode imposes less of a processing load, but it can still be a problem. If you are contemplating loopback mode, ensure adequate stress testing of user impact.

Limit how often GPOs are updated

This relates to two specific times. You should limit your modifications to GPOs that could immediately cause a policy refresh on all clients or users, as this could impose a slowdown across the network and on the client. It would be better to make the updates during scheduled systems maintenance times. You also should carefully control the policy refresh interval. You have to ask yourself if you really need to refresh policy every 10 minutes, whether every 24 hours might be sufficient? Make the refresh interval a sensible one.

Restrict blocking of domain GPOs

You should not block domain GPOs in order to specifically use LGPOs on a domain client without very good reasons. If you do choose to apply LGPOs only to a client, you need to be aware of the management overhead because each client needs to be managed individually. If you have 20 orphaned clients using LGPOs and you need to make a change, you need to make it 20 times, one per client. The whole concept behind GPOs was to aid centralized management and administration of distributed resources, not distributed management of distributed resources. Think carefully before going down this path.

Use test GPOs

I always recommend creating test GPOs and linking them to a branch of test Organizational Units set up for this purpose. No GPO should ever be applied to users or computers unless it has been fully tested.

Choose monolithic or segmented GPOs

While I would recommend keeping similar settings, or all settings relating to a particular item, in the same GPO, there is nothing stopping you from having only a few huge GPOs as opposed to a number of smaller GPOs. If you go for the monolithic approach, you process fewer GPOs, which is obviously faster; however, delegation is not as easy due to the fact that the policy contains so many settings. Segmented GPOs allows easier delegation but can impact performance. Mix and match the two to a level that you are comfortable with and that works for your network.

Designing Delegation and Change Control

Now that you've designed a policy-based implementation for your organization, you have to work out how you will maintain firm control over GPOs once you start deploying them. Specifically, you need to consider who will be managing your GPOs and how you will keep control over the wide-ranging changes they can make.

The importance of change control procedures

The best way to keep track of GPOs in your organization is through a series of change-control procedures. These will work well whether your GPO administrators are domain administrators or not. I suggest a file such as a Word document with tables, a spreadsheet, or even a database in a central location to hold data on each GPO, the settings that it applies, whether it applies to computers and users or both, the containers in Active Directory that it applies to, and so on. You also should add extra columns/fields to the data for the proposer of the original GPO and those people who ratified the change. If you add those fields/columns, every time a new change is made, it is added by the proposer to the existing data set. Then the proposer or the system automatically contacts the rest of the GPO administrators and asks them to review and ratify the change in the data set. Discussions could continue via email if there were problems preventing ratification or if items needed clarifying. Finally, when the GPO data is ratified by all, it can be regression-tested on test systems if that hasn't already been done and then implemented within Active Directory.

Default GPO Permissions

Any user, computer, or group needs both Read and Apply Group Policy in order to apply a policy. Active Directory ships with certain permissions already in existence for GPOs. These are:

Authenticated Users group has Read and Apply Group Policy.
Creator Owner has Full Control without an explicit Apply Group Policy.
Local System group has Full Control without an explicit Apply Group Policy.
Domain Admins group has Full Control without an explicit Apply Group Policy.
Enterprise Admins group has Full Control without an explicit Apply Group Policy.
Group Policy Admins group has Full Control without an explicit Apply Group Policy.

Administrators in the latter two groups are also authenticated users and so inherit the Read permission from that group. If you don't want administrators to have the user parts of GPOs applied on logon, set the Apply Group Policy setting to Deny for Domain Admins, Enterprise Admins, and possibly Creator Owner as well.

Designing the delegation of GPO administration

There are three types of permission that can be considered here:

The permission to allow sets of users to link policies to a domain or an Organizational Unit branch
The permission to allow sets of users to create GPOs
The permission to allow sets of users to change the GPOs themselves

Link delegation can be easily accomplished using the Delegation of Control Wizard that you get by right-clicking an object in Active Directory and choosing Delegate Control. Here you are actually delegating read and write access to the gPLink5 attribute of the GPO itself.6

The other GPO attribute that can be delegated in this way is called gPOptions. As discussed earlier and shown is FigureLabel,ExampleLabel,TableLabel], this deals with the area of blocking inheritance. If you're interested in how these attributes work, set up a few GPOs in your Active Directory. Then use ADSIEDIT from the Windows 2000 Resource Kit to examine the attributes of the newly created GPOs in this location:

LDAP://CN=Policies,CN=System,dc=windows,dc=mycorp,dc=com

Creation of GPOs is limited to those indicated in the sidebar by default. However, you can add users to the Group Policy Admins security group, which allows members to create new GPOs. If a member of Group Policy Admins creates a GPO, that user is set as the Creator Owner[dcross]{}[dcross] of the GPO and can continue to manage it. The Creator Owner of a GPO can manage the GPO, even if the user is removed from all groups that give GPO management privileges.

The Group Policy Admins group does not give full control to all GPOs in the domain, as the name implies.

Editing can be more problematic. Due to the underlying security restrictions in force, in order to open a GPO and look at it or modify it within the GPE, users must have write access to the GPO. Users also need to be able to write to the appropriate GPT directories as well, which non-administrators will not have the ability to do.

GPC data in Active Directory (i.e., the actual Active Directory object itself) will never inherit security permissions from parents up the tree. There is a special block in place that prevents this in Active Directory, so that all GPO ACLs have to be modified from within the Group Policy tools.

You can delegate edit access to new GPOs, as long as the people creating those GPOs are the ones that will be editing them, by placing those users into the Group Policy Admins group. If you also want to delegate edit access to more people or to GPOs that a user is not the Creator Owner of, then open up the properties of each GPO in turn and give the appropriate user or group of users Full Control to the policy. There is no simple way to give a set of users the ability to manipulate all GPOs in a domain very quickly; you have to go through the GPOs one at a time.

A word of warning before I finish up here. Correctly applied, GPOs are fundamental to the well-being of your Windows 2000 system. Policies incorrectly applied to the root of the domain could lock down the Administrator account or disallow logons at domain controllers. This is obviously a worst-case scenario, and you'd have to be a significant fool to get to that state of affairs in the GPE and then choose Save. However, there are mistakes that are much more likely to occur: a mistyped registry value that forces users to an invalid proxy server and thus stops Internet Explorer from working, forgetting to clear a checkbox and thus applying a policy down an entire branch of the tree (the default) when it was only to apply to the root of the branch, and so on. These changes have the potential to affect all users or computers throughout the tree, so I would caution you to keep the administrators of GPOs to a very select subset. If you allow nonadministrators the ability to create, change, and delete GPOs, then they have to be able to take responsibility for and be accountable for their actions. Users who are already administrator-equivalent will automatically be able to administer GPOs and should already be held accountable.

Creating customized GPEs for administrators

The GPE comes with a series of permitted snap-ins that normal administrators will get by default. These snap-ins allow administrators to manage all parts of a GPO. However, it is possible to ship customized GPEs that focus on only one GPO and load only certain permitted snap-ins. This allows you to state that Group 1 can manage this part of a policy and Group 2 that part of the same policy. This is a very useful tool that I encourage you to use when delegating administration, but you must be aware that just giving a restricted tool to certain users will not stop them from being able to manipulate other aspects of a GPO if they open up their own GPE and point it at the same policy.

To solve this problem, cast your mind back to the section when I was discussing the Administrative Templates (User) section, specifically the Windows Components › Microsoft Management Console › Restricted › Permitted snap-ins › Group Policy section. The best solution is to use the Restricted › Permitted snap-ins › Group Policy section of a GPO in order to allow and deny users or groups access to certain extensions. This covers you completely, since your users or groups can now run up only their own GPE with the extensions that you have explicitly permitted them to use.

Debugging Group Policies

If at any point you need to debug group policies, there are two mechanisms. The first is from Microsoft Knowledge Base article 154120 on Windows NT System Policies, but it applies equally well to Windows 2000. The article can be found at: https://support.microsoft.com/default.aspx?scid=kb;en-us;154120&sd=tech. The second is specific to Windows 2000 GPOs. Either or both can be used to help solve your problems.

Logging to a File Using a Checked Version of userenv.dll

The first method involves replacing the userenv.dll file with a checked version in order to get all policy data logged to a file. Checked versions of files have the debug options enabled and run considerably slower due to the extensive logging and checking involved in the lines of code. To start the debug process, follow these steps:

To enable the log file, rename the file called userenv.dll file in the %windir%\ system32 directory to userenv.orig or a unique name of your choice.
Copy the checked version of userenv.dll (which you can find on the Windows 2000 CD or obtain from Microsoft) to the %windir%\system32 directory of the client computer that you want to debug. The checked version of the userenv.dll file must match the version/build of Windows 2000 that you are using.
Start regedt32.exe and create a new value called UserEnvDebugLevel as a REG_DWORD in the HKLM\Software\Microsoft\WindowsNT\CurrentVersion\ Winlogon key.
Assign UserEnvDebugLevel the value 10,002 in hexadecimal format.
Restart the computer. From now on, log information will be recorded on this machine in the text file c:\winnt\debug\userenv.log.

When you are finished debugging, replace the checked version of the DLL with the normal version, remove the registry key, and reboot the client.

Verbose Logging to the Event Log

Verbose logging in the event log can be turned on by simply setting a registry key. Once the key exists with the correct value, logging is done automatically. The value, a REG_DWORD, is called RunDiagnosticLoggingGroupPolicy and needs to be created with a value of 1 in the HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Diagnostics key.

The value of 1 sets the logging to verbose mode; this is similar to what you get from the checked DLL in the previous section, although the checked version may yield slightly more information. Setting the value to 0 is the same as having the key absent and is known as normal logging, which is the default that Windows NT used to support. In other words, the key makes a difference only when set to a value of 1. It's really as simple as that.

This key is actually one of four currently supported keys that you can use at this location. You also can create RunDiagnosticLoggingIntellimirror, RunDiagnosticLoggingAppDeploy, and RunDiagnosticLoggingGlobal. The last turns Application Deployment, Intellimirror, and Group Policy logging on without needing to set all three individually.

Summary

While GPOs are more advanced than Windows NT System Policies, Microsoft is not standing still in their development. There are a number of areas in which GPOs are deficient and Microsoft is working on enhancements and fixes for the future. For example:

Microsoft is currently working on a mechanism to expose all GPO data using a standard Schema. This will allow automation and manipulation of the data in an easier way. This Schema will interface with the Windows Management Instrumentation (WMI)7's (DMTF) Web-based Enterprise Management (WBEM) initiative, which provides standards for accessing and sharing management information in an enterprise environment. initiative.
Various independent software vendors and Microsoft are aiming to ship tools that will enable you to see the Resultant Set of Policy on a client. Microsoft's tool will be very basic and will show such information as the policies applied to a user or computer and what policies would apply if a user logged in at that computer. The tools provided by the vendors are likely to be significantly richer.
Cutting and pasting GPOs within and between domains is currently not possible.

Microsoft recognizes how new and difficult these GPOs may seem and is producing copious documentation to help administrators in understanding and deployment. Their current raft of documentation is already proving useful enough that I feel that I don't have to duplicate it here and can simply reference it instead.

Alistair G. Lowe-Norris currently works as an Enterprise Programme Manager at Microsoft and previous to that was a system administrator at Leicester University in the UK. For the past two years, he has been responsible for the rollout of Windows 2000 and the replacement of the existing NetWare installation at the university. He holds an MCSE and MCIS, and is a frequent contributor to Windows NT Magazine.

We at Microsoft Corporation hope that the information in this work is valuable to you. Your use of the information contained in this work, however, is at your sole risk. All information in this work is provided "as -is", without any warranty, whether express or implied, of its accuracy, completeness, fitness for a particular purpose, title or non-infringement, and none of the third-party products or information mentioned in the work are authored, recommended, supported or guaranteed by Microsoft Corporation. Microsoft Corporation shall not be liable for any damages you may sustain by using this information, whether direct, indirect, special, incidental or consequential, even if it has been advised of the possibility of such damages. All prices for products mentioned in this document are subject to change without notice.

International rights = English only.

1	The GPC data part of a GPO is an object in Active Di
2	The default settings for these two policies can be found in Microsoft
3	This is the default case.
4	There is a chance that this will be taken out of the final version o
5	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 one called gPLink that stores Active Directory ADsPaths of the containers that the GPO is linked to.
6	When administrators create GPOs, the Domain Admins group becomes the Creator Owner.
7	WMI is an implementation of the Desktop Management Task Force