Expansion of the "small exchange organization" - Part 4

In the fourth part of the expansion of the small Exchange organization, it's DAG's turn. The domain controller and Sophos UTM are already running redundantly and the second Exchange server has also been prepared. An Exchange DAG (Database Availability Group) is now required so that the failure of an Exchange server or the failure of the Hyper-V / ESX server can also be intercepted.

Foreword

For the DAG with two Exchange servers, an additional Windows server is required as a witness server. The witness server must not run on one of the two hypervisors that also host the Exchange servers. In the environment I have described, a third physical server (Server 3) is therefore required:

The witness server is required to determine which Exchange server has failed and which is the remaining Exchange server. The witness server does not have to fulfill any special hardware requirements, only a few small files will be stored here later.

Background witness server

The DAG is based on the Windows Failover Cluster feature and the Windows Failover Cluster works according to the "voting principle". In simple terms: Each cluster member receives one vote, within the cluster the majority of votes must always be guaranteed, otherwise the operation will be stopped. In the case of two Exchange Servers, each Exchange Server has one vote; if one of the Exchange Servers fails, one vote is also lost. The cluster would cease operation as the majority is no longer guaranteed. The one remaining vote is not the majority, so we would need more than 50% of the votes.

This is where the witness server comes into play. The witness server gets 0.5 votes. With two Exchange servers and one witness server, the entire cluster therefore has 2.5 votes. If one Exchange server fails, 1.5 votes remain. This means that the majority is maintained and everything is fine. The reason for the majority is simple: a failover can only be carried out if it is clear which of the two servers has failed.

The horror scenario: Somewhere a switch or uplink fails, Exchange1 can no longer communicate with Exchange2, Exchange1 thinks it has to bring the passive database online, Exchange2 also thinks it has to bring the passive database online. Without a witness server, we would have active databases on both Exchange servers and inevitably corrupt data. To avoid this, the witness server is asked and the majority is determined.

Configuration of the witness server

Hardly anything needs to be prepared on the witness server. It is sufficient to install Server 2012 R2 and add it to the Active Directory. I have installed the server fs.frankysweb.org with the IP 172.16.100.17.

When configuring the network, make sure that both DNS servers are specified:

In order for the witness directory to be configured by Exchange, the "Exchange Trusted Subsystem" group must be added to the local administrators group:

That's all, let's continue with the configuration of the DAG.

Exchange DAG configuration

The DAG can now be configured on one of the two Exchange servers

Once the DAG has been created, the two Exchange servers can be added:

After a short time, the servers have been added and the dialog can be closed.

It should now look like this in the EAC:

A DAG with the name "FWDAG1". The servers with the names "Exchange" and "Exchange2" are members, the witness server is "FS".

Configuration of database copies

A copy of each of the two databases must now be added to the other Exchange server:

A copy of the "MailboxDB" database is therefore configured on "Exchange2":

A copy of the second database is also added to the "Exchange" server:

After the copies have been added, it should look something like this:

After the copies have been added, the status can be checked.

Review

Before a failure can be tested, it should be checked whether the mailbox copies and the index are in order:

Get-MailboxDatabaseCopyStatus -Server exchange
Get-MailboxDatabaseCopyStatus -Server exchange2

• One of my indexes was damaged. I have recreated the index:

Recreate Exchange Index

Using the following command, the index can then be transferred to the second server (if the index is defective on both servers)

Update-MailboxDatabaseCopy MailboxDB\EXCHANGE2 -CatalogOnly

The failure

The most important test is, of course, the failure of an entire server. In this case, a domain controller, an Exchange server and a Sophos UTM are no longer available at the same time. I test the failure of Server1:

Server1 contains the active Sophos UTM, a domain controller and the Exchange server with the active database "MailboxDB" in which the administrator mailbox is stored. In my case, there is a failover of the UTM cluster and a failover of the mailbox database "MailboxDB". As a reminder, a load balancer for Exchange is not used. You can see the result in the video:

At the top right is a ping to the domain controller "DC", in the middle is a ping to the Exchange server. At the top left is a ping to my blog and at the bottom left the ping to the UTM. If Server1 fails, the passive UTM takes over after a short time; only one ping is lost here. Exchange Server and Domain Controller remain offline, Outlook does not notice any of this. The failover to Exchange2 was successful:

Conclusion

There is no short conclusion at this point. There is a more detailed article on the pros and cons and the unresolved problems.