Probably not such a good idea to disable Managed Availability

Two previous posts describe why a self-monitoring and healing capability is useful in software applications and provide an overview of how the Managed Availability framework provides these capabilities in Exchange 2013 and Exchange 2016. As in any discussion about technology, the almost inevitable question that arises after people have had a chance to think about the material is “what if…”

In this case, the thought is whether Exchange 2013 or Exchange 2016 need a Managed Availability subsystem at all and what would happen if Managed Availability wasn’t running? The logic behind this notion is that the server will perform better because the resources (chiefly memory) normally used by Managed Availability would then be available for other work.

It’s easy to test the theory on a server. Stop the Microsoft Exchange Health Manager service (or, if you really want to, change the service startup status from Automatic to Disabled). Now wait to see what happens. The answer is “not much”. All you have done is to remove the server's capability to monitor its operations. Mail is still transported and delivered. The Information Store still mounts databases and connects clients. Active Manager will activate database copies automatically to execute a failover within a DAG. All is well, or so it seems.

It’s good to know that Exchange will function perfectly happily without the array of probes, monitors, and responders that Managed Availability deploys to perform its task of keeping a server online at all costs. However, once Managed Availability is stopped, you prevent Exchange monitoring itself for problems and stop it attempting to self-heal if an issue is detected.

Removing any capacity from software to execute automated tasks is fine if you are willing to take on the workload. So feel free to stop Managed Availability using all that valuable RAM or clicking up those hard-to-get CPU cycles if you feel that you’re better equipped to monitor servers and fix any problems that you find. Unfortunately, this is work that might become tiresome and mundane, especially in the wee hours of the night, when most people find that they are more interested in what’s on TV than reviewing the contents of application event logs, scanning performance monitor counters, or checking that email is flowing. On the other hand, software just loves doing this kind of repetitive, well-defined tasks. In fact, it’s what software does best.

More importantly (in a formal sense), if you disable Managed Availability, you create a scenario where Exchange operates in an untested environment and if a problem happens, you might just have an issue. Microsoft expects Managed Availability to be running on every Exchange 2013 or Exchange 2016 server, so beginning a support call with “I disabled Managed Availability and then all hell broke loose…” is unlikely to cause the cheery support technician to applaud your charm, style, and wisdom. They might just end up questioning your sanity, but that’s another story.

For these reasons, but especially because no one wants their sanity to be questioned, it is best to leave Managed Availability alone to work in the background. Just accept that self-monitoring is part of what an Exchange server does. For now, anyway.

Happy New Year!

Follow Tony @12Knocksinna