Verwalten von Postfachdatenbankkopien

Gilt für: Exchange Server 2013

Nachdem Sie eine Datenbankverfügbarkeitsgruppe (DAG) erstellt, konfiguriert und mit Postfachservermitgliedern 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 die EAC oder die Shell verwenden, um die Integrität und den Status jeder Kopie zu überwachen. Sie können auch andere Verwaltungsaufgaben ausführen, die mit Datenbankkopien verbunden sind. Zum Beispiel:

• Anhalten oder Fortsetzen einer Datenbankkopie.
• Führen Sie ein Seeding für eine Datenbankkopie durch.
• Überwachen von Datenbankkopien.
• Konfigurieren Sie die Einstellungen für das Datenbankkopieren.
• Entfernen Sie eine Datenbankkopie.

Anhalten und Fortsetzen von Datenbankkopien

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

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

Seeding von Datenbankkopien

Seeding (auch als Aktualisierung bezeichnet) bedeutet das Hinzufügen einer leeren Datenbank oder einer Kopie der Produktionsdatenbank auf einem anderen Postfachserver, der sich in derselben DAG wie die aktive Datenbank befindet. Diese Datenbank wird zur Basisdatenbank für die Kopie, die von diesem Server verwaltet wird.

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

Wenn Sie für eine Datenbankkopie ein manuelles Seeding ohne automatisches Seeding beim Erstellen der Kopie ausführen möchten, verwenden Sie den SeedingPostponed-Parameter im Cmdlet Add-MailboxDatabaseCopy .

In der Regel muss für Datenbankkopien ein erneutes Seeding durchgeführt werden, nachdem das erste Seeding stattgefunden hat. Wenn Sie jedoch ein manuelles Seeding für eine Datenbankkopie durchführen müssen oder möchten, können Sie eine der folgenden Methoden verwenden:

• Der Assistent zum Aktualisieren der Postfachdatenbank in der Exchange-Verwaltungskonsole.
• Das Update-MailboxDatabaseCopy-Cmdlet 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 Startvorgangs wird die Replikation für die Datenbankkopie des Seedingpostfachs automatisch fortgesetzt. Wenn Sie nicht möchten, dass die Replikation automatisch fortgesetzt wird, können Sie den Parameter ManualResume im Cmdlet Update-MailboxDatabaseCopy verwenden.

Auswählen der Seedingziele

Wenn Sie eine Startoperation durchführen, haben Sie die folgenden Optionen:

• Seeding für die Postfachdatenbankkopie durchführen: Dieses Verhalten ist die Standardeinstellung für den Assistenten zum Aktualisieren der Postfachdatenbankkopie und das Cmdlet Update-MailboxDatabaseCopy.
• Seeding des Inhaltsindexkatalogs für die Postfachdatenbankkopie: Verwenden Sie den Parameter "DatabaseOnly" im Cmdlet Update-MailboxDatabaseCopy .
• Seeding für die Datenbankkopie und die Kopie des Inhaltsindexkatalogs: Verwenden Sie den Parameter "CatalogOnly" 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 hinweg erweitern.

Stellen Sie sich beispielsweise eine DAG-Bereitstellung mit vier Mitgliedern vor:

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

Wenn Sie eine Kopie von DB1 zu MBX4 hinzufügen, haben Sie die Möglichkeit, die Kopie auf MBX3 als Quelle für das Seeding zu verwenden. Bei dieser Option wird das Seeding über die WAN-Verbindung (Wide Area Network) zwischen Portland und New York vermieden.

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

• Verwenden Sie zum Hinzufügen der Datenbankkopie den SeedingPostponed-Parameter im Cmdlet Add-MailboxDatabaseCopy . Wenn der SeedingPostponed-Parameter nicht verwendet wird, wird das Seeding für die Datenbankkopie explizit durchgeführt, wobei die aktive Kopie der Datenbank als Quelle verwendet wird.

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

  • Im Assistenten zum Aktualisieren der Postfachdatenbank im EAC.
  • Der Parameter "SourceServer" im Cmdlet "Update-MailboxDatabaseCopy ".

Im vorherigen Beispiel würden Sie „MBX3" als Quellserver angeben. Wenn der SourceServer-Parameter nicht verwendet wird, wird das Seeding für die Datenbankkopie von der aktiven Kopie der Datenbank explizit durchgeführt.

Seeding und Netzwerke

Neben der Auswahl 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 Startvorgangs.

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

• Wenn sich Quellserver und Zielserver im gleichen Subnetz befinden und ein Replikationsnetzwerk konfiguriert ist, das das Subnetz umfasst, 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. Standardmäßig werden Verschlüsselung und Komprimierung nur für die Kommunikation in unterschiedlichen Subnetzen verwendet.

Wenn sich die Quelle und das Ziel in unterschiedlichen Subnetzen befinden und die DAG mit den Standardwerten für NetworkCompression und NetworkEncryption konfiguriert ist, können Sie diese Werte mithilfe der Parameter NetworkCompressionOverride und NetworkEncryptionOverride im Cmdlet Update-MailboxDatabaseCopy außer Kraft setzen.

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 Server zu überprüfen:

   • Auf dem Quell- und Zielserver wird Exchange 2013 ausgeführt.
   • Der Quell- und der 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 den Status Seeding 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 anschließende Kommunikation für das 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 im Hauptverzeichnis der Datenbank, 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 das Anhalten 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 mit dem Namen, 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 Einstellungen für Datenbankkopien anzuzeigen und zu konfigurieren. Zum Beispiel:
  • Wiedergabe der Verzögerungszeit.
  • Abbruchverzögerungszeit.
  • Reihenfolge der Aktivierungspräferenzen.

Ausführliche Schritte zum Anzeigen und Konfigurieren von Einstellungen für Datenbankkopien finden Sie unter Konfigurieren der Kopiereigenschaften für Postfächerdatenbanken.

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 Ansammlung von Protokolldateien führen, wirkt sich die Verwendung der beiden auf Ihren Speicherentwurf aus.

Wiedergabeverzögerung

Die Wiedergabeverzögerungszeit ist eine Eigenschaft einer Postfachdatenbankkopie, die den Zeitraum in Minuten angibt, für den die Protokollwiedergabe für die Datenbankkopie verzögert werden soll. Der Wiedergabeverzögerungs-Timer wird gestartet, 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ögerungszeit größer als Null konfiguriert ist, wird als verzögerte Postfachdatenbankkopie 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 können jedoch keinen Schutz vor Datenverlusten bieten, da häufig logische Beschädigungen auftreten. Verzögerte Kopien sollen Datenverluste aufgrund logischer Beschädigungen verhindern. 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 oder an die falsche Stelle geschrieben. Diese Situation wird als verlorener Flush 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 Beschädigung des Speichers: Daten werden auf eine Weise hinzugefügt, gelöscht oder bearbeitet, die der Benutzer nicht erwartet. Diese Fälle werden in der Regel durch Anwendungen verursacht, die nicht von Microsoft stammen. Es ist Korruption in dem Sinne, dass der Benutzer es als Korruption ansieht. Der Exchange-Speicher betrachtet die Transaktion, die zur logischen Beschädigung geführt hat, als eine Folge gültiger MAPI-Operationen. Das Beweissicherungsfeature in Exchange 2013 bietet Schutz vor Beschädigungen der Speicherlogik (da es verhindert, dass ein Benutzer oder eine Anwendung Inhalte dauerhaft löscht). Es kann jedoch Szenarien geben, in denen ein Benutzerpostfach so beschädigt wird, 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 Wiedergabeverzögerung (eine verzögerte Kopie) verwendet werden soll, hängt davon ab, welche Nicht-Microsoft-Anwendungen Sie verwenden und wie in Ihrer organization zuvor die Speicherlogik beschädigt wurde.

Verzögerte Kopien können sich in Exchange 2013 selbst versorgen, wenn Sie die Protokolldateien in bestimmten Szenarien automatisch wiedergeben:

• Ein Schwellenwert für einen niedrigen Speicherplatz ist erreicht.
• Die verzögerte Kopie weist eine physische Beschädigung auf und muss auf der Seite gepatcht werden.
• Es gibt weniger als drei verfügbare fehlerfreie Kopien (aktiv oder nur 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 für eine verzögerte Kopie ein Seitenpatch erforderlich ist, werden die Protokolle automatisch in die verzögerte Kopie wiedergegeben, um Seitenpatches durchzuführen. Verzögerte Kopien rufen diese automatische Wiedergabefunktion auch in den folgenden Szenarien auf:

• Ein Schwellenwert für einen niedrigen Speicherplatz ist 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.

Stellen Sie sich beispielsweise eine Umgebung vor, in der eine Datenbank vier Kopien enthält:

• Drei hochverfügbare Exemplare.
• 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. weil die Kopie angehalten wurde), spielt die verzögerte Kopie automatisch ihre Protokolldateien innerhalb von 24 Stunden ab.

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

• Die Wiedergabeverzögerungszeit ist ein vom Administrator konfigurierter Wert. Standardmäßig ist die Verzögerungszeit für die Wiedergabe 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 die Notfallwiederherstellung konzipiert, um vor Beschädigungen der Speicherlogik zu schützen.

• Je größer die festgelegte Wiedergabeverzögerung, desto länger ist der Datenbankwiederherstellungsprozess. Die Wiederherstellung einer Datenbank kann aufgrund der folgenden Faktoren mehrere Stunden dauern:

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

• Es wird empfohlen, zu bestimmen, ob verzögerte Kopien für Ihre allgemeine Notfallwiederherstellungsstrategie entscheidend sind. Wenn ihre Verwendung für Ihre Strategie entscheidend ist, empfehlen wir die folgenden Konfigurationen:

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

  Wenn Sie einen Datenträger verlieren oder es zu einer Beschädigung kommt, geht Ihr verzögerter Zeitpunkt nicht verloren.

• Verzögerte Kopien können mit dem ESE-Feature zum Wiederherstellen einzelner Seiten nicht gepatcht werden. Wenn bei einer verzögerten Kopie eine Datenbankseitenbeschädigung auftritt (z. B. ein -1018-Fehler), muss das Seeding erneut durchgeführt werden (dabei geht der verzögerte Aspekt der Kopie verloren).

Das Aktivieren und Wiederherstellen einer verzögerten Postfachdatenbankkopie ist ein einfacher Prozess, wenn die Datenbank alle Protokolldateien wiedergeben und die Datenbankkopie auf den neuesten Stand bringen 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 Datenbankdienstprogramme (Database Utilities, Eseutil.exe) ausführen müssen.

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

Abschneideverzögerung

Der Abbruchzeitpunkt ist eine Eigenschaft einer Postfachdatenbankkopie. Sie legt die Anzahl der Minuten fest, die die Protokolllöschung für die Datenbankkopie verzögern soll, nachdem die Protokolldatei in der Datenbankkopie wiedergegeben wurde.

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

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

Datenbankkopien und Abschneiden der Protokolldateien

Das Abschneiden von Protokollen funktioniert in Exchange 2013 genauso wie in Exchange 2010. Die Einstellungen für die Wiedergabeverzögerung und die Abbruchzeit für die Datenbankkopie bestimmen das Abbruchverhalten.

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 Umlaufprotokollierung 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 erneut ausführen.

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 in der aktiven Kopie abgeschnitten werden.

In Exchange 2013 erfolgt das Abschneiden des Protokolls für eine aktive Postfachdatenbankkopie nicht, wenn eine oder mehrere passive Kopien angehalten werden. Wenn geplante Wartungsaktivitäten über einen längeren Zeitraum (z. B. mehrere Tage) in Anspruch nehmen, kann die Protokolldatei erheblich anwachsen. 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 erneut hinzufügen.

Exchange 2013 Service Pack 1 (SP1) führt ein neues Feature namens loses Abschneiden ein, das standardmäßig deaktiviert ist. Während des normalen Betriebs werden in jeder Datenbankkopie Protokolle aufbewahrt, 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 erneut abgespielt haben .
• Alle verzögerten Kopien der Datenbank bestätigen, dass sie die Protokolldateien erhalten haben .

Dieses Verhalten zum Abschneiden des Protokolls 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. Wenn eine betroffene Datenbankkopie über einen längeren Zeitraum offline bleibt, kann dies dazu führen, dass für die anderen Datenbankkopien nicht mehr genügend Speicherplatz verfügbar ist.

Wenn die lose Trunkierung aktiviert ist, ist das Abschneideverhalten anders. 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. Bei den passiven Kopien wird versucht, die Entscheidung zum Abschneiden der aktiven Kopie zu respektieren. 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 mithilfe der in der folgenden Tabelle beschriebenen konfigurierten Parameter abgeschnitten.

Bei einer Offlinedatenbank, die wieder online geschaltet wird, treten die folgenden Probleme auf:

• In der Datenbank fehlen Protokolldateien, die aus den anderen fehlerfreien Kopien gelöscht wurden.
• Der Status der Datenbankkopie lautet FailedAndSuspended.

Wenn Autoreseed konfiguriert ist, wird das Seeding für die betroffene Kopie automatisch erneut durchgeführt. Wenn AutoReseed nicht konfiguriert ist, muss ein Administrator manuell ein Seeding für die Datenbankkopie durchführen.

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

Sie aktivieren das lose Abschneiden und konfigurieren die Parameter für das lose Abschneiden, indem Sie die Windows-Registrierung für jedes DAG-Mitglied bearbeiten. Es können drei Registrierungswerte konfiguriert werden, die alle unter HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformationgespeichert sind. Der BackupInformation-Schlüssel Die folgenden DWORD-Werte sind standardmäßig nicht vorhanden und müssen manuell erstellt werden. Die DWORD-Registrierungswerte unter „BackupInformation“ werden in der folgenden Tabelle beschrieben:

Der LooseTruncation_MinLogsToProtect Registrierungswert bewirkt ein unterschiedliches Verhalten für aktive und passive Datenbankkopien.

• Aktive Kopien: Gibt die Anzahl der zusätzlichen Protokolle an, die vor den von den geschützten passiven Kopien erforderlichen Protokollen aufbewahrt werden, und den erforderlichen Bereich der aktiven Kopie.
• Passive Kopien: Gibt die Anzahl der Protokolle an, die seit dem letzten 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 beanspruchen, da ihr erforderlicher Bereich normalerweise sehr groß ist.

Datenbankaktivierungsrichtlinie

Die folgenden Szenarien geben Aufschluss darüber, 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-Datencenter bereit.
• Sie konfigurieren eine verzögerte Datenbankkopie zu Wiederherstellungszwecken.
• Sie führen Wartungsarbeiten 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 über Protokollversand und Wiedergabe beizubehalten, verhindert jedoch, dass das System die Kopie automatisch aktiviert und verwendet.

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

• Serverbasiert: 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

In einer sehr ausgelasteten Postfachdatenbank mit einer hohen Protokollgenerierungsrate besteht eine größere Wahrscheinlichkeit für Datenverluste, wenn die Replikation zu den passiven Datenbankkopien nicht mit der Protokollgenerierung Schritt halten kann. Das Verschieben von Postfächern kann zu einer hohen Protokollgenerierungsrate führen.

Exchange 2013 enthält eine Datengarantie-API. Der Microsoft Exchange-Postfachreplikationsdienst (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 für die erforderliche Anzahl von Datenbankkopien wiedergegeben wurden.

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

• Wiederholen: Bedeutet, dass vorübergehende Fehler vorliegen, die verhindern, dass eine Bedingung mit der Datenbank abgeglichen wird.
• Zufrieden: Bedeutet, dass die Datenbank die erforderlichen Bedingungen erfüllt oder die Datenbank nicht repliziert wird.
• NotSatisfied: Bedeutet, 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 im Rahmen der Anforderung ausgewertet werden sollen. Der Parameter DataMoveReplicationConstraint hat die folgenden möglichen Werte:

• 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 eine erforderliche Anzahl von Datenbankkopien die erforderlichen Transaktionsprotokolle wiedergegeben hat. Die API überprüft diesen Status, indem sie den Zeitstempel der letzten wiedergegebenen Protokollwiedergabe mit dem Commit-Zeitstempel des aufrufenden Diensts vergleicht. In den meisten Fällen ist dieser Zeitstempel der Zeitstempel der letzten Protokolldatei, die erforderliche Daten enthält. Die API fügt fünf zusätzliche Sekunden hinzu, um Stechuhrverzerrungen oder Abweichungen im System zu behandeln.

• Wenn der Wiedergabe-Zeitstempel größer als der Commit-Zeitstempel ist, wird der Parameter DataMoveReplicationConstraint erfüllt.
• Wenn der Zeitstempel für die Wiedergabe kleiner als der Commit-Zeitstempel ist, wird der DataMoveReplicationConstraint nicht erfüllt.

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

Ausgleichen von Datenbankkopien

Aufgrund der inhärenten Natur von DAGs wechseln aktive Postfachdatenbankkopien während der 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 Aktivierungsvoreinstellung von 3.
• Keine Kopien mit einer Aktivierungspräferenz von 4.

Wie Sie sehen, 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 bereitgestellten Datenbanken.

Sie können das RedistributeActiveDatabases.ps1 Skript verwenden, um die Kopien der aktiven Postfachdatenbanken über eine 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 Rücksicht auf den Active Directory-Standort in ihre bevorzugte Kopie (basierend auf der Aktivierungseinstellung) zu verschieben.
• BalanceDbsBySiteAndActivationPreference: Wenn diese Option angegeben ist, versucht das Skript, aktive Datenbanken in ihre bevorzugte Kopie zu verschieben und gleichzeitig den Ausgleich aktiver Datenbanken an jedem Active Directory-Standort zu gewährleisten.

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

DAG mit ausgeglichener Verteilung aktiver Kopien

Wie in der vorangegangenen Tabelle dargestellt, wird diese DAG nun auf der Grundlage der folgenden Faktoren ausgeglichen:

• Die Anzahl der aktiven und passiven Datenbanken auf jedem Server.
• Die serverübergreifende Aktivierungspräferenz.

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 den 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:
  • Länge der Warteschlange kopieren.
  • Länge der Warteschlange wiedergeben.
  • Status.
  • Informationen zum Status des Inhaltsindexes.
• Sie können das Cmdlet Get-MailboxDatabaseCopyStatus in der Shell verwenden, um verschiedene Statusinformationen 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 der Exchange-Verwaltungskonsole 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 Datenbank-Switchover 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. Wenn Sie einen Switchover durchführen, können Sie optional die Einstellung für die Datenbankeinbindung auf dem neuen 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 Switchover mithilfe des Links "Aktivieren " in der Exchange-Verwaltungskonsole oder mithilfe des Cmdlets "Move-ActiveMailboxDatabase" in der Shell durchführen.

Vor dem Aktivieren einer passiven Kopie werden mehrere interne Prüfungen durchgeführt:

• Der Status der Datenbankkopie wird überprüft. Wenn die Datenbankkopie einen fehlerhaften Status aufweist, wird der Switchover blockiert. Sie können dieses Verhalten außer Kraft setzen 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 verschieben, die sich in einem fehlerhaften Zustand befindet.

• 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 außer Kraft setzen und die Überprüfung der Seedingquelle umgehen, indem Sie den Parameter SkipActiveCopyChecks des Cmdlets Move-ActiveMailboxDatabase verwenden. Dieser Parameter ermöglicht das Verschieben einer aktiven Kopie, die als Seedingquelle verwendet wird. Bei Verwendung dieses Parameters wird der Seedingvorgang abgebrochen und als fehlgeschlagen betrachtet.

• 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. Der Wechsel wird 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 außer Kraft setzen und diese Überprüfungen umgehen, indem Sie den Parameter SkipLagChecks 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 Überprüfung des Suchkatalogs umgehen, indem Sie den Parameter SkipClientExperienceChecks 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 unbrauchbaren Zustand befindet, müssen Sie den Suchkatalog erneut durchforsten oder starten.

Bei einem Datenbank-Switchover haben Sie auch die Möglichkeit, die für den Server konfigurierten Einhängereglereinstellungen zu überschreiben, auf dem die zu aktivierende passive Datenbankkopie gehostet wird. Die Verwendung des MountDialOverride-Parameters des Move-ActiveMailboxDatabase-Cmdlets weist den Zielserver an, seine eigenen Einbindungsreglereinstellungen zu überschreiben und die durch den Parameter "MountDialOverride " angegebene Einstellung zu verwenden.

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