Before walking the actual Entra Connect installer in the next post, take a step back and understand what you’re installing. The Entra Connect “Sync Engine” is more than a single process — it’s a four-component architecture that moves identity data between your on-prem AD and the cloud through staging stores and a central hub. Knowing which component sits where is what makes troubleshooting tractable when something inevitably goes sideways: the difference between “sync is broken” (panic) and “the AD-side import isn’t completing because of an LDAP timeout” (specific, fixable) is just understanding the architecture.
The four components
1. Connected Data Sources (the “real” directories)
These are the actual systems where the data lives. For Entra Connect, the two that matter:
- On-Premises Active Directory — your local AD, the source of truth for users, groups, computers. Lives on Domain Controllers; reachable via LDAP / RPC. In our worked examples, this is
infotechninja.local. - Microsoft Entra ID — the tenant-side directory. Lives in Microsoft’s cloud; reachable via the Entra ID Sync API (a versioned REST API). For our examples, this is the tenant backing
infotechninja.com.
Other connected data sources are possible (SQL databases, LDAP-V3 directories, generic CSV files via specific connectors), but for standard Entra Connect deployments only AD and Entra ID matter.
2. Connectors (the pipes)
A Connector is the bridge between a Connected Data Source and the Sync Engine. Two of them in a typical deployment: one for AD, one for Entra ID.
Important rule: data flows through a Connector in ONE direction at a time. A connector cycle is either an Import (pulling data from the data source into the staging store) or an Export (pushing data from the staging store back to the data source). Never both simultaneously. The sync schedule alternates between Import and Export phases.
3. Connector Space (the staging area)
Each Connector has its own Connector Space (CS) — a database table inside the Entra Connect server’s SQL store. The CS holds a copy of every object the Connector knows about from its data source, plus delta-tracking metadata (what changed, when, what was imported, what’s pending export).
Why a staging store rather than working directly against the live directory? Three reasons:
- Performance. Reads from the staging store are local and fast; reads from AD or the cloud over the network are slow.
- Atomicity. The Sync Engine can analyse the entire delta in isolation before deciding what to write back. Live directories can’t support that pattern without locking.
- Auditability. The CS retains a snapshot of every state the object has been in, useful for troubleshooting why a particular sync attempt failed.
Two Connector Spaces in a standard deployment: AD CS (left side, mirrors AD) and Entra ID CS (right side, mirrors the cloud).
4. The Metaverse (the central hub)
The Metaverse is the consolidated, processed identity store. It sits between the two Connector Spaces and represents the “final” view of each user.
For a hybrid user (exists in both AD and Entra ID), the Metaverse joins them into one logical record. The user appears once in the Metaverse, with attributes drawn from both connector spaces according to sync rules.
Sync rules (the policy layer) live here. They’re what makes Entra Connect more than a dumb mirror: they map AD attributes to Entra attributes, transform values (combine first + last name into displayName, normalise email casing, hash passwords), filter out objects you don’t want synced, and decide which side wins when there’s a conflict.
The sync cycle — five steps
A sync cycle runs every 30 minutes by default (Delta sync), or once at install time (Initial sync that copies everything). The five steps:
Step 1 — Import from AD
The AD Connector reads from on-prem AD via LDAP. It pulls everything new or changed since the last successful import: new users created, password hashes for users who recently changed their password, group membership changes, attribute updates. The data lands in the AD Connector Space as raw delta records.
This is where most network latency in a sync cycle lives. For very large directories, the import is the longest step.
Step 2 — Import from Entra ID
The Entra ID Connector reads from the cloud via the Entra ID Sync API. Same pattern: anything that changed cloud-side since the last sync gets pulled into the Entra ID Connector Space. Most often this is empty (cloud-side changes are rare in pure-AD-authoritative deployments), but it matters for features like password writeback, where a user resets their password in the cloud and Entra Connect needs to write it back to AD.
Step 3 — Synchronisation (rules apply)
Both Connector Spaces now have fresh delta data. The Sync Engine processes it through the rule pipeline:
- Inbound rules (CS → Metaverse) read from a Connector Space, apply transformations and filters, and update the Metaverse.
- Outbound rules (Metaverse → CS) read from the Metaverse, apply transformations and filters, and queue updates in the OTHER Connector Space.
For a new AD user named jdoe: an inbound rule on the AD connector reads the user, joins/creates a Metaverse record, populates attributes (UPN, displayName, mail). Then an outbound rule on the Entra ID connector reads the Metaverse record and queues an Entra-side create with the appropriate attributes.
This step is purely local — no network calls. Fast even for large deltas.
Step 4 — Export to Entra ID
The Entra ID Connector takes the queued changes from its CS and pushes them to the cloud via the Sync API. New users get created in the tenant; updated users get patched; deleted users get soft-deleted (recoverable for 30 days).
This is the second-longest step. It depends on the cloud-side throughput and the size of the export queue.
Step 5 — Export to AD
If you have any cloud-to-on-prem features enabled (password writeback, device writeback, group writeback), the AD Connector takes its queued changes from its CS and pushes them to AD. Most installs have nothing to export back; this step finishes immediately. Installs with password writeback enabled have one row per recent cloud-side password reset.
Worked example: jdoe’s journey
To make the architecture concrete, walk through what happens when you create a new user named jdoe in your on-prem AD:
- Create. You create jdoe in Active Directory Users and Computers. UPN is
jdoe@infotechninja.local(which Part 4 of this series tells you to fix — let’s assume you did, so it’s actuallyjdoe@infotechninja.com). - Import (Step 1). Within 30 minutes, the AD Connector imports the new jdoe record into the AD Connector Space.
- Sync (Step 3). Inbound rule on AD CS creates a new Metaverse object representing jdoe. Outbound rule on Entra CS sees the new Metaverse object, queues a create operation in the Entra Connector Space.
- Export (Step 4). Entra Connector pushes the queued create to the cloud. jdoe appears in Entra ID with UPN
jdoe@infotechninja.com. - Verification. jdoe can now sign into Microsoft 365 with
jdoe@infotechninja.comand the password jdoe set in on-prem AD.
For Step 5 to come into play, jdoe would need to do something cloud-side — e.g. reset their password via the SSPR portal. Then the cloud-side change goes through Step 2 (Import from Entra), Step 3 (Sync rules promote it), and Step 5 (Export to AD), so the password change writes back into on-prem.
How this changes troubleshooting
When sync looks “broken,” understanding the architecture lets you locate the failure precisely:
- New user not appearing in cloud: check Step 1 (did the AD Connector see the user?), then Step 3 (did the rules create a Metaverse object?), then Step 4 (did the Entra Connector queue an export?). The Sync Service Manager UI shows the status of each step.
- Stale attribute on a user: probably a sync rule problem. Look at what the AD CS has, what the Metaverse has, and what the Entra CS has — the discrepancy shows you which step is mis-mapping the attribute.
- Sync runs but nothing changes: usually means the delta detection is broken — either the source watermark is stuck or the Connector lost its sync state. Reset and full sync.
- Cloud-side change not making it back to AD: Steps 2 + 3 + 5 are the path; check each.
The Sync Service Manager (a desktop app on the Entra Connect server) lets you inspect each Connector Space and the Metaverse object-by-object. Most production troubleshooting starts there.
Where this fits
The architecture overview matters because the next post (the actual Entra Connect installer walk-through) makes a lot more sense once you know what each install option corresponds to. The Express install picks default rules and a default schedule; Custom install lets you pick OUs, attributes, and rules per Connector. Without the architecture context, the install wizard’s questions are confusing; with it, they’re obvious.
Series context in the Hybrid Identity pathway. Previous posts: Part 1 (Prerequisites), Part 2 (Stage Installers), Part 3 (TLS 1.2), Part 4 (UPN Suffix Prep), Part 5 (IdFix).