Architecture of Windows Group Policy for Windows Server 2008 and Windows Vista

GPO Replication

You just saw that a single GPO is not a single entity. A GPO has two major parts: the GPT and the GPC. Earlier in this chapter, we briefly discussed how Group Policy relied on replication services to move GPO settings from one domain controller to another. These replication services are essential for the success and efficiency of Group Policy application. Because Group Policy models the concept of a multi-master environment, changes to a GPO are made on only one domain controller. The replication services are responsible for making sure that the changes to the GPO get to all domain controllers.

The two parts of the GPO could not be more different, nor could the replication services that synchronize the parts on domain controllers. Understanding how the replication services are dissimilar can make you a troubleshooting expert. In many cases, failed Group Policy processing is the result of failed or errant replication of either the GPC or the GPT.

Group Policy Template and SYSVOL Replication

SYSVOL replication in Windows 2000 and Windows Server 2003 was driven by the File Replication Service (FRS). FRS was a stable and reliable service, but it had some issues for large organizations. FRS was difficult to troubleshoot, and when broken, it was hard to get running again.

With Windows Server 2008, a new replication service ensures that SYSVOL is synchronized among all domain controllers. The new service is the Distributed File System Replication (DFSR). DFSR was introduced with Windows Server 2003 R2, but this version did not support replication of SYSVOL. The current version of DFSR in Windows Server 2008 supports replication of SYSVOL for Windows Server 2008 domain controllers, but it does not support Windows Server 2003 and earlier. The only way to use DFSR to replicate the SYSVOL is to raise your Windows Server 2008 domain to the Windows Server 2008 domain functional level. The service is installed and started by default, but the upgrade to the domain functional level will trigger it to control replication.

How It Works: Enabling DFSR for Your Active Directory Domain

Enabling DFSR will benefit your entire Active Directory infrastructure because it is much more efficient than the old FRS replication. The first step is to ensure that all of your domain controllers are running Windows Server 2008. This is a requirement for replicating the SYSVOL using DFSR, because only domain controllers running Windows Server 2008 support this form of replication of the SYSVOL. The second step is to raise the domain level to Windows Server 2008 functional level. The process is very similar to the process for raising the level of the domain in Windows 2000 and Windows Server 2003. Open the Active Directory User and Computers interface and do the following:

1. In the console tree pane, locate the domain name.

2. Right-click the domain name, and then click Raise Domain Functional Level, as shown in Figure 4-10.

   

   Figure 4-10 The Active Directory Users and Computers interface allows you to configure the domain functional level, including Windows Server 2008.

3. In the Domain Functional Level dialog box, select Windows Server 2008.

4. To Convert your SYSVOL from FRS to DFSR, you must run the dfsrmig command on all domain controllers to properly convert the SYSVOL to DFSR. After you do this, you will not have the option to convert back to FRS.

Warning

After you upgrade to a new functional level, you cannot revert back to the original level. For more information about functional levels in Windows Server 2008 Active Directory, refer to the article titled “Appendix of Functional Level Features” at http://technet2.microsoft.com/windowsserver2008/en/library/34678199-98f1-465f-9156-c600f723b31f1033.mspx?mfr=true.

DFSR provides additional benefits over its predecessor, FRS, such as the following:

• Bandwidth throttling and replication scheduling

• Support for replication groups

• Replication of GPO differences only

• File and subfolder filtering

Note that DFSR and FRS follow state-based replication schedules. This means that as soon as a change occurs in the SYSVOL, SYSVOL will replicate the changes to the replication partners. This state-based replication does not adhere to any Active Directory site topology, so the convergence of the changes is rather fast compared to schedule-based replication technologies.

NOTE

DFSR does provide for scheduling and manipulating of the service, but it is a best practice to leave the replication of SYSVOL at the default values.

Active Directory Replication

Active Directory replication is controlled by...Active Directory replication. The underlying services that control Active Directory replication include the Knowledge Consistency Checker (KCC) and the Inter-Site Topology Generator (ISTG) services. The KCC is in charge of all Active Directory replication, whereas the ISTG is responsible only for replication of Active Directory between domain controllers in different sites.

Because the GPC is stored in Active Directory, it is important to understand how this replication differs from DFSR replication. First, Active Directory replication is not state based. There is a schedule associated with the replication of Active Directory, which is set in the Active Directory Sites and Services tool, as shown in Figure 4-11.

Note that the replication value available for configuration shown in Figure 4-11 is only for replication between sites. The replication of Active Directory between domain controllers in the same site is not available for configuration. This replication, intra-site replication, is set to 15 seconds by default. The maximum time that a change to Active Directory should take to converge to all domain controllers in the same site is 45 seconds, which is a three-hop maximum between replication partners.

Figure 4-11 Site links have a schedule for Active Directory replication between sites, which is configured in Active Directory Sites and Services.

In Figure 4-11, you can see that a much longer convergence time could occur with domain controllers between sites. The default value is 180 minutes, with simple conversion to three hours. This is only the replication of the domain controllers chosen to replicated between sites (bridgehead servers), not the replication within the site between domain controllers. If multiple site hops must be completed, the convergence time could be substantially higher.

NOTE

It has become a best practice for most companies to set the intra-site replication schedule to 15 minutes. This is because most site links are a high-bandwidth scenario. If your bandwidth is significantly less than 10 Mbps, you should consider keeping the replication schedule interval between 60 and 180 minutes.

As you can clearly see, Active Directory replication can lag behind DFSR replication substantially. This has caused dramatic effects in the past, but since the release of Windows XP, this lag in convergence of the two replication technologies has been almost eliminated because Group Policy processing now checks for version numbers in a different way. For more information about Group Policy processing with regard to the version numbers of the GPT and GPC, refer to Chapter 5, “Group Policy Processing.” For more information on troubleshooting replication issues with Group Policy, refer to Chapter 15, “Troubleshooting GPOs.”