Technically you can’t rename an existing Database Availability Group, but you can recreate it with a new name. It’s possible to do this without requiring that the databases within the DAG to reseed.
Here are the steps to recreate a DAG with a new name:
- Suspend all backups and disable circular logging if it’s enabled. This will ensure you have all the transaction logs required to update the database copies when you’re done.
- Remove all database copies from the DAG. This will remove them from the DAG, but doesn’t actually delete the database files on the server.
Remove-MailboxDatabaseCopy -Identity DB01\MBX3
- Remove all nodes from the DAG using the -ConfigurationOnly switch. The Mailbox servers will be evicted from the DAG’s cluster and removed from the DAG object in Active Directory.
Remove-DatabaseAvailabilityGroupServer -Identity DAG -MailboxServer MBX3 -ConfigurationOnly
- Remove the DAG. Now that the DAG has no members, it can be deleted from Exchange and Active Directory.
Remove-DatabaseAvailabilityGroup -Identity DAG
- Clean up the cluster service on each node. This restores the configuration of the Cluster service on the specified node to its original state.
cluster node /force
- Restart the Microsoft Exchange Replication service on each node. Now each server is in standalone. Databases should mount and be accessible.
- Create the DAG with the new name. Ensure your DAG properties and network settings are correct.
New-DatabaseAvailabilityGroup -Name DAG3 -WitnessServer EXHUB2 -DatabaseAvailabilityGroupIPAddresses 10.0.0.8,192.168.0.8
- Add the nodes to the new DAG.
Add-DatabaseAvailabilityGroupServer -Identity DAG3 -MailboxServer MBX3
- Add mailbox database copies. Exchange will see that the database copies already exist in the target file system and will resume replication.
Add-MailboxDatabaseCopy -Identity DB01 -MailboxServer MBX3 -ActivationPreference 3
As long as there wasn’t a tremendous amount of data churn (>~10%) you won’t need to reseed the databases. Exchange will just replicate the logs generated from the time you removed the database copies.
Remember to resume your Exchange backups and reconfigure circular logging if it was previously enabled.
Today’s article is a tidbit of information, but important to call out for larger scale DAG deployments.
Exchange 2010 always uses the active database in the DAG as the source for log shipping during normal replication. That means that if you have multiple passive copies in your DAG, Exchange ships transaction logs from the active copy to each passive copy, even if some of the copies are in the same site. There is no peer-to-peer log shipping between passive copies in a DAG.
|Simple four node DAG with three passive copies|
In the example above we have a single DAG with the active database and one HA copy in DC1, and one DR copy and a lagged copy in DC2. Log shipping occurs from the active database to the three passive copies, traversing the WAN twice for the copies in DC2.
This can have quite an affect on a complex enterprise deployment with multiple DAGs and many remote passive copies, so keep that in mind for your designs.
Log shipping is different than seeding. Seeding is a file copy of the database to another server. Once seeding completes log shipping is used to keep that copy up to date. It is possible to seed a database from a specific server, perhaps one in the same site. For more information see the “Selecting the Seeding Source” topic in http://technet.microsoft.com/en-us/library/dd335158.aspx
Normally when you seed (copy) an Exchange database in a DAG, the source is the active database. This may not be efficient if the source database is across the WAN. This article explains how to seed from a different source, preferably a passive copy in the local LAN.
Seeding a database copy can be performed from the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). The database will always seed from the active database when you perform the operation from the EMC. If you want to select a different source you need to use EMS.
Open and elevated EMS prompt and run the following three cmdlets:
Add-MailboxDatabaseCopy -Identity DB01 -MailboxServer EXMB03 -SeedingPostponed
Suspend-MailboxDatabaseCopy -Identity DB01\EXMB03 -SuspendComment “Seed DB01 from EXMB02″ -Confirm:$False
Update-MailboxDatabaseCopy -Identity DB01\EXMB03 -SourceServer EXMB02 -DeleteExistingFiles
The first command adds a new mailbox database copy of database DB01 on mailbox server EXMB03, but does not start the seeding operation. Once this operation completes you will see the DB01 database copy on EXMB03 will be in a “Failed and Suspended” state.
The second command suspends the mailbox database copy and creates a suspend comment. This step is not necessary, but it’s helpful to create a comment so other administrators don’t try to “fix” the failed and suspended database copy.
The third command seeds the mailbox database copy on EXMB01 from the source server EXMB02. It also deletes any existing EXMB01 database or log files prior to seeding. Once this operation begins the database copy state will change to “Seeding” until the seeding operation is complete, at which point it will change to “Healthy”.
Some Exchange-supported virtualization platforms, such as Hyper-V and VMware include features that support the clustering or portability of guest virtual machines across multiple physical root machines. Examples of host-based failover clustering and migration include Hyper-V Live Migration and VMware ESX vMotion.
Microsoft support for host-based failover clustering and migration virtualization with Database Availability Groups (DAGs) depends on the Exchange 2010 service pack level. Per the Exchange 2010 System Requirements
With Exchange 2010 RTM:
Microsoft doesn’t support combining Exchange high availability solutions (such as DAGs) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. DAGs are supported in hardware virtualization environments, provided the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.
With Exchange 2010 SP1 (or later) deployed:
Exchange server virtual machines (including Exchange Mailbox virtual machines that are part of a DAG), may be combined with host-based failover clustering and migration technology, as long as the virtual machines are configured such that they will not save and restore state on disk when moved, or taken offline. All failover activity must result in a cold boot when the virtual machine is activated on the target node. All planned migration must either result in shutdown and cold boot, or an online migration that makes use of a technology like Hyper-V Live Migration. Hypervisor migration of virtual machines is supported by the hypervisor vendor; therefore, you must ensure that your hypervisor vendor has tested and supports migration of Exchange virtual machines. Microsoft supports Hyper-V Live Migration of these virtual machines.
In summary, Exchange 2010 SP1 or better supports hypervisor migrations such as Hyper-V Live Migration and VMware ESX vMotion for DAG member servers. Host-based failover cluster migrations, such as Hyper-V Quick Migration, is supported only if the virtual Exchange DAG server is restarted immediately after the quick migration completes. Exchange 2010 RTM is not supported with either migration technology. RTM only supports the native Exchange high availability features present in DAGs.
Other Exchange Server 2010 roles (CAS, Hub Transport, Edge Transport, and Unified Messaging) fully support host-based failover clustering and migration because they do not employ native Exchange high-availability solutions.
For a list of the virtualization platforms supported by Exchange, visit the Windows Server Virtualization Validation Program