Are You Facing an Error When You Run the StartDagServerMaintenance.ps1 Script?
Learn how to address errors with the StartDagServerMaintenance.ps1 script in Exchange Server, and discover reliable recovery solutions for database issues.
Join the DZone community and get the full member experience.
Join For FreeIn 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
The error is a bit misleading. You run the Get-MailboxDatabaseCopy
command in the Exchange Management Shell (EMS). However, the report doesn’t show any errors.
Possible Solutions to Resolve the Error
You can try to run the manual command to put the server in maintenance mode.
Run the below command to confirm that all databases are healthy.
Get-MailboxDatabase -Server 'MaintenanceServerName' | Get-MailboxDatabaseCopyStatus
Next, you need to move the active databases from the server.
Move-ActiveMailboxDatabase -Server 'MaintenanceServerName'
Then, move the cluster services to another node.
cluster.exe DAGFQDN group "ClusterGroup" /moveto: 'MaintenanceServerName'
Suspend all the copies on the server.
Get-MailboxDatabaseCopyStatus -Server 'MaintenanceServerName' | Suspend-MailboxDatabaseCopy -ActivationOnly:$true
Pause the node in the cluster.
cluster.exe DAGFQDN node '**MaintenanceServerName**' /pause
Stop the database from failing over.
Set-MailboxServer -Identity 'MaintenanceServerName' -DatabaseCopyAutoActivationPolicy:BLOCKED
This will put the server in question under maintenance, and you will be able to proceed with the maintenance work.
It is possible that a typo or an issue would cause a server to reboot, making it unresponsive, or an issue might occur, which could hinder the manual setting to maintenance mode. This will cause disruption to the system, especially to the mail flow and activation of the services.
You must also consider the impact on the servers that will be active and ensure that the servers are well-equipped to take on the added load. The performance of the servers and storage needs to be considered. When setting up multiple servers in maintenance mode, you must ensure that the rest of the servers can take the added load.
Recovering From a Failing Exchange Server
As you have seen, you can manually set the maintenance mode using the Exchange Management Shell (EMS). In case of any issue with the mailbox databases or Exchange Server, you can use a third-party application to recover from such a situation. Stellar Repair for Exchange is the right application, as it is recommended by MVPs.
With Stellar Repair for Exchange, you can open offline or damaged databases from any Exchange version with no size limit. If you have just the EDB file, the application will be able to open it. After a quick/deep scan, you will have access to the entire structure of the database/s.
You can granularly pick the user mailboxes, user archives, shared mailboxes, disabled mailboxes, and public folders and export them directly to a new Exchange Server mailbox database or another Exchange Server, with automatic mailbox matching. You can use the application to export the EDB data to PST and Exchange Online.
Conclusion
The StartDagServerMaintenance.ps1
script may fail to run if there is an underlying problem with the server or database. When running the commands manually, if the process is not done correctly, there could be repercussions to the health of the server or database. In this case, you can take the help of Stellar Repair for Exchange to recover the data and migrate to a new Exchange Server database. The application helps facilitate speedy recovery with no data loss.
Opinions expressed by DZone contributors are their own.
Comments