70-240 in 15 minutes a week: Kerberos and Active Directory Replication Page 2
Windows 2000 implements replication much differently than Windows NT 4. In Windows NT domain environments, replication was single-master, meaning that only one domain controller actually accepted updates - the PDC. In Windows 2000, the model is multi-master, meaning that any domain controller can update Active Directory. This presents some challenges in terms of tracking changes on the network and resolving conflicts that might occur, as I'll discuss in a moment. However, along with the challenges that Windows 2000 Active Directory replication presents, it also presents an opportunity in that replication can finally be easily controlled, through the use of sites, site links, and schedules.
I could easily have devoted this entire article to only replication, since there is so much that takes place behind the scenes. Thankfully, what is most important to understand is a handful of concepts (albeit a rather large handful), most of which are rather straightforward. Lets begin by taking a look at how replication works.
In an Active Directory environment, all domain controllers do not contact one central domain controller for changes. Instead, they create relationships with one another which track which domain controllers are sources of replication changes for them. These relationships are called connection objects, and I'll discuss how they work and how they are created shortly. Since every domain controller can accept updates, there is actually a distinction as to which domain controller made the original update. This update is called the originating update. Any update that is received on a DC as a result of replication is referred to as a replicated update.
The actual process of getting updates from one domain controller to another is different depending on whether we are talking about replication within a site or replication between sites. As discussed earlier in the series, a site is a collection of high-speed IP subnets, and the intermediary element between sites is most often a WAN link. You need to define subnets in Active Directory, or AD will assume that all domain controllers are part of the single default site, literally named Default-First-Site-Link. Replication within a site happens on a 5-minute change notification interval. In this type of setup, after an originating update occurs on a domain controller, it waits 5 minutes before initiating a change notification message to replication partners (separated by 30-second intervals). This gives the domain controller time to batch many changes, instead of initiating replication for every change. After being notified, replication partners pull the changes. Note that replication is always pulled, not pushed. Replication between sites is a bigger discussion, and will be discussed in a bit.
A process that runs on all domain controllers called the Knowledge Consistency Checker (KCC) creates the connection objects between domain controllers automatically. The KCC runs every 15 minutes, and makes changes to the topology of connection objects if necessary (for example if a domain controller cannot be contacted). It is also possible to manually create connection objects between domain controllers, though this is not necessary. Connection objects are listed (and can be created) in Active Directory Sites and Services under the NTDS settings icon for a server. Note that the connection objects listed are those from whom a given domain controller will pull replicated changes. By default, the KCC creates a topology that ensures that a domain controller is never more than 3 hops away from another domain controller. In this case, hops refer to the number of domain controllers that need to be traversed to get a change to another domain controller.
Because of the nature of Active Directory replication, it is possible that conflicts could occur if one domain controller accepted an originating update, while another received an originating update on the same object (for example a user). First of all, Active Directory helps to reduce the possibility of this by replicating at the attribute level. As such, one domain controller could update a user's password and another his postal code and there would be no conflict, even thought changes were made to the same object. In the event that there is a conflict, these are solved using three possible methods (also referred to as globally unique stamps), in the order listed below:
1. Version numbers - all attributes start with their version number set to 1. Every time an update occurs, this number increases by one, and a higher version number always wins. However, this also means it is possible that 2 domain controllers could update the numbers to the same value, which means a conflict still exists.
2. Timestamps - In the event that version numbers are the same, timestamps are used, with the time of the update on the domain controllers being compared. The most recent update (say 2:10pm over 2:07pm) always wins.
3. Server GUID - In the highly unlikely event that a conflict still exists, the globally unique identifiers of the servers making the originating update are compared, the one with the higher value wins.
There are a couple of cases that may still cause problems. One example is with orphaned objects. Lets say that you were to create a user in an OU called Sales, and then a minute later the Sales OU was deleted on another domain controller before replication had occurred. In this case, the parent object of the user would no longer exist, and the user would be moved to the LostandFound container, as shown below:
In situations where two
objects are created on different domain controllers that
have the same distinguished name, you'll always be able to
tell, because one of the objects (the one with the higher
stamp from the above list) retains the name while the
lower of the two will exist with a name that appears as
the object's relative name + the characters "CNF:"
+ the GUID of the object.
Another potential problem in a multi master replication model would be the possibility of replication loops occurring. Quite simply, A might let B and C know that changes exist. After receiving the changes, B might also try to send notification to C, who has already received them. To accomplish this, Active Directory uses a technique called propagation dampening. This technique has every domain controller hold a table in memory called the up-to-dateness table, which stores update sequence numbers (USNs) for every domain controller. When a domain controller handles an originating update, it updates its USN number, and this information is held on all other domain controllers. For example, if an originating change was made on DC1, and the USN on DC1 increased to 2667, all domain controllers would have this information in their up-to-dateness table, and would not require it to be replicated again from other partners if they offered the same updates.
Replication between sites works differently than replication within sites in an Active Directory environment. AS mentioned early, a site is a collection of high-speed subnets. In order to define sites and subnets, the proper objects must be created and associated. Usually you would start by creating site objects, and then associating subnet objects with sites. As the screen below shows, I have created 3 new sites, and associated 3 subnets with the site called Toronto, as shown.
In order to control
replication between sites, we need to link the sites
together using site links. A site link connects the 2 or
more sites for the purpose of creating a pathway for
replication. Once a site link has been created, properties
can be set on that link, including the cost, schedule, and
interval. The cost is a number between 1 and 32767 that
helps determine the links that will be crossed in the
event that multiple paths exist. The lower the cost
number, the higher the priority of the path. Usually you
map costs to speed of links - maybe 50 for a T1 link,
500 for a 56K link, and so forth. The schedule defines
when replication is allowed to happen. By default this is
always, but it could be configured to only allow
replication at night, for example. The interval controls
how often replication can occur between sites. By default
this is set to every 180 minutes, but it can be set to
lower or higher values if you choose. Note that inter-site
replication does not use change notification. Instead it
uses the schedule and interval values to figure out when
replication occurs. This is very different than it NT 4,
when change notification was used throughout the
If you are thinking that site links might be problematic, you might be right. For example, imagine if you were to create a new user account and the originating update were to take place on a domain controller in Toronto at 9am. If the schedule on the site link between Toronto and Vancouver only allowed replication between 6pm and 8am, the user account would not appear on domain controllers in Vancouver until after 6pm that evening. Note that this problem is easily circumvented - when creating the account in AD Users and Computers, simply connect to a different domain controller (say one in Vancouver) and create the account. This will make the originating update take place in Vancouver, and then user (presumably in Vancouver) would be able to log on immediately.
Connection objects between domain controllers differ within and between sites. Within a site, domain controllers will have many connection objects with other domain controllers. However, replication between sites happens via connection objects between domain controllers in each site that are designated as bridgeheads. Bridgehead servers are chosen automatically, but you can set a list of preferred bridgehead servers, as shown below. The process that chooses bridgehead servers is the Intersite Topology Generator (ISTG), which runs automatically and will designate a new bridgehead should the current one not be available.