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.
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
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
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
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
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.