Entra Connect Sync wird durch Cloud Sync abgelöst

Microsoft holt 2026 den letzten On-Prem-Sync-Server vom Sockel — und du bekommst ein Migrationsfenster, ob du es willst oder nicht.

Executive Summary

Microsoft hat ein Datum gesetzt — und diesmal meinen sie es ernst. Seit April 2026 läuft der gestaffelte Übergang von Entra Connect Sync auf Entra Cloud Sync. Ab Juli 2026 informiert Microsoft jeden einzelnen Tenant über Message Center, Entra Connect Health und gezielte E-Mails darüber, wann das eigene Migrationsfenster aufgeht. Spätestens am 30. September 2026 stellt jede Connect-Sync-Installation unterhalb Version 2.5.79.0 kommentarlos den Betrieb ein. Wer dann noch träumt, fällt aus der hybriden Authentifizierung heraus — und mit ihm jeder synchronisierte Benutzer, jede Gruppe, jede Mailbox-Verknüpfung.

Die gute Nachricht: Cloud Sync ist seit Jahren reif für den produktiven Einsatz, kommt mit mehreren aktiven Agents, ist im Admin Center konfigurierbar und bringt Disconnected Forests nativ mit. Die schlechte Nachricht: einige Connect-Sync-Funktionen sind in Cloud Sync schlicht nicht vorhanden — Stichworte Hybrid Azure AD Join, komplexe Sync-Rules, Cross-Forest-References und Reconciliation. Wer das heute nutzt, hat Hausaufgaben.

Abb. 1: Microsoft rollt die Migration in Wellen aus — der 30.09.2026 ist der harte Hard-Stop.

Worum geht es im Detail?

Entra Connect Sync — früher Azure AD Connect, davor DirSync — war über ein Jahrzehnt lang der Hauptdarsteller in jeder hybriden Identitätsarchitektur. Ein Windows-Server, eine SQL-LocalDB, ein Sync-Rules-Editor, ein Heartbeat. Wer das Ding sauber installiert und in Ruhe gelassen hat, bekam Jahr für Jahr Patches eingespielt, hin und wieder ein Major-Upgrade, und ansonsten lief es. Genau dieses Modell hat Microsoft jetzt offiziell auf das Abstellgleis geschoben.

Cloud Sync ist die strategische Nachfolge-Plattform. Statt eines fetten Servers gibt es einen leichtgewichtigen Provisioning-Agent, der auf einem Domain Controller oder einem kleinen Member-Server läuft. Die Konfiguration — Scope, Mappings, Filter, Attribut-Flows — liegt nicht mehr in einer lokalen SQL-DB, sondern direkt in Entra ID. Updates laufen automatisch durch, mehrere Agents teilen die Last und springen füreinander ein, wenn einer aussteigt. Microsofts gesamte Entwicklung neuer Sync- und Provisioning-Features passiert seit Jahren ausschließlich auf Cloud Sync — Connect Sync bekommt nur noch Security-Patches und gerade einmal die nötigsten Bugfixes.

Die Migrationswelle läuft in mehreren Stufen. In den ersten Wellen ab April 2026 nimmt Microsoft die einfachen Fälle — Tenants mit einem oder mehreren verbundenen Forests, Standard-Attributen, OU-basiertem Filtering, ohne Device-Sync. Ab Juli 2026 startet dann die breite Benachrichtigungswelle über die üblichen Kanäle: M365 Message Center, Entra Connect Health und gezielte E-Mails an die Tenant-Admins. Wer in dieser Welle dran ist, bekommt ein konkretes Migrationsfenster zugewiesen — und einen Hinweis darauf, dass Microsoft seinen eigenen Migrations-Tooling-Pfad bevorzugt.

Komplexere Tenants — solche mit Disconnected Forests, Hybrid Azure AD Join, exotischen Sync-Rules oder Cross-Forest-References — bekommen entweder spätere Wellen oder müssen eine Exception beantragen. Die Exception ist machbar, aber sie kommt mit Hausaufgaben und einem Datum dran. Niemand bekommt einen Persilschein bis Sankt Nimmerlein.

Wichtig: Hybrid-Authentifizierung — also Pass-Through Authentication und Seamless Single Sign-On — bleibt nach der Migration funktional. PTA und Seamless SSO werden nicht vom Sync-Tool, sondern separat konfiguriert. Du kannst den alten Connect-Sync-Wizard auch nach dem Wechsel weiter für diese beiden Features nutzen. Was sich ändert, ist ausschließlich die Sync-Maschine darunter.

Abb. 2: Ein klobiger Server gegen mehrere agile Agents — Microsoft hat sich entschieden.

Was sind Chancen? Was sind Risiken?

Architektonisch ist Cloud Sync der überfällige Sprung vom physischen Hochregallager zum Just-in-Time-Modell. Du bekommst mehrere aktive Agents, die sich gegenseitig ablösen, ohne dass jemand einen Failover-Cluster baut. Du kannst Agents geografisch verteilen, Wartungsfenster verschwinden weitgehend, Konfigurationsdrift wird durch die zentrale Cloud-Konfiguration eliminiert. Mergers & Acquisitions, in denen plötzlich ein zweiter, völlig disconnected Forest dazukommt, werden statt zur 14-Tage-Migration zum Klick im Admin Center.

Operativ heißt das: weniger Server zu patchen, weniger Tickets über abgestürzte Sync-Engines, weniger VPN-Sessions ins lokale RZ, um irgendeine Sync-Rule zu fixen. Wer als Consultant oder MSP mehrere Kunden betreut, wird die Konsolidierung der Sync-Konfiguration im Admin Center lieben — und das einheitliche Verhalten gleich mit. Endlich keine drei verschiedenen Connect-Versionen pro Kunden mehr.

Die Risiken sind technisch konkret. Cloud Sync skaliert pro AD-Domain bis 150.000 Objekte, Connect Sync ist hier unbegrenzt. Große Gruppen sind aktuell auf 50.000 Mitglieder gedeckelt, Connect Sync schafft 250.000. Wer einen einzigen Verteiler-Monolithen mit 80.000 Mitgliedern hat, fällt erstmal raus — und sollte den Anlass nutzen, das Gruppen-Design ernsthaft zu hinterfragen.

Richtig schmerzhaft wird es bei den Features, die in Cloud Sync schlicht nicht existieren: Hybrid Azure AD Join (also klassische Device-Synchronisation), komplexe Sync-Rules mit eigenem Regelwerk, Cross-Forest-References, das Mergen von Attributen aus mehreren Domains und die klassische Reconciliation für Out-of-Band-Korrekturen. Wer das nutzt, muss entweder warten, bis Microsoft nachliefert, oder den Architekturweg umbauen. Für Hybrid Join ist Cloud Kerberos Trust ohnehin der saubere Nachfolger — die Migration dahin ist kein verlorener Aufwand, aber sie ist auch nicht trivial.

Praxisbeispiel: Bei einem Mittelständler mit zwei Forests (Stammhaus plus zugekaufte Tochter) hat das Inventarisieren der Sync-Regeln drei Tage gekostet. Das eigentliche Migrieren — Agent installieren, Cloud-Sync-Scope konfigurieren, Pilot-OU swingen, validieren — dann nur noch knapp einen Tag pro Forest. Die wirklichen Stolpersteine waren altgediente Custom-Sync-Rules, die irgendwann für eine längst eingestampfte Anwendung gebaut wurden und die niemand mehr zuordnen konnte. Aufräumen vor Migrieren — sonst migriert man jeden Altlasten-Frosch gleich mit.

Abb. 3: Feature-Reality-Check — die rote Spalte ist die, an der du Architekturentscheidungen treffen musst.

Was müssen wir jetzt schon vorbereiten?

Schritt eins ist banal und wird trotzdem regelmäßig übersehen: prüfe, auf welcher Version dein Connect Sync läuft. Alles unterhalb 2.5.79.0 ist am 30.09.2026 tot. Update auf die aktuelle Version, Health-Check sauber, alle Alerts in Entra Connect Health abgearbeitet. Damit gewinnst du das Recht, überhaupt entspannt in die Migrationsplanung zu gehen.

Schritt zwei: Konfiguration exportieren und versionieren. Connect Sync bringt einen Import/Export-Mechanismus mit, der die komplette Konfiguration als JSON ausspielt. Das Ergebnis gehört in dein Git, nicht auf einen vergessenen Share. Ohne sauberen Export hast du keine Rollback-Option, falls die Migration kippt. Microsoft empfiehlt ausdrücklich, Connect Sync zunächst in den Staging Mode zu schicken und Cloud Sync parallel zu validieren, bevor der finale Swing passiert.

Schritt drei ist die ehrliche Inventur. Wieviele Objekte pro Domain? Wieviele Gruppen über 50.000 Mitgliedern? Welche Sync-Rules sind Standard, welche sind handgeschrieben und warum? Nutzen wir Hybrid Azure AD Join, Cross-Forest-References, Multi-Domain-Attribut-Merging, Reconciliation? Diese Liste ist deine Roadmap. Alles, was rot in der Feature-Matrix steht, braucht eine bewusste Entscheidung — nicht erst, wenn die Microsoft-E-Mail eintrudelt.

Schritt vier ist organisatorisch: definiere die Verantwortlichkeiten. Wer überwacht Message Center und Entra Connect Health? Wer entscheidet, ob eine Exception beantragt wird? Wer hat die Berechtigung im Admin Center, Cloud-Sync-Konfigurationen anzulegen? Hybrid Identity ist erfahrungsgemäß ein Thema, das niemandem so richtig gehört — bis es brennt. Jetzt ist der Moment, dem Thema einen Owner zu geben.

Schritt fünf: rede mit deinem Lizenz- und Auth-Provider-Stack. Wer Federation über ADFS fährt, muss die ADFS-Konfiguration getrennt vom Sync-Tool weiterpflegen. Wer auf PTA und Seamless SSO setzt, kann den klassischen Connect-Sync-Wizard auch nach der Migration weiter als Konfigurations-Frontend behalten. Wer Conditional Access und Compliance-Policies an synchronisierten Attributen hängen hat, sollte vor dem Swing genau prüfen, ob alle relevanten Attribute auch von Cloud Sync transportiert werden.

Letzter Punkt — und der ist mehr Haltung als Technik: nimm Microsoft beim Wort. Die Kommunikation läuft nicht über Pressekonferenzen, sondern über Message Center und Entra Connect Health. Wer diese Kanäle heute nicht systematisch überwacht, wird im Juli 2026 überrascht sein. Wer sie überwacht, hat ein paar Wochen Vorlauf — genug, um die Migration nicht als Brandlösch-Aktion, sondern als geplantes Projekt zu fahren.