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.

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:

Und das ist der aktuelle Stand:

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:

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

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

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

Der gesamte Vorgang dauert nur wenige Minuten.

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

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:

Nach einem Neustart suche ich weitere Updates:

Dann ist das System Up-To-Date:

Die Aktivierung ist ebenfalls erledigt.

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:

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

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

Wichtig sind auch die installierten Rollen und Features:

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

Mehr ist auf dem Server nicht zu finden.

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:

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

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

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

Jetzt kann die Deinstallation des alten Servers beginnen.

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:

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

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:

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

Danach entferne ich die nun leere DAG-1:

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

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:

Ich entferne die alten Datenbanken aus der Sicherung:

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:

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:

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:

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

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

Die Rolle MBS ist nun fertig konfiguriert.

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:

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

Dann kann ich jetzt die Deinstallation in der Systemsteuerung starten.

Wie erwartet sind alle Voraussetzungen erfüllt.

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

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

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

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

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

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

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

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

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

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

Die neue VM erhält ihren finalen Anzeigenamen:

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

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

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

Der neue Server ist nun konfigurationsbereit.

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:

Danach benenne ich den Server um und starte ihn neu

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

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

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:

Jetzt erstelle ich das neue Volume:

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:

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.

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

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

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:

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

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

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

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:

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

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

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.

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:

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:

Das Setup selber führe ich benutzerdefiniert aus:

Hier kann man wenig falsch machen:

Auch den Speicherpfad belasse ich auf dem Systemlaufwerk:

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

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

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“) .

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

Jetzt starte ich das Setup:

Einige Minuten später ist es abgeschlossen:

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

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

Das ExchangeSetupLog-Verzeichnis archiviere ich wieder in meinem AdminShare:

Im Exchange Admin Center wird der neue Server gelistet:

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

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

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

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

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

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

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:

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

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

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

Das war auch schon alles.

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:

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.

Die Verbindungen werden umgelenkt:

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

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

Beide Mailserver arbeiten nun gemeinsam die Clientanfragen ab:

Damit ist diese Funktion wieder hochverfügbar.

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:

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:

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:

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

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

Final starte ich die Transport-Dienste neu:

Beide Features haben sich als Transport-Agents registriert:

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:

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

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:

Das ist das Ergebnis:

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:

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:

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:

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

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

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.

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:

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:

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

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

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]

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

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

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

Die Bereitstellung wird nach einer Weile automatisch geschwenkt.

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:

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

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

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

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:

Und dann kann ich den Agent im DPM einbinden:

Das war problemlos.

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

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.

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

Die Datenbank lässt sich aber nicht schwenken…

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

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

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

Laut dem Active Directory sind beide Server DAG-Member:

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

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

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

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

Der Vorgang war wohl erfolgreich:

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

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

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

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:

Ich nehme den ersten Mailserver als Member auf:

Dabei wird der Cluster gebildet:

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

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

Jetzt hole ich den anderen Server dazu:

Beide sind jetzt online:

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

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

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

Das Seeding erwartet einen Quellserver:

Danach geht es recht schnell:

Das sieht doch viel besser aus:

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

JA! Endlich hab ich eine funktionale DAG!

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

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

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

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}“

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:

Im Detail kann man es besser erkennen:

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

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:

Damit sollte ich Probleme beim Exchange Service rechtzeitig kommen sehen.

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!