In Windows Server 2003, the replication process is responsible for keeping each domain controller updated with the latest Active Directory information. The replication process is also responsible for keeping DNS replicas synchronised.
As you can see, replication is a very important part of the Windows Server 2003 network operating system. So what do you do when replication fails? For that matter, how do you even know when a failure has occurred? Here are some answers to these questions and how to fix the replication process.
How does replication work?
Before you can fix the replication process, you need to understand how it works. As I mentioned earlier, replication is used to keep both domain controllers and DFS replicas synchronised. There are a few other tasks that use replication as well. For the purposes of this article, I will focus my discussion on Active Directory replication that occurs between domain controllers.
If you have ever worked with Windows NT, then you are probably familiar with the PDC and BDC domain controller roles. In such an environment, if someone needs to make an update to the Security Accounts Manager, the update gets applied to the PDC. The PDC then alerts the BDCs to the update and the BDCs download the updates and use them to update their own copies of the Security Accounts Manager. This structure is known as single master replication.
In contrast, Windows 2000 and Windows 2003 use multi-master replication. In multi-master replication, there is no PDC or BDC. Every domain controller contains a writable copy of the Active Directory database. If an administrator makes an update to the Active Directory, the update is applied to the closest available domain controller. The domain controller then uses the replication process to apply the update to the other domain controllers.
Because of the multi-master replication model, the Active Directory must have a technique for resolving conflicts. For example, suppose that two different administrators are making changes to the same attribute of the same user account at the same time. Now, suppose that those changes get written to two different domain controllers. When the next replication cycle occurs, you will have two domain controllers attempting to write contradictory data to the other domain controllers.
To get around this problem, Windows relies on a "most recent change wins" mentality. This means that Windows looks at the timestamp for both changes. Whichever of the two changes was made most recently will be the change that takes precedence. The other change will be overwritten.
I mention this because I've seen situations in which two administrators try to apply updates to user accounts and can't figure out why some of their changes are undone. If you suspect that you might have a replication problem, do a little checking to make sure that two or more people are not trying to update the same information at the same time.
Another aspect of replication that I want to touch on is something called Inter-site replication. Inter-site replication is domain controller replication across two or more sites.
The idea behind Active Directory sites is that you want to avoid congesting slow WAN links with excessive replication traffic. Imagine for a moment that you have a domain spanning two offices and that each of the two offices has ten domain controllers. Also, imagine that these two offices are separated by a slow WAN link.
In a situation like this, every time anyone makes a change to the Active Directory, the change is replicated to nineteen other domain controllers. It also means that, since there are nineteen other domain controllers that have to be updated, nineteen different copies of the same data are flowing across your network. To make matters worse, ten separate copies of the same identical data are flowing across your WAN link.
1%
8%
ok - now you have told us how 2000 does it, how about telling us how 2003 does it better so you dont have all these issues?