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.
Database Availability Groups (DAG) sind ein Kernelement für die Hochverfügbarkeit von Exchange-Servern im lokalen Rechenzentrum. Wir zeigen, wie man Datenbanken umgeht.
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:
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:
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:
Ü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:
Stand: 08.12.2025
Es ist für uns eine Selbstverständlichkeit, dass wir verantwortungsvoll mit Ihren personenbezogenen Daten umgehen. Sofern wir personenbezogene Daten von Ihnen erheben, verarbeiten wir diese unter Beachtung der geltenden Datenschutzvorschriften. Detaillierte Informationen finden Sie in unserer Datenschutzerklärung.
Einwilligung in die Verwendung von Daten zu Werbezwecken
Ich bin damit einverstanden, dass die Vogel IT-Medien GmbH, Max-Josef-Metzger-Straße 21, 86157 Augsburg, einschließlich aller mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen (im weiteren: Vogel Communications Group) meine E-Mail-Adresse für die Zusendung von Newslettern und Werbung nutzt. Auflistungen der jeweils zugehörigen Unternehmen können hier abgerufen werden.
Der Newsletterinhalt erstreckt sich dabei auf Produkte und Dienstleistungen aller zuvor genannten Unternehmen, darunter beispielsweise Fachzeitschriften und Fachbücher, Veranstaltungen und Messen sowie veranstaltungsbezogene Produkte und Dienstleistungen, Print- und Digital-Mediaangebote und Services wie weitere (redaktionelle) Newsletter, Gewinnspiele, Lead-Kampagnen, Marktforschung im Online- und Offline-Bereich, fachspezifische Webportale und E-Learning-Angebote. Wenn auch meine persönliche Telefonnummer erhoben wurde, darf diese für die Unterbreitung von Angeboten der vorgenannten Produkte und Dienstleistungen der vorgenannten Unternehmen und Marktforschung genutzt werden.
Meine Einwilligung umfasst zudem die Verarbeitung meiner E-Mail-Adresse und Telefonnummer für den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern wie z.B. LinkedIN, Google und Meta. Hierfür darf die Vogel Communications Group die genannten Daten gehasht an Werbepartner übermitteln, die diese Daten dann nutzen, um feststellen zu können, ob ich ebenfalls Mitglied auf den besagten Werbepartnerportalen bin. Die Vogel Communications Group nutzt diese Funktion zu Zwecken des Retargeting (Upselling, Crossselling und Kundenbindung), der Generierung von sog. Lookalike Audiences zur Neukundengewinnung und als Ausschlussgrundlage für laufende Werbekampagnen. Weitere Informationen kann ich dem Abschnitt „Datenabgleich zu Marketingzwecken“ in der Datenschutzerklärung entnehmen.
Falls ich im Internet auf Portalen der Vogel Communications Group einschließlich deren mit ihr im Sinne der §§ 15 ff. AktG verbundenen Unternehmen geschützte Inhalte abrufe, muss ich mich mit weiteren Daten für den Zugang zu diesen Inhalten registrieren. Im Gegenzug für diesen gebührenlosen Zugang zu redaktionellen Inhalten dürfen meine Daten im Sinne dieser Einwilligung für die hier genannten Zwecke verwendet werden. Dies gilt nicht für den Datenabgleich zu Marketingzwecken.
Recht auf Widerruf
Mir ist bewusst, dass ich diese Einwilligung jederzeit für die Zukunft widerrufen kann. Durch meinen Widerruf wird die Rechtmäßigkeit der aufgrund meiner Einwilligung bis zum Widerruf erfolgten Verarbeitung nicht berührt. Um meinen Widerruf zu erklären, kann ich als eine Möglichkeit das unter https://contact.vogel.de abrufbare Kontaktformular nutzen. Sofern ich einzelne von mir abonnierte Newsletter nicht mehr erhalten möchte, kann ich darüber hinaus auch den am Ende eines Newsletters eingebundenen Abmeldelink anklicken. Weitere Informationen zu meinem Widerrufsrecht und dessen Ausübung sowie zu den Folgen meines Widerrufs finde ich in der Datenschutzerklärung.
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:
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:
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 clussvcCluster <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: