When replication is RPC-based (within a site), the server that makes changes to its directory is responsible for initiating replication by notifying the servers specified in its Reps-To list for that particular naming context. Below is the Reps-From attribute details for the Site container. You can view this information by bringing up the raw properties of the Site object, selecting the Reps-To or Reps-From attribute, choosing Viewer, and selecting the Replica link viewer type. The following illustration shows the Reps-To value for the Boston01 Site container in the NAmerica-E site.
Every replica link (Reps-From, Reps-To and Reps-To-Ext) contains all the above values. The Other DRA value is the name of the server to be replicated. Note that this may be an X.500-type value in the case of a server in a different site. The Reps-To attribute does not use many values because you notify the Other DRA of the USN value based on the Replicator notify pause after modify (secs) registry setting. The Reps-From attribute has significantly more information, including the remote servers UUID and the USN of the last change committed to the directory for this naming context.
Note the check boxes for Periodic sync, Init sync and Mail replica.
| Option | Description |
| Periodic sync | Defines whether request changes for this naming context are based on the Period-Rep-Sync-Times attribute. |
| Init Sync | Specifies whether or not the directory will request an update for this naming context at directory service startup. |
| Mail replica | Defines whether the directory uses mail-based replication or RPC-based replication. |
| Writeable replica | Defines whether clients can make changes to this naming context and is not used for replication. |
In the example, this is a replica within a site because the Mail replica option is not selected. The directory is replicated as follows.
Example: Replicating Within a Site
You can now use your understanding of the directory replication infrastructure and replication within a site to track the replication of an object between two servers in a site. Server NewYork01 and server Boston01 are the only two
servers in site NAmerica-E.
In the following example, mailbox Bill Lee (/o=Ferguson&Bardell/ou=NAmerica-E/cn=Recipients/cn=Bill Lee) on server Boston01 will be modified to let it replicate to server NewYork01.
First, determine the replication state of the object on both servers before
the modification, starting with server Boston01. Determine the replication
state of an object by looking at the Object Replication attributes in raw
mode. By viewing these attributes, note that the DSA-Signature is EE6CF383865BD1118CFB00C04FB169AC, and that the USN-Changed,
USN-Created and USN-Source are all 1946. The DSA-Signature states that
the last directory service to modify the object was Boston01. In this case,
the all the USN values are the same. When the USN-Changed, USN-Created
and USN-Source are the same, you can determine that the object was created
on the local directory and that it has not been modified since creation.
Now examine the object replication state on server NewYork01. The
DSA-Signature of the Bill Lee mailbox object on server NewYork01 is EE6CF383865BD1118CFB00C04FB169AC. The USN-Created and USN-Changed values are 1157. The USN-Source value is 1946. These values state that the object was last modified by Server Boston01 (based on the DSA-Signature). USN-Created and USN-Changed are unique to this server and happen to be 1157. USN-Source is the USN-Changed value from the server that replicated the object. In this case, go back and see that 1946 is indeed the USN-Changed value from server Boston01.
Your next step is to modify this object on Server NewYork01 and see what changes when it is replicated to server Boston01. In the Administrator program, change the City attribute of the mailbox to London, and review the new state on server NewYork01.
As a result of the modification, DSA-Signature on server NewYork01 is changed to 52D4C132F161D111B1B900C04FB169F3. USN-Changed attribute has been modified to 1220. USN-Created remains at 1157 and the USN-Source remains at 1946. DSA-Signature has changed, because by definition it is the Invocation-ID of the last directory to modify it, in this case server NewYork01. USN-Changed is changed because the object has been modified. Whenever an object is modified, the USN counter on the directory is incremented and the value is assigned to the USN-Changed attribute of the object. USN-Created should not change anymore because it should only be set when an object is created on a particular Microsoft Exchange Server directory. USN-Source can change, however, in this case it will not. Remember that by definition USN-Source is USN-Changed value from the directory service that last replicated the change. Because the object was changed on this server, the last server to replicate a change was Boston01, and therefore USN-Source does not change.
At this point, you have a new change on the Site naming context (/o=Ferguson&Bardell/ou=NAmerica-E) for server NewYork01. The directory is replicated as follows.
At this point, look at the state of the object on server Boston01. The object Bill Lee on server Boston01 now has a new set of object attributes as a result of the replication. DSA-Signature is 52D4C132F161D111B1B900C04FB169F3 (Server NewYork01s DSA-Signature). USN-Changed value is 1966, a unique value to this server. USN-Created stays at 1946, the original USN number assigned to this object. Finally, the USN-Source value is 1220, the USN-Changed value from the remote directory that replicated the change (server NewYork01).
Important Notes about Replication Within a Site
The following are important points to keep in mind about directory replication and replication within a site.
The most important point to remember about replication within a site is that all RPC-based replication uses Notify, Request, Response, and Write messages.