Exchange Maintenance Mode
When you are performing maintenance in your Exchange environment it’s important to place the server in maintenance mode.
When you place a server into maintenance mode the process will drain the transport queues. If it is a DAG member, it will move the active copies of the databases to another DAG member and ensure that no databases can be mounted. Finally, it will place all the components to an inactive state. This process is the same for Exchange 2013, 2016 & 2019.
In this examples below we are planning to perform maintenance on a server called EX1 which is a DAG member. To ensure our users can continue to work we will move the active copy of any database over to another DAG member called EX2.
Enter maintenance mode
### The following commands should be run in an administrative Exchange Management Shell! ### Set the HubTransport component to “Draining”, and redirect any messages currently in the queue to another server. If you're running a single Exchange server, you can skip the redirect command. Set-ServerComponentState -Server EX1 -Component HubTransport -State Draining -Requester Maintenance Redirect-Message -Server EX1 -Target EX2.domain.com ### If the server is a DAG member, run the following command to pause the node in the cluster. If your server is not a DAG member, skip to the final command to place the server into maintenance mode. Suspend-ClusterNode -name EX1 ### Disable database copy auto-activation. This command will also move any active database copies to other DAG members, assuming there are other healthy DAG members available. This is not instantaneous, it can take several minutes for the moves to occur. We'll check on it shortly anyway. Set-MailboxServer EX1 -DatabaseCopyActivationDisabledAndMoveNow $True ### Make a note of the database copy auto-activation policy on the server, so you can set it back to this value at the end of maintenance. Get-MailboxServer EX1 | Select DatabaseCopyAutoActivationPolicy ### If the policy is not already set to “Blocked”, run the following command to set it. Set-MailboxServer EX1 -DatabaseCopyAutoActivationPolicy Blocked ### Check for any database copies that are still mounted on the server. This command should return no results. If any database copies are still active on the server, and there are other DAG members that host copies of the database, perform a manual switchover. Get-MailboxDatabaseCopyStatus -Server EX1 | Where {$_.Status -eq "Mounted"} ### Place the server into maintenance mode Set-ServerComponentState EX1 -Component ServerWideOffline -State Inactive -Requester Maintenance
Check load balancing
For servers that are in a load-balanced pool on a hardware or software load balancer:
- Verify that the load balancer health checks have taken the server out of the pool or marked it as offline/inactive.
- If the load balancer does not automatically do this, manually mark the server as offline/inactive.
For servers that are in a DNS round robin group, remove the DNS record for this server’s IP address.
Remember to update your load balancing settings as appropriate after you have exited maintenance mode!
Exit maintenance mode
### The following commands should be run in an administrative Exchange Management Shell! ### Take the server out of maintenance mode. Set-ServerComponentState EX1 -Component ServerWideOffline -State Active -Requester Maintenance ### If a DAG Member, resume the node in the cluster. If the server is NOT a DAG member skip to the final step to set the hub transport back to active. Resume-ClusterNode –Name EX1 ### Set the database activation policy back to the setting you noted earlier (the default is Unrestricted) Set-MailboxServer EX1 –DatabaseCopyAutoActivationPolicy Unrestricted ### Re-enable database copy auto-activation Set-MailboxServer EX1 –DatabaseCopyActivationDisabledAndMoveNow $false #### Set hub transport to active Set-ServerComponentState EX1 –Component HubTransport –State Active –Requester Maintenance
Perform a health check
Here are some suggestions for health checking your Exchange servers after any maintenance.
- Check the cluster nodes are all up – verify that you have not left any DAG members suspended in the cluster by running the Get-ClusterNode cmdlet on one of the DAG members.
- Test service health – use the Test-ServiceHealth cmdlet to verify that all required services are running on each server.
- Test MAPI connectivity to every database – use the Test-MAPIConnectivity cmdlet to verify that all databases are mounted and accessible.
- Check the database copy status for DAGs – use the Get-MailboxDatabaseCopyStatus cmdlet to verify that all database copies, copy/replay queues, and content indexes are healthy.
- Test replication health for DAGs – use the Test-ReplicationHealth cmdlet on each DAG member to verify replication health is good.
- Check the database activation policy for each Mailbox server – verify that each Mailbox server that is in a DAG has the correct database activation policy for your environment.
- Check server component status – use Get-ServerComponent to verify that you have not left any servers in maintenance mode.
Thank you for the well laid out steps. I am training a junior Exchange administrator and am using this to document the steps he should take prior to upgrades/patches. The only thing I am adding is the actual commands in the last section (health check).