Our environment has 2 Windows domain controllers successfully replicating on W2k12. In that domain, like everyone else, we have tons of accounts, some of whose account attributes are required to be unique. For business reasons not worth visiting here, we need to sometimes swap attributes between accounts. That is, user1 may have (forced unique) mail of [email protected], but we many need to swap that to [email protected] in order to give user2 mail attribute [email protected].
If I execute an LDAP update to set user1 mail to [email protected], get a successful result, and then assign [email protected] to user2, I am often (but not always) confronted with a uniqueness constraint violation. Even if I close sessions between operations; pause up to 2 seconds; etc. If I give it 5-10 seconds, it seems to go through OK, but I have an HTTP response hinging on this, so I'd really like to have bounced back with a result before then.
That leaves me two questions:
- What's causing the violation to be thrown despite a successful MOD?
- Is there even a reasonable way to swap these emails without threading the operation and hoping it succeeds (or keeping the user waiting for 10-15s)?
In retrospect, it's obvious that in order to check for uniqueness the AD would query the Global Catalog, requiring you to wait for replication with whichever Global Catalog server your DC is checking against. As you say, the solution is to perform the operation on a DC that itself hosts a copy of the Global Catalog.
In your particular scenario, with only two DCs, I would suggest that you make both of them Global Catalog servers. Quite apart from the renaming issue, you don't currently have any redundancy for operations that require a GC.