AD DS: The KCC should be enabled in this site in this forest to generate an optimal replication topology
Updated: August 31, 2012
Applies To: Windows Server 2008 R2, Windows Server 2012
This topic is intended to address a specific issue identified by a Best Practices Analyzer scan. You should apply the information in this topic only to computers that have had the Active Directory Domain Services Best Practices Analyzer run against them and are experiencing the issue addressed by this topic. For more information about best practices and scans, see Best Practices Analyzer (https://go.microsoft.com/fwlink/?LinkId=122786).
Windows Server 2008 R2
Windows Server 2012
Active Directory Domain Services (AD DS)
The Knowledge Consistency Checker (KCC) is disabled in this site.
If the KCC in this site is disabled, you must create replication connections manually to tailor the replication topology. This can increase the workload with regard to monitoring changes in the network topology, or it can cause replication failures on domain controllers.
The KCC is a built-in process that automatically generates and maintains the intrasite and intersite replication topology in Active Directory forests. The KCC runs at regular intervals to adjust the replication topology for changes that occur in AD DS, such as adding new domain controllers and new sites. At the same time, the KCC reviews the replication status of existing connections to determine if any connections are not working. If a connection is not working, after a threshold is reached, KCC automatically builds temporary connections to other replication partners (if they are available) to ensure that replication is not blocked.
The KCC adjusts the replication topology dynamically when domain controllers are added to or removed from the network; when a domain controller is not available; when site links are created, removed, or modified; or when the data replication schedules change.
The KCC tasks are as follows. By default, each of these tasks runs every 15 minutes:
Based on the network topology that the Active Directory objects describe, the KCC creates connection objects that define inbound and outbound replication to domain controllers:
For sources within the same site, inbound to the domain controller on which the KCC is running
For sources in different sites, inbound to the site in which the KCC is running, if the domain controller on which the KCC is running is the elected interSiteTopologyGenerator for its site
The KCC converts the KCC-defined and administrator-defined Microsoft Windows NT® Directory Service Connection (ntdsConnection) objects into a configuration that the directory service replication engine understands.
The KCC creates connection objects automatically, but they can also be created manually. If you disable the KCC, thus disabling automatic intrasite and intersite replication topology, you must manually create the necessary replication connection objects to ensure that replication data continues to flow across the forest. However, before you create your own connection objects without the help of the KCC, there are several points to consider:
Server failures. Consider a case in which the domain controller BR1 in a branch office site is connected to the domain controller HQ1 in the corporate hub site, and HQ1 undergoes a hardware error, power failure, or some other catastrophic event. When automatic intersite topology is enabled, the KCC adds an additional connection to temporarily replicate from another domain controller in the corporate hub site until HQ1 returns online. Without automatic intersite topology generation, to ensure that replication continues to occur in cases of server failures, redundant connections must be defined—two connections inbound to BR1: one from HQ1 and one from HQ2. If there are two domain controllers in the branch office, BR1 and BR2, the second connection should be from HQ2 to BR2. This makes it possible for updates to replicate from the corporate hub site if one of the two branch office domain controllers fails.
Redundant connections that are defined in this manner may force the same Active Directory updates to replicate more than once unless the IP transport is used and all connections inbound to the site have the same destination domain controller within the site. When you use the Simple Mail Transfer Protocol (SMTP) or multiple destination domain controllers, the replication schedule should be interleaved so that the updates from one source are received, applied, and replicated in the destination site before the request to the second source is made. Extending the example above, the first connection might replicate on odd hours and the second connection might replicate on even hours.
Global catalog placement. If a site contains global catalogs, one or more of the global catalogs must be used for replication to and from the site. If they are not used for replication, the global catalogs will not remain synchronized.
Domain placement. If domain controllers of a particular domain are spread out over multiple sites, one or more domain controllers of that domain must be used for replication with other domain controllers of that same domain. This ensures that domain data replicates across all domain controllers of that domain. It is not sufficient for a domain A domain controller in site 1 to replicate solely with a domain B global catalog in site 2 if site 2 contains a domain controller for domain A. Because the domain B global catalog has only a subset of the attributes for objects in domain A, it cannot act as a conduit to replicate attributes not in this set between the domain A domain controllers.
Load balancing. Distribute the inbound and outbound replication load. For example, if you have 100 domain controllers in your corporate hub site and 1000 branch offices with 1 domain controller each, do not configure all 1000 branch office domain controllers to replicate from the same domain controller in your hub site. Instead, load-balance so that each domain controller in the corporate hub communicates with 10 branch office sites. Because only one inbound replication can occur at a time and communication with branch office sites is often over slow wide area network (WAN) links, failing to load-balance not only increases the CPU and memory load on the hub site domain controller, but it may also result in very large backlogs of data to replicate.
A single run of the KCC can also be used to initially create connections that an administrator can then adapt. If the intersite KCC is not to be run periodically thereafter, the administrator must define additional replication connections so that replication continues to function if the source domain controller that is identified by the first connection fails.
Make sure that the KCC is enabled in this site.
You can use the following procedure to enable the KCC on this domain controller.
Membership in the Enterprise Admins group in the forest or the Domain Admins group in the forest root domain, or equivalent, is the minimum required to complete this procedure. Review details about using the appropriate accounts and group memberships at Local and Domain Default Groups (https://go.microsoft.com/fwlink/?LinkId=83477).
To enable the KCC
Open Active Directory Sites and Services: On the Start menu, point to Administrative Tools, and then click Active Directory Sites and Services.
In the console tree, expand Sites, and then select the site for which you want to enable the KCC.
In the details pane, right-click the NTDS Site Settings object for the selected site, and then click Properties.
In NTDS Site Settings Properties, on the Attribute Editor tab, select the options attribute, and then click Edit.
Note the current hexadecimal value of the options attribute, as well as the list of flags that are currently set for the options attribute.
In Integer Attribute Editor, modify the value of the options attribute by removing the bit flag 0x1 (IS_AUTO_TOPOLOGY_DISABLED) and the bit flag 0x10 (IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED), if they are present, and then click OK twice.
The presence of the IS_INTER_SITE_AUTO_TOPOLOGY_DISABLED flag signifies that intersite topology management is disabled. The presence of the IS_AUTO_TOPOLOGY_DISABLED flag signifies that intrasite topology management is disabled.
For example, if the current value of the **options** attribute is **0x31** and both the flags **IS\_AUTO\_TOPOLOGY\_DISABLED** and **IS\_INTER\_SITE\_AUTO\_TOPOLOGY\_DISABLED** are set, enter **0x20** as the new value for the **options** attribute (0x31 – 0x01 – 0x10 = 0x20).
For more information, see Active Directory Replication Concepts (https://go.microsoft.com/fwlink/?LinkId=148244).