Microsoft Entra Connect Sync Troubleshooting Guide (2026)

Updated: June 2, 2026

Microsoft Entra Connect Sync troubleshooting almost always comes down to four moving parts: the on-premises Active Directory connector, the Entra ID (Azure AD) connector, the sync scheduler that runs every 30 minutes, and the rules engine that decides which attributes flow where. When a hybrid identity user can't sign in, can't get a license, or shows up twice in the global address list, one of those four is failing, and the symptom you see at the helpdesk almost never points at the right one. So, let's walk through the diagnostics I actually run on tickets, in the order I run them.

• Microsoft Entra Connect Sync (renamed from Azure AD Connect in 2023) runs a delta sync every 30 minutes. Entra Cloud Sync is the lightweight agent-based replacement for most new deployments in 2026.
• The four most common ticket categories are duplicate attribute errors (ProxyAddress, UPN, SourceAnchor), scheduler stopped or in maintenance mode, password hash sync (PHS) silently broken, and staging-mode confusion after a server swap.
• Diagnose in this order: Get-ADSyncScheduler, the Synchronization Service Manager (miisclient.exe) Operations tab, then the connector space for the failing object.
• Force a delta sync with Start-ADSyncSyncCycle -PolicyType Delta. A full sync only after a filtering or rule change.
• Entra Connect v1 (Azure AD Connect v1) reached end of support on August 31, 2022. Any server still on v1.x stops syncing eventually and must be upgraded to v2.5+ or migrated to Cloud Sync.
• Entra Connect Health is the canonical monitoring surface. Install the agent on every sync server, even the staging one.

How Entra Connect Sync actually works

Before you can troubleshoot a sync problem, you need a mental model of what each step is doing. The on-premises Entra Connect server hosts the Synchronization Service (the MIIS-derived engine inherited from Forefront Identity Manager) and a Windows service called ADSync. Every 30 minutes the scheduler triggers a delta run profile that touches both connectors: the Active Directory Domain Services (AD DS) connector reads changes from one or more on-prem forests, and the Entra ID connector writes the resulting changes to your tenant.

Between those two connectors sits the metaverse, an in-memory join space where objects from AD are matched to objects in Entra ID using the SourceAnchor attribute (almost always mS-DS-ConsistencyGuid since v1.1.524). Sync rules, including the inbound rules from AD, the outbound rules to Entra ID, and any custom rules you've added, decide which attributes flow, in which direction, and with what transformation. When a ticket says "the user's job title isn't updating in Outlook," the answer is almost always a rule problem, not a connectivity problem.

One more wrinkle in 2026: Microsoft now ships two products. Entra Connect Sync is the heavyweight Windows-server-hosted engine described above. Entra Cloud Sync is a lightweight agent (40 MB, no SQL) that runs in the cloud and handles 80% of customer scenarios. Cloud Sync added Group Writeback in 2024 and Device Writeback in 2025, closing most of the remaining feature gap. For brownfield environments with custom rules, you're almost certainly still on Entra Connect Sync, but new tickets increasingly involve both products in the same tenant (which has its own failure modes).

First five minutes: the checks I run on every sync ticket

When a sync ticket lands, I open three windows before I open the rules editor or call the user back. Honestly, this sequence catches roughly 70% of incidents in my service desk's last twelve months of data. Run all three on the active (not staging) Entra Connect server:

# 1. Is the scheduler actually running, and is the server in staging mode?
Get-ADSyncScheduler

# 2. Are there any sync errors on the last run?
Get-ADSyncConnectorRunStatus

# 3. Is the ADSync service healthy?
Get-Service ADSync | Format-List Name, Status, StartType

Look for three specific things in the Get-ADSyncScheduler output. SyncCycleEnabled : True means the scheduler is on. If it's False, someone disabled it manually with Set-ADSyncScheduler -SyncCycleEnabled $false and never re-enabled it. StagingModeEnabled : False means this server is actively writing to Entra ID. If it's True on the server you thought was primary, you've got a failover problem (see staging mode pitfalls). NextSyncCyclePolicyType : Delta with a NextSyncCycleStartTimeInUTC in the next 30 minutes means the engine is alive and scheduled.

Then open the Synchronization Service Manager (%ProgramFiles%\Microsoft Azure AD Sync\UIShell\miisclient.exe) and go to the Operations tab. Anything red or yellow in the Status column needs to be opened. The connector spaces are where you'll spend most of your debugging time, so it's worth keeping that shortcut on the desktop of your jump server. The path is still Microsoft Azure AD Sync on disk even after the Entra rename, since Microsoft did not change the directory name to avoid breaking installer logic.

How do I fix duplicate attribute sync errors in Entra Connect?

Duplicate attribute errors are the single most common Entra Connect ticket I see, and they're almost always one of three attributes: userPrincipalName, proxyAddresses, or sourceAnchor. The error surfaces in the Microsoft 365 admin center as "Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services", a deliberately scary message that says nothing useful about which attribute or which other object.

To find the actual conflict, open Synchronization Service Manager, click the AD connector, then Search Connector Space. Set Scope to Pending Export, click Search, and look for the user. Right-click the object and select Properties, then Lineage, then look at the most recent run's errors. The error detail names the attribute and the conflicting value. From there, PowerShell finds the duplicate in seconds:

# Find every AD user with a given proxyAddress (case-insensitive, anywhere in multi-valued attribute)
Get-ADUser -LDAPFilter "(proxyAddresses=*[email protected]*)" `
    -Properties proxyAddresses, userPrincipalName, distinguishedName |
    Select-Object Name, userPrincipalName, distinguishedName

# Find duplicate UPNs in a forest
Get-ADUser -Filter * -Properties userPrincipalName |
    Group-Object userPrincipalName |
    Where-Object Count -gt 1 |
    Select-Object Name, Count

For sourceAnchor duplicates, the cause is usually a recent forest migration or an ADMT cross-forest move where mS-DS-ConsistencyGuid was copied to the new object but not cleared on the old one. The fix is to clear the attribute on the abandoned object (do not clear it on the live one, or you'll create a new cloud object and orphan the license). If the duplicate is between an enabled user and a disabled mailbox-bearing object, the disabled one is almost always the right cleanup target. Just check with the mailbox owner first, because shared mailbox conversions create the same pattern legitimately. The official Entra Connect object-not-syncing troubleshooter walks through the connector-space search in screenshots if you want to share something with a tier-1 tech.

Why is Entra Connect not syncing? Scheduler and run profile issues

If Get-ADSyncScheduler shows SyncCycleEnabled : False, the scheduler was disabled. This usually happens during a maintenance window that didn't get reverted, or by an automation script that runs before a planned schema change. Re-enable with Set-ADSyncScheduler -SyncCycleEnabled $true. If the scheduler is enabled but no sync has run in over 30 minutes, look at the ADSync Windows service. A common failure mode is the service running as a local service account whose password expired after a domain GPO change. The service shows Running, but every operation immediately fails an AD bind. Check the Application event log for source ADSync events around the last good sync time.

The other scheduler trap is the maintenance window. Entra Connect Sync respects a tenant-side maintenance schedule that Microsoft sets, and during Microsoft-pushed schema updates the scheduler genuinely cannot run. You'll see MaintenanceEnabled : True in the scheduler output. That's not a bug. But if it stays true for more than a few hours, open a Microsoft case and don't wait. If you need to force a sync outside the scheduler entirely (after fixing a duplicate attribute, for instance), the canonical command is:

# Force a delta sync (the right answer 95% of the time)
Start-ADSyncSyncCycle -PolicyType Delta

# Force a full sync (only after a filtering, rule, or connector change)
Start-ADSyncSyncCycle -PolicyType Initial

A full sync can take hours on a large directory and locks out delta runs while it executes. Don't reflexively reach for -PolicyType Initial just because someone in a Reddit thread said to. A delta sync picks up object-level changes (including newly fixed duplicates) within one cycle. If you've recently changed the configuration of an inbound rule, organizational unit filtering, or domain selection, then a full sync is correct because delta runs skip objects whose source attributes haven't changed. The Microsoft scheduler reference documents every available parameter.

Password hash sync is broken (and nobody told you)

This is the silent killer. Password hash sync (PHS) is the feature that lets users sign in to Entra ID with their on-prem password, and it has a habit of breaking in ways that produce zero error messages anywhere a tier-1 tech would naturally look. The symptom is "my password just changed in AD but I still need to use the old one for Outlook on the web." It can persist for hours before anyone notices, because Entra ID quietly falls back to the cached hash from the last successful sync.

I hit this exact bug last winter on a tenant we'd inherited from an MSP, and it had been failing silently for nine days. To confirm whether PHS is healthy, run this in PowerShell on the active sync server:

Import-Module ADSync
$connectors = Get-ADSyncConnector

# Pull the AD connector (there may be one per forest)
$adConnector = $connectors | Where-Object { $_.ConnectorTypeName -eq "AD" } | Select-Object -First 1

# Get PHS configuration details
Get-ADSyncAADPasswordSyncConfiguration -SourceConnector $adConnector.Name

# Look at the latest PHS heartbeat event in the Application log
Get-WinEvent -LogName Application -MaxEvents 200 |
    Where-Object { $_.ProviderName -eq "Directory Synchronization" -and $_.Id -in 611, 651, 656 } |
    Select-Object TimeCreated, Id, Message -First 5

Event ID 656 is a successful password sync batch. You should see one every two minutes during business hours. Event ID 611 is a hard failure, usually an RPC connection problem to a domain controller. Event ID 651 is an outbound failure to Entra ID, often an outbound proxy or TLS issue. If you don't see any of those events at all, PHS isn't running. The common cause is that the Microsoft Azure AD Sync service account lost the "Replicating Directory Changes" and "Replicating Directory Changes All" rights on the domain naming context (a routine AD permissions cleanup script will sometimes strip them). Re-grant on the domain root, restart the ADSync service, and the heartbeat will resume within minutes. Our Active Directory account lockout troubleshooting guide has more on diagnosing replication-permission issues that surface as auth problems.

Staging mode pitfalls and the failover playbook

Every production hybrid identity deployment should run two Entra Connect servers: one active, one in staging mode. Staging mode means the server imports from AD and Entra ID, runs sync rules in the metaverse, and stages export changes, but never actually exports. It's a hot spare. The problem is that staging-mode confusion is responsible for the most painful Entra Connect tickets I've seen, because failing over the wrong way creates duplicate cloud objects or wipes attributes.

Three rules I drill into every IT admin who touches these servers:

1. Never have two servers with StagingModeEnabled : False at the same time. Both will try to export. Whichever runs last wins, and the loser's writes are reverted on the next cycle. Confirm with Get-ADSyncScheduler on every sync server before you promote anything.
2. Before you promote staging to active, run the Connect Sync configuration documenter. If the staging server has drifted from the active server's rules (because someone forgot to mirror a custom rule change), promoting it will silently roll back attribute flows. The AADConnectConfigDocumenter on GitHub diffs two server configs and outputs an HTML report.
3. The Microsoft 365 admin center's "last sync" timestamp is global, not per-server. If your tenant shows "Synchronized 12 minutes ago" but you just took the active server offline, you're looking at staging-server data through Entra Connect Health, not a successful sync. Staging servers report health even though they don't export.

To execute a clean failover, on the new server, run Set-ADSyncScheduler -StagingModeEnabled $false. On the old server, immediately run Set-ADSyncScheduler -StagingModeEnabled $true. The order matters because you want a brief window where both are staging, not one where both are active. Trigger a delta sync on the new active server and verify Get-ADSyncConnectorRunStatus shows a successful export to the Entra ID connector. Then update DNS, monitoring, and your runbook to reflect the new primary.

Should I migrate from Entra Connect Sync to Entra Cloud Sync?

If you're standing up a new hybrid identity environment in 2026, default to Cloud Sync unless you have a specific reason to use Entra Connect Sync. The decision is rarely that simple for existing deployments though. Microsoft now supports running both products against the same tenant for different OUs (a "side-by-side" topology), which both unlocks gradual migration and creates new ways to misconfigure things. Here's how the two products compare on the dimensions that actually matter for a service desk:

Capability	Entra Connect Sync	Entra Cloud Sync
Install footprint	Windows Server + SQL (LocalDB or full)	Lightweight agent, ~40 MB, multi-agent HA
Custom sync rules	Full rules engine, expression-based	Attribute mapping + scoping filters (no rules engine)
Group Writeback	Supported (M365 groups to AD)	Supported since 2024
Device Writeback	Supported	Supported since 2025
Exchange Hybrid attributes	Full support	Supported (most attributes)
Pass-Through Authentication	Supported	Not supported (use PHS or federation)
Multi-forest, disconnected forests	Single-server, joined topology	Designed for disconnected forests
Configuration via Graph API / IaC	PowerShell only, hard to automate	Full Graph API, Terraform-friendly

The migration path Microsoft endorses is to enable Cloud Sync agents alongside the existing Entra Connect server, scope Cloud Sync to a pilot OU, validate, and gradually move scope from Connect Sync to Cloud Sync until Connect Sync can be retired. The Cloud Sync documentation explicitly supports this dual-state during migration. If you depend on custom expression-based sync rules (a Connect Sync feature Cloud Sync deliberately does not replicate), you have to choose between rewriting those rules as Cloud Sync attribute mappings (sometimes impossible, since there's no equivalent of inline IIF expressions) or staying on Connect Sync. The companion Microsoft Entra ID Conditional Access guide covers the policy-side considerations when you change sign-in methods during a Cloud Sync migration.

Entra Connect Health, event logs, and where to look next

Entra Connect Health is the agent-based monitoring service that ships with Entra ID P1 and above. Install the Health agent on every Entra Connect server (active and staging) and on at least two domain controllers per AD site. It surfaces alerts you can't easily get elsewhere: stale sync schedules, expiring service-account passwords, replication latency, AD FS token issuance failures, and bad password attempts that look like attacks. Connect Health alerts appear in the Entra admin center under Identity → Hybrid management → Microsoft Entra Connect → Connect Health.

For deeper diagnostics, the Application event log on the sync server is the canonical source. The relevant providers are Directory Synchronization (for the sync engine), ADSync (for the service), and FIMSynchronizationService (legacy name, still used by some events). The Windows Event Viewer troubleshooting guide covers how to build a saved custom view that filters all three providers and surfaces only error and warning events. That's the view I keep pinned on my jump server's desktop.

When all of the above fails to find the root cause, escalate with three artifacts: the output of Get-ADSyncScheduler, the connector-space search result for the failing object (Export to file from miisclient), and the Application event log filtered to the providers above for the last six hours. Microsoft support engineers can usually triage with just those three. Without them, the case will bounce for a week. I learned this the hard way during a 2024 outage where we spent four days getting routed between tiers because nobody had grabbed a connector-space export at the moment of failure.

Frequently Asked Questions

How do I force an Entra Connect sync immediately?

On the active sync server, open PowerShell as administrator and run Start-ADSyncSyncCycle -PolicyType Delta. This triggers a delta sync that picks up changes since the last cycle, typically completing in 1 to 3 minutes. Use -PolicyType Initial only after a rule or filtering change.

What replaced Azure AD Connect?

Microsoft renamed Azure AD Connect to Microsoft Entra Connect Sync in 2023, and introduced Entra Cloud Sync as a lightweight cloud-managed alternative. Both products are still supported. New deployments default to Cloud Sync unless they need custom expression-based sync rules or Pass-Through Authentication.

Where are the Entra Connect Sync logs located?

Sync engine events appear in the Windows Application log under providers Directory Synchronization, ADSync, and FIMSynchronizationService. Per-object errors are visible in the Synchronization Service Manager (miisclient.exe). Tenant-wide health alerts surface in Entra Connect Health in the Entra admin center.

Why is password hash sync not working in Entra Connect?

The most common cause is the sync service account losing "Replicating Directory Changes" and "Replicating Directory Changes All" rights on the domain naming context, usually after an AD permissions cleanup script. Check Application event log for event IDs 611, 651, and 656 to confirm, then re-grant the rights and restart the ADSync service.

Can I run Entra Connect Sync and Entra Cloud Sync at the same time?

Yes. Microsoft supports running both products against the same tenant in a "side-by-side" topology, scoped to different organizational units. This is the recommended migration path: pilot Cloud Sync on a small OU, validate, and gradually expand scope until Connect Sync can be retired.