sync filter syntax

ADUC and QMM are a little different ADUC is not RFC literal and QMM is RFC literal. That means this syntax, (&(!adminDescriptio=exclude)(samaccoutname=*))  is NOT RFC literal. (&(!(adminDescription=exclude))(samAccoutName=*))  is RFC literal.

Thank you Jeff.  Does it make sense that even though now that this filter is accepted without error and even though I am setting the sync source scope to a single OU in the source domain, the initial sync is enumerating every object and the dsa log shows "throwing.." ?  Prior to this ldap filter a full resync was quick because it was one single OU, but now it seems with the LDAP filter even though only one single OU is sourced, the entire domain enumerates ?

adminDescription is not an indexed attribute. That is the root cause of the speed of your query. 

Throwing ... Means it is part of the query record set, but is filtered out for other reasons. 

i have only 3 test accounts in the source OU I targeted so it's strange that the filter forces an enumeration of every userID in the domain.  I changed the filter to be  (&(!(adminDescription=exclude))(samAccoutName=qmm*))  since the three test accounts all are nammed with the qmm prefix, and now the resync takes a few seconds.  So leaving the samccountName=* seems to be the culprit.  Do you concur?  

A full sync enumerates the full domain, "throwing" out, out of scope objects. It does this to build a cache for the domain to allow the delta syncs to only get the changes from USN=X and higher. So setting the query to query unindexed attributes has a geometric impact on the full sysc speed that directory corolates with the number of objects in the domain. You can cut the number of objects by exclusing object classes you do not need. 

In both cases the 'AND' in the filter was adminDescription=exclude, which is unindexed.  if I'm still querying an unindexed attribute why is it so much faster when  samaccount=qmm* versus samaccount=*  ?  

samaccount=qmm* filters in the query only objects with qmm in the same account name AND vers All object with samAccountName attribute. 1M object vers 3 object. More object to throws.

that makes sense.  Since this is considered an advanced filter, does that mean if we enable object deletion sync it will not work because the adminDescription attribute isn't preserved on delete (tombstone)?  Or will it be the case that since we have a double condition in the filter (samaccount=*)AND(adminDescription is not Exclude), then sync deletions would still succeed since the filter would still meet the criteria (where samaccount name preserved by default therefore meeting criteria 1, and admindescription will be null which would still meet criteria 2).

The deletion would apply. One is scope of the objects, the other is the value that changed on the object. The only way to the delete would be missed if it the object fell outside of the scope and then was deleted. I.E. Moved out of the OU in and then deleted. 

so what about KB 4254857?  (object deletion not synchronized when advanced filter used).  If I keep a simple advanced filter like !(admindescription=exlude) , and the user is successfully sync'd, then it gets deleted in source, since that attribute is not preserved in tombstone wouldn't the sync deletion fail?