Moderne Exchange-Hybridtopologie nachträglich einsetzen

Dieser Artikel beschreibt das Vorgehen, wie eine bestehende klassische Exchange-Hybridtopologie durch die moderne Exchange-Hybridtopologie abgelöst werden kann.

Moderne Exchange-Hybridtopologie
Hybrid Configuration Wizard

Auf der Microsoft Ignite 2018 wurde dieser neue, moderne Ansatz vorgestellt. Bei der klassischen Exchange-Hybridtopologie mussten die lokalen Exchange WebServices veröffentlicht werden. Das war erfahrungsgemäß öfters ein Problem, weil die WebServices gar nicht veröffentlich waren. Sicherheitstechnisch ist das auch ganz sicher ein komplexes Thema. Deshalb wurde die moderne Exchange-Hybridtopologie von Microsoft eingeführt, um diese Veröffentlichung zu vereinfachen. Bei der modernen Variante wird für die Veröffentlichung der WebServices ein Azure AD Application Proxy (Hybrid Agent) genutzt. Das ist jetzt nicht neu und konnte auch bereits schon vorher genutzt werden um lokalen Anwendungen zu veröffentlichen (Dazu habe ich auch schon einen Beitrag geschrieben).

Und genau diese Vereinfachung (man benötigt keine zusätzliche Infrastruktur um den Zugriff von Extern abzusichern) führt dazu, dass man gerne die moderne Exchange-Hybridtopologie nutzen möchte, anstatt den klassischen Ansatz.

Allerdings gibt es einige Dinge zu Berücksichtigen, wenn die Umstellung funktionieren soll. Zuerst hat die Nutzung des Hybrid Agents einige generelle Einschränkungen. Diese sind bei Microsoft dokumentiert.

Die Konfiguration von Exchange Hybrid und der Topologie erfolgt wie gewohnt über den Hybrid Configuration Wizard (HCW). Wenn allerdings bereits eine klassische Exchange-Hybridtopologie konfiguriert ist, kann es passieren, dass die Auswahl der Topologie überhaupt nicht erscheint und nur die Konfiguration der klassischen Topologie angepasst werden kann.

Moderne Exchange-Hybridtopologie
Hybrid Topologie Auswahlmöglichkeit erscheint nicht

Damit die Topologie geändert werden kann, dürfen laut Microsoft keine alten Migrationsbatches mehr vorhanden sein. Das macht natürlich Sinn, weil diese alten Migrationsbatches den bisherigen Migrationsendpunkt genutzt haben, den wir jetzt ersetzen möchten. Das Aufräumen der alten Migrationsbatches geht ganz einfach über das Exchange Online admin center.

Prüfen auf alte Migrationsbatches

Allerdings hat es danach bei mir leider immer noch nicht funktioniert und ich konnte nur die bestehende Konfiguration anpassen. Zum Glück hat der HCW ein ganz akzeptables Logging, was unter %UserProfile%\AppData\Roaming\Microsoft\Exchange Hybrid Configuration zu finden ist. Dort ist dann folgende Zeile aufgefallen.

[Client=UX, Thread=1] Hybrid Connector Availability: False, Reason: Previous Migration Endpoint found with standard on-premises configuration.
Log Datei vom HCW

Anscheinend hat der HCW ein Problem mit dem bereits bestehenden Migrationsendpunkt von der klassischen Exchange-Hybridtopologie. Den Migrationsendpunkt können wir über die Exchange Management Shell ganz einfach in unserem lokalen Exchange und in Exchange Online löschen.

Get-MigrationEndpoint | Remove-MigrationEndpoint

Hier auch noch ein Bild, wo zuerst der bestehende Migrationsendpunkt gelöscht wird, dann der HCW mit der modernen Topologie ausgeführt wird und dann der neue Migrationsendpunkt angezeigt wird. Hier kann man den Unterschied zwischen den beiden Topologien recht einfach erkennen.

Moderne Exchange-Hybridtopologie
Exchange Management Shell

Nach dem Löschen war es dann ganz einfach möglich, die moderne Exchange-Hybridtopologie im HCW auszuwählen und zu konfigurieren.

Ich hoffe, ich konnte euch ein paar Stolpersteine aus dem Weg räumen, wenn ihr versucht die Exchange-Hybridtopologie zu ändern.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert