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.

AD Site Details

2.  Ensure that the Exchange Server Infrastructure is healthy, and all the databases are replicated properly.

DB Copy Status

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

Before Moving Site Info

Before Moving Exchange Server Site Info

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

Move it to Maitenance


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.

Final Stages


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.


Published in Solutions

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.

Option 1:

      1. Disable the ActivationSuspended value in the second node

      2. The database would failover immediately in the event of a node failure.

Option 2:

      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.


Published in Solutions

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,

  • Prepare a server with OS and patches similar to failed server
  • Use the same hostname as the failed server
  • Same drive letters and capacity of disks should be used
  • Similar hardware capacity should be used to avoid performance issues.

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

setup recover cmd

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,

Exchange Virtual directory settings,
Restoration of Databases

Note – It is recommended to restart the server before the start of DB restore and other custom settings.

Share your experience!


Published in Articles

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.

WARNING: Server 'EX2010-02' was marked as stopped in database availability group 'DAG-01' but couldn't be removed from
the cluster. Error: A server-side database availability group administrative operation failed. Error: The operation
failed. CreateCluster errors may result from incorrectly configured static addresses. Error: An error occurred while
attempting a cluster operation. Error: Cluster API '"EvictClusterNodeEx('EX2010.fabrikam.com') failed with 0x46.
Error: The remote server has been paused or is in the process of being started"' failed. [Server:
WARNING: The operation wasn't successful because an error was encountered. You may find more details in log file
Server 'EX2010' in database availability group 'DAG-01' is marked to be stopped, but couldn't be removed from the cl
uster. Error: A server-side database availability group administrative operation failed. Error: The operation failed. C
reateCluster errors may result from incorrectly configured static addresses. Error: An error occurred while attempting
a cluster operation. Error: Cluster API '"EvictClusterNodeEx('EX2010-02.fabrikam.com') failed with 0x46. Error: The rem
ote server has been paused or is in the process of being started"' failed. [Server: Ex2010-DR.fabrikam.com]
    + CategoryInfo          : InvalidArgument: (:) [Restore-DatabaseAvailabilityGroup], FailedToEvictNodeException
    + FullyQualifiedErrorId : EF6ADD3F,Microsoft.Exchange.Management.SystemConfigurationTasks.RestoreDatabaseAvailabil

Before we jump into the solution, let’s understand what the command actually does,

  1. It forms the cluster with started DAG members using /forcequorum
  2. It evicts the stopped DAG member from the cluster nodes list.

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,

  1. Do run the Restore-DatabaseAvailabilityGroup cmdlets after some time and see if the activity succeed. (Note – you may re-run it when the cluster services are up and running if you are running Exchange 2010 SP1 or later. Earlier version administrators, please excuse me !!
  2. If you are unsuccessful when using Exchange Powershell, try evicting the server from Failover Cluster Manager mmc.

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.


Published in Articles
theme by reviewshub