Article ID: 244368
Article Last Modified on 3/2/2007
APPLIES TO
- Microsoft Windows 2000 Server
- Microsoft Windows 2000 Advanced Server
- Microsoft Windows 2000 Datacenter Server
This article was previously published under Q244368
Important This article contains information about how to modify the registry. Make sure to back up the registry before you modify it. Make sure that you know how to restore the registry if a problem occurs. For more information about how to back up, restore, and modify the registry, click the following article number to view the article in the Microsoft Knowledge Base:
256986 Description of the Microsoft Windows registry
SUMMARY
This article describes how to optimize Active Directory replication in large network configurations.
MORE INFORMATION
Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk. The Knowledge Consistency Checker (KCC) dynamically adjusts the data replication topology of your network when domain controllers are added to or removed from the network, when a domain controller is unavailable, or when the data replication schedules are changed.
The tasks of the KCC are:
- Based on the network topology described by Active Directory objects, the KCC creates connection objects which are used to 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.
- Convert the KCC-defined and administrator-defined Microsoft Windows NT Directory Service Connection (ntdsConnection) objects into a configuration understood by the Directory Service (DS) replication engine.
By default, each of these tasks is executed every 15 minutes. For more information about the KCC, please see the Active Directory Replication chapter in the Windows 2000 Resource Kit.
Example
In some large site configurations containing many sites, many domains, or many routes betweens sites, the inter-site KCC executes slowly, consuming too much Central Processing Unit (CPU) time and memory resources.
If D is the number of domains in your network, S is the number of sites in your network, and
(1 + D) * S^2 <= 100,000
then you can safely ignore the rest of this article.
The following table lists the execution times and memory consumption figures for an inter-site KCC running in a variety of hub-and-spoke configurations with no performance tuning applied. Each site contains a domain controller for a single domain and a global catalog. Domains are equally dispersed across the sites. Automatic site-link bridging is enabled. Measurements were made on an Intel Pentium III Xeon at 500MHz with 1 gigabyte (GB) of Random Access Memory (RAM). Memory usage includes database caching. Memory consumption will be lower on computers with less physical memory.
| Location | # Sites | # Domains | Time Elapsed (h:m:s) | Memory Usage in K |
|---|---|---|---|---|
| Satellite | 125 | 1 | 0:00:12 | 11748 |
| Hub | 125 | 1 | 0:00:21 | 12256 |
| Satellite | 250 | 1 | 0:00:41 | 45660 |
| Hub | 250 | 1 | 0:01:05 | 44820 |
| Satellite | 500 | 1 | 0:02:56 | 173216 |
| Hub | 500 | 1 | 0:04:34 | 174752 |
| Satellite | 1000 | 1 | 0:15:23 | 685596 |
| Hub | 1000 | 1 | 0:17:34 | 688568 |
| Satellite | 1000 | 1 | 0:15:54 | 685604 |
| Hub | 1000 | 1 | 0:17:51 | 689668 |
| Satellite | 125 | 10 | 0:00:59 | 58520 |
| Hub | 125 | 10 | 0:01:19 | 58536 |
| Satellite | 250 | 10 | 0:04:00 | 228304 |
| Hub | 250 | 10 | 0:04:47 | 227508 |
| Satellite | 500 | 10 | 0:21:32 | 815916 |
| Satellite | 500 | 10 | 0:19:41 | 823808 |
| Hub | 500 | 10 | 0:21:18 | 828484 |
| Satellite | 125 | 50 | 0:04:49 | 266088 |
| Hub | 125 | 50 | 0:05:54 | 264024 |
| Satellite | 250 | 50 | 0:20:19 | 831924 |
| Hub | 250 | 50 | 0:22:49 | 841536 |
The formula for the execution time is:
(1 + num domains) * num sites ^ 2 * 0.0000075 minutes
You can determine how long the KCC runs in your existing configuration using the Active Directory Sites and Services snap-in:
- Determine which domain controller in the site is the current inter-site topology generator by viewing the properties of the NTDS Site Settings object.
- Time the execution of the KCC on that domain controller:
- Right-click NTDS Settings.
- Click Check Replication Topology.
Also, you can monitor the execution time of the KCC on an on-going basis by using Registry Editor to view the following registry key:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Diagnostics
Change the "1 Knowledge Consistency Checker" value to a value of 3 or greater.
With this value set to 3 or greater, the KCC will log events 1009 and 1013 to signify the beginning and end of the check.
Recommendations
If your configuration does not satisfy the above criteria, then use the appropriate method:
Reduce Use of Site-Link Bridges in Your Site Configuration
This option works well in typical hub and spoke configurations by reducing the number of potential routes between sites.
Automatic site-link bridging indicates the entire network is fully Internet Protocol (IP) routed. In this situation, any computer in a given site can communicate over IP with any computer in any other site. Automatic site-link bridging is enabled for both the IP and Simple Mail Transport Protocol (SMTP) inter-site transports by default. Disabling this feature requires that you add explicit site-link bridge objects where needed. Site-link bridges are necessary only if a particular site contains a domain controller of a domain that is not present in any adjacent site, but another domain controller of that domain does occur in other sites in the forest. An adjacent site is defined to be any site included in any site link containing the site in question. Most configurations do not require the use of site-link bridges, because any site holding a domain controller of a given domain that occurs in more than one site is almost always adjacent to at least one other site containing a domain controller of the same domain.
If KCC is unable to directly or transitively connect all the sites containing domain controllers of a particular domain after you disable automatic site-link bridging, the KCC will log event 1311.
Example
The Directory Service consistency checker has determined that either:
- There is not enough physical connectivity published by using the Active Directory Sites and Services Manager to create a spanning tree connecting all the sites in the forest.
- Replication cannot be performed with one or more critical servers for changes to propagate across all sites. This is most often due to the servers being unreachable.
To resolve issue A, use the Active Directory Sites and Services Manager to do one of the following:
- Publish sufficient site connectivity information such that the computer can infer a route by which this partition can reach this site. This option is preferred.
- Add an ntdsConnection object to a domain controller that contains the partition domain controller=europe,domain controller=mycorp,domain controller=com in this site from a domain controller that contains the same partition in another site.
To resolve issue B, examine the current event log to determine which server or servers could not be contacted by the KCC.
To disable automatic site-link bridging:
- Double-click the Active Directory Sites and Services snap-in.
- Right-click the IP transport object, and then click Properties.
- In the Inter-Site Transports container, click the appropriate check box to clear it, and then click OK.
There are still limits to the configurations for which the KCC can automatically calculate an inter-site topology, even when no site-link bridging is being used. The following table lists the execution times and memory consumption figures for the inter-site KCC running in a variety of hub-and-spoke configurations. Each site contains a domain controller of a single domain and a global catalog (GC). Domains are equally dispersed across the sites. Automatic site-link bridging is disabled, and no site-link bridges have been defined. Measurements were made on an Intel Pentium III Xeon at 500MHz with 1GB of RAM; execution times on Intel Pentium II 200MHz processors are about double those listed. Memory usage includes database caching. Memory consumption will be lower on computers with less physical memory.
| Location | # Sites | # Domains | Time Elapsed (h:m:s) | Memory Usage in K |
|---|---|---|---|---|
| Satellite | 1002 | 1 | 0:01:27 | 31380 |
| Hub | 1002 | 1 | 0:04:46 | 33352 |
| Satellite | 502 | 1 | 0:00:35 | 9980 |
| Hub | 502 | 1 | 0:01:58 | 11540 |
| Satellite | 252 | 1 | 0:00:23 | 4072 |
| Hub | 252 | 1 | 0:00:54 | 4112 |
| Satellite | 127 | 1 | 0:00:10 | 1464 |
| Hub | 127 | 1 | 0:00:26 | 2052 |
| Satellite | 1002 | 50 | 0:39:42 | 92160 |
| Hub | 1002 | 50 | 1:21:30 | 85392 |
| Satellite | 502 | 50 | 0:11:33 | 42456 |
| Hub | 502 | 50 | 0:26:26 | 37384 |
| Satellite | 252 | 50 | 0:03:32 | 15292 |
| Hub | 252 | 50 | 0:09:36 | 18408 |
| Satellite | 127 | 50 | 0:01:15 | 7364 |
| Hub | 127 | 50 | 0:04:05 | 9324 |
| Satellite | 1002 | 10 | 0:09:00 | 50752 |
| Hub | 1002 | 10 | 0:19:04 | 60956 |
The formula for the execution time for satellite sites is
(1 + number of domains) * number of sites * 0.0006 minutes
where number of domains is the number of domains, and number of sites is the number of sites.
The formula for hub sites is:
(1 + number of domains) * number of sites * 0.0015 minutes
Run the Inter-site KCC Only During Off Peak Hours
This option works well when the computer has a time slot when little work is being done, and an inter-site KCC run fits within this time slot. This technique would typically be used only if the use of site-link bridging has already been reduced, and the execution time or memory usage of the KCC remains a problem during critical business hours.
The KCCs in a given site can be configured to disable only the inter-site topology calculation, maintaining their ability to respond to changing replication requirements within the site. The inter-site topology calculation can then be re-enabled at a specific time of day just long enough for a KCC in the site to run the inter-site check and can then be disabled again.
When the inter-site topology check is disabled for a particular site, that site will not respond to changes in the inter-site topology. If one or both replication partners for all inter-site connections that replicate a given domain are unavailable, no KCC automatic adaptation to a new source or destination will be done until the domain controllers come back online or the inter-site portion of the KCC is run again.
NOTE: The administrator can manually add connections while the inter-site KCC is disabled.
To evaluate whether this option is realistic in your configuration, first determine how long the KCC takes to run in your environment. Then determine if there is a block of time on one domain controller in each site to accommodate the time and memory requirements. It is not necessary for the inter-site portion of the KCC to be run in all sites at the same time.
To schedule the inter-site KCC, use the Task Scheduler component to schedule executions of "wscript /b runkcc.vbs" (the script in text form is included later in this article). For more information about Task Scheduler, refer to the Task Scheduler topic in Windows 2000 Help. Runkcc.vbs requires the support tools in the Support\Tools folder in the Windows 2000 CD-ROM to be installed on the computer on which it is run.
Disable Inter-Site KCC Entirely, Manually Configure Connections
This option works well in typical hub-spoke configurations. It is typically used only when the two previous methods are not viable options, especially in configurations with thousands of sites.
When automatic inter-site topology is disabled entirely, it becomes the responsibility of the administrator to create the necessary inter-site replication connection objects to ensure that replication data continues to flow across the forest. Typically, customers with enough sites to surpass the KCC limits employ hub-and-spoke network topologies to connect a corporate headquarters with a large number of homogeneous branch office sites. This symmetry greatly simplifies the process.
Before creating your own connection objects without the help of the KCC, there are several points to consider:
- Server failures. Consider the case where 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 inter-site topology is enabled, the KCC takes care of adding an additional connection to temporarily replicate from another domain controller in the corporate hub site until HQ1 returns online. Without automatic inter-site topology generation, to ensure that replication continues to occur in cases of server failures, redundant connections must be defined. Define 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, then the second connection should be from HQ2 to BR2. This allows updates to be replicated from the corporate hub site in the event that one of the two branch office domain controllers fails.
Redundant connections defined in this manner may force the same Active Directory updates to be replicated more than once unless the IP transport is being used and all connections inbound to the site have the same destination domain controller within the site. When using the SMTP transport or multiple destination domain controllers, the replication schedule should be interleaved such that the updates from one source are received, applied, and replicated within 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 replicate on even hours.
- Global Catalog placement. If a site contains GCs, one or more of the GCs must be used for replication to and from the site. If this is not done, then GCs 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 is replicated 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 GC in site 2 if site 2 contains a domain controller for domain A. Because the domain B GC 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, you do not want to configure all 1000 branch office domain controllers to replicate from the same domain controller in your hub site. Instead, load balance such that each domain controller in the corporate hub communicates with 10 branch office sites. Since 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 will not only increase the CPU and memory load on the hub site domain controller, but this 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 can then be adapted by an administrator. If the inter-site KCC is not to be run periodically thereafter, then the administrator must define additional replication connections so that replication continues to function in the event of failure of the source domain controller identified by the first connection. If all existing connections fail and the inter-site KCC is not re-run, the administrator must connect directly to the target domain controller and create a connection to a domain controller that is reachable. In configurations with high volatility (when the optimal source domain controllers are occasionally unavailable for long periods of time due to network failures) it is advisable to have more than one extra connection.
Runkcc.vbs (VBScript to Trigger the One-time Run of the KCC)
Microsoft provides programming examples for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. This article assumes that you are familiar with the programming language that is being demonstrated and with the tools that are used to create and to debug procedures. Microsoft support engineers can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific requirements. '*/ runkcc.vbs
'*/
'*/ Parameters: <none>
'*/ Purpose: When run on a domain controller, this script makes the local domain controller the Inter-Site
'*/ Topology Generator for its site, enables inter-Site topology generation temporarily if it is disabled,
'*/ runs the KCC topology generation process, and disables inter-site topology generation if it was
'*/ configured so to begin with.
'*/
'*/
On Error Resume Next
Call ExecuteKCC()
Public Sub ReportError ()
'tell the user the error
wscript.Echo "The following error occurred: (" + cstr(hex(err.number)) +") " + cstr(err.description)
End Sub
Public Sub ExecuteKCC ()
On Error Resume Next
wscript.echo "Loading functions for use by this script..."
set dll=createobject("iadstools.DCFunctions")
if err.number <> 0 then ReportError:WScript.Quit
dll.enabledebuglogging 1
'get the local box name
wscript.echo "1> Connecting to local machine..."
set localMachine=GetObject("LDAP://localhost/rootdse")
if err.number <> 0 then ReportError:Wscript.Quit
ServerName=localmachine.get("dnsHostName")
if err.number <> 0 then ReportError:WScript.Quit
wscript.echo "2> Found local machine " + ucase(ServerName)
'get the config NC
configNC=localMachine.get("configurationNamingContext")
if err.number <> 0 then ReportError:Wscript.Quit
wscript.echo "3> Configuration Naming Context is: " + configNC
'get the SiteName of this box
domaincontrollerSiteName=dll.dsgetsitename
if err.number <> 0 then ReportError:Wscript.Quit
wscript.echo "4> The site for this server is: " + domaincontrollersitename
'get the DSA DN for this box
DSAObj = localMachine.get("dsServiceName")
if err.number <> 0 then ReportError:Wscript.Quit
wscript.echo "5> The DN for this machine's DSA is: " + DSAObj
'bind to the Site Settings object in the Directory
SiteSettingsPath="LDAP://localhost/CN=NTDS Site Settings,CN="+domaincontrollerSiteName+",CN=Sites,"+configNC
set SiteSettings=GetObject(SiteSettingsPath)
if err.number <> 0 then ReportError:WScript.Quit
'make the current box the ISTG
wscript.echo "6> Making " + ucase(ServerName) + " the Inter Site Topology Generator for the " + ucase(domaincontrollerSiteName) + " site."
SiteSettings.Put "interSiteTopologyGenerator",DSAObj
SiteSettings.SetInfo
if err.number <> 0 then ReportError:Wscript.Quit
'get the current options
origOptions=SiteSettings.Get("options")
if hex(err.number) = "8000500D" then
origOptions=0
elseif err.number=0 then
'do nothing
else
ReportError:Wscript.Quit
end if
modOptions=origOptions
wscript.echo "7> Currently, the options specified for KCC operations for the ISTG in this site is set to: " + cstr(origOptions)
'enable the KCC if currently disabled, otherwise, leave it alone
if modOPtions And 16 then
mod2Options=modOptions XOr 16
wscript.echo "8> The KCC is currently disabled for inter-site topology generation. Temporarily re-enabling it. Setting options to: "+ cstr(mod2Options)
SiteSettings.Put "options", mod2Options
SiteSettings.SetInfo
if err.number <> 0 then
ReportError
wscript.echo "An error occurred during the process of modifying the options attribute. Check to make sure that it has the correct original value. This script is terminating."
Wscript.Quit
end if
else
wscript.echo "8> The KCC is currently enabled to handle inter-site topology generation. No change is necessary before triggering the KCC."
end if
'run the KCC
Result=dll.TriggerKCC(cstr(ServerName))
if err.number > 0 then ReportError
If result=0 then
wscript.echo "9> The KCC was successfully triggered on " + ucase(ServerName)
else
wscript.echo "9> The following error occurred trigerring the KCC on " + ucase(ServerName) + ": " + dll.lasterrortext
end if
'disable the KCC
wscript.echo "10> Re-writing the original options (" + cstr(origOptions) + ") to the ISTG."
SiteSettings.Put "options", origOptions
SiteSettings.SetInfo
if err.number <> 0 then ReportError:WScript.Quit
End Sub
'end script
For more information about the Windows 2000 KCC, click the following article numbers to view the articles in the Microsoft Knowledge Base:
242780 Disabling KCC from automatically creating replication topology
224815 The role of the Inter-Site Topology Generator
214745 Troubleshooting Event ID 1311: Knowledge Consistency Checker
Keywords: kbinfo kbnetwork KB244368
