Changing the cross-site topology generator

Active Directory replication concepts

  • 4 minutes to read

Applies to: Windows Server 2016, Windows Server 2012 R2, Windows Server 2012

Before you begin designing your site topology, familiarize yourself with some of the concepts of Active Directory replication.

Connection object

A connection object is an Active Directory object that represents a replication connection from a source domain controller to a destination domain controller. A domain controller is a member of a single site and is represented at the site by a server object in Active Directory Domain Services (AD DS). Each server object has a child NTDS Settings object that represents the replicating domain controller at the site.

The connection object is a child of the NTDS Settings object on the destination server. For replication to occur between two domain controllers, the server object of one object must have a connection object that represents the inbound replication from the other. All replication connections for a domain controller are stored as connection objects under the NTDS Settings object. The connection object identifies the source replication server, contains a replication schedule, and specifies a replication transport.

The Knowledge Consistency Checker (KCC) creates connection objects automatically, but it can also be created manually. Connection objects created by KCC appear as shown in the Active Directory Sites and Services snap-in and are considered reasonable under normal operating conditions. Connection objects created by an administrator are manually created connection objects. A manually created connection object is identified by the name assigned by the administrator when it was created. When you change a connection object, you convert it to a management-modified connection object and the object is displayed in the form of a GUID. The KCC does not make any changes to manual or changed connection objects.


KCC is an integrated process that runs on all domain controllers and generates replication topology for the Active Directory forest. The KCC creates separate replication topologies depending on whether replication occurs within a site (intra-site site) or between sites (cross-site site). The KCC also dynamically adjusts the topology to support adding new domain controllers, removing existing domain controllers, removing domain controllers to and from sites, changing costs and schedules, and domain controllers that are temporarily unavailable or in an error state .

Within a site, the connections between writable domain controllers are always arranged in a bidirectional ring, with additional link connections to reduce latency in large sites. On the other hand, the cross-site topology is a layering of spanning structures, which means that there is a cross-site connection between any two sites for each directory partition and usually does not contain any link connections. For more information about tree spanning and the Active Directory replication topology, see the Active Directory Replication Topology Technical Reference (

On each domain controller, KCC creates replication routes by creating one-way inbound connection objects that define connections from other domain controllers. For domain controllers in the same location, KCC automatically creates connection objects without administrative intervention. If you have multiple sites, configure site links between sites, and a single KCC at each site automatically creates links between sites as well.

KCC improvements for Windows Server 2008 RODCs

There are a number of KCC enhancements to the newly available read-only domain controller (RODC) in Windows Server 2008. A typical deployment scenario for RODC is the branch office. The most common Active Directory replication topology deployed in this scenario is based on a hub-and-spoke design in which branch domain controllers in multiple sites are replicated with a small number of bridgehead servers in one hub site.

One of the advantages of deploying RODC in this scenario is one-way replication. Bridgehead servers are not required for replication from the RODC, which reduces administration and network usage.

However, an administrative challenge highlighted by the hub-spoke topology in earlier versions of the Windows Server operating system is that once a new bridgehead domain controller is added to the hub, there is no automatic mechanism to handle the replication connections between the branch domain controllers and the Redistribute hub domain controllers to take advantage of the new hub domain controller.

For Windows Server 2008 RODCs, the normal functioning of the KCC allows for balancing. The new functionality is activated by default. You can disable it by adding the following registry key set on the RODC:

HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ NTDS \ Parameters

"Random RANDOM Loadbalancing Allowed"1 = activated (default), 0 = deactivated

For more information on how these KCC enhancements work, see Planning and Deploying Active Directory Domain Services for Branch Offices (

Failover functions

Sites ensure that replication is routed around network failures and offline domain controllers. The KCC runs at specified intervals to adjust the replication topology for changes that occur in AD DS, such as: For example, as new domain controllers are added and new sites are created. The KCC checks the replication status of existing connections to see if connections are not working. When a connection fails due to a faulty domain controller, KCC automatically creates temporary connections with other replication partners (if available) to ensure that replication occurs. If all domain controllers in one site are unavailable, KCC automatically creates replication connections between domain controllers from another site.


A subnet is a segment of a TCP / IP network that is assigned a set of logical IP addresses. Subnet groups computers together to identify their physical proximity on the network. Subnet Objects in AD DS are the network addresses that are used to map computers to locations.


Sites are Active Directory objects that represent at least one TCP / IP subnet with extremely reliable and fast network connections. Site information enables administrators to configure Active Directory access and replication to optimize the use of the physical network. Site objects are associated with a set of subnets, and each domain controller in a forest is associated with an Active Directory site based on its IP address. Sites can host domain controllers from more than one domain, and a domain can be represented in more than one site.


Site links are Active Directory objects that represent logical paths that KCC uses to connect for Active Directory replication. A site link object represents a group of sites that can communicate over a specified inter-site transport at a uniform cost.

All sites included in the site link are considered to be connected to the same network type. Sites must be manually linked to other sites by using site links so that domain controllers in one site can replicate directory changes from domain controllers in another site. Because site links do not correspond to the actual path network packets use on the physical network during replication, you do not need to create redundant site links to improve the efficiency of Active Directory replication.

When two sites are connected by a site link, the replication system automatically creates links between specific domain controllers in each site called bridgehead servers. In Windows Server 2008, all domain controllers in a site that hosts the same directory partition are candidates for selection as bridgehead servers. The replication connections that KCC creates are randomly distributed among all candidate bridgehead servers in a site to share the replication workload. By default, the random selection process happens only once when connection objects are added to the site for the first time.

Location link bridge

A site link bridge is an Active Directory object that represents a group of site link objects, the sites of which can all communicate over a common transport. Site link bridges enable replication from domain controllers that are not directly connected by a communications link. Typically, a site link bridge corresponds to a router (or group of routers) on an IP network.

By default, the KCC can form a transitive route over all location link links that some locations have in common. When this behavior is disabled, each site link represents its own and isolated network. Sets of site links, which can be treated as a single route, are expressed through a site link bridge. Each bridge represents an isolated communication environment for network traffic.

Site link bridges are a mechanism to logically represent transitive physical connections between sites. A site link bridge allows the KCC to use any combination of the included site links to determine the most cost effective route to connect directory partitions in those sites. The site link bridge does not provide actual connectivity with the domain controllers. If the site link bridge is removed, replication continues over the combined site links until the KCC removes the links.

Site link bridges are only required when a site contains a domain controller that hosts a directory partition that is not also hosted on a domain controller in an adjacent site. However, a domain controller that hosts this directory partition is in one or more different locations in the forest. Neighboring locations are defined as two or more locations that are contained in a single location link.

A site link bridge creates a logical connection between two site links and provides a transitive path between two separate sites using an intermediate site. As part of the Intersite Topology Generator (ISTG), the bridge implies physical connectivity using the intermediate site. The bridge does not imply that a domain controller at the intermediate site will provide the replication path. However, this would be the case if the intermediate site contained a domain controller that hosted the directory partition to be replicated. In this case, a site link bridge is not required.

The cost of each site link is added, which adds up to the cost of the resulting path. The link site bridge is used when the intermediate site does not contain a domain controller to host the directory partition and there is no less costly link available. If the intermediate site contains a domain controller that hosts the directory partition, two separate sites establish replication connections with the intermediate domain controller and do not use the bridge.

Transitivity of location links

By default, all site links are transitive or "bridged". When site links are bridged and schedules overlap, KCC creates replication links that determine domain controller replication partners between sites where the sites are not directly linked by site links but are transitively linked by a series of common sites. This means that you can connect any website to a different location using a combination of location links.

In general, you don't need to create site link bridges for a fully routed network unless you want to control the flow of replication changes. If your network is not fully routed, site link bridges should be created to avoid impossible replication attempts. All site links for a given transport implicitly belong to a single site link bridge for that transport. The default bridging for site links is automatic, and no Active Directory object represents this bridge. The Bridge all site links setting Location links close), which is located in the properties of the TRANSPORTCONTAINER for ip and Simple Mail Transfer Protocol (SMTP), implements the automatic bridging of site links.


SMTP replication will not be supported in future versions of AD DS. Therefore, creating site link objects in the SMTP container is not recommended.

Global catalog server

A global catalog server is a domain controller that stores information about all objects in the forest so that applications can browse AD DS without referring to specific domain controllers that store the requested data. Like all domain controllers, a global catalog server stores full, writable replicas of the schema and configuration directory partitions and a full, writable replica of the domain directory partition for the domain it is hosting. In addition, a global catalog server stores a partial, read-only replica of every other domain in the forest. Partial, read-only domain replicas contain every object in the domain, but only a subset of the attributes (the attributes most commonly used to search the object).

Caching of universal group memberships

Universal group membership caching enables the domain controller to cache universal group membership information for users. You can enable domain controllers running Windows Server 2008 to cache universal group memberships by using the Active Directory Sites and Services snap-in.

Enabling caching of universal group memberships eliminates the need for a global catalog server at every site in a domain, which minimizes network bandwidth usage because a domain controller does not have to replicate all objects in the forest. Logon times are also reduced because the authenticating domain controllers do not always have to access a global catalog to obtain information about universal group membership. For more information about when to use universal group membership caching, see Planning Global Catalog Server Placement.