AttributeValueMustBeUnique and InvalidSoftMatch: duplicate objects stop sync

Fix it now

Entra ID rejected an object your sync engine tried to write because one of its values already belongs to something else. Microsoft documents that mail, proxyAddresses, signInName and userPrincipalName cannot be duplicated across objects. Nothing is lost – the object is parked until you decide which side keeps the value.

Start-ADSyncSyncCycle -PolicyType Delta

1. On the synchronisation server, open Synchronization Service Manager, go to Operations and select the most recent export that reported errors.
2. Open the failing object and note the attribute and the exact value in conflict. That is the whole diagnosis; everything after it is a decision about which object wins.
3. Find the other holder in the cloud: active users and deleted users in the Microsoft 365 admin center, and a recipient search in Exchange Online for mail addresses.
4. Decide which object keeps the value, then remove or change it on the other one – at source in Active Directory if the object is synchronised.
5. Run the delta cycle above, then re-open the export results and confirm the object exports cleanly.

Fix duplicates at source. Editing the cloud copy leaves the collision waiting to recur at the next synchronisation.

If the export clears, you are done. If the match is being refused rather than the value duplicated, the next section separates soft match, hard match and object type mismatch, which are three different refusals.

Why it happens

User principal names, primary mail addresses and proxy addresses have to be unique across a tenant, because they are how mail is routed and how people sign in. Microsoft states the schema does not allow two or more objects to share a value for mail, proxyAddresses, signInName or userPrincipalName, and AttributeValueMustBeUnique is raised when the sync engine tries to add or update an object with a value another object already holds. Writes arriving from synchronisation are validated on arrival like any other write.

Matching is the other half of the story. When an on-premises object arrives with no cloud object linked to it, the engine looks for an existing cloud object with the same soft-match attributes and links the two. Microsoft documents InvalidSoftMatch as the case where hard match found nothing, soft match found a candidate, and that candidate’s immutableId differs from the incoming object’s sourceAnchor – which implies it was already synchronised from a different on-premises object. ObjectTypeMismatch is the same collision across object types: two objects of different types, user, group or contact, holding the same soft-match values, which the directory does not permit.

Hard matching is restricted separately and deliberately. Microsoft documents InvalidHardMatch as error type 103, raised when Entra ID blocks the hard match because the target cloud user is protected from takeover or reassociation – the account is assigned or eligible for a privileged role, or its onPremisesObjectIdentifier is already set, or the tenant has BlockCloudObjectTakeoverThroughHardMatchEnabled turned on. That protection exists to stop an on-premises object taking over a privileged cloud account, so the recovery paths are deliberately explicit rather than a switch you flip.

Full reference

Identifying the conflicting pair

Why some objects appear anyway, with a strange name

Duplicate attribute resiliency is the default behaviour for all Entra tenants and it explains objects that turn up in the cloud with an identity nobody recognises. Microsoft documents it as handling only two attributes, userPrincipalName and SMTP proxyAddress. Without it, an object whose UPN or proxy address violates the uniqueness constraint is simply blocked from being created, and keeps failing until the conflict is resolved.

With it, the conflicting value is quarantined instead. For a required attribute such as UPN, the service assigns a placeholder in the form of the original prefix, a four-digit number, and the initial tenant domain ending in onmicrosoft.com. For an optional attribute such as proxy address, the conflicting value is simply quarantined and the object is created or updated regardless. The quarantined values are stored in a multi-valued attribute named DirSyncProvisioningErrors, and a background task runs hourly to release them once the conflict is resolved.

So an account that exists in the cloud with a placeholder-looking UPN has not been half created. It has been created with the conflicting value held aside, and it will pick up the real value on its own once you clear the duplicate at source.

Working the two event trails

• The authoritative record is the export result in Synchronization Service Manager: Operations, the failing run, then the object. It names the object, the attribute and the value.
• Microsoft Entra Connect Health sync reports are the documented route for identifying the duplicated value and the conflicting objects without opening the console on the server.
• Event ID 6941 and the error number 0x8023134A are commonly quoted alongside these failures, but Microsoft does not publish a meaning for either. Do not build a diagnosis on them; work from the named error and the object.
• Repeat the cycle after every change rather than batching several fixes, so you can tell which change cleared which object.

Deleting to release a value

Deleting a cloud object to release an address can remove a mailbox and its contents. Confirm what data the object holds, and what your retention arrangements actually cover, before you delete anything permanently.

1. Establish that the object is genuinely obsolete, not merely inconvenient.
2. Check whether it is receiving mail at the contested address.
3. Soft-delete it and confirm the conflict is still present, because a soft-deleted object keeps its addresses.
4. Purge it only when you are certain, then run a delta cycle.
5. Confirm the export clears rather than assuming it will.

Every code this article covers

Confirm the fix worked

1. The export run completes with no errors for the object you fixed.
2. The object appears in the tenant with the correct user principal name and addresses, and not a placeholder.
3. The other holder of the value no longer carries it.
4. A second delta cycle runs clean, confirming the fix was made at source rather than in the cloud copy.

Questions people ask about this