Verwalten von Datenbankverfügbarkeitsgruppen in Exchange Server

Eine Datenbankverfügbarkeitsgruppe (Database Availability Group, DAG) ist eine Gruppe von bis zu 16 Exchange Postfachservern, die eine automatische Wiederherstellung auf Datenbankebene von einer Datenbank, einem Server oder einem Netzwerkfehler ermöglicht. Für DAGs wird eine fortlaufende Replikation und ein Teil der Windows-Failoverclusteringtechnologien verwendet, um eine hohe Verfügbarkeit und Ausfallsicherheit für Standorte zu gewährleisten. Die Postfachserver in einer DAG überwachen sich gegenseitig auf Fehler. Wenn einer DAG ein Postfachserver hinzugefügt wird, arbeitet dieser Server mit den anderen Servern in der DAG zusammen, um eine automatische Wiederherstellung auf Datenbankebene nach Datenbankfehlern bereitzustellen.

Wenn Sie eine DAG erstellen, ist diese zunächst leer. Wenn Sie der DAG den ersten Server hinzufügen, wird für die DAG automatisch ein Failovercluster erstellt. Darüber hinaus wird die Infrastruktur für die Überwachung der Server auf Netzwerk- oder Serverfehler initiiert. Der Failovercluster-Taktmechanismus und die Clusterdatenbank werden dann zum Verfolgen und Verwalten von Informationen zur DAG verwendet, die sich schnell ändern können, z. B. Datenbankeinbindungsstatus, Replikationsstatus und Standort der letzten Einbindung.

Erstellen von DAGs

Eine DAG kann mit dem Assistenten für neue Datenbankverfügbarkeitsgruppen im Exchange Admin Center (EAC) oder durch Ausführen des Cmdlets "New-DatabaseAvailabilityGroup" in der Exchange Verwaltungsshell erstellt werden. Wenn Sie eine DAG erstellen, geben Sie einen Namen für die DAG, einen optionalen Zeugenserver und Einstellungen für das Zeugenverzeichnis an. Darüber hinaus können Sie der DAG eine oder mehrere IP-Adressen zuweisen, entweder durch Verwenden statischer IP-Adressen oder durch Zulassen der automatischen Zuweisung erforderlicher IP-Adressen zur DAG über DHCP (Dynamic Host Configuration Protocol). Mit dem Parameter DatabaseAvailabilityGroupIpAddresses können Sie der DAG manuell IP-Adressen zuweisen. Wenn Sie diesen Parameter weglassen, versucht die DAG, mithilfe eines DHCP-Servers in Ihrem Netzwerk eine IP-Adresse zu erhalten.

Wenn Sie eine DAG erstellen, die Postfachserver enthält, auf denen Windows Server 2012 R2 ausgeführt wird, haben Sie auch die Möglichkeit, eine DAG ohne cluster administrativen Zugriffspunkt zu erstellen. In dem Fall hat der Cluster kein Clusternamenobjekt (CNO) in Active Directory, und die Clusterkernressourcengruppe enthält weder eine Netzwerknamensressource noch eine IP-Adressenressource.

Genaue Anweisungen zum Erstellen einer DAG finden Sie unter Erstellen einer Datenbankverfügbarkeitsgruppe.

Wenn Sie eine DAG erstellen, werden ein leeres Objekt für die DAG mit dem von Ihnen angegebenen Namen und die Objektklasse msExchMDBAvailabilityGroup in Active Directory erstellt.

DAGs verwenden eine Teilmenge der Windows Failoverclusteringtechnologien in Windows Server 2008 R2 oder höher, z. B. den Clustertakt, Clusternetzwerke und Clusterdatenbanken (zum Speichern von Daten, die sich schnell ändern oder ändern können, z. B. Änderungen des Datenbankstatus von aktiv zu passiv oder umgekehrt oder von der Bereitstellung zum Aufheben der Bereitstellung oder umgekehrt). Daher können Sie DAGs nur auf Exchange Postfachservern erstellen, die in unterstützten Versionen von Windows installiert sind, die Windows Failoverclustering enthalten.

Hinweis

Der erstellte und von der DAG verwendete Failovercluster muss für die DAG bestimmt sein. Der Cluster darf für keine andere Hochverfügbarkeitslösung oder zu einem anderen Zweck verwendet werden. Der Failovercluster darf z. B. nicht dazu verwendet werden, andere Anwendungen oder Dienste zu Clustern zusammenzufassen. Die Verwendung des Failoverclusters, der einer DAG zugrunde liegt, für einen anderen Zweck, wird nicht unterstützt.

DAG-Zeugenserver und -Zeugenverzeichnis

Beim Erstellen einer DAG müssen Sie einen Namen für die DAG angeben, der maximal 15 Zeichen lang und innerhalb der Active Directory-Gesamtstruktur eindeutig ist. Darüber hinaus wird jede DAG mit einem Zeugenserver und einem Zeugenverzeichnis konfiguriert. Der Zeugenserver und sein Verzeichnis werden nur verwendet, wenn eine gerade Anzahl von Mitgliedern in der DAG vorliegt und auch dann nur zu Quorumzwecken. Sie müssen das Zeugenverzeichnis nicht im Voraus erstellen. Exchange erstellt und sichert das Verzeichnis automatisch für Sie auf dem Zeugenserver. Das Zeugenverzeichnis sollte nur für den DAG-Zeugenserver verwendet werden.

Hinweis

In der Datenbankspiegelungstopologie können Sie über einen dritten Server verfügen, der als Zeuge bezeichnet wird. Der Zeugenserver ermöglicht das automatische Failover vom Prinzipal auf den Spiegelserver oder umgekehrt. Im Gegensatz zu Prinzipal- und Spiegelservern wird die Datenbank nicht vom Zeugenserver bedient. Die Rolle des Zeugen besteht darin, zu überprüfen, ob ein bestimmter Partnerserver funktionsfähig ist. Die Unterstützung des automatischen Failovers ist die einzige Funktion für den Zeugenserver und identifiziert, welcher Server die Prinzipalkopie enthält und welcher Server die Spiegelkopie der Datenbank enthält.

Der Zeugenserver muss folgende Anforderungen erfüllen:

  • Der Zeugenserver darf kein Mitglied der DAG sein.

  • Der Zeugenserver muss sich in derselben Active Directory-Gesamtstruktur wie die DAG befinden.

  • Der Zeugenserver muss Windows Server 2008 oder höher ausgeführt werden.

  • Ein einzelner Server kann als Zeuge für mehrere DAGs fungieren. Für jede DAG ist jedoch ein eigenes Zeugenverzeichnis erforderlich.

Unabhängig von dem als Zeugenserver verwendeten Server müssen Sie, wenn die Windows-Firewall auf dem vorgesehenen Zeugenserver aktiviert ist, die Windows-Firewallausnahme für die Datei- und Druckerfreigabe aktivieren. Der Zeugenserver verwendet SMB-Port 445.

Wichtig

Wenn der angegebene Zeugenserver kein Exchange Server 2010 oder höher ist, müssen Sie die Exchange Universelle Sicherheitsgruppe des vertrauenswürdigen Subsystems (Trusted Subsystem Universal Security Group, USG) vor dem Erstellen der DAG der lokalen Gruppe "Administratoren" auf dem Zeugenserver hinzufügen. Diese Sicherheitsrechte sind erforderlich, um sicherzustellen, dass bei Bedarf mithilfe von Exchange ein Verzeichnis und eine Freigabe auf dem Zeugenserver erstellt werden kann.

Weder Zeugenserver noch Zeugenverzeichnis müssen fehlertolerant sein oder eine Form von Redundanz oder hoher Verfügbarkeit verwenden. Es besteht keine Notwendigkeit zur Verwendung eines Dateiclusterservers oder einer anderen Form von Ausfallsicherung für den Zeugenserver. Hierfür gibt es verschiedene Gründe. Bei größeren DAGs (z. B. mit sechs oder mehr Mitgliedern) können mehrere Fehler auftreten, bevor der Zeugenserver benötigt wird. Da eine DAG mit sechs Mitgliedern zwei Wählerfehler tolerieren kann, ohne dass das Quorum verloren geht, müssten drei Wähler ausfallen, bevor der Zeugenserver zur Aufrechterhaltung des Quorums benötigt wird. Wenn es einen Fehler gibt, der sich auf den aktuellen Zeugenserver auswirkt (wenn Sie beispielsweise den Zeugenserver wegen eines Hardwareausfalls verlieren), können Sie zudem mit dem Cmdlet Set-DatabaseAvailabilityGroup einen neuen Zeugenserver und ein neues Zeugenverzeichnis konfigurieren (vorausgesetzt, es besteht ein Quorum).

Hinweis

Sie können auch das Cmdlet Set-DatabaseAvailabilityGroup verwenden, um den Zeugenserver und das Zeugenverzeichnis am ursprünglichen Speicherort zu konfigurieren, wenn der Zeugenserver seinen Speicher verloren oder jemand das Zeugenverzeichnis oder gemeinsame Berechtigungen geändert hat.

Überlegungen zur Platzierung von Zeugenservern

Die Platzierung eines Zeugenservers der DAG hängt von Ihren Geschäftsanforderungen und den für Ihre Organisation verfügbaren Optionen ab. Exchange bietet jetzt Unterstützung für neue DAG-Konfigurationsoptionen, die in Exchange 2010 nicht empfohlen werden oder nicht möglich sind. Diese Optionen beinhalten die Verwendung eines dritten Standorts wie ein drittes Rechenzentrum, eine Filiale oder ein virtuelles Microsoft Azure-Netzwerk.

In der folgenden Tabelle sind allgemeine Empfehlungen zur Platzierung von Zeugenservern für unterschiedliche Bereitstellungsszenarien aufgeführt.

Bereitstellungsszenario Empfehlungen
Einzelner DAG in einem einzelnen Rechenzentrum bereitgestellt Platzieren Sie Zeugenserver im selben Rechenzentrum wie die DAG-Mitglieder.
Einzelne DAG in zwei Rechenzentren bereitgestellt, keine weiteren Standorte verfügbar Platzieren Sie Zeugenserver in einem virtuellen Microsoft Azure-Netzwerk, um das automatisierte Failover von Rechenzentren zu aktivieren.

Platzieren Sie Zeugenserver im primären Rechenzentrum.

Mehrere DAGs in einem einzelnen Rechenzentrum bereitgestellt Platzieren Sie Zeugenserver im selben Rechenzentrum wie die DAG-Mitglieder. Weitere Optionen beinhalten Folgendes:
  • Verwenden desselben Zeugenservers für mehrere DAGs
  • Verwenden eines DAG-Mitglieds als Zeugenserver für eine andere DAG
Mehrere DAGs in zwei Rechenzentren bereitgestellt Platzieren Sie Zeugenserver in einem virtuellen Microsoft Azure-Netzwerk, um das automatisierte Failover von Rechenzentren zu aktivieren.

Platzieren Sie den Zeugenserver in dem Rechenzentrum, das für die einzelnen DAGs als primäres Rechenzentrum angesehen wird. Weitere Optionen beinhalten Folgendes:

  • Verwenden desselben Zeugenservers für mehrere DAGs
  • Verwenden eines DAG-Mitglieds als Zeugenserver für eine andere DAG
Einzelne oder mehrere DAGs in mehr als zwei Rechenzentren bereitgestellt Bei dieser Konfiguration sollte sich der Zeugenserver in dem Rechenzentrum befinden, in dem die Mehrzahl der Quorumstimmen vorhanden sein soll.

Wenn eine DAG in zwei Rechenzentren bereitgestellt wurde, können Sie jetzt einen dritten Speicherort zum Hosten des Zeugenservers verwenden. Wenn Ihre Organisation über einen dritten Standort mit einer Netzwerkinfrastruktur verfügt, die von Netzwerkfehlern isoliert ist, die sich auf die beiden Rechenzentren auswirken, in denen Ihre DAG bereitgestellt wird, können Sie den Zeugenserver der DAG an diesem dritten Speicherort bereitstellen. Dadurch konfigurieren Sie Ihre DAG mit der Möglichkeit, Datenbanken als Reaktion auf ein Fehlerereignis auf Rechenzentrumsebene automatisch auf das andere Rechenzentrum hochzustufen. Wenn Ihre Organisation nur über zwei physische Standorte verfügt, können Sie ein Microsoft Azure virtuelles Netzwerk als dritten Standort verwenden, um Ihren Zeugenserver zu platzieren.

Angeben eines Zeugenservers und Zeugenverzeichnisses bei der DAG-Erstellung

Beim Erstellen einer DAG müssen Sie einen Namen für die DAG angeben. Optional können Sie auch einen Zeugenserver und ein Zeugenverzeichnis angeben.

Beim Erstellen einer DAG sind die folgenden Kombinationen von Optionen und Verhalten verfügbar:

  • Sie können nur einen Namen für die DAG angeben und die Felder " Zeugenserver " und "Zeugenverzeichnis " leer lassen. In diesem Szenario durchsucht der Assistent den lokalen Active Directory-Standort nach einem Clientzugriffsserver, auf dem der Postfachserver nicht installiert ist, und erstellt automatisch das Standardverzeichnis (%SystemDrive%:\DAGFileShareWitnessesDAFGQDN\><) und die Standardfreigabe (<DAGFQDN>) auf diesem Server und verwendet diesen Clientzugriffsserver als Zeugenserver. Betrachten Sie beispielsweise den Zeugenserver CAS3, auf dem das Betriebssystem auf Laufwerk C installiert wurde. Eine DAG mit dem Namen DAG1 in der contoso.com Domäne würde ein Standardzeugenverzeichnis von "C:\DAGFileShareWitnesses\DAG1.contoso.com" verwenden, das als \CAS3\DAG1.contoso.com freigegeben würde.

  • Sie können einen Namen für die DAG, den Zeugenserver, den Sie verwenden möchten, sowie das Verzeichnis, das Sie erstellen und auf dem Zeugenserver freigeben möchten, angeben.

  • Sie können einen Namen für die DAG und den Zeugenserver angeben, den Sie verwenden möchten, und das Feld Zeugenverzeichnis leer lassen. In diesem Szenario erstellt der Assistent das Standardverzeichnis auf dem angegebenen Zeugenserver.

  • Sie können einen Namen für die DAG angeben, das Feld Zeugenserver leer lassen und das Verzeichnis angeben, das Sie erstellen und auf dem Zeugenserver freigeben möchten. In diesem Szenario sucht der Assistent nach einem Clientzugriffsserver, auf dem der Postfachserver nicht installiert ist, erstellt automatisch die angegebene DAG auf dem Server, gibt das Verzeichnis frei und verwendet den Clientzugriffsserver als Zeugenserver.

Eine neu erstellte DAG verwendet zunächst das Knotenmehrheits-Quorummodell. Wird der DAG der zweite Postfachserver hinzugefügt, wird das Quorum automatisch in ein Knoten- und Dateifreigabemehrheits-Quorummodell geändert. Kommt es zu dieser Änderung, beginnt der DAG-Cluster mit der Verwendung des Zeugenservers, um das Quorum aufrechtzuerhalten. Ist das Zeugenverzeichnis nicht vorhanden, wird es von Exchange automatisch erstellt und freigegeben, und die Freigabe wird mit den vollständigen Steuerungsberechtigungen für das CNO-Computerkonto für die DAG ausgestattet.

Hinweis

Die Verwendung einer Dateifreigabe, die zum Namespace eines verteilten Dateisystems gehört, wird nicht unterstützt.

Wenn die Windows-Firewall auf dem Zeugenserver aktiviert wird, bevor die DAG erstellt wurde, kann dies die Erstellung der DAG möglicherweise blockieren. Exchange verwendet die Windows Management Instrumentation (WMI), um das Verzeichnis und die Dateifreigabe auf dem Zeugenserver zu erstellen. Wenn die Windows-Firewall auf dem Zeugenserver aktiviert ist und für WMI keine Firewallausnahmen konfiguriert sind, schlägt das Cmdlet New-DatabaseAvailabilityGroup mit einem Fehler fehl. Wenn Sie einen Zeugenserver, aber kein Zeugenverzeichnis angeben, erhalten Sie die folgende Fehlermeldung.

The task was unable to create the default witness directory on server <Server Name>. Please manually specify a witness directory.

Wenn Sie einen Zeugenserver und ein Zeugenverzeichnis angeben, erhalten Sie die folgende Warnmeldung.

Unable to access file shares on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: The network path was not found.

Wenn die Windows-Firewall auf dem Zeugenserver aktiviert wird, nachdem die DAG erstellt wurde, aber bevor die Server hinzugefügt wurden, kann dies das Hinzufügen oder Entfernen von DAG-Mitgliedern blockieren. Wenn die Windows-Firewall auf dem Zeugenserver aktiviert ist und für WMI keine Firewallausnahmen konfiguriert sind, zeigt das Cmdlet Add-DatabaseAvailabilityGroupServer die folgende Warnmeldung an.

Failed to create file share witness directory 'C:\DAGFileShareWitnesses\DAG_FQDN' on witness server '<ServerName>'. Until this problem is corrected, the database availability group may be more vulnerable to failures. You can use the Set-DatabaseAvailabilityGroup cmdlet to try the operation again. Error: WMI exception occurred on server '<ServerName>': The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)

Führen Sie eine der folgenden Aktionen aus, um die vorangehenden Fehler und Warnungen zu beheben:

  • Erstellen Sie das Zeugenverzeichnis und die Freigabe auf dem Zeugenserver manuell, und weisen Sie dem Clusternamensobjekt für die DAG den Vollzugriff für das Verzeichnis und die Freigabe zu.

  • Aktivieren Sie die WMI-Ausnahme in der Windows-Firewall.

  • Deaktivieren Sie die Windows-Firewall.

DAG-Mitgliedschaft

Nachdem eine DAG erstellt wurde, können Sie der DAG Server hinzufügen oder diese entfernen, indem Sie den Assistenten zum Verwalten von Datenbankverfügbarkeitsgruppen im Exchange Admin Center (EAC) oder die Cmdlets "Add-DatabaseAvailabilityGroupServer" oder "Remove-DatabaseAvailabilityGroupServer" in der Exchange Verwaltungsshell verwenden. Ausführliche Schritte zum Verwalten der DAG-Mitgliedschaft finden Sie unter Verwalten der Datenbankverfügbarkeitsgruppenmitgliedschaft.

Hinweis

Für jeden Postfachserver, der Mitglied einer DAG ist, liegt ein Knoten im zugrunde liegenden Cluster vor, der von der DAG verwendet wird. Deshalb kann jeweils nur ein Postfachserver Mitglied einer DAG sein.

Wenn für den einer DAG hinzugefügten Postfachserver keine Failoverclusteringkomponente installiert ist, wird die Failoverclusteringfunktion mit der Methode installiert, die zum Hinzufügen des Servers verwendet wird (z. B. das Cmdlet Add-DatabaseAvailabilityGroupServer oder der Assistent zum Verwalten einer DAG).

Beim Hinzufügen des ersten Postfachservers zu einer DAG geschieht Folgendes:

  • Die Windows-Failoverclusteringkomponente wird installiert, wenn sie nicht bereits installiert ist.

  • Ein Failovercluster mit dem Namen der DAG wird erstellt. Dieser Failovercluster wird ausschließlich von der DAG verwendet, und der Cluster muss für die DAG bestimmt sein. Die Verwendung des Clusters für einen anderen Zweck wird nicht unterstützt.

  • Ein Clusternamensobjekt wird im Container des Standardcomputers erstellt.

  • Name und IP-Adresse der DAG werden als Datensatz "Host (A)" in DNS (Domain Name System) registriert.

  • Der Server wird dem DAG-Objekt in Active Directory hinzugefügt.

  • Die Clusterdatenbank wird anhand der Informationen in den eingebundenen Datenbanken auf dem hinzugefügten Server aktualisiert.

In einer großen oder mehrere Standorte umfassenden Umgebung, insbesondere mit DAGs, die sich über mehrere Active Directory-Standorte erstrecken, müssen Sie auf den Abschluss der Active Directory-Replikation des DAG-Objekts warten, das das erste DAG-Mitglied enthält. Wenn dieses Active Directory-Objekt nicht in der gesamten Umgebung repliziert wird, kann das Hinzufügen des zweiten Servers zum Erstellen eines neuen Clusters (und eines neuen Clusternetzwerkobjekts) für die DAG führen. Der Grund hierfür ist, dass das DAG-Objekt aus Sicht des zweiten hinzugefügten Mitglieds leer zu sein scheint. Dies führt dazu, dass das Cmdlet Add-DatabaseAvailabilityGroupServer einen Cluster und ein Clusternamensobjekt für die DAG erstellt, obwohl diese Objekte bereits vorhanden sind. Wenn Sie überprüfen möchten, ob das DAG-Objekt, das den ersten DAG-Server enthält, repliziert wurde, verwenden Sie das Cmdlet Get-DatabaseAvailabilityGroup auf dem zweiten Server. Dieser wurde hinzugefügt, um sicherzustellen, dass der erste von Ihnen hinzugefügte Server als Mitglied der DAG aufgelistet wird.

Beim Hinzufügen des zweiten sowie weiterer Server zur DAG geschieht Folgendes:

  • Der Server wird mit dem Windows-Failovercluster für die DAG verknüpft.

  • Das Quorum-Modell wird automatisch angepasst:

    • Für DAGs mit einer ungeraden Mitgliederzahl wird ein Knotenmehrheits-Quorummodell verwendet.

    • Für DAGs mit einer geraden Mitgliederzahl wird ein Knoten- und Dateifreigabemehrheits-Quorummodell verwendet.

  • Zeugenverzeichnis und -freigabe werden bei Bedarf automatisch von Exchange erstellt.

  • Der Server wird dem DAG-Objekt in Active Directory hinzugefügt.

  • Die Clusterdatenbank wird anhand von Informationen über eingebundene Datenbanken aktualisiert.

Hinweis

Die Änderung des Quorummodells sollte automatisch erfolgen. Wird das Quorummodell jedoch nicht automatisch in das richtige Modell geändert, können Sie das Cmdlet Set-DatabaseAvailabilityGroup nur mit dem Parameter Identity ausführen, um die Quorumeinstellungen für die DAG zu korrigieren.

Provisorische Bereitstellung des Clusternamensobjekts für eine DAG

Das Clusternetzwerkobjekt (CNO) ist ein in Active Directory erstelltes Computerkonto und der Namensressource des Clusters zugeordnet. Die Namensressource des Clusters ist an das Clusternetzwerkobjekt gebunden, wobei es sich um ein Kerberos-fähiges Objekt handelt, das als Identität des Clusters dient und den Sicherheitskontext des Clusters bereitstellt. Die Formation des Clusters, der der DAG zugrunde liegt, und des Clusternetzwerkobjekts für diesen Cluster wird durchgeführt, wenn das erste Mitglied zur DAG hinzugefügt wird. Wenn der erste Server zur DAG hinzugefügt wird, kontaktiert Remote-Powershell den Microsoft Exchange-Replikationsdienst auf dem hinzuzufügenden Postfachserver. Der Microsoft Exchange-Replikationsdienst installiert die Failoverclusteringfunktion (sofern diese nicht bereits installiert ist) und beginnt mit der Clustererstellung. Der Microsoft Exchange-Replikationsdienst wird unter dem Sicherheitskontext LOKALES SYSTEM ausgeführt, unter dem auch die Clustererstellung durchgeführt wird.

Achtung

Wenn Ihre DAG-Mitglieder Windows Server 2012 ausführen, müssen Sie das Clusternetzwerkobjekt provisorisch bereitstellen, bevor Sie der DAG den ersten Server hinzufügen. Wenn Ihre DAG-Mitglieder Windows Server 2012 R2 ausführen und Sie eine DAG ohne Cluster-Administratorzugriffspunkt erstellen, wird kein CNO erstellt, und Sie müssen kein CNO für die DAG bereitstellen oder erstellen.

In Umgebungen, in denen die Erstellung von Computerkonten eingeschränkt ist oder in denen Computerkonten in einem anderen Container als dem Container der Standardcomputer erstellt werden, können Sie das Clusternetzwerkobjekt vorab bereitstellen und einrichten. Sie erstellen zuerst ein Computerkonto für das CNO, deaktivieren es, und führen dann einen der folgenden Schritte aus:

  • Zuweisen von Vollzugriff auf das Computerkonto an das Computerkonto des ersten Postfachservers, der der DAG hinzugefügt wird.

  • Zuweisen von Vollzugriff auf das Computerkonto an die universelle Sicherheitsgruppe "Exchange Trusted Subsystem".

Das Zuweisen des Vollzugriffs auf das Computerkonto zum Computerkonto des ersten Postfachservers, den Sie der DAG hinzufügen, stellt sicher, dass der Sicherheitskontext LOKALES SYSTEM in der Lage ist, das vorab bereitgestellte Computerkonto zu verwalten. Das Zuweisen des Vollzugriffs auf das Computerkonto an die universelle Sicherheitsgruppe "Exchange Trusted Subsystem" kann stattdessen verwendet werden, da die universelle Sicherheitsgruppe "Exchange Trusted Subsystem" die Computerkonten aller Exchange-Server in der Domäne enthält.

Genaue Anweisungen zum Vorabbereitstellen und Einrichten des Clusternetzwerkobjekts für eine DAG finden Sie unter Provisorische Bereitstellung des Clusternamenobjekts für eine Database Availability Group.

Entfernen von Servern aus einer DAG

Postfachserver können aus einer DAG entfernt werden, indem Sie den Assistenten zum Verwalten von Datenbankverfügbarkeitsgruppen im EAC oder das Cmdlet "Remove-DatabaseAvailabilityGroupServer" in der Exchange-Verwaltungsshell verwenden. Vor dem Entfernen eines Postfachservers aus einer DAG müssen zunächst alle replizierten Postfachdatenbanken vom Server entfernt werden. Der Versuch, einen Postfachserver mit replizierten Postfachdatenbanken aus einer DAG zu entfernen, schlägt fehl.

In manchen Szenarien müssen Sie einen Postfachserver aus einer DAG entfernen, bevor Sie bestimmte Vorgänge ausführen können. Diese Szenarien umfassen:

  • Ausführen eines Serverwiederherstellungsvorgangs: Wenn ein Postfachserver, der Mitglied einer DAG ist, verloren geht oder anderweitig fehlschlägt und nicht wiederhergestellt werden kann und ersetzt werden muss, können Sie einen Serverwiederherstellungsvorgang mithilfe der Option "Setup /m:RecoverServer " ausführen. Bevor Sie jedoch den Wiederherstellungsvorgang ausführen können, müssen Sie zuerst den Server mithilfe des Cmdlets Remove-DatabaseAvailabilityGroupServer mit dem Parameter ConfigurationOnly aus der DAG entfernen.

  • Entfernen der Datenbankverfügbarkeitsgruppe: Es kann Situationen geben, in denen Sie eine DAG entfernen müssen (z. B. beim Deaktivieren des Replikationsmodus von Drittanbietern). Wenn Sie eine DAG entfernen müssen, müssen Sie zunächst alle Server aus der DAG entfernen. Beim Versuch, eine DAG mit Mitgliedern zu entfernen, tritt ein Fehler auf.

Konfigurieren von DAG-Eigenschaften

Nachdem Der DAG Server hinzugefügt wurden, können Sie die EAC oder die Exchange-Verwaltungsshell verwenden, um die Eigenschaften einer DAG zu konfigurieren, einschließlich des von der DAG verwendeten Zeugenservers und Zeugenverzeichnisses sowie der DER DAG zugewiesenen IP-Adressen.

Zu den konfigurierbaren Eigenschaften gehören folgende:

  • Zeugenserver: Der Name des Servers, auf dem Sie die Dateifreigabe für den Dateifreigabezeugen hosten möchten. Es wird empfohlen, einen Clientzugriffsserver als Zeugenserver anzugeben. Auf diese Weise kann das System die Freigabe ganz nach Bedarf automatisch konfigurieren, absichern und verwenden, und der Messagingadministrator hat jederzeit einen Überblick über die Verfügbarkeit des Zeugenservers.

  • Zeugenverzeichnis: Der Name eines Verzeichnisses, das zum Speichern von Dateifreigabezeugendaten verwendet wird. Dieses Verzeichnis wird automatisch vom System auf dem angegebenen Zeugenserver erstellt.

  • GRUPPEN-IP-Adressen für Datenbankverfügbarkeitsgruppen: Eine oder mehrere IP-Adressen müssen der DAG zugewiesen werden, es sei denn, die DAG-Mitglieder führen Windows Server 2012 R2 aus und Sie erstellen eine DAG ohne IP-Adresse. Andernfalls können die IP-Adressen der DAG mithilfe manuell zugewiesener statischer IP-Adressen konfiguriert werden, oder sie können der DAG über einen DHCP-Server in Ihrer Organisation automatisch zugewiesen werden.

Mit der Exchange-Verwaltungsshell können Sie DAG-Eigenschaften konfigurieren, die im EAC nicht verfügbar sind, z. B. DAG-IP-Adressen, Netzwerkverschlüsselungs- und Komprimierungseinstellungen, Netzwerkermittlung, der für die Replikation verwendete TCP-Port sowie alternative Einstellungen für Zeugenserver und Zeugenverzeichnisse sowie den Aktivierungskoordinationsmodus für Rechenzentren.

Genaue Anweisungen zum Konfigurieren der Eigenschaften von DAGs finden Sie unter Konfigurieren der Eigenschaften einer DAG.

DAG-Netzwerkverschlüsselung

DAGs unterstützen die Verwendung von Verschlüsselung durch die Nutzung der Verschlüsselungsfunktionen des Windows Server-Betriebssystems. DAGs verwenden die Kerberos-Authentifizierung zwischen Exchange-Servern. Die EncryptMessage- und DecryptMessage-APIs von Microsoft Kerberos Security Support Provider (SSP) verarbeiten die Verschlüsselung des DAG-Netzwerkdatenverkehrs. Microsoft Kerberos SSP unterstützt mehrere Verschlüsselungsalgorithmen. (Eine vollständige Liste finden Sie in Abschnitt 3.1.5.2 zum Thema "Verschlüsselungstypen" unter Kerberos-Protokollerweiterungen). Der Kerberos-Authentifizierungshandshake wählt das stärkste Verschlüsselungsprotokoll aus der Liste aus: Im Allgemeinen ist dies AES (Advanced Encryption Standard) mit 256 Bit, möglicherweise mit einem SHA-basierten Nachrichtenauthentifizierungscode (Hash-based Message Authentication Code, HMAC) zur Wahrung der Datenintegrität. Weitere Informationen finden Sie unter HMAC.

Die Netzwerkverschlüsselung ist eine Eigenschaft der DAG, nicht eines DAG-Netzwerks. Sie können die DAG-Netzwerkverschlüsselung mit dem Cmdlet "Set-DatabaseAvailabilityGroup" in der Exchange-Verwaltungsshell konfigurieren. Die möglichen Verschlüsselungseinstellungen für die DAG-Netzwerkkommunikation sind in der folgenden Tabelle aufgelistet.

Einstellung Beschreibung
Deaktiviert Die Netzwerkverschlüsselung wird nicht verwendet.
Aktiviert Die Netzwerkverschlüsselung wird in allen DAG-Netzwerken für Replikation und Seeding verwendet.
InterSubnetOnly Die Netzwerkverschlüsselung wird in DAG-Netzwerken bei der Replikation über verschiedene Subnetze verwendet. Dies ist die Standardeinstellung.
SeedOnly Die Netzwerkverschlüsselung wird in allen DAG-Netzwerken nur für Seeding verwendet.

DAG-Netzwerkkomprimierung

DAGs unterstützen die integrierte Komprimierung. Ist die Komprimierung aktiviert, verwendet die DAG-Netzwerkkommunikation XPRESS, die Microsoft-Implementierung des LZ77-Algorithmus. Es handelt sich um denselben Komprimierungstyp, der in zahlreichen Microsoft-Protokollen verwendet wird, insbesondere bei der MAPI-RPC-Komprimierung zwischen Outlook und Exchange.

Wie die Netzwerkverschlüsselung ist auch die Netzwerkkomprimierung eine Eigenschaft der DAG, nicht eines DAG-Netzwerks. Sie konfigurieren die DAG-Netzwerkkomprimierung mithilfe des Cmdlets "Set-DatabaseAvailabilityGroup" in der Exchange-Verwaltungsshell. Die möglichen Komprimierungseinstellungen für die DAG-Netzwerkkommunikation sind in der folgenden Tabelle aufgelistet.

Einstellung Beschreibung
Deaktiviert Die Netzwerkkomprimierung wird nicht verwendet.
Aktiviert Die Netzwerkkomprimierung wird in allen DAG-Netzwerken für Replikation und Seeding verwendet.
InterSubnetOnly Die Netzwerkkomprimierung wird in DAG-Netzwerken bei der Replikation über verschiedene Subnetze verwendet. Dies ist die Standardeinstellung.
SeedOnly Die Netzwerkkomprimierung wird in allen DAG-Netzwerken nur für Seeding verwendet.

DAG-Netzwerke

Ein DAG-Netzwerk ist eine Sammlung von Subnetzen, die entweder für Replikationsdatenverkehr oder MAPI-Datenverkehr verwendet werden. Jedes DAG-Netzwerk enthält maximal ein MAPI-Netzwerk und null oder mehr Replikationsnetzwerke. In einer einzigen Netzwerkadapterkonfiguration wird das Netzwerk sowohl für MAPI- als auch für Replikationsdatenverkehr verwendet. Obwohl ein einzelner Netzwerkadapter und Pfad unterstützt wird, wird empfohlen, dass jede DAG mindestens zwei DAG-Netzwerke hat. In einer Konfiguration mit zwei Netzwerken ist in der Regel ein Netzwerk für Replikationsdatenverkehr vorgesehen, und das andere Netzwerk wird hauptsächlich für MAPI-Datenverkehr verwendet. Sie können auch jedem DAG-Mitglied Netzwerkadapter hinzufügen und weitere DAG-Netzwerke als Replikationsnetzwerke konfigurieren.

Hinweis

Bei der Verwendung mehrerer Replikationsnetzwerke gibt es keine Möglichkeit, eine Priorität für die Netzwerkverwendung festzulegen. wählt ein Replikationsnetzwerk nach dem Zufallsprinzip aus der Gruppe der für den Protokollversand verfügbaren Replikationsnetzwerke aus.

In Exchange 2010 war in vielen Szenarien eine manuelle Konfiguration der DAG-Netzwerke erforderlich. In späteren Versionen von Exchange werden DAG-Netzwerke standardmäßig automatisch vom System konfiguriert. Bevor Sie DAG-Netzwerke erstellen oder ändern können, müssen Sie zunächst die manuelle DAG-Netzwerksteuerung aktivieren, indem Sie folgenden Befehl ausführen:

Set-DatabaseAvailabilityGroup <DAGName> -ManualDagNetworkConfiguration $true

Nachdem Sie die manuelle DAG-Netzwerkkonfiguration aktiviert haben, können Sie das Cmdlet "New-DatabaseAvailabilityGroupNetwork" in der Exchange-Verwaltungsshell verwenden, um ein DAG-Netzwerk zu erstellen. Genaue Anweisungen zum Erstellen eines Netzwerks mit DAGs finden Sie unter Erstellen eines DAG-Netzwerks.

Sie können das Cmdlet "Set-DatabaseAvailabilityGroupNetwork" in der Exchange-Verwaltungsshell verwenden, um DAG-Netzwerkeigenschaften zu konfigurieren. Genaue Anweisungen zum Konfigurieren der Eigenschaften von DAG-Netzwerken finden Sie unter Konfigurieren der Eigenschaften von DAG-Netzwerken. In jedem DAG-Netzwerk müssen erforderliche und optionale Parameter konfiguriert werden:

  • Netzwerkname: Ein eindeutiger Name für das DAG-Netzwerk mit bis zu 128 Zeichen.

  • Netzwerkbeschreibung: Eine optionale Beschreibung für das DAG-Netzwerk mit bis zu 256 Zeichen.

  • Netzwerksubnetze: Ein oder mehrere Subnetze, die mit einem Format von IPAddress/Bitmaske eingegeben wurden (z. B. 192.168.1.0/24 für IPv4-Subnetze (Internet Protocol Version 4; 2001:DB8:0:C000:::/64 für IPv6-Subnetze).

  • Replikation aktivieren: Aktivieren Sie im EAC das Kontrollkästchen, um das DAG-Netzwerk dem Replikationsdatenverkehr zu widmen und MAPI-Datenverkehr zu blockieren. Deaktivieren Sie das Kontrollkästchen, um zu verhindern, dass die Replikation das DAG-Netzwerk verwendet, und um MAPI-Datenverkehr zu aktivieren. Verwenden Sie in der Exchange Verwaltungsshell den Parameter ReplicationEnabled im Cmdlet "Set-DatabaseAvailabilityGroupNetwork", um die Replikation zu aktivieren und zu deaktivieren.

Hinweis

Das Deaktivieren der Replikation im MAPI-Netzwerk gewährleistet nicht, dass das MAPI-Netzwerk vom System nicht für die Replikation verwendet wird. Wenn alle konfigurierten Replikationsnetzwerke offline, ausgefallen oder anderweitig nicht verfügbar sind und nur ein MAPI-Netzwerk übrig bleibt (das nicht für die Replikation aktiviert ist), wird dieses Netzwerk vom System für die Replikation verwendet.

Die vom System erstellten anfänglichen DAG-Netzwerke (z. B. "MapiDagNetwork" und "ReplicationDagNetwork01") basieren auf den Subnetzen, die vom Clusterdienst aufgezählt wurden. Jedes DAG-Mitglied muss über dieselbe Anzahl von Netzwerkadaptern verfügen und jeder Netzwerkadapter muss eine IPv4-Adresse (und optional auch eine IPv6-Adresse) in einem eindeutigen Subnetz besitzen. Mehrere DAG-Mitglieder können IPv4-Adressen im gleichen Subnetz besitzen, aber jedes Paar aus Netzwerkadapter und IP-Adresse in einem bestimmten DAG-Mitglied muss sich in einem eindeutigen Subnetz befinden. Außerdem sollte nur der für das MAPI-Netzwerk verwendete Adapter mit einem Standardgateway konfiguriert werden. Replikationsnetzwerke sollten nicht mit einem Standardgateway konfiguriert werden.

Stellen Sie sich z. B. DAG1 vor, eine zwei Mitglieder umfassende DAG, in der jedes Mitglied zwei Netzwerkadapter besitzt (einer für das MAPI-Netzwerk und der andere für das Replikationsnetzwerk). In der nachfolgenden Tabelle sind Beispieleinstellungen für die IP-Adresskonfiguration enthalten.

Beispieleinstellungen für den Netzwerkadapter

Servernetzwerkadapter IP-Adresse/Subnetzmaske Standardgateway
EX1-MAPI 192.168.1.15/24 192.168.1.1
EX1-Replikation 10.0.0.15/24 Nicht zutreffend
EX2-MAPI 192.168.1.16 192.168.1.1
EX2-Replikation 10.0.0.16 Nicht zutreffend

In der folgenden Konfiguration werden zwei Subnetze in der DAG konfiguriert: 192.168.1.0 und 10.0.0.0. Beim Hinzufügen von EX1 und EX2 zur DAG werden zwei Subnetze aufgezählt und zwei DAG-Netzwerke erstellt: MapiDagNetwork (192.168.1.0) und ReplicationDagNetwork01 (10.0.0.0). Diese Netzwerke werden, wie in der folgenden Tabelle gezeigt, konfiguriert.

Aufgezählte DAG-Netzwerkeinstellungen für eine DAG mit einzelnem Subnetz

Name Subnetze Schnittstellen MAPI-Zugriff aktiviert Replikation aktiviert
MapiDagNetwork 192.168.1.0/24 EX1 (192.168.1.15)
EX2 (192.168.1.16)
True True
ReplicationDagNetwork01 10.0.0.0/24 EX1 (10.0.0.15)
EX2 (10.0.0.16)
False Wahr

Deaktivieren Sie die Replikation für MapiDagNetwork, indem Sie den folgenden Befehl ausführen, um die Konfiguration von ReplicationDagNetwork01 als dediziertes Replikationsnetzwerk abzuschließen.

Set-DatabaseAvailabilityGroupNetwork -Identity DAG1\MapiDagNetwork -ReplicationEnabled:$false

Nachdem die Replikation für MapiDagNetwork deaktiviert wurde, verwendet der Microsoft Exchange-Replikationsdienst ReplicationDagNetwork01 zur fortlaufenden Replikation. Wenn in ReplicationDagNetwork01 ein Fehler auftritt, verwendet der Microsoft Exchange-Replikationsdienst wieder MapiDagNetwork zur fortlaufenden Replikation. Das System geht bewusst auf diese Weise vor, um die hohe Verfügbarkeit zu erhalten.

DAG-Netzwerke und Bereitstellungen mit mehreren Subnetzen

Im vorherigen Beispiel wird die DAG als DAG mit einzelnem Subnetz betrachtet, obwohl zwei unterschiedliche Subnetze verwendet werden (192.168.1.0 und 10.0.0.0), da jedes Mitglied dasselbe Subnetz verwendet, um das MAPI-Netzwerk zu bilden. Wenn die DAG-Mitglieder verschiedene Subnetze für das MAPI-Netzwerk verwenden, wird die DAG als DAG mit mehreren Subnetzen bezeichnet. In einer DAG mit mehreren Subnetzen werden automatisch jedem DAG-Netzwerk die richtigen Subnetze zugeordnet.

Stellen Sie sich z. B. DAG2 vor, eine zwei Mitglieder umfassende DAG, in der jedes Mitglied zwei Netzwerkadapter besitzt (einer für das MAPI-Netzwerk und der andere für das Replikationsnetzwerk), und jedes DAG-Mitglied befindet sich an einem separaten Active Directory-Standort, während das jeweiige MAPI-Netzwerk in einem anderen Subnetz enthalten ist. In der nachfolgenden Tabelle sind Beispieleinstellungen für die IP-Adresskonfiguration enthalten.

Beispieleinstellungen für einen Netzwerkadapter für eine DAG mit mehreren Subnetzen

Servernetzwerkadapter IP-Adresse/Subnetzmaske Standardgateway
EX1-MAPI 192.168.0.15/24 192.168.0.1
EX1-Replikation 10.0.0.15/24 Nicht zutreffend
EX2-MAPI 192.168.1.15 192.168.1.1
EX2-Replikation 10.0.1.15 Nicht zutreffend

In der folgenden Konfiguration werden vier Subnetze in der DAG konfiguriert: 192.168.0.0, 192.168.1.0, 10.0.0.0 und 10.0.1.0. Beim Hinzufügen von EX1 und EX2 zur DAG werden vier Subnetze aufgezählt, jedoch nur zwei DAG-Netzwerke erstellt: MapiDagNetwork (192.168.0.0, 192.168.1.0) und ReplicationDagNetwork01 (10.0.0.0, 10.0.1.0). Diese Netzwerke werden, wie in der folgenden Tabelle gezeigt, konfiguriert.

Aufgezählte DAG-Netzwerkeinstellungen für eine DAG mit mehreren Subnetzen

Name Subnetze Schnittstellen MAPI-Zugriff aktiviert Replikation aktiviert
MapiDagNetwork 192.168.0.0/24
192.168.1.0/24
EX1 (192.168.0.15)
EX2 (192.168.1.15)
True True
ReplicationDagNetwork01 10.0.0.0/24
10.0.1.0/24
EX1 (10.0.0.15)
EX2 (10.0.1.15)
False Wahr

DAG-Netzwerke und iSCSI-Netzwerke

Standardmäßig führen DAGs die Ermittlung aller Netzwerke durch, die erkannt und für die Verwendung durch den zugrunde liegenden Cluster konfiguriert wurden. Dazu gehören alle iSCSI-Netzwerke (Internet SCSI), die sich als iSCSI-Speicher für ein oder mehrere DAG-Mitglieder in Verwendung befinden. Es wird empfohlen, dass iSCSI-Speicher dedizierte Netzwerke und Netzwerkadapter verwenden. Diese Netzwerke sollten nicht durch die DAG oder deren Cluster verwaltet oder als DAG-Netzwerke (MAPI oder Replikation) verwendet werden. Stattdessen sollten diese Netzwerke manuell für die Verwendung durch die DAG deaktiviert werden, damit sie für iSCSI-Speicherverkehr reserviert werden können. Damit iSCSI-Netzwerke nicht als DAG-Netzwerke erkannt und verwendet werden, konfigurieren Sie die DAG so, dass alle aktuell erkannten iSCSI-Netzwerke ignoriert werden. Verwenden Sie dazu das Cmdlet Set-DatabaseAvailabilityGroupNetwork, wie in diesem Beispiel gezeigt:

Set-DatabaseAvailabilityGroupNetwork -Identity DAG2\DAGNetwork02 -ReplicationEnabled:$false -IgnoreNetwork:$true

Dieser Befehl deaktiviert auch die Verwendung des Netzwerks durch den Cluster. Nach Ausführung des oben stehenden Befehls werden die iSCSI-Netzwerke zwar weiterhin als DAG-Netzwerke angezeigt, jedoch nicht für MAPI- oder Replikationsdatenverkehr verwendet.

Konfigurieren von DAG-Mitgliedern

Postfachserver, die Mitglieder einer DAG sind, weisen einige für die hohe Verfügbarkeit spezifische Eigenschaften auf, die gemäß den Beschreibungen in den folgenden Abschnitten konfiguriert werden sollten:

Automatische Datenbank-Einbindungswahl

Der Parameter AutoDatabaseMountDial gibt das Verhalten für das automatische Einbinden von Datenbanken nach einem Datenbankfailover an. Mithilfe des Cmdlets Set-MailboxServer können Sie den Parameter AutoDatabaseMountDial mit den folgenden Werten konfigurieren:

  • BestAvailability: Wenn Sie diesen Wert angeben, wird die Datenbank automatisch unmittelbar nach einem Failover bereitgestellt, wenn die Länge der Kopierwarteschlange kleiner oder gleich 12 ist. Die Länge der Kopiewarteschlange entspricht der Anzahl von Protokollen, die von der passiven Kopie als zu replizieren erkannt werden. Wenn die Länge der Kopiewarteschlange größer als 12 ist, wird die Datenbank nicht automatisch bereitgestellt. Wenn die Länge der Kopiewarteschlange kleiner oder gleich 12 ist, versucht Exchange die verbleibenden Protokolle auf die passive Kopie zu replizieren und stellt die Datenbanken bereit.

  • GoodAvailability: Wenn Sie diesen Wert angeben, wird die Datenbank automatisch unmittelbar nach einem Failover bereitgestellt, wenn die Länge der Kopierwarteschlange kleiner oder gleich sechs ist. Die Länge der Kopiewarteschlange entspricht der Anzahl von Protokollen, die von der passiven Kopie als zu replizieren erkannt werden. Wenn die Länge der Kopiewarteschlange größer als sechs ist, wird die Datenbank nicht automatisch bereitgestellt. Wenn die Länge der Kopiewarteschlange kleiner oder gleich sechs ist, versucht Exchange die verbleibenden Protokolle auf die passive Kopie zu replizieren und stellt die Datenbanken bereit.

  • Lossless: Wenn Sie diesen Wert angeben, wird die Datenbank erst automatisch bereitgestellt, wenn alle Protokolle, die in der aktiven Kopie generiert wurden, in die passive Kopie kopiert wurden. Diese Einstellung führt auch dazu, dass der Auswahlalgorithmus für den optimalen Kopiervorgang von Active Manager die potenziellen Kandidaten für die Aktivierung auf Grundlage des Aktivierungseinstellungswerts und nicht der Länge der Kopierwarteschlange sortiert wird.

Der Standardwert ist GoodAvailability. Wenn Sie entweder BestAvailability oder GoodAvailabilityangeben und alle Protokolle aus der aktiven Kopie nicht in die passive Kopie kopiert werden können, die aktiviert wird, gehen möglicherweise einige Postfachdaten verloren. Die Funktion "Sicherheitsnetz" (die standardmäßig aktiviert ist) unterstützt Sie aber beim Schutz vor den meisten Datenverlusten, indem Nachrichten, die sich in der Sicherheitsnetz-Warteschlange befinden, erneut übermittelt werden.

Beispiel: Konfigurieren der automatischen Datenbank-Einbindungswahl

Im folgenden Beispiel wird ein Postfachserver mit der Einstellung GoodAvailability"AutoDatabaseMountDial" konfiguriert.

Set-MailboxServer -Identity EX1 -AutoDatabaseMountDial GoodAvailability

Automatische Aktivierungsrichtlinie für die Datenbankkopie

Der Parameter DatabaseCopyAutoActivationPolicy gibt den Typ der automatischen Aktivierung an, der für Postfachdatenbankkopien auf ausgewählten Postfachservern verfügbar ist. Mithilfe des Cmdlets Set-MailboxServer können Sie den Parameter DatabaseCopyAutoActivationPolicy mit den folgenden Werten konfigurieren:

  • Blocked: Wenn Sie diesen Wert angeben, können Datenbanken nicht automatisch auf den ausgewählten Postfachservern aktiviert werden.

  • IntrasiteOnly: Wenn Sie diesen Wert angeben, kann die Datenbankkopie auf Servern am selben Active Directory-Standort aktiviert werden. Dadurch wird ein Failover oder eine Aktivierung zwischen Standorten vermieden. Diese Eigenschaft gilt für eingehende Postfachdatenbankkopien (z. B. für eine passive Kopie, die von einer aktiven Kopie erstellt wird). Datenbanken können auf diesem Postfachserver nicht für Datenbankkopien aktiviert werden, die an einem anderen Active Directory-Standort aktiv sind.

  • Unrestricted: Wenn Sie diesen Wert angeben, gibt es keine besonderen Einschränkungen beim Aktivieren von Postfachdatenbankkopien auf den ausgewählten Postfachservern.

Beispiel: Konfigurieren der automatischen Aktivierungsrichtlinie für die Datenbankkopie

The following example configures a Mailbox server with a DatabaseCopyAutoActivationPolicy setting of Blocked.

Set-MailboxServer -Identity EX1 -DatabaseCopyAutoActivationPolicy Blocked

Maximale Anzahl von aktiven Datenbanken

Der Parameter MaximumActiveDatabases (der auch mit dem Cmdlet Set-MailboxServer verwendet wird) gibt die Anzahl von Datenbanken an, die auf einem Postfachserver eingebunden werden können. Sie können Postfachserver derart konfigurieren, dass sie Ihren Bereitstellungsanforderungen entsprechen, indem Sie sicherstellen, dass ein einzelner Postfachserver nicht überlastet wird.

Der Parameter MaximumActiveDatabases wird mit einem ganzzahligen Wert konfiguriert. Wenn die maximale Anzahl erreicht ist, werden die Datenbankkopien auf dem Server bei einem Failover oder Switchover nicht aktiviert. Sind die Kopien auf einem Server bereits aktiv, lässt der Server die Einbindung der Datenbanken nicht zu.

Beispiel: Konfigurieren der maximalen Anzahl von aktiven Datenbanken

Im folgenden Beispiel wird ein Postfachserver für die Unterstützung von maximal 20 aktiven Datenbanken konfiguriert.

Set-MailboxServer -Identity EX1 -MaximumActiveDatabases 20

Ausführen des Wartungsprozesses auf DAG-Mitgliedern

Bevor Sie eine Software- oder Hardwarewartung auf einem DAG-Mitglied durchführen, müssen Sie das betreffende DAG-Mitglied zunächst in den Wartungsmodus versetzen. Die folgenden Skripts werden mit Exchange Server zur Unterstützung von DAG-Wartungsverfahren bereitgestellt.

  • StartDagServerMaintenance.ps1: Hilft beim Verschieben aller aktiven Datenbanken vom Server. Außerdem werden alle wichtigen DAG-Supportfunktionen wie die Pam-Rolle (Primary Active Manager) verschoben und verhindert, dass sie wieder auf den Server wechseln, bevor die Wartung abgeschlossen ist.

  • StopDagServerMaintenance.ps1: Hilft dabei, das DAG-Mitglied aus dem Wartungsmodus zu nehmen und es zu einem aktiven Ziel für alle Datenbanken und alle wichtigen DAG-Supportfunktionen zu machen.

Beide der obigen Skripts akzeptieren den ServerName-Parameter (der entweder der Hostname oder der vollqualifizierte Domänenname (FQDN) des DAG-Mitglieds sein kann) und den WhatIf-Parameter . Beide Skripts können lokal oder remote ausgeführt werden. Auf dem Server, auf dem die Skripts ausgeführt werden, müssen die Tools zur Verwaltung von Windows-Failoverclustern (RSAT-Clustering) installiert sein.

Hinweis

Das skriptRedistributeActiveDatabases.ps1 ist ebenfalls verfügbar, was die Bereitstellung von Postfachdatenbanken für bestimmte DAG-Mitglieder unterstützt, die durch die Aktivierungseinstellungsnummer in jeder Datenbank gekennzeichnet sind. In Exchange 2016 CU2 oder höher gleicht die neue DAG-Eigenschaft mit dem Namen PreferenceMoveFrequency automatisch Datenbankkopien in einer DAG aus. Daher müssen Sie RedistributeActiveDatabases.ps1 nur verwenden, wenn Sie diese Funktion deaktiviert haben oder wenn Sie Datenbankkopien manuell ausgleichen möchten.

Das Skript „StartDagServerMaintenance.ps1“ führt die folgenden Tasks aus:

  • Legt den Wert des Parameters DatabaseCopyAutoActivationPolicy für das DAG-Mitglied auf Blocked, der verhindert, dass Datenbankkopien auf dem Server aktiviert werden.

  • Anhalten des Knotens im Cluster, damit der Knoten weder als PAM fungieren noch als PAM festgelegt werden kann

  • Verschieben aller aktuell auf dem DAG-Mitglied gehosteten aktiven Datenbanken auf andere DAG-Mitglieder

  • Falls das DAG-Mitglied aktuell die Standardclustergruppe hostet: Verschieben der Standardclustergruppe (und damit der PAM-Rolle) auf ein anderes DAG-Mitglied

Wenn einer der oben genannten Tasks fehlschlägt, werden sämtliche Vorgänge durch das Skript rückgängig gemacht, mit Ausnahme erfolgreicher Datenbankverschiebungen.

Gehen Sie wie folgt vor, um die Wartung auf einem DAG-Mitglied anzustoßen, inklusive Leeren der Transportwarteschlangen und Unterbrechen der Clientkonnektivität:

  1. Führen Sie den folgenden Befehl aus, um die Transportwarteschlangen zu leeren:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Draining -Requester Maintenance
    
  2. Führen Sie den folgenden Befehl aus, um die Entleerung der Transportwarteschlangen zu initiieren:

    Restart-Service MSExchangeTransport
    
  3. Führen Sie den folgenden Befehl aus, um mit dem Ausgleich aller Unified Messaging-Anrufe zu beginnen (nur in Exchange 2016):

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Draining -Requester Maintenance
    
  4. Führen Sie den folgenden Befehl aus, um auf die DAG-Wartungsskripts zuzugreifen:

    CD $ExScripts
    
  5. Führen Sie den folgenden Befehl aus, um das skript StartDagServerMaintenance.ps1 auszuführen:

    .\StartDagServerMaintenance.ps1 -ServerName <ServerName> -MoveComment Maintenance -PauseClusterNode
    

    Für den Wert des MoveComment-Parameters können Sie eine beliebige Notation erstellen. Im obigen Beispiel wird „Maintenance“ verwendet.

    Hinweis

    Die Ausführung dieses Skripts kann einige Zeit dauern. Während dieser Zeit sind auf Ihrem Bildschirm möglicherweise keinerlei Aktivitäten zu sehen.

  6. Führen Sie zum Umleiten von Nachrichten mit ausstehender Zustellung in den lokalen Warteschlangen an den Exchange Server aus, der durch den Parameter "Target" angegeben ist.

    Redirect-Message -Server <ServerName> -Target <Server FQDN>
    
  7. Führen Sie Folgendes aus, um den Server in den Wartungsmodus zu setzen:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Inactive -Requester Maintenance
    

Führen Sie die folgenden Aufgaben aus, um zu überprüfen, ob ein Server zur Wartung bereit ist:

  1. Um zu überprüfen, ob der Server in den Wartungsmodus versetzt wurde, bestätigen Sie dies nur Monitoring und RecoveryActionsEnabled befinden sich in einem aktiven Zustand, wenn Sie den folgenden Befehl ausführen:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize
    
  2. Führen Sie Folgendes aus, um zu überprüfen, ob der Server keine aktiven Datenbankkopien hostet:

    Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy
    
  3. Führen Sie Folgendes aus, um zu überprüfen, ob der Clusterknoten angehalten ist:

    Get-ClusterNode <ServerName> | Format-List
    
  4. Führen Sie Folgendes aus, um zu überprüfen, ob alle Transportwarteschlangen geleert wurden:

    Get-Queue
    

Sobald die Wartung abgeschlossen und das DAG-Mitglied bereit ist, den Dienst wieder aufzunehmen, können Sie das Skript „StopDagServerMaintenance.ps1“ verwenden, um das DAG-Mitglied aus dem Wartungsmodus zurück in den Produktionsmodus zu versetzen. Das Skript „StopDagServerMaintenance.ps1“ führt die folgenden Tasks durch:

  • Fortsetzen des Knotens im Cluster, sodass auf dem DAG-Mitglied wieder alle Clusterfunktionen zur Verfügung stehen

  • Legt den Wert des Parameters DatabaseCopyAutoActivationPolicy für das DAG-Element auf Unrestricted.

  • Ausführen des Cmdlets Resume-MailboxDatabaseCopy für jede auf dem DAG-Mitglied gehostete Datenbankkopie

Wenn Sie bereit sind, das DAG-Mitglied auf den vollständigen Produktionsstatus wiederherzustellen, einschließlich der Fortsetzung der Transportwarteschlangen und der Clientkonnektivität, führen Sie die folgenden Aufgaben aus:

  1. Führen Sie Folgendes aus, um den Server als nicht mehr im Wartungsmodus zu konfigurieren und bereit für die Annahme von Clientverbindungen zu sein:

    Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Maintenance
    
  2. Führen Sie Folgendes aus, um zuzulassen, dass der Server Unified Messaging-Anrufe akzeptiert (nur in Exchange 2016):

    Set-ServerComponentState <ServerName> -Component UMCallRouter -State Active -Requester Maintenance
    
  3. Führen Sie den folgenden Befehl aus, um auf die DAG-Wartungsskripts zuzugreifen:

    CD $ExScripts
    
  4. Führen Sie Folgendes aus, um das skript StopDagServerMaintenance.ps1 auszuführen:

    .\StopDagServerMaintenance.ps1 -serverName <ServerName>
    
  5. Führen Sie Folgendes aus, um zu ermöglichen, dass die Transportwarteschlangen die Annahme und Verarbeitung von Nachrichten fortsetzen können:

    Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance
    
  6. Führen Sie zum Fortsetzen der Transportaktivität Folgendes aus:

    Restart-Service MSExchangeTransport
    

Führen Sie die folgenden Aufgaben aus, um zu überprüfen, ob ein Server für den Produktionseinsatz bereit ist:

  1. Führen Sie den folgenden Befehl aus, um sich zu vergewissern, dass der Server nicht mehr im Wartungsmodus ist:

    Get-ServerComponentState <ServerName> | Format-Table Component,State -Autosize
    

Wenn Sie ein Exchange Update installieren und der Updatevorgang fehlschlägt, können einige Serverkomponenten inaktiv bleiben, was in der Ausgabe des obigen Get-ServerComponentState Cmdlets angezeigt wird. Führen Sie die folgenden Befehle aus, um dies zu beheben:

  1. Set-ServerComponentState <ServerName> -Component ServerWideOffline -State Active -Requester Functional

  2. Set-ServerComponentState <ServerName> -Component Monitoring -State Active -Requester Functional

  3. Set-ServerComponentState <ServerName> -Component RecoveryActionsEnabled -State Active -Requester Functional

Herunterfahren von DAG-Mitgliedern

Exchange Hochverfügbarkeitslösung ist in den Windows Herunterfahren integriert. Wenn ein Administrator oder eine Anwendung das Herunterfahren eines Windows-Servers in einer DAG mit einer eingebundenen Datenbank initiiert, die an eine oder mehrere DAG-Mitglieder repliziert wird, versucht das System, eine andere Kopie der eingebundenen Datenbank zu aktivieren, bevor der Server heruntergefahren werden kann.

Dieses neue Verhalten garantiert jedoch nicht, dass für alle Datenbanken auf dem heruntergefahrenen Server eine lossless Aktivierung erfolgt. Aus diesem Grund sollte vor dem Herunterfahren eines Servers, der Mitglied einer DAG ist, ein Serverswitchover durchgeführt werden.

Installieren von Updates auf DAG-Mitgliedern

Das Installieren Exchange Updates auf einem Server, der Mitglied einer DAG ist, ist ein relativ einfacher Prozess. Wenn Sie ein Update auf einem Server installieren, der Mitglied einer DAG ist, werden mehrere Dienste während der Installation angehalten, darunter auch alle Exchange-Dienste und der Clusterdienst. Die allgemeine Vorgehensweise zum Zuweisen von Updates zu einem DAG-Mitglied ist folgende:

  1. Führen Sie die oben beschriebenen Schritte aus, um das DAG-Mitglied in den Wartungsmodus zu versetzen.

  2. Installieren Sie das Update.

  3. Führen Sie die oben beschriebenen Schritte aus, um das DAG-Mitglied aus dem Wartungsmodus zurück in den Produktionsmodus zu versetzen.

  4. Verwenden Sie optional das Skript "RedistributeActiveDatabases.ps1", um die aktiven Datenbankkopien für die DAG neu auszugleichen.

Weitere Informationen zu den neuesten Exchange Updates finden Sie unter Exchange Server Buildnummern und Veröffentlichungsdaten.