We often think how to Move Exchange Server 2016 to Different Active Directory Site. This kind of situation arises when you plan to extend the Messaging Infrastructure DR for Site resilience. Replicating small databases are possible by installing Exchange Server in DR site, however it may not be viable option replicate databases over narrow bandwidth if we plan to host bigger databases. From Exchange Server 2010, we can easily shift/move exchange server one active directory site to different AD Site by following simple steps outlined below.
1. Ensure that you have created and replicated required AD site and Subnets for DR/Secondary datacenter.
2. Ensure that the Exchange Server Infrastructure is healthy, and all the databases are replicated properly.
3. It is also recommended to check the AD and Exchange replication help using,
Test-ReplicationHealth from DR Exchange Server & nltest from DR Domain Controller
4. Verify the current AD site status of Exchange Server
5. Now we are good to initiate the server site migration. Before we shut down and physically move the server to different site, it is recommended to set the Exchange Server to Maintenance Mode.
.\StartDagServerMaintenance.ps1 -serverName EX16-DR1 -MoveComment SiteChange
And check the cluster status
Get-ClusterNode | ft name, dynamicweight, nodeweight, state -AutoSize
6. Shutdown and Shift the server to new site (DR/Secondary data center) and Bring up the server with new IP range configuration (subnet should be aligned to DR site).
7. Restart the Server once again to register required DNS entries and other connectivity.
8. Follow the below commands and ensure that the site movement of DAG member is success
Get-ClusterNode | ft name, dynamicweight, nodeweight, state –AutoSize
And if the status is Pause, then everything is fine. If the status is Down, that means some connectivity issues, please continue to troubleshoot.
Get-ExchangeServer | select Name,Site
Ensure that the site has changed, if you find the value that you expect then proceed to remove the server from maintenance mode.
.\StopDagServerMaintenance.ps1 -serverName EX16-DR1
The server status will change to Up from Paused post this step, and it will begin to replicate the delta and eventually the database copies will become healthy.
That’s it, you have completed the AD site change for Exchange DAG Member/Node.
Share you experience in the form of comments, we will deal whichever possible.
Couple of times in the past, I observed this behavior that the database copy status turns to DisconnectedAndResynchronizing from DisconnectedAndHealthy after removing the activation restriction.
This situation arise because, the copy try to replay the recent logs from other nodes. If your database copy could not find any copy to copy the pending logs, the status would stay the same for longer period.
If you wish to have 2 DAG cluster with one of the cluster node as DR instance, then it is not a good idea to keep the ActivationSuspended parameter to true. Following are the approach you should consider to ensure a seamless recovery in case of a failover.
1. Disable the ActivationSuspended value in the second node
2. The database would failover immediately in the event of a node failure.
1. Enable the ActivationSuspended value in the DR node
2. In the event of active node failure, follow the DR procedure to evict the failed node prior to release the Activation suspension
It is recommended that, activation suspension can be released either when the nodes are available or after evicting failed nodes from the DAG cluster.
In the past we all had nightmares about the recovery of a failed or crashed exchange server. But from the version 2010 (even in 2007) the recovery process became really painless and easy. The following steps will help you to recover a completely failed/crashed server from scratch.
Though all of us know, I would like to emphasize the fact that most of the exchange configuration information are stored in the AD database and we only need to recover the application by using the AD information and then complete the Database recovery and other customized exchange settings.
Note – This document is reference only for Exchange server which are not part of Database Availability Group. If you wish to get more details about DAG member recovery, please follow Recovery Installation of a DAG Member with Multi Roles – Exchange Server 2010.
Before we proceed, please ensure that a proper account with required permissions are used to complete the activity.
Other thumb rules,
Recovery Procedure for Exchange Server 2013, SP1
1. Logon AD console and reset the failed server computer account
2. Join the prepared server with similar characteristics and same host name (as stated above) to domain. Recovery will fail if the pre-requisite did not match with the failed server.
3. Log back in to the server being recovered using an account which has required permissions assigned and open the command prompt. Navigate to the location where Exchange Installation files are extracted and execute the cmdlet, Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms
4. Now sit back and relax, the process will automatically read the information from AD and recover the server.
5. After the successful recovery process, please proceed with the custom configurations and restorations such as,
Note – It is recommended to restart the server before the start of DB restore and other custom settings.
Share your experience!
Restore-DatabaseAvailabilityGroup is one of the cmdlets used when we do a datacenter switchover of Exchange DAG, especially during a disaster recovery situation. We might end up unsuccessful in executing the Restore-DatabaseAvailabilityGroup and will fail with below error.
Before we jump into the solution, let’s understand what the command actually does,
You might observe that few stopped DAG members are evicted and failed on one of the stopped servers. What I observed is, it can be due to the delay in information replication or a communication failure.
The issue can be workaround in couple of ways as stated below,
As mentioned, you may run the Restore-DatabaseAvailabilityGroup cmdlet couple of time to see if it succeeds without being stopping the cluster service on Exchange 2010 SP1 and above.