Group Policy
Physical Structure
Every group policy object (GPO) consists of two components: a) an Active Directory object
known as the group policy container (GPC), which contains GPO attributes, such as name and
version number, and b) a folder structure known as the group policy template (GPT), which is
located under the sysvol share and replicated among domain controllers (DCs). A GPO is
simply the sum of these two components. Each GPO is identified by a single globally unique
identifier (GUID), a 128-bit (32-digit) number enclosed in braces. A GPO’s GUID is used for
both its GPC and GPT parts. Though each GPO is assigned a name, this name is merely a
descriptor used for the administrator’s convenience. Microsoft Windows ® 2000 identifies and
keeps track of a GPO and its parts by its GUID.
Each GPO is stored in the domain in which it was created; however it can be linked to sites,
other domains, and OUs anywhere in the forest. GPOs are stored only on Windows 2000
domain controllers, since these are the only computers hosting Active Directory and the sysvol
share.
A GPT with a GUID of {31B2F340-016D-11D2-945F-00C04FB984F9} is located under the
following paths:
Local path:
%systemroot%\SYSVOL\sysvol\<DNS_DomainName>\Policies\{31B2F340-016D-11D2-945F00C04FB984F9}
For example: e:\winnt\SYSVOL\sysvol\lab.twc-us.local\Policies\{31B2F…B984F9}
UNC path:
\\<DomainController_NetBIOS_Name>\sysvol\<DNS_DomainName>\Policies\{31B2F340016D-11D2-945F-00C04FB984F9}
For example: \\DomSrv21\sysvol\lab.twc-us.local\Policies\{31B2F…B984F9}
Application Logic
1. Every Group Policy Template consists of two parts:
a. Computer Configuration, and
b. User Configuration.
How are these two parts applied?
When a computer is authenticated by a DC, the Computer Configuration settings in the
GPOs that apply to that computer account are put into effect, while the User Configuration
settings are ignored. Conversely, when a user is authenticated by a DC, the User
Configuration settings in the GPOs that apply to that user account are put into effect, while
the Computer Configuration settings are ignored.
In general, Group Policy settings (both Computer and User Configurations) are applied to a
computer by placing keys and values in its Registry. For example, consider settings in the
Administrative Templates folders. Computer Configuration template settings are applied to
the HKEY_LOCAL_MACHINE subtree of the Registry, while User Configuration template
settings are applied to the HKEY_CURRENT_USER Registry subtree.
How does Windows determine which GPOs apply to a user or computer?
First, Windows locates the computer or user account in the AD hierarchy. Next, all Site,
Domain, and OU containers that indirectly or directly contain the computer or user account
Copyright © 2001 Trinity Worldwide Corporation. All rights reserved.
Page 1
Group Policy
are located. (This is related to the concept of “scope”. See item 2. below for greater detail.)
Next, Windows compiles an ordered list of all GPOs linked to each of these containers. The
list begins with the highest container (for example, a Site) and ends with the lowest
container (for example, an OU) in the hierarchy. This is the order in which the GPOs will be
applied. Because lower level GPOs are applied after higher level ones, the lower level
GPOs will override the higher level GPOs, whenever they have settings in common.
Next, GPO link Options (No Override, Disabled), AD container Properties (Block Policy
Inheritance), and GPO object Properties (Disable Computer/User Configuration settings)
and Security settings (GPO filtering) are applied to eliminate from the list those GPOs and
those policy settings that do not apply to the specific computer or user. Finally, the
remaining GPOs and settings are sent to the client computer to be applied by it.
Example 1.1:
GPO-1 is linked to the Research OU in the XYZ.com domain and has both Computer
Configuration and User Configuration settings enabled. GPO-1 Security settings grant Read
and Apply Group Policy to Authenticated Users (users and computers) in its OU. Among its
various child objects, the Research OU contains a computer account "C-1" and a user
account "JHenry". John Henry boots his Windows 2000 Professional domain member
computer (C-1) at 8:00 AM and waits for it to display an invitation to log on. During startup,
computer C-1 is authenticated by a nearby domain controller, and since C-1 is a child
computer object of the Research OU, the Computer Configuration settings in GPO-1 are
applied to C-1's HKEY_LOCAL_MACHINE Registry subtree. At 8:38 AM, after consuming
his morning snack, John Henry logs on to the domain at computer C-1. He is authenticated
by a nearby domain controller, and since JHenry is a child user object of the Research OU,
the User Configuration settings in GPO-1 are applied to C-1's HKEY_CURRENT_USER
Registry subtree.
Thus, GPO-1 is separately and multiply applied: once when the computer is authenticated,
applying the Computer Configuration, then again when the user is authenticated, applying
the User Configuration. This occurs because both computer account C-1 and user account
JHenry are located under the Research OU in AD hierarchy.
If user account JHenry were a child of the Users container rather than the Research OU,
and if JHenry were a member of a global group named Researchers, which is a child object
of the Research OU, would GPO-1’s User Configuration settings by applied when John
Henry logged on? Answer: No. Same question, but change GPO-1 Security settings to
grant Read and Apply Group Policy only to Researchers? Answer: No. Why? Because
GPO-1 is linked to the Research OU, and JHenry is not a child object (is not in the scope) of
the Research OU. Therefore, GPO-1 won’t appear in the original list of GPOs to be applied
to JHenry, because this list is not built based on JHenry’s group memberships, but on its
location within the AD container hierarchy.
2. Group policy scope is the set of child objects, i.e. users and computers, to which a
particular GPO may be applied. If a GPO is linked to a site, then all computers located on
subnets of that site are within the Scope of the GPO.
If a GPO is linked to a domain, then all computers and users defined within that domain are
within the Scope of the GPO.
If a GPO is linked to an OU, then all computers and users which are child objects within the
subtree of that OU are within the Scope of the GPO.
Copyright © 2001 Trinity Worldwide Corporation. All rights reserved.
Page 2
Group Policy
Looking at scope in reverse, you can determine which GPOs may apply to a particular user
or computer object by analyzing the Active Directory subtree in which that object resides.
Here's how it is done. First, locate the object in the Active Directory tree. Next, trace upward
through the tree structure, noting each OU between the object and the domain in which it is
located. All of these OUs are containing OUs. Any GPO linked to a containing OU or to the
domain itself has the object in its scope and may apply to the object. I say "may apply",
because you then have to look at each GPO's permissions list to check for filtering and to
such properties as Block Policy Inheritance and Disable User Configuration to see whether
in fact that GPO applies to the object.
NOTE: If you have a GPO that is linked only to OUs which have no child computer objects
anywhere in their subtrees, and you have no plans for any, then disable the Computer
Configuration settings on the GPO Properties dialog, General tab, because there are no
computer accounts in the scope of these GPOs and Computer Configuration settings are
only applied to computers, never to users. A similar statement applies to child user objects
and the User Configuration settings.
3. To filter users and groups from the application of a GPO, where the default Security tab
settings are in effect for the Authenticated Users group (Allow box checked for both the
Read and Apply Group Policy permissions), use the following procedure:
Add the group or user account to the Name list on the Security tab and check Deny for the
Read permission. This is the minimum requirement. Optionally, you may also check Deny
for the Apply Group Policy permission.
4. Account Policies and Public Key Policies (under Computer Configuration) have domainwide scope. This means, for example, that Account Policies (Password and Account
Lockout) are not effective if applied through a GPO linked to an OU. These policies must be
applied through a GPO linked to a Domain.
Account Policies are handled differently from other policy settings. For example, on a
domain controller, Local Security Account Policies are ignored, even if Account Policy
settings remain "Not defined" in all non-local GPOs.
5. If you force (No Override) a filtered GPO at a given level, it will not apply to the accounts
filtered out, so the No Override option does not apply to them at lower levels. To illustrate
this, let’s look at an example.
Example 5.1:
Suppose you have a Domain with two OUs, Research and Sales, on the same level. Each
of these three containers has a different GPO linked to it as follows:

Domain: GPO-D
 Authenticated Users group removed
 Applies only to the Development group (everyone else is filtered out)
 User Configuration setting "Remove Run menu from Start menu" - enabled
 Forced (“No override” link Option set)

Research OU: GPO-R
 Applies to Authenticated Users group
 User Configuration setting "Remove Run menu from Start menu" - disabled
Copyright © 2001 Trinity Worldwide Corporation. All rights reserved.
Page 3
Group Policy

Sales OU: GPO-S
 Applies to Authenticated Users group
 User Configuration setting "Remove Run menu from Start menu" - disabled
Assume: The Development group is located in the Users container and is populated only
with user accounts located in the Research OU.
Result 1: All users in the Sales OU will see the Run menu, because they have been filtered
out of the range of application of GPO-D, and because the GPO-S setting requires the Run
menu to be displayed for everyone in the Sales OU.
Result 2: All users in the Research OU who are NOT members of the Development group
will also see the Run menu for the same reason as Result 1.
Result 3: Only those users in the Research OU who are also members of the Development
group will be denied the Run menu because only these users are in the range of application
of GPO-D, which forces removal of the Run menu over GPO-R’s objection.
Example 5.2:
Here's another example using the same Domain and OU hierarchy as Example 5.1, but
from a converse viewpoint.

Domain: GPO-D
 Applies to Authenticated Users group
 Read permission Denied to the Administrators built-in local group
 Read permission Denied to the Marketing domain local group
 User Configuration setting "Remove Run menu from Start menu" - enabled
 Forced (“No override” link Option set)

Sales OU: GPO-S
 Applies to Authenticated Users group
 User Configuration setting "Remove Run menu from Start menu" - disabled

Research OU: GPO-R
 Applies to Authenticated Users group
 User Configuration setting "Remove Run menu from Start menu" - disabled
Assume: The Marketing group is located in the Users container and is populated only with
user accounts located in the Sales OU. None of the Administrators are located in the Sales
or Research OU.
Result 1: All users in the Sales OU who are NOT members of the Marketing group will be
denied the Run menu, because Marketing has been filtered out of the range of application
of GPO-D.
Result 2: All users in the Research OU will also be denied the Run menu, because no one
but Administrators and Marketing is filtered out of the range of application of GPO-D.
Result 3: Because Administrators and Marketing are the only users who have been filtered
out of the range of application of GPO-D, they are the only users in the domain who will see
the Run menu.
Copyright © 2001 Trinity Worldwide Corporation. All rights reserved.
Page 4
Group Policy
Example 5.3:
Using Example 5.2 above, let us make one change to the Marketing group membership.
Suppose a user account, Tom Wilson, resides in the Users container (to which no GPO
may be linked), and suppose Tom is made a member of the Marketing Group.
Question: Will Tom Wilson see the Run menu?
Answer: Yes, because he is a member of Marketing, and the Marketing group is filtered out
of the range of application of GPO-D. (This assumes the Local Computer Policy does not
define this policy setting.)
NOTE: By keeping, for example, members of the Domain Admins and Enterprise Admins
groups within the Users container, the only GPOs that can ever by applied to members of
these groups are those at the Site and Domain levels.
6. The order of group policy application is Local Security Policy, Site GPOs (bottom up),
Domain GPOs (bottom up), and finally OU GPOs (bottom up) in order of nesting from
highest to lowest in the AD tree.
7. You can only Block Policy Inheritance at the Domain and OU levels. This option is grayed
out at the Site level. The reason for this is twofold: a) there are no Active Directory levels
above Site to be blocked, and b) though Local Security Policy is not considered a level, it is
applied before Site GPOs, and you can't block Local Security Policy. Its settings are loaded
into the Registry first, and remain there unless overridden by non-local GPOs.
For example, checking Block Policy Inheritance at the domain level will block Site GPOs,
but not Local Security Policy (except for Account Policy settings as noted above).
8. When blocking group policy inheritance, you do this for an entire Domain or OU container,
not for a GPO. The Block Policy Inheritance check box has nothing to do with any GPOs
that might or might not be linked to that Domain or OU. For example, you can block policy
inheritance at an OU that has no GPO linked to it. You might want to do this if the OU is the
parent of several subordinate OUs where all the user and computer child objects are
located. By blocking group policy inheritance at the parent OU, you avoid having to block
inheritance individually at each subordinate OU.
9. When blocking group policy inheritance at an OU, you block all policy settings in all
applicable, non-forced GPOs at higher levels (Site and Domain), regardless whether GPOs
linked to the OU redefine these settings or just leave them "Not defined"/"Not configured".
10. When trying to determine which GPOs will be applied to a computer where permission
filtering is used, consider only Authenticated Users, individual computer accounts, and
security groups containing computer accounts. No amount of user account filtering in the
GPO's permission list will have any effect (Allow or Deny) on the application of the GPO to a
computer. This is because at the time the computer is being authenticated and the GPOs
are applied, no user has yet logged on, and there is no way for the domain controller to
know who will log on or when they will log on to the authenticating computer. That is why the
GPO’s User Configuration settings are NOT applied to the computer when it is
authenticated by a domain controller, only the Computer Configuration settings are applied.
It is only later, when the user logs on, that the domain controller will determine which GPOs
Copyright © 2001 Trinity Worldwide Corporation. All rights reserved.
Page 5
Group Policy
apply to the user account, and then the appropriate User Configuration settings in those
GPOs will be applied.
Copyright © 2001 Trinity Worldwide Corporation. All rights reserved.
Page 6