This article applies to:
Exchange 2016
This article describes how to properly perform a maintenance procedure on a 2 node Exchange Database Availability Group (DAG).
You will typically need this in order to perform maintenance work like hardware installation, patching, software upgrades and similar, where it is necessary to shut down or reboot an Exchange machine that is part of a DAG.
For this purpose Microsoft delivers 3 PowerShell scripts as a part of your Exchange installation :
StartDagServerMaintenance.ps1 StopDagServerMaintenance.ps1 RedistributeActiveDatabases.ps1
Those scripts will automate a lot of steps for you. For example, StartDagServerMaintenance.ps1 will set the Exchange server into maintenance mode, which will prevent that other servers in the DAG, attempt a database failover onto the maschine where you are currently performing maintenance work. Also all active databases will be moved to the other node(s). And after the maintenance work is done, you will be able to automatically redistribute database with the RedistributeActiveDatabases.ps1 script based on the configured activation preference.
Those scripts are located in the Exchange scripts folder. In Exchange PowerShell the path to this folder is preloaded in the variable $exscripts. Therefore you don’t need to memorise the langly path or to wonder around seaching for it (in case Exchange was installed in a non-default path). In order to switch directly to Exchange scripts folder, just type the following command in the Exchange PowerShell window.
cd $exscripts
So here are the steps on how to perform maintenance on your Exchange 2016 DAG:
On Server1
cd $exscripts .\StartDagServerMaintenance.ps1 -ServerName SERVER1 -OverrideMinimumTwoCopies
Do you maintenance work
.\StopDagServerMaintenance.ps1 -ServerName SERVER1
On Server2 (same process as on Server1)
cd $exscripts .\StartDagServerMaintenance.ps1 -ServerName SERVER2 -OverrideMinimumTwoCopies
Do your maintenance work
.\StopDagServerMaintenance.ps1 -ServerName SERVER2
Now that maintenance work is done on both servers, all database copies are active on SERVER1 and we need to redestribute them back to server(s) where those belong. For that purpose you can execute the following script
.\RedistributeActiveDatabases.ps1 -DagName DAGNAME -BalanceDbsByActivationPreference -Confirm:$False
Additional tips:
TIP1
In order to verify that everything went OK with the database moves, at any given time, you can use the following command.
Get-MailboxDatabaseCopyStatus -Server SERVER1 | Format-Table -Autosize Get-MailboxDatabaseCopyStatus -Server SERVER2 | Format-Table -Autosize
On servers that are handling larger amount of data it can take some time until indexing service picks up. So if for example ContentIndexState shows any value other than Healthy, simply wait 10-15 minutes. As a last resort you can force the retry by simply restarting the Microsoft Exchange Search Service.
TIP2
In this example we used the -OverrideMinimumTwoCopies switch with the StartDAGServerMaintenance.ps1 script. The script will by default make sure that there are at least 2 available copies of data available, before it attempts to move a database. Since we here have only 2 nodes during maintenance on one of those you will actually have only 1 active copy available during the maintenance. Therefore the usage of the switch -OverrideMinimumTwoCopies is necessary. In environments where you have 3 or more copies of a database, you can omit this switch.
- FAQ 000181 – How to enable mailbox auditing using PowerShell - August 1, 2023
- FAQ 000180 – How to set Microsoft Teams Room Device to use internal NTP server - December 15, 2021
- FAQ 000178 – How to change the sender and reply E-mail address in Microsoft Bookings - January 11, 2021
Great info… my comment/question is… in the scenario where you have 2 nodes in your cluster, and a DAG defined for the main databases, yet have a single database not apart of a DAG on each… how can you proceed to maintenance, when the scripts won’t run, cause it still finds that there is still an active database on it? How would proceed to patch that?
Well, building a DAG for high availablity and then having a database that is not highly available on those, does not make much sense, does it? I would suggest you move mailboxes from those “standalone databases” to database that is a part of the DAG. They will probably contain special sytem mailboxes that need to be moved out of those. For example, to move Arbitration mailboxes to another database, you would use: Get-Mailbox -Database -Arbitration | New-MoveRequest -TargetDatabase . Do not attempt to forcibly remove a database before all system mailboxes are moved, as that could break your exchange server
Thanks for the great article …