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

Screen grabs to illustrate the difference:

Could you post your current scope filter condition and your filtered object class condition including the remark if it is an object filter or an system filter?

Thank you

I can't find a good way to use a system filter as there is a limitation in AD that prevents me using wildcards when filtering a DistinguishedName.I did try

!(ou:dn:=OUtoExclude)

And that was very fast - took the time down to 1 second - but then the target system browser wouldn't return any contacts from outside that OU either, so no use.

All the object filters for the screenshots were set up exactly the same:

not (distinguishedName like '%OU=OUtoExclude,DC=company,DC=com')

That's why I can't figure out why the contacts one takes so long to process compared to other object types that are set up the exact same way.

@Markus, I've sent you an email with more detailed screenshots.

In effect, I configured the class filter for container to be the same as the one for contact. Even if I make the two rules totally identical, the container query comes back in well under 0.2 seconds while it takes at least 20 seconds for the contact one to run.

I can't think of a reason why that is, unless the sync is still interrogating every object with objectclass=contact inside the container. But it shouldn't be touching anything in there.

The object filter filters the data after it has loaded all the data specified in your scope. And because the number of contacts are way more than the amount of all other objects you see the differences in load times.

Please keep in mind that the filter for each object is a combination of the scope filter and the filter at the object class.

And for your case you should be able to use a system filter on the scope for the organizational units as demonstrated in the screenshot.

And, your query has to by like the following (notice the ! inside of the parentheses)

If the scope filtering is not working, contact support and request the fix for VPR#28501.

EDIT: Sorry, this works on the organizational units but not on the contacts it seems. You may want to contact support for a solution.

After spending some time with Google I might have a solution for you.

Active Directory does not support the search additions you have tried to use with the !(ou:dn:=OUtoExclude) syntax.

But if your Active Directory has a schema based on Windows Server 2012 R2 you can use the following.

(!msDS-parentdistname=OUtoExclude)

Please note that the attribute msDS-parentdistname is only available starting with Windows Server 2012 R2.

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).

Thanks for the detailed analysis.

If it is slowing down when the filter is defined on the scope level, you need VPR#28501. As I have suggested before.

I've tested this with a normal & reference scope set to all object types directly (no hierarchy filter used) and it worked, fast. Sadly my version is newer than 7.1.2 that's why I am pointing to VPR#28501.

Cheers Markus.

Anyway - I've just nailed it!

Same setup as in the previous post, but with two modifications:

1. In the scope and reference scope, check the OU to exclude in the treeview, then on the left add filters for container and organizationalUnit only. Both of these need the system filter and the object filter

(!msDS-parentdistname=OU=parentOU,DC=company,DC=com)

the add this as the system filter to the filtered schema class:

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

Comparison in target system browser:

contact (all) is the default schema type. Clicking on it returned 28 rows in 18.1 seconds
contact (exclude problem OU) is the new schema type. returned the same 28 rows in 1.8 seconds

Thanks very much for the pointer; I suspected if I tried enough permutations I'd eventually find the one that works!