I find myself quite often trying to keep straight all the different replication activities that can occur within an Active Directory (AD) domain.
There is:
- Intrasite Replication
- Urgent Replication
- Intersite Replication
- Intersite Change Notification Replication
- Reciprocal Replication
- Immediate Replication
- Manual Replication
Replication between Domain Controllers (DC’s) occurs without administrative intervention. Replication provides the multimaster database that AD uses to allow all DC’s to have equivalent objects within a given time frame so an object modified at one location can be stored and forwarded to all other DC’s in its domain. How quickly objects are replicated to the rest of the domain, by an individual dc, is computed by the replication rules that exist and/or applied against them.
Intrasite Replication:
Replication between DC’s within a site don’t need to worry about connectivity speed, so the connections between dc’s are optimized for speed. Intrasite Replication within a site notifies a partner DC 15 seconds after a change has occurred and all subsequent DC’s it communicates are delayed by 3 seconds. For Windows 2000’s partners the initial time delay was 300 seconds (5 minutes) and subsequent partners was 30 seconds. So after the delay a partner DC is notified that the notifier has an update. It is up to this partner DC to request the modification. The notifying DC only notifies, it doesn’t push the change. It is up to the notified DC to pull the change. Also, all DC’s within a site are never more than 3 hops away from all other DC’s due to the KCC generating a bidirectional ring topology. This also ensures a quicker convergence within a site.
Urgent Replication:
Urgent notification is just that, it is not bound by the 15 second (Or 5 minutes) time delay of Intrasite Replication. Partner DC’s are immediately notified of changes, this only holds true for intrasite DC’s except if change site notification is enabled.
Intersite Replication:
DC’s between sites don’t follow the same set of rules that intrasite replication does. Changes between sites are setup on a schedule. The schedule is broken up in 15 minute increments, this schedule can also be set to only allow changes to occur at certain times of the day, thereby saving bandwidth at key points of time. The shortest time span for intersite to occur is 15 minutes and the longest is once a week. Note once replication begins between DC’s, the process will not stop until complete. So you won’t have to worry about incomplete replication activity due to time constraints.
Intersite Change Notification Replication:
With bandwidth pipes becoming cheaper and available, many organizations are becoming more well connected, 15 minutes can be a long time. Imagine having to wait for a password unlock not being reset in the proper site and having to wait 15 minutes for replication to occur. Obviously you can force replication but the point is 15 minutes between sites sometimes just isn’t realistic. To bypass the scheduled notification delays you can enable, Intersite Change Notification. Once enabled partners in different sites will be treated equivalently as intrasite replication, with the exception this only holds for NTDS, NTFRS still works on the schedule.
Reciprocal Replication:
Sometimes connectivity isn’t always available, for example a Navy/Cruise ship or a dial up connection. With this type of topology both sides need to take advantage of the connect time, so both sides can replicate at the same time. So when the remote site connects up to the Data Center the replication pair should both request and receive any delta’s that are available. Hence, replication is initiated on the basis of change rather than on a schedule.
Immediate Replication:
If an administrator resets a password for a user who has forgotten their password, the change is immediately replicated back to the PDCe. This isn’t a situation where the PDCe is notified about the change but instead the change is immediately pushed to it. The reason this is so important is that if a user attempts to logon and the password they attempt to use fails, the DC will send the hash from the password (Password itself is never sent over the wire) back to the PDCe to check to see if the password is correct, since there is latency in replication.
Manual Replication:
Manual replication is triggered by the admin. This can occur from either the repadmin command or from AD Sites and Services. This will cross intersite replication schedules if requested. So if you have a Lag Site and the network is enabled, even though your site isn’t scheduled to replicate for possibly days a forced replication will cause the replication to occur. So you need to be aware of this, in a lag site I had set up I had a schedule task that actually enabled and disabled replication to prevent this.
Over the next few weeks I hope to expand and add some diagrams to help make this easier to follow, as well as some helpful links.
This can be confusing and I hope I have helped in you grasping this concept.