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:

• EXDB_NEW

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:

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:

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:

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:

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:

We’ll just confirm this has in fact worked:

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:

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

We can now confirm our databases have been moved to 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:

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

Our mailbox service on EXCH01 is now in maintenance mode.

We then put the server itself into maintenance mode:

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

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

Confirm this has worked:

Resume the cluster node

Run this command from an PowerShell window with elevated permissions:

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:

We can confirm this has worked by running this command:

Set the HubTransport component to active

Confirm that the HubTransport component is active:

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: