Datenbank lässt sich nicht einbinden

Hallo Erik,

du hast ja bereits ein Hardrecovery der Datenbank durchgeführt. Hast du danach alle Dateien aus dem Verzeichnis (bis auf die EDB-DJatei natürlich) aus dem Verzeichnis gelöscht? Kannst du einmal den aktuellen Status von eseutil /mh posten?

Gruß,

Frank

Hallo Frank,

ich habe nach dem Hardrecovery alle Dateien bis auf den Ordner da raus gelöscht! Darf der drin bleiben oder auch raus?

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
Database: C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\AllUser\alluser.edb

DATABASE HEADER:
Checksum Information:
Expected Checksum: 0x8394ac80
Actual Checksum: 0x8394ac80

Fields:
File Type: Database
Checksum: 0x8394ac80
Format ulMagic: 0x89abcdef
Engine ulMagic: 0x89abcdef
Format ulVersion: 0x620,20
Engine ulVersion: 0x620,20
Created ulVersion: 0x620,20
DB Signature: Create time:07/26/2019 14:08:09.642 Rand:1622008791 Computer:
cbDbPage: 32768
dbtime: 280 (0x118)
State: Dirty Shutdown
Log Required: 636516-636623 (0x9b664-0x9b6cf)
Log Committed: 0-636624 (0x0-0x9b6d0)
Log Recovering: 0 (0x0)
GenMax Creation: 10/23/2019 19:59:41.753
Shadowed: Yes
Last Objid: 5
Scrub Dbtime: 0 (0x0)
Scrub Date: 00/00/1900 00:00:00
Repair Count: 0
Repair Date: 00/00/1900 00:00:00.000
Old Repair Count: 0
Last Consistent: (0x0,0,0) 00/00/1900 00:00:00.000
Last Attach: (0x1,1,268) 07/26/2019 14:08:09.658
Last Detach: (0x0,0,0) 00/00/1900 00:00:00.000
Last ReAttach: (0x960B2,2,268) 08/24/2019 17:45:07.628
Dbid: 1
Log Signature: Create time:07/26/2019 14:08:09.549 Rand:4140400809 Computer:
OS Version: (6.2.9200 SP 0 NLS ffffffff.ffffffff)

Previous Full Backup:
Log Gen: 636484-636594 (0x9b644-0x9b6b2) - OSSnapshot
Mark: (0x9B6B3,1,0)
Mark: 10/23/2019 18:01:17.197

Previous Incremental Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000

Previous Copy Backup:
Log Gen: 615819-615922 (0x9658b-0x965f2) - OSSnapshot
Mark: (0x965F3,1,0)
Mark: 08/28/2019 22:00:34.135

Previous Differential Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000

Current Full Backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000

Current Shadow copy backup:
Log Gen: 0-0 (0x0-0x0)
Mark: (0x0,0,0)
Mark: 00/00/1900 00:00:00.000

cpgUpgrade55Format: 0
cpgUpgradeFreePages: 0
cpgUpgradeSpaceMapPages: 0

ECC Fix Success Count: none
Old ECC Fix Success Count: none
ECC Fix Error Count: none
Old ECC Fix Error Count: none
Bad Checksum Error Count: none
Old bad Checksum Error Count: none

Last checksum finish Date: 00/00/1900 00:00:00.000
Current checksum start Date: 00/00/1900 00:00:00.000
Current checksum page: 0

Operation completed successfully in 0.93 seconds.

Ich hoffe du kannst mir irgendwie helfen, das Teil steht seit Freitag still und ich hab aktuell keine idee mehr.

Ich hab heute die Datenbank aus dem Backup zurückgeholt. Gleicher Fehler jedoch, lässt sich kurz Einbinden danach wieder in Fehler.

Allerdings steht jetzt bei eseutil /p Rebuldiung

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 15.00
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating REPAIR mode...
Database: C:\Program Files\Microsoft\Exchange Server\V15\Mailbox\AllUser\alluser.edb
Temp. Database: TEMPREPAIR11100.EDB

Checking database integrity.

The database is not up-to-date. This operation may find that
this database is corrupt because data from the log files has
yet to be placed in the database.

To ensure the database is up-to-date please use the 'Recovery' operation.

Scanning Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|

Rebuilding MSysObjectsShadow from MSysObjects.

Scanning Status (% complete)

0 10 20 30 40 50 60 70 80 90 100
|----|----|----|----|----|----|----|----|----|----|
...................................................

Checking the database.

Meinst ich soll den mal laufen lassen???

Hi Erik

da stehts doch noch...

Veröffentlicht von: @erik-boerner

State: Dirty Shutdown

Solange da kein Clean Shutdown steht, wirst du die weiterhin nicht eingebunden bekommen.

Gruß,
Monthy

Nachtrag: Wenn du (hart) reparierst, immer darauf achten, dass du mindestens nochmal den Platz der eigentlichen DB auf deinem Medium benötigst, da er eine komplette temp. EDB anlegt.

Nachtrag 2: Du kannst auch erstmal eine neue DB anlegen mit leren Mailboxen. So können neue Mails rein und raus gehen. Danach hast du etwas weniger Not und kannst die alte DB als Recovery DB mounten. Wenn das soweit auch passt, kannst du zwischen den Postfächern mergen. Oder du holst dir 3th party Tools, die Problemlos in die kaputte DB schauen können und ziehst dir davon PST Dateien, die du den Usern wieder in die Mailboxen importierst.

Hi Monthy,

Speicher ist genug frei keine Sorge, ich hab jetzt auch 6 Jahre Exchange Erfahrung also kein Neuling nur am Rande. 

Ich hatte die Datenbank schon im Clean Shutdown, danach den Dienst Informationspeicher gestartet, er bindet sie ja automatisch ein.

5 Minuten später ist die wieder im Dirty und gleicher Fehler.

Gruß Erik

Hi Erik,

da scheint die Datenbank ordentlich was abbekommen zu haben. Ich würde in deinem Fall auch erst mal eine Dial-Tone Recovery durchführen damit die Benutzer wieder arbeiten können. Die alten Daten lassen sich dann über eine Recovery Datenbank wiederholen. Für Exchange 2010 hatte ich das Vorgehen hier beschrieben:

https://www.frankysweb.de/exchange-2010-dial-tone-recovery/

Das Vorgehen an sich ist bei Exchange 2013 aber gleich.

Gruß,

Frank

Hi Erik,

im Zweifelsfall das letzte Backup bevor die Probleme anfingen wiederherstellen, wenn es nicht anders geht. Wenn du kein Dialtone machst, dann wäre es noch eine Lösung, den letzten funktionierenden Stand zum laufen zu bekommen und danach alle Benutzer direkt in eine neue DB zu verschieben. Was in der Zwischenzeit an Mails durchs System ist, wäre dann allerdings hinfällig. Das wären in deinem Fall ja schon ein paar Tage = Doof. Daher ist Dialtone eigentlich eine sehr brauchbare Herangehensweise. 

Gruß,
Monthy

Hallo ihr beiden,

danke für die Hilfe, aktueller Stand: Ich hab gestern die Datenbank von letzter Woche (vor dem Fehler) wiederhergestellt. Logs gelöscht und versucht einzubinden.

Dies hat auch erstmal geklappt, aber ich bekomme kein Zugriff mit Outlook oder OWA außer beim Admin Konto, da konnte ich auch Mails versenden, wenn ich darauf antworte kommt die Mail auch zurück aber ich bekomme zusätzlich eine Fehlermeldung unzustellbar:

Ihre Nachricht konnte nicht zugestellt werden, weil sich das Postfach des Empfängers in Quarantäne befindet. Quarantäne befindet. Kontaktieren Sie bitte Helpdesk, wenn das Problem weiterhin auftritt.

Habt Ihr ne Idee warum das so ist? Ich hab das Admin Postfach bereits in eine neue Datenbank verschoben!

Gruß Erik

Update:

Die Datenbank an sich läuft wieder. Nur ein Postfach will nicht (meins) es fliegt immer wieder in die Quarantäne.

Wenn ich Disable-MailboxQuarantine ist es für 10 Sekunden draußen und wird dann wieder in Quarantäne gestellt.

Eine Mitarbeiterin kann per iPad Mails versenden aber nicht empfangen, auch sehr komisch. Das sind so die letzten Fehler die ich beheben muss.

Wenn ihr noch einen Tipp habt gebt mir bescheid. Danke

Gruß Erik

Hallo Erik,

du solltest nach der Wiederherstellung in jedem Fall eine neue Datenbank anlegen und die Postfächer in die neue Datenbank verschieben. Ich denke das wird die Probleme schon lösen. Wiederhergestellte Datenbanken sowie auch Datenbanken die mit eseutil angefasst wurden, werden durch MS nicht unterstützt.

Gruß,

Frank

Hi Frank,

ja ok dies werde ich tun aber das Postfach welches in Quarantäne ist kann ich ja nicht in eine neue Datenbank verschieben?

Wie gehe ich da am besten vor? Es lässt sich immer nur kurzzeitig aus raus holen, das reicht nicht zum migrieren.

Gruß Erik

Hi Erik,

ich würde erst einmal sehen, dass die Maße an Postfächern aus der Datenbank raus kommt. Für das eine Postfach würde ich zunächst ein neues Postfach anlegen, damit zumindest Mail wieder geht. Die Daten können zur Nor aus der Datensicherung kommen. Der scheinbar ziemlich defekten Datenbank würde ich allerdings nicht mehr trauen.

Gruß,

Frank

Hi Frank,

also ich konnte alle Postfächer in eine neue Datenbank migrieren. Wie soll man jetzt mit dem einen Postfach vorgehen??

Gruß Erik

Veröffentlicht von: @erik-boerner

also ich konnte alle Postfächer in eine neue Datenbank migrieren. Wie soll man jetzt mit dem einen Postfach vorgehen??

Ich würde das Postfach per new-mailboxexportrequest exportieren, zusätzlich die kompletten Eigenschaften (inklusive LegExDN), dann disable-mailbox für dieses Postfach durchführen. Als letzten Schritt dann wieder enable-mailbox auf der neuen DB und den LegExDN als X500 Adresse dazupacken. 

Gruß,
Monthy