A Database Availability Group (DAG) cluster in the Exchange Server environment serves as a key component when it comes to data resilience and high availability of the Exchange Server services. If something happens to the main server, services and data do not get impacted and the users experience no downtime. For this, there is a process, called switchover, in which the active database copy is moved to another server in the DAG. In this article, we will go through the step-by-step process to ensure a safe and successful Database Availability Group (DAG) server switchover.
There are various reasons why you need to perform a switchover. Let’s take a look at some common ones.
- Planned maintenance is the most common factor where the administrators would need to replace/upgrade or repair hardware or storage on the server. This is also done for software maintenance that requires restart.
- Testing of failover is commonly done to comply with the business checklists and with regulatory compliance to ensure that if something happens, the business continuity document and disaster recovery document are up-to-date. Also, to ensure that the failover will work as planned.
- Load balancing is done when the main server needs to be replaced if the server is not coping with the load and the services/data access needs to be shifted to another more powerful node/hardware.
- Disaster Recovery is done when there are issues with the current server and the administrators need to shift to the other server/s until the issue is resolved.
Pre-requisites for the DAG Server Switchover
Usually, there are no prerequisites to fulfil since everything should work normally. But if there is a planned maintenance or downtime, you should always perform the below tests to ensure that everything is working as it should be before switching over.
Step 1 – Check the Member Servers’ Health
For this, you must ensure that all the member Exchange Servers of the cluster are healthy and there are no issues. To check the Database Availability Group (DAG) health, you can use the following command:
Get-MailboxServer | Test-ServiceHealth
Step 2 – Check the Replication of Databases
If the databases replication is unhealthy, the data will not be up-to-date. To confirm that data transit has no issues and the databases are in sync, you can use the below command:
Get-MailboxDatabaseCopyStatus
Step 3 – Check Network Connectivity and Reach
There should be clear and fast communication between the Exchange Servers via the Cluster network and the Client network. To confirm this, you can check with the network team if the servers are at different sites or locations. If there are any issues, the switchover will not be successful.
Step 4 – Check the Transaction Logs
You need to ensure that the transaction logs are properly replicated and truncated. The synchronization of data is based on log shipping. You can run the below commands to confirm that everything is in order.
Test-ReplicationHealth -Server <MailboxServer>
Get-MailboxDatabaseCopyStatus -Identity <DatabaseName>
To successfully perform the switchover, you should plan well and make sure that everything is in order. If the above tests are successful, you can proceed with the below steps.
Step 1 – Confirm the Active Mailbox Databases
You need to see the active mailbox database on the server and also see which databases can be moved to another server since the server might be hosting database copies of another server. For this, you can use the below command:
Get-MailboxDatabase | Format-Table Name, Server
Step 2 – Move the Active Databases to the Target Server
You can use the below command to switch the active databases specified on the target server. This will make the active databases as copy and will mark the copy database as active after verifying the synchronization.
Move-ActiveMailboxDatabase -Identity <DatabaseName> -ActivateOnServer <TargetServer> -Confirm:$false
This may take some time depending on the load, performance, and size of the mailbox database.
To monitor the changeover, you can use the below command:
Get-MailboxDatabaseCopyStatus -Identity <DatabaseName>
Step 3 – Test Client Access
After the move, it’s important to run some tests to confirm that all is working fine. These involve the following:
- Test access of the mailbox via Outlook Web Access (OWA).
- Test access of the mailbox via Microsoft Outlook/mobile device.
- Check email flow by checking the queues.
- Confirm that the Exchange Server services are running.
If all went well, then you can put the affected server in maintenance mode. This will ensure that any work on the server will not impact the users and other operations. This will allow the administrators to fix the problems or do the maintenance work.
What if Something Goes Wrong?
There are a lot of things that could go wrong during this operation if the prerequisites are not met and there are replication issues between the servers. You must also consider that a switchover might happen automatically if there is an issue, such as:
- Hardware failure
- Installation of non-compatible third-party software
- Sudden loss of power
- Malicious attacks
- Lack of free storage space
All the above issues can hinder the integrity of data and uptime of the databases. In case the server is inaccessible or corrupted, it can easily be rebuilt. If, after a disaster or misconfiguration, the transaction logs or Exchange Server database is corrupted or not in sync, you can use the ESEUtil. However, this might be time-consuming and often not successful.
Alternatively, you can rely on specialized Exchange recovery tools that can mitigate the above challenges. Stellar Repair for Exchange is one such tool that can independently open databases in any state, of any size, and of any version of Exchange Server, and even when the Exchange Server is not running. After opening the database, you can granularly export the user mailboxes, shared mailboxes, user archives, disabled mailboxes, and public folders to PST file or other formats. After rebuilding the server, you can easily export the EDB data to a live Exchange Server database or Microsoft 365 tenant with automatic mailbox matching.
Conclusion
It is very important that you have everything in order when you need to do switchover, if a disaster strikes or there are any other issues. It’s important to monitor and maintain the Exchange Server cluster and ensure that issues (if any) are immediately mitigated. Also, if a disaster occurs, you must make sure to have the right tools in hand that can help recover the services and data in the least possible time, and with minimal impact on the business.
Was this article helpful?
