Exchange-Datenbankfehler untersuchen und beheben

    Exchange-Datebank und LogsBeim Einspielen des CU4 für Exchange 2019 trat beim Installations­schritt Postfachrolle: Postfach­dienst die Fehler­meldung Mapi­Exception­DatabaseError: Unable to mount database (hr=0x80004005, ec=1108) auf. An diesem Beispiel zeige ich, wie man Problemen mit der Exchange-DB auf den Grund gehen kann.

    Während des Updates auf das Cumulative Update 4 (CU4) konnte eine der Datenbanken nicht wieder eingebunden werden, wodurch der gesamte Vorgang scheiterte. Dabei zeigte das Setup folgenden Fehler an:

    "$error.Clear(); […]" ausgeführt wurde: "System.InvalidOperationException: Fehler beim Einbinden der Datenbank "Mailbox Database 1729189166". Fehler: Fehler bei Active Manager-Vorgang: Fehler bei der Datenbankaktion: Fehler bei Vorgang mit folgender Meldung: MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108)

    Datenbankfehler beim Einspielen des CU4 für Exchange 2019

    Der Exchange-Server befand sich anschließend in einem inkonsistenten und funktions­untüchtigen Zustand. Die Dienste liefen zwar soweit, aber Exchange ließ sich weder über die ECP noch über PowerShell ansprechen. Im Eventlog tauchte die obige Fehler­meldung ebenfalls auf.

    Anfang der Fehlersuche

    Wenn eine Datenbank nicht gemountet werden kann, so liegt es nahe, dass mit ihr selbst etwas nicht stimmt. Um dies zu überprüfen, steht das Tool eseutil zur Verfügung. Dazu wechselt man in das Verzeichnis der jeweiligen Datenbank, danach kann sie mit dem Parameter /mh überprüfen:

    eseutil /mh "Mailbox Database 1729189166.edb"

    Überprüfen der Exchange-Datenbank mit eseutil.exe zeigt den Fehler 'Dirty Shutdown'.

    Als State gab das Tool Dirty Shutdown aus. Ob dies nun mit dem Update zusammen­hing oder durch andere Ereignisse verursacht wurde, ließ sich nach­träglich nicht mehr feststellen. Da der Exchange-Server allerdings noch weitere Daten­banken hat und die Fehler­meldung sich nur auf diese eine DB bezog, handelte es sich offenbar um kein globales Problem.

    Da die Datenbank in einem Dirty Shutdown State hängen blieb, bot es sich an, sie mit dem Parameter /p zu reparieren:

    eseutil /p "Mailbox Database 1729189166.edb"

    Reparieren der Exchange-Datenbank mit eseutil.exe

    Das Ergebnis der Reparatur sah recht vielversprechend aus. Mit dem Parameter /mh habe ich die Datenbank wie oben noch einmal überprüft und festgestellt, dass der Status nun auf Clean Shutdown stand.

    Die erneute Überprüfung der Exchange-Datenbank nach der Reparatur mit eseutil zeigt den Status 'Clean Shutdown'

    Daher startete ich die Installation erneut. Zum Glück erkennt das Exchange-Setup, wenn eine vorangegangene Installation schief gelaufen ist und versucht, diese wieder in Ordnung zu bringen. Leider schlug auch dieser Versuch mit der gleichen Fehlermeldung fehl.

    Transaktions-Logs überprüfen

    Ich untersuchte nun, ob die Transaktions-Logs geschrieben werden können und ob das Verzeichnis dafür noch vorhanden war. In früheren Versionen ist es nämlich vereinzelt vorgekommen, dass das Log-Verzeichnis verschwand.

    Dies war hier allerdings nicht der Fall, da Exchange die Logs direkt in das Verzeichnis schrieb, in dem auch die Datenbank lag.

    Transaction-Logs für die Exchange-Datenbank

    Im nächsten Schritt löschte ich alle .log-Dateien, da ich den Verdacht hatte, dass eine von ihnen fehlerhaft sein könnte. Beim nächsten Anlauf gelang die Installation tatsächlich und die Datenbank wurde eingebunden. Es sind bisher keine weiteren Fehler aufgetaucht.

    1 Kommentar

    Timbo sagt:
    4. Februar 2020 - 14:08

    komischer Artikel, zunächst eine schöne Spannungskurve, die drei Sätze am Ende bringen den bis dahin schön geschriebenen Artikel zu einem völlig unprofessionellen nicht zufriedenstellendem Ende, letztlich wurde gar nichts untersucht... das warum und die Frage ob man das so in einer produktiven Umgebung machen würde bleiben