Recovering from a broken Entra Connect Sync

Directory sync breaks quietly. The Microsoft 365 admin center shows a small banner that sync has not run in a while, someone notices a new starter's account never appeared, and by then it has been three days. This runbook is ordered from the cheapest fix to the most expensive, because most broken syncs are a stopped scheduler or an expired credential, and only a few are a dead server.

Throughout, the site's Entra Connect Health coverage is the thing that would have told you on day one. If it is not deployed, note that for afterwards.

Step 1: is it actually not running?

On the Connect server, in an elevated PowerShell:

Get-ADSyncScheduler

Look at SyncCycleEnabled, NextSyncCyclePolicyType, LastSyncCycleStartTimeInUTC, and StagingModeEnabled. Three quick verdicts:

• SyncCycleEnabled is False: someone disabled the scheduler — usually during a migration or an upgrade and forgot. Set-ADSyncScheduler -SyncCycleEnabled $true and a delta sync.
• StagingModeEnabled is True: this server is a staging server and is not supposed to export. Either the active server is elsewhere and that is the one to look at, or someone switched this one to staging by mistake and you need the wizard to switch it back — after checking there is no other active server.
• Both look right but the last start time is old: the scheduler is stuck. Restart the Microsoft Entra ID Sync service (still named ADSync) and run Start-ADSyncSyncCycle -PolicyType Delta.

Then open Synchronization Service Manager and watch the operations. The run profile that fails, and its error, is your diagnosis.

Step 2: the usual suspects

Entra connector export fails with an authentication error. The sync account's password (the Sync_servername_xxx service account in Entra) is normally rotated automatically, but if the account was blocked by a Conditional Access policy, hit by a licence-cleanup script, or had MFA forced on it by a tenant-wide policy, exports stop. That account must be excluded from CA — it is one of the standard exclusions — and it must not be touched by lifecycle automation. Check its sign-in log in Entra for the blocking policy.

AD connector import fails. The on-prem service account (AD DS Connector account) lost permissions, its password expired, or a domain controller it was bound to was decommissioned. Check the account in AD, and in Synchronization Service Manager → connector properties → Configure Directory Partitions → check which DCs are preferred.

Connectivity. Proxy changes, TLS inspection, expired proxy credentials. Test-NetConnection login.microsoftonline.com -Port 443 from the service account's context, not yours, because the sync service uses machine proxy settings and its own credentials.

Stopped-extension-dll or database errors. The LocalDB instance the default installation uses has a size cap; large tenants hit it and the sync database corrupts or fills. This is a rebuild-on-SQL case, not a fix.

Version. Entra Connect versions go out of support and Microsoft eventually blocks sync from very old builds. If the console warns the version is retired, upgrade before anything else — auto-upgrade may have been stuck on the same underlying issue.

Step 3: the deletion threshold, and why you should be glad

If the run completes but exports are held with an error about the deletion threshold, the accidental deletion prevention feature has stopped a batch of deletions from reaching Entra. The default threshold is 500 objects. Something — an OU moved out of scope, a filter change, a domain controller returning partial results — has caused Connect to decide that hundreds of users no longer exist.

Do not run Disable-ADSyncExportDeletionThreshold until you have looked at what it wants to delete. Synchronization Service Manager → the Entra connector → Search Connector Space → pending export → deletes. If those are real (a divested business unit), disable the threshold, run one export, and re-enable it. If they are not, fix the cause — restore the OU to scope, fix the DC — and the pending deletes disappear on the next full import.

Blowing through the threshold with an unexamined batch of deletes is how a sync outage becomes a restore-500-users-from-the-recycle-bin incident. Soft-deleted users are recoverable for 30 days, so even that is survivable, but it takes the rest of the week.

Step 4: when the server is gone

Hardware failure, ransomware on the box, a failed in-place upgrade that will not roll back. The recovery is a rebuild, and it is much better if you have an exported configuration (Connect has exported its settings automatically to %ProgramData%\AADConnect since version 1.5, and you can export manually from the wizard). Copy that folder off the old server if you can reach the disk.

1. Build a new server, install the current Entra Connect.
2. In the wizard choose Customize and Import synchronization settings from the exported JSON. This reproduces connectors, OU filtering, and custom sync rules. Without it, you are reconstructing rules from memory, and the risk of a mismatch that generates mass changes is real.
3. Install in staging mode. Let it complete a full import and full sync, then review what it would export — the Sync statistics in staging show adds, updates and deletes. A healthy rebuild shows near-zero pending changes.
4. Once satisfied, switch the new server out of staging. If the old server is somehow still reachable, put it in staging first or shut it down; two active servers exporting to one tenant is a genuine emergency.

Total elapsed time for a clean rebuild is a few hours plus the initial sync, which scales with directory size. During that time, nothing syncs — new starters, password changes with password hash sync, group membership. Users keep working; only changes stall. Tell the service desk to expect "my new account has not appeared" tickets and to hold them rather than create cloud-only accounts that will later collide with the synced object.

Step 5: after recovery

• Run a delta, then confirm in the Microsoft 365 admin center that the last sync time updates.
• Check the Entra admin center Provisioning errors view for anything the rebuild surfaced — duplicate proxy addresses and UPN conflicts tend to appear at exactly this moment.
• If it was a rebuild, re-establish the staging server. A single Connect server is a single point of failure by design, and the fix is either a staging server or, longer term, Cloud Sync's active-active agents.
• Deploy Connect Health, or an alert on the admin center's sync-status signal, so the next stall is a same-day finding.

What needs support

Very little. Microsoft support helps when the tenant side is stuck — for example a sync that was disabled at the tenant level and cannot be re-enabled, or an object stuck in a state the tools cannot clear. Everything on the server side is yours, and the exported configuration is what makes it survivable.