Verwalten von Postfachdatenbankkopien

Gilt für: Exchange Server 2013

Nachdem Sie eine Datenbankverfügbarkeitsgruppe (DAG) mit Postfachservermitgliedern erstellt, konfiguriert und aufgefüllt haben, können Sie Postfachdatenbankkopien auf flexible und präzise Weise hinzufügen.

Verwalten von Datenbankkopien

Nachdem Sie mehrere Kopien einer Datenbank erstellt haben, können Sie das EAC oder die Shell verwenden, um die Integrität und status jeder Kopie zu überwachen. Sie können auch andere Verwaltungsaufgaben im Zusammenhang mit Datenbankkopien ausführen. Zum Beispiel:

• Anhalten oder Fortsetzen einer Datenbankkopie.
• Seeding für eine Datenbankkopie.
• Überwachen von Datenbankkopien.
• Konfigurieren Von Datenbankkopiereinstellungen
• Entfernen sie eine Datenbankkopie.

Anhalten und Fortsetzen von Datenbankkopien

Geplante Wartungs-, Seeding- und andere Wartungstasks erfordern möglicherweise, dass Sie die fortlaufende Replikation für eine Datenbankkopie anhalten und fortsetzen müssen.

Es wird empfohlen, alle Replikationsaktivitäten anzuhalten, wenn der Pfad der Datenbank oder ihrer Protokolldateien geändert wird. Sie können die Datenbankkopieraktivität anhalten und fortsetzen, indem Sie das EAC verwenden oder die Cmdlets Suspend-MailboxDatabaseCopy und Resume-MailboxDatabaseCopy in der Shell ausführen. Ausführliche Schritte zum Anhalten oder Fortsetzen der kontinuierlichen Replikation für eine Datenbankkopie finden Sie unter Anhalten oder Fortsetzen einer Postfachdatenbankkopie.

Seeding von Datenbankkopien

Beim Seeding (auch als Aktualisieren bezeichnet) wird eine leere Datenbank oder eine Kopie der Produktionsdatenbank auf einem anderen Postfachserver in derselben DAG wie die aktive Datenbank hinzugefügt. Diese Datenbank wird zur Basisdatenbank für die von diesem Server verwaltete Kopie.

Abhängig von der Situation kann das Seeding ein automatischer Prozess oder ein manueller Prozess sein, den Sie initiieren. Wenn eine Datenbankkopie hinzugefügt wird, wird für die Kopie automatisch ein Seeding ausgeführt, sofern der Zielserver und sein Speicher ordnungsgemäß konfiguriert sind.

Verwenden Sie den Parameter SeedingPostponed im Cmdlet Add-MailboxDatabaseCopy , um eine Datenbankkopie manuell ohne automatisches Seeding zu seeden, wenn Sie die Kopie erstellen.

Datenbankkopien müssen selten nach dem anfänglichen Seeding erneut eingereet werden. Wenn Sie jedoch ein manuelles Seeding für eine Datenbankkopie benötigen oder möchten, können Sie eine der folgenden Methoden verwenden:

• Der Assistent zum Aktualisieren des Kopierens von Postfachdatenbanken im EAC.
• Das Cmdlet Update-MailboxDatabaseCopy in der Shell.

Vor dem Seeding einer Datenbankkopie müssen Sie zunächst die Postfachdatenbankkopie anhalten. Ausführliche Anweisungen zum Seeding einer Datenbankkopie finden Sie unter Aktualisieren einer Postfachdatenbankkopie.

Nach Abschluss eines manuellen Seedvorgangs wird die Replikation für die Datenbankkopie des Seedings des Postfachs automatisch fortgesetzt. Wenn die Replikation nicht automatisch fortgesetzt werden soll, können Sie den Parameter ManualResume im Cmdlet Update-MailboxDatabaseCopy verwenden.

Auswählen der Seedingziele

Wenn Sie einen Seedvorgang ausführen, haben Sie die folgenden Optionen:

• Seeding der Postfachdatenbankkopie: Dieses Verhalten ist das Standardverhalten für den Assistenten zum Aktualisieren des Kopierens von Postfachdatenbanken und das Cmdlet Update-MailboxDatabaseCopy .
• Seeding des Inhaltsindexkatalogs für die Postfachdatenbankkopie: Verwenden Sie den DatabaseOnly-Parameter im Cmdlet Update-MailboxDatabaseCopy .
• Seeding sowohl der Datenbankkopie als auch der Inhaltsindexkatalogkopie: Verwenden Sie den CatalogOnly-Parameter im Cmdlet Update-MailboxDatabaseCopy .

Auswählen der Seedingquelle

Jede fehlerfreie Datenbankkopie kann als Seedingquelle für eine zusätzliche Kopie dieser Datenbank verwendet werden. Diese Option ist nützlich, wenn Sie eine DAG über mehrere physische Standorte erweitern.

Betrachten Sie beispielsweise eine DAG-Bereitstellung mit vier Mitgliedern:

• Zwei Mitglieder (MBX1 und MBX2) befinden sich in Portland, Oregon. Eine Postfachdatenbank mit dem Namen DB1 ist auf MBX1 aktiv.
• Zwei Mitglieder (MBX3 und MBX4) befinden sich in New York, New York. Es gibt passive Kopien von DB1 auf MBX2 und MBX3.

Beim Hinzufügen einer Kopie von DB1 zu MBX4 haben Sie die Möglichkeit, die Kopie auf MBX3 als Quelle für das Seeding zu verwenden. Diese Option vermeidet seeding über die WAN-Verbindung (Wide Area Network) zwischen Portland und New York.

Führen Sie die folgenden Schritte aus, um beim Hinzufügen einer neuen Datenbankkopie eine bestimmte Kopie als Quelle für das Seeding zu verwenden:

• Verwenden Sie zum Hinzufügen der Datenbankkopie den Parameter SeedingPostponed im Cmdlet Add-MailboxDatabaseCopy . Wenn der SeedingPostponed-Parameter nicht verwendet wird, wird die Datenbankkopie explizit mit der aktiven Kopie der Datenbank als Quelle seeded.

• Sie können den Quellserver, den Sie für das Seeding verwenden möchten, an den folgenden Speicherorten angeben:

  • Im Assistenten zum Aktualisieren des Kopierens von Postfachdatenbanken im EAC.
  • Der SourceServer-Parameter im Cmdlet Update-MailboxDatabaseCopy .

Im vorherigen Beispiel würden Sie „MBX3" als Quellserver angeben. Wenn der SourceServer-Parameter nicht verwendet wird, wird die Datenbankkopie explizit aus der aktiven Kopie der Datenbank aus seeded.

Seeding und Netzwerke

Zusätzlich zum Auswählen eines bestimmten Quellservers für das Seeding einer Postfachdatenbankkopie können Sie die Shell auch für Folgendes verwenden:

• Geben Sie an, welche DAG-Netzwerke verwendet werden sollen.
• Überschreiben Sie optional die Komprimierungs- und Verschlüsselungseinstellungen des DAG-Netzwerks während des Seedvorgangs.

Um die Netzwerke anzugeben, die Sie für das Seeding verwenden möchten, verwenden Sie den Network-Parameter im Cmdlet Update-MailboxDatabaseCopy , und geben Sie die DAG-Netzwerke an, die Sie verwenden möchten. Wenn Sie den Network-Parameter nicht verwenden, verwendet das System das folgende Standardverhalten für die Auswahl eines Netzwerks, das für den Seedingvorgang verwendet werden soll:

• Wenn sich Quellserver und Zielserver im selben Subnetz befinden und ein Replikationsnetzwerk konfiguriert ist, das das Subnetz enthält, wird das Replikationsnetzwerk verwendet.

• Wenn sich der Quellserver und der Zielserver in unterschiedlichen Subnetzen befinden, wird das Clientnetzwerk (MAPI) für das Seeding verwendet, selbst wenn ein Replikationsnetzwerk konfiguriert ist, das diese Subnetze enthält.

• Wenn sich der Quellserver und der Zielserver in unterschiedlichen Rechenzentren befinden, wird das Clientnetzwerk (MAPI) für das Seeding verwendet.

Auf der Ebene der DAG sind DAG-Netzwerke für die Verschlüsselung und Komprimierung konfiguriert. Die Standardeinstellungen sind, Verschlüsselung und Komprimierung nur für die Kommunikation in verschiedenen Subnetzen zu verwenden.

Wenn sich quelle und ziel in unterschiedlichen Subnetzen befinden und die DAG mit den Standardwerten für NetworkCompression und NetworkEncryption konfiguriert ist, können Sie diese Werte überschreiben, indem Sie die Parameter NetworkCompressionOverride und NetworkEncryptionOverride im Cmdlet Update-MailboxDatabaseCopy verwenden.

Seedingprozess

Wenn Sie einen Seedingprozess mithilfe der Cmdlets Add-MailboxDatabaseCopy oder Update-MailboxDatabaseCopy initiieren, werden die folgenden Aufgaben ausgeführt:

1. Datenbankeigenschaften in Active Directory und Datenbankpfade werden gelesen, um die angegebene Datenbank und die angegebenen Server zu überprüfen:

   • Auf den Quell- und Zielservern wird Exchange 2013 ausgeführt.
   • Die Quell- und Zielserver sind beide Mitglieder derselben DAG.
   • Die angegebene Datenbank ist keine Wiederherstellungsdatenbank.

2. Vom Microsoft Exchange-Replikationsdienst auf dem Zielserver werden Vorbereitungen für Prüfungen zum erneuten Seeding getroffen.

3. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver überprüft das Vorhandensein von Datenbank- und Transaktionsprotokolldateien aus den Überprüfungen in Schritt 1.

4. Der Microsoft Exchange-Replikationsdienst gibt die Statusinformationen vom Zielserver an die Verwaltungsschnittstelle zurück, von der aus das Cmdlet ausgeführt wurde.

5. Wenn alle vorläufigen Überprüfungen erfolgreich sind, werden Sie aufgefordert, den Vorgang zu bestätigen, bevor Sie fortfahren. Wenn Sie den Vorgang bestätigen, wird der Prozess fortgesetzt. Wenn während der einleitenden Prüfungen ein Fehler auftritt, wird der Fehler gemeldet, und der Vorgang schlägt fehl.

6. Der Seedingvorgang wird vom Microsoft Exchange-Replikationsdienst auf dem Zielserver gestartet.

7. Der Microsoft Exchange-Replikationsdienst hält die Datenbankreplikation für die aktive Datenbankkopie an.

8. Der Microsoft Exchange-Replikationsdienst aktualisiert die Statusinformationen, um eine status des Seedings widerzuspiegeln.

9. Wenn der Zielserver noch nicht über die Verzeichnisse für die Zieldatenbank und die Protokolldateien verfügt, werden sie erstellt.

10. Eine TCP-Anforderung zum Seeding der Datenbank wird vom Zielserver an den Quellserver im Microsoft Exchange-Replikationsdienst übergeben. Diese Anforderung und die nachfolgende Kommunikation zum Seeding der Datenbank erfolgen in einem DAG-Netzwerk, das als Replikationsnetzwerk konfiguriert ist.

11. Der Microsoft Exchange-Replikationsdienst auf dem Quellserver startet eine ESE-Streamingsicherung (Extensible Storage Engine) über die Schnittstelle des Microsoft Exchange-Informationsspeicherdiensts.

12. Der Microsoft Exchange-Informationsspeicherdienst sendet die Datenbankdaten als Stream an den Microsoft Exchange-Replikationsdienst.

13. Die Datenbankdaten werden vom Microsoft Exchange-Replikationsdienst des Quellservers zum Microsoft Exchange-Replikationsdienst das Zielservers verschoben.

14. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver schreibt die Datenbankkopie in ein temporäres Verzeichnis, das sich im Hauptdatenbankverzeichnis befindet, das als temporäres Seeding bezeichnet wird.

15. Die Streamingsicherung auf dem Quellserver endet, wenn das Ende der Datenbank erreicht wurde.

16. Der Schreibvorgang auf dem Zielserver wird abgeschlossen, und die Datenbank wird aus dem Verzeichnis "temp-seeding" an den endgültigen Speicherort verschoben. Das Verzeichnis "temp-seeding" wird gelöscht.

17. Auf dem Zielserver leitet der Microsoft Exchange-Replikationsdienst eine Anforderung mittels Proxyweiterleitung an den Microsoft Exchange-Suchdienst weiter, um den Inhaltsindexkatalog für die Datenbankkopie einzubinden, sofern dieser vorhanden ist. Wenn veraltete Katalogdateien einer früheren Instanz der Datenbankkopie vorhanden sind, schlägt der Einbindungsvorgang fehl, sodass der Katalog vom Quellserver repliziert werden muss. Wenn der Katalog nicht in einer neuen Instanz der Datenbankkopie auf dem Zielserver vorhanden ist, ist entsprechend eine Kopie des Katalogs erforderlich. Der Microsoft Exchange-Replikationsdienst weist den Microsoft Exchange-Suchdienst an, die Indizierung für die Datenbankkopie anzuhalten, während ein neuer Katalog von der Quelle kopiert wird.

18. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver sendet eine Anforderung zum Seeding des Katalogs an den Microsoft Exchange-Replikationsdienst auf dem Quellserver.

19. Auf dem Quellserver fordert der Microsoft Exchange-Replikationsdienst die Verzeichnisinformationen vom Microsoft Exchange-Suchdienst an und fordert die Aussetzung der Indizierung an.

20. Der Microsoft Exchange-Suchdienst auf dem Quellserver gibt die Verzeichnisinformationen des Suchkatalogs an den Microsoft Exchange-Replikationsdienst zurück.

21. Der Microsoft Exchange-Replikationsdienst auf dem Quellserver liest die Katalogdateien aus dem Verzeichnis.

22. Der Microsoft Exchange-Replikationsdienst auf dem Quellserver verschiebt die Katalogdaten mithilfe einer Verbindung über das Replikationsnetzwerk zum Microsoft Exchange-Replikationsdienst auf dem Zielserver. Nachdem der Lesevorgang abgeschlossen ist, sendet der Microsoft Exchange-Replikationsdienst eine Anforderung an den Microsoft Exchange-Suchdienst, um die Indizierung der Quelldatenbank fortzusetzen.

23. Wenn sich im Verzeichnis auf dem Zielserver vorhandene Katalogdateien befinden, werden diesem vom Microsoft Exchange-Replikationsdienst auf dem Zielserver gelöscht.

24. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver schreibt die Katalogdaten in ein temporäres Verzeichnis namens CiSeed.Temp , bis die Daten vollständig übertragen wurden.

25. Der Microsoft Exchange-Replikationsdienst verschiebt die vollständigen Katalogdaten an ihren endgültigen Speicherort.

26. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver fährt mit der Suchindizierung für die Zieldatenbank fort.

27. Der Microsoft Exchange-Replikationsdienst auf dem Zielserver gibt einen Fertigstellungsstatus zurück.

28. Das letzte Ergebnis des Vorgangs wird an die Verwaltungsschnittstelle übergeben, von der aus das Cmdlet aufgerufen wurde.

Konfigurieren von Datenbankkopien

Nachdem eine Datenbankkopie erstellt wurde, können Sie ihre Konfigurationseinstellungen bei Bedarf anzeigen und ändern.

• Sie können einige Konfigurationsinformationen für eine Datenbankkopie im EAC auf der Seite Eigenschaften anzeigen.
• Sie können die Cmdlets Get-MailboxDatabase und Set-MailboxDatabaseCopy in der Shell verwenden, um Datenbankkopiereinstellungen anzuzeigen und zu konfigurieren. Zum Beispiel:
  • Wiedergabeverzögerungszeit.
  • Kürzungsverzögerungszeit.
  • Reihenfolge der Aktivierungspräferenz.

Ausführliche Schritte zum Anzeigen und Konfigurieren von Datenbankkopiereinstellungen finden Sie unter Konfigurieren von Kopiereigenschaften für Postfachdatenbanken.

Verwenden von Optionen für die Wiedergabe- und Abschneideverzögerung

Postfachdatenbankkopien unterstützen die Verwendung von Wiedergabeverzögerungen und Abschneideverzögerungen, die jeweils innerhalb von Minuten konfiguriert werden können. Durch das Festlegen einer Wiedergabeverzögerung können Sie bei einer Datenbankkopie zu einem bestimmten Zeitpunkt zurückkehren. Durch das Festlegen einer Abschneideverzögerung können Sie anhand der Protokolle für eine passive Datenbankkopie die verlorenen Protokolldateien für die aktive Datenbankkopie wiederherstellen. Da beide Features zur temporären Erstellung von Protokolldateien führen, wirkt sich die Verwendung einer dieser Features auf Ihren Speicherentwurf aus.

Wiedergabeverzögerung

Die Wiedergabeverzögerungszeit ist eine Eigenschaft einer Postfachdatenbankkopie, die die Zeitspanne in Minuten angibt, um die Protokollwiedergabe für die Datenbankkopie zu verzögern. Der Wiedergabeverzögerungstimer startet, wenn eine Protokolldatei in die passive Kopie repliziert wird und die Überprüfung erfolgreich besteht. Durch die Verzögerung der Wiedergabe von Protokollen für die Datenbankkopie haben Sie die Möglichkeit, die Datenbank zu einem bestimmten Zeitpunkt in der Vergangenheit wiederherzustellen. Eine Postfachdatenbankkopie, die mit einer Wiedergabeverzögerung größer als 0 (null) konfiguriert ist, wird als verzögerte Kopie der Postfachdatenbank oder einfach als verzögerte Kopie bezeichnet.

Eine Strategie, die Datenbankkopien und die Beweissicherungsfeatures in Exchange 2013 verwendet, kann Schutz vor einer Reihe von Fehlern bieten, die normalerweise zu Datenverlusten führen würden. Diese Features bieten jedoch keinen Schutz vor Datenverlusten aufgrund der Häufigkeit logischer Beschädigungen. Verzögerte Kopien sind so konzipiert, dass Datenverluste aufgrund logischer Beschädigungen verhindert werden. Im Allgemeinen gibt es zwei Arten von logischen Beschädigungen:

• Logische Beschädigung der Datenbank: ESE versucht, eine Datenbankseite zu schreiben, und die Daten werden nie auf den Datenträger geschrieben oder an die falsche Stelle geschrieben. Diese Situation wird als verlorene Leerung bezeichnet. Damit bei verlorenen Leerungen keine Daten verloren gehen, bezieht ESE einen Mechanismus zur Erkennung verlorener Leerungen zusammen mit einer Funktion zum Patchen von Seiten (Einzelseitenwiederherstellung) in die Datenbank ein.

• Logische Speicherbeschädigung: Daten werden auf eine Weise hinzugefügt, gelöscht oder bearbeitet, die der Benutzer nicht erwartet. Diese Fälle werden in der Regel durch Nicht-Microsoft-Anwendungen verursacht. Es ist eine Beschädigung in dem Sinne, dass der Benutzer dies als Beschädigung betrachtet. Der Exchange-Speicher betrachtet die Transaktion, die zur logischen Beschädigung geführt hat, als eine Folge gültiger MAPI-Operationen. Die Beweissicherungsfunktion in Exchange 2013 bietet Schutz vor logischer Speicherbeschädigung (da ein Benutzer oder eine Anwendung daran gehindert wird, Inhalte dauerhaft zu löschen). Es kann jedoch Szenarien geben, in denen ein Benutzerpostfach so beschädigt ist, dass es einfacher ist, die Datenbank wiederherzustellen und dann das Benutzerpostfach zu exportieren, um nicht beschädigte Daten abzurufen.

Durch die Kombination aus Datenbankkopien, Aufbewahrungsrichtlinien und ESE-Wiederherstellungen einzelner Seiten verbleibt nur die seltene, jedoch katastrophale logische Beschädigung des Speichers. Ihre Entscheidung, ob eine Datenbankkopie mit einer Wiedergabeverzögerung (einer verzögerten Kopie) verwendet werden soll, hängt davon ab, welche Nicht-Microsoft-Anwendungen Sie verwenden, und vom Verlauf Ihrer organization mit logischer Speicherbeschädigung.

Verzögerte Kopien können in Exchange 2013 für sich selbst sorgen, wenn Sie die automatische Protokollwiedergabe aufrufen, um die Protokolldateien in bestimmten Szenarien wiederzugeben:

• Ein niedriger Speicherplatzschwellenwert wird erreicht.
• Die verzögerte Kopie weist eine physische Beschädigung auf und muss auf eine Seite gepatcht werden.
• Es sind weniger als drei fehlerfreie Kopien verfügbar (nur aktiv oder passiv; verzögerte Datenbankkopien werden nicht gezählt) für mehr als 24 Stunden.

Das Patchen von Seiten ist für verzögerte Kopien über diese automatische Wiedergabefunktion verfügbar. Wenn das System erkennt, dass seitenpatching für eine verzögerte Kopie erforderlich ist, werden die Protokolle automatisch in die verzögerte Kopie wiedergegeben, um seitenpatchen zu können. Verzögerte Kopien rufen auch dieses Feature für die automatische Wiedergabe in den folgenden Szenarien auf:

• Ein niedriger Speicherplatzschwellenwert wird erreicht.
• Die verzögerte Kopie wird als einzige verfügbare Kopie für einen bestimmten Zeitraum erkannt.

Die Wiedergabe für verzögerte Kopien ist standardmäßig deaktiviert und kann durch Ausführung des folgenden Befehls aktiviert werden:

Set-DatabaseAvailabilityGroup <DAGName> -ReplayLagManagerEnabled $true

Nach der Aktivierung wird eine Wiedergabe durchgeführt, wenn weniger als drei Kopien zur Verfügung stehen. Sie können den Standardwert 3 ändern, indem Sie den folgenden DWORD-Registrierungswert bearbeiten.

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagManagerNumAvailableCopies

Sie müssen den folgenden Registrierungswert konfigurieren, um die Wiedergabe bei Erreichen von Schwellenwerten in Bezug auf zu wenig Speicherplatz zu aktivieren:

HKLM\Software\Microsoft\ExchangeServer\v15\Replay\Parameters\ReplayLagLowSpacePlaydownThresholdInMB

Starten Sie nach der Konfiguration einer dieser Registrierungseinstellungen den Microsoft Exchange DAG-Verwaltungsdienst neu, damit die Änderungen übernommen werden.

Betrachten Sie beispielsweise eine Umgebung, in der eine Datenbank über vier Kopien verfügt:

• Drei hochverfügbare Kopien.
• Eine verzögerte Kopie.
• Die Standardeinstellung wird für ReplayLagManagerNumAvailableCopies verwendet.

Wenn eine nicht verzögerte Kopie aus irgendeinem Grund außer Betrieb ist (z. B. wenn die Kopie angehalten wird), spielt die verzögerte Kopie ihre Protokolldateien in 24 Stunden automatisch ab.

Wenn Sie verzögerte Kopien verwenden möchten, ohne den ReplayLagManagerEnabled Parameter zu aktivieren, beachten Sie die folgenden Auswirkungen:

• Die Wiedergabeverzögerungszeit ist ein vom Administrator konfigurierter Wert. Standardmäßig ist die Wiedergabeverzögerung deaktiviert.

• Die Einstellung für die Wiedergabeverzögerung besitzt eine Standardeinstellung von 0 Tagen sowie eine maximale Einstellung von 14 Tagen.

• Verzögerte Kopien werden nicht als hochverfügbare Kopien betrachtet. Stattdessen sind sie für Notfallwiederherstellungszwecke konzipiert, um vor logischer Speicherbeschädigung zu schützen.

• Je größer die festgelegte Wiedergabeverzögerung, desto länger ist der Datenbankwiederherstellungsprozess. Es kann mehrere Stunden dauern, bis eine Datenbank basierend auf den folgenden Faktoren wiederhergestellt wird:

  • Die Anzahl der Protokolldateien, die wiedergegeben werden müssen.
  • Die Geschwindigkeit, mit der die Hardware die Protokolldateien wiedergeben kann.

• Es wird empfohlen, dass Sie bestimmen, ob verzögerte Kopien für Ihre allgemeine Strategie für die Notfallwiederherstellung von entscheidender Bedeutung sind. Wenn ihre Verwendung für Ihre Strategie von entscheidender Bedeutung ist, empfehlen wir die folgenden Konfigurationen:

  • Verwenden mehrerer verzögerter Kopien.
  • Verwenden eines redundanten Arrays unabhängiger Datenträger (RAID) zum Schutz einer einzelnen verzögerten Kopie.

  Wenn Sie einen Datenträger verlieren oder eine Beschädigung auftritt, verlieren Sie ihren verzögerten Zeitpunkt nicht.

• Verzögerte Kopien können nicht mit dem Single-Page-Wiederherstellungsfeature von ESE gepatcht werden. Wenn bei einer verzögerten Kopie eine Datenbankseitenbeschädigung auftritt (z. B. ein Fehler -1018), muss sie erneut eingeset werden (wodurch der verzögerte Aspekt der Kopie verloren geht).

Das Aktivieren und Wiederherstellen einer verzögerten Postfachdatenbankkopie ist ein einfacher Prozess, wenn die Datenbank alle Protokolldateien wiedergeben und die Datenbankkopie aktuell machen soll. Wenn Sie Protokolldateien bis zu einem bestimmten Zeitpunkt wiedergeben möchten, ist dies ein schwierigerer Vorgang, da Sie Protokolldateien manuell bearbeiten und Exchange Server Database Utilities (Eseutil.exe) ausführen.

Ausführliche Schritte zum Aktivieren einer verzögerten Postfachdatenbankkopie finden Sie unter Aktivieren einer verzögerten Postfachdatenbankkopie.

Abschneideverzögerung

Die Kürzungsverzögerungszeit ist eine Eigenschaft einer Postfachdatenbankkopie. Es gibt die Anzahl von Minuten an, die das Löschen des Protokolls für die Datenbankkopie verzögert, nachdem die Protokolldatei in der Datenbankkopie wiedergegeben wurde.

Der Timer für die Kürzungsverzögerung wird gestartet, nachdem eine Protokolldatei in die passive Kopie repliziert wurde, die Überprüfung erfolgreich bestanden wurde und erfolgreich in die Kopie der Datenbank wiedergegeben wird.

Indem Sie das Abschneiden von Protokolldateien aus der Datenbankkopie verzögern, können Sie nach Fehlern wiederherstellen, die sich auf die Protokolldateien für die aktive Kopie der Datenbank auswirken.

Datenbankkopien und Abschneiden der Protokolldateien

Die Protokollkürzung funktioniert in Exchange 2013 genauso wie in Exchange 2010. Die Einstellungen für wiedergabeverzögerte Zeit und Kürzungsverzögerung für die Datenbankkopie bestimmen das Abschneidungsverhalten.

Die folgenden Kriterien müssen für das Abschneiden der Protokolldatei einer Datenbankkopie erfüllt sein, wenn die die Standardwerte (0 = deaktiviert) der Verzögerungseinstellungen beibehalten werden:

• Die Protokolldatei muss erfolgreich gesichert werden, oder die Zirkelprotokollierung muss aktiviert sein.
• Die Protokolldatei muss sich unterhalb des Prüfpunkts (die für die Wiederherstellung erforderliche minimale Protokolldatei) für die Datenbank befinden.
• Alle anderen verzögerten Kopien müssen die Protokolldatei überprüfen.
• Alle anderen Kopien (keine verzögerten Kopien) müssen die Protokolldatei wiedergeben.

Die folgenden Kriterien müssen erfüllt sein, damit das Abschneiden für eine verzögerte Datenbankkopie erfolgt:

• Die Protokolldatei muss sich unterhalb des Prüfpunkts für die Datenbank befinden.
• Die Protokolldatei muss älter sein als "ReplayLagTime" + "TruncationLagTime".
• Die Protokolldatei muss für die aktive Kopie abgeschnitten werden.

In Exchange 2013 tritt keine Protokollkürzung bei einer aktiven Postfachdatenbankkopie auf, wenn mindestens eine passive Kopie angehalten wird. Wenn geplante Wartungsaktivitäten einen längeren Zeitraum in Anspruch nehmen (z. B. mehrere Tage), kann es zu erheblichen Protokolldateien kommen. Damit das Protokolllaufwerk nicht durch Transaktionsprotokolle überfüllt wird, können Sie die betroffene passive Datenbankkopie entfernen, anstatt sie anzuhalten. Wenn die geplante Wartung abgeschlossen ist, können Sie die passive Datenbankkopie lesen.

Exchange 2013 Service Pack 1 (SP1) führt ein neues Feature namens lose Kürzung ein, das standardmäßig deaktiviert ist. Während des normalen Betriebs speichert jede Datenbankkopie Protokolle, die an andere Datenbankkopien gesendet werden müssen. Alle Kopien der Datenbank müssen die folgenden Fakten bestätigen:

• Alle passiven Kopien der Datenbank bestätigen, dass sie die Protokolldateien wiedergegeben haben .
• Alle verzögerten Kopien der Datenbank bestätigen, dass sie die Protokolldateien erhalten haben .

Dieses Protokollkürzungsverhalten ist die Standardeinstellung.

Wenn eine Datenbankkopie aus irgendeinem Grund offline geht, sammeln sich die Protokolldateien auf den Datenträgern an, die von anderen Kopien der Datenbank verwendet werden. Eine betroffene Datenbankkopie, die über einen längeren Zeitraum offline bleibt, kann dazu führen, dass für die anderen Datenbankkopien nicht genügend Speicherplatz verfügbar ist.

Wenn loses Abschneiden aktiviert ist, unterscheidet sich das Kürzungsverhalten. Jede Datenbankkopie verfolgt ihren eigenen freien Speicherplatz und wendet ungenaues Abschneiden an, wenn der freie Speicherplatz zur Neige geht. Für die aktive Kopie wird der älteste Nachzügler (die passive Datenkkopie, die in der Protokollwiedergabe am weitesten zurückliegt) ignoriert und beim Abschneiden werden die ältesten verbleibenden passiven Kopien respektiert. Die aktive Datenbankkopie ist dort, wo das globale Abschneiden berechnet wird. Die passiven Kopien versuchen, die Kürzungsentscheidung für die aktive Kopie zu berücksichtigen. Trotz der Implikation des Namens MinCopiesToProtect ignoriert Exchange nur den ältesten bekannten Nachzügler zum Zeitpunkt der Kürzung. Wenn bei einer passiven Kopie der Speicherplatz knapp wird, werden die Protokolldateien unabhängig voneinander abgeschnitten, indem die in der anstehenden Tabelle beschriebenen konfigurierten Parameter verwendet werden.

Eine Offlinedatenbank, die wieder online geschaltet wird, weist die folgenden Probleme auf:

• In der Datenbank fehlen Protokolldateien, die aus den anderen fehlerfreien Kopien gelöscht wurden.
• Die Datenbankkopie status ist FailedAndSuspended.

Wenn Autoreseed konfiguriert ist, wird die betroffene Kopie automatisch erneut eingeset. Wenn Autoreseed nicht konfiguriert ist, muss ein Administrator ein manuelles Seeding für die Datenbankkopie ausführen.

Die erforderliche Anzahl von fehlerfreien Kopien, der Schwellenwert für freien Festplattenspeicher und die Anzahl der zu speichernden Protokolle sind konfigurierbare Parameter. Standardmäßig beträgt der Schwellenwert für freien Speicherplatz 204.800 MB (200 GB), und die Anzahl der zu speichernden Protokolle beträgt 100.000 (100 GB) für passive Kopien und 10.000 (10 GB) für aktive Kopien.

Sie aktivieren die lose Kürzung und konfigurieren lose Kürzungsparameter, indem Sie die Windows-Registrierung für jedes DAG-Mitglied bearbeiten. Es gibt drei Registrierungswerte, die konfiguriert werden können, die alle unter HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformationgespeichert werden. Der BackupInformation-Schlüssel mit den folgenden DWORD-Werten ist standardmäßig nicht vorhanden und muss manuell erstellt werden. Die DWORD-Registrierungswerte unter „BackupInformation“ werden in der folgenden Tabelle beschrieben:

Der LooseTruncation_MinLogsToProtect Registrierungswert verursacht ein anderes Verhalten für aktive und passive Datenbankkopien.

• Aktive Kopien: Gibt die Anzahl der zusätzlichen Protokolle an, die vor den Protokollen aufbewahrt werden, die für die geschützten passiven Kopien erforderlich sind, und den erforderlichen Bereich der aktiven Kopie.
• Passive Kopien: Gibt die Anzahl der Protokolle an, die aus dem neuesten verfügbaren Protokoll verwaltet werden. Ein Zehntel dieser Zahl wird auch verwendet, um Protokolle vor dem erforderlichen Bereich dieser passiven Kopie zu verwalten.

Die beiden Grenzwerte stellen sicher, dass verzögerte Datenbankkopien nicht zu viel Speicherplatz in Anspruch nehmen, da ihr erforderlicher Bereich in der Regel sehr groß ist.

Datenbankaktivierungsrichtlinie

Die folgenden Szenarien geben an, wo Sie möglicherweise eine Postfachdatenbankkopie erstellen möchten und verhindern, dass das System diese Kopie nach einem Fehler automatisch aktiviert:

• Sie stellen eine oder mehrere Postfachdatenbankkopien in einem alternativen oder Standby-Rechenzentrum bereit.
• Sie konfigurieren eine verzögerte Datenbankkopie zu Wiederherstellungszwecken.
• Sie führen Eine Wartung oder ein Serverupgrade durch.

Damit das System am automatischen Aktivieren einer Postfachdatenbankkopie gehindert wird, können Sie die Kopie so konfigurieren, dass sie für die Aktivierung blockiert (angehalten) ist.

Diese Konfiguration ermöglicht es dem System, die Währung der Datenbank durch Protokollversand und Wiedergabe beizubehalten, verhindert jedoch, dass das System die Kopie automatisch aktiviert und verwendet.

Ein Administrator muss manuell aktive Kopien aktivieren, die für die Aktivierung blockiert sind. Sie können die Datenbankaktivierungsrichtlinie mit den folgenden Methoden konfigurieren:

• Pro Server: Verwenden Sie das Cmdlet Set-MailboxServer .
• Pro Datenbank: Verwenden Sie den Wert Blocked für den Parameter DatabaseCopyAutoActivationPolicy im Cmdlet Set-MailboxDatabaseCopy .

Weitere Informationen zum Konfigurieren der Richtlinie für die Datenbankaktivierung finden Sie unter Konfigurieren der Aktivierungsrichtlinie für die Kopie einer Postfachdatenbank.

Auswirkungen von Postfachverschiebungen auf die fortlaufende Replikation

Bei einer sehr ausgelasteten Postfachdatenbank mit einer hohen Protokollgenerierungsrate besteht eine höhere Wahrscheinlichkeit für Datenverluste, wenn die Replikation in die passiven Datenbankkopien mit der Protokollgenerierung nicht Schritt halten kann. Postfachverschiebungen können zu einer hohen Protokollgenerierungsrate führen.

Exchange 2013 enthält eine Datengarantie-API. Der Microsoft Exchange-Postfachreplikationsdienst (Microsoft Exchange Mailbox Replication Service, MRS) und andere Dienste verwenden diese API, um die Integrität der Datenbankkopierarchitektur zu überprüfen. Diese Integritätsprüfung basiert auf dem DataMoveReplicationConstraint-Parameterwert , der vom System oder einem Administrator festgelegt wurde. Insbesondere wird die Datengarantie-API für die folgenden Überprüfungen verwendet:

• Replikationsintegrität: Bestätigt, dass die erforderliche Anzahl von Datenbankkopien verfügbar ist.
• Replikationsleerung: Bestätigt, dass die erforderlichen Protokolldateien anhand der erforderlichen Anzahl von Datenbankkopien wiedergegeben wurden.

Bei der Ausführung gibt die API die folgenden Statusinformationen für die aufrufende Anwendung zurück:

• Wiederholen: Gibt an, dass vorübergehende Fehler vorliegen, die verhindern, dass eine Bedingung anhand der Datenbank überprüft wird.
• Zufrieden: Gibt an, dass die Datenbank die erforderlichen Bedingungen erfüllt oder die Datenbank nicht repliziert wird.
• NotSatisfied: Gibt an, dass die Datenbank die erforderlichen Bedingungen nicht erfüllt. Darüber hinaus wird für die aufrufende Anwendung angegeben, weshalb die Antwort NotSatisfied zurückgegeben wurde.

Der Wert des DataMoveReplicationConstraint-Parameters für die Postfachdatenbank bestimmt, wie viele Datenbankkopien als Teil der Anforderung ausgewertet werden sollen. Der DataMoveReplicationConstraint-Parameter weist die folgenden möglichen Werte auf:

• None: Wenn Sie eine Postfachdatenbank erstellen, wird dieser Wert standardmäßig festgelegt. Bei Festlegung dieses Werts werden die Bedingungen der Datengarantie-API ignoriert. Diese Einstellung sollte nur für Postfachdatenbanken verwendet werden, die nicht repliziert werden.
• SecondCopy: Dieser Wert ist der Standardwert, wenn Sie die zweite Kopie einer Postfachdatenbank hinzufügen. Bei Festlegung dieses Werts muss mindestens eine passive Datenbankkopie die Bedingungen der Datengarantie-API erfüllen.
• SecondDatacenter: Wenn dieser Wert festgelegt ist, muss mindestens eine passive Datenbankkopie an einem anderen Active Directory-Standort die Bedingungen der Datengarantie-API erfüllen.
• AllDatacenters: Wenn dieser Wert festgelegt ist, muss mindestens eine passive Datenbankkopie an jedem Active Directory-Standort die Bedingungen der Datengarantie-API erfüllen.
• AllCopies: Wenn dieser Wert festgelegt ist, müssen alle Kopien der Postfachdatenbank die Bedingungen der Datengarantie-API erfüllen.

Überprüfen der Replikationsintegrität

Wenn die Datengarantie-API ausgeführt wird, um die Integrität der Infrastruktur der Datenbankkopien auszuwerten, werden verschiedene Elemente ausgewertet.

Überprüfen von Replikationslöschvorgängen

Die Datengarantie-API kann auch verwendet werden, um zu überprüfen, ob die erforderlichen Datenbankkopien die erforderlichen Transaktionsprotokolle wiedergegeben haben. Die API überprüft diesen Zustand, indem der zuletzt wiedergegebene Protokollzeitstempel mit dem Commitzeitstempel des aufrufenden Diensts verglichen wird. In den meisten Fällen ist dieser Zeitstempel der Zeitstempel der letzten Protokolldatei, die die erforderlichen Daten enthält. Die API fügt zusätzliche fünf Sekunden hinzu, um Abweichungen oder Abweichungen der Systemzeituhr zu behandeln.

• Wenn der Wiedergabezeitstempel größer als der Commitzeitstempel ist, wird der DataMoveReplicationConstraint-Parameter erfüllt.
• Wenn der Wiedergabezeitstempel kleiner als der Commitzeitstempel ist, wird DataMoveReplicationConstraint nicht erfüllt.

Bevor Sie eine große Anzahl von Postfächern in oder aus Replikationsdatenbanken innerhalb einer DAG verschieben, sollten Sie den DataMoveReplicationConstraint-Parameter für jede Postfachdatenbank gemäß der folgenden Tabelle konfigurieren:

Ausgleichen von Datenbankkopien

Aufgrund des inhärenten Charakters von DAGs ändern aktive Postfachdatenbankkopien als Ergebnis von Datenbankwechseln und Failovern während der gesamten Lebensdauer einer DAG mehrmals den Host. Dadurch kann die Verteilung der aktiven Postfachdatenbankkopien der DAGs aus dem Gleichgewicht geraten. Die folgende Tabelle zeigt als Beispiel eine DAG mit vier Datenbanken und vier Kopien jeder Datenbank (insgesamt 16 Datenbanken auf jedem Server) sowie einer unausgeglichenen Verteilung aktiver Datenbankkopien.

DAG mit unausgeglichener Verteilung aktiver Kopien

Im vorausgehenden Beispiel sind vier Kopien jeder Datenbank vorhanden, daher gibt es nur vier mögliche Werte für die Aktivierungseinstellungen (1, 2, 3 oder 4). Die Spalte Anzahl von Datenbanken mit diesen Einstellungen zeigt die Anzahl von Datenbanken mit diesen Werten. In der vorherigen Tabelle enthält EX3 Datenbanken mit den folgenden Konfigurationen:

• 13 Datenbankkopien mit einer Aktivierungspräferenz von 1.
• Zwei Kopien mit einer Aktivierungspräferenz von 2.
• Eine Kopie mit einer Aktivierungspräferenz von 3.
• Keine Kopien mit einer Aktivierungspräferenz von 4.

Wie Sie sehen können, ist diese DAG aus den folgenden Gründen unausgeglichen:

• Die Anzahl der aktiven Datenbanken, die von jedem DAG-Mitglied gehostet werden.
• Die Anzahl der passiven Datenbanken, die von jedem DAG-Mitglied gehostet werden.
• Die Anzahl der Aktivierungseinstellungen der gehosteten Datenbanken.

Sie können das RedistributeActiveDatabases.ps1 Skript verwenden, um die Kopien der aktiven Postfachdatenbanken in einer DAG auszugleichen. Das Skript verschiebt Datenbanken zwischen ihren Kopien, um die Anzahl von eingebundenen Datenbanken auf jedem Server in einer DAG auszugleichen. Bei Bedarf versucht das Skript auch, aktive Datenbanken standortübergreifend auszugleichen.

Das Skript stellt zwei Optionen zum Ausgleich aktiver Datenbankkopien in einer DAG bereit:

• BalanceDbsByActivationPreference: Wenn diese Option angegeben ist, versucht das Skript, Datenbanken ohne Berücksichtigung des Active Directory-Standorts in ihre bevorzugte Kopie zu verschieben (basierend auf der Aktivierungspräferenz).
• BalanceDbsBySiteAndActivationPreference: Wenn diese Option angegeben ist, versucht das Skript, aktive Datenbanken in die am häufigsten bevorzugte Kopie zu verschieben, während gleichzeitig versucht wird, aktive Datenbanken innerhalb jedes Active Directory-Standorts auszugleichen.

Nachdem Sie das Skript mit der ersten Option ausgeführt haben, wird der vorherige unausgeglichene DAG ausgeglichen, wie in der folgenden Tabelle gezeigt.

DAG mit ausgeglichener Verteilung aktiver Kopien

Wie in der obigen Tabelle gezeigt, wird diese DAG jetzt basierend auf den folgenden Faktoren ausgeglichen:

• Die Anzahl der aktiven und passiven Datenbanken auf jedem Server.
• Die Aktivierungspräferenz für mehrere Server.

In der folgenden Tabelle sind die verfügbaren Parameter für das Skript "RedistributeActiveDatabases.ps1" aufgeführt.

Skriptparameter "RedistributeActiveDatabases.ps1"

RedistributeActiveDatabases.ps1 – Beispiele

In diesem Beispiel wird die aktuelle Datenbankverteilung für eine DAG, einschließlich der Anzahl von Datenbanken mit diesen Einstellungen, veranschaulicht.

RedistributeActiveDatabases.ps1 -DagName DAG1 -ShowDatabaseDistributionByServer | Format-Table

In diesem Beispiel werden die aktiven Postfachdatenbankkopien in einer DAG mithilfe von Aktivierungseinstellungen neu verteilt und ausgeglichen, ohne dass eine Eingabe erforderlich ist.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -Confirm:$False

In diesem Beispiel werden die aktiven Postfachdatenbankkopien in der DAG mithilfe von Aktivierungseinstellungen neu verteilt und ausgeglichen. Außerdem wird eine Zusammenfassung der Verteilung erstellt.

RedistributeActiveDatabases.ps1 -DagName DAG1 -BalanceDbsByActivationPreference -ShowFinalDatabaseDistribution

Überwachen von Datenbankkopien

Eine Datenbankkopie stellt Ihre erste Verteidigungsmaßnahme dar, wenn ein Fehler auftritt, der sich auf die aktive Kopie einer Datenbank auswirkt. Es ist wichtig, die Integrität und status von Datenbankkopien zu überwachen, um sicherzustellen, dass sie bei Bedarf verfügbar sind.

• Sie können das EAC verwenden, um Informationen zur Datenbankkopie anzuzeigen. Zum Beispiel:
  • Warteschlangenlänge kopieren.
  • Länge der Wiedergabewarteschlange.
  • Status.
  • Statusinformationen des Inhaltsindexes.
• Sie können das Cmdlet Get-MailboxDatabaseCopyStatus in der Shell verwenden, um eine Vielzahl von status Informationen für eine Datenbankkopie anzuzeigen.

Weitere Informationen zum Überwachen von Datenbankkopien finden Sie unter Überwachen von Datenbankverfügbarkeitsgruppen.

Entfernen einer Datenbankkopie

Eine Datenbankkopie kann jederzeit mithilfe des EAC oder mithilfe des Cmdlets Remove-MailboxDatabaseCopy in der Shell entfernt werden. Nachdem Sie eine Datenbankkopie entfernt haben, müssen Sie manuell alle Datenbank- und Transaktionsprotokolldateien von dem Server entfernen, von dem die Datenbankkopie entfernt wurde. Genaue Anweisungen zum Entfernen einer Datenbankkopie finden Sie unter Entfernen einer Postfachdatenbankkopie .

Datenbankswitchover

Der Postfachserver, der die aktive Kopie einer Datenbank hostet, wird als Postfachdatenbankmaster bezeichnet. Die Aktivierung einer passiven Datenbankkopie ändert den Postfachdatenbankmaster für die Datenbank und macht aus der passiven Kopie eine neue, aktive Kopie. Dieser Vorgang wird als Datenbankwechsel bezeichnet. Bei einem Datenbankswitchover wird die Einbindung einer aktiven Kopie einer Datenbank auf einem Postfachserver aufgehoben und eine passive Kopie dieser Datenbank als neue aktive Postfachdatenbank auf einem anderen Postfachserver eingebunden. Bei einem Switchover können Sie optional die Wähleinstellung für die Datenbankeinbindung für die neue Postfachdatenbank master überschreiben.

Sie können schnell erkennen, welcher Postfachserver der aktuelle Postfachdatenbankmaster ist, indem Sie die rechte Spalte auf der Registerkarte Datenbankkopien im EAC überprüfen. Sie können einen Wechsel durchführen, indem Sie den Link Aktivieren im EAC oder das Cmdlet Move-ActiveMailboxDatabase in der Shell verwenden.

Es gibt mehrere interne Überprüfungen, die vor dem Aktivieren einer passiven Kopie durchgeführt werden:

• Der Status der Datenbankkopie wird überprüft. Wenn die Datenbankkopie einen fehlerhaften Status aufweist, wird der Switchover blockiert. Sie können dieses Verhalten überschreiben und die Integritätsprüfung umgehen, indem Sie den SkipHealthChecks-Parameter des Cmdlets Move-ActiveMailboxDatabase verwenden. Mit diesem Parameter können Sie die aktive Kopie in eine Datenbankkopie in einem fehlerhaften Zustand verschieben.

• Für die aktive Datenbankkopie wird überprüft, ob sie gegenwärtig eine Seedingquelle für passive Kopien der Datenbank ist. Wenn die aktive Kopie gegenwärtig als Seedingquelle verwendet wird, wird der Switchovervorgang blockiert. Sie können dieses Verhalten überschreiben und die Seedingquellenüberprüfung umgehen, indem Sie den SkipActiveCopyChecks-Parameter des Cmdlets Move-ActiveMailboxDatabase verwenden. Dieser Parameter ermöglicht das Verschieben einer aktiven Kopie, die als Seedingquelle verwendet wird. Die Verwendung dieses Parameters bewirkt, dass der Seedingvorgang abgebrochen und als fehlerhaft angesehen wird.

• Die Länge der Kopie- und Wiedergabewarteschlange für die Datenbankkopie wird überprüft, um sicherzustellen, dass ihre Werte den konfigurierten Kriterien entsprechen. Die Datenbankkopie wird auch überprüft, damit sichergestellt ist, dass sie momentan nicht als Seedingquelle verwendet wird. Die Umstellung ist in den folgenden Szenarien blockiert:

  • Die Werte für die Warteschlangenlängen liegen außerhalb der konfigurierten Kriterien.
  • Die Datenbank wird derzeit als Quelle für das Seeding verwendet.

  Sie können dieses Verhalten überschreiben und diese Überprüfungen umgehen, indem Sie den SkipLagChecks-Parameter des Cmdlets Move-ActiveMailboxDatabase verwenden. Dieser Parameter ermöglicht es, dass eine Kopie aktiviert wird, die über nicht den Kriterien entsprechende Wiedergabe- und Kopiewarteschlangen verfügt.

• Der Status des Suchkatalogs (Inhaltsindex) für die Datenbankkopie wird überprüft. Wenn der Suchkatalog nicht auf dem neuesten Stand ist, sich in einem fehlerhaften Zustand befindet oder beschädigt ist, wird der Switchover blockiert. Sie können dieses Verhalten außer Kraft setzen und die Suchkatalogüberprüfung umgehen, indem Sie den SkipClientExperienceChecks-Parameter des Cmdlets Move-ActiveMailboxDatabase verwenden. Dieser Parameter führt dazu, dass diese Suche die Systemdiagnose für den Katalog überspringt.

  Wenn sich der Suchkatalog für die Datenbankkopie, die Sie aktivieren, in einem fehlerhaften oder nicht verwendbaren Zustand befindet, müssen Sie den Suchkatalog entweder durchforsten oder erneut seeden.

Bei einem Datenbankwechsel haben Sie auch die Möglichkeit, die Einstellungen für die Einbindungswählfunktion zu überschreiben, die für den Server konfiguriert sind, auf dem die passive Datenbankkopie gehostet wird, die aktiviert wird. Mithilfe des MountDialOverride-Parameters des Cmdlets Move-ActiveMailboxDatabase wird der Zielserver angewiesen, seine eigenen Einbindungswähleinstellungen zu überschreiben und die einstellung zu verwenden, die durch den MountDialOverride-Parameter angegeben wird.

Ausführliche Schritte zum Umstellen einer Datenbankkopie finden Sie unter Aktivieren einer Postfachdatenbankkopie.