Hallo Leser,

ja ich weiß, ich schulde euch noch einen anderen Beitrag, jedoch lässt es die Zeit nicht so zu wie ich es gerne hätte. Dafür bekommt ihr weiterhin einen Werbefreien Blog mit guten Infos :)

Das Bild zu dem heutigen Blog-Post ist Copilot generiert, Copilot hat einige Anläufe Benötigt bis Exchange Server richtig geschrieben war ;) Nun zum Inhalt des heutigen Artikels ….

Was war diese Woche los? Ein Unternehmen ist an uns (cloudcoop GmbH) herangetreten mit der Bitte nach dem Exchange Server zu schauen. Wir haben uns einen Überblick verschafft und folgendes vorgefunden:

  • 1x Exchange Server 2019 Cu14 mit November SU (dieses ist mittlerweile zurückgezogen)
  • Windows Server 2019, aktueller Patch Stand
  • Alle Outlook Clients lokale im Online Modus
  • Circular Logging aktiv, um LOG-Kapazität zu sparen …..
  • 1x VM auf ESXi 6.7.0 (Wir haben keinen Einfluss, ist halt da)
  • Acronis Backup vorhanden. Aufbewahrung Full, 30 Tage. Entire VM, kein Application Aware.
  • NoSpamProxy Mailgateway

Du benötigst Unterstützung bei einem Microsoft Projekt?

Exchange, Hybrid, Cloud & Entra ID sind für dich ein rotes Tuch oder du benötigst einen Partner der dich souverän in einem Kundenprojekt unterstützt?

Buche einen unverbindlichen Beratungstermin HIER

Melde dich bei uns, unter https://cloudcoop.de findest du alle Informationen!

Selbstverständlich kannst du uns auch gerne eine E-Mail an support@cloudcoop.de schreiben.

Die Fehlerbeschreibung

Das habe ich noch nicht erlebt. Der Ansprechpartner des Unternehmens beschrieb es wie folgt:

Wir können so gut wie gar nicht mehr mit Mail arbeiten. Outlook kann sich nicht zu dem Exchange Server verbinden, dieser wird jedoch ausgeführt. Die VM läuft. Damit wieder gearbeitet werden kann muss ich die VM beenden (PowerOff) und neu starten. Anschließend haben wir ca. 5  Minuten Zeit Nachrichten zu Empfangen und zu senden, und das Spiel geht von Vorne los.

Erste Analyse & Exchange Server Recovery

Die Erste Analyse brachte die o.g. Gegebenheiten zum Vorschein und damit auch die ersten Herangehensweisen. Das System friert tatsächlich vollständig ein. Jegliche Versuche durch

  • entfernen unnützer Software,
  • Treiber-Updates,
  • VM-Anpassungen,
  • Umzug der VM-Ressourcen,
  • Deinstallation neuster Windows Updates,
  • Anpassen der Systemparameter

brachte keine Verbesserung.

Das Entfernen des zurückgezogenen SU (Released: November 2024 Exchange Server Security Updates | Microsoft Community Hub) war uns zu heikel, da der Server ggf, in einen irreparablen Zustand verfällt.

Zudem hat der Server keinerlei Dumps geschrieben. Durch das einfrieren und den PowerOff (einzige Möglichkeit) war das System wohl nicht mehr dazu in der Lage, was uns die Fehlersuche ebenfalls erschwerte.

Auf dem Host-System werden noch 7 andere VMs betrieben, ohne Probleme!!!

Exchange Server Restore?

Da wir nur ein Fullbackup von letzter Woche hatten, und der Zustand zu dem Zeitpunkt bereits schon gewesen ist, war dies keine Option.

Mailbox-Recovery ebenfalls nicht, da wir einzig nur die Datenbank-Dateien im Zugriff hatten. Was also tun? Ein Restore der Datenbank von diesem Tag hatte zufolge das Mails der vergangenen Tage nicht mehr verfügbar waren – es sollte die letzte Option sein.

Dadurch das der verantwortliche den Server jedoch immer wieder im Zugriff hatte, konnte der NoSpamProxy auch Mails zustellen. Die Postfächer wurden in unregelmäßigen Abständen mit Inhalten versorgt, was tun mit den Mails der vergangenen Wochen?

Exchange Server Migration

Wir stehen also vor dem Punkt das ein Restore nahezu ausgeschlossen ist, der Kunde und die Mitarbeiter wieder arbeiten wollen, klar! Zunächst einmal sollte unsere Aufgabe sein einen neuen Exchange Server bereitzustellen.

Wir haben demnach:

  • Windows Server 2022 Standard in einer neuen VM installiert
  • Exchange Server 2019 CU14 SU April 24 mit einer klassischen Installation bereitgestellt (kein  „Setup.exe /Mode:RecoverServer“)
  • Der Server, wie alle anderen im übrigen auch, läuft einwandfrei.
  • Eine neue Datenbank mit dem Namen MDB03 Implementiert

Das System wird Stabil ausgeführt. Ein Zugriff auf die PowerShell und ECP ermöglichen uns nun einen konstanten Blick auf die Umgebung, ohne das wir bangen müssen.

Unsere Überlegungen, während der Installation, sind selbstverständlich nicht eingeschlafen.  Was uns zum nächsten Punkt führt.

Exchange Server Disaster Recovery

Achtung! Das hier beschriebene Szenario ist der letzte Notnagel und sollte im Fall eines Falles mehrfach überdacht werden!

Wir haben uns nun auf zusammenhänge Disaster-Recovery Methoden fokussiert:

  1. Database Recoevry
  2. Database Portability
  3. Dial Tone Portability

Database Recovery

Den alten Exchange Server haben wir vom Mailflow getrennt und gestartet. So konnten wir sicher sein das keine Nachrichten mehr verarbeitet werden. Nachdem das System gestartet war (Zeitfenster in etwa 5 Minuten), wurde die gemountete Datenbank dismounted!

Yippihe wir haben einen „Clean Shutdown“ :)!

Clean Shutdown of Exchange Database

Da eine Kopie der Datenbankdatei über Windows ausgeschlossen wurde, da unser Zeitfenster nur beschränkt war. Haben wir das System in den Wartungsmodus versetzt und heruntergefahren.

Im nächsten Schritt wurde die VM-Disk an das neue System gehangen und wir konnten die relevanten Datenbankdateien kopieren!

Perfekt, zum einem einen Clean Shutdown zum anderen alle aktuellen Daten, inklusive der Mails zwischen dem letzten Full und heute!!!

Als nächstes habe ich auf dem neuem Exchange Server 2019 folgendes getan:

New-MailboxDatabase -Name MDB05 -EdbFilePath E:\MDB05\MDB05.edb -LogFolderPath F:\MDB05\

Set-MailboxDatabase MDB05 -AllowFileRestore $true

-AllowFileRestore

Der Parameter AllowFileRestore gibt an, ob eine Datenbank aus einer Sicherung wiederhergestellt werden kann. Gültige Werte sind:

  • $true: Sie können eine vorhandene Datenbank durch eine neu erstellte Datenbank ersetzen. Sie können eine Datenbank einbinden, die nicht mit dem Datenbankeintrag in Active Directory übereinstimmt.
  • $false: Sie können eine vorhandene Datenbank nicht durch eine neu erstellte Datenbank ersetzen. Sie können keine Datenbank einbinden, die nicht mit dem Datenbankeintrag in Active Directory übereinstimmt. Dies ist der Standardwert.

Database Portability

Damit habe ich erreicht das ich die Datenbankdatei ersetzen kann:

  • Filecopy der alten DB-Datei in den neuen DB-Ordner (E:\MDb05\
  • Rename der alten Datendatei in MDB05.edb
  • Filecopy der DB-Logdaten in den neuen Logordner (F:\MDB05)

Nun konnte ich die Datenbank auch tatsächlich Mounten!!! :)

Die Datenbankportabilität ist ein Feature, mit dem eine Exchange-Postfachdatenbank auf einen beliebigen anderen Exchange-Postfachserver in derselben Organisation verschoben und eingebunden werden kann. Mithilfe der Datenbankportabilität wird die Zuverlässigkeit verbessert, indem auf verschiedene fehleranfällige manuelle Schritte bei den Wiederherstellungsprozessen verzichtet werden kann. Darüber hinaus verringert die Datenbankportabilität die Gesamtwiederherstellungsdauer für verschiedene Fehlerszenarien.

Genaue Anweisungen zur Verwendung der Datenbankportabilität finden Sie unter Verschieben einer Postfachdatenbank mithilfe der Datenbankportabilität.

Dial Tone Portability

Puhh, das war geschafft! Server läuft und die Datenbank ist ebenfalls gemountet. Nun haben wir folgende Situation:

  • Postfach der Benutzer mit Verweis auf die alte Datenbank, der User kann nicht arbeiten!
  • Die kopierte Datenbank ist gemounted und darin befinden sich auch die Postfächer!
    • get-MailboxStatistics -Database MDB05

Get-MailboxStatistics from Recoverd Database

Nun müssen wir die Postfächer aus der wiederhergestellten Datenbank wieder mit den Usern verknüpfen. Dazu müssen die Postfächer auf einer neuen Datenbank hosten.

Get-Mailbox -Database MDB01  | Set-Mailbox -Database MDB03

oder für einen einzelnen User (zum testen):

Set-Mailbox „Andres Sichel“ -Database MDB03

Damit wird für alle User aus der alten Defekten Datenbank (MDB01) eine neue leere Mailbox in der Datenbank MDB03 erstellt. Die Exchange GUID bleibt bestehen!!!

Anschließend muss die Mailbox wiederhergestellt werden:

New-MailboxRestoreRequest -Name „Andres Sichel“ -SourceDatabase MDB05 -SourceStoreMailbox „Andres Sichel“ -TargetMailbox „Andres Sichel“ -LargeItemLimit 500 -AcceptLargeDataLoss

Was passiert bei diesem Befehl?

  • Es wird ein Wiederherstellungsprozess gestartet
  • Der Name lautet „Andres Sichel“
  • Die Quelle ist die portierte Datenbank MDB05 / ehemals MDB01
  • Das Ziel ist die rehomed Mailbox auf der MDB03
  • LargeItemLimit ist 500 – Maximal zulässige große Elemente, bei mehr als 51 muss zudem „-AcceptLargedataLoss“ angegeben werden
  • AcceptLargeDataLoss gibt an das der Kopiervorgang fortgesetzt wird, auch wenn eine große Anzahl an zu großen Elementen nicht kopiert werden kann

Der User Andres Sichel ist nun wieder arbeitsfähig und sein Postfach füllt sich mit den Inhalten.

Ich habe auch versucht dem User direkt seine Mailbox aus der wiederhergestellten Datenbank zu vergeben, das hat leider nicht geklappt. Weil:

  • OS muss identisch sein (hier nicht der Fall)
  • Exchange Version muss identisch sein (hier nicht der Fall)

Der Vorgang als solches hat funktioniert, jedoch erhält man mit Outlook keinen Zugriff und OWA meldet folgendes:

Microsoft.Mapi.MapiExceptionWrongServer

Alle Restore Requests waren erfolgreich. Die User können wieder Arbeiten!

Weitere Aufgaben sind nun:

  • MailFlow wiederherstellen
  • Systempostfächer umziehen / Set-Mailbox -Database
  • Zugriffe von extern wiederherstellen – Firewall anpassen
  • Eventuelle Serverkonfigurationen vom alt System übernehmen
  • Altsystem aus der Organisation entfernen

Fazit Exchange Disaster Recovery

Es ist schon herausfordernd in einer unbekannten Infrastruktur die korrekten Schritte in der richtigen Reihenfolge zu tätigen. Gerade auch nach der Analyse und bei der Ausgangsituation den Kunden wieder arbeitsfähig zu bekommen. Sicherlich hätte ein korrekt konfiguriertes Backup unterstützen können. Andernfalls ist eine DAG immer eine Überlegung wert! Diese hätte hier ggf. viel Zeit gespart.

Weshalb der hier genannte Server so eingefroren ist haben wir nicht mehr herausfinden können. Immerhin hat der Verantwortliche das Backup nun sauber konfiguriert!

Achtet bitte immer auf ein funktionierendes Backup. Zudem sollten Updates nicht unbedingt unmittelbar installiert werden, gerade nicht für Single Exchange Server ;)

Für meine Mitarbeiter war die Aktion eine gute Learning-Session. Exchange Datenbanken und Reparatur-Optionen durchzusprechen und in Zukunft auch unsere Kunden  präventiv Beraten zu können.

Der Kunde will, kann oder darf im übrigen NICHT in eine Managed Exchange Server Lösung migrieren. Er erhält dafür von uns nun eine DAG installiert. Neue Serverhardware ist dort ab jetzt wohl auch im Gespräch. Auch wenn es ein kleiner Kunde ist, mit wenigen Mitarbeiter. In summe hat die Aktion nun drei Tage angedauert, was für den Kunden wohl drei Tage Zuviel waren. Zumindest im Hinblick auch den Verzicht von Mails.

Gruß Andi

PS: Am 06.12.2024 findet noch eine Exchange User Group OWL statt –>Zur anmeldung!