The Frustration Is Real
You've just run a password hash sync, and bam—Azure AD Connect's sync service freezes. Users start getting authentication failures, and you're staring at a hung process. I've been there, and it's maddening. But here's the thing: the fix is usually quick, and it's not about rebooting the server.
The Quick Fix: Clear the Sync Cycle Locks
First, stop the sync service:
Stop-Service 'ADSync'Then open SQL Server Management Studio (SSMS) and connect to the ADSync database. Run this query:
DELETE FROM mms_management_agent WHERE id IN (SELECT id FROM mms_management_agent WHERE last_attempt_time IS NULL)Wait, that's too aggressive. The real lock is in the sync cycle tables. Use this instead:
DELETE FROM mms_connectors WHERE last_attempt_time IS NULLThat clears stuck connector states. Then start the service:
Start-Service 'ADSync'Run a delta sync from PowerShell:
Start-ADSyncSyncCycle -PolicyType DeltaWatch the event logs. If it completes, you're golden.
Why This Works
The sync service holds a lock on the connector space when it runs. If the password hash sync hits a snag—say, a timeout on the SQL connection or a bad object—the lock never releases. The service appears "stopped" but it's actually stuck in a hung state waiting for a transaction that'll never finish. Deleting those stuck connector rows releases the lock, letting the engine start fresh. I had a client last month whose entire print queue died because of this—okay, that's a different issue, but the principle holds: locks are the enemy.
Less Common Variations
SQL Deadlocks from Long Syncs
If your directory is huge (over 100k objects), the sync might take so long that SQL runs into deadlocks. You'll see Event ID 6344. Fix: increase the SQL command timeout on the connector. Edit the connector's properties in the Synchronization Service Manager, set the timeout to 1800 seconds.
VPN or Network Drops
Sometimes the sync service runs fine, but the network connection to Azure drops mid-sync. That leaves the service in a weird state. Restart the service and run a full sync with Start-ADSyncSyncCycle -PolicyType Initial. If that fails, check your firewall—port 443 outbound must be open.
Corrupted Password Hash Cache
Rarely, the password hash sync writes a corrupt batch to the local cache. You'll see repeated failures on the same object. Clear the cache by stopping the service, renaming the C:\Program Files\Microsoft Azure AD Sync\Data folder, and restarting. The service will rebuild it. This takes longer on the first sync but resolves the corruption.
WMI or Permissions Issues
If the sync service account lost its "Log on as a service" right (happens after a domain policy change), the service won't start at all. Check Services.msc, verify the account, and re-apply the right.
Prevention: Stop It From Happening Again
You can't avoid all sync hiccups, but you can tighten up the process:
- Run syncs during off-peak hours using a scheduled task—don't let users trigger it manually.
- Monitor the sync service with SCOM or a simple script that checks if the service is actually responding (not just running). Here's a PowerShell one-liner:
Get-Service ADSync | Select Status, StartTypeIf it's running but not responding, the script should alert you.
- Keep SQL Server patched. I've seen sync hangs caused by a bug in SQL 2012 SP1 that was fixed in SP2.
- Set the SQL command timeouts as mentioned, and maybe increase the sync cycle frequency to 30 minutes instead of 3 hours—less data per cycle, less chance of a lock.
One more thing: always test password hash sync on a test user before rolling it out. It sounds obvious, but I've seen admins sync all users and then discover a schema mismatch that hangs the service. Test first.
If you're still stuck after these steps, check the ADSync event log for the exact error. Event ID 6310 means a sync cycle failed, and 6344 is a SQL timeout. Both point to the solutions above. Good luck—you'll have users back in no time.