Closing One Domain in a Two-Domain Entra Connect Setup Without Breaking the Other

Picture a Microsoft 365 tenant fed by two on-premises Active Directory domains through one Entra Connect (the tool you may still know as Azure AD Connect) sync, with a two-way trust between the domains. Both domains' users and groups sync up into the same tenant. Then the day comes when one of those domains has to go: its domain controllers are being decommissioned and its people and groups need to keep working, just without an on-premises directory behind them. This is the story of doing exactly that, converting the closing domain's objects to cloud-only while the main domain stayed hybrid, with no password resets and no data loss.

It is a surprisingly under-documented scenario, and the obvious approach (remove the domain from the sync scope) is the one that causes the most damage. The method that actually works cleanly is a little counter-intuitive, so this guide explains both what to do and why it works.

Why You Would Do This

This situation comes up more than you might expect, usually for one of these reasons:

• Divesting or selling a business unit. Part of the organisation is being sold or spun out, and the domain that belonged to it needs to be retired while its identities live on in the cloud.
• Absorbing an acquisition. A company you acquired came with its own domain, you have finished merging the important bits, and you no longer want to run its legacy directory.
• Collapsing a multi-domain forest. Years of organic growth left you with more domains than you need, and you are consolidating down to one.
• Moving one part of the business cloud-only. One division is going fully cloud while the rest stays hybrid, and its domain is the thing standing in the way.
• Retiring ageing domain controllers. You have old DCs you do not want to replace, and rather than stand up new hardware you would rather move those identities to the cloud entirely.

In every case the goal is the same: the closing domain's users and groups become cloud-only objects that keep their identities, their passwords, their licences, and their group memberships, while the main domain carries on syncing as it always did.

Three Methods, and Why the Obvious One Is Wrong

There are three ways to approach this, and the difference between them is the difference between a clean cutover and a weekend spent restoring objects from the recycle bin.

This guide documents the disable-and-rescope method in full, because it is the one that works on essentially any Connect version and cleanly handles the "one domain closes, one stays hybrid" shape. The per-object Source of Authority method is covered at the end as the modern alternative worth knowing.

Why the Disable-and-Rescope Method Works

The mechanism is worth understanding, because on the face of it "turn off sync for the whole tenant" sounds alarming when you only want to change one domain. Here is what actually happens, step by step.

Turning off directory sync tenant-wide converts every synced object to cloud-only in place. This is a documented Microsoft operation, not a hack. It does not delete anything. Each synced user and group has its source of authority moved from on-premises Active Directory to the cloud, its on-premises-only attributes cleared, and its DirSyncEnabled flag flipped to false. Passwords are retained (the last synced hash stays valid), mailboxes, OneDrive, and SharePoint data are untouched, and crucially the object's ImmutableID is retained.

That retained ImmutableID is the clever part. When you then reconfigure Connect to sync only the main domain and turn sync back on, Connect looks at the main domain's on-premises objects and matches them to their existing cloud counterparts using that retained ImmutableID (a "hard match"). The main domain's objects reconnect to their on-premises source and resume being hybrid, exactly as before. The closing domain, which you did not include in the new configuration, has nothing pointing at it, so its objects simply stay as the cloud-only objects they became when sync was disabled.

The result is precisely what you wanted: the main domain is hybrid again, the closed domain is cloud-only, and at no point was anything deleted or recreated. Compare that with the filtering method, which gets to a similar end state only by deleting everything in the closing domain and making you restore the users and rebuild the groups by hand.

What Converts Cleanly, and What Needs a Look

Under the tenant-wide disable, the conversion is clean for most object types, but there is one category to be careful about, and it comes down to whether the closing domain had its own on-premises Exchange.

The single biggest factor is whether the closing domain had its own on-premises Exchange server. The documented "distribution groups do not convert, recreate them" problem is specifically a hybrid-Exchange problem: it bites when those group objects were mastered by an on-premises Exchange. If the closing domain had no on-premises Exchange of its own (its mailboxes already in Exchange Online, or served by the other domain), that whole failure mode largely does not arise, and distribution lists and mail-enabled security groups tend to convert cleanly along with everything else.

The Runbook

This is the ordered sequence. It spans a real calendar window rather than an afternoon, chiefly because of a mandatory waiting period in the middle that we will come to.

Connect-MgGraph -Scopes "User.Read.All","Group.Read.All","Organization.Read.All"

# Users and their sync/immutable state
Get-MgUser -All -Property DisplayName,UserPrincipalName,OnPremisesImmutableId,OnPremisesSyncEnabled |
    Select DisplayName,UserPrincipalName,OnPremisesImmutableId,OnPremisesSyncEnabled |
    Export-Csv "<path>\users.csv" -NoTypeInformation

# Groups, their type, and sync state
Get-MgGroup -All |
    Select DisplayName,GroupTypes,SecurityEnabled,MailEnabled,OnPremisesSyncEnabled |
    Export-Csv "<path>\groups.csv" -NoTypeInformation

From Exchange Online, separately export distribution groups, dynamic distribution groups, and mail contacts, capturing each group's members, owners, proxy addresses, and (important for reply-to continuity) its LegacyExchangeDN.

Set-ADSyncScheduler -SyncCycleEnabled $false

Connect-MgGraph -Scopes "Organization.ReadWrite.All"

$orgId = (Get-MgOrganization).Id

# Confirm current state first
Get-MgOrganization | Select-Object OnPremisesSyncEnabled

# Disable directory synchronisation for the whole tenant
Update-MgOrganization -OrganizationId $orgId `
    -BodyParameter @{ onPremisesSyncEnabled = $false }

# Verify (will read False once accepted)
Get-MgOrganization | Select-Object OnPremisesSyncEnabled

$orgId = (Get-MgOrganization).Id

Update-MgOrganization -OrganizationId $orgId `
    -BodyParameter @{ onPremisesSyncEnabled = $true }

Then, on the sync server, re-enable the scheduler and run a sync cycle:

Set-ADSyncScheduler -SyncCycleEnabled $true
Start-ADSyncSyncCycle -PolicyType Initial

Pitfalls to Plan For

Hard-match takeover blocking

When sync resumes and Connect tries to hard-match the main domain's objects via ImmutableID, Microsoft's hard-match-block protection can get in the way, particularly for privileged accounts, which are deliberately protected from being taken over through hard match. If re-matching does not behave as expected for some accounts, this protection is the likely reason. Understand its state before you start rather than discovering it mid-cutover.

The all-or-nothing nature of the tenant disable

The disable step converts the entire tenant to cloud-only, both domains, for the duration of the window before you re-scope and re-enable. That is by design and is exactly what makes the method work, but it does mean there is a period where nothing is syncing from anywhere. Schedule accordingly, and make sure no other change that depends on sync is due during the window.

Group-based licensing

If you use group-based licensing, make sure the licensing groups survive as cloud objects through the conversion (they will, as security or Microsoft 365 groups) and that licences re-apply cleanly afterward. Check licence assignment as part of Phase 9.

Password changes during the window

Passwords already synced remain valid, so users are not locked out. But during the period when sync is off, any password change made on-premises will not flow to the cloud, and vice versa. Keep on-premises password changes to a minimum during the window and communicate that to anyone who might be affected.

The Modern Alternative: Per-Object Source of Authority

Recent Entra Connect builds added a genuinely better tool for this specific problem, which did not exist when many of us first had to do it. Instead of the tenant-wide disable, you can flip the source of authority to the cloud on a per-object basis, converting exactly the objects you want (the closing domain's) while the main domain keeps syncing untouched throughout. No tenant-wide disruption, no 72-hour lock.

It works by setting an isCloudManaged flag on each object through Microsoft Graph, and Connect then stops syncing just those objects from on-premises. The essential points:

• It requires a current Connect Sync build (roughly the 2.5.76.0 generation or later for users and groups, with a slightly newer build for contacts). There is a hardening deadline that requires you to be on a recent build anyway, so this is worth combining with that upgrade.
• Convert groups first, then users, then contacts, because a cloud-managed user cannot be added to a group that is still mastered on-premises.
• It is the surgical option: it touches only what you point it at, which makes it the natural choice when only part of a domain is moving, or when you want to avoid any tenant-wide window at all.

For a full-domain closure on an older Connect version, the disable-and-rescope method in this guide remains the reliable, well-worn path. For the same job on a current build, the per-object approach is cleaner still and avoids the 72-hour window entirely. Both get you to the same place: the closing domain's identities living happily in the cloud, and the main domain carrying on as hybrid.

---

Quick-Action Checklist

The disable-and-rescope method in order. Each step links back to the detail above.

1. Inventory everything: users, groups (with type), memberships, distribution and dynamic distribution groups, mail contacts, licences. This is your safety net and your verification baseline.
2. Pre-create the fragile objects in Exchange Online: dynamic distribution groups, and (if the closing domain had on-premises Exchange) any distribution lists or contacts you are unsure of. Validate mail flow.
3. Confirm everything you want to keep is in scope and healthy before you touch anything.
4. Stop the sync scheduler (Set-ADSyncScheduler -SyncCycleEnabled $false) and take Connect out of the picture.
5. Disable directory sync tenant-wide with Update-MgOrganization -BodyParameter @{ onPremisesSyncEnabled = $false }. Everything converts to cloud-only in place.
6. Wait out the ~72-hour window and confirm the conversion: objects show as cloud, editable in the portal, licences intact.
7. Reconfigure Connect for the main domain only, excluding the closing domain entirely.
8. Re-enable directory sync (onPremisesSyncEnabled = $true), re-enable the scheduler, and run an initial sync. The main domain hard-matches back to hybrid via ImmutableID; the closed domain stays cloud-only.
9. Verify the end state against your inventory: main domain synced, closed domain cloud-only, licences and mail flow intact.
10. Decommission the closing domain's DCs only after verification. With nothing pointing at them, they can go.

Closing Thoughts

The instinct when you need to remove one domain is to reach for the filtering option that seems to target exactly that domain, and it is the wrong instinct, because that path deletes what it de-scopes. The disable-and-rescope method feels heavier (you are briefly converting the whole tenant) but it is the one that never deletes anything, and it uses the retained ImmutableID to bring the main domain straight back to hybrid while leaving the closed domain as clean cloud-only objects. Inventory first, respect the 72-hour window, verify at each checkpoint, and it is a calm, reversible-until-the-last-step operation. Hundreds of users and groups can make that journey with nothing lost and nobody needing a password reset, which for a domain closure is about as good as it gets. And if you are on a current Connect build, the per-object Source of Authority route makes it cleaner still.

← All guides