Some food for thought. If you start putting in policies to deal with looping through larger lists
of members, go increase your heap size. By default it is set to 64MB. Easy to blow through that
with groups. Go bump it to 256 and you'll have plenty of room to work. Memory is cheap.

Also, I would check the merge authority in your filter for the group memberships. If you are
getting AD wiping out eDir values you could have something awry there if eDir is actually authoritative.

On 8/14/2012 3:46 PM, ambradley wrote:
> We've got a problem, unsure how it happened, where group members in eDir
> and AD do not match on at least a few of the >1,000 groups. It is a
> seemingly impossible task to verify whether the group members match
> because group membership is stored by CN in both, but CNs don't match in
> the two systems (CN in eDir matches sAMAccountName but not cn, which is
> in a "Last, First@DEPT" format).
> The AD forest and domain functional level are Windows 2008 so it does
> delta group member adds and deletes. I tried exporting then deleting and
> adding (changetype: modify, replace: member) all members from a group in
> eDir that I knew had at least one mismatch, but when the event syncs via
> IDM and it attempts to remove a user that isn't in the group in AD, it
> throws an LDAP_UNWILLING_TO_PERFORM error and none of the users get
> deleted.
> I'd almost prefer to have the W2K3 style of group member updates so
> that it removes, then re-adds all members. Is it OK for me to change the
> AD functional level in the driver, remove and re-add all group members,
> then change it back? Or, does anyone have a more elegant solution?
> Another possible solution that just came to mind is to massage the eDir
> LDIF export of group members into a separate LDIF entry for each member
> of each group - remove each group member one by one, let it error on the
> members not in the AD group, then add all the members back to the
> groups. What do you think?