Active Directory Replication Model

Technical Reference
The Active Directory service replication model ensures that Active Directory data on one domain controller is consistent with the
replica of the same data on other domain controllers in the same domain. The Active Directory replication model determines how
changes to Active Directory data are propagated and tracked automatically between domain controllers. The replication model
allows directory data on each domain controller to be updated directly. Each domain controller maintains replication metadata
that indicates the update status both for itself and relative to other domain controllers. In addition, the replication model allows
each domain controller to request (pull) only changes that need to be replicated and to forward changes to other domain
controllers that need them.

What Is the Active Directory Replication Model?

Active Directory replication is the means by which changes to directory data are transferred between domain controllers in an
Active Directory forest. The Active Directory replication model defines the mechanisms that allow directory updates to be
transferred automatically between domain controllers to provide a seamless replication solution for the Active Directory
distributed directory service.

Note
• This discussion of the replication model and related mechanisms for transferring directory data between domain controllers
does not include the topic of replication topology. Replication topology is the set of connections that are generated by the
Knowledge Consistency Checker (KCC) to enable replication to take place between domain controllers.

Active Directory is distributed by means of directory partitions. In addition to directory partitions that store forest‐wide data, each
domain controller stores a replica of a single domain directory partition, which contains data that is specific to one or more closely
aligned business units—the users, computers, organizational units, and network resources that are managed by the same set of
service and data administrators. Because each domain controller stores only one domain directory partition, Active Directory can
scale to hundreds or thousands of domains storing millions of objects.

To efficiently synchronize data between domain controllers that store the same domain, Active Directory replication transfers
updates according to directory partition. Each domain controller receives directory updates to the data that is stored in its domain
only, as well as updates that are stored in the two directory partitions that store configuration and schema data for the forest.

Note
• In Windows Server 2003 forests, domain controllers can also store application directory partitions, which store application data
that can be replicated to only the domain controllers that store the directory partition, irrespective of domain.

Active Directory replication manages the transfer of these updates to the appropriate domain controllers automatically, keeping
domain data up‐to‐date among all domain controllers in the domain, regardless of location. In the process, all domain controllers
in the forest are also updated with changes to forest‐wide data.

Replication Model Components

To globally distribute the directory service, the Active Directory replication model incorporates the components in the following
table.
Replication Model Components and Advantages
Component Description Advantage

Multimaster Every domain controller can receive originating updates to data for Provides fault tolerance, eliminating
replication which it is authoritative, rather than having a single domain controller the dependency on a single domain
that receives all original updates (single‐master replication, such as controller to maintain directory
Windows NT 4.0 replication). operations.
Pull replication Domain controllers request (pull) changes rather than send (push) Reduces unnecessary network traffic.
changes that might not be needed.
Store‐and‐ Each domain controller communicates with a subset of domain Balances the replication load among
forward controllers to transfer replication changes, rather than one domain many domain controllers.
replication controller being responsible for communicating with every other
domain controller that requires the change.
State‐based Each domain controller tracks the state of replication updates. Conflicts and unnecessary replication
replication are reduced.
The Active Directory replication model ensures:
• Domain controller availability. Multimaster replication ensures that all domain controllers are available for updates,
eliminating the potential for slow service if only a single updatable domain controller were available.
• Efficient transfer of data. State‐based and pull replication ensures the minimum replication traffic and the maximum efficiency
to retrieve only the changes that are needed.
•
Reliable consistency. Directory consistency is guaranteed within the same period of replication latency.
• Conflict resolution. Even if two administrators change the same attribute on different domain controllers at the same time,
conflict resolution ensures that only one of the values is replicated to all domain controllers.

Replication Latency
Multimaster replication involves latency — the period of time for an update that occurs on the originating domain controller to
reach all other domain controllers that need it. To address replication latency, multimaster replication ensures loose consistency
with convergence, as follows:
• Loose consistency means that the replicas are not guaranteed to be consistent with each other at any particular point in time
because changes can originate from any replica at any time.
• Convergence means that if the system is allowed to reach a steady state in which no new updates are occurring and all previous
updates have been completely replicated, all replicas of the same directory partition are guaranteed to converge on the same
set of values.

With multimaster replication, it is not necessary for every domain controller to replicate with every other domain controller.
Instead, the system implements a robust set of connections that determines which domain controllers replicate to which other
domain controllers to ensure that networks are not overloaded with replication traffic and that replication latency is not so long
that it inconveniences users. The set of connections through which changes are replicated to domain controllers in an enterprise is
called the replication topology.

Although it involves latency, multimaster update capability provides high availability of write access to directory objects because
several servers can contain writable copies of an object. Each domain controller in the domain can accept updates independently,
without communicating with other domain controllers. Active Directory replication resolves any conflicts that occur when multiple
updates are made to a single directory object.

State‐based Vs. Log‐based Replication

In state‐based replication, each domain controller (master) in the multimaster system applies updates to its replica as they arrive,
without maintaining a change log file. In a typical log‐based replication system (also called “change‐based”), each master keeps a
log of the updates that it originated and communicates its log to every other replica. After a log has arrived at a replica, the replica
applies the log, bringing itself more up‐to‐date. In this process, the destination receives and stores a record of all changes, not just
the changes it needs.

Active Directory replication relies on the current “state” (the current values of all objects) of the source replica instead of logs. The
current state includes metadata that is used to resolve conflicts and to avoid sending the full replica on each replication cycle.
Generally speaking, a directory partition replica maintains all of its objects in a list ordered by last modification. This list is a log of
sorts, but one whose size is a tiny fraction of the size of the replica itself. A typical replication request can be satisfied by
examining only the last few objects on the list because the replication destination server is aware of how much of its replication
source’s list of changes have already been processed.

Multimaster vs. Single‐master Replication

Although a single‐master model is adequate for a directory that has a small number of replicas and for an environment where all
of the changes can be applied centrally, this approach does not scale beyond small organizations nor does it address the needs of
decentralized organizations.

Multimaster replication provides the following advantages over single‐master replication:

• If one domain controller becomes inoperable, other domain controllers can continue to update the directory. In single‐master
replication, if the master becomes inoperable, directory updates cannot take place. For example, if the failed server holds your
password and your password has expired, you cannot reset your password and therefore you cannot log on to the domain.
• Servers that are capable of making changes to the directory can be distributed across the network and can be deployed in
multiple locations.
• By creating multiple replicas of the directory and keeping the replicas consistent, the directory service can handle more queries
per second. Directory services must handle a large number of queries compared to the number of updates they must process. A
typical ratio of queries to updates is 99:1.

Pull Vs. Push Replication

In push replication, a source domain controller sends unsolicited information to update a destination domain controller. Push
replication is problematic because it is difficult for the source to know what information the destination needs. The destination
can receive the same information from another source. Therefore, a source can send unnecessary information to a destination.
Technologies Related to Active Directory Replication
File Replication service (FRS) is related to Active Directory replication because it requires the Active Directory replication topology.
FRS is a multimaster replication service that is used to replicate files and folders in the System Volume (SYSVOL) shared folder on
domain controllers and in Distributed File System (DFS) shared folders. FRS works by detecting changes to files and folders and
then replicating the updated files and folders to other replica members, which are connected in a replication topology.
FRS uses the replication topology that is generated by the KCC to replicate the SYSVOL files to all domain controllers in the
domain. SYSVOL files are required by all domain controllers for Active Directory to function.

Active Directory Replication Dependencies

Active Directory replication has the following dependencies:
• DNS. The Domain Name System (DNS) that resolves DNS names to IP addresses. Active Directory requires that DNS is properly
designed and deployed so that domain controllers can correctly resolve DNS names of replication partners.
• Remote procedure call (RPC). Active Directory replication requires IP connectivity and the Remote Procedure Call (RPC) to
transfer updates between replication partners.
• Kerberos v5 authentication. The authentication protocol for both authentication and encryption that is required for all Active
Directory RPC replication.
• LDAP protocol. The primary access protocol for Active Directory. Replication of an entire replica of an Active Directory domain,
as occurs when Active Directory is installed on an additional domain controller in an existing domain, uses LDAP communication
rather than RPC.
The following diagram shows the interaction of these components within the replication process.
How the Active Directory Replication Model Works
Active Directory data takes the form of objects that have properties, or attributes. Each object is an instance of an object class,
and object classes and their respective attributes are defined in the Active Directory schema. The values of the attributes define
the object, and a change to a value of an attribute must be transferred from the domain controller on which it occurs to every
other domain controller that stores a replica of that object.

Thus, Active Directory replicates directory data updates at the attribute level. In addition, updates from the same directory
partition are replicated as a unit to the corresponding replica on the destination domain controller over the same connection to
optimize network usage.

The information in this section applies to organizations that are designing, deploying, or operating an Active Directory
infrastructure that satisfies the following requirements:
• A Domain Name System (DNS) infrastructure is in place that manages the name resolution for domain controllers in the forest.
Active Directory‐integrated DNS is assumed, wherein DNS zone data is stored in Active Directory and is replicated to all domain
controllers that are DNS servers.
• All Active Directory sites have local area network (LAN) connectivity.
• IP connectivity is available between all datacenter locations and branch sites.

The limits for data that can be replicated in one replication cycle are as follows:
• Values that can be transferred in one replication cycle (replication of the current set of updates between a source and
destination domain controller): no limit.
• Values that can be transferred in one replication packet: approximately 100. Replication exchanges continue during the course
of one replication cycle until no values are left to send.
• Values that can be written in a single database transaction: 5,000. The effect of this limit depends on the forest functional level:
• Windows 2000 forest functional level: The minimum unit of replication at this level is the entire attribute. Therefore,
changes to any value in the linked, multivalued member attribute results in replicating the entire attribute. For this
reason, the supported size of group membership is limited to 5,000.
• Windows Server 2003 or Windows Server 2003 interim forest functional level: The minimum unit of replication is a single
value of a linked, multivalued attribute. Therefore, the limitation on group membership is effectively removed.

This section covers the interactions that take place between individual domain controllers to synchronize directory data in an
Active Directory forest.

Active Directory Replication Model Architecture

Active Directory replication operates within the directory service component of the security subsystem. The directory service
component, Ntdsa.dll, is accessed through the Lightweight Directory Access Protocol (LDAP) network protocol and LDAP C
application programming interface (API) for directory service updates, as implemented in Wldap32.dll. The updates are
transported over Internet Protocol (IP) as packaged by the replication remote procedure call (RPC) protocol. Simple Mail Transfer
Protocol (SMTP) can also be used to prepare non‐domain updates for Transmission Control Protocol (TCP) transport over IP.
The Directory Replication System (DRS) client and server components interact to transfer and apply Active Directory updates
between domain controllers.

When SMTP is used for the replication transport, Ismserv.exe on the source domain controller uses the Collaborative Data Object
(CDO) library to build an SMTP file on disk with the replication data as the attached mail message. The message file is placed in a
queue directory. When the mail is scheduled for transfer by the mail server application, the SMTP service (Smtpsvc) delivers the
mail message to the destination domain controller over TCP/IP and places the file in the drop directory on the destination domain
controller. Ismserv.exe applies the updates on the destination.
The following diagram shows the client‐server architecture for replication clients and LDAP clients.
Replication and LDAP Client‐Server Architecture

The following table describes the replication architecture components.

Replication Architecture Components
Component Description

Ntdsapi.dll Manages communication with the directory service over RPC.

Private DRS client Private version of Ntdsapi.dll that runs on domain controllers to make RPC calls for replication.
Wldap32.dll Client library with APIs for access to directory service.
Asn.1 Encodes and decodes LDAP requests for transport over TCP/IP or UDP/IP.
Drs.idl Set of functions for replication (for example, Get‐Changes) and maintenance (for example, Get replication
status)
MAPI (address Entry protocol for address book applications such as Microsoft Outlook.
book)
Domain rename Carries out domain rename instructions.
Ntdsa.dll The directory service module, which supports the Windows Server 2003 and Windows 2000 replication
protocol and LDAP, and manages partitions of data.
ISMServ.exe Prepares replication data in e‐mail message format for SMTP protocol transport.
Component Description

CDO library Used by Ismserv.exe to package replication data into a mail message.
Smtpsvc SMTP service.

Note
• If Windows NT 4.0 backup domain controllers (BDCs) are operating in the forest, Windows NT4 Net APIs provide an entry to the
security accounts manager (SAM) on the primary domain controller (PDC) emulator.

The protocols that are used by Active Directory replication are described in the following table. RPC and SMTP are the replication
transport protocols. LDAP is a directory access protocol, and IP is a network wire protocol.

Active Directory Access and Replication Protocols

Protocol Description

LDAP The primary directory access protocol for Active Directory. Windows Server 2003 family, Windows XP,
Windows 2000 Server family, and Windows 2000 Professional clients, as well as Windows 98, Windows 95,
and Windows NT 4.0 clients that have the Active Directory client components installed, use LDAP v3 to
connect to Active Directory.
IP Routable protocol that is responsible for the addressing, routing, and fragmenting of packets by the
sending node. IP is required for Active Directory replication.
Replication RPC The Directory Replication Service (Drsuapi) RPC protocol, used in the enabling of administration and
monitoring of Active Directory replication, to communicate replication status and topology and network
topology from a client running administrative tools to a domain controller. RPC is required by Active
Directory replication.
Replication Simple Replication protocol that can be used by Active Directory replication over IP network transport for
Mail Transfer message‐based replication between sites only and for non‐domain replication only.
Protocol (SMTP)

Replication Subsystem
Within the directory service component of the Active Directory architecture, the replication subsystem interacts with the
operational layer to implement replication changes on the destination domain controller. The replication subsystem also
determines the changes that a replication partner already has or those that are needed.

The database layer manages the database capability of the directory service. The extensible storage engine (Esent.dll)
communicates directly with individual records in the directory data store.
The following diagram shows the replication subsystem components.

Replication Subsystem Components

The components of the replication subsystem are described in the following table.
Replication Subsystem Components
Component Description

Ntdsa.dll Directory system agent (DSA), which provides the interfaces through which directory clients and other
directory servers gain access to the directory database.
Replication Directory Replication System (DRS) interface, which communicates with the database through RPC.
Component Description

Operational layer Performs low‐level operations on the database without regard for protocol.
Database layer API that resides within Ntdsa.dll and provides an interface between applications and the directory
database to protect the database from direct interaction with applications.
Extensible storage Manages the tables of records, each with one or more columns that comprise the directory database.
engine (ESE)
Ntds.dit The directory database file.

Active Directory Replication Model Physical Structure

The Active Directory replication model components that determine how Active Directory replication functions between domain
controllers are associated with mechanisms that effect automatic transfer of changes between replicating domain controllers, as
described in the following table.

Active Directory Replication Model Components and Related Mechanisms

Component Description Related Mechanisms

Multimaster All domain controllers accept LDAP requests for changes to attributes of Active LDAP update
replication Directory objects for which they are authoritative, subject to security constraints that Directory partitions
are in place. Each originating update is replicated to one or more other domain Change notification
controllers, which record it as a replicated update. Change tracking
Conflict resolution
Pull replication When an update occurs on a domain controller, it notifies its replication partner. The DNS name resolution
partner domain controller responds by requesting (pulling) the changes from the source Kerberos
domain controller. authentication
Change tracking
Change notification
Change request
Store‐and‐ Domain controllers store changes received from replication partners and forward the Change tracking
forward changes to other domain controllers so that the originating domain controller for each Kerberos
replication change is not required to transfer changes to every other domain controller that authentication
requires the change. DNS name resolution
Change notification
Change request
State‐based Active Directory replication is driven by the difference between the current “state” (the Change‐tracking
replication current values of all attributes) of the directory partition replica on the source and metadata:
destination domain controllers. This state includes metadata that is used to resolve • Update sequence
conflicts and to avoid sending the full replica on each replication cycle. number (USN)
counter
• Up‐to‐dateness
vector
• High‐watermark
These mechanisms are implemented by the replication system in a sequence of events that occurs between two domain
controllers.
The following diagram shows a simplified version of the sequence between source and destination domain controllers when the
source initiates replication by sending a change notification.
Replication Sequence

Active Directory Data Updates

When a change is made to an object in a directory partition, the value of the changed attribute or attributes must be updated on
all domain controllers that store a replica of the same directory partition. Domain controllers communicate data updates
automatically through Active Directory replication. Their communication about updates is always specific to a single directory
partition at a time.

Active Directory data is logically partitioned so that all domain controllers in the forest do not store all objects in the directory.
Active Directory objects are instances of schema‐defined classes, which consist of named sets of attributes. Schema definitions
determine whether an attribute can be administratively changed. Attributes that cannot be changed are never updated and
therefore never replicated. However, most Active Directory objects have attribute values that can be updated.

Different categories of data are stored in replicas of different directory partitions, as follows:
• Domain data that is stored in domain directory partitions:
• Every domain controller stores one writable domain directory partition.
• A domain controller that is a global catalog server stores one writable domain directory partition and a partial, read‐only
replica of every other domain in the forest. Global catalog read‐only replicas contain a partial set of attributes for every
object in the domain.
• Configuration data: Every domain controller stores one writable configuration directory partition that stores forest‐wide data
controlling site and replication operations.
• Schema data: Every domain controller stores one writable schema partition that stores schema definitions for the forest.
Although the schema directory partition is writable, schema updates are allowed on only the domain controller that holds the
role of schema operations master.
• Application data: Domain controllers that are running Windows Server 2003 can store directory partitions that store application
data. Application directory partition replicas can be replicated to any set of domain controllers in a forest, irrespective of
domain.
Changes to Attributes
Active Directory updates originate on one domain controller (originating updates) and the same update is subsequently made on
other domain controllers during the replication process (replicated updates).

Object update behaviour is consistent and predictable: when a set of changes is made to a specific directory partition replica,
those changes will be propagated to all other domain controllers that store replicas of the directory partition. How soon the
changes are applied depends on the distance between the domain controllers and whether the change must be sent to other
sites.

The following key points are central to understanding the behaviour of Active Directory updates:
• Changes occur at the attribute level; only the changed attribute value is replicated, not the entire object.
• At the time of replication, only the current value of an attribute that has changed is replicated. If an attribute value has changed
multiple times between replication cycles (for example, between scheduled occurrences of intersite replication), only the
current value is replicated.
• The smallest change that can be replicated in Windows 2000 Active Directory is an entire attribute; even if the attribute is
linked and multivalued, all values replicate as a single change. The smallest change that can be replicated in
Windows Server 2003 Active Directory is a separate value in a multivalued attribute that is linked. This Windows Server 2003
feature is called linked‐value replication.
• The individual values of a multivalued attribute are replicated separately under the following conditions:
• The forest functional level is Windows Server 2003 interim or Windows Server 2003.
• The attribute is linked. Linked attributes have the following characteristics:
The attribute has distinguished name syntax.
The attribute is marked as linked in the schema.
• An attribute is available for replication as soon as it is written.
• Replication is store‐and‐forward and moves sequentially through a set of connected domain controllers that host directory
partition replicas.
• Multimaster conflict resolution is effective without depending on clock synchronization.
• Originating updates to a single object are written to the database in the same transaction, so partially written objects are not
possible and a consistent view of the object is maintained.
• For replicated updates to large numbers of values in linked multivalued attributes, such as the member attribute of a group,
updates are not always guaranteed to be applied in the same transaction. In this case, the updates are guaranteed to be
applied in one or more subsequent transactions in the same replication cycle (all updates from one source are applied at the
destination).
• After a replication cycle is initiated, all available changes to a directory partition on the source domain controller are sent to the
destination domain controller, including changes that occur while the replication cycle is in progress.

Effect of Schema Changes on Replication

Attribute definitions are stored in attributeSchema objects in the schema directory partition. Changes to attributeSchema objects
block other replication until the schema changes are performed. During replication of any directory partition other than the
schema directory partition, the replication system first checks to see whether the schema versions of the source and the
destination domain controllers are in agreement. If the versions are not the same, the replication of the other directory partition
is rescheduled until the schema directory partition is synchronized.

Prior to upgrading a domain controller from Windows 2000 Server to Windows Server 2003, you must update the schema to be
compatible with Windows Server 2003. When you run Adprep.exe, Windows Server 2003 schema is installed in the forest. This
process upgrades the schema on each Windows 2000–based domain controller. Thereafter, you can begin upgrading domain
controllers to Windows Server 2003.

Note
• The Windows Server 2003 schema update adds 25 indexed attributes to the schema directory partition. An update of this size
can cause replication delays in a large database. For this reason, domain controllers that are running Windows 2000 Server
must be running at a minimum Windows 2000 Service Pack 2 (SP2) plus all additional Windows updates. However, it is highly
recommended that you install Windows 2000 Service Pack 3 (SP3) on all domain controllers prior to preparing your
infrastructure for upgrade to the Windows Server 2003 operating system.

Effect of Raising the Forest Functional Level on Existing Linked, Multivalued Attributes
Existing linked, multivalued attributes are not directly affected when you raise the forest functional level to enable linked‐value
replication. These attribute values are converted to replicate as single values only when they are modified. This design avoids the
performance effects that would potentially result from rewriting the existing member attribute values of all group objects in the
forest at the same time.

Because the member attribute is not converted until it is modified, a group that exceeded the 5,000‐member limit in
Windows 2000 continues to represent a replication issue because the original set of members continues to replicate as a unit
under the new forest functional level. New members that are added and any member values that are updated replicate separately
thereafter. Therefore, if the groups that were created in Windows 2000 do not exceed the 5,000‐member limit, no replication
issues are associated with the group.
Raising the forest functional level does affect the ability of an authoritative restore process to restore the back‐links of a restored
object that has one or more single‐valued or multivalued linked attributes. The version of Ntdsutil that is included with
Windows Server 2003 provides this functionality automatically when the forest has a functional level of Windows Server 2003
interim or Windows Server 2003. The version of Ntdsutil that is included with Windows Server 2003 SP1 also provides the ability
to restore back‐links that were created before the forest functional level was raised to Windows Server 2003 interim or
Windows Server 2003.

Originating Updates: Initiating Changes

As a Lightweight Directory Access Protocol (LDAP) directory service, Active Directory supports the following four types of update
requests:
• Add an object to the directory.
• Modify (add, delete, or replace) attribute values of an object in the directory.
• Move an object by changing the name or parent of the object.
• Delete an object from the directory.

Each LDAP request generates a separate write transaction. An LDAP directory service processes each write request as an atomic
transaction; that is, the transaction is either completed in full or not applied at all. The practical limit to the number of values that
can be written in one LDAP transaction is approximately 5,000 values added, modified, or deleted at the same time.

A write request either commits and all its effects are durable, or it fails before completion and has no effect. A write request that
commits is called an originating update. An originating update is initiated and committed at a specific replica. The absolute success
or failure of an update applies even for requests that might affect several attributes of a single object, such as Add or Modify. In
this case, if one attribute update fails, they all fail and the object is not updated.

An originating update enforces schema restrictions, including allowable parent object types and syntax for mandatory and
optional attributes for an object. The restrictions are enforced according to the schema that exists on the domain controller at the
moment of the update.

Originating Add
An Add request makes a new object with a unique objectGUID attribute. The values of all replicated attributes that are set by the
Add request are stamped Version = 1. The Add request fails immediately if the parent object does not exist or if the originating
domain controller does not contain a writable replica of the parent object’s directory partition.

Originating Modify
All Modify operations replace the current value of an attribute with a new value. A modify request can specify one of the
following:
• That an attribute be deleted from the object. Attribute deletion is best thought of as replacing the attribute value with NULL.
The NULL value occupies no storage of its own but does carry a stamp, as does any value that is stored as a directory attribute.
• That a value be added to the current value of an attribute, as when modifying an attribute that can have multiple values. The
effect is to replace the current values with the current values plus the added value.

For each attribute in the request, a Modify request compares the new value in the request with the existing value. If the values are
the same, the request to modify that attribute is ignored. If the resulting Modify request does not change any attributes of the
object, the entire request is ignored.

Otherwise, a Modify request computes a stamp in the metadata for each new replicated attribute value by reading the version
from the existing value (version=0 for an attribute that has never been written) and then adding 1 to this value. The Modify
request replaces the old stamp values with new stamp values.

Originating Move
A Move request is essentially a special Modify request for a single attribute, the name attribute. The operation proceeds as
described for the Modify request.

Originating Delete
A Delete request is essentially a special Modify request that does the following series of operations:
1. Sets the isDeleted attribute to TRUE, which marks the object as a tombstone (an object that has been deleted but not fully
removed from the directory).
2. Changes the relative distinguished name of the object to a value that cannot be set by an LDAP application (a value that is
impossible).
3. Strips all attributes that are not needed by Active Directory. A few important attributes (including objectGUID, objectSid,
distinguishedName, nTSecurityDescriptor, and uSNChanged) are preserved on the tombstone.
Note
• Because these attributes are preserved, tombstones can be restored (reanimated) by applications that use the LDAP API
 for undeleting an object.
• On domain controllers running Windows Server 2003 with SP1, the sIDHistory attribute is also retained on tombstone
objects.
4. Moves the tombstone to the Deleted Objects container, which is a hidden container within those directory partitions that
allow deletions.
On domain controllers running Windows Server 2003, you can restore tombstones in the Deleted Objects container to an active
state.

Configuration Objects Protected from Deletion

Certain objects in the configuration directory partition are critical to the functioning of a domain controller. These objects and
their child objects are protected from deletion.

Reanimination of Protected Objects

Each domain controller protects the following objects from deletion:
• The cross‐reference (class crossRef) objects that represent the writable directory partitions that are stored on the domain
controller.
• The RID object for the domain controller.
These objects are protected at that domain controller, as follows:
• The domain controller rejects an originating deletion of a protected object.
• The domain controller does not carry out a replicated deletion of a protected object. Instead, the threatened protected object
is revived by updating its replication metadata as if each attribute had just been updated. The update is then replicated out,
thereby reanimating the deleted object.

Reanimation of the NTDS Settings Object

The NTDS Settings (class nTDSDSA) object is also protected from deletion. On domain controllers running Windows 2000 Server or
Windows Server 2003 with no service pack installed, the NTDS Settings object is reanimated and partner domain controllers
continue to attempt to replicate with it. However, because the NTDS Settings object represents a domain controller in the
replication topology, preserving it as a replication source when a domain controller has been removed from service is
counterproductive and represents a security risk. For example, if a domain controller is demoted (that is, Active Directory is
removed by running Dcpromo.exe), another server with the same name can be installed and mistaken by a replication partner for
the demoted domain controller. To eliminate the possibility of improper replication attempts, domain controllers running
Windows Server 2003 with SP1 disable the ability of the preserved NTDS Settings object to receive replication requests. Although
the object is preserved on the domain controller that deleted it, replication attempts with the server that is represented by the
deleted NTDS Settings object are discontinued.

Replicated Update Tracking by Domain Controllers

A replicated update is performed on one domain controller as a result of receiving replication of an originating update that was
performed at another domain controller. There is not necessarily a one‐to‐one correspondence between originating and
replicated updates. A single replicated update might reflect a set of originating updates (even updates originating at different
domain controllers) to the same object.

For example, the manager of a user object can be changed at one domain controller at the same time the address of the same
user is changed at another domain controller. A third domain controller might receive these changes separately to the user object
and in turn replicate the changes to a fourth domain controller in a single replicated update.

To avoid endless replication of the same update and reapplication of an update that is received from different replication
partners, a domain controller must be able to recognize replicated updates that it has already received as opposed to those that it
has not. Some directory services use timestamps to determine what changes need to be propagated, on the basis of preserving
the last write. But keeping time closely synchronized in a large network is difficult. When the latest time of a directory write is the
only means of determining which of two changes is recorded and replicated, skewed time on a domain controller can result in
data loss or directory corruption.

Active Directory replication does not primarily depend on time to determine what changes need to be propagated. Instead it uses
update sequence numbers (USNs) that are assigned by a counter that is local to each domain controller. Because these USN
counters are local, it is easy to ensure that they are reliable and never run backward (that is, they cannot decrease in value).
Note
• Replication uses Kerberos v 5 authentication protocol for security, which does require that the time services on domain
controllers are synchronized.

When a conflict occurs, instead of using timestamps as the primary mechanism to determine what updates are preserved, Active
Directory uses volatility (number of changes) as the first element of the per‐attribute stamps that are compared during conflict
resolution. The second element is a timestamp. Therefore, if an attribute is updated once on domain controller A and once on
domain controller B, the last writer’s update is preserved. But if the attribute is updated on domain controller A, then on domain
controller B, and then again on domain controller A, the update of domain controller A is preserved even if the clock of domain
controller B is set forward from that of domain controller A. With Active Directory, clock skew can never prevent a value from
being overwritten.
Domain controllers use USNs to simplify recovery after a failure. When a domain controller is restored following a failure, it
queries its replication partners for changes with USNs greater than the USN of the last change it received from each partner.
You do not need to be concerned with USNs and their implications unless you experience problems with replication that require
troubleshooting.

Server Object GUID (DSA GUID) and Server Database GUID (Invocation ID)
The server object that represents a domain controller in the Sites container of the configuration directory partition has a globally
unique identifier (GUID) that identifies it to the replication system as a domain controller. This GUID, called the DSA (Directory
System Agent) GUID, is used in USNs to track originating updates. It is also used by domain controllers to locate replication
partners. The DSA GUID is the GUID of the NTDS Settings object (class nTDSDSA), which is a child object of the server object. Its
value is stored in the objectGUID attribute of the NTDS Settings object.

The DSA GUID is created when Active Directory is initially installed on the domain controller and destroyed only if Active Directory
is removed from the domain controller. The DSA GUID ensures that the DSA remains recognizable when a domain controller is
renamed. The DSA GUID is not affected by the Active Directory restore process.

The Active Directory database has its own GUID, which the DSA uses to identify the database instance (version of the database).
The database GUID is stored in the invocationId attribute on the NTDS Settings object. Unlike the DSA GUID, which never changes
for the lifetime of the domain controller, the invocation ID is changed during an Active Directory restore process to ensure
replication consistency.

On domain controllers that are running Windows Server 2003, the invocation ID also changes when an application directory
partition is removed from or added to the domain controller.

Determining Changes to Replicate: Update Sequence Numbers

A source domain controller uses USNs to determine what changes have already been received by a destination domain controller
that is requesting changes. The destination domain controller uses USNs to determine what changes it needs to request.
The current USN is a 64‐bit counter that is maintained by each Active Directory domain controller as the highestCommittedUsn
attribute on the rootDSE object. At the start of each update transaction (originating or replicated), the domain controller
increments its current USN and associates this new value with the update request.
Note
• The rootDSE (DSA‐specific Entry) represents the top of the logical namespace for one domain controller. RootDSE has no
hierarchical name or schema class, but it does have a set of attributes that identify the contents of a given domain controller.

The current USN value is stored on an updated object as follows:

• Local USN: The USN for the update is stored in the metadata of each attribute that is changed by the update as the local USN of
that attribute (originating and replicated writes). As the name implies, this value is local to the domain controller where the
change occurs.
• uSNChanged: The maximum local USN among all of an object’s attributes is stored as the object’s uSNChanged attribute
(originating and replicated writes). The uSNChanged attribute is indexed, which allows objects to be enumerated efficiently in
the order of their most recent attribute write.
Note
• When the forest functional level is Windows Server 2003 or Windows Server 2003 interim, discrete values of linked
multivalued attributes can be updated individually. In this case, there is a uSNChanged associated with each link in
addition to the uSNChanged associated with each object. Therefore, updates to individual values of linked multivalued
attributes do not affect the local USN, only the uSNChanged attribute on the object.
• Originating USN: For an originating write only, the update’s USN value is stored with each updated attribute as the originating
USN of that attribute. Unlike the local USN and uSNChanged, the originating USN is replicated with the attribute’s value.

Tracking Object Creation, Replication, and Change

The following series of diagrams illustrates the replication‐related data for a single object and one of its attributes as it goes from
creation through replication.
The following diagram shows the replication‐related data for the user object when it is first created on domain controller DC1.
Before the user object is created, the current USN for the domain controller is 4710. When the object is created, the local USN of
4711 is assigned to each attribute of the user object, and the current USN for the domain controller increments from 4710 to
4711. Because the object has not yet changed, the value of its uSNChanged attribute is the same as its uSNCreated attribute 4711.
1. Replication‐related Data on DC1 When a User Object is Created

The next diagram shows the change to the destination domain controller when the new user object is replicated. The object is
created as a replicated update on DC2. Notice that the per‐attribute originating USN and stamp (version, originating time,
originating DC) are replicated from DC1 to DC2, but the per‐attribute local USN and per‐object uSNChanged are unique to DC2.

2. Replication‐related Data on DC2 When a New User Object is Replicated From DC1

The following information is transferred in the metadata of an updated attribute value from the source domain controller to the
destination domain controller:
• The originating USN value for the updated attribute, which is the USN assigned by the domain controller on which the update
was made.
• The stamp, which is used to resolve conflicts.
The next diagram illustrates the change in the replicated object on DC2 when someone changes the password (the userPassword
property in the diagram) of the object on that domain controller. By this time, the current USN on DC2 has increased from 1746 to
2001. The update request changes the password and increments the current USN to 2002 on DC2. The request also sets the
password attribute’s originating USN and local USN to 2002 and creates a new stamp for the password value. The version number
of this password’s stamp is 2, which is one version number higher than the version of the previous password.

3. Replication‐related Data on DC2 After the User Password Value Has Been Changed on DC2

In the next diagram, the changed password is now replicated back to the original domain controller, whose current USN has
increased to 5039. The replicated update increments the current USN of DC1 to 5040. The per‐attribute originating USN and
stamp (version, originating time, originating DC) are replicated from DC2 to DC1, and the per‐attribute local USN and per‐object
uSNChanged values are set to 5040.
4. Replication‐related Data on DC1 After the Password Change Has Replicated to DC1

Replication Request Filtering

Destination domain controllers use the originating USN to track changes they have received from other domain controllers with
which they replicate. When requesting changes from a source domain controller, the destination informs the source of the
updates it has already received so that the source never replicates changes that the destination does not need.

Two values are used by source and destination domain controllers to filter updates when the destination requests changes from
the source replication partner:
• Up‐to‐dateness vector. The current status of the latest originating updates to occur on all domain controllers that store a
replica of a specific directory partition.
• High‐watermark (direct up‐to‐dateness vector). The latest originating update to a specific directory partition that has been
received by a destination from a specific source replication partner during the current replication cycle.
Both of these values specify the invocation ID of the source domain controller.

Attributes to Send for Replication: Up‐to‐Dateness Vector

The up‐to‐dateness vector is a value that the destination domain controller maintains for tracking the originating updates that are
received from all source domain controllers. When a destination domain controller requests changes for a directory partition, it
provides its up‐to‐dateness vector to the source domain controller. The source domain controller uses this value to reduce the set
of attributes that it sends to the destination domain controller.

The up‐to‐dateness vector contains an entry for each domain controller that holds a full replica of the directory partition. The up‐
to‐dateness vector values include the database GUID (invocation ID) of the source domain controller and the highest originating
write (based on the USN) received from the source domain controller. If the up‐to‐dateness entry that corresponds to source
domain controller X contains the USN n, the destination domain controller guarantees that it holds all updates to a specific
directory partition that originated at domain controller X and that have an originating USN value of less than or equal to n.

If the destination already has an up‐to‐date value, the source domain controller does not send that attribute. If the source has no
attributes to send for an object, it sends no information at all about that object.

At the completion of a successful replication cycle between two replication partners, the source domain controller returns its up‐
to‐dateness vector to the destination, including the highest originating USN on the source domain controller. The destination
merges this information into its up‐to‐dateness vector. In this way, the destination tracks the latest originating update it has
received from each partner, as well as the status of every other domain controller that stores a replica of the directory partition.

Timestamp on Up‐to‐Dateness Vector in Windows Server 2003

On domain controllers that are running Windows Server 2003, the up‐to‐dateness vector includes a timestamp that represents the
last time the local (destination) domain controller has completed a full replication cycle with the source domain controller. The
replication cycle may have occurred directly (direct replication partner) or indirectly (transitive replication partner). The
timestamp is recorded whether or not the local domain controller actually received any changes from the partner.

By examining the timestamps, a domain controller can quickly identify other domain controllers that are not replicating. Warning
messages are posted to the event log on each domain controller when non‐replicating partners are discovered (Event ID 1864 in
the Directory Service event log).

Objects to Consider for Replication: High‐Watermark (Direct Up‐to‐Dateness Vector)

The high‐watermark, or direct up‐to‐dateness vector, is a value that the destination domain controller maintains during replication
to keep track of the most recent attribute change that it has received from a specific source domain controller for an object in a
specific directory partition. When sending changes to a destination domain controller, the source domain controller provides the
changes in increasing order of uSNChanged. Although the uSNChanged values from the source domain controller are not stored
on objects at the destination domain controller, the destination domain controller keeps track of the uSNChanged value of the
most recent object that was successfully updated from the source domain controller for a specific directory partition. This USN is
called the destination’s high‐watermark with respect to the directory partition and the source domain controller.
When requesting changes during a replication cycle, the destination provides the high‐watermark value with each request to the
source domain controller, which in turn uses this value to filter the objects that it considers for continuing replication to the
destination. If the uSNChanged value of an object on the source domain controller is less than or equal to the high‐watermark
value of the destination domain controller, the object update has already been received by the destination domain controller and
is therefore not replicated. The high‐watermark serves to decrease the CPU time and number of disk I/O operations that would
otherwise be required.

The up‐to‐dateness vector and the high‐watermark are complementary filter mechanisms that work together to decrease
replication latency. Whereas the high‐watermark prevents irrelevant objects from being considered by the source domain
controller with respect to a single destination, the up‐to‐dateness vector helps the source domain controller to filter irrelevant
attributes (and entire objects if all attributes are filtered) on the basis of the relationships between all sources of originating
updates and a single destination.

For a specific directory partition, a domain controller maintains a high‐watermark value for only those domain controllers from
which it requests changes, but it maintains an up‐to‐dateness vector entry for every domain controller that has ever performed an
originating update, which is typically every domain controller that holds a full replica of the directory partition.

Multiple Paths Without Redundant Replication

Multiple replication paths can exist between a pair of domain controllers. Multiple paths provide fault tolerance and can reduce
latency. However, when multiple paths exist, you might expect the same change to be sent along each path to a specific domain
controller or that a change might replicate in an endless loop. Active Directory prevents these potential problems with multiple
paths by using the up‐to‐dateness vector. The ability to eliminate redundancy is called “propagation dampening.”
The following is an example of how replication ordinarily occurs:
1. DC A updates a password attribute. In this example, the originating USN of the attribute is set to 3.
2. Destination DC B requests changes from source DC A and sends its high‐watermark and up‐to‐dateness vector to DC A.
3. According to the high‐watermark that was passed by DC B, source DC A examines one or more objects, one of which contains
the changed password. When DC A encounters the changed password attribute, it proceeds as follows:
1. First, DC A finds that the originating directory system agent (DSA) of the password attribute is DC A.
Note:
The DSA is the server‐side process that creates an instance of a directory service. The DSA provides access to the
physical store of directory information located on a hard disk.
2. Therefore, DC A reads the up‐to‐dateness vector supplied by DC B and finds that DC B is guaranteed to be up‐to‐date
with updates that originated at DC A and that have an originating USN of less than or equal to 2.
3. DC A then finds that the originating USN of the password attribute is 3.
4. Because 3 is greater than 2, DC A sends the changed password attribute to DC B.
To illustrate propagation dampening, suppose that DC B had already received the password update from DC C, which had received
it from DC A. In this case, the entry in the up‐to‐dateness vector of DC B for DC A would contain the USN value 3, not 2. Therefore,
DC A would not send the changed password to DC B.

Multimaster Conflict Resolution Policy

Active Directory must ensure that all domain controllers agree on the value of the updated attribute after replication occurs. The
general approach to resolving conflicts is to order all update operations (Add, Modify, Move, and Delete) by assigning a globally
unique (per‐object and per‐attribute) stamp to the originating update. Thus each replicated attribute value (or multivalue) is
stamped during the originating update and this stamp is replicated with the value.

Conflict Resolution Stamp

The stamp that is applied during an originating write has the following three components:
• The version is a number that is incremented for each originating write. The version of the first originating write is 1. The version
of each successive originating write is increased by 1.
• The originating time is the time of the originating write, to a one‐second resolution, according to the system clock of the
domain controller that performed the write.
•
The originating DC is the DSA GUID of the domain controller that performed the originating write.
When stamps are compared, the version is the most significant, followed by the originating time and then the originating DC. If
two stamps have the same version, the originating time almost always breaks the tie. In the extremely rare event that the same
attribute is updated on two different domain controllers during the same second, the originating DC breaks the tie in an arbitrary
fashion.

Two different originating writes of a specific attribute of a particular object cannot assign the same stamp because each
originating write advances the version at a specified originating domain controller. The originating time does not contribute to
uniqueness. Replicated writes cannot decrease the version because values with smaller versions lose during conflict resolution.
You can see all three components of the stamp in the output of the repadmin /showobjmeta command.
In the case of a conflict, the ordering of stamps allows a consistent resolution, as described in the following table.
Replication Conflict Resolution
Replication
Description Resolution
Conflict

Attribute value A Modify operation sets the value of an The attribute value at all domain controllers is the value with the
conflict attribute. Concurrently, at another domain larger version number in its stamp.
controller, a Modify operation sets the
value of the same attribute to a different
value.
Add or Move An Add or Move operation makes an At all domain controllers, the parent object is deleted and the
under deleted object a child of parent object. child object is a child of the special LostAndFound container in the
parent, Delete Concurrently, at another domain directory partition. Stamps are not involved in the resolution.
non‐leaf object controller, a Delete operation deletes the
parent object.
Relative An Add or Move operation names a child The child object whose naming attribute has the larger version
distinguished object below a parent object. number in its stamp keeps its given name. The child object whose
name conflict Concurrently, at another domain relative distinguished name attribute (for example, CN for most
controller, an Add or Move operation objects, OU for organizational units, DC for domain components)
names a different child of the same parent has the smaller version number in its stamp is named by the
with the same child name, resulting in two following convention: At all domain controllers, a system‐assigned
child objects with identical relative value that is unique to the conflicting name and cannot conflict
distinguished name values below the same with any client‐assigned value is assigned to the child object. For
parent object. example, if the relative distinguished name of a child object was
“CN=ABC” before conflict resolution, its relative distinguished
name after resolution is “CN=ABC*CNF:<GUID>,” where “*”
represents a reserved character, “CNF” is a constant that
indicates a conflict resolution, and “<GUID>” represents a
printable representation of the objectGUID attribute value.

Preservation of Replication Metadata

On domain controllers running Windows Server 2003 with no service pack installed, replication metadata of the NTDS Settings
object is maintained by default after Active Directory is removed from a domain controller. The mechanism for preserving
replication metadata is disabled in Windows Server 2003 SP1.

How Replication Metadata is Preserved in Windows Server 2003

The period of time during which the replication metadata of the NTDS Settings object is maintained after Active Directory is
removed from the respective domain controller is determined by an attribute of the Directory Service object (cn=Directory
Service,cn=Windows NT,cn=Services,cn=Configuration,dc=ForestRootDomainName). This attribute,
replTopologyStayOfExecution, has a default value of 14 days and a maximum value of half the tombstone lifetime.

For example, if you set the tombstone lifetime to 30 days and the replTopologyStayOfExecution value to 20 days, the actual stay‐
of‐execution value is 15 days.

The root object of each directory partition replica has a multivalued attribute repsFrom that contains configuration and persistent
state information associated with inbound replication from each source replica of that directory partition. A destination domain
controller uses this information to poll source domain controllers for replication changes. The Knowledge Consistency Checker
(KCC) is the replication topology component that manages creation of connection objects. When the KCC detects a repsFrom
value with no corresponding connection object, as is the case when the NTDS Settings object has been deleted, the KCC checks the
tombstone for the NTDS Settings object for the time it was deleted and compares that time to the interval in
replTopologyStayOfExecution. If the NTDS Settings object has been deleted for a time that is equal to or greater than the value in
replTopologyStayOfExecution, then the KCC removes the repsFrom value and replication is no longer attempted with the deleted
server.

Prior to the stay‐of‐execution lifetime, you can see evidence of failed replication attempts in the Directory Service event log and in
the output of Windows Support tools such as Repadmin.exe. When replication attempts are from a server designated as
<unknown>, they are likely due to the stay‐of‐execution mechanism.

Disabled replTopologyStayOfExecution in Windows Server 2003 SP1

On domain controllers running Windows Server 2003 with SP1, the stay‐of‐execution mechanism is disabled so that replication
attempts do not continue after a domain controller is demoted. Without the repsFrom metadata, destination domain controllers
no longer poll for replication from the deleted source. Eliminating this mechanism ensures that computers attempting to
maliciously spoof the deleted domain controller cannot respond to polling for replication changes. However, if you provide a value
for replTopologyStayOfExecution, the stay‐of‐execution mechanism takes effect according to that value.
Replication of Linked and Nonlinked Attributes
Attributes are replicated differently depending on whether they are linked or nonlinked. Understanding the differences in how
these attributes operate is helpful to understanding their effect on replication.

Linked Attributes
A linked attribute represents an interobject, distinguished‐name reference. Linked attributes occur in pairs — forward link and
backward link (back‐link). The forward link is the linked attribute on the source object (for example, the member attribute on the
group object), while the backward link is the linked attribute on the target object (for example, the memberOf attribute on the
user object). A back‐link value on any object instance consists of the distinguished names of all the objects that have the object's
distinguished name set in their corresponding forward link. For example, manager and directReports are a pair of linked
attributes, where manager is the forward link and directReports is the back‐link. If Bill is Joe's manager and the distinguished
name of Bill's user object is stored in the manager attribute of Joe's user object, then the distinguished name of Joe's user object
appears in the directReports attribute of Bill's user object.

A linked attribute can have either single or multiple values. For example, the manager attribute identifies the distinguished name
of a single manager of the object or objects that are managed. The directReports attribute of a user object can have multiple
values of user names.

The relationships between linked attributes are stored in a separate table in the directory database as link pairs. The matching pair
of Link IDs (defined as any two numbers 2N and 2N+1) tie the attributes together. For example, the member attribute has a link ID
of 2 and the memberOf attribute has a link ID of 3. Because the member and the memberOf attributes are linked in the database
and indexed for searching, the directory can be examined for all records in which the link pair is member/memberOf and the
memberOf attribute identifies the group (for example, “What user objects have group X as a value in their memberOf
attribute?”).

Attributes are marked in the schema as being linked. Attributes with the distinguished name syntax Object(DS‐DN), Object(DN‐
String), or Object(DN‐Binary) can be linked, but not all such attributes are linked.

Nonlinked Attributes
Nonlinked, distinguished‐name attributes reference other objects in the same way as linked attributes do except that their
behaviour is different when a referred‐to object is deleted, as described in “Replication of Deletion Updates” later in this section.
In addition, nonlinked, multivalued attributes have an approximate limit of 1200 values (increased from the Windows 2000 Server
limit of approximately 800 values). This limit is based on an approximate maximum page size of 8 kilobytes. For attributes of this
maximum size, there are no storage or replication drawbacks or limitations.

USNs and Database Transactions

Originating and local USNs effectively identify the database transactions that record originating and replicated changes. Local
USNs represent a local database transaction. Therefore, local USNs that are the same represent the same database transaction.
For example, when two updates to the same object originate on different systems, they are assigned different originating GUIDs
and originating USN values. By definition, the local USN for each originating change is the same as the respective originating USN.
Then, these changes replicate to a third domain controller independently. The originating USNs stay the same, but the local USNs
now change to reflect the two separate transactions. When this set of changes replicates to a fourth domain controller, the two
changes travel together. When they are applied at the fourth system, the originating USNs are still different, but the local USNs
are now the same, reflecting their application in the same transaction.

Individual values of a multivalued attribute have slightly different rules. On origination, each unique value is assigned its own
originating USN. The values replicate out independently, in roughly increasing USN order; however, atomicity between values is
not guaranteed. When a set of values is applied on the destination domain controller, they are applied in batches to the same
object. The batch size is approximately 100 multivalues. Therefore, when they are written on the destination domain controller,
their originating USNs are still different, but the values on the same object, in groups of 100, have the same local USN.

Atomicity of Linked and Nonlinked Attributes

Atomicity is a guarantee by a database system that a grouping is applied in a single transaction. "Atomic" can be defined as
"indivisible." Atomicity of a transaction means that the transaction occurs in total, or not at all. This guarantee ensures that
objects are always in a complete state of either pre‐ or post‐update. Nothing in between is possible.
As evidenced by the application of the local USN, write transactions are performed according to the way replication data is
packaged and received. Rules that affect whether attribute values replicate together or separately differ for linked and nonlinked
attributes.
• Nonlinked attributes: All changes to nonlinked attributes of an object replicate together and are assigned the same local USN.
Therefore, they are committed to the database in the same write transaction.
• Linked attributes: Changes to linked attributes are not guaranteed to replicate together. Therefore, they are not guaranteed to
be written in the same database transaction.

The issue for an update transaction, then, is at what points in the replication stream the application of an update can be
interrupted and the effect of interruption on the end state. For inbound replication, the unit of transaction is the entire object for
nonlinked attributes. For linked attributes, the unit of transaction is the batch of values for the same object. Therefore, it is
possible for a replicated update to a single object that has linked values to occur in more than one transaction. However,
transactions to apply all updates to the same object are guaranteed to occur during the same replication cycle.

Atomicity provides the following assurances:

• Inferences can be based on the relationships of multiple attributes: If you always update attribute 1 and attribute 2 together
and you see attribute 1, you know that you can make a decision based on attribute 2.
• Even if the system crashes in the middle of applying the replicated update, the database system guarantees that all changes are
applied or that no changes are applied, and nothing in between.

Replication Order of Linked and Nonlinked Attribute Updates

To accommodate the guarantee that changes that are committed together on the originating domain controller appear in the
same write transaction on the destination domain controller, updates to nonlinked attributes are prioritized more highly than
updates to linked attributes. For this reason, although originating USNs are applied as they occur in order of the update and
outbound replication changes are assembled in this update order, nonlinked updates are packaged for transmission ahead of
linked updates. Therefore, when an object is updated and some of the updated attributes are linked and some are not linked, the
replication packet orders the nonlinked values first, splitting the order of values between linked and nonlinked. For example, if
two objects (obj1 and obj2) receive updates simultaneously to one linked attribute and one nonlinked attribute on each object,
the order of the attribute values in the replication data packet are as follows:
obj1.nonlinked; obj2.nonlinked; obj1.linked; obj2.linked

Now, suppose that the number of nonlinked changes is sufficiently large that the values fill an entire replication packet. When
both linked and nonlinked attributes are replicated, this scenario results in a set of changes that are made to one of the objects
spanning multiple replication packets. All nonlinked values for a single object are included in one packet, but linked values for the
same object can span multiple packets. Therefore, the write transaction at the destination can occur out of update order, and
replicated updates to a single object can require multiple transactions.

Transaction Order of Linked and Nonlinked Attribute Updates

For linked attributes, although objects are transmitted in increasing USN order, object transactions might be applied out of order
as a result of parent‐child relationships. This condition guarantees that object creation precedes the application of any links to that
object.

In addition, when the object already exists at the destination, although replication of nonlinked attributes occurs first, transaction
of nonlinked attribute updates before linked attribute updates is not guaranteed. However, nonlinked updates are generally
applied before linked updates at the destination.

For applications that depend on updates being written in update order, the prioritized implementation of replicated linked and
nonlinked attribute updates can occasionally result in unexpected behaviour.

Group Membership and Linked‐Value Replication

The replication of linked, multivalued attributes is especially important for group objects. Potentially, the linked, multivalued
member attribute of a group object can have thousands of values. Linked‐value replication in Windows Server 2003 enables
individual values to replicate separately. Linked‐value replication requires a forest functional level of Windows Server 2003 or
Windows Server 2003 interim. When it is in effect, linked‐value replication solves the problem of replication delays that are due to
the inability to write an entire member attribute in a single database transaction. Linked‐value replication also makes restoring
group membership back‐links possible when a user or group object is authoritatively restored.

Group Membership Replication in Windows 2000 Forests

Linked‐value replication is not available in Windows 2000 Server forests. Because an originating update must be written in a single
database transaction, and because the practical limit for a single transaction is 5,000 values, membership of more than
5,000 values is not supported in Windows 2000 Server Active Directory. A group of this size represents a limitation both in terms
of the database write operation that is required to record a change to an attribute of that size and the transfer of that much data
over the network.

These conditions have the following impacts on replication, most notably for group and distribution list objects:
• Lost changes: If values of the same multivalued attribute are updated on two different domain controllers during a period of
replication latency, the most recently changed replica of the attribute with all its multiple values is replicated and any earlier
changes are lost. Changes to the separate values are not merged.
Note
• Because all changes to an object must be written in the same database transaction, multiple changes to a single group
object can take a relatively long time to be written, which increases the likelihood of another change occurring to the
same object prior to the completion of the original write.
• Excessive network bandwidth consumption: For example, when one member is added to a group of 3,000 members, the
member attribute with all 3,001 values is transmitted between domain controllers. Transmission of all values to apply a change
to only the updated value or values is inefficient use of network resources.
These limitations are effectively removed in a forest that has a forest functional level of Windows Server 2003 or
Windows Server 2003 interim. At these levels, linked‐value replication accommodates replication of individually updated member
values.

Group Membership Replication in Windows Server 2003 Forests

In a Windows Server 2003 forest that has a forest functional level of Windows Server 2003 or Windows Server 2003 interim,
linked‐value replication provides the following benefits:
•
Removed likelihood of losing entire sets of changes to the same group membership made on different domain controllers.
• Greatly reduced likelihood of update collisions, where the same member value is changed on different domain controllers at
the same time and one update is lost.
• Improved network efficiency by transmitting only updated values and not the entire set of attribute values, which can include
many thousands of values.
Although replication of many thousands of individual membership updates can be accommodated in a Windows Server 2003
forest, LDAP writes have a practical limit of approximately 5,000 updates in a single transaction. Because originating updates are
required to complete in a single transaction, a practical limit of approximately 5,000 updates to a single object is recommended.
Note
• Only originating updates must be applied in the same database transaction. Replicated updates can be applied in more than
one database transaction.

Replication of Deletion Updates

Object deletions are replicated by replicating tombstones. After an object is deleted but before it is removed from the directory,
object references that formerly referred to the object now refer to the deleted object’s tombstone. The isDeleted attribute, which
has a value of TRUE when an object is a tombstone, indicates the object deletion to other domain controllers. Deleted objects are
stored in the Deleted Objects hidden container. Every directory partition has a Deleted Objects container.
Note
• Objects are moved to the Deleted Objects container according to system flags. Certain protected configuration objects, such as
NTDS Settings, do not move to the Deleted Objects container when they are deleted. In addition, dynamic objects that are
deleted are removed from Active Directory according to a Time‐to‐Live (TTL) setting. They are not moved to the Deleted
Objects container as tombstones. DNS resource records that are removed by scavenging are also not stored as tombstones
when DNS is Active Directory–integrated. For more information about storage of object deletions and dynamic data, see
"Storage and Removal of Object Deletions" and "Dynamic Data," respectively, in How the Data Store Works. For more
information about how DNS data is removed from Active Directory, see "Understanding Aging and Scavenging" in How DNS
Works.
By default, tombstones have a lifetime of 60 days (180 days in a forest that was created on a server running Windows Server 2003
with SP1), after which they are permanently removed from the directory database through a process called garbage collection.
The tombstone lifetime can be changed, but it is important to ensure that the tombstone lifetime is larger than the worst possible
replication latency for any directory partition so that a tombstone cannot be deleted before it has replicated to every directory
partition replica. In addition, Active Directory does not allow data to be restored from a backup image that is older than the
tombstone lifetime.
Note
• A tombstone is invisible to normal LDAP searches. However, a tombstone is visible to searches that use the special LDAP control
1.2.840.113556.1.4.417.

Effect of Deletion on Linked Values

When an object is deleted, two types of automatic cleanup occur with regard to linked values:
• All of the forward links that are held by the deleted object are removed; that is, if a group object is deleted, all of the member
links on the group object are removed. The target of each link (for example, the user object that is named in the member
attribute) is not affected by the removal of the group and its forward link, except that its memberOf back‐link attribute loses
the value that corresponds to the deleted group.
• All the back‐links that are held by the deleted object are removed; that is, if a user is deleted, its back‐links include all the group
objects that have forward links to the user object. For example, if a user is a member of multiple groups and the user is deleted,
the user's distinguished name value is removed from the member attributes of each group object that is named in the
memberOf attribute of the deleted user. The group object is not changed in any way other than its membership.
During replication, if a linked value replicates to a domain controller, the linked value is silently dropped (that is, it disappears
from the database with no history) under the following conditions:
•
The forward link holder object that is referenced by the link value has been deleted.
•
The backward link holder that is referenced by the link value (the target of the back‐link) has been deleted.
When a target and source object are authoritatively restored together on a domain controller running Windows Server 2003,
whether the links are restored on the destination domain controller depends on which restored object replicates out first:
• If the restored group object replicates to a destination domain controller before the restored user object, the group
membership of the user is not restored because the user object does not exist on the destination.
• If the user object replicates out ahead of the group object and if the functional level of the forest was Windows Server 2003 or
Windows Server 2003 interim when the back‐link was created (that is, when the user was added to the group), the group
 membership of the user is restored in the member and memberOf attributes on the respective objects.

Replication of Absent Linked Object References

A different condition occurs when the object that the link refers to is simply removed as a referent, as it is when a user is removed
from a group.

In a Windows 2000 forest, this condition results in replication of the entire linked attribute. In a forest with a functional level of
Windows Server 2003 or Windows Server 2003 interim, this condition is replicated on a per‐value basis. For example, if a user is
removed from a group, the user value in the member attribute is marked “absent” in the database so that its condition can be
replicated, much like a tombstone.

The deletion of the user object from the group replicates as an absent value in the member attribute of the group. After a
tombstone lifetime, absent values are physically removed from the database. Until that time, the link value remains in the
database. Such absent values can be restored prior to the end of the tombstone lifetime. If you add the user back to the group
prior to the end of a tombstone lifetime, the link value is restored in the database by the value being marked "present."

Deleting Group Objects in a Windows Server 2003 Forest

In a forest that has a forest functional level of Windows Server 2003 or Windows Server 2003 interim, you can delete a group
object of any size and its multivalued member attribute values are cleaned up in the background. For this reason, it is not required
for the deletion to complete in one transaction, as it is in a Windows 2000 forest. However, if you delete more than
5,000 members in the same transaction without deleting the group itself, the same long‐running transaction conditions can occur
as described in “Group Membership Replication in Windows 2000 Forests” earlier in this section.
Therefore, if you must add, modify, or delete more than 5,000 members of the same group, do so in blocks of less than
5,000 members to avoid long‐running transactions and excessive network bandwidth consumption.

Deletions on Nonreplicating Domain Controllers

If a domain controller fails to replicate for a number of days that exceeds the tombstone lifetime, replicas of objects that have
been deleted from a writable partition might remain in that domain controller’s directory. Because the tombstones of the deleted
objects are permanently removed from the directory at the end of the tombstone lifetime, a domain controller that fails to
replicate changes for tombstoned objects never deletes them.
This condition can occur for a variety of reasons, including:
• Prolonged misconfigurations.
• Prolonged errors in name resolution, authentication, or the replication engine that block inbound replication.
• Turning on a domain controller that has been offline for longer than the tombstone lifetime.
• Advancing system time or reducing tombstone lifetime values in an attempt to accelerate garbage collection before end‐to‐end
replication has taken place for all directory partitions in the forest.
The condition of outdated objects can also occur due to hardware and software problems that render the domain controller
unreachable. Regardless of the reason, a deleted object can remain on a domain controller any time the domain controller goes
offline before receiving a deletion and remains offline for longer than the tombstone lifetime of that deletion.
These outdated objects, called lingering objects, create inconsistency in the directory. If a change is made to an outdated object
on the reconnected domain controller, it is possible for the object to be recreated in the directory under certain conditions. To
avoid this situation, replication of an outdated object is prohibited by default in newly created Windows Server 2003 forests.

Backup Latency Interval

On domain controllers running Windows Server 2003 with SP1, a new NTDS Replication event provides a warning to
administrators when a domain controller has not been backed up. Event ID 2089 provides the backup status of each directory
partition that a domain controller stores, including application directory partitions. Specifically, event ID 2089 is logged in the
Directory Service event log when partitions in the Active Directory forest are not backed up within a backup latency interval. The
value for the backup latency interval is stored as a REG_DWORD value in the Backup Latency Threshold (days) entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
By default, the value of Backup Latency Threshold (days) is half the value of the tombstone lifetime of the forest. If halfway
through the tombstone lifetime a directory partition has not been backed up, event ID 2089 is logged in the Directory Service
event log and continues daily until the directory partition is backed up.
This event serves as a warning to administrators and monitoring applications to make sure that domain controllers are backed up
before the tombstone lifetime expires. However, it is recommended that you take backups at a much higher frequency than the
default value of Backup Latency Threshold (days).

Replication Consistency Setting

If the attributes on a lingering object never change, the object is never considered for replication. However, if an attribute
changes, the attribute is considered for outbound replication. Because the destination domain controller does not hold the object
for the attribute that is being replicated, an update cannot be performed. How this condition is resolved depends on the
replication consistency setting on the domain controller.

A registry setting on domain controllers that are running Windows Server 2003 or Windows 2000 Server with SP3 provides a
consistency value that determines whether a domain controller replicates and reanimates an updated object that has been
deleted from all other replicas, or whether replication of such objects is blocked. The default settings are different on domain
controllers that are running Windows 2000 Server with SP3 and Windows Server 2003.

Strict Replication Consistency

To avoid problems with reanimating objects that have been deleted, a domain controller that is running Windows Server 2003 in a
newly created (not upgraded) Windows Server 2003 forest blocks inbound replication by default when it receives an update to an
object that it does not have.
Note
• Active Directory replication uses update tracking to differentiate between replicating a newly created object and updating an
attribute for an existing object. Replication of a lingering object is an attempt to update an attribute or attributes of an object
that the destination domain controller cannot update because the object does not exist.
Replication is halted in the directory partition for the object until the lingering object is removed from the source domain
controller or the strict replication consistency setting is disabled.

Loose Replication Consistency

When strict replication consistency is disabled, the effect is called “loose” consistency. By using “loose” consistency, the
destination domain controller detects that it does not have the object for the attribute that is being replicated. The destination
domain controller requests the entire object from the source partner, and thereby reanimates the object in its copy of the
directory. The same process repeats on all domain controllers that do not have a copy of the object.

This mechanism can be used to cause lingering objects to be reanimated across the entire forest. If a lingering object is discovered
and its presence is intended, then perform any update to the object. As long as replication consistency is set to loose (strict
replication consistency is disabled) on all domain controllers, the object will be reanimated as it replicates around the forest.
Loose replication consistency is the default setting for domain controllers that are running Windows 2000 Server with SP3 or later.
The Windows 2000 Server default is not changed by upgrading to Windows Server 2003; strict replication consistency remains
disabled and replication is allowed to proceed. Keeping the Windows 2000 Server setting is required to ensure that the upgraded
domain and forest are consistent with Windows 2000 Server functionality. You must change the setting manually following the
upgrade.

Storage for Consistency Setting

The setting for replication consistency is in the registry on each domain controller.
The value for the consistency setting is stored in the Strict Replication Consistency entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
The values are as follows:
• Value: 1 (Set to 0 to disable)
• Default: 1 (enabled) in a new Windows Server 2003 forest, otherwise 0.
• Data type: REG_DWORD
Note
• Having Strict Replication Consistency set to 0 or unset is equivalent to the Windows 2000 Server setting applied by the Correct
Missing Objects registry entry. However, the semantics for Correct Missing Objects are the opposite of Strict Replication
Consistency: Correct Missing Objects=1 is equivalent to Strict Replication Consistency=0 or unset.

Lingering Object Removal

On domain controllers that are running Windows Server 2003, you can use Repadmin to analyze and remove lingering objects
from a domain controller that you suspect or know has not replicated for a tombstone lifetime or longer. If strict replication
consistency is in effect and replication fails on the destination domain controller, event ID 1988 is logged in the Directory Service
event log on the destination domain controller. Event ID 1988 indicates that the local domain controller has attempted to
replicate an object from the source domain controller and the object is not present on the local domain controller because it
might have been deleted and its tombstone already garbage collected. Event ID 1988 provides the GUID‐based distinguished name
of the source domain controller as well as the distinguished name and GUID of the outdated object. Replication of the directory
partition containing the outdated object does not continue with the source domain controller until the situation has been
resolved.
In this event, you can use an up‐to‐date domain controller as the authority against which to compare the objects on the source
replication partner suspected of harboring lingering objects. This domain controller acts as the authoritative directory replica to
reveal outdated objects in the suspect directory database on the destination.
In the Repadmin command‐line arguments that remove lingering objects, the roles of source and destination are switched. The
repadmin /removelingeringobjects command compares the directories of two domain controllers, as follows:
• A “source” domain controller that you designate as the authoritative reference server.
• A “destination” domain controller, which is the source replication partner that has attempted to replicate an outdated object.
To use the repadmin /removelingeringobjects command, both source and destination domain controllers must be running
Windows Server 2003.
If the comparison reveals any mismatched objects, Repadmin either displays or removes the objects that are found on the
destination but not on the source, depending on the arguments that you use. The advisory mode argument allows you to view the
results of the command before you take action to remove any objects from the directory.
Repadmin /RemoveLingeringObjects Command Syntax
The command repadmin /removelingeringobjects has the following syntax:
/removelingeringobjects <Dest_DC_LIST> <Source DC GUID> <NC> [/ADVISORY_MODE]
where
• <Dest_DC_List> is the DNS or NetBIOS name of one or more domain controllers that you suspect of harboring lingering objects.
<DC_List> provides the ability to target specific domain controllers, such as all domain controllers in a site, all global catalog
servers, or domain controllers that hold specific operations master roles. To see the syntax for DC_List, type repadmin /listhelp
at the command prompt.
• <Source DC GUID> is the GUID you obtained by running repadmin /showrepl against the source domain controller that you are
using as the authoritative server.
•
<NC> is the distinguished name of the directory partition that contains the lingering object.
• [/ADVISORY_MODE] is an optional switch that specifies that no deletions are performed on the destination domain controller,
but are displayed (logged) only. Using this switch is recommended prior to allowing Repadmin to remove any objects.
To use this command, you must first obtain the GUID of the authoritative source domain controller by running repadmin
/showrepl <source_server>, where <source_server> is the name of the domain controller that has a writable copy of the directory
partition that will serve as the authoritative replica. The output of this command provides the “DC GUID,” which the
/removelingeringobjects command requires to identify the authoritative source.

RemoveLingeringObjects Implementation
When you run repadmin /removelingeringobjects, the tool performs the following steps to compare the directories of the source
and destination domain controllers and log (or remove) any found lingering objects:
1. Check to ensure that the directory partition and the source domain controller are valid.
2. Verify that the user has the DS‐Replication‐Manage‐Topology extended right on the directory partition container object
specified in <NC>. This extended right is required to verify object state between two domain controllers. Members of the
Domain Admins group have this right by default.
3. Ensure that both source and destination use the same objects for comparison by merging the up‐to‐dateness vectors to filter
out any objects that have not replicated from the source to the destination or from the destination to the source. This check
rules out a lingering object on the destination if the destination has not received the tombstone from the source, and vice
versa. Any such nonreplicated objects are removed from the comparison.
4. Create the list of object GUIDs for each domain controller to be compared. Examine the metadata of each object and use the
merged up‐to‐dateness vector to determine whether the object should be present on both source and destination.
5. For each GUID that is in the list for the destination, determine if it is in the list of GUIDs for the source.
6. If a GUID is not found on the source, the object is identified to be outdated on the destination and is either displayed or
deleted on the destination server. If advisory mode has been specified, the GUID is displayed only.

Active Directory Replication on a Restored Domain Controller

All domain controllers must be backed up routinely to ensure directory integrity. In case of failure on a domain controller, the
backup media can be used to restore the domain controller to its state at the time of the backup. When a domain controller is
restored from a backup, it can then be brought up‐to‐date by normal replication.
There are two general methods for restoring Active Directory from backup media, each of which has different replication
consequences:
• Nonauthoritative restore. Replication brings the domain controller up‐to‐date from its state at the time of backup, including
updating deletions that have occurred since the time of the backup.
• Authoritative restore. Objects that were deleted can be reinstated.

Nonauthoritative Restore
Nonauthoritative restore is the default method of performing a restore of Active Directory, and it is used in the majority of restore
situations, such as domain controller hard disk failure. Nonauthoritative restore is performed by using the backup tool that you
used to create the backup file. A nonauthoritative restore returns Active Directory on the domain controller to a state that is
consistent with the time that the backup was taken. When the domain controller restarts following the restore process, it requests
changes from its replication partners. Through the normal replication process, the restored domain controller receives any
directory changes that have occurred since the time of the backup.
Because the restore process does not restore any previously deleted data to Active Directory, it is described as nonauthoritative.
The following example illustrates the process of replication between a set of domain controllers before and after nonauthoritative
restore, including the metadata changes that determine the effect of the restore operation. In this example, three domain
controllers (DC1, DC2, and DC3) exist as part of the Active Directory replication topology. The scenario includes the following
steps:
Step 1
Prior to backup, DC1 maintains replication information about itself and its replication partners:
• Its own invocation ID (database GUID)
• Highest USN that it has committed for changes to the local database.
• Replication metadata for its two replication partners, DC2 and DC3:
• Invocation ID of the local Active Directory database of each domain controller.
• The up‐to‐dateness vector, as shown in the table below.
Step 2
Some changes have been made to the Active Directory database on DC1 since Step 1, which result in advancing the current USN
on DC1 to 35. At this point, DC1 is backed up.
Step 3
A total of 14 additional change changes have been made to the local Active Directory database on DC1, advancing the highest
committed USN on DC1 to 49. DC1 now begins replicating these changes to DC2. After replicating 12 of the 14 changes to DC2,
DC1 becomes unavailable due to hard drive corruption. As a result, DC2 has USN 47 as the last change it received from DC1. At this
point, the up‐to‐dateness vector on DC2 shows a highest committed USN of 47 for DC1.
Step 4
A nonauthoritative restore has been completed and DC1 is restarted. During the restore process a new invocation ID has been
assigned to the local Active Directory database on DC1. For replication purposes, DC1 adds its old invocation ID (GUID1) and
highest committed USN of 35 to its up‐to‐dateness vector, effectively restoring it to its state as of Step 2.
Step 5
DC1 replicates in the 12 changes that were saved to DC2 before the restore (which corresponds to Step 3 in the following table).
The last two changes that occurred as originating updates on DC1 prior to going offline are lost.

DC1 Replication Metadata Values Pre‐ and Post‐Nonauthoritative Restore

Step 3: Offline
Step 1: Prior Step2: Immediately Step 4: Immediately Step 5: After post‐
status before
to backup post‐backup post‐Restore restore replication
restore

Invocation ID of DC1‐GUID1 DC1‐GUID1 DC1‐GUID1 DC1‐GUID4 DC1‐GUID4

DC1
Highest committed 20 35 49 35 47
USN on DC1
Up‐to‐dateness DC2‐GUID2, DC2‐GUID2, USN=25; DC2‐GUID2, DC2‐GUID2, USN=25; DC2‐GUID2, USN=37;
vector on DC1 USN=10; DC3‐GUID3, USN=60 USN=37; DC3‐GUID3, USN=60; DC3‐GUID3, USN=60;
DC3‐GUID3, DC3‐GUID3, USN=60 DC1‐GUID1, USN=35 DC1‐GUID1, USN=47
USN=45

Authoritative Restore
The primary purpose of an authoritative restore is to reinstate objects that were deleted from Active Directory. To reinstate
objects that were intentionally or accidentally deleted, a nonauthoritative restore must be completed and followed by an
authoritative restore. Authoritative restore is performed by using Ntdsutil.exe.
The nonauthoritative restore process cannot reinstate deleted objects from a backup image because the backup media that was
used to restore the domain controller contains an image of Active Directory that was created before the objects were deleted. In
this case, the deletions would simply be replicated in from the up‐to‐date replication partner and applied by the restored domain
controller. To reinstate a deleted object, an authoritative restore is required.
The authoritative restore process works as follows:
1. The domain controller is restarted in Directory Services Restore Mode, and a nonauthoritative restore of Active Directory is
performed by using backup media that was created before the object was deleted.
2. Following the nonauthoritative restore but prior to restarting, the object metadata is altered by Ntdsutil.exe so that it has a
higher USN than any other possible version of the object (by default, the version number is increased by 100,000). The effect
is to render the object or objects as authoritative and reinstates them in Active Directory.
The authoritative restore process does not affect objects that were created after the backup was created.
Note
• Only the domain and configuration directory partitions can be marked as authoritative. The schema directory partition cannot
be authoritatively restored.

Restoring Back‐links for Authoritatively Restored Objects

When authoritative restore is performed on domain controllers running Windows Server 2000, the procedure recovers objects
that have been deleted, but it does not restore the back‐links for any objects that have linked attributes. The effect of not
restoring back‐links for the restored objects is particularly problematic for group memberships, which must be restored manually.
In a forest that has a forest functional level of Windows Server 2003 or Windows Server 2003 interim, the procedure for
performing authoritative restore automatically restores back‐links for multivalued, linked attributes. For example, the member
attribute of groups to which a restored user object belongs are updated. This restoration applies to only those links that were
created after the functional level was raised. For example, if you added a user to a group before raising the forest functional level,
the user's membership in that group is not restored if you delete the user and then authoritatively restore the user. Automatic
restore of back‐links requires the raised forest functional level because link restoration is made possible by linked‐value
replication.
Restoring Back‐links Created Before Linked‐Value Replication
An updated version of Ntdsutil that is included with Windows Server 2003 SP1 makes it possible to also restore back‐links that
were created before implementation of linked‐value replication. On domain controllers that have this updated version of Ntdsutil,
the authoritative restore option generates an LDAP Data Interchange Format (LDIF) file that can be used to restore any back‐links
that are not restored automatically. In addition, Ntdsutil generates a text file that you can use to create an LDIF file for restoring
back‐links for groups in other domains. The LDIF file can be used to restore back‐links on domain controllers running
Windows 2000 Server or Windows Server 2003, and it does not depend on forest functional level. This method also resolves the
problem of links not being restored if linked user and group objects are authoritatively restored together and the restored group
object replicates out before the restored user object. For more information about restoring back‐links, see "Managing Active
Directory Backup and Restore" in the Active Directory Operations Guide.

Domain Controller Notification of Changes

Replication within a site occurs as a response to changes. On its NTDS Settings object, the source domain controller stores a
repsTo attribute that lists all servers in the same site that pull replication from it. When a change occurs on a source domain
controller, it notifies its destination replication partner, prompting the destination domain controller to request the changes from
the source domain controller. The source domain controller either responds to the change request with a replication operation or
places the request in a queue if requests are already pending. Replication occurs one request at a time until all requests in the
queue are processed.
Note:
Replication between sites occurs according to a schedule, where the destination requests changes at the specified time. By
default, change notification is not enabled on site links.

Notification Delay Values

When a change occurs on a domain controller within a site, two configurable intervals determine the delay between the change
and subsequent events:
• Initial notification delay. The delay between the change to an attribute and notification of the first partner. This interval serves
to stagger network traffic caused by intrasite replication. When a domain controller makes a change (originating or replicated)
to a directory partition, it starts the timer for the interval; when the timer expires, the domain controller begins to notify its
replication partners (for that directory partition and within its site) that it has changes.
• Subsequent notification delay. The delay between notification of the first partner and notification of each subsequent partner.
A domain controller does not notify all of its replication partners at one time. By delaying between notifications, the domain
controller distributes the load of responding to replication requests from its partners.
The storage location and default values for the initial and subsequent notification delay intervals vary depending on the version of
the operating system (Windows Server 2003 or Windows 2000 Server) that is running on the domain controller and whether the
domain controller has been upgraded. Application of notification delay values is also potentially affected by their default status
and by the forest functional level.

Storage of Intrasite Notification Delay Values

On a domain controller that is running Windows Server 2003, intrasite notification delay values are specific to each directory
partition and are stored in two attributes of the cross‐reference object for each directory partition.

Windows Server 2003 Storage of Notification Delay Values

On domain controllers that are running Windows Server 2003, the attributes that store the change notification values are located
on each cross‐reference object in the Partitions container within the configuration directory partition:
• The value for initial change notification delay is stored in the msDS‐Replication‐Notify‐First‐DSA‐Delay attribute.
The default value is 15 seconds.
• The value for subsequent notification delay is stored in the msDS‐Replication‐Notify‐Subsequent‐DSA‐Delay attribute.
The default value is 3 seconds.
These attributes do not exist in Windows 2000 Server.
Although the attribute values are present on all domain controllers that are running Windows Server 2003, the default values of
15 seconds for initial notification delay and 3 seconds for subsequent notification delay are in effect only under the conditions
described in “Application of Notification Delay Values by Domain Controllers” later in this section.

Windows 2000 Server Storage of Notification Delay Values

On domain controllers that are running Windows 2000 Server, intrasite notification delay values affect all directory partitions and
are stored in registry entries on each domain controller. The registry entries are as follows:
• The value for the delay before the first change notification is stored in the Replicator notify pause after modify (secs) entry in
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
The default value is 300 seconds.
• The value for the delay before each subsequent change notification is stored in the Replicator notify pause between DSAs
(secs) entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters.
The default value is 30 seconds.
Effect of Upgrade and Forest Functional Level on Registry Notification Delay Values
Notification delay values for first and subsequent change notification are preserved as registry settings during upgrades from
Windows 2000 Server to Windows Server 2003.
Raising the forest functional level to Windows Server 2003 Interim or Windows Server 2003 affects notification delay values for
first and subsequent change notification, as follows:
• If a registry entry has the Windows 2000 Server default value of 300 seconds for initial notification delay or 30 seconds for
subsequent notification delay at the time the forest functional level is raised, the registry entry that has the default value is
removed and the Windows Server 2003 default value takes effect on the respective attribute of each cross‐reference object.
• If a registry entry has a nondefault value, the registry value is preserved.
Note:
One or both notification delay registry entries can be added to the registry to override the cross‐reference values, if needed, to
control notification by a specific domain controller running Windows Server 2003.

Application of Notification Delay Values by Domain Controllers

To accommodate both the registry and cross‐reference object locations of notification delay information, the process that is used
to determine which change notification delay values to apply favors the settings in the registry if any exist. When replication
partners send notification of changes, notification delay values are checked according to the operating systems that are running
on the partners, as follows:
• Windows Server 2003 only:
• Check the registry for the presence of initial and subsequent notification delay values and use those values if they exist.
• If no registry values exist, check the cross‐reference object for the directory partition to which the change has occurred. If
values are set, use those values.
• Otherwise, use the default values of 15 seconds for initial notification delay and 3 seconds for subsequent notification
delay.
• Windows Server 2003 and Windows 2000 Server:
• Check the registry for the presence of registry values. If a value is set for an entry, use the value that is set for all relevant
directory partitions.
• If no value is set on a registry entry (the default is in effect), use the respective default values of 300 seconds for initial
notification delay and 30 seconds for subsequent notification delay.

Identifying and Locating Replication Partners

Replication occurs in one direction between two domain controllers at a time. The replication topology determines the replication
partnerships between source and destination domain controllers. As a replication source, the domain controller must determine
the replication partners it must notify when changes occur. As a replication destination, the domain controller participates in
replication either by responding to notification of changes from a source, or by requesting changes to initiate replication when it
starts up or in response to a schedule.

Destination Identification of Source Replication Partners

When the KCC creates the replication topology, it creates connection objects on destination domain controllers that represent the
inbound connection from the replication source domain controller. For each source domain controller that is represented by an
inbound connection object, the KCC writes information to the repsFrom attribute of the directory partition object for each
directory partition that the destination domain controller has in common with the source domain controller. This information is
local to the destination domain controller and is not replicated. For a destination domain controller, the repsFrom attribute
contains the following information about each source domain controller:
• Directory partition name.
• NTDS Settings object distinguished name.
• GUID‐based DNS name (CNAME alias).
• Whether replication is intrasite, intersite using IP (RPC), or intersite using SMTP.
• Flags that govern the options, which indicate whether notification is allowed (no value is present) or not allowed
(NEVER_NOTIFY is present).
• Invocation ID, for the purpose of detecting a change due to a restore from backup.
• Direct USN vector (high‐watermark), which is the USN pair of object USN (OU) and property USN (PU).
• Time of last attempt and time of last success.
• Last error code.
• Count of consecutive failures, if any.
If notification is enabled on the destination domain controller, the destination responds to notification messages from source
domain controllers by sending a request for changes. If notification is not enabled, the destination responds to notification
requests with an error.

Notification is enabled on a destination domain controller except under the following conditions, in which the KCC sets the option
NEVER_NOTIFY in repsFrom:
• The connection object that the KCC creates is inbound from a server in a different site. Such a destination is designated as a
bridgehead server for the directory partition. Bridgehead servers pull replication according to a schedule on the site link object.
• The connection object is created to identify the source from which this domain controller replicates to add Active Directory as a
new domain controller.

Source Identification of Destination Replication Partners

The source domain controller keeps track of the replication partners that pull changes from it and uses the information to locate
partners for change notification. This information is not provided by the KCC, but rather by the source domain controller itself
during a replication cycle. The first time a domain controller receives a request for changes from a new destination, the source
creates an entry for the destination in the repsTo attribute on the respective directory partition object.
Whenever the source has changes, it sends a notification to all replication partners that are identified in the repsTo value for the
respective directory partition. Like the repsFrom data, this information is stored locally on the domain controller and is not
replicated. When updates occur, the source domain controller checks the repsTo attribute to determine the identities of its
destination replication partners. The source domain controller notifies them one by one that changes are available.
Note
• The output of the command repadmin /showrepl /v /all shows the contents of the repsFrom value (INBOUND NEIGHBORS)
and the repsTo value (OUTBOUND NEIGHBORS).
If a destination domain controller has the NEVER_NOTIFY option set, the destination responds to a notification message with an
error. When the error is received by the source domain controller, it removes the entry for that destination from its repsTo data.
If a destination domain controller moves to a different site, the KCC adjusts the notify setting to indicate that notification is not
needed.

Locating Replication Partners

The partner that initiates replication locates its partner by querying DNS to look up the IP address of the partner according to the
GUID of the NTDS Settings object (class nTDSDSA). The NTDS Settings object represents the directory system agent (DSA) on the
domain controller. Its GUID uniquely identifies the domain controller and is guaranteed to find the correct server, even if the
name of the server has been changed.
The GUID of the NTDS Settings object is stored in the objectGUID attribute. The DSA GUID is created when Active Directory is
installed on the domain controller, and is destroyed only if Active Directory is removed from the domain controller to create a
member server.
Note
• The Active Directory database also has a GUID, which is used by the DSA to identify the specific versions of the database when a
database has been restored. This GUID is stored in the invocationId attribute on the NTDS Settings object.
As part of the DNS registration process, the Net Logon service on every domain controller registers a canonical name (CNAME)
resource record, or alias record, which is constructed using the DSA GUID as the alias and maps to the DNS fully qualified domain
name (FQDN) of the respective domain controller. The format of CNAME alias is:
DsaGuid._msdcs.DNSForestName.
To initiate replication, the domain controller retrieves the GUID‐based DNS name that is stored in repsTo (for a source domain
controller that is sending a change notification) and repsFrom (for a destination domain controller that is initiating replication) and
queries DNS for the CNAME resource record. DNS responds by returning both the CNAME resource record and the A resource
record, which contains the IP address of the destination domain controller. The domain controller uses information in the CNAME
resource record to authenticate to the replication partner. Therefore, by using the CNAME and A resource record data, the
domain controller can initiate replication.
Note
• The _msdcs.DnsForestName DNS zone contains a variety of forest‐wide service (SRV) resource records that are used to locate
special servers, such as domain controllers and global catalog servers, and to facilitate replication. In the context of this
discussion, it is important to note that if a DNS server that is authoritative for the _msdcs.DnsForestName zone is not available,
replication between domain controllers cannot occur.

Urgent Replication
Certain important events trigger replication immediately, overriding existing change notification. Urgent replication is
implemented immediately by using RPC/IP to notify replication partners that changes have occurred on a source domain
controller. Urgent replication uses regular change notification between destination and source domain controller pairs that
otherwise use change notification, but notification is sent immediately in response to urgent events instead of waiting the default
period of 15 seconds (or 300 seconds on domain controllers that are running Windows 2000).

Events That Trigger Urgent Replication

Urgent Active Directory replication is always triggered by certain events on all domain controllers within the same site. When you
have enabled change notification between sites, these triggering events also replicate immediately between sites.
Between Windows Server 2003–based and Windows 2000–based domain controllers in the same site, immediate notification is
caused by the following events:
• Assigning an account lockout, which a domain controller performs to prohibit a user from logging on after a certain number of
failed attempts.
• Changing the account lockout policy.
• Changing the domain password policy.
• Changing a Local Security Authority (LSA) secret, which is a secure form in which private data is stored by the LSA (for example,
 the password for a trust relationship).
• Changing the password on a domain controller computer account.
• Changing the relative identifier (known as a “RID”) master role owner, which is the single domain controller in a domain that
assigns relative identifiers to all domain controllers in that domain.

Urgent Replication of Account Lockout Changes

Account lockout is a security feature that sets a limit on the number of failed authentication attempts that are allowed before the
account is “locked out” from a further attempt to log on, in addition to a time limit for how long the lockout is in effect.
The PDC emulator receives urgent replication of account lockouts. In Active Directory domains, a single domain controller in each
domain holds the role of PDC emulator, which simulates the behaviour of a Windows NT version 3.x–based or Windows NT 4.0–
based PDC. In Windows NT domains, the only domain controller that can accept updates is the PDC. If authentication fails at a
BDC, the authentication request is passed immediately to the PDC, which is guaranteed to have the current password.
An account lockout is urgently replicated to the PDC emulator and is then urgently replicated to the following:
• Domain controllers in the same domain that are located in the same site as the PDC emulator.
• Domain controllers in the same domain that are located in the same site as the domain controller that handled the account
lockout.
• Domain controllers in the same domain that are located in sites that have been configured to allow change notification
between sites (and, therefore, urgent replication) with the site that contains the PDC emulator or with the site where the
account lockout was handled. These sites include any site that is included in the same site link as the site that contains the PDC
emulator or in the same site link as the site that contains the domain controller that handled the account lockout.
In addition, when authentication fails at a domain controller other than the PDC emulator, the authentication is retried at the PDC
emulator. For this reason, the PDC emulator locks the account before the domain controller that handled the failed‐password
attempt if the bad‐password‐attempt threshold is reached.
Note
• When a bad password is used in an attempt to change a password, the lockout count is incremented on that domain controller
only and is not replicated. As such, an attacker could try (of domain controllers)*(lockout threshold ‐1) + 1 guesses before the
account is locked out. Although this scenario has a relatively small impact on account lockout security, domains with an
exceptionally high number of domain controllers represent a significant increase in the total number of guesses available to an
attacker. Because a user cannot specify the domain controller on which the password change is attempted, an attack of this
type requires an advanced tool.

Replication of Password Changes

Password changes are replicated differently than both normal (non‐urgent) replication and urgent replication. Changes to security
account passwords present a replication latency problem wherein a user’s password is changed on domain controller A and the
user subsequently attempts to log on, being authenticated by domain controller B. If the password has not replicated from A to B,
the attempt to log on fails. Active Directory replication remedies this situation by forwarding password changes immediately to a
single domain controller in the domain, the PDC emulator.
In Active Directory, when a user password is changed at a domain controller, that domain controller attempts to update the
respective replica at the domain controller that holds the PDC emulator role. Update of the PDC emulator occurs immediately,
without respect to schedules on site links. The updated password is propagated to other domain controllers by normal replication
within a site.
When the user logs on to a domain and is authenticated by a domain controller that does not have the updated password, the
domain controller refers to the PDC emulator to check the credentials of the user name and password rather than denying
authentication based on an invalid password. Therefore, the user can log on successfully even when the authenticating domain
controller has not yet received the updated password. On domain controllers that are running Windows Server 2003 or
Windows 2000 Server with SP4, if the authentication is successful at the PDC emulator, the PDC emulator replicates the password
immediately to the requesting domain controller to prevent that domain controller from having to check the PDC emulator again.
If the update at the PDC emulator fails for any reason, the password change is replicated non‐urgently by normal replication.
For clients that are running Windows NT 4.0 or clients that are running Windows 95 or Windows 98 without the Directory Service
Client Pack, the client attempts to contact the PDC emulator. If the client has the Directory Service Client Pack installed, the client
contacts any domain controller and the contacted domain controller then attempts to contact the PDC emulator.
Note
• The Group Policy setting “Contact PDC on logon failure” can be disabled to keep a domain controller from contacting the PDC
emulator if the PDC emulator role owner is not in the current site. If this setting is disabled, the password change reaches the
PDC emulator non‐urgently through normal replication.
Network Ports Used by Active Directory Replication
By default, RPC‐based replication uses dynamic port mapping. When connecting to an RPC endpoint during Active Directory
replication, the RPC run time on the client contacts the RPC endpoint mapper on the server at a well‐known port (port 135). The
server queries the RPC endpoint mapper on this port to determine what port has been assigned for Active Directory replication on
the server. This query occurs whether the port assignment is dynamic (the default) or fixed. The client never needs to know which
port to use for Active Directory replication.
Note
• An endpoint comprises the protocol, local address, and port address.
In addition to the dynamic port 135, other ports that are required for replication to occur are listed in the following table.
Port Assignments for Active Directory Replication
Service Name UDP TCP

LDAP 389 389

LDAP 636 (Secure Sockets Layer [SSL])
LDAP 3268 (global catalog)
Kerberos 88 88
DNS 53 53
SMB over IP 445 445
Replication within a domain also requires File Replication service (FRS) using a dynamic RPC port.

Active Directory Replication Tools

The following tools are associated with Active Directory replication.

Dssite.msc: Active Directory Sites and Services

Category
Active Directory Administrative Tools Microsoft Management Console (MMC) snap‐in. This tool is installed automatically when
you install Active Directory, and is available on the Start menu under Programs\Administrative Tools. This tool also ships with the
Administration Tools Pack (Adminpak.msi).
Version compatibility
Active Directory Sites and Services runs on domain controllers that are running Windows Server 2003 and Windows 2000 Server.
On administrative workstations that are running Windows XP Professional with Service Pack 1, you can install the Windows
Server 2003 Administration Tools Pack (Adminpak.msi) from the i386 directory on the Windows Server 2003 operating system CD.
This version of the Administration Tools Pack encrypts and signs LDAP traffic between the administrative tool clients and domain
controllers.
The Windows Server 2003 version of Active Directory Sites and Services (installed on the domain controller or on the
administrative workstation by using Administration Tools Pack) can target domain controllers that are running Windows
Server 2003 and Windows 2000 Server.
Active Directory Sites and Services provides a view into the Sites container of the configuration directory partition. Use Active
Directory Sites and Services to manage Active Directory replication topology. The following objects and their properties can be
managed by using this tool:
• Sites container: Add new sites.
• Site objects: Add new servers to a site.
• NTDS Site Settings object: For each site, view the connection object schedule and enable Universal group membership caching.
• Server object: View the NTDS Settings object and designate the server as a bridgehead server.
• NTDS Settings object: View inbound connections for the server. View the connection object schedule and change the source
server for the connection.
• Inter‐Site Transports container: Manage IP and SMTP site links.
• Site link objects: Manage the site link properties for a set of sites.
• Subnets container: Add, remove, and configure subnets with IP addresses. Associate subnets with sites.

Reapdmin.exe: Repadmin
Category
Windows Server 2003 Support Tools, command‐line tool.
Version compatibility
Repadmin runs on any computer on which Windows Server 2003 Support Tools can be installed, which includes Windows
Server 2003 family and Windows XP Professional.
Repadmin is used to view the replication information on domain controllers. You can determine the last successful replication of
all directory partitions, identify inbound and outbound replication partners, identify the current bridgehead servers, view object
metadata, and generally manage Active Directory replication topology. You can use Repadmin to force replication of an entire
directory partition or of a single object. You can also list domain controllers in a site.
Repadmin is extended in Windows Server 2003 to enable commands to target sets of domain controllers. For example, you can
target all domain controllers in a site or domain, or all domain controllers that are global catalog servers. In Windows 2000 Server,
Repadmin can report information about only one domain‐controller at a time.
Repadmin has also been improved in Windows Server 2003 to include the RemoveLingeringObjects command, which removes
objects that are outdated (do not exist in a replica of the same directory partition on the source domain controller).

Ntdsutil.exe: Ntdsutil
Category
Windows Server 2003 Support Tools, command‐line tool.
Version compatibility
This tool is compatible with Windows Server 2003. An updated version of Ntdsutil is included with Windows Server 2003 Service
Pack 1 (SP1).
Ntdsutil.exe provides management capabilities for Active Directory. You can use Ntdsutil.exe to perform Active Directory database
maintenance, manage and control single‐master operations, and remove replication metadata left behind by domain controllers
that are removed from the network without uninstalling Active Directory. The version of Ntdsutil that is included with
Windows Server 2003 SP1 removes File Replication service (FRS) metadata in addition to Active Directory replication metadata.
You can also use Ntdsutil to create application directory partitions and perform authoritative restore operations. This tool is
intended for use by experienced administrators.

Active Directory Replication Registry Entries

The information here is provided as a reference for use in troubleshooting or verifying that the required settings are applied. It is
recommended that you do not directly edit the registry unless there is no other alternative. Modifications to the registry are not
validated by the registry editor or by Windows before they are applied, and as a result, incorrect values can be stored. This can
result in unrecoverable errors in the system. When possible, use Group Policy or other Windows tools, such as Microsoft
Management Console (MMC), to accomplish tasks rather than editing the registry directly. If you must edit the registry, use
extreme caution.
The following registry settings cannot be modified by using Group Policy or other Windows tools.

NTDS Parameters Registry Settings

The following registry entries are associated with Active Directory replication.
Replicator notify pause after modify (secs)
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Version
Windows 2000 Server.
Default value
Windows 2000 Server: 300 seconds.
The value for the delay between an originating update on a domain controller and the first change notification. On domain
controllers running Windows Server 2003, the value for initial change notification delay is stored in the
msDSReplicationNotifyFirstDSADelay attribute on the cross‐reference object for each directory partition in the Configuration
container. The default value in Windows Server 2003 is decreased to 15 seconds when the forest functional level is
Windows Server 2003.

Replicator notify pause between DSAs (secs)

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Version
Windows 2000 Server.
Default value
Windows 2000 Server: 30 seconds
The value for the delay before each subsequent change notification. On domain controllers running Windows Server 2003, the
value for subsequent notification delay is stored in the msDSReplicationNotifySubsequentDSADelay attribute on the cross‐
reference object for each directory partition in the Configuration container. The default value in Windows Server 2003 is
decreased to 3 seconds when the forest functional level is Windows Server 2003.
RPC Replication Timeout (mins)
Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
Windows 2000 Server: 45 minutes; Windows Server 2003: 5 minutes.
The number of minutes between initiation of Active Directory replication and the RPC timeout. The domain controller must be
restarted before the change takes effect.

Strict replication consistency

Registry path
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server with SP3.
Default value
Windows 2000 Server with SP3: off (0); Windows Server 2003: on (1)
The value that determines the treatment of replication of outdated objects that exist on reconnected domain controllers that
have not replicated in longer than a tombstone lifetime. If the destination domain controller has strict replication consistency
enabled, inbound replication of an outdated object is blocked. If the destination domain controller has strict replication disabled,
inbound replication of the full object occurs.

Replicator intra site packet size (objects)

Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
1/1,000,000th the size of RAM, with a minimum of 100 objects and a maximum of 1,000 objects.
The maximum number of objects per packet for RPC replication within a site.
Replicator intra site packet size (bytes)
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
1/100th the size of RAM, with a minimum of 1 megabyte (MB) and a maximum of 10 MB.
The maximum size of objects per packet for RPC replication within a site.

Replicator inter site packet size (objects)

Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
1/1,000,000th the size of RAM, with a minimum of 100 objects and a maximum of 1,000 objects.
The maximum number of objects per packet for RPC replication between sites.

Replicator inter site packet size (bytes)

Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
The maximum size of objects per packet for RPC replication between sites.
Default value
1/100th the size of RAM, with a minimum of 1 MB and a maximum of 10 MB.

Replicator async inter site packet size (objects)

Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
1/1,000,000th the size of RAM, with a minimum of 100 objects and a maximum of 1,000 objects.
The maximum number of objects per packet for SMTP replication between sites.
Replicator async inter site packet size (bytes)
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
1 MB.
The maximum size of objects per packet for SMTP replication between sites.

Replicator compression algorithm

Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003.
Default value
3. For Windows 2000 Server compression, change the value to 2.
Determines the compression algorithm that is used on a site link (Windows Server 2003 algorithm or Windows 2000 Server
algorithm).

Repl topology update delay (secs)

Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
300 seconds.
Number of seconds to wait between the time Active Directory starts and the KCC performs the first topology check.

Repl topology update period (secs)

Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
900 seconds.
Interval between KCC replication topology checks.

IntersiteFailuresAllowed
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
1.
Number of failed replication attempts prior to excluding nonresponding servers from the intersite topology.

MaxFailureTimeForIntersiteLink (sec)
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
7200 seconds (2 hours).
Time in seconds that must elapse prior to excluding nonresponding servers from the intersite topology.

NonCriticalLinkFailuresAllowed
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
1.
Number of failed replication attempts prior to excluding nonresponding servers from the intrasite topology.

MaxFailureTimeForNonCriticalLink (sec)
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
43200 seconds (12 hours).
Time in seconds that must elapse prior to excluding nonresponding servers from the intrasite topology.

CriticalLinkFailuresAllowed
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
0.
Number of failed replication attempts prior to excluding nonresponding servers for immediate neighbour connections within a
site.

MaxFailureTimeForCriticalLink (sec)
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
7200 seconds (2 hours).
Time in seconds that must elapse prior to excluding nonresponding servers for immediate neighbour connections within a site.

TCP/IP Port
Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003, Windows 2000 Server.
Default value
135.
TCP port that the directory service uses instead of using dynamic port 135. The domain controller must be restarted before the
change takes effect.

Backup Latency Threshold (days)

Registry path
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
Version
Windows Server 2003 with SP 1
Default value
Half the value of the tombstone lifetime of the forest.
When the value is reached, logs event ID 2089 in the Directory Service event log, warning administrators and monitoring
applications to make sure that domain controllers are backed up before the tombstone lifetime expires.
Active Directory Replication Group Policy Settings
The following table lists and describes the Group Policy settings that are associated with Active Directory replication updates.
Group Policy Settings Associated with Active Directory Replication
Group Policy Setting Description

Account Lockout Policy: Changes to these settings in the Domain Security Policy trigger urgent
• Account lockout duration replication.

• Account lockout threshold

• Reset account lockout counter after

Password Policy: Changes to these settings in the Domain Security Policy trigger urgent
• Enforce password history replication.

• Maximum password age

• Minimum password age
• Minimum password length
• Password must meet complexity
requirements
• Store passwords using reversible encryption

Contact PDC on logon failure Account lockout and domain password changes rely on contacting the primary
domain controller (PDC) emulator urgently to update the PDC emulator with the
change. If Contact PDC on logon failure is disabled, replication of password
changes to the PDC emulator occurs non‐urgently.

Active Directory Replication WMI Classes

The following table lists and describes the WMI classes that are associated with Active Directory replication. These classes are
shipped with Windows Server 2003, but are also compatible with Windows 2000 Server.

WMI Classes Associated with Active Directory Replication

Class Name Namespace Version Compatibility

MSAD_DomainController \\root\MicrosoftActiveDirectory Windows Server 2003

Windows 2000 Server
MSAD_NamingContext \\root\MicrosoftActiveDirectory Windows Server 2003
Windows 2000 Server
MSAD_ReplNeighbor \\root\MicrosoftActiveDirectory Windows Server 2003
Windows 2000 Server
MSAD_ReplCursor \\root\MicrosoftActiveDirectory Windows Server 2003
Windows 2000 Server
MSAD_ReplPendingOp \\root\MicrosoftActiveDirectory Windows Server 2003
Windows 2000 Server
Network Ports Used by Active Directory Replication
By default, RPC‐based replication uses dynamic port mapping. When connecting to an RPC endpoint during Active Directory
replication, the RPC run time on the client contacts the RPC endpoint mapper on the server at a well‐known port (port 135). The
server queries the RPC endpoint mapper on this port to determine what port has been assigned for Active Directory replication on
the server. This query occurs whether the port assignment is dynamic (the default) or fixed. The client never needs to know which
port to use for Active Directory replication.
Note
• An endpoint comprises the protocol, local address, and port address.
In addition to the dynamic port 135, other ports that are required for replication to occur are listed in the following table.

Port Assignments for Active Directory Replication

Service Name UDP TCP

LDAP 389 389

LDAP 636 (Secure Sockets Layer [SSL])
LDAP 3268 (global catalog)
Kerberos 88 88
DNS 53 53
SMB over IP 445 445
Replication within a domain also requires FRS using a dynamic RPC port.