Exchange Server 2016 and Microsoft Cloud – Deployment Guide (Part 4)

By /

If you would like to read the other parts in this article series please go to:

Deploying a DAG on the main site…

At this point we have the Exchange Server 2016 deployed on two servers in the main site (TOREX01 and TOREX02) and the Public Certificate is installed and configured on both of them. Our next step is to create a DAG to provide high availability at the mailbox store level between the two existent servers.

Before deploying the DAG, let’s make sure that we have addressed these following key points:

  • Keep consistency, all Operating System changes (including Windows Updates) should be the same on all Exchange Servers that are part of the same DAG. The same applies for configuration at OS level, disk partitions and so forth.
  • Use a separate disk for all servers to host the Mailbox Databases (the Exchange Server Role Requirements Calculator does a great job to define the disks required for the solution)
  • For now, a File Server to be the witness server on the main site will be used. As part of this series we will move this witness server to Microsoft Azure. In that File Server we must have the group Exchange Trusted Subsystem as member of the local group Administrators.
  • Two (2) network adapters on each existent and future Exchange Servers in our organization. One adapter will be used for client communication and the second for replication purposes;
  • Rename the network adapters, using something meaningful, such as MAPI and Replication. Also, configure the binding order and make sure that MAPI is always the first one on the list.
  • These following settings must be configured on the Replication network adapter:
    • At the DNS tab properties (on the Advanced TCP/IP Settings) make sure that the option Register this connection’s addresses in DNS is unchecked
    • Uncheck all client/services at the adapter properties (e.g.: Client for Microsoft Networks, and File and Printer Sharing for Microsoft Networks)
    • A different subnet is required on the Replication network
  • Exchange Server 2016 databases and logs should be stored in volumes formatted as ReFS and the integration feature should be disabled. In Figure 01, we already initialized the disk using Disk Management and we use PowerShell to list the existent disks (the Disk with Number 1 is the new disk added and reserved for Exchange Databases in our scenario) and in the second cmdlet we create a new partition, format it, and configure the integration feature. Both cmdlets are listed below, and after running that we can assign a mount point or a drive letter.
    • Get-Disk
    • Get-Disk <Number> | New-Partition –UseMaximumSize | Format-Volume –FileSystem ReFS –SetIngegrityStreams $False

Image
Figure 01

Creating the DAG (Database Availability Group)…

The DAG creation must be performed only once per DAG, and the process will create the object configuration in the Exchange Organization, however no changes will be done at the server level at this stage. After creating the DAG, the administrator has the ability to add servers to the DAG (DAG members) and we will cover this process on this article as well.

The first step is to create the Database Availability Group object, logged on Exchange Admin Center (EAC), click on servers (1), database availability groups (2) and then click on + (add, item 3), as shown in Figure 02.

Image
Figure 02

In the new page, fill out the DAG name, the witness server that we prepared in the previous section, and the local path location for the witness directory on the witness server, as shown in Figure 03. Finally, we will create a DAG without an APP (Cluster Administrative Access Point) which reduces complexity where no objects must be created on Active Directory before hand and also there is no IP requirement for this new DAG. In order to configure a DAG without an APP, the administrator has to configure 255.255.255.255 on the Database availability group IP addresses section. After configuring all settings, click on save.

Image
Figure 03

For any DAG with two or more members that use built-in replication, the administrator should always enable the Datacenter Activation Coordination mode (DAC). The concept is easy to understand and it ensures that a mailbox database cannot be mounted on two different servers at the same time (also known as split brain syndrome), and it does that using a DACP bit (Datacenter Activation Coordination Protocol) which is stored in memory and it always starts with 0 which does not allow the server to mount databases, after that server communicates with other DAG members, then the bit can be set to 1 and then databases can be mounted on the given server.

The good news is that as administrator we just need to configure the Datacenter Activation Mode on the earlier stages of the DAG and we should be good. In order to configure it, we must use Exchange Management Shell, and the configuration is set on the second cmdlet below. The first and second cmdlets are just to check the current values (Figure 04), please change the DAGTOR for the name of your DAG object in your environment.

Get-DatabaseAvailabilityGroup | Select Name,Servers,DatacenterActivation* | ft –AutoSize

Set-DatabaseAvailabilityGroup DAGTOR –DatacenterActivationMode DagOnly

Get-DatabaseAvailabilityGroup | Select Name,Servers,DatacenterActivation* | ft –AutoSize

Image
Figure 04

Since we are configuring the DAG object, an administrator that is planning to use the AutoReseed feature should configure the FileSystem attribute to ReFS and the cmdlet required for that is listed below. The AutoReseed feature allows Exchange to use a spare disk to restore database redundancy automatically.

Set-DatabaseAvailabilityGroup DAGTOR -FileSystem ReFS

Adding DAG Members…

Logged on Exchange Admin Center (EAC), click on Servers, then Database Availability Group and click on the DAG listed, and then click on Manage DAG Membership button. In the new page, click on Add and a list with all existent Exchange Servers will be displayed in a new window (in the third column it provides information if that given server belongs or not to an existent DAG). After adding the server(s), click on Save, as shown in Figure 05.

Image
Figure 05

That process may take a while and it will install Failover Clustering feature on the server and any other requirements. When the process is complete, the administrator will be able to check the new member server being listed on the Database availability groups tab of Exchange Admin Center (Figure 06). We can use the same procedure to add additional DAG members.

Image
Figure 06

Now that the DAG is operational and we have a couple of DAG members, we need to configure the initial database replication in the new DAG. By default, any new Exchange Server installation will create a Mailbox Database and we can see those created as part of the Exchange regular installation (Figure 07).

A best practice is to remove the databases created during the Exchange Server installation, and in order to do that the administrator can start removing all Mailbox Databases from the Exchange Server(s), however the first mailbox database of the first Exchange Server will have the administrator mailbox and arbitration mailboxes. In that specific mailbox database, we will need to move all mailboxes to a new Mailbox Databases before deleting it.

Image
Figure 07

The next step is to create a new Mailbox Database, click on servers, databases, and click on + (Add). In the new page (Figure 08), define a mailbox database name, server and the new location for database files and logs (in our article series we will use the drive M:), click on save. A restart of the Microsoft Exchange Information Store (MSExchangeIS) service is recommended.

Image
Figure 08

After creating the first Mailbox Database, the administrator can configure the replication and high availability for it. Click on servers, databases, select the desired database from the list (item 2), click on … (item 3) and then Add database copy (item 3), as shown in Figure 09.

Image
Figure 09

In the new page, click on Browse to add additional servers to be part of the mailbox database copy, and click on save, as shown in Figure 10.

Image
Figure 10

Conclusion

In this article we worked on the Database Availability Group (DAG) by checking the basic requirements, configuring the file witness, creating the DAG object, adding servers and finally adding Mailbox Databases and building the high availability.

If you would like to read the other parts in this article series please go to:

About The Author

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides of the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange, CISSP and several other certifications. Anderson contributes to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at Techgenix.com, MSExchange.org, ITPROCentral.com and Anderson Patricio.org (Portuguese).

Read Next

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top