Entra Connect Sync: Why Auto-Upgraded Servers Fail in April

You disable a leaver's account in Active Directory, reset the password, and move on. Within half an hour Microsoft Entra Connect Sync has carried the change to Entra ID, and the cloud side of that person's access starts to close. From 7 April 2027 that stops happening on a class of server that looks fully patched, and under password hash synchronisation the failure is quiet: sign-in keeps working, and the leaver keeps their access.

When I checked Microsoft's documentation on 17 September, it said Connect Sync servers below version 2.5.79.0 would stop synchronising on 30 September 2026. The pages now carry update dates between 29 September and 1 October, and they say something different. The deadline is 7 April 2027. The minimum version is 2.6.84.0, a build Microsoft released on 7 July, ten weeks before I read the page that still named 2.5.79.0. And a third condition appeared: the server must use application-based authentication, which replaces the Sync_ service account that Connect Sync uses to sign in to Entra ID with an app registration and a certificate.

That third condition is the one that will catch people. Auto-upgrade, which most organisations rely on to keep Connect Sync current, has never delivered a build that meets the version floor, and since July background sync no longer switches the credential either. So the version number alone no longer tells you whether a server survives April.

What the pages said, and what they say now

On 17 September the Learn page titled "Hardening updates for Microsoft Entra Connect Sync", which I will call the hardening page, said servers must be on 2.5.79.0 or higher by 30 September 2026, and that below that version all synchronisation would fail until an upgrade. On 2 October the hardening page says this:

To maintain directory synchronization and avoid service disruptions, customers must upgrade to Microsoft Entra Connect version 2.6.84.0 or later and configure application-based authentication by April 7, 2027.

The consequence is unchanged: every synchronisation service fails between the deadline and the upgrade. The deadline, the version floor and the credential requirement all changed.

The security updates page now carries both dates at once. Its opening paragraph still says "Customers who were autoupgraded won't be impacted by the service change", and still recommends upgrading "by September 30, 2026". A boxed notice underneath says:

Mandatory upgrade required: Upgrade Microsoft Entra Connect Sync to version 2.6.84.0 or later and configure application-based authentication by April 7, 2027. Legacy authentication is being retired, and synchronization services will stop working after this date if these requirements aren't met.

The same notice sits on the upgrade page, the prerequisites page and the version history. Read together, September now reads as a recommendation and April as the deadline, and what is enforced is an authentication method with a version floor attached. The sentence about auto-upgraded customers predates the new conditions, and the rest of this post explains why it no longer holds.

None of this is in the Entra "What's new" page. The change lives in page edits and in whatever Message Center post your tenant received. If your plan cited the 30 September date from the hardening page, that page no longer states it as a requirement.

Two clocks: version support and the deadline

Connect Sync 2.x versions lose support twelve months after the next version ships. The version history gives these dates for the versions that matter here:

The 2.5.79.0 row does not follow the page's own rule. Its successor shipped on 19 November 2025, which would give 19 November 2026, and the page says 23 October. I have used the date the page states.

Two things follow. First, 2.5.79.0, the version the old deadline named, loses support on 23 October 2026 whatever happens in April, so anyone who hit the old minimum and stopped is days from an unsupported build. Second, 2.6.3.0 is in support until July 2027 and fails in April 2027. The support table governs whether Microsoft supports a build; the 7 April deadline governs whether it syncs.

Why an auto-upgraded server still fails

Auto-upgrade is the feature that keeps an Express installation current without anyone touching it. It is enabled by default only for Express installs with the LocalDB database, the default MSOL_ account and fewer than 100,000 objects. Most enterprise installs are custom, with full SQL or a custom account, and were never candidates. For the servers that are, three facts decide the outcome.

First, before 2.6.84.0, Connect Sync would switch an existing server from the Sync_ account to application-based authentication on its own, during background sync. Application-based authentication became the default in 2.5.76.0, so a server that ran a build between 2.5.76.0 and 2.6.3.0 for long enough may already have been switched. Whether that switch succeeded on a given server is not something the version tells you.

Second, from 2.6.84.0, nothing switches an existing server except a person. The 2.6.84.0 release notes say:

Microsoft Entra Connect no longer automatically switches existing servers from the legacy directory synchronization account to Application-Based Authentication during background sync. New installations continue to configure Application-Based Authentication during setup.

The application identity page says the same, and adds that the managed application "is automatically set up during initial installation or manual interactive upgrades". The two pages do not agree on whether an in-place upgrade through the wizard switches a server, so treat that as unproven.

Third, auto-upgrade has not offered any build from 2.6.84.0 onward. Each version history entry says whether a build went out by auto-upgrade or by download only. The last build with an auto-upgrade rollout statement is 2.6.3.0, from March. The entries for 2.6.84.0, 2.6.91.0 and 2.6.92.0 say "Released for download via the Microsoft Entra admin center" and nothing more.

Put those three facts together. A server that has done everything auto-upgrade asked of it is on 2.6.3.0 today, below the floor, and fails in April on version alone. If Microsoft starts an auto-upgrade phase for a newer build before April, that server passes the version check and still fails, because background sync no longer switches the credential. A server someone upgraded by hand and then rolled back to the service account, which Learn documents as a supported procedure, is in the same position. Two servers on the same build can differ in the one thing that matters, and the only way to know is to ask the server:

# Windows PowerShell 5.1, elevated, on the Connect Sync server
Import-Module ADSync
Get-ADSyncEntraConnectorCredential

The ConnectorIdentityType value is Application or ServiceAccount. Anything that returns ServiceAccount fails on 7 April 2027 regardless of version. Run it on every Connect Sync server you have, including the staging server, and write the answer down against the hostname.

No tenant setting changed. The condition is a version and a credential type on a Windows server, and Secure Score, Message Center and Conditional Access will never report it. The passkey migration in September was a tenant policy change you could at least read in the portal; this one lives on a host.

A leaver disabled in Active Directory keeps access

This is the cost, and the part I would put in front of a steering group. The accountEnabled attribute travels in the object sync cycle, every 30 minutes by default; password hashes travel on their own scheduler every two minutes. When the sync service fails, both stop. The disable you set in Active Directory never arrives, and under password hash synchronisation neither do the two password resets that Microsoft's hybrid leaver procedure tells you to run after the disable. The leaver keeps their password, and Entra ID still thinks the account is enabled.

For a leaver, sign-in, mail and Teams all carry on, so nobody raises a ticket. What they can still do after sync stops:

Pass-through authentication, where the domain controller checks each password sign-in, differs from password hash synchronisation only on the first row. Every other path authenticates against Entra ID's view of the account, and that view has not changed. I have not verified what federation does for passwordless methods. Continuous Access Evaluation does not rescue you either: it fires on "User Account is deleted or disabled" when Entra ID sees the change, and Entra ID has not seen it.

Group changes stop arriving too. A leaver removed from a synced group that is used as a Conditional Access exclusion, or for application or licence assignment, stays in it in the cloud. Groups synced from on-premises cannot be enabled for PIM for Groups, so that one is not exposed. If your design leans on synced groups, reread the Conditional Access post assuming group membership never changes.

Microsoft does warn when sync stops, but every warning is a message to a person:

None of those is an outage.

Which servers you are looking for

The automatic upgrade page lists what makes a server ineligible: a custom install that is not a DirSync upgrade, a database other than LocalDB, LocalDB at 8 GB or larger, TLS below 1.2, or health data uploads disabled in the portal. Custom sync rules stopped blocking it after 2.2.1.0, so a server whose auto-upgrade was disabled for that reason can be re-enabled. Full SQL installs, which Microsoft requires above 100,000 objects, are never eligible.

On each server, three commands tell you where it stands:

# Windows PowerShell 5.1, elevated
Import-Module ADSync
 
# Auto-upgrade state, and the reason if Suspended
Get-ADSyncAutoUpgrade
Get-ADSyncAutoUpgrade -Detail
 
# Scheduler: SyncCycleEnabled, StagingModeEnabled, NextSyncCycleStartTimeInUTC
Get-ADSyncScheduler
 
# Which credential the Entra connector uses
Get-ADSyncEntraConnectorCredential

The installed version is the product version of AzureADConnect.exe under C:\Program Files\Microsoft Azure AD Connect. For the history of auto-upgrade attempts, filter the Application log on the source "Microsoft Entra Connect Upgrade" and event IDs 300 to 399. A result beginning UpgradeNotSupported means auto-upgrade has ruled the server out, and Microsoft expects it to be upgraded manually; UpgradeAborted means a temporary condition.

Find the pass-through authentication agent servers at the same time; Microsoft says to treat a server running that agent as if it were a domain controller.

Upgrade to 2.6.92.0, not the 2.6.84.0 minimum

The minimum is 2.6.84.0. Do not install it. The version history records that upgrading it over an existing ADSync database can fail with 0xE0474352, and that reopening its wizard can reselect a domain you had deselected and enable sync for the whole domain. Both are fixed in 2.6.91.0. That build has its own known issue enabling pass-through authentication through the wizard, fixed in 2.6.92.0, a hotfix released on 23 September and still the newest build in the version history on 12 October. Go to 2.6.92.0. The installer is in the Microsoft Entra admin centre, under Microsoft Entra Connect, Get started. The prerequisites page gives a .NET Framework minimum of 4.7.2 in its notice and 4.6.2 in its body; plan for 4.7.2.

Four applications appear in what follows, and they are easy to confuse. The first-party service principal "Microsoft Entra AD Synchronization Service", application ID 6bf85cfa-ac8a-4be5-b5de-425a0d0dc016, is Microsoft's, one per tenant, and the hardening page calls it "critical for the continued operation" of sync. The Connect Sync app registration is the one the wizard creates for application-based authentication, one per server. And Microsoft.Azure.SyncFabric and the Microsoft 365 Reporting Service appear to be the resources the wizard's own sign-in talks to.

Microsoft's upgrade page says to upgrade the staging server first and promote it, and to prefer a swing migration, a new server built alongside, for anything not upgraded in twelve to eighteen months. A staging server imports and synchronises but exports nothing, so it can be upgraded and checked without touching the tenant. The order I would use:

1. Confirm the first-party service principal exists and is enabled, under Enterprise applications. If it is missing or disabled, stop and find out why.

2. Check Conditional Access before the upgrade, in two places. The 2.6.91.0 notes add Microsoft Graph permissions to Connect Sync and say "If you use app-scoped Conditional Access policies, review policies targeting Microsoft.Azure.SyncFabric or Microsoft 365 Reporting Service"; those are user policies that will hit the administrator who runs the wizard. Separately, if you run Conditional Access for workload identities, which needs the Workload ID Premium licence, put the Connect Sync app registration's sign-ins under a report-only policy for a week first. I have not confirmed that a location policy on that registration blocks sync, but it targets the credential sync now uses, so I would not find out in production.

3. Upgrade the staging server to 2.6.92.0 through the wizard. Since 2.6.84.0 the wizard stops with an error rather than falling back to the legacy account if application-based authentication setup fails.

4. Run Get-ADSyncEntraConnectorCredential and confirm Application. If it says ServiceAccount, open the wizard, choose Additional tasks, then Configure application-based authentication to Microsoft Entra ID, and check again.

5. Let the staging server complete a full import and synchronisation, then review its pending exports before you promote it. A server that has sat in staging mode for months has a backlog.

6. Promote the staging server and power the old active server off, un-upgraded. It is your rollback for the next fortnight, and it still works as one because nothing on it has changed.

7. When the fortnight is up, upgrade the old server the same way, switch it to staging mode, and only then remove the legacy accounts. Each server has its own Sync_ account, and removing one while its server still reports ServiceAccount stops that server syncing at once:

   $cred = Get-Credential   # an Entra administrator
   Remove-ADSyncAADServiceAccount -AADCredential $cred -Name Sync_SERVER_id   # placeholder: the account name from the users list

   The -Name value is the first part of the account's UPN, visible in the users list. Microsoft's application identity page strongly recommends removing the account once application-based authentication is working. Left in place, it is a password-based account with directory synchronisation rights that nothing uses. If you decommission a server instead, uninstall it fully; the upgrade page is blunt about old sync servers that come back on the network and overwrite tenant data with stale attributes every 30 minutes.

8. Confirm password hash synchronisation is still on. From 2.6.84.0, Connect Sync no longer re-enables the cloud-side flag by itself, and until an administrator does, password changes stop reaching the cloud with no outage.

9. Treat the Connect Sync app registration as a control plane asset from the day you switch. The application identity page says a holder of Application Administrator can add a credential to it and act as Connect Sync; I would assume the same of Cloud Application Administrator and of any owner of the registration, though the page does not say so. Remove owners, keep those roles in PIM, and alert on credential changes.

If sync has already stopped, deal with the leavers before the backlog

This applies to any sync outage, whatever the cause. Disable the leavers in the cloud before you export. The reason is the accidental delete threshold, a safety limit that defaults to 500 objects: if more than that are pending deletion when the export runs, Connect Sync exports nothing, including the accountEnabled changes you most need to land, and a long outage can accumulate that many. So:

1. List everyone disabled in Active Directory since the failure whose Entra ID account is still enabled.

2. Block them in the cloud with a Conditional Access block policy scoped to a group you control. I expect clearing Account enabled on a synced user to be blocked or overwritten at the next sync; I have not tested it.

3. Revoke their sessions. This works in the cloud without sync, and already-issued access tokens live out their hour:

   Connect-MgGraph -Scopes User.RevokeSessions.All
   Revoke-MgUserSignInSession -UserId $UserId   # object ID or UPN

4. Disable their registered devices.

5. Review the sign-in logs for those accounts from the date sync stopped.

6. Review the pending deletions on the upgraded server before the first export. Raise the threshold temporarily if the deletions are legitimate. Do not disable it.

7. Review synced groups used in Conditional Access for members who should have left them.

Do not enable soft matching or hard match takeover to clear matching errors during recovery. The prerequisites page says to keep both disabled if you do not need them, and the errors they would clear are the ones telling you something is wrong.

Add a check that does not run on the sync server

Every warning in the table above depends on the sync server's own reporting or on someone reading a message. Add one check that runs in Azure and reads the tenant. The Graph organization resource carries onPremisesLastSyncDateTime, "the time and date at which the tenant was last synced with the on-premises directory":

GET https://graph.microsoft.com/v1.0/organization?$select=onPremisesLastSyncDateTime,onPremisesSyncEnabled

That needs Organization.Read.All; a caller with only User.Read gets null for the property. Run it from an Azure Automation runbook, a Function or a Logic App under a managed identity with that one permission, and alert at 90 minutes, three missed cycles. The permission is an application role on the Microsoft Graph service principal, so it is granted with New-MgServicePrincipalAppRoleAssignment rather than in the portal; readers who cannot find the portal button tend to grant Directory.Read.All instead, which is far more than this needs. Do not run it on the sync server, because that shares its failure domain and puts another credential on a control plane host. The tenant health post is the natural home for the check, and the Graph post covers permissions and managed identities.

Two cautions. I have not confirmed whether the timestamp advances on a delta cycle that exported nothing, which is why the threshold has slack. And I have not confirmed whether Cloud Sync updates the same property; if it does, a tenant running both could show a fresh timestamp while Connect Sync is down. If you run both, and your servers are on application-based authentication, watch each Connect Sync app registration's sign-ins as a second signal.

Cloud Sync is a 2027 planning item

Microsoft Entra Cloud Sync is the newer, cloud-managed replacement for Connect Sync. Its provisioning agent has no April deadline in its version history, 2.6.91.0 added a guided migration to it, and the hardening page and the security updates page both recommend it where a tenant is eligible. Microsoft's "What's new" page also says that from July 2026 it began notifying tenants, through Message Center, Connect Health and email, of individual timelines for a phased move from Connect Sync to Cloud Sync, so your tenant may already have one.

Check eligibility against Microsoft's Cloud Sync decision guide, which changed on 6 October. Fix the authentication method first, and migrate afterwards from a server that is not about to stop.

What is verified, and what is not

The deadline, the version floor and the application-based authentication condition are quoted from Learn pages as they stood on 2 October 2026, re-checked on 12 October with no change to dates, versions or builds: the hardening page, updated 1 October; the security updates page, the upgrade page and the prerequisites page, updated 29 September; and the version history, updated 6 October for spelling only, which also supplies the support table, the release notes, the known issues and the auto-upgrade rollout statements. The behaviour of application-based authentication, the credential check and the account removal are from the application identity page, updated 22 June. The PIM for Groups exclusion, the token lifetimes and the Graph permission behaviour were re-checked against their pages on 12 October. What the hardening page said on 17 September is from my own notes of that day, not an archive.

Not re-fetched since 17 September: the 30-minute and two-minute sync intervals, the three-day admin centre warning, the email about missed synchronisation, the Connect Health alert list and the delete threshold default. No command in this post was run against a live server for it, and the Graph call was not tested.

Three things are not documented, and each changes what you should assume. Microsoft's documentation history shows the deadline was extended on 30 September itself, and by 12 October I had found no report of any change to a server below 2.5.79.0 on that day; the pages now call that date a recommendation. Whether pass-through authentication agents are affected by the April change is not stated anywhere I can find; if they are, sign-ins fail loudly and the quiet-failure argument weakens. And Microsoft's own pages still contradict each other, on auto-upgraded customers being unaffected, on whether a manual upgrade switches the credential, and on the .NET Framework minimum.

I wrote this against the pages as they stood on 2 October and re-checked them on 12 October. Check the hardening page before you take any date here into a plan.

What to do now

1. List every Connect Sync server, including staging, and every pass-through authentication agent server. Record the version, the auto-upgrade state and the output of Get-ADSyncEntraConnectorCredential.
2. Treat a server as stopping on 7 April 2027 if it is below 2.6.84.0 or reports ServiceAccount, whatever its support date says.
3. Upgrade through the staging server to 2.6.92.0 in the order above, and confirm Application on each server afterwards. Any server still on 2.5.79.0 goes first, before 23 October.
4. Put the Graph freshness check in Azure.
5. Write the leaver clean-up order into the runbook now, while nobody needs it.