DirWiz Logo
Knowledgebase

Article Tags

Duplicate Dest DN (Duplicate Record) Errors

2017-05-01 10:16:50
Errors Troubleshooting UnitySync 

Duplicate Destination DN (or Duplicate Record) errors occurs when two (or more) different source records attempt to create the same destination DN. The first record will be synced successfully. Subsequent attempts to sync to the same DN will fail.

In most cases, default mapping uses email address in the destination DN to help avoid duplicate DNs (since source email addresses are supposed to be unique). However, if two source objects have the same email address, the Duplicate DN error will occur.

Options to fix these errors:

Option 1: You can resolve this error by making the required attribute unique for each object throwing the error. By default, UnitySync usually uses email address, so youd be required to make the source email addresses unique.

Option 2: You may elect to Exclude specific objects or containers that do not need to be synced.

NOTE: //To implement options 1 or 2, see “Identifying the source records throwing the error' outlined below.//

Option 3: This option is not generally recommended unless this is a first time sync, or unless option 1 and 2 are not able to be implemented. For this option, you may use [[239|a Custom Object Map File]] to modify the DN format of synced objects. You may select any source attribute to be part of the DN. The goal is to ensure uniqueness of the value in the attribute: dn:cn=^attribute^,ou=~stuct~

If you do not have a source attribute that can be used to to specify a unique value, you may use an internal variable ~uniqueid~. This is a numeric value based on the dn of the source object. Since the source dn is unique, the value generated for ~uniqueid~ will be unique. You can use this alone or in conjunction with the existing mapping:

:dn:cn=uniqueid,ou=struct\ dn:cn=cn~ uniqueid,ou=struct~

NOTE: //If you modify the DN mapping on an exiting connection, the next time you run the Sync the previously synced objects will be modified when their DNs are changed. If syncing to AD they will simply be moved. If syncing to a destination that does not support the move function, they will be deleted and added under the new DN.//

IMPORTANT NOTE about customizing the DN mapping: //When you run a sync after changing the DN mapping, the sync may perform MOVES of previously synced objects if the destination directory supports a Move (i.e. AD). However, the sync may perform DELETE/ADD for all objects if the destination directory does NOT support a Move (i.e. Ex55, Notes, iPlanet).//

====Identifying the source records throwing the errors:

An easily readable Duplicate Records summary appears near the end of the log file so you can identify the source objects that are causing the error. First, the destination DN being created is identified. Then, the first records which writes to that destination DN is identified. This first entry for that dn is created successfully. What follows is a list of one or more other source DNs. Each of these DNs failed to sync due to the Duplicate Record error.

=====Example (using email address in DN mapping):

:Duplicate Records : Tue, Jul 23, 2004 10:32:18 AM\ DestDN: cn=JSmith@domain.com,ou=contacts,dc=domainB,dc=com\ SourceDN:cn=John Smith,ou=container,dc=domainA,dc=com\ SourceDN:cn=Jonathan Smith,ou=container,dc=domainA,dc=com

Both source records have an email address of JSmith@domain.com. :cn=John Smith synced successfully\ cn=Jonathan Smith failed to sync because the DN it attempted to create already exists.

Either modify one of the source records to have a unique email address (option 1) or exclude one of the records (option 2).

=====Example Exclude syntax: :DN=cn=John Smith,ou=container,dc=domainA,dc=com

Share this article: Twitter reddit