Serie „Migration auf Windows Server 2019“ – Migration eines Exchange Servers 2016 auf 2019 – Teil 2/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 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

Den Mailserver WS-MX2 habe ich bereits auf Windows Server 2019 und Exchange Server 2019 umgestellt. Jetzt ist der Server WS-MX1 an der Reihe. Auf diesem sind nur noch die Rollen Hubtransport und ClientAccess aktiv. Alle Datenbanken laufen bereits auf dem neuen Server. Nach der Neuinstallation soll eine Datenbankverfügbarkeitsgruppe die Ausfallsicherheit gewährleisten. Aktuell ist die Verfügbarkeit also eingeschränkt.

Das war meine ursprüngliche Mailserver-Infrastruktur:

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

Und das ist der aktuelle Stand:

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

Vorbereitung

Aufbau der neuen VM

Zuerst baue ich eine neue virtuelle Maschine in dem gleichen Hyper-V-Host, der auch den alten Mailserver beheimatet. Ich führe die Migration als Wipe & Load aus, daher verwende ich die Namen und IP-Adressen der Server wieder:

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

Damit ich zwischenzeitlich nicht durcheinander komme, benenne ich den neuen Server um:

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

Die Installation führe ich wie immer mit einer vorinstallierten VHDX aus. Diese enthält ein vorbereitetes Betriebssystem:

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

Die Kopie meiner Basefile hänge ich in die VM ein. Ebenso gibt es noch etwas mehr Hardware:

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

Der gesamte Vorgang dauert nur wenige Minuten.

Bereitstellung des neuen Betriebssystems

Nach dem Einschalten der neuen VM kann ich mich mit der Konsole verbinden. Hier wartet nach wenigen Sekunden der Einrichtungsassistent auf mich:

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

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

Danach kann ich mich bereits lokal anmelden. Ich verschiebe den Server fix ins Client-LAN, damit ich die Aktivierung und neue Patches online beziehen kann – im Servernetz sind die Systeme isoliert. Die Updates sind schnell gefunden:

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

Nach einem Neustart suche ich weitere Updates:

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

Dann ist das System Up-To-Date:

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

Die Aktivierung ist ebenfalls erledigt.

Sammlung von Informationen und Elementen im alten Server

Nun geht es weiter auf dem alten Server. Hier sammle ich wieder Informationen. Dazu gehören geplante Aufgaben. Diese kann ich mit einem einfachen Rechtsklick in xml-Dateien exportieren:

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

Die Dateien lege ich in meinem Admin-Verzeichnis lokal ab. Das gesamte Verzeichnis kopiere ich auf meinen Fileserver:

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

Danach verschaffe ich mir einen Überblick über lokal installierte Anwendungen:

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

Wichtig sind auch die installierten Rollen und Features:

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

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

Die IP-Konfiguration ist mir bekannt. Eine schnelle Dokumentation kann aber nicht schaden:

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

Mehr ist auf dem Server nicht zu finden.

Maintenance vorbereiten

Jetzt kann ich die Wartung für die Deinstallation einleiten. So verhindere ich unnötige Alarm-Meldungen von meinem Monitoring. Ich pausiere im PRTG einfach alle zum Server WS-MX1 gehörenden Sensoren:

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

Der ClientAccess-Service ist noch aktiv. Vorgeschaltet arbeitet meine PFSense mit einem HAProxy als Loadbalancer. Der Traffic ist rechts im Bild sichtbar:

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

In der Backend-Konfiguration des HAProxies kann ich den Server deaktivieren. Das nehme ich für CAS und HTS vor:

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

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

Neue Verbindungen von Clients und neue SMTP-Verbindungen werden jetzt nur noch dem neuen Server WS-MX2 zugewiesen:

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

Jetzt kann die Deinstallation des alten Servers beginnen.

Entfernung der alten Exchange-Installation

Bereinigungen in der Rolle MBS

Eine Deinstallation des Exchange Servers 2016 kann nur gelingen, wenn alle Voraussetzungen erfüllt sind. Eine davon sagt: Es dürfen keine Mailboxdatenbanken zugewiesen sein. Der alte Server hat noch 4 leere Datenbanken und ist noch Mitglied in der alten DAG. Die Mailboxen hatte ich bei der letzten Migration schon in 4 neue Datenbanken auf den neuen Server verschoben. Die Namen der Datenbanken musste ich dabei neu vergeben, da Exchange die Namen nur einmal in der Organisation vergeben kann. Das hier ist also das aktuelle Layout:

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

Diese alten, leeren Datenbanken entferne ich mit einer Anweisung in der PowerShell ISE. Die Warnungen kann ich ignorieren:

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

Weiter geht es mit dem alten DAG-Cluster. Die Administration gelingt nur mit einem NTLM-fähigen AdminAccount. Da mein regulärer Account durch die Mitgliedschaft in der Gruppe „Protected Users“ kein NTLM verwenden kann, konfiguriere ich mir mit meinem PAM-Tool einen temporären AdminAccount:

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

Mit dem Login Admin-Setup starte ich eine Exchange Management Shell. Jetzt kann ich den Server aus dem DAG-Cluster entfernen:

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

Danach entferne ich die nun leere DAG-1:

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

Das dazugehörige AD-Computerkonto entferne ich im Active Directory:

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

Umbenennen der neuen Datenbanken

Jetzt kann ich die Namen der neuen Datenbanken anpassen und den Suffix ‚-neu‘ entfernen. Vorher passe ich aber meine Datensicherung im Data Protection Manager an. Hier sind die leeren, alten Datenbanken und auch die neuen mit dem temporären Namen gelistet:

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

Ich entferne die alten Datenbanken aus der Sicherung:

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

Ein paar Klicks später sind nur noch die neuen DBs gelistet. Diese kann ich nun im Exchange Server WS-MX2 umbenennen. Das könnte ich mit 4 Einzeilern erledigen. Wenn es mehr Datenbanken werden, bietet sich eine Foreach-Schleife an:

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

Meine Hoffnung ist nun, dass der Data Protection Manager die Datenbanken nicht nach ihrem Anzeigenamen, sondern deren GUID identifiziert. Dann müsste er den Anzeigenamen bei der nächsten Sicherung anpassen. Das probiere ich jetzt aus:

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

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

Leider ist auch dieses Produkt an den Anzeigenamen gekoppelt… Also entferne ich testweise eine der neuen Datenbanken, um sie dann wieder mit dem neuen Namen anzufügen:

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

Das hat funktioniert. Also entferne ich auch die anderen 3 Datenbanken und füge sie neu an:

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

Die Sicherung läuft. Nach dem Abschluss entferne ich die alten, getrennten Sicherungen:

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

Die Rolle MBS ist nun fertig konfiguriert.

Bereinigungen in der Rolle HTS

Weiter geht es mit dem HubTransport. Hier muss ich nur den Sende-Konnektor vom Server WS-MX1 entfernen, indem ich WS-MX2 als alleinigen SourceTransportServer definiere. Von den Empfangs-Konnektoren erstelle ich einen Dump in einer Textdatei:

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

Das war auch schon alles. Der ClientAccess-Service muss nicht zurückgebaut werden.

Deinstallation des Exchange Servers

Dann kann ich jetzt die Deinstallation in der Systemsteuerung starten.

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

Wie erwartet sind alle Voraussetzungen erfüllt.

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

Das Setup bricht aber nach wenigen Sekunden mit der gleichen Fehlermeldung wie beim andernen Mailserver WS-MX2 ab. Offensichtlich reicht der Arbeitsspeicher nicht aus:

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

Wie beim Server WS-MX2 hat sich auch hier das Setup einen großen Teil des Arbeitsspeichers geholt:

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

Ich breche das Setup ab. Der Server hat eigentlich genug Speicher:

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

Da der neue Server noch ausgeschaltet ist, kann ich dem alten Server mehr RAM konfigurieren:

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

Aber das Setup braucht nur ein paar Sekunden mehr, um auch diese Reserve zu belegen:

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

Während ich diese ScreenShots erstelle, vergehen weitere Sekunden. In diesen „erholt“ sich das Setup. Die Meldung bleibt. Sie kommt aber auch vom Betriebssystem:

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

Das Setup läuft weiter. Nach wenigen Minuten wurde Exchange Server 2016 vom Server WS-MX1 deinstalliert. Nun steht noch ein Neustart aus:

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

Ich sichere noch das Verzeichnis C:\ExchangeSetupLogs auf mein AdminShare:

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

Dann gibt es den Neustart. Im EAC ist nun nur noch der neue WS-MX2 mit Exchange Server 2019 gelistet:

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

Entfernung des alten Servers und Austausch der VM

Nach dem Neustart fahre ich den alten Server herunter. Dann entferne ich die virtuelle Maschine im Hyper-V:

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

Die neue VM erhält ihren finalen Anzeigenamen:

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

Nun muss ich noch die virtuellen Festplattendateien vom Hyper-V-Storage entfernen. Die VHDX habe ich auf 2 Volumes aufgeteilt:

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

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

Der neue Server verfügt aktuell nur über eine System-Festplatte. Jetzt kommt noch eine weitere für die Exchange Datenbanken dazu:

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

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

Den Arbeitsspeicher konfiguriere ich statisch. Dazu muss ich die VM noch einmal herunterfahren:

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

Der neue Server ist nun konfigurationsbereit.

Bereitstellung des neuen Mailservers (MX2019)

Grundkonfiguration des Betriebssystems

Weiter geht es mit der Konfiguration der IP-Adresse. Der neue Server erbt die alte IP-Konfiguration. So spare ich mir einige Umstellungen in meiner PFSense-Firewall:

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

Danach benenne ich den Server um und starte ihn neu

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

Nach dem Neustart bereite ich ein Admin-Konto mit einer temporären Berechtigung für den Domain Join vor:

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

Danach kann der Server ins Active Directory aufgenommen werden. Dabei übernimmt er das freigewordene AD-Computerkonto des alten Servers:

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

Nach dem Neustart konfiguriere ich die zusätzliche Festplatte. Hier soll der Exchange Server später seine Datenbanken ablegen können. Der Datenträger ist noch offline:

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

Jetzt erstelle ich das neue Volume:

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

Ich verwende den maximalen Speicherplatz und formatiere wie auf WS-MX2 mit ReFS – das bevorzugte Dateisystem für Exchange Datenbanken. Wichtig ist zudem, dass der Laufwerksbuchstabe mit dem vom anderen Mailserver identisch ist. Nur so kann ich später die Datenbanken in einer DAG synchronisieren:

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

Danach ist das Volume fertig. Ich verändere noch die ACL für den Zugriff. In meinem Active Directory habe ich eine spezielle Rechtegruppe für den Zugriff auf diese Volumes. Nur diese und das System sollen darauf zugreifen dürfen. Das Ziel dieser Änderung ist einfach erklärt: Ich habe danach 3 Rechtegruppen für die Administration, die sich gegenseitig ergänzen:

  • die Admingruppe „LD-SEC-ServerMX-Admins„ für die Betriebssystem-Administration
  • die Admingruppe „Organization Management“ für die Exchange-Administration
  • die Admingruppe „LD-Admin-MX-Storage“ für die Speicher-Administration

Je nach anstehender Aufgabe nehme ich meine Adminkennung temporär in die dazugehörige Gruppe auf. Stehen beispielsweise Windows Updates an, dann brauche ich keinen Storage-Zugriff oder Rechte im Exchange Dienst.

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

Weiter geht es mit den zusätzlichen Rollen und Features, die nicht zwingend etwas mit Exchange Server zu tun haben:

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

Danach gibt es noch einmal einen Neustart. Ein Feature hatte ich vergessen. Das hole ich noch fix mit der PowerShell nach:

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

Der neue Exchange Server 2019 benötigt das .net-Framework 4.8. Das installiere ich mit einem Offline-Installer, der auf meinen Software-Share liegt:

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

Ebenso wird das Microsof Unified Communications Managed API 4.0als Runtime benötigt:

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

Und auch Visual C++ 2013 Redist wird benötigt:

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

Alle Setups lassen sich problemlos installieren. Danach wird es Zeit für ein Windows Update. Das .net-Framework muss aktualisiert werden:

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

Einrichtung der Datensicherung (BMR mit Windows Server Sicherung)

Bevor der Server in die Produktion geht, konfiguriere ich die Datensicherung. Diese splittet sich wie bereits bei meinen anderen Servern in 2 Teile auf. Hier soll das Betriebssystem durch regelmäßige SystemState-Images gesichert werden. Dafür importiere ich eine Aufgabe:

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

Der Sicherungsaccount ist ein Group Managed Service Account. Diesen kann ich beim Import nicht angeben. Daher trage ich hier einen Dummy ein:

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

Die Umstellung auf den gMSA nehme ich mit meiner PowerShell-GUI vom Domain Controller aus vor:

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

Die geplante Aufgabe wird jeden Tag ein Script auf meinem Sicherungsserver aufrufen. Dieses liest eine Konfigurationsdatei ein und sichert das Betriebssystem nach den darin enthaltenen Vorgaben mit Windows Server Backup auf eine geschützte Freigabe. Die Konfiguration ist auf den Servernamen ausgerichtet. Da dieser übernommen wurde, muss ich keine weiteren Anpassungen vornehmen.

Installation des Exchange Server 2019 CU4)

Für das Exchange Server Setup halte ich noch den Windows Defender an. Dafür habe ich eine passende GPO. In diese muss ich nur den Server im Sicherheitsfilter hinterlegen. Ein gpupdate später ist der Defender auf WS-MX1 aus:

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

Das ISO mit Exchange Server 2019 CU4 habe ich eingelegt. Ich starte das grafische Setup. Updates wird der Server dank meiner Firewall nicht finden. Also spare ich mir diese Zeit:

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

Das Setup selber führe ich benutzerdefiniert aus:

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

Hier kann man wenig falsch machen:

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

Auch den Speicherpfad belasse ich auf dem Systemlaufwerk:

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

Diesen Schutz möchte ich später weiter verwenden:

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

Das Setup analysiert die Voraussetzungen für die Installation. Hier passt alles:

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

Bevor ich das Setup starte, bringe ich ein PowerShell-Script in Stellung. Dieser Code korrigiert den ServiceConnectionPoint aller Exchange Server, indem er bei allen die URL meines LoadBalancers einträgt. Das hatte ich bei meinem ersten Mailserver WS-MX2 bereits ausführlich erläutert (https://www.ws-its.de/serie-mig2019-ws-mx2/ im Punkt „Installation des Exchange Servers 2019 CU4“) .

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

Das Script läuft und kontrolliert im Sekundentakt auf abweichende Records:

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

Jetzt starte ich das Setup:

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

Einige Minuten später ist es abgeschlossen:

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

Während der Server neustartet, kontrolliere ich mein SCP-Korrektur-Script. Hier gab es ein paar Verzögerungen durch die AD-Replikation:

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

Das führte zu mehreren Sekunden, in denen der FQDN des neuen Servers veröffentlicht wurde:

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

Praxistipp:
Zur Sicherheit sollte jetzt auf JEDEM Exchange Server im IIS-Manager der ApplicationPool für das AutoDiscover durchgestartet werden. Diese Webanwendungen speichern sich unter Umständen diese falschen Informationen aus dem Active Directory für 30 Minuten!

Das ExchangeSetupLog-Verzeichnis archiviere ich wieder in meinem AdminShare:

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

Im Exchange Admin Center wird der neue Server gelistet:

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

Zuletzt entferne ich die Gruppenrichtlinie mit der Deaktivierung des Windows Defender:

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

Das Setup ist damit abgeschlossen. Weiter geht es mit der Rollenkonfiguration.

Konfiguration der Rolle CAS

Konfiguration der Virtual Directories

Ich beginne mit der Rolle ClientAccessService. Die Konfiguration habe ich vom anderen Server kopiert. Ich definiere die VirtualDirectories:

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

Die Warnungen können ignoriert werden –das ECP und das OWA Virtual Directory wurden nacheinander konfiguriert:

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

Installation des Serverzertifikates

Der CAS ist ein Webdienst. Hier ist ein Serverzertifikat eine zwingende Voraussetzung. Die PKCS12-Datei importiere ich mit der PowerShell:

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

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

Danach aktiviere ich die Verwendung des neuen Zertifikates im IIS und auch gleich für den Hubtransport:

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

Umstellung auf Kerberos-Authentication

Im nächsten Schritt aktiviere ich die Anmeldung mit Kerberos auf dem neuen Exchange Server. Die Konfiguration ist auf dem anderen Server bereits aktiv. Daher soll sich der neue Server dessen Informationen holen. In meinem PowerShell-Script wird der Aufruf als Text ausgegeben. Das Ergebnis sind Befehle. Dies kopiere ich in die Zwischenablage:

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

Dann starte ich auf dem Exchange Server WS-MX1 eine Exchange Management Shell und füge anschließend die Befehle aus der Zwischenablage ein:

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

Der Prozess war erfolgreich. Das bestätigt mir auch die Abfrage in der PowerShell-ISE:

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

Jetzt kann ich Kerberos für den Outlook-Zugriff konfigurieren:

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

Das war auch schon alles.

Testlauf im Loadbalancer

Der ClientAccessService ist fertig konfiguriert. Es wird Zeit für einen Testlauf. Der vorgeschaltete LoadBalancer in meiner PFSense leitet aktuell alle Clients auf den anderen Mailserver um:

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

In meiner kleinen Umgebung drehe ich nun das Backend des LoadBalancers um und leite alle Clientanfragen auf den neuen Server. Das würde ich in einer größeren Umgebung anders losen. Da könnte z.B. die HOSTS-Datei eines Testclients modifiziert werden, damit der Client direkt beim neuen Mailserver herauskommt.

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

Die Verbindungen werden umgelenkt:

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

Mein Outlook hat mit dem neuen Server keine Probleme. Ebenso funktioniert mein ActiveSync am Smartphone:

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

Produktivschaltung der CAS-Rolle

CAS ist also einsatzbereit. Final aktiviere ich beide Exchange Server im LoadBalancer:

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

Beide Mailserver arbeiten nun gemeinsam die Clientanfragen ab:

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

Damit ist diese Funktion wieder hochverfügbar.

Konfiguration der Rolle HTS

Verschiebung der Transportdatenbank

Auch die zweite der drei Hauptfunktionen – der Mailfluss im HubTransportService – benötigt nicht viel Zeit. Zuerst verschiebe ich die Transportdatenbank auf die neue Partition. Diese DB kann ebenfalls schnell sehr groß werden und würde auf der Systempartition nur Probleme verursachen. Die Verschiebung gelingt mit einem Exchange-Script in der Management Shell:

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

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

Aktivierung der AntiSpam und AntiMalware-Features

Bevor die ersten Mails den Server passieren, brauche ich AntiSpam und AntiMalware-Features. Dafür verwende ich die Boardmittel des Exchange Servers. Das erste Feature aktiviere ich in der Management Shell:

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

Das Script startet eine Aktualisierung. Die Dateien sollen aus dem Internet heruntergeladen werden. Da hat meine PFSense-Firewall aber etwas dagegen. Die entsprechende Ausnahme lässt den Server nach draußen:

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

Wenige Minuten später ist ein Neustart des Services fällig:

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

Zuvor installiere ich noch AntiSpam – ebenfalls mit einem Exchange Script in der Management Shell:

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

Final starte ich die Transport-Dienste neu:

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

Beide Features haben sich als Transport-Agents registriert:

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

Konfiguration der Konnektoren

Für den Empfang der Nachrichten führe ich die gleichen Befehle wie beim Server WS-MX2 aus. Damit editiere ich den Default-Connector zum Empfang interner Nachrichten und aktiviere das Logging:

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

Und mit einem neuen Connector kann das System Mails aus dem Internet empfangen:

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

Da mein Monitoring und mein LoadBalancer permanent die SMTP-Services kontaktieren, erstelle ich einen weiteren Connector, trage dort die IP-Adressen ein und lasse die Protokollierung deaktiviert. So kann ich bei Zustell-Problemen die Logfiles viel leichter kontrollieren:

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

Das ist das Ergebnis:

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

Jetzt trage ich den neuen Server noch in meinen Sende-Konnektor ein. Wichtig ist hier, dass BEIDE Server gelistet sind. Würde nur der neue Server angegeben werden, dann würde der bestehende Server herausfallen:

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

Testlauf und Produktivschaltung

Die Rolle HTS hat nun alle erforderlichen Konfigurationen erhalten. Es wird Zeit für einen Testlauf. Mein PFSense-LoadBalancer arbeitet auch eingehende Mails ab und verteilt diese auf die beiden Mailserver. Aktuell ist aber nur der WS-MX2 aktiv. Ich drehe wie beim CAS die Verbindungen um. Neue Mails kommen nun über den neuen Mailserver rein:

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

Natürlich habe ich einen Test vorbereitet. Die Werkzeuge von mxtoolbox können einen externen Mailversand simulieren. Die Testmail kommt über den neuen Server rein:

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

Das Tool meckert zwar wegen der Transaction Time, aber da hab ich kein Problem mit:

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

Mit meinem PowerShell-Tool Exchange-PSGUI kann ich die Logfiles des Nachrichtenflusses gezielt untersuchen. In den Connectivity-Logs finde ich den Zustellversuch von mxtoolbox:

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

Das sieht fein aus. Der HTS ist einsatzbereit. Zum Abschluss aktiviere ich in der PFSense beide Mailserver für den Mailempfang. Damit sind 2/3 Rollen hochverfügbar.

Konfiguration der Rolle MBS

Beitritt zur Datenbankverfügbarkeitsgruppe

Die letzte der 3 Rollen ist der Datenbankservice. Hier soll die Verfügbarkeit durch eine Datenbankverfügbarkeitsgruppe abgebildet werden. Diese arbeitet mit dem Windows Failover Cluster Feature und kann Datenbanken über die beteiligten Server replizieren.

Die DAG „WS-DAG“ hatte ich bereits mit dem anderen Server WS-MX2 aufgebaut. Der neue Server WS-MX1 muss diesem Cluster nur noch beitreten:

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

Konfiguration der Datenbanken – Problem beim Seeding

Die Datenbanken werden aber nicht automatisch geschützt. Die Kopien müssen von Hand erstellt werden. Aktuell sollen es 4 Produktionsdatenbanken sein. Das EAC zeigt aber noch eine Default-DB auf dem neuen Server an:

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

Die Default-DB entferne ich mit der PowerShell. Die Datenbankdatei entferne ich später:

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

Jetzt erstelle ich für jede Datenbank eine lokale Kopie. Leider ist der Befehl schlecht programmiert:

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

Hintergrund:
Der Befehl Add-MailboxDatabaseCopy erstellt eine Datenbankkopie auf dem angegebenen Server. Anschließend wird das sogenannte „Seeding“ gestartet, mit dem der aktuelle Datenstand importiert wird. Die beiden Aktionen werden von zwei unterschiedlichen Diensten ausgeführt. In meinem Fall hat der Replikationsdienst versucht, die Daten zu importieren, bevor der InformationService die Datenbank-Instanz erstellt hat. Da spielt die AD-Integration eine Rolle. Denn das Vorhandensein einer Datenbank wird im Active Directory hinterlegt. Das hätte man besser konfigurieren können.

In der Praxis bietet es sich daher an, das Seeding manuell zu einem späteren Zeitpunkt zu starten. Dafür wird der SwitchParameter -SeedingPostponed verwendet:

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

Das Seeding kann dann nach einigen Minuten mit Update-MailboxDatabaseCopy gestartet werden.

In meinem Fall sind die 4 Kopien erstellt worden. Nun warte ich einige Minuten:

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

Nach der Wartezeit versuche ich das Update-MailboxDatabaseCopy für alle Kopien zu starten:

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

Leider kommen hier auch nur Fehlermeldungen als Ergebnis:

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

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

Ich versuche es man mit dem cmdlet Update-MailboxDatabaseCopy. Leider auch ohne Erfolg:

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

Die grafische Oberfläche gibt mir bei einem weiteren Versuch eine sprechendere Fehlermeldung aus. Aber auch die angegebene Option bringt nichts:

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

Ich starte den neuen Server mal durch und versuche es erneut. Jetzt kann ich einen Server auswählen. Die angezeigte Aktion entspricht dem cmdlet Update-MailboxDatabaseCopy:

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

Die Fehlermeldung ist aber wieder die gleiche:

Fehler beim Seedingvorgang. Fehler: Fehler beim Ausführen des Seedingvorgangs. Fehler: Fehler beim Verarbeiten einer Anforderung auf dem Server 'WS-MX2.ws.its'. Fehler: Das Sicherungsdateihandle für Datenbank "DB-Jungbrunnen" auf Server "WS-MX2" konnte nicht geöffnet werden. Hresult: 0x9. Fehler: Die angegebene Datenbank ist nicht vorhanden.. [Datenbank: DB-Jungbrunnen, Server: WS-MX1.ws.its]

Und es stimmt: Die Datenbank fehlt. Aber genau darum geht es ja beim Seeding:

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

Auch mit den anderen Parametern bekomme ich keine Erfolgsmeldung:

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

Also rolle ich einen Schritt zurück und entferne die nicht existenten Kopien vom Server WS-MX1. Dann erstelle ich eine neue Kopie. Doch auch so bekomme ich nur eine Fehlermeldung:

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

Access Denied? Ich habe doch die erforderlichen Rechte? Die PowerShell meldet das gleiche:

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

Ich habe durch Gruppenrichtlinien ein Tier-Management für meine Administration aufgebaut. Vielleicht ist ja hier etwas durcheinandergeraten? Die Mitgliedschaft der lokalen Administratoren zeigt nur den lokalen Admin und eine AD-Gruppe. Die Domain Admins hab ich hier explizit verbannt…

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

Die Einstellung kommt wie gewünscht durch meine GPO zustande:

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

in die LocalDomain-Gruppe „LD-SEC-Server-MX-Admins“ ist eine globale Gruppe verschachtelt:

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

Und das ist mein Problem: Die Exchange Server können sich untereinander administrieren. Dafür existiert eine Active Directory Gruppe „Exchange Trusted Subsystems“. Diese wird beim Setup automatisch in die lokale Gruppe „Administratoren“ aufgenommen. Meine GPO arbeitet aber im Modus „Ersetzen“. Damit verlieren die Exchange Server ihre Rechte!!!

Also nehme ich die Gruppe durch eine Verschachtelung wieder auf: „Exchange Trusted Subsystems“ GG-SEC-Server-MX-Admins LD-SEC-Server-MX-Admins .\Administratoren

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

Die Übernahme braucht wahrscheinlich einen Neustart. Der ist schnell durchgeführt.

Konfigurieren der Datenbanken – mit Erfolg

Dann probiere ich es noch einmal. Und kaum macht man es richtig, schon funktioniert es:

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

Meine Datenbanken sind nicht sehr groß, daher dauert das Erstellen der 4 Kopien nicht sehr lange:

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

Jetzt sorge ich noch für eine Lastverteilung, indem ich 2 der 4 Datenbanken primär auf dem neuen Server ausführen lasse:

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

Die Bereitstellung wird nach einer Weile automatisch geschwenkt.

Konfiguration der Datensicherung mit dem DPM

Integration des neuen Servers im DPM – Problem: keine Sicherung

Jetzt kommt die Datensicherung der Datenbanken dran. Diese werden ja bereits von meinem Data Protection Manager 2019 auf dem anderen Mailserver WS-MX2 gesichert. Daher sollten hier nur noch Feinheiten notwendig sein.

Der neue Server benötigt den DPM-Agent installiert. Das nehme ich lokal vor. Das Setup liegt in einer Freigabe des DPM:

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

Auch die Konfiguration des Agents starte ich auf dem Exchange Server mit einer Batch-Datei:

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

In der DPM-Konsole ist der alte Server noch gelistet:

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

Den Eintrag kann man in der GUI nicht entfernen. Daher nehme ich den Powershell-Befehl:

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

Für die Verbindung zwischen Agent und DPM ist ein NTLM-fähiger Account erforderlich. Den richte ich mir fix mit meinem PAM-Tool her:

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

Und dann kann ich den Agent im DPM einbinden:

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

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

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

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

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

Das war problemlos.

Jetzt müssen die Datenbanken des Server WS-MX1 nur noch in die Schutzgruppe aufgenommen werden. Diese listet aber schon Probleme…

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

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

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

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

Die Datenbanken sind eingetragen. Aber die Sicherung läuft nicht mehr an. Der DPM hat sich komplett verkeilt… Es wird Zeit für ein TroubleShooting.

Problem: Clusterfehler

Bevor ich mit meinen Produktionsdatenbanken weiter experimentiere, erstelle ich mir lieber eine Test-Datenbank in meiner DAG:

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

Die Datenbank lässt sich aber nicht schwenken…

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

Für ein weiteres TroubleShooting benötigt mein DAG-Cluster eine IPv4-Adresse. Diese trage ich im EAC ein:

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

Und dann meldet das EAC, der Server WS-MX1 sei nicht korrekt im Cluster Mitglied??

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

Da muss ich ihn wohl noch einmal neu joinen. Leider muss ich dazu alle Datenbank-Kopien wieder entfernen:

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

Laut dem Active Directory sind beide Server DAG-Member:

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

Der Server WS-MX1 sieht sich aber alleine in der DAG:

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

Ich versuche, den Cluster des Servers zu entfernen. Dieser scheint eine Dublette zu sein.

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

Ich versuche erneut, die IPv4 dem Cluster zuzuweisen. Dieses mal mit Erfolg:

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

Den WS-MX1 hole ich direkt mit der EAC dazu:

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

Der Vorgang war wohl erfolgreich:

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

Jetzt entferne ich die lokalen Datenbank-Kopien auf dem neuen Cluster-Member:

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

Danach nehme ich mir das Erstellen der Datenbank-Kopien vor:

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

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

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

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

Dank der geringen Größe der Datenbank ging das recht schnell. Dennoch wird eine Kopie im Anschluss wieder als defekt angezeigt:

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

Offenbar ist der Cluster WS-DAG defekt. Daher baue ich jetzt alles neu auf. Die eine Datenbank-Kopie entferne ich wieder. im Anschluss nehme ich beide Server aus der DAG heraus. Danach entferne ich die DAG. Jetzt kann ich eine neue DAG erstellen:

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

Ich nehme den ersten Mailserver als Member auf:

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

Dabei wird der Cluster gebildet:

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

Hierbei handelt es sich um einen traditionellen Windows Failover Cluster mit IPv4 und einem Cluster-Computerkonto im Active Directory:

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

Mit dieser traditionellen Bauart kann ich jetzt auch den Cluster-Manager verwenden:

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

Jetzt hole ich den anderen Server dazu:

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

Beide sind jetzt online:

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

Es wird wieder Zeit für die Datenbank-Kopien. Ich teste mit der kleinen DB-System:

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

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

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

Hier war die Replikation zu schnell. Ich warte also ab, bis die EAC den „Aktualisieren“-Schalter zeigt:

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

Jetzt ist es soweit. Das kleine Detail kann man leicht übersehen:

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

Das Seeding erwartet einen Quellserver:

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

Danach geht es recht schnell:

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

Das sieht doch viel besser aus:

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

Aber so weit war ich schon mal. Lässt sich die Datenbank auch verschieben?

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

JA! Endlich hab ich eine funktionale DAG!

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

Ich erstelle nun auch für die anderen Datenbanken die fehlende Kopie.

Nacharbeiten

Lizensierung des Exchange Servers

Die letzten Arbeitsschritte führen zur Aktivierung des neuen Servers:

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

Logfile-Optimierung

Ebenso benötige ich eine automatische Bereinigung der unzähligen Logdateien. Dazu importiere ich den gleichen Scripttask wie beim anderen Server:

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

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

Der Task startet diesen Code:

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

Nun fehlt nur noch das Monitoring. Hier stehe ich vor einem Problem: der mitgelieferte Sensor von PRTG kann mit Exchange Server 2019 Datenbanken nicht umgehen. Diese haben eine andere Form der Datenindizierung. Da die alte Variante fehlt – aber geprüft wird – gibt es Fehler:

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

Im Detail kann man es besser erkennen:

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

Also erstelle ich mir eigene Sensoren mit der PowerShell und binde diese ein:

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

Das neue Script kann bis zu 16 Datenbanken je Server überwachen – in einem Sensor (zur Info: bei PRTG wird unter anderem nach der Anzahl der Sensoren lizensiert. Die hauseigenen Exchange-Sensoren können nur eine Datenbank je Sensor überwachen). Integriert habe ich je Datenbank die Bereitstellung, den Indexstand und das Alter der Datensicherung.

Und schon ist wieder alles im grünen Bereich.

Und weil ich gerade dabei bin gibt es noch einen weiteren neuen Sensor (selbstprogrammiert). Mit diesem kann ich die ServerComponentStates überwachen:

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

Damit sollte ich Probleme beim Exchange Service rechtzeitig kommen sehen.

Abschluss der Migration

Zusammenfassung

Endlich sind die beiden Mailserver umgezogen. Das war viel Arbeit. Aber nun trennen mich nur noch wenige Server von meinem Ziel einer reinen Windows Server 2019 Umgebung!

Den Artikel gibt es wie gewohnt hier als pdf zum downloaden.

Stay tuned!

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

Kommentar hinterlassen