Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Zielsetzung

Migration der Windows Server und der Exchange Server
Meine Infrastruktur soll auf Windows Server 2019 aktualisiert werden. In diesem Abschnitt der Umstellung sind meine beiden Exchange Server 2016 dran. Beide laufen als virtuelle Maschine auf je einem Hyper-V-Host.

Mit Windows Server 2019 als Betriebssystem kann ich gleichzeitig auf Exchange Server 2019 migrieren.

Die Migration wird durch ein Wipe & Load je Server durchgeführt. Dabei deinstalliere ich jeweils einen Exchange Server, entferne das alte Betriebssystem, installiere einen neuen Windows Server 2019 und installiere darauf den neuen Exchange Server.

Wichtig ist mir dabei, dass der Mailservice ohne Unterbrechung weiterläuft. Die fehlende Hochverfügbarkeit während der Umstellung kann ich akzeptieren.

Der Mailservice
Beide Mailserver stellen meine Mailboxen mit insgesamt 4 Datenbanken zur Verfügung. Jeder der Server hält eine Kopie der 4 Datenbanken in einer Datenbankverfügbarkeitsgruppe (DAG). Der für diesen Cluster erforderliche Zeugenserver ist mein WS-FS3. Dieser steht im Außenstandort.

Die Clients greifen intern wie extern über den Namespace email.ws-its.de zu. Beide Mailserver verwenden dafür ein externes Webserver-Zertifikat. Der Zugriff wird über einen Loadbalancer gesteuert. Dieser läuft auf meinen beiden virtuellen PFSense-Servern mit dem Service HAProxy. Beide PFSense-Systeme bilden einen Cluster.

Durch den HAProxy werden auch externe Mails an meine beiden Mailserver zugestellt.

Das ist meine Mailserver-Infrastruktur:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Den Loadbalancer erkennt man in dieser Grafik besser:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der Mailserver WS-MX2 hat Probleme mit der Datenbank-Bereitstellung. Daher werde ich diesen zuerst neu installieren.

Vorbereitung

Berechtigung
Ich verwende in meiner Infrastruktur ein Tier-Modell für die Administration und zusätzlich eine zeitliche Begrenzung von Gruppenmitgliedschaften. Gesteuert werden diese durch meine eigene PAM-Scriptlösung (Privileged Access Management). Ich weise meinem Account für die Server-Administration (T1) die erforderlichen Gruppenmitgliedschaften zu:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Aufbau der neuen VM
Mit diesen Rechten ausgestattet melde ich mich an meinem Hyper-V-Host an, auf dem der aktuelle WS-MX2 läuft. Hier erstelle ich eine neue virtuelle Maschine. Die Festplatte lasse ich weg:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Den Server habe ich bereits mit dem neuen Namen erstellt. Damit passt dann auch der Pfad im Hyper-V-Volume. Damit es später keine Verwechslung gibt, ändere ich den Anzeigenamen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Jetzt kopiere ich meine Basefile in das Verzeichnis der neuen VM. Darin ist ein installierter und (einigermaßen) aktueller Windows Server 2019 mit grafischer Oberfläche installiert. Das Betriebssystem hatte ich mit sysprep zurückgesetzt und generalisiert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Jetzt binde ich die kopierte VHDX-Datei in die neue VM ein. Zusätzlich ändere ich noch ein paar andere Parameter wie die Anzahl der CPU-Kerne und die Integrationsdienste. Auch die Firmware-Starteinstellung wird modifiziert. Das geht aber erst nach dem Einbau der VHDX:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Bereitstellung des neuen Betriebssystems
Im nächsten Schritt starte ich die VM. Das Betriebssystem führt die Out-Of-Box-Experience (OOBE) aus und startet die Einrichtung:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Danach kann ich mich auch schon anmelden. Weiter geht es mit den Windows Updates. Damit der Server an den Windows Update Server im Internet kommt, hänge ich ihn fix in ein freigeschaltetes Netzwerk. Und dann geht es auch schon los:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Sammlung von Informationen und Elementen im alten Server
Die Aktualisierung des neuen Servers wird einige Minuten dauern. Währenddessen prüfe ich, ob es auf dem alten WS-MX2 noch brauchbare Dateien und Konfigurationen gibt: Dazu zählen auch geplante Aufgaben. Diese exportiere ich als XML-Dateien:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Weitere Dateien lege ich üblicherweise unter C:\Admin ab. Auch diese werden in ein Netzlaufwerk kopiert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Meine Exchange Server laufen aktuell nicht fehlerfrei. Hier sind meine 4 Datenbanken sichtbar. Die DB-System hat auf dem Server WS-MX2 Probleme mit dem Suchindex. Dadurch kann ich die Datenbank nicht auf WS-MX2 bereitstellen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

In meinem Monitoring ist das ebenfalls als Problem sichtbar:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Für die Neuinstallation ist es auch immer interessant, welche Anwendungen auf dem alten Server installiert waren. Viel ist es nicht, da der Server nur für Exchange verwendet wird:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Die installierten Rollen und Features lese ich fix mit der Powershell aus:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Im DNS ist erkennbar, wie ich für interne Clients die interne Adresse auf den LoadBalancer konfiguriert habe: Es existiert dafür eine eigene DNS-Zone für den externen Namespace:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Früher verwendete ich dafür den zusätzlichen Namespace email.ws.its, dessen Konfiguration einfache HOST-A-Records in meiner Domain-Zone sind:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Mehr ist auf meinem Server WS-MX2 nicht zu finden.

Maintenance vorbereiten
Bevor ich die Deinstallation starte, halte ich die Sensoren des Servers in meinem PRTG-Monitoring an:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Ebenso kontrolliere ich noch den aktuellen Sicherungsstatus meiner Datenbanken. Diese werden von einem System Center Data Protection Manager 2019 (DPM) gesichert. Hier ist alles gut:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

In meiner PFSense starte ich im Modul HAProxy die Maintenance für HTTPS und SMTP für den Server WS-MX2:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Die Maintenance wird über das Backend eingestellt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Nach wenigen Sekunden schwenken die Verbindungen der Clients auf den Server WS-MX1:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Es kann losgehen.

Entfernung der alten Exchange-Installation

Bereinigungen in der Rolle MBS
Alle Schritte der Migration des Exchange Servers habe ich mit einem PowerShell-Script vorbereitet. In diesem Abschnitt baue ich die Konfigurationen der Rolle Mailboxserver zurück.

Zuerst verbinde ich meine PowerShell-ISE mit dem Exchange Server:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Jetzt verschiebe ich die 2 noch aktiven Datenbanken auf den Server WS-MX1:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Nachdem nun alle 4 Datenbanken vom Server WS-MX1 bereitgestellt werden kann ich die 4 Datenbankkopien vom Server WS-MX2 entfernen. Jede Aktion wird manuell bestätigt

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der Befehl kann die Datenbank-Dateien im Dateisystem nicht löschen. Daher erhalte ich für jede entfernte Kopie eine Warnung. Diese kann ich ignorieren, da auch die virtuelle Festplatte darunter später entfernt wird:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Ein letzter Blick im Exchange Control Panel zeigt, dass alle Datenbanken ausschließlich auf Server WS-MX1 laufen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Beide Mailserver laufen in einer Datenbankverfügbarkeitsgruppe. Ich entferne den Server WS-MX2 als Mitglied:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Als Ergebnis wird mir eine Warnung angezeigt. Das ist nicht normal:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Daher kontrolliere ich mit dem Failovercluster-Manager die Lage. Der Server wird nicht mehr als Clusterknoten aufgeführt. Es sollte also kein Problem sein:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der Server WS-MX2 ist damit kein Mailboxserver mehr.

Bereinigungen in der Rolle HTS
Weiter geht es mit der Rolle Hub-Transport-Service – also dem Nachrichtenfluss. Beide Server dürfen Mails ins Internet senden. Dafür verwenden sie einen Sende-Konnektor. Mit Set-SendConnector entferne ich den Server WS-MX2. Jetzt darf nur noch Server WS-MX1 Mails versenden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Die Receive-Konnektoren werden bei der Deinstallation automatisch entfernt, da sie serverbezogen sind. Hier sichere ich nur die aktuelle Konfiguration in einer Textdatei:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Damit ist auch die Rolle HTS für die Deinstallation vorbereitet. Die Client-Access-Rolle (CAS) ist ebenfalls serverbezogen und kann durch eine einfache Deinstallation des Exchange Servers entfernt werden.

Deinstallation des Exchange Servers – Problem: Reste des Failover Clusters
Es kann also mit der Entfernung der Installation weitergehen. Hier hilft die alte Systemsteuerung:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der Assistent startet:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Vor der Deinstallation wird eine Bereitschaftsprüfung ausgeführt. Diese zeigt aber einen seltsamen Fehler an:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Offensichtlich hat die Entfernung der DAG-Mitgliedschaft (diese wurde ja mit einer Warnung abgeschlossen) nicht funktioniert. Ich öffne erneut den Failovercluster-Manager und prüfe die Cluster-Events. Hier wurde der Server ausgetragen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Vielleicht hilft ein Neustart? Normalerweise ist das nicht erforderlich, aber ich versuche es einfach mal. Doch auch der zweite Versuch der Deinstallation scheitert. Dank meines Screenshots von vorhin kann ich mir die Warnmeldung noch einmal genauer ansehen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Es gibt eine Nacharbeit. Cluster.exe existiert aber nicht mehr. Daher verwende ich das PowerShell-Cmdlet für die Bereinigung. Leider hat auch dieser Befehl nur eine Fehlermeldung als Ergebnis. Das Cmdlet benötigt einen Kontakt zum Clusterdienst. Doch dieser wurde bereits beendet:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Und dann kommt mir eine Idee: Bis Windows Server 2019 konnte für die Authentifizierung in einem Cluster ausschließlich NTLM verwendet werden. Doch genau dieses alte Protokoll wird explizit für Mitglieder der AD-Gruppe „Protected Users“ abgeschaltet. Und genau in dieser Gruppe ist meine administrative T1-Kennung dauerhaftes Mitglied:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Also präpariere ich einen „ungeschützten“ Account mit den sonst erforderlichen Rechten:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Mit dieser Kennung starte ich eine PowerShell-ISE und versuche die Entfernung:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Aber auch hier muss der Cluster-Dienst gestartet sein. Also versuche ich die DAG-Mitgliedschaftsentfernung mit der Kennung meines Admin-Setup. Nur dieser Teil hatte ja schon funktioniert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

So macht das keinen Spass. Ich prüfe meine Möglichkeiten in der Webseite des Exchange Admin Centers. Hier wird der Server WS-MX2 sogar noch als Member der DAG gelistet. Daher versuche ich hier eine Entfernung. Die Fehlermeldung ist anders – das Ergebnis bleibt gleich:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der Cluster-Dienst selber wird sich nicht mehr starten lassen. Ich versuche es trotzdem einmal. Das wird aber leider auch nichts:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Langsam gehen mir die Möglichkeiten aus. Es wird Zeit für einen Rollback. Der Cluster speichert seine Konfiguration in dem Verzeichnis c:\Windows\Cluster:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Diese Dateien stelle ich aus einer SystemState-Sicherung wieder her. Jeder Server sichert bei mir seine Betriebssystem-Partitionen mit der Windows Server Sicherung auf ein Netzlaufwerk. Hier liegen also die Sicherungsdateien. Dies sind normale VHDX-Dateien, die sich mit dem Windows Explorer bereitstellen lassen. Ich mounte die passende VHDX auf meinem Sicherungsserver:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Ggf. müssen die Laufwerksbuchstaben angepasst werden. Hier hilft die Datenträgerverwaltung:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Die Dateien unter S:\. sind wieder von heute Morgen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Vor der Wiederherstellung sichere ich noch die aktuelle Datenbank in ein lokales Verzeichnis:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Dann stelle ich die Dateien wieder her. Da mein Exchange Server keinen direkten Zugriff auf meinen Sicherungsserver hat, stelle ich die Dateien über ein Austausch-Netzlaufwerk bereit:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der Cluster-Dienst lässt sich leider immer noch nicht starten:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Daher versuche ich es jetzt mit einer Deinstallation des Features „Failover-Cluster“:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Interessanterweise hat die Entfernung funktioniert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Es ist für den Abschluss ein Neustart erforderlich.

Deinstallation des Exchange Servers – Problem: Memory Leak
Ich versuche erneut mit der Deinstallation:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Wieder startet der Assistent und sucht nach verbliebenen Abhängigkeiten. Das Entfernen des Clusters hat funktioniert! Die Deinstallation kann gestartet werden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Leider ist die Freude von sehr kurzer Dauer. Das System hat keinen ausreichenden Arbeitsspeicher:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Eigentlich ist der Server mit 14GB RAM ausgestattet und hat keine Last mehr. Das sollte doch genügen. Wo also wird der Arbeitsspeicher verbraucht? Ha: das Setup selber belegt 10GB!!!

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Deinstallation des Exchange Servers – mit Erfolg
Ich nutze aber die Gelegenheit der gescheiterten Deinstallation und erweitere die Berechtigungen meines administrativen Accounts. Diese hatte ich zuvor vergessen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Nach einer Neuanmeldung probiere ich es erneut. Dieses Mal läuft das Setup weiter. Der Prozess selber bindet wieder innerhalb von Sekunden fast den gesamten Arbeitsspeicher:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Die Meldung vom Betriebssystem lässt nicht lange auf sich warten. Aber das Setup läuft weiter und gibt auf einen Schlag den Arbeitsspeicher wieder frei. Was soll man davon halten…

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Jetzt kommt die Deinstallation voran:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Nach einigen Minuten ist der Vorgang abgeschlossen. Ein Neustart steht aus:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Während der Server WS-MX2 neustartet, kontrolliere ich im Exchange Admin Center die Lage. Der Server wird nicht länger angezeigt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Nachdem der Server seinen Neustart abgeschlossen hat, archiviere ich die Logfiles des Setups. Falls doch etwas schief gelaufen ist, kann ich hier im Nachgang den Fehler suchen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Das Logfile-Archiv verschiebe ich in meine administrative Freigabe:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Jetzt ist auf dem Server WS-MX2 nichts mehr vorhanden.

Entfernung des alten Servers und Austausch der VM
Ich fahre den Server herunter und entferne ihn im Hyper-V. Dazu lösche ich die virtuellen Festplatten-Dateien…

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

… ebenso wie die virtuelle Maschine selber:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der Name WS-MX2 ist nun frei. Daher benenne ich die vorbereitete virtuelle Maschine um:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der neue Server erhält weitere Ressourcen. 16GB, 8 vCPU und eine neue virtuelle Festplatte für die Datenbanken kommen dazu:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Bereitstellung des neuen Mailservers (MX2019)

Grundkonfiguration des Betriebssystems
Ich starte die neue VM. Zuerst benenne ich den Server um. Den Namen WS-MX2 verwende ich weiter:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Wie üblich ist ein Neustart erforderlich. Während dieser Zeit bereite ich das Active Directory Computerkonto für die Übernahme vor:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Wieder angemeldet passe ich die IPv4-Konfiguration an. Auch die IP-Adresse 192.168.100.13/24 verwende ich wieder. So spare ich mir die Anpassungen in der Firewall und im LoadBalancer:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Für den Domain Join bereite ich einen Account vor:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

15 Minuten sind dafür mehr als ausreichend. Ich nehme den neuen Server in die Domain auf. Dabei übernimmt er das Computerkonto und somit die Identität des alten Mailservers:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Nach einem weiteren Neustart werden die Gruppenrichtlinien angewendet. Ich starte noch einmal ein Windows Update. Dieses Mal kommen die Daten von meinem WSUS:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Durch die manuelle Aktivierung der Aktualisierung meldet sich der Server im WSUS:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Interessanterweise werden Updates auf dem WSUS gefunden. Eigentlich war ja schon alles installiert. Aber ok – dann installiere ich diese eben noch einmal:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Während der Aktualisierung kümmere ich mich um die neue Festplatte. Darauf erstelle ich eine neue Partition. Zuerst muss sie aber aktiviert werden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Das neue Volume kann einfach mit dem Server-Manager erstellt werden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Als Dateisystem verwende ich das von Microsoft für Exchange Server 2016+ empfohlende ReFS. Meine Datensicherung ist damit kompatibel:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Jetzt installiere ich noch ein paar Rollen und Features, die nicht zwingend zum Exchange Server gehören. Mit System Insights kann ich den Trend der Serverbelastung später mit dem Windows Admin Center überwachen. Und die Windows Server Sicherung soll später für die Datensicherung des SystemStates verwendet werden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Die Rollen- und Feature-Installation und die Windows Updates erfordern einen Neustart:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Für den Zugriff auf das neue Volume erstelle ich im Active Directory zwei neue Gruppen GG-Admin-MX-Storage und LD-Admin-MX-Storage. Die GG ist in der LD als Mitglied verschachtelt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Auf dem neuen Volume ändere ich die Stammberechtigung ab. Damit ist ein einfacher Zugriff auf das Volume nicht mehr möglich:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Diese Konfiguration ist für mein Rollenzugriffs-Konzept gedacht. So kann ich später den Zugriff auf die Datenbank-Partition explizit delegieren.

Einrichtung der Datensicherung (BMR mit Windows Server Sicherung)
Bevor der Server in die produktive Phase geht konfiguriere ich die Serversicherung. Diese ist wie bei meinen anderen Servern auch auf 2 Strategien aufgebaut: Das Betriebssystem ziehe ich als SystemImage mit der Windows Server Sicherung ab. Nutzdaten – wie Datenbanken – sichere ich mit dem Data Protection Manager. Hier konfiguriere ich die Serversicherung. Diese wird durch eine geplante Aufgabe gestartet. Als XML-Datei kann ich sie recht einfach importieren:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Der Sicherungstask wird mit einem Group Managed Service Account (gMSA) ausgeführt. Beim Speichern der Aufgabe habe ich einen Dummy-Account eingetragen, da ich das Passwort des gMSA nicht kenne – die Server holen sich diese Information geschützt vom Domain Controller. Aber ohne Passwort kann ich den Task nicht speichern:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Mit meiner PowerShell-GUI „gMSA-Admin“ konfiguriere ich nun den Sicherungstask remote vom Domain Controller aus neu:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Bevor ich mit der Installation beginne, starte ich die Datensicherung:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Sie dauert nur wenige Minuten. Mit dieser Sicherung kann ich ein Rollback durchführen, wenn bei der Installation vom Exchange Server etwas schief läuft.

Vorbereitung des AD für Exchange Servers 2019 CU4
Auf WS-MX2 installiere ich den ersten Exchange Server 2019 mit dem kumulativen Update 4. Dabei ist im Normalfall immer eine Vorbereitung des Active Directory erforderlich. Also statte ich meinen administrativen Account temporär mit den richtigen Gruppenmitgliedschaften aus. Jetzt ist er Mitglied in den Gruppen „Schema-Admins“ und „Organisations-Admins“ (engl. „Enterprise-Admins“):

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Die Aktualisierung des Active Directory starte ich direkt vom zukünftigen Exchange Server WS-MX2 aus. Dafür werden die RSAT-Features für das Active Directory erforderlich. Diese installiere ich mit der PowerShell:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Eine weitere Voraussetzung ist das aktuelle .net-Framework 4.8. Dieses ist selbst auf einem Windows Server 2019 nicht standardmäßig installiert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Mit einem Offline-Installer ist das aber schnell nachgeholt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Nach dem Setup prüfe ich wieder mit Windows Updates auf Aktualisierungen. Natürlich wird auch hier etwas gefunden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Das Setup und das Update beende ich mit einem Neustart. Jetzt passt die installierte Version:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 1/2

Ich möchte die Vorbereitung des Active Directory losgelöst vom Exchange Server Setup durchführen. Das bietet sich immer an, wenn man mehr als einen Domain Controller verwendet. Anderenfalls könnte die Aktualisierung auf einem DC1 angewendet werden, das Setup aber mit dem DC2 fortfahren. Die Replikation der beiden Domain Controller ist aber keine Echtzeit. Und gerade nach Schema-Veränderungen wird sie zusätzlich verzögert. Das Setup des neuen Exchange Servers kann so in einen Fehler laufen. Das will ich gerne vermeiden. Daher starte ich die Aktualisierung meiner Domain und warte dann auf die Replikation der Domain Controller.

Die Aktualisierung wird mit dem Installations-ISO und dem Aufruf der darin enthaltenen setup.exe durchgeführt. Ich starte den Befehl auf dem neuen Exchange Server.

Praxistipp: In Kundenumgebungen würde ich Aktualisierungen am Schema des Active Directory immer nur an einem Domain Controller selbst durchführen. Fehler bei diesem Vorgang können eine Rücksicherung ALLER Domain Controller erfordern – inklusiver der damit verbundenenen Downtime. Diese Form der Wiederherstellung wird Forest Recovery genannt.

Wer auf Nummer sicher gehen möchte, der sollte folgende Vorgehensweise anwenden:

  1. Die FSMO-Rollen werden auf einen virtuellen Domain Controller verschoben.
  2. Die AD-Replikation aller Domain Controller wird geprüft.
  3. Optional kann für den Schema Master eine Maintenance im DNS gestartet werden. Dazu kann mit nltest.exe /dsderegdns:<FQDN-des-DC> jeder DNS-Record des Domain Controllers im DNS gelöscht werden. Inklusive einer Replikation und mit Abwarten der TimeToLive sollte jetzt 15 Minuten gewartet werden.
  4. Die Netzwerkverbindung des Schema-Masters wird unterbrochen.
  5. Vom virtuellen Domain Controller kann ein VM-Snapshot erstellt werden. Das Betriebssystem sollte dabei Windows Server 2012 oder neuer sein.
  6. Jetzt kann das Schema “offline” auf dem isolierten Domain Controller aktualisiert werden.
  7. Wenn alles passt, dann kann die Netzwerkverbindung wiederhergestellt werden. Mit nltest /dsregdns kann sich der Domain Controller wieder im DNS registrieren
  8. Wenn der Prozess aber fehlerhaft war, dann muss nur der VM-Snapshot angewendet werden. Die anderen Domain Controller wissen von der fehlerhaften Veränderung nichts. Es ist also keine Forest Recovery erforderlich.
Ich starte den Befehl auf meinem neuen Exchange Server. Mein AD ist sauber. Und im Problemfall gibt es gleich eine Forest Recovery… Das ist der Befehl:

setup.exe /prepareschema /IAcceptExchangeServerLicenseTerms

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Der nächste Befehl aktualisiert die Configuration-Partition der Gesamtstruktur:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Abschließend starte ich noch die Aktualisierung der Domain Partition. Da ich nur eine Domain im meinem Active Directory Forest verwende muss ich den Befehl auch nur einmal starten:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Nach wenigen Minuten ist alles erledigt. Die beim Aktualisieren geschriebenen Logfiles im Verzeichnis c:\ExchangeSetupLogs archiviere ich im Admin-Share. Logfiles von relevanten Veränderungen sind später immer wertvoll bei der Fehlersuche:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Installation des Exchange Servers 2019 CU4
Die Installation des ersten Exchange Server 2019 benötigt noch einige Voraussetzungen. Diese werden aber vom Setup entweder auf Wunsch mitinstalliert oder als fehlend bei der Vorprüfung angegeben. Ich starte das Setup auf dem Server WS-MX2. Eine Update-Suche ist nicht möglich, da der neue Server nicht ins Internet kommt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Nach dem ausführlichen Lesen der EULA bestätige ich diese:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ich möchte gerne die volle Kontrolle über den Installationsprozess. Daher wähle ich diese Option aus:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Im nächsten Fenster wähle ich die automatische Installation fehlender Komponenten aus. Bei den Rollen enthält die Rolle Mailbox seit Exchange Server 2016 die Datenbankrolle, den ClientAccess, das Unified Messaging und den Hubtransport-Service. Der Edge-Transport-Service ist wie in den Vorgängerversionen auch ein vorgelagerter SMTP-Server für die DMZ. Beide Rollen schließen sich gegenseitig bei der Installation aus:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Installation soll im Standardverzeichnis landen. So kann ich mit einem SystemImage und der Sicherung der Systempartition das Betriebssystem und den Exchange Server als eine Einheit sichern und wiederherstellen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Prüfung auf Schadsoftware muss später manuell konfiguriert werden. Daher belasse ich die Einstellung unverändert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das Setup installiert die erforderlichen Rollen und Features und bleibt mit einer Auflistung fehlender Voraussetzungen stehen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Beide Komponenten sind kein Problem. Sie können kostenlos bei Microsoft heruntergeladen werden. Ich habe beide bereits im Software-Share auf meinem Fileserver vorrätig:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Installationen waren wie immer sehr unspektakulär. Mit einer Wiederholung der Voraussetzungsprüfung kehre ich zum Setup des neuen Exchange Servers zurück. Dieses Mal sind alle Voraussetzungen erfüllt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Bevor ich das Setup starte, deaktiviere ich den Windows Defender. Dieser ist sein Windows Server 2016 eine bereits installierte Schutzkomponente. Leider grätscht er gerne in das Setup rein. Daher beende ich ihn. Das geht bei mir nur mit einer Gruppenrichtlinie, da eine andere GPO den Defender aktiviert. Mit einem Sicherheitsfilter auf der GPO treffe ich nur den neuen Exchange Server:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Zusätzlich starte ich auf einem anderen Server ein PowerShell-Script. Dieses scannt im Sekundentakt das Active Directory auf ServiceConnectionPoints (SCP). Hier trägt jeder Exchange Server seine URL ein, die von Outlook-Clients und ActiveSync-Clients zum Auffinden der Server abgefragt werden können. Der Default-Wert der URL enthält dabei immer der FQDN des Servers: https://<FQDN>/autodiscover/autodiscover.xml

Hintergrund:

Warum ist das problematisch und wird daher von mir bereits beim Setup korrigiert? Ganz einfach:

  1. Der Eintrag wird während dem Setup automatisch mit dem FQDN des Servers erstellt.
  2. Üblicherweise wird der Server erst nach dem Setup und einem Neustart konfiguriert. Dabei wird der Namespace – z.B. mail.ws-its.de – in der URL hinterlegt (https://mail.ws-its.de/autodiscover/autodiscover.xml) und es wird ein passendes Zertifikat installiert.
  3. Zwischen Schritt 1 und Schritt 2 könnten Outlook-Clients auf die Idee kommen, die Autodiscover-Informationen zu aktualisieren. Dabei fragen sie einen Domain Controller nach SCP für Autodiscover. In diesem Fall würde ein DC neben der eigentlichen Namespace-URL https://mail.ws-its.de/autodiscover/autodiscover.xml auch die URL https://<FQDN>/autodiscover/autodiscover.xml in der Antwort versenden. Der Client hat also eine 50% Chance, dass er eine Verbindung zum neuen Server aufbaut.
  4. Und je nach Setup-Stand kann dieser bereits aktiv sein. Leider hat er bis zur finalen Konfiguration im Schritt 2 ein selbstsigniertes Zertifikat, dem die Outlook-Clients natürlich nicht vertrauen. Nur leider haben sie dann schon das lokale Outlook-Profil verändert. Oft ist dieses irreparabel gestört und muss dann vom Helpdesk auf den Clients zurückgesetzt werden.

Da hilft auch kein Loadbalancer, der vor den Exchange Servern steht, denn die Clients umgehen diesen ja beim direkten Verbindungsaufbau mit dem Exchange Server! Bei mir würde das eine Firewall zwischen dem Servernetz und den Client-Netzen verhindern. Aber bei Kunden hatte ich dieses Problem schon mehrfach beobachtet.

Warum das Microsoft nicht selber löst, indem der Record vielleicht zu Begin leer bleibt, weiß ich nicht. Aber mein Script kann die Korrektur direkt erkennen und den richtigen URL-Eintrag einschreiben. So bleibt für das oben genannte Szenario nahezu keine Zeit und es werden im Idealfall keine Outlook-Profile zerstört.

Ich starte das Script auf einem anderen Server:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt sind alle Komponenten bereitgestellt. Ich starte das immer noch wartende Setup:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Einige Minuten später ist es erfolgreich abgeschlossen und muss mit einem Neustart finalisiert werden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Auf dem anderen Server kontrolliere ich mein Script zur SCP-Korrektur. Im Logging finde ich den Zeitpunkt mit dem falschen Record. Und eine Sekunde später war er gefixt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Im Active Directory kann man mit ADSIEdit den Record natürlich auch sehen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt wird es auch wieder Zeit für den Defender. Ich entferne den Sicherheitsfilter der GPO und aktualisiere die Gruppenrichtlinien auf dem Server WS-MX2:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die vom Setup geschriebenen Logfiles archiviere ich wieder in meinem Admin-Share:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das Setup ist jetzt abgeschlossen. Jetzt folgt die Konfiguration der für mich relevanten Exchange Server Rollen.

Konfiguration der CAS-Rolle

Konfiguration der Virtual Directories
Die erste Rolle ist der ClientAccessService. Über diese Webdienste greifen alle Clients auf ihre Mailboxen zu. Dafür muss ich den Namespace „email.ws-its.de“ in alle virtuellen Verzeichnisse des Internet Information Services eintragen. Das geht sehr einfach mit der PowerShell. Wichtig an dieser Stelle wäre noch der Hinweis, dass ich alle Befehle von meinem Admin-Server ausführe. Die Anmeldung auf dem Exchange Server vermeide ich nach Möglichkeit.

Zuerst stelle ich in der PowerShell-ISE eine Verbindung zum Exchange Server her:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Intern wie extern verwende ich den gleichen Namespace. Die DNS-Server liefern dazu je nach Netzwerk die interne oder die externe IPv4-Adresse des LoadBalancers. Zeile 69 ändert übrigens den URL-Eintrag im Active Directory für das Autodiscover – der ServiceConnectionPoint, den mein Script vorhin schon veränderte:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Zeilen laufen anstandslos durch.

Installation des Serverzertifikates
Aber ohne ein passendes und vor allem vertrauenswürdigem Serverzertifikat wird kein Client gerne eine Verbindung aufbauen wollen. Das bisherige Zertifikat ist noch ein paar Monate gültig. Es wurde von einer öffentlichen Zertifizierungsstelle digital signiert. Die PKCS12-Datei mit dem öffentlichen und dem dazugehörigen privaten Schlüssel liegt mit einem Passwort geschützt in meinem Admin-Share. Mit der PowerShell kopiere ich die Datei auf den RemoteServer und installiere dort das Zertifikat. So umgehe ich den DoppelHop (AdminServer Exchange Server FileServer)

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt kann ich das Zertifikat an die beiden Services SMTP und IIS binden. Die Warnmeldung zeigt die aktuelle Verwendung eines selbstsignierten Zertifikates an. Mit Freuden bestätige ich sie:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Eine kurze Kontrolle im Internet Information Service Manager (IIS-Manager) zeigt das eingebundene Zertifikat:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Umstellung auf Kerberos-Authentication
Vor einiger Zeit habe ich die Anmeldung meiner Clients am Exchange Service auf Kerberos umgestellt (https://www.ws-its.de/aktivierung-von-kerberos-im-exchange-server-2016-2019). Der neue Server muss dafür das Passwort des Accounts von einem anderen Server kopieren. Nur so können mehrere Exchange Server hinter einem LoadBalancer mit der gleichen Kerberos-Identität agieren. Der Quellserver ist der alte WS-MX1. Mit meinem Script in der PowerShell-ISE erzeuge ich nur die Befehle. Diese müssen in der Exchange Management Shell ausgeführt werden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ich starte auf dem neuen Exchange Server die Management Shell und starte das Script mit den 2 Befehlen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das war recht einfach. Eine kleine Kontrolle in der PowerShell-ISE bestätigt den Import:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt rekonfiguriere ich noch die relevanten virtuellen Verzeichnisse. Das hätte ich natürlich auch vorher schon erledigen können. Aber jetzt passt es besser rein:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Damit ist der ClientAccessService auf dem neuen WS-MX2 fertig konfiguriert.

Testlauf im Loadbalancer
Es wird Zeit für eine Testphase. Dafür starte ich mein Outlook und öffne die Anzeige des Verbindungsstatus. Aktuell bin ich mit dem alten Exchange Server verbunden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das war auch zu erwarten, da der Loadbalancer den neuen Server nicht anspricht. Man erkennt bei genauer Betrachtung dessen Maintenance-State:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Für meinen Test schwenke ich nun die beiden Server im Loadbalancer: damit verhindere ich den Zugriff auf den alten Mailserver und zwinge die Clients, eine Verbindung zum neuen Server herzustellen. In größeren Umgebungen geht das natürlich etwas anders…

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Mein Outlook hat von der Aktion nichts bemerkt. Es ist einfach zu träge und zudem sind die Verbindungen auch nicht dauerhaft etabliert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Im Loadbalancer sieht man deutlich, dass nun alle Verbindungen den neuen Server verwenden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Einen weiteren Test nehme ich mit meinem Browser vor. Hier rufe ich intern die OWA-Webseite auf. Auch diese wird korrekt angezeigt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ebenso bleibt mein Smartphone mit den Mailboxen verbunden. Die Rolle CAS kann also auf dem neuen Server verwendet werden!

Produktivschaltung der CAS-Rolle
So ist der nächste Schritt die Aktivierung beider Mailserver im Loadbalancer:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt werden die Verbindungen über beide Server verteilt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Damit ist der Aufbau der ClientAccessServer-Rolle abgeschlossen.

Konfiguration der HTS-Rolle

Verschiebung der Transportdatenbank
Der neue Mailserver soll auch für den Mailtransport verwendet werden. Diese Rolle übernimmt der im Mailbox-Server integrierte HubTransportService – kurz HTS. Auch diese Rolle konfiguriere ich mit der PowerShell.

Ich beginne mit der Verschiebung der Transport-Datenbank. Diese liegt natürlich im Systemlaufwerk. Sie kann aber durchaus sehr groß werden. Daher verschiebe ich sie auf die Partition mit den anderen Datenbanken. Der dazugehörige PowerShell-Befehl muss aber in der Exchange Management-Shell ausgeführt werden. Mein Script rendert dazu den Befehl:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Mit Copy & Paste übertrage ich den Befehl in die Management-Shell. Diese muss als Administrator privilegiert ausgeführt werden. Der Transport-Dienst wird dabei kurz angehalten. Das stellt aber kein Problem dar:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Und das war es auch schon.

Aktivierung der AntiSpam und AntiMalware-Features
Jetzt kommen die Schutzfunktionen. Über den Mailservice wird viel Spam und ebenso der eine oder andere Schadcode transportiert werden. Beides kann ich nicht gebrauchen. Zur Abwehr verwende ich die eingebauten Features des Exchange Servers. Diese muss ich aber erst mit zwei Exchange-Scripten in der noch offenen Exchange Management-Shell aktivieren:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das erste Script möchte eine Verbindung zum Internet aufbauen, um neue Module herunterzuladen. Das scheint aber nicht zu funktionieren:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Ursache ist schnell gefunden: Meine Firewall blockiert die Downloads, da meine Mailserver wie alle anderen auch per Default keinen Internetzugriff haben:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Fürs Erste erlaube ich die Protokolle http und https. Später werde ich die erforderlichen URL zusätzlich beschränken. Diese beiden Regeln in meiner PFSense-Firewall sind für den Internet-Zugriff aus dem Server-VLAN zuständig. Die Quellserver habe ich dabei als Alias angelegt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Nun editiere ich beide Aliase und trage den neuen Mailserver mit seiner IP-Adresse ein:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ein Apply später wird die erste Verbindung aufgebaut:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Es dauert aber noch ein paar Minuten, bis das Script alles abgeschlossen hat:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt führe ich das Script zur Installation des AntiSpam-Agents aus:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Beide Scripte erfordern einen Neustart der Transport-Dienste:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Danach sind die Schutzkomponenten im HTS integriert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Konfiguration ist bereits im Active Directory abgelegt. Daher muss hier nichts angepasst werden.

Konfiguration der Konnektoren
Nun sind die Konnektoren für den Mailfluss an der Reihe:
  1. Ich editiere zuerst den „Default Frontend“-Konnektor. Dieser nimmt normalerweise von allen IP-Adressen auf Port 25 Mails entgegen. Dabei wird aber immer der FQDN des Mailservers übertragen. Mein Serverzertifikat ist aber nur für den externen Namen email.ws-its.de ausgestellt. Den FQDN des System-Konnektors kann man nicht verändern. Daher reduziere ich im ersten Befehlsblock die IP-Adressen des Konnektors auf interne Adressen.
  2. Im zweiten Block aktiviere ich die Protokollierung auf allen Default-Konnektoren. Damit kann ich später Probleme im Mailfluss leichter erkennen.
  3. Im dritten Block baue ich einen neuen Empfangs-Konnektor. Dieser darf von allen IPv4-Adressen verwendet werden. Und als FQDN soll mein Mailserver den richtigen Namen – der auch im TLS-Zertifikat steht – verwenden.
  4. Sowohl mein Monitoring-Server mit der IP-Adresse 192.168.100.18 als auch der Loadbalancer mit der IP-Adresse 192.168.100.250 senden regelmäßige Verbindungsaufbauten zum Mailserver. Diese will ich nicht in meinem Logging haben. Daher baue ich für beide IPs einen weiteren Empfangs-Konnektor. Dieser hat dann keine Protokollierung.

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

So schicke ich die Befehle ab. Und hier sieht man die Ergebnisse:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Es fehlt noch der Zugriff auf den Sende-Konnektor. Dieser ist serverübergreifend. Also muss ich nur den neuen Server in die Liste der Source-Transport-Server mit aufnehmen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Damit kann mein neuer WS-MX2 Mails senden und empfangen.

Testlauf und Produktivschaltung
Aber auch hier soll ein Testlauf eventuelle Konfigurationsfehler aufdecken. Mails aus dem Internet werden ebenfalls durch den Loadbalancer geschickt. In diesem ist der neue Server momentan im Wartungszustand. Wie beim CAS verdrehe ich auch hier die Konfigurationen. Weitere Mails kommen jetzt ausschließlich am neuen Exchange Server an:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das ist sehr schön im unteren, rechten Bereich erkennbar. Der alte Server hat Pause und der neue Server unterhält sich mit einem Server im Internet:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das ist kein Zufall. Zuvor habe ich mit dem Test-Tool von mxtoolbox einen Mailversand vorbereitet. In der Webausgabe kann ich mir das Ergebnis ansehen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Und auch mit meiner PowerShell-GUI kann ich den Mailfluss grafisch beobachten:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Hier funktioniert alles. Daher schalte ich die Rolle frei und aktiviere im Loadbalancer wieder beide Server:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Damit ist auch der Mailfluss konfiguriert.

Konfiguration der MBS-Rolle

Konfiguration der neuen Mailbox-Datenbanken
Es folgt die dritte Komponente eines Exchange Servers: die Mailbox-Server-Rolle – oft auch als MBS abgekürzt. Auf dem alten Server existieren aktuell 4 Postfachdatenbanken. Aber auch der neue Server hat eine Default-Database mitgebracht:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ich muss die Mailboxen, die in den alten Datenbanken enthalten sind, auf den neuen Server verschieben. Eine gemeinsame Datenbankverfügbarkeitsgruppe scheidet wegen der unterschiedlichen Betriebssysteme (Win 2016 und Win2019) und wegen der unterschiedlichen Exchange Server Versionen aus. Also erstelle ich neue Datenbanken auf dem neuen Server und verschiebe die Mailboxen. Danach kann ich die alten Datenbanken entfernen.

Wichtig ist aber, dass jede Datenbank einen eindeutigen Bezeichner hat. Da ich meine alten Namen später wiederverwenden möchte, hänge ich an jede neue DB einfach ein „-neu“ an. Die Pfade der Dateien im Dateisystem kann ich aber schon an den Zielnamen anpassen.

Die neue Default-Datenbank benötige ich nicht. Daher möchte ich sie löschen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Da ist aber schon etwas enthalten. Mit der PowerShell lässt sich das Geheimnis schnell lüften:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

OK, dann plane ich um. Die Datenbank erhält einen neuen Namen „DB-System-neu“ und wird auf die Partition der Exchange Datenbanken verschoben. So ist die erste der 4 neuen DBs fertig. Hier gibt es den neuen Namen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Und hier ein neuen Zuhause:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt benötige ich noch 3 weitere Datenbanken. Nebenbei bemerkt: an einer solchen Stelle ist ein Redesign der Mailboxdatenbanken sehr gut platzierbar. Mein Layout passt mir aber. Die 3 neuen Datenbanken sind mit wenigen Zeilen angelegt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Im Exchange Admin Center sind nun 8 Datenbanken enthalten:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jede Datenbank hat diese Dateien auf der neuen Exchange-Partition. Auffällig ist bei Exchange Server 2019, dass der Indizierungsordner fehlt. Das ist eine lange ersehnte Verbesserung: Der Suchindex einer Datenbank ist nun IN der Datenbank enthalten und kann auch mit der Replikation in einer Verfügbarkeitsgruppe auf einen anderen Server repliziert werden. Vorher musste jeder Server die Datenbank lokal durchsuchen und indizieren!

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt kommen noch ein paar Einstellungen auf alle neuen Datenbanken:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Aufbau der neuen Datenbankverfügbarkeitsgruppe (DAG)
Eigentlich könnte ich jetzt die Mailboxen verschieben. Es fehlt aber ein wichtiges Element: Das Backup! Für die Datensicherung brauche ich eigentlich nicht viel. Ich möchte aber bei der Migration des anderen Mailservers nicht mehr viel anpassen müssen. Mein Backup kann mit der Datenbankverfügbarkeitsgruppe umgehen. Also sollte ich diese jetzt erstellen. Dann wird mein Backup-Programm später keine Probleme haben.

Eigentlich benötige ich für einen DAG-Cluster mehr als einen Server. Aber es ist nicht unmöglich.

Der alte Cluster hat eine Cluster-IP:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Den neuen Cluster erstelle ich ohne IP-Adresse mit einem anderen Namen. Den Zeugenserver kann ich aber weiterverwenden. Beim Anlegen der DAG erhalte ich eine Warnmeldung:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ein Blick ins Active Directory zeigt an, dass die Gruppe tatsächlich kein Mitglied der lokalen Administratoren auf dem Fileserver WS-FS3 ist. Daher verschachtele ich sie in die richtige Gruppe.

Hintergrund:

Ich habe meine Server aufgeteilt. Jede Servergruppe liegt in einer eigenen Organisationseinheit. Jede dieser OUs hat eine eigene Gruppenrichtlinie und eigene Gruppen im Active Directory. Die Gruppenrichtlinie setzt nun für die AD-Gruppen die lokalen Rechte auf den Servern um. So kann ich z.B. die Berechtigung „lokal administrative Rechte“ für eine Menge von Servern explizit im Active Directory steuern. Hier sieht man die OU mit den Servern:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das sind die administrativen Gruppen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Und hier die dazugehörige Gruppenrichtlinie:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Mitglieder der Gruppe „LD-SEC-Server-File-Admins“ sind also auch Mitglieder der Gruppe „Administratoren“ auf meinen Fileservern. Also kann ich hier auch die erforderliche Gruppe „Exchange Trusted Subsystems“ aufnehmen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Mit diesem Modell der Berechtigung habe ich unter anderem auch den Vorteil, dass ich lokale Rechte ausschließlich über das Active Directory steuern kann.

Weiter geht es mit dem Aufbau der DAG. Bisher ist sie nur ein Datensatz im Active Directory. Erst mit dem ersten Mitglied wird sie erstellt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Mit der im Hintergrund replizierten Gruppenmitgliedschaft konnte die neue DAG erstellt werden. Ohne eine Cluster-IP wird die Broadcast-Adresse als Platzhalter im EAC angezeigt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Konfiguration der Datensicherung mit dem DPM 2019
Jetzt kann ich für die neue DAG im Data Protection Manager eine Datensicherung planen. Vorher muss ich aber noch die alte Sicherungskonfiguration bereinigen. Denn hier steht noch der alte Server drin:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ich verändere die Schutzgruppe:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die alten Sicherungseinträge entferne ich einfach:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ein paar Klicks später ist die alte Schutzgruppe sauber:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Nun muss ich noch die alte Agent-Verbindung zum nicht mehr vorhandenen Windows Server 2016 WS-MX2 entfernen. Das geht leider nicht mit der grafischen Oberfläche. Daher verwende ich einen PowerShell-Befehl:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt hat der DPM den alten Mailserver vergessen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Auf dem neuen Mailserver installiere ich den Agent des DPM. Das geht lokal einfach am besten. Auf meinem DPM hatte ich dazu eine Freigabe erstellt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Nach der Installation muss der Agent auf seinen neuen DPM-Server vorbereitet werden. Dabei werden Firewall-Ausnahmen erstellt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Für die Verbindung des DPM-Agents mit dem DPM-Server benötige ich eine Kennung, die administrative Rechte auf dem DPM-Server (Standard) und den Exchange Servern (MX) hat. Durch meine administrativen Trennungen mit den GPOs gibt es einen solchen Account aktuell nicht. Er wird aber nur kurz benötigt. Zudem darf er kein Mitglied der Gruppe „Protected Users“ sein. Für solche Fälle habe ich den Account „admin-setup“. Dieser hat keine statischen Gruppenmitgliedschaften. Mit meinem PAM-PowerShell-Script weise ich die zeitlich begrenzten Mitgliedschaften zu:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Weiter geht es im DPM in der Verwaltungsseite der Management-Konsole. Hier kann ich einen neuen Agent mit dem Schalter „Hinzufügen Server“ einrichten:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Wichtig ist, dass nur noch eine Verbindung aufgebaut werden muss. Der Agent ist ja bereits installiert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Jetzt suche ich den Server aus der Liste aus. Nach dem Hinzufügen wird er nicht mehr angezeigt. Das ist ein Bug:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Anschließend gebe ich die Anmeldeinformationen des zuvor konfigurieren Admin-Accounts ein:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Und dann kann der DPM beginnen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Der neue Mailserver wird angezeigt:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Weiter geht es mit der Konfiguration der Datensicherung. Ich möchte die Definitionen der aktuellen Schutzgruppe weiterverwenden. Also starte ich die Änderung:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Zu der alten DAG wähle ich die 4 neuen Datenbanken der neuen DAG aus:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Überprüfung mit eseutil muss ich an dieser Stelle herausnehmen. Ein DPM benötigt dazu explizit die passende eseutil.exe einer Exchange Server Version. Ich habe aber gerade eine Mischumgebung. Hier komme ich nach Abschluss der Migration noch einmal zurück.

Hintergrund:

Die Datenbanken werden im laufenden Betrieb mittels VSS-Snapshot gesichert. Sie wurden also nicht korrekt heruntergefahren. Bei der Sicherung ist das auch kein Problem. Das tritt erst bei einer Wiederherstellung auf. Dabei wird die gesicherte edb-Datenbankdatei aus dem DPM extrahiert und im Exchange Server gespeichert. Der Information Store Service kann aber nur korrekt heruntergefahrene Datenbanken mounten. Die gesicherte Datei ist aber in einem „Dirty-Shutdown“-Zustand. Mit eseutil kann die Datenbank „repariert“ bzw. in einen „Clean-Shutdown“-State gebracht werden. Leider kostet diese Arbeit neben Fachwissen vor allem Zeit. Und die haben wir nicht im Recovery-Fall. Daher kann der DPM jede gesicherte Datenbank automatisch in einen „Clean-Shutdown“ überführen. Bei einer Recovery wird sie einfach extrahiert und kann anschließend direkt gemountet werden.

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die 4 Datenbanken sollen mit einem Full-Backup gesichert werden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Der Speicherplatz wird in einem Pool organisiert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Sicherung darf sofort starten. Noch sind die Datenbanken klein. Das sollte nicht lange dauern:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Und nach wenigen Minuten sind die leeren Datenbanken gesichert:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Verschiebung der Mailboxen
Endlich kann ich meine Mailboxen aus den gesicherten, alten Mailboxdatenbanken in die gesicherten, neuen DBs verschieben. Die Postfächer sind sauber in den Datenbanken organisiert. Ich verschaffe mir einen Überblick. Dabei sollen auch die System-Mailboxen Beachtung finden:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Die Verschiebungen plane ich mit ein paar PowerShell-Zeilen. Von jeder Mailbox lese ich den Namen der alten DB aus un d verschiebe sie in die DB mit dem alten Namen plus dem Suffix „-neu“. Archive werden dabei ebenfalls berücksichtigt. Damit es besonders schnell geht, weise ich die Verschiebung mit der Priorität „emergency“ an. Es gibt schließlich bald Abendessen!

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Mit „emergency“ wandern die Mailboxen in Windeseile auf den neuen Server:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Abschließend entferne ich die Verschiebeanforderungen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Damit ist auch die dritte Rolle produktiv. Die Mailboxbenutzer haben von den Verschiebungen übrigens nichts mitbekommen. Verbindungen von den Clients werden immer zum CAS-Server aufgebaut. Nur dieser muss die neue Location eines Mailbox-Elementes im Hintergrund lernen. Der Vorgang ist vollkommen transparent!

Nacharbeiten

Lizensierung des Exchange Servers
Damit ich auch nach den 119 Testtagen Freude am neuen Exchange Server habe, trage ich den Produktschlüssel ein. Der Vorgang muss mit einem Neustart des Information Store Service abgeschlossen werden. In größeren Umgebungen sollte der Prozess daher VOR der Verschiebung der Mailboxen stattfinden.

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Logfile-Optimierung
Jetzt möchte ich noch die Log-Optimierung einrichten. Ein Exchange Server protokolliert den ganzen Tag in etliche Logfiles. Jedes Log kann dabei mit einer Rotation und einer Bereinigung konfiguriert werden. Das ist mir echt zu aufwendig. Daher erstelle ich lieber einen Task, der auf der gesamten Systemplatte nach bestimmten Dateitypen sucht, die älter als ein Schwellwert sind. Gefundene Files werden dann gelöscht. Den Task importiere ich mit einer XML-Datei:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Das hier ist der Aufruf in der geplanten Aufgabe. Alle Logfiles (auch die des IIS), die älter sind als 14 Tage, werden gelöscht:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe “& {Get-ChildItem -Path ‘C:\Program Files\Microsoft\Exchange Server\V15\Logging’,’C:\inetpub\logs\LogFiles’ -Include ‘*.log’,’*.bak’,’*.blg’ -Recurse | Where-Object { $_.LastWriteTime -le (Get-Date).AddDays(-14) } | Remove-Item -Confirm:$false -ErrorAction SilentlyContinue}”

Konfiguration des Monitorings
Zu den Nacharbeiten gehört auch das Monitoring. Diese Aufgabe übernimmt mein PRTG. Einige Sensoren habe ich bereits erstellt.

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Dazu zählt auch mein selbstgeschriebener PowerShell-Script-Sensor „BASE“. Mit diesem kann ich die typischen Werte des Betriebssystems überwachen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Der von mir geschriebene Sensor „MX-CAS“ überwacht die einzelnen Webservices des Client-Access-Services:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Ebenfalls selbst geschrieben überwacht der Sensor „DB-Health“ den Zustand der Datenbanken. Und im Vergleich zu dem Standard-Sensor von PRTG kann er auch mit dem neuen Indizierungsmechanismus vom Exchange Server 2019 umgehen:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Und zuletzt liefert mir ein selbst programmierter Sensor alle ServerComponentStates des Servers:

Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 &#8211; Teil 1/2

Zusammenfassung

Viel Arbeit
Der erste Mailserver ist neu installiert. Mit allen Begleitdiensten, wie dem Backup und dem Monitoring war es viel Arbeit. Aber es gab bis auf die Probleme bei der Deinstallation des alten Servers keine großen Schwierigkeiten. Also kann es bald mit dem anderen Exchange Server weitergehen.

Den Artikel gibt es wie gewohnt hier als pdf zum downloaden. Und zusätzlich habe ich in diesem ZIP-Archiv die beiden PowerShell-Scripte meiner Migration bereitgestellt.

Stay tuned!

Hier geht es zum Übersichtsbeitrag meiner Serie „Migration auf Windows Server 2019“.

Kommentar hinterlassen