Exchange 2019 has adopted the familiar principle of the Database Availability Group (DAG). There are no major changes to the DAG. However, something has changed in the databases. The index is now part of the database and no longer ghosts around separately in the file system. Exchange 2019 also offers the option of using SSDs as a database cache (MetaCache Database, MCDB), but this only works with a DAG.
This article is dedicated to the configuration of an Exchange 2019 DAG consisting of two servers. The MetaCache Database (MCDB) is then part of further articles.
Surroundings
The Exchange 2019 test environment consists of a total of 4 servers: one domain controller (DC1), 2 Exchange servers (EX1, EX2) and one file server (FS1). All servers use Windows Server 2019 as the operating system.
The Active Directory is named frankysweblab.de. A load balancer for the high availability of the CAS service is not initially part of this test environment; I will first use the DNS here. More on this later.
The two Exchange servers were installed after this manual installed, the basic configuration of the two Exchange servers has also already been completed and relates to these instructions. Both Exchange servers were configured with the same URLs and both Exchange servers were added to the send connector as source servers.
Only the "File server" role is installed on the FS1 server.
For the sake of completeness, here are the IP addresses of the servers:
- DC1: 192.168.200.12
- FS1: 192.168.200.13
- EX1: 192.168.200.14
- EX2: 192.168.200.15
A client with Outlook 2019 installed is available for testing.
Preparation
The first step is to prepare the FS1 file server. The "Exchange Trusted Subsystem" group must be added to the local "Administrators" group on the server:
And that is all. FS1 will provide the witness directory for the DAG. It is important that the FileServer role is installed on the FileServer, otherwise an error message will appear when the DAG is created:
The witness directory in a 2-server DAG is used to determine which of the two servers has failed in the event of an error. The witness directory must not be stored on a domain controller, as otherwise the "Exchange Trusted Subsystem" group would also receive far-reaching authorizations to the Active Directory via the Administrators group. It is therefore better to select an existing file server for the witness directory.
Configuration of the DAG
Creating the DAG is very simple. A new DAG can be created under the "Database Availability Groups" tab using the "plus sign". You only need to enter a name for the DAG, the FQDN of the witness server (in this case FS1) and a path for the witness directory. Enter 255.255.255.255 in the IP address field to create an IP-less DAG:
Once the DAG has been created, the member servers can be added:
In this case, both Exchange servers must now be specified as members of the DAG:
After clicking on "Save" the servers are added to the DAG, this may take a moment. If an error occurs here, please read the tip at the end of this section.
After a few minutes, the two servers are configured as members of the new DAG:
This provides the basic framework for the database copies.
To enable the databases to be activated on another Exchange server in the event of a failure or for maintenance purposes, a copy of each database must be created on the other server. This is done in the next step.
Tip: The following error may occur when adding the Exchange Server to the DAG:
Error during the server-side administration process for a Database Availability Group. Error: Error during operation. CreateCluster errors can be caused by incorrectly configured static addresses. Error: Windows failover clustering is not installed on 'EX1.frankysweblab.de'.
In this case, the Exchange servers must be restarted once. Although the "Windows Failoverclustering" feature is installed when the servers are added to the DAG, it requires the server to be restarted:
After the servers have been restarted, the servers can be added to the DAG.
Add database copy
For Exchange databases to be highly available, there must be at least one copy on another Exchange server. The database copies can now be configured, the settings can be made individually for each database. In a 2-server DAG, the options are of course very limited, here only the other server can host a copy of the active database.
Important: An Exchange 2019 server in the Standard Edition can only host a maximum of 5 active databases. This means that only a maximum of 5 databases may be created here, so in this example EX1 may only host 3 active databases and EX2 only 2 active databases. In the event of an error, 5 databases would therefore be active on an Exchange Server. Exchange Server in the Enterprise Edition does not have this limit.
The database copies can also be configured in the Exchange Admin Center on the "Databases" tab:
The Exchange server for the copy can now be specified here:
The database and the log files are now transferred to the server for the copy:
Tip: If the DAG is configured retrospectively and the databases already contain some mailboxes / data, it is advisable to add the copy after the full backup. This means that not so many logs have to be copied from server to server.
After both databases have a copy, the status is displayed in the Exchange Admin Center as follows:
The tests can now begin.
A distinction can be made here between switchover and failover. The switchover is a planned event, for example for maintenance purposes. In a switchover, the active copy is deliberately moved to another server. Failover occurs, for example, if the hardware fails and an Exchange server suddenly goes down.
Test switchover
After the database copies have been added, you can first test moving a database (switchover). To do this, the copy of the database is activated in the Exchange Admin Center:
After clicking on "Activate", a security prompt is displayed:
After a few seconds, the passive database is activated. The previously active database thus becomes passive:
In this case, Outlook in "Online mode" displays the message "Connection attempt" for about 1 second:
After approx. 1 second Outlook is reconnected without cache mode. The screenshots are actually two switchover processes, recognizable by the time: 22:11 and 22:12, I was a bit too slow with the screenshots...
If Outlook is running in cache mode, Outlook does not notice this brief interruption.
I have created a short video so that the switchover is easier to understand:
Test failover
For the failover test, I switched off the server with the active database. The failover of the database takes a little longer than the switchover, here Exchange must first detect the failure of a server and then integrate the database. However, Outlook in online mode is also unimpressed by this. I have also created a short video to make the process a little easier to understand:
DNS settings for the Client Access Service
I mentioned at the beginning that I do not use a load balancer for the Client Access Service, but use the DNS instead. The DAG only protects the databases from failure, the Client Access Service must be considered separately.
Normally, you would connect a cluster of at least two load balancers upstream to make the Client Access Service highly available. Here in this test environment, however, this also works via DNS round robin, which is not ideal and there is no real load balancing, but this is sufficient for a simple test environment.
So there are simply two entries in the DNS for Autodiscover and Outlook, each with the IPs of the two Exchange servers:
DNS Round Robin is activated by default:
If you are really clever, you could also use DNS policies for "load balancing":
However, I would always prefer a load balancer here. You can also use a small Linux VM with HAProxy or similar for test environments.
Kann man mehrere ip less DAGs haben? z.B. migrations zwecke eine für 2016 und eine weiter mit 2019 ertellen? Oder wird die esrte automtisch übnerschrieben da 255.255.255.255 schon besteht?
Hallo Zusammen,
ich scheitere an der DB Kopie auf dem zweiten Server
Fehler der speicherort für logfolderpath befindet sich nicht auf einem festplattenlaufwerk.
Server 1 2 Platten , C und D (alles Exchange ist auf D)
Server 2 1 Platte alles auf c….
muss Server im Plattenlayout exakt gleich sein?
Hallo Holger,
die Pfade und Laufwerksbuchstaben müssen gleich sein.
Beste Grüße,
Frank
nein, kannst du natürlich in einer Powershell machen. Die Move-Requests werden nach und nach im Hintergrund abgearbeitet. Den Stand kann man sich jederzeit ansehen. Du kannst alle auf einmal losschicken, oder auch einzeln (sinnvoll sicher erstmal für die ersten Testaccounts) oder auch datenbankweise, ganz nach deinem Geschmack.
Die Nutzer merken davon normalerweise auch nichts, wenn sonst alles richtig eingerichtet ist. Zumindest war es bei mir von 2013 nach 2016 so, aber ich wüsste jetzt auch keinen Grund, warum das nach 2019 anders sein sollte.
Hallo zusammen,
mir ist das grundsätzliche Verfahren noch nicht ganz klar, deshalb frage ich lieber nach und bin für jeden Input dankbar: ich habe eine Exchange 2016 DAG mit vier Servern und mehrere Datenbanken mit Kopien auf allen vier Servern. Wenn ich die neuen Exchange 2019 Server nicht in die bestehende DAG aufnehmen kann, sondern eine neue erstellen muß, wie bekomme ich dann die Datenbanken von der alten in die neue DAG? Der normale Weg über „neue Datenbankkopie erstellen“ geht ja in dieser Konstellation nicht.
Viele Grüße,
Michael
gar nicht. du legst neue DBs in der neuen DAG an und schiebst alle Mailkonten (einschließlich der Systemmailboxen) in dies(e) neue(n) DB. Die alten haust du dann weg, wenn mit den neuen alles funktioniert.
Danke für die schnelle Antwort. Wenn ich das richtig verstehe, geht es also nur über Move-Requests. Ich habe 25 Datenbanken mit je um die 300 Nutzer. Kann ich da die Nutzer einer DB per Powershell moven oder wird das zu viel und ich muß es irgendwie „quanteln“?
Viele Grüße,
Michael
Moin Moin,
hat wer Erfahrungen mit DAG´s an geografisch unterschiedlichen Lokationen?
Bsp.:
Site A:
DAG-Node A
DAG-Node B
Loadbalancer für NodeA und NodeB;
DNS Name ist exchange.Meinedomain.local im Loadbalancer hinterlegt
Site B
DAG-Node C
DNS Name ist exchange.Meinedomain.local
Wenn nun ein Client aus SiteB sich mit der DAG verbindet gelangt sein Packet zwangsweise beim Loadbalancer; doch was passiert dann?
Über welchen Server versendet der Client seine Mails?
Achtung Fallstrick: Bei einer Migration EX2013 -> EX2019 mit Einrichtung einer DAG2019 „bevor“ die Postfächer migriert wurden, trifft man auf das Problem, dass man keine Datenbank Kopien erstellen kann.
Lösung: Man muss zuerst ein Postfach eines Benutzers mit entsprechenden Rechten auf einer DB2019 einrichten oder migrieren und sich mit diesem Benutzer an der EAC anmelden.
Hat ne Weile gedauert, bis ich auf die Lösung gestoßen bin…
VG Bernie
Hallo zusammen, ich schließe nicht aus, dass ich zu doof dafür bin :D aber ich habe noch meine Testumgebung für die Migration übrig gehabt. Jetzt wo auch das Echtsystem fertig ist, wollte ich mir das DAG einmal anschauen.
Ich hab in meiner Testumgebung einen Exchange 2019 als Core gehabt. Ich habe einfach einen zweiten Server 2019 mit Exchange 2019 installiert (hier konnte ich keine Organisation mehr auswählen, da ja schon in der Domäne vorhanden). Links identisch gesetzt… Connectoren identisch… (beideseitig eingetragen wie bei der Migration, sofern überhaupt nötig?!).
Jeder Server hat seine eigene DB (Namen sind NICHT identisch).
DAG aufgebaut nach der Anleitung und bei dem Punkt „Datenbankkopie erstellen“ stopt alles mit dem Hinweis, dass schon Logs vorhanden wären mit gleichem Namen. Äh?! Wie kann das sein, ab welchem Punkt habe ich hier einen Fehler gemacht?
Gruß Mike
Hi Basti,
das ist nur ein Beispiel. Es geht auch mit nur einer DB (die allerdings dann in der DAG repliziert wird, aber das sind eben die Kopien, die du mit dem o.g. Befehl einsehen kannst). In diesem Fall sind es wohl zwei, weil auf jedem Server nach der Installation eine Standard-DB vorhanden ist, die Frank in seinem Installationsbeispiel halt einfach umbenannt hat in DB01 und DB02. Genauso gut hätte er eine umbennen und eine löschen oder eine neue anlegen und die Standard-DBs im Anschluss löschen können (nach übertragen der Systemmailboxen natürlich).
Ich glaub, du verstehst da was grundsätzlich falsch: Du kannst auf *einem* Exch-Server dutzende Datenbanken haben, die nichts miteinander zu tun haben. Dort verteilst du dann deine Nutzer. Es kann aber sehr gut auch nur eine DB sein. Hat man eine DAG eingerichtet, kann man für jede dieser DBs Kopien auf beliebige Mitgliedsserver der DAG verteilen – die sind dann synchron und bringen die Sicherheit. Mehrere DBs hat man im Fall einer DAG z.B. zu Zwecken der Lastverteilung, indem man die User dann auf die DBs aufteilt und im vorliegenden Fall z.B. auf jedem Knoten jeweils die aktive Kopie der DBs hält, so dass man eine Lastverteilung erreicht.
Ansonsten lies dich vielleicht nochmal in das Konzept von DAGs ein, das würde hier sonst bisschen weit führen, das im einzelnen zu erklären.
@Udo
das habe ich verstanden, dachte nur das die zusätzlich synchronisiert werden aber macht ja kein Sinn, daher habe ich noch mal gefragt. Gut erklärt, Danke Dir :)
@Basti
Die synchronisieren sich gar nicht, das sind ja zwei völlig verschiedene Datenbanken. In einer DAG wird von der DB01 und der DB02 in diesem Fall auf jedem DAG-Member(Server) eine Kopie gehalten, wovon jeweils eine immer die aktive ist.
Anschauen kannst du dir das mit
Get-MailboxDatabaseCopyStatus DB*
Da bekommst du für beide Datenbanken (db*) alle Kopien, mit Servernamen und den Mount- und Indexstatus angezeigt. Wenn da überall „Healthy“ bzw. „Mounted“ steht, is alles fit und die Kopien sind in Ordnung.
@Udo
Danke für die Antwort aber ich verstehe dann nicht wozu 2 DB´s benötigt werden wenn diese sich nicht synchronisieren?
Hallo Franky,
Danke für das tolle Tutorial.
Eine Frage habe ich, wie synchronisiert sich die DB01 mit der DB02.
Weil, wenn ich get-mailbox -database DB01 ausführe bekomme ich alle aktiven Postfächer angezeigt, führe ich das mit der DB02 aus wird nicht ein User angezeigt.
Hallo,
erstmal super Website. Hat mir schon oft geholfen. Eine Frage zur DAG. Ich beabsichtige mit 2 Exchange 2019 eine DAG aufzubauen. Müssen in der Grundkonfiguration beide Systeme identisch eingerichtet werden? Da auch eine Migration eines Exchange 2010 durchgeführt werden muß, macht es da Sinn erstmal die Migration durchzuführen und danach die DAG einzurichten? Anschließend den 2ten Server mit den Einstellungen (Autodiscover, Sende- Empfangsconnector etc) des ersten Servers einzubinden. Achso, gibt es eine reelle Empfehlung zum RAM ausser die 128GB von MS? Früher war es doch pro Postfach x Ram.
Gruß, Robert
Die Systeme müssen nicht unbedingt gleich sein, allerdings aber die Datenbank-Pfade im Filesystem und das Filesystem selbst sollte auch identisch sein (NTFS oder ReFS). Selbstverständlich sollte auch genügend Platz vorhanden sein, die einzelnen Kopien auf jedem Knoten zu mounten.
Ansonsten würde ich die 2019er DAG mit den beiden von dir geplanten Knoten komplett parallel aufbauen mit allen dazugehörigen Konfigurationen (du erwähntest schon die Konnektoren etc.) und dann, wenn alles rund läuft, die Postfächer einfach in die neue DAG mirgrieren (MoveRequest). Ist alles umgezogen (Systempostfächer nicht vergessen), die alte DB und dann den alten Server abbauen.
Die HW-Voraussetzungen seitens MS scheinen mir persönlich etwas überzogen. Hab jetzt noch keinen 2019er am Laufen, aber soooo ein großer Unterschied zum 2016er wird es auch nicht sein und die laufen hier bei mir in einer 3-Knoten-DAG mit jeweils 16MB RAM. Das kannst du ja aber testen, wenn du deine neue DAG aufbaust. Bevor du die „heißen“ Postfächer migrierst, wirst du ja sowieso erstmal mit Testusern ausprobieren.
Hallo Udo,
danke für die sehr schnelle Rückinfo. Starte mit dem Projekt Ende 10/2019. Deine Infos waren hilfreich. Ich werde es testen und eine Rückinfo hier posten.
Gruß, Robert
Hallo Robert,
wir haben schon 2 2019er im Einsatz mit einigen Powerusern.
Ich habe beiden Ex2019 40GB Ram „Gegönnt“ (Endausbau sind knapp 350 Postfächer, wobei 215 User + Shared).
Bisher ist die Last fast nichts (ca. 10GB), wobei ich die Server auf Server 2019 CORE betreibe.
Microsoft empfiehlt in seinem PA aber (ich meine schon ab Version 2016) keine Loadbalancer mehr zu verwenden sondern generell DNS Round Robin einzusetzen…?
Würde ich nie machen. Der Vorteil eines Loadbalancers ist ja auch die aktive Prüfung der Verfügbarkeit, Stuerung der Lastverteilung Vorfilterung der Zugriffe und vieles mehr. Bei stumpfem RR hast du ja z.B. bei Ausfall eines Knotens im Zeifel auch immer einen Fehlzugriff, wenn du vom DNS eben gerade diese Adresse geroundrobint bekommen hast. Von den fehlenden anderen Möglichkeiten mal ganz abgesehen.
Gibt MS in deiner Quelle auch einen Grund für RR und den Verzicht auf Loadbalancer an? Wäre mal interessant, vielleicht übersehe ich ja auch was.
Hi Chris,
man kann in DAGs nicht verschiedene Serverversionen mischen. Ging aber auch noch nie. Wenn du eine 2016er DAG hast, kann du parallel eine 2019er aufbauen, dann die Postfächer alle nach und nach rüber moven (Systempostfächer nicht vergessen) und dann die 2016er DAG abbauen, wenn sie leer ist.
Hi Udo,
das stimmt nicht seit 2013 gibt es die Möglichkeit das DAG auch über Exchange-Versionen hinweg zu „migieren“. Das haben wir bei uns aktuell mit der Migration von 2016 auf 2019 gemacht, einfach die Exchange 2019 Server in das DAG hinzufügen und dann mittels add-mailboxdatabasecopy die Kopien auf die neuen Exchange-Server bereitstellen.
Danach einfach die alten Kopien entfernen und die Exchange 2013/2016 Installation deinstallieren. Wichtig via ADSI-Edit nachschauen ob die Server sauber entfernt wurden, wird scheinbar bei SplitPermission installationen nicht gemacht.
Hallo Michael,
es ist nicht supported innerhalb einer DAG unterschiedliche Exchange Versionen einzusetzen:
All servers within a DAG must be running the same version of Exchange. You can’t mix Exchange 2013 servers and Exchange servers in the same DAG.
https://docs.microsoft.com/en-us/Exchange/high-availability/manage-ha/create-dags?view=exchserver-2019
Der Weg wie von Udo beschrieben ist hier die richtige Vorgehensweise.
Gruß,
Frank
super Bericht, wie immer auch optisch perfekt aufbereitet.
was ich noch in diesem Bericht vermisse ist die Mischform (also nicht auf grüner Wiese) sondern in bestehenden Umgebungen. Wie sieht es aus wenn man bereits zwei Exchange 2016 mit einer DAG hat? Da die 2019er Datenbanken auch den Index beinhalten wird man vermutlich nicht die bestehende DAG verwenden können – oder? Sollte man dann am besten eine neue DAG anlegen oder die bestehende auflösen. Welche IP? 255.255.255.255 ist ja bereits reserviert wenn die bestehende bleibt?
Es gibt keine DAGs die verschiedene Exchange Versionen beinhalten. Du installierst eine neue, wie oben beschrieben, und verschiebst die Postfächer.
Was ist mit IP gemeint? DAGs sollten seit 2013SP1 immer IP-less installiert werden.
New-DatabaseAvailabilityGroup -Name DAG01 -DatabaseAvailabilityGroupIPAddresses ([System.Net.IPAddress]::None) -WitnessServer WitnessServerName
Ralf
ist hier nicht direkt on-topic aber da du es erwähnst: man *kann* ja trotzdem immernoch eine IP zuweisen, es geht aber seit 2016 (glaube ich), auch ohne. *Sollte* man wirklich IP-less installieren, also ist das best practise und was ist der Vorteil daran?
…hatte ich mich auch schon gefragt. :)