ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Active Directory
Replication
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
environment.
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.
