Disable Entra Directory Sync: PowerShell, the Cut, and the 72-Hour Wait

Sometimes you need to stop the sync entirely. Maybe you’re going fully cloud and decommissioning the on-prem servers. Maybe you’re consolidating tenants. Maybe legacy AD is too rotted to fix and the rebuild is starting in the cloud. Whatever the reason, when you disable directory sync, you’re telling Microsoft Entra ID: stop listening to my local AD; treat every synced user as cloud-managed from now on. This is a one-way door (technically reversible via Microsoft support, but not in any timeline you’d enjoy). This post is the procedure with all the warnings.

Pre-flight checklist (do not skip)

Before running the disable command:

Backup AD. Even though we’re cutting the cloud-link, your AD VMs still exist post-cut. Take a fresh DR backup before anything destructive.
Export user attributes. Run Get-ADUser -Filter * with all properties to a CSV. After the cut, attributes you stop syncing become editable in the cloud and may diverge.
Reset all admin passwords in the cloud BEFORE the cut. Once sync is off, your AD password isn’t reaching the cloud anymore. Whatever password is in Entra is the one you’ll be stuck with for that admin until you reset via SSPR (which requires it to already be configured) or via another admin.
Verify a cloud-only break-glass admin works. One account that doesn’t depend on sync, MFA-secured, password stored in a vault. If everything goes wrong, this is your way back in.
Comms to all users. They need to know that whatever password they have right now is the cloud password going forward; it stops mirroring AD. Some workflows will change.

Skip any of these and you risk locking yourself out, losing group memberships, or finding that a user’s on-prem-managed attributes (manager, department) are now blank in the cloud.

Step 1 — verify the “before” state

Microsoft 365 admin centre Active Users page with the Sync status column visible showing a mix of Cloud-only icons and Synced-from-on-premises icons — Step 1 baseline. M365 admin centre > Users > Active users. Note the **Sync status** column — mix of Cloud-only and Synced-from-on-prem.

Go to M365 admin centre. Users > Active users. Look at the Sync status column. You’ll see two icons: a cloud icon (cloud-only users) and a sync icon (synced from on-prem). After the cut, all rows will be the cloud icon. Take a screenshot now — this is your before state.

Step 2 — PowerShell setup

This isn’t a UI operation. There is no toggle for it in the admin centre. PowerShell only.

Sign into the Entra Connect server (or any machine with the Microsoft.Graph PowerShell modules installed). Run as administrator:

# on the Entra Connect server
Import-Module ADSync
Get-ADSyncScheduler | Format-Table SyncCycleEnabled
Set-ADSyncScheduler -SyncCycleEnabled $false

Install-Module Microsoft.Graph -Force
Install-Module Microsoft.Graph.Beta -AllowClobber -Force
Connect-MgGraph -Scopes "Organization.ReadWrite.All"

PowerShell ISE on the Entra Connect server running the seven-command bootstrap: Import-Module ADSync, Get-ADSyncScheduler, Set-ADSyncScheduler with SyncCycleEnabled false, Install-Module Microsoft.Graph and Beta, Connect-MgGraph with Organization.ReadWrite.All scope — Step 2 PowerShell setup on the Entra Connect server. Stop the local sync scheduler first (`Set-ADSyncScheduler -SyncCycleEnabled $false`), then install the Graph modules and connect with the right scope.

What this does:

Import-Module ADSync — loads the local Entra Connect cmdlets
Set-ADSyncScheduler -SyncCycleEnabled $false — stops the LOCAL scheduler from running new sync cycles. (This is local-side; the cloud-side cut comes next.)
Install-Module Microsoft.Graph — the modern API to manage tenant settings
Connect-MgGraph -Scopes "Organization.ReadWrite.All" — sign in as a Global Administrator with permission to update org settings

Step 3 — verify admin context

Output of Get-MgContext or whoami showing the admin context the session is operating under, used to confirm the Global Administrator identity before the destructive step — Step 3 sanity check. Confirm you’re signed in as the right Global Administrator before running anything destructive.

Sanity check before anything destructive. Run Get-MgContext — confirm the account, tenant ID, and scopes match what you expect.

Step 4 — disable directory sync (the cut)

$OrgID = (Get-MgOrganization).Id
$params = @{ onPremisesSyncEnabled = $false }
Update-MgOrganization -OrganizationId $OrgID -BodyParameter $params

# verify
Get-MgOrganization | Select-Object DisplayName, OnPremisesSyncEnabled

PowerShell Update-MgOrganization command being executed with onPremisesSyncEnabled set to false, the cloud-side disable directive — Step 4 the actual cut. `Update-MgOrganization -OrganizationId $OrgID -BodyParameter @{ onPremisesSyncEnabled = $false }`. This tells Microsoft to stop listening to on-prem.

The OnPremisesSyncEnabled field flips to False on the cloud side. Microsoft begins the conversion process — every synced user becomes a cloud-managed user.

Step 5 — the waiting game

Not instant. Don’t panic if M365 admin centre still shows the sync icons immediately after.

Small labs (under ~50 users): 5–10 minutes for full propagation
Mid-size orgs (a few hundred users): 30 min to a few hours
Large directories (thousands of users): up to 72 hours

Make a coffee. Don’t make any user changes during the conversion period.

Step 6 — verify the “after” state

Check 1: M365 admin centre

Microsoft 365 admin centre Active Users page after the change with all users now showing the Cloud-only icon in the Sync status column, the sync indicator gone — Step 6 first verification. M365 admin centre. After the propagation completes (5–10 min in a small lab, up to 72h in a large org), all user rows show Cloud-only.

Refresh the Active Users page. The sync status column now shows Cloud-only for every user. Sync icons gone.

Check 2: Entra admin centre — Connect status

Entra admin centre Hybrid management > Microsoft Entra Connect page showing Sync Disabled status and a stale Last Sync timestamp confirming the cloud no longer accepts sync from on-premises” /><figcaption>Step 6 second verification. Entra admin centre > Hybrid management > Microsoft Entra Connect. Status shows Sync Disabled / Not Enabled and Last Sync no longer updates. Decoupling complete.</figcaption></figure>
<p>Hybrid management > Microsoft Entra Connect. Status: <strong>Sync Disabled</strong> (or <strong>Not Enabled</strong>). Last Sync timestamp is stale and won’t update. Decoupling complete.</p>
<h2>What changed (and what didn’t)</h2>
<h3>Changed</h3>
<ul>
<li>Users are now cloud-managed. Their attributes are edited in the cloud.</li>
<li>Passwords no longer mirror AD. Whatever the cloud password is, that’s what the user signs in with for M365.</li>
<li>Group memberships, especially security groups synced from on-prem, must now be managed in the cloud.</li>
<li>Local AD changes (new users, password changes) no longer reach M365.</li>
</ul>
<h3>Did NOT change</h3>
<ul>
<li>The on-premises AD itself is untouched. Users still sign into domain-joined machines with the AD password (which is now divergent from cloud).</li>
<li>Existing M365 mailboxes, OneDrive, Teams content. All preserved.</li>
<li>Tenant ID, domain names, licences. All intact.</li>
<li>Local Entra Connect installation. Still on disk; just not syncing.</li>
</ul>
<h2>Things that bite people</h2>
<h3>The 72-hour propagation panic</h3>
<p>For large directories, the cloud-side conversion takes time. Don’t flip back during that window. Wait the full propagation time before judging success or failure.</p>
<h3>Helpdesk script becomes wrong</h3>
<p>If your helpdesk has scripts that say “reset password in AD, it’ll sync to M365 in 30 min,” those are now wrong. Update the runbook before the cut, not after.</p>
<h3>Conditional Access “hybrid Azure AD joined” rules break</h3>
<p>If you have CA policies that condition on hybrid Azure AD joined devices, those still work but the JOIN itself is now happening differently — cloud-only, not via AD. Audit the policies.</p>
<h3>Re-enabling is painful</h3>
<p>You can re-enable sync. But every cloud-only user that came from a synced user has to be re-matched to its AD object via <code>ImmutableID</code>. If you don’t have that data, users get duplicated and the cleanup is significant. Plan as if this is one-way.</p>
<h3>Service accounts</h3>
<p>If you have service accounts in AD that were syncing to the cloud, those users continue working in the cloud (now cloud-managed). But the service that uses the AD account (e.g. a SQL service) doesn’t care about the cloud and continues using the AD password. So nothing breaks IF the password isn’t changed. If you change the cloud password later, the SQL service still uses the AD password — the two diverge silently.</p>
<h3>SSPR with writeback now means nothing</h3>
<p>If you had <a href=

Tags: #Cloud Migration #Decommission #Entra Connect #Microsoft Entra ID #PowerShell