Entra Connect sync: fix duplicate attributes, export errors, and no-join objects

TL;DR — When Entra Connect starts throwing sync errors, the fastest wins are: identify whether the failing object is blocked by a duplicate proxyAddresses/UPN, an export error in the connector space, or a join mismatch caused by sourceAnchor/immutableId or attribute drift. Start in Synchronization Service Manager, isolate the exact object and error text, then fix the attribute collision in the authoritative source and run a delta sync. Reading time: ~6 min

The scenario

It is Tuesday afternoon and your helpdesk starts forwarding screenshots from users who changed names, got married, or were rehired last week and still do not exist correctly in Entra ID. A few cloud accounts are missing aliases, one mailbox-enabled user is stuck with the wrong sign-in name, and the sync server shows a clean scheduler heartbeat even though exports are failing. You open Entra Connect and see red on the Azure AD connector, but the errors are split across duplicate attributes, export failures, and a handful of objects that refuse to join. You need to identify which objects are actually blocked, fix the authoritative source once, and avoid making the connector space messier.

Symptoms

• Users or groups never appear in Entra ID after existing on-prem for hours.
• Attribute updates do not reach cloud objects even though sync runs complete.
• In Synchronization Service Manager, Operations shows export failures on the Azure AD connector.
• Typical error text in export details:

dn-attributes-failure
AttributeValueMustBeUnique
The value of attribute 'proxyAddresses' is not unique.

• Other common export errors:

dn-attributes-failure
AttributeValueMustBeUnique
The value of attribute 'userPrincipalName' is not unique.

permission-issue
Insufficient access rights to perform the operation

stopped-extension-dll-exception

• In Connectors → <connector> → Search Connector Space, the object exists in both AD DS and Azure AD connector spaces but does not join to a single metaverse object.
• In Metaverse Search, you see two person objects that should be one, or one connector with Disconnectors / Explicit Disconnectors.
• PowerShell against Entra ID or Exchange Online shows duplicates on addresses/UPNs.
• Event Viewer on the sync server logs sync engine warnings/errors under:

Applications and Services Logs/Microsoft/AzureADConnect
Application

Likely causes

Step-by-step diagnosis

1. Check whether the sync engine is actually failing on export, not import or scheduler.

Get-ADSyncScheduler
Get-ADSyncConnectorRunStatus

If you see a connector stuck in progress for an unusual time or repeated recent export failures, this is an active sync problem. Jump to step 2.

1. Open the exact failing operation and copy the real error text.

Synchronization Service Manager → Operations → sort by End Time descending → open the latest Export on the Azure AD connector → click Errors

If the error contains AttributeValueMustBeUnique, this is almost certainly a duplicate attribute problem. Jump to Fixes → Duplicate proxyAddresses or UPN. If it says permission-issue, jump to Fixes → Connector permissions/account issue. If the object is not in the error list but still does not sync, continue.

1. Find the object in the AD connector space.

Synchronization Service Manager → Connectors → <your AD DS connector> → Search Connector Space → Scope: Pending Export / All → search by sAMAccountName, mail, or DN

If the object is missing entirely, it is filtered out before sync; jump to step 6. If it exists but shows as a disconnector or has pending import/sync only, continue.

1. Check whether the object joined to the metaverse.

Open the connector space object → Properties → Metaverse Object Properties

If there is no metaverse object, or the object is an explicit disconnector, this is a join problem. Jump to Fixes → Join failure from sourceAnchor/immutableId or re-created object. If it does join, continue.

1. Inspect all connectors on the metaverse object.

Synchronization Service Manager → Metaverse Search → search the user → open object → Connectors

If you see two person objects in the metaverse for what should be one identity, or one AD connector plus one Azure AD connector attached to different metaverse objects, this is usually a stale object or join mismatch after rename/re-hire. Jump to Fixes → Stale connector-space object or rehire/rename collision.

1. Check whether a sync rule or OU/domain filtering excluded the object.

Get-ADSyncRule | Sort-Object Precedence | Select-Object Name,Direction,Precedence,DisabledIdentifier

Also check the wizard/config for OU filtering on the sync server. If the object’s OU or attribute state changed recently and the object is absent from connector space, this is a filtering/rule issue. Jump to Fixes → Sync rule or filtering issue.

1. For duplicate attributes, confirm where the duplicate lives before changing anything.

Get-ADObject -LDAPFilter "(|(proxyAddresses=smtp:alias@contoso.com)(proxyAddresses=SMTP:alias@contoso.com)(userPrincipalName=user@contoso.com))" -Properties proxyAddresses,userPrincipalName,mail | Select-Object DistinguishedName,ObjectClass,userPrincipalName,mail,proxyAddresses

If only one on-prem object has the value, the duplicate may already exist in Entra ID from a cloud-only or deleted object. Check cloud side and then fix in the authoritative source.

1. Preview the object before forcing another sync.

Synchronization Service Manager → Connectors → <AD DS connector> → Search Connector Space → open object → Preview → Full Synchronization

If preview shows the object still will not join or will export the conflicting value, do not run another cycle yet; apply the relevant fix first.

Fixes

Duplicate proxyAddresses or userPrincipalName

Find every holder of the conflicting value in AD DS:

$upn = 'user@contoso.com'
$addr = 'smtp:alias@contoso.com'
Get-ADObject -LDAPFilter "(|(userPrincipalName=$upn)(proxyAddresses=$addr)(proxyAddresses=SMTP:alias@contoso.com))" -Properties proxyAddresses,userPrincipalName,mail | Format-List DistinguishedName,ObjectClass,userPrincipalName,mail,proxyAddresses

If the duplicate is a stale contact, group, or disabled user, remove or change the conflicting attribute on the wrong object:

Set-ADUser "CN=Wrong User,OU=Disabled,DC=contoso,DC=com" -UserPrincipalName "wrong.user-archive@contoso.com"
Set-ADObject "CN=Old Contact,OU=Contacts,DC=contoso,DC=com" -Remove @{proxyAddresses='smtp:alias@contoso.com'}

If the duplicate exists only in Entra ID, identify the cloud object and clear the conflicting alias/UPN there if that object is cloud-managed. If it is synced, fix on-prem instead. Then run a delta sync:

Start-ADSyncSyncCycle -PolicyType Delta

Verify it worked:

Get-ADSyncConnectorRunStatus

No new AttributeValueMustBeUnique on the next Azure AD export means the fix took.

Join failure from sourceAnchor / immutableId or re-created object

This is common after deleting and recreating a user on-prem, changing anchor strategy historically, or restoring from backup. First inspect the on-prem object’s anchor value:

Get-ADUser user1 -Properties objectGUID,mS-DS-ConsistencyGuid | Select-Object SamAccountName,ObjectGUID,mS-DS-ConsistencyGuid

If your deployment uses mS-DS-ConsistencyGuid as source anchor, the re-created object will have a different value unless you deliberately preserved it. In the metaverse/connector space, if the cloud object is attached elsewhere or not joining, the safe fix is usually to let the authoritative on-prem object project cleanly and remove the stale cloud-side linkage.

⚠️ Deleting connector-space objects or cloud users can cause attribute loss, license detachment, or mailbox side effects. If the object is licensed or mailbox-enabled, confirm the identity lifecycle path before deletion.

For a pure stale cloud object that should be rejoined to the on-prem identity, remove the stale cloud-only object or move it out of scope, then sync again. If you must hard-match a cloud object to an on-prem object, set the cloud immutable ID to the on-prem anchor value in Base64 using the supported admin tooling for your tenant workflow. Do this only if you have confirmed the object really is the same identity. Run a full sync if joins were recalculated:

Start-ADSyncSyncCycle -PolicyType Initial

Verify it worked:

Metaverse Search → user → Connectors shows both AD DS and Azure AD connectors on the same metaverse object

Stale connector-space object or rehire/rename collision

A rename, rehire, or move between OUs can leave old connector-space state that prevents clean join/export. Inspect the object lineage and pending operations:

Synchronization Service Manager → AD DS connector → Search Connector Space → open object → Lineage / Preview

If you see an old disconnected object plus a new projected object for the same user, clear the stale one from scope or delete the obsolete object from the authoritative directory, then run sync. If the stale state is only in connector space and the source object is already gone from AD, use the connector-space delete for the obsolete entry.

⚠️ Deleting a connector-space object is invasive. Delete only the obsolete disconnected entry, not the active source object.

After cleanup:

Start-ADSyncSyncCycle -PolicyType Initial

Verify it worked:

Search Connector Space → only one active connector-space object remains for the user, and export no longer fails

Connector permissions/account issue

If export errors show permission-issue or the connector account lost rights, re-run the Entra Connect configuration wizard on the sync server and repair the connector credentials/permissions using the built-in path for your installed version. For a quick health check first:

Get-ADSyncConnectorRunStatus

Check Event Viewer for permission-related details:

Event Viewer → Applications and Services Logs → Microsoft → AzureADConnect

If the account password changed outside the tool or required rights were removed, update the connector credentials in the wizard and trigger a new cycle:

Start-ADSyncSyncCycle -PolicyType Delta

Verify it worked:

Operations → latest Azure AD Export completes with 0 adds/updates/deletes in error

Sync rule or filtering issue

If the object never enters connector space, check OU/domain filtering in the sync configuration and any custom inbound sync rules with higher precedence than the defaults. List rules:

Get-ADSyncRule | Sort-Object Precedence | Select-Object Name,Identifier,Direction,Precedence,Description | Format-Table -AutoSize

Look for custom rules that set cloudFiltered or alter join conditions. If a custom rule is the culprit, disable or lower its precedence using the Sync Rules Editor, then run an initial sync. Also confirm the object’s OU is selected in the connector configuration. After changing filtering or join rules:

Start-ADSyncSyncCycle -PolicyType Initial

Verify it worked:

AD DS connector → Search Connector Space now returns the object, and Preview shows a join/projection instead of filter

Prevention

• Add a pre-sync duplicate check for UPN and proxy addresses in AD DS and schedule it daily:

Get-ADObject -LDAPFilter "(|(proxyAddresses=*)(userPrincipalName=*))" -Properties proxyAddresses,userPrincipalName |
  ForEach-Object {
    foreach ($p in $_.proxyAddresses) { [pscustomobject]@{Type='proxy';Value=$p.ToLower();DN=$_.DistinguishedName} }
    if ($_.userPrincipalName) { [pscustomobject]@{Type='upn';Value=$_.userPrincipalName.ToLower();DN=$_.DistinguishedName} }
  } |
  Group-Object Type,Value | Where-Object {$_.Count -gt 1} |
  Select-Object Name,Count,@{n='DNs';e={$_.Group.DN -join '; '}}

• Alert on export errors from the sync engine instead of only scheduler status. Poll recent operations and fail your monitoring check if any Azure AD export has errors:

Get-ADSyncRunProfileResult | Select-Object -First 20 ConnectorName,RunNumber,Result,StartDate,EndDate

• Pin and document your source anchor strategy. If you use mS-DS-ConsistencyGuid, preserve it during migrations/rehire workflows; do not recreate users blindly from HR imports.
• Add a rehire runbook step: search for existing cloud and on-prem identities before creating a new AD user. Minimum check:

Get-ADUser -Filter "EmailAddress -eq 'user@contoso.com' -or UserPrincipalName -eq 'user@contoso.com'" -Properties mail,userPrincipalName,proxyAddresses

• Keep custom sync rules to the absolute minimum and export their configuration after changes so you can diff precedence drift:

Get-ADSyncRule | Sort-Object Precedence | Export-Csv C:\temp\adsync-rules.csv -NoTypeInformation

• After any OU filtering or rule change, run Preview on one known user before a full sync. This catches accidental cloudFiltered or broken joins before you affect the whole tenant.

This article was written by an AI system and published pending human review. Verify anything you intend to act on.