Welcome > Windows Server 2003 Technical Reference > Technologies Collections > Group Policy Collection > Core Group Policy Technical

Reference
In this section
Core Group Policy Architecture
Core Group Policy Physical Structure
Core Group Policy Processes and Interactions
Network Ports Used by Group Policy
Related Information
Core Group Policy or the Group Policy engine is the infrastructure that processes Group Policy components including
server-side snap-in extensions and client-side extensions. You use administrative tools such as Group Policy Object
Editor and Group Policy Management Console to configure and manage policy settings.
At a minimum, Group Policy requires Windows 2000 Server with Active Directory installed and Windows 2000
clients. Fully implementing Group Policy to take advantage of all available functionality and the latest policy settings
depends on a number of factors including:
Windows Server 2003 with Active Directory installed and with DNS properly configured.
Windows XP client computers.
Group Policy Management Console (GPMC) for administration.
The Group Policy engine is a framework that handles client-side extension (CSE) processing and interacts with other
elements of Group Policy, as shown in the following figure:
Core Group Policy Architecture
The following table describes the components that interact with the Group Policy engine.
Core Group Policy Components
How Core Group Policy Works
Core Group Policy Architecture
Back to Top
Page 1 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Component Description
Server (domain
controller)
In an Active Directory forest, the domain controller is a server that contains a writable copy of the
Active Directory database, participates in Active Directory replication, and controls access to network
resources.
Active Directory Active Directory, the Windows-based directory service, stores information about objects on a network
and makes this information available to users and network administrators. Administrators link Group
Policy objects (GPOs) to Active Directory containers such as sites, domain, and organizational units
(OUs) that include user and computer objects. In this way, policy settings can be targeted to users and
computers throughout the organization.
Sysvol The Sysvol is a set of folders containing important domain information that is stored in the file system
rather than in the directory. The Sysvol folder is, by default, stored in a subfolder of systemroot folder
(%\systemroot\sysvol\sysvol) and is automatically created when a server is promoted to a domain
controller. The Sysvol contains the largest part of a GPO: the Group Policy template, which includes
Administrative Template-based policy settings, security settings, script files, and information regarding
applications that are available for software installation. It is replicated through the File Replication
Service (FRS) between all domain controllers in a domain.
Group Policy
object (GPO)
A GPO is a collection of Group Policy settings, stored at the domain level as a virtual object consisting
of a Group Policy container and a Group Policy template. The Group Policy container, which contains
information about the properties of a GPO, is stored in Active Directory on each domain controller in
the domain. The Group Policy template contains the data in a GPO and is stored in the Sysvol in
the /Policies subdirectory. GPOs affect users and computers that are contained in sites, domains, and
OUs.
Local Group
Policy object
The Local Group Policy object (Local GPO) is stored on each individual computer, in the hidden
Windows\System32\GroupPolicy directory. Each computer running Windows 2000, Windows XP
Professional, Windows XP 64-Bit Edition, Windows XP Media Center Edition, or Windows Server 2003
has exactly one Local GPO, regardless of whether the computers are part of an Active Directory
environment.
Local GPOs are always processed, but are the least influential GPOs in an Active Directory
environment, because Active Directory-based GPOs have precedence.
Winlogon A component of the Windows operating system that provides interactive logon support, Winlogon is
the service in which the Group Policy engine runs.
Group Policy
engine
The Group Policy engine is the framework that handles common functionalities across registry-based
settings and client-side extensions (CSEs).
Client-side
extensions
CSEs run within dynamic-link libraries (DLLs) and are responsible for implementing Group Policy at the
client computer.
The CSEs are loaded on an as-needed basis when a client computer is processing policy
File system The NTFS file system on client computers.
Registry A database repository for information about a computer´s configuration, the registry contains
information that Windows continually references during operation, such as:
Profiles for each user.
The programs installed on the computer and the types of documents that each can create.
Property settings for folders and program icons.
The hardware on the system.
Which ports are being used.
The registry is organized hierarchically as a tree, and it is made up of keys and their subkeys, hives,
and entries.
Registry settings can be controlled through Group Policy, specifically, Administrative Templates (.adm
files). Windows Server 2003 comes with a predefined set of Administrative Template files, which are
Page 2 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...

Group Policy Engine Architecture
The primary purpose of Group Policy is to apply policy settings to computers and users in an Active Directory
domain. GPOs can be targeted through Active Directory containers, such as sites, domains, and OUs, containing
user or computer objects. The Group Policy engine is in userenv.dll, which runs inside the Winlogon service. This is
shown in the following figure.
Group Policy Engine Architecture and CSE Components
implemented as text files (with an .adm extension), that define the registry settings that can be
configured in a GPO. These .adm files are stored in two locations by default: inside GPOs in the Sysvol
folder and in the Windows\inf directory on the local computer.
Event log The Event log is a service, located in Event Viewer, which records events in the system, security, and
application logs.
Help and
Support Center
The Help and Support Center is a component on each computer that provides HTML reports on the
policy settings currently in effect on the computer.
Resultant Set of
Policy (RSoP)
infrastructure
All Group Policy processing information is collected and stored in a Common Information Model Object
Management (CIMOM) database on the local computer. This information, such as the list, content, and
logging of processing details for each GPO, can then be accessed by tools using Windows Management
Instrumentation (WMI).
WMI WMI is a management infrastructure that supports monitoring and controlling of system resources
through a common set of interfaces and provides a logically organized, consistent model of Windows
operation, configuration, and status.
WMI makes data about a target computer available for administrative use. Such data can include
hardware and software inventory, settings, and configuration information. For example, WMI exposes
hardware configuration data such as CPU, memory, disk space, and manufacturer, as well as software
configuration data from the registry, drivers, file system, Active Directory, the Windows Installer
service, networking configuration, and application data. WMI filtering in Windows Server 2003 allows
you to create queries based on this data. These queries (WMI filters) determine which users and
computers receive all of the policy configured in the GPO where you create the filter.
Page 3 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Group Policy Engine Architecture and CSE Components

RSoP Architecture
Resultant Set of Policy (RSoP) uses WMI to determine how policy settings are applied to users and computers. RSoP
has two modes: logging mode and planning mode. Logging mode determines the resultant effect of policy settings
that have been applied to an existing user and computer based on a site, domain, and OU. Logging mode is
available on Windows XP and later operating systems. Planning mode simulates the resultant effect of policy
Component Description
Group Policy
Engine
The framework that handles functionalities across CSEs, the Group Policy engine runs inside
userenv.dll.
Winlogon.exe A component of the Windows operating system that provides interactive logon support, Winlogon is the
service in which the Group Policy engine runs. Winlogon is the only system component that actively
interacts with the Group Policy engine.
Userenv.dll Userenv.dll runs inside Winlogon and contains the Group Policy engine and the Administrative
Templates extension.
gptext.dll Used to configure Scripts, IP Security, QoS Packet Scheduler, and Wireless settings.
fdeploy.dll Used to configure folder redirection
scecli.dll Used to configure security settings.
iedkcs32.dll Used to manage various Internet Explorer settings.
appmgmts.dll Used to configure software installation settings.
dskquota.dll Used for setting disk quotas.
Page 4 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
settings that are applied to a user and computer. Planning mode requires a Windows Server 2003 computer as a
domain controller. For RSoP functionality, using GPMC is recommended, which includes RSoP features integrated
with the rest of GPMC. In GPMC, RSoP logging mode is referred to as Group Policy Results; planning mode is
referred to as Group Policy Modeling.
The following figure shows the high-level architecture of RSoP for Group Policy Results and Group Policy Modeling:
RSoP Architecture
Windows Server 2003 collects Group Policy processing information and stores it in a WMI database on the local
computer. (The WMI database is also known as the CIMOM database.)This information, such as the list, content and
logging of processing details for each GPO, can then be accessed by tools using WMI.
In Group Policy Results, RSoP queries the WMI database on the target computer, receives information about the
policies and displays it in GPMC. In Group Policy Modeling, RSoP simulates the application of policy using the
Resultant Set of Policy Provider on a domain controller. Resultant Set of Policy Provider simulates the application of
GPOs and passes them to virtual CSEs on the domain controller. The results of this simulation are stored to a local
WMI database on the domain controller before the information is passed back and displayed in GPMC (or the RSoP
snap-in). This is explained in greater detail in the following section.
WMI and CIMOM
WMI provides a common scriptable interface to retrieve, and in some cases set, a wide variety of system and
application information. WMI is implemented through the winmgmt.exe service. The WMI information hierarchy is
modeled as a hierarchy of objects following the Common Information Model (CIM) standards.
This information hierarchy is extensible, which allows different applications and services to expose configuration
information by supplying a WMI provider. WMI providers are the interface between the WMI service and the
application´s data in its native format.
WMI data can be dynamic (generated on demand when required by a management application) or static. Static
data is stored in the CIMOM database. This data can be accessed at any time (security controls permitting) by
management applications. RSoP uses WMI and the CIMOM to write, store and query RSoP settings information.
Resultant Set of Policy Provider
RSoP in planning mode has the special requirement that no settings information is actually applied to the client
system during the RSoP data generation. In fact, in many planning scenarios, there might not be a computer or
user object to apply the settings to. To meet this requirement, the RSoP provider runs on domain controllers and
performs some of the functions of a client system for GPO application.
The RSoP provider is actually a WMI provider that performs the role of Winlogon in invoking CSEs to log RSoP
Page 5 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
information to the CIM repository. It takes parameters supplied by the RSoP wizard to select GPOs from the
directory. It uses the following parameters:
Scope of management (SOM). This is the combination of user object OU and computer object OU and Site
(although the latter is optional). Either the User or Computer SOM can be omitted but one must be specified.
This can be specified as either an existing computer, user, or both, or as existing OUs for the computer, user,
or both.
Security group memberships for the computer and user objects. By default, these are the existing
security group memberships if actual user or computer objects are chosen as the SOM. Security filtering can
be ignored entirely or a new or a modified set of groups can be chosen.
WMI filter. New or modified WMI filters can be applied to the GPOs during the RSoP generation.
RSoP provider is a service on a domain controller and runs in system context. There are two ramifications to this
design. The service manually evaluates the security descriptor of each GPO in the SOM against the user object and
computer object security identifiers (SIDs) and their security group membership. If Active Directory is locked down,
some security group membership analyses might fail until the user is provided the correct access.
In addition, because the RSoP provider has Domain Admin-equivalent access rights, some control needs to be
placed on who can generate RSoP information in the directory. This control is achieved by an extended access right
- GenerateRSoPData. To execute an RSoP session for a particular container, the user must have the Generate
RSoP (planning) access right for that container.
Planning Mode (Group Policy Modeling)
In planning mode, RSoP provider performs the RSoP data generation in the following steps:
1. RSoP tool gets the user, computer and domain controller name from the wizard.
2. RSoP connects to the WMI database on the specified domain controller.
3. WMI service in turn calls the WMI Provider (an out-of-process service provider) on the same computer to
create the RSoP data.
4. RSoP provider gets the list GPOs for the user and computer from Active Directory.
5. RSoP provider populates the WMI database with instances of the GPOs for user and computer.
6. The list of registered CSEs is retrieved. Each of the policy extensions is dynamically loaded in succession by
the RSoP provider and the list of computer and user GPOs is passed to each extension. Each policy
extension takes the list of GPOs and instead of applying the policy, it populates the WMI database with
instances of policy objects that describe the effective policy.
7. After the WMI database population is over, RSoP provider returns the namespace under which the RSoP
data was created to the WMI service. This returns the namespace to the RSoP tool.
8. The RSoP tool connects to the namespace on the WMI database on the domain controller. RSoP navigates
or iterates through the populated data in the WMI database using WMI enumeration APIs to retrieve the
policy data.
9. The RSoP data is displayed to the user. When the user is done looking at the RSoP data, the RSoP tool calls
RsopDeleteSession on the WMI service to delete the data in WMI´s database that was previously created.
Logging Mode (Group Policy Results)
In logging mode, the RSoP data generation is controlled by Winlogon and is part of the normal GPO processing
operation.
The Winlogon process retrieves the list of GPOs from the Active Directory using the security context of the user or
computer.
Winlogon process populates the WMI database with instances of the GPOs.
The list of registered policy extensions is retrieved. Each of the policy extensions is dynamically loaded in
succession by the Winlogon process and the list of GPOs is passed to each policy extension. Each extension
takes the list of GPOs and, in addition to applying the policy, it populates the WMI database with the policies
set and which GPOs applied them.
Page 6 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Understanding where GPOs are stored and how they are structured can help you troubleshoot problems you might
encounter when you implement Group Policy. Although GPOs can be linked to sites, domains, and OUs, they are
stored only in the domain. As explained earlier, a GPO is a virtual object that stores its data in two locations: a
Group Policy container and a Group Policy template.
Group Policy Container
A Group Policy container is a location in Active Directory that stores GPOs and their properties. The properties of a
GPO include both computer and user Group Policy information. The Policies container is the default location of
GPOs. The path to the Policies container, in Lightweight Directory Access Protocol (LDAP) syntax, is
CN=Policies,CN=System,DC=Domain_Name,DC=Domain_Name, where the Domain_Name values specify a
fully qualified domain name (FQDN).
The Active Directory store contains the Group Policy container of each GPO in the domain. The Group Policy
container contains attributes that are used to deploy GPOs to the domain, to OUs, and to sites within the domain.
The Group Policy container also contains a link to the file system component of a GPO - the Group Policy template.
Some of the information in a Group Policy container includes:
Version information. Ensures that the information is synchronized with the Group Policy template
information.
Status information. Indicates whether the user or computer portion of the GPO is enabled or disabled.
List of components. Lists (extensions) that have settings in the GPO. These attributes are
gPCMachineExtensionNames and gPCUserExtensionNames.
File system path. Specifies the Universal Naming Convention (UNC) path to the Sysvol folder. This attribute
is gPCFileSysPath,
Functionality version. Gives the version of the tool that created the GPO. Currently, this is version 2. This
attribute is gPCFunctionalityVersion.
WMI filter. Contains the distinguished name of the WMI filter. This attribute is gPCWQLFilter.
System Container
Each Windows Server 2003 domain contains a System container. The System container stores per-domain
configuration settings, including GPO property settings, Group Policy container settings, IP Security settings, and
WMI policy settings. IP Security and WMI policy are deployed to client computers through the GPO infrastructure.
The following subcontainers of the System container hold GPO-related settings:
Policies. This object contains groupPolicyContainer objects listed by their unique name. Each
groupPolicyContainer object holds subcontainers for selected computer and user policy settings.
Domain, OUs and Sites. These objects contain two GPO property settings, gPLink and gPOptions.
Default Domain Policy. This object contains the AppCategories container, which is part of the Group Policy
Software installation extension.
IP Security. This object contains IP Security policy settings that are linked to a GPO. The linked IP Security
policy is applied to the recipients (user or computer) of the GPO.
WMIPolicy. This object contains WMI filters that can be applied to GPOs. WMI filters contain one or more
Windows Query Language (WQL) statements.
System\Policies Container
The System container is a top level container found in each domain naming context. It is normally hidden from view
in the Active Directory Users and Computers snap-in but can be made visible by selecting "Advanced Features" from
the snap-in View menu inside MMC. (Objects appear hidden in the Active Directory Users and Computers snap-in
when they have the property showInAdvancedViewOnly = TRUE.) Group Policy information is stored in the Policies
Core Group Policy Physical Structure
Back to Top
Page 7 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
subcontainer of this container. Each GPO is identified by a GroupPolicyContainer object stored within the Policies
container.
The Group Policy container is located in the Domain_Name/System/Policies container. Each Group Policy
container is given a common name (CN) and this name is also assigned as the container name. For example, the
name attribute of a Group Policy container, might be: {923B9E2F-9757-4DCF-B88A-1136720B5AF2}, which is also
assigned to the Group Policy container´s CN attribute.
The default GPOs are assigned the same Group Policy container CN on all domains. All other GPOs are assigned a
unique CN. The default GPOs and their Group Policy container common names are:
Default Domain Policy: {31B2F340-016D-11D2-945F-00C04FB984F9}.
Default Domain Controllers Policy: {6AC1786C-016F-11D2-945F-00C04fB984F9}.
Knowing the common names of the default GPOs will help you distinguish them from non-default GPOs.
How a Group Policy Container is Named
Group Policy containers are named automatically when they are created. The CN of each Group Policy container is a
GUID (Globally Unique Identifier). This is distinct from and unrelated to the Object GUID given to each Active
Directory object. The CN is the name of the Group Policy container used to ensure uniqueness of Group Policy
container names within the Policies container. There is no requirement for these GUIDs to be unique between
domains (the Default Domain Policy and the Default Domain Controllers Policy GPOs each have identical GUIDs in
all Active Directory installations). However, an Object GUID is always unique across all installations of the Active
Directory store.
The following table shows permissions on Group Policy container:
Default Group Policy Container Permissions

GPO Attributes in the Policies CN
GPOs are created by instantiating the groupPolicyContainer class in the Active Directory schema and storing the
resulting GPO in the System/Policies container of the Active Directory store. After creating a GPO, you can review
its CN from the Active Directory Users and Computers snap-in by enabling the Advanced view and then expanding
the Policies CN. You can review all GPO attributes and their values from the Active Directory Services Interface
Editor snap-in, ADSI Edit.
Object attributes are either mandatory or optional, as defined in the Active Directory schema. The CN attribute is
mandatory for the class Container, Group Policy container´s parent class. Three attributes - instanceType,
objectCategory, and objectClass - are mandatory for the class Top, CN´s parent class. Thus the Group Policy
container class inherits all four mandatory attributes. The following table describes the mandatory attributes:
Mandatory Attributes of the groupPolicyContainer Class
Trustee Access
Authenticated Users Read, Apply Group Policy
Domain Admins Read, Write
System Read, Write
Name Description
CN The common name of the GPO. This is in the form of a GUID to avoid GPO naming conflicts within the
Policies container.
instanceType An attribute that dictates how an object is instantiated from its class on a particular server. In this case,
it describes how the groupPolicyContainer class is created into a GPO in the Active Directory. A GPO is
assigned the instanceType value of 4.
Page 8 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...

There are also a number of optional attributes inherited from the top class, and others that are assigned directly to
the Group Policy container. Many optional attributes are required in order for the Group Policy container to function
properly. For example, the GPCFileSysPath optional attribute must be present or the Group Policy container will not
be linked to its corresponding Group Policy template.
GroupPolicyContainer Subcontainers
Within the GroupPolicyContainer there are a series of subcontainers. The first level of subcontainers - User and
Machine - belong to the class Container. These two containers are used to separate some User-specific and
Computer-specific Group Policy components.
Group Policy Container-Related Attributes of Domain, Site, and OU Containers
Windows Server 2003 uses domain, DNS, site, and organizational unit classes to create domain, site, and OU
container objects respectively. These objects contain two optional Group Policy container-related attributes, gPLink
and gPOptions. The gPLink property contains the prioritized list of GPOs and the gPOptions property contains
the Block Policy Inheritance setting.
The gPLink attribute holds a list of all Group Policy containers linked to the container and a number for each listed
Group Policy container, that represents the Enforced (previously known as No Override) and Disabled option
settings. The list appears in priority order from lowest to highest priority GPO.
The gPOptions attribute holds an integer value that indicates whether the Block Policy Inheritance option of a
domain or OU is enabled (0) or disabled (1).
Managing Group Policy Links for a Site, Domain, or OU
To manage GPO links to a site, domain, or OU, you must have read and write access to the gPLink and gPOptions
properties. By default, Domain Admins have this permission for domains and organizational unit, and only
Enterprise Admins and Domain Admins of the forest root domain can manage links to sites. Active Directory
supports security settings on a per-property basis. This means that a non-administrator can be delegated read and
write access to specific properties. In this case, if non-administrators have read and write access to the gPLink and
gPOptions properties, they can manage the list of GPOs linked to that site, domain, or OU.
How WMIPolicy Objects are Stored and Associated with Group Policy Container
Objects
A single WMI filter can be assigned to a Group Policy container. The Group Policy container stores the distinguished
name of the filter in gPCWQLFilter attribute. The Group Policy container locates the assigned filter in the
System/WMIPolicy/SOM container. Each Windows Server 2003 domain stores its WMI filters in this Active Directory
container. Each WMI filter stored in the SOM container lists the rules that define the WMI filter. Each rule is listed
separately. For example, consider a WMI filter containing the following three WQL queries:
Three WMI rules are defined in the details of the filter. Each rule contains a number of attributes, including the
query language (WQL) and the WMI namespace queried by the rule.
objectCategory An object class name, including the object´s path, used to group objects of the instantiated class. For
example, the objectCategory of a GPO in the contoso.com domain is: CN=Group-Policy-
Container,CN=Schema,CN=Configuration,DC=contoso,DC=com.
objectClass The list of classes from which this class is derived. For a GPO, the objectClass is Container,
groupPolicyContainer, and top.
SELECT * FROM Win32_Product WHERE IdentifyingNumber = "{5E076CF2-EFED-43A2-A623-13E0D62EC7E0}"
SELECT * FROM Win32_Product WHERE IdentifyingNumber = "{242365CD-80F2-11D2-989A-00C04F7978A9}"
SELECT * FROM Win32_Product WHERE IdentifyingNumber = "{00000409-78E1-11D2-B60F-006097C998E7}"
Page 9 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Group Policy Template
The majority of Group Policy settings are stored in the file system of the domain controllers. This part of each GPO
is known as the Group Policy template. The GroupPolicyContainer object for each GPO has a property,
GPCFileSysPath, which contains the UNC path to its related Group Policy template.
All Group Policy templates in a domain are stored in the \\\Sysvol\\Policies
folder, where domain_name is the FQDN of the domain. The Group Policy template for the most part stores the
actual data for the policy extensions, for example Security Settings inf file, Administrative Template-based policy
settings .adm and .pol files, applications available for the Group Policy Software installation extension, and
potentially scripts.
The Gpt.ini File
The Gpt.ini file is located at the root of each Group Policy template. Each Gpt.ini file contains GPO version
information. Except for the Gpt.ini files created for the default GPOs, a display name value is also written to the file.
Each Gpt.ini file contains the GPO version number of the Group Policy template.
Normally, this is identical to the version-number property of the corresponding GroupPolicyContainer object. It is
encoded in the same way - as a decimal representation of a 4 byte hexadecimal number, the upper two bytes of
which contain the GPO user settings version and the lower two bytes contain the computer settings version. In this
example the version is equal to 10003 hexadecimal giving a user settings version of 1 and a computer settings
version of 3.
Storing this version number in the Gpt.ini allows the CSEs to check if the client is out of date to the last processing
of policy settings or if the currently applied policy settings (cached policies) are up-to-date. If the cached version is
different from the version in the Group Policy template or Group Policy container, then policy settings will be
reprocessed.
Group Policy Template Subfolders
The Group Policy template folder contains the following subfolders:
Machine. Includes a Registry.pol file that contains the registry settings to be applied to computers. When a
computer initializes, this Registry.pol file is downloaded and applied to the HKEY_LOCAL_MACHINE portion
of the registry. The Machine folder can contain the following subfolders (depending on the contents of the
GPO):
Scripts\Startup. Contains the scripts that are to run when the computer starts up.
Scripts\Shutdown. Contains the scripts that are to run when the computer shuts down.
Applications. Contains the advertisement files (.aas files) used by the Windows installer. These are
applied to computers.
Microsoft\Windows NT\Secedit. Contains the Gpttmpl.inf file, which includes the default security
configuration settings for a Windows Server 2003 domain controller.
Adm. Contains all of the .adm files for the GPO.
User. Includes a Registry.pol file that contains the registry settings to be applied to users. When a user logs
on to a computer, this Registry.pol file is downloaded and applied to the HKEY_CURRENT_USER portion of the
registry. The User folder can contain the following subfolders (depending on the contents of the GPO):
Applications. Contains the advertisement files (.aas files) used by the Windows installer. These are
applied to users.
Documents and Settings. Contains the Fdeploy.ini file, which includes status information about the
Folder Redirection options for the current user´s special folders.
[General]
Version=65539
Page 10 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Microsoft\RemoteInstall. Contains the OSCfilter.ini file, which holds user options for operating system
installation through Remote Installation Services.
Microsoft\IEAK. Contains settings for the Internet Explorer Maintenance snap-in.
Scripts\Logon. Contains all the user logon scripts and related files for this GPO.
Scripts\Logoff. Contains all the user logoff scripts and related files for this GPO.
The User and Machine folders are created at install time, and the other folders are created as needed when policy is
set.
The permissions of each Group Policy template reflect the read and write permissions applied to the
GroupPolicyContainer through the Group Policy Object Editor. These permissions are automatically maintained and
are shown in the following table.
Default Group Policy Template Permissions

Group Policy Object Editor use of Sysvol
Each policy setting changed in a GPO causes at least two files to be rewritten - the GPT.ini and the file holding the
changed setting. Making many changes to a GPO can cause a lot of network traffic as Sysvol replicates these
changes. This congestion should only occur on a local area network where Sysvol replication occurs frequently.
Across wide area network links, the inter-site replication schedule will cause these changes to be amalgamated into
a smaller amount of traffic (for example, four changes to the Registry.pol file will result in only a single file
replication).
The Local Group Policy Object
The Local GPO has no Active Directory component. Information stored in the Group Policy container of an Active
Directory GPO is instead stored in the Group Policy template of a Local GPO. The Group Policy template of a Local
GPO is located in the Windows\system32\GroupPolicy folder. The Gpt.ini file in this GroupPolicy folder must
hold more management information than its counterpart in a domain-based GPO because there is no Active
Directory component to hold this information. The following table shows the attributes for the Group Policy
template.ini file.
Local GPO GPT.INI Attributes
Trustee Access
Authenticated Users Read and Execute
Administrators Full Control
Group Policy Creator Owners Read and Execute
Creator Owner Full Control (Subfolders and Files only)
System Full Control
Attribute Description
gPCUserExtensionNames Includes a list of GUIDs that tells the client-side engine which CSEs have User data in the
GPO.
The format is: [{GUID of CSE}{GUID of MMC extension}{GUID of second MMC extension if
appropriate}][repeat first section as appropriate].
GPCMachineExtensionNames Includes a list of GUIDs that tells the client-side engine which CSEs have computer data in
the GPO.
Options Refers to GPO options such as User portion disabled or Computer portion disabled.
Page 11 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...

The following extensions are disabled in a Local GPO:
Group Policy Software installation extension
Folder Redirection
The following extensions have reduced functionality in a Local GPO:
Public Key policies; EFS only; there are not any options for trust lists or auto enrolment.
Security Settings; there are not any options for Restricted Groups or File System, Registry or Service Access
Control Lists (ACLs).
Application of GPOs to targeted users and computers relies on many interactive processes. This section explains
how GPOs are applied and filtered to Active Directory containers such as sites, domains, and OUs. It includes
information about how the Group Policy engine processes GPOs in conjunction with CSEs. In addition, it explains
how Group Policy is replicated among domain controllers.
Group Policy Processing Rules
GPOs that apply to a user or computer do not all have the same precedence. Settings that are applied later can
override settings that are applied earlier. Group Policy settings are processed in the following order:
Local Group Policy object. Each computer has exactly one Group Policy object that is stored locally. This
processes for both computer and user Group Policy processing.
Site. Any GPOs that have been linked to the site that the computer belongs to are processed next. Processing
is in the order that is specified by the administrator, on the Linked Group Policy Objects tab for the site in
GPMC. The GPO with the lowest link order is processed last, and therefore has the highest precedence.
Domain. Processing of multiple domain-linked GPOs is in the order specified by the administrator, on the
Linked Group Policy Objects tab for the domain in GPMC. The GPO with the lowest link order is processed last,
and therefore has the highest precedence.
Organizational units. GPOs that are linked to the organizational unit that is highest in the Active Directory
hierarchy are processed first, then GPOs that are linked to its child organizational unit are processed, and so
on. Finally, the GPOs that are linked to the organizational unit that contains the user or computer are
processed.
To summarize, the Local GPO is processed first, and the organizational unit to which the computer or user belongs
(the one that it is a direct member of) is processed last. All of this processing is subject to the following conditions:
WMI or security filtering that has been applied to GPOs.
Any domain-based GPO (not Local GPO) can be enforced by using the Enforce option so that its policies
cannot be overwritten. Because an Enforced GPO is processed last, no other settings can write over the
settings in that GPO. If you have more than one Enforced GPO, it´s possible to set the same setting in each
GPO to a different value, in which case, the link order of the GPOs determines which one contains the final
settings.
At any domain or organizational unit, Group Policy inheritance can be selectively designated as Block
Inheritance. However, because enforced GPOs are always applied, and cannot be blocked, blocking
inheritance does not prevent policy from Enforced GPOs from applying.
Every computer has a single Local GPO that is always processed regardless of whether the computer is part of a
domain or is a stand-alone computer. The Local GPO can´t be blocked by domain-based GPOs. However, settings in
domain GPOs always take precedence since they are processed after the Local GPO.
Targeting GPOs
The site, domain, and OU links from a GPO are used as the primary targeting principle for defining which computers
Core Group Policy Processes and Interactions
Back to Top
Page 12 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
and users should receive a GPO. Security filtering and WMI filtering can be used to further reduce the set of
computers and users to which the GPO will apply. The Group Policy engine uses the following logic in processing
GPOs: If a GPO is linked to a domain, site, or OU that applies to the user or computer, the Group Policy engine
must then determine whether the GPO should be added to its GPO list for processing. A GPO is blocked from
processing in the following circumstances:
The GPO is disabled. You disable either or both the computer or user components of a GPO from its Policy
Properties dialog box.
The computer or user does not have permission to read and apply the GPO. You control permission to
a GPO through security filtering, as explained in the following section.
A WMI filter applied to a GPO evaluates to false on the client computer. A WMI filter must evaluate to
true before the Group Policy engine will allow it to be processed, as explained in the following section.
Security Filtering
Security filtering is a way of refining which users and computers will receive and apply the settings in a GPO. By
using security filtering to specify that only certain security principals within a container where the GPO is linked
apply the GPO, you can narrow the scope of a GPO so that it applies only to a single group, user, or computer.
Security filtering determines whether the GPO as a whole applies to groups, users, or computers; it cannot be used
selectively on different settings within a GPO.
In order for the GPO to apply to a given user or computer, that user or computer must have both Read and Apply
Group Policy (AGP) permissions on the GPO, either explicitly, or effectively though group membership.
By default, all GPOs have Read and AGP both Allowed for the Authenticated Users group. The Authenticated Users
group includes both users and computers. This is how all authenticated users receive the settings of a new GPO
when it is applied to an organizational unit, domain or site. Therefore, the default behavior is for every GPO to
apply to every Authenticated User. By default, Domain Admins, Enterprise Admins, and the local system have full
control permissions, without the Apply Group Policy access-control entry (ACE). However, administrators are
members of Authenticated Users, which means that they will receive the settings in the GPO by default.
These permissions can be changed to limit the scope to a specific set of users, groups, or computers within the
organizational unit, domain, or site. The Group Policy Management Console manages these permissions as a single
unit, and displays the security filtering for the GPO on the GPO Scope tab. In GPMC, groups, users, and computers
can be added or removed as security filters for each GPO.
How Security Filtering is Processed
Before processing a GPO, the Group Policy engine checks the Access Control List ACL associated with the GPO. If an
ACE on a GPO denies a security principal to which the computer or user belongs, either the Apply Group Policy or
Read permission, the Group Policy engine does not add the GPO to its list of GPOs to process. Additionally, an ACE
on a GPO must allow the appropriate security principal both Apply Group Policy and Read permissions in order for
the Group Policy engine to add the GPO to the GPO processing list.
If appropriate permissions are granted to the GPO, it is added to the list of GPOs to download.
In general, Deny ACEs should be avoided because you can achieve the same results by granting or not granting
Allow permissions.
WMI Filtering
WMI makes data about a target computer available for administrative use. Such data can include hardware and
software inventory, settings, and configuration information. For example, WMI exposes hardware configuration data
such as CPU, memory, disk space, and manufacturer, as well as software configuration data from the registry,
drivers, file system, Active Directory, the Windows Installer service, networking configuration, and application data.
WMI filtering allows you to filter the application of a GPO by attaching a Windows Query Language query to a GPO.
The queries can be written to query WMI for multiple items. If the query returns true for all queried items, then the
GPO will be applied to the target user or computer.
When a GPO that is linked to a WMI filter is applied on the target computer, the filter is evaluated on the target
Page 13 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
computer. If the WMI filter evaluates to false, the GPO is not applied (except if the client computer is running
Windows 2000, in which case the filter is ignored and the GPO is always applied). If the WMI filter evaluates to true,
the GPO is applied.
The WMI filter is a separate object from the GPO in the directory. A WMI filter must be linked to a GPO in order to
apply. Each GPO can have only one WMI filter; however the same WMI filter can be linked to multiple GPOs. WMI
filters, like GPOs, are stored only in domains. A WMI filter and the GPO it is linked to must be in the same domain.
How WMI Filtering is Processed
If, after security filtering, appropriate permissions are granted to the GPO, it is added to the list of GPOs to
download. Upon download, the Group Policy engine reads the gPCWQLFilter attribute in the Group Policy container
to determine if a WMI filter is applied to the GPO. If so, the WMI filter, which contains one or more WQL
statements, is evaluated. If the statement evaluates to true, then the GPO is processed. There are tradeoffs in
using WMI filters because they can increase the amount of time it takes to process policy especially if the filter to
be evaluated takes a long time to process.
WMI Filtering Scenarios
Sample uses of WMI filters include:
Services. Computers where DHCP is turned on.
Registry. Computers that have this registry key populated.
Hardware inventory. Computers with a Pentium III processor.
Software inventory. Computers with Visual Studio .NET installed.
Hardware configuration. Computers with network interface cards (NICs) on interrupt level 3.
Software configuration. Computers with multi-casting turned on.
Associations. Computers that have any services dependent on Systems Network Architecture (SNA) service.
Client support for WMI filters exists only on Windows XP, Windows Server 2003, and later operating systems.
Windows 2000 clients will ignore any WMI filter and the GPO is always applied, regardless of the WMI filter. WMI
filters are only available in domains that have at least one Windows Server 2003 domain controller.
Application of Group Policy
Application of Group Policy involves a series of processes, beginning with user and computer logon.
Initial Processing of Group Policy
Group Policy for computers is applied at computer startup. For users, Group Policy is applied when they log on. In
Windows 2000, the processing of Group Policy is synchronous, which means that computer Group Policy is
completed before the logon dialog box is presented, and user Group Policy is completed before the shell is active
and available for the user to interact with it. As explained in the following section, Windows XP with Fast Logon-
enabled (which is the default setting) allows users to log on while Group Policy is processed in the background.)
Synchronous and Asynchronous Processing
Synchronous processes can be described as a series of processes where one process must finish running before the
next one begins. Asynchronous processes, on the other hand, can run on different threads simultaneously because
their outcome is independent of other processes.
You can change the default processing behavior by using a policy setting for each GPO so that processing is
asynchronous instead of synchronous. For example, if the policy has been set to remove the Run command from
the Start menu, it is possible under asynchronous processing that a user could logon prior to this policy taking
effect, so the user would initially have access to this functionality.
Fast Logon in Windows XP Professional
By default in Windows XP Professional, the Fast Logon Optimization feature is enabled for both domain and
Page 14 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
workgroup members. This means that policy settings apply asynchronously when the computer starts and when the
user logs on. This process of applying policies is similar to a background refresh process. As a result, users can
logon and begin using the Windows shell faster than they would with synchronous processing. Fast Logon
Optimization is always off during logon under the following conditions:
When a user first logs on to a computer.
When a user has a roaming user profile or a home directory for logon purposes.
When a user has synchronous logon scripts.
Note that under the preceding conditions, computer startup can still be asynchronous. However, because logon is
synchronous under these conditions, logon does not exhibit optimization. The following table compares policy
processing of Windows 2000 and Windows XP client computers.
Default Policy Processing for Client Computers

Windows XP clients support Fast Logon Optimization in any domain environment. Fast Logon Optimization can be
disabled with the following policy setting:
Computer Configuration\Administrative Templates\System\Logon\ Always wait for the network at
computer startup and logon.
Note that Fast Logon Optimization is not a feature of Windows Server 2003.
Folder Redirection and Software Installation Policies
Note that when Fast Logon Optimization is on, a user might need to log on to a computer twice before folder
redirection policies and software installation policies are applied. This occurs because the application of these types
of policies requires the synchronous policy application. During a policy refresh (which is asynchronous), the system
sets a flag indicating that the application of folder redirection or a software installation policy is required. The flag
forces synchronous application of the policy at the user´s next logon.
Time Limit for Processing of Group Policy
Under synchronous processing, there is a time limit of 60 minutes for all of Group Policy to finish processing on the
client computer. Any CSEs that are not finished after 60 minutes are signaled to stop, in which case the associated
policy settings might not be fully applied.
Background Refresh of Group Policy
In addition to the initial processing of Group Policy at startup and logon, Group Policy is applied subsequently in the
background on a periodic basis. During a background refresh, a CSE will only reapply the settings if it detects that a
change was made on the server in any of its GPOs or its list of GPOs.
In addition, software installation and folder redirection processing occurs only during computer startup or user
logon. This is because background processing could cause undesirable results. For example, in software installation,
if an application is no longer assigned, it is removed. If a user is using the application while Group Policy tries to
uninstall it or if an assigned application upgrade takes place while someone is using it, errors would occur. Although
the Scripts CSE is processed during background refresh, the scripts themselves only run at startup, shutdown,
logon, and logoff, as appropriate.
Periodic Refresh Processing
By default, Group Policy is processed every 90 minutes with a randomized delay of up to 30 minutes - for a total
maximum refresh interval of up to 120 minutes.
Client Application at startup/log on Application at refresh
Windows 2000 Synchronous Asynchronous
Windows XP Professional Asynchronous Asynchronous
Page 15 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Group Policy can be configured on a per-extension basis so that a particular extension is always processed during
processing of policy even if the GPOs haven´t changed. Policy settings for each extension are located in Computer
Configuration\Administrative Templates\System\Group Policy.
On-Demand Processing
You can also trigger a background refresh of Group Policy on demand from the client. However, the application of
Group Policy cannot be pushed to clients on demand from the server.
Messages and Events
When Group Policy is applied, a WM_SETTINGCHANGE message is sent, and an event is signaled. Applications
that can receive window messages can use them to respond to a Group Policy change. Those applications that do
not have a window to receive the message (as with most services) can wait for the event.
Refreshing Policy from the Command Line
You can update or refresh Group Policy settings manually through a command line tool. On Windows 2000, you can
use Secedit with the /refreshpolicy option; on Windows XP and Windows Server 2003, you can use Gpupdate.
Group Policy and Slow Links
When Group Policy detects a slow link, it sets a flag to indicate to CSEs that a policy setting is being applied across
a slow link. Individual CSEs can determine whether or not to apply a policy setting over the slow link. The default
settings are as follows:
Default Slow Link Settings

Group Policy Loopback Support
Group Policy is applied to the user or computer, based on where the user or computer object is located in Active
Directory. However, in some cases, users might need policy applied to them, based on the location of the computer
object, not the location of the user object. The Group Policy loopback feature gives you the ability to apply User
Group Policy, based on the computer that the user is logging onto. The following figure shows a sample site,
domain, and OU structure and is followed by a description of the changes that can occur with loopback processing.
Sample Active Directory Structure
Extension Default Setting
Security Settings On (and cannot be turned off)
Administrative Templates On (and cannot be turned off)
Software Installation Off
Scripts Off
Folder Redirection Off
Page 16 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Normal user Group Policy processing specifies that computers located in the Servers organizational unit have the
GPOs A3, A1, A2, A4, and A6 applied (in that order) during computer startup. Users of the Marketing organizational
unit have GPOs A3, A1, A2, and A5 applied (in that order), regardless of which computer they log on to.
In some cases this processing order might not be what you want. An example is when you do not want applications
that have been assigned or published to the users of the Marketing organizational unit to be installed while they are
logged on to the computers in the Servers organizational unit. With the Group Policy loopback feature, you can
specify two other ways to retrieve the list of GPOs for any user of the computers in the Servers organizational unit:
Merge mode. In this mode, the computer´s GPOs have higher precedence than the user´s GPOs. In this
example, the list of GPOs for the computer is A3, A1, A2, A4, and A6, which is added to the user´s list of A3,
A1, A2, A5, resulting in A3, A1, A2, A5, A3, A1, A2, A4, and 9A6 (listed in lowest to highest priority).
Replace mode. In this mode, the user´s list of GPOs is not gathered. Only the list of GPOs based upon the
computer object is used. In this example, the list is A3, A1, A2, A4, and A6.
The loopback feature can be enabled by using the User Group Policy loopback processing mode policy under
Computer Settings\Administrative settings\System\Group Policy.
The processing of the loopback feature is implemented in the Group Policy engine. When the Group Policy engine is
about to apply user policy, it looks in the registry for a computer policy, which specifies which mode user policy
should be applied in.
How the Group Policy Engine Processes Client-Side Extensions
Client-side extensions are the components running on the client system that process and apply the Group Policy
settings to that system. There are a number of extensions that are pre-installed in Windows Server 2003. Other
Microsoft applications and third party application vendors can also write and install additional extensions to
implement Group Policy management of these applications.
The default Windows Server 2003 CSEs are listed in the following table:
Default Windows Server 2003 CSEs
Client-Side Extension Active Directory Component Sysvol Component
Software Installation PackageRegistration objects .aas files
Security Settings Gptmpl.inf
Folder Redirection fdeploy.ini
Scripts Scripts.ini
Page 17 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...

Client-Side Extension Operation
CSEs are called by the Winlogon process at computer startup, user logon and at the Group Policy refresh interval.
CSEs are registered with Winlogon in the registry. This registration information includes a DLL and a DLL entry point
(function call) by which the CSE processing can be initiated. The Winlogon process uses these to trigger Group
Policy processing.
Each extension can opt not to perform processing at any of these points (for example, avoid processing during
background refresh).
Client-Side Extensions Registered with WinLogon
Each of the CSEs is registered under the following key:
HKEY_LOCAL_MACHINE\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon\GPExtensions
Each extension is identified by a key named after the GUID of the extension. These extensions are shown in the
following table.
CSE Extensions

How Group Policy Processing History Is Maintained on the Client Computer
Each time GPOs are processed, a record of all of the GPOs applied to the user or computer is written to the registry.
IP Security IPSec Policy objects
Internet Explorer Maintenance .ins + branding .inf files.
Administrative Templates Registry.pol and .adm files
Disk Quota Registry.pol
EFS Recovery Registry.pol
Remote Installation Oscfilter.ini
Wireless Network Policies Registry.pol and .adm files
QoS Packet Scheduler Registry.pol and .adm files
Extension GUID Extension Name
25537BA6-77A8-11D2-9B6C-0000F8080861 Folder Redirection
35378EAC-683F-11D2-A89A-00C04FBBCFA2 Administrative Templates Extension
3610EDA5-77EF-11D2-8DC5-00C04FA31A66 Disk Quotas
426031c0-0b47-4852-b0ca-ac3d37bfcb39 QoS Packet Scheduler
42B5FAAE-6536-11D2-AE5A-0000F87571E3 Scripts
827D319E-6EAC-11D2-A4EA-00C04F79F83A Security
A2E30F80-D7DE-11d2-BBDE-00C04F86AE3B Internet Explorer Maintenance
B1BE8D72-6EAC-11D2-A4EA-00C04F79F83A EFS Recovery
C6DC5466-785A-11D2-84D0-00C04FB169F7 Software Installation
E437BC1C-AA7D-11D2-A382-00C04F991E27 IP Security
Page 18 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
GPOs applied to the local computer are stored in the following registry path:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
GPOs applied to the currently logged on user are stored in the following registry path:
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Group Policy\History
Preferences and Policy Configuration
Manipulating these registry values directly is not recommended. Most of the items in which you might need to
change the behavior of an extension (such as forcing a CSE to run over a slow link), are available as Group Policy
settings. These can be found in the Group Policy Object Editor in the following location:
Computer Settings\Administrative Templates\System\Group Policy
The behavior can be changed for the following CSEs:
Administrative Templates (Registry-based policy)
Internet Explorer Maintenance
Software Installation
Folder Redirection
Scripts
Security
IP Security
EFS recovery
Disk Quotas
Order of Extension Processing
Administrative Templates policy settings are always processed first. Other extensions are processed in an
indeterminate order.
Policy Application Processes
There are two primary milestones that the Group Policy engine uses for GPO processing:
Creating the list of GPOs targeted at the user or computer.
Invoking the relevant CSEs to process the policy settings relevant to them within the GPO list.
The following figure shows the steps required to reach the first milestone in GPO processing, GPO list creation.
GPO List Creation
Page 19 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Creating the GPO list involves the following steps:
1. Query the Active Directory for the gPLink and gPOptions properties in the Site and Domain hierarchies to
which the user or computer object belongs.
2. Query the Active Directory for the GroupPolicyContainer objects referenced in the gPLink properties.
3. Evaluate security filtering to determine if the user or computer have the Apply Group Policy access
permission to the GPO.
4. Evaluate the WMI query against the WMI repository on the client computer to determine if the computer
meets the query requirements.
Once the GPO list is created, the Group Policy engine and the CSEs work together to process Group Policy template
components. The following figure shows the steps required to determine which CSEs to call.
Determining CSEs to Call
Page 20 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
Determining which CSEs to call involves the following steps:
1. Retrieve the list of CSEs registered with Winlogon.
2. Check to see whether it is appropriate to run a particular CSE (for example, whether background processing
or slow link processing is enabled for the extension).
3. Check the CSE history against list of Applied GPOs. GPOs with new version numbers and GPOs that have
settings relevant to the CSE (that is, they have the CSE extension GUID in the Group Policy container
gpcUserExtension or gpcMachineExtension properties) are added to the Changed GPO List. GPOs no longer
in the Applied GPO List are added to the Deleted GPO List.
4. Check to see whether the appropriate CSE should be processing policy settings for the user or the
computer.
5. Check the version number listed in the GPO against its recorded version history in the registry to determine
whether the GPO needs reprocessing.
If all of the version numbers are unchanged the MaxNoGPOListChanges interval might have expired; if so, the CSE
processes policy settings without regard to an unchanged version number.
Steps 3 through 5 are repeated by each CSE for all GPOs in the GPO list. After one CSE is done, the next CSE that
needs to run repeats the entire process.
Group Policy updates are dynamic and occur at specific intervals. If there have been no changes to Group Policy,
the client computer still refreshes the security policy settings at regular intervals for the GPO.
If no changes are discovered, GPOs are not processed. Security policies have a periodic force apply every 16 hours.
Page 21 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...
For security policies, there is a value that sets a maximum limit of how long a client can function without reapplying
non-changed GPOs. By default, this setting is every 16 hours plus a randomized delay of up to 30 minutes. Even
when GPOs that contain security policy settings do not change, the policy is reapplied every 16 hours
Group Policy Replication
In a domain that contains more than one domain controller, Group Policy information takes time to propagate, or
replicate, from one domain controller to another. Low bandwidth network connections between domain controllers
slow replication. The Group Policy infrastructure has mechanisms to manage these issues.
Each GPO is stored partly in the Sysvol on the domain controller and partly in Active Directory. GPMC and Group
Policy Object Editor present and manage the GPO as a single unit. For example, when you set permissions on a GPO
in GPMC, GPMC is actually setting permissions on objects in both Active Directory and the Sysvol. It is not
recommended that you manipulate these separate objects independently outside of GPMC and the Group Policy
Object Editor. As shown in the following figure, it is important to understand that these two separate components of
a GPO rely on different replication mechanisms. The file system portion is replicated through FRS, independently of
the replication handled by Active Directory. Only the Sysvol subfolder (%systemroot%\SYSVOL\sysvol) is shared
and replicated. Sysvol was designed to allow multiple domain´s Sysvols to be replicated in the same tree - each
domain´s Sysvol is contained under a subfolder of the Sysvol share. For the current domain, a copy of the domain´s
Sysvol subtree is also stored directly under the %systemroot%\SYSVOL\domain folder.
Group Policy Replication
FRS is a multi-master replication service that synchronizes folders between two or more Windows Server 2003 or
Windows 2000 systems. Modified files are queued for replication at the point the file is closed. In the case of
conflicting modifications between two copies of an FRS replica, the file with the latest modification time will
overwrite any other copies. This is referred to as a "last-writer-wins" model.
FRS replication topology configuration is stored as a combination of child objects of each FRS replica partner (in the
FRS Subscriptions subcontainer) and objects within another hidden subcontainer of the domain System container.
Replication links between systems are maintained as FRS subscription objects. These objects specify the replica
partner and the replication schedule. It is possible to view the schedule by browsing to an FRS subscription object
and viewing the properties. The replica partner is stored as the object GUID of the computer account of that
partner.
The Sysvol folder is a special case of FRS replication. Active Directory automatically maintains the subscription
objects and their schedules as the directory replication is built and maintained. It is possible, but not recommended,
to modify the properties (for example, the schedule) of the Sysvol subscription objects manually.
The FRS replication schedule only approximates to the directory replication schedule so it is possible for the
Page 22 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...

directory-based Group Policy information and the file-based information to get temporarily out of synch. Since GPO
version information is stored in both the Group Policy container object and in the Group Policy template, any
discrepancy can be viewed with tools such as Gpotool.exe and Repladmin.exe.
For those Group Policy extensions that store data in only one data store (either Active Directory or Sysvol), this is
not an issue, and Group Policy is applied as it can be read. Such extensions include Administrative Templates,
Scripts, Folder Redirection, and most of the Security Settings.
For any Group Policy extension that stores data in both storage places (Active Directory and Sysvol), the extension
must properly handle the possibility that the data is unsynchronized. This is also true for extensions that need
multiple objects in a single store to be atomic in nature, since neither storage location handles transactions.
An example of an extension that stores data in Active Directory and Sysvol is Group Policy Software installation
extension. The .aas files are stored on Sysvol and the Windows Installer package definition is in Active Directory. If
the .aas file exists, but the corresponding Active Directory components are not present, the software is not
installed. If the .aas file is missing, but the package is known in Active Directory, application installation fails
gracefully and will be retried on the next processing of Group Policy.
The tools used to manage Active Directory and Group Policy, such as GPMC, the Group Policy Object Editor, and
Active Directory Users and Computers all communicate with domain controllers. If there are several domain
controllers available, changes made to objects like users, computers, organizational units, and GPOs might take
time to appear on other domain controllers. The administrator might see different data depending on the last
domain controller on which changes were made and which domain controller they are currently viewing the data
from.
If multiple administrators manage a common GPO, it is recommended that all administrators use the same domain
controller when editing a particular GPO, to avoid collisions in FRS. Domain Admins can use a policy to specify how
Group Policy chooses a domain controller - that is, they can specify which domain controller option should be used.
The Group Policy domain controller selection policy setting is available in the Administrative Templates node for
User Configuration, in the System\Group Policy subcontainer.
Port Assignments for Group Policy

The following resources contain additional information that is relevant to this section.
Group Policy Settings Reference for Windows Server
Group Policy Administrative Tools
Network Ports Used by Group Policy
Back to Top
Service Name UDP TCP
Lightweight Directory Access Protocol n/a 389
SMB n/a 445
DCOM Dynamicallly assigned Dynamically assigned
RPC Dynamically assigned Dynamically assigned
Related Information
Back to Top
Nanage Your Profile ] Legal ] Contact Us
© 2005 Nicrosoft Corporation. All rights reserved. Terms of Use ] Trademarks ] Privacy Statement
Page 23 of 23 How Core Group Policy Works - Management Services: Windows Server 2003
22/03/2005 http://www.microsoft.com/Resources/Documentation/windowsserv/2003/all/techref/en-us...