Exchange 2016 Database Availability Group Maintenance

Hello Everyone and Welcome to IT-Notes Blog!

This is my first post in this blog. And it is about “How-To perform Exchange 2016 DAG Maintenance”.

Existing Enviroment

We have two Exchange 2016 servers in a DAG with mailbox databases replicated between them for high availability. The Exchange servers are:

  • EXCH01
  • EXCH02

We have one mailbox databases:


There’s a copy of this mailbox databas on EXCH01 and EXCH02.

Put a mailbox server into maintenance mode:

We’ll start with putting EXCH01 into maintenance mode so we can install Exchange updates, Windows Updates, hardware maintenance etc.

In Exchange 2016, the mailbox servers include all the Exchange roles, CAS (Client Access) and MBX (Mailbox). If your Exchange 2016 server is providing CAS services for your clients, you should remove it from the load balanced array. How you do this will depend on how you have configured load balancing.

Also note that your incoming and outgoing external messages need to be routed through both servers so that when you put one into maintenance mode, this won’t stop external message delivery. This will depend on how you have your message routing configured.
Other than the CAS service, the server will be performing the below functions:

  • Message delivery
  • Cluster services (Primary Active Manager)
  • Mailbox service (either active or passive mailbox databases)

Message Delivery

The HubTransport component on EXCH01 needs to be drained. To do this, we put the HubTransport component into a draining state, restart the Transport Service then redirect messages that are pending delivery to EXCH02. Log into EXCH01 and run these commands from the Exchange Management Shell running as administrator:

SetServerComponentState EXCH01 -Component HubTransport State Draining Requester Maintenance
Restart-Service MSExchangeTransport
RedirectMessage Server EXCH01 Target Exch02

Press y when prompted

The server should now not be involved in message transport.

We can confirm this by checking that the HubTransport component on EXCH01 is draining:

GetServerComponentState EXCH01 -Component HubTransport


Cluster Services

If you’re wondering what the Primary Active Manager (PAM) is, well it’s the term given to the server that owns the quorum and reacts to server failures. Although a failure of the server that holds the PAM causes a failover to the Standby Active Manager (SAM), it’s best to fail this over gracefully. To do this, we need to pause the cluster node, EXCH01. This not only moves the PAM from EXCH01 to EXCH02 but it prevents EXCH01 owning this role till the cluster node is resumed.

First, let’s confirm where our PAM is located:

GetDatabaseAvailabilityGroup -Status | fl Name,PrimaryActiveManager


Here we see that it’s currently on EXCH01 which means we need to move it .

We need to move it to EXCH02 by running this command:

MoveClusterGroup "Cluster Group" Node EXCH02


We also need to prevent EXCH01 becoming the PAM by pausing the cluster node. You need to run this command from an elevated PowerShell window:

SuspendClusterNode EXCH01

We’ll just confirm this has in fact worked:



GetDatabaseAvailabilityGroup -Status | fl Name,PrimaryActiveManager


PAM has been moved just fine and the cluster node EXCH01 is paused. We can move on to the next step.

Mailbox service

We need to move any active mailbox databases off EXCH01. They should fail over when we shut down the server or when the services stop but we’ll move them off manually which is the recommended approach.

Let’s just see what databases are mounted on EXCH01 before we start this step:

GetMailboxDatabaseCopyStatus Server EXCH01


Ok, we can see mailbox database  NTT_NEW is mounted on EXCH01. To move it to EXCH02, we use this command:

GetMailboxDatabaseCopyStatus Server EXCH01 | ? {$_.Status -eq "Mounted"} | {e446ef79be674adb3c6945ce128768d37101f21a4bf2301a6de0b74a3fac67b5} {MoveActiveMailboxDatabase $_.DatabaseName ActivateOnServer EXCH02 -Confirm:$false}

We can now confirm our databases have been moved to EXCH02:

GetMailboxDatabaseCopyStatus Server EXCH02

All our mailbox databases are mounted on EXCH02.

The next step is to prevent EXCH01 automatically mounting the databases in case of a problem with EXCH02. To do this, we set the DatabaseCopyAutoActivationPolicy property to blocked on EXCH01:

SetMailboxServer EXCH01 DatabaseCopyAutoActivationPolicy Blocked

We can confirm that this was done by running this command:

GetMailboxServer EXCH01 | ft Name,DatabaseCopyAutoActivationPolicy


Our mailbox service on EXCH01 is now in maintenance mode.

We then put the server itself into maintenance mode:

SetServerComponentState EXCH01 -Component ServerWideOffline State Inactive Requester Maintenance

We can confirm that EXCH01 is now inactive by running the command below:

GetServerComponentState EXCH01 -Component ServerWideOffline

Your server is now in maintenance mode and we can now do the required work on it.

Take a mailbox server out of maintenance mode

When we’re done with our maintenance, we can take EXCH01 out of maintenance mode. We’ll reverse the changes we’ve made to put the server into maintenance mode.

Set the mailbox server as active

SetServerComponentState EXCH01 -Component ServerWideOffline State Active Requester Maintenance

Confirm this has worked:

GetServerComponentState EXCH01 -Component ServerWideOffline


Resume the cluster node

Run this command from an PowerShell window with elevated permissions:

ResumeClusterNode EXCH01

Confirm the node is now up in the cluster:



Set the mailbox server DatabaseCopyAutoActivationPolicy

Here we set the DatabaseCopyAutoActivationPolicy property to Unrestricted to allow EXCH01 to mount databases automatically if needed:

SetMailboxServer EXCH01 DatabaseCopyAutoActivationPolicy Unrestricted

We can confirm this has worked by running this command:

GetMailboxServer EXCH01 | ft Name,DatabaseCopyAutoActivationPolicy


Set the HubTransport component to active

SetServerComponentState EXCH01 -Component HubTransport State Active Requester Maintenance
Restart-Service MSExchangeTransport

Confirm that the HubTransport component is active:

GetServerComponentState EXCH01 -Component HubTransport


Confirm that our server is not in maintenance mode

To confirm that our server is no longer in maintenance mode, we can run the command below to check that all required components are active:

GetServerComponentState EXCH01 | ft Component,State -AutoSize


2 responses to “Exchange 2016 Database Availability Group Maintenance”

  1. Lian avatar

    Hi! Are there any manuals for MAC?

    1. D.Rusov avatar

      Hi Lian,

      So far I’m not planning to post any manuals for client operation systems. But may be in the future If i will get some interesting information to share i will post it.


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.