Exchange Hybrid: Management Server und Verwaltung
Viele Administratoren befinden sich aktuell in der Situation wieder, den eigenen On-Premises Exchange abzulösen und die bestehende Organisation nach O365 zu migrieren. Dabei gilt es nach Abschluss der Migration einige, wichtige Punkte in Anbetracht der Administration im Hinterkopf zu behalten. Welche das sind und wie man damit am besten umgeht, schauen wir uns in diesem Artikel näher an.
Exchange Hybrid Aufbau
Der grundsätzliche Aufbau dürfte bei allen Administratoren relativ ähnlich aussehen und sich nur in der Größe und Komplexität etwas unterscheiden. Folgende Kernkomponenten sollten allerdings überall vorkommen:
- Lokales Active-Directory
- Azure AD Connect für die Synchronisation zwischen lokalem und Azure-AD
- Exchange (Single-Node oder Cluster)
- Exchange Hybrid Configuration Wizard
Wurden alle Postfächer und Daten vom On-Premises Exchange in die Microsoft Cloud migriert, liegt die Vermutung nahe, dass man den gesamten lokalen Exchange abbauen kann. Die Daten liegen nun ohnehin bei Microsoft und das O365 Exchange Portal bietet alle Möglichkeiten zur Verwaltung – korrekt? Nein! Das liegt an der Art und Weise, wie der Azure AD Sync Attribute synchronisiert und welche Limitierungen dieser aufweist. Doch gehen wir einen Schritt zurück.
Active Directory und seine Attribute
Für all jene, die mit einem Active Directory und den Attributen bereits vertraut sind, können dieses Kapitel getrost überspringen. Für alle anderen gibt es einen kleinen Exkurs.
Das Active Directory speichert unzählige Daten. Nehmen wir als Beispiel einen Benutzer. Dieser hat natürlich einen Vor- und Nachnamen, einen Benutzernamen und vielleicht auch eine Adresse im AD hinterlegt. Neben den hier aufgezählten Attributen gibt es noch hunderte andere, auch jene, die der Benutzer nie zu sehen bekommt. Darunter zum Beispiel der letzte Anmeldeversuch, wann das Passwort geändert wurde oder der Timestamp, an dem der Administrator das AD-Konto angelegt hat. All diese Informationen müssen irgendwie innerhalb der Domäne auf einem Domain Controller abgebildet werden. Und genau dafür sind die Attribute zuständig. Dabei bringt das Active Directory einen Standardsatz an Attributen mit, die ein AD-Objekt besitzen kann – das AD-Schema. Dieses Schema ist sozusagen die Vorlage für die möglichen Attribute eines bestimmten AD-Objekt (Benutzer, Kontakt, Gruppe, …).
Betreibt man nun innerhalb der Domäne einen Exchange, so wird dieses AD-Schema mit hunderten weiteren Exchange-abhängigen Attributen erweitert. Denn plötzlich muss das Active Directory auch Bescheid wissen, in welcher Datenbank der Benutzer sein Postfach hat, welche Mailbox-Limitierungen hinterlegt wurden und welche anderen Postfächer via Auto-Mapping eingebunden werden müssen. Diese Liste lässt sich nun noch seitenweise fortführen aber ich denke, ihr wisst, was damit gemeint ist. Diese Exchange-abhängigen Attribute besitzen den Prefix „msExch“ und werden automatisch hinzugefügt, sobald man einen Exchange installiert.
Soweit so gut aber was hat das mit O365 zu tun?
Azure AD Sync
Der Azure AD Connect Client hat die Aufgabe, den Datenstand von dem lokalen Active Directory mit jenem aus dem Azure AD synchron zu halten. Doch hier gibt es einige Limitierungen, die uns das Leben erschweren. Azure AD Connect ist nämlich nicht dazu in der Lage, viele der Exchange-abhängigen Attribute aus dem Azure AD in das lokale AD zu übernehmen. Das bedeutet: Setzt man das Attribut XY im Azure AD, so wird es zwar dort korrekt übernommen, euer lokales Active Directory bekommt diese Änderung allerdings nicht mit. Zwangsläufig werden damit zwei unterschiedliche Datenstände entstehen. Je nachdem, wie viele Änderungen gesetzt wurden, ist es nach Wochen, Monaten oder gar Jahren unglaublich schwierig und zeitaufwändig diese Unterschiede nachzuvollziehen und manuell im lokalen AD nachzutragen.
Zum besseren Verständnis ein kleines Beispiel: Ihr legt einen Benutzer im lokalen AD an, dieser wird ins Azure AD übertragen. Nun aktiviert ihr für diesen Benutzer über das O365 Portal ein Postfach. Das Postfach wird in Exchange Online korrekt angelegt. Euer lokales AD wird aber nie darüber informiert. Euer AD geht nun nach wie vor davon aus, dass kein Postfach für diesen Benutzer existiert. Als Endnutzer wird man gar kein Problem feststellen können und genau das ist das Problem. Auf den ersten Blick scheint alles korrekt zu funktionieren. In Wirklichkeit haben wir damit aber schon zwei unterschiedliche Datenstände geschaffen.
Ein weiteres Beispiel: Es existiert ein Benutzerpostfach mit dem Namen „Service“. Es wurde korrekt angelegt, beide ADs kennen das Postfach und den dazugehörigen Benutzer. Nun möchte ich das „Service“ Postfach in eine Shared-Mailbox umwandeln. Theoretisch bietet das Exchange Online Portal eine einfache Schnittstelle um das umzusetzen.
Würde man nun das Postfach über diese Weise umwandeln, wäre die Änderung zwar wieder dem Azure AD bekannt, das lokale Active Directory wird darüber aber wieder nicht informiert.
Da das Active Directory die Kernkomponente einer jeden Unternehmensinfrastruktur darstellt, sollte das lokale AD immer der „Single Point of Truth“ sein, sozusagen der heilige Gral. Doch dadurch, dass wir einen unternehmenskritischen Service wie Exchange in die Microsoft Cloud ausgelagert haben, müssen wir sicherstellen, dass der Azure AD Datensatz mit jenem aus unserem lokalen AD übereinstimmt.
Exchange Management Server
Wie setzt man nun solche Änderungen korrekt um? Dabei kommt der Exchange Management Server ins Spiel. Wurden alle Postfächer nach O365 migriert, kann der On-Premises Exchange (sei es Cluster oder Single Node) auf einen Exchange Management Server zurück gebaut werden. Dieser Server dient als reine Verwaltungskonsole für die Exchange Online Postfächer und bildet die Schnittstelle zwischen lokalem und Azure AD.
Bei dem Exchange Management Server handelt es sich um eine minimal Installation mit folgenden Spezifikationen:
- Windows Server 2019 oder 2022
- Exchange 2019 (kostenlose Lizenz von Microsoft)
- CPU: 2 Cores
- RAM: 10GB
- Disk: 100GB
Wie du siehst, ist das eine relativ „kleine“ VM – kann aber notfalls auch auf einem bestehenden Domain Controller installiert werden (nicht empfehlenswert). Die Exchange 2019 Lizenz wird von Microsoft kostenlos zur Verfügung gestellt.
Alle Änderungen, die wir normalerweise über das Exchange Online Portal vollziehen würden, müssen wir nun über den Management Server erledigen. Dabei ist es egal, ob wir diese mittels Exchange Management Shell oder dem Exchange Control Panel umsetzen. Hierbei wird gewährleistet, dass alle Exchange-abhängigen Attributsänderungen zuerst im lokalen AD gesetzt und anschließend ins Azure AD übertragen werden. Somit haben wir auch sichergestellt, dass unsere lokale Domäne weiterhin der „Single Point of Truth“ bleibt und wir nicht in die Gefahr laufen, zwei unterschiedliche Datenstände zu provozieren.
Wie so oft in der IT gibt es aber auch hier kleinere Einschränkungen. Nicht alle Einstellungen können über das lokale ECP gesetzt werden. Möchte man beispielsweise die Vollzugriff Berechtigung auf ein Postfach vergeben, so muss man diese leider im Exchange Online Portal setzen. Ich möchte aber auf die gängigsten Parameter in den nächsten Artikeln näher eingehen.
Folgenden Merksatz sollte man meiner Meinung nach immer im Hinterkopf behalten: Jede Änderung muss über das lokale ECP (oder Powershell) passieren, außer es gibt keine Schnittstelle dafür. Erst dann darf auf das Exchange Online Portal ausgewichen werden.
Weiterführende Artikel zu diesem Thema:
