Microsoft Entra Connect Sync Setup and Configuration (2026 Guide)

Anyone who has run on-prem Active Directory for years knows one thing: the user account no longer lives only in the domain. The same user asks a domain controller when they sign in each morning, and Microsoft Entra ID (formerly Azure AD) when they open Teams at noon. The bridge between those two worlds has been the same for years: directory synchronization.

But in 2026 both the name and the rules of that bridge changed. "Azure AD Connect" is now Microsoft Entra Connect. More importantly, for new deployments Microsoft positions Microsoft Entra Cloud Sync as the strategic direction — it no longer recommends the heavy, server-installed sync engine for every scenario. So the first question to ask isn’t "how do I install it" but "which one should I install?"

In this guide we answer that decision first; then, for the scenario where Connect Sync is the right choice for you, we install it the way it actually works in the field — without clicking "next-next-finish" through the express wizard. And at the very end we cover the two things that will break your setup in 2026 if you ignore them: the mandatory version upgrade and the hard-match security hardening. Because a setup that works today can stop working in the coming months purely because you skipped these.

Decide first: Connect Sync or Cloud Sync?

Let’s be honest about this, because starting wrong means a migration months later.

Microsoft Entra Cloud Sync runs through a lightweight provisioning agent; all configuration lives in the cloud, there is no SQL on the server, the agent self-updates, failover across multiple agents is native, and it synchronizes multiple disconnected forests to a single tenant from one place. This is the product Microsoft writes new features to first and calls the "strategic direction." If you are building a new, simple environment, your default choice should be Cloud Sync. It now supports device sync (and therefore hybrid join) too — which used to be the most common reason people said "Cloud Sync won’t work for us."

The valid reason to still choose Microsoft Entra Connect Sync is a specific need Cloud Sync doesn’t yet meet. The most common one in the field: complex, attribute-based filtering and advanced transformation rules. Heavy, multi-forest legacy topologies, custom attribute flows, bespoke logic baked into Connect’s sync rule editor — if you have these, Connect Sync is still your tool.

Practical rule:

• New/simple environment, standard attributes → evaluate Cloud Sync.
• Existing Connect Sync install, complex rules → stay on Connect Sync, but apply the 2026 requirements at the end of this guide.
• Undecided → go through Microsoft’s decision-guide comparison table against your environment’s requirements, one by one. If you can’t write down a single Cloud-Sync-unsupported feature you actually use, you have no valid reason to stay on Connect Sync.

The rest of this guide is for the scenario where you’ve made that decision and are installing/keeping Connect Sync.

How Connect Sync works (short but clear)

Connect Sync is a synchronization engine installed on a Windows server. It reads from on-prem AD, filters and transforms per your rules, and writes to Entra ID. By default a sync cycle runs every 30 minutes (that’s the difference from Cloud Sync’s ~2-minute model; heavier but controlled).

How the user authenticates in the cloud is a separate decision from synchronization:

• Password Hash Sync (PHS): a hash of the password hash is synced to Entra. The recommended, most resilient baseline for most environments; sign-in works in the cloud even if on-prem is down.
• Pass-through Authentication (PTA): password validation stays on-prem and is never stored in the cloud; requires an agent.
• Federation (AD FS): a separate federation infrastructure; unnecessary complexity in most scenarios today.

We cover the differences and when to pick which in a dedicated guide. This install assumes PHS + Seamless SSO — the combination that works best and surprises least in the field.

Prerequisites — the checklist before you open the wizard

Most field install failures come not from a wrong click but from a skipped prerequisite. Before opening the wizard, settle these:

Server

• Windows Server 2016 or later (prefer 2022/2025 for a new build). A domain-joined, patched, dedicated server — installing on a domain controller is technically possible but I don’t recommend it in production.
• .NET and PowerShell up to date. TLS 1.2 enabled.
• Antivirus exclusions configured (the Connect directory and SQL files).

Database

• Under ~100,000 objects, the bundled SQL Server Express LocalDB is enough (the 10 GB limit lands around here).
• For a larger environment use full SQL Server. Choose this correctly up front; moving it later is a separate project.

Accounts

• On the Entra side, the Hybrid Identity Administrator role (formerly Global Admin) for setup.
• On-prem, the sync account used in a custom install (either let the wizard create it or pre-authorize it).
• Think about MFA and Conditional Access exceptions for these accounts in advance — don’t let authentication hit a wall mid-install.

Namespace (very critical)

• The UPN suffix of users to be synced must be a routable domain verified in Entra (e.g. company.com), not company.local.
• If needed, add a UPN suffix via "Active Directory Domains and Trusts" and fix users’ UPNs. Do this before install; a bulk UPN change afterwards is an operation in its own right.

Network

• Outbound 80/443 from the server to Microsoft endpoints must be open. If there’s a proxy, Connect must be made aware of it.

Express or Custom?

The wizard offers two paths. Express sets up the simple single-forest PHS scenario in a few clicks and creates the required accounts itself. It’s fine for demos and very small environments.

In production I recommend Custom. The reason is simple: express decides for you — which OUs sync, which attributes, which sign-in method. With Custom you make those decisions and, months later, you know the answer to "why is this synced this way." The most expensive thing in systems administration is configuration no one remembers making or why.

Step-by-step install (Custom)

1. Download the latest version. Always start with the newest Connect Sync build. Don’t reuse an old installer.
2. Start setup, accept the license terms, choose "Customize."
3. Component options: specify custom SQL here if you’ll use it. Same if you must enforce an existing service account. Otherwise proceed with defaults.
4. User sign-in: check Password Hash Synchronization. Also check Enable single sign-on (Seamless SSO).
5. Connect to Entra ID: sign in with the Hybrid Identity Administrator. In recent versions setup connects to the cloud using application-based authentication; the old "directory sync account" method is being left behind.
6. Connect directories: add your on-prem forest(s). Let the wizard create the sync account or enter one you prepared.
7. Entra sign-in configuration (UPN): the wizard warns about users with an unverified UPN suffix here. If you see a warning, stop, finish UPN/domain verification, then continue.
8. Filtering (domain/OU): don’t sync everything from the start. Select only the OUs that should exist in Entra. Keep scope narrow; widening is always easier than pulling back.
9. Optional features: Exchange hybrid writeback, group writeback, password writeback (for SSPR) are selected as needed. Don’t enable what you don’t need.
10. Review the configuration and install. If the environment is sensitive, consider starting in staging mode until you’ve verified.

The first hour after install — verification

"Install finished" doesn’t mean the job is done. Don’t leave your desk without watching the first sync run.

Check the sync scheduler:

Get-ADSyncScheduler

You should see SyncCycleEnabled : True and a ~30-minute cycle.

Trigger the first run manually (initial full sync):

Start-ADSyncSyncCycle -PolicyType Initial

• In Synchronization Service Manager (miisclient), check the connector runs: any unexpected errors or a high number of deletions? If you see a bulk-deletion warning, stop and investigate — that usually means a wrong filter.
• Entra admin center → Users: did the users you expected appear as "Directory synced = Yes"?
• Monitoring: turn on Microsoft Entra Connect Health.

2026 reality: working today doesn’t mean working tomorrow

On the Connect Sync side Microsoft set clear rules, and environments that ignore them risk silently stopping.

1) Mandatory version and application-based authentication (deadline). Legacy auth is being retired. Per current Microsoft Learn guidance, the deadline to upgrade Connect Sync to 2.6.84.0 or later and configure application-based authentication is April 7, 2027. If those requirements aren’t met, the sync service stops working after that date.

Also, all 1.x versions are unsupported and don’t sync; 2.x versions retire 12 months after a newer version ships. The summary: always run the latest version, don’t defer updates to "later."

2) Hard-match security hardening. Entra ID tightened hard-match behavior to prevent cloud account takeover. From July 1, 2026 this protection is applied automatically (blocking for admin-role accounts began June 2026; rollout completed end of September 2026). Hard-matching an AD object to an existing cloud account that holds an Entra role can be blocked (the BlockCloudObjectTakeoverThroughHardMatchEnabled tenant property relates to this). Soft match and ordinary matches on non-privileged accounts are not affected. A blocked operation returns "Hard match operation blocked due to security hardening"; the fix is to review the OnPremisesObjectIdentifier mapping.

Staging mode — the structure that saves you in the field

Don’t leave your production sync server standing alone. Install Connect Sync on a second server with the same configuration and keep it in staging mode. A staging server reads, processes rules and keeps its database but does not write (export) to Entra. The benefit is threefold:

• Disaster recovery: if the primary server is lost, activate staging and resume sync within minutes.
• Safe upgrades: test a new version/config on staging first, review the export preview, switch roles once you’re sure.
• Change preview: see what a new filter/rule would delete without touching production.

Its one rule: only one server may actively export at a time.

Field pitfalls (where everyone trips once)

• Starting with a .local UPN. Sync before moving to a verified domain and users land as onmicrosoft.com. Fix the namespace first.
• Leaving the filter wide. Don’t say "sync it all, we’ll clean up later." Pulling a polluting object back out of the cloud is harder than never sending it.
• Ignoring the bulk-deletion threshold. Connect’s export deletion threshold protection stops a large delete. Don’t dismiss that warning.
• One server, zero monitoring. No staging, no Connect Health — you’re blind at the first serious failure.
• Deferring updates. The 2026 rules above punish exactly this habit.
• MFA/Conditional Access blocking the setup account. Authentication stalls mid-install; sort out these accounts’ access in advance.

Conclusion

Installing Microsoft Entra Connect Sync is not a few "next" clicks. It starts with the right decision (for most new environments today, putting Cloud Sync on the table), continues with solid prerequisites, is installed with a narrow filter and the right authentication method, verified by watching the first sync run, and kept alive with staging + monitoring. Add 2026’s two requirements — a current version/app-based auth and hard-match hardening — and you’ve built something that works not just today but keeps working.

After you’ve synced users, the next step is to bring devices into Entra too and to settle the authentication method.