Active Directory KCC Architecture and Processes
The replication topology is generated by the Knowledge Consistency Checker (KCC), a
replication component that runs as an application on every domain controller and
communicates through the distributed Active Directory database. The KCC functions locally
by reading, creating, and deleting Active Directory data. Specifically, the KCC reads
configuration data and reads and writes connection objects. The KCC also writes local,
nonreplicated attribute values that indicate the replication partners from which to request
replication.
For most of its operation, the KCC that runs on one domain controller does not communicate
directly with the KCC on any other domain controller. Rather, all KCCs use the knowledge
of the common, global data that is stored in the configuration directory partition as input to
the topology generation algorithm to converge on the same view of the replication topology.
Each KCC uses its in-memory view of the topology to create inbound connections locally,
manifesting only those results that apply to itself. The KCC communicates with other KCCs
only to make a remote procedure call (RPC) request for replication error information. The
KCC uses the error information to identify gaps in the replication topology. A request for
replication error information occurs only between domain controllers in the same site.
Note
The KCC uses only RPC to communicate with the directory service. The KCC does
not use Lightweight Directory Access Protocol (LDAP).
One domain controller in each site is selected as the Intersite Topology Generator (ISTG). To
enable replication across site links, the ISTG automatically designates one or more servers to
perform site-to-site replication. These servers are called bridgehead servers. A bridgehead is a
point where a connection leaves or enters a site.
The ISTG creates a view of the replication topology for all sites, including existing
connection objects between all domain controllers that are acting as bridgehead servers. The
ISTG then creates inbound connection objects for servers in its site that it determines will act
as bridgehead servers and for which connection objects do not already exist. Thus, the scope
of operation for the KCC is the local server only, and the scope of operation for the ISTG is a
single site.
Each KCC has the following global knowledge about objects in the forest, which it gets by
reading objects in the Sites container of the configuration directory partition and which it uses
to generate a view of the replication topology:
Sites
Servers
Site affiliation of each server
Global catalog servers
Directory partitions stored by each server
Site links
Site link bridges
Detailed information about these configuration components and their functionality is
provided later in this section.
The following diagram shows the KCC architecture on servers in the same forest in two sites.
KCC Architecture and Processes
The architecture and process components in the preceding diagram are
described in the following table
Goals of Replication Topology
The KCC generates a replication topology that achieves the following goals:
Connect every directory partition replica that must be replicated.
Control replication latency and cost.
Route replication between sites.
Effect client affinity.
By default, the replication topology is managed automatically and optimizes existing
connections. However, manual connections created by an administrator are not modified or
optimized.
Connect Directory Partition Replicas
The total replication topology is actually composed of several underlying topologies, one for
each directory partition. In the case of the schema and configuration directory partitions, a
single topology is created. The underlying topologies are merged to form the minimum
number of connections that are required to replicate each directory partition between all
domain controllers that store replicas. Where the connections for directory partitions are
identical between domain controllers — for example, two domain controllers store the same
domain directory partition — a single connection can be used for replication of updates to the
domain, schema, and configuration directory partitions.
A separate replication topology is also created for application directory partitions. However,
in the same manner as schema and configuration directory partitions, application directory
partitions can use the same topology as domain directory partitions. When application and
domain directory partitions are common to the source and destination domain controllers, the
KCC does not create a separate connection for the application directory partition.
A separate topology is not created for the partial replicas that are stored on global catalog
servers. The connections that are needed by a global catalog server to replicate each partial
replica of a domain are part of the topology that is created for each domain.
The routes for the following directory partitions or combinations of directory partitions are
aggregated to arrive at the overall topology:
Configuration and schema within a site.
Each writable domain directory partition within a site.
Each application directory partition within a site.
Global catalog read-only, partial domain directory partitions within a site.
Configuration and schema between sites.
Each writable domain directory partition between sites.
Each application directory partition between sites.
Global catalog read-only, partial domain directory partitions between sites.
Replication transport protocols determine the manner in which replication data is transferred
over the network media. Your network environment and server configuration dictates the
transports that you can use. For more information about transports, see “Replication
Transports” later in this section.
Control Replication Latency and Cost
Replication latency is inherent in a multimaster directory service. A period of replication
latency begins when a directory update occurs on an originating domain controller and ends
when replication of the change is received on the last domain controller in the forest that
requires the change. Generally, the latency that is inherent in a WAN link is relative to a
combination of the speed of the connection and the available bandwidth. Replication cost is
an administrative value that can be used to indicate the latency that is associated with
different replication routes between sites. A lower-cost route is preferred by the ISTG when
generating the replication topology.
Site topology is the topology as represented by the physical network: the LANs and WANs
that connect domain controllers in a forest. The replication topology is built to use the site
topology. The site topology is represented in Active Directory by site objects and site link
objects. These objects influence Active Directory replication to achieve the best balance
between replication speed and the cost of bandwidth utilization by distinguishing between
replication that occurs within a site and replication that must span sites. When the KCC
creates replication connections between domain controllers to generate the replication
topology, it creates more connections between domain controllers in the same site than
between domain controllers in different sites. The results are lower replication latency within
a site and less replication bandwidth utilization between sites.
Within sites, replication is optimized for speed as follows:
Connections between domain controllers in the same site are always arranged in a ring, with
possible additional connections to reduce latency.
Replication within a site is triggered by a change notification mechanism when an update
occurs, moderated by a short, configurable delay (because groups of updates frequently
occur together).
Data is sent uncompressed, and thus without the processing overhead of data compression.
Between sites, replication is optimized for minimal bandwidth usage (cost) as follows:
Replication data is compressed to minimize bandwidth consumption over WAN links.
Store-and-forward replication makes efficient use of WAN links — each update crosses an
expensive link only once.
Replication occurs at intervals that you can schedule so that use of expensive WAN links is
managed.
The intersite topology is a layering of spanning trees (one intersite connection between any
two sites for each directory partition) and generally does not contain redundant
connections.
Route Replication Between Sites
The KCC uses the information in Active Directory to identify the least-cost routes for
replication between sites. If a domain controller is unavailable at the time the replication
topology is created, making replication through that site impossible, the next least-cost route
is used. This rerouting is automatic when site links are bridged (transitive), which is the
default setting.
Replication is automatically routed around network failures and offline domain controllers.
Effect Client Affinity
Active Directory clients locate domain controllers according to their site affiliation. Domain
controllers register SRV resource records in the DNS database that map the domain controller
to a site. When a client requests a connection to a domain controller (for example, when
logging on to a domain computer), the domain controller Locator uses the site SRV resource
record to locate a domain controller with good connectivity whenever possible. In this way, a
client locates a domain controller within the same site, thereby avoiding communications
over WAN links.
Sites can also be used by certain applications, such as DFS, to ensure that clients locate
servers that are within the site or, if none is available, a server in the next closest site. If the
ISTG is running Windows Server 2003 or later server operating systems, you can specify an
alternate site based on connection cost if no same-site servers are available. This DFS feature,
called “site costing,” is new in Windows Server 2003.
For more information about the domain controller Locator, see “DNS Support for Active
Directory Technical Reference.” For more information about DFS site costing, see “DFS
Technical Reference.”
Topology-Related Objects in Active Directory
Active Directory stores replication topology information in the configuration directory
partition. Several configuration objects define the components that are required by the KCC
to establish and implement the replication topology.
Active Directory Sites and Services is the Microsoft Management Console (MMC) snap-in
that you can use to view and manage the hierarchy of objects that are used by the KCC to
construct the replication topology. The hierarchy is displayed as the contents of the Sites
container, which is a child object of the Configuration container. The Configuration container
is not identified in the Active Directory Sites and Services UI. The Sites container contains an
object for each site in the forest. In addition, Sites contains the Subnets container, which
contains subnet definitions in the form of subnet objects.
The following figure shows a sample hierarchy, including two sites: Default-First-Site-Name
and Site A. The selected NTDS Settings object of the server MHDC3 in the site Default-
First-Site-Name displays the inbound connections from MHDC4 in the same site and from A-
DC-01 in Site A. In addition to showing that MHDC3 and MHDC4 perform intrasite
replication, this configuration indicates that MHDC3 and A-DC-01 are bridgehead servers
that are replicating the same domain between Site A and Default-First-Site-Name.
Sites Container Hierarchy
INTERSITE AND INTRASITE REPLICATION
Thus, the KCC creates two types of topologies: intrasite and intersite. Within a site, the KCC
creates a ring topology by using all servers in the site. To create the intersite topology, the
ISTG in each site uses a view of all bridgehead servers in all sites in the forest. The following
diagram shows a high-level generalization of the view that the KCC sees of an intrasite ring
topology and the view that the ISTG sees of the intersite topology. Lines between domain
controllers within a site represent inbound and outbound connections between the servers.
The lines between sites represent configured site links. Bridgehead servers are represented as
BH.
KCC and ISTG Views of Intrasite and Intersite Topology
Replication Topology Physical Structure
The Active Directory replication topology can use many different components. Some
components are required and others are not required but are available for optimization. The
following diagram illustrates most replication topology components and their place in a
sample Active Directory multisite and multidomain forest. The depiction of the intersite
topology that uses multiple bridgehead servers for each domain assumes that at least one
domain controller in each site is running at least Windows Server 2003. All components of
this diagram and their interactions are explained in detail later in this section.
Replication Topology Physical Structure
In the preceding diagram, all servers are domain controllers. They independently use global
knowledge of configuration data to generate one-way, inbound connection objects. The
KCCs in a site collectively create an intrasite topology for all domain controllers in the site.
The ISTGs from all sites collectively create an intersite topology. Within sites, one-way
arrows indicate the inbound connections by which each domain controller replicates changes
from its partner in the ring. For intersite replication, one-way arrows represent inbound
connections that are created by the ISTG of each site from bridgehead servers (BH) for the
same domain (or from a global catalog server [GC] acting as a bridgehead if the domain is
not present in the site) in other sites that share a site link. Domains are indicated as D1, D2,
D3, and D4.
Each site in the diagram represents a physical LAN in the network, and each LAN is
represented as a site object in Active Directory. Heavy solid lines between sites indicate
WAN links over which two-way replication can occur, and each WAN link is represented in
Active Directory as a site link object. Site link objects allow connections to be created
between bridgehead servers in each site that is connected by the site link.
Not shown in the diagram is that where TCP/IP WAN links are available, replication between
sites uses the RPC replication transport. RPC is always used within sites. The site link
between Site A and Site D uses the SMTP protocol for the replication transport to replicate
the configuration and schema directory partitions and global catalog partial, read-only
directory partitions. Although the SMTP transport cannot be used to replicate writable
domain directory partitions, this transport is required because a TCP/IP connection is not
available between Site A and Site D. This configuration is acceptable for replication because
Site D does not host domain controllers for any domains that must be replicated over the site
link A-D.
By default, site links A-B and A-C are transitive (bridged), which means that replication of
domain D2 is possible between Site B and Site C, although no site link connects the two sites.
The cost values on site links A-B and A-C are site link settings that determine the routing
preference for replication, which is based on the aggregated cost of available site links. The
cost of a direct connection between Site C and Site B is the sum of costs on site links A-B
and A-C. For this reason, replication between Site B and Site C is automatically routed
through Site A to avoid the more expensive, transitive route. Connections are created
between Site B and Site C only if replication through Site A becomes impossible due to
network or bridgehead server conditions.
By: Pritam, Jerson n Firoz