Understanding Group Policy Replication

Group Policy replication is controlled by two different replication mechanisms: FRS and Active Directory replication. We will take a look at both mthods within this article.

As Group Policy becomes more important for managing desktops and servers in Active Directory, it makes sense that the details around Group Policy need to be understood more completely. There are many moving parts to Group Policy, including client side extensions, ADM/ADMX files, GPC, GPT, and much more. When a change occurs to a Group Policy object (GPO), that change only occurs on one domain controller. Thus, the change to the GPO must be replicated to all of the other domain controllers. This replication affects multiple replication mechanisms and can cause odd effects if not completed properly. This article will discuss the replication of Group Policy and what you can do to verify that all replication has occurred.

Triggering Replication

Replication is triggered when a setting in a GPO is changed. This can be any of the settings in the GPO and with over 5000 in Windows Server 2008, there are plenty of opportunities to make changes now. A change can occur on either the Computer Configuration side or User Configuration side of the GPO. Either one will trigger replication to occur.

The system tracks this triggering by both the Computer and User changes for the GPO. If you look at the details of a GPO in the Group Policy Management Console (GPMC), you will see that there is a listing of both Computer and User version, as seen in Figure 1.

Figure 1: Details of a GPO in the GPMC show the version of both Computer and User portions of a GPO.

When a change occurs to either portion of the GPO, the version number for that portion is updated, as can be seen in Figure 2.


Figure 2: Changes to settings in a GPO increment the version number.

When a GPO is edited in the Group Policy Management Editor (GPME), the domain controller running the PDC Emulator role is used by default. Therefore, all replication will stem from this domain controller. If a different domain controller is selected, as can be done from the GPMC (see Figure 3), the replication will stem from that domain controller.

Replication of the Group Policy Template

The portion of the GPO that stores the settings into one or more files is the Group Policy Template (GPT). This portion of the GPO and the related files are stored on domain controllers under the Sysvol. The default path for these files isc:\Windows\Sysvol\Sysvol\<domainname>\Policies, as shown in Figure 3.

Figure 3: All GPOs store settings in files under the Sysvol on domain controllers.

The Sysvol on domain controllers is used to deliver Group Policy settings and logon scripts to clients at logon. Since Sysvol is used for authentication of users and computers, it must be up to date on all domain controllers. When any information is changed under the Sysvol on one domain controller, it triggers replication of the Sysvol to all other domain controllers.

The Sysvol is replicated using the File Replication System (FRS). FRS does not have a schedule associated with it. FRS uses state-based replication instead. This means that as soon as there is a change to any file under the Sysvol folder structure, replication is triggered. This creates a very efficient and fast replication model for the GPT.

As a side note, FRS replication does not adhere to any site boundaries. Thus, replication will converge to all of the domain controllers within only a few minutes, even to those domain controllers in remote locations.

Note: Windows Server 2008 can use FRS or DFS-R to replicate the contents of the Sysvol.

Replication of the Group Policy Container

The Group Policy Container (GPC) potion of the GPO is stored in Active Directory. I refer to the GPC as the glue of the GPO. There are no settings stored in the GPC, rather all of the settings that you make in a GPO are stored in the GPT. The GPC contains all of the referential information for the GPO. This includes the path to the GPT, including the GUID of the GPO, as well as all of the Active Directory path information for the GPC.

You can view the GPC and its properties by accessing the Active Directory Users and Computers (ADUC). When you open up the ADUC, you will most likely need to make a quick configuration change to see the GPC data. To do this, click on the View from the toolbar, then select the Advanced Features menu option, as seen in Figure 4. This will display many different details in the ADUC.

Figure 4: The Advanced Features option will display the GPC in the ADUC.

Now that you have configured the ADUC to show the GPC, expand the following nodes to see them: <domainname>\System\Policies, as shown in Figure 5.

Figure 5: The list of GPCs can be seen under the System\Policies node.

Here you will see the full list of GUIDs that correspond to the GPCs of each GPO in the domain.

The replication of the GPC is also triggered by a change to any setting in a GPO, just like the GPT. However, the replication of the GPC is not state-based and not based on FRS. Instead, like all other Active Directory objects, all of the GPCs are driven by Active Directory replication.

Active Directory replication has two different replication schedules by default. There is the replication between domain controllers that are in the same site and replication between domain controllers in different sites.

The first replication schedule occurs every 15 seconds for domain controllers in the same site. This interval should not be changed and is controlled by the Knowledge Consistency Checker (KCC).

The second replication schedule occurs every 3 hours be default and is controlled by the Intersite Topology Generator (ISTG). This interval change, and in most instances, should be reduced to accommodate a schedule that will optimize changes to domain controllers. To change this interval, you will need to modify the site link and configure the schedule. This is done in the Active Directory Sites and Services tool, As shown in Figure 6.

Figure 6: Intersite replication can be managed and reduced from the default 3 hours.

Verifying GPO Replication

The easiest tool to use to verify that both the GPC and GPT have replicated is GPOTool. This tool is free and very easy to use. It comes with the operating system and can be run from a command prompt. Just type gpotool <dcname> /verbose from the command prompt, like you see in Figure 7.

Figure 7: GPOTool provides information on the convergence of both parts of the GPO.

The results of running this command will display the GPT and GPC version numbers for each GPO on the listed domain controller.

If a portion of the GPO has not replicated to the domain controller that you are authenticating to, there is a chance that the new settings in the GPO will not apply. Thus, if you know a GPO has been changed, yet the settings are not being delivered, it is a good idea to verify that the GPO has replicated to the domain controller that you are authenticating too.

Summary

Group Policy replication is controlled by two different replication mechanisms: FRS and Active Directory replication. In order for the GPO content to be up to date on all domain controllers, replication must converge for both parts of the GPO, GPT and GPC, in order for Group Policy to function properly. By using a tool like GPOTool, you can verify that all GPO data has replicated to each domain controller.