I'm trying to create a sync filter that will include all users that have samaccountname present and that do not have adminDescription set to Exclude. In ADUC my filter is working properly using (&(!adminDescriptio=exclude)(samaccoutname=*)) , but in QMM I get errors of invalid filter. Don't know how to get the filter to be accepted by QMM.
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.
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?
What does your testing show?
I was hoping not to have to test this filter in production because we a large user count in the source directory and the resync takes hours, but I sense that you are suggesting that sync deletion will still work even with a simple filter like (!(admindescription=exclude)). So does this mean that KB 4254857 no longer applies ?
I am telling you I don't know. I would have to test it to know . So I told you to test it.
I suspect becasue the object moves from OU=Blah,DC=Blah,DC=Blah to CN=Deleted Items,DC=,DC= it would fall out of scope and it would not be appied. Testing is the only way to know anything for sure.
I personally would never implement in production something I had not tested.
