AD DS replication

The AD database consists of partitions that can replicate independently. Specifically, Schema, and Configurationalways replicate forest-wide, Domainreplicates within its domain, and Applicationreplicates according to predefined rules. Also remember the Global Catalog (GC), which replicates throughout the forest, but only between other GCs.

How AD DS replication works.

How AD DS replication works.

The AD database is multimaster, so replication itself uses the multimaster model, allowing separate AD database partitions to replicate independently. Every DC can therefore accept updates for which it is authoritative.

AD replication uses:

• multimaster replication – every DC can accept updates for which it is authoritative
• pull replication – the destination DC requests only changes in advance, reducing network traffic
• store-and-forward replication – DCs use subnet configuration to optimise replication. Each subnet has one selected DC (bridgehead server) responsible for replication with a bridgehead server in another subnet. This avoids chaotic replication between all DCs: replication occurs within each subnet and between subnets through bridgehead servers.

AD changes that trigger replication:

• creating an AD object (a new user, etc.)
• modifying an AD object and its attributes (phone number, department)
• moving an object within AD (changing OU)
• deleting an object

Deletion differs from other changes. A deleted AD object is assigned a lifetimeof, by default, 180 days, which is then replicated to other DCs. Only when this lifetime expires is the object permanently deleted from the AD database.

In Server 2008 R2, the domain Recycle Bin increases this to 360 days: 180 days in the domain Recycle Bin + 180 days in AD

How AD DS replication works within a site

• once changes are applied on one DC, it automatically notifies other DCs to retrieve them
• for ordinary changes, the DC contacts other DCs after 15 minutes
• for security changes (password changes), it contacts other DCs immediately
• replication within a site is uncompressed because a fast connection between DCs is assumed

Resolving replication conflicts

Conflict types

There are three conflict types:

• the same object attribute changes simultaneously on two DCs
• an object is added or changed on one DC while its entire container is deleted on another DC at the same time
• objects with the same name are added simultaneously on two DCs

Conflict resolution

To address potential conflicts, AD uses Global unique stamps, which create a stampfor each change to be replicated, containing a Version number, the time the change was applied ( Timestamp ) and the unique GUID of the server that made the change.
Conflicts are resolved by accepting the item with the newer stamp number – stamp

Replication topology defines paths determining which data replicates with which DCs. The resulting topology is managed by the KCC service, running on every DC. For any change affecting replication (adding a DC), it calculates the options and determines which DCs and which data will replicate with one another. By default, in a single site environment (only one subnet), all DCs replicate with each other.

The illustration shows two domains and one forest, with a replication topology automatically created based on AD partitions (AD Partitions), where Schema and Configuration replicate forest-wide, domain replicates within each domain, and Global Catalog (GC) replicates between other GC within the forest.