Verwalten von Datenbankkopien

GILT FÜR:2016 2019 Subscription Edition

In Exchange Server können Sie die Exchange-Verwaltungskonsole (Exchange Management Console, EAC) oder die Exchange-Verwaltungsshell verwenden, um Postfachdatenbankkopien hinzuzufügen, nachdem eine Datenbankverfügbarkeitsgruppe (DAG) erstellt, konfiguriert und mit Postfachservermitgliedern aufgefüllt wurde.

Verwalten von Datenbankkopien

Nachdem mehrere Kopien einer Datenbank erstellt wurden, können Sie die Exchange-Verwaltungskonsole (EAC) oder die Exchange-Verwaltungsshell verwenden, um die folgenden Aufgaben auszuführen:

• Überwachen Sie Integrität und Status jeder Kopie.
• Führen Sie andere Verwaltungsaufgaben im Zusammenhang mit Datenbankkopien aus. Zum Beispiel:
  • Anhalten oder Fortsetzen einer Datenbankkopie.
  • Führen Sie ein Seeding für eine Datenbankkopie durch.
  • Überwachen von Datenbankkopien.
  • Konfigurieren von Einstellungen für Datenbankkopien
  • Entfernen Sie eine Datenbankkopie.

Anhalten und Fortsetzen von Datenbankkopien

Aus verschiedenen Gründen, z. B. bei der Durchführung geplanter Wartungsarbeiten, müssen Sie möglicherweise die fortlaufende Replikation für eine Datenbankkopie anhalten und fortsetzen. Außerdem erfordern einige Verwaltungsaufgaben, z. B. das Seeding, dass Sie zuerst eine Datenbankkopie anhalten. 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 Exchange-Verwaltungsshell 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 bekannt als Aktualisierung, ist, wenn eine leere Datenbank oder eine Kopie der Produktionsdatenbank zum Zielkopierspeicherort auf einem anderen Postfachserver in derselben DAG wie die aktive Datenbank hinzugefügt wird. Diese Datenbank wird zur Basisdatenbank für die Kopie, die von diesem Server verwaltet wird.

Abhängig von der Situation kann das Seeding einer Datenbank ein automatischer Prozess oder ein von Ihnen eingeleiteter, manueller Prozess sein. Wenn eine Datenbankkopie hinzugefügt wird, erfolgt automatisch Seeding für die Kopie, wenn der Zielserver und sein Speicher ordnungsgemäß konfiguriert sind. Wenn Sie ein manuelles Seeding für eine Datenbankkopie ausführen möchten und nicht möchten, dass beim Erstellen der Kopie ein automatisches Seeding durchgeführt wird, können Sie den SeedingPostponed-Parameter im Cmdlet Add-MailboxDatabaseCopy verwenden.

Für Datenbankkopien ist nach dem anfänglichen Seeding selten ein erneutes Seeding erforderlich. Wenn jedoch ein erneutes Seeding erforderlich ist oder um ein manuelles Seeding für eine Datenbankkopie durchzuführen, anstatt das System automatisch Seeding für die Kopie durchführen zu lassen, haben Sie zwei Möglichkeiten:

• Verwenden Sie den Assistenten zum Aktualisieren der Postfachdatenbank in der Exchange-Verwaltungskonsole.
• Verwenden Sie das Cmdlet Update-MailboxDatabaseCopy in der Exchange-Verwaltungsshell .

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 folgende Optionen:

• Führen Sie ein Seeding für die Postfachdatenbankkopie durch.
• Führen Sie ein Seeding für den Inhaltsindexkatalog für die Postfachdatenbankkopie durch.
• Führen Sie ein Seeding für die Datenbankkopie und die Kopie des Inhaltsindexkatalogs durch.

Das Standardverhalten des Assistenten zum Aktualisieren von Postfachdatenbankkopien und des Cmdlets Update-MailboxDatabaseCopy ist es, das Seeding sowohl für die Postfachdatenbankkopie als auch für die Inhaltsindex-Katalogkopie auszuführen.

Wenn Sie nur das Seeding für die Postfachdatenbankkopie ohne Seeding für den Inhaltsindexkatalog ausführen möchten, verwenden Sie den Parameter "DatabaseOnly " im Cmdlet Update-MailboxDatabaseCopy .

Verwenden Sie den Parameter CatalogOnly im Cmdlet Update-MailboxDatabaseCopy , um nur das Seeding für die Inhaltsindexkatalogkopie auszuführen.

Auswählen der Seedingquelle

Sie können jede fehlerfreie Datenbankkopie als Seedingquelle für eine andere Kopie dieser Datenbank verwenden. Diese Option ist besonders nützlich, wenn Sie eine DAG über mehrere physische Standorte hinweg erweitert haben.

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

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

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

Um eine bestimmte Kopie als Quelle für das Seeding beim Hinzufügen einer neuen Datenbankkopie zu verwenden, gehen Sie wie folgt vor:

• Verwenden Sie den SeedingPostponed-Parameter im Cmdlet Add-MailboxDatabaseCopy , um die Datenbankkopie hinzuzufügen. Andernfalls erfolgt das Seeding für die Datenbankkopie explizit unter Verwendung der aktiven Kopie der Datenbank als Quelle.

• Sie können den zu verwendenden Quellserver im Assistenten zum Kopieren von Postfachdatenbanken in der Exchange-Verwaltungskonsole angeben, oder Sie können den SourceServer-Parameter im Cmdlet Update-MailboxDatabaseCopy verwenden, um den gewünschten Quellserver für das Seeding anzugeben.

  Im vorherigen Beispiel geben Sie MBX3 als Quellserver an. Andernfalls erfolgt ein explizites Seeding für die Datenbankkopie aus der aktiven Kopie der Datenbank.

Seeding und Netzwerke

Zusätzlich zum Auswählen eines bestimmten Quellservers für das Seeding einer Postfachdatenbankkopie können Sie über die Exchange-Verwaltungsshell auch angeben, welche DAG-Netzwerke zu verwenden sind. Sie können die Komprimierungs- und Verschlüsselungseinstellungen des DAG-Netzwerks während des Startvorgangs außer Kraft setzen.

Sie können die Netzwerke angeben, die für das Seeding verwendet werden sollen, indem Sie den Parameter Network im Cmdlet Update-MailboxDatabaseCopy verwenden und die DAG-Netzwerke angeben, 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. Die Standardeinstellungen geben an, dass die Verschlüsselung und Komprimierung nur für die Kommunikation in unterschiedlichen Subnetzen verwendet wird. 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 des Add-MailboxDatabaseCopy- oder Update-MailboxDatabaseCopy-Cmdlets starten, werden die folgenden Aufgaben ausgeführt:

1. Datenbankeigenschaften aus Active Directory werden gelesen, um die angegebene Datenbank und Server zu überprüfen und sicherzustellen, dass auf dem Quell- und Zielserver Exchange Server ausgeführt wird, dass beide Mitglieder derselben DAG sind und dass die angegebene Datenbank keine Wiederherstellungsdatenbank ist. Die Datenbankdateipfade werden ebenfalls gelesen.

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 prüft das Vorhandensein von Datenbank- und Transaktionsprotokolldateien in den Dateiverzeichnissen, die von den Active Directory-Prüfungen in Schritt 1 gelesen werden.

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 für die Datenbank, 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 Microsoft Exchange-Replikationsdienst auf dem Zielserver an den Microsoft Exchange-Replikationsdienst auf dem Quellserver ü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, dass die Indizierung angehalten wird.

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 auch die Cmdlets Get-MailboxDatabase und Set-MailboxDatabaseCopy in der Exchange-Verwaltungsshell verwenden, um Einstellungen für Datenbankkopien anzuzeigen und zu konfigurieren. Zum Beispiel die Verzögerungszeit für die Wiedergabe, die Verzögerungszeit beim Abschneiden und die Reihenfolge der Aktivierungseinstellungen. 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ögerung ist eine Eigenschaft einer Postfachdatenbankkopie, die die Dauer (in Minuten) angibt, um die die Protokollwiedergabe für die Datenbankkopie verzögert wird. 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 Server 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 Datenverlust aufgrund logischer Beschädigungen bieten. Obwohl logische Beschädigungen selten sind, können sie zu Datenverlusten führen. 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: Die Prüfsumme der Datenbankseiten stimmt überein, aber die Daten auf den Seiten sind logisch falsch. Diese Situation tritt auf, wenn ESE versucht, eine Datenbankseite zu schreiben. Obwohl das Betriebssystem eine Erfolgsmeldung zurückgibt, werden die Daten entweder nie auf den Datenträger geschrieben oder an die falsche Stelle geschrieben. Dieser Zustand wird als verlorene Spülung 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. Nicht-Microsoft-Anwendungen verursachen diese Fälle im Allgemeinen. Es wird im Allgemeinen als Korruption in dem Sinne angesehen, dass der Benutzer es als Korruption betrachtet. 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 Server bietet Schutz vor Beschädigungen der Speicherlogik (da es verhindert, dass Inhalte von einem Benutzer oder einer Anwendung dauerhaft gelöscht werden). Es kann jedoch Szenarien geben, in denen ein Benutzerpostfach so beschädigt wird, dass es einfacher wäre, die Datenbank auf einen Zeitpunkt vor der Beschädigung 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.

Wenn Sie verzögerte Kopien verwenden, beachten Sie die folgenden Konsequenzen für deren Verwendung:

• 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 Wiedergabe-Verzögerungszeit hat eine Standardeinstellung von null Tagen und 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 mehrere Stunden dauern, weil:

  • Die Anzahl der Protokolldateien, die wiedergegeben werden sollen.
  • Die Geschwindigkeit, mit der Ihre Hardware sie 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 Verwendung mehrerer verzögerter Kopien oder die Verwendung eines redundanten Arrays unabhängiger Datenträger (RAID), um eine einzelne verzögerte Kopie zu schützen, wenn Sie nicht über mehrere verzögerte Kopien verfügen. 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 nicht mit dem ESE-Feature zum Wiederherstellen einzelner Seiten gepatcht werden. Wenn bei einer verzögerten Kopie eine Datenbankseitenbeschädigung auftritt (z. B. ein -1018-Fehler), muss für die Kopie ein erneutes Seeding durchgeführt werden. Beim erneuten Seeding geht der verzögerte Aspekt der Kopie verloren.

Wenn die Datenbank alle Protokolldateien wiedergeben und die Datenbankkopie auf dem neuesten Stand halten soll, ist das Aktivieren und Wiederherstellen einer verzögerten Postfachdatenbankkopie ein einfacher Prozess. Wenn Sie Protokolldateien bis zu einem bestimmten Zeitpunkt wiedergeben möchten, ist der Vorgang schwieriger, da Sie Protokolldateien manuell bearbeiten und Exchange Server 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

Die Abbruchverzögerungszeit ist die Eigenschaft einer Postfachdatenbankkopie, die die Zeit in Minuten angibt, die die Protokolllöschung für die Datenbankkopie verzögern soll, nachdem die Protokolldatei in der Datenbankkopie wiedergegeben wurde. Der Zeitgeber für die Abschneideverzögerung startet, wenn eine Protokolldatei für die passive Kopie repliziert, erfolgreich überprüft und erfolgreich in der Kopie der Datenbank wiedergegeben wurde. Durch die Verzögerung beim Abschneiden von Protokolldateien von der Datenbankkopie haben Sie die Möglichkeit, eine Wiederherstellung nach Fehlern durchzuführen, die die Protokolldateien für die aktive Kopie der Datenbank betreffen.

Datenbankkopien und Abschneiden der Protokolldateien

Das Abschneiden von Protokollen funktioniert in Exchange 2016 und Exchange 2019 genauso wie in Exchange 2010. Das Abschneideverhalten wird durch die Einstellungen für die Wiedergabe- und Abschneideverzögerung der Kopie bestimmt.

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 wurde erfolgreich gesichert, oder die Umlaufprotokollierung wurde aktiviert.
• 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 haben die Protokolldatei überprüft.
• Alle anderen Kopien (mit Ausnahme von verzögerten Kopien) haben die Protokolldatei erneut abgespielt.

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 wird auf der aktiven Kopie abgeschnitten.

In Exchange Server 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. Nach Abschluss der geplanten Wartung können Sie die passive Datenbankkopie wieder hinzufügen.

Exchange Server verfügt jetzt über ein Feature namens loses Abschneiden, das standardmäßig deaktiviert ist. Bei normalen Vorgängen werden in jeder Datenbankkopie Protokolle aufbewahrt, die an andere Datenbankkopien gesendet werden müssen, bis alle Kopien einer Datenbank Folgendes bestätigen:

• Sie spielten die Protokolldateien (passive Kopien) erneut ab.
• Sie haben die Protokolldateien (verzögerte Kopien) erhalten.

Dieses Verhalten ist das Standardverhalten beim Abschneiden des Protokolls. 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 die betreffende Datenbankkopie über einen längeren Zeitraum hinweg offline bleibt, kann dies dazu führen, dass die anderen Datenbankkopien nicht mehr über ausreichend Speicherplatz verfügen.

Das Abbruchverhalten ist anders, wenn die lose Trunkierung und die zirkuläre Protokollierung aktiviert sind. 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.

• Wenn bei einer passiven Kopie der Speicherplatz knapp wird, werden die Protokolldateien unabhängig mithilfe der konfigurierten Parameter abgeschnitten, die weiter unten in der Tabelle mit dem Registrierungswert beschrieben werden. 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 die Offlinedatenbank wieder online geschaltet wird, werden die fehlenden Protokolldateien aus den anderen fehlerfreien Kopien gelöscht, und ihr Status für Datenbankkopien lautet "FailedAndSuspended". Wenn in diesem Fall Autoreseed konfiguriert ist, wird das Seeding für die betroffene Kopie automatisch erneut durchgeführt. Wenn AutoReseed nicht konfiguriert ist, muss die Datenbankkopie von einem Administrator manuell mit Seeding versehen werden.

Wenn die Zirkelprotokollierung deaktiviert ist, berücksichtigt die lose Trunkierung alle Sicherungskopien, die erstellt wurden. Beim losen Abschneiden werden keine Protokolldateien entfernt, die nicht gesichert wurden.

Die Trunkierung ist ein empfohlenes Feature für die bevorzugte Architektur, bei der keine Sicherungen verwendet werden und die Zirkelprotokollierung aktiviert ist.

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 Festplattenspeicher 204.800 MB (200 GB), und die Anzahl der zu speichernden Protokolle beträgt 100.000 (100 GB) für passive Kopien sowie 100.000 (100 GB) für aktive Kopien.

Zum Aktivieren der Funktion zum ungenauen Abschneiden und Konfigurieren der zugehörigen Parameter muss die Windows-Registrierung auf jedem DAG-Mitglied bearbeitet werden. Es gibt drei Registrierungswerte, die konfiguriert werden können und alle unter „HKLM\Software\Microsoft\ExchangeServer\v15\BackupInformation" gespeichert werden. 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:

Bei Verwendung des Registrierungswerts LooseTruncation_MinLogsToProtect ist das Verhalten für aktive und passive Datenbankkopien unterschiedlich

• Aktiv: Die Anzahl der zusätzlichen Protokolle, die vor den von den geschützten passiven Kopien erforderlichen Protokollen aufbewahrt werden, und der erforderliche Bereich der aktiven Kopie.
• Passiv: Die Anzahl der Protokolle, die aus dem letzten verfügbaren Protokoll beibehalten werden. Ein Zehntel dieser Zahl wird auch verwendet, um Protokolle vor dem erforderlichen Bereich dieser passiven Kopie zu verwalten.

Die beiden Grenzwerte sollen sicherstellen, dass verzögerte Datenbankkopien nicht zu viel Speicherplatz beanspruchen, da ihr erforderlicher Bereich normalerweise sehr groß ist.

Datenbankaktivierungsrichtlinie

Es gibt Szenarien, in denen Sie möglicherweise eine Postfachdatenbankkopie erstellen und verhindern möchten, dass das System diese Kopie automatisch aktiviert. Beispielsweise gilt nach einem Fehler:

• 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.

In jedem der vorangehenden Szenarien verfügen Sie über Datenbankkopien, die nicht automatisch vom System aktiviert werden sollen. 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 für die Aktivierung gesperrte Kopien manuell aktivieren.

Sie können den Parameter DatabaseCopyAutoActivationPolicy auf Blocked festlegen für:

• Der gesamte Server mithilfe des Cmdlets Set-MailboxServer.
• Eine einzelne Datenbankkopie mithilfe des Cmdlets 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 Postfachdatenbank mit hoher Auslastung und hoher Protokollgenerierungsrate besteht ein größeres Risiko von Datenverlust, wenn die Replikation in die passiven Datenbankkopien nicht mit der Protokollgenerierung Schritt halten kann. Ein Szenario, in dem eine hohe Protokollgenerierungsrate auftreten kann, sind Postfachverschiebungen. Exchange Server enthält eine Datengarantie-API, die von Diensten wie dem Exchange-Postfachreplikationsdienst (Exchange Mailbox Replication Service, MRS) verwendet wird, um die Integrität der Datenbankkopierarchitektur basierend auf dem Wert des DataMoveReplicationConstraint-Parameters zu überprüfen, der vom System oder einem Administrator festgelegt wurde. Diese Datengarantie-API kann für folgende Aufgaben verwendet werden:

• Überprüfen der Replikationsintegrität: Bestätigt, dass die erforderliche Anzahl von Datenbankkopien verfügbar ist.

• Replikationsleerung prüfen: Bestätigt, dass die erforderlichen Protokolldateien gegen die erforderliche Anzahl von Datenbankkopien wiedergegeben werden.

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: Dies 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.

In allen Szenarien muss die passive Datenbankkopie die folgenden Bedingungen erfüllen:

• Fehlerfreier Status.

• Wiedergabewarteschlange mit einer Dauer von 10 Minuten des Wiedergabeverzögerungszeitraums.

• Länge der Kopiewarteschlange von weniger als 10 Protokollen.

• Durchschnittliche Länge der Kopiewarteschlange von weniger als 10 Protokollen. Die durchschnittliche Länge der Kopierwarteschlange wird basierend darauf berechnet, wie oft die Anwendung den Datenbank-Status abgefragt hat.

Ü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. Dies wird überprüft, indem der Zeitstempel der letzten Wiedergabe des Protokolls mit dem des Commit-Zeitstempels des aufrufenden Diensts verglichen wird (in den meisten Fällen ist dies der Zeitstempel der letzten Protokolldatei, die erforderliche Daten enthält) plus zusätzliche fünf Sekunden (für den Umgang mit Stechuhrverzerrungen oder -abweichungen im System). 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.

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. Auf EX3 gibt es beispielsweise 13 Datenbankkopien mit der Aktivierungseinstellung 1, zwei Kopien mit der Aktivierungseinstellung 2, eine Kopie mit der Aktivierungseinstellung 3 und keine Kopie mit der Aktivierungseinstellung 4.

Diese DAG ist also weder hinsichtlich der Anzahl von aktiven Datenbanken, die von jedem DAG-Mitglied gehostet werden, der Anzahl von passiven Datenbanken, die von jedem DAG-Mitglied gehostet werden, oder der Anzahl von Aktivierungseinstellungen der gehosteten Datenbanken ausgeglichen.

Sie können das Skript "RedistributeActiveDatabases.ps1" verwenden, um die aktiven Datenbankkopien innerhalb einer DAG auszugleichen. Das Skript verschiebt Datenbanken zwischen ihren Kopien, um die Anzahl von eingebundenen Datenbanken auf jedem Server in einer DAG auszugleichen. Falls erforderlich, versucht das Skript auch einen Ausgleich aktiver Datenbanken an den Standorten durchzuführen.

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.

Nach Ausführen des Skripts mit der ersten Option wird die vorher unausgeglichene DAG ausgeglichen, wie in der folgenden Tabelle gezeigt.

Wie in der vorherigen Tabelle gezeigt, ist diese DAG jetzt bezüglich der Anzahl aktiver und passiver Datenbanken auf jedem Server und der Aktivierungseinstellungen auf den Servern ausgeglichen.

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

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

Sie können eine Vielzahl von Informationen anzeigen, einschließlich der Länge der Kopierwarteschlange, der Länge der Wiedergabewarteschlange, des Status und des Inhaltsindexstatus, indem Sie die Details einer Datenbankkopie in der Exchange-Verwaltungskonsole untersuchen. Sie können auch das Cmdlet Get-MailboxDatabaseCopyStatus in der Exchange-Verwaltungsshell 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 des EAC oder mithilfe des Remove-MailboxDatabaseCopy -Cmdlets in der Exchange-Verwaltungsshell 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 Prozess wird als Datenbankswitchover 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 ausführen, können Sie die Wahleinstellung für die Datenbankeinbindung für den neuen Postfachdatenbankmaster optional außer Kraft setzen.

Sie können schnell erkennen, welcher Postfachserver der aktuelle Postfachdatenbankmaster ist, indem Sie die rechte Spalte auf der Registerkarte Datenbankkopien im EAC überprüfen. Ein Switchover kann über den Link Aktivieren im EAC oder über das Move-ActiveMailboxDatabase -Cmdlet in der Exchange-Verwaltungsshell ausgeführt werden.

Bevor eine passive Kopie aktiviert wird, werden mehrere interne Prüfungen durchgeführt. In einigen Fällen wird der Switchover der Datenbank blockiert oder abgebrochen. In anderen Fällen können Sie die Cmdlets für verwenden, um einige Prüfungen zu verschieben oder zu überspringen.

• 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. Mithilfe dieses Parameters können Sie die aktive Kopie in eine Datenbankkopie mit einem fehlerhaften Status 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 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. Die Verwendung dieses Parameters führt dazu, dass der Seedingvorgang abgebrochen wird und als fehlgeschlagen gilt.

• 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. Wenn die Werte für die Warteschlangenlänge nicht den konfigurierten Kriterien entsprechen oder die Datenbank derzeit als Seedingquelle verwendet wird, wird der Switchover blockiert. 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 und Sie diesen Parameter verwenden, um die Katalogintegritätsprüfung zu überspringen und die Datenbankkopie zu aktivieren, müssen Sie den Suchkatalog erneut durchforsten oder starten.

Wenn Sie einen Datenbankswitchover ausführen, haben Sie auch die Möglichkeit, die Wahleinstellungen für die Einbindung außer Kraft zu setzen, die für den Server konfiguriert wurden, der den Host für die zu aktivierende passive Datenbankkopie darstellt. Die Verwendung des MountDialOverride-Parameters des Move-ActiveMailboxDatabase-Cmdlets weist den Zielserver an, seine eigenen Einbindungsreglereinstellungen zu überschreiben und die durch den Parameter MountDialOverride angegebenen Einstellungen zu verwenden.

Genaue Anweisungen zum Ausführen eines Switchovers für eine Datenbankkopie finden Sie unter Aktivieren einer Kopie einer Postfachdatenbank.