Synchronization uses server resources. Consider the following resource requirements when defining the replication strategy:

A site that manages human resource databases or financial information is likely to put a heavier load on the directory than a site containing engineering staff that uses the directory for simple telephone book purposes.

As with multi-master replications, synchronization requires a changelog of to track directory edits and log entries for the state information for update entries, and tombstone entries for deleted entries. This information is required for synchronization. Because these log files can get very large, periodically cleaning up these files is necessary to keep from wasting disk space.

There are four attributes which can maintain the changelog. Two are under cn=changelog5 and relate directly to trimming the changelog:

The other two attributes are under the synchronization agreement entry in cn=sync_agreement, cn=WindowsReplica,cn=suffixDN,cn=mapping tree,cn=config. These two attributes relate to maintenance information kept in the changelog, the tombstone and state information, rather than the directory edits information.

The parameters for managing replication and the changelog are described in chapter 2, "Core Configuration Attributes," in the Configuration, Command, and File Reference.

Synchronization can occur using simple authentication over a standard port, using SSL/TLS, or using Start TLS (a secure connection over a standard port).

Although it is not required, it is strongly recommended that SSL or other secure connection be used for synchronization. If passwords are going to be synchronized from the Windows server, then SSL must be enabled on both servers so the synchronization proceeds over a secure port.

The data master is the server that is the master source of data; this is the primary or authoritative source for data.

Windows and Directory Server services are kept continuously synchronized through the synchronization agreement, which minimizes potential conflicts between the two services. However, if the Directory Server is part of a replication deployment, then conflicts could arise between changes made within the Directory Server replication scenario and the Windows domain depending on the replication schedule.

Consider which server will be the data master when the data resides in two different directory services, and decide how much of that information will be shared. The best course is to choose a single directory service to master the data and allow the synchronization process to add, update, or delete the entries on the other service.

Choose one area (Windows domain or Directory Server) to master the data. Alternatively, choose a single Directory Server as a data master and synchronize it with each Windows domain. If the Directory Server is involved in replication, design the replication structure to avoid conflicts, losing data, or overwriting data.

How master copies of the data are maintained depends on the specific needs of the deployment. Regardless of how data masters are maintained, keep it simple and consistent. For example, do not attempt to master data in multiple sites, then automatically exchange data between competing applications. Doing so leads to a "last change wins" scenario and increases administrative overhead.

Only a single Directory Server subtree can be synchronized to a single Windows subtree, and it is recommended that there only be a single synchronization agreement between directory services. Select or design the parts of the directory trees to synchronize; consider designing special suffixes specifically for synchronized entries.

Synchronization links a Directory Server suffix and subtree (for example, ou=People,dc=example,dc=com) to a corresponding Windows domain and subtree (cn=Users,dc=test,dc=com). Each subtree can be synchronized only to one other subtree to avoid naming conflicts and change conflicts.

To take advantage of Windows Sync, use it with a Directory Server supplier in multi-master replication synchronized to a member of a Windows domain. This propagates changes through both directory systems while keeping the information centralized and easy to maintain. It also makes it easier to master the data.

Only create one synchronization agreement to any given Windows domain. To propagate the changes and information synchronized from the Windows server throughout the Directory Server, create the synchronization agreement with a multi-master supplier, preferably a data master for the replication deployment.

Windows Sync synchronizes user and group entries between directory services. After deciding which subtrees to synchronize, plan the information to store in those subtrees, such as the following:

Which entries are synchronized is set in the synchronization agreement. User entries are synchronized separately from group entries. Additionally, deleting entries is configured separately; deletions have to be specifically synchronized.

In the Directory Server, only entries that contain the ntGroup or ntUser object classes and required attributes are synchronized; determine what existing and future entries should be synchronized with the Windows server.

After determining what entries should be present in the directory, determine what attributes of these objects need to be maintained in the directory. Only a subset of the possible attributes for Directory Server or for Active Directory are synchronized. Additionally, this subset of attributes can be limited even more by excluding certain attributes through the sync agreement (fractional synchronization).

Plan both the entries and the data contained in those entries according to the available synchronization attributes. The synchronized attributes and the differences between Directory Server and Active Directory schema are described in Section 8.3, “Schema Elements Synchronized Between Active Directory and Directory Server”.

While the DirSync plug-in is installed with the Directory Server and enabled by default, an additional Windows service, Password Sync, must be installed on the Windows machine to synchronize passwords. This service is required to transfer any password changes made on the Windows server over to the Directory Server.

Unless the Password Sync service is installed, password synchronization (synchronizing the userPassword attribute) is not enabled. What this means is that even if Directory Server user entries are synchronized over to the Windows server, the user entries are not active on the Windows domain (meaning, among other things, those synced users cannot log into the domain, since they do not have a password).

Existing Directory Server entries that are modified to contain the necessary synchronization attributes are not synchronized until the next total update. Modifications to Windows entries and Directory Server entries that have already been synchronized are carried at the next incremental update. As a part of this strategy, try to master data in a single place, limiting the applications that can change the data, and schedule necessary total updates (these updates do not overwrite or delete existing information; they add new entries and send modifications).

By default, the Windows and Directory Server instances are kept constantly in sync and have changes published every five minutes. This schedule can be altered by manually setting the sync agreement attributes to change the update interval (winSyncInterval) or by setting a different update schedule (nsDS5ReplicaUpdateSchedule).

The basic sync agreement configured through the Directory Server Console sets very simple information about synchronization, like the host and port information, synchronized subtrees, and connection types.

However, many configurations available to multi-master replication, like fractional replication and sync schedules, are available to Windows-Directory Server synchronization. These settings must simply be added to the sync agreement manually.

Changing the default sync agreement is described in the Administrator's Guide, and the available sync agreement attributes are listed in the Configuration, Command, and File Reference.