Exchange 2016 Security updates

Not applicable

Hello. If I am just applying Exchange monthly security updates which we do using our software distribution product, not Windows update, do I still need to put the server in maintenance mode like I would have to with a CU? It seems like starting with Exchange 2013, the update process has become more complicated than with 2010. Any particular reason for this? In 2010, I simply did a switch over of all the DB's, ran security updates or installed a CU, switched back and did the other server. Done....

7 Replies



MS recommends to restart your server before and after update. Restarting a server without putting in into maintenance mode is not the best idea. 

So first start the maintenance mode which will switch over the database copies, the restart your server, turn off antivirus software, patch it, restart again, turn on antivirus, switch off maintenance mode and finally, when you‘re in a hurry, start redistribution of the DBs. 


So what happens if a server restarts on it's own. Servers do that. A bugcheck or an exception and there's an unplanned restart. My assumption is all the DB's fail over to the mailbox server and when the rebooted server comes back up, all is good. Just seems like they make you go through a lot of trouble just to patch a server. Flushing queues, stopping the cluster service etc. Guess the question is what is so different about 2013/16 than 2010 that you have to do all this. Example, MBX1 is running a bit slow and a reboot is needed. I can't just activate DB's on MBX2 and reboot the thing? I have to put it in maintenance mode first? Seem ridiculous.

@Deleted If it seems ridiculous to you, don’t do it. Your server, your decision.

Still doesn't answer the question as to what happens in an unplanned reboot. They happen for a variety of reasons like power fails, a VM being accidently rebooted etc. There is no one there to put the server in maintenance mode. If you don't know, its OK because I haven't been able to find the answer either. Are we just to assume that everything will be OK. As I mentioned in my previous reply, my assumption is Active Manager will fail over the DB's, the Shadow Queue or Safety Net will take care of any messages, the Cluster Manager will maintain quorum as long as the witness server is available, and after the server comes back up, your only job is to re-distribute databases, or is it? Does anything else need to be done?

@Deleted Starting the maintenance mode will prepare Exchange for a "smooth" restart. All database copies are switched, the message queues are drowned, the whole system ist set to consistent state. It won't accept any incoming connections since the DAG knows it's state. And the services are set to inactive for the next reboot. A switchover also checks for example if databases can be switched. On errors the switchover stops and an administrator has the chance to check this out. On an failover (that's what a simple reboot is) there are no checks.


So if you just restart your system might be in an inconsistant state and services like the HealthManager have to do some work to repair your system. This might take longer until bringing the system up, depending on your hardware's performance.


And at least if you just reboot your system all services will come back as soon as possible. Usually this ist not wanted if you patch Exchange.


For example if you have more than 500 OUs in your organization EAC won't display any OU. You have to manually edit the ECP web.config to show more than 500. This change has to be repeated at least for every CU and IIS has to be restarted. If you restart IIS on an operating Exchange server the clients will get outages or error messages. So I'm checking my configuration changes after any update. When checked an fixed I manually switch back the server into active mode.


If you still just restart your systems everything might go easy. I'm not quite sure if you have to switch back the databases manually or if they switch back themselves after a while.


I assume that you don't have a support contract with Microsoft. If you have, you should consider opening a service request to make sure that you get support for any problem that'll appear while or after skipping the maintenance mode procedure.


Best practice: (This one describes CUs but SUs might patch some files needed by Exchange so I'd handle CU & SU equally):



Best Practices

  • [...]
  • Reboot the server beforehand.
  • [...]
  • Reboot your server upon completion of the update.
  • For exchange servers installed on database availability group, follow steps mentioned in Manage database availability groups in Exchange Server to put the DAG members in maintenance mode before installing the cumulative updates.

Good luck


Thanks. I plan on using Maintenance Mode for updates and CU's. Just curious what would happen if a mailbox server rebooted and it was unplanned and obviously not in Maintenance Mode. I am sure there are provisions for this as these things to happen.

Silly question but is it only servers with the Mailbox Role on them that need to be put in Maintenance Mode? We have a server with just the client and hub transport role only.


First take a look at Github, there are 2 scripts for starting and stopping maintenance easily, They should work with 2016 (


Surely Exchange provides mechanisms to "heal" failover switches (DB copies, shadow network etc.) Usually a failover shouldn't harm your system. But you should run backups nevertheless. ;)


Since Exchange 2016 enforces multi role servers I'm sure you don't have servers with just the mailbox role and others with cas and transport. Maybe you have a mailbox/cas/transport and a separate edge role running?! Or you have a mailbox server without mailboxes?!


Since dividing up the roles on several servers isn't recommended I'm not sure what you've done there and don't want to suggest you doing things I would do on my server setup.


At last you have to start maintenance mode on the servers you're going to patch. If you want to patch the "transport server" (let's say, the scripts I mentioned above, work) has to drown its queues and the "cas server" has to redirect client requests. So, yes. Bring any server you patch into maintenance mode.


Seems you migrated from 2010 to 2016 keeping the old known principles of different servers for different roles. That's not best practice. You should think of a redesign, maybe on the 2019/vNext upgrade...


Good luck, again.


Best Practice Exchange 2016: