Windows 2000�s Knowledge Consistency Checker (KCC) automatically manages replication within a site. The KCC uses a bidirectional ring topology that uses remote procedure call (RPC) over TCP/IP without compression. Domain controllers (DCs) within a site are typically on a fast network (per the definition of a site), and the extra processing necessary for compression and decompression is undesirable.
The KCC runs every 15 minutes, adjusting the topology as necessary. As you create new DCs, the KCC automatically places them in the ring. To view the DC links, you can use the Microsoft Management Console (MMC) Active Directory Sites and Services snap-in. Expand the site, the Servers container, and the server. Under the NTDS Settings branch are the created connection objects.
Because the KCC runs on all DCs, the rings are in order of the DCs� globally unique IDs (GUIDs) to ensure convergence on one topology. An exception to the ring rule is that no more than three hops can exist between two DCs within the ring. To protect the three-hop rule, the KCC adds extra links for seven or more DCs, as the Figure shows.
These rings are for same-naming context (i.e., domains) in one site. If you have multiple domains in a site, rings exist for each domain in the site.Another type of ring that exists replicates schema and configuration information between DCs, as the Figure shows. Because all the domains share this information (i.e., the information is forestwide), each site has only one ring. Thus, if you have two domains in a site, you have three rings: one ring for each domain and one ring for the schema and configuration information. If you have only one domain in a site, one ring functions as two.
Manual configuration of intrasite replication is unnecessary, and Microsoft doesn�t recommend such configuration. The only task you might need to perform is adding extra connection objects to reduce the hop count between DCs.
When you make a change to the naming context (i.e., domain) data, the DC�s local copy of Active Directory (AD) records the change, then the DC waits 5 minutes (by default) before notifying its replication partners of the change. You can continue to make changes during this time period. The delay exists so that all changes transmit at once. If no changes occur during a particular time period (which you can configure in the intrasite connection object schedule), a replication sequence initiates to ensure no changes were missed.
The SAM or the Local Security Authority (LSA) can trigger urgent replication during the following events: replication of a newly locked-out account (e.g., if you fire someone), change of an LSA secret (i.e., a trust account), and state changes to the Relative Identifier (RID) Manager. These events trigger immediate replication. Because urgent replication requires notification, this type of replication occurs only within a site (i.e., intrasite). However, you can modify site links to enable notification.
An exception to multimaster normal replication is user passwords. As in other attribute changes, you can change a user password at any DC. However, the DC pushes the change to the PDC Flexible Single-Master Operation (FSMO) role holder on a best-attempt basis. Other DCs receive the password through normal replication. The reason for the extra password work is that if password validation fails, the validating DC will pass the request to the PDC FSMO in case the password has changed and the DC hasn�t yet received the new password via standard replication.
|
|
|
|
|
|
|
|