Exchange 2016: Konfiguration einer DAG (Database Availability Group)

Die Konfiguration einer Exchange 2016 DAG ist nahezu identisch mit der Konfiguration einer DAG mit Exchange 2013. Prinzipiell ist es sogar etwas einfacher, denn die Frage, ob die Rollen getrennt werden sollen, oder ob alle Rollen auf einem Server installiert werden können, stellt sich bei Exchange 2016 nicht mehr. Es gibt ja nur noch die Mailbox Rolle. Ein Loadbalacing zwischen den CAS Dienst mittels Windows Loadbalancing Feature funktioniert allerdings weiterhin nicht, denn Fail-Over Cluster und Windows Loadbalancing auf dem gleichen Server schleißen sich gegenseitig aus. Es empfiehlt sich also nach wie vor einen Loadbalancer vorzuschalten, da die Anforderungen seitens Exchange 2016 an einen Loadbalancer gering sind (Layer 4 reicht völlig aus), gibt es zu gut Open Source Lösungen. Nun aber zur DAG. Ich habe ein Testnetzwerk aus 4 VMs erstellt:

Zeichnung1

Alle VMs laufen mit Windows Server 2012 R2. FWDC1 ist der Domain Controller mit einer Netzwerkkarte in das Produktions VLAN, FWFS1 ist ein Memberserver, bisher ohne besondere Konfiguration mit einer Netzwerkkarte im Produktions VLAN. FWEX1 und FWEX2 sollen die DAG Mitglieder werden, die beiden Server haben jeweils 2 Netzwerkkarten, eine im Produktions VLAN und eine dedizierte Netzwerkkarte für die Replikation der DAG.

1

Das Active Directory ist bereits installiert und konfiguriert, fangen wir also an mit der Konfiguration der beiden Exchange Server.

Die Netzwerkkarte für das Replikationsnetzwerk wird wie folgt fonfiguriert:

3

Es wird nur eine feste IP Adresse aus einem anderen Subnetz wie das Produktions Netzwerks vergeben, alle Protokolle bis auf TCP/IPv4 werden deaktiviert.

2.1

Zusätzlich wird der Haken bei „Adressen dieser Verbindung in DNS registrieren“ entfernt. Für die Datenbanken wird ein zusätzliches Laufwerk erstellt, in meinem Fall Laufwerk D: (muss auf beiden Servern identisch sein)

4

Das Laufwerk für die Datenbanken und die Logfiles wird mit ReFS formatiert:

5

Das waren auch schon alle Vorbereitungen für die Exchange Server. Exchange kann jetzt auf dem ersten Server installiert werden. Die Exchange Installation ist identisch mit meiner Anleitung die hier zu finden ist:

https://www.frankysweb.de/exchange-2016-installation-auf-windows-server-2012-r2/

Nachdem Exchange 2016 auf beiden Servern installiert ist, kann der FileServer (FWFS1) vorbereitet werden. Die Gruppe „Exchange Trusted Subsystem“ muss zur lokalen Gruppe „Administratoren“ hinzugefügt werden

10

Zusätzlich müssen folgende Firewall Regeln aktiviert werden, wenn nicht bereits geschehen:

  • Datei- und Druckerfreigabe (SMB eingehend)
  • Windows-Verwaltungsinstrumentation (WMI eingehend)
  • Windows-Verwaltungsinstrumentation (DCOM eingehend)
  • Windows-Verwaltungsinstrumentation (ASync eingehend)

11 12

Jetzt kann das Computerkonto für die DAG vorbereitet werden, dazu wird im Active Directory ein Computer Konto erstellt, welches den Namen der DAG trägt. In meinem Fall ist das FWDAG1, das Computer Konto muss nach dem Erstellen deaktiviert werden.

6

6.2Auf das Computerkonto der DAG bekommt ebenfalls die Gruppe „Exchange Trusted Subsystem“ Vollzugriff

6.1

Hinweis: Wer den Reiter Sicherheit nicht sieht, muss unter Ansicht die „erweiterten Features“ aktivieren.

Bevor die DAG konfiguriert werden kann, müssen noch die Datenbanken an ihren Bestimmungsort verschoben werden, dabei lässt sich auch gleich der Name anpassen:

Get-MailboxDatabase -Server FWEX1 | Set-MailboxDatabase -Name MBDB01
Get-MailboxDatabase -Server FWEX2 | Set-MailboxDatabase -Name MBDB02

7

Danach kann die Datenbank verschoben werden, das Verschieben funktioniert nur auf dem Exchange Server, der gerade die Datenbank hostet, der folgende Befehl muss also auf jeweiligen Exchange Server ausgeführt werden:

Get-MailboxDatabase -Server FWEX1 | Move-DatabasePath -EdbFilePath d:\MBDB01\MBDB01.edb -LogFolderPath d:\MBDB01
Get-MailboxDatabase -Server FWEX2 | Move-DatabasePath -EdbFilePath d:\MBDB02\MBDB02.edb -LogFolderPath d:\MBDB02

8

Jetzt sollte es in der EAC ungefähr so aussehen:

9

Jeder Exchange Server hostet seine eigene Datenbank, MBDB01 ist auf FWEX1 aktiv und MBDB02 auf FWEX2. Jetzt kann die DAG angelegt werden:

15

Als Database Availability Group Name wird der Name des eben erstellten Computer Kontos angegeben, Zeugenserver ist FWFS1 und das Zeugenverzeichnis soll unter C:\Wittness liegen (oder wo auch immer). Mit Exchange 2016 soll es möglich sein, die DAG auch ohne Cluster IP zu betreiben, ich vermute aber mal das wird sich auf Server 2016 beziehen, ich musste sie angeben.

Der frisch angelegten DAG müssen jetzt die Exchange Server zugewiesen werden:

16

Beide Exchange Server auswählen und hinzufügen:

17

Das Hinzufügen der Server dauert etwas

19

20

In der EAC sollte es jetzt so aussehen, FWEX1 und FWEX2 sind Mitglieder der DAG.

21

Zum Schluss müssen noch die Datenbankkopien konfiguriert werden:

22

Hinweis: Wer den Menüpunt „Datenbankkopie hinzufügen“ nicht sieht, einmal EAC neustarten.

Für beide Datenbanken den jeweils anderen Server hinzufügen und Speichern

23

Die DAG ist jetzt fertig. Die Tests können beginnen.

24

Der nächste Beitrag wird sich dann um das Loadbalancing drehen.

28 Kommentare zu “Exchange 2016: Konfiguration einer DAG (Database Availability Group)”

  1. Hat jemand eine Idee zu der Fehlermeldung

    „Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. “

    es werden keine Eigenschaften der DAG auf der Detailseite angezeigt

  2. Hi Michael,
    ich würde dir dafür einen Loadbalancer empfehlen, z.B. den Kemp (https://kemptechnologies.com/de/), gibt es zum Probieren auch als freie Variante oder auch den HAProxy (http://www.haproxy.org/) als freie Alternative. Es gibt natürlich auch noch viele andere, die beiden haben wir hier im Einsatz.
    Damit kannst du deinen Traffic aber gut verteilen und hast für alle Services einen Einstiegspunkt. Dort kannst du dein Autodiscover dann ausfallsicher auflaufen lassen und auch deine MXen darauf setzen, egal, wie viele DAG-Member du dahinter hast. Auch sehr angenehm, wenn man mal z.B. zur Wartung einen rausnehmen will.

  3. Hallo,
    ich möchte gerne meine erste DAG machen, bevor ich beginne habe ich noch die Frage wie es mit dem MX Record und Autodiscover funktioniert. Derzeit verweist mein MX Record auf den einen Exchange 2016 Server den ich habe gleich gilt auch für das Autodiscover, wenn ich jetzt einen weiteren Exchange Server installiere benötige ich dann einen weiteren MX Record und autodiscover Link? Bzw. wie finden die eingehenden Mails den Weg zum Client wenn der Server auf den der MX Record zeigt down ist?
    Vielen Dank Franky für die tolle Seite, sie ist super erklärt und hilfreich.
    Vielen Dank.
    LG Michael

  4. Hallo zusammen,

    habe folgende Situation:
    Exchange Version 15.0 ‎(Build 1365.1)‎ CU19
    und
    Exchange Version 15.1 ‎(Build 1415.2)‎ CU8

    Folgenden Fehler gibt er raus:
    „EX02“ kann der Datenbankverfügbarkeitsgruppe „DAGtest“ nicht hinzugefügt werden, weil mindestens eins der aktuellen Mitglieder eine andere Exchange-Version hat. Version von „EX01“: Version 15.0 (Build 1365.1). Version von „EX02“: Version 15.1 (Build 1415.2).

    Geht es gar nicht? oder habe ich etwas nicht beachtet?

  5. Hallo zusammen,
    ich habe das gleiche Problem wie Udo, nach dem hinzufügen des ersten Server in die DAG. „Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt“
    Hat da einer schon eine Lösung?

  6. Hallo Frank,
    wie immer Top Anleitung. Ich hätte tatsächlich noch eine Frage und sogar eine Anmerkung.

    Zur Frage:
    Wofür wird die Cluster IP eigentlich benötigt? Sollte man die Cluster IP vielleicht im DNS für das Autodiscover hinterlegen oder hat die Cluster IP nichts mit einem Balancing zu tun sondern ist nur organisatorisch?

    Dann eine Anmerkung:
    Auch wenn man extra eine Netzwerkkarte für die Replikation anlegt, so kann auch die Karte im Produktiv Netz dafür genutzt werden, ist mir ganz zufällig aufgefallen.
    Mit Get-DatabaseAvailabilityGroupNetwork -Identity DAGNAME wird es dann deutlich. Wir haben die Konfiguration von automatisch auf manuell geändert und für die Replikation ausschließlich die extra angelegte Netzwerkkarte zugewiesen.
    Das haben wir so erledigt:
    Set-DatabaseAvailabilityGroup DAGNAME -ManualDagNetworkConfiguration:$true
    Set-DatabaseAvailabilityGroupNetwork -Identity „DAGNAME\MapiDagNetwork“ -ReplicationEnabled:$false -IgnoreNetwork:$true

    Ist vielleicht ein nice to know!

  7. Super Artikel, danke dafür!
    Ich hab ein Problem bei meiner Installation: wenn ich die DAG angelegt und den ersten Server hinzugefügt habe, steht im EAC, wenn ich die DAG markiere, die Meldung „Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.“ und es werden keine Eigenschaften der DAG auf der Detailseite angezeigt.
    Ich hab schon überall gesucht, konnte dazu aber nirgends was finden. Kennt das einer? Wie bekomme ich das weg?

  8. Hallo Frank,
    wieder mal eine tolle Anleitung die wir demnächst in unserer Testumgebung mal nachbauen werden.
    Uns drängt sich aber eine Frage auf:
    Wenn wir einen Datenbankschwenk auslösen, was passiert mit den Anmeldungen der Clients am Exchange? Müssen diese Outlook schließen und wieder öffnen weil die Anmeldung ja jetzt eigentlich am zweiten Exchange erfolgen muss? Oder wird beim Datenbank Schwenk auch die Anmeldung durchgereicht?
    Wäre schön wenn du mir das kurz beantworten könntest.

    Grüße
    Andreas

  9. Hallo Frank.
    Vielen Dank für deine Hilfestellung. In der Zwischenzeit konnte ich das Problem lösen, und bin deinem Rat gefolgt, indem ich die Postfächer verschoben habe. Die Ursache waren die Systemkonten „Federated und Migration“ außerdem hatte ich in der AD noch verwaißte Syystemkonten der alten 2010er DAG gefunden, obwohl ich diese sauber aus dem AD entfernt hatte und die Exchange 2010 deinstalliert hatte. Naja, ich habe also sämtliche Systemkonten deinstaliert und anschließend aus de, exchange/bin Verzeichnis eine erneutes prepareAd ausgeführt und im Anschluss die neuen Sytemkonten konfiguriert. Danach funktionierte alles wieder.
    Gruß, Michael

  10. Hallo Frank.
    Danke für die Antwort. Die Idee hatt ich auch schon. Allerdings habe ich folgendes Problem: Beim verschieben eines Postfachs von Mailbox1 zu Mailbox2 bkomme ich folgende Fehlermeldung:“Für diese Organisation wurden mehrere potenzielle Migrationspostfächer gefunden.
    Geben Sie bitte ein bestimmtes Partitionspostfach an, das verwendet werden soll.“
    Bisher gemacht habe ich folgendes: Systemmailboxes gelöscht und neu angelegt; In der AD nach Migrationsmailbox gesucht, fazit: Es ist nur eine zu finden.

    Insofern ich dazu keine Lösung habe, möchte ich die Datenbanken auf neue Volumes verschieben. Da bin ich mir aber nicht sicher wie der beste Weg aussieht.

    Gruß, Michael.

    1. Hi Michael,
      Ich würde dir empfehlen das Problem mit dem Verschieben der Postfächer zu lösen und dann neue Datenbanken auf dem neuen Storage zu erstellen. (Der neue Storage bzw. das Verschieben der Datenbanken wird nicht das Problem mit dem Verschieben der Postfächer beheben, falls das die Intention für das Verschieben der Datenbanken ist). Das Problem mit Verschieben der Postfächer lässt sich aber meist einfach lösen. Schick doch mal die Ausgabe von „get-mailbox -Arbitration | fl name,PersistedCapabilities“. Dann kannst du ja immer noch entscheiden ob du die Datenbanken lieber offline nehmen willst und dann verschieben, oder neue Datenbanken erstellst und die Postfächer verschiebst.
      Gruß, Frank

  11. Nochmal ich.
    MIr ist ein kleiner Schreibfehler unterlaufen: Es soll natürlich heissen nach dem verschieben der Datenbanken…und dann neue Kopien erstellen.

    1. Hallo Michael,
      du kannst zwar die Datenbanken verschieben, aber wäre es nicht einfacher eine neue Datenbank am neuen Speicherort zu erstellen und dann die Postfächer zu verschieben? Dann brauchst du keine Downtime…
      Gruß, Frank

  12. Hallo zusammen.

    Auch von mir ein dickes Lob an Franky und seine Website. Tolle Erklärungen und Ideen, und zudem ein sehr schöner Erfahrungstausch.
    Ich betreibe der zeit eine 2016 DAG mit 2 Exchangeservern und einem Whitness, die jeweils 6 Datenbanken verwalten. Eingebunden auf Mountpoints.
    Leider besteht mitlerweile die Notwendigkeit, dass ich die Datenbanken auf neue Volumes verschieben muss. Hier bin ich mir bezüglich der Vorgehensweise etwas unsicher und würde mich über Hilfestellung freuen.
    Ich gehe davon aus das ich die Bindung der Datenbanken aufheben muss und die Logs wohl gelöscht werden müssen…Stimmt das soweit? Aber was mache ich mit den Datenbankkopien? Auch löschen und nach dem Verschieben der Datenbankkopien wieder einbinden?

    Ich bedanke mich schon mal im Vorraus für jede Hilfestellung.

    Beste Grüße, Micha.

  13. Hi,

    wir haben Server 2012 R2 mit Exchange 2016 (4 Stück) mit jeh 2 Netzwerkkarten (Mapi und Replication).

    Die DAG-Netzwerke haben wir automatisch konfigurieren lassen, allerdings auch mit einer IP und keine IP-less-DAG
    Der DAG haben wir nun eine IP aus dem selben Subnet wie das MAPI netz gegeben. (10.0.253.27/24)

    Braucht die DAG auch eine IP im Replikationsnetzwerk, oder nur im MAPI (10.10.10.0/24)

    Grüße
    Tobias

  14. @Roland
    Du kannst mittels „Set-DatabaseAvailabilityGroup EXCHDAG01 -ManualDagNetworkConfiguration:$true“ die manualle Configuration aktivieren und dann für das entsprechende Netzwerk die Replikation bzw. die MAPI zugriffe deaktivieren „Set-DatabaseAvailabilityGroupNetwork -Identity „EXCHDAG01\MapiDagNetwork“ -ReplicationEnabled:$false -IgnoreNetwork:$true“

    Guck mal hier:
    http://www.admin-enclave.com/en/articles/exchange/206-migrate-from-exchange-2010-to-exchange-2016.html
    Bei Punkt 13f

  15. Hallo und Guten Tag,
    mich würde einmal interessieren, woher weiß der Exchange oder die DAG denn nun, dass es zur Replizierung der Datenbank jetzt das andere Netzwerk nehmen soll?
    Habt Ihr da eine Info für mich?
    Vielen Dank
    Gruß
    Roland

  16. Wenn die Datenträger / Partitionen / Volumes für die Exchange DBs im ReFs Layout vorliegen muss die DAG entsprechend so konfiguriert werden. „[PS] C:\>Set-DatabaseAvailabilityGroup -FileSystem ReFs“

  17. Hallo & guten Abend,

    als erstes möchte ich erstmal ein ganz großes Lob an Franky aussprechen. Das sind super How-To’s wo sich der Hersteller mal eine Scheibe abschneiden könnte. Echt prima. Vielen lieben Dank für die Mühe.

    Ich hab ein Problem mit einer Failoback Situation einer 2016er Exchange CU3 DAG auf 3 Server 2012 R2 mit allen Updates & Hotfixes. Microsoft Ticket ist schon seit gut 2 Wochen in Bearbeitung, aber da fehlt es meiner Meinung nach am grundlegenden Sachverstand. Deswegen meine Frage hier an die echten Pros:
    Folgende Situation:
    1 * MAPI Netzwerk IP im LAN
    1 * Replikations IP im isolierten Netz nur für die Exchange Server
    DAG über 3 Server angelegt mit je einer IP im selben Netz (LAN & Repliaktion)
    Je Server eine Mailboxdatenbank angelegt
    Je eine Replikationen auf die 2 verbleibenden Server

    Dann ist alles grün. DAG funktioniert in jeglicher Hinsicht & beide IP-Adressen der DAG aus den Netzen (LAN & Replikation) sind pingbar, Failover-Cluster Manager ist auch alles bestens.

    Dann simuliere ich einen Failover und starte den ersten Server im Bunde neu. Der hat anscheinend eine Art Master Quorum Funktion.

    Danach fehlt dieser Knoten logischerweise erstmal bis er wieder online ist. Die Replikationen werden in der Zwischenzeit aktiviert & alles läuft weiter bis auf den Ping auf die Replikations-IP.

    Wenn der Knoten dann wieder on ist und ich im Failover-Cluster Manager dann die Replikations-IP wieder aktivieren will kommt folgender Fehler zur Replikations-IP der DAG:

    Die Cluster-IP-Adressressource „Cluster-IP-Adresse „10.254.0.74““ kann nicht online geschaltet werden, da die Konfiguration des Clusternetzwerks „Clusternetzwerk 2“ den Clientzugriff nicht zulässt. Verwenden Sie das Snap-In „Failovercluster-Manager“, um die konfigurierten Eigenschaften des Clusternetzwerks zu prüfen.

    Im Ereignis-Log gibt’s das noch dazu:
    [RES] IP Address : Cannot bring resource online because network 95b417df-430b-4ab1-ad36-3d73bd2e495b (Clusternetzwerk 2) has role 1.

    [RHS] Resource Cluster-IP-Adresse „10.254.0.74“ has indicated that it cannot come online on any node.

    [RCM] HandleMonitorReply: ONLINERESOURCE for ‚Cluster-IP-Adresse „10.254.0.74“‚, gen(0) result 5943/0.

    Wie gesagt vor dem Restart des ersten Knoten war noch alles gut. Danach bekomm ich das Teil nicht mehr Online. Somit findet keine Replikation mehr statt da dies auf keinen Fall über das LAN laufen darf.

    Wenn Ihr mir bei diesem Problem zur Seite stehen könntet….Ich wäre Euch unendlich Dankbar.

    Vielen Dank noch mal für die super Anleitung & hoffentlich für kompetente Hilfe ;)

    Das Problem überschreitet die Kompetenzen des Microsoft Supports. Leider traurig aber wahr.

    Dann wünsche ich allen Pros einen schönen Feierabend & VG

    Christoph

  18. Ich habe irgendwo gelesen das Exchange 2016 nur noch eine NIC haben sollte und nicht mehr zwei … sprich die Auftrennung in das Normale LAN und in ein Replications LAN entfällt. Du hast es aber aufgetrennt. Was macht man jetzt am besten?

    1. Hi Bernd,
      technische gesehen funktioniert es auch mit einer Netzwerkkarte, auf dem Exchange Team Blog unter dem Punkt „DAG Network Design“ findet sich auch der entsprechende Hinweis:
      http://blogs.technet.com/b/exchange/archive/2015/10/12/the-exchange-2016-preferred-architecture.aspx
      Im TechNet liest sich es schon wieder etwas anderes, hier ist der Punkt „Network requirements“ interessant:
      https://technet.microsoft.com/en-us/library/dd638104(v=exchg.160).aspx
      Ich tendiere immer noch zur Trennung zwischen MAPI und Replikations Netzwerk, also im Prinzip klassisch FrontEnd und BackEnd, so kommt sich nichts in die Quere falls mal etwas unvorhergesehenes passiert.
      Allerdings haben 2 Netzwerkkarten auch Nachteile, es lässt sich nur ein Default Gateway setzen, andere Netze müsssen ggf. per Routen gepflegt werden, wenn eine DAG beispielsweise über mehrere Standorte gespannt wird. Das ist natürlich komplexer und somit auch anfälliger für Fehler. Es kommt also wie so oft auf die Umgebung und die Anforderungen an.
      Gruß, Frank

    1. Hi Patric,
      ja, ich hab einen F5 BigIP LTM und einen Kemp Loadmaster mit ESP stehen. Mir gefallen die F5 persönlich besser, aber das wird Geschmackssache sein.
      Ich werde das Loadbalacing noch gesondert betrachten.
      Gruß, Frank

  19. Super Beitrag!
    Was für eine OpenSource LoadBalancer Lösung kannst du empfehlen. Ich habe bisher immer nur Exchange CAS (in CAS-Array) über MS NLB betrieben ohne weitere Rollen auf diesen CAS – Servern.
    Danke und Gruss aus der Schweiz!
    André

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.