Verwalten von Datenbankverfügbarkeitsgruppen in Exchange Server

Eine Datenbankverfügbarkeitsgruppe (DAG) ist ein Satz von bis zu 16 Exchange-Postfachservern, die eine automatische Wiederherstellung auf Datenbankebene nach einem Datenbank-,Server-/Netzwerkausfall ermöglichen. 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 einem DAG ein Postfachserver hinzugefügt wird, arbeitet dieser Server mit den anderen Servern in der DAG zusammen, um eine automatische Wiederherstellung nach Datenbankfehlern auf Datenbankebene 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 Failoverclustertaktmechanismus und die Clusterdatenbank werden dann verwendet, um Informationen zur DAG zu verfolgen und zu verwalten, die sich schnell ändern können, z. B. status der Datenbankbereitstellung, Replikation status und zuletzt bereitgestellter Speicherort.

Erstellen von DAGs

Eine DAG kann mithilfe des 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 sowie optionale Zeugenserver- und Zeugenverzeichniseinstellungen 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). Sie können ip-Adressen manuell der DAG zuweisen, indem Sie den Parameter DatabaseAvailabilityGroupIpAddresses verwenden. 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, die Windows Server 2012 R2 ausgeführt werden, haben Sie auch die Möglichkeit, eine DAG ohne einen Clusteradministratorzugriffspunkt zu erstellen. In diesem Fall verfügt der Cluster nicht über ein Clusternamenobjekt (Cluster Name Object, CNO) in Active Directory, und die Clusterkernressourcengruppe enthält keine Netzwerknamenressource oder IP-Adressressource.

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

Wenn Sie eine DAG erstellen, werden in Active Directory ein leeres Objekt erstellt, das die DAG mit dem angegebenen Namen und die Objektklasse msExchMDBAvailabilityGroup darstellt.

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

DAG-Zeugenserver und -Zeugenverzeichnis

Wenn Sie eine DAG erstellen, müssen Sie einen Namen für die DAG angeben, der nicht länger als 15 Zeichen in der Active Directory-Gesamtstruktur 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 vorhanden ist, und 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.

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.

• Auf dem 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 davon, welcher Server als Zeugenserver verwendet wird, müssen Sie die Windows-Firewall-Ausnahme für die Datei- und Druckerfreigabe aktivieren, wenn die Windows-Firewall auf dem vorgesehenen Zeugenserver aktiviert ist. Der Zeugenserver verwendet SMB-Port 445.

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

Ü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 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 Standort zum Hosten des Zeugenservers verwenden. Wenn Ihr organization über einen dritten Standort mit einer Netzwerkinfrastruktur verfügt, die von Netzwerkausfällen 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 Standort bereitstellen und so Ihre DAG mit der Möglichkeit konfigurieren, als Reaktion auf ein Fehlerereignis auf Rechenzentrumsebene automatisch ein Failover von Datenbanken auf das andere Rechenzentrum auszuführen. Wenn Ihr organization nur über zwei physische Standorte verfügt, können Sie ein virtuelles Microsoft Azure-Netzwerk als dritten Standort verwenden, um Ihren Zeugenserver zu platzieren.

Angeben eines Zeugenservers und Zeugenverzeichnisses bei der DAG-Erstellung

Wenn Sie eine DAG erstellen, müssen Sie einen Namen für die DAG angeben. Optional können Sie auch einen Zeugenserver und ein Zeugenverzeichnis angeben.

Wenn Sie eine DAG erstellen, stehen die folgenden Kombinationen von Optionen und Verhaltensweisen zur Verfügung:

• 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%:\DAGFileShareWitnesses\<DAGFQDN) 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 das Standardzeugenverzeichnis C:\DAGFileShareWitnesses\DAG1.contoso.com verwenden, das als \CAS3\DAG1.contoso.com freigegeben wird.

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

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 keine Firewallausnahmen für WMI 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 einen der folgenden Schritte aus, um die oben genannten 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 Server zur DAG hinzufügen oder daraus entfernen, indem Sie den Assistenten zum Verwalten von Datenbankverfügbarkeitsgruppen im 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 Mitgliedschaft in Datenbankverfügbarkeitsgruppen.

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

Wenn der erste Postfachserver einer DAG hinzugefügt wird, treten die folgenden Ereignisse auf:

• 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 umgebung mit großen oder mehreren Standorten, insbesondere in umgebungen, in denen die DAG auf mehrere Active Directory-Standorte erweitert wird, müssen Sie warten, bis die Active Directory-Replikation des DAG-Objekts, das das erste DAG-Mitglied enthält, abgeschlossen ist. Wenn dieses Active Directory-Objekt nicht in Ihrer gesamten Umgebung repliziert wird, kann das Hinzufügen des zweiten Servers dazu führen, dass ein neuer Cluster (und ein neuer CNO) für die DAG erstellt wird. Diese Erstellung liegt daran, dass das DAG-Objekt aus der Perspektive des zweiten hinzugefügten Elements leer erscheint, wodurch das Cmdlet Add-DatabaseAvailabilityGroupServer einen Cluster und einen CNO für die DAG erstellt, obwohl diese Objekte bereits vorhanden sind. Um zu überprüfen, ob das DAG-Objekt, das den ersten DAG-Server enthält, repliziert wurde, verwenden Sie das Cmdlet Get-DatabaseAvailabilityGroup auf dem zweiten hinzugefügten Server, um zu überprüfen, ob der erste hinzugefügte Server als Mitglied der DAG aufgeführt ist.

Wenn der zweite und nachfolgende Server der DAG hinzugefügt werden, treten die folgenden Ereignisse auf:

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

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.

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 und deaktivieren ein Computerkonto für den CNO 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 mithilfe des Assistenten zum Verwalten von Datenbankverfügbarkeitsgruppen im EAC oder mit dem Cmdlet Remove-DatabaseAvailabilityGroupServer in der Exchange-Verwaltungsshell aus einer DAG entfernt werden. 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 mit dem Schalter Setup /m:RecoverServer ausführen. Bevor Sie den Wiederherstellungsvorgang ausführen können, müssen Sie jedoch zuerst den Server mithilfe des Cmdlets Remove-DatabaseAvailabilityGroupServer mit dem ConfigurationOnly-Parameter 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 Server der DAG hinzugefügt wurden, können Sie das 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 IP-Adressen, die der DAG zugewiesen sind.

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. Diese Benennung ermöglicht es dem System, die Freigabe bei Bedarf automatisch zu konfigurieren, zu schützen und zu verwenden, und ermöglicht es dem Messagingadministrator, die Verfügbarkeit des Zeugenservers zu erkennen.

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

• IP-Adressen der Datenbankverfügbarkeitsgruppe: Mindestens eine IP-Adresse muss der DAG zugewiesen werden, es sei denn, die DAG-Mitglieder werden Windows Server 2012 R2 ausgeführt, 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; und alternative Einstellungen für Zeugenserver und Zeugenverzeichnis; und , um den Koordinierungsmodus für die Rechenzentrumsaktivierung zu aktivieren.

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. (Die vollständige Liste finden Sie in Abschnitt 3.1.5.2, "Verschlüsselungstypen" der Kerberos-Protokollerweiterungen.) Der Kerberos-Authentifizierungs-Handshake wählt das stärkste unterstützte Verschlüsselungsprotokoll in der Liste aus: in der Regel AES (Advanced Encryption Standard) 256-Bit, möglicherweise mit einem SHA Hash-based Message Authentication Code (HMAC), um die Integrität der Daten aufrechtzuerhalten. Weitere Informationen finden Sie unter HMAC.

Die Netzwerkverschlüsselung ist eine Eigenschaft der DAG und nicht des DAG-Netzwerks. Sie können die DAG-Netzwerkverschlüsselung mithilfe des Cmdlets Set-DatabaseAvailabilityGroup in der Exchange-Verwaltungsshell konfigurieren. Die möglichen Verschlüsselungseinstellungen für die DAG-Netzwerkkommunikation sind in der folgenden Tabelle aufgeführt:

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. Diese Einstellung 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. Diese Komprimierung ist dieselbe Art von Komprimierung, die in vielen Microsoft-Protokollen verwendet wird, insbesondere bei der MAPI-RPC-Komprimierung zwischen Microsoft Outlook und Exchange.

Wie bei der Netzwerkverschlüsselung ist auch die Netzwerkkomprimierung eine Eigenschaft der DAG und nicht des 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 aufgeführt:

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. Diese Einstellung 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 einzelnen 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 über zwei DAG-Netzwerke verfügt. In einer Konfiguration mit zwei Netzwerken ist ein Netzwerk in der Regel für Replikationsdatenverkehr dediziert, 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.

In Exchange 2010 war in vielen Szenarien eine manuelle Konfiguration der DAG-Netzwerke erforderlich. In höheren 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: Mindestens ein Subnetz, das im Format IPAddress/Bitmaske eingegeben wurde (z. B. 192.168.1.0/24 für IPv4-Subnetze (InternetProtokoll Version 4); 2001:DB8:0:C000::/64 für Subnetze der Internetprotokollversion 6 (IPv6).

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

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). Beispieleinstellungen für die IP-Adresskonfiguration sind in der folgenden Tabelle aufgeführt:

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 konfiguriert, wie in der folgenden Tabelle gezeigt:

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

Um die Konfiguration von ReplicationDagNetwork01 als dediziertes Replikationsnetzwerk abzuschließen, deaktivieren Sie die Replikation für MapiDagNetwork, indem Sie den folgenden Befehl ausführen:

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. Die Rückkehr zu MapiDagNetwork erfolgt absichtlich vom System, um Hochverfügbarkeit aufrechtzuerhalten.

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.

Betrachten Sie beispielsweise DAG2, eine DAG mit zwei Mitgliedern, bei der jedes Mitglied über zwei Netzwerkadapter verfügt (einer für das MAPI-Netzwerk und der andere für ein Replikationsnetzwerk), und jedes DAG-Mitglied befindet sich an einem separaten Active Directory-Standort mit seinem MAPI-Netzwerk in einem anderen Subnetz. Beispieleinstellungen für die IP-Adresskonfiguration sind in der folgenden Tabelle aufgeführt:

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 dargestellt 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 für die Verwendung durch den zugrunde liegenden Cluster erkannt und konfiguriert wurden. Diese Ermittlung schließt die aller iSCSI-Netzwerke (Internet SCSI) ein, die aufgrund der Verwendung von iSCSI-Speicher für ein oder mehrere DAG-Mitglieder verwendet werden. Als bewährte Methode sollte iSCSI-Speicher dedizierte Netzwerke und Netzwerkadapter verwenden. Diese Netzwerke sollten nicht von der DAG oder ihrem Cluster verwaltet oder als DAG-Netzwerke (MAPI oder Replikation) verwendet werden. Stattdessen sollten diese Netzwerke manuell von der DAG deaktiviert werden, damit sie für iSCSI-Speicherdatenverkehr dediziert werden können. Um zu deaktivieren, dass iSCSI-Netzwerke erkannt und als DAG-Netzwerke verwendet werden, konfigurieren Sie die DAG so, dass alle aktuell erkannten iSCSI-Netzwerke ignoriert werden, indem Sie das Cmdlet Set-DatabaseAvailabilityGroupNetwork verwenden, 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

• Automatische Aktivierungsrichtlinie für die Datenbankkopie

• Maximum active databases

Automatische Datenbank-Einbindungswahl

Der Parameter AutoDatabaseMountDial gibt das Verhalten für das automatische Einbinden von Datenbanken nach einem Datenbankfailover an. Sie können das Cmdlet Set-MailboxServer verwenden, um den Parameter AutoDatabaseMountDial mit einem der folgenden Werte zu konfigurieren:

• BestAvailability: Wenn Sie diesen Wert angeben, wird die Datenbank sofort nach einem Failover automatisch eingebunden, 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 Kopierwarteschlange kleiner oder gleich 12 ist, versucht Exchange, die verbleibenden Protokolle in die passive Kopie zu replizieren, und bindet die Datenbank ein.

• GoodAvailability: Wenn Sie diesen Wert angeben, wird die Datenbank sofort nach einem Failover automatisch eingebunden, 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 nicht automatisch eingebunden, bis alle protokolle, die für die aktive 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 AutoDatabaseMountDial-Einstellung konfiguriert GoodAvailability.

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. Sie können das Cmdlet Set-MailboxServer verwenden, um den Parameter DatabaseCopyAutoActivationPolicy mit einem der folgenden Werte zu konfigurieren:

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

• IntrasiteOnly: Wenn Sie diesen Wert angeben, darf die Datenbankkopie auf Servern am gleichen Active Directory-Standort aktiviert werden. Durch diese Aktivierung wird ein standortübergreifendes Failover oder eine aktivierung verhindert. 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 für die Aktivierung von Postfachdatenbankkopien auf den ausgewählten Postfachservern.

Beispiel: Konfigurieren der automatischen Aktivierungsrichtlinie für die Datenbankkopie

Im folgenden Beispiel wird ein Postfachserver mit der DatabaseCopyAutoActivationPolicy-Einstellung konfiguriert 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 numerischen Wert für ganze Zahlen 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 so konfiguriert, dass maximal 20 aktive Datenbanken unterstützt werden:

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 bei DAG-Wartungsprozeduren bereitgestellt:

• StartDagServerMaintenance.ps1: Unterstützt beim Verschieben aller aktiven Datenbanken vom Server. Außerdem werden alle wichtigen DAG-Unterstützungsfunktionen verschoben, z. B. die PAM-Rolle (Primary Active Manager) und verhindert, dass diese vor Abschluss der Wartung auf den Server zurückgewechselt werden.

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

Beide oben genannten Skripts akzeptieren den ServerName-Parameter (der entweder der Hostname oder der vollqualifizierte Domänenname (FQDN) des DAG-Mitglieds sein kann) und die 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.

Das StartDagServerMaintenance.ps1-Skript führt die folgenden Aufgaben aus:

• Legt den Wert des Parameters DatabaseCopyAutoActivationPolicy für den DAG-Member auf fest Blocked, wodurch verhindert wird, 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-Aufrufe (nur in Exchange 2016) zu beginnen:

   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 zum Ausführen des StartDagServerMaintenance.ps1 Skripts den folgenden Befehl aus:

   .\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 in Anspruch nehmen, und während dieser Zeit werden möglicherweise keine Aktivitäten auf dem Bildschirm angezeigt.

6. Führen Sie den folgenden Befehl aus, um Nachrichten mit ausstehender Übermittlung in den lokalen Warteschlangen an den exchange-Server umzuleiten, der durch den Parameter Target angegeben wird:

   Redirect-Message -Server <ServerName> -Target <Server FQDN>
   

7. Führen Sie den folgenden Befehl aus, um den Server in den Wartungsmodus zu versetzen:

   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, vergewissern Sie sich, dass sich nur Monitoring und RecoveryActionsEnabled in einem aktiven Zustand befinden, wenn Sie den folgenden Befehl ausführen:

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

2. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob auf dem Server keine aktiven Datenbankkopien gehostet werden:

   Get-MailboxServer <ServerName> | Format-List DatabaseCopyAutoActivationPolicy
   

3. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob der Clusterknoten angehalten ist:

   Get-ClusterNode <ServerName> | Format-List
   

4. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob alle Transportwarteschlangen geleert wurden:

   Get-Queue
   

Nachdem die Wartung abgeschlossen ist und das DAG-Mitglied bereit ist, in den Dienst zurückzukehren, hilft das StopDagServerMaintenance.ps1-Skript , das DAG-Mitglied aus dem Wartungsmodus zu versetzen und es wieder in die Produktion zu versetzen. Das StopDagServerMaintenance.ps1-Skript führt die folgenden Aufgaben aus:

• 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 den DAG-Member auf fest 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 Produktions-status wiederherzustellen, einschließlich des Fortsetzens der Transportwarteschlangen und der Clientkonnektivität, führen Sie die folgenden Aufgaben aus:

1. Führen Sie den folgenden Befehl aus, um den Server so zu konfigurieren, dass er sich im Wartungsmodus befindet und bereit ist, Clientverbindungen zu akzeptieren:

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

2. Führen Sie den folgenden Befehl aus, damit der Server Unified Messaging-Anrufe annehmen kann (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 den folgenden Befehl aus, um dasStopDagServerMaintenance.ps1 Skript auszuführen:

   .\StopDagServerMaintenance.ps1 -serverName <ServerName>
   

5. Führen Sie den folgenden Befehl aus, damit die Transportwarteschlangen die Annahme und Verarbeitung von Nachrichten fortsetzen können:

   Set-ServerComponentState <ServerName> -Component HubTransport -State Active -Requester Maintenance
   

6. Führen Sie den folgenden Befehl aus, um die Transportaktivität fortzusetzen:

   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 zu überprüfen, ob sich der Server nicht im Wartungsmodus befindet:

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

Wenn Sie ein Exchange-Update installieren und der Updatevorgang fehlschlägt, kann es sein, dass einige Serverkomponenten in einem inaktiven Zustand bleiben, der in der Ausgabe des obigen Get-ServerComponentState Cmdlets angezeigt wird. Führen Sie die folgenden Befehle aus, um dieses Problem 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

Die Exchange-Hochverfügbarkeitslösung ist in den Windows-Herunterfahrensprozess 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 alle Datenbanken auf dem Server, die heruntergefahren werden, eine lossless Aktivierung erfahren. 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 von 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. Optional können Sie das RedistributeActiveDatabases.ps1 Skript verwenden, um die aktiven Datenbankkopien in der DAG neu auszugleichen.

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