Fix Azure AD Sync Errors: Connect & Cloud Sync Troubleshooting [2026]

Azure AD Connect and Microsoft Entra Cloud Sync are the bridge between on-premises Active Directory and the cloud. When they work, identity synchronization is invisible. When they break, the consequences are immediate: new users cannot sign in, password changes do not propagate, group memberships become stale, and conditional access policies enforce rules against outdated data. For organizations that depend on managed IT services to keep hybrid identity running, sync errors are one of the most common and disruptive issues to diagnose.

This guide covers the most frequent Azure AD sync errors, their root causes, and exact steps to fix them. Whether you are running Azure AD Connect (now Microsoft Entra Connect) or have migrated to Cloud Sync, the troubleshooting patterns apply across both engines.

If you are still in the planning stages of your hybrid identity deployment, our step-by-step guide to migrating Active Directory to Azure AD covers the full journey from on-premises to cloud identity.

Azure AD Connect vs Cloud Sync: Which One Are You Running?

Before troubleshooting, confirm which synchronization engine is in place. The two tools serve similar purposes but differ significantly in architecture, capabilities, and where errors surface.

Feature	Azure AD Connect	Microsoft Entra Cloud Sync
Architecture	Heavyweight on-premises agent with SQL database	Lightweight agent, configuration lives in the cloud
Supported topologies	Multi-forest, multi-tenant, complex filtering	Multi-forest (simplified), single tenant
Password hash sync	Yes	Yes
Pass-through authentication	Yes	No
Federation (AD FS)	Yes	No
Device writeback	Yes	No
Custom sync rules	Yes (Synchronization Rules Editor)	Limited (scoping filters and attribute mapping)
Staging mode	Yes	Not applicable (cloud-managed)
Management interface	On-premises Synchronization Service Manager	Azure portal (Entra ID > Cloud Sync)

When to use Azure AD Connect: Complex environments with pass-through authentication, device writeback, custom sync rules, or AD FS federation. Azure AD Connect remains the right choice for organizations that need granular control over synchronization behavior.

When to use Cloud Sync: Simpler topologies where centralized cloud management, automatic agent updates, and high availability across disconnected forests are priorities. Cloud Sync is also the strategic direction for Microsoft and the recommended path for new deployments where its feature set is sufficient.

Microsoft provides a detailed comparison of Azure AD Connect and Cloud Sync to help determine the right fit.

Common Sync Errors and How to Fix Them

Attribute Conflicts and Duplicate Attribute Errors

Symptom: Sync completes but reports errors like “AttributeValueMustBeUnique” or “InvalidSoftMatch.” Objects are not exported to Azure AD, or two on-premises accounts map to the same cloud identity.

Cause: Azure AD enforces uniqueness on certain attributes, including userPrincipalName (UPN), proxyAddresses, and mailNickname. When two or more objects share the same value for one of these attributes, the sync engine cannot export the conflicting object.

This frequently occurs when:

• A user was previously created directly in Azure AD (cloud-only) and then an on-premises account is synced with the same UPN or email.
• Mailbox migrations leave behind stale proxyAddresses on objects that should not have them.
• Multiple on-premises forests contain objects with overlapping SMTP addresses.

Fix:

1. Identify the conflicting objects. In the Azure portal, navigate to Microsoft Entra ID > Entra Connect > Connect Sync (or Cloud Sync) and review the sync error report. Each error includes the source object and the conflicting attribute value.

2. For duplicate proxyAddresses, use PowerShell on-premises to find all objects sharing the address:

Get-ADObject -Filter 'proxyAddresses -eq "SMTP:user@contoso.com"' -Properties proxyAddresses

3. Remove the conflicting value from the object that should not have it:

Set-ADUser -Identity "stale-user" -Remove @{proxyAddresses="SMTP:user@contoso.com"}

4. If the conflict is with a cloud-only object, either delete the cloud object or use hard matching by setting the on-premises ms-DS-ConsistencyGuid or ImmutableId to link the on-premises object to the existing cloud object.

5. Force a sync cycle to clear the error:

Start-ADSyncSyncCycle -PolicyType Delta

InvalidSoftMatch Errors

Symptom: Error code “InvalidSoftMatch” appears during export. Azure AD Connect cannot match an on-premises object to an existing Azure AD object.

Cause: Soft matching relies on the proxyAddresses attribute (specifically the primary SMTP address) to pair an on-premises user with a cloud-only user. If the primary SMTP address does not match, or if the cloud object does not have a proxyAddresses value at all, the soft match fails.

Fix:

1. Verify the on-premises user’s primary SMTP address:

Get-ADUser -Identity "jdoe" -Properties proxyAddresses | Select-Object -ExpandProperty proxyAddresses

2. Confirm the cloud object has a matching address:

Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -UserId "jdoe@contoso.com" -Property ProxyAddresses | Select-Object -ExpandProperty ProxyAddresses

3. If soft matching is not feasible, perform a hard match by setting the ImmutableId on the cloud object to the Base64 encoding of the on-premises ObjectGUID:

$guid = (Get-ADUser -Identity "jdoe").ObjectGUID
$immutableId = [Convert]::ToBase64String($guid.ToByteArray())
Update-MgUser -UserId "jdoe@contoso.com" -OnPremisesImmutableId $immutableId

4. Run a full sync cycle:

Start-ADSyncSyncCycle -PolicyType Initial

ObjectTypeMismatch

Symptom: An object fails to sync with an “ObjectTypeMismatch” error. Typically seen when a contact object in Azure AD conflicts with a user object being synced from on-premises.

Cause: Azure AD already contains a mail contact (or another object type) with the same email address as the user being synced. Since the object types differ, the sync engine cannot merge them.

Fix:

1. Identify the conflicting contact in Azure AD:

Get-MgContact -Filter "mail eq 'user@contoso.com'"

2. If the contact is no longer needed (because the on-premises user should take ownership of that identity), delete the contact:

Remove-MgContact -OrgContactId "<contact-object-id>"

3. Trigger a delta sync:

Start-ADSyncSyncCycle -PolicyType Delta

UPN Mismatch and Non-Routable Domains

Symptom: Users sync successfully but cannot sign in with their expected email address. Their UPN in Azure AD shows as user@contoso.local instead of user@contoso.com.

Cause: The on-premises UPN suffix uses a non-routable domain (like .local or .internal) that Azure AD cannot accept. Azure AD requires a verified, internet-routable domain as the UPN suffix.

Fix:

1. Add the routable UPN suffix to your on-premises Active Directory. Open Active Directory Domains and Trusts, right-click the root node, and add the new UPN suffix (e.g., contoso.com).

2. Update user UPNs in bulk:

Get-ADUser -Filter {UserPrincipalName -like "*@contoso.local"} | ForEach-Object {
    $newUPN = $_.SamAccountName + "@contoso.com"
    Set-ADUser -Identity $_ -UserPrincipalName $newUPN
}

3. Verify the domain is listed as a verified domain in Microsoft Entra ID > Custom domain names in the Azure portal.

4. Run a delta sync and confirm the UPNs update correctly in Azure AD.

This issue is closely related to broader identity planning. Our Active Directory replication troubleshooting guide covers how to ensure these changes replicate reliably across all domain controllers before sync picks them up.

Export Errors and Stopped-Server Scenarios

Symptom: The sync cycle runs but objects are stuck in a “pending export” state. The Synchronization Service Manager shows export errors with codes like “permission-issue” or “server-down.”

Cause: Export failures typically result from:

• The Azure AD Connect service account lacking the required permissions in Azure AD.
• Network connectivity issues between the Azure AD Connect server and Microsoft’s authentication endpoints.
• An expired or revoked service account credential.

Fix:

1. Open the Synchronization Service Manager on the Azure AD Connect server. Click the Connectors tab, select the Azure AD connector, and click Search Connector Space to inspect pending exports.

2. Verify network connectivity to the required Microsoft endpoints:

Test-NetConnection -ComputerName "login.microsoftonline.com" -Port 443
Test-NetConnection -ComputerName "adminwebservice.microsoftonline.com" -Port 443

3. If the connector credentials have expired, re-enter them. Open the Azure AD Connect wizard, select Customize synchronization options, and re-authenticate with a Global Administrator or Hybrid Identity Administrator account.

4. Review the full list of required endpoints and ports and ensure your firewall and proxy allow access.

Password Hash Sync Failures

Password hash synchronization (PHS) is the most common authentication method for hybrid environments and also serves as a critical fallback if pass-through authentication or federation fails. When PHS breaks, users cannot sign in to cloud resources with their on-premises credentials.

Symptom: Users report that password changes made on-premises are not reflected in Azure AD. Sign-in attempts fail with “incorrect password” even though the on-premises password is correct. The Azure AD Connect Health dashboard may show a “Password sync is not working” alert.

Diagnosing the issue:

1. Check the password sync status:

Import-Module ADSync
Get-ADSyncAADPasswordSyncConfiguration -SourceConnector "contoso.com"

2. Review the password sync heartbeat:

Get-ADSyncScheduler

Look for the NextSyncCyclePolicyType and SyncCycleInProgress properties. If the scheduler is suspended, password changes will not propagate.

3. Check the Application Event Log on the Azure AD Connect server for Event ID 611 (password sync started), 656 (password sync completed for a batch), or 657 (password sync failed).

Common fixes:

• Re-enable password hash sync: If PHS was accidentally disabled, re-enable it through the Azure AD Connect wizard or via PowerShell:

Set-ADSyncAADPasswordSyncConfiguration -SourceConnector "contoso.com" -TargetConnector "contoso.onmicrosoft.com - AAD" -Enable $true

• Restart the ADSync service: Sometimes the sync engine needs a restart to recover from transient errors:

Restart-Service ADSync

• Re-initialize password sync: If individual password syncs continue to fail, trigger a full re-synchronization of all password hashes:

$connectorName = "contoso.com"
$aadConnectorName = "contoso.onmicrosoft.com - AAD"
Import-Module ADSync
$c = Get-ADSyncConnector -Name $connectorName
$p = New-Object Microsoft.IdentityManagement.PowerShell.ObjectModel.ConfigurationParameter "Microsoft.Synchronize.ForceFullPasswordSync", String, ConnectorGlobal, $null, $null, $null
$p.Value = 1
$c.GlobalParameters.Remove($p.Name)
$c.GlobalParameters.Add($p)
$c = Add-ADSyncConnector -Connector $c
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $connectorName -TargetConnector $aadConnectorName -Enable $false
Set-ADSyncAADPasswordSyncConfiguration -SourceConnector $connectorName -TargetConnector $aadConnectorName -Enable $true

Once PHS is restored, make sure users are also configured for multi-factor authentication as a security layer on top of password-based authentication.

Filtering Issues: Objects Syncing (or Not) When They Should Not (or Should)

Filtering determines which on-premises objects are synchronized to Azure AD. Misconfigured filters are a silent source of problems — objects are either missing from the cloud or syncing when they should be excluded.

OU-Based Filtering

OU-based filtering is the most straightforward approach. Only objects in selected OUs are synchronized.

Common mistake: Creating a new OU for a department and forgetting to include it in the sync scope. All users in that OU are invisible to Azure AD.

How to verify and adjust:

1. Open the Azure AD Connect wizard and select Customize synchronization options.
2. On the Domain and OU Filtering page, expand each domain and verify that the correct OUs are checked.
3. After making changes, run a full sync:

Start-ADSyncSyncCycle -PolicyType Initial

Attribute-Based Filtering

Attribute-based filtering uses sync rules to include or exclude objects based on attribute values. For example, filtering out all users where extensionAttribute15 equals “NoSync.”

Diagnosing unexpected filtering:

1. Open the Synchronization Rules Editor on the Azure AD Connect server.
2. Review inbound sync rules with scoping filters. Look for rules with a lower precedence number (higher priority) that may override default behavior.
3. Use the Connector Space Search in Synchronization Service Manager to find the specific object and inspect why it was filtered.

Tip: If you need to exclude service accounts or shared mailboxes from sync, attribute-based filtering on a custom extension attribute is cleaner and more maintainable than managing dozens of OU exclusions.

Domain-Based Filtering

Domain-based filtering selects which domains in a multi-domain or multi-forest topology are synchronized.

Common mistake in multi-forest environments: Adding a new trusted forest but not configuring it in Azure AD Connect. Objects from the new forest are not synced.

How to add a new forest:

1. Open the Azure AD Connect wizard.
2. Select Configure source anchors or Customize synchronization options.
3. Add the new forest and provide the required credentials for the AD DS connector account.
4. Select the OUs to include and complete the wizard.

Sync Cycle Management

The sync scheduler runs automatically every 30 minutes by default. Understanding how to manage it is essential for troubleshooting.

Key PowerShell Commands

Check the scheduler status:

Get-ADSyncScheduler

Manually trigger a delta sync (only syncs changes since last cycle):

Start-ADSyncSyncCycle -PolicyType Delta

Manually trigger a full sync (re-evaluates all objects):

Start-ADSyncSyncCycle -PolicyType Initial

Temporarily disable the scheduler (useful during maintenance):

Set-ADSyncScheduler -SyncCycleEnabled $false

Re-enable the scheduler:

Set-ADSyncScheduler -SyncCycleEnabled $true

Warning: Avoid running full sync cycles during business hours in large environments. A full sync re-processes every object in the connector space and can take hours in directories with hundreds of thousands of objects.

Health Monitoring with Azure AD Connect Health

Azure AD Connect Health provides cloud-based monitoring for your on-premises sync infrastructure. It surfaces alerts for sync errors, agent connectivity problems, and performance degradation before they become user-impacting incidents.

Setting up Connect Health:

1. Ensure you have a Microsoft Entra ID P1 or P2 license (included with Microsoft 365 E3/E5).
2. The Connect Health agent is installed automatically with Azure AD Connect version 1.1.614.0 and later. For older installations, download the agent separately.
3. Verify the agent is reporting by navigating to Microsoft Entra ID > Entra Connect > Connect Health in the Azure portal.

Key health alerts to monitor:

• Sync not completing in time. The sync cycle is taking longer than the configured interval, causing cycles to be skipped.
• Export errors exceeding threshold. A spike in export errors usually indicates a systemic problem like an expired credential or connectivity failure.
• Password sync stopped. PHS has not completed a cycle within the expected window.
• Agent unreachable. The Connect Health agent on the Azure AD Connect server cannot reach the service endpoints.

For organizations following the Microsoft 365 security hardening checklist, Connect Health alerts should be integrated into your monitoring workflow alongside sign-in anomaly detections and conditional access reporting.

Staging Mode: Safe Testing and Disaster Recovery

Azure AD Connect supports a staging mode where the server imports and synchronizes data but does not export any changes to Azure AD or on-premises AD.

Use cases for staging mode:

• Pre-upgrade testing. Install the new version on the staging server, verify sync rules produce the expected results, then promote it to active.
• Disaster recovery. If the active Azure AD Connect server fails, promote the staging server to active to resume sync within minutes instead of hours.
• Validating sync rule changes. Test custom sync rules on the staging server without risking production synchronization.

How to promote a staging server:

1. On the current active server (if accessible), re-run the Azure AD Connect wizard and enable staging mode.
2. On the staging server, re-run the wizard and disable staging mode.
3. Verify that a sync cycle completes successfully and objects are exported to Azure AD.

Critical rule: Never run two active Azure AD Connect servers against the same Azure AD tenant. This causes duplicate sync operations and data corruption.

Upgrading Azure AD Connect

Microsoft regularly releases updates to Azure AD Connect that include bug fixes, security patches, and new features. Running an outdated version is a common source of sync errors that have already been resolved in newer releases.

Check your current version:

(Get-ADSyncGlobalSettings).Parameters | Where-Object {$_.Name -eq "Microsoft.Synchronize.ServerConfigurationVersion"} | Select-Object Value

Or open Programs and Features on the Azure AD Connect server and look for the “Microsoft Azure AD Connect” entry.

Upgrade approaches:

• In-place upgrade (recommended for minor versions). Download the latest installer from Microsoft’s download center and run it on the existing server. The wizard preserves your configuration.
• Swing migration (recommended for major versions). Build a new server with the latest version in staging mode, verify configuration, then promote it and decommission the old server.

Microsoft maintains a version history with details on what each release fixes. If you are troubleshooting a specific error, check whether it is addressed in a newer version before investing time in manual remediation.

Migrating from Azure AD Connect to Cloud Sync

Microsoft’s strategic direction is toward Cloud Sync as the primary hybrid identity solution. Organizations currently running Azure AD Connect should evaluate whether Cloud Sync meets their requirements and plan a migration when ready.

Pre-migration checklist:

• Confirm that Cloud Sync supports all features your environment requires (check the comparison table at the top of this article).
• If you rely on pass-through authentication, device writeback, or custom sync rules, Cloud Sync is not yet a drop-in replacement.
• Verify that every forest and domain in your topology has a Cloud Sync provisioning agent installed.

Migration steps:

1. Install the Microsoft Entra Cloud Sync provisioning agent on a domain-joined server in each forest.
2. Configure the Cloud Sync scope in the Azure portal: Microsoft Entra ID > Entra Connect > Cloud Sync > New Configuration.
3. Set the scope to match your current Azure AD Connect OU and domain filters.
4. Enable the Cloud Sync configuration in “disabled” mode first and review the preview results.
5. Once validated, disable Azure AD Connect by putting it into staging mode, then enable Cloud Sync.
6. Monitor sync health in the Azure portal for 48 hours before uninstalling Azure AD Connect.

Warning: Do not run Azure AD Connect and Cloud Sync against the same set of objects simultaneously. This creates conflicting sync operations. Use one or the other for each set of users and groups.

For organizations going through this transition while also resolving Azure SSO issues, coordinate the migration carefully to avoid compounding identity disruptions.

Quick Reference: Sync Error Lookup Table

Error	Likely Cause	First Step
AttributeValueMustBeUnique	Duplicate UPN or proxyAddress across objects	Find and remove the duplicate attribute value on-premises
InvalidSoftMatch	SMTP address mismatch between on-prem and cloud objects	Align primary SMTP or perform a hard match with ImmutableId
ObjectTypeMismatch	Contact in Azure AD conflicts with synced user	Delete the stale contact object in Azure AD
IdentitySynchronizationError	Generic export failure	Check connector credentials and network connectivity
LargeObject	Object exceeds attribute size limits (e.g., too many group members)	Split large groups or increase the multi-valued attribute limit
Password sync not working	PHS disabled, service stopped, or credential expired	Re-enable PHS and restart the ADSync service
DataValidationFailed	Attribute value contains invalid characters	Clean the attribute value on-premises (remove illegal characters from display names, UPNs, etc.)

When to Escalate

Not every sync error can be resolved through self-service troubleshooting. Escalate to Microsoft support or your managed services provider when:

• Sync has been broken for more than one full cycle (30+ minutes) and you cannot identify the root cause.
• The Azure AD Connect server is in a corrupted state and the wizard will not launch.
• You suspect data corruption in the metaverse or connector space databases.
• A Microsoft service incident is affecting sync endpoints (check the Microsoft 365 Service Health Dashboard).
• You are planning a migration from Azure AD Connect to Cloud Sync and need to coordinate across multiple forests with complex filtering rules.

Sync errors left unresolved compound over time. A single attribute conflict today becomes dozens of orphaned objects next month. The key to maintaining a healthy hybrid identity environment is treating sync errors with the same urgency as security incidents — investigate immediately, fix at the source, and validate that the fix holds across multiple sync cycles.