Verfügbarkeit in Exchange verbessern und DAGs wiederherstellen Mit Tools und Bordmitteln lokale Exchange-Server reparieren
Anbieter zum Thema
Fallen einzelne Exchange-Server aus, spielt die Zeit der Wiederherstellung eine wesentliche Rolle. Deshalb müssen in erster Linie die Daten in den Postfachdatenbanken schnell wiederherstellbar sein – aber auch die Server selbst sollten nicht zum Recovery-Bremsklotz werden. Der Beitrag zeigt die Möglichkeiten.

Datenbankverfügbarkeitsgruppen (Database Availability Groups, DAG) sind ein Kernelement für die Hochverfügbarkeit von Exchange-Servern im lokalen Rechenzentrum. Das gilt für Exchange Server 2016, Exchange Server 2019 und hochwahrscheinlich auch für den Nachfolger, der in 2025 erscheinen soll.
Fällt ein DAG-Mitglied aus, müssen sich Administratoren daran machen, die Datenbanken wiederherzustellen. Hierfür kommt entweder ein noch vorhandener Server zum Einsatz, oder das DAG-Mitglied wird neu installiert und danach in die vorhandene Umgebung wiederhergestellt. DAGs lassen sich in Exchange 2016/2019 einfacher einrichten. So müssen zum Beispiel keine IP-Adressen mehr für diese Gruppen reserviert und konfiguriert werden.
Bei der Wiederherstellung von DAGs und Mitgliedern einer DAG spielen auch die Exchange-Dienste eine wichtige Rolle. Der Dienst „Microsoft Exchange DAG-Verwaltung“ steuert die Verwaltung von Postfachservern und die Zusammenarbeit mit Datenbankverfügbarkeitsgruppen. Der Dienst muss auf Postfachservern gestartet sein. Funktioniert er nicht, dann ist auch die DAG gestört.
Lizenzen bei der Wiederherstellung von DAGs beachten
Nutzen Sie Datenbankverfügbarkeitsgruppen (DAGs), dürfen diese 16 Mitglieder umfassen. Beim Einsatz der Standard-Edition von Exchange 2016/2019 darf jeder Server aber nur maximal fünf aktive oder passive Datenbankkopien bereitstellen. Wird die Enterprise-Edition eingesetzt, lassen sich auch hier bis zu 100 Datenbanken nutzen. Das spielt bei einem Wiederherstellungsvorgang eine wichtige Rolle.
Wiederherstellung von DAGs und DAG-Mitgliedern vorbereiten
Über den Menüpunkt „Allgemein“ ist in den Eigenschaften von Datenbanken im Exchange Admin Center der Pfad und der Name der Datenbank zu sehen. Haben Unternehmen Datenbankverfügbarkeitsgruppen im Einsatz, werden im Bereich „Server, die eine Kopie dieser Datenbank hosten“ die Server mit Kopien der Datenbank angezeigt. Das spielt bei der Wiederherstellung eine wesentliche Rolle.
Auch beim Einsatz von öffentlichen Ordnern sind DAGs wichtig. Selbst wenn auf einem Exchange-Server kein Replikat eines öffentlichen Ordners liegt, werden Benutzern, deren Postfächer auf diesem Exchange-Server liegen, dennoch die öffentlichen Ordner angezeigt und sie können diese nutzen. Die Replikation erfolgt in Exchange 2019 über Datenbankverfügbarkeitsgruppen, genau wie bei Postfachdatenbanken.
Bei der Wiederherstellung von DAGs ist auch der Virenschutz auf dem Server wichtig. Hier sollte darauf geachtet werden, dass Systemverzeichnisse nicht durch einen Virenscanner überprüft werden, da ansonsten die Leistung deutlich vermindert wird. Bei der Wiederherstellung eines DAG-Mitglieds sind die Verzeichnisse relevant, da oft der Malwarescanner schon installiert ist und die Verzeichnisse in der Konfiguration herausgenommen werden müssen. Auf Servern, die Mitglied einer Datenbankverfügbarkeitsgruppe sind, sollten beim Virenscanner die folgenden Ordner am besten ausgeschlossen werden:
%WinDir%\Cluster
%SystemDrive%\DAGFileShareWitnesses\<DAGFQDN>
Bei Ausfall eines DAG-Mitglieds das Active Directory bereinigen
Fällt ein DAG-Mitglied aus, sollten Administratoren zunächst das Active Directory bereinigen, um sicherzustellen, dass bei einer Wiederherstellung keine unvorhersehbaren Fehler auftreten. Im ersten Schritt muss dazu sichergestellt sein, dass keine Datenbankkopie mehr auf den ausgefallenen Server zeigt. Das geht am einfachsten in der Exchange Management Shell:
Get-MailboxDatabaseCopyStatus -Server <Name des ausgefallenen Servers> | Remove-MailboxDatabaseCopy -Confirm:$False
Anschließend kann der Server von der DAG entfernt werden:
Remove-DatabaseAvailabilityGroupServer -Identity <Name der DAG> -MailboxServer <Ausgefallener Server> -ConfigurationOnly
An dieser Stelle ist es auch sinnvoll, den Server komplett aus dem Cluster zu entfernen:
Get-ClusterNode <failedservername> | Remove-ClusterNode
DAG-Mitglied wiederherstellen
Im nächsten Schritt kann ein neuer Server bereitgestellt oder der vorhandene Server neu installiert werden. Hier kann der gleiche Name zum Einsatz kommen, wie vor dem Ausfall. Nach der Installation des Betriebssystems und dem Beitritt des Servers zur Domäne sollten alle verfügbaren Updates installiert werden. In der Exchange Management Shell können mit „Get-ExchangeServer“ die notwendigen Daten ausgelesen werden, unter anderem vom Parameter „AdminDisplayVersion“. Es muss sichergestellt sein, dass alle Exchange-Server die gleiche Version nutzen. Die Installation des neuen Servers erfolgt danach mit:
setup /m:recoverserver /iacceptexchangeserverlicenseterms
Über diese Option reparieren Admins eine Exchange-Installation direkt auf dem Server, wenn Exchange nicht mehr ordnungsgemäß funktioniert. Während dieses Vorgangs ruft der Server auch Daten ab, die in Active Directory hinterlegt sind. Nach der erfolgreichen Installation kann der Server wieder in die DAG integriert werden:
Add-DatabaseAvailabilityGroupServer -Identity <DAG> -MailboxServer <Name des Servers>
Danach müssen die Datenbanken wieder auf den neuen Server repliziert werden. Das erfolgt entweder im Exchange Admin Center oder in der Exchange Management Shell zum Beispiel mit folgendem Befehl:
Add-MailboxDatabaseCopy -Identity DBX01 -MailboxServer EX02
Dieser Befehl muss für jede zu replizierende Datenbank durchgeführt werden. Danach sollte der Informationsspeicherdienst neu gestartet werden. Die Datenbanken werden danach auf den neu erstellten Server übertragen. Den Replikationsstatus können Admins mit dem Befehl Get-MailboxDatabaseCopyStatus überprüfen.
Probleme bei der Wiederherstellung von Datenbanken lösen: Stellar Repair for Exchange
Die Datenbanken sollten auf dem Server jetzt wieder problemlos funktionieren. Jedoch kann es bei diesem Reparatur-Vorgang durchaus passieren, dass Exchange-Datenbanken beschädigt werden. Das resultiert darin, dass sich die Datenbank in der DAG nicht starten lässt. In diesem Fall ist eine schnelle Problemlösung notwendig. Sinnvoll sind an dieser Stelle Tools wie bspw. Stellar Repair for Exchange. Das Tool kann kostenlos heruntergeladen werden und bei Problemen Datenbanken in Exchange reparieren. Vor allem korrupte EDB-Dateien können ein Problem darstellen. Stellar Repair for Exchange kann die Datenbanken in diesem Fall so reparieren, dass sie auch in einer DAG wieder problemlos funktionieren. Parallel dazu kann das Tool dabei helfen, Daten zu exportieren oder zu Microsoft 365 zu migrieren.
Für die Verwendung des Tools ist keine Installation auf dem Exchange-Server notwendig, die Datenbanken können auch auf Arbeitsstationen repariert werden. Stellar Repair for Exchange benötigt nur die EDB-Datei, die hierfür problemlos auf einen anderen Rechner kopiert werden kann. Schon die Testversion ist in der Lage, festzustellen, ob Datenbanken noch so funktionsfähig sind, dass eine Datenwiederherstellung möglich ist. Eine Reparatur kann dann die kostenpflichtige Version von Stellar Repair for Exchange durchführen.
Ausfall von DAG-Mitgliedern: Serverswitchover durchführen
Mit einem Serverswitchover können Admins die aktive Datenbank auf Exchange-Servern auf ein anderes DAG-Mitglied verschieben. Dazu wird entweder die Exchange Management Shell oder das Exchange Admin Center verwendet. Im Exchange Admin Center sind die Optionen bei „Server“ zu finden. Zunächst erfolgt die Auswahl des gewünschten Postfachservers, auf dem aktuell die produktiven Datenbanken gespeichert sind. Die Option „Serverswitchover“ startet den Vorgang.
Die Server, auf denen die Postfachdatenbankkopien aktiviert sind, die also die produktiven Datenbanken bereitstellen, müssen Mitglied in derselben Datenbankverfügbarkeits-Gruppe sein.
Anschließend kann Exchange entscheiden, welche Postfachdatenbankkopien auf den verschiedenen Servern aktiv geschaltet werden, oder Admins können manuell einen Zielserver auswählen, auf dem Exchange die Postfachdatenbankkopien zukünftig als produktive Datenbanken einsetzt.
Der Vorgang kann auch in der Exchange Management Shell durchgeführt werden:
Move-ActiveMailboxDatabase -Server <Quellserver> -ActivateOnServer <Zielserver>
Switchover von ganzen Rechenzentren
Bei Ausfall kompletter Rechenzentren, können Admins die DAG-Mitglieder dieses Rechenzentrums auf einmal deaktivieren und die aktiven Datenbanken auf die Server in einem anderen Rechenzentrum übertragen. Dazu kann für Datenbankverfügbarkeits-Gruppen (DAG) ein Modus für Rechenzentren aktiviert werden. Die Option ist sinnvoll, wenn größere DAGs im Einsatz sind und diese über verschiedene Active-Directory-Standorte verteilt sind. Der Modus ist standardmäßig deaktiviert.
Der Modus sollte nur für Datenbankgruppen mit mehr als drei Mitgliedern aktiviert werden, die über mehrere Rechenzentren verteilt sind. Den Aktivierungsmodus für Rechenzentren finden Admins in der Exchange Management Shell mit dem Cmdlet "Set-DatabaseAvailabilityGroup". Ein Beispiel für den Befehl lautet:
Set-DatabaseAvailabilityGroup -Identity DAG1 -DatacenterActivationMode DagOnly
Die DAG-Mitglieder im primären Rechezntrum müssen als beendet gekennzeichnet sein, damit die Datenbanken nicht versehentlich bereitgestellt werden. Dazu wird das Cmdlet Stop-DatabaseAvailabilityGroup und die Option ActiveDirectorySite verwendert. Das Cmdlet muss auf allen Servern im zentralen Rechenzentrum ausgeführt werden.
Im zweiten Rechenzentrum, dem Standby-Zentrum, muss herausgefunden werden, welche Server des zentralen Rechenzentrums beendet wurden. Dazu wird ebenfalls das Cmdlet Stop-DatabaseAvailabilityGroup mit den Optionen ConfigurationOnly und ActiveDirectorySite mit dem Namen des Active Directory-Standorts im ausgefallenen zentralen Rechenzentrum verwendet.
Für DAG-Mitglieder im zentralen Rechenzentrum müssen Admins Cluster der Datenbankverfügbarkeits-Gruppe entfernen, wenn die Bereinigung nicht korrekt funktioniert:
Net stop clussvc
Cluster <DAG> node <DAG-Mitglied> /forcecleanup
Die Mitglieder der Datenbankverfügbarkeits-Gruppe im zweiten Rechenzentrum müssen neu gestartet werden. Jedes Mitglied der DAG im zweiten Datencenter muss angehalten werden:
Net stop clussvc
Auf einem DAG-Mitglied im zweiten Rechenzentrum ist dazu der folgende Befehl notwendig, um das Quorum, also die Steuerung des DAG-Clusters, zu übernehmen:
Net start clussvc /forcequorum
Mitglieder zu einer DAG hinzufügen, entfernen und reparieren
Jeder Postfachserver kann nur in einer Datenbankverfügbarkeitsgruppe Mitglied sein. Nur Datenbanken auf Postfachservern, die Mitglied einer DAG sind, lassen sich durch diese DAG auch absichern. Admins können über das gleiche Menü auch Server wieder aus der DAG entfernen. Die Mitgliedschaft wird durch ein eigenes Icon in der Symbolleiste des Exchange Admin Center angezeigt. Neben dem Exchange Admin Center, lassen sich Server auch in der Exchange Management Shell zu einer DAG hinzufügen:
Add-DatabaseAvailabilityGroupServer -Identity <DAG-Name> -MailboxServer <Servername>
(ID:49699780)