Managed Availability in Exchange Server: health sets, probes and why services restart

An app pool recycles overnight, a protocol goes Inactive with the requester HealthApi, or a server restarts with nobody logged on. Often no admin did it: Exchange did, through Managed Availability. In this post I'll explain how it decides, show how to trace what it did on Exchange Server SE and Exchange 2019, and cover the safe way to override it when you really must.

How it works#

Managed Availability, also called Active Monitoring, runs on every Exchange server inside the Microsoft Exchange Health Manager service: MSExchangeHMHost.exe manages the work and MSExchangeHMWorker.exe does it. It's designed to recover fast, not to tell you the root cause, and it works in three stages:

• Probes measure. Recurrent probes are synthetic transactions, such as a logon to a health mailbox or a call to a protocol endpoint, that run every few minutes. Checks compare performance counters with thresholds, and notifications let other services report problems directly. Each result lands in the ProbeResult event channel, where ResultType 3 means success, 4 means failure and 1 means timeout.
• Monitors decide. A monitor reads the probe results that match its sample mask and turns Unhealthy only when its threshold is reached, usually after several failures rather than one. A monitor that has been unhealthy for up to 60 seconds shows as Degraded; you'll also see Disabled, Unavailable and Repairing.
• Responders act. Recovery escalates in stages: for example recycle the app pool, then restart the service, then restart the server, then take the server offline so it stops accepting traffic. Every responder is throttled so recovery can't make things worse.

The probes, monitors and responders for one component form a health set, such as OWA.Protocol or HubTransport, and a health set is only as healthy as its worst monitor. Results go to event logs under Applications and Services Logs › Microsoft › Exchange › ActiveMonitoring and › ManagedAvailability. Local overrides live in the server's registry, and global overrides live in Active Directory.

Step-by-step: what did it see, and what did it do?#

1. Start with the summary#

Get-HealthReport -Identity EX01 | Where-Object AlertValue -ne 'Healthy' |
  Format-Table HealthSet, AlertValue, LastTransitionTime, MonitorCount -AutoSize

An empty result is what you want. Anything listed is a health set to drill into.

2. Find the unhealthy monitor#

Get-ServerHealth -Identity EX01 -HealthSet OWA.Protocol |
  Where-Object AlertValue -ne 'Healthy' | Format-Table Name, TargetResource, AlertValue -AutoSize
Get-MonitoringItemIdentity -Server EX01 -Identity OWA.Protocol | Format-Table Identity, ItemType, Name -AutoSize

The second command lists every probe, monitor and responder in the health set, with the exact, case-sensitive names you'll need later.

3. Read the probe error#

Get-WinEvent -ComputerName EX01 -LogName Microsoft-Exchange-ActiveMonitoring/ProbeResult -MaxEvents 500 |
  ForEach-Object { ([xml]$_.ToXml()).Event.UserData.EventXml } |
  Where-Object { $_.ResultType -eq '4' -and $_.ResultName -like '*owa*' } |
  Format-List ResultName, ExecutionStartTime, Error

Keep these queries narrow. The ProbeResult channel is very busy, and Microsoft warns that expensive queries against it can slow a production server. For problems that need a human, the Microsoft-Exchange-ManagedAvailability/Monitoring channel is a better first stop, and it includes the most recent probe error.

4. See what it did#

Get-WinEvent -ComputerName EX01 -LogName Microsoft-Exchange-ManagedAvailability/RecoveryActionResults -MaxEvents 20 |
  ForEach-Object { ([xml]$_.ToXml()).Event.UserData.EventXml } | Format-List *

Each event records which recovery action ran, what it acted on (an app pool, a service or the server), which responder asked for it and the result. Microsoft documents that an action is logged when it starts and again when it's considered complete, whether it succeeded or not. This is your evidence when someone asks why a service restarted at night.

5. Fix the cause, then re-run the probe#

Managed Availability treats symptoms. Fix what the probe error points to, such as a certificate, a full disk or an unreachable domain controller, then run the probe on demand and check the result and any error it returns. Take its name from the Get-MonitoringItemIdentity output (ItemType Probe):

Invoke-MonitoringProbe -Identity 'OWA.Protocol\<ProbeName>' -Server EX01 | Format-List

Overrides: the careful way#

An override changes a property of a probe, monitor or responder, most often Enabled. Use one only when you understand the cause and need breathing room, for example while you fix a dependency that keeps triggering a reboot responder. Microsoft's own example disables an Active Directory reboot responder on one server for 20 days:

Add-ServerMonitoringOverride -Server EX01 -Identity "AD\ActiveDirectoryConnectivityConfigDCServerReboot" -ItemType Responder -PropertyName Enabled -PropertyValue 0 -Duration 20.00:00:00
Get-ServerMonitoringOverride -Server EX01 | Format-List
Remove-ServerMonitoringOverride -Server EX01 -Identity "AD\ActiveDirectoryConnectivityConfigDCServerReboot" -ItemType Responder -PropertyName Enabled

• The identity format is HealthSet\ItemName[\TargetResource] and it's case-sensitive, so copy it from Get-MonitoringItemIdentity.
• Always use -Duration or -ApplyVersion (not both) so the override can't outlive the problem.
• Nothing changes immediately: the Health Manager checks for new configuration every 10 minutes, and global overrides (Add-GlobalMonitoringOverride) also wait for Active Directory replication.

For planned work such as reseeding a database copy, mark the monitor as being repaired instead (add -TargetResource if the monitor has one), then set it back to $false afterwards. Microsoft describes the Repairing state as a way to tell the system that a human is already working on the problem:

Set-ServerMonitor -Server EX01 -Name '<MonitorName>' -Repairing $true

Verify#

• Get-HealthReport -Identity EX01 shows the health set as Healthy again.
• RecoveryActionResults has no new actions against that resource.
• Get-ServerComponentState -Identity EX01 shows no component held Inactive by HealthApi.
• Get-ServerMonitoringOverride lists only overrides you meant to keep, each documented and time-limited.

Tips & gotchas#

• Leave the health mailboxes alone. Get-Mailbox -Monitoring lists them. Deleting or disabling them, or catching them in clean-up scripts, makes probes fail and can trigger the very restarts you're trying to avoid.
• Unexplained reboot? Check RecoveryActionResults for a bugcheck or reboot action before blaming hardware.
• HealthApi holds are symptoms. An Offline responder took the protocol out of service because probes kept failing; fix the cause and check the component returns. The POP3 and IMAP4 article shows a typical case.
• MSExchangeHMWorker.exe using CPU in short bursts is normal; if it stays high, see high CPU or memory on Exchange Server.
• Pair it with the Health Checker, which reviews configuration that Managed Availability doesn't judge.

References#

• Managed availability (Microsoft Learn)
• Manage health sets and server health (Microsoft Learn)
• Configure managed availability overrides (Microsoft Learn)