Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
If client and server are two DCs in the NC replica graph of a given NC and forest, where server is the initial vertex of an arc and client is the final vertex of the same arc, client will perform a replication cycle from server by calling IDL_DRSGetNCChanges ([MS-DRSR] section 4.1.10) until the cycle is complete in either of these two cases:
The DC client's repsFrom tuple for server contains a schedule field that calls for replication at the current time. The schedule contains a REPLTIMES structure as specified in [MS-DRSR] section 5.165. This is scheduled replication.
The DC server calls the IDL_DRSReplicaSync method ([MS-DRSR] section 4.1.23.2) on the client. This is event-driven replication. The events that cause this form of replication are specified later in this section.
A precondition for event-driven replication involves server's repsTo abstract attribute, specified in [MS-DRSR] section 5.173. The repsTo abstract attribute is a sequence tuples, like repsFrom. Like repsFrom, each repsTo tuple contains a field uuidDsa that contains the objectGUID of an nTDSDSA object. The nTDSDSA object represents a DC as specified in section 6.1. If server's repsTo abstract attribute contains a tuple whose uuidDsa field contains the objectGUID of client's nTDSDSA object, server performs event-driven replication to client.
It remains to specify how a DC's repsTo abstract attribute is populated, and to specify the events that trigger event-driven replication.
A DC's repsTo abstract attribute is populated as follows:
A DC server's repsTo abstract attribute is populated for event-driven replication to client if client's repsFrom tuple for server has the DRS_ADD_REF bit set in its replicaFlags field, and client calls the IDL_DRSGetNCChanges method on server during scheduled replication. The DC client sets the DRS_ADD_REF bit in Request.ulFlags on the scheduled call to IDL_DRSGetNCChanges on server ([MS-DRSR] section 4.1.10.4.1) and server updates repsTo for event-driven replication to client as a result ([MS-DRSR] section 4.1.10.5.2).
Since the KCC running on client writes client's repsFrom, this behavior is controlled by the state of KCC objects as specified in section 6.2.
A DC server's repsTo abstract attribute is populated for event-driven replication to DC client if the IDL_DRSReplicaAdd method ([MS-DRSR] section 4.1.19.2) is called on client, specifying server as the replication source (either pmsgIn.V1.pszSourceDsaAddress or pmsgIn.V2.pszDsaSrc, depending upon the request version used). If the IDL_DRSReplicaAdd adds a new tuple to client's repsFrom, it proceeds to call IDL_DRSUpdateRefs ([MS-DRSR] section 4.1.26.2) on server to update server's repsTo abstract attribute.
Since IDL_DRSReplicaAdd is an RPC method, this behavior is controlled by any authorized requester of this method. Within Active Directory itself, IDL_DRSReplicaAdd is called by the KCC to maintain repsFrom.
The events that trigger event-driven replication from a DC server are as follows:
The DC server receives an update, either originating or replicated, as specified in section 3.1.1.5.1.7 (Urgent Replication).
A configurable time expires after DC server receives any update, as specified in section 3.1.1.5.1.6 (Replication notification).