Share via

How Active Directory Replication Works

  • Article

Introduction

This article introduces the Active Directory Domain Services (AD DS) replication architecture, shows how to detect network packets that are caused by replication, and presents some network traffic statistics that will help you understand and design an efficient replication topology.

Note In Windows 2000 Server and Windows Server 2003, the directory service is named Active Directory. Starting in Windows Server 2008, the directory service is referred to as Active Directory Domain Services (AD DS).

AD DS is a distributed directory service that stores objects that represent real-world entities such as users, groups, computers, services, and network resources. Objects in the directory are distributed among all domain controllers in a forest, and all writeable domain controllers can be updated directly. AD DS replication is the process by which the changes that originate on one domain controller are automatically transferred to other domain controllers and global catalogs.

Replication Architecture

The AD DS is made up of one or more naming contexts (NCs) or partitions. A naming context is a contiguous sub-tree of the directory (such as the directory schema) that is a unit of replication. In the Active Directory each domain controller always holds at least three NC replicas:

  • Schema

  • Configuration (replication topology and related metadata)

  • Domain naming context (contains the actual objects in the directory)

The schema NC defines types of objects (such as users) and attributes of those objects (such as telephone numbers) that can be created stored in the AD DS, and as well as the rules for creating and manipulating them. Schema information (which attributes are mandatory for object creation, what additional attributes can be set, and what attribute data types are used) is replicated to all domain controllers in the forest. Unlike other NCs, the schema NC is only writeable on the domain controller holding the Schema Master FSMO role.

The configuration NC includes information about the AD DS as a whole—what domains exist, what sites are available, what domain controllers are running in the particular sites and domains, as well as configuration information for additional services such as Active Directory Certificate Services (AD CS) and Microsoft Exchange. All enterprise domain controllers need this information to make operational decisions (such as choosing replication partners) so it is replicated to every domain controller in the forest.

A domain naming context holds objects such as users, groups, computers, and organizational units. A full domain naming context replica contains a writeable replica of all information in the domain including all objects and their attributes. A domain controller (DC) holds a full replica of its domain naming context. A partial domain naming context replica contains a read-only subset of the information in the domain—all objects, but only selected attributes. These attributes are collectively known as the Partial Attribute Set (PAS). A domain controller that's a global catalog (GC) server contains a partial replica of every other domain in the forest (and a full replica of its own domain.)

GC servers speed up enterprise-wide directory searches by acting as indexers for the enterprise, holding in their database a copy of selected attributes for all enterprise objects—a small set of common object attributes typically meaningful in searches: first and last names for user objects, locations for printers, and so on. Even if the specific attribute is not found in the GC database, the user or application can at least find out which domain controllers to contact for more information.

Besides that, global catalogs are also needed for logon operations. GCs servers map user principal names (FredG@Acme.com) to accounts (HQ.Acme.com\FredG). Only GC servers know all user memberships in universal groups, so the logon process must communicate to a GC to add the security IDs (SIDs) of the universal groups to the user's access token, if the user is a member of a universal group.

Normal replication mechanisms keep GC server partial domain replicas up to date. When AD DS builds a replication topology for a naming context, it includes the partial domain replicas. Thus, a partial domain replica cannot act as a replication source for a full domain replica, because the partial domain replica only knows about a subset of attributes. A partial domain replica can, however, act as a replication source for another partial domain replica.

Object Model

Objects in the Active Directory are defined by their attributes' types and values. An object receives its identity from its Global Unique Identifier (GUID—the only attribute that cannot be changed). It keeps track of a system object in the Active Directory even after a move between domains changes its distinguished name (DN).
 
As noted, the schema defines which attributes can be used on objects. The AD DS Extensible Storage Engine (pronunciations include saying the letters ESE or saying "easy") reserves space only for attributes with actual values set on them (attributes containing values). This helps conserve database space because user objects have more than 100 defined attributes, but only 20 to 30 are commonly used. Using this model, the replication engine minimizes traffic by replicating only object attributes that have values assigned, and only attributes with values that have changed since the last replication.

Multi-Master Replication

The AD DS uses a multi-master replication topology that allows you to use any domain controller to manipulate the domain database and to replicate changes to its replication partners.

Domain controllers use update sequence numbers (USNs) to see if replication partners are up to date. In the case of collisions (when the same attribute of the same object is manipulated on two domain controllers at the same time) the last writer wins. To determine last writer status, an algorithm checks the following properties of the change in order:

  1. attribute version number
  2. attribute modification timestamp
  3. GUIDs of the domain controllers that performed the write operation

This ensures that the attribute value is determined consistently and locally, reducing communication between domain controllers.

Replication Topology

Replication efficiency is enhanced by a flexible replication topology that can reflect the structure of an existing network. The Active Directory's replication topology generator runs as part of the Knowledge Consistency Checker (KCC). You feed the KCC information on the cost of sending data from one location to another, and which domain controllers are running in the same location. Using this, the KCC builds an inter-site replication topology that is a spanning tree based on low-cost routing decisions between remote locations, and a more strongly connected intra-site topology. You can disable the KCC topology generator and manually create the connection objects required for replication. During this process, the Active Directory logging mechanism identifies domain controllers that appear to be isolated from the enterprise-wide replication.
Note Using replication topology generator is strongly recommended: it simplifies a complex task, has a flexible architecture that reacts to failures and to changes you make later in the network topology, and helps compute the lowest-cost topology.

Connection Objects

The fact that one domain controller uses another as a source for replication information is expressed as a connection object in the Active Directory. These define incoming replication only. For example, if domain controller DC1 has a connection object to DC2, then DC1 can use all naming contexts on DC2 as a source for updated information, but DC2 cannot use DC1 unless it creates a connection object that defines DC1 as a source. Once a connection object has been created, it can be used to replicate information from all naming contexts.

Sites

Used in the Active Directory to express proximity of network connection, a site is defined as an IP subnetwork—a concept used in all routed TCP/IP network environments. A legal definition of a site could be 177.177.177.0/24, where 177.177.177.0 describes the IP subnet, and 24 tells how many bits are used to define it. The remaining bits of an IP address (32 – 24 = 8 bits in this example) can be used to define hosts.

A site consists of one or more subnets (unique network segments). For example, in a network with three subnets in Redmond and two in Paris, the administrator can create two sites: one in Redmond and one in Paris, and add the subnets to the local sites.

The Active Directory uses site information in these ways:

  • The KCC generates a replication topology more strongly-connected within a site than between sites (adds some traffic but reduces intra-site replication latency).

  • Does not compress intra-site replication messages (adds some traffic but reduces CPU utilization on DCs).

  • Intra-site DC replication is change-based; inter-site DC replication is scheduled.

  • Client machines use site information to find nearby DCs for logon operations.

  • The Active Directory uses site information to help users find the closest machine that offers a needed network or a third-party service.

Intra-Site Replication

Intra-site replication (between domain controllers in the same site) attempts to complete in the fewest CPU cycles possible. Because domain controllers should be able to serve clients quickly for logons, searches, etc., the network connection between them is assumed to have lots of available bandwidth and reliable connection.

Replication is a trade off: data should be as accurate as possible on all domain controllers, which means that latency should be as small as possible, which means fast updates, which means frequent replication. On the other hand, frequency doesn't always equal efficiency. For instance, if there is a bulk import of directory objects, changes in a domain controller database will become out of date after 10 seconds, but it makes no sense to replicate the changes until the database is stable (the bulk import is complete).

Intra-site replication avoids unnecessary network traffic by introducing a change notification mechanism that replaces the usual polling of replication partners for updates. When a change is performed in its database, a domain controller waits a configurable interval (default 5 minutes), accepts more changes during this time, then sends a notification to its replication partners, which pull the changes. If no changes are performed for a configurable period (default 6 hours) the domain controller initiates a replication sequence anyway, just to make sure that it did not miss anything.

Attribute changes considered security-sensitive are immediately replicated and intra-site partners are notified: lockout of user accounts, change of domain trust passwords, some changes in the roles of domain controllers.

Intra-site replication topology is a bi-directional ring built using domain controller GUIDs. If a ring contains seven or more DCs, bi-directional connections are added to keep the path between any pair to less than three hops. New DCs configured in the site are included in the ring. One bi-directional ring is built for each naming context available in a site. Schema and configuration information share the same topology and only one bi-directional ring is built for them, because they must be replicated to all domain controllers.

If all of a site's domain controllers are in the same domain, the two rings are the same—the ring that includes all site domain controllers is equivalent to the ring that includes all domain controllers in that domain. You have more than one distinct ring only when your site contains more than one domain: 2 domains = 3 rings, 3 domains = 4 rings, and so forth. To find out what rings exist in a site, use the Active Directory Sites and Services Manager snap-in to check the connection objects and see what incoming replication connections they represent.

Inter-Site Replication

Inter-site replication is based on the assumption that the WAN is connected by slower links, so it is designed to minimize traffic rather than CPU cycles. Before being sent out, data is compressed to about 10% to 15% of original volume.

Inter-site replication topology is a spanning tree. As long as a replication route can be constructed between all sites in the enterprise, the replication topology is functional. It is not necessary to create additional links. The administrator decides which sites are connected, and can create a site link that allows domain controllers from any site to talk to domain controllers in any other site. Site links are based on the cost of replication (which reflects the speed and reliability of the underlying network) and its schedule (which defines a window when replication is allowed over the link).

Unlike Intra-site replication, inter-site replication does not use a notification process. Inter-site replication can be fully scheduled by the administrator on a per site-link basis.

Since there is no notification between the replication partners, a domain controller does not know which naming context was updated on the sourced replication partner. Therefore, it has to check all existing naming contexts on the source machine. A normal domain controller (that is, one that uses a GC as replication partner) will check only the normal three naming contexts on the GC (schema, configuration, and its domain) but never the partial naming contexts of other domains. For that reason, the initial replication setup traffic is slightly higher in the inter-site case. But if many objects are replicated, compression kicks in and makes this kind of replication more efficient.

Replication Transports

While intra-site replication supports only replication based on remote procedure calls (RPCs), the initial release of Windows 2000 offers two transports for inter-site replication:

  • Synchronous (scheduled) via RPC over TCP/IP

  • Asynchronous via simple mail transfer protocol (SMTP) using the Collaborative Data Objects (CDO v2) interface and the SMTP component in IIS 5, that is included in Windows 2000.

The intra-site RPC transport does not support data compression; the inter-site transports, both RPC and SMTP, do. RPC-based replication can be used for any kind of replication—intra-domain, configuration information, or global catalog information.

The SMTP transport has some restrictions: It can be used to replicate configuration and global catalog information, but cannot be used for replication between domain controllers that belong to the same domain and therefore have to replicate the full domain-naming context. The reason for this restriction is that some domain operations (for example: global policy) require the support of the file replication service (FRS) that does not yet support an asynchronous transport like SMTP for replication.

Active Directory Replication Traffic (http://technet.microsoft.com/library/bb742457.aspx)
Active Directory Replication Technologies (http://technet.microsoft.com/library/cc776877.aspx)