active directory replication overview

8/13/2019 Active Directory Replication Overview

1/13

[ Team LiB ]

Replication Overview

It helps to manage Active Directory replication if you have a road map of how the domaincontrollers connect to each other and what information they exchange. In this section, we'll

take a look at what Active Directory components get replicated, where the replication trafficgoes, how that traffic is managed, and what happens when conflicting updates collide with eachother.

Replication and Naming Contexts

Domain controllers are like hard-working parents. They can only give what they have. Eachdomain controller has at least three naming context replicas:

Configuration.All domain controllers in a forest have a read/write copy of this naming

context.

Schema.All domain controllers in a forest have a read-only copy of this naming context.

Domain.Each domain controller in a domain has a read/write copy of that domain's

naming context.

In addition, Global Catalog servershost partial naming contexts for domains other than theirown. You can also create Application naming contexts for holding DNS zone objects and placethose naming contexts on domain controllers running DNS. Figure 7.1shows a three-domainforest and the naming contexts that would be found on a Global Catalog serverin one of those

domains.

Figure 7.1. Diagram of three-domain forest and the naming contextshosted by a GC in the root domain.

As you build a mental image of replication, keep in mind that each naming context constitutes a

separate replication unit. Domain controllers must propagate changes made to their replica of anaming context out to other domain controllers hosting a replica of the same naming context.

Connections

Page 1 of 13

25-11-2013mk:@MSITStore:C:\Users\harmandeep.saggu\Desktop\Inside%20Windows%20Serv...


2/13

Domain controllers replicate with specific partners. These partners are defined by Connection

objects in Active Directory. The map of domain controllers and their connections is called atopology.

The service responsible for handling replication between two domain controllers is the DirectoryReplication Agent, or DRA. The DRA depends on the Connection objects in the topology map todetermine which partners to contact when replicating updates to a naming context.

Connection objects define inbound replication paths. Domain controllerspullupdates from theirpartners. When a domain controller needs to update its copy of a naming context, the DRAsends a replication request to its partners. The DRAs on the partners respond by assembling a

replication packet containing updates to the naming context then delivering the packet to therequesting partner.

This replication packet varies in size depending on the memory in the domain controller. Thepacket size is 1/100 of the amount of RAM. For this reason, it is advantageous to add memoryto a DC. A heavily loaded DC would also benefit from a second processor.

Watching domain controllers selecttheir partners is like watching teenagers pick seats in the

cafeteria at lunchtime. The DRA prefers to use a single Connection object to define the endpoints for all the naming contexts hosted by a domain controller. For this reason, domaincontrollers prefer to replicate with other domain controllers in their own domain. If necessary, a

domain controller will replicate its Configuration and Schema naming contexts with one partnerand its Domain naming context with another partner, but only if no other options are available.

Global Catalog servershave a special challenge when selectingreplication partners. GC serversneed a partial replica of every Domain naming context. They can replicate the partial namingcontext replicas from another GC or directly from domain controllers in the source domain.Keep this behavior in mind as you lay out your architecture. Make sure that GC serverscan link

to other GC serversto prevent a serverfrom snaking out links to multiple domain controllers inother domains.

Property Replication

I t would be a tall order to replicate the entire contents of a naming context each time a domain

controller updates its partners. I t's more efficient to replicate only the items that change.

The Exchange directory service from which Active Directory was derived takes the approach ofreplicating an entire object when any property of that object changes. This makes for a simplereplication mechanism, because the DRA simply copies an entire row out of the table holdingthe object's information. Replicating entire objects abuses the network with unnecessary traffic,though, and complicates the collision handling mechanism if conflicting changes are made in the

same replication interval.

The Active Directory engine replicates individual properties rather than entire objects. This

conserves bandwidth at the expense of a little added complexity. I t's more difficult to ensuredatabase consistency with lots of individual properties flying around the network.

To help control property replication, each property contains a set of information that defineswhen the property was last modified, where the modification originated, and how many totalrevisions have been applied to the property. This is called theproperty metadata. The metadatais stored right along with the property's primary value, such as Name or CN or Department. Seethe "Property Metadata" section later in this chapter.

Sites

Replication reliability is heavily dependent on the underlying infrastructure. I f a network link isslow or unreliable, the replication connections using that link will fail.

Page 2 of 13



3/13

Microsoft defines a siteas an area of reliable, high-speed network communications. Replication

within a site is calledintra-site. Replication between sites is called inter-site.

Deciding where to create sites and how to define and provision the links between those sites

constitutes a critical part of laying out the Active Directory architecture.

A site is usually a LAN or MAN. I t can also be a campus network if you have sufficientbandwidth between buildings. You should have at least 500Kbps of bandwidth to support fullspeed replication within a site. See the "Measuring Link Performance" sidebar. Even if the links

are fast, though, if they regularly become oversubscribed or demonstrate long periods of highlatency, you may experience replication problems if you do not define separate sites.

Sites are also used to limit network traffic caused by LDAP searches and Kerberosauthentication. Details of this localization are in the "Localizing Active Directory Access" topic.

Replication Frequency

Active Directory uses a loosely coupled replication mechanism. This means an interval of some

duration exists between the time a modification is made to a property in one replica and thetime the modified property appears in all replicas. During this interval, an LDAP query to onedomain controller could produce a different result than the same query submitted to anotherdomain controller. Keep this behavior in mind when troubleshooting problems.

The time it takes for a modified property to replicate to all domain controllers is calledconvergence time. Ideally, changes would propagate nearly instantaneously so that

convergence time would be zero. That ideal cannot be obtained in a practical network.Convergence time is always a compromise between low network traffic and fast updatepropagation. Active Directory uses two methods for controlling convergence time: notificationand polling.

Notification

When a domain controller modifies a property in one of its naming contexts, it notifies itsreplication partners within a site that a change has been made. The partners then pull a copy of

the changed property and apply it to their naming context replica. Those domain controllers, inturn, notify their own replication partners and the change propagates in stages around the site.

Measuring Link PerformanceUnlike classic NT, Windows Server2003 dynamically measures link performance todetermine if a slow or fast link exists. The calculation goes like this:

1. Ping a serverwith 0 bytes of data and time the round trip. If the time is lessthan 10ms, it's a fast link.

2. Ping the same serverwith 4KB of data and time the round trip.

3. Calculate the delta between the 4KB round trip and the 0KB round trip. This

results in the time necessary to move 4KB of data.

4. Repeat 3 times and get an average 4KB transfer time.

5. Convert to bits-per-second and compare to benchmark. The default benchmarkis 500Kbps.

Page 3 of 13



4/13

Short notification intervals will propagate changes more quickly than long intervals, butgenerate more traffic to carry the same amount of information. (Each replication packet is

smaller.) The default notification interval is 15 seconds.

Notification is only used between domain controllers in the same site. Replication between

bridgehead serversin different sites uses polling only, not notification. This permits the

system to accumulate sufficient changes (more than 50KB) to warrant compression.

Polling

Domain controllers periodically query their replication partners to see if any changes haveoccurred. Shorter polling intervals reduce convergence time.

The polling interval between domain controllers in the same site is set to 1 hour. This intra-sitepolling is not intended to propagate changes. I t simply acts as a status check to ensure that thereplication partner is available in the event that no Active Directory changes are made duringthat hour.

The default polling interval between domain controllers in different sites is set to 180 minutes,or 3 hours. This is a long time to wait for updates to propagate. You can set it to a shorter

interval.

Keep these replication intervals in mind. You'll use the numbers over and over as you set up

your sites and configure replication parameters. They also affect daily operation. For example, aHelp Desk technician responsible for changing group members needs to remember that achange made to a user's group membership could take three hours (or longer) to replicate tothe site containing the user who was just added to the group.

Urgent replication items are propagated between sites using the normal polling frequency. Youcan enable notification between sites but this is not recommended. See "Controlling ReplicationParameters" for details.

Replication Methods

Urgent Replication

Three items are replicated immediately, regardless of the notification interval setting.These are

Account lock-outs

Changes to LSA secrets

Changes to the RI D Manager

Urgent changes are only replicated quickly within a site. Because inter-site replicationpartners do not use notification, they cannot propagate urgent replication packets.

This can affect lockout handling because the user who entered the wrong passwordseveral times might be in a different site than the administrator who needs to resetthe lockout.

You might expect password changes to also be replicated urgently, but they arehandled using a different mechanism. Password changes are sent directly to the PDCEmulator using a secure channel rather than standard replication. The PDC Emulatoracts as a second-check for all denied passwords.

Page 4 of 13



5/13

Most communication between network entities uses an application-layer protocol. For instance,

when a Windows network client copies a file from a Windows server, it uses the ServerMessageBlock (SMB) protocol. When an Internet email client wants to send a message to a post office, ituses Simple Mail Transport Protocol (SMTP). Active Directory replication can use one of twohigh-level protocols.

Remote Procedure Calls

The primary protocol used by Active Directory replication is the Remote Procedure Call, or RPC.RPC transactions are simple to code and have a robust set of tools for creating and managing aconnection. RPCs are especially attractive for Active Directory replication because they have astraightforward encryption methodology. Encryption is an essential component of replication.You do not want someone with a packet sniffer to view sensitive directory information as it

transits the network.

In an RPC transaction, an RPC client issues a function call to the complementary RPC server

without much regard for the state of the intervening network. This greatly simplifies the wayapplications are coded. On the other hand, the application can get impatient if it waits too longfor a response. This can cause a loss of connection if the client gives up.

Here's the bottom line: RPCs make for a great data communication tool but they are finickyover wide area connections. For this reason, Active Directory uses two forms of RPC: a high-speed form for use in a local network and a low-speed form for use across a WAN. The low-

speed form has higher latency (longer timeouts) and will suffer through multiple connectionlosses before giving up.

SMTP

Active Directory can also use Simple Mail Transport Protocol (SMTP) for transferring replicationpackets. SMTP is a robust protocol, well suited for use across uncertain network connections.

SMTP also permits asynchronous communication, making it possible to transfer replicationpackets in bulk.

Unfortunately, SMTP has a couple of serious drawbacks when it comes to Active Directoryreplication. The first is structural. SMTP transfers messages in clear text. For this reason, thesystem automatically encrypts SMTP messages using a proprietary form of secure messaging.This form of encryption uses certificates, so you must have a Certification Authority. Encryptionputs a significant load on a server, so ensure that the bridgeheadsare especially fast with

multiple processors to share the workload.

The second drawback of using SMTP is a limitation of the File Replication Service (FRS). Recall

that FRS is used to sync the contents of Sysvol between domain controllers. FRS can only useRPCs to carry replication traffic. In addition, FRS uses the same replication topology (includingthe same connection options) as those specified for Active Directory replication, so you cannotspecify one transport for Active Directory replication and another for FRS.

Because of this limitation, SMTP cannot be used to replicate the contents of a Domain namingcontext because the contents of Sysvol cannot be kept in sync. SMTP can be used for all other

naming contexts, including the Configuration, Schema, and Application naming contexts and thepartial naming contexts that make up the Global Catalog.

If you have a remote location with a slow, unreliable connection that calls for the queuingcapabilities of SMTP, you'll need to create a separate domain for that location.

Replication Topology

Domain controllers know each other's location and the connections between them. The LDAPterm for this topology information is knowledge. The service responsible for tailoring the

Page 5 of 13



6/13

replication topology is the Knowledge Consistency Checker, or KCC.

The KCC treats the domain controller topology like a game of K* Nex. Every 15 minutes, itsurveys the domain controllers in the domain and decides where to place Connection objects so

that each domain controller gets its updates in a reasonable amount of time. The KCC on a

bridgehead serverincludes the bridgehead serversin other sites in its calculations.

The KCC makes its decisions based on a spanning tree algorithm. One of the improvementsmade in Windows Server2003 is a streamlining of this algorithm that enables the KCC tohandle more sites and larger topologies. In Windows 2000, there was a limit of approximately

100 sites and domain controllers before an administrator would be forced to intervene andcreate manual connections. Using Windows Server2003, a much larger number of sites anddomain controllers are supported. Microsoft has not specified a limit.

Intra-Site Topology

If you're an Exchange administrator, you'll be pleased with the changes made to the KCC in

Windows Server2003.

When it comes to selectingreplication partners, the Exchange directory service behaves like a

sailor on a 24-hour pass. I t creates point-to-point replication connections between everydomain controllers in a site. The Active Directory KCC is much more discriminating. I t selectsalimited number of partners to structure a tightly controlled topology. For intra-site replication,the KCC builds a replica ring. See Figure 7.2for an example.

Figure 7.2. Simple replication ring.

When constructing a replica ring, the KCC follows a 3-hop rule: no domain controller is morethan 3 hops from any other domain controller. Recall that a domain controller can wait up to 15seconds to notify its replication partners following a change to one of its naming contexts. Bylimiting the hop count, the KCC ensures that changes converge quickly.

Page 6 of 13



7/13

Replica Ring Formation

When a new domain controller is promoted, the KCC on that domain controller gets a copy ofActive Directory in much the same way that aliens invading Earth get the name and location ofthe White House. They land furtively and use a slimy tendril to suck the brains out of an

innocent human being who wasn't doing them any harm at all. (Excuse the emotion. I was bornand raised in Roswell, where we're a little sensitive about this sort of treatment.)

During a domain controller promotion, the Active Directory Promotion Wizard creates aconnection to an existing domain controller then uses that connection to pull a full copy ofActive Directory. When the next KCC on the existing domain controller runs (sometime in thenext 15 minutes), it sees the new connection and builds a complementary connection to thenew domain controller. They are now full-fledged replication partners.

The KCCs on the other domain controllers take note of these changes and proceed to break andmake their own connections to insert the new domain controller into the replica ring. This

happens without any administrative intervention.

If the ring gets more than six domain controllers, such as that in Figure 7.3, the KCC running

on each domain controller realizes that there are more than three hops in the ring. It sets towork building optimizing connectionsbetween domain controllers to reduce the hop count.Remember that the domain controllers share common knowledge about connections, so theyeventually work out a mutually agreeable topology.

Figure 7.3. Meshed replication ring.

Replica Ring Repair

If a domain controller does not respond to a replication request, the DRA wakes up the KCC.

Page 7 of 13



8/13

The KCC takes over and builds new connections to bypass the failed domain controller, like a

heart muscle healing itself after a heart attack.

The DRA keeps trying to contact the lost domain controller. When the domain controller comes

back online again, the KCC sets to work restructuring the connections to reintroduce it back intothe ring.

Under normal circumstances, all this repair work happens automatically. The only time anadministrator should need to do any manual configuration is in the event that the KCC is unableto find a suitable replication partner due to a Domain Name System (DNS) failure. Thisgenerally occurs when a failed domain controller is also the DNS serverfor a site. If you always

specify multiple DNS serversin your TCP/ IP configuration, you should avoid this problem.

Inter-Site Topology

The replication picture changes considerably when the domain controllers are in different sites.Let's consider for a moment what would happen if there were such thing as inter-sitereplication. Figure 7.4shows what this would look like.

Figure 7.4. Replica ring without special site configurations.

In this configuration, the Directory Replication Agents running on the domain controllers haveno way of knowing that the intervening network connections are slow and prone tooversubscription and potential failure. They blithely replicate as fast and as often as they would

for normal network connections.

That's when trouble begins. The high-speed RPC connections begin to fail when the WAN links

become oversubscribed and latency increases. The symptoms of RPC failures include persistentdifferences between replicas, DRA and KCC errors in the Event log, and eventually fatal RPCend-point errors when the connections fail repeatedly.

Active Directory avoids this carnage by building connections between sites that use special, low-speed RPCs. For this reason, inter-site replication uses an entirely different topology. See Figure7.5for an example.

Figure 7.5. Inter-site replication topology.

Page 8 of 13



9/13

Inter-Site Replication Compared to Intra-Site Replication

Several features differentiate inter-site replication topology from its intra-site cousin:

Replication between sites occurs only between two domain controllers, called

bridgeheads.

Notification is disabled between bridgehead servers. Replication is controlled solely bypolling. The default inter-site polling interval is 180 minutes (3 hours).

Replication packets between sites are compressed to conserve bandwidth. Compression

puts more of a CPU load on the domain controller, so bridgeheadsshould be capablemachines with sufficient speed and processors to handle their duties.

Bridgehead Server Selection

The KCC selectsa serverto act as the bridgeheadfor a site. I t makes this decision using thefollowing criteria:

I t looks to see if an administrator has selectedany preferred bridgehead servers. Ifso, it uses these as a selectionpool.

I f there are no preferred bridgehead servers, any domain controller in the site is acandidate.

The KCC lines up the candidates in order of their Globally unique I dentifier (GUID). The

domain controller with the highest GUID wins.

Inter-Site Topology Generator

Page 9 of 13



10/13

The bridgehead selectionis something of a secret in that domain controllers in other sitesdon't know the results until they are told, something like waiting for the College of Cardinals toselecta pope.

Rather than watching for the color of the smoke from the chimney of the Sistine Chapel, thesites wait for a Connection object between the bridgeheadsto appear in the Configurationnaming context. This Connection object is created by a domain controller designated as the

Inter-Site Topology Generator, or ISTG.

There is only one ISTG in a site. I t is selectedusing the same criteria as the bridgeheadserverthat is, the domain controller with the highest GUID. For this reason, the ISTG is often

a bridgehead server, but it doesn't have to be. For instance, the ISTG might not be on thelist of preferred bridgehead servers.

The ISTG runs as a separate function from the KCC because one site can have more than onebridgeheadif there are multiple domains. Each of these bridgeheadshas a copy of the Schemaand Configuration naming contexts and may have a copy of the Global Catalog partial namingcontexts, as well. Inter-site replication would turn into anarchy if all those bridgeheadsmadeindependent decisions about where to create Connection objects.

Inter-Site Topology Highlights

If you're experiencing a little anarchy of your own right now in trying to construct a mentalpicture of all this, here are some highlights (refer to Figure 7.5)

There is only one I STG per site. I t creates the Connection objects that define the

replication path between bridgeheadsin different sites.

There is one bridgehead serverfor each Domain naming context in each site. One

Identifying the Bridgehead Serverand ISTG

You can identify the serverdesignated as the bridgeheadfor a site using theREPADMIN utility with the following syntax:

[View full width]

C: \ >r epadmi n / br i dgeheads / ver boseGat heri ng topol ogy f r omsi t e Phoeni x ( s1. company. com) :Br i dgeheads f or si t e Phoeni x ( s1. company. com) :Sour ce Si t e Local Br i dge Tr ns Fai l . Ti me #

St at usHoust on S1 RPC ( never ) 0

Operat i on compl eted successf ul l y.

Nami ng Context At t empt Ti me Success Ti me#Fai l Last Resul t

subsi di ary 2002- 02- 07 08: 53: 01 2002- 02- 07 08: 53: 01 0Oper at i on compl et ed successf ul l y.

Conf i gur at i on 2002- 02- 07 09: 04: 42 2002- 02- 07 09: 04: 42 0Oper at i on compl et ed successf ul l y.

Schema 2002- 02- 07 08: 49: 19 2002- 02- 07 08: 49: 19 0Oper at i on compl et ed successf ul l y.

You can identify the ISTG for a site by opening the Properties window for the NTDSSite Settings object in the AD Sites and Services console.

Page 10 of 13



11/13

Domain bridgehead serveris designated as the bridgeheadfor the Configuration andSchema naming contexts. Another bridgeheadwill be responsible for theDomainDNSZones and ForestDNSZones naming contexts if the Configuration and Schemabridgeheadis not a DNS server.

The KCC selectsthe bridgeheadby picking the domain controller with the highest GUID

from a list of candidate domain controllers. If an administrator has selectedpreferred

bridgehead servers, they become the only candidates.

I f you create an Application naming context and designate domain controllers in differentsites to host a replica, each site will have a bridgeheadfor this naming context. This mayor may not be the same bridgeheadused by another naming context.

Failure of a Bridgeheador ISTG

If a bridgeheadfails, its partners in other sites will be unable to complete replicationtransactions. The Directory Replication Agents on the bridgehead's local replication partners will

notice that the bridgeheadhas stopped responding. They snitch to the KCC, which sets to work

selectinga replacement. The KCC waits a period of time (two hours by default) beforetransferring responsibility to the new bridgehead

If an administrator has selecteda set of preferred bridgehead serversand none of theseserversis available, the KCC will not selecta replacement bridgeheadand inter-site replication

will fail. For this reason, it is very important that you selectmultiple preferred bridgehead

serversfor each Domain naming context.

If a failed bridgeheadcomes back on line, it does not reassume its old responsibilities. I t gets inline as a candidate for replacing the new bridgeheadshould the new bridgeheadever fail.

Detecting an ISTG failure is a little trickier. The ISTG is like an emeritus professor; it only showsup at ceremonial occasions and funerals. To make sure everyone knows it's still alive, the I STG

periodically updates an attribute called Inter-siteTopologyGenerator in its NTDS Settings object.By default, it does this update every 30 minutes. The update replicates to the rest of thedomain controllers so they know the ISTG is on the line. I f an hour passes without this attributebeing updated, the KCC on the other domain controllers selecta new ISTG using the highestGUID rule.

Site Objects in Act ive Directory

Active Directory stores the objects that control replication under the Sites container in theConfiguration naming context. Because every domain controller hosts a copy of the

Configuration naming context, every domain controller has the same information about site

names, locations, and connections. This is how the KCC services on separate domain controllersall come to the same conclusion about replication topology. They all work from the same cribsheet.

Figure 7.6shows how Active Directory objects represent the various components of areplication topology. Here is a list of the objects and their functions:

Site.This object acts as a placeholder for the objects underneath.

. This object represents a specific site. The object contains a Site-Object-BL

attribute that points to a Subnet object such as 10.3.20.0/24. Every site must be linkedto at least one Subnet object.

Page 11 of 13



12/13

Subnet.This object contains a Site-Object attribute that points at the linked Site object.

A site can be linked to more than one subnet, but a subnet can be linked to only one site.

.This object represents a specific server. I t contains attributes that

define the DNS host name of the serverand its Globally Unique Identifier (GUID). Thisinformation is included in each property that is changed on the serverand acts as a

marker when the changed properties are replicated to other servers.

NTDS Settings.This object lists the naming contexts hosted by the associated domain

controller. For example, a Global Catalog serverin domain DomA in a two-domain forestwith DomB would have these entries:

hasMast er NCs: CN=Schema, CN=Conf i gur at i on, DC=DomA, DC=comhasMast er NCs: CN=Conf i gur at i on, DC=DomA, DC=comhasMast er NCs: DC=DomB, DC=comhasPar t i al Repl i caNCs: DC=DomB, DC=com

NTDS Site Settings.This object has an attribute called Schedule that determines the

default replication schedule for the Connection objects in the site. I t also has an Inter-site-Topology-Generator attribute that identifies the ISTG for the site.

Site Link.This object contains a Site-List attribute that shows the sites that act as end-

points for the link. The system defines a default Site Link object called Default-IP-Site-Link.

Connection.This object defines parameters for inbound replication to the domaincontroller. It has a From-Serverattribute that identifies the replication partner. A

Transport-Type attribute specifies the transport used by the connection. A Scheduleattribute defines how often to poll for updates. By default, a Connection object uses theschedule defined by its parent NTDS Site Settings object.

Figure 7.6. Active Directory objects representing replication topology.

The "Configuring Inter-site Replication" section later in this chapter describes how these objectsare used when configuring sites and inter-site replication.

Replication Topology Summary

Page 12 of 13



13/13

Here are the important points to remember when you begin detailing your Active Directory site

architecture:

Active Directory is divided into separate naming contexts. Each naming context forms a

discrete replication unit.

Only changed properties are replicated, not entire objects. Properties contain special

metadata information used to validate database consistency and control replication traffic.

Sites define areas of reliable, high-speed network communication. A high-speed link is

500Kbps or faster.

Domain controllers replicate from specific partners. Connection objects in Active Directory

define replication partners. All replication is inbound across the connection.

The KCC is responsible for mapping out replication topology by creating Connection

objects between domain controllers in the same site. The ISTG creates Connection objects

between bridgehead serversin different sites.

Intra-site topology uses a ring with sufficient meshed connections to maintain a hop count

of 3 or fewer. Inter-site replication uses bridgeheads.

Within a site, domain controllers notify their partners when updates are pending. The

default notification interval is 15 seconds. Between sites, bridgeheadswait for polling. Thedefault polling interval is 3 hours.

There are three replication transports: high-speed RPCs used within a site, low-speed

RPCs used between sites, and SMTP that can be used between domains. SMTP requiresIPSec and a Microsoft Certificate Authority.

[ Team LiB ]

Page 13 of 13

active directory replication overview

Documents