Understanding Active Directory replication

By Brien M. Posey MCSE February 16, 2001, 8:00am PST If youve worked much with Windows 2000, you know just how important Active Directory can be. Active Directory stores everything from network security information to basic contact information for network users. As with any database of such importance, Active Directory is subject to constant updates. Normally, rapid database updates arent a problem. What makes Active Directory updates so special is that unlike a conventional database, Active Directory isnt stored in a single location. Instead, its distributed across all of your domain controllers. Therefore, Windows 2000 must be able to keep track of any database changes, regardless of which server the change was made on. The process by which Windows keeps track of these changes is called replication. In this Daily Drill Down, Ill discuss the concepts involved in Active Directory replication. The multimaster model If youve done much networking with Windows NT, youre probably at least vaguely familiar with the concept of replication. As with Windows 2000, Windows NT offers the possibility of having multiple domain controllers in each domain. However, Windows NT uses a much simpler replication model than Windows 2000 uses. In Windows NT, any changes to the Security Accounts Manager (SAM) database can occur only on the primary domain controller. Therefore, when an administrator makes a change to an account, the change is always applied directly to the primary domain controller, regardless of how many domain controllers actually exist on the system. Keep in mind that in Windows NT, each domain controller maintains a copy of the SAM database. This copy allows any domain controller to authenticate users. Because each domain controller contains an independent copy of the SAM database, the copy must be updated to match changes that occur to the primary domain controllers copy. To avoid overwhelming the backup domain controllers, which may already be busy with other tasks, the primary domain controller doesnt automatically push the database modifications onto the backup domain controllers. Instead, the primary domain controller simply alerts each backup domain controller to the fact that a change has occurred. When the backup domain controllers have some idle time, they each contact the primary domain controller and request that the changes be replicated to them. Windows 2000, on the other hand, uses a much more complicated replication model called multimaster replication. In multimaster replication, any time an administrator makes a change to Active Directory, the change can be applied directly to any domain controller. Remember that in Windows 2000, theres no such thing as a primary domain controller or a backup domain controller. Instead, a server is either a domain controller or a non-domain controller. As such, all domain controllers in Windows 2000 are treated equally. Given the variety of types of information that Active Directory can store, its easy to see just how fast changes to Active Directory can accumulate across multiple domain controllers in a large organization. Its therefore necessary for Windows to frequently synchronize the domain controllers through the replication process.

Windows 2000 accomplishes this task in a method similar to the one used by Windows NT, with the obvious exceptions Ive already discussed. When an administrator makes a change that affects a domain controllers copy of Active Directory, the domain controller sends a notice to the other domain controllers about the change. The other domain controllers may then request a copy of the changes when they have idle time. Because several domain controllers may be replicating changes at any given time, each Active Directory change is time-stamped. This allows Windows 2000 to know which change should take precedence in the event that contradictory changes are made within a replication cycle. As you can imagine, the Active Directory replication process can cause considerable network traffic when large numbers of domain controllers exist within an organization. In a large organization, dozens of domain controllers could potentially be replicating hundreds of Active Directory changes at any given time. This can cause some serious congestion problems, especially on networks that are already bogged down with excessive traffic. Replication-related network traffic can also cause problems by bogging down wide area network (WAN) links. Fortunately, Windows 2000 provides an Active Directory structure that you can use to reduce the replication-related network traffic. This structure is called a site. Intersite Active Directory replication If your background consists primarily of working on Windows NT Servers, the concept of sites may be new to you. Youre probably familiar with sites only if youve used Exchange Server. Even so, sites created by Exchange Server are somewhat different from sites created by Windows 2000. So whats a site? To put it simply, a site is a collection of domain controllers. Typically, these domain controllers service a common group of users. To understand why dividing a network into sites is effective, you must first understand something about the nature of Active Directory. As you probably already know, Active Directory is divided into all sorts of structures, such as domains, trees, and forests. All of these structures fall under the organizations root level. This means that every domain controller in every level of the organization must share Active Directory information to some extent. For example, consider an organization that contains two domains. Even if those two domains have almost nothing to do with each other, they share a common Active Directory and must therefore replicate Active Directory updates between themselves on a regular basis. Earlier I explained how the Active Directory replication process works. In that explanation, any Active Directory changes were replicated across the entire organization on an as-needed basis. If a change was made to a domain controller, the domain controller saw the need to replicate the change to every other domain controller in the entire organization just as soon as the other domain controllers became available. Given the examples and explanations Ive presented so far, you might assume that if two domains or other organizational structures dont have anything to do with each other, then theres really no need to replicate updates between them. Nothing could be further from the truth. Your domain controllers must replicate changes with one another to maintain Active

Directorys consistency and integrity. However, just because you have to replicate Active Directory updates between unrelated organizational structures, it doesnt mean that the replication has to occur immediately. The advantage to creating sites is that you can replicate Active Directory changes between the sites on a scheduled basis rather than on an as-needed basis. Scheduling replication can greatly reduce network traffic and can relieve a tremendous burden from WAN links. I mentioned earlier that sites were nothing more than a collection of domain controllers that serve a common group of users. The idea is that users within these groups need to know about Active Directory updates that are directly related to them more quickly than they would need to know about Active Directory updates that relate to a different office, department, or company. Sites are very flexible. I mentioned that a site is a collection of domain controllers that serve a common group of users, so you may have assumed that a site exists at the same level as a domain. However, this simply isnt true. You can have multiple sites within a single domain, or you can make each domain an individual site. Other than some general guidelines, no firm rules exist governing how sites should be implemented. When should I implement sites? In spite of Windows 2000s loose control over how you implement sites, some situations are much more appropriate for implementing sites than others. One situation in which youd almost always want to implement a site would be the case of a domain spread across a WAN link. Suppose for a moment that you work for a company that has two local offices connected by a WAN link. Now imagine that the idiot who you inherited the network from got the bright idea to use a single domain to cover both buildings. You could greatly improve the networks efficiency by setting up each building as an individual site. The first step youd take in such an arrangement would be to make sure that each building has at least one domain controller. Remember that sites require domain controllers. Even if you werent dividing the network into sites, it would still be a good idea to have at least one domain controller in each building so that users in each building could authenticate locally. After all, you dont want to congest your WAN link with authentication traffic. Now, consider the reason for and the results of separating the two buildings into individual sites. Theres a good chance that the users in each building work more closely with one another than they do with users in the other office. Therefore, an Active Directory change in building A would more likely affect the users in building A than the users in building B. Because of this, youd want to make sure that Active Directory updates within each building continue to be replicated on an as-needed basis. You still have to replicate the changes over to the other building but doing so isnt as time sensitive as replicating the update within the original building. Therefore, you can update the other building on a scheduled basis. You can allow Active Directory updates to accumulate for several hours before replicating them to the other building. This means your WAN link will receive only the occasional burst of strategically timed replication traffic rather than the constant bombardment of traffic it would otherwise be subjected to. I recommend timing the intersite replications to correspond with low periods of network traffic, such as during lunch or after people start going home for the day. Of course, if an

important update is made to Active Directory, the administrator can always force an immediate replication. Now, suppose your entire company shares a single building. Its still possible (and often a good idea) to implement sites, even though no WAN link is present. You can create a separate site for each department. Doing so can drastically cut down on the replication-related network traffic in your organization. How do sites work? Now that you know what a site is, lets take a brief look at how sites work. As youve probably already figured out, the domain controllers that exist within a site continue to replicate with one another on an as-needed basis. Only one domain controller in each site is responsible for replicating changes with other sites, however. This domain controller is known as the bridgehead server. Replication occurs on an as-needed basis among the domain controllers within each site. When it comes time for sites to replicate with one another, each site's bridgehead server forwards all of the changes that have occurred since the last replication cycle to the remote site's bridgehead server. When the bridgehead server in the remote site receives the changes, it replicates those changes to the other domain controllers within the site. Conclusion In this Daily Drill Down, I explained the process by which Active Directory changes are replicated between domain controllers. I also discussed why its sometimes necessary to reduce replication-related network traffic by dividing Active Directory into multiple sites. The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.