Die Exchange 2019 Hybrid Umgebung wurde bereits mit Teil 4 eingerichtet. Eigentlich wollte ich in diesem Artikel näher auf die Migration Batches eingehen, habe mich aber dagegen entschieden. Die Migration Batches und deren Möglichkeiten sind meistens erst in größeren Umgebungen relevant. Bei kleineren Umgebungen lassen sich die Migration Batches bequem via Exchange Online Admin Center verwalten. Erst wenn es viele Postfächer werden, muss man sich Gedanken um Scripte, Migration Endpoints und CSV Dateien machen.
Ich nehme an, dass die Meisten welche diese Artikelserie lesen, eine überschaubare Anzahl von Postfächern zu Microsoft 365 migrieren wollen. Auch wollen wahrscheinlich die wenigsten dauerhaft eine Hybrid Umgebung betreiben, sondern komplett zu Microsoft 365 migrieren. In diesem letzten Artikel zur Exchange 2019 Hybrid Umgebung geht es daher um Notwendigkeit des „letzten Exchange Servers“ und ein paar Besonderheiten, welche beachtet werden müssen. Es wird dann noch einen weiteren Artikel geben: Exchange 2019 Hybrid zu Cloud Only (also den Abbau der Hybrid Umgebung hin zu Microsoft 365 ohne Exchange Hybrid).
Migration Batches
Mit den Migrations Batches lässt sich die Migration der Postfächer recht gut planen. Zu beachten ist, dass nach dem Verschieben des Postfachs der Benutzer aufgefordert wird, Outlook neu zu starten. Damit Benutzer nicht mitten am Tag durch einen Outlook Neustart belästigt werden, lässt sich der Abschluss der Migration Batches planen und etwa auf das Wochenende verschieben:
Wer eine größere Anzahl Postfächer in einem Migration Batch aufnehmen will, muss nicht jedes Postfach manuell auswählen und hinzufügen. Mittels einer CSV-Datei lassen sich die Postfächer bequem auf verschiedene Batches aufteilen und die Migration der Daten automatisieren.
Mit dem folgenden Befehl lässt sich beispielsweise eine CSV–Datei mit allen Postfächern erzeugen:
1 |
$_
|
Wenn nötig lassen sich auf dem Weg die Postfächer auch beliebig filtern, oder man bearbeitet die CSV-Datei mit einem Editor.
Auch über das Exchange Admin Center lassen sich die CSV Dateien für die Migration Batches erstellen:
Nur das Attribut „E-Mail-Adresse“ ist hier erforderlich:
In der per Exchange Admin Center erstellen CSV muss allerdings die erste Zeile einmal nach „EmailAddress“ geändert werden:
AADConnect und der letzte Exchange Server
Das Thema AADConnect und der letzte Exchange Server ist schon recht alt und sorgt immer noch für Frust. Eigentlich handelt es sich um ein recht banales Problem, welches aber leider immer noch nicht durch Microsoft gelöst wurde (Stand Dezember 2021). Das Problem ist folgendes: Wenn AADConnect zur Synchronisation der lokalen AD Konten zu Azure Active Directory verwendet wird, ist das lokale Active Directory das „führende System“.
Das große Problem
Bestimmte Änderungen an den mittels AAConnect synchronisierten Objekten (beispielswiese Gruppen und Benutzerkonten) müssen im lokalen AD durchgeführt werden und können nicht im Azure Active Directory geändert werden. So ist beispielsweise die Änderung oder das Hinzufügen einer E-Mail Adresse zu einem Postfach nicht in Exchange Online möglich, sondern nur im lokalem AD. Wenn beispielsweise versucht wird eine E-Mail Adresse in Exchange Online zu einem mittels AADConnect synchronisierten Benutzer hinzuzufügen, ist dies nicht möglich und es erscheint die folgende Fehlermeldung:
In diesem Fall muss also die neue E-Mail Adresse für das Postfach am lokalen Exchange Server (bzw. im lokalen AD) hinzugefügt werden:
Das Hinzufügen der Adresse ist eigentlich nur eine Änderung am lokalen AD-Attribut „ProxyAddresses“, diese Änderung wird dann mittels AADConnect zu AzureAD synchronisiert und Exchange Online kann die neue Adresse nutzen.
Die Konsequenz aus dem Problem
Um beispielsweise eine E-Mail Adresse zu einem mittels AADConnect synchronisiertem Benutzerkonto hinzuzufügen, wird ein lokaler Exchange Server als „GUI“ oder „Verwaltungs Exchange Server“ benötigt. Ohne den lokalen Exchange Server fehlt es schlicht an der Möglichkeit via Exchange Management Shell oder Exchange Admin Center eine E-Mail Adresse hinzuzufügen. Auch wenn schon alle Postfächer zu Microsoft 365 migriert wurden, wird also ein letzter Exchange Server zur Verwaltung der Exchange Online Postfächer benötigt, einfach aus dem Grund, weil die Änderung im on-Prem AD stattfinden muss und erst dann vom lokalen AD mittels AADConnet zu AzureAD übertragen wird.
Jetzt könnte man auf die Idee kommen, dann ändere ich doch einfach das Attribut direkt im lokalen AD, ohne Exchange Shell oder Exchange Admin Center. Genau dies wird aber durch Microsoft nicht supported. In der Praxis dürfte dies auch ziemlich umständlich sein, es geht ja schließlich nicht nur um die Mail Adressen, sondern auch noch um viele weitere Einstellungen. Wer weiß schon so genau welches Attribut für welche Einstellung zuständig und wie die genaue Syntax ist?!
Solange also AADConnect im Einsatz ist und lokale AD Konten zu AzureAD synchronisiert werden, braucht es einen einsamen lokalen Exchange Server zur Verwaltung der Einstellungen. Genau dieses Problem ist schon länger (Jahre) bei Microsoft auf der Roadmap, aber imme noch nicht gelöst.
Übrigens: Mit Exchange 2016 brachte der Hybrid Configuration Wizard aus genau diesem Grund eine kostenlose Exchange 2016 Lizenz mit. Bedingung ist: Der lokale Exchange Server darf keine Postfächer mehr speichern, also nur noch der Verwaltung dienen. Dafür wurde aber immerhin keine Exchange Server Lizenz mehr fällig. Mit Exchange 2019 wurde dies wieder geändert: Auch der letzte Exchange Server, der nur noch der Verwaltung dient, muss lizensiert sein. Ein „Einsamer Exchange 2019 Hybrid Verwaltungsserver ohne Postfächer“ benötigt eine Exchange Server Lizenz.
Damit die Verwaltung der Postfächer im Exchange Online Admin Center möglich wird, muss also die Synchronisation der Benutzerkonten via AADConnect aufgegeben werden.
Wie geht es weiter?
Von einer Hybrid Umgebung hin zu „Cloud Only“ ist es nicht mehr weit. Im nächsten Artikel geht es daher um den Rückbau der Hybrid Umgebung, der Abschaltung von AAD Connect und der Deinstallation des letzten Exchange Servers.
Super Artikel, vielen Dank dafür.
Gibt es bereits „Exchange 2019: Einrichtung einer Hybrid Umgebung Teil 6“ -> Rückbau der Hybrid Umgebung und ich habe den nur nicht gefunden?
Nicht gefunden ;-)
https://www.frankysweb.de/exchange-2019-hybrid-zu-cloud-only/
Hallo Frank,
ein weiteres, dickes „Danke schön“ für diese Artikelreihe.
Eine Frage hierzu:
Ich habe ein Szenario, da wird der Mailverkehr des onPrem-Exchange noch über Smarthost & POP-Connector realisiert.
Wenn ich die Hybrid-Umgebung einrichte, würde ich deshalb gerne den Exchange-Online zum Senden & Empfangen nutzen.
Der onPrem soll also im Grunde nur die Mailboxen tragen und für die Konfiguration übers EAC benutzt werden.
Wenn das Routing zwischen den beiden Exchange-Servern funktioniert, dann sollte es doch reichen, wenn ich zum Abschluss
den MX-Record ändere und auf Microsoft zeigen lasse, oder ?!
Oder müssen auch Sende- bzw. Empfangskonnektoren angepasst werden?
Der Autodiscover-Eintrag muss dann natürlich auch aus dem Split-DNS entfernt werden – das ist klar.
Nein, muss er nicht.
Falsch gedacht. ;-)
Hallo Frank,
vielen Dank für Deine Artikel. Ich hab nur eine Frage und zwar wie bekomm ich die Systempostfächer in die Cloud oder brauch ich die nicht mehr?
Hallo Frank,
vielen Dank für die umfangreichen Artikel, auf die ich immer wieder gerne zurückgreife!
Gibt es schon einen Plan, wann die erwähnte Fortsetzung veröffentlich werden soll?
Und gehe ich recht in der Annahme, dass am Ende von Teil 5 auch das Mailrouting mittels MX-Record bereits auf die Cloud gemacht werden kann?
Freue mich auf den nächsten Teil!
Liebe Grüße,
Martin
Hallo Frank,
danke für deine Artikel, die sind immer super!
Würde es gut finden, wenn du einen vielleicht noch einen Artikel zu den folgenden Themen bringen könntest:
1) Bereinigen von bestehenden Exchange 2013/2016 Servern, wenn diese als letzter onPrem bestehen bleiben sollen.
2) Hardening eines reinen Verwaltungsexchange.
Denke es wird vielen so gehen, dass sie nicht unbebingt einen neuen Exchange 2016 aufsetzen wollen, nur zur Verwaltung. Reicht es da nicht aus den 2013 weiterzubetreiben? Dieser ist ja letztlich von extern nicht mehr erreichbar i.d.R. und daher sollten doch keine großen von ihm aus gehen, oder?
Wie würde eine Migration des reinen Verwaltungsexchange von 2013 auf 2016 aussehen? Gibts hier fallstricke zu beachten?
Das wären bestimmt noch super Themen für weitere Artikel zu dieser Serie :)
LG
Hallo Frank,
wie immer eine tolle Artikelserie! Den nächsten Artikel erwarte ich schon mit Spannung :)
Grüße
Jens
Hallo, ich habe 2 Fragen.
Wie ist das mit angebundenen Smartphones die z.B. mit einer Google Mail App (oder Samsung Mail …) am Exchange angebunden sind. Konfigurieren die sich auch automatisch neu oder muss man diese neu für M365 einrichten (z.B. mit der Outlook App)?
Wenn der Kunde noch einen Exchange 2010 hat, muss ich erst auf Exchange 2016 (erst Trail und dann frei lizenziert durch den HCW) migrieren oder kann ich gleich von 2010 zu M365. Und wie installiere ich den Verwaltungsexchange im Nachgang?
Vielen Dank für deine ausführlichen Berichte und HowTo´s
Deswegen lizenziert der HCW nach wie vor einen Exchange 2016 für den letzten Server, wenn er keine Postfächer hält, da die minimal Anforderungen von Exchange 2016 deutlich niedriger sind als 2019 ist das auch in meinen Augen immer noch der beste letzte verbliebende Server.
Da auch das Support Ende von Exchange 2016 und Exchange 2016 auf dem gleichen Tag liegt, ist auch der Exchange 2019 dort nicht im Vorteil, das wird sich wahrscheinlich erst mit Exchange 202X oder vNext in meinen Augen ändern.