Understanding the Importance of Putting an Exchange Server in Maintenance Mode for Updates

Putting an Exchange Server into maintenance mode pauses its normal operations before you install a cumulative or security update. Mail stops routing through it, database copies move to other servers, and nothing reactivates behind your back.

I do this for every Exchange update, on single servers and on DAG members alike. Below, I explain what each step does and why it matters, so you can adapt the sequence to your own environment rather than blindly copying commands.

Does it make sense to put a single Exchange server in maintenance mode?

Absolutely. Switching to maintenance mode when updating or maintaining your single Exchange server is wise. Here’s the straightforward reason why:

• By activating maintenance mode, you’re effectively pausing your server’s usual activities, such as email traffic. This pause grants you complete control, ensuring updates occur on your terms. It’s all about preventing surprises and clearly understanding when and how your server’s services are paused and restarted.
• Understanding the importance of this control is critical. It lets you plan updates around your schedule, strategically minimizing disruptions for users. Instead of updates potentially causing unexpected downtime, you can decide when the server goes offline and when it comes back online, making the entire process smoother and more predictable.

In essence, engaging maintenance mode on your single Exchange server isn’t just a technical step; it’s you taking the reins to ensure the update process is smooth, controlled, and free of unexpected email flow or service hiccups. This way, you keep surprises to a minimum and reliability to a maximum.

Okay, let’s move on to Exchange DAG; here, it is more obvious why you should put the Exchange server in maintenance mode.

The Clear Benefits of Maintenance Mode in Exchange DAG Environments

If you manage servers as part of an Exchange Database Availability Group (DAG), you’re in a unique position regarding updates and maintenance. Here, putting your server into maintenance mode isn’t just recommended; it’s a crucial part of ensuring the smooth operation of your email services. Let’s talk about why:

• Seamless Collaboration: In a DAG setup, your servers work together to provide high availability and resilience. Switching a server to maintenance mode before an update helps maintain this harmony, ensuring that the rest of the group picks up the slack without missing a beat.
• Protecting Your Data: Maintenance mode in a DAG context safeguards your data integrity across multiple servers. It ensures that updates don’t interfere with the replication process, keeping your databases consistent and your messages safe.
• Predictability and Peace of Mind: Just like with a single server, taking control by using maintenance mode means updates happen on your terms. But in a DAG, this control is even more critical. It’s about ensuring not just one server, but your entire exchange environment remains stable and predictable during maintenance tasks.

In short, the interconnected nature of DAGs makes using maintenance mode not just a best practice but a foundational aspect of effectively managing your Exchange environment.

Let’s dive deeper into what this looks like in practice to put an Exchange Server in Maintenance mode.

Set Exchange Hub Transport in draining mode

Draining mode is a preparatory state for the Exchange Hub Transport server, where it begins to cease accepting new messages and processes any existing messages in the queue. Here’s what it entails and why it’s important:

• Purpose of Draining Mode: The main goal of putting the Hub Transport server in draining mode is to ensure that all messages it handles are delivered before the server undergoes maintenance. This mode prevents the server from accepting new email messages but allows it to continue processing and delivering any already in the queue.
• How It Works: When you set the Hub Transport server to draining mode, the server signals to the Exchange environment that it should not route new messages to this server. Meanwhile, the server works through its existing queue, ensuring all pending messages reach their intended destinations. This process helps to clear the server’s message queue in a controlled manner, minimizing the risk of losing any messages during the maintenance period.

Redirect message queue

By redirecting the message queue, you ensure that email communication within your organization is not interrupted, even as one server is being prepared for maintenance.

• Purpose: The purpose of redirecting the message queue is to reroute incoming and queued messages to another server within the Exchange environment. This ensures that no messages are sent to the server in draining mode, which is preparing for maintenance and will not process new messages.
• How It Works: Redirecting the message queue involves configuring the transport settings to move any new messages or messages still in the queue to another operational Exchange server. This ensures continuous mail flow within the organization, as the messages are seamlessly directed to a server that can process them immediately, avoiding delays or potential loss.

Suspending the Server from DAG

The step of suspending the server from the Database Availability Group (DAG) is pivotal when preparing for maintenance. Here’s what it entails:

• Purpose: Suspending the server from DAG means temporarily removing it from the group of servers that actively manage your Exchange data. This is crucial for ensuring that the server doesn’t receive any new data or client connections while it’s being updated or maintained.
• How It Works: To suspend a server from DAG, an administrator uses specific Exchange management commands. This action stops the server from participating in replication and automatic failover processes. It ensures that no additional mailbox databases are mounted on this server during the maintenance period. Existing databases are moved to other servers within the DAG, ensuring data redundancy and availability are not compromised.

This step is essential for a smooth maintenance process, keeping the server isolated from the DAG’s active data management tasks.

Disabling Database Copy Auto Activation

This step focuses on preventing the automatic activation of mailbox database copies on the server slated for maintenance. Here’s a straightforward explanation:

• Purpose: The goal is to stop the Exchange system from automatically moving database copies back to the server you’re preparing for maintenance mode. This ensures that while the server is offline or being updated, it won’t become a cluster node for active database copies, which could disrupt the maintenance process.

• How It Works: Disabling database copy auto-activation involves adjusting the server properties to prevent it from automatically becoming the host for active mailbox database copies. This is usually achieved through Exchange Management Shell commands, which modify the server’s settings to temporarily bypass its role in the database copy activation process within the DAG.

By taking this step, you ensure that your maintenance activities can proceed without the server inadvertently taking on active database roles, maintaining the stability and efficiency of the maintenance process.

Put the Exchange server in maintenance mode.

The final step officially puts the server into maintenance mode, preparing it for the upcoming update or maintenance tasks. Here’s the essence of this step:

• Purpose: The core purpose of putting the server into maintenance mode is to signal both the system and the administrators that the server is now undergoing maintenance. Once maintenance is complete, this status adjustment ensures that the server is expected only to perform its regular roles, such as email processing or database hosting.
• How It Works: Activating maintenance mode typically involves a series of commands executed via the Exchange Management Shell. These commands adjust various settings and services on the server to temporarily reduce its operational roles. It effectively pauses certain functions, ensuring the server can be safely updated or maintained without risking data integrity or service availability. This includes stopping specific Exchange services, dismounting databases (if not already handled in previous steps), and other necessary preparations for a safe maintenance process.

Remember that Exchange Services will not stop when Exchange is in maintenance mode. 

That covers what each step does and why. For the exact Exchange Management Shell commands, Ali Tajran’s guide sets them out in order. If you would rather script it, Roman Gelman’s PowerShell module puts the whole sequence behind a single command.

Verifying the Server Is in Maintenance Mode

Once you have executed the steps to put your Exchange server into maintenance mode, it is crucial to confirm that the server has entered this state correctly. This verification step ensures that all preparatory measures have been effectively applied, safeguarding your maintenance activities. Here’s how you can check if the server components are successfully in maintenance mode:

Get-ServerComponentState "YourServerName" | Select Component, State

The state of all components should be ‘Inactive’ except for two components listed in the screenshot above.

The Exchange servers I administer are VMs on VMware or Proxmox. Before I start performing updates with the new Exchange CUs, I reboot the server after putting it into maintenance and take a snapshot. You should know that a recent backup is on hand. It’s better to have more than one fallback possibility. 

I have performed updates with two Exchange Servers in a DAG during business hours in a production environment and have not received any user complaints. 

You can use the PowerShell script in the collection above to remove the Exchange server from maintenance mode.

I always rerun 

Get-ServerComponentState "YourServerName" | Select Component, State

to check if all components are in an active state

With

Test-ReplicationHealth

you check if the process database copy has been resumed

Lastly, it is good practice to run an Exchange Server health check after each update to ensure everything is in good shape.

I’d love to hear from you. Was this article helpful? Share your thoughts in the comments below. If you prefer, you can also reach me by email or connect with me on Reddit at Navigatetech.