Understanding Active Directory Replication

Windows Server 2003 improvements in Active Directory replication are directly drawn from lessons learned in Windows 2000. Replication compression can now be disabled in well-connected sites, enabling designers to sacrifice bandwidth for processor utilization in domain controllers (DCs). In addition, novel concepts such as DC Promotion from Media allow global catalog servers to be created from CDs or other media, which greatly increases DC placement flexibility. Improvements such as universal group caching on domain controllers allow remote domain controllers to function as global catalog servers by caching frequently used universal group membership locally. New functionality, such as support for IPv6, has also been added to further improve the operating system.

The redesign of the replication structure in Windows Server 2003 fixes design limitations that have thwarted replication plans in the past. Problems with replication design can potentially cripple a network, and it is therefore wise to put some serious thought into the proper layout and design of an effective replication scheme.

This chapter focuses on the definition of the components of Windows Server 2003's Active Directory that make up its replication topology. It details design strategies for Active Directory sites and provides real-world examples to illustrate the principles behind them. In addition, new components related to AD infrastructure such as support for IPv6 (Internet Protocol version 6) are outlined and described.

Understanding the Role of Replication in Active Directory

All enterprise directory environments must include mechanisms to synchronize and update directory information across the entire directory structure. In Windows Server 2003's Active Directory, this means that every domain controller must be updated with the most recent information so that users can log in, access resources, and interact with the directory accurately.

Active Directory differs from many directory services implementations in that the replication of directory information is accomplished independently from the actual logical directory design. The concept of Active Directory sites is completely independent from the logical structure of Active Directory forests, trees, and domains. In fact, a single site in Active Directory can actually host domain controllers from different domains or different trees within the same forest. This allows for the creation of a replication topology based on a WAN structure, while the directory topology can mirror the organization's structure.

Multimaster Topology Concepts

Active Directory was specifically written to allow for the creation, modification, and deletion of directory information from multiple domain controllers. This concept, known as multimaster replication, allows no one domain controller to be authoritative. If any domain controllers go out of service, any one of the rest of the domain controllers can make changes to directory information. Those changes are then replicated across the domain infrastructure. Of course, there needs to be some level of control on this type of replication so that only the most recent changes take precedence. This type of control is realized in Active Directory through the concept of Update Sequence Numbers (USNs).

Update Sequence Numbers

All enterprise directory services implementations require a mechanism to handle the incremental storage of changes made to directory objects. In other words, whenever a password is changed, that information must be accurately passed to all domain controllers in the domain. This mechanism must also be able to apply only those changes that occurred at the most recent intervals.

Many directory services implementations relied on exact time synchronization on all domain controllers to synchronize information. However, keeping the clocks of multiple servers in sync has been proven to be extremely difficult, and even slight variations in time could affect replication results.

Thus was born the concept of the Update Sequence Number. Active Directory utilizes USNs to provide for accurate application of directory changes. A USN is a 64-bit number that is maintained by each domain controller in Active Directory. The USN is sequentially advanced upon each change that is made to the directory on that specific server. Each additional domain controller also contains a copy of the last-known USN from its peers. Updates are subsequently made to be more straightforward. For example, when requesting a replication update from Server2, Server1 will reference its internal table for the most recent USN that it received from Server2 and request only those changes that were made since that specific number. The simplicity of this design also ensures accuracy of replication across the domain environment.

The integrity of replication is assured with USNs because the USN number is updated only upon confirmation that the change has been written to the specific domain controller. This way, if a server failure interrupts the replication cycle, the server in question will still seek an update based on its USN number, ensuring the integrity of the transaction.

Replication Collisions

The concept of USNs does not completely eliminate the role of proper time synchronization in Active Directory. It is still important to maintain accurate time across a domain environment because of the possibility of replication collisions. A replication collision is an inaccuracy in replicated information that takes place because of changes that are enacted on the same object, but before that change has been replicated to all domain controllers. For example, if an administrator resets a user's password on Server1, and another administrator resets the same user's password on Server2 before Server1 has had a chance to replicate that change, a replication collision will occur. Replication collisions are resolved through the use of property version numbers.

Property Version Numbers

Property version numbers are applied as an attribute to all objects within Active Directory. These numbers are sequentially updated and time-stamped whenever a change is made to that object. If a replication collision occurs, the property version number with the latest time stamp will be enacted, and the older change will be discarded. In the example from the preceding section, the password change with the latest time stamp will be applied to the user.

This concept subsequently requires accurate time synchronization to be a priority for an Active Directory domainalthough it is not as critical as in other directory services implementations that rely on it for all replication activity.

Note

Windows Server 2003 includes a built-in service to synchronize time within a domain. Using the Windows Time Service is recommended to keep DCs synchronized so that they can accurately resolve replication collisions.

Connection Objects

Connection objects are automatically generated by the Active Directory Knowledge Consistency Checker (KCC) to act as pathways for replication communication. They can be manually established, as well, and essentially provide a replication path between one domain controller and another. If, for example, an organization wants to have all replication pushed to a primary domain controller (PDC) before it is disseminated elsewhere, direct connection objects can be established between the two domain controllers.

Creating a connection object is a straightforward process. After one is created, Windows Server 2003 will not attempt to automatically generate a new one across the same route unless that connection object is deleted. To manually set a connection object to replicate between domain controllers, perform the following steps:

1.	Open Active Directory Sites and Services.
2.	Expand Sites\<Sitename>\Servers\<Servername>\NTDS Settings, where Servername is the source server for the connection object.
3.	Right-click NTDS Settings and choose New Active Directory Connection.
4.	Select the target domain controller and click OK.
5.	Name the connection object and click OK.
6.	Right-click the newly created connection object and select Properties to open a properties page similar to Figure 7.1. You can then modify the connection object to fit any specific schedule, transport, and so on. Figure 7.1. Connection object properties.

Note

The connection objects that appear as automatically generated were created by the KCC component of Active Directory to provide for the most efficient replication pathways. You must therefore have a good reason to manually create these pathways because the automatically generated ones usually do the trick.

Replication Latency

Administrators who are not accustomed to Active Directory's replication topology may become confused when they make a change in AD and find that the change is not replicated immediately across their environment. For example, an administrator may reset a password on a user's account, only to have that user complain that the new password does not immediately work. The reason for these types of discrepancies simply lies in the fact that not all AD changes are replicated immediately. This concept is known as replication latency. Because the overhead required in replicating change information to all domain controllers immediately is large, the default schedule for replication is not as often as may be desired. Replication of critical information can be forced through the following procedure:

1.	Open Active Directory Sites and Services.
2.	Drill down to Sites\<Sitename>\Servers\<Servername>\ NTDS Settings, where Servername is the server that you are connected to and that the desired change should be replicated from.
3.	Right-click each connection object and choose Replicate Now, as shown in Figure 7.2. Figure 7.2. Forcing replication via connection objects.

Another useful tool that can be used to force replication is the repadmin command-line tool. This tool is installed as part of the Windows Server 2003 Support Tools on the server media. Once installed, repadmin can be used to force replication for the entire directory, specific portions of the directory, or to sync domain controllers across site boundaries. If the bandwidth is available, a batch file can be effectively written to force replication between domain controllers, effectively making the directory quiescent. Figure 7.3 illustrates an example of a simple batch file that forces the replication of all Active Directory naming contexts between two domain controllers.

Figure 7.3. A sample batch file that forces replication using repadmin.

In addition to the repadmin utility, the Support Tools install the replmon utility, which allows for a graphic display of replication attempts and history for domain controllers. This utility can be useful for giving advance notice of replication problems before they become major issues. Figure 7.4 illustrates how this utility can display replication information between domain controllers in Active Directory.

Figure 7.4. Monitoring domain controller replication with replmon.

The default replication schedule can be modified to fit the needs of your organization. For example, you might have very high bandwidth between all your domain controllers in a site and decide to change the default schedule to as low as fifteen minutes. To make this change, perform the following steps:

1.	Open Active Directory Sites and Services.
2.	Drill down to Sites\<Sitename>.
3.	Right-click NTDS Site Settings and choose Properties.
4.	Click Change Schedule.
5.	Set the Schedule to Four Times Per Hour, as shown in Figure 7.5. Figure 7.5. Setting the default site replication schedule.
6.	Click OK to save any schedule changes and then OK again to close the NTDS Site Settings Properties page.

Of course, changing this schedule comes with some caveats, namely watching for increased network bandwidth consumption. You should match the trade-off of your organization's needs with the increased resource consumption levels required.

SMTP Versus IP Replication

Active Directory in Windows Server 2003 allows for the dissemination of replication traffic in the form of either IP (RPC) or SMTP packets. This functionality allows for the flexibility to choose SMTP traffic if no direct link exists between two disparate sites in AD.

IP replication traffic is utilized in most cases for intersite communications. This type of traffic uses the familiar Remote Procedure Call (RPC) communications to send information between different sites, making it an ideal form of communications for most WAN-based networks.