The configuration of an Exchange 2016 DAG is almost identical to the configuration of a DAG with Exchange 2013. In principle, it is even somewhat simpler, because the question of whether the roles should be separated or whether all roles can be installed on one server no longer arises with Exchange 2016. There is now only the mailbox role. However, load balancing between the CAS service using the Windows load balancing feature still does not work, as fail-over clusters and Windows load balancing on the same server are mutually exclusive. It is therefore still advisable to connect a load balancer upstream, as the requirements of Exchange 2016 for a load balancer are low (layer 4 is completely sufficient), there are good open source solutions. But now to the DAG. I have created a test network consisting of 4 VMs:
All VMs are running Windows Server 2012 R2. FWDC1 is the domain controller with a network card in the production VLAN, FWFS1 is a member server, so far without special configuration with a network card in the production VLAN. FWEX1 and FWEX2 are to become the DAG members, the two servers each have 2 network cards, one in the production VLAN and a dedicated network card for the replication of the DAG.
The Active Directory is already installed and configured, so let's start with the configuration of the two Exchange servers.
The network card for the replication network is configured as follows:
Only a fixed IP address from a different subnet than the production network is assigned, all protocols except TCP/IPv4 are deactivated.
In addition, the "Register addresses of this connection in DNS" checkbox is removed. An additional drive is created for the databases, in my case drive D: (must be identical on both servers)
The drive for the databases and log files is formatted with ReFS:
That was all the preparations for the Exchange servers. Exchange can now be installed on the first server. The Exchange installation is identical to my instructions which can be found here:
https://www.frankysweb.de/exchange-2016-installation-auf-windows-server-2012-r2/
Once Exchange 2016 has been installed on both servers, the file server (FWFS1) can be prepared. The "Exchange Trusted Subsystem" group must be added to the local "Administrators" group
In addition, the following firewall rules must be activated, if not already done:
- File and printer sharing (SMB incoming)
- Windows Management Instrumentation (WMI in-depth)
- Windows management instrumentation (DCOM incoming)
- Windows management instrumentation (ASync incoming)
Now the computer account for the DAG can be prepared by creating a computer account in the Active Directory with the name of the DAG. In my case this is FWDAG1, the computer account must be deactivated after creation.
The "Exchange Trusted Subsystem" group also has full access to the DAG computer account
Note: If you do not see the Security tab, you must activate the "Advanced features" under View.
Before the DAG can be configured, the databases must be moved to their destination and the name can be changed at the same time:
Get-MailboxDatabase -Server FWEX1 | Set-MailboxDatabase -Name MBDB01 Get-MailboxDatabase -Server FWEX2 | Set-MailboxDatabase -Name MBDB02
The database can then be moved. Moving only works on the Exchange server that is currently hosting the database, so the following command must be executed on the respective Exchange server:
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
Now it should look something like this in the EAC:
Each Exchange server hosts its own database, MBDB01 is active on FWEX1 and MBDB02 on FWEX2. The DAG can now be created:
The Database Availability Group Name is specified as the name of the computer account just created, the witness server is FWFS1 and the witness directory should be under C:\Wittness (or wherever). With Exchange 2016 it should be possible to run the DAG without a cluster IP, but I assume this will refer to Server 2016, I had to specify it.
The Exchange servers must now be assigned to the newly created DAG:
Select and add both Exchange servers:
Adding the servers takes some time
In the EAC it should now look like this, FWEX1 and FWEX2 are members of the DAG.
Finally, the database copies must be configured:
Note: If you do not see the menu item "Add database copy", restart EAC once.
Add and save the other server for both databases
The DAG is now ready. The tests can begin.
The next article will then focus on load balancing.
Ich schaffe es nicht die verfluchten DCOM 10028 Meldungen aus den Eventlogs zu verbannen, hat dazu vielleicht jemand eine Lösung?
Das AD Computer Objekt DAGxxx ist deaktiviert, interessiert den Servermanager aber nicht. Ich entferne den virtuellen DAGComputer aus dem Servermanager und er taucht wieder auf, so auch die Fehlermeldungen:
DCOM konnte über keines der konfigurierten Protokolle mit dem Computer XXXDAG.local kommunizieren. Während der Aktivierung von CLSID {8DF3A05B-D86B-11D0-A075-00C04FB5682A} von PID 31f4 (C:\Windows\system32\ServerManager.exe) angefordert.
Hi erstmal großes Lob an Franky wie immer für seine Super Anleitungen.
Wir hatten vor einiger Zeit auch 2 Exchange 2016 eingerichtet, jetzt sollten die in einer DAG zusammengefasst werden.
alles komplett nach Anleitung eingerichtet, Zertifikate alles valid,DAG Replikations-Netzwerk laut Cluster alles up und gut aber ich schaffe es nicht eine DB Kopie zu erstellen,
es kommt immer der Fehler das keine sicherer Kanal eingerichtet werden kann.
beim Test am Server1 mit: Test-ReplicationHealth -Identity server2
TcpListener *FEHLER* Fehler beim Statustest des TCP-Listeners für den Microsoft
Exchange-Replikationsdienst auf Server ’server2′. Dieser
Server kann erst an der Replikation teilnehmen, nachdem der
Fehler behoben wurde. Fehler: Fehler beim Kommunizieren mit dem
Server ’server2′. Fehler: Es konnte kein sicherer Kanal
eingerichtet werden.
beim Test am Server 1 kommt ganz normal
TasksRpcListener Prüfung
bestanden
Was hat es mit dem sicheren Kanal auf sich, dass das seeden einer Datenbank verhindert?
Hallo Frank, ich habe mittlerweile schon einige deiner Artikel umgesetzt und auch als Basis (natürlich mit Verweis auf deine Seite) für meine Blogbeiträge genommen unter http://www.leibling.de .
Nun befasse ich mich mit dem Thema HA eines Netzwerkes, unter anderem mit dem Thema DAG – jedoch finde ich keine Informationen zu folgenden Themen:
a) FSW, wenn ich das an EINEN Server binde, ist das dann nicht ein Single Point of Failure?
b) Was passiert wenn der Witness-Server nicht da ist?
c) Kann ich das FSW nicht auf eine DFS Freigabe zeigen lassen?
Weiterhin würde mich interessieren, warum bei den vielen beispielen oft eine IP lose Konfiguration bevorzugt wird?
Danke dir vielmals :).
Hi Peter,
der Witness ist prinzipiell ja nur im Fehlerfall zur Bildung eines gültigen Quorums nötig. Deswegen wird z.B. bei ungeraden Knotenzahlen größer zwei gar kein Witness benötigt (und daher im FSW auch kein Verzeichnis angelegt), da sich in dieser Konstellation die Knoten selber einigen können, wer denn nun „weg“ ist. Das Problem eines Clusters und die Notwendigkeit des Witness sieht man am besten bei zwei Knoten (und damit prinzipiell auch jeder anderen geraden Knotenanzahl): ist die Verbindung zwischen beiden unterbrochen, kann kein Knoten von sich aus sagen, wer denn nun ausgefallen ist (z.B. wenn beide Server noch laufen und bei einem die Netzwerkkabel gezogen wurden). Es kann jedoch nur noch der eine *mit* Kabel die Dienste anbieten. Bei drei wäre es klar, da können sich dann zwei noch unterhalten und damit ihr „Leben“ feststellen. Da kommt dann bei zweien der Witness ins Spiel. Wer den noch erreichen kann, ist der lebende, der andere muss die Ressourcen loslassen und ggf. seine Dienste runterfahren.
Das betrachtend führt ein fehlender Witness im laufenden Betrieb zu keinen Problemen, allenfalls zu Warnmeldungen. Nur, wenn in diesem Moment der Cluster ein Problem hat, wird es schwierig(er), ein gültiges Quorum zu bilden.
Idealerweise nimm eine ungerade Knotenanzahl, dann wird das auch gar nicht benötigt :)
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
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.
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
Nee, das geht nicht. Guck mal hier: https://docs.microsoft.com/en-us/exchange/high-availability/database-availability-groups/database-availability-groups
Zweiter Absatz: In einer DAG müssen alle Server in der gleichen Version sein. Daher kannst du eine 2013er DAG auch nicht „weich“ in eine 2016er migrieren, sondern musst eine neue 2016er aufsetzen, dann die Postfächer rüberschieben und am Ende die leere 2013er DAG wegschmeißen.
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?
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?
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!
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?
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
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
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.
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
Nochmal ich.
MIr ist ein kleiner Schreibfehler unterlaufen: Es soll natürlich heissen nach dem verschieben der Datenbanken…und dann neue Kopien erstellen.
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
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.
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
@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
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
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“
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
Eine IP-lose DAG kannst du erstellen, indem du als IP die 255.255.255.255 angibst. Das funktioniert ab Server 2012 R2.
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?
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
Schau dir mal Kemp (http://kemptechnologies.com/de/) an. Mit dem arbeite ich die meiste Zeit.
Gruß
Patric
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
Hallo André,
schau Dir mal HA-Proxy oder loadbalancer.org an.
Gruß
Marcel
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é
Hi André,
da wäre auch noch Zen: http://www.zenloadbalancer.com/
Gruß, Frank