GPO replication: Understanding the ins and outs

Replication services for Group Policy Objects are key to the stability of a GPO. Expert Derek Melber breaks down the process for GPO replication, and explains how to ensure a more stable environment.

GPO Replication

Group Policy can seem like a black box. Designing the settings in a Group Policy is just the first step. After you create a new GPO, link it to an Active Directory node, and configure your settings within the GPO, you probably expect it to just work. Well, if your enterprise is very, very small, you might get lucky enough for it to work like this. However, if your enterprise has any girth, you need to consider the after-effects that must occur to a GPO post-creation and configuration.

These after-effects include the replication of both parts of the GPO, which are the Group Policy Template (GPT) and Group Policy Container (GPC). Understanding the replication specifics of GPOs will help you implement, troubleshoot, and make your Group Policy infrastructure more efficient.

Replication of the GPT

The GPT portion of the GPO is stored in the SYSVOL folder structure of your domain controllers. Like all content of the SYSVOL, the GPT must be replicated to all domain controllers. The GPT must be on the domain controllers to service computers and users when they authenticate . The replication service that controls this content is the File Replication Service (FRS), which has gone through a recent makeover and is now partnered with DFS Replication. FRS replication will still control the replication of SYSVOL, where DFS Replication will handle DFS links and members.

If we track a newly created GPO and how the GPT is replicated to all domain controllers, it will help clarify how the replication works. Assume you have the three domain controllers and sites as shown in Figure 1.

Figure 1. Domain Controllers and Active Directory Sites

If you create a new GPO on Domain Controller 1, the content of the SYSVOL will be changed, therefore causing an alert to the FRS Replication service telling you that other domain controllers need to be updated. The default replication schedule in Windows Server 2003 FRS Replication is an immediate replication between partners based on the state of the SYSVOL. The FRS replication schedule should not be altered, ensuring that you have the most efficient replication of the contents of the SYSVOL to all domain controllers.

Replication of the GPC

The GPC does not reside in the SYSVOL; it takes residence in the Active Directory database. Therefore, it only makes sense that the GPC is an Active Directory object. Like the SYSVOL, it is imperative that the objects in Active Directory replicate to all domain controllers in the domain. Unlike the GPT, the GPC replication is controlled by Active Directory Replication, which is serviced by the Knowledge Consistency Checker (KCC). The KCC's primary role is to control replication between domain controllers in the same Active Directory site. By default this replication occurs every 5 minutes (and every 15 seconds for Windows Server 2003 domain controllers). With a three hop maximum, all updates to a GPO should arrive on all domain controllers within 15 minutes for those domain controllers in the same site. This replication should not be altered, as it could cause instability or failed replication between domain controllers.

For replication between domain controllers in different sites, the KCC has a side-kick called the Intersite Topology Generator (ISTG). The ISTG is primarily responsible for establishing and keeping the replication schedule between the domain controllers in the different sites. By default, the replication schedule is set to every three hours.

As a best practice, you will want to reduce this replication schedule to as low as possible, without causing too much overhead on your connections. Therefore, where you have well connected links, you will want to throttle the replication down to 15 minutes for each link. This will ensure that the GPT is getting replicated to all domain controllers as fast as possible. Where your links are not reliable or low bandwidth pipes, you will want to increase your replication schedule. Since you can create a replication schedule per link, this is easy to accomplish. A range of 60 to 180 minutes should be investigated and tested.


The two replication services that control each portion of the GPO are key to the overall convergence and stability of the GPO. Knowing that the replication of the GPT stored in the SYSVOL can't be altered is key, especially if you are having trouble with the synchronization of the GPT and GPC. The replication of the GPC has two factors, intrasite and intersite replication. The intrasite replication can't be altered, but the intersite replication can. Lower the replication schedule of the intersite connections can ensure that the GPO is synchronized faster and the environment is more stable.

Derek Melber, MCSE, MVP and CISM, is the director of compliance solutions for DesktopStandard Corp. He has written the only books on auditing Windows security available at The Institute of Internal Auditors' bookstore, and he also wrote the Group Policy Guide for Microsoft Press -- the only book Microsoft has written on Group Policy. You can contact Melber at

This was last published in August 2006

Dig Deeper on Microsoft Group Policy Management



Find more PRO+ content and other member only offers, here.



Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to: