Exchange NOTFALL - Serverdesaster 5.5

Dieser Abschnitt gilt für Exchange 5.5. Wenn Sie einen Exchange 2000 Server haben, sollten Sie die Seite Serverdesaster 2000 lesen. Lesen Sich auch die Einleitung auf der Exchange NOTFALL Seite. Diese Seite trifft zu, wenn ihr Exchange Server defekt ist und sie KEIN Backup haben. Mit einem Backup sollten Sie Restore mit Backup lesen.

Abhängig davon, was von ihrem Exchange Server noch übrig ist müssen sie ein paar Entscheidungen treffen:

  • Sind die die Datenbanken (PRIV.EDB, PUB.EDB, DIR.EDB) noch vorhanden
    dann sollte unter Ziel sein, diese irgendwie  wieder lesbar zu machen.
    Ob Sie am Ende produktiv gehen, oder nur zum Export der Daten in einen neuen Server ist noch dahingestellt.
  • Sind die Datenbanken nicht mehr vorhanden (Festplatte komplett entfallen), dann können wir nur versuchen, von den Clients Daten zu erhalten.
  • Wenn der Server nicht mehr funktioniert, weil andere Systeme (z.B. die Domäne) verloren gegangen sind, ist deren Wiedergewinnung das Ziel.

Entsprechend finden Sie nun drei Abschnitte, die ihnen Hinweise für das Recovery gehen. Und schreiben, was möglich ist und was nicht und einige Tricks.

Datenbanken wieder online nehmen.

Wenn sie noch die Datenbanken haben, sollte unter erstes Ziel sein, diese wieder ans Leben zu bringen oder zumindest die Inhalte zu exportieren. Dazu ist es notwendig, diese Dateien mit Exchange zu öffnen oder ein Recoverytool wie Ontrack PowerControls zu nutzen.

Für die folgenden Schritte sollten Sie etwas wissen, wie die Exchange Datenbank funktioniert und welche Dateien dazu gehören (-> Datenbankgrundlagen). Und dann ist wichtig, dass eine Exchange Datenbank nur dann von Exchange geöffnet werden kann, wenn folgende Voraussetzungen stimmen:

  • Name der Organisation
    Hierbei zählt der interne Name und nicht der Displayname. Vielleicht haben Sie ja noch eine Kopie der Registrierung des alten Servers oder einen zweiten Exchange Server in der Organisation, aus der Sie diese Information auslesen können. Ansonsten müssen Sie eben zweimal Exchange installieren
  • Name des Standorts
    Hier gilt das gleiche wie für die Organisation
  • Name  des Servers
    Zumindest den sollten Sie schon noch wissen. Ansonsten können Sie mit dem Servermanager in der Domäne nachsehen.
  • SID des Dienstkonto
    Solange ihre Domäne noch funktioniert und Sie das Dienstkonto nicht gelöscht haben ist diese Information problemlos vorhanden. Wenn Sie aber nicht mehr wissen, welches Dienstkonto verwendet wurde, heißt es später "Trial and Error"
  • Laufwerkspfade müssen übereinstimmen
    Das ist besonders wichtig, wenn die Datenbank "inkonsistent" ist und die Protokolldateien eingespielt werden müssen.
  • Gleiche oder höherer Exchange Version
    Die Datenbank wird je nach Service Pack verändert. Daher muss das Recovery System am besten die gleiche Version sein, wie das ausgefallene Systeme. Notfalls kann auch eine neuere Version eingesetzt werden, wenn gleich dann Fehler durch die zusätzlich erfolgende Konvertierung schwerer aufzufinden sind. Eine ältere Version der Programmdateien ist nicht nutzbar !

Wenn Sie diese Daten nicht können, dann installieren Sie Exchange mit neuen Werten und schauen beim ersten Start nach der Fehlermeldung im Eventlog. Exchange schreibt hier, wie die Organisation und Site heißen müsste und dann dürfen Sie noch mal anfangen.

Wenn den Namen der Organisation oder der Administrativen Gruppe nicht dokumentiert ist und Sie sich die zweimalige Installation ersparen wollen, könenn Sie versuchen aus bestehenden Daten diese Information auszulesen. Wer noch Zugriff auf die Registrierung oder das Active Directory des alten Servers hat, kann hier nach den Werten suchen. (HKLM\System\CurrentControlSet\Services\MSExchangeIS\Parameters). Aber auch in den Protokolldateien und der Datenbank selbst sind die Werte oft zu finden. Eine Volltextsuche nach "/o=" kann helfen, da bei Exchange die Daten in den Protokolldateien als /o=Organisation/OU=Standortname" hinterlegt sind.

Die sichern die Datenbank in ein anderen Verzeichnis und installieren Exchange 5.5 mit dem SETUP. Ob Sie hierbei nun ein normales SETUP machen oder ein "SETUP /R" hängt davon ab, ob Sie Konnectoren manuell wieder einrichten wollen. Das Datenbanken können sie bei beiden Setups wieder unterschieben. Beim normalen Setup bekommen Sie zumindest "leere" Datenbanken für DIR.EDB, PRIV.EDB und PUB.EDB, was speziell dann hilfreich ist, wenn ihre alten Datenbanken nicht komplett wieder da sind.

Nach der Installation von Exchange sind die Dienste zu stoppen, die bestehenden Datenbanken samt LOG und CHK-Datei zu verschieben  und die alten Datenbanken wieder einzustellen.

Es ist eine gute Idee, das Diagnoseprotokoll von Exchange (Eigenschaften des Servers) für den "Start/Beenden" und "Allgemein" des Informationsspeicher (IS) auf Maximum zu setzen und das Eventlog groß genug zu machen. Wenn der Dienst nicht startet, dann ist das Eventlog zugleich erste Anlaufstelle um die Ursache zu finden (z.B. falsch eingegebene Werte für Organisation oder Standort)

Nun können Sie mit "ESEUTIL /MH c:\exchsrvr\mdbdata\priv.edb" (und entsprechend DIR.EDB und PUB.EDB) nachsehen, ob die Datenbanken konsistent sind oder nicht. (Siehe ESEUTIL). Wenn die Datenbanken konsistent sind und alles andere passt, dann sollten Sie die Protokolldateien und CHK-Datei verschieben, so dass nur noch die Datenbanken übrig sind. Eventuell müssen Sie ein ISINTEG /PATCH ausführen, damit einige Zuordnungen in der Datenbank und der Registrierung des Servers neu gesetzt werden. Aber auch dies "lesen" Sie im Eventlog nach.

Sollten die Datenbanken allerdings nicht "Clean Shutdown" sein, dann sind offene Transaktionen in den Protokolldateien, welche beim Start des Store gesucht und eingespielt werden. Hier hängt es nun davon ab, ob Sie die Dateien noch alle haben (welche das sind siehe ESEUTIL) und an der richtigen Stelle liegen (Siehe Eventlog). Legen Sie die Dateien an die richtige Stelle (Eventlog) und starten Sie den Dienst.

Wenn all das nichts hilft, dann liegt der Verdacht nahe, dass der Schaden größer ist und die Datenbanken nicht mehr auf dem normalen Weg "konsistent" gemacht werden können. Ursache können fehlende oder korrupte Protokolldateien (EDB*.LOG) sein oder eine wirklich defekte Datenbank.

Dann bleibt nur noch die Chance, mit ESEUTIL so lange zu reparieren, bis die Datenbank wieder gestartet werden kann (Siehe ESEUTIL). Sie sollten aber auf jeden Fall immer eine "gute" Kopie der defekten Datenbank vorhalten, so dass mehrere Versuche oder spätere externe Hilfe möglich sind. Leider kann ich hierzu keine "Schritt für Schritt" Anleitung liefern, da hier mehr Praxis und Erfahrung zählen als Kommandozeilen. Wenn Sie nach der Reparatur die Datenbank wieder am Laufen haben, dann sollten Sie schnellstens dafür sorgen, die Inhalte zu exportieren (Siehe Exmerge). Nur so wissen Sie, welche Inhalte zuverlässig lesbar sind und den Store nicht wieder zum Absturz bringen. Ob sie die reparierte Datenbank später produktiv nutzen möchten oder nicht müssen Sie sich überlegen. Empfehlungen gibt es kaum. Versteckte Probleme können Sie später zum Wahnsinn bei der Fehlersuche treiben aber ein Neuaufbau mit EXMERGE lässt die Datenbank stark wachsen (-> Wegfall des Single Instance Store). Wer Zeit und Ressourcen hat, kann einen zweiten Server installieren und die Ordner replizieren und Postfächer verschieben

Keine Datenbanken mehr

Schade. Mehr kann man dazu nicht sagen, denn ohne Datenbanken keine Daten zum Restaurieren. Aber trotzdem muss nicht alles verloren sein. Es gibt mehrere Stellen, an denen Sie "suchen" können um, den Informationsverlust zu minimieren:

  • PST-Dateien
    Wenn Sie viel Glück haben, dann haben ihre Anwender ihre Nachrichten gar nicht auf dem Server liegen, sondern auf lokalen PST-Dateien. Das sollte normalerweise gerade nicht der Fall sein beim Einsatz von Exchange Server, aber in dieser Situation ein Glücksfall.
    Sie können die Informationen auf dem PC einfach weiter nutzen, nach der Installation eines neuen Servers.
  • Datenbank weg, Transaktionsdateien vorhanden
    Dann können Sie Glück haben und über ein kontrolliertes Roll Forward die Datenbanken wieder herstellen. Aber das ist eher unwahrscheinlich, denn Exchange 5.5 löscht die Protokolldateien (Circular Logging). Daher gilt für 99% aller Fälle, dass die Transaktionsdateien nur hilfreich sind, um ein Backup der letzten Nacht zu restaurieren und die Änderungen des Tages nachzuziehen. Aber auch das gilt nur, wenn die Protokolldateien nicht gelöscht werden. Bei Exchange 2000 ist eben Sie nun Standard und zugleich auch Risiko (Siehe Festplatte voll)
  • Offline Ordner
    Vielleicht haben Sie Glück, dass einige Mitarbeiter so genannte Offline Ordner auf Notebooks nutzen. Dann können Sie hier versuchen, einen Teil der Daten "offline" in PST-Dateien zu exportieren und später wieder zusammen zu führen.
  • Replikate von Ordnern
    Für öffentliche Ordner gibt es zu den OST-Dateien noch eventuell Replikate auf anderen Servern, die möglichst schnell zu sichern sind. Schließlich könnten Diese beim Neuinstallieren des Server mit "weg repliziert" werden.

Sie erkennen aber schon, dass der Verlust der Datenbanken ohne Backup immer einen schweren Datenverlust gleich kommt und alle Ansätze den Schaden nur verringern können. Aber als wenn der Datenverlust nicht schon schlimm genug wiegt, können auch Zivil- und Strafrechtliche Folgen folgen. Gerade Finanzämter und Strafverfolgungsbehörden sind sehr ungehalten, wenn wichtige Daten nicht mehr verfügbar sind. Das kann bis zum Vernichten von Beweisen gedeutet werden. Vielleicht reicht solche in Hinweis an den Geschäftsführer, dass die Mittel für eine ordentliche Datensicherung  bereitgestellt werden.

Domäne ist verloren

Der Verlust der Domäne ist für Exchange 5.5 besonders kritisch, da Exchange ein so genanntes "Dienstkonto" nutzt, um zu arbeiten. Das Konto zeichnet sich durch die interne Nummer (SID) aus. Eine neue gleichnamige Domäne oder ein neu angelegter Benutzer mit gleichem Namen hat trotzdem eine unterschiedliche SID und ist damit nicht geeignet.

Wenn Sie keine Möglichkeit mehr haben, die Original Domäne wieder herzustellen, dann können Sie auch nicht mehr Exchange restaurieren aber wenn ihr Exchange noch läuft, dann kann ein Trick helfen

  • Exchange kann noch administriert werden
    Windows "cached" Benutzerdaten, so dass auch ohne DC es möglich sein kann, das Sie mit dem Exchange Administrator ihr Verzeichnis administrieren können.
    Dann sollten sie als erstes die DIR.EDB "entsichern". Dies passiert, indem Sie auf den Objekten für die Organisation, Standort und Konfiguration alle Berechtigungen LöSCHEN.  Wenn alle Rechte "entfernt" sind, haben ALLE Benutzer Rechte. Nun können Sie Exchange in die neue Domäne aufnehmen und dann die Rechte wieder zurecht biegen. (siehe Dienstkonto ändern auf Exchange Verschieben, umbenennen, umbauen.)
  • Exchange ist nicht mehr zu starten
    Dann hilft ihnen die Information, dass es eigentlich die DIR.EDB ist, welche von der SID abhängt. Insofern können Sie die PRIV.EDB und PUB.EDB wegsichern und dann Exchange "frisch" installieren. Die neue DIR.EDB hat nun das neue Dienstkonto und nachdem Sie Exchange dann gestoppt haben, können Sie die Maildatenbanken unterschieben und wieder starten. Durch die IS/DS Konsistenzanpassung werden dann alle Postfächer und Ordner, welche in der Datenbank abgelegt sind auch im Verzeichnisdienst wieder angelegt.
    Aber viel Arbeit bleibt dann noch, denn eine leere DIR.EDB enthält auch andere Mailadresse, keine  Connectoren etc.
    Daher empfehle ich ihnen in diesem Sonderfall einen Fachmann zu rufen.

Sie sehen, dass der Verlust einer Domäne mit Exchange 5.5 nicht zu unterschätzen ist, da die SID Problematik nicht einfach gelöst werden kann. Daher gehört zu einem sicheren Exchange Betrieb immer auch eine Sicherung der Domäne und ab einer bestimmten Firmengröße mehrere Domain Controller. Mit Exchange 2000 wird diese Abhängigkeit noch kritischer.

Weitere Links