Entra Connect sync errors: duplicate attributes, export failures, join issues

TL;DR — When Entra Connect starts throwing sync errors, the highest-probability causes are duplicate values on join-critical attributes like proxyAddresses, userPrincipalName, or mail, a bad source-anchor/immutable ID relationship, or an object scope/filtering mismatch. Start in Synchronization Service Manager and Entra admin center provisioning logs, identify the exact attribute and distinguished name involved, then fix the duplicate or anchor mismatch in on-prem AD and force a delta sync. Reading time: ~7 min

The scenario

It is Tuesday afternoon, your helpdesk starts getting "some users are missing from Microsoft 365" tickets, and a few newly created users exist in on-prem AD but never show up in Entra ID. At the same time, a mailbox change for an existing user is not syncing, and Entra Connect Health is showing export errors. You open Synchronization Service Manager and see a mix of duplicate attribute, dn-attributes-failure, and objects stuck as disconnectors that will not join. Leadership does not care whether this is metaverse, connector space, or source anchor theory; they want the affected identities fixed before the next access review run.

Symptoms

• New or updated users/groups do not appear in Entra ID after a normal sync cycle.
• Synchronization Service Manager shows export errors such as:

stopped-extension-dll-exception
permission-issue
dn-attributes-failure
cd-error
attributeValueMustBeUnique

• Entra admin center provisioning/sync error details show messages shaped like:

AttributeValueMustBeUnique
The value of attribute 'proxyAddresses' must be unique.
Conflicting object: ObjectId 12345678-90ab-cdef-1234-567890abcdef

• Join-related warnings in connector space/metaverse searches, including objects remaining disconnectors instead of joined/provisioned.
• Event Viewer on the Entra Connect server logs sync engine errors under Application with source similar to directory synchronization components.
• PowerShell sync trigger completes, but the object still does not export:

Start-ADSyncSyncCycle -PolicyType Delta

Result
------
Success

• Affected users may see one of these outcomes:
  • user absent in Microsoft 365/Entra ID
  • stale SMTP aliases or UPN in cloud
  • duplicate account in cloud not linked to on-prem object
  • group membership missing in cloud apps

Likely causes

| Source anchor / ImmutableId mismatch after hard match, restore, or domain migration | Common | ```powershell
Get-ADUser jdoe -Properties msDS-ConsistencyGuid,objectGUID | fl SamAccountName,msDS-ConsistencyGuid,objectGUID
``` |
| OU/domain filtering excludes the object, so it never enters scope or never rejoins | Common | Click-path: Entra Connect server → Azure AD Connect → Configure → Customize synchronization options → Domain/OU filtering |
| Join rules blocked by attribute mismatch (`mail`, `proxyAddresses`, UPN, soft-match collision) | Common | Synchronization Service Manager → Connector Space Search → locate object → Properties → Lineage / Connectors |
| Invalid or blocked attribute export (`dn-attributes-failure`, illegal characters, bad manager/member reference) | Occasional | Synchronization Service Manager → Operations → double-click failed Export → Error Details |
| Sync service account/permissions issue writing or reading AD attributes | Less common | ```powershell
Get-ADSyncScheduler
``` |

## Step-by-step diagnosis

1. Check the last failed run and capture the exact error class.
   - Open `Synchronization Service` on the Entra Connect server.
   - Go to `Operations`.
   - Sort by `End Time`, then open the latest run with `Export` or `Synchronization` errors.
   - If you see `attributeValueMustBeUnique` or an error naming `proxyAddresses`, `mail`, or `userPrincipalName`, jump to **Fixes → Duplicate join/export attributes**.
   - If you see `dn-attributes-failure`, jump to **Fixes → Invalid or blocked attribute export**.
   - If there are no obvious export errors but the object is missing, continue.

2. Confirm whether the object is in scope at all.
   - Open `Synchronization Service` → `Connectors` → your on-prem AD connector → `Search Connector Space`.
   - Search by DN, `sAMAccountName`, or UPN.
   - If the object is not found in connector space, jump to **Fixes → OU/domain filtering excludes the object**.
   - If found, open the object and inspect whether it is a `disconnector` or has a metaverse connection.
   - `disconnector` with no metaverse link usually means join rules or scope issue; continue.

3. Check whether the object joins to an existing cloud object or collides.
   - In `Search Connector Space`, open the object → `Properties` → `Connectors` and `Lineage`.
   - Then use `Metaverse Search` to search the expected cloud identity by UPN/mail.
   - If you find two candidate objects with overlapping SMTP/UPN values, jump to **Fixes → Duplicate join/export attributes**.
   - If the on-prem object and cloud object clearly represent the same user but are not linked, jump to **Fixes → Source anchor / ImmutableId mismatch**.

4. Run direct AD duplicate checks for the conflicted value.
   - On a domain-joined management shell:
```powershell
$val = 'user@contoso.com'
Get-ADObject -LDAPFilter "(|(proxyAddresses=smtp:$val)(proxyAddresses=SMTP:$val)(mail=$val)(userPrincipalName=$val))" -Properties proxyAddresses,mail,userPrincipalName,distinguishedName | select Name,ObjectClass,DistinguishedName,mail,userPrincipalName,proxyAddresses

• If more than one object is returned for the same effective value, jump to Fixes → Duplicate join/export attributes.
• Edge case: contacts, groups, and soft-deleted users can also conflict. If AD is clean, continue in cloud.

1. Check source anchor values for the affected user.
   • Run:

Get-ADUser jdoe -Properties msDS-ConsistencyGuid,objectGUID,userPrincipalName | fl SamAccountName,userPrincipalName,msDS-ConsistencyGuid,objectGUID

• If this user was restored, migrated, or manually hard-matched recently, and the cloud account exists but does not join, jump to Fixes → Source anchor / ImmutableId mismatch.

1. Inspect filtering and sync rules only after the cheap checks above.

   • Open Azure AD Connect → Configure → Customize synchronization options → authenticate → Domain and OU filtering.
   • If the OU containing the object is unchecked, jump to Fixes → OU/domain filtering excludes the object.
   • If filtering is correct, open Synchronization Rules Editor and review custom inbound rules affecting join precedence.
   • If a custom rule changed join behavior or scoping filter, jump to Fixes → Join rules blocked by attribute mismatch.

2. Force a delta sync after each remediation, then escalate to initial only if required.

Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta

• If the object still does not move and you changed filtering or join logic, run an initial sync:

Start-ADSyncSyncCycle -PolicyType Initial

⚠️ Initial sync is heavier and can take time on large directories. Do not stack repeated initial syncs during business hours unless you have confirmed scheduler state and capacity.

Fixes

Duplicate join/export attributes

Clean the duplicate on the authoritative source object, usually on-prem AD. Do not "fix" this by changing the wrong object in cloud first unless you are deliberately doing a hard/soft match correction.

Find all duplicates for the value:

$val = 'user@contoso.com'
Get-ADObject -LDAPFilter "(|(proxyAddresses=smtp:$val)(proxyAddresses=SMTP:$val)(mail=$val)(userPrincipalName=$val))" -Properties proxyAddresses,mail,userPrincipalName | ft Name,ObjectClass,mail,userPrincipalName -AutoSize

Remove or correct the conflicting value on the wrong object:

Set-ADUser olduser -Remove @{proxyAddresses='smtp:user@contoso.com'}
Set-ADUser olduser -Clear mail

For groups/contacts:

Set-ADObject "CN=Old Contact,OU=Contacts,DC=contoso,DC=com" -Remove @{proxyAddresses='smtp:user@contoso.com'}

Then sync:

Start-ADSyncSyncCycle -PolicyType Delta

Verify it worked:

Get-ADObject -LDAPFilter "(|(proxyAddresses=smtp:user@contoso.com)(mail=user@contoso.com)(userPrincipalName=user@contoso.com))" -Properties proxyAddresses,mail,userPrincipalName

You should see only one authoritative object for the value.

Source anchor / ImmutableId mismatch

This usually appears after restore/recreate, cross-forest migration, or manual cloud account manipulation. The fix is to align the cloud object with the current on-prem source anchor, not to keep retrying sync.

First capture the on-prem anchor:

$user = Get-ADUser jdoe -Properties msDS-ConsistencyGuid,objectGUID
$user.msDS-ConsistencyGuid

If msDS-ConsistencyGuid is empty in your deployment, inspect objectGUID and confirm your anchor design before changing anything.

⚠️ Hard-match/source-anchor corrections can attach the wrong cloud object to the wrong on-prem user if you pick the wrong account. Confirm UPN, SMTP aliases, licenses, and mailbox ownership first.

Use your cloud identity tooling to set the cloud object's immutable ID to the Base64-encoded on-prem anchor that your deployment uses. Example for a GUID value:

$guid = [Guid]'aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee'
[System.Convert]::ToBase64String($guid.ToByteArray())

Then set that value on the intended cloud user using your tenant's supported identity module/workflow, and run:

Start-ADSyncSyncCycle -PolicyType Delta

Verify it worked: in Synchronization Service Manager, the object should move from disconnector/collision state to a joined connector with successful export.

OU/domain filtering excludes the object

If the object never enters connector space, include its OU/domain in sync scope.

On the Entra Connect server:

• Open Azure AD Connect
• Click Configure
• Choose Customize synchronization options
• Authenticate
• Go to Domain and OU filtering
• Check the OU/domain containing the object
• Complete the wizard

Then run:

Start-ADSyncSyncCycle -PolicyType Initial

Verify it worked: Search Connector Space now returns the object from the on-prem AD connector.

Join rules blocked by attribute mismatch

If the object is in scope but remains a disconnector, inspect the actual join attributes and any custom rules.

Open Synchronization Rules Editor and sort inbound rules by precedence. Look for custom rules changing scoping filters or join conditions on user/group objects. If a custom rule was recently added, disable or lower its precedence only if you understand the blast radius.

Typical practical fix: normalize the expected matching attributes in AD.

Set-ADUser jdoe -UserPrincipalName 'jdoe@contoso.com' -EmailAddress 'jdoe@contoso.com'
Set-ADUser jdoe -Add @{proxyAddresses='SMTP:jdoe@contoso.com','smtp:jdoe@contoso.onmicrosoft.com'}

If a stale cloud-only object is blocking soft match, remove the conflicting SMTP/UPN from that object or retire it according to your tenant process, then run:

Start-ADSyncSyncCycle -PolicyType Delta

Verify it worked: in connector space properties, the object shows a metaverse connection instead of disconnector.

Invalid or blocked attribute export

dn-attributes-failure often means a referenced DN/linked attribute cannot be resolved or an attribute value is invalid for export.

Open Operations → failed Export → inspect Error Details. Common offenders are manager, group member, malformed proxy address values, or illegal characters introduced by upstream provisioning.

Examples:

Get-ADUser jdoe -Properties manager,proxyAddresses | fl manager,proxyAddresses
Get-ADGroup "Finance-App" -Properties member | fl member

Fix the bad reference/value, for example clearing an invalid manager:

Set-ADUser jdoe -Clear manager

Or removing a malformed SMTP alias:

Set-ADUser jdoe -Remove @{proxyAddresses='smtp:jdoe@@contoso.com'}

Then sync:

Start-ADSyncSyncCycle -PolicyType Delta

Verify it worked: the next export run shows success for the connector and no repeat of dn-attributes-failure.

Sync service account/permissions issue

If many objects fail at once, especially after service account rotation or AD permission changes, verify scheduler and service health first:

Get-ADSyncScheduler
Get-Service ADSync

Expected service shape:

Status   Name               DisplayName
------   ----               -----------
Running  ADSync             Microsoft Azure AD Sync

If the service is stopped:

Start-Service ADSync

If permissions to read/write required attributes were changed, re-run the Entra Connect configuration wizard and repair the connector credentials/permissions using the supported setup flow for your deployment.

Verify it worked: a new delta sync completes and previously broad failures stop appearing across unrelated objects.

Prevention

• Add a pre-sync duplicate check for join-critical attributes in your identity automation pipeline:

Get-ADObject -LDAPFilter "(|(mail=*)(userPrincipalName=*)(proxyAddresses=*))" -Properties mail,userPrincipalName,proxyAddresses |
  ForEach-Object {
    foreach ($p in $_.proxyAddresses) { [PSCustomObject]@{Type='proxyAddresses';Value=$p.ToLower();DN=$_.DistinguishedName} }
    if ($_.mail) { [PSCustomObject]@{Type='mail';Value=$_.mail.ToLower();DN=$_.DistinguishedName} }
    if ($_.userPrincipalName) { [PSCustomObject]@{Type='userPrincipalName';Value=$_.userPrincipalName.ToLower();DN=$_.DistinguishedName} }
  } | Group-Object Type,Value | Where-Object Count -gt 1

• Alert on sync/export failures instead of waiting for user tickets. Poll the sync scheduler and event logs from your monitoring stack:

Get-ADSyncScheduler | fl SyncCycleEnabled,NextSyncCycleStartTimeInUTC,CustomizedSyncCycleInterval

• Pin and document your source-anchor strategy. If you use msDS-ConsistencyGuid, block ad-hoc scripts from rewriting it except in a controlled migration path.

• Put OU/domain filtering under change control. Record the expected synced OUs in infra code or a checked-in runbook, and require review for any filtering change.

• Add a post-provision smoke test for every new user/group created by automation:

Start-ADSyncSyncCycle -PolicyType Delta
# then query connector space / cloud directory in your existing admin tooling for expected UPN + SMTP

• Periodically scan for malformed SMTP aliases and empty/invalid manager references introduced by upstream HR or app provisioning feeds:

Get-ADUser -LDAPFilter "(proxyAddresses=*)" -Properties proxyAddresses,manager |
  Where-Object { $_.proxyAddresses -match '@@' -or ($_.manager -and -not (Get-ADObject -Identity $_.manager -ErrorAction SilentlyContinue)) } |
  select SamAccountName,proxyAddresses,manager

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