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.
As specified in [MS-ADTS], domain controllers (DCs) use the Directory Replication Service (DRS) Remote Protocol (as specified in [MS-DRSR]) to replicate their configurations, schema, and domain naming context (domain NC) to other DCs. DCs are usually configured to use DRS over an RPC transport mechanism; however, in some environments, RPC transport is unsuitable (for example, if firewalls in the network between the DCs are configured to block the ports used by RPC).
This document defines the extensions to the DRS Protocol for transport over the Simple Mail Transfer Protocol (SMTP). These DRS Protocol Extensions for SMTP provide an alternate transport for the DRS Protocol that allows DCs to perform replication in environments where the RPC transport mechanism is unsuitable. As specified in this document, the DRS Protocol Extensions for SMTP encapsulate the DRS messages into MIME attachments (as specified in [RFC2045]) that are then sent in email between DCs by using SMTP (as specified in [RFC2821]).
The DRS Protocol Extensions for SMTP specified in this document are not a general transport mechanism. They can be used only for the transport of a subset of DRS messages during replication between DCs. As specified in sections 1.5 and 3.1.3, there are additional conditions that the configurations of the DCs have to meet before the DRS Protocol Extensions for SMTP can be used to replicate state between the DCs.
When two DCs replicate, the DC that is initiating the replication is referred to as the client, and the other DC is referred to as the server. The basic steps of a replication are as follows:
The client DC sends a "get replicated change" request to the server DC.
The server DC accepts the "get replicated change" request from the client DC and identifies new updates for this client.
The server DC sends a "get replicated change" response to the client DC that is carrying those updates.
The client DC accepts the "get replicated change" response from the server DC and incorporates non-redundant updates from the server.
When using the DRS Protocol Extensions for SMTP, clients and servers asynchronously process batches of "get replicated change" messages. For example, a client can make multiple requests to the server before receiving a response, and a client is free to process replies at a later time than when the request was sent.
The following figure outlines the processing steps performed by the DRS Protocol Extensions for SMTP as a "get replicated change" message (either a request or a response) is prepared for transport to the other DC involved in the replication. The details of these steps are specified in section 3. When a DC receives an SMTP message, the steps are performed in the reverse order, starting with the SMTP Mail Transfer Agent (MTA), and proceeding to obtaining the DRS Replication Data, which is then given to the DRS Protocol.
Figure 1: Transporting a "get replicated change" message to the other DC involved in a replication
The result is an SMTP message structured as shown in the following figure. The message is given to the SMTP Mail Transfer Agent (MTA) for delivery to the remote DC.
Figure 2: SMTP message given to the SMTP MTA for delivery to the remote DC
The specification of the DRS Protocol Extensions for SMTP depends on the terminology and concepts that are specified in [MS-ADTS] and [MS-DRSR]. For illustrative examples, see [MSADRTTR]. Summarizing information as specified in [MS-ADTS], all DCs are configured to be part of a forest. Each DC stores two or more naming contexts (NCs), where an NC is a conceptual directory that maps names to attributes. DCs use the Directory Replication Service Protocol (as specified in [MS-DRSR]) to maintain consistency between NCs that are stored on multiple DCs.
The properties and configuration of a forest are defined by the values in a configuration NC and a schema naming context (schema NC). Each DC maintains a copy of its forest's configuration NC and schema NC. Changes made to any copy of these NCs, at any DC, are replicated to the copies at all other DCs in the forest. DCs also store a domain NC for one or more domains. A DC might be configured to have a read/write copy of the domain NC, in which case the DC is a full master for the domain, or it might have a read-only copy of the NC, in which case it is a global catalog. As part of the configuration NC for a forest, each DC in the forest is assigned to a site (conceptually, a site is a geographic region).
The following figure illustrates an example of a forest that contains two sites (Site1 and Site2). The DCs in Site2 (DC2-1 and DC2-2) are full master for the Domain2 Domain NC (D2) and global catalogs for the Domain1 Domain NC (D1). The DC DC1 in Site1 is a full master for the Domain1 NC. Each DC also has a Configuration NC (C). A scenario in which this situation might exist is the operation of a DC on a submarine that makes contact with its base only infrequently. The submarine would be configured as Site1 and the base as Site2.
Figure 3: Forest that contains two sites (Site1 and Site2)
The configuration state in the forest's configuration NC dictates what transports are used by DRS during replication. In the example in Figure 3, the two DCs in Site2 are configured to use RPC transport for their replication using DRS, as specified in [MS-DRSR], and DC1 and DC2-1 are configured to use SMTP transport for their replication using DRS, as specified in this document.
The choices regarding which DCs replicate, and on what schedule, are made by the Knowledge Consistency Checker (KCC), as specified in [MS-ADTS]. For a set of informative examples of replication topology, see [MSADRTTR].