In Exchange Server, you can set up Database Availability Group (DAG) for high availability. There are two options of setting up a Database Availability Group (DAG) - IP-less DAG and IP-based DAG. These two setups are needed for failover and business resilience for Exchange Server. These ensure business continuity and recovery of the Exchange Server infrastructure in case of disaster. In this article, we will understand both IP-less DAG and IP-based DAG setups, differences between these setups, and see how to transition from IP-based DAG to IP-less DAG.
What is an IP-based DAG?
An IP-based DAG is a Database Availability Group (DAG) failover and high availability setup which is dependent on static IP addresses. This involves setting up network name resources and IP address resources in the Windows Cluster Service and registered in the Active Directory DNS. These IP addresses are then used for communication between the DAG members and client communications, which also help to check connectivity and other functions related to the cluster's health and operations.
What is an IP-less DAG?
An IP-less DAG is a cluster configuration which has no IP addresses assigned to the cluster resources in the Windows Cluster Service. This means that there are no IP addresses resources and no network name resources. In this, one single network interface is used for both the client and DAG communications for the connectivity and other functions for a cluster to be operational.
IP-based DAG vs IP-less DAG ? Key Differences
Below is a comparison between the IP-based DAG and the IP-less DAG.
Aspect | IP-based DAG | IP-less DAG |
---|---|---|
IP Requirement | Requires static IP addresses. | No static IP addresses needed. |
Compatibility | Compatible with third-party tools and backup software. | Limited compatibility with third-party tools. |
Network Setup | Requires multiple interfaces for complex networks. | Simplifies setup with a single interface. |
Flexibility | Suitable for scalable and complex DAG setups. | Simplified network setup with cost savings. |
Is it possible to change from IP-based to IP-less DAG?
As of today, there is no direct way to change an IP-based Database Availability Group (DAG) to an IP-less infrastructure. With newer Exchange Servers, precisely the Exchange Server 2016, IP-less Database Availability Group (DAG) is the default group configuration, when you setup high availability.
If you want to transition from one setup to another, then you need to create a new Exchange Server setup, move all the data, and then decommission the current IP-based setup or a new IP-less DAG, and move the data and operations onto it. However, this would require double the resources and involves shifting of mail flow, configuring the clients, and moving of the data.
Another option is to remove the Database Availability Group (DAG) and shift to a standalone server. This will remove the IP-based DAG configuration. Then, you can create a new IP-less DAG setup with new servers, add the single server as a member of the DAG so that you can move the data, and decommission the old server. You need to prepare accordingly, perform such tasks in a maintenance window, and have the right tools in place to prevent data loss or business loss.
How to Transition to an IP-less DAG?
If all goes well with the setting up of the new Database Availability Group (DAG) and the old node has been evicted and added to the new group, you can use the New-MoveRequest PowerShell command to move the mailboxes from one server to another. Before using this command, ensure that all the databases are mounted and healthy. If there is an issue with the database or the database is not being able to mount or has missing transaction logs, then the command will not work.
Challenges in Transitioning
Here are some challenges you can face when transitioning from one DAG setup to another:
- Database or Transaction Log Corruption: Any mistake or issue during the migration may corrupt the databases or transaction logs.
- Downtime: Migration may require planned downtime to avoid impact on users.
- Configuration Changes: Adjustments in mail flow and client access might be necessary.
What if the Database gets Corrupted?
The databases or transaction logs can get easily corrupted if the operation is not done correctly. In such cases, you can revert back to the previous setup by restoring the Exchange Servers and Active Directory Servers. However, this will consume a lot of time and resources.
To ensure that the data can be recovered from corrupted databases without any loss and as fast as possible, you can use Stellar Repair for Exchange. With this tool, you can independently open any version of Exchange Server databases, of any size, and in any state. After a quick or deep scan, you can granularly export user mailboxes, user archives, shared mailboxes, disabled mailboxes, public folders, and even purged or deleted items to PST and other formats.
With this tool, you can export the mailboxes and other items directly from the IP-based DAG databases to the IP-less DAG databases. This will give you a peace of mind that the data integrity is assured while reducing the data migration time and risks involved.
Some Best Practices to Follow When doing such Changes
The best practice is to decide the type of setup, whether IP-based or IP-less, at the start of the project and not after. In case, you need to change the setup from one to another, then you should consider the following things:
- Plan Ahead: The process of changeover must be well-planned as it involves creating a new Database Availability Group (DAG) and shifting all the operations from one DAG to another. There are many things that could go wrong. Therefore, you should be well-prepared and have the right tools in hand to recover any data, which might be affected.
- Take Backup: When performing such delicate processes, you must ensure that a full backup is taken. If something goes wrong, you can easily failback to the working environment. This includes the Exchange Servers, along with the Active Directory Servers.
- Schedule Downtime: Downtime is something to consider when doing such operations and the business/users must be aware of this. The process should be planned outside office hours or on special holidays to ensure that the business is not impacted.
- Test Thoroughly: Thorough tests should be done pre and post the setup to ensure that everything is working fine and there are no issues that could impact the business or the data integrity.
Conclusion
Above, we have discussed both IP-based and IP-less DAG systems that are used to ensure business resilience and disaster recovery. We have also explained the process of migration from one setup to the other and the challenges that one might face. However, it's important to decide the type of setup in the beginning so that the challenges can be prevented. But if there is a need, then you should be well-prepared and have the right tools in hand to recover data in case something goes wrong.