Entra Connect Sync Pflichtupdate September 2026: Warum 2.5.79.0 das falsche Ziel ist

Was die Frist zum Entra Connect Sync Pflichtupdate September 2026 wirklich bedeutet

Die Frist zum Entra Connect Sync Pflichtupdate im September 2026 ist ein harter Dienststopp, kein sanfter Hinweis auf eine Support-Richtlinie. Microsoft schreibt es wörtlich auf der Seite Microsoft Entra Connect: Versionsverlauf (Seitendatum 7. Juli 2026) und wiederholt denselben Wortlaut identisch auf der Seite Upgrade-Anleitung:

Pflicht-Upgrade erforderlich: Alle Synchronisierungsdienste in Microsoft Entra Connect Sync werden am 30. September 2026 eingestellt, wenn Sie nicht mindestens auf Version 2.5.79.0 sind. Im Mai 2025 haben wir diese Version mit einer Backend-Dienständerung veröffentlicht, die unsere Dienste härtet.

Der Folgesatz beseitigt jeden Zweifel am Fehlerverhalten: „Wenn Sie das Upgrade nicht vor der Frist durchführen können, schlagen alle Synchronisierungsdienste fehl, bis Sie auf die neueste Version aktualisieren."

Zwei operative Details im selben Hinweiskasten werden leicht überlesen. Die Connect-Sync-.msi ist jetzt ausschließlich über das Microsoft Entra Admin Center verfügbar, nicht mehr über das Download Center. Und der Installer erzwingt weiterhin die Basisvoraussetzungen: .NET Framework 4.7.2 und TLS 1.2.

Eine Ungereimtheit ist es wert, benannt zu werden, denn sie wird jeden stolpern lassen, der sein Inventar gegenprüft. Der Hinweis sagt, 2.5.79.0 sei „im Mai 2025" erschienen, aber derselbe Eintrag zum Release-Status von 2.5.79.0 auf derselben Seite lautet „09.01.2025: Zum Download über das Microsoft Entra Admin Center veröffentlicht", und die Ablaufkurve datiert das Support-Ende von 2.5.76.0 auf „01. September 2026 (12 Monate nach Veröffentlichung von 2.5.79.0)". Die Versionsuntergrenze ist die maßgebliche Tatsache; der Erscheinungsmonat im Hinweiskasten stimmt nicht mit dem Rest der Seite überein.

Warum 2.5.79.0 die falsche Version für das Upgrade ist

Liest man die Überschrift wörtlich, liegt der naheliegende Schritt darin, genau 2.5.79.0 zu installieren, den Haken zu setzen und weiterzumachen. Dieselbe Learn-Seite zeigt, warum das nur 23 Tage statt eines Jahres bringt.

Microsofts Ablaufrichtlinie für Connect Sync ist versionsrelativ, nicht kalenderrelativ: „Versionen von Microsoft Entra Connect Sync 2.x laufen 12 Monate nach dem Datum ab, an dem eine neuere Version veröffentlicht wird. Diese Richtlinie gilt seit dem 15. März 2023." Mehrere neuere Builds sind seit 2.5.79.0 erschienen, sodass dessen Uhr bereits läuft und fast abgelaufen ist:

Ein Administrator, der auf die vorgeschriebene Untergrenze aktualisiert, umgeht den harten Stopp am 30. September und fällt dann am 23. Oktober 2026, dreiundzwanzig Tage später, aus dem Support. Die benachbarte Zeile ist noch schärfer: 2.5.76.0 fällt am 01. September 2026 aus dem Support, einen Monat vor dem harten Stopp – ein Server, der eine Build-Stufe unterhalb der Untergrenze steht, ist also bereits unsupportet, wenn der Dienst ihn abschaltet.

Drei weitere Gründe, warum das Minimum das falsche Ziel ist:

• 2.5.79.0 wird mit einem bekannten UI-Fehler ausgeliefert. Microsoft wiederholt denselben Hinweis bei 2.5.3.0, 2.5.76.0, 2.5.79.0 und 2.5.190.0: „Verwenden Sie in dieser Version nicht die Synchronization Service Manager-Benutzeroberfläche. Andernfalls können der Microsoft Entra Connect-Assistent und die automatische Zertifikatserneuerung fehlschlagen. Dieses Problem ist in Version 2.6.1.0 behoben." Der Fehler betrifft jeden Build unterhalb von 2.6.1.0 – ein Upgrade auf die Untergrenze entkommt ihm also nicht.
• Der aktuelle Build enthält Sicherheitskorrekturen. 2.6.84.0, veröffentlicht am 07.07.2026, ist als „Dieses Release enthält Sicherheitskorrekturen. Wir empfehlen, so bald wie möglich auf diese Version zu aktualisieren" gekennzeichnet, und sein Änderungsprotokoll enthält „Mehrere Sicherheitslücken in gebündelten Drittanbieter-Abhängigkeiten behoben."
• Installieren Sie nicht 2.6.79.0. Microsoft hat diese Version zurückgerufen: „Version 2.6.79.0 steht nicht mehr zum Download zur Verfügung. Nach der Veröffentlichung wurde ein Problem festgestellt, und der Installer wurde zurückgerufen. Kunden, die diese Version installiert haben, sollten sie deinstallieren und die neueste verfügbare Version (2.6.84.0) von Microsoft Entra Connect Sync installieren."

Wer wirklich betroffen ist: die Falle bei der Auto-Upgrade-Berechtigung

Die intuitive Lesart ist, dass nur Administratoren betroffen sind, die das automatische Upgrade absichtlich deaktiviert haben. Die dokumentierten Berechtigungsregeln sagen etwas anderes. Laut Microsoft Entra Connect: Automatisches Upgrade ist das automatische Upgrade standardmäßig nur aktiviert, wenn alle folgenden Bedingungen zutreffen:

• Express-Einstellungsinstallation oder ein DirSync-Upgrade
• SQL Express LocalDB, die von Express-Einstellungen immer verwendet wird
• Das AD-Konto ist das Standardkonto MSOL_, das von Express-Einstellungen oder DirSync erstellt wurde
• Weniger als 100.000 Objekte in der Metaverse

Das ist das Profil eines kleinen Mandanten. Eine typische Unternehmensbereitstellung – benutzerdefinierte Installation, vollständiger SQL Server, ein dediziertes Connector-Konto, sechsstellige Objektzahlen – hat von Anfang an nie automatisch aktualisiert. Genau diese Server driften auf den 30. September zu, und niemand hat etwas deaktiviert, um dorthin zu gelangen.

Microsoft veröffentlicht die konkreten Bedingungen, die einen Server nicht berechtigt machen, jede mit einer eigenen Ergebniszeichenfolge:

Es gibt eine subtilere Falle für Mandanten, die tatsächlich automatisch aktualisieren. Das automatische Upgrade liefert nur Builds, die Microsoft für diesen Kanal freigibt, und die Versionshinweise sagen, welche das sind: 2.6.1.0 und 2.6.3.0 geben jeweils an, dass das automatische Upgrade bestehende Installationen auf diesen Build verschiebt, während das aktuelle 2.6.84.0 nur „Zum Download über das Microsoft Entra Admin Center veröffentlicht" angibt. Ein gesund automatisch aktualisierender Server steht daher höchstwahrscheinlich auf 2.6.3.0 – komfortabel jenseits des harten Stopps, aber nicht auf dem Build mit den Sicherheitskorrekturen vom Juli 2026. Microsofts eigene Einordnung dieses Kompromisses: „Die Auto-Upgrade-Version enthält möglicherweise nicht die neuesten Funktionen."

Zwei weitere Dinge unterbrechen das automatische Upgrade unbemerkt. Wird die Synchronization Service Manager-Benutzeroberfläche auf dem Server offen gelassen, wird das Upgrade pausiert („das Upgrade wird ausgesetzt, bis die Benutzeroberfläche geschlossen wird"), und das Blockieren der Microsoft Entra Connect Health-URLs am Proxy bricht es komplett ab, da das automatische Upgrade auf der Health-Infrastruktur aufsetzt.

Erkennung: Version und Auto-Upgrade-Status bestätigen

Vertrauen Sie nicht der CMDB. Prüfen Sie jeden Connect-Sync-Server direkt, einschließlich der Staging-Server, die genauso der Frist unterliegen wie der aktive.

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

Das Versionspaar zählt mehr als jede der beiden Zahlen für sich. Microsofts Anleitung zur Fehlerbehebung für einen Server, der sich nach einem automatischen Upgrade fehlerhaft verhält – KB 4038479, dessen Symptomliste auf ältere 1.x-Builds beschränkt ist, dessen Beschreibung des Upgrade-Mechanismus jedoch generisch bleibt – ist eindeutig: „Während des automatischen Upgrades wird die aktuelle Installation von Microsoft Entra Connect aktualisiert, und anschließend wird die Version in der Serverkonfiguration aktualisiert. Stimmen die beiden Versionen nicht überein, wurde Microsoft Entra Connect nur teilweise aktualisiert." Ein Server, der eine konforme installierte Version, aber eine veraltete Microsoft.Synchronize.ServerConfigurationVersion meldet, hat den Vorgang nicht abgeschlossen und sollte nicht als behoben gezählt werden. Von derselben Seite stammen auch die Prüfung auf SchedulerSuspended und der Pfad des SyncEngine-AutoUpgrader-Protokolls.

Der Ereignisprotokollfilter ist der schnellste Weg, um Server zu finden, die seit Monaten erfolglos versuchen: Filtern Sie das Anwendungsprotokoll nach der Quelle Microsoft Entra Connect Upgrade und dem Ereignis-ID-Bereich 300–399. Ergebniscodes mit dem Präfix UpgradeAborted sind vorübergehend und werden erneut versucht. Codes mit dem Präfix UpgradeNotSupported bedeuten laut Microsoft, dass „erwartet wird, dass das System manuell aktualisiert werden muss".

Behebung: Den Upgrade-Pfad wählen und seine Falle vermeiden

Microsoft dokumentiert drei Upgrade-Strategien. Wählen Sie nach Serveranzahl und Konfigurationsabweichung, nicht nach Bequemlichkeit.

1. Automatisches Upgrade. Nur für Express-Installationen möglich, die noch berechtigt sind. Kein manueller Eingriff nötig, aber der erreichte Build kann hinter dem aktuellen zurückbleiben.

2. In-Place-Upgrade. Microsoft nennt dies „bevorzugt, wenn Sie einen einzelnen Server mit weniger als etwa 100.000 Objekten haben", und benennt den Kompromiss unverblümt: „Wenn beim In-Place-Upgrade ein Problem auftritt, können Sie das neue Release oder die Konfiguration nicht zurückrollen …" Zwei Dinge sind einzuplanen:

• Haben sich die Standard-Sync-Regeln zwischen den Builds geändert, läuft anschließend ein vollständiger Import und eine vollständige Synchronisierung. „Dieser Lauf kann je nach Anzahl der im Sync-Engine-Umfang befindlichen Objekte mehrere Stunden dauern." Die Delta-Synchronisierung wird währenddessen ausgesetzt; die Passwortsynchronisierung läuft weiter.
• Haben Sie die Standard-Sync-Regeln angepasst, „werden diese Regeln beim Upgrade auf die Standardkonfiguration zurückgesetzt."

Um die vollständige Synchronisierung auf außerhalb der Geschäftszeiten zu verschieben, deaktivieren Sie während des Upgrades Start the synchronization process when configuration completes, prüfen Sie anschließend die aufgezeichneten Überschreibungen und löschen Sie sie:

Get-ADSyncSchedulerConnectorOverride | Format-List

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

Set-ADSyncScheduler -SyncCycleEnabled $true

Führen Sie den zurückgestellten vollständigen Import und die vollständige Synchronisierung bei der nächsten Gelegenheit aus. Werden sie dauerhaft ausgelassen, bleibt die neue Konfiguration für bestehende Objekte unangewendet.

3. Swing-Migration. Bauen Sie den neuen Server parallel auf, verifizieren Sie ihn, dann befördern Sie ihn. Microsoft führt dies als „sichersten Ansatz und reibungsloseren Übergang zu einer neueren Version" auf, merkt an, dass „die Synchronisierung nicht unterbrochen wird und kein Risiko für die Produktion darstellt", und nennt einen klaren Auslöser für diese Wahl: Kunden, die seit 12–18 Monaten kein Upgrade durchgeführt haben, „sollten stattdessen ein Swing-Upgrade in Betracht ziehen, da dies die konservativste und risikoärmste Option ist." Es ist zudem der unterstützte Weg, wenn das Windows Server-Betriebssystem ersetzt werden muss, da In-Place-OS-Upgrades nur von Server 2016, 2019 oder 2022 auf Server 2025 unterstützt werden.

Bei einer Swing-Migration den alten Server vollständig außer Betrieb nehmen. Der Fehlerfall ist still und schleichend: Ein zurückgelassener Sync-Server „kann möglicherweise nicht mehr auf das lokale Active Directory zugreifen … kann sich aber weiterhin mit Microsoft Entra ID verbinden und dazu führen, dass Attributwerte in jedem Sync-Zyklus fortlaufend zurückgesetzt werden."

Zwei Fehler zum Zeitpunkt des Upgrades, auf die zu prüfen ist

Angepasste miiserver.exe.config. Wurde diese Datei bei 2.5.190.0 und 2.6.1.0 zuvor bearbeitet – häufig gemäß früherer Anleitungen zur Unterstützung der Passwort-Hash-Synchronisierung in FIPS-aktivierten Umgebungen –, lässt das Upgrade sie unangetastet, und die Synchronisierung schlägt anschließend fehl mit System.IO.FileLoadException: Could not load file or assembly 'System.Diagnostics.DiagnosticSource, Version=6.0.0.1'. Die dokumentierte Umgehung besteht darin, die Datei unter %programfiles%\Microsoft Azure AD Sync\Bin zu sichern, die Bindungsumleitung innerhalb des assemblyBinding-Abschnitts hinzuzufügen und den ADSync-Dienst neu zu starten:

<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 behebt die eigentliche Ursache: Laut Änderungsprotokoll „führt das automatische Upgrade nun Kundenanpassungen mit der neuen Konfiguration zusammen und validiert das Ergebnis, bevor es angewendet wird", statt die Datei zu überschreiben.

Nicht standardmäßige Konnektoren. Verwenden Sie den Generic-LDAP- oder Generic-SQL-Konnektor, aktualisieren Sie die Konnektorkonfiguration im Synchronization Service Manager nach einem In-Place-Upgrade. Wird dies übersprungen, schlagen Import- und Exportläufe mit einem Fehler „Assembly version in AAD Connector configuration … is earlier than the actual version" im Anwendungsereignisprotokoll fehl.

Die Cloud-Sync-Frage

Microsoft eröffnet seine eigene Upgrade-Seite mittlerweile mit einem Hinweis: „Prüfen Sie, statt auf die neueste Version von Microsoft Entra Connect zu aktualisieren, ob Cloud Sync für Sie geeignet ist." Das ist eine legitime Option, und beide können im selben Forest nebeneinander laufen. Prüfen Sie vorher jedoch die Tabelle der unterstützten Szenarien: Cloud Sync unterstützt nicht den Microsoft Entra Hybrid Join, Windows Hello for Business, Domänen mit mehr als 250.000 Objekten, das Filtern von Verzeichnisobjekten nach Attributwerten oder die Topologie „Benutzerkonten in einem Forest, Postfächer in einem Ressourcen-Forest".

Was am 1. Oktober tatsächlich ausfällt

„Alle Synchronisierungsdienste werden fehlschlagen" hat einen größeren Wirkungsradius als einen pausierten Sync-Zyklus, weil Connect Sync der Transportweg für mehrere Dinge ist, die nicht offensichtlich „Synchronisierung" sind.

• Die Passwort-Hash-Synchronisierung hört auf, aktualisiert zu werden. PHS ist, in Microsofts Worten, „eine Erweiterung der Verzeichnissynchronisierungsfunktion, die von Microsoft Entra Connect Sync implementiert wird." Lokale Passwortänderungen erreichen den Mandanten nicht mehr, sodass Benutzer sich weiterhin gegen zunehmend veraltete Hashes authentifizieren.
• Die Erkennung durchgesickerter Anmeldedaten wird für Hybrid-Konten veraltet. Dieselbe Seite besagt, dass „Password Hash Sync auch die Erkennung durchgesickerter Anmeldedaten für Ihre Hybrid-Konten ermöglicht." Ohne aktuelle, nachfließende Hashes werden Treffer gegen Passwörter ausgewertet, die lokal möglicherweise bereits geändert wurden – und risikobehaftete Benutzer, die niemand behebt, sind in dieser Kette bereits das schwächste Glied.
• Joiner-Mover-Leaver stoppt an der Mandantengrenze. Das ist der sicherheitsrelevante Punkt. Das Deaktivieren oder Löschen eines Kontos im lokalen AD wird nicht mehr propagiert, sodass die Cloud-Identität so lange weiterfunktioniert, wie der Ausfall dauert, und jeder Abgang während dieses Zeitraums zu einem verwaisten, aber weiterhin aktivierten Konto wird. Genau das ist der blinde Fleck bei der hybriden Identitätssynchronisierung, der Monate später als Audit-Befund auftaucht.
• Gruppenmitgliedschaften frieren ein. Lokale Gruppenänderungen steuern den Cloud-Zugriff nicht mehr, einschließlich der Mitgliedschaft in Gruppen, die für Rollenzuweisungen oder das Conditional-Access-Scoping verwendet werden.

Behandeln Sie den 30. September als ein Ereignis der Identitäts-Governance, nicht nur der Verfügbarkeit. Es ist zudem nicht die einzige terminierte Entra-Änderung, die gerade läuft – die SSPR-Änderung auf ausschließlich registrierte Methoden am 9. November 2026 folgt rund sechs Wochen später.

Wie EtcSec dies erkennt

Ein stehen gebliebenes oder nur teilweise aktualisiertes Connect Sync kündigt sich im Mandanten nicht selbst an. Es zeigt sich als Identitätsdrift, und genau das kann ein Audit erfassen. EtcSecs Azure-Prüfungen erfassen exakt diese Art von Drift: HYBRID_ORPHANED_CLOUD_USER markiert Hybrid-Benutzer, die noch als lokal synchronisiert gekennzeichnet, in Entra ID aber deaktiviert sind, HYBRID_CLOUD_ONLY_PRIVILEGED erfasst reine Cloud-Benutzer mit privilegierten Rollen außerhalb der lokalen Tier-0-Governance, UNRESOLVED_PRIVILEGED_MEMBERS meldet privilegierte Rollenzuweisungen, die auf nicht mehr auflösbare Prinzipale verweisen, und PA_ADMIN_STALE_ACCOUNT erfasst Admin-Rollenzuweisungen für Benutzer, die sich lange nicht angemeldet haben.

Auf der lokalen Seite deckt dasselbe Audit die privilegierten Konten und Dienstkonten ab, die eine defekte Synchronisierung unbemerkt isoliert, und es fügt sich in die Art von wiederholbarem Audit-Workflow ein, der Drift zwischen den Fristen erfasst statt danach. Auf der Mandantenseite reiht es sich in dieselbe Entra-ID-Sicherheitsüberprüfung ein, die Sie bereits über Conditional Access, MFA und Rollenzuweisungen hinweg durchführen sollten.