How does intrasite replication work in Windows 2000?
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.
Security FAQ
Windows Privacy Tools - http//www.privacywindows.com
| 
