Synchronizing only the attributes you really want
In our previous ADAMSync runs we synchronized all attributes except those in the <exclude> tags. This is probably ok for our tinkering, but in a real scenario, you might want to consider picking those you want instead of getting everything but those you say not to.
Why? Well, consider the costs. If you synchronize everything, you’re paying the costs for all of those attributes (cost for lookup in AD, shipping them over the wire, writing them in to ADAM, storage in ADAM, etc.). If you only synchronize what you need you save on those costs while still servicing what you need in your application. And of course, you can always change your mind later. :)
The one tricky thing about this operation is picking the attributes you need. Consider that for some set of classes you’re creating, there is a minimum set of attributes that each class will require in order to be created properly. Should you miss some of them, you will get errors such as this one:
Processing Entry: Page 2, Frame 1, Entry 65, Count 1, USN 0
Processing source entry <guid=09e91eb3653f004fb8f8350d6ef2d577>
Processing in-scope entry 09e91eb3653f004fb8f8350d6ef2d577.
Adding target object CN=Domain System Volume (SYSVOL share),CN=NTFRS Subscriptio
ns,CN=EFLEIS-DF2,OU=Domain Controllers,ou=SyncTargetOU.
Adding attributes: sourceobjectguid, objectClass, instanceType, lastagedchange,Ldap error occured. ldap_add_sW: Object Class Violation.
Extended Info: 0000207C: UpdErr: DSID-0315116B, problem 6002 (OBJ_CLASS_VIOLATIO
N), data 0
And 207C maps to:
C:\>err 207C
# for hex 0x207c / decimal 8316 :
ERROR_DS_MISSING_REQUIRED_ATT winerror.h
# A required attribute is missing.
So this can be tougher than it first appears. For my test environment (as mentioned previously, a fresh win2k3 forest), the following set of attributes was enough. But perhaps you will need more. If so, note the object that failed, and check out the attributes required on that object. Make sure you include all of them.
With that having been said, let’s go ahead and trim our attribute set down a bit. I’ll go ahead and only retain a subset of the attributes.
I’ll change this section:
<attributes>
<include></include>
<exclude>extensionName</exclude>
<exclude>displayNamePrintable</exclude>
<exclude>flags</exclude>
<exclude>isPrivelegeHolder</exclude>
<exclude>msCom-UserLink</exclude>
<exclude>msCom-PartitionSetLink</exclude>
<exclude>reports</exclude>
<exclude>serviceprincipalname</exclude>
<exclude>accountExpires</exclude>
<exclude>adminCount</exclude>
<exclude>primarygroupid</exclude>
<exclude>userAccountControl</exclude>
<exclude>codePage</exclude>
<exclude>countryCode</exclude>
<exclude>logonhours</exclude>
<exclude>lockoutTime</exclude>
</attributes>
To be:
<attributes>
<include>description</include>
<include>frsstagingpath</include>
<include>fRSRootPath</include>
<include>sourceObjectGuid</include>
<include>lastAgedChange</include>
<exclude></exclude>
</attributes>
Here’s where this list came from….
I first just decided I wanted object descriptions.
Then, I gave it a run. It complained with the error previously discussed. So I went to the class definition for the object and included the list of must contain attributes.
The last two attributes (sourceobjectguid and lastagedchange) are ADAMSync attributes themselves. These are used for internal tracking. So I went ahead and included them.
And with a little luck, it’ll work out just as well for you as it did for me.
Finished (successful) synchronization run.
Number of entries processed via dirSync: 169
Number of entries processed via ldap: 3
Processing took 10 seconds (0, 1085404416).
Number of object additions: 168
Number of object modifications: 4
Number of object deletions: 0
Number of object renames: 3
Number of references processed / dropped: 0, 0
Maximum number of attributes seen on a single object: 6
Maximum number of values retrieved via range syntax: 0