FAQ 000160 – How to properly perform maintenance on an Exchange DAG (reboot me softly)

This article applies to:
Exchange 2016, Exchange 2019, Exchange SE

This article describes how to properly perform a maintenance procedure on Exchange Servers that are members of an Exchange Database Availability Group (DAG).

You will typically need this in order to perform maintenance work like hardware upgrades, 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 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 memorize the long path or to wonder around searching for it (in case Exchange was installed in a custom install path). In order to switch directly to Exchange scripts folder, just type the following command in the Exchange PowerShell window.

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 other servers in the DAG from attempting a database fail-over onto the machine where you are currently performing maintenance. Also all active databases will be moved to the other node(s).

After the maintenance work is done, you end the maintenance with StopDagServerMaintenance.ps1. Your server is back in business and you can continue with work on remaining members of the DAG.

Once the maintenance is completed on all DAG member servers, the only thing left to do, is to redistribute databases with the RedistributeActiveDatabases.ps1 script which will automatically redistribute mailbox databases, based on the configured activation preference.

Now lets put those tools to work:
Before performing any maintenance on your Exchange DAG Servers it might be a good idea to check if there is anybody else logged in, to prevent multiple people doing something to your servers at the same time. So here is a handy command which will generate a list of servers in your DAG and then check for logged in users on each of them:

Copy to Clipboard
Syntax Highlighter# Check if there are logged on users on any of my Exchange DAG member server 
$MyDAGServers = Get-DatabaseAvailabilityGroup | Where-Object {$_.Servers -match $env:COMPUTERNAME} | Select-Object -ExpandProperty Servers | Select-Object Name | Sort-Object Name
$MyDAGServers | Foreach-Object {$commandstring = "query user /server:" + $_.Name; Write-Host "Server:" $_.Name; Invoke-expression $commandstring; Write-Host}

So here are the steps on how to perform maintenance on your Exchange Server:

Repeat the same steps stated above on all you DAG member servers.

Once the maintenance work is completed on all servers in the DAG, we need to redistribute mailbox databases back to server(s) where those belong.
For that purpose you can execute the following script:

Optional follow-up steps:

If you want to check or document the layout of your databases after all work is done, you can use following commands:

You can also use the command examples given below to automatically perform checks across all DAG member servers:

• if Exchange related services are up and running;
• if server components are up and running;
• if mailbox replication is functioning correctly;
• and if all mailbox databases are online and indexed.

NOTE1
On servers that are handling larger amount of data it can take some time until indexing service picks up. So if you run the Get-MailboxDatabaseCopyStatus command and  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.

NOTE2
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, this switch can be omitted.

NOTE3
As you can see we are using the variable $env: computername to get the name of the machine. This allows reuse of the code without need to adjust for server names every time and also reduces the possibility of calling the command on a wrong server.