Bei einem eigenständigen Exchange Server reicht es nicht aus, die Geschäftskontinuität zu gewährleisten. Für die Anforderungen an Failover und Business Continuity können Sie Microsofts Database Availability Groups (DAG) verwenden, um sicherzustellen, dass Ihr Exchange Server weiterläuft, wenn eine Instanz ausfällt. Damit dies funktioniert, benötigen Sie zwei oder mehr Server, um eine DAG mit Microsoft Exchange Server Standard oder Enterprise Edition zu erreichen. Die Entscheidung für die Standard- oder Enterprise-Edition hängt ganz von der Konzeption und dem Volumen Ihrer Postfächer ab.
Wenn Sie nicht mehr als fünf Mailbox-Datenbanken benötigen, können Sie sich für die Standard-Edition entscheiden. Was die Lizenzierung angeht, so müssen Sie Exchange Server Standard/Enterprise für jeden Server kaufen. Die Benutzerlizenzen für den Client-Zugriff (CALs) müssen Sie nur einmal erwerben.
Eine typische Datenbankverfügbarkeitsgruppe (DAG) mit zwei Exchange-Servern und einem File Share Witness-Server, die über ein Quorum und eine Abstimmungsmehrheit verfügt, ist unten abgebildet.
Wenn Sie Datenbankverfügbarkeitsgruppen (DAG) erstellen, haben Sie eine Kopie einer Datenbank auf einem Server und eine passive Kopie auf einem anderen Server. Es wird also immer auf die aktive Kopie zugegriffen und die andere Datenbank repliziert von ihr.
In der Abbildung unten sehen Sie, dass es zwei Datenbanken gibt, wobei sich die aktive Kopie von DB1 auf EX01 Server und die passive Kopie auf EX02 Server befindet. Und die aktive Kopie von DB2 befindet sich auf EX02 Server und die passive Kopie auf EX01 Server.
Wenn Sie eine neue Postfachdatenbank zu einer Datenbankverfügbarkeitsgruppe (DAG) hinzufügen, müssen Sie zunächst eine Kopie auf den zweiten Server (in unserem Beispiel EX02) erstellen. Nachdem die vollständige Kopie, die als erster Seed bezeichnet wird, abgeschlossen ist, fährt die Datenbankverfügbarkeitsgruppe (DAG) fort, alle Änderungen zu replizieren. Sie können dies auch tun, indem Sie eine Kopie der Datenbank erstellen und diese auf den sekundären Server kopieren. Alles hängt von der Größe und Geschwindigkeit des Netzwerks zwischen den beiden Knoten ab.
Manchmal müssen Sie aufgrund von Hardware- oder Softwareproblemen die Datenbank neu einrichten. Dies könnte auf beschädigte Informationen in der Datenbankkopie zurückzuführen sein oder auf einen Fehler in der Datenbank, der die Kopie für die Database Availability Group (DAG) unbrauchbar machte.
Während des Seedings kann ein Problem mit der passiven Datenbank auftreten und das Seeding wird mit der Fehlermeldung “Mailbox Database Copy Failed or Suspended” abgebrochen. Nach der Untersuchung finden Sie die folgende Meldung in der Ereignisanzeige.
MSExchangeRepl Ereignis-ID: 4113
Datenbankredundanz-Zustandsprüfung fehlgeschlagen. Datenbank-Kopie: DB01 Redundanzanzahl:1
Fehler: Die Passivkopie ‘DB01\EX02’ ist nicht in einem guten Zustand. Status: FailedAndSuspended
Um mit der Fehlerbehebung zu beginnen, müssen Sie zunächst den Status der Kopie von der Exchange Management Shell (EMS) mit dem PowerShell-Cmdlet – Get-MailboxDatabaseCopyStatus – abrufen.
Um die Ursache des Problems zu verstehen, können Sie den Exchange Best Practice Analyzer gegen die Server einsetzen. Führen Sie in der Exchange Management Shell (EMS) die Funktionen Test-ServiceHealth und Test-ReplicationHealth aus. Dadurch erhalten Sie die Information, dass alle benötigten Dienste ausgeführt werden. Natürlich können Sie auch einen Selbsttest auf den Exchange-Servern durchführen.
Versuchen wir nun, die Datenbank zu reparieren, indem wir die Kopie zwischen der aktiven und der passiven Datenbank aussetzen. Dies kann mit dem Befehl Suspend-MailboxDatabaseCopy erfolgen.
Suspend-MailboxDatabaseCopy -Identity “DB01\EX01”
Hier können Sie der Sache auf den Grund gehen. Sie müssen die Datenbank neu säen. Dazu müssen Sie zunächst alle Kopien der Datenbank löschen. Sie können das PowerShell-Cmdlet Update-MailboxDatabaseCopy mit der Option -DeleteExistingFiles verwenden, um das Setup zu bereinigen und die Kopien zu löschen. Ein Beispiel für den Befehl ist unten angegeben:
Update-MailboxDatabaseCopy -Identity “DB01\EX01” -DeleteExistingFiles
Dadurch wird die Datenbank von der aktiven auf die passive Kopie umgesucht.
Vor der erneuten Aussaat sind einige Dinge zu beachten:
- Abhängig von der Größe der Datenbank, der Leistung der Server und der Netzwerkgeschwindigkeit zwischen den Knoten kann der Prozess eine beträchtliche Zeitspanne in Anspruch nehmen.
- Wenn Sie mehr als zwei Server haben, übernimmt der PowerShell-Befehl die aktive Kopie der Datenbank. Sie können nicht wählen, von wo aus Sie die Kopie erneut einspeisen.
- Es gibt einen Größenunterschied zwischen der aktiven und der passiven Kopie, da die Kopie die Größe der Datenbank zusammen mit der zusätzlichen Transaktionsprotokolldatei und dem Inhaltsindex hat.
Alternativ können Sie die Datenbank über das Exchange Admin Center (EAC) neu bestücken.
Hierfür,
- Klicken Sie auf den Abschnitt Server und auf den Knoten Datenbank.
- Wählen Sie die Datenbank aus, die aktualisiert werden soll, und klicken Sie auf die Schaltfläche Aktualisieren, um den Vorgang zu starten.
- Wählen Sie die Quelle der aktiven Datenbank und das Ziel.
Schlussfolgerung
Der obige Prozess kann Ihnen helfen, den Fehler “Mailbox-Datenbankkopie fehlgeschlagen und ausgesetzt” zu beheben. Aber was ist zu tun, wenn das Problem wieder auftaucht? Was passiert, wenn die aktive Kopie beschädigt ist und Sie die Daten aus der Kopie wiederherstellen müssen? Oder was passiert, wenn die aktive und die passive Kopie beide beschädigt sind?
Sie können sich auf ein Drittanbieter-Tool zur Wiederherstellung von Exchange-Datenbanken verlassen, das Sie aus solchen heiklen Situationen befreien kann. Stellar Repair for Exchange ist eine solche Anwendung, die jede Art von Exchange-Datenbank öffnen kann, egal ob sie gesund ist oder nicht, und die Daten in PST und andere Formate wiederherstellen kann. Sie können auch direkt in eine neue Exchange-Postfachdatenbank oder in einen Office 365-Mieter exportieren.
Was this article helpful?
