• State Suggested Answer
  • Locked Locked
  • Replies 9 replies
  • Answers 1 answer
  • Subscribers 95 subscribers
  • Views 11468 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

AD Sync Project: A scope that excludes an OU takes much longer to query Contacts than any other object type

Tim Staddon
over 7 years ago

Hi,

This is with v7.1.2.

Here I have an Active Directory OU in a test domain which contains over 50,000 AD contacts external to the domain 1IM needs to manage. We don't need our sync project to touch any object in this OU at all.

ADUC can scan the container for all contacts in less than a second, and a filtered LDAP query in an LDAP browser will give me all contacts except these ones in under 0.14 seconds. 

The best I've been able to manage in Synchronization Editor is, I got it down to ~21 seconds by applying scope filters in three ways:

  • Scope filter based on the heirarchy of existing system objects (de-selecting the offending OU from the treeview)
  • Object filter - NOT LIKE %OU=OUtoExclude,DC=company,DC=com
  • Schema classes using the same filter

But even then, it shouldn't take the target system browser 150 times as long as ADUC or LDAP Browser to retrieve the exact same result using the exact same LDAP filter.

If I use the target system browser to find containers, users or organizational units outside the excluded OU, the result set is returned inside of 0.16 seconds even when the result sets have hundreds of objects from many different OUs. So it almost seems like the issue is specific to AD contacts.

If I set the container, contacts and organizationalUnits mappings to use the filtered schema classes, it takes 40 seconds for Target System Browser to find all contacts.

Any ideas why this might be happening?
And, why is this only happening with contacts? It doesn't happen with any other class of object, as far as I can tell.

Parents
  • 0 over 7 years ago

    Hi,

    Thanks for the suggestion. I've tried it, but it doesn't help any. The sync is still hitting every object the container even when I have crossed out the problem OU in the treeview and configured filters like this.

    contact: (!(msDS-parentdistname=OU=ProblemOU,OU=parentOU,DC=company,DC=com)
    organizationalUnit: (!msDS-parentdistname=OU=ProblemOU,OU=parentOU,DC=company,DC=com)

    The equivalent object filters are:

    contact: not (msDS_parentdistname='OU=ProblemOU,OU=parentOU,DC=company,DC=com')
    organizationalUnit: not (msDS_parentdistname='OU=ProblemOU,OU=parentOU,DC=company,DC=com')

    If I use this query string from the directory root in an LDAP tool, I get the 28 rows I need in less than 0.2 seconds and it doesn't return the ProblemOU objects before filtering them out of the result list; this is how the contact scope needs to work in Identity Manager.

    (&(objectClass=contact)(!(msDS-parentdistname=OU=ProblemOU,DC=company,DC=com)))

    I did some more testing. If I remove all system filters from everywhere, then set the AD syc up exactly as follows:

    (a) Scope:  deselect the problem container from the treeview on the right hand side and configure nothing on the left hand side.

    (b) Reference scope: set up as above

    (c) Schema classes for Contacts, Containers, Users: Set object filter only on the schema class for each one.

    I get the optimum performance when all three of these are configured - for example the OU list returns in 0.09 seconds if configured this way, compared to 0.8 seconds if the filters are configured differently.

    If I add any system filter to a schema class or scope, it slows back down and I am certain it is pulling objects in from the sync.

    So, to test, I configured *identical* filter logic for users and contacts.

    Users:

    • (b and c) ==> 2188 objects in 1.37 secs
    • (a, b and c) ==>  2188 objects in 1.24 secs

    Same test with Contacts:

    • (b and c) ==> 28 objects in 28.65 secs
    • (a, b and c) ==>  28 objects in 18 secs

    Sync reports clearly show it is interrogating the excluded container for objects we have expressly told it to skip:

    2017-10-25 01:32:55 -07:00 - ***REDACTED*** - VI.Projector.ADS.JobComponent.ADSComponent - d4709c0f-17a8-45ae-90ae-448e132aa934: Successful
   Unable to resolve SID or DN (CN=(names,OU=ProblemOU,OU=ParentOU,DC=company,DC=com).

Reply
  • 0 over 7 years ago

    Hi,

    Thanks for the suggestion. I've tried it, but it doesn't help any. The sync is still hitting every object the container even when I have crossed out the problem OU in the treeview and configured filters like this.

    contact: (!(msDS-parentdistname=OU=ProblemOU,OU=parentOU,DC=company,DC=com)
    organizationalUnit: (!msDS-parentdistname=OU=ProblemOU,OU=parentOU,DC=company,DC=com)

    The equivalent object filters are:

    contact: not (msDS_parentdistname='OU=ProblemOU,OU=parentOU,DC=company,DC=com')
    organizationalUnit: not (msDS_parentdistname='OU=ProblemOU,OU=parentOU,DC=company,DC=com')

    If I use this query string from the directory root in an LDAP tool, I get the 28 rows I need in less than 0.2 seconds and it doesn't return the ProblemOU objects before filtering them out of the result list; this is how the contact scope needs to work in Identity Manager.

    (&(objectClass=contact)(!(msDS-parentdistname=OU=ProblemOU,DC=company,DC=com)))

    I did some more testing. If I remove all system filters from everywhere, then set the AD syc up exactly as follows:

    (a) Scope:  deselect the problem container from the treeview on the right hand side and configure nothing on the left hand side.

    (b) Reference scope: set up as above

    (c) Schema classes for Contacts, Containers, Users: Set object filter only on the schema class for each one.

    I get the optimum performance when all three of these are configured - for example the OU list returns in 0.09 seconds if configured this way, compared to 0.8 seconds if the filters are configured differently.

    If I add any system filter to a schema class or scope, it slows back down and I am certain it is pulling objects in from the sync.

    So, to test, I configured *identical* filter logic for users and contacts.

    Users:

    • (b and c) ==> 2188 objects in 1.37 secs
    • (a, b and c) ==>  2188 objects in 1.24 secs

    Same test with Contacts:

    • (b and c) ==> 28 objects in 28.65 secs
    • (a, b and c) ==>  28 objects in 18 secs

    Sync reports clearly show it is interrogating the excluded container for objects we have expressly told it to skip:

    2017-10-25 01:32:55 -07:00 - ***REDACTED*** - VI.Projector.ADS.JobComponent.ADSComponent - d4709c0f-17a8-45ae-90ae-448e132aa934: Successful
   Unable to resolve SID or DN (CN=(names,OU=ProblemOU,OU=ParentOU,DC=company,DC=com).

Children
No Data