Der Umbau auf Entra Cloud Sync ist ein Betriebsprojekt, kein Servertausch

Wer eine hybride Identitätslandschaft betreibt, liest Microsofts Cloud-Sync-Kurs schnell als technische Modernisierung: leichterer Agent, mehr Cloud-Steuerung, weniger eigener Sync-Server. Das ist nicht falsch, aber es greift zu kurz. In der Praxis scheitert ein Wechsel von Entra Connect Sync zu Entra Cloud Sync selten am Installationspaket. Kritisch werden stattdessen Scope, Zuständigkeit, Pilotgrenzen, Feature-Abgleich und die Frage, welches Objekt zu welchem Zeitpunkt genau von welchem Sync-Werkzeug geführt wird. Genau deshalb ist der Umbau kein Servertausch, sondern ein Betriebsprojekt.

Für Leser ohne tiefen Hybrid-Identity-Hintergrund: Microsoft Entra Connect Sync und Microsoft Entra Cloud Sync lösen dieselbe Grundaufgabe, nämlich Benutzer, Gruppen und Kontakte zwischen lokalem Active Directory und Microsoft Entra ID zu synchronisieren. Der Unterschied liegt in der Architektur. Connect Sync arbeitet stärker über einen lokal betriebenen Sync-Server. Cloud Sync verlagert die Orchestrierung in die Cloud und nutzt dafür leichtgewichtige Provisioning-Agents vor Ort. Für IT-Teams klingt das zunächst nach weniger Infrastruktur. Der eigentliche Gewinn oder Schaden entsteht aber erst im Migrationsbetrieb.

Warum Microsoft den Pfad strategisch nach vorn zieht

Microsoft beschreibt Entra Cloud Sync in der aktuellen Learn-Dokumentation ausdrücklich als strategische Richtung für hybride Identität. Dahinter steckt kein Marketing-Satz, sondern ein anderes Betriebsmodell. Die Konfiguration liegt cloudseitig, die Agenten arbeiten als Brücke zum lokalen Active Directory, Updates kommen automatisch, und Microsoft nennt ausdrücklich Mehrwert für mehrere aktive Agenten, automatisches Failover sowie Szenarien mit getrennten oder historisch gewachsenen Forests. Gerade für Unternehmen mit Migrationsdruck, M&A-Konstellationen oder gewachsenen AD-Landschaften ist das relevant, weil Cloud Sync nicht nur einen alten Server ersetzt, sondern einige typische Architekturengpässe der bisherigen Betriebsweise entschärft.

Wichtig ist auch der Takt. Microsoft dokumentiert für Cloud Sync einen eng getakteten, cloudgesteuerten Synchronisationsrhythmus. Das klingt wie ein reines Performance-Detail, verändert operativ aber die Erwartungshaltung. Teams bekommen eine andere Beziehung zu Scoping, Attribut-Mappings, Agent-Status und Testläufen, weil Änderungen schneller und stärker in produktive Abläufe hineinwirken können. Wer das als bloßes Infrastruktur-Upgrade behandelt, übersieht genau den Punkt, an dem Identität vom einmaligen Projekt in einen feineren Regelbetrieb übergeht.

Der zweite große Hebel ist die Mehr-Forest- und Verfügbarkeitslogik. Microsoft hebt hervor, dass Cloud Sync mehrere getrennte Active-Directory-Forests nativ unterstützen und mehrere aktive Agenten parallel für Ausfallsicherheit nutzen kann. Für klassische IT-Management-Sichten ist das mehr als Technik. Es beeinflusst Governance, Verantwortungszuschnitt und Betriebsnachweis. Sobald mehrere Forests, unterschiedliche Eigentümer oder getrennte Standorte im Spiel sind, wird die Identitätsplattform automatisch auch ein Abstimmungsprojekt zwischen Teams.

Die eigentliche Migrationsarbeit liegt beim Scope, nicht beim Agenten

Der schärfste operative Hinweis steht deshalb nicht in einer Hochglanzankündigung, sondern in Microsofts Migrations-FAQ. Connect Sync und Cloud Sync dürfen nicht dieselben Objekte parallel verwalten. Für die Migration empfiehlt Microsoft ausdrücklich OU-basiertes Scoping, damit jede Organisationseinheit immer genau einem Sync-Werkzeug gehört. Das ist der Kern des ganzen Themas. Sobald Teams an dieser Grenze unsauber werden, entstehen Konflikte nicht erst im Reporting, sondern direkt an der Autorität über Benutzer, Gruppen und Attribute.

Genau hier kippen viele Projekte in unnötige Hektik. Der technische Reflex lautet oft: neuen Agenten aufsetzen, Pilot aktivieren, später feinjustieren. Der richtige Betriebsreflex lautet anders: zuerst festlegen, welche OUs als Pilot taugen, welche Objektklassen dort kritisch sind, welche Sonderregeln oder Altlasten existieren und wie ein sauberer Rollback aussieht. Microsoft nennt dazu mehrere vernünftige Schutzmechanismen. Die bestehende Connect-Sync-Umgebung wird während der Migration in den Staging Mode versetzt, Konfigurationen sollen vorab exportiert und gesichert werden, und Konfigurationsänderungen lassen sich zunächst über Pilotwälder oder On-Demand-Provisioning gegen einzelne Benutzer prüfen.

Das Entscheidende daran ist nicht, dass diese Werkzeuge existieren. Entscheidend ist, dass sie einen anderen Projektcharakter erzwingen. Identitätsmigration ist hier kein Blindflug bis zum Go-live, sondern ein kontrollierter Zuständigkeitswechsel mit klaren Grenzen je OU, sauberer Sicherung der Alt-Konfiguration und testbaren Zwischenstufen. Wer diesen Charakter nicht anerkennt, baut sich genau die Art von Problemen, die später als „unerklärliche Sync-Abweichung“ im Service Desk landen.

Feature-Lücken, Sonderfälle und Zuständigkeiten müssen vorher auf den Tisch

Noch ein Punkt wird in Microsofts Dokumentation oft unterschätzt: Nicht jede Umgebung muss sofort migrieren. Die FAQ sagt ausdrücklich, dass Organisationen nicht wechseln müssen, bevor die Funktionen verfügbar sind, auf die sie heute angewiesen sind. Genau das ist ein wichtiger Managementsatz. Er bedeutet, dass ein sauberer Feature-Vergleich vor jedem Wechsel Pflicht ist. Nicht die Roadmap entscheidet über den Zeitpunkt, sondern die reale Abhängigkeit der eigenen Umgebung.

Gleichzeitig weist Microsoft darauf hin, dass unterstützte Konfigurationen übertragen werden können, aber nicht jede Anpassung automatisch gleichwertig landet. Das macht den Feature- und Customization-Check zum Muss. Teams sollten vorab hart benennen, welche Attribute, Writeback-Pfade, Sonderregeln, Filter, Quellen der Autorität und hybriden Randfälle in ihrer Umgebung nicht nur „irgendwie vorhanden“, sondern operativ geschäftskritisch sind. Alles andere ist Schönwetterplanung.

Besonders nützlich ist in diesem Zusammenhang der Hinweis auf hybride Authentifizierungsfunktionen. Microsoft trennt klar zwischen Sync-Werkzeug und Verfahren wie Pass-Through Authentication oder Seamless Single Sign-On. Diese Funktionen bleiben nach der Migration grundsätzlich verfügbar, weil sie separat konfiguriert sind. Das ist wichtig, weil viele Projektteams sonst unbewusst alles in einen Topf werfen und Identität, Authentifizierung und Verzeichnis-Synchronisation als einen monolithischen Wechsel behandeln. Genau dadurch werden Risiken größer als nötig.

Was Teams vor dem ersten Produktionswechsel festziehen sollten

Vor einem echten Umstieg sollten drei Fragen ohne Interpretationsspielraum beantwortet sein. Erstens: Welche OUs und Objektgruppen gehen in den Pilot, und wer bestätigt fachlich, dass genau diese Grenze sauber ist? Zweitens: Welche Funktionen oder Anpassungen sind in der Zielarchitektur heute schon belastbar unterstützt, und welche bleiben vorerst bewusst auf Connect Sync? Drittens: Wie sehen Rollback, Nachweis und Fehlerdiagnose aus, wenn während des Piloten Objekte, Attribute oder Scopes anders laufen als erwartet?

Erst danach lohnt sich der eigentliche Tool-Schritt. Microsofts Cloud-Sync-Modell bringt reale Vorteile: weniger lokale Komplexität, bessere Mehr-Forest-Fähigkeit, cloudseitige Steuerung und eine modernere Agentenlogik. Diese Vorteile materialisieren sich aber nur dort, wo die Betriebsgrenzen vorher sauber gezogen wurden. Wer nur den neuen Agenten installiert, modernisiert die Architektur nicht. Er verlagert die Unklarheit lediglich an eine neue Stelle.

Unterm Strich ist Entra Cloud Sync für viele Hybrid-Identity-Landschaften ein sinnvoller Zielpfad. Die operative Lehre lautet aber: Nicht der Installationsschritt ist das Projekt, sondern der kontrollierte Wechsel der Zuständigkeit pro Objektbereich. Genau deshalb gehört der Umbau in dieselbe Kategorie wie andere kritische Betriebsübergänge: mit Scope-Disziplin, Pilotgrenzen, Rollback, Feature-Abgleich und einer gemeinsamen Wahrheit zwischen AD-, IAM- und Betriebsverantwortlichen.

Quellen

• Microsoft Learn: What is Microsoft Entra Cloud Sync?
• Microsoft Learn: Migrate from Microsoft Entra Connect Sync to Cloud Sync FAQ
• Microsoft Learn: Migrating from Microsoft Entra Connect to Microsoft Entra Cloud Sync
• Microsoft Learn: Migrate from Microsoft Entra Connect to Cloud Sync: Decision Guide
• Microsoft Learn: Microsoft Entra Cloud Sync FAQ