Force rebuild Active Directory Replication Topology across Site Links
To force the rebuild of the topology within one site, run the Knowledge Consistency Checker (KCC) on any domain controller within that site.
You can run the KCC by selecting the desired site in the Active Directory Sites and Services console, expand the Servers folder from this site, expand the server node and click on NTDS Settings, right-click in the details pane and click on All Tasks -> Check Replication Topology. Do this for all servers within the site.
![](https://blog.matrixpost.net/wp-content/uploads/2021/12/AD_Topology002-1024x466.png)
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.
The KCC uses only RPC to communicate with the directory service. The KCC does not use Lightweight Directory Access Protocol (LDAP).
Source: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755994(v%3dws.10)#active-directory-kcc-architecture-and-processes
In order to force the rebuild of the Active Directory Replication Topology across Site Links, we first need to determine the Inter-Site Topology Generator (ISTG) for each site and then we also need to run the KCC on that ISTG as done before within the site.
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.
Source: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755994(v%3dws.10)#active-directory-kcc-architecture-and-processes
To determine what domain controller holds the Inter-Site Topology Generator (ISTG) for a site, you can also use the Active Directory Sites and Services console.
Click on the site you want to check and double-click in the details pane on NTDS Site Settings.
The ISTG will be displayed under Inter-Site Topology Generator if one is present. The first server in a site becomes the ISTG for that site.
![](https://blog.matrixpost.net/wp-content/uploads/2021/12/AD_Topology003-1024x729.png)
Now we will run the KCC on that ISTG as done before within the site above and shown in the following figure.
![](https://blog.matrixpost.net/wp-content/uploads/2021/12/AD_Topology002-1024x466.png)
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
The following diagram shows the KCC architecture on servers in the same forest in two sites.
![](https://blog.matrixpost.net/wp-content/uploads/2021/12/cc755994.12795193-a8ee-4a3b-a2c7-5271fe921781ws.10.gif)
The architecture and process components in the preceding diagram are described in the following table.
KCC Architecture and Process Components
Component | Description |
---|---|
Knowledge Consistency Checker (KCC) | The application running on each domain controller that communicates directly with the Ntdsa.dll to read and write replication objects. |
Directory System Agent (DSA) | The directory service component that runs as Ntdsa.dll on each domain controller, providing the interfaces through which services and processes such as the KCC gain access to the directory database. |
Extensible Storage Engine (ESE) | The directory service component that runs as Esent.dll. ESE manages the tables of records, each with one or more columns. The tables of records comprise the directory database. |
Remote procedure call (RPC) | The Directory Replication Service (Drsuapi) RPC protocol, used to communicate replication status and topology to a domain controller. The KCC also uses this protocol to communicate with other KCCs to request error information when building the replication topology. |
Intersite Topology Generator (ISTG) | The single KCC in a site that manages intersite connection objects for the site. |
Repadmin
Repadmin.exe helps administrators diagnose Active Directory replication problems between domain controllers running Microsoft Windows operating systems.
Trigger the Knowledge Consistency Checker (KCC) to run on each of the domain controllers that are in the site named HQ:
repadmin /kcc site:HQ
Forces the Knowledge Consistency Checker (KCC) on each targeted domain controller to immediately recalculate the inbound replication topology.
Source: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc742173(v=ws.11)
You can use Repadmin.exe to view the replication topology, as seen from the perspective of each domain controller. In addition, you can use Repadmin.exe to manually create the replication topology, to force replication events between domain controllers, and to view both the replication metadata and up-to-dateness vectors (UTDVECs). You can also use Repadmin.exe to monitor the relative health of an Active Directory Domain Services (AD DS) forest.
During the normal course of operations, there is no need to create the replication topology manually. Incorrect use of Repadmin can adversely impact the replication topology. The primary use of Repadmin is to monitor replication so that you can identify problems, such as offline servers or an unavailable local area network (LAN) or wide area network (WAN) connection.
Links
How Active Directory Replication Topology Works
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc755994(v%3dws.10)#kcc-and-topology-generation
Troubleshooting Active Directory Replication Problems
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/troubleshoot/troubleshooting-active-directory-replication-problems
Advanced Active Directory Replication and Topology Management Using Windows PowerShell (Level 200)
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/manage/powershell/advanced-active-directory-replication-and-topology-management-using-windows-powershell–level-200-
Active Directory Replication Concepts
https://docs.microsoft.com/en-us/windows-server/identity/ad-ds/get-started/replication/active-directory-replication-concepts
Repadmin
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/cc770963(v=ws.11)#:~:text=Service%20(BITS)%20Overview-,Repadmin,-Article