Exchange Server: EventID 40025 (MSExchangeIS)

Wer das Ereignis mit der ID 40025 in den Ereignisanzeige eines Exchange Servers entdeckt, hat erst einmal keinen direkten Grund zur Sorge, sollte aber handeln:

Quelle: MSExchangeIS

ID: 40025

Database “Database Name” („Database GUID”) has been offline-repaired (by eseutil.exe) one or more times in the past. However, although this ensures database-level logical consistency and may permit the database to be successfully mounted, Exchange-level logical consistency can no longer be guaranteed. Therefore, all mailboxes should be evacuated from the database and the database should be retired as soon as possible in order to eliminate the potential for unexpected behaviour caused by Exchange-level logical inconsistency.

This event will continue to be emitted once per hour while the database is mounted as an urgent reminder to evacuate and retire the database as soon as possible.

 

EventID 40025 (MSExchangeIS)

Die im Ereignis angegebene Datenbank wurde wahrscheinlich schon einmal aus einer Sicherung wiederhergestellt, oder mittels ESEUTIL nach einem Absturz wiederbelebt. Ursache für das Ereignis 40025 ist, dass jeder Reparaturversuch mittels ESEUTIL den Repair Count erhöht, sobald der Repair Count größer als 0 ist, wird das Event 40025 stündlich in das Protokoll geschrieben.

Der Repair Count mittels ESEUTIL geprüft werden, dazu muss die Datenbank allerdings offline sein:

eseutil /mh .\MDB1.edb | Select-String "Repair"

ESEUTIL Rapair Count

Wenn die Datenbank nicht ohne weiteres runtergefahren werden kann, kann auch der Schalter /vss benutzt werden, damit klappt die Abfrage bei einer eingebundenen Datenbank:

eseutil /mh /vss .\MDB1.edb | Select-String "Repair"

ESEUTIL Rapair Count

Hintergrund ist eine überarbeitete Support Policy von Microsoft. Die Kurzfassung: Mit ESEUTIL bearbeitete Datenbanken sollten nicht länger als unbedingt nötig in Betrieb bleiben. Es muss also eine neue Datenbank angelegt und die Postfächer aus der alten Datenbank in die neue Datenbank verschoben werden.

Hier der Originalartikel zu geänderten Support Policy:

Um den Fehler zu beheben, kann eine neue Mailboxdatenbank angelegt werden. Alle Postfächer der alten Datenbank können dann ohne Unterbrechung in die neue Datenbank verschoben werden.

Das Verschieben der Postfächer ist zum Beispiel mit den folgenden Befehlen möglich:

get-mailbox -Database MDB1 -ResultSize unlimited | New-MoveRequest -TargetDatabase MDB_Neu
get-mailbox -Database MDB1 -Arbitration -ResultSize unlimited | New-MoveRequest -TargetDatabase MDB_Neu
get-mailbox -Database MDB1 -Archive -ResultSize unlimited | New-MoveRequest -TargetDatabase MDB_Neu

Mit den 3 Befehlen werden alle Benutzerpostfächer, Systempostfächer und Archivpostfächer aus der Datenbank “MDB1” in die Datenbank “MDB_Neu” verschoben. Falls auch Postfächer für Öffentliche Ordner in der Datenbank gespeichert werden, können diese mit dem folgenden Befehl verschoben werden:

get-mailbox -Database MDB1  -PublicFolder -ResultSize unlimited | New-MoveRequest -TargetDatabase MDB_Neu

Wenn alle Postfächer verschoben wurden, kann die alte Datenbank gelöscht werden.

Kleiner Tipp: Beim Anlegen der neuen Datenbank auf die Limits der alten achten und die neue Datenbank entsprechend anpassen.

Schreibe einen Kommentar