Syncing to our OU=SyncTargetOU NC instead

  • Article

Earlier in this series of posts I changed our sync target from form “OU=” to “DC=”. This was done to carefully skirt around a small issue. Now with our new found knowledge of logging in ADAMSync, let’s give it another try.

So let’s go ahead in to our previous config file and change this line:
     <target-dn>dc=SyncTargetDC</target-dn> 

To read:
     <target-dn>ou=SyncTargetOU</target-dn> 

Of course, this hopefully means you have created one such NC in your ADAM environment.
From there, I went ahead and installed and ran my config:

C:\WINDOWS\ADAM>adamsync /install localhost:50000 ADAMSyncDemo.XML
Done.

C:\WINDOWS\ADAM>adamsync /sync localhost:50000 ou=synctargetou /log OULog1.txt

And when I cracked open the log, there were all sorts of errors.

Processing Entry: Page 2, Frame 1, Entry 22, Count 1, USN 0 Processing source entry <guid=ba50fb2e1bdd53468913b5d023460185> Processing in-scope entry ba50fb2e1bdd53468913b5d023460185. Adding target object CN=Builtin,ou=SyncTargetOU. Adding attributes: sourceobjectguid, objectClass, instanceType, showInAdvancedViewOnly, creationTime, forceLogoff, lockoutDuration, lockOutObservationWindow, lockoutThreshold, maxPwdAge, minPwdAge, minPwdLength, modifiedCountAtLastProm, nextRid, pwdProperties, pwdHistoryLength, uASCompat, lastagedchange,  Ldap error occured. ldap_add_sW: Naming Violation.  Extended Info: 00002099: NameErr: DSID-03050F78, problem 2005 (NAMING_VIOLATION), data 0, best match of:
 'ou=SyncTargetOU'
. Ldap error occured. ldap_add_sW: Naming Violation.  Extended Info: 00002099: NameErr: DSID-03050F78, problem 2005 (NAMING_VIOLATION), data 0, best match of:
 'ou=SyncTargetOU'
.

First, notice that ADAMSync gives you all of the error text that ADAM returned to it. This is critical data.
So the question is, why did we fail?
Looking at the error in more detail:
Extended Info: 00002099: NameErr: DSID-03050F78, problem 2005 (NAMING_VIOLATION), data 0, best match of:

The most interesting piece of data here is the 2099, which maps to:

C:\>err 2099
# for hex 0x2099 / decimal 8345 :
  ERROR_DS_ILLEGAL_SUPERIOR                                 winerror.h
# The object cannot be added because the parent is not on the
# list of possible superiors.

And that’s the problem.
This entry was an attempt to create the object CN=Builtin under the parent object of OU=SyncTargetOU. This makes sense, we asked it to go in to OU=SyncTargetOU.
CN=Builtin is an object with an objectClass of builtinDomain:
      >> Dn: CN=Builtin,DC=erictest,DC=local
       2> objectClass: top; builtinDomain;
OU=SyncTargetOU is an OrganizationalUnit (specified when we created the NC in dsmgmt). We need to make it such that OrganizationalUnit is a possSuperior of builtinDomain. More info on possSuperiors can be found here.

So anyway, after making that change, I ran sync again…..

Finished (successful) synchronization run.
Number of entries processed via dirSync: 168
Number of entries processed via ldap: 2
Processing took 13 seconds (0, 1085446656).
Number of object additions: 52
Number of object modifications: 118
Number of object deletions: 0
Number of object renames: 112
Number of references processed / dropped: 58, 7
Maximum number of attributes seen on a single object: 18
Maximum number of values retrieved via range syntax: 0

As we said earlier, most ADAMSync failures are schema problems. :)

Update: Corrected a small typo in my before target DN. Thanks!