Exchange Hybrid - Eine saubere Lösung (2/2)

Im ersten Teil dieses Zweiteilers bin ich auf die generellen Vorteile eines Hybrid-Betriebes eingegangen.

Der Schwerpunkt dieses Beitrages wird nun etwas technischer und soll einen Überblick darüber geben, wie das ganze Hybrid-Konstrukt zusammenhängt. Ich setze an dieser Stelle voraus, dass bereits eine Verzeichnissynchronisierung via AD Connect erfolgt und im Office 365 eine passende Lizensierung vorhanden ist (mind. Exchange Online Plan 1). Außerdem sollten die Exchange Web Services (Autodiscover, EWS, OWA usw.) extern erreichbar sein (z.B. über einen Web Application Proxy abgesichert). Die Bereitschaft dieser Dienste könnt ihr einfach mit dem Remote Connectivity Analyzer von Microsoft testen (Link). Außerdem benötigt ihr ein SSL-Zertifikat (Wildcard oder SAN) für die Absicherung des Hybrid-Betriebes.

Exchange Hybrid - Eine saubere Lösung (1/2)

Der klassische Workload, den ein Unternehmen in die Cloud verlagert, ist oft das E-Mail-System. Server vor Ort kosten Geld, Ressourcen, Wartungsaufwand und Know-How. Bei Exchange Online sorgt Microsoft dafür, dass genügend Kapazitäten vorhanden sind und das System insgesamt skaliert, wenn ein Wachstum stattfindet. Plump ausgedrückt: „Ich habe 500 Benutzer, die auf einem Exchange Online Server arbeiten. Wenn ich nun über Nacht weitere 500 Leute einstelle, muss ich mir keine Gedanken machen — Microsoft stellt einfach einen weiteren Server daneben und ich bemerke davon gar nichts.“ Ganz so ist es natürlich nicht, aber bezogen auf ein selbst betriebenes Rechenzentrum ist der Vergleich durchaus erlaubt.

Die Wahl der richtigen Lizensierung

Spätestens nach Ablauf der Testlizenzen (max. 30 + 60 Tage) steht der Office 365-Admin vor der Entscheidung, über welche Quelle die User lizensiert werden sollen.

Microsoft bedient in der O365-Lizensierung eigentlich alle klassischen Lizensierungswege: egal ob Enterprise Agreement, Open-Vertrag oder klassische Subscription — alles ist möglich und die verschiedenen Bezugsarten sind beliebig miteinander kombinierbar. In letzter Zeit macht der Begriff „CSP“ im IT-Umfeld die Runde — daher möchte ich hier mal kurz skizzieren, was dahinter steckt und welche Vorteile das Modell bietet.

Vorbereitung der UPNs für die Synchronisation

Ob im Rahmen einer Office 365-Testphase oder durch bevorstehende Migration: irgendwann müsst ihr euch Gedanken machen, wie sich die Benutzer zukünftig in der Cloud anmelden sollen. Die Vorteile von AD Connect oder ADFS habe ich ja bereits kurz erklärt. Bei sehr kleinen Umgebungen kann man sicherlich darüber nachdenken, ob man die Synchronisation nicht ganz auslässt. Wenn kein Active Directory betrieben wird, macht es ja sowieso keinen Sinn erst ein Active Directory einzurichten. Doch mit Active Directory werden sowohl bei AD Connect als auch bei ADFS die Benutzerkonten aus dem Active Directory exportiert und ins Azure AD synchronisiert. Es gilt also festzulegen, mit welchem Anmeldenamen sich die Benutzer an den Office 365-Diensten authentifizieren werden.

Synchronisationslogik bei der Postfachmigration

Bei einer Migration von einem anderen E-Mail-System (Exchange On-Prem, IMAP, etc.) zu Exchange Online ist es für Administratoren sehr einfach, bestehende Postfach-Daten (Mail, Kontakte, Kalender) zu migrieren. Der Wunsch nach einem „Neuanfang“ ist relativ selten. Bei der Datenübernahme gibt es natürlich den klassischen „Turnschuh“-Ansatz (Export in PST-Datei und Einbindung der PST-Datei im neuen Postfach), aber komfortabel ist das natürlich nicht.

Im Exchange Admin Center von Office 365 gibt es die Möglichkeit sogenannte Migrations-Batches anzulegen. Dabei unterscheidet sich die Art des Batches immer je nach Migrationsszenario. Bei Exchange Hybrid geht man über den MRS (Mailbox Replication Service) an den lokalen Exchange ran — aber auch die Migration von einem IMAP-Server ist möglich. Oft entsteht dabei die Frage, wie die Synchronisierung arbeitet und die Logik dahinter funktioniert.

Mobile Menu