none
Exchange 2016 DB lässt sich nach RecoveryServer nicht mehr einbinden

    Question

  • Hallo zusammen,

    in unserer noch nicht produktiven Exchange Server 2016 (CU6) Umgebung, musste ich einen Exchange Server 2016 miit CU6 neu installieren (Fehlerbeseitigung zwecks Zertifikatszuweisung von Diensten und Dokumentation für den Fall der Fälle).

    Der Server hat den selben Namen (AD-Konto vorher zurückgesetzt) IP-Adresse etc. bekommen. Die Installation mittels "Setup.exe /m:RecoverServer /IAcceptExchangeServerLicenseTerms" verlief fehlerfrei. Des Weiterem ist der Server mit all seinen Einstellungen fertig konfiguriert. Leider lässt sich aber eine Postfachdatenbank (ist nur eine vorhanden auf dem Server) nicht starten. Aktuell fahren Wir keine DAG - bitte nicht schlagen aber die Entscheidung kommt von höhere Ebene.

    Folgenden Ablauf habe ich grob im Vorfeld der Exchange Recover Installation durchgeführt:

    1. Frische Installation von Server 2016 (neue Platte)

    2. Festplatten wieder am ursprünglichen Ort eingebunden (wir haben eine vDisk für DB und eine vDisk für Logs und fahren keine DAG)

    3. Die Logs aus dem ursprünglichem Ordner entfernt und sicherheitshalber temporär anderweitig abgelegt

    Nach der Exchange Installation und dem Versuch die Postfachdatenbank zu starten werden auch neue Logs erstellt, aber der Vorgang wird mit einem Fehler beendet.

    Fehler beim Einbinden der Datenbank "PFMailbox_DB". 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) 

    Vielen Dank für Eure Tipps

    MfG Paul


    • Edited by Lexxitus Wednesday, December 20, 2017 1:14 PM
    Wednesday, December 20, 2017 1:12 PM

Answers

  • Moin. ich ergänze mal: Die echte Fehlermeldung steht im Eventlog. Exchange zeigt nur den letzten Fehler an, meistens steht der richtige Grund in einer Meldung davor. Ich tippe mal darauf, dass die Datenbank nicht mit dem Haken, „darf aus Widerherstellung überschrieben werden“ gekennzeichnet ist.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Marked as answer by Lexxitus Thursday, December 21, 2017 11:22 AM
    Wednesday, December 20, 2017 6:23 PM

All replies

  • Hallo,

    ich interpretiere es so, dass keine Transaktionslogs wiederhergestellt wurden?

    Damit die wiederhergestellte Datenbank gemountet werden kann, müssen auch alle notwendigen Logs wieder vorhanden sein. Eseutil.exe zeigt an, welche Logs mindestens wiederhergestellt sein müssen.

    Eseutil LogFiles


    Grüße Steve (P.S.: War die Antwort hilfreich, dann bitte links markieren.)

    Wednesday, December 20, 2017 2:59 PM
  • Moin. ich ergänze mal: Die echte Fehlermeldung steht im Eventlog. Exchange zeigt nur den letzten Fehler an, meistens steht der richtige Grund in einer Meldung davor. Ich tippe mal darauf, dass die Datenbank nicht mit dem Haken, „darf aus Widerherstellung überschrieben werden“ gekennzeichnet ist.

    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    • Marked as answer by Lexxitus Thursday, December 21, 2017 11:22 AM
    Wednesday, December 20, 2017 6:23 PM
  • Hallo Robert,

    ich habe die DB mit der Option versehen das Sie überschrieben werden kann und vorher die DB & Logs aus dem Backup im urpsünglichen Ort wiederhergestellt. Die DB konnte wieder eingebunden werden.

    Eine Frage noch:

    Wenn im Fall der Fälle ich einem Exchange Server neu installieren muss (Recover Install) und vorher sauber herunterfahren konnte, dann können die Daten der DB (DB & Logs etc.) verbleiben, oder? Verstehe noch nicht ganz, warum mir unser Externer (aktuell im Urlaub) wollte, das ich die Logs lösche.

    MfG Paul

    Thursday, December 21, 2017 11:27 AM

  • Wenn im Fall der Fälle ich einem Exchange Server neu installieren muss (Recover Install) und vorher sauber herunterfahren konnte, dann können die Daten der DB (DB & Logs etc.) verbleiben, oder? Verstehe noch nicht ganz, warum mir unser Externer (aktuell im Urlaub) wollte, das ich die Logs lösche.

    MfG Paul

    Die Frage, ob die Logs noch benötigt werden oder nicht, kann man nicht ohne Blick mit eseutil /mh auf die nichtbereitgestellte Datenbank klären.

    Ist der Status "Clean Shutdown" werden keine Log-Dateien mehr benötigt. Bei "Dirty Shutdown" werden noch Exx.log, Exx.chk und die Log-Dateien mit den Nummer benötigt, die eseutil /mh anzeigt.

    Technisch gesehen kann man die Log-Dateien löschen, wenn die Datenbank "Clean Shutdown" ist. Es braucht dann nur noch die EDB-Datei.

    Löscht man die Log-Dateien und die *.chk-Datei!), dann beginnt die ESE mit der Zählung der Log-Dateien wieder bei "0". Vorteil ist, dass Seiteneffekte aus veralteten Dateien verhindert werden (daher findet man die Anweisung auch im Support von MSFT bei manchen Exchange Reparaturen). Nachteil ist, dass alle alten Backups unbrauchbar geworden sind und man nun als allerestes ein neues Vollbackup anlegen muss.

    Ob es in Deinem konkreten Fall notwendig war, die Log-Dateien zu löschen, kann man im nachhinein schwer feststellen. Definitiv ist es bei einer intakten Datenbank aber auch kein Problem.

    Ich persönlich lösche sie im Zweifelsfall auch eher, als dass ich sie stehen lasse.


    Gruesse aus Berlin schickt Robert - MVP Office Servers and Services (Exchange Server)

    Thursday, December 21, 2017 11:52 AM