Active Directory Replication

OCTOBER 20, 2011 LEAVE A COMMENT

Replication
Replication ensures that changes to a domain controller are reflected in all domain controllers within a domain.
Directory information is replicated to domain controllers both within and among sites.
The Active Directory database is replicated between domain controllers. The data replicated between controllers
called "data" are also called "naming context". Only the changes are replicated, once a domain controller has
been established. Active Directory uses a multimaster model which means changes can be made on any
controller and the changes are sent to all other controllers. The replication path in Active Directory forms a ring
which adds reliability to the replication.

Replication: How and Why

Replication between the domain controllers in an Active Directory domain, no matter in which sites those domain
controllers live, works by keeping track of a version number assigned to the Active Directory database. This
version number is called an Update Sequence Number (USN), and it is used to track the changes made to each
copy of Active Directory. Every time a change is made to the database, the domain controller updates the
database USN where the change was made. Every domain controller keeps track of its USN and, more
importantly, the USNs of its replication partners. Then, every 5 minutes (this is the default interval), the domain
controller checks for changes from its replication partners in the same site. If a domain controller finds that its
replication partner has an update to its USN, it then requests that all changes since the last known USN be sent.
Even if a domain controller has been offline for an extended time, it can quickly be sent all updates to the Active
Directory database when it comes back online. When its time for the test, be sure you understand the differences
between how Active Directory information is exchanged among domain controllers within the same site and
among domain controllers between separate sites.

How Replication is Tracked:

USN Each object has an Update Sequence Number (USN), and if the object is modified, the USN is

incremented. This number is different on each domain controller.

Stamps Each object has a stamp with the version number, timestamp, and the GUID of the domain

controller where the change was made

Domain controllers each contain a "replica" which is a copy of the domain directory. The "directory update
type"indicates how the data is replicated. The two types are:

Origination update A change made by an administrator at the local domain controller.

Replicated update A change made to the replica because of a replication from a replication partner.

What Information Is Replicated

The information stored in the directory (in the Ntds.dit file) is logically partitioned into four categories. Each of
these information categories is referred to as a directory partition. A directory partition is also referred to as
a naming context. These directory partitions are the units of replication. The directory contains the following
partitions:
Schema partition This partition defines the objects that can be created in the directory and the attributes those
objects can have. This data is common to all domains in a forest and is replicated to all domain controllers in a
forest.
Configuration partition This partition describes the logical structure of the deployment, including data such as
domain structure or replication topology. This data is common to all domains in a forest and is replicated to all
domain controllers in a forest.
Domain partition This partition describes all of the objects in a domain. This data is domain-specific and is not
replicated to any other domains. However, the data is replicated to every domain controller in that domain.

Application Directory partition This partition stores dynamic application specific data in Active Directory without
significantly affecting network performance by enabling you to control the scope of replication and the placement
of replicas. The application directory partition can contain any type of object except security principals (users,
groups, and computers). Data can be explicitly rerouted to administrator-specified domain controllers within a
forest in order to prevent unnecessary replication traffic, or it can be set to replicate everything to all domain
controllers in the same fashion as the schema, configuration, and domain partitions.
A domain controller stores and replicates:

The schema partition data for a forest.

The configuration partition data for all domains in a forest.

The domain partition data (all directory objects and properties) for its domain.

This data is replicated to additional domain controllers in the domain. For the purpose of finding information, a
partial replica containing commonly used attributes of all objects in the domain is replicated to the global catalog.
A global catalog stores and replicates:

The schema partition data for a forest

The configuration partition data for all domains in a forest

A partial replica containing commonly used attributes for all directory objects in the forest (replicated
between global catalog servers only)
A full replica containing all attributes for all directory objects in the domain in which the global catalog is

located
DNS Replication
The DNS IP address and computer name is stored in Active Directory for Active Directory integrated DNS zones
and replicated to all local domain controllers. DNS information is not replicated to domain controllers outside the
domain.

How Information Is Replicated

Active Directory replicates information in two ways: intrasite (within a site) and intersite (between sites). The need
for up-to-date directory information is balanced with the limitations imposed by available network bandwidth.
Intrasite Replication Within a site, a Windows Server 2003 service known as the knowledge consistency
checker(KCC) automatically generates a topology for replication among domain controllers in the same domain
using a ring structure. The KCC is a built-in process that runs on all domain controllers. The topology defines the
path for directory updates to flow from one domain controller to another until all domain controllers in the site
receive the directory updates. The KCC determines which servers are best suited to replicate with each other,
and designates certain domain controllers as replication partners on the basis of connectivity, history of
successful replication, and the matching of full and partial replicas. Domain controllers can have more than one
replication partner. The KCC then builds connection objects that represent replication connections between the
replication partners. The ring structure ensures that there are at least two replication paths from one domain
controller to another; if one domain controller is down temporarily, replication still continues to all other domain
controllers,

The KCC analyzes the replication topology within a site every 15 minutes to ensure that it still works. If you add
or remove a domain controller from the network or a site, the KCC reconfigures the topology to reflect the
change.
Intersite Replication To ensure replication between sites, you must connect them manually by creating site
links. Site links represent network connections and allow replication to occur. A single KCC per site generates all
connections between sites. Active Directory uses the network connection information to generate connection
objects that provide efficient replication and fault tolerance,
You provide information about the replication transport used, cost of a site link, times when the link is available for
use, and how often the link should be used. Active Directory uses this information to determine which site link is
used to replicate information. Customizing replication schedules so replication occurs during specific times, such
as when network traffic is light, makes replication more efficient.

Replication Between Sites (Intersite)

The replication between Active Directory sites is a much more complex process. It needs to be: the replication
traffic can have a much more dramatic impact on available bandwidth, and, as such, must include the ability to be
governed more carefully.
You should be familiar with the following key information about intersite replication:
Replication between sites uses compression The compression of Active Directory increases the processing
load on domain controllers. It also cuts back on bandwidth use, which is the more precious resource in Windows
Server 2003.
It uses scheduling Replication between sites occurs only during scheduled hours.
It uses a replication interval The replication is available only during a set schedule; even then, it happens only
periodically during those set hours. These last two behaviors of intersite replication are critical to managing the

impact replication traffic has on your WAN. But before you can manage these parameters, you must create a
second site and then move at least one domain controller to this other site.
After youve moved a domain controller to the other site, youll need to create a connection object between the
domain controllers. By default, one is created for you called DEFAULTIPSITELINK, but you can use Active
Directory Sites and Services to create other sites as needed. Once youve created the links between sites, you
can manage the properties of the connection object much like managing the properties of other objects in the
Active Directory database. In short, theres a lot to consider when configuring and managing Active Directory
traffic once your organization starts to encompass multiple geographic locales.
Configuring Preferred Bridgehead Servers
An easy way to think of the bridgehead server is that its the spokesperson for a site. It is the main server used
to send and receive replication information between sites. As shown in Figure 19-20, the bridgehead sends
replication on behalf of the site, and visa versa. By default, one bridgehead server is selected by the Inter-Site
Topology Generator (ISTG) for each site that contains a domain controller, but you can change this selection
using the method outlined next. Normally, you let this background process select the bridgehead server, so this is
yet another area of expertise that you will rarely need to perform in a production environment.

The Inter-Site Topology Generator (ISTG)

As mentioned, you wont have to specify a bridgehead server under most circumstances. Thats because yet
another Active Directory replication process handles this for you behind the scenes. In every Active Directory site,
there will be one domain controller (if there is a domain controller in the site) called the Inter-Site Topology
Generator (ISTG). This domain controllers job is to build the replication topology both between sites and within
sites. It checks the cost of connections between sites, including whether domain controllers have been added or
removed. The KCC process then uses this polling information to update the inter-site replication topology as
needed. When youre designing and implementing your Active Directory sites, youre mostly concerned with the
placement of your domains domain controllers, the other physical component of the Active Directory
infrastructure.
How to replicate data manually from one site to another site:
1. Repadmin/syncall
2. Active directory sites and services Site name Server NTDS settings right click on connection name and
select Replicate now.
3. Between sites there is a concept of Polling, where DC in one site will check updates from DC in other site. This
polling takes place every 3 hours.
By default replication time from one site to another is 180 mins but this can be changed manually by going to
properties of default site link.