Konzepte für die Wiederherstellung von MS Exchange
Werbung
Konzepte für die Wiederherstellung von MS Exchange 5.5 Kapitel 9 aus Microsoft Exchange Server 5.5 verwalten und warten; (Microsoft Press) Microsoft Exchange ist eine sehr stabile und robuste Plattform für das Messaging innerhalb eines Unternehmens, aber dennoch kann es passieren, dass Computer ausfallen, die Stromversorgung unterbrochen wird oder andere Katastrophen eintreten. Sie benötigen also einen Plan zur Wiederherstellung von Exchange bei möglichst kurzen Ausfallzeiten und geringen Datenverlusten. Es ist sehr wichtig, dass ein solcher Plan rechtzeitig ausgearbeitet wird und immer bereit liegt. Falls es einmal zu einer Katastrophe kommen sollte, müssen Sie in der Lage sein, erprobte und zuverlässige Maßnahmen zu ergreifen. Sie dürfen nicht erst dann einen Plan entwerfen, wenn der Notfall bereits eingetreten ist. Dieses Kapitel ist eine Ergänzung zu vorhandenen Onlinedokumentationen und Handbüchern. Es soll Ihnen helfen, einen eigenen Plan zur Systemwiederherstellung zu formulieren, zu testen, zu zertifizieren und einzurichten. Sicherungsprogramme anderer Anbieter werden hier nicht behandelt. Allgemeine Anmerkungen Microsoft Exchange ist eine unternehmenskritische Anwendung. Dieses Programm kann mehr Benutzer pro Server und eine größere Datenmenge verwalten als frühere Messagingsysteme mit gemeinsamer Dateinutzung. Mit dem zunehmenden Umfang der Exchange-Konfigurationen wurde jeder einzelne Server immer wichtiger für das Unternehmen, und die Benutzer erwarten inzwischen, dass das System an sieben Tagen pro Woche 24 Stunden lang zur Verfügung steht. Dennoch sind in vielen Unternehmen bisher nur sehr unzureichende Maßnahmen zur Wartung und Systemwiederherstellung eingeführt worden. Da Exchange zur Echtheitsprüfung auf die Sicherheitsmechanismen von Windows NT zurückgreift, müssen die Sicherungs- und Wiederherstellungsfunktionen von Windows NT in einen Plan zur Datensicherung in Exchange miteinbezogen werden. Das Programm NTBACKUP.EXE in Windows NT bietet eine Datensicherung auf Dateibasis und sichert zudem die Windows NT-Registrierung. Mit der erweiterten Version von NTBACKUP.EXE, die zusammen mit Exchange Server 4.0 und höheren Versionen ausgeliefert wird, können die Informationsspeicher und Verzeichnisse in Exchange im laufenden Betrieb gesichert werden, ohne dass das Messagingsystem unterbrochen wird. Exchange Server wurde so konzipiert, dass der Netzwerkbetrieb für die Datensicherung nicht unterbrochen werden muss. Dadurch wird sogar der Datenverkehr im System reduziert, weil die Server sich nicht mehr neu im Netz anmelden und somit keine erneute Echtheitsprüfung durchführen müssen. Der gesamte Informationsspeicher, das Verzeichnis, der MTA und die Systemaufsicht bleiben während der Online-Datensicherung uneingeschränkt in Betrieb. Sie können den Vorgang auch automatisieren und mithilfe des visuellen Zeitplaners WINAT. EXE vorausplanen. (Informationen hierzu finden Sie in Microsoft Windows NT 4.0 Die technische Referenz.) In dem Abschnitt "Beispiel für eine Stapeldatei zur Online-Datensicherung" am Ende dieses Kapitels finden Sie ein Beispiel für eine Stapeldatei, mit der die Exchange-Dienste abgeschaltet und neu gestartet werden. Sie können diese Datei auch für andere Zwecke einsetzen. Wenn Sie allerdings Dateien in Verzeichnissen sichern, auf die auch andere ExchangeDienste für Windows NT zugreifen (beispielsweise die Verzeichnissynchronisation, DX, oder der Microsoft Mail Message Transfer Agent, PCMTA), müssen Sie Exchange zuvor beenden. Was muss gesichert werden? Bei den Datensicherungsprozeduren müssen zwei Arten von Daten aufgezeichnet werden: Benutzerdaten Die Daten in den Informationsspeichern (PUB.EDB und PRIV.EDB), die PST-, OST- und PAB-Dateien sowie die Transaktionsprotokolle. Konfigurationsdaten Die Daten im Exchange-Verzeichnis (DIR.EDB), die Windows NT-Registrierung und verschiedene Unterverzeichnisse im Installationsverzeichnis von Exchange Server (unter Umständen auch Verzeichnisse, die nach dem Ausführen der Exchange-Leistungsoptimierung erstellt wurden). In der folgenden Tabelle sehen Sie die standardmäßigen Verzeichnisse, in denen sich die Datenbankdateien befinden. Auf der Seite Datenbankpfade des Serverobjekts können Sie bei der Installation die Pfade aller Datenbankdateien ändern, indem Sie einen anderen Pfad als den angezeigten Standardpfad (\exchsrvr) auswählen. Mithilfe der Exchange-Leistungsoptimierung können Sie einstellen, dass die Transaktionsprotokolle auf einem anderen physischen Laufwerk gespeichert werden als die Informationsspeicher- und Verzeichnisdateien. Die Daten des Schlüsselverwaltungsservers und die Startdiskette, die bei seiner Installation erstellt wird, werden von dem Online-Sicherungsprogramm nicht automatisch gesichert. Sie müssen dies manuell erledigen. Die Daten des Schlüsselverwaltungsservers in Exchange 5.5 befinden sich im Verzeichnis exchsrvr\kmsdata. (In Exchange 4.0 und 5.0 befinden Sie sich in dem Verzeichnis \security.) Standardmäßige Verzeichnisse der Datenbankdateien in Exchange Komponente Informationsspeicher Datei Privat Öffentlich Standardpfad \exchsrvr\mdbdata\PRIV.EDB \exchsrvr\mdbdata\PUB.EDB Verzeichnis \exchsrvr\dsadata\DIR.EDB Transaktionsprotokolle Informationsspeicher \exchsrvr\mdbdata\*.LOG Verzeichnis \exchsrvr\dsadata\*.LOG Exchange 4.0 und Schlüsselverwaltungsserver C:\security 5.0 Exchange 5.5 \exchsrvr\kmsdata Zusätzlich zu diesen Daten sollten sie regelmäßig Folgendes sichern: Die Windows NT-Registrierung Sie enthält die Konfigurationsinformationen für die Exchange-Dienste und für die SAM-Datenbank (Security Accounts Manager), in der das Dienstkonto von Exchange gespeichert ist. Daten in den Unterverzeichnissen von "\exchsrvr" Hier sind beispielsweise das Verzeichnis der Datei TRACKING.LOG wichtig, das die Aufzeichnungen über das Nachrichtentracking enthält, und das Verzeichnis IMCDATA, das archivierte Nachrichten aus dem Internet enthält, usw. PST-Dateien (Personal Message Store) Stellen Sie sicher, dass alle auf Dateiservern (Basisverzeichnisse) gespeicherten PSTDateien in die Sicherungsroutinen eingeschlossen werden. Wenn eine PST-Datei verloren geht oder beschädigt wird, brauchen Sie sie nur wiederherzustellen und in ein vorhandenes Benutzerprofil einzufügen. Beschädigte PST-Dateien lassen sich auch mithilfe des Programms SCANPST reparieren. Manchmal speichern die Benutzer die PSTDateien auf lokalen Laufwerken, die nicht regelmäßig gesichert werden, oder sie schützen die PST-Dateien durch ein Kennwort, das sie dann vergessen. In beiden Fällen lassen sich die Daten nicht wiederherstellen. Sie müssen dafür sorgen, dass die Benutzer sich dieser Tatsachen bewusst sind. OST-Dateien (Offline Message Store) Die Daten in OST-Dateien sind gefährdet, so lange die Änderungen an lokalen OSTDateien noch nicht in den Informationsspeicher auf dem Server repliziert wurden. Wenn der Computer eines Benutzers nach einer abgeschlossenen Replikation ausfällt, kann auf seinem neuen Computer eine neue OST-Datei erstellt werden, und anschließend können die auf dem Server gespeicherten Informationen durch Synchronisation in die neue OSTDatei eingefügt werden. Beschädigte OST-Dateien lassen sich mithilfe des Programms SCANPST reparieren. PAB-Dateien (Personal Address Book) Die Dateien des persönlichen Adressbuchs können entweder lokal oder in einem Verzeichnis auf dem Server gespeichert werden. Letzteres ist sicherer, da die meisten Server regelmäßig gesichert werden. Wenn Benutzer ihr persönliches Adressbuch lokal speichern, müssen sie selbst für die Datensicherung sorgen. Wenn eine PAB-Datei verloren geht, bedeutet das oft stundenlange Arbeit, während der der Benutzer nicht produktiv für das Unternehmen tätig ist. Outlook - Archivierung und automatische Archivierung In Outlook gibt es die Möglichkeit der automatischen Archivierung von PST-Dateien, und dieses Leistungsmerkmal können Sie in Ihre Strategien zur Datensicherung einbeziehen. Wenn sich auf Ihrem Schreibtisch Papiere ansammeln, müssen Sie gelegentlich aufräumen. Sie sortieren sie und legen diejenigen Papiere ab, die Sie zwar behalten wollen, aber nicht ständig benutzen. Andere Papiere legen Sie aus dem einen Ordner in einen anderen, und alte werfen Sie weg. In Outlook können Sie alte Objekte in eine Speicherdatei verschieben, indem Sie im Menü Datei auf den Befehl Archivieren klicken oder in dem Sie die Funktion AutoArchivierung verwenden, bei der Sie eine Zeitdauer angeben können, nach der die Objekte entweder gelöscht oder verschoben werden. In Outlook können alle Dateien archiviert werden, auch beispielsweise Excel-Tabellen und Word-Dokumente, die als Anlage von Nachrichten empfangen wurden, wenn sie in Nachrichtenordnern gespeichert sind. Die AutoArchivierung läuft in zwei Schritten ab. Klicken Sie im Menü Extras auf den Befehl Optionen und anschließend auf die Registerkarte AutoArchivierung. Stellen Sie für jeden Ordner die Eigenschaften der AutoArchivierung ein, wobei Sie festlegen, welche Objekte archiviert werden (bestimmte Ordner, Ordnergruppen oder alle Ordner) und wann die Archivierung stattfindet. Bei jedem Start von Outlook prüft die AutoArchivierung die Eigenschaften jedes Ordners und archiviert oder löscht ihn, je nach angegebener Einstellung. Einige Outlook-Ordner werden von der AutoArchivierung automatisch behandelt: der Kalender (sechs Monate), die Aufgaben (sechs Monate), das Journal (sechs Monate), der Ordner Gesendete Objekte (zwei Monate) und der Ordner Gelöschte Objekte (zwei Monate). Die Ordner Posteingang, Notizen und Kontakte werden dagegen nicht automatisch behandelt. Bei der Archivierung wird die vorhandene Ordnerstruktur in der neuen Archivdatei beibehalten. Wenn Sie einen Unterordner archivieren, wird bei dem Prozess auch der übergeordnete Ordner in der Archivdatei neu erstellt, aber die Objekte in diesem Ordner werden nicht archiviert. Die Ordnerstruktur des Archivs wird der Struktur des Postfachs nachgebildet. Die Ordner bleiben nach der Archivierung an ihrem Platz, selbst wenn sie leer sind. Im Gegensatz zur Archivierung, bei der die Objekte in persönliche Ordner verschoben werden, werden die ursprünglichen Objekte beim Exportieren in ihren aktuellen Ordnern belassen und es werden nur Kopien in verschiedenen Dateitypen erstellt. Vergessen Sie nicht, auch archivierte Outlook-Dateien in Ihre Strategie zur Datensicherung mit einzubeziehen. Verschiedene Arten der Datensicherung Online und Offline Online-Datensicherung Bei der Onlinesicherung muss der entsprechende Dienst (Informationsspeicher oder Verzeichnisdienst) ausgeführt werden. Das Messaging auf dem jeweiligen Exchange-Server wird nicht unterbrochen. Sie können auch die Windows NT-Registrierung in die Sicherung einschließen, und Sie können den Verzeichnisdienst selbst dann sichern, wenn der Informationsspeicher nicht ausgeführt wird. Offline-Datensicherung Bei der Offlinesicherung müssen alle Exchange-Dienste beendet werden. Sie wird auf Dateibasis durchgeführt. Sie führen dazu einfach NTBACKUP aus, um alle Dateien auf den ausgewählten Laufwerken zu sichern, einschließlich der Windows NT-Registrierung. Verschiedene Arten der Online-Datensicherung Normal (Vollständig) Mit dieser Methode werden die gesamten Informationsspeicher- und Verzeichnisdatenbanken gesichert. Die Transaktionsprotokolle werden zuerst gesichert und dann gelöscht. Sie bilden den Kontext für die schrittweisen und die Differenzsicherungen (siehe unten). Kopieren Mit dieser Methode werden weder Protokolldateien gelöscht noch der Kontext für die schrittweise oder die Differenzsicherung verändert. Es wird eine Momentaufnahme der Datenbanken erstellt, ohne andere Sicherungsroutinen auszulösen bzw. zu beeinflussen. Diese Methode ist sehr gut geeignet, wenn Sie den Zustand eines Systems für Testzwecke reproduzieren wollen. Hinzufügen (Schrittweise) Mit dieser Methode wird ein Teil des Informationsspeichers oder der Datenbank gesichert, wobei nur die Änderungen seit der letzten vollständigen bzw. schrittweisen Sicherung aufgezeichnet werden (je nachdem, welcher Vorgang zuletzt durchgeführt wurde). Bei einer schrittweisen Sicherung werden (nur) die Protokolldateien auf das Band geschrieben und anschließend von der Festplatte gelöscht, so dass der Kontext für die nächste Sicherung gesetzt wird. Bei der Wiederherstellung schrittweise gesicherter Daten benötigen Sie in der Regel das Band der letzten vollständigen Sicherung sowie die Bänder jeder einzelnen darauffolgenden schrittweisen Sicherung bis zu dem Zeitpunkt des Systemausfalls. Nehmen Sie beispielsweise an, jeden Sonntagabend würde eine vollständige Sicherung durchgeführt und an jedem Wochentag eine schrittweise Sicherung. Wenn das System am Freitagmorgen ausfällt, müssen Sie zuerst die vollständige Sicherung vom Sonntag wiederherstellen (so dass das System bis zu dem Zustand am Sonntagabend wiederhergestellt wird). Anschließend müssen Sie die schrittweisen Sicherungen der Reihe nach wiederherstellen (so dass das System den Zustand am Donnerstag wieder erreicht). Die Dienste dürfen erst gestartet werden, wenn die letzte schrittweise Sicherung wiederhergestellt wurde. Wenn die Umlaufprotokollierung (zirkuläre Protokollierung) aktiviert ist, ist die schrittweise Sicherung deaktiviert. Weitere Informationen zu diesem Thema finden Sie im Abschnitt "Protokolldateien und Umlaufprotokollierung" weiter hinten in diesem Kapitel. Differenzsicherung Mit dieser Methode werden die Änderungen im Informationsspeicher und/oder Verzeichnis seit der letzten vollständigen oder schrittweisen Sicherung gesichert, obwohl die meisten Administratoren in einer Sicherungsreihe normalerweise schrittweise und Differenzsicherungen nicht gemischt einsetzen. Bei einer Differenzsicherung werden nur die Protokolldateien aufgezeichnet, sie werden aber nicht von der Festplatte gelöscht. Wenn die Transaktionsprotokolle und Datenbanken wiederhergestellt werden müssen, brauchen Sie in diesem Fall nur zwei Bänder: die letzte vollständige Sicherung und die letzte Differenzsicherung. Wenn die Transaktionsprotokolle seit der letzten vollständigen Sicherung noch intakt sind, brauchen Sie sogar nur das Band der letzten vollständigen Sicherung, weil bei dem Prozess der Wiederherstellung alle Protokolle seit der letzten vollständigen Sicherung durch die aktuelle EDB.LOG-Datei abgespielt werden, so dass die Transaktionen bis zum aktuellen Zeitpunkt wiederhergestellt werden. In diesem Fall dürfen Sie bei der Wiederherstellung auf keinen Fall die Option Alle bestehenden Daten löschen aktivieren, weil mit dieser Option alle Protokolldateien bis zum aktuellen Zeitpunkt gelöscht werden. Wenn die Umlaufprotokollierung aktiviert ist, ist die Differenzsicherung deaktiviert. Weitere Informationen zu diesem Thema finden Sie im Abschnitt "Umlaufprotokollierung der Datenbankdateien" weiter hinten in diesem Kapitel. Protokolldateien und Umlaufprotokollierung Grundlagen der Protokollierung Exchange Server unterhält mehrere Datenbanken (Speicher) in einer für den Benutzer transparenten Struktur. Der Informationsspeicher besteht beispielsweise aus zwei Datenbanken, dem privaten Informationsspeicher (PRIV.EDB) und dem öffentlichen Informationsspeicher (PUB.EDB), die beide vom Informationsspeicherdienst verwaltet werden. Das Exchange-Verzeichnis ist in der Datei DIR.EDB gespeichert. Für jede dieser Datenbanken gibt es in Exchange Server eine Transaktionsprotokolldatei. Die Datenbank-Technologie von Exchange Server implementiert Protokolldateien, die die Daten aufzeichnen, überprüfen und pflegen. Zur Erhöhung der Leistung und zur Erleichterung der Systemwiederherstellung werden alle Nachrichtentransaktionen zuerst in die Protokolldateien geschrieben und im Speicher gehalten und erst dann in die entsprechenden Datenbanken eingetragen. Die Leistung des Clients wird dadurch gesteigert, dass die Protokolldateien sequenziell geschrieben werden (so dass keine Suchzeiten anfallen) und dass die Nachrichtentransaktionen in Exchange Server sofort in die Protokolldateien geschrieben werden. Die Einträge werden allerdings immer am Ende der Protokolldatei hinzugefügt. Bei den Datenbankdateien von Exchange (PUB.EDB, PRIV.EDB und DIR.EDB) werden dagegen Datensätze an bestimmten Positionen abgelegt, so dass die Leistung durch die Suchzeit beeinflusst wird. Auch die Systemwiederherstellung wird erleichtert, weil bei einer Beschädigung des Informationsspeichers oder des Verzeichnisses bei einem Hardwarefehler Daten über die Nachrichtentransaktionen aus den Protokolldateien gewonnen werden können, vorausgesetzt diese wurden gesichert und sind intakt. Die Protokolldateien werden in der Regel auf einem anderen Laufwerk gespeichert als die Datenbankdateien des Informationsspeichers und des Verzeichnisses, damit sie bei einem Fehler, der die Datenbankdateien beschädigt, erhalten bleiben. Alle noch nicht gesicherten Daten, die in den Transaktionsprotokollen aufgezeichnet wurden, können zur Wiederherstellung der Datenbankdateien abgespielt werden. Die Dienste des Verzeichnisses und des Informationsspeichers verwenden Transaktionsprotokolldateien, vorherige Protokolldateien, Checkpointdateien, reservierte Protokolldateien und Patchdateien. Transaktionsprotokolle Die Transaktionsprotokolle können auf einem anderen physischen Laufwerk gespeichert werden als die zugehörigen EDB-Dateien. Standardmäßig werden die Protokolldateien der Informationsspeicher im Verzeichnis \exchsrvr\mdbdata gespeichert und die des Verzeichnisdienstes im Verzeichnis \exchsrvr\dsadata. Jedes dieser Unterverzeichnisse enthält eine Edb.log-Datei, die das aktuelle Transaktionsprotokoll des jeweiligen Dienstes ist. Im Unterverzeichnis des Informationsspeichers und des Verzeichnisdienstes ist jeweils eine andere EDB.LOG-Datei gespeichert. Die Protokolldateien sollten immer 5 MB groß sein. Wenn sie eine andere Größe haben, sind sie wahrscheinlich beschädigt. Die Transaktionen werden zuerst in die EDB.LOGDateien geschrieben und erst dann in die Datenbank eingetragen, daher setzt sich die tatsächliche Größe der Datenbank aus den noch nicht übertragenen Transaktionen in der Transaktionsprotokolldatei (die ebenfalls im Speicher residieren) und der EDBDatenbankdatei zusammen. Wenn die EDB.LOG-Dateien mit Transaktionsdaten gefüllt sind, werden sie umbenannt, und eine neue EDB.LOG-Datei wird erstellt. Vorherige Protokolldateien Wenn die Datei EDB.LOG umbenannt wird, werden die umbenannten Protokolldateien in demselben Unterverzeichnis gespeichert wie die neue EDB.LOG-Datei. Die Protokolldateien werden der Reihe nach benannt (d.h. EDB00014.LOG, EDB00015.LOG usw., wobei es sich bei den Zahlen in den Dateinamen um hexadezimale Werte handelt). Protokolldateien, deren Daten bereits in die Datenbank eingetragen wurden, werden bei einer normalen (vollständigen) oder einer schrittweisen (Hinzufügen) Sicherung mit NTBACKUP.EXE von der Festplatte entfernt. Es werden aber nicht alle vorherigen Protokolldateien entfernt. Nachdem jeweils 5 MB Transaktionsdaten gespeichert wurden, wird eine neue Protokolldatei erstellt, aber nicht unbedingt in die Datenbank übertragen. Es können immer mehrere vorherige Protokolldateien vorhanden sein, die noch nicht übertragen wurden, und diese Dateien werden nicht entfernt. Wenn die Umlaufprotokollierung aktiviert wird, wird keine Liste der vorherigen Protokolldateien mehr gepflegt, und sie werden bei Sicherungsvorgängen auch nicht mehr entfernt. Bei aktivierter Umlaufprotokollierung sind die schrittweise Sicherung und die Differenzsicherung deaktiviert. Die in den Protokolldateien gespeicherten Transaktionen werden in die entsprechende EDB-Datei übertragen, wenn der Dienst normal beendet wird. Wenn der Informationsspeicherdienst beispielsweise ordnungsgemäß (d.h. ohne Fehler) beendet wird, werden alle Transaktionen aus den Protokolldateien, die weder in der Datei PRIV.EDB noch in der Datei PUB.EDB enthalten sind, in die EDB-Dateien eingetragen. Die Protokolldateien sollten nicht manuell entfernt werden, solange die Dienste ausgeführt werden. Im Allgemeinen sollten Sie die Protokolle am besten während des Sicherungsprozesses entfernen. Checkpointdateien und der Checkpoint Die Checkpointdateien werden zur Übertragung (zum Einspielen) der Daten aus den Transaktionsprotokollen in die EDB-Dateien verwendet. Der Checkpoint ist die Markierung in der Datei EDB.CHK, der anzeigt, welche Transaktionen bereits in die Datenbankdateien übertragen wurden. Der Informationsspeicher- und Verzeichnisdienst unterhalten jeweils eine eigene Checkpointdatei (EDB.CHK). Immer wenn Daten aus dem Transaktionsprotokoll in eine EDB-Datei geschrieben werden, wird die Datei EDB.CHK mit Informationen aktualisiert, die angeben, dass eine Transaktion erfolgreich in ihre zugehörige EDB-Datei übertragen wurde. Bei einer Systemwiederherstellung liest Exchange entweder die Datei EDB.CHK oder direkt die Transaktionsprotokolldateien um festzustellen, welche Transaktionen noch nicht übertragen wurden. Wenn die Protokolldateien direkt gelesen werden, wird die Datei EDB.CHK nicht benötigt. Von den Diensten des Informationsspeichers und des Verzeichnisses wird die Datei EDB.CHK beim Start gelesen, und daraufhin spielen die Dienste alle noch nicht übertragenen Transaktionen aus den Protokolldateien in die EDB-Dateien ein. Wenn beispielsweise ein Exchange-Server ausfällt und einige Transaktionen zwar bereits in die Protokolldateien, aber noch nicht in die Datenbank geschrieben wurden, versucht Exchange beim erneuten Starten das System wiederherzustellen, indem es die Transaktionen automatisch aus den Protokollen in die Datenbankdateien überträgt. Reservierte Protokolldateien Der Verzeichnis- und der Informationsspeicherdienst unterhalten unabhängig voneinander in den Verzeichnissen \dsadata und \mdbdata zwei Reservedateien, RES1.LOG und RES2.LOG. Wenn für die Umbenennung der Datei EDB.LOG und die Erstellung einer neuen Protokolldatei nicht genügend Speicherplatz vorhanden ist, werden diese Reserveprotokolldateien verwendet. Dabei handelt es sich um einen Sicherheitsmechanismus, der nur im Notfall verwendet wird. Danach sendet die Datenbankengine eine Fehlermeldung an den betreffenden Dienst, der dann alle Transaktionen im Speicher, die noch nicht in ein Transaktionsprotokoll geschrieben wurden, in die Datei RES1.LOG und bei Bedarf auch in die Datei RES2.LOG speichert. Anschließend wird der Dienst beendet und ein Ereignis wird in das Ereignisprotokoll von Windows NT geschrieben. (Die RES-Transaktionsprotokolldateien sind wie alle anderen Protokolldateien beide 5 MB groß.) Patchdateien Auch während einer Online-Datensicherung in Exchange können Transaktionen für die EDB-Dateien eingegeben werden. Wenn eine Transaktion für einen Teil einer EDB-Datei eingegeben wird, der noch nicht gesichert wurde, wird die Transaktion ganz normal verarbeitet. Wenn eine Transaktion für einen Teil einer EDB-Datei stattfindet, der bereits gesichert wurde, wird sie in einer PAT-Datei (Patchdatei) aufgezeichnet. Für jede Datenbank wird eine eigene Patchdatei verwendet: PRIV.PAT, PUB.PAT und DIR.PAT. Diese Dateien sind nur während des Sicherungsprozesses vorhanden. Die Patchdateien werden im Sicherungsprozess folgendermaßen eingesetzt: Für die aktuelle Datenbank wird eine PAT-Datei erstellt. Der Sicherungsvorgang für die aktuelle EDB-Datei beginnt. Transaktionen, die in Teile der EDB-Datei geschrieben werden müssen, die bereits gesichert wurden, werden in die EDB- und PAT-Dateien eingetragen. Die PAT-Datei wird auf das Sicherungsband geschrieben. Die PAT-Datei wird aus dem Verzeichnis \MDBDATA oder \DSADATA gelöscht. Die Datei TEMP.EDB In dieser Datei werden Transaktionen gespeichert, die gerade durchgeführt werden. Sie wird als temporärer Speicherplatz während der Onlinekomprimierung verwendet. So bereinigt das Sicherungsprogramm die Protokolldateien Wenn die Umlaufprotokollierung nicht aktiviert ist, sammeln sich die Transaktionsprotokolldateien so lange auf ihrem Festplattenlaufwerk an, bis eine normale (vollständige) oder eine schrittweise Online-Datensicherung durchgeführt wird. In der Sequenz des Sicherungsprozesses findet die Bereinigung der Protokolldateien folgendermaßen statt: Während des Sicherungsprozesses werden die angegebenen Datenbankdateien kopiert. Bei Bedarf werden Patchdateien erstellt (in ihnen werden Transaktionen aufgezeichnet, die während der Datensicherung in einen bereits verarbeiteten Teil der EDB-Dateien geschrieben werden müssten). Die Protokolldateien, die während des Sicherungsprozesses erstellt wurden, werden auf das Band kopiert. Die Patchdateien werden auf das Band geschrieben. Alle Protokolldateien, die älter sind als der Checkpoint zu Beginn des Sicherungsvorgangs, werden entfernt. Sie sind überflüssig geworden, weil die Transaktionen bereits in die EDB-Dateien übertragen wurden und die EDB-Dateien auf das Band gesichert wurden. Umlaufprotokollierung der Datenbankdateien Bei der zirkulären oder Umlaufprotokollierung (die standardmäßig aktiviert ist) werden zwar Transaktionsprotokolle eingesetzt, aber die vorherigen Protokolldateien bleiben nicht erhalten. Es werden nur einige wenige Protokolldateien unterhalten, und nachdem die Transaktionen in die Datenbank übertragen wurden, werden sie zusammen mit den in ihnen enthaltenen Transaktionen entfernt. Auf diese Weise wird weniger Platz auf der Festplatte in Anspruch genommen und es sammeln sich nicht so viele Protokolldateien an, aber dafür können weder schrittweise noch Differenzsicherungen durchgeführt werden, weil dazu die Aufbewahrung früherer Transaktionsprotokolldateien erforderlich wäre. Da bei der zirkulären Protokollierung immer wieder Transaktionsprotokolldateien gelöscht werden, können Sie nach einem Systemausfall oft nicht mehr alle Daten bis zum Zeitpunkt des Ausfalls wiederherstellen, indem Sie die Transaktionsprotokolldateien abspielen, da einige von ihnen bereits fehlen. Aus diesem Grund ist es empfehlenswert, die zirkuläre Protokollierung auf allen Exchange-Servern zu deaktivieren. Wenn Sie regelmäßig Onlinedatensicherungen druchführen, bei denen die Protokolldateien nach der Sicherung ja ebenfalls von der Festplatte entfernt werden, haben Sie auch dann den beanspruchten Speicherplatz unter Kontrolle. Wenn die Umlaufprotokollierung aktiviert ist, sind in den Unterverzeichnissen \DSADATA und \MDBDATA meist mehrere EDBnnnnn.LOG-Dateien vorhanden. Dies ist ganz normal, weil Exchange mehrere Protokolldateien verwendet, bis der Kreislauf wieder von vorne beginnt und die erste Datei gelöscht wird. Wenn zuerst die Dateien EDB00010.LOG, EDB00011.LOG, EDB00012.LOG und EDB00013.LOG vorhanden sind, wird die Datei EDB00010.LOG irgendwann entfernt und eine Datei EDB00014.LOG erstellt, so dass dann EDB00011.LOG, EDB00012.LOG, EDB00013.LOG und EDB00014.LOG vorhanden sind. Die Nummern sind hexadezimal. Bei der Umlaufprotokollierung werden meist vier Protokolldateien erhalten, aber wenn die E/A-Belastung des Servers sehr hoch ist, können auch mehr verwendet werden. Wenn einmal mehr als die anfänglichen vier Protokolldateien erstellt wurden, werden sie erst entfernt, wenn der zugehörige Dienst (Informationsspeicher oder Verzeichnis) beendet und neu gestartet wird. So stellen Sie fest, ob die Umlaufprotokollierung aktiviert ist Wenn Sie die Einstellungen der zirkulären Protokollierung der Datenbank einsehen wollen, gehen Sie folgendermaßen vor 1. Führen Sie das Programm Exchange Administrator aus. 2. Klicken Sie nacheinander auf Standort, Konfiguration und das Objekt Server, und wählen Sie den gewünschten Server aus. 3. Klicken Sie im Menü Datei auf Eigenschaften. 4. Klicken Sie auf die Registerkarte Weitere Optionen. Beachten Sie, dass Sie die Umlaufprotokollierung für Informationsspeicher und das Verzeichnis getrennt einstellen können. Sie können die Einstellungen für die Umlaufprotokollierung über das Programm Exchange Administrator im laufenden Betrieb verändern, aber in diesem Fall wird der betreffende Dienst automatisch beendet und neu gestartet. Beispiel für eine Systemwiederherstellung mit Transaktionsprotokollen Situation: Die Umlaufprotokollierung ist nicht aktiviert, und die Transaktionsprotokolle werden nicht auf derselben Festplatte gespeichert wie die Datenbankdateien. Die letzte normale (vollständige) Sicherung wurde vor zwei Tagen durchgeführt. Die Datenbanken des Informationsspeichers sind durch einen Hardwarefehler (kaputte Festplatte) beschädigt worden, aber das Laufwerk mit den Transaktionsprotokollen ist intakt geblieben. Frage: Ist eine vollständige Wiederherstellung möglich, oder gehen die Daten von zwei Tagen verloren? Antwort: Es gehen keine Daten verloren. Da die Transaktionsprotokolle vollständig sind, enthalten sie alle Transaktionen seit der letzten vollständigen Sicherung, und die Hardware zur Wiederherstellung kann eine vollständige Wiederherstellung durchführen. Entfernen Sie auf keinen Fall die vorhandenen Protokolldateien (d.h. aktivieren Sie nicht die Option Alle bestehenden Daten löschen). Bei der vollständigen Wiederherstellung werden die Datenbankdateien und die Protokolldateien, die bei der letzten vollständigen Sicherung gesichert wurden, auf die neue Festplatte geschrieben. Die wiederhergestellten Protokolldateien sind alle Protokolldateien auf dem Sicherungsband bis zu der ersten Protokolldatei auf dem aktuellen Laufwerk mit den Transaktionsprotokollen. Wenn beispielsweise bei der vollständigen Sicherung die Dateien EDB00012.LOG bis einschließlich EDB00014.LOG auf das Band kopiert wurden, befinden sich auf dem Laufwerk mit den Transaktionsprotokollen jetzt Protokolldateien ab der Nummer EDB00015.LOG. Bei der vollständigen Wiederherstellung werden die Protokolldateien EDB00012.LOG bis EDB00014.LOG sowie die Datenbankdateien in dem Sicherungssatz zurück auf die Festplatte kopiert. Wenn Sie dann den Informationsspeicherdienst starten, werden die Transaktionen aus den Protokolldateien ab EDB00012.LOG bis zur letzten Protokolldatei (EDB00019.LOG) abgespielt und anschließend wird die zuletzt erstellte Datei, EDB.LOG, abgespielt. Dann wird der Dienst neu gestartet, und die Datenbank ist auf dem neuesten Stand. In den Protokolldateien sind Signaturen enthalten, die sie als Teil der Sequenz identifizieren, die abgespielt werden muss. Einen Schlüsselverwaltungsserver sichern Es ist empfehlenswert, die Datendateien der Schlüsselverwaltung (C:\SECURITY\MGRENT in Version 4.0 und 5.0 und \EXCHSRVR\KMSDATA in Version 5.5) getrennt von anderen Daten zu sichern und diese Sicherungskopien an einem noch sichereren Ort aufzubewahren als die normalen Sicherungskopien. Alle Schlüssel in diesen Dateien sind nach 64-Bit-CAST verschlüsselt und daher sehr gut geschützt, aber dennoch sollten Sie sie sehr sicher aufbewahren, denn sie enthalten die privaten Verschlüsselungsdaten aller Benutzer und sie werden von dem Programm NTBACKUP nicht gesichert. Bänder sind insofern ein Problem, als sie offline sind: jeder, der sie in die Hände bekommt, kann die Dateien auf einem Server wiederherstellen und hat dann alle Zeit der Welt, um die Verschlüsselung zu decodieren. Da er sich nicht im System anmelden muss, braucht er nicht zu fürchten, entdeckt zu werden. Für die meisten Hacker ist es technisch praktisch unmöglich, einen 64-Bit-Schlüssel zu knacken. Im Moment wird davon ausgegangen, dass dies sogar mit spezieller Hardware im Wert von etwa 300.000 Dollar über 12 Jahre dauern würde. Mit normaler PCTechnologie dauert es noch weit länger. (Informationen über die Länge von Schlüsseln und die geschätzte Dauer zu ihrer Entschlüsselung sowie über andere Themen in diesem Zusammenhang finden Sie unter: http://www.bsa. org/.) Dies ist die gute Nachricht. Die schlechte Nachricht lautet, dass die Technologie mit jedem Jahr Fortschritte macht und dass es skrupellose Menschen gibt, die zudem sehr schlau und einfallsreich sind. Aus diesem Grund sollten Sie die Datenbank des Schlüsselverwaltungsservers als einen der am sorgfältigsten zu schützenden Werte in Ihrem Informationssystem behandeln. Wenn Sie die Daten des Schlüsselverwaltungsservers sichern wollen, gehen Sie nach folgenden Schritten vor: 1. Beenden Sie den Dienst des Schlüsselverwaltungsservers. 2. Sichern Sie die Daten: In Exchange 4.0 und 5.0 müssen Sie das Verzeichnis SECURITY\MGRENT sichern. IIn Exchange 5.5 müssen Sie das Verzeichnis EXCHSRVR\KMSDATA sichern. 3. Sichern Sie die Startdiskette des Schlüsselverwaltungsservers 4. Starten Sie den Dienst des Schlüsselverwaltungsservers. Sichern Sie in regelmäßigen Abständen mithilfe des Sicherungsdienstprogramms von Windows NT die Dateien und Unterverzeichnisse für weitere Sicherheitsmechanismen. Wenn die Sicherheitsdateien eines Benutzers beschädigt werden oder wenn ein Benutzer sein Sicherheitskennwort vergisst, kann er keine verschlüsselten Nachrichten öffnen, auch nicht die bereits archivierten Nachrichten. Der Administrator kann den Schlüssel wiederherstellen (dieser Vorgang wird in der Dokumentation zu Microsoft Exchange Server beschrieben, suchen Sie nach dem Stichwort "Sichern und Wiederherstellen der erweiterten Sicherheitsdaten"). Dies ist aber nur möglich, wenn die Sicherheitsdaten auf dem aktuellen Stand sind. Weitere Informationen über die Datenbankarchitektur Zuverlässige Datenspeicherung mit Transaktionsprotokollen In Anlehnung an relationale Datenbanken wie Microsoft SQL Server verwenden der Informationsspeicherdienst und der Verzeichnisdienst in Exchange Server separate Transaktionsprotokolldateien, um die Leistung zu steigern und die Integrität der Daten sicherzustellen. Alle Änderungen werden sofort in sequenziellen Transaktionsprotokollen aufgezeichnet und dann erst in die zugrunde liegende Datenbankdatei übertragen. Wenn der Strom ausfällt oder der Server unerwarteterweise abgeschaltet wird, bleiben die Daten bis zu der zuletzt durchgeführten vollständigen Transaktion intakt und können wiederhergestellt werden. Durch diese Gestaltung der Architektur können keine Daten in unvollständigem oder beschädigtem Zustand hinterlassen werden. Die Grundprinzipien zur Sicherstellung der Integrität von Datenbanktransaktionen sind seit den 70er Jahren bekannt. Damals wurde der sogenannte ACID-Test entwickelt (Atomicity, Consistency, Isolation, Durability = Unteilbarkeit, Konsistenz, Isolierung, Dauerhaftigkeit). Die Datenbank, die dem Informationsspeicher zugrunde liegt, unterstützt alle diese Eigenschaften: Unteilbarkeit: Die Ergebnisse einer Transaktion werden entweder alle zusammen übertragen oder zusammen rückgängig gemacht. In Exchange Server wird die Unteilbarkeit der Operationen durch Transaktionsprotokolle erzielt. Wie weiter oben bereits beschrieben, werden die Transaktionen im Protokoll, die noch nicht in die Datenbankdatei übertragen wurden, entweder abgeschlossen und übertragen oder - wenn sie nicht beendet wurden - wieder entfernt. Dieser Prozess findet schnell und automatisch bei jedem Neustart des Systems statt. Konsistenz: Eine gemeinsam genutzte Ressource (wie die Datenbank) wird immer wieder aus einem gültigen Zustand in den nächsten gültigen Zustand versetzt. Alle Operationen im Informationsspeicher von Exchange Server sind unteilbar, so dass die Daten immer in konsistentem Zustand sind. Wenn die Transaktion mit der Information aktualisiert wird, dass eine Transaktion komplett in die Datenbankdatei übertragen wurde, so handelt es sich dabei um eine unteilbare Operation. Isolierung: Transaktionen können serialisiert werden. In einem System, das mehrere gleichzeitige Transaktionen bearbeitet, sind die Ergebnisse jeder einzelnen Transaktion genau dieselben, wie wenn jede Transaktion allein auf dem System ausgeführt worden wäre. Im Wesentlichen bedeutet das, dass mehrere Benutzer gleichzeitig auf sichere Weise auf die Daten zugreifen können. Gleichzeitig stattfindende Operationen verschiedener Benutzer können sich nicht auf eine Weise beeinflussen, die dazu führt, dass die Datenbank ungültig wird. Diese Eigenschaft wird durch die Datenbank sichergestellt, die dem Informationsspeicher in Exchange Server zugrunde liegt. Dauerhaftigkeit: Die Ergebnisse der Transaktionen sind dauerhaft und bleiben auch nach späteren System- und Datenträgerfehlern erhalten. Wenn ein Teil einer Transaktionsprotokolldatei in Exchange Server beschädigt oder unlesbar ist (z.B. aufgrund einer physischen Beschädigung), werden die betreffenden Transaktionen einfach wieder entfernt. Das physische Format der Transaktionsdateien wurde so gestaltet, dass selbst bei einer Beschädigung der Datenträger die Auswirkungen minimal bleiben. Dies wird durch eine Kombination mehrerer Faktoren erreicht. Erstens werden die Transaktionsdateien nur sequenziell beschrieben, zweitens wird nach 5 MB jeweils eine neue Datei erstellt und drittens werden Methoden auf niedriger Ebene eingesetzt, wie beispielsweise die Pingpong-Protokollierung, so dass die Dauerhaftigkeit der Transaktionen selbst bei partiell beschädigten Protokolldateien maximiert wird. Es mag nun so scheinen, als würden die Transaktionsprotokolle das System sehr stark belasten, weil die Daten zuerst in das Protokoll geschrieben und dann erst in die Datenbank eingetragen werden müssen. In Wahrheit wird jedoch durch die richtige Verwendung der Protokolldateien der Durchsatz im System sogar erhöht. Dafür gibt es mehrere Gründe. Wenn sich die Transaktionsprotokolldateien auf einer separaten Festplatte befinden, werden sie nicht über wahlfreien Zugriff, sondern sequenziell geschrieben. Da der Schreib-Lese-Kopf aus diesem Grund nicht willkürlich bewegt werden muss, läuft der Vorgang selbst bei den heutigen sehr schnellen Festplatten um mindestens eine Größenordnung schneller ab als die wahlfreien Schreibvorgänge in die Datenbankdatei. Die protokollierten Transaktionen werden dann per Lazy-Übertragung in die Datenbankdatei eingefügt, und dieser Vorgang kann sehr effizient durchgeführt werden, weil er asynchron abläuft (in Leerlaufzyklen des Servers). Außerdem ordnen die NTFS- und FAT-Festplattencachesysteme in Windows NT Server die Schreibvorgänge mithilfe von klassischen Methoden automatisch in der effizientesten Reihenfolge an. Zu diesen Methoden gehört beispielsweise die aufzugsorientierte Suche, durch die die physische Bewegung des Kopfes minimiert wird. Die Wiederherstellungsmethoden von Exchange Server funktionieren für große Datensätze ebenso wie für kleine, weil deren Transaktionsprotokolle nur die veränderten Bestandteile der Daten speichern. Systeme mit Transaktionsrollback schnell und automatisch wiederherstellen Wenn ein Informationsspeicher- oder Verzeichnisdienst in Exchange Server nach einem nicht ordnungsgemäßen Abschalten des Servers neu gestartet wird, wird die Transaktionsprotokolldatei nach unvollständigen Transaktionen durchsucht. Falls solche vorhanden sind, findet automatisch ein Rollback zu dem Zustand vor dem Abschalten statt. Diese automatische Wiederherstellungsoperation läuft relativ schnell ab, weil nur die zuletzt durchgeführten Transaktionen überprüft werden müssen. Diese Differenzen in der Wiederherstellbarkeit entsprechen den Differenzen zwischen im Einsatz befindlichen DBMS-Servern wie Microsoft SQL Server oder Oracle und den Datenbanken der Endbenutzer wie Microsoft Access oder Lotus Approach. Automatische Integrität der Referenzen durch Speicherung ohne Redundanzen Für Kunden, bei denen die Nachrichten der Benutzer zentral auf dem Server gespeichert werden sollen, ist die Speicherung ohne Redundanzen eine Grundvoraussetzung. Wenn 100 Benutzer an einem Server dieselbe Nachricht empfangen, wird nur eine Instanz dieser Nachricht auf dem Server gespeichert. In die Postfächer der Benutzer werden Zeiger auf diese Nachricht platziert. Durch die redundanzfreie EinzelinstanzenSpeicherung sparen Sie Platz auf der Festplatte, und außerdem wird die Leistung des Servers erhöht. Der Informationsspeicher in Exchange Server wurde von vornherein für die Speicherung ohne Redundanzen entwickelt. Sie ist immer aktiv und erfordert weder spezielle Einstellungen noch spezielle Pflege. Wenn eine Nachricht oder das Postfach eines Benutzers gelöscht werden, können keine Waisen entstehen und es können keine Nachrichten verloren gehen. Die Zeiger auf die einzelnen Dateien können auch nicht durcheinander geraten, weil alle Dateien nur in einem Original gespeichert werden und die Integrität der Referenzen intern von der Datenbankengine verwaltet wird. Exchange Server wurde für die effiziente und zuverlässige Speicherung der Nachrichten auf dem Server optimiert. Speicherung ohne Redundanzen und mit Speicherbeschränkungen für die Benutzer Untersuchungen haben ergeben, dass einer der Hauptgründe für Ausfälle des Mailsystems darin liegt, dass der Speicherplatz, der den einzelnen Benutzern zur Verfügung steht, nicht begrenzt werden kann. Der Speicherplatz auf den Servern wird dadurch immer knapper, und irgendwann können sie nicht mehr arbeiten. Um dies zu verhindern, haben die Administratoren in Exchange Server die Möglichkeit, Speicherplatzquoten einzustellen und durchzusetzen, und zwar auf allen Ebenen, vom einzelnen Benutzer bis zum gesamten System. Sie können den Benutzern entweder nur eine Warnung zukommen lassen oder auch eine harte Grenze festlegen, bei der die Benutzer erst wieder Nachrichten versenden können, wenn sie ihr Postfach bereinigt haben. Auf diese Weise können die Benutzer immer noch dringende Nachrichten empfangen, und andere Benutzer werden nicht dafür bestraft, dass sie Nachrichten an bereits verwarnte Benutzer senden. Onlinesicherung auf Band im ununterbrochenen Betrieb In Exchange Server werden Online-Datensicherungen direkt auf Band unterstützt. Sie müssen den Server dazu nicht abschalten, und die Benutzer können angemeldet bleiben. Darüber hinaus ist die Datensicherung in Exchange Server mit der Datensicherung in Windows NT Server integriert, und Sie können beide Serverarten am selben Ort sichern. Sie können entweder vollständige, schrittweise oder Differenzsicherungen direkt auf eine Vielzahl verschiedener Bandgeräte durchführen, von ¼-Zoll-Bändern bis zu DATSystemen mit hoher Kapazität. Szenarien zur Wiederherstellung von Daten Im Folgenden werden drei verschiedene Szenarien zur Wiederherstellung besprochen: die Wiederherstellung einzelner Elemente, die Wiederherstellung eines gesamten Servers und die Wiederherstellung von PST-, OST- und PAB-Dateien. Einzelne Elemente wiederherstellen Einzelne Elemente sind zum Beispiel einzelne Postfächer, öffentliche Ordner, Nachrichten oder private Ordner. Sie können mit einer der folgenden Methoden wiederhergestellt werden: Einzelne Postfächer können durch die Wiederherstellung des gesamten privaten Informationsspeichers wiederhergestellt werden. Einzelne Elemente können in Exchange 5.5 mit dem Leistungsmerkmal zur Wiederherstellung gelöschter Einträge wiederhergestellt werden. Einzelne Elemente können auch mithilfe spezieller Sicherungsprogramme von anderen Anbietern wiederhergestellt werden. Postfächer wiederherstellen Die folgende Prozedur können Sie in Exchange 4.0 und 5.0 verwenden, um entweder ein gelöschtes Postfach oder andere einzelne Elemente wiederherzustellen. In Exchange 5.5 gibt es das Leistungsmerkmal zur Wiederherstellung gelöschter Einträge, so dass Sie diese Prozedur nur noch zur Wiederherstellung von Postfächern, nicht aber für Nachrichten, Ordner und öffentliche Ordner durchführen müssen. Achtung: Führen Sie diese Prozedur nicht an einem Server aus, der sich in Betrieb befindet. Mit dieser Prozedur werden die Daten auf einem Server wiederhergestellt, der nicht Teil eines im Einsatz befindlichen Exchange-Standorts ist. Bei der Installation des speziellen Wiederherstellungsservers wird zwar der Name des im Einsatz befindlichen Standorts und derselbe Organisationsname angegeben, aber Sie müssen die Option Neuen Standort erstellen aktivieren. Anforderungen Ein dezidierter Server mit genügend Kapazität, um die gesamte Datenbank des privaten Informationsspeichers wiederherzustellen. Eine Sicherungskopie der Datenbank des privaten Informationsspeichers. Den Installationscode für einen Exchange-Client und Exchange Server. Den Installationscode für Windows NT und das Service Pack von Windows NT. Sie können mit dieser Prozedur auch ein Postfach wiederherstellen. In einer zentralisierten Organisation können die zugehörigen Niederlassungen die Bänder per Post an ein internes "Wiederherstellungszentrum" schicken, und dieses kann die Postfächer auf jedem Server in der Organisation wiederherstellen, unabhängig vom Servernamen. Sie müssen den gesamten Informationsspeicher wiederherstellen und anschließend die Daten des speziellen Postfachs abrufen. Richten Sie auf einem Server Windows NT ein, und installieren Sie Exchange mit dem Namen des Standorts und der Organisation, an dem sich das verlorene Postfach befand. Stellen Sie den Informationsspeicher von der Sicherungskopie auf einem Band wieder her, melden Sie sich in Exchange mit den Berechtigungen eines Administrators an, und weisen Sie der Adminstrator-ID in Windows NT die Zugriffsrechte auf das gewünschte Postfach zu. Stellen Sie die Daten in einer PST-Datei wieder her, und fügen Sie die PST-Datei in das Profil des betreffenden Benutzers ein. Den Wiederherstellungsserver vorbereiten 1. Bereiten Sie einen Server vor, der sich nicht im Einsatz befindet (in manchen Systemen gibt es einen Wiederherstellungsserver, der immer zur Verfügung steht). Sie können diesen Computer als Windows NT-PDC, als BDC oder als Mitgliedsserver installieren. Außerdem sollte auf ihm das entsprechende Service Pack von Windows NT installiert sein. Stellen Sie sicher, dass der verfügbaren Festplattenspeicher ausreicht, um den gesamten Informationsspeicher von dem Sicherungsband wiederherzustellen, dass er ein Bandlaufwerk besitzt, das mit den Laufwerken an den im Einsatz befindlichen Servern kompatibel ist und dass das Bandlaufwerk getestet wurde und funktionsfähig ist. 2. Erstellen Sie einen neuen Standort (fügen Sie den Server nicht einem bestehenden Standort hinzu). Nun müssen Sie Exchange installieren. Dabei dürfen Sie den Server nicht einem bestehenden Standort hinzufügen. Der Wiederherstellungsserver muss ein unabhängiger Computer sein, der nicht zu Ihrem im Einsatz befindlichen Standort gehört. 3. Melden Sie sich in Windows NT als Administrator an, und führen Sie eine vollständige Installation von Exchange durch, bei der Sie den Namen der Organisation und des Standorts angeben, der auch auf dem Server angegeben war, dessen Postfächer Sie wiederherstellen. Fügen Sie den Server nicht einem vorhandenen Standort hinzu. Bei der Wiederherstellung eines Postfachs spielt der Servername des Wiederherstellungscomputers keine Rolle, weil Sie ja nur den Informationsspeicher wiederherstellen und nicht das Verzeichnis. Wenn Sie an jedem Standort einen speziellen Wiederherstellungsserver haben, können Sie Exchange installiert lassen, wenn jedoch der Wiederherstellungsserver für mehrere Standorte verwendet wird, sollten Sie eine Kopie des Installationscodes von Exchange auf der Festplatte speichern, damit Sie für jeden Standort- und Organisationsnamen neu installieren können. Sie müssen Exchange aber nicht in den gleichen Verzeichnissen installieren wie auf dem im Einsatz befindlichen Server, der wiederhergestellt werden soll. 4. Installieren Sie das Service Pack von Exchange, das zum Zeitpunkt der letzten vollständigen Sicherung auf dem im Einsatz befindlichen Computer gespeichert war. Wenn zum Zeitpunkt der Sicherung auf dem Server das Service Pack 1 installiert war und Sie inzwischen auf Service Pack 2 aufgerüstet haben, müssen Sie auf dem Wiederherstellungsserver trotzdem Service Pack 1 installieren, bevor Sie den Informationsspeicher wiederherstellen. 5. Installieren Sie den Exchange-Client auf dem Wiederherstellungsserver. Den Informationsspeicher vom Band wiederherstellen Bei dieser Prozedur wird ein Band mit einer online erstellten Sicherungskopie zur Wiederherstellung verwendet. (Sie können auch ein offline erstelltes Band verwenden, doch dazu sind zusätzliche Schritte notwendig. Diese Schritte werden nach der folgenden Prozedur erläutert.) 1. Legen Sie das Sicherungsband in das Bandlaufwerk ein. 2. Melden Sie sich in der Wiederherstellungsdomäne als Administrator an. 3. Führen Sie in der Gruppe Verwaltung (Allgemein) das Programm Bandsicherung aus. 4. Klicken Sie im Menü auf Funktionen, dann auf Microsoft Exchange. 5. Klicken Sie auf das Symbol Bänder, und doppelklicken Sie auf den Namen des Bandes. Ein Dialogfeld wird geöffnet, das anzeigt dass der Katalog geladen wird. 6. Klicken Sie im rechten Teil des Fensters Bänder auf ORGANSIATION\STANDORT\SERVER\Informationsspeicher. 7. Klicken Sie im oberen Teil des Hauptfensters des Programms Bandsicherung auf die Schaltfläche Wiederherstellen. 8. Geben Sie im Dialogfeld Wiederherstellungsinformationen in das entsprechende Feld den Namen des Zielservers ein. 9. Aktivieren Sie die Optionen Alle bestehenden Daten löschen, Privat, Öffentlich, Nach Wiederherstellung überprüfen und Service nach Wiederherstellung starten. Klicken Sie auf OK. 10. Ein Dialogfeld mit der Meldung, dass die Wiederherstellung bevorsteht und dass alle Exchange-Dienste auf dem Zielserver beendet werden, wird eingeblendet. Klicken Sie auf OK. 11. Klicken Sie auch im Dialogfeld Überprüfungsstatus auf OK. 12. Klicken Sie auf Systemsteuerung und anschließend auf Dienste, und stellen Sie sicher, dass die Exchange-Dienste ausgeführt werden. Von einer offline erstellten Sicherungskopie wiederherstellen Wenn Sie den Exchange-Informationsspeicher offline gesichert haben, müssen Sie folgende Schritte durchführen: 1. Beenden Sie alle Informationsspeicherdienste in Exchange. 2. Ermitteln Sie die Speicherorte der Datenbank und der Protokolldateien des Informationsspeicherdienstes in den folgenden Verzeichnissen der Registrierung: Verzeichnis der Protokolldateien des Informationsspeicherdienstes: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeIS \ParametersSystem \DB Log Path Verzeichnis der Datenbank des privaten Informationsspeichers: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeIS \ParametersPrivate \DB Path Verzeichnis der Datenbank des öffentlichen Informationsspeichers: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeIS \ParametersPublic \DB Path 3. Verschieben Sie alle Dateien aus den Verzeichnissen \EXCHSRVR\MDBDATA auf allen Laufwerken. 4. Kopieren Sie die Datei PRIV.EDB in das Verzeichnis der Datenbank des privaten Informationsspeichers. 5. Kopieren Sie die Datei PUB.EDB in das Verzeichnis der Datenbank des öffentlichen Informationsspeichers. 6. Kopieren Sie alle Protokolldateien des Informationsspeichers in das Verzeichnis für die Protokolle des Informationsspeicherdienstes. 7. Stellen Sie sicher, dass der Verzeichnisdienst von Exchange ausgeführt wird. 8. Wechseln Sie an der Eingabeaufforderung in das Verzeichnis \EXCHSRVR\BIN, und führen Sie den folgenden Befehl aus: isinteg –patch 9. Starten Sie den Dienst des Informationsspeichers. Das Postfach eines Benutzers wiederherstellen 1. Melden Sie sich unter der Administrator-ID von Windows NT am Wiederherstellungsserver an. 2. Führen Sie das Programm Exchange Administrator aus. Führen Sie die DS/ISKonsistenzanpassung aus. Markieren Sie den Namen des Servers. Klicken Sie im Menü Datei auf den Befehl Eigenschaften, um die Eigenschaftenseiten des Objekts Server aufzurufen. Klicken Sie auf die Registerkarte Weitere Optionen. In Version 4.0 oder 5.0 des Programms Exchange Administrator klicken Sie auf Alle Inkonsistenzen und anschließend auf die Schaltfläche Anpassen. In Version 5.5 des Programms Exchange Administrator klicken Sie auf der Seite Weitere Optionen auf die Schaltfläche Konsistenzanpassung, um das Dialogfeld DS/IS-Konsistenzanpassung zu öffnen. Aktivieren Sie alle Optionen für die öffentlichen und privaten Informationsspeicher, markieren Sie Alle Inkonsistenzen und klicken Sie dann auf OK. 3. Markieren Sie den Container Empfänger, und doppelklicken Sie auf den Postfachnamen des gewünschten Benutzers. 4. Klicken Sie auf der Registerkarte Allgemein auf die Schaltfläche Primäres Windows NT-Konto. 5. Klicken Sie im Dialogfeld Primäres Windows NT-Konto auf Bereits existierendes Windows NT-Konto auswählen und klicken Sie dann auf OK. 6. Klicken Sie im Dialogfeld Benutzer oder Gruppe hinzufügen auf Administrator und anschließend auf die Schaltfläche Hinzufügen und dann auf OK. 7. Klicken Sie im Dialogfeld Benutzereigenschaften auf OK. 8. Öffnen Sie die Systemsteuerung in Windows NT und führen Sie Mail und Fax aus. 9. Konfigurieren Sie ein Profil für den gewünschten Benutzer. 10. Fügen Sie dem Profil eine Datei für den persönlichen Ordner hinzu. 11. Führen Sie den Exchange-Client aus. 12. Klicken Sie im linken Teil des Fensters auf Postfach - <BENUTZERNAME>. 13. Markieren Sie den ersten Ordner oder das erste Element in der Liste im rechten Teil des Fensters. 14. Klicken Sie in dem Pulldownmenü auf Bearbeiten und auf Alle auswählen. 15. Klicken Sie in dem Pulldownmenü auf Datei und dann auf Kopieren. 16. Klicken Sie im Dialogfeld Kopieren auf Persönlicher Ordner und anschließend auf OK. Alle Daten werden in diese PST-Datei kopiert. 17. Kopieren Sie den persönlichen Ordner in das Zielverzeichnis. Sie können dazu bei Bedarf auch eine Sicherungskopie vom Band wiederherstellen. 18. Fügen Sie die PST-Datei in das Benutzerprofil auf dem im Einsatz befindlichen Server ein, oder senden Sie sie zusammen mit einer Anleitung an den Endbenutzer. Sie müssen die Datei möglicherweise auf Band verschicken. Wenn Sie Zugriff auf das Netzwerk haben, können Sie die wiederhergestellte PST-Datei jedoch direkt auf den gewünschten Server kopieren. 19. Wenn Sie versuchen, ein ganzes Postfach für einen Outlook-Benutzer wiederherzustellen, ist es einfacher, wenn Sie sich in Outlook anmelden und das gesamte Postfach in eine PST-Datei zu exportieren. Verwenden Sie dazu im Menü Datei die Befehle zum Import und Export. 20. Wenn der Benutzer anstelle des Outlook-Clients den Schedule+-Client verwendet, um seine Aktivitäten zu planen, müssen Sie die Schedule+-Daten des Benutzers wiederherstellen. Melden Sie sich unter dem Namen des Benutzers in Schedule+ an, wählen Sie die Option zum Erstellen einer lokalen Zeitplandatei (SCD), und senden Sie dann diese SCD-Datei an den Benutzer. Ein Postfach in Microsoft Exchange wiederherstellen Sie können den Server zur Wiederherstellung von Postfächern in das Netzwerk der im Einsatz befindlichen Server einbinden, weil sein Name nicht dem des im Einsatz befindlichen Servers entsprechen muss, auf dem Exchange ausgeführt wird. Wenn Sie ihn jedoch online betreiben, dürfen Sie nicht zulassen, dass zwischen ihm und den im Einsatz befindlichen Servern eine Verzeichnisreplikation stattfindet. Beispiel für eine Netzwerktopologie mit einem Server zur Wiederherstellung von Postfächern Sie sehen hier eine beispielhafte Topologie für die Unterhaltung eines Reserveservers zur Wiederherstellung von Postfächern. Beachten Sie, dass der Reserveserver Sabc nicht mit dem im Einsatz befindlichen Standort verbunden ist, obwohl er bei der Installation denselben Organisations- und Standortnamen erhalten hat wie die Server an dem Standort. Einzelne Elemente in Exchange 5.5 wiederherstellen Das neue Leistungsmerkmal zur Wiederherstellung gelöschter Elemente in Exchange Server 5.5 stellt den Benutzern einen Papierkorb zur Verfügung, aus dem sie einzelne Ordner und Nachrichten aus den privaten und öffentlichen Informationsspeichern wiederherstellen können. Das Löschen eines ganzen Postfachs kann dadurch aber nicht rückgängig gemacht werden; dazu müssen Sie den oben beschriebenen Prozess durchführen. Wie funktioniert das Leistungsmerkmal zur Wiederherstellung gelöschter Elemente? Mit jedem Objekt wird ein neues Attribut assoziiert, dessen Wert sich ändert, wenn das Objekt gelöscht wird. Daraufhin wird das Objekt vom Informationsspeicher vor dem Client verborgen. Der Informationsspeicher bewahrt das Objekt eine bestimmte Anzahl von Tagen auf, und danach wird es permanent gelöscht. Der Administrator kann einen Wert einstellen, der verhindert, dass das Objekt permanent gelöscht wird, bis der Informationsspeicher das nächste Mal vollständig gesichert wird. Das Merkmal Wiederherstellung gelöschter Elemente konfigurieren Dieses Leistungsmerkmal wird im Programm Exchange Administrator konfiguriert, obwohl die Wiederherstellung auf dem Client durchgeführt wird. Sie können die Einstellungen auf der Ebene des privaten Informationsspeichers oder auf der Ebene der Postfächer konfigurieren, wie in den folgenden Abbildungen gezeigt. Einstellungen auf der Ebene des privaten Informationsspeichers gelten für alle Postfächer auf einem Server, mit Einstellungen auf Postfachebene können Sie die Einstellungen auf Informationsspeicherebene für einzelne Postfächer überschreiben. In diesem Dialogfeld können Sie die Einstellungen zur Wiederherstellung gelöschter Elemente auf der Ebene des Informationsspeichers festlegen In diesem Dialogfeld können Sie die Einstellungen zur Wiederherstellung gelöschter Elemente auf der Ebene einzelner Postfächer festlegen Elemente vom Outlook-Client wiederherstellen Der Vorgang der Wiederherstellung wird vom Client mithilfe einer Erweiterung durchgeführt, die in Outlook 8.03 zur Verfügung steht. Wenn Sie ein gelöschtes Element aus dem Postfach eines Benutzers wiederherstellen wollen, klicken Sie im Outlook-Client auf den Ordner Gelöschte Objekte. Anschließend klicken Sie im Menü Extras auf den Befehl Gelöschte Objekte wiederherstellen. Daraufhin wird das Dialogfeld Gelöschte Objekte wiederherstellen (Restore Deleted Items From)geöffnet, das in der folgenden Abbildung gezeigt wird. Das Dialogfeld "Gelöschte Objekte wiederherstellen" Nun kann der Benutzer die Nachrichten oder Ordner auswählen, die wiederhergestellt werden sollen. Diese Objekte werden in den Ordner Gelöschte Objekte platziert, und von dort kann der Benutzer sie in andere Ordner verschieben. Auf diese Weise können gelöschte Objekte viel einfacher wiederhergestellt werden als durch eine Wiederherstellung des gesamten Informationsspeichers. Anmerkung: Obwohl die gelöschten Objekte im Informationsspeicher aufbewahrt werden und damit seine Größe erhöhen, werden sie nicht in die Speicherquote eines Benutzers einbezogen. Einzelne Elemente mithilfe von speziellen Sicherungsprogrammen anderer Anbieter wiederherstellen Einige Hersteller bieten Lösungen zur speziellen Datensicherung für Exchange an, mit denen Sie einzelne Postfächer, Ordner und öffentliche Ordner sichern und wiederherstellen können. Wenn Sie ein solches Sicherungsprogramm verwenden, brauchen Sie nicht den gesamten Informationsspeicher wiederherzustellen, sondern Sie können ein beschädigtes oder gelöschtes Postfach bzw. einen öffentlichen Ordner auf dem Band auswählen und wiederherstellen. Auf diese Weise sparen Sie viel Zeit, doch leider haben diese Sicherungsprogramme wesentliche Beschränkungen. Sie sichern die einzelnen Postfächer und öffentlichen Ordner, und die Sicherung aller Postfächer und öffentlichen Ordner auf einem Server dauert länger als die Sicherung des Informationsspeichers. Der Grund dafür liegt darin, dass die Daten in jedem Postfach bzw. öffentlichen Ordner einzeln gesichert werden und die Objekte damit mehrfach gespeichert werden (mit Redundanzen). Daraus ergeben sich meist viel mehr Daten als im Informationsspeicher, der die Objekte ohne Redundanzen speichert. Da die Größe der Datenbank in Exchange 5.5 nur noch durch die Hardwarekapazität begrenzt wird, können spezielle Sicherungsprogramme oft nicht für die tägliche Sicherung eines gesamten Exchange-Servers verwendet werden. Überlegen Sie sich daher, für den Verzeichnisdienst und den Informationsspeicher ein normales Sicherungsprogramm zu verwenden, das Exchange erkennt, und ein spezialisiertes Sicherungsprogramm nur für wichtige Postfächer und öffentliche Ordner einzusetzen. Wenn Sie den Einsatz eines speziellen Sicherungsprogramms in Betracht ziehen, prüfen Sie in der zugehörigen Dokumentation genau nach, welche Leistungsmerkmale und Grenzen es hat. Mit manchen Produkten können Sie beispielsweise keine ExchangeFormulare sichern bzw. wiederherstellen, und andere Produkte wandeln RTF-Nachrichten in das normale Textformat um. Server vollständig wiederherstellen Das Wiederherstellen eines Exchange-Servers auf einem anderen physischen Computer ist ein Sonderfall, weil Sie dazu Windows NT neu installieren und eine neue Registrierung sowie eine neue Windows NT-SID (Sicherheits-ID) für den neuen Computer erstellen müssen. Die neue SID ist nur dann erforderlich, wenn Sie eine Windows NT-Registrierung auf einem anderen Computer wiederherstellen müssen. Wenn Sie beispielsweise nur eine Festplatte austauschen und Windows NT darauf neu installieren müssen, müssen Sie keine neue SID erstellen. Die im Folgenden beschriebene Prozedur können Sie auch anwenden, wenn Sie eine Installation von Exchange Server auf einen leistungsfähigeren Computer umsiedeln wollen. Wenn die Situation eine vollständige Wiederherstellung der Datenbanken von Exchange Server verlangt (Informationsspeicher und Verzeichnisdienst), kann es je nach Umgebung notwendig sein, auch die SAM-Datenbank in Windows NT wiederherzustellen. Exchange fügt während des Installationsvorgangs automatisch das Windows NTDienstkonto und das Windows NT-Konto hinzu, das bei der anfänglichen Installation der Software angemeldet war. Zwar werden beide Konten während der Installation mit speziellen Berechtigungen ausgestattet, aber dennoch wird zur Wiederherstellung des Exchange-Verzeichnisdienstes nur diejenige Windows NT-Konto-SID benötigt, die ursprünglich während der Installation verwendet wurde. Diese SID muss in der Windows NT-Umgebung vorhanden sein, damit Sie auf den Verzeichnisdienst zugreifen können. Wenn aus irgendeinem Grund die Domänen-Controller der ursprünglichen Domäne nicht zur Verfügung stehen, müssen sie die PDC-SAM von Windows NT wiederherstellen. Anforderungen Eine vollständige Sicherungskopie des Informationsspeichers und des Verzeichnisses Ein neuer PC mit derselben Hardwarekapazität wie der vorher im Einsatz befindliche Server Zugriff auf die ursprüngliche SAM von Windows NT Die Konfigurationsaufzeichnungen des im Einsatz befindlichen Servers Der Installationscode von Exchange Der Installationscode von Windows NT Server und des Windows NT Service Packs Die Konfigurationsaufzeichnungen des im Einsatz befindlichen Exchange-Servers Die vollständige Wiederherstellung eines Servers ist komplizierter als die Wiederherstellung eines Postfachs. Ein ursprünglicher Exchange-Server, der sich im Einsatz befand, wird dabei so wiederhergestellt, dass alle Sicherheits- und Konfigurationsinformationen von Windows NT sowie alle Konfigurations- und Nachrichtendaten von Exchange wieder zur Verfügung stehen. Wenn dann der neue Server in Betrieb geht, können sich die Benutzer mit ihren bisherigen Kennwörtern an ihren Postfächern anmelden. Während Sie bei der Wiederherstellung von Postfächern nur den Informationsspeicher wiederherstellen müssen, ist es zur Wiederherstellung eines gesamten Servers erforderlich, sowohl den Informationsspeicher als auch den Verzeichnisdienst wiederherzustellen. Exchange regelt den Zugriff auf die Postfächer mithilfe der Sicherheitsmechanismen in Windows NT, und außerdem verwendet es die SIDInformationen der Windows NT-Konten in den Eigenschaften der Objekte im ExchangeVerzeichnis. Es gibt zwei Voraussetzungen für eine erfolgreiche Wiederherstellung des Verzeichnisdienstes: Der Verzeichnisdienst muss auf einem Windows NT-basierten Server wiederhergestellt werden, der mit demselben Standort-, Organisations- und Servernamen konfiguriert ist wie der zuvor im Einsatz befindliche Server. Der Wiederherstellungsserver muss sich in derselben Domäne befinden, in der Exchange Server ursprünglich installiert wurde. Zu einer vollständigen Wiederherstellung eines Servers nach einem Systemausfall sind drei Computer erforderlich: zwei im Einsatz befindliche Server (ein PDC und ein BDC) und ein dritter Server, der entweder nicht eingesetzt wird oder der im Netz keine wesentliche Funktion erfüllt. Der dritte Server kann zwar im Netz bestimmte Aufgaben haben, muss aber für die Wiederherstellung bereit gehalten werden. Diese Kombination aus PDC, BDC und Wiederherstellungsserver ist notwendig, weil Exchange die Echtheit der Verzeichnisobjekte mithilfe der SAM-Datenbank von Windows NT prüft. Bei einer vollständigen Wiederherstellung eines Exchange-Servers (Informationsspeicher und Verzeichnisdienst) müssen Sie aus der Domäne auf die SAM-Datenbank zugreifen können, in der der Exchange-basierte Server ursprünglich installiert wurde. Beispiel für eine falsche Vorgehensweise Nehmen Sie beispielsweise an, in einem Standort gibt es einen Exchange-basierten Server, der gleichzeitig als PDC eingesetzt wird, und einen OfflineWiederherstellungsserver. Der Informationsspeicher und der Verzeichnisdienst von Exchange werden in jeder Nacht gesichert. Wenn der Exchange-Server ausfällt, könnte im laufenden Betrieb ein neuer PDC mit Exchange eingerichtet werden, und auch der Informationsspeicher könnte wiederhergestellt werden (so wie im Fall der Wiederherstellung eines Postfachs). Wenn allerdings das Exchange-Verzeichnis wiedergeherstellt wird, müssen die Sicherheitseigenschaften aller Verzeichnisobjekte mit der Windows NT-SAM für die Konten übereinstimmen. In diesem Fall tun sie das jedoch nicht, weil bei der Neuerstellung des PDC auch eine neue SAM-Datenbank erstellt wurde. Der Administrator kann sich nicht im Programm Exchange Administrator anmelden, die Exchange-Dienste können nicht gestartet werden, und es besteht kein Zugriff auf die wiederhergestellten Daten. Wenn Sie den Informationsspeicher ohne den Verzeichnisdienst wiederherstellen, hat nur der Administrator Zugriff auf die Postfachdaten, und dies kann man nicht als vollständige Wiederherstellung eines Servers bezeichnen. Die ursprünglichen Informationen über das Exchange-Verzeichnis sind auf dem im Betrieb befindlichen Server nicht mehr vorhanden. Beispiel für eine richtige Vorgehensweise Ein weiteres Beispiel: Nehmen Sie an, es gibt einen dezidierten PDC, der im Einsatz befindliche Exchange-Server fungiert als BDC, und es gibt einen eigenen Wiederherstellungsserver. Wenn der Exchange-Server in diesem Fall ausfällt, können Sie auf dem Wiederherstellungsserver einen Windows NT Server-Domänen-Controller einrichten und ihm den Computernamen des ausgefallenen Exchange-Servers zuweisen. Wenn Sie diesen als BDC in die Domäne einfügen (Sie können ihn auch als Mitgliedscontroller einfügen), können Sie eine Kopie der SAM-Datenbank der Domäne abrufen, in der sich auch der zuvor im Einsatz befindliche Exchange-Server befand. Dazu müssen Sie im Server-Manager den ursprünglichen Computernamen (BDC-Definition) vom PDC löschen und ihn dann während der Installation des neuen BDC wieder hinzufügen. (Dies ist notwendig, weil jeder Computername eine eindeutige SID erhält, wenn er in die Domäne eingefügt wird, und der Wiederherstellungsserver benötigt eine neue SID). Installieren Sie dann Exchange, und verwenden Sie dabei denselben Standort- und Organisationsnamen. Dabei wird standardmäßig derselbe Servername zugewiesen, weil dieser in Exchange aus dem Computernamen erstellt wird. Anmerkung: Wenn Sie einen Server wiederherstellen und ihn dabei einem bereits existierenden Standort hinzufügen, lesen Sie weitere Einzelheiten in der Dokumentation von Microsoft Exchange Server nach. In diesem Fall müssen Sie Exchange Server auf dem neuen oder reparierten Server installieren, aber Sie dürfen ihn nicht mit den anderen Servern in der Organisation replizieren. Weisen Sie dem Server stattdessen den ursprünglichen Standort- und Organisationsnamen zu, und führen Sie Setup /R aus. Nun können Sie den Informationsspeicher und das Verzeichnis des vorher im Einsatz befindlichen Exchange-Servers wiederherstellen. Wenn der ursprüngliche Server noch zur Verfügung steht, speichern Sie alle Transaktionsprotokolle aus den Verzeichnissen \DSADATA und \MDBDATA. Mit ihrer Hilfe können der Informationsspeicher- und Verzeichnisdienst alle Transaktionen, die seit der letzten Sicherung an den Datenbanken ausgeführt wurden, abspielen. Wenn diese Protokolle nicht zur Verfügung stehen, können Sie die Datenbanken nur bis zu ihrem Zustand zum Zeitpunkt der letzten Sicherung wiederherstellen. Beispiel für das Wiederherstellen eines Servers von einer Sicherungskopie auf Band In dem nun folgenden Beispiel wird die Wiederherstellung eines Servers mithilfe der Sicherungskopie des Informationsspeichers und Verzeichnisdienstes eines im Einsatz befindlichen Servers beschrieben. Es wurde eine Sicherung vom Typ normal durchgeführt, das heißt, der Informationsspeicher und das Verzeichnis wurden vollständig gesichert. Sie dürfen bei der Installation von Exchange auf keinen Fall die Option Server einem bereits existierenden Standort hinzufügen aktivieren. Aktivieren Sie stattdessen die Option Neuen Standort erstellen. Die Sicherungskopie der Verzeichnisdatenbank von Exchange stellt trotzdem bei einem Neustart die vorherige Standortidentität des Servers wieder her, so dass er automatisch mit den anderen Servern an dem Standort synchronisiert wird. Den Wiederherstellungscomputer vorbereiten Der Computer, auf dem die Wiederherstellung durchgeführt wird, muss folgende Voraussetzungen erfüllen: Windows NT muss installiert sein. Er muss denselben Computernamen haben wie der ausgefallene Exchange-Server. Er muss für dieselbe Rolle konfiguriert sein wie der ausgefallene Exchange-Server: Wenn der Server ein BDC war, müssen Sie den Wiederherstellungsserver ebenfalls als BDC in die im Einsatz befindliche Domäne einfügen. (Das bedeutet, dass Sie den Computernamen auf dem PDC zuerst löschen und dann wieder hinzufügen müssen, damit dem Wiederherstellungscomputer eine neue SID zugewiesen wird.) Es müssen dieselben Windows NT Service Packs installiert sein wie auf dem ausgefallenen Exchange-Server. Es muss genügend Speicherplatz vorhanden sein, damit der gesamte Informationsspeicher und das Verzeichnis von der Sicherungskopie auf Band wiederhergestellt werden können. Das Bandlaufwerk muss mit den Bandlaufwerken kompatibel sein, die auf den im Einsatz befindlichen Servern verwendet werden. Damit die Wiederherstellung schneller vor sich geht, können Sie eine Kopie des Installationscodes von Windows NT und dem Service Pack auf der Festplatte des Wiederherstellungscomputers speichern. Halten Sie die Aufzeichnungen der Konfiguration von Windows NT Server bereit, damit Sie die Einstellungen richtig vornehmen können, beispielsweise die Protokolladressen, die Partitionierung, die Protokolle, Optionen, Feineinstellungen usw. Zur Vorbereitung des Wiederherstellungsservers führen Sie folgende Schritte durch: 1. Melden Sie sich in Windows NT als Domänenadministrator an. 2. Führen Sie das Programm Exchange Administrator aus. Wenn Sie nicht Exchange 4.0 verwenden, können Sie einen vorhandenen Exchange-Server mit dem Befehl Setup /R auf neuer Hardware wiederherstellen. 3. Stellen Sie sicher, dass der Server denselben Namen trägt wie der zuvor im Einsatz befindliche Server. 4. Aktivieren Sie die Option Neuen Standort erstellen (aktivieren Sie auf keinen Fall die Option Server einem bereits existierenden Standort hinzufügen). 5. Verwenden Sie denselben Standort- und Organisationsnamen. 6. Wählen Sie dasselbe Dienstkonto, das auch auf dem zuvor im Einsatz befindlichen Server verwendet wurde. 7. Installieren Sie dieselben Connectors, die auch auf dem zuvor im Einsatz befindlichen Server installiert waren. 8. Führen Sie die Exchange-Leistungsoptimierung aus, um Exchange für dieselbe Konfiguration zu optimieren, die auch auf dem zuvor im Einsatz befindlichen Exchange-Server verwendet wurde. Lesen Sie dazu auch in Ihren Aufzeichnungen der Konfiguration des zuvor im Einsatz befindlichen Servers nach. 9. Installieren Sie dasselbe Exchange Service Pack, das zum Zeitpunkt der letzten Datensicherung auf dem zuvor im Einsatz befindlichen Exchange-Server installiert war. Wenn Sie nicht Exchange 4.0 verwenden, führen Sie den Befehl Update /R aus. 10. Wenn auf dem ursprünglichen Server der Microsoft Mail (MS Mail) Connector installiert war, müssen Sie ihn auf dem neuen Server auf identische Weise konfigurieren. Bei den X.400- und anderen Standortconnectors werden die Konfigurationsinformationen im Exchange-Verzeichnis gespeichert, aber beim MS Mail Connector werden sie sowohl im Verzeichnis als auch in der Windows NTRegistrierung gespeichert. Damit die entsprechenden Einträge erneut in der Registrierung erstellt werden, müssen Sie den MS Mail Connector konfigurieren, bevor Sie das Exchange-Verzeichnis wiederherstellen. Wenn auf dem ursprünglichen Server Connectors von anderen Anbietern installiert waren, müssen sie möglicherweise ebenfalls erneut konfiguriert werden. Lesen Sie hierzu in der Dokumentation des im Einsatz befindlichen Servers nach. 11. Wenn auf dem ursprünglichen Server der Schlüsselverwaltungsserver installiert war, müssen Sie ihn auch auf dem neuen Server installieren. 12. Installieren Sie entweder Exchange Client oder Outlook auf dem Wiederherstellungsserver. Um die Exchange-Daten wiederherzustellen, müssen Sie eine der folgenden Prozeduren durchführen, je nachdem, welche für Ihre Situation angemessen ist. Die Wiederherstellung durchführen Mit online erstellter Sicherungskopie Bei dem folgenden Vorgang wird vorausgesetzt, dass Sie das Programm NTBACKUP.EXE verwenden, das zusammen mit Exchange Server ausgeliefert wird. Wenn Sie ein anderes Sicherungsprogramm verwenden, lesen Sie in der zugehörigen Dokumentation nach. Wenn Sie eine online erstellte Sicherungskopie des Exchange-Servers haben, führen Sie folgende Schritte durch: 1. Legen Sie das Band mit der Sicherungskopie ein, die wiederhergestellt werden soll. 2. Klicken Sie in der Programmgruppe Verwaltung (Allgemein) auf das Symbol Bandsicherung. 3. Doppelklicken Sie auf das Symbol Bänder. 4. Doppelklicken Sie auf die Schaltfläche für vollständige Sicherung. Daraufhin wird das Dialogfeld Katalogisierungsstatus mit der Meldung geöffnet, dass die Satzliste vom Band geladen wird. 5. Markieren Sie im rechten Teil des Fensters Verzeichnis und Informationsspeicher. 6. Klicken Sie im oberen Teil des Dialogfelds Bandsicherung auf die Schaltfläche Wiederherstellen. Das Dialogfeld Wiederherstellungsinformationen wird geöffnet. 7. Wenn seit dem Zeitpunkt der letzten Sicherung noch Änderungen an dem ursprünglich im Einsatz befindlichen Server vorgenommen wurden und Sie die Transaktionsprotokolle des Servers haben, fahren Sie mit der Prozedur fort, die direkt im Anschluss an diese Prozedur beschrieben wird. Anmerkung: Wenn sich der öffentliche Informationsspeicher auf einem separaten Server befindet, setzen Sie sich mit Microsoft Technical Support in Verbindung. Im nächsten Schritt werden Sie aufgefordert, den öffentlichen Informationsspeicher zu löschen. Tun Sie dies jedoch nicht, wenn sich dieser auf einem anderen Server befindet. 8. Geben Sie in das Dialogfeld Wiederherstellungsinformationen den Namen des Zielservers ein. Aktivieren Sie die Option Alle bestehenden Daten löschen. Stellen Sie sicher, dass die Optionen Privat, Öffentlich, Service nach Wiederherstellung starten und Nach Wiederherstellung überprüfen alle aktiviert sind. Klicken Sie auf OK. 9. Klicken Sie im Dialogfeld Wiederherstellungsinformationen auf OK. Das Dialogfeld Wiederherstellungsstatus wird geöffnet. 10. Wenn die Wiederherstellung abgeschlossen ist, klicken Sie im Dialogfeld Wiederherstellungsstatus auf OK. 11. Schließen Sie das Sicherungsprogramm. Auf diese Weise werden der Exchange-Verzeichnisdienst und der Informationsspeicher in dem Zustand wiederhergestellt, in dem sie sich zum Zeitpunkt der letzten Sicherung befanden. Wenn seit dem Zeitpunkt der letzten Datensicherung Änderungen an dem ursprünglich im Einsatz befindlichen Server vorgenommen wurden und Sie die Transaktionsprotokolle haben, führen Sie folgende Schritte durch: 1. Verschieben Sie auf dem neuen Server alle Dateien aus den Verzeichnissen \MDBDATA und \DSADATA auf allen Laufwerken. 2. Kopieren Sie die Transaktionsprotokolldateien aus den Verzeichnissen \DSADATA und \MDBDATA auf dem ursprünglichen Server in die entsprechenden Verzeichnisse auf dem neuen Server. Wenn Sie nicht sicher sind, in welche Verzeichnisse Sie die Protokolldateien kopieren sollen, prüfen Sie die folgenden Einträge in der Registrierung. Verzeichnis der Protokolldateien des Verzeichnisdienstes: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeDS \Parameters \Database log files path Verzeichnis der Protokolldateien des Informationsspeichers: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeDS \ParametersSystem \DB Log Path 3. Führen Sie das Sicherungsprogramm aus, um die Daten des Verzeichnisdienstes und des Informationsspeichers wiederherzustellen. Führen Sie dazu die Schritte 1 bis 6 in der vorherigen Prozedur durch. 4. Aktivieren Sie im Dialogfeld Wiederherstellungsinformationen nicht die Option Alle bestehenden Daten löschen. Aktivieren Sie nur die Optionen Nach Wiederherstellung überprüfen und Service nach Wiederherstellung starten. Klicken Sie auf OK. (Wenn der Verzeichnisdienst und der Informationsspeicher in zwei separaten Sicherungsaufträgen gesichert wurden, dürfen Sie die Dienste erst wieder starten, wenn beide wiederhergestellt wurden.) Sie dürfen in dieser Situation auf keinen Fall die Option Alle bestehenden Daten löschen aktivieren, sonst werden alle vom ursprünglichen Server kopierten Transaktionsprotokolle wieder gelöscht. 5. Klicken Sie im Dialogfeld Wiederherstellungsinformationen auf OK. Das Dialogfeld Wiederherstellungsstatus wird geöffnet. 6. Wenn die Wiederherstellung abgeschlossen ist, klicken Sie im Dialogfeld Wiederherstellungsstatus auf OK. 7. Schließen Sie das Sicherungsprogramm. Mit offline erstellter Sicherungskopie Wenn Sie eine offline erstellte Sicherungskopie des Exchange-Verzeichnisses und Informationsspeichers haben, führen Sie folgende Schritte durch: 1. Beenden Sie alle Exchange-Dienste. 2. Ermitteln Sie die Verzeichnisse der Datenbanken und Protokolldateien des Verzeichnis- und Informationsspeicherdienstes aus den folgenden Registrierungseinträgen: Verzeichnis der Protokolldateien des Verzeichnisdienstes: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeDS \Parameters \Database log files path Verzeichnis der Datenbank des Verzeichnisdienstes: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeDS \Parameters \DSA Database file Verzeichnis der Protokolldateien der Informationsspeicher: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeIS \ParametersSystem \DB Log Path Verzeichnis der Datenbank des privaten Informationsspeichers: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeIS \ParametersPrivate \DB Path Verzeichnis der Datenbank des öffentlichen Informationsspeichers: HKEY_LOCAL_MACHINE \System \CurrentControlSet \Services \MSExchangeIS \ParametersPublic \DB Path 3. Kopieren Sie die Datei DIR.EDB (sie sollte sich im Verzeichnis \DSADATA befinden) in das Verzeichnis, in dem sich die Datenbank des Verzeichnisdienstes befindet. 4. Kopieren Sie alle Protokolldateien des Verzeichnisdienstes in das Verzeichnis für die Protokolldateien des Verzeichnisdienstes. 5. Kopieren Sie die Datei PRIV.EDB in das Verzeichnis der Datenbank des privaten Informationsspeichers. 6. Kopieren Sie die Datei PUB.EDB in das Verzeichnis der Datenbank des öffentlichen Informationsspeichers. 7. Kopieren Sie alle Protokolldateien der Informationsspeicher in das Verzeichnis für die Protokolldateien der Informationsspeicher. 8. Starten Sie den Exchange-Verzeichnisdienst. 9. Wechseln Sie an der Eingabeaufforderung in das Verzeichnis \EXCHSRVR\BIN, und führen Sie folgenden Befehl aus: isinteg –patch 10. Starten Sie den Informationsspeicherdienst. Die Daten des Schlüsselverwaltungsservers wiederherstellen Wenn auf dem ursprünglichen Server der Schlüsselverwaltungsserver installiert war, führen Sie die folgenden Schritte durch, um die zugehörigen Daten auf dem neuen Server wiederherzustellen: 1. Wenn der Dienst des Schlüsselverwaltungsservers noch nicht installiert ist, müssen Sie ihn jetzt installieren. 2. Beenden Sie den Dienst des Schlüsselverwaltungsservers. 3. Stellen Sie die Daten des Schlüsselverwaltungsservers wieder her: Verwenden Sie Exchange Server 4.0 oder 5.0, stellen Sie das Verzeichnis \SECURITY\MGRENT wieder her. Verwenden Sie Exchange Server 5.5, stellen Sie das Verzeichnis \EXCHSRVR\ KMSDATA wieder her. 4. Stellen Sie die Startdiskette des Schlüsselverwaltungsservers wieder her. 5. Starten Sie den Dienst des Schlüsselverwaltungsservers. Die Zuordnung der Postfächer zu Windows NT-Konten prüfen 1. Markieren Sie den Container Empfänger des jeweiligen Standorts. 2. Doppelklicken Sie auf einen beliebigen Benutzer. 3. Prüfen Sie den Eintrag im Feld Primäres Windows NT-Konto, um festzustellen, ob das Windows NT-Konto mit dem Postfach übereinstimmt. 4. Wiederholen Sie diesen Vorgang für mehrere Benutzer. Die Anmeldung der Benutzer von Clientworkstations testen 1. 2. 3. 4. Führen Sie den Exchange-Client aus. Stellen Sie sicher, dass die Benutzerkennwörter gültig sind. Stellen Sie sicher, dass die Mailfunktionen, der Kalender usw. einsatzbereit sind. Stellen Sie sicher, dass der Benutzer Nachrichten an andere Postfächer auf demselben Server und auch an Postfächer auf anderen Servern und an anderen Standorten versenden kann. 5. Wiederholen Sie diesen Test auf mehreren Workstations. Die individuellen Einstellungen von Microsoft Exchange wiederherstellen Stellen Sie die Connectors und anderen Dienste auf dem Server anhand der Aufzeichnungen zur Konfiguration des zuvor im Einsatz befindlichen Servers genau so ein wie vorher. Prüfen Sie die Einstellungen der Umlaufprotokollierung und die weiteren Optionen der Diagnostik, die ebenfalls in der Microsoft Windows NT-Registrierung gespeichert werden. Hardwareplattformen Die meisten Datenbanken in Exchange sind von der Hardware unabhängig. Sie können die auf einem Intel-Server erstellten Dateien PRIV.EDB, PUB.EDB und DIR.EDB auch auf einem Alpha-Server verwenden und umgekehrt. Das Verzeichnis (DIR.EDB) enthält allerdings Informationen über plattformspezifische Komponenten wie E-Mailgeneratoren und Add-Ins. Diese Informationen können über das Programm Exchange Administrator unter <Standort>\Konfiguration\Erweiterungen und <Standort>\Konfiguration\Adressierung\E-Mail-Adreßgeneratoren eingesehen werden. In Exchange 5.0 und späteren Versionen werden automatisch die Erweiterungen und EMail-Adressgeneratoren für alle unterstützten Plattformen installiert, unabhängig davon, auf welche Plattform der Server installiert wird. Dadurch wird der Wechsel von einer Hardwareplattform zur anderen erleichtert. Bei Exchange 4.0 werden nur die Komponenten für die Plattform installiert, auf der das Programm installiert wird. Wenn Sie also Exchange 4.0 verwenden, müssen Sie möglicherweise zusätzliche Schritte durchführen, wenn Sie neue Server auf anderen Hardwareplattformen installieren wollen. Setzen Sie sich zu diesem Zweck mit Microsoft Technical Support in Verbindung. Die wichtigsten Artikel und Hinweise über den Informationsspeicher Anmerkung: In den nun folgenden Artikeln aus der Knowledge Base werden grundlegende Prozeduren beschrieben. In manchen Situationen müssen möglicherweise andere oder leicht veränderte Schritte durchgeführt werden. Da bei der Wiederherstellung des Informationsspeichers die Daten ebenso gut verloren gehen wie wiederhergestellt werden können, ist es immer empfehlenswert, bei Microsoft Technical Support Hilfe zu erfragen. Die dortigen Mitarbeiter sammeln laufend Informationen und verfeinern die Prozeduren, so dass Sie sich sehr viel Arbeit ersparen können, wenn Sie sich mögliche Alternativen überlegen. Die aktuellsten Informationen finden Sie unter http://support.microsoft.com/support/ . Q147244, XADM: Troubleshooting Information Store Start Up Problems Überarbeitungsdatum: 03.02.1998 Die Informationen in diesem Artikel gelten für: Microsoft Exchange Server, Version 4.0, 5.0 und 5.5. Zusammenfassung Der Informationsspeicher in Exchange 4.0 kann beschädigt werden, so dass er nicht mehr gestartet werden kann. Gründe dafür sind beispielsweise ein plötzlicher Stromausfall bei einem in Betrieb befindlichen Exchange-Server oder eine Beschädigung der Hardware, durch die Daten nicht ordnungsgemäß auf die Festplatte geschrieben werden. In diesem Artikel werden die Schritte zur Wiederherstellung beschrieben. Mit den in diesem Artikel beschriebenen Schritten erzielen Sie das beste Ergebnis, wenn die Umlaufprotokollierung deaktiviert ist und Sie bereits regelmäßige Prozesse zur Datensicherung eingerichtet haben. Wenn die Umlaufprotokollierung aktiviert ist (Standard), gelten die Schritte 1, 2 und 6 bis 9 (bei der Umlaufprotokollierung werden die Transaktionsprotokolldateien automatisch überschrieben, wenn die in ihnen enthaltenen Daten in die Datenbank übertragen wurden). Wenn keine Sicherungskopie zur Verfügung steht, gelten die Schritte 1, 2, 8 und 9. Weitere Informationen und Strategien für die Prozesse zur Datensicherung und Wiederherstellung finden Sie in Kapitel 12 in diesem Buch sowie in der Dokumentation von Microsoft Exchange Server. Weitere Informationen Befolgen Sie diese Schritte genau in der angegebenen Reihenfolge, damit Sie möglichst viele Daten wiederherstellen können. 1. Suchen Sie in der Ereignisanzeige von Windows NT im Anwendungsprotokoll nach Meldungen in Zusammenhang mit EDB, MSExchangeIS, MSExchangePriv und MSExchangePub. Diese Fehlermeldungen enthalten eventuell den genauen Grund für die Probleme mit dem Informationsspeicher. Zwei sehr häufige Gründe sind entweder, dass der Speicherplatz für das Anwendungsprotokoll zu knapp wird oder dass Sie isinteg -patch ausführen müssen. Weitere Informationen finden Sie in den folgenden Artikeln: Q128325, XADM: Reclaiming Disk Space for the Information Store Q149238, XADM: Information Store Fails to Start with -1011 Error 2. Beenden Sie alle Exchange-Dienste, und starten Sie den Exchange-Server neu. Wenn der Informationsspeicher neu gestartet wird, versucht er automatisch, seine Daten wiederherzustellen und die Datenbank in einen konsistenten Zustand zu bringen. 3. Erstellen Sie eine vollständige Offlinesicherungskopie des Informationsspeichers (dazu müssen Sie alle Exchange-Dienste beenden). Diese Sicherungskopie sollte alle EDB- und LOG-Dateien beinhalten. Diese sind manchmal auf unterschiedlichen physischen Laufwerken gespeichert. Wenn Sie sie suchen müssen, sehen Sie in der Registrierung unter dem Schlüssel HKEY_LOCAL_ MACHINE unter folgendem Teilschlüssel nach: \SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem Sie finden sie im Parameter DB log path. Dies ist eine Vorsichtsmaßnahme, mit der der gegenwärtige Zustand von Exchange Server aufgezeichnet wird, bevor Sie fortfahren. Sie benötigen diese Sicherungskopie, wenn Sie die Schritte 8 oder 9 durchführen. 4. Stellen Sie die letzte vollständige Onlinesicherungskopie wieder her. Markieren Sie nicht das Kontrollkästchen Service nach Wiederherstellung starten. Daraufhin müssen Sie alle schrittweise erstellten Onlinesicherungskopien des Informationsspeichers (von dem Zeitpunkt der letzten vollständigen Onlinesicherung bis zum Zeitpunkt des Systemausfalls) der Reihe nach wiederherstellen. Markieren Sie das Kontrollkästchen Service nach Wiederherstellung starten erst, wenn die letzte schrittweise erstellte Sicherungskopie wiederhergestellt wurde. Markieren Sie nicht das Kontrollkästchen mit der Option, alle bestehenden Daten zu löschen. Wenn der Informationsspeicherdienst gestartet wird, werden alle vorhandenen Transaktionsprotokolle der Datenbank abgespielt, und die darin enthaltenen Daten werden in den wiederhergestellten Informationsspeicher eingetragen. Auf diese Weise erreicht der Informationsspeicher wieder den Zustand zu dem Zeitpunkt vor dem Systemabsturz. Wenn Sie diesen Vorgang erfolgreich durchführen konnten, sind keine Daten verloren gegangen. Ab Schritt 5 verlieren Sie jeweils unterschiedliche Mengen von Daten. 5. Wenn sich der Informationsspeicher nach Schritt 4 noch nicht starten lässt, öffnen Sie das Anwendungsprotokoll in der Ereignisanzeige, und lesen Sie die protokollierten Meldungen über die EDB-Quelldateien. Für jede Protokolldatei, die bei der Wiederherstellung in Schritt 4 abgespielt wurde, ist hier eine Meldung vorhanden. Wenn in einer dieser Meldungen ein Problem beim Abspielen einer bestimmten Protokolldatei aufgezeichnet wurde, wechseln Sie in das Verzeichnis \MDBDATA, und entfernen Sie die betreffende Protokolldatei sowie alle Protokolldateien mit höherer Nummerierung. Versuchen Sie anschließend erneut, den Informationsspeicher zu starten. Wenn im Anwendungsprotokoll beispielsweise vermerkt ist, dass die Datei EDB00012.LOG nicht verarbeitet werden konnte oder beschädigt war, und wenn im Verzeichnis \MDBDATA Protokolldateien von EDB00001.LOG bis EDB00025.LOG vorhanden sind, müssen Sie die Dateien von EDB00012.LOG bis EDB00025.LOG entfernen und dann den Informationsspeicher starten. Wenn Sie ihn jetzt starten können, gehen nur die Dateien in den gerade entfernten Protokolldateien verloren. 6. Wenn auch Schritt 5 fehlschlägt, stellen Sie die letzte vollständige Onlinesicherungskopie des Informationsspeichers wieder her. Aktivieren Sie die Optionen Service nach Wiederherstellung starten und Alle bestehenden Daten löschen. Damit wird der Informationsspeicher in dem Zustand wiederhergestellt, den er zum Zeitpunkt der letzten Onlinesicherung innehatte. Führen Sie anschließend im Programm Exchange Administrator auf der Registerkarte Weitere Optionen der Eigenschaftenseiten des Serverobjekts die DS/IS-Konsistenzanpassung aus. 7. Wenn Schritt 6 fehlschlägt, versuchen Sie es erneut mit der vorletzten vollständigen Online- oder Offline-Sicherungskopie. 8. Wenn Schritt 7 nicht funktioniert, löschen Sie alle EDB- und LOG-Dateien aus dem Verzeichnis \MBDATA, und stellen Sie die Dateien PRIV.EDB und PUB.EDB aus der Sicherungskopie der Datenbank wieder her, die Sie erstellt haben, als das Problem zum ersten Mal auftrat (Schritt 3). Wechseln Sie dann in das Verzeichnis \EXCHSRVR\BIN und führen Sie zuerst edbutil /d /r /ispriv und anschließend edbutil /d /r /ispub aus. (In Exchange 5.5 verwenden Sie eseutil statt edbutil.) Mit diesen Befehlen werden der private und der öffentliche Informationsspeicher defragmentiert, und es wird versucht, alle festgestellten Fehler in den Datenbanken zu reparieren. Wenn EDBUTIL.EXE erfolgreich ausgeführt werden kann, versuchen Sie, den Informationsspeicher zu starten. Wenn er sich starten lässt, führen Sie sowohl im öffentlichen als auch im privaten Informationsspeicher den Befehl isinteg -fix aus, um alle Inkonsistenzen zu bereinigen, die sich während der Ausführung von edbutil möglicherweise ergeben haben. Bei der Ausführung von edbutil /d /r (oder eseutil) können unter Umständen Daten gelöscht werden. Sie sollten diese Befehle nur als letztes Hilfsmittel verwenden und sich unbedingt vorher mit Microsoft Technical Support in Verbindung setzen. 9. Weitere Informationen über die Dienstprogramme EDBUTIL.EXE und ISINTEG.EXE finden Sie in der Dokumentation von Microsoft Exchange Server und in dem Artikel in der Knowledge Base Q143233, XADM: Command Line Parameters for EDBUTIL.EXE. 10. Wenn alle der soeben beschriebenen Schritte fehlschlagen, können Sie als letztes Hilfsmittel den Informationsspeicher vollkommen leeren. Wenn dies unumgänglich ist, sollten Sie im Allgemeinen zuerst den öffentlichen Informationsspeicher leeren. Wenn Sie beide Speicher leeren müssen, werden Sie verstehen, warum dieser Prozess als sehr drastisch betrachtet wird. Wenn Sie die Datei PRIV.EDB leeren, werden alle Mail-Nachrichten und Ordner der Benutzer unwiderruflich gelöscht. Wenn Sie die Datei PUB.EDB leeren, werden alle öffentlichen Ordner unwiderruflich gelöscht. Wenn Sie den Informationsspeicher leeren müssen, führen Sie folgende Schritte durch: 1. Vergewissern Sie sich, dass Schritt 3 (vollständige Sicherungskopie) abgeschlossen wurde, oder kopieren Sie das Verzeichnis EXCHSRVR\MDBDATA an eine Stelle auf der Festplatte. 2. Löschen Sie im Verzeichnis EXCHSRVR\MDBDATA alle EDB*.LOG- und RES*. LOG-Dateien sowie die Dateien EDB.CHK und PUB.EDB. 3. Starten Sie jetzt den Informationsspeicher neu. Wenn er gestartet werden kann, sind die Informationen der öffentlichen Ordner verloren gegangen (die Dateien PUB.EDB, RES*.LOG und EDB.CHK werden automatisch neu angelegt), ebenso wie alle Information in den Protokolldateien. Erhalten geblieben sind dagegen alle Mailnachrichten und Ordner der Benutzer, die im privaten Informationsspeicher (PRIV.EDB) gespeichert waren. Wenn die Leerung des Informationsspeichers fehlschlägt, dann führen Sie folgende Schritte durch: 1. Entfernen Sie alle Informationen aus dem Verzeichnis \MDBDATA. 2. Kopieren Sie die Datei PUB.EDB von einem Band oder einem anderen Datenträger zurück in dieses Verzeichnis. 3. Versuchen Sie erneut, den Informationsspeicher zu starten. Wenn er gestartet werden kann, sind die Informationen der öffentlichen Ordner noch intakt, aber alle Mailnachrichten und Ordner der Benutzer sowie alle Protokollinformationen sind verloren. Wenn sich die Benutzer das nächste Mal anmelden, werden die Postfächer neu erstellt. Wenn alle hier beschriebenen Schritte erfolglos verlaufen, entfernen Sie alle Informationen aus dem Verzeichnis \EXCHSRVR\MDBDATA und starten Sie den Informationsspeicherdienst neu. Auf diese Weise wird der Standardzustand nach der Installation wiederhergestellt. Mit der DS/IS-Konsistenzanpassung (Registerkarte Weitere Optionen des Serverobjekts) können Sie alle Inkonsistenzen zwischen Verzeichnisdienst und Informationsspeicher bereinigen. Damit der Informationsspeicher von Exchange Server wiederhergestellt werden kann, müssen Sie eine tägliche Prozedur zur Datensicherung und Transaktionsprotokolle einrichten. Es wird dringend empfohlen, dass Sie eine Prozedur zur täglichen Datensicherung einrichten und die Bänder jedes Mal prüfen. Q143235, XADM: Err Msg: Error -550 Has Occurred Die Informationen in diesem Artikel gelten für: Microsoft Exchange Server, Version 4.0, 5.0 und 5.5. Symptome Wenn der Computer, auf dem Exchange ausgeführt wird, nicht mehr reagiert, oder wenn er nach dem korrekten Beenden aller Dienste nicht ordnungsgemäß heruntergefahren wurde, wird auf dem Bildschirm und in den Ereignisprotokollen die folgende Fehlermeldung gezeigt: Error -550 has occurred Nach einem Stromausfall kann es auch vorkommen, dass diese Fehlermeldung in den Datenbanken des Verzeichnisses oder des Informationsspeichers angezeigt wird. Ursache Dieser Fehler bedeutet in der Regel, dass sich die Datenbank in inkonsistentem Zustand befindet und nicht gestartet werden kann. Lösung Stellen Sie zunächst sicher, dass die Datenbank wirklich inkonsistent ist, und versuchen Sie anschließend eine weiche Wiederherstellung. Beenden Sie unbedingt alle Dienste und erstellen Sie eine Sicherungskopie aller Dateien, bevor Sie EDBUTIL.EXE ausführen. 1. Prüfen Sie den Zustand der Datenbank. Exchange 4.0 und 5.0: Führen Sie in der problematischen Datenbank EDBUTIL.EXE mit der Option MH aus, und lassen Sie die Ausgabe in einer Textdatei speichern: EDBUTIL /MH c:\exchsrvr\dsadata\dir.edb >c:\edbdump.txt oder EDBUTIL /MH c:\exchsrvr\mdbdata\priv.edb >c:\edbdump.txt oder EDBUTIL /MH c:\exchsrvr\mdbdata\pub.edb >c:\edbdump.txt Exchange 5.5: Führen Sie in der problematischen Datenbank ESEUTIL.EXE mit der Option MH aus, und lassen Sie die Ausgabe in einer Textdatei speichern: ESEUTIL /MH c:\exchsrvr\dsadata\dir.edb >c:\edbdump.txt oder ESEUTIL /MH c:\exchsrvr\mdbdata\priv.edb >c:\edbdump.txt oder ESEUTIL /MH c:\exchsrvr\mdbdata\pub.edb >c:\edbdump.txt 2. Bearbeiten Sie die Textdatei EDBDUMP.TXT, und prüfen Sie, ob sich die Datenbank in inkonsistentem Zustand befindet. 3. Ist dies der Fall, führen Sie folgende Befehle aus: Exchange 4.0 und 5.0: EDBUTIL /R /DS Exchange 5.5: ESEUTIL /R /DS Wenn Sie nicht die Verzeichnisdatenbank, sondern den privaten oder öffentlichen Informationsspeicher wiederherstellen wollen, verwenden Sie anstelle von /DS die Optionen /ISPRIV bzw. /ISPUB. Q152959, XADM: How to Remove the First Exchange Server in a Site Überarbeitungsdatum: 03.02.1998 Die Informationen in diesem Artikel gelten für: Microsoft Exchange Server, Version 4.0 und 5.0. Zusammenfassung In diesem Artikel werden die Schritte beschrieben, mit denen der erste Exchange-Server, der an einem Standort installiert wurde, entfernt werden kann. Auf dem ersten Server an einem Standort befinden sich standardmäßig außer Postfächern und öffentlichen Ordnern auch noch die Ordner des Standorts, für die dieser Server verantwortlich ist: der Ordner des Offlineadressbuchs (OAB), der Ordner mit den Schedule+-Zeitplaninformationen und, falls vorhanden, der Ordner mit den globalen Formularen der Organisation. Die später installierten Server rufen diese Informationen standardmäßig von diesem Server ab. Wenn also beispielsweise der dritte an dem Standort installierte Server das Offlineadressbuchs (OAB) generieren soll, muss er eine Verbindung mit dem ersten Server herstellen. Wenn Sie den ersten Server des Standorts entfernen, ohne die im Folgenden beschriebenen Schritte durchzuführen, können Sie danach möglicherweise nicht mehr auf die Daten der Ordner des Standorts zugreifen. Außerdem ist der erste Server standardmäßig für die Routingberechnungen zuständig, und er aktualisiert auch die Gateway-Routingtabelle (GWART) des Standorts. Bevor Sie den Server von dem Standort entfernen, müssen Sie also auch diese Aufgabe einem anderen Server zuweisen. Die dazu notwendige Prozedur wird in dem folgenden Artikel der Knowledge Base erklärt: Q162012, XADM: Unable to Change the Routing Calculation Server. Wenn Sie den ersten Server an einem Standort bereits entfernt haben, ohne diesen Artikel zu lesen, dann lesen Sie jetzt Q152960, XADM: Rebuilding the Site Folders in a Site. Weitere Informationen Bevor Sie den ersten Exchange-Server an einem Standort entfernen, sollten Sie die folgenden Schritte durchführen, um Probleme zu vermeiden: Wichtig: Alle Benutzer und öffentlichen Ordner (keine Standortordner), deren Stammserver der erste Server am Standort ist, müssen auf andere Server an dem Standort verlegt werden, damit keine Daten verloren gehen. Weitere Informationen finden Sie in der Dokumentation von Microsoft Exchange Server. Offlineadressbuch 1. Wählen Sie den Server am Standort aus, auf den Sie die OAB-Datei verschieben wollen. 2. Klicken Sie im Programm Exchange Administrator auf den Container Konfiguration und öffnen Sie die Eigenschaften des Objekts DSStandortkonfiguration. 3. Markieren Sie in der Dropdown-Liste Offline-Adreßbuchserver den Server, den Sie in Schritt 1 ausgewählt haben. 4. Klicken Sie auf die Schaltfläche Offline-Adreßbuch jetzt erstellen. 5. Klicken Sie aufOK. Schedule+-Zeitplaninformationen sowie globale Formulare 1. Wählen Sie einen Server am Standort aus, auf dem Sie die Schedule+Informationen und die Formulare der Organisation speichern wollen. 2. Klicken Sie im Programm Exchange Administrator auf den Container Konfiguration, den Container Server und den Server, den Sie in Schritt 1 ausgewählt haben. 3. Doppelklicken Sie auf das Objekt Öffentlicher Informationsspeicher. 4. Klicken Sie auf die Registerkarte Instanzen. 5. Markieren Sie im Listenfeld Öffentliche Ordner die Ordner Schedule+ Zeitplaninformationen und Globale Formulare, und klicken Sie auf Hinzufügen. Beachten Sie, dass bei diesen Ordnern nach dem Bindestrich der Name des ersten Servers stehen sollte, beispielsweise Schedule+ Zeitplaninformationen - ersterserver. Bei diesem Prozess wird auf dem in Schritt 1 ausgewählten Server ein Replikat dieser Ordner erstellt. 6. Klicken Sie auf OK. Server für die Berechnung der Routing-Tabelle 1. Wählen Sie am Standort einen Server aus, der von jetzt an die Routingberechnungen durchführen soll. 2. Klicken Sie im Programm Exchange Administrator auf den Container Konfiguration und doppelklicken Sie auf das Objekt Standortadressierung. 3. Klicken Sie auf die Registerkarte Allgemein. 4. Markieren Sie im Listenfeld mit den Servern für die Berechnung der RoutingTabelle den in Schritt 1 ausgewählten Server. Damit die Schaltfläche Übernehmen aktiviert wird und die Änderungen erhalten bleiben, müssen Sie in den Eigenschaftenseiten noch eine weitere Änderung vornehmen. 5. Klicken Sie auf die Registerkarte Routing, und klicken Sie auf die Schaltfläche Routing neu berechnen. 6. Klicken Sie auf OK. Anmerkung: Wenn Sie prüfen wollen, ob dieser Vorgang erfolgreich verlaufen ist, schalten Sie den ersten Server am Standort vorübergehend ab, oder trennen Sie seine Verbindung zum Netzwerk, nachdem Sie diese Schritte druchgeführt haben. Erst wenn Sie sicher sind, dass die Änderungen übernommen wurden (starten Sie einen Exchange-Client, und prüfen Sie, ob Sie auf den Schedule+-Zeitplan eines anderen Benutzers zugreifen und ein Offlineadressbuch erstellen können), können Sie den ersten Server permanent vom Netzwerk trennen oder ausschalten. Anschließend müssen Sie die im Folgenden beschriebenen Schritte durchführen, um den Server dauerhaft von dem Standort entfernen zu können. 7. Klicken Sie im Programm Exchange Administrator auf den Container Konfiguration und dann auf den Container Server. 8. Markieren Sie den ersten Server am Standort. 9. Klicken Sie im Menü Bearbeiten auf den Befehl Löschen oder drücken Sie ENTF. Anmerkung: Wenn im Container Empfänger des ersten Servers am Standort nach dem Verschieben aller anderen Objekte auf den neuen (Stamm-)Server weiterhin ein Exchange Schedule+-Zeitplanconnector angezeigt wird, wird, wird dieser Connector nicht automatisch verschoben, sondern er wird beim entfernen des ersten Servers von dem Standort gelöscht. Um dieses Objekt erneut zu erstellen, müssen Sie die Schritte durchführen, die in dem folgenden Artikel der Knowledge Base beschrieben sind: Q148199, XCLN: Recreating a Deleted Schedule+ Free/Busy Agent. Frei/Belegt-Informationen im Zeitplan In den Standortordner Schedule+-Zeitplaninformationen werden immer wieder neue Daten eingetragen, wenn sich Benutzer in Schedule+ anmelden und Änderungen durchführen. Während dieser Zeit stehen die Zeitplaninformationen mancher Benutzer vorübergehend nicht zur Verfügung. Solange sich noch kein Benutzer angemeldet und einen Termin eingetragen hat, können auch keine Zeitplaninformationen angezeigt werden.) Q177635 XADM: How to Set Up a Disaster Recovery Server for DIR.EDB Überarbeitungsdatum: 27. Januar 1998 Die Informationen in diesem Artikel gelten für: Microsoft Exchange Server, Version 4.0, 5.0 und 5.5. Zusammenfassung In diesem Artikel wird beschrieben, wie Sie einen Microsoft Exchange-Computer so einrichten, dass er Informationen aus dem Exchange-Verzeichnisdienst, die in der Datei DIR.EDB enthalten sind, wiederherstellen kann. Weitere Informationen Die Datei DIR.EDB ist für jeden Windows NT-Computernamen spezifisch und kann daher nur auf einem Server mit demselben Computernamen wiederhergestellt werden. Anmerkung: Mit den folgenden Schritten können Sie offline einen Server einrichten. Sie können diese Schritte nicht in der im Einsatz befindlichen Exchange-Umgebung durchführen. Um einen Server einzurichten, auf dem die Datei "DIR.EDB" wiederhergestellt werden kann, führen Sie folgende Schritte durch: 1. Richten Sie in der Domäne, in der sich das Dienstkonto von Exchange befindet, einen Computer als BDC ein, und installieren Sie auf ihm dieselbe Version von Windows NT Server und dieselben Service Packs, die auch auf dem im Einsatz befindlichen Exchange-Computer installiert sind. 2. Stellen Sie sicher, dass auf dem Wiederherstellungsserver genügend Festplattenspeicher frei ist und dass er alle anderen notwendigen Geräte wie CDROM- und Bandlaufwerk besitzt. Trennen Sie diesen Computer von dem im Einsatz befindlichen Netzwerk an einem Hubstandort. 3. Stufen Sie den Server zum PDC auf, und starten Sie ihn neu. 4. Fügen Sie im Benutzer-Manager für Domänen einen BDC mit demselben Windows NT-Computernamen hinzu, den auch der Exchange-Server besitzt, und benennen Sie den Wiederherstellungsserver auf den Computernamen des ursprünglichen Exchange-Servers um. (Stellen Sie zuvor sicher, dass der Computer nicht mit dem Netzwerk verbunden ist.) Weitere Informationen finden Sie in der Knowledge Base im Artikel Q150298, Renaming a Windows NT PDC or BDC. 5. Starten Sie den Server neu. Auf dem Wiederherstellungsserver wird jetzt dieselbe Version von Windows NT Server ausgeführt wie auf dem im Einsatz befindlichen Exchange-Server. 6. Installieren Sie Exchange Server, wobei Sie zwar denselben Organisations- und Standortnamen angeben, der auch auf dem im Einsatz befindlichen ExchangeServer verwendet wurde, aber die Option Neuen Standort erstellen aktivieren. Wählen Sie unbedingt dasselbe Dienstkonto, das auch in der im Einsatz befindlichen Domäne für die Exchange-Dienste verwendet wird. 7. Aktualisieren Sie auf dasselbe Service Pack, das auch auf dem im Einsatz befindlichen Exchange-Server verwendet wird. 8. Stellen Sie aus einer Sicherungskopie den vorherigen ExchangeVerzeichnisspeicher und/oder den Exchange-Informationsspeicher wieder her. Q163686, XADM: What to do if the Service Account is Deleted Überarbeitungsdatum: 28. Oktober 1997 Die Informationen in diesem Artikel gelten für: Microsoft Exchange Server, Version 4.0 und 5.0. Zusammenfassung Die Exchange-Dienste benötigen zu ihrem Start ein Domänenkonto mit der Bezeichnung Microsoft Exchange-Dienstkonto in Windows NT Server. In diesem Artikel wird erläutert, was Sie tun können, wenn dieses Dienstkonto aus Versehen gelöscht wird. Weitere Informationen Bei der Einrichtung des Systems wird dem Dienstkonto standardmäßig die Zugriffsberechtigung auf alle Objekte im Exchange-Verzeichnis zugewiesen. Die Windows NT-Konten im Verzeichnis werden nicht anhand ihres Namens, sondern anhand ihrer SID-Werte referenziert. Wenn das Dienstkonto aus der Windows NT-Kontendatenbank gelöscht wird, können die Exchange-Dienste nicht gestartet werden. Selbst wenn das Dienstkonto mit demselben Namen und Kennwort neu erstellt wird, ist der zugehörige SID-Wert nicht mehr derselbe wie bei dem gelöschten Konto, daher kann der Dienst nicht mehr auf Verzeichnisobjekte zugreifen. Lösung Die einzig empfehlenswerte Lösung in dieser Situation ist eine Wiederherstellung der SAM-Datenbank in Windows NT von einer aktuellen Sicherungskopie. Dabei wird das gelöschte Dienstkonto mit seinem ursprünglichen SID-Wert wiederhergestellt, so dass die Exchange-Dienste wieder gestartet werden können. Wenn Sie keine Sicherungskopie der SAM-Datenbank zur Verfügung haben, bleibt nur die Möglichkeit, Exchange Server auf allen Servern, die vom Verlust des Dienstkontos in Mitleidenschaft gezogen wurden, neu zu installieren. Dabei können Sie zwar die Informationen aus dem Exchange-Informationsspeicher sichern (PRIV.EDB und PUB.EDB), aber das Verzeichnis müssen Sie neu erstellen, so dass alle verzeichnisspezifischen Informationen verloren gehen (benutzerdefinierte Empfänger, Verteilerlisten, Postfachinformationen, Connectors usw.). Erzwungene Wiederherstellung Wenn sich nach einer Wiederherstellung die Verzeichnisinformationen auf einem Server verändern oder automatisch bereinigt werden, könnte es zu einem unerwünschten nachträglichen Auffüllen kommen. Das bedeutet, dass zuvor von dem wiederhergestellten Server replizierte Veränderungen von einem anderen Server wieder zurück repliziert werden, weil die Änderungsaufzeichnungen auf dem anderen Server aktueller sind als die der wiederhergestellten Datenbank. Das Tool Authoritative Restore (AUTHREST.EXE) ermöglicht es Ihnen, die Replikation einer von einer Sicherungskopie wiederhergestellten Verzeichnisdatenbank auf andere Server zu erzwingen. Für den Gebrauch dieses Tools können Sie die Hilfe von Microsoft Technical Support anfordern. In der Regel wird davon ausgegangen, dass eine wiederhergestellte Datenbank gegenüber den kollektiven Informationen in allen Verzeichnisreplikaten in der Organisation veraltet ist. Daher wird ein wiederhergestelltes Verzeichnis normalerweise die in ihm enthaltenen Informationen durch die aktuelleren Daten auf anderen Servern austauschen, weil bei einer Wiederherstellung meist eine verlorene Datenbank bzw. ein ausgefallener Server wiederhergestellt wird. In bestimmten Situationen ist dies jedoch nicht erwünscht. Wenn beispielsweise durch einen Administrationsfehler Tausende von Postfächern oder wichtige Konfigurationsinformationen gelöscht wurden, soll durch die Wiederherstellung nicht ein Server wieder funktionsfähig gemacht werden, sondern das gesamte System soll wieder in den Zustand vor der unerwünschten Veränderung versetzt werden. Ohne das Tool Authoritative Restore müssten Sie jeden einzelnen Server in der Organisation von einer Sicherungskopie wiederherstellen, die erstellt wurde, bevor der Fehler passiert ist. Alternativ müssten Sie jeden Server an dem betreffenden Standort wiederherstellen und anschließend alle Replikationshubs an den anderen Standorten zu einer vollständigen Neusynchronisation zwingen. Wenn Sie nämlich nur einen Server oder die Server einen nach dem anderen wiederherstellen, werden die wiederhergestellten Daten auf jedem Server sehr schnell mit den aktuelleren (falschen) Informationen auf allen anderen Servern am Standort überschrieben. Mit dem Tool Authoritative Restore können Sie die Objektversionen und USNs auf allen Objekten in dem Verzeichnis, auf die Schreibzugriff besteht, erhöhen, so dass die Daten aus der Sicherungskopie scheinbar aktueller sind als die Kopien auf anderen Servern. Bei der normalen Replikation werden die wiederhergestellten Informationen dann an alle anderen Server weitergegeben. Auf diese Weise müssen Sie nicht alle Server wiederherstellen, sondern es genügt, wenn Sie einen Server wiederherstellen (den Server mit der Sicherungskopie, die möglichst kurz vor dem Fehler erstellt wurde). Die Datei AUTHREST.EXE befindet sich auf der CD-ROM von Exchange Server im Verzeichnis \Support\Utils\<Plattform>\. Service Packs wiederherstellen Wiederhergestellte Datenbanken müssen unter derselben Version von Exchange ausgeführt werden, unter der sie auch erstellt wurden. Daher dürfen Sie nach einer Wiederherstellung die Dienste erst dann starten, wenn die Programmversion in allen Einzelheiten korrekt installiert ist. Wenn Sie beispielsweise Exchange Service Pack 2 verwenden und die Original-Server-CD-ROM und den Code von SP2 zur Verfügung haben, müssen Sie den Code von SP2 zuerst laden, bevor Sie Exchange mit der von einem Server mit SP2 wiederhergestellten Datenbank ausführen. Zu diesem Zweck stehen Ihnen die Befehle setup /r und update /r zur Verfügung, mit denen Sie den Original-Servercode und das Service Pack installieren können. Das Setupprogramm wird damit angewiesen, die Dienste nicht zu starten. Die Option /r gibt an, dass die Datenbanken aus einer wiederhergestellten Sicherungskopie stammen. Sie können setup und update auch ohne die Option /r ausführen. Dann müssen Sie zu dem Zeitpunkt, wenn das korrekte Service Pack installiert ist, die Datenbanken wiederherstellen, um die von Setup neu erstellten Datenbanken zu ersetzen. Befolgen Sie unbedingt die richtigen Wiederherstellungsprozeduren. Setup und /r können in manchen Fällen nicht verwendet werden: Mit dem Befehl setup /r werden die Dateien DIR.EDB, PUB.EDB und PRIV.EDB nicht erstellt. Normalerweise werden diese Dateien anhand des Organisationsund Standortnamens erstellt, den Sie während des Setups eingeben. Der Befehl setup /r hingegen kopiert die Datei DIR.EDB von der Exchange Server-CD-ROM genau so wie sie ist. Mit dieser standardmäßigen Datei DIR.EDB können Sie den Verzeichnisdienst nach dem Ausführen von setup /r nicht starten. Wenn Sie nur den Informationsspeicher und nicht den Verzeichnisdienst wiederherstellen wollen, dürfen Sie setup /r nicht ausführen. Mit diesem Befehl müssen Sie alle Datenbankdateien wiederherstellen (DIR.EDB, PUB.EDB und PRIV.EDB). Die Option /r wird von dem Programm UPDATE.EXE in den Service Packs von Exchange Server 4.0 nicht unterstützt. Wenn Sie einen Exchange 4.0-Server nach einem Systemabsturz wiederherstellen, dürfen Sie bei der Ausführung von SETUP.EXE die Option /r nicht verwenden. Wenn das Setupprogramm abgeschlossen ist, führen Sie UPDATE.EXE ebenfalls ohne die Option /r aus, um die erforderlichen Service Packs zu installieren und die Exchange-Dienste mit den Standarddaten zu starten. Dann können Sie den Informationsspeicher und/oder den Verzeichnisdienst von einer Sicherungskopie wiederherstellen. Ein gelöschtes Postfach von einer OST-Datei wiederherstellen OST-Dateien sind Slave-Replikate von serverbasierten Ordnern. Wenn Sie den MasterOrdner löschen, bleibt der Slave als Waise zurück. Wenn das ursprüngliche Exchange-Profil nicht verändert wurde, müsste es möglich sein, mit der alten OST-Datei offline zu starten und die Daten wiederherzustellen, indem Sie sie in eine PST-Datei kopieren. Wenn jedoch das alte Profil gelöscht oder verändert wurde (wenn es also zur Anmeldung an einem neuen Postfach verwendet wird), sind die Daten unwiderruflich verloren. Der Grund dafür liegt an den Sicherheitsmechanismen der OST-Dateien: die Windows NT-Echtheitsprüfung kann nicht durchgeführt werden, wenn die Benutzer offline sind. Stattdessen müssen die Benutzer beweisen, dass sie zur Anmeldung an dem serverbasierten Master berechtigt sind, damit der lokale Zugriff auf die OST-Datei freigegeben wird. Um diese Prozedur durchzusetzen, wird in Exchange aus der eindeutigen Zugangs-ID des Benutzerpostfachs ein verschlüsselter Cookie erstellt, während der Benutzer am Server angemeldet ist. Diese wird dann im Exchange-Profil des Benutzers sicher gespeichert. So hat also das Profil den Schlüssel zu der OST-Datei. Wenn ein Benutzer auf die OST-Datei zugreifen will, prüft die OST-Datei, ob dieser Schlüssel in seinem Profil vorhanden ist. Das bedeutet, dass die Daten einer OST-Datei nicht wiederhergestellt werden können, wenn das Postfach auf dem Masterserver gelöscht wird und wenn das Profil mit dem Schlüssel zur OST-Datei gelöscht oder verändert wird. PST- und OST-Dateien mit "SCANPST.EXE" reparieren Das Programm SCANPST, das auch unter der Bezeichnung "Posteingang reparieren" bekannt ist, repariert sowohl PST- als auch OST-Dateien. SCANPST ähnelt der MMFÜberprüfungsfunktion in Microsoft Mail und wird standardmäßig im Unterverzeichnis des Exchange-Clients installiert. Es prüft die ausgewählte Datei auf acht verschiedenen Weisen. Sie haben die Möglichkeit, die vorhandene Datei zu sichern, bevor die Reparatur durchgeführt wird. Dazu benötigen Sie allerdings genügend freien Speicherplatz, der mindestens so groß ist wie die PST- oder OST-Datei. Bildschirm SCANPST SIDs (Sicherheits-IDs), Geheimobjekte und Windows NTbasierte Computerkonten Beispiel für einen sicheren Kanal in Windows NT im normalen Betrieb Beachten Sie, dass der Server EXS1 die Windows NT-SID xyz hat. Jeder Windows NTbasierte Computer hat eine eindeutige SID, die zur Echtheitsprüfung in der Domäne verwendet wird (xyz entspricht nicht dem tatsächlichen Format für SIDs). Um eine Verbindung zu der Domäne herstellen zu können, muss der Windows NT-BDC oder Mitgliedsserver eine zusammengehörende Kombination aus SID und LSA (Local Security Authority)-Kennwort besitzen, damit die Echtheitsprüfung stattfinden kann. Beispiel für die fehlgeschlagene Herstellung eines sicheren Kanals Dieses Beispiel zeigt, was geschieht, wenn Sie das Konto des Exchange-basierten Servers nicht zuerst löschen und dann neu hinzufügen, bevor Sie einen Wiederherstellungsserver installieren. Wenn Sie einen Wiederherstellungsserver einrichten, indem Sie Windows NT neu installieren und denselben Computernamen verwenden, schlägt NETLOGON fehl, weil das alte Computerkonto und die SID in der SAM-Datenbank der Domäne erhalten geblieben sind. Diese beiden können nur im Benutzer-Manager für Domänen zurückgesetzt werden, indem Sie das Computerkonto löschen und neu hinzufügen. Beispiel für ein neu eingerichtetes Computerkonto In dieser Abbildung sehen Sie ein Beispiel für ein neu eingerichtetes Computerkonto. Wenn das alte Computerkonto gelöscht und der SAM-Datenbank der Domäne wieder neu hinzugefügt wird, wird der SAM-Eintrag zunächst in den Status der Initialisierung versetzt. Wenn der neue Server hinzugefügt wird, wird ein lokales LSA-Geheimobjekt zusammen mit einer SID erstellt. Auf diese Weise wird das LSA-Geheimobjekt (das lokal auf dem BDC oder Mitgliedsserver gespeichert wird) mit dem SAM-Objekt des entsprechenden Computers synchronisiert. Das bei diesem Prozess generierte Kennwort wird jedes Mal benutzt, wenn der BDC oder Mitgliedsserver sich in der Domäne anmeldet. Bei diesem Prozess wird ein sicherer Kanal zwischen dem BDC oder Mitgliedsserver und dem PDC hergestellt. Das Kennwort für diesen sicheren Kanal wird von NETLOGON automatisch geändert, damit es nicht entschlüsselt werden kann. Das LSA-Geheimobjekt wird vom Setupprogramm bei der ersten Installation oder beim Hinzufügen eines Servers zu einer Domäne erzeugt. Das SAM-Computerkonto wird jedoch vom Benutzer-Manager für Domänen erstellt. Weitere Informationen finden Sie in der Knowledge Base im Artikel Q102476, Changing the Name of Windows NT Workstations and Servers. Allgemeine Sicherheitsmaßnahmen Tägliche Sicherungskopien erstellen und überprüfen Die Überprüfung der Sicherungskopien ist ein wichtiger Schritt im Prozess der Systemwiederherstellung (Daten können ja nur von gültigen Sicherungskopien wiederhergestellt werden), doch oft wird sie vernachlässigt. Gehen Sie nicht einfach davon aus, dass die Sicherungsbänder richtig ausgetauscht und die Daten ordnungsgemäß gesichert werden, sondern sorgen Sie dafür, dass dieser Prozess jeden Tag überprüft wird. Prüfen Sie immer alle Sicherungsprotokolle und beseitigen Sie alle Fehler und Inkonsistenzen. Stellen Sie sicher, dass auch die Registrierung und der Schlüsselverwaltungsserver gesichert werden. Bei erfolgreich durchgeführten vollständigen Datensicherungen werden nicht nur gültige Daten gesichert, die Sie zur Wiederherstellung des Systems verwenden können, sondern es werden auch die Transaktionsprotokolle zurückgesetzt und entfernt, so dass wieder freier Speicherplatz entsteht. Wenn die täglichen Sicherungsvorgänge fehlschlagen, werden die Transaktionsprotokolle nicht bereinigt, so dass das Laufwerk, auf dem sie gespeichert werden, sehr schnell voll wird. Wenn die Umlaufprotokollierung aktiviert ist, ist die Gewinnung freien Speicherplatzes kein so wichtiges Problem, aber andererseits können Sie die Umlaufprotokollierung deaktivieren, wenn Sie den Speicherplatz auf andere Weise frei machen. Sicherungskopien überprüfen 1. Stellen Sie die Exchange-Datenbanken von der Sicherungskopie wieder her. 2. Wenn Sie Exchange 5.5 verwenden, führen Sie die Integritätsprüfung der Datenbank aus (ESEUTIL /G). 3. Wenn Sie Exchange 4.0 oder 5.0 verwenden, defragmentieren Sie die Datenbanken (EDBUTIL /D). Periodische dateibasierte Sicherungen Damit Sie alle Konfigurationsdaten aufzeichnen können, müssen Sie regelmäßig vollständige dateibasierte Sicherungen durchführen. Um sicherzustellen, dass alle zu Exchange gehörenden Dateien geschlossen sind und gesichert werden können, beenden Sie alle Dienste. Dies können Sie beispielsweise während der für Wartungsaufgaben vorausgeplanten Zeitspanne tun. Für die Informationsspeicher- und Verzeichnisdatenbanken ist dagegen die Online-Datensicherung (nicht dateibasiert) empfehlenswert. Vorhandene Protokolldateien vor der Wiederherstellung sichern Eine bewährte Vorsichtsmaßnahme besteht darin, alle vorhandenen Protokolldateien zu sichern, bevor Sie einen Exchange-Server wiederherstellen. Wenn Daten verloren gehen oder wenn Sie aus Versehen einen alten Sicherungssatz wiederherstellen, können Sie die Protokolle zur Wiederherstellung des ursprünglichen Zustands verwenden. Betrachten Sie beispielsweise die folgende Situation. Am Sonntag- und Montagabend wurde jeweils eine vollständige Onlinesicherung durchgeführt. Der Informationsspeicher wird am Dienstag ausgeführt und erzeugt 50 Protokolldateien. Dann tritt ein Problem auf, und Sie müssen das System von Sicherungskopien wiederherstellen. Sie wollen also die vollständige Sicherung vom Montagabend wiederherstellen, doch aus Versehen verwenden Sie die Sicherung vom Sonntagabend. Nun haben Sie eine Datenbank vom Sonntag wiederhergestellt, die Protokolldateien auf dem Laufwerk wurden aber am Dienstag erstellt. Die Protokolldateien vom Montag wurden bei der vollständigen Sicherung am Montagabend vom Laufwerk gelöscht. Beim Starten des Dienstes entdeckt die Datenbankengine eine Lücke in der Reihenfolge der Protokolldateien (die Dateien vom Montag fehlen), daher löscht sie die Protokolldateien vom Dienstag (alle Protokolldateien nach der Lücke), weil sie nicht abgespielt werden können und weil der Dienst Protokolle mit den von ihnen verwendeten Nummern erstellen muss. Wenn das passiert, gibt es keine Möglichkeit mehr, die am Dienstag erzeugten Daten wiederherzustellen. Wenn Sie die vorhandenen Protokolldateien jedoch vor der Wiederherstellung gesichert hätten, könnten Sie auch in der beschriebenen Situation den Zustand vom Dienstag wiederherstellen. Das Format der Bandsicherungen standardisieren Die zur Systemwiederherstellung verwendeten Geräte müssen mit den Bandgeräten an den im Einsatz befindlichen Computern kompatibel sein. Wenn Sie eine neue Art von Bandgeräten einführen, müssen Sie auch auf den Wiederherstellungscomputern ein kompatibles Modell einrichten. Testen Sie neue Geräte immer vor dem Einsatz und testen Sie auch die bereits eingerichteten Geräte immer wieder regelmäßig. Eine USV einrichten und regelmäßig testen Sie dürfen nicht die Einstellung entwickeln, dass bei einem Stromausfall an einem Server, auf dem Exchange läuft, ohnehin auch alle anderen Server ausfallen. Richten Sie wenn irgend möglich eine unterbrechungsfreie Stromversorgung (USV) ein, und prüfen Sie sie dann regelmäßig. In manchen Fällen decken die USVs nicht alle Stromquellen an einem Standort ab. Wenn Sie keine dezidierte USV haben, muss Ihr Layout von Elektrikern oder technischem Personal überprüft und getestet werden. Geben Sie sich nicht damit zufrieden, dass Sie selbst abgesichert sind. Es nützt den Benutzern nichts, dass jemand irgendwann ein Papier unterschrieben hat, das besagt, dass alle Stromquellen USVgesichert sind, wenn sie alle Daten verloren haben. USV-Systembatterien für Server sind nach etwa drei Jahren nicht mehr zu gebrauchen, behalten Sie sie also im Auge. Regelmäßige Notfallübungen Bei einer Übung können Sie feststellen, wie gut Sie in der Lage wären, das System nach einem Ausfall wiederherzustellen, und außerdem können Sie Ihre Pläne zur Systemwiederherstellung überprüfen. Bauen Sie eine Testumgebung auf, und versuchen Sie, eine vollständige Systemwiederherstellung durchzuführen. Verwenden Sie dazu unbedingt die Daten aus den Sicherungskopien des im Einsatz befindlichen Systems, und messen Sie, wie lange der Prozess dauert. Anhand dieser Informationen können Sie verlässliche und genaue Pläne für den Ernstfall ausarbeiten. Aus den Ergebnissen der Übung sollten Sie erkennen, dass bis zu einem Drittel der Gesamtdauer der Wiederherstellung mit der Sammlung von Informationen, dem Entwurf eines Plans und der Bereitstellung der erforderlichen Werkzeuge vergeht. Den größten Effekt erzielen Sie, wenn Ihre Mitarbeiter nicht wissen, dass es sich um eine Übung handelt. Dies ist die wertvollste Erfahrung, die Sie für die Planung der Systemwiederherstellung gewinnen können. Bei der Platzierung von Servern die Umgebung berücksichtigen Wenn Sie Server einrichten, sollten Sie zuvor die Umgebung inspizieren. Stellen Sie sicher, dass die Energieversorgung ausreicht. Stellen Sie nach Möglichkeit eigene Stromleitungen für die Exchange-Ausstattung zur Verfügung. Überprüfen Sie die vorhandenen Stromstärken und die neuen Anforderungen an die Stromstärke. Platzieren Sie die Server an physisch sicheren Orten und sorgen Sie dafür, dass sich die Raumtemperatur immer in akzeptablen Bereichen befindet. Wenn an dem Standort Sprinklerlöschanlagen vorhanden sind, dürfen Sie die Server nicht darunter aufstellen. Führen Sie bei der Platzierung von Servern grundlegende präventive Wartungsmaßnahmen durch. Windows NT-Ereignisprotokolle täglich prüfen Überprüfen Sie die Protokolle jeden Tag. Auf diese Weise erkennen Sie Probleme schon frühzeitig, manchmal sogar, bevor sie ihre Wirkung entfalten. Nutzen Sie die umfassenden Protokollierungsfunktionen von Exchange und die Protokolliertools, die Sie auf der Begleit-CD zu Microsoft BackOffice. Die technische Referenz finden können. Ein Notfall-Kit zusammenstellen Stellen Sie ein Notfall-Kit zusammen, das Aufzeichnungen über die Konfiguration des Betriebssystems, über die Konfiguration der Festplattenpartitionen, die RAIDKonfiguration, die Hardwarekonfiguration, Konfigurierungsdisketten für EISA/MCA, Aufzeichnungen über die Exchange-Konfiguration, eine Windows NT-Notfalldiskette, Aufzeichnungen über die Einstellungen der Leistungsoptimierung usw. umfasst. Diese Materialien lassen sich leicht sammeln, und sie verkürzen die Dauer der Wiederherstellung. Ein Großteil der dazu erforderlichen Zeit wird nämlich oft damit verbracht, die Informationen und Disketten zu suchen, die zur Konfiguration des wiederhergestellten Systems notwendig sind. Den Zeitplan für die Wartung öffentlich bekanntgeben Die Server, auf denen Exchange läuft, müssen immer wieder überprüft und gewartet werden. In manchen Organisationen werden zwar Zeitpläne zur Wartung der Großrechner ausgearbeitet, die Server werden dabei jedoch außer Acht gelassen. Durch eine geplante Wartung können Sie aber in der Regel eine unvorhergesehene Abschaltung der Server vermeiden. Geben Sie die Zeiten, zu denen die Server abgeschaltet sind, den Benutzern bekannt, denn diese erwarten oft, dass die Server sieben Tage pro Woche 24 Stunden lang in Betrieb sind. Zusätzlich zur regelmäßigen Wartung müssen neue Service Packs, bessere Hardware und aktualisierte Softwareversionen installiert werden. Manchmal müssen Sie den Informationsspeicherdienst beenden, um die Größe der Speicherdateien mithilfe von EDBUTIL.EXE zu verringern. Lassen Sie die Benutzer immer im voraus wissen, wann und wie lange das System abgeschaltet wird. Die durch die Abschaltung verursachten Kosten kalkulieren Solche Kostenschätzungen sind sehr nützlich für die Planung des Einkaufs neuer Ausrüstung. Es gibt verschiedene Modelle zur Berechnung dieser Kosten. Oft werden die ausgefallenen Arbeitsstunden und Bestellungen, die Kosten verspäteter finanzieller Transaktionen und die Kosten verspätet getroffener dringender Entscheidungen eingerechnet. Bänder und Ausrüstung an anderen Orten lagern Wenn Sie die Sicherungsbänder aus juristischen Gründen oder aus Sicherheits- oder Kostengründen nicht an einen anderen Standort außerhalb Ihrer Organisation schicken können, sollten Sie sie wenigstens an einen anderen Standort innerhalb Ihrer Organisation senden. Geräte speziell für die Wiederherstellung beschaffen und eine Testumgebung für die Wiederherstellung einrichten Bestimmte Hardwaregeräte sollten Sie speziell für die Wiederherstellung verwenden. Oft wird bei kleinen Ausgaben gespart, und die großen Folgen werden missachtet, so dass mit Test- und Wiederherstellungsausstattung geizig umgegangen wird, weil die Geräte lieber im Netzwerk eingesetzt werden. Sie müssen jedoch Geräte speziell für die Wiederherstellung vorsehen und sie funktionsbereit und verfügbar halten. Eine Testumgebung hat neben ihrem ständigen Nutzen auch oft noch eine lebenswichtige Funktion bei der Systemwiederherstellung. Wenn Sie das System mit EDBUTIL wiederherstellen und damit auch die Datenbanken defragmentieren, benötigen Sie manchmal den doppelten Speicherplatz der größten Informationsspeicher-Datenbank in der im Einsatz befindlichen Umgebung. Meist ist es kostenwirksam, einen Wiederherstellungsserver zu unterhalten, auf dem genügend Festplattenspeicher zur Verfügung steht. Konfigurationseinstellungen an den im Einsatz befindlichen Servern sorgfältig aufzeichnen Diese Informationen benötigen Sie zur Konfiguration des Wiederherstellungsservers. Halten Sie die Aufzeichnungen der Windows NT-Feineinstellungen, der Verzeichnisinformationen, Protokolladressen, der Einstellungen der Exchange-Connectors usw. immer auf dem Laufenden. Machen Sie sie zu einem Bestandteil des Notfall-Kits. Den Informationsspeicher überwachen Überwachen Sie die Größenzunahme des Informationsspeichers und die Leistung des Servers und arbeiten Sie im voraus einen Plan aus, mit dem Sie den Erweiterungs- und Logistikproblemen begegnen können. Richten Sie in Windows NT Alarmmeldungen ein, die ausgegeben werden, wenn der Festplattenspeicher knapp wird, und überwachen Sie den freien Speicherplatz. Nutzen Sie die Objekte für den Informationsspeicher im Systemmonitor. Einen Archivierungsplan ausarbeiten Mithilfe eines Archivierungsplans können die Benutzer die auf dem Server gespeicherten Nachrichten in lokalen Dateien speichern. Dadurch wird die Größe des Informationsspeichers auf dem Server reduziert. Lassen Sie die Benutzer PST-Dateien auf lokalen Laufwerken oder auf einer separaten Festplatte bzw. einem separaten Server speichern. Richten Sie bei Bedarf einen eigenen Dateiserver ein, auf dem die PST-Dateien archiviert werden, sonst kann es sein, dass die Datenmenge im Informationsspeicher zwar reduziert wird, aber gleichzeitig in einem anderen Bereich derselben Festplatte bzw. desselben logischen Laufwerks wieder zunimmt. Dies kann sehr große Auswirkungen haben, denn in PST-Dateien werden Nachrichten im RTF- oder ASCII-Format gespeichert und außerdem können für PST-Dateien keine Speichergrenzen festgelegt werden. Ihre Strategien zur Datensicherung müssen alle wichtigen Daten berücksichtigen, inklusive der PST-Dateien der Benutzer. Beim Erstellen der PST- und OST-Dateien sollten Sie eine Verschlüsselung einsetzen. Grundsätze zur Konfiguration von Exchange Die Rollen der Microsoft Exchange-Server Wenn Sie den Exchange-Server als PDC einrichten und er dann ausfällt, müssen Sie einen anderen Domänen-Controller zum PDC aufstufen. Wenn der Exchange-Server nicht gleichzeitig PDC ist, müssen Sie sich bei einer Wiederherstellung keine Gedanken über Auf- und Abstufungen von Domänen-Controllern machen. Daher sollte der ExchangeServer kein PDC sein. Manche Organisationen richten Exchange Server am liebsten auf einem BDC in der Kontendomäne ein, so dass zur Windows NT-Echtheitsprüfung an Remotestandorten kein zweiter Computer erforderlich ist. Auf diese Weise ersparen Sie sich zwar den Kauf eines Computers, doch Sie müssen genügend RAM für die SAM-Datenbank in Windows NT und die Anforderungen von Exchange Server bereitstellen. Im allgemeinen benötigen die Domänen-Controller von Windows NT Server 2,5-mal so viel RAM wie die SAMDatenbank. Weitere Informationen zur Planung von Domänen finden Sie unter den Titel Windows NT 4.0 Networking Guide im TechNet. Wenn der Exchange-Server als Mitgliedsserver eingerichtet ist (weder PDC noch BDC), fällt kein Speicherbedarf für die SAM-Datenbank der Domäne an. Manche Unternehmen mit Remoteniederlassungen können jedoch Geld sparen, wenn sie den lokalen ExchangeServer so einrichten, dass er die Echtheitsprüfung durchführt (als BDC fungiert) und Messagingdienste leistet. Bei einer ordnungsgemäßen Wiederherstellung des Verzeichnisdienstes müssen Sie Zugriff auf die ursprüngliche SAM-Datenbank haben. Installieren Sie nie einen Exchange-Server in einer Domäne, in der es keinen BDC gibt. Als Alternative können Sie die Exchange-Server in eine große Ressourcendomäne platzieren, in der Vertrauensstellungen zu den einzelnen Kontendomänen bestehen. In diesem Fall können Sie Exchange Server auf BDCs installieren, ohne dass der Arbeitsspeicher wesentlich belastet wird, weil die SAM-Datenbank für die ExchangeRessourcendomäne relativ klein ist. Protokolldateien auf einer eigenen physischen Festplatte speichern Dieser Aspekt ist im Hinblick auf die Leistung der Exchange-Server der wichtigste, und er spielt auch bei der Wiederherstellung des Systems eine Rolle. Wenn die Transaktionsprotokolle auf einer separaten Festplatte untergebracht sind, können Sie sie für die Systemwiederherstellung verwenden, denn wenn die Festplatte mit den Datenbankdateien ausfällt, können Sie die Daten mithilfe der Transaktionsprotokolldateien wiederherstellen. Den Informationsspeicher auf einem RAID5-Stripe-Set oder einem Spiegelsatz speichern Im Informationsspeicher herrscht wahlfreier Zugriff, daher erreicht er auf einem StripeSet oder einem Spiegelsatz hervorragende Leistungen. Darüber hinaus wird auf diese Weise die Wiederherstellung erleichtert. Den Schreibcache des SCSI-Controllers deaktivieren Auch durch die Deaktivierung des Schreibcaches des SCSI-Controllers können Sie Datenverluste vermeiden. Wenn auf Programmierungsebene das Flag "write-through" gesetzt ist, verwendet Windows NT keine Puffer. In diesem Fall ist daher garantiert, dass die Daten auf die Festplatte geschrieben wurden, wenn ein Programm von Windows NT das Signal erhält, dass ein Schreibvorgang abgeschlossen wurde. Für die Protokollierung der Transaktionen in Exchange ist dies sehr wichtig. Wenn der Schreibcache aktiv ist, meldet Windows NT der anfragenden Anwendung fälschlicherweise die Beendigung des Schreibvorgangs auf die Festplatte, obwohl sich noch Daten im Puffer befinden. Wenn dann das System ausfällt, bevor die Daten bei dieser Lazy-Übertragung tatsächlich auf die Festplatte geschrieben wurden, werden die Daten möglicherweise beschädigt. Wenn die SCSI-Controller durch Batterien vor Stromausfall geschützt sind, können Sie den Schreibcache ruhig aktivieren. Einzelheiten hierzu erfahren Sie bei Ihrem Hardwarehersteller. Die Partition des Betriebssystems spiegeln oder durch RAID5 absichern Auf diese Weise ist das dem System zugrunde liegende Betriebssystem redundant gespeichert. Nach Möglichkeit Hardware-RAID und Spiegelung verwenden Ein softwarebasiertes RAID-System muss nach einem Ausfall neu konfiguriert werden, damit Sie ein neues Laufwerk hinzufügen können, um die ursprüngliche Konfiguration wiederherzustellen. Daher sollten Sie nach Möglichkeit lieber ein Hardware-RAID5System einsetzen, damit Sie ein fehlerhaftes Festplattenlaufwerk sofort durch ein neues ersetzen können. Die Systempartitionen sollten entweder gespiegelt oder auf einem RAID5-System gespeichert werden, damit die Daten redundant vorhanden sind. Die Umlaufprotokollierung deaktivieren Durch die Umlaufprotokollierung sparen Sie zwar Platz auf der Festplatte, sie hat jedoch beträchtliche Nachteile, denn mit ihr können Sie weder schrittweise noch Differenzsicherungen durchführen und außerdem werden die Transaktionsprotokolle zyklisch immer wieder überschrieben und können nicht zur Wiederherstellung verwendet werden. Wenn Sie sicherstellen wollen, dass die Protokolldateien regelmäßig bereinigt werden, so dass sie nicht zu viel Festplattenspeicher beanspruchen, dann müssen Sie eine solide Strategie zur Datensicherung entwickeln, die die Umlaufprotokollierung überflüssig macht. Die Attribute des Informationsspeichers im frühen Stadium begrenzen Setzen Sie Begrenzungen für den Speicherplatz der Postfächer und ein maximales Alter für Nachrichten auf dem Server fest. Begrenzen Sie auch die Größe der MTA-Nachrichten und die Größe der Nachrichten, die von Benutzern verschickt werden können. Auf diese Weise wissen die Benutzer, was sie erwarten können, und der Server wird weniger belastet. Die MTAs entsprechend konfigurieren Stellen Sie die Frequenz der MTAs ein, damit die Warteschlangen prompt abgearbeitet werden und sich im Informationsspeicher keine langen Nachrichtenwarteschlangen ansammeln. Richten Sie einen redundanten MTA-Pfad ein, damit die Nachrichten weiterfließen können, selbst wenn einmal eine Verbindung ausfällt. Wenn die MTAs in der Lage sind, den Nachrichtenverkehr zu bewältigen, verringert sich die Zahl der Nachrichten im Informationsspeicher, und die Nachrichten werden schneller übermittelt. Den Informationsspeicher periodisch offline warten Wenn Sie auf einem Server sehr viele Postfächer löschen oder verschieben oder wenn Sie die Postfächer bereinigen und dabei sehr viele Nachrichten löschen, sollten Sie anschließend den Informationsspeicher offline defragmentieren. Obwohl es nicht unbedingt erforderlich ist, sollten Sie regelmäßig (etwa einmal pro Quartal) die Integrität der Exchange-Datenbanken prüfen, indem Sie den Befehl eseutil /g ausführen. Auf diese Weise können Sie die Datenbanken beurteilen und Maßnahmen zur Behebung von Fehlern einleiten, bevor sie sich zu echten Problemen entwickeln. Im Verlauf Ihrer normalen Wartungspläne dürfen Sie die Datenbanken nicht mithilfe der Befehle edbutil /d /r oder eseutil /p reparieren. Datenbanken in Exchange 5.5 planen, die größer als 16 GB sind In Exchange Server 5.5 ist die Beschränkung der Datenbankgröße auf 16 GB aufgehoben worden, so dass die Größe der Datenbanken nur noch von der Hardware abhängig ist. Auf diese Weise können Sie mehrere Server zu einem Server zusammenfassen, so dass die Kosten für Hardware und Administration gesenkt werden. Bei der Konsolidierung von Servern sollten Sie jedoch eine eventuell notwendige Wiederherstellung des Systems berücksichtigen. Je größer die Datenbank, desto länger dauern sowohl ihre Sicherung als auch ihre Wiederherstellung und desto mehr Zeit wird für die Offlinewartung benötigt. In Exchange Server 5.5 wurden mehrere Merkmale im Hinblick auf die Behandlung großer Datenbanken verbessert. Die APIs zur Datensicherung unterstützen jetzt Geschwindigkeiten von über 30 GB/h. Wenn also bei der Datensicherung Engpässe auftreten, liegt der Grund vermutlich in der Hardware. Auch die Dienstprogramme für die Datenbanken wurden erweitert. Je nach Hardware und Belastung des Computers kann das neue Programm ESEUTIL.EXE die Datenbankintegrität mit einer Geschwindigkeit von etwa 10 GB/h prüfen. Die Defragmentierungsgeschwindigkeit liegt bei etwa 4 bis 5 GB/h, und die Reparatur wird mit etwa 8 bis 10 GB/h durchgeführt. Wenn Sie die Obergrenze der Datenbanken des Informationsspeichers festlegen, müssen Sie die Wartung, Datensicherung und die Zeit, die zur Wiederherstellung erforderlich wäre, im Auge behalten. Je größer die Datenbanken, desto länger dauern diese Vorgänge. Legen Sie Grenzen für die Postfächer fest, kontrollieren Sie die Zahl der Postfächer pro Server, definieren Sie Grenzen für die Größe der Nachrichten und bereinigen Sie die Postfächer regelmäßig. Die in Exchange 5.5 gebotene Möglichkeit, gelöschte Elemente wiederherzustellen, ist ein nützliches Leistungsmerkmal. Bedenken Sie aber, dass der Speicherplatz auf der Festplatte, der von den gelöschten Objekten beansprucht wird, nicht in die Größe eines Postfachs einbezogen wird. Wenn Sie dieses Leistungsmerkmal also aktivieren, steigt die Größe des Informationsspeichers in Exchange 5.5 im Vergleich zu Exchange 4.0 und 5.0 wesentlich an. Überlegen Sie sich daher gut, nach wie vielen Tagen die gelöschten Objekte endgültig aus dem Informationsspeicher entfernt werden sollen, und nehmen Sie die entsprechenden Einstellungen vor. Die Server mit genügend Festplattenspeicher ausstatten Für die offline durchgeführten Wartungs- und Reparaturvorgänge mit den Dienstprogrammen EDBUTIL bzw. ESEUTIL wird oft maximal das Doppelte des Speicherplatzes benötigt, den die betreffende Datenbankdatei auf der Festplatte einnimmt. Ein Beispiel für die Verteilung der Informationen, die im gesamten System von Microsoft Exchange zur Verfügung stehen sollen, und der lokalen Speicherdaten Wenn Sie eine optimale Leistung und Wiederherstellbarkeit erreichen wollen, müssen Sie das Laufwerk, auf dem das Betriebssystem installiert ist, spiegeln (oder in einem RAID5System einrichten), die Transaktionsprotokolldateien müssen auf einem eigenen physischen Laufwerk gespeichert werden (das auch gespiegelt werden kann), und der Informationsspeicher sollte sich in einem RAID5-Stripe-Set befinden. In Windows NT ist es erforderlich, dass die Auslagerungsdatei auf der Systempartition groß genug für eine Abbildung des gesamten Arbeitsspeichers sein muss. Wenn Sie auf anderen Laufwerken weitere Auslagerungsdateien einrichten, werden sie zur Optimierung der Festplattenleistung verwendet. Strategien für die Datensicherung Die Strategien zur Datensicherung hängen sehr oft von den Anforderungen des Unternehmens ab. In diesem Abschnitt werden die Eigenschaften der verschiedenen Arten der Datensicherung untersucht, ihre Vorteile, Grenzen und die Kompromisse, die dabei eingegangen werden müssen. Die zur Sicherung erforderliche Zeit hängt von der Art der Sicherung ab. Bei einer täglichen vollständigen Sicherung ist sie am längsten, und wenn die Datenbank mehrere Gigabyte groß ist, ist diese Art der Sicherung nicht sehr praktisch. In manchen Fällen eignet sich eine Kombination aus periodisch durchgeführten vollständigen und dazwischen liegend schrittweisen oder Differenzsicherungen am besten. Beispiel A: Eine vollständige Sicherung pro Tag Zeitplan: SO:voll, MO:voll, DI:voll, MI:voll, DO:voll, FR:voll, SA:voll Vorteile Die Transaktionsprotokolle werden immer entfernt. Es ist nur eine Wiederherstellungsoperation vom Band erforderlich. Die Zeitplanung wird vereinfacht. Nachteile Sie beeinträchtigt die Serverleistung am längsten. Sie beansprucht am meisten Platz auf dem Band. Das Band muss meist täglich gewechselt werden. Die Umlaufprotokollierung ist möglich. Beispiel B: Abwechselnd vollständige und schrittweise Sicherung Zeitplan: So:voll, Mo:schritt, Di:voll, Mi:schritt, Do:voll, Fr:schritt, Sa:voll Vorteile Die Transaktionsprotokolldateien werden immer entfernt. Mehrere vollständige Sicherungen werden auf verschiedenen Bändern durchgeführt. Die schrittweise Sicherung wirkt sich viel weniger auf die Leistung aus. Die Bänder müssen seltener gewechselt werden. Bei der Wiederherstellung werden maximal zwei Bänder gebraucht. Nachteile Zur Wiederherstellung sind zwei Bänder notwendig. Der Sicherungszyklus muss bekannt sein. Die Umlaufprotokollierung muss deaktiviert werden. Beispiel C: Je eine vollständige und zwei schrittweise Sicherungen Zeitplan: So:voll, Mo:schritt, Di:schritt, Mi:voll, Do:schritt, Fr:schritt, Sa:voll Vorteile Die Transaktionsprotokolldateien werden immer entfernt. Vollständige Sicherungen werden relativ selten durchgeführt. Die Auswirkungen auf die Serverleistung werden minimiert. Die schrittweise Sicherung erfordert sehr wenig Speicherplatz auf dem Band. Nachteile In diesem Fall sind bis zu drei Bänder notwendig - eines für jede vollständige und jede schrittweise Sicherung. Der Sicherungszyklus muss bekannt sein. Die Umlaufprotokollierung muss deaktiviert werden. Beispiel D: Je eine vollständige und zwei Differenzsicherungen Zeitplan: So:voll, Mo:diff, Di:diff, Mi:voll, Do:diff, Fr:diff, Sa:voll Vorteile Vollständige Sicherungen werden relativ selten durchgeführt. Bei der Wiederherstellung werden maximal zwei Bänder gebraucht. Die Auswirkungen auf die Serverleistung werden minimiert. Die Differenzsicherung erfordert sehr wenig Speicherplatz auf dem Band. Nachteile Bei der Differenzsicherung werden die Protokolldateien nicht von der Festplatte entfernt. Die Umlaufprotokollierung muss deaktiviert sein. Ihre Sicherungsstrategie muss den Anforderungen Ihres Unternehmens entsprechen. Eine Faustregel lautet jedoch, dass bei kleinen Datenmengen jeden Tag vollständig gesichert werden sollte, während bei großen Datenmengen eine Kombination aus vollständigen, schrittweisen und Differenzsicherungen eingesetzt werden sollte. Durch die Kombination der Methoden wird die Beeinträchtigung der Systemleistung möglichst gering gehalten, und es wird auch weniger Speicherplatz auf den Bändern beansprucht. Das Problem des betriebsbereiten Reserveservers Ist es möglich, einen sofort betriebsbereiten Reserveserver zu unterhalten, der ständig zur Wiederherstellung des Exchange-Systems bereitgehalten wird? Die Antwort auf diese Frage hängt davon ab, wie Sie den Begriff "betriebsbereiter Reserveserver" verstehen. Da der Wiederherstellungsserver denselben Computernamen haben muss wie der Exchange-Server (damit der Informationsspeicher und der Verzeichnisdienst vollständig wiederhergestellt werden können), kann der Reserveserver nicht im Netzwerk betrieben werden (dort sind keine mehrfach vorkommenden NetBIOS-Namen erlaubt). Auch in Windows NT Server-Domänen können keine zwei Computer mit identischem Namen vorhanden sein. Wenn Sie dagegen dem Wiederherstellungsserver einen anderen Namen geben, können Sie mit ihm das Exchange-Verzeichnis nicht wiederherstellen. Sie können dann jedoch trotzdem einzelne Postfächer wiederherstellen, obwohl sie die Windows NTSicherheit für alle Objekte neu konfigurieren müssen. Da diese Operation manuell durchgeführt werden muss, kann sie sehr komplex sein. Speichern Sie zumindest den erforderlichen Programmcode, der auch auf den im Einsatz befindlichen Computern verwendet wird, auf den Wiederherstellungscomputern. Bei der Wiederherstellung einzelner Postfächer wird das Exchange-Verzeichnis nicht wiederhergestellt, so dass der Wiederherstellungsserver nur denselben Standort- und Organisationsnamen wie der Exchange-Server (aber nicht denselben Computernamen) haben muss. Daher können Sie den Windows NT-basierten Wiederherstellungsserver in diesem Fall im Netzwerk betreiben. Wenn der Wiederherstellungsserver nur für einen Standort verwendet wird, kann auch Exchange ausgeführt werden, aber es darf nicht mit dem im Einsatz befindlichen System in Verbindung stehen. Für eine vollständige Wiederherstellung des Systems muss der Wiederherstellungsserver mit demselben Standort-, Organisations- und Computernamen konfiguriert sein. Der Wiederherstellungsserver kann unter einem anderen Computernamen durchaus unwichtige Aufgaben durchführen (beispielsweise als zusätzlicher RAS-Server oder als Microsoft Mail Multitasking-MTA, MMTA, dienen). Wenn Sie ihn dann zur Systemwiederherstellung verwenden müssen, können Sie ihn umbenennen oder Windows NT neu installieren. Speichern Sie den Installationscode auf dem Wiederherstellungsserver (\ntinstall\i386, \patches\sp4, \exchinst\i386), und sorgen Sie dafür, dass die Kapazität des Servers der Kapazität des im Einsatz befindlichen Servers entspricht. Exchange Server 5.5 unterstützt Microsoft Cluster Server und kann somit von der hohen Verfügbarkeit profitieren, die mit Clusters erreicht wird. Beispiel für die automatisierte Online-Datensicherung Wenn Sie eine Onlinesicherung des Informationsspeichers und des Verzeichnisdienstes vornehmen wollen, führen Sie folgende Schritte durch: 1. Installieren Sie das Programm WINAT.EXE von der Begleit-CD zu Microsoft Windows NT. Die technische Referenz im Verzeichnis von Windows NT auf dem lokalen Computer. 2. Erstellen Sie eine allgemeine Programmgruppe mit der Bezeichnung Microsoft Exchange-Sicherung. 3. Erstellen Sie ein Symbol für die Datei BACKUP.LOG. Auf diese Weise können Sie die Sicherungsprotokolldatei schnell öffnen und prüfen. 4. Kopieren Sie das Symbol NTBACKUP.EXE aus der Programmgruppe Verwaltung (Allgemein) in die Programmgruppe Microsoft Exchange-Sicherung. 5. Erstellen Sie in der Programmgruppe Microsoft Exchange-Sicherung ein Symbol für WINAT.EXE. 6. Klicken Sie in der Systemsteuerung auf Dienste, markieren Sie den Dienst Schedule, und klicken Sie auf die Schaltfläche Startart. Konfigurieren Sie den Dienst so, dass er automatisch gestartet wird, und weisen Sie ihm eine ID zu, die zur Gruppe der Windows NT Sicherungs-Operatoren gehört. Geben Sie unbedingt das richtige Kennwort ein. Wenn das Kennwort des Administrators geändert wird, müssen Sie das Kennwort des Dienstes Schedule entsprechend ändern. Dieses Konto muss die Administratorberechtigungen für die Organisations-, Standortund Konfigurationscontainer haben, die gesichert werden sollen. Wenn Sie fertig sind, starten Sie den Dienst Schedule. 7. Erstellen Sie die Sicherungsstapeldatei, geben Sie ihr den Namen BACK.BAT, und speichern Sie sie im Verzeichnis \winnt. Weiter hinten in diesem Kapitel finden Sie eine Beispieldatei. 8. Führen Sie das Programm WINAT.EXE aus und erstellen Sie einen Zeitplan für die Datei BACK.BAT. Sie müssen dazu nicht für eine Sitzung auf dem Computer angemeldet sein, auf dem WINAT.EXE ausgeführt wird, weil der Dienst Schedule sich anmeldet und die Operation unter dem definierten Sicherheitskontext durchführt. Stellen Sie für den Stapelauftrag unbedingt den interaktiven Modus ein. Beispiel für eine Stapeldatei zur Online-Datensicherung rem ** 15.08.98 Sicherung erstellt von <Ihr Name> rem ** Mit dieser Datei wird der IS und DS auf <SERVERNAME1> und rem ** <SERVERNAME2> gesichert. ntbackup backup DS \\SERVERNAME1 IS \\SERVERNAME1 /v /d "SERVERNAME1 ISDS" /b /t Normal /l c:\winnt\backup.log /e ntbackup backup DS \\SERVERNAME2 IS \\SERVERNAME2 /a /v /d "SERVERNAME2 IS-DS" /b /t Normal /l c:\winnt\backup.log /e exit Beispiel 1: Stapeldatei zur Offline-Datensicherung Möglicherweise müssen Sie zuerst testen, in welcher Reihenfolge die Dienste beendet werden müssen. Zwischen den Diensten bestehen Abhängigkeitsbeziehungen, so dass Sie einen Dienst nur beenden können, wenn Sie auch die von ihm abhängigen Dienste beenden. rem ** Microsoft Exchange-Dienste beenden rem ** Sie können die Dienste von Microsoft Exchange beenden und automatisch neu starten, um rem ** Dateien zu sichern, die ein bestimmter Dienst geöffnet hält REM // alle Dienste beenden echo Stopping Services... net stop MSExchangeMSMI net stop MSExchangePCMTA net stop MSExchangeFB net stop MSExchangeDX net stop MSExchangeIMC net stop MSExchangeMTA net stop MSExchangeIS net stop MSExchangeDS net stop MSExchangeSA ntbackup backup c:\ d:\ /a /v /d "Full File Based Backup" /b /l c:\winnt\backup.log /e REM edbutil OPTIONS net net net net net start start start start start MSExchangeSA MSExchangeDS MSExchangeIS MSExchangeMTA MSExchangeIMC net net net net start start start start MSExchangeDX MSExchangeFB MSExchangePCMTA MSExchangeMSMI Beispiel 2: Stapeldatei zur Offline-Datensicherung Die PCMTA-Dienste können Sie starten und beenden, indem Sie ihre Namen in Anführungszeichen setzen. Die Namen der Dienste können Sie im Programm Exchange Administrator, in der Windows NT-Systemsteuerung oder in der Windows NTRegistrierung (HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services) ermitteln. Die Dienste sind in alphabetischer Reihenfolge aufgelistet. rem Stapeldatei zum Beenden und Neustarten der Microsoft Exchange-Dienste rem zur dateibasierten Sicherung echo Stopping Services... net stop MSExchangeMSMI net stop MSExchangePCMTA net stop MSExchangeFB net stop MSExchangeDX net stop MSExchangeMTA net stop MSExchangeIMC net stop MSExchangeIS net stop MSExchangeDS net stop "PC MTA - HUB" net stop MSExchangeSA ntbackup BACKUP d:\exchsrvr\mdbdata /v /d "File Based Backup" /b /l c:\winnt\backup.log /e net net net net net net net net net start start start start start start start start start MSExchangeSA MSExchangeDS MSExchangeIS MSExchangeMTA MSExchangeIMC MSExchangeDX MSExchangeFB MSExchangePCMTA MSExchangeMSMI net start "PC MTA - HUB" Der WINAT-Scheduler und der Windows NTDienst Schedule Der WINAT-Scheduler Das Programm NTBACKUP.EXE erfordert, dass für die Aufträge in BACK.BAT der interaktive Modus eingestellt ist. Die mit dem WINAT-Scheduler vorausgeplanten Aufträge werden vom Dienst Schedule in Windows NT ausgeführt. Da die Stapelaufträge im Kontext des Dienstes Schedule ausgeführt werden, müssen Sie die Sicherheitsmechanismen in Windows NT berücksichtigen. Wenn Sie den Dienst Schedule konfigurieren, müssen Sie das Konto in die Gruppe der Windows NT Sicherungs-Operatoren einfügen. Auf diese Weise kann eine vollständige Sicherungskopie des Informationsspeichers und des Verzeichnisdienstes angelegt werden. Dialogfeld für die Konfiguration des Windows NT-Dienstes Schedule Die Veröffentlichung des oben stehenden Materials erfolgt mit freundlicher Genehmigung von Microsoft Press<http://mspress.microsoft.com/>. Copyright 1999, Microsoft Corporation. Das Team der Microsoft Corporation hofft, dass die Informationen in diesem Dokument für Sie von Nutzen sind. Die Verwendung der in diesem Dokument enthaltenen Informationen erfolgt jedoch auf eigene Gefahr. Alle Informationen werden wie besehen bereitgestellt, ohne jede Gewährleistung, sei sie ausdrücklich oder konkludent, für die Richtigkeit, die Vollständigkeit, die Eignung für einen bestimmten Zweck, den Eigentumsvorbehalt oder die Nichtverletzung von Rechten Dritter, und keine der in diesem Dokument genannten Fremdherstellerprodukte oder Informationen von Dritten wurden/werden von der Microsoft Corporation verfasst, empfohlen oder unterstützt, und Microsoft Corporation übernimmt keine Garantie dafür. Die Microsoft Corporation kann nicht für Schäden haftbar gemacht werden, die aus der Verwendung dieser Informationen entstehen, ungeachtet dessen, ob es sich um direkte oder indirekte, spezielle, zufällig entstandene oder Folgeschäden handelt, selbst dann nicht, wenn Microsoft Corporation auf die mögliche Entstehung solcher Schäden hingewiesen wurde. Alle in diesem Dokument genannten Preise für Produkte können ohne ohne vorherige Ankündigung geändert werden.
