in the driver config, turn off support for DirSync Incremental updates
and see what happens when you make a change to the group in AD.

> 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?