The Knowledge Consistency Checker (KCC) is an Active Directory component that is responsible for the generation of the replication topology between domain controllers. This article describes the role of one server per site, known as the Inter-Site Topology Generator, which is responsible for managing the inbound replication connection objects for all bridgehead servers in the site in which it is located.
This section, method, or task contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
How to back up and restore the registry in Windows
When the KCC on each domain controller generates the intra-site topology for the site in which it resides, the KCC create a connection object in the Active Directory only when a connection object is required for the local computer. These changes propagate to other domain controllers through the normal replication process. Each domain controller uses the same algorithm to compute the replication topology, and in a state of equilibrium between domain controllers, each should arrive at the same result in respect to what the replication topology should be. In the process, each domain controller creates its own connection objects.
Connection objects for bridgehead servers for inter-site replication are created differently. The KCC on one domain controller (regardless of the domain) in each site is responsible for reviewing the inter-site topology and creating inbound replication connection objects as necessary for bridgehead servers in the site in which it resides. This domain controller is known as the Inter-Site Topology Generator (ISTG). The domain controller holding this role may not necessarily also be a bridgehead server.
When the ISTG determines that a connection object needs to be modified on a given bridgehead server in the site, the ISTG makes the change to its local Active Directory copy. As part of the normal intra-site replication process, these changes propagate to the bridgehead servers in the site. When the KCC on the bridgehead server reviews the topology after receiving these changes, it translates the connection objects into replication links that Active Directory uses to replicate data from remote bridgehead servers.
The current owner of the ISTG role is communicated through the normal Active Directory replication process. Initially, the first server in the site becomes the ISTG for the site. The role does not change as additional domain controllers are added to the site until the current ISTG becomes unavailable.
The current ISTG notifies every other domain controller in the site that it is still present by writing the "interSiteTopologyGenerator" attribute on "CN=NTDS Site Settings,CN=SiteName
" under its domain controller object in the Configuration naming context in Active Directory at a specified interval. You can modify this interval using the following registry value (which is not present by default, it must be added):
Value Name: KCC site generator renewal interval (minutes)
Value Data: Number of minutes between updates to Active Directory, in minutes
As this attribute gets propagated to other domain controllers by Active Directory replication, the KCC on each of these computers monitors this attribute to verify that it has been written within a specified amount of time. If the amount of time elapses without a modification, a new ISTG takes over. You can modify this time interval using the following registry value:
Value Name: KCC site generator fail-over (minutes)
Value Data: Time that must elapse before a new ISTG is selected, in minutes
In the event that a new ISTG needs to be established, each domain controller orders the list of servers in ascending order by their Globally Unique Identifier (GUID). The domain controller that is next highest in the list of servers from the current owner takes over the role, starts to write the "interSiteTopologyGenerator" attribute, and performs the necessary KCC processes to manage inbound connection objects for bridgehead servers.
As domain controllers evaluate which server should assume the ISTG role, the selection begins again with the first domain controller listed in the site if the current server is the last server in the list.
In the event that two domain controllers in the site believe that they own the ISTG role, there may be temporary state of inbound replication connection objects being created by two computers. However, once replication occurs and all domain controllers receive the change identifying the new ISTG, the KCC on the ISTG adjusts the topology as appropriate.