Author: Shelly Bhardwaj

Database Availability Group (DAG) setup in Exchange Server provides full protection and recovery in case of database, network, or server failure. In a DAG, you can have up to 16 mailbox servers hosting a set of databases. This helps provide automatic, database-level recovery in case something happens. 

Sometimes, situations arise when you need to split the Database Availability Group (DAG) and move the mailboxes from one availability group to another. Some common situations are:

In Exchange Server, if you need to do some maintenance work on a node and need to stop the services, restart the server, or shut down the server, it’s important to set the Exchange Server in maintenance mode. This allows you to stop and start the server with no impact. In the Exchange Server, the StartDagServerMaintenance.ps1 script is used to run various commands to put the Exchange server in maintenance mode. However, sometimes, when running the script, you may get the following error:

VERBOSE: [Time UTC] Move-DagActiveCopy: Entering: `$MailboxServer=ExServer, `$Database=
VERBOSE: [Time UTC] Move-DagActiveCopy: Moving all replicated active databases off server ExServer
VERBOSE: [Time UTC] Move-DagActiveCopy: moving database 'DBName' off server 'ExServer'
VERBOSE: [Time UTC] Move-DagMasterCopy: Entering: `$db=DBName, `$srcServer=ExServer, `$preferredTarget=
VERBOSE: [Time UTC] Test-DagTargetCopy: Testing move criteria for DatabaseName\ExchangeServer, with `$Lossless=True and `$CICheck=False …
VERBOSE: [Time UTC] Test-DagTargetCopy: Name='DatabaseName\ExchangeServer', Status='DisconnectedAndHealthy', CIStatus='Healthy', CopyQueueLength=0, ReplayQueueLength=0
VERBOSE: [Time UTC] Test-DagTargetCopy: Leaving (returning 'False')
VERBOSE: [Time UTC] Test-DagTargetCopy: Testing move criteria for DBName\DR-ExServer, with `$Lossless=True and `$CICheck=False …
VERBOSE: [Time UTC] Test-DagTargetCopy: Name='DBName\DR-ExServer', Status='DisconnectedAndHealthy', CIStatus='Healthy', CopyQueueLength=0, ReplayQueueLength=0
VERBOSE: [Time UTC] Test-DagTargetCopy: Leaving (returning 'False')
VERBOSE: [Time UTC] Move-DagMasterCopy: 0 copies out of 3 for database DBName will be attempted for move.
 Log-Error : [Time UTC] Move-DagMasterCopy: Database 'DBName' *FAILED* to move! Now attempting to perform rollback to prevent a DB outage…

At D:\Program Files\Microsoft\Exchange\V14\scripts\DagCommonLibrary.ps1:483 char:14 + Log-Error <<<< ($DagCommonLibrary_LocalizedStrings.res_0064 –f $db,"Move-DagMasterCopy") + CategoryInfo : NotSpecified: ( : ) [Write-Error], WriteErrorException + FullyQualifiedErrorId :   Microsoft.PowerShell.Commands.WriteErrorException,Log-Error

To patch the Exchange Servers against known threats and fix bugs and vulnerabilities, Microsoft releases Cumulative and Security updates on a regular basis. These updates also provide new features, security patches, and various other fixes. Usually, the installation of these updates goes smoothly if done with proper planning and process. However, sometimes, you may encounter issues during and post installation of these updates. In this article, we will list some common issues that you may encounter when installing CU and SU and the possible solutions to fix them.

Common Issues and Errors When Installing Exchange Updates and Their Solutions

Below, we have mentioned some common issues that you may encounter when installing Cumulative and Security updates on the Exchange Server, along with their solutions. 

Ransomware attacks on on-premises Exchange Servers are quite common as they store sensitive and confidential information and business data. The attackers often exploit vulnerabilities to gain access to the organization's network and steal or encrypt data for ransom.  

Even if attackers do not succeed in encrypting the data, they may leave a backdoor or cause other damage that can leave your server unusable or cause permanent data loss. That's why it's important to have a disaster recovery plan or recovery strategy ready to deal with such critical situations.

Witness Server and Witness Directory are the most critical components of the Database Availability Group (DAG). DAG requires Witness Server or File Share Witness (FSW) and Directory to maintain the Quorum. In case of Witness Server failure, the Quorum is no longer maintained, leading to inconsistent DAG. In addition, the cluster may no longer respond or work, leading to downtimes if a disaster strikes.

However, you can change the Witness Server and Witness Directory to maintain the Quorum and ensure high availability when the Witness Server has failed, is unavailable, or does not boot.