KCC and Topology Generation

  • Article

The KCC is a built-in process that runs on all domain controllers. It is a dynamic-link library that modifies data in the local directory in response to systemwide changes, which are made known to the KCC by changes to the data within Active Directory. The KCC generates and maintains the replication topology for replication within sites and between sites.

The KCC has two major functions:

  • Configures replication connections (connection objects) between domain controllers. Each connection object defines incoming replication from a replication partner. Within a site, each KCC generates its own connections. For replication between sites, a single KCC per site generates all connections between sites.

  • Converts the connection objects that represent inbound replication to the local domain controller into the replication agreements that are actually used by the replication engine.

By default, the KCC reviews and makes modifications to the Active Directory replication topology every 15 minutes to ensure propagation of data, either directly or transitively, by creating and deleting connection objects as needed. The KCC recognizes changes that occur in the environment and ensures that domain controllers are not orphaned in the replication topology.

Tools That Communicate with the KCC

Although the work done by the KCC is evidenced by the automatically generated connection objects that are visible in Active Directory Sites and Services, there is no UI component for managing the KCC per se.

Most replication tasks that affect the KCC can be managed by using Active Directory Sites and Services. For information about non-MMC tools that can be used for advanced replication management and diagnosis, see "Active Directory Diagnostics, Troubleshooting, and Recovery" in this book.

Active Directory Sites and Services

Active Directory Sites and Services is the primary administrative tool that is used to manage replication. Use this tool to create connection objects and site links that the KCC uses to implement replication. Replication within a site is completely automatic and usually requires no intervention. Replication between sites is managed most effectively by changing the settings on the site link objects, as described in this chapter.

For information about procedures for managing replication through Active Directory Sites and Services, see Windows 2000 Server Help.

Event Viewer

Communication from the KCC to the administrator occurs through event logs that you can view in Event Viewer.

The following examples contain a few of the events that are generated by the KCC in the event log:

  • Event 1009 (informational): The consistency checker has started updating the replication topology for this server.

  • Event 1013 (informational): The replication topology update task terminated normally.

  • Event 1265 (warning): The attempt to establish a replication link with parameters < parameters > failed with the following status: < error message >. The record data is the status code. This operation is going to be re-tried.

The KCC, like all subsystems in Active Directory, has a variable event logging level. By default, only the most important events are logged. You can increase the level of detail in the event log by modifying the value in the Replication Events entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics in the registry. Increasing the level of detail can be used to better understand the behavior of the KCC in different situations. However, a logging level value of greater than 2 generally results in excessive logging that degrades the performance of the component. Increasing the logging level can be useful for troubleshooting problems, but it is not recommended for normal operation. For information about how to modify the registry to increase logging levels, see "Active Directory Diagnostics, Troubleshooting, and Recovery" in this book. For information about using Event Viewer, see Windows 2000 Server Help.

Objects Required by the KCC for Building Topology

When the KCC builds the topology, it must determine which servers that are present in each site in order to construct an efficient topology. The following objects provide the information required by the KCC to create the topology:

  • Server object: All domain controllers are identified as server objects in the configuration directory partition, broken down by site.

  • The NTDS Settings object: Each server object that represents a domain controller has a child NTDS Settings object, which identifies the domain controller as having Active Directory installed. The NTDS Settings object must be present for the server to be considered as part of the replication topology.

The presence of these objects also determines the site in which the domain controller is to be located. For example, the distinguished name of the NTDS Settings object contains the site to which that domain controller belongs. If the server is physically located in one site but is configured for another site in Active Directory, the KCC uses the information in Active Directory to construct the topology. Therefore, the improper configuration of servers in sites can affect network bandwidth.

Topology Generation Phases

There are two phases of topology generation. During phase one, the KCC evaluates the current topology, determines whether replication failures have occurred with the existing connections, and constructs whatever new connection objects are required to complete the replication topology. During phase two, the KCC implements, or "translates," the decisions that were made in phase one into agreements between the replication partners.

Phase One: Evaluating the Current Topology and Generating Connection Objects

The topology is evaluated by reading the connection objects. When the KCC notices a connection object, it reads the NTDS Settings object of the source domain controller (indicated by the fromServer value on the connection object) to determine what directory partitions its destination controller has in common with the source domain controller. The hasMasterNCs attribute (where "NC" stands for "naming context," a synonym for "directory partition") of an NTDS Settings object contains the set of writable (non-Global Catalog) directory partitions that are located on that domain controller. The hasPartialReplicaNCs attribute contains the set of partial-replica directory partitions (Global Catalog partitions) that are located on that domain controller. For each directory partition that the two domain controllers have in common and that matches the full and partial characteristics of a replication source, the KCC creates (or updates) a replication agreement.

note-iconNote

Within a site, all KCCs generate connection objects for replication within the site. When there is more than one site, a single KCC in each site generates all connection objects for replication between sites.

Phase Two: Translating Connections

In phase two, all KCCs process their connection objects and translate them into connection agreements between pairs of domain controllers. At specified intervals, Active Directory replicates data from one replication partner to the other for directory partitions that they have in common. These replication agreements do not appear in the administrative tools. They are used internally by the replication engine to track the directory partitions that are to be replicated from specified servers.

For example, suppose that you define a connection object between two domain controllers from different domains. In phase two, assuming that neither of these domain controllers is a Global Catalog server, the KCC identifies the only two directory partitions that the domain controllers have in common — the schema directory partition and the configuration directory partition. If you create a connection object that links domain controllers in the same domain, at least three directory partitions are replicated: the schema directory partition, the configuration directory partition, and the domain directory partition.

In contrast, if the connection object is established between two domain controllers that are Global Catalog servers, a partial replica of each directory partition (which includes only specified attributes) in the forest is replicated between the two domain controllers.

Intervals at Which the KCC Runs

The KCC evaluates the replication topology at specified intervals, which can be modified.

By default, the KCC runs its first replication topology check five minutes after the domain controller starts. This interval can be modified by changing the Repl   topology update delay (secs) entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters as follows:

Value: Number of seconds to wait between the time Active Directory starts and the KCC runs for the first time.

Default: 300 seconds (5 minutes)

Data type: REG_DWORD

By default, as long as services are running, the KCC checks the topology every 15 minutes and makes changes as necessary. The administrator can modify the interval at which the KCC performs this review by changing the Repl topology update period (secs) entry in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters as follows:

Value: Number of seconds between KCC topology updates

Default: 900 seconds (15 minutes)

Data type: REG_DWORD

caution-iconCaution

Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. There are programs available in Control Panel or Microsoft Management Console (MMC) for performing most administrative tasks. These programs provide safeguards that prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Registry editors bypass the standard safeguards that are provided by these administrative tools. Modifying the registry is recommended only when no administrative tool is available. Before you make changes to the registry, it is recommended that you back up any valuable data on the computer. For instructions about how to edit registry entries, see Help for the registry editor that you are using. For more information about the registry, see the Microsoft Windows   2000 Resource Kit Technical Reference to the Windows 2000 Registry (Regentry.chm).

Automated Replication Topology Generation Within a Site

During topology creation within a site, KCC activity includes topology translation and topology generation. The KCC "translates" the information provided by an algorithm and then creates (generates) connection objects that implement the topology that is dictated by the translation. In general, topology translation and generation are accomplished as follows:

  • The KCC on each domain controller runs an algorithm to determine the topology for replication within its site. All servers in the same site have the same information about each other, so they all deduce the same topology.

  • The KCC creates the connection objects for servers from which the domain controller receives data (source servers), as dictated by the algorithmically generated topology.

  • The sum total of the connection objects for all servers is the desired topology.

By listing and sorting the domain controllers that hold replicas of the same partition, the topology is generated and then optimized to minimize the number of hops.

Forced Topology Generation

Topology generation creates the topology for replication within a site automatically. Topology generation occurs on a schedule that determines how often the KCC runs. Topology generation can also be started manually by right-clicking the NTDS Settings object, clicking All Tasks , and then clicking Check Replication Topology .

Simplified Ring Topology Generation

An overly simplified process for creating the topology for replication within a site begins as follows:

  • The KCC generates a list of all servers in the site that hold that directory partition.

  • These servers are connected in a ring.

  • For each neighboring server in the ring from which the current domain controller is to replicate, the KCC creates a connection object if one does not already exist.

This simple approach guarantees a topology that tolerates a single point of failure. If a domain controller is not available, it is not included in the ring that is generated by the list of servers because its NTDS Settings object is not available. However, this topology, with no other adjustments, accommodates only seven servers. Beyond this number, the ring would require more than three hops for some servers.

The simplest case scenario — seven or fewer domain controllers, all in the same domain and site — would result in the topology shown in Figure 6.17. Even if one or all of these domain controllers were Global Catalog servers, when the KCC runs on those particular computers, no extra connections would be necessary. The only directory partitions to replicate are a single domain directory partition, the schema directory partition, and the configuration directory partition. Those topologies are generated first, and at that point, sufficient connections to replicate each directory partition have already been created.

Cc961781.DSBH14(en-us,TechNet.10).gif

Figure 6.17 Simple Ring Topology That Requires No Optimization

Because a ring topology is created for each directory partition, the topology might look different if domain controllers from a second domain were present in the site. Figure 6.18 illustrates the topology for domain controllers from two domains in the same site with no Global Catalog servers defined in the site.

Cc961781.DSBH15(en-us,TechNet.10).gif

Figure 6.18 Ring Topology for Two Domains in a Site That Has No Global Catalog Server

note-iconNote

The examples in Figure 6.18 and Figure 6.19 are designed to illustrate only how the KCC creates connections, not how to configure a site. A Global Catalog server is a requirement for logging on to a domain, and for this reason, it is advisable to have at least one Global Catalog server in a site. If a Global Catalog server is not available in a site and there is a Global Catalog server in a remote site, the server in the remote site can be used for the logon process. If no Global Catalog is available in any site, the logon process proceeds with cached logon information. (For more information about Global Catalog support for logging on to domains, see "Active Directory Logical Structure" in this book.)

Expanded Ring Topology

When the number of servers grows beyond seven, the KCC estimates the number of connections that are needed so that if a change occurs at any one domain controller, there are as many replication partners as needed to ensure that no domain controller is more than three replication hops from another domain controller (that is, a change takes no more than three hops before it reaches another domain controller that has already received the change by another path). These optimizing connections are created at random and are not necessarily created on every third domain controller.

In Figure 6.19, there is no Global Catalog server in the site, all domain controllers are in the same domain, but enough servers have been added to require optimizing connections. Although they are located in the same domain and site, Domain Controller A and Domain Controller B are more than three hops away from each other. The optimizing connections for the domain, schema, and configuration directory partitions that might be created from Domain Controller A to Domain Controller B are depicted as a single straight line in the diagram for readability, but in reality, these partitions are replicated separately as shown between the neighboring replication partners. There would also be more optimizing connections than the one shown.

Cc961781.DSBH16(en-us,TechNet.10).gif

Figure 6.19 Optimized Connections for Ten Domain Controllers in the Same Domain in a Single Site

Figure 6.20 illustrates the connections required between a Global Catalog domain controller and three other domains to which it does not belong. When a Global Catalog server is added to the site, additional connections are required to replicate copies of the directory partitions to the domains to which the Global Catalog server does not belong. Because the reskit.com domain has only seven servers, no optimizing connections are required in the replication topology for the reskit.com directory partition. However, the Global Catalog server is the source for each domain directory partition in the forest, and in this example, the KCC has created connection objects to replicate from domain controllers for each of those domain directory partitions within the site. Wherever a domain directory partition is replicated, the KCC also uses the connection to replicate the schema and configuration directory partitions.

note-iconNote

Connection objects are generated independently for the configuration and schema directory partitions (one connection) and for the separate domain directory partitions, unless a connection from the same source to destination domain controllers already exists for one directory partition, in which case the same connection is used for both (a duplicate connection is not created).

Cc961781.DSBH17(en-us,TechNet.10).gif

Figure 6.20 Optimized Connections That Are Required for Site That Has Four Domains and a Global Catalog Server

Optimized Ring Topology Connections Within a Site

Connections are added to optimize a ring topology within a site on the basis of the answer to the following question:

Given a set of nodes in a ring, what is the minimum number of connections, n , that each server must have to ensure a path of no more than three hops to another server?

Given n , topology generation proceeds as follows.

If the local server does not have n extra connections, do the following:

  • Choose n other servers randomly in the site as source servers.

  • For each of those servers, create a connection object.

This approach approximates the minimum-hop goal of three servers. In addition, it grows well, because as the site grows in server count, old optimizing connections are still useful and are not removed. Also, every time an additional 9 to 11 servers are added, a connection object is deleted at random; then a new one is created, ideally having one of the new servers as its source. This process ensures that, over time, the extra edges are distributed well over the entire site.

Excluded Nonresponding Servers

The KCC automatically rebuilds the replication topology when it recognizes that a domain controller has failed or is unresponsive.

The criteria that the KCC uses to determine when a domain controller is not responsive depend upon whether the server computer is within the site or not. Two thresholds must be reached before a domain controller is declared "unavailable" by the KCC:

  • The requesting domain controller must have made n number of attempts to replicate from the target domain controller.

    • For replication between sites, the default value is 1 attempt.

    • For replication within a site, the following distinctions are made between the two immediate neighbors (in the ring) and the optimizing connections:

    For immediate neighbors, the default value is 0 failed attempts. (Thus, as soon as an attempt fails, a new server is tried.)
    For optimizing connections, the default value is 1 failed attempt. (Thus, as soon as a second failed attempt occurs, a new server is tried.)

  • A certain amount of time must pass since the last successful replication attempt.

    • For replication between sites, the default time is 2 hours.

    • For replication within a site, a distinction is made between the two immediate neighbors (in the ring) and the optimizing connections:

    For immediate neighbors, the default time is 2 hours.
    For optimizing connections, the default value is 12 hours.

To modify the thresholds for excluding nonresponding servers, use the following registry entries in HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, with the data type REG_DWORD. You can modify these values to any desired value as follows:

For replication between sites, use the following entries:

  • IntersiteFailuresAllowed
    Value: Number of failed attempts
    Default: 1

  • MaxFailureTimeForIntersiteLink (secs)
    Value: Time that must elapse before being considered stale, in seconds
    Default: 7200 (2 hours)

For optimizing connections within a site, use the following entries:

  • NonCriticalLinkFailuresAllowed
    Value: Number of failed attempts
    Default: 1

  • MaxFailureTimeForNonCriticalLink
    Value: Time that must elapse before considered stale, in seconds
    Default: 43200 (12 hours)

For immediate neighbor connections within a site, use the following entries:

  • CriticalLinkFailuresAllowed
    Value: Number of failed attempts
    Default: 0

  • MaxFailureTimeForCriticalLink
    Value: Time that must elapse before considered stale, in seconds
    Default: 7200 (2 hours)

caution-iconCaution

Editing the registry directly can have serious, unexpected consequences that can prevent the system from starting and require that you reinstall Windows 2000. There are programs available in Control Panel or Microsoft Management Console (MMC) for performing most administrative tasks. These programs provide safeguards that prevent you from entering conflicting settings or settings that are likely to degrade performance or damage your system. Registry editors bypass the standard safeguards that are provided by these administrative tools. Modifying the registry is recommended only when no administrative tool is available. Before you make changes to the registry, it is recommended that you back up any valuable data on the computer. For instructions about how to edit registry entries, see Help for the registry editor that you are using. For more information about the registry, see the Microsoft Windows   2000 Resource Kit Technical Reference to the Windows 2000 Registry (Regentry.chm).

When the original domain controller begins responding again, the KCC automatically restores the replication topology to its pre-failure condition the next time that the KCC runs.

Fully Optimized Ring Topology Generation

Taking the addition of extra connections, management of nonresponding servers, and growth-management mechanisms into account, the fully optimized intrasite topology generation proceeds and the appropriate connection objects are created and deleted according to the available criteria.

note-iconNote

Connection objects from nonresponding servers are not deleted because the condition is expected to be transient.

The following key points characterize the optimized approach to topology generation:

  • Sorting the servers ensures that each server arrives at the same desired topology.

  • Intrasite topology generation never creates or deletes connection objects that are not directly under the NTDS Settings object for the local domain controller.

Automated Intersite Topology Generation

Topology generation for replication between sites is more complex than for replication within a site because Windows 2000 supports replication between sites over asynchronous transport (SMTP). Therefore, whereas for intrasite topology generation the KCC can assume that any server can replicate to any other server, the same assumption cannot be made for replication between sites.

Intersite Topology Generator Role

A fundamental concept in the generation of the topology within a site is that each server does its part to create a sitewide topology. In a similar manner, the generation of the topology between sites depends on each site doing its part to create a forest-wide topology between sites. As part of this effort, one domain controller per site assumes the role of the intersite topology generator. The KCC on this domain controller is responsible for creating the connections between the domain controllers in its site and the domain controllers in other sites, which includes specifically the inbound replication connection objects for all bridgehead servers in the site in which the domain controller is located.

After the intersite topology generator assesses the topology and determines that its own site is the only site, it performs no further processing because no connections between sites are possible for the current configuration.

Generation of Connections Between Sites vs. Generation of Connections Within a Site

Connection objects between bridgehead servers for replication between sites and connection objects for connections within a site are created differently.

When the KCC on each domain controller generates the intrasite topology for the site in which it resides, the KCC creates a connection object in Active Directory only when a connection object is required for the local computer. This change propagates to other domain controllers through the normal replication process. Each domain controller uses the same algorithm to compute the replication topology; in a state of equilibrium between domain controllers, each domain controller arrives at the same result with respect to what the replication topology should be. In the process, each domain controller creates its own connection objects.

For connections between sites, in each site, the KCC that has the intersite topology generator role (regardless of the domain) is responsible for reviewing the intersite topology and creating inbound replication connection objects as necessary for bridgehead servers in the site in which it resides.

When the intersite topology generator determines that a connection object needs to be modified on a specific bridgehead server in the site, the intersite topology generator makes the change to its local Active Directory copy. These changes propagate to the bridgehead servers in the site as part of normal replication within the site. When the KCC on the bridgehead server reviews the topology after receiving these changes, it translates the connection objects into replication agreements (replication partners) that Active Directory uses to replicate data from remote bridgehead servers.

Bridgehead Server Selection

As the KCC constructs the intersite topology for each directory partition, the servers in each site are evaluated for becoming bridgehead servers. If preferred bridgehead servers are configured, these servers are the candidates for selection. Otherwise, all domain controllers in the site that host the directory partition and can communicate over a specific transport are candidates for becoming a bridgehead server. In either case, the first domain controller that meets the requirements becomes the bridgehead server. All preferred bridgehead servers in the same site that are configured for the same transport are considered to be equal. In a state of equilibrium of the configuration directory partition, the intersite topology generator from each site selects the same bridgehead server, given the same requirements. For example, if the same bridgehead server (either preferred or automatically selected) is capable of replication over the IP transport and holds the requested directory partition, that server is selected by bridgehead servers from other sites that require the same directory partition data.

If preferred bridgehead servers are defined for a specific site and all of the servers specified are unavailable, no failover is performed to the other domain controllers in the site, even if they can act as bridgehead servers. The same is true in the case where no preferred bridgeheads are specified and where all domain controllers that can act as a bridgehead for the required data are unavailable.

Intersite Topology Generator Role Owner

The current owner of the intersite topology generator role is communicated through the normal Active Directory replication process. Initially, the first domain controller in the site becomes the intersite topology generator for the site. The role does not change as additional domain controllers are added to the site until the current intersite topology generator becomes unavailable.

To determine the intersite topology generator role owner for a site

  1. In Active Directory Sites and Services, click the site object.

  2. In the details pane, right-click the NTDS Site Settings object, and then click Properties . The current role owner appears in the Server box under Inter-Site Topology Generator .

note-iconNote

You cannot change the intersite topology generator role.

Intersite Topology Generator Role Owner Notification

At 30-minute intervals, the current intersite topology generator notifies every other domain controller in the site of its existence by writing the attribute interSiteTopologyGenerator on the NTDS Settings object under its domain controller object in the configuration directory partition.

As the interSiteTopologyGenerator 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. If a period of 60 minutes elapses without a modification, a new intersite topology generator takes over.

Establishing a New Intersite Topology Generator

When a new intersite topology generator is required, each domain controller requests the list of servers in the site in ascending order. The domain controller that takes over the role is the one that is next in the list of servers after the current owner. This domain controller then writes the interSiteTopologyGenerator attribute and performs the necessary KCC processes to manage inbound connection objects for bridgehead servers.

When there are two domain controllers in the site that appear to own the intersite topology generator role, there might be a temporary state of inbound replication connection objects being created by both computers. However, after replication occurs and all domain controllers receive the change that identifies the new intersite topology generator, the KCC on the intersite topology generator adjusts the topology.

Intersite Topology Generator and Modified Connections

It is possible for a connection object to be modified by an administrator on one domain controller and be modified subsequently by the KCC on another domain controller prior to the initial change being replicated. Overwriting such a change can occur within the local site or when a connection object changes in a remote site. By default, the KCC runs every 15 minutes. If the connection object change is not replicated to another domain controller before the KCC on that domain controller runs, the KCC on that domain controller might modify the same connection object. In this case, ownership of the connection object belongs to the KCC because the latest write to the connection object is the write that is applied.

To ensure that modification of an intersite connection object is not overwritten by the KCC, make the modification on the computer that has the intersite topology generator role in the site of the modified connection object.