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.