Syncing Manager value to Active Directory, when Manager’s object is outside the connection’s Destination scope

When syncing Active Directory to Active Directory (AD), there is a default mapping to sync the Manager attribute value:

Manager=#Manager#

Note: ODBC to AD does not have a default mapping, but the same solution can be applied when an ODBC solution is in use. Please see our knowledge base article on Syncing Manager from ODBC to AD for other important information about syncing the Manager value from an ODBC directory.

Default functionality requires that in order for the ‘Manager’ attribute value to be set on a synced object, the Manager’s Source object must be part of the sync, and also sync over in the same connection. When the Manager object is included in the scope of the sync, the Manager object’s DN is included in the connections hash table, and the Sync phase is thus able to translate #Manager# mapping for the corresponding Destination object.

In certain circumstances, you may have a connection that does not include all Source objects. So when creating some objects on the Destination, the Manager attribute is not set because the sync can not translate #Manager#. In these cases, you may implement a DNHashGen connection solution.

This solution uses a separate Join connection between the Source and Destination. It builds an export.txt file containing DN information for both the Source and Destination objects. This dnhash.txt file is utilized by your original connection to resolve #Manager# and populate the Manager attribute on the synced Destination objects.

Solution

Connection 1

This is your new DNHashGen connection. This connection uses a special Destination sync engine of DNHashGen. This connection should select Source Object Types of Users/Contacts. This connection uses typical Join rules (on the Destination tab) to perform a Join, identifying matching member objects between the Source data and Destination objects. The suggested join query is (mail=^mail^), or some other set of unique index attributes, such as (employeeID=^employeeNumber^). The DNHashGen discovery reads the Source data as usual. The Synchronization then performs a JOIN only. The Sync exports a file, export.txt. This file contains a hash table identifying Source/Destination matches.

Note: Your Destination objects are not touched in this process.

To create Connection 1:

1. Click New to create a Connection
2. Give this connection a name, such as “Forest 1 to Forest 2 DNHashGen”
3. Select a Source map template that corresponds with your Source directory type, and a Source engine of LDAP or ODBC
4. Leave the default Destination Map Template and select a Destination Engine of DNHashGen (the exact Destination Map Template doesn’t matter because this connection isn’t really creating anything)
5. Fill in the Source tab to identify your Source as usual
   1. Select the desired Source Object Type(s) (i.e., Users, Contacts)
   2. If appropriate, specify a Selection DN
      NOTE: If your Source is ODBC, identify the DSN as usual and fill in Field Definitions for Index.
6. Enter your credentials on the Destination tab to access the Destination LDAP directory as usual
7. On the Destination tab, enable the Sync/Join Mode of Join
8. Fill in the appropriate Join Query using the Source and Destination indexes you’ve selected (i.e. employeeID=^employeeNumber^)
9. If appropriate, use the Optional Base DN to limit the Destination query structure
   Note: *Destination peer domains - If your Destination contains peer domains, and you need to export matching objects in all domains, specify an Optional Base DN of NULL
10. Click Save
11. Run Discovery and Synchronization. Discovery reads the Source, then Sync finds the matching Destination object and outputs a file, export.txt. Nothing is added or changed on the destination
12. Review the results of the sync run:
    • Were the appropriate number of records exported?
    • Did you have any “Join Non Match” warnings? If so, this means a record exists on the Source, but no match was found on the Destination.
13. Copy Connection 1’s export.txt file to Connection 2 renamed dnhash.txt

Connection 2

This is your standard connection. This connection may be configured as usual. When run, this connection will use the dnhash.txt created by connection 1 and put in the connection folder by you. With this added information, Connection 2 can resolve Manager values no matter where they exist on the destination.

To create Connection 2

1. Copy export.txt (created by connection 1) to the Connection 2 directory and rename it dnhash.txt (i.e., \UnitySync-v2.x\Connections\Connection2\dnhash.txt)
2. On the General tab, change the Log File level to 3-Detailed
3. Run Discovery and Simulation first; Discovery reads the Source, then Simulation will show us what will occur on Destination
4. Review the results of the Simulation:
   • Were the appropriate number of object created/updated?
   • Search the log for Dest Entry to see if/how Manager is set. Be sure to check objects for whom manager is outside the sync container (i.e. in a peer domain). Do you see a Manager assigned in the Dest Entry? *Do you see any Manager Not Found errors recorded in the Error Summary at the bottom of the log?

Note: *If this process is needed on an ongoing basis, you’ll want to always run both connections,copying the export.txt to dnhash.txt in between the connection runs. You can automate the connection runs and the copy of the export file via script.

Sample Script to automate the DNHashGen process:

shell “Connection1”
copy /y c:\UnitySync-v2.0\Connections\Connection1\export.txt c:\UnitySync-
v1.0\Connections\Connection2\dnhash.txt
shell “Connection2”