Entra Connect Sync Errors: Duplicate Attributes, Soft and Hard Match Conflicts

Direct answer: When a user is missing from Microsoft 365, or a change made in Active Directory never reaches the cloud, the sync server almost always recorded why. Look at the export errors for the Microsoft Entra connector, name the error type, and find the other object involved: most failures are two objects claiming the same unique value (a UPN, a proxy address or a security identifier), or an on-premises object trying to take over a cloud object that the service now refuses to hand over. Fix the value in the directory the object comes from, usually on-premises AD, then let the next delta cycle carry it. Deleting the cloud user to "make room" is the change most likely to cost mailbox data, licences and role assignments, and it is rarely needed.

Why it matters

Identity sync faults are quiet. The sync service keeps running, the scheduler keeps its 30-minute cycle, and most users carry on working. The one user who cannot sign in, the shared mailbox whose new address bounces, or the new starter who has no account in Microsoft 365 on their first day is the visible symptom of an error that may have been logged for days.

The cost of guessing is high. Each typical guess has a typical side effect:

• Deleting and recreating the cloud user can detach the mailbox, OneDrive and licence state from the account people used.
• Changing the source anchor on-premises outside a documented procedure can link the wrong account or leave a duplicate rather than a match.
• Turning off matching protections for the whole tenant can let an on-premises account take over a privileged cloud account.

Microsoft's own guidance points the same way: fix the data at its source and let synchronisation do the rest.

This article covers the common export errors and the order in which to check them. It does not cover password hash sync, writeback, federation, or custom synchronisation rules beyond showing where to look.

How it works

The sync cycle and where errors appear

Microsoft Entra Connect Sync works in three operations, run per connector:

• Import brings objects into a connector space: one for AD, one for Microsoft Entra ID.
• Synchronisation runs inbound and outbound rules through the metaverse.
• Export writes changes to the target directory.

Errors can happen at any stage. Most "user missing or not updating in Microsoft 365" cases are export errors on the Microsoft Entra connector, which is typically named after the tenant's onmicrosoft.com domain.

The built-in scheduler runs a delta cycle every 30 minutes by default. You can see its state with Get-ADSyncScheduler. If the cmdlet is not found, Import-Module ADSync loads it. A full cycle is Full Import, Full Sync and Export on every connector. Microsoft notes it can be very time-consuming, so it is not a routine troubleshooting step.

Errors are reported in three places:

• Synchronization Service Manager on the sync server. The Operations tab shows each run and its errors. By default the operations log keeps seven days.
• The Synchronization Errors report in Microsoft Entra Connect Health for sync, in the Microsoft Entra admin center. Microsoft states it is updated every 30 minutes and shows errors from the latest attempt. It needs the Connect Health agent, and the licensing that comes with it.
• The tenant itself, for conflicts handled by duplicate attribute resiliency (next section). These can produce no error on the sync server at all.

Duplicate attribute resiliency changes what you see

Some attributes must be unique across the tenant. The sync errors page lists mail, proxyAddresses, signInName and userPrincipalName for the uniqueness error, and gives a wider set for the soft-match error (adding onPremisesSecurityIdentifier, objectId and immutableId).

Before duplicate attribute resiliency existed, an object with a duplicate UPN or proxy address failed to export on every cycle. Resiliency is now the default for all tenants: it is on for tenants that first enabled sync on or after 22 August 2016, older tenants were enabled in batches from September 2016, and it cannot be turned off. With resiliency on, Microsoft Entra ID "quarantines" the conflicting value:

• A required UPN is replaced by a placeholder in the form <OriginalPrefix>+<4DigitNumber>@<InitialTenantDomain>.onmicrosoft.com.
• A conflicting proxy address is dropped from the object, and the object is created or updated without it.
• The conflict is recorded in a DirSyncProvisioningErrors attribute on the user, group or contact. It appears in the tenant's error notification email once, at the time of quarantine.
• An hourly service-side task puts the value back once the conflict is resolved.

The practical consequence: an object can export "successfully" with the wrong UPN or a missing address, and the sync server records no error. The resiliency page states this directly, and it applies only to UPN and SMTP proxy address values.

So if a user says "my sign-in name is something like jsmith+1234@contoso.onmicrosoft.com", or "mail to my new alias bounces", and the sync server is clean, look in the tenant rather than at the server.

Soft match and hard match

When a new object arrives from on-premises, Microsoft Entra ID tries to match it to an existing cloud object before creating a new one:

• Hard match: the incoming sourceAnchor equals an existing object's ImmutableId. By default the sourceAnchor is the Base64 form of mS-DS-ConsistencyGuid, or objectGUID depending on configuration.
• Soft match: if no hard match is found, the service tries the incoming userPrincipalName or primary SMTP address. Only the SMTP: primary value of proxyAddresses counts.

A successful match converts the cloud object to on-premises managed. Every attribute that has a value on-premises overwrites the cloud value, and with password hash sync the cloud password hash is replaced too. Microsoft warns that values kept only in the cloud are lost if AD does not hold them.

Matching is evaluated only for new objects coming from on-premises. Changing an existing synced object so that it matches another cloud object produces an error, not a merge.

The hard-match hardening that took effect in 2026

The sync errors page, updated 2 July 2026, describes security hardening for hard match enforced automatically from 1 July 2026. A hard match is blocked when the target cloud user:

• has onPremisesObjectIdentifier set; or
• is assigned, or eligible for, a privileged role.

Hard match is also blocked when the tenant has BlockCloudObjectTakeoverThroughHardMatchEnabled set. The result is an InvalidHardMatch error (error code 103) or AttributeUpdateNotAllowed (96).

A tenant can also block soft matching altogether with BlockSoftMatchEnabled. Microsoft encourages switching either block off only while a matching procedure is under way, and back on afterwards.

Read-only checks

None of these was run for this article. Run them on the sync server, or from an administrative workstation with Microsoft Graph PowerShell or the Microsoft Entra PowerShell module.

Privileges and side effects:

• Synchronization Service Manager and the ADSync cmdlets need local administrative access to the sync server, or membership of the sync service's administration groups created at install. Check which groups your installation uses.
• The Graph and Entra cmdlets need read scopes such as OnPremDirectorySynchronization.Read.All and Directory.Read.All, granted to whoever signs in.
• The checks below only read. "Preview" in the connector space with Generate Preview keeps changes in memory; Commit Preview writes to the metaverse and is not read-only.

1. Confirm the scheduler is running and when it last ran

Get-ADSyncScheduler

Check these fields:

A disabled scheduler or a server left in staging mode explains "nothing updates" for everyone, not for one object. Rule that out before chasing individual errors. Before you state that nothing has exported, or rely on this state while making a change, open the Operations tab in Synchronization Service Manager on that server and check the run history, including any run in progress or started by hand.

2. Read the export error on the sync server

1. In Synchronization Service Manager, open Operations.
2. Select the most recent Export run on the Microsoft Entra connector.
3. Open each error and note: - the error type, such as AttributeValueMustBeUnique, InvalidSoftMatch, ObjectTypeMismatch or LargeObject; - the distinguished name of the on-premises object; - the conflicting attribute and value, where shown.
4. From the error, Connector Space Object Properties and Lineage show which inbound and outbound rules produced the value and link to the metaverse object.

The Connect Health Synchronization Errors report shows the same errors grouped by category, and for duplicates it names both objects in the conflict. That is often faster than searching for the second object by hand.

3. Look for quarantined values in the tenant

Use this when the sync server shows no error but a UPN looks like a placeholder or an address is missing:

Connect-Entra -Scopes 'Directory.Read.All'
Get-EntraDirectoryObjectOnPremisesProvisioningError |
  Where-Object PropertyCausingError -eq 'ProxyAddresses'

Swap 'UserPrincipalName' for the UPN case, or add | Where-Object Value -eq 'alias@contoso.com' to narrow it to one value.

The resiliency page still also shows the older Get-MsolDirSyncProvisioningError cmdlet from the MSOnline module. Prefer the Entra cmdlet; do not install the legacy MSOnline module for this.

The Microsoft 365 admin center also lists directory synchronisation errors, but only for users. Conflicts between groups and contacts do not appear there.

4. Find the other object

A duplicate always has two sides. Search for the value everywhere it can live:

• On-premises AD: search proxyAddresses and userPrincipalName across all object classes (users, contacts, groups, and public folder or mail-enabled objects), and across every synced domain and forest. For example:

powershell Get-ADObject -LDAPFilter '(proxyAddresses=smtp:alias@contoso.com)' -Properties proxyAddresses

Check that the search returns both the primary (SMTP:) and secondary (smtp:) forms in your environment; also search mail and userPrincipalName.

• The tenant: find users, groups and contacts holding the address, including cloud-only groups created in Microsoft 365.

An ObjectTypeMismatch is the clue that the other side is a different object class. Microsoft's example is a mail-enabled security group created in Microsoft 365 with an address that a new on-premises user then also receives.

5. Check matching protections and the target account's state (for match errors)

Connect-MgGraph -Scopes 'OnPremDirectorySynchronization.Read.All'
Get-MgDirectoryOnPremiseSynchronization |
  Select-Object -ExpandProperty Features |
  Format-List BlockCloudObjectTakeoverThroughHardMatchEnabled, BlockSoftMatchEnabled

For the target cloud user, read:

• onPremisesImmutableId, and compare it with the incoming object's sourceAnchor (the Base64 form of its anchor attribute, shown in the sync server's connector space). Equal values are a hard match; a different value on a soft-match candidate is what produces InvalidSoftMatch; an absent value leaves the account open to soft match. A populated value on its own does not forbid a hard match;
• whether onPremisesObjectIdentifier is set (where your tooling exposes it), which blocks a hard match under the 2026 hardening;
• whether it holds, or is eligible for, any privileged directory role, which also blocks a hard match;
• the tenant flags read above.

Match each finding to the exact error the sync server reports. Each check is a separate protection; one being true does not explain an error that names another.

Interpreting the results

Some figures help keep size errors in proportion:

• Microsoft gives worked examples of a user able to hold about 332 proxy addresses with few other attributes, dropping to 311 with certificates and licences.
• Its rule of thumb is to plan for about 300.
• Those are Microsoft's illustrative numbers, not limits to test against.

Decision guidance

Every change below writes to a directory. Record the before value of each attribute you edit; that record is the rollback.

Duplicates and type mismatches

1. Decide which object legitimately owns the value. It is usually the long-standing mailbox or account people already use. A newly created duplicate rarely wins.
2. Remove or change the value on the other object, in its source directory. - For an on-premises object, edit AD. Use the Exchange management tools where Exchange attributes are managed that way. - For a cloud-only group or contact, edit it in Microsoft 365. - Do not edit the cloud copy of a synced object to work around it. Sync overwrites it, or the edit is refused.
3. Let the next delta cycle run, or start one with Start-ADSyncSyncCycle -PolicyType Delta. This triggers a normal delta run of the existing configuration; it does not change rules.
4. Verification: - the export error is gone from the next Export run on the sync server; - for quarantined values, the placeholder UPN or missing address is back. Allow for the hourly service task, and for Connect Health's 30-minute refresh.
5. Rollback: restore the recorded attribute values. If the wrong object lost the value, the conflict comes back on the next cycle and is visible in the same places.

Soft-match failures after a forest move, rebuild or re-created account

The pattern is an old cloud object holding an immutableId from the old AD object, and a new AD object with a different anchor.

1. Do not assume deleting the cloud object is the fix. Identify whether the cloud object carries the mailbox and data that users rely on. Usually it does.
2. The supported paths are described in Microsoft's "Configure Microsoft Entra Connect for an existing tenant" page under its hard match scenarios and recovery paths. Choose the one that matches your situation and follow it as written.
3. When a re-created on-premises user has the same UPN and SMTP but a new SID, the existing-tenant page says these scenarios "typically mean that you're trying to reprovision the same user", and directs updating the on-premises user's mS-DS-ConsistencyGuid to the existing cloud user's ImmutableID so a hard match can occur. Treat it as a planned re-link: confirm it is the same person, record the current values, get approval, then make the change.
4. Verify in the sync server Lineage view and the tenant that one cloud object is now linked to one AD object, and that only one user holds the address.

Refused hard match (2026 hardening)

The refusal is a protection working. The documented remediations are all deliberate, temporary changes to the target account or tenant:

• temporarily removing the target user's role assignment or eligibility;
• clearing onPremisesObjectIdentifier;
• temporarily setting allowOnPremUpdateOfOnPremisesObjectIdentifierEnabled;
• temporarily disabling BlockCloudObjectTakeoverThroughHardMatchEnabled.

Each one weakens a protection for the duration.

• Who approves: the person responsible for privileged access. Never as a by-product of fixing sync.
• Order: confirm the on-premises account is the one that should own the cloud account, and that its data on-premises is complete. Overwritten cloud attributes are not restored by undoing the match.
• Verification: the match completes on the next cycle; the export error clears; the user signs in with the expected account.
• Rollback, same day: restore the role, eligibility or tenant flag. Record the time each protection was off.

For an Existing Admin Role Conflict, Microsoft's procedure involves removing the cloud account from admin roles, hard-deleting the quarantined object, letting soft match complete and then restoring roles. Hard deletion is irreversible. Treat it as a planned change with its own approval, not a troubleshooting step.

Large objects

Remove values that are no longer needed, on-premises:

• revoked or expired certificates;
• stale SMTP, X.400, X.500 and other legacy addresses.

Before removing an X.500 address, check with whoever runs Exchange whether it is still needed for mail to an old mailbox; it is often kept for that reason.

Rollback is restoring the recorded values.

Sync server changes

If you need to change sync rules or filtering, the standard order is:

1. Set-ADSyncScheduler -SyncCycleEnabled $false.
2. Make the change.
3. Run the required sync steps.
4. Set-ADSyncScheduler -SyncCycleEnabled $true.

Forgetting step 4 is a common cause of the "nothing updates any more" symptom.

To see what a change will export before it happens, a server in staging mode runs import and sync without exporting. Microsoft's staging-server page shows how to export the pending changes with csexport and CSExportAnalyzer, and review them before making that server active.

Staging mode also suppresses password hash sync and writeback on that server. Microsoft warns that password sync catch-up after leaving staging mode can take a long time.

What not to do

• Do not delete a synced cloud user to clear a conflict before you know what it holds. Even where a deleted user can still be restored, relinking data, licences and group membership is work you created.
• Do not change mS-DS-ConsistencyGuid or the source anchor ad hoc to make an object "match"; an anchor that points at the wrong cloud object links the wrong identity. The one exception is Microsoft's documented reprovisioning of the same user, where the existing-tenant page directs setting mS-DS-ConsistencyGuid to the cloud user's ImmutableID: do it only after confirming both are the same person, with approval, a record of the current values and a check in Lineage afterwards.
• Do not disable the hard-match or soft-match blocks tenant-wide as a standing setting. Use them only for a named matching window, then turn them back on.
• Do not run a full sync cycle by reflex. It is slow and does not resolve data conflicts. Microsoft lists the configuration changes that actually need it.
• Do not edit the cloud copy of a synced attribute. The source of authority is on-premises; the edit is either refused or overwritten.
• Do not leave the scheduler disabled after a rule change. Check SyncCycleEnabled before you finish.
• Do not trust a clean sync server alone. Quarantined conflicts live in the tenant.

Limitations

• Cloud Sync is not covered. Microsoft Entra Cloud Sync uses a different agent and configuration. Its matching rules are similar, but this article does not cover its portal, provisioning logs or quarantine behaviour.
• Product and cmdlet names change. Azure AD Connect became Microsoft Entra Connect, MSOnline cmdlets were superseded, and the resiliency page still mixes the two. Check current documentation before scripting.
• Exchange hybrid adds rules of its own for proxy addresses, X.500 addresses and mail-enabled objects that this article only touches on.
• Hardening dates and flag names come from Microsoft Learn pages updated in July 2026. They may change again.
• Connect Health's errors report needs its agent and licensing. Without them, the sync server and tenant cmdlets are your sources.
• Untested. The procedures here were not tested for this article.

Acceptance checklist

• [ ] Scheduler state checked: SyncCycleEnabled true, staging mode off on the active server, no stuck suspension.
• [ ] Each error named by type, with the on-premises distinguished name and the conflicting value recorded.
• [ ] The second object in every duplicate identified, in AD (all object classes, all synced forests) and in the tenant.
• [ ] Quarantined values checked in the tenant when the sync server showed no error.
• [ ] Owner of each disputed value decided and recorded; before values saved.
• [ ] Fix applied in the object's source directory, not to the synced cloud copy.
• [ ] Any change to a protection (role removal, takeover block, soft-match block) approved, timed and reversed the same day.
• [ ] Next Export run shows no error for the object; placeholder UPN or missing address restored in the tenant.
• [ ] The user confirmed sign-in or mail delivery with the expected account.

References

All accessed 2 November 2026.

• Microsoft Learn, "Troubleshoot errors during synchronization" (updated 2 July 2026): https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/tshoot-connect-sync-errors
• Microsoft Learn, "Identity synchronization and duplicate attribute resiliency" (updated 9 April 2025): https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-syncservice-duplicate-attribute-resiliency
• Microsoft Learn, "Configure Microsoft Entra Connect for an existing tenant" (hard and soft match; updated 2 July 2026): https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-install-existing-tenant
• Microsoft Learn, "Microsoft Entra Connect Sync service features" (updated 16 July 2026): https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-syncservice-features
• Microsoft Learn, "Microsoft Entra Connect Sync: Scheduler" (updated 9 April 2025): https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-feature-scheduler
• Microsoft Learn, "Microsoft Entra Connect: Staging server and disaster recovery" (updated 2 April 2026): https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/how-to-connect-sync-staging-server
• Microsoft Learn, "Troubleshoot an object that is not synchronizing" (updated 9 April 2025): https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/tshoot-connect-object-not-syncing

Related articles

• Group Policy Not Applying: gpresult, Events and SYSVOL
• Domain Controllers on VMware: Snapshots and Restores

• How to connect VMware workloads to Azure with controlled routing and private DNS

• Account Keeps Locking Out: Find the Source From Event 4740 to the Process

• Revoke a Departed Administrator's Access Across a Hosted Estate

Learning notes

1. Most "missing in Microsoft 365" cases are export errors on the Microsoft Entra connector. Read the error type before changing anything.
2. Every duplicate has two sides. Find the other object in every object class and every synced forest, and in the cloud.
3. Duplicate attribute resiliency means a conflict can leave no error on the sync server: check the tenant for quarantined UPNs and addresses.
4. Hard match uses the source anchor, soft match the UPN or primary SMTP, and matching only happens for new objects. Since 1 July 2026 hard match to privileged or already-linked cloud users is refused by design.
5. Fix data in the object's source directory, then verify on the next delta cycle; changes to protections are temporary, approved and reversed the same day.