Related Posts
Exchange Database Availability Group – Overview
Written By
Megha Sharma
Updated On
December 02, 2022
Read time 4 minutes
Get to know about an advanced Exchange Server feature – Database Availability Groups or DAG – for multiple server storage, replication, and failover mechanism.
Database Availability Group or DAG is usually a set of 16 mailbox servers (of the same version) with databases hosted in them. It is the component of the Exchange Server’s mailbox server high availability and site resilience framework. It acts as a boundary for Active Manager (internal component for individual servers to manage switchovers and failovers in DAG), mailbox database replication, database/servers failovers/switchovers.
DAG offers database-level recovery from issues and failures such as disk failures, network problems, server crashes or failures, etc., that badly impact the servers and databases. A DAG server hosts the copy of a mailbox database of another server and works together with added servers to deliver an automatic database-level recovery after the aforementioned failures.
Note: Exchange administrators can create DAG with physical and virtual mailbox servers given that these servers along with solutions fulfill Exchange Server system and Exchange Server virtualization requirements
Once the Exchange Server is installed, administrators can create DAG, then add mailbox servers to it and further replicate mailbox databases between DAG members.
A DAG is created as an empty object in the Active Directory to store information about server membership and configuration settings. On the addition of a server to the DAG initially, a failover cluster is created automatically, which is solely dedicated to DAG use. DAG can be created with or without a cluster administrative access point (on Exchange 2019, Exchange 2016, Exchange 2013, Windows Server 2012 R2 Standard/Datacenter addition only). When DAG is created without a cluster administrative access point, cluster object name not created in AD, DAG name is not registered in DNS; IP address is not assigned in DAG, and no network name assigned to the cluster.
Before creating the DAG, the user or administrator must have high availability and site resilience permissions and have specified witness server and directory for an even number of Exchange nodes. This witness server contains a folder accessible to the Exchange Trusted Subsystem AD Universal group and is used to maintain the quorum.
The Exchange administrator needs to add the Exchange Trusted Subsystem AD group to the local Administrators group and create a new folder for it with a relevant name for witness server configuration.
Exchange Management Shell includes a cmdlet, namely Get-MailboxDatabaseCopyStatus to monitor mailbox database copies for DAGs. It outputs the mailbox database copy status like Failed, Seeding, SeedingSource, Suspended, Healthy, ServiceDown, Initializing, Resynchronizing, Mounted, Dismounted, Mounting, Dismounting, DisconnectedAndHealthy, DisconnectedAndResynchronizing, FailedAndSuspended, and SinglePageRestore.
To check the status of all database copies on the local mailbox server, here is the command.
To check the status of all database copies on the specific mailbox server, run this command.
The unfortunate thing is that Exchange database corruption can occur in spite of all these features. In such situations, one needs to use ESEUTIL for Exchange Server repair. Also, one can try a professional Exchange recovery solution – Kernel for Exchange Server.
This tool is developed to efficiently recover Exchange Server mailboxes, public folders, and archive/shared mailboxes to save them to live Exchange Server, PST, Office 365, and more destinations.
Database Availability Groups keep mailbox database copies on multiple servers and reduces data loss chances. It offers database-level recovery in cases of failures. The basic DAG concept and methods to create DAG are explained to help Exchange Server users.
