Entra Connect Sync Mandatory Upgrade September 2026: Why 2.5.79.0 Is the Wrong Target

What the Entra Connect Sync Mandatory Upgrade September 2026 Deadline Actually Says

The Entra Connect Sync mandatory upgrade September 2026 deadline is a hard service stop, not a support-policy nudge. Microsoft states it verbatim on the Microsoft Entra Connect: Version release history page (page date 7 July 2026), and repeats the identical wording on the upgrade guidance page:

Mandatory Upgrade Required: All synchronization services in Microsoft Entra Connect Sync will stop working on September 30, 2026 if you're not on at least version 2.5.79.0. In May 2025, we released this version with a back-end service change that hardens our services.

The follow-up sentence removes any ambiguity about the failure mode: "If you're unable to upgrade before the deadline, all synchronization services will fail until you upgrade to the latest version."

Two operational details in the same box are easy to skim past. The Connect Sync .msi is now available exclusively from the Microsoft Entra admin center, not the Download Center. And the installer still enforces the baseline prerequisites: .NET Framework 4.7.2 and TLS 1.2.

One inconsistency is worth naming, because it will trip anyone cross-checking their inventory. The banner says 2.5.79.0 shipped "In May 2025", but the same page's release-status entry for 2.5.79.0 reads "09/01/2025: Released for download via the Microsoft Entra admin center", and the retirement table dates 2.5.76.0's end of support as "01 September 2026 (12 months after release of 2.5.79.0)". The version floor is the operative fact; the release month in the banner does not match the rest of the page.

Why 2.5.79.0 Is the Wrong Version to Upgrade To

Read the headline literally and the obvious move is to install exactly 2.5.79.0, tick the box, and move on. The same Learn page shows why that buys 23 days rather than a year.

Microsoft's retirement policy for Connect Sync is version-relative, not calendar-relative: "Versions of Microsoft Entra Connect Sync 2.x retire 12 months from the date that a newer version is released. This policy went into effect on 15 March 2023." Several newer builds have shipped since 2.5.79.0, so its clock has already been started and nearly run out:

An admin who upgrades to the mandated floor clears the 30 September hard stop and then falls out of support on 23 October 2026, twenty-three days later. The adjacent row is sharper still: 2.5.76.0 retires on 01 September 2026, a month before the hard stop, so a server sitting one build below the floor is already unsupported when the service cuts it off.

Three more reasons the minimum is the wrong destination:

• 2.5.79.0 ships with a known UI defect. Microsoft repeats the same note on 2.5.3.0, 2.5.76.0, 2.5.79.0 and 2.5.190.0: "Do not use the Synchronization Service Manager UI in this version. Doing so may cause the Microsoft Entra Connect wizard and automatic certificate renewal to fail. This issue is fixed in version 2.6.1.0." The defect follows every build below 2.6.1.0, so upgrading to the floor does not escape it.
• The current build carries security fixes. 2.6.84.0, released 07/07/2026, is flagged "This release includes security fixes. We recommend upgrading to this version as soon as possible", and its changelog includes "Fixed multiple security vulnerabilities in bundled third-party dependencies."
• Do not install 2.6.79.0. Microsoft recalled it: "Version 2.6.79.0 is no longer available for download. An issue was identified after release and the installer was recalled. Customers who had installed this version should un-install and install latest available version (2.6.84.0) of Microsoft Entra Connect Sync."

Who Is Actually at Risk: the Auto-Upgrade Eligibility Trap

The intuitive read is that only admins who deliberately disabled auto-upgrade are exposed. The documented eligibility rules say otherwise. Per Microsoft Entra Connect: Automatic upgrade, auto-upgrade is enabled by default only when all of the following hold:

• Express settings installation or a DirSync upgrade
• SQL Express LocalDB, which is what Express settings always use
• The AD account is the default MSOL_ account created by Express settings or DirSync
• Fewer than 100,000 objects in the metaverse

That is the small-tenant profile. A typical enterprise deployment - custom install, full SQL Server, a dedicated connector account, six-figure object counts - was never auto-upgrading in the first place. Those servers are the ones drifting toward 30 September, and nobody disabled anything to get there.

Microsoft publishes the specific conditions that make a server ineligible, each surfacing as a named result string:

There is a subtler trap for tenants that are auto-upgrading. Auto-upgrade only delivers builds Microsoft releases to that channel, and the release notes say which ones those are: 2.6.1.0 and 2.6.3.0 each state that auto-upgrade will move existing installations to that build, while the current 2.6.84.0 says only "Released for download via the Microsoft Entra admin center." A healthy auto-upgrading server therefore most likely sits on 2.6.3.0 - comfortably past the hard stop, but not on the build carrying July 2026's security fixes. Microsoft's own framing of the trade-off: "Auto-upgrade version might not include the latest features."

Two more things suspend auto-upgrade quietly. Leaving the Synchronization Service Manager UI open on the server pauses it ("the upgrade is suspended until the UI is closed"), and blocking the Microsoft Entra Connect Health URLs at the proxy breaks it outright, because auto-upgrade rides on the Health infrastructure.

Detection: Confirm Your Version and Your Auto-Upgrade State

Do not trust the CMDB. Check each Connect Sync server directly, including staging servers, which are just as subject to the deadline as the active one.

Get-ADSyncAutoUpgrade
Get-ADSyncAutoUpgrade -Detail
(Get-ADSyncGlobalSettings).Parameters | Select-Object Name,Value
Get-ADSyncScheduler

The version pair matters more than either number on its own. Microsoft's troubleshooting guidance for a server that misbehaves after an automatic upgrade - KB 4038479, whose symptom list is scoped to legacy 1.x builds but whose description of the upgrade mechanism is generic - is explicit: "During automatic upgrade, the current installation of Microsoft Entra Connect is upgraded, and then the version in the server configuration is updated. If the two versions don't match, Microsoft Entra Connect is only partially upgraded." A server reporting a compliant installed version alongside a stale Microsoft.Synchronize.ServerConfigurationVersion has not finished the job, and should not be counted as remediated. The same page is where the SchedulerSuspended check and the SyncEngine-AutoUpgrader log path come from.

The event-log filter is the fastest way to find servers that have been trying and failing for months: filter the Application log on source Microsoft Entra Connect Upgrade and event ID range 300-399. Result codes prefixed UpgradeAborted are transient and get retried. Codes prefixed UpgradeNotSupported mean, in Microsoft's words, that "the expectation is that the system must be upgraded manually."

Remediation: Pick the Upgrade Path, Then Avoid Its Trap

Microsoft documents three upgrade strategies. Choose by server count and configuration drift, not by convenience.

1. Automatic upgrade. Only viable for Express installations that are still eligible. No manual intervention, but the build you land on may lag the current one.

2. In-place upgrade. Microsoft calls this "preferred when you have a single server and less than about 100,000 objects", and states the trade-off plainly: "If there's an issue while in-place upgrading, you can't roll back the new release or configuration ..." Two things to plan for:

• If the out-of-box sync rules changed between builds, a full import and full synchronization runs afterwards. "This run might take a few hours, depending on the number of objects that are in scope of the sync engine." Delta sync is suspended during it; password synchronization continues.
• If you modified the out-of-box sync rules, "these rules are set back to the default configuration on upgrade."

To push the full sync to off-hours, clear Start the synchronization process when configuration completes during the upgrade, then inspect and clear the recorded overrides:

Get-ADSyncSchedulerConnectorOverride | Format-List

foreach ($connectorOverride in Get-ADSyncSchedulerConnectorOverride)
{
    Set-ADSyncSchedulerConnectorOverride -ConnectorIdentifier $connectorOverride.ConnectorIdentifier.Guid -FullSyncRequired $false -FullImportRequired $false
}

Set-ADSyncScheduler -SyncCycleEnabled $true

Run the deferred full import and full synchronization at the earliest opportunity. Dropping them permanently leaves the new configuration unapplied to existing objects.

3. Swing migration. Build the new server alongside, verify it, then promote it. Microsoft lists it as the "Safest approach and smoother transition to a newer version", notes that "Sync isn't interrupted and doesn't impose a risk to production", and gives a clear trigger for choosing it: customers who haven't upgraded in 12-18 months "should consider a swing upgrade instead as this is the most conservative and least risky option." It is also the supported route when the Windows Server OS needs replacing, since in-place OS upgrades are supported only from Server 2016, 2019 or 2022 to Server 2025.

If you swing, decommission the old server completely. The failure mode is silent and slow: a leftover sync server "may no longer be able to access on-premises Active Directory ... but can still connect to Microsoft Entra ID and cause attribute values to continually revert in every sync cycle."

Two upgrade-time defects to check for

Modified miiserver.exe.config. On 2.5.190.0 and 2.6.1.0, if that file was previously edited - commonly following earlier guidance to support password hash synchronization in FIPS-enabled environments - the upgrade leaves it alone and synchronization then fails with System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.1'. The documented workaround is to back up the file in %programfiles%\Microsoft Azure AD Sync\Bin, add the binding redirect inside the assemblyBinding section, and restart the ADSync service:

<dependentAssembly>
  <assemblyIdentity name="System.Diagnostics.DiagnosticSource" publicKeyToken="cc7b13ffcd2ddd51" culture="neutral" />
  <bindingRedirect oldVersion="0.0.0.0-8.0.0.0" newVersion="8.0.0.0" />
</dependentAssembly>

Version 2.6.84.0 addresses the root cause: its changelog records that auto-upgrade now "merges customer modifications with the new configuration and validates the result before applying" rather than overwriting the file.

Non-standard connectors. If you run the Generic LDAP or Generic SQL connector, refresh the connector configuration in Synchronization Service Manager after an in-place upgrade. Skip it and the import and export run steps break with an "Assembly version in AAD Connector configuration ... is earlier than the actual version" error in the application event log.

The Cloud Sync question

Microsoft now opens its own upgrade page with a nudge: "Instead of upgrading to the latest version of Microsoft Entra Connect, see if cloud sync is right for you." That is a legitimate option, and the two can run in the same forest side by side. Check the supported scenarios table before committing, though: cloud sync does not support Microsoft Entra hybrid join, Windows Hello for Business, domains larger than 250K objects, filtering directory objects on attribute values, or the user-accounts-in-one-forest with mailboxes-in-a-resource-forest topology.

What Actually Breaks on October 1

"All synchronization services will fail" has a wider blast radius than a paused sync cycle, because Connect Sync is the transport for several things that are not obviously "sync".

• Password hash synchronization stops updating. PHS is, in Microsoft's words, "an extension to the directory synchronization feature implemented by Microsoft Entra Connect Sync." On-premises password changes stop reaching the tenant, so users keep authenticating against increasingly stale hashes.
• Leaked-credential detection goes stale for hybrid accounts. The same page states that "Password Hash Sync also enables leaked credential detection for your hybrid accounts." Without fresh hashes flowing, matches are evaluated against passwords that may already have been rotated on-premises - and risky users nobody remediates are already the weak link in that chain.
• Joiner-mover-leaver stops at the tenant boundary. This is the security-relevant one. Disabling or deleting an account in on-premises AD no longer propagates, so the cloud identity keeps working for as long as the outage lasts, and every departure during that window becomes an orphaned but still-enabled account. That is precisely the hybrid identity sync blind spot that surfaces as an audit finding months later.
• Group membership freezes. On-premises group changes stop driving cloud access, including membership of groups used for role assignment or Conditional Access scoping.

Treat 30 September as an identity-governance event, not only an availability one. It is also not the only dated Entra change in flight - the SSPR registered-methods-only change on 9 November 2026 lands roughly six weeks later.

How EtcSec Detects This

A stalled or partially upgraded Connect Sync does not announce itself in the tenant. It shows up as identity drift, and that is what an audit can catch. EtcSec's Azure checks surface exactly this class of drift: HYBRID_ORPHANED_CLOUD_USER flags hybrid users still marked as on-premises synced but left disabled in Entra ID, HYBRID_CLOUD_ONLY_PRIVILEGED catches cloud-only users holding privileged roles outside on-premises Tier 0 governance, UNRESOLVED_PRIVILEGED_MEMBERS reports privileged role assignments pointing at principals that can no longer be resolved, and PA_ADMIN_STALE_ACCOUNT picks up admin role assignments held by users who have not signed in for an extended period.

On the on-premises side, the same audit covers the privileged and service accounts that a broken sync quietly strands, and it fits the kind of repeatable audit workflow that catches drift between deadlines instead of after them. On the tenant side, it slots into the same Entra ID security review you should already be running across Conditional Access, MFA and role assignments.