How to Optimize Active Directory Replication in a Large Network

ID: Q244368


The information in this article applies to:
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Datacenter Server
  • Microsoft Windows 2000 Server

IMPORTANT: This article contains information about editing the registry. Before you edit the registry, make sure you understand how to restore it if a problem occurs. For information about how to do this, view the "Restoring the Registry" Help topic in Regedit.exe or the "Restoring a Registry Key" Help topic in Regedt32.exe.

SUMMARY

This article describes how to optimize Active Directory replication in large network configurations.


MORE INFORMATION

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry Editor can be solved. Use Registry Editor at your own risk.

For information about how to edit the registry, view the "Changing Keys and Values" Help topic in Registry Editor (Regedit.exe) or the "Add and Delete Information in the Registry" and "Edit Registry Data" Help topics in Regedt32.exe. Note that you should back up the registry before you edit it. If you are running Windows NT, you should also update your Emergency Repair Disk (ERD).
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:
  1. Determine which domain controller in the site is the current inter-site topology generator by viewing the properties of the NTDS Site Settings object.


  2. Time the execution of the KCC on that domain controller:

    1. Right-click NTDS Settings.


    2. 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. For additional information about Event Logging in Windows 2000, click the article number below to view the article in the Microsoft Knowledge Base:
Q220940 Enabling Diagnostic Event Logging for Active Directory Services

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


  2. 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:
  1. Double-click the Active Directory Sites and Services snap-in.


  2. Right-click the IP transport object, and then click Properties.


  3. 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, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose. This article assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures. Microsoft support professionals 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 needs. If you have limited programming experience, you may want to contact a Microsoft Certified Solution Provider or the Microsoft fee-based consulting line at (800) 936-5200. For more information about Microsoft Certified Solution Providers, please see the following page on the World Wide Web:

http://www.microsoft.com/mcsp/
For more information about the support options available from Microsoft, please see the following page on the World Wide Web:

http://www.microsoft.com/support/supportnet/overview/overview.asp
'*/ 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.domain controllerfunctions")
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
domain controllerSiteName=dll.dsgetsitename
if err.number <> 0 then ReportError:Wscript.Quit
wscript.echo "4> The site for this server is: " + domain controllersitename

'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="+domain controllerSiteName+",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(domain controllerSiteName) + " 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 additional information about the Windows 2000 KCC, click the article numbers below to view the articles in the Microsoft Knowledge Base:
Q242780 Disabling KCC From Automatically Creating Replication Topology
Q224815 The Role of the Inter-Site Topology Generator
Q214745 Troubleshooting Event ID 1311: Knowledge Consistency Checker

Additional query words: kbfaqw2kds

Keywords : kbnetwork kbtool ntdomain
Version : WINDOWS:2000
Platform : WINDOWS
Issue type : kbinfo


Last Reviewed: January 31, 2000
© 2000 Microsoft Corporation. All rights reserved. Terms of Use.