Share via

3.1.1.1.14 Scheduled and Event-Driven Replication

  • Article

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:

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

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

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

  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:

  1. The DC server receives an update, either originating or replicated, as specified in section 3.1.1.5.1.7 (Urgent Replication).

  2. A configurable time expires after DC server receives any update, as specified in section 3.1.1.5.1.6 (Replication notification).