Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 5: Managed Availability and OWA Health Probes

Summary: Exchange generates its own OWA traffic through Managed Availability, and that traffic can look confusing when it is mixed with real user requests. In this part, we separate health probes from interactive logons and look at exhealth.check, SelfTest, DeepTest, OWADEEPTEST, EACBACKENDLOGON, HealthMailbox traffic, backend 401 challenges, and the 241 response captured during testing.

Exchange’s own health traffic can look surprisingly similar to failed user authentication. Knowing how to recognize Managed Availability probes prevents normal 401 challenges, HealthMailbox activity, and synthetic tests from becoming false troubleshooting leads.

Part 4 focused on following one user request through W3SVC1, HttpProxy, and W3SVC2. The next problem is noise. Exchange continuously tests itself, so the same logs also contain requests generated by Managed Availability.

If those requests are treated as ordinary browser traffic, it is easy to misread a healthy probe as a user login, or to assume a 401 means something is broken.

What Managed Availability is doing

Managed Availability is Exchange’s built-in health monitoring system. Microsoft describes it as a combination of probes, monitors, and responders.

Probe
  measures or tests something
        ↓
Monitor
  decides whether the component is healthy
        ↓
Responder
  performs recovery or escalation when required

These items are grouped into health sets for components such as Outlook on the web, ActiveSync, transport, databases, and other Exchange workloads. Microsoft Learn: Managed availability

That means a request in an OWA log does not automatically mean a user opened a browser. Exchange itself may be generating the request to verify that the service is still working.

Check the health view before reading individual probes

Before digging through IIS logs, I like to see what Exchange currently thinks about server health.

Get-HealthReport -Server EX601

Get-ServerHealth -Identity EX601 |
Where-Object {$_.HealthSetName -match 'OWA'} |
Format-Table HealthSetName,Name,AlertValue -Auto

Get-HealthReport -Server EX601

Get-ServerHealth -Identity EX601 |
Where-Object {$_.HealthSetName -match 'OWA'} |
Format-Table HealthSetName,Name,AlertValue -Auto

Microsoft also provides Get-MonitoringItemIdentity when you need to see the probes, monitors, and responders that belong to a particular health set. Microsoft Learn: Manage health sets and server health

The simplest probe in the backend log: exhealth.check

One request appeared repeatedly in the backend OWA log:

GET /owa/exhealth.check   444   -   200

This is not an interactive user opening OWA. It is a health check against the backend OWA application.

The interesting part came during the backend authentication test from Part 3. Anonymous Authentication was disabled on Exchange Back End\owa, but exhealth.check continued to return HTTP 200.

That gives us another example of why cs-username=- must not be read as “Anonymous Authentication was used.” Anonymous was disabled in that test, yet the probe still returned 200 without a username in the IIS field.

SelfTest and DeepTest are different levels of checking

Not all OWA probes do the same amount of work. In the captured traffic, lightweight self-test activity could be separated from deeper synthetic transactions that exercised more of the OWA path.

The deeper tests generated recognizable identities and request patterns such as:

OWADEEPTEST
EACBACKENDLOGON
HealthMailbox...

Health mailboxes are part of Managed Availability. Microsoft documents that Exchange creates and uses health mailboxes for probe activity, so seeing a HealthMailbox identity in the logs is not evidence that a normal mailbox user signed in. Microsoft Learn: Managed availability and health mailboxes

A backend 401 can be part of a healthy probe

The most useful Managed Availability capture was the backend deep-test sequence. With backend Windows Authentication available, the probe did not simply start with HTTP 200.

The captured pattern looked like this:

Request reaches backend OWA
        ↓
401
        ↓
401
        ↓
HealthMailbox identity appears
        ↓
241
        ↓
/owa/default.aspx → 200
        ↓
service.svc → 200

The first 401 responses were part of the authentication exchange. They were followed by an authenticated HealthMailbox context and successful application requests.

This is exactly why a filter such as “show every 401 in W3SVC2” can create false alarms. A 401 must be interpreted with the requests that come before and after it.

What about status 241?

The deep-test flow also contained 241.

241 falls numerically in the 2xx range, but it is not a standard registered HTTP status code.

In this lab, IIS logged sc-status=241 as an intermediate value inside an Exchange-generated Managed Availability flow that then continued to HTTP 200. I could not find a public Microsoft definition that assigns a general OWA meaning to this value.

So I treat 241 only as a correlation clue from this captured transaction, not as a documented Exchange status code or something that should be generalized to unrelated web traffic.

Frontend probes and backend deep tests are not the same request

Another easy mistake is to see health traffic on both sites and assume it is one request moving from W3SVC1 to W3SVC2.

That is not always true. Managed Availability can run separate frontend and backend checks with different test identities and different purposes.

During the tests, the HealthMailbox used for frontend FBA activity was not necessarily the same mailbox identity used by the backend deep test. That is normal for synthetic monitoring and is another reason to correlate by time, URI, probe name, and identity instead of assuming every health request belongs to one chain.

How I separate user traffic from Managed Availability

No single column is enough by itself. The combination is what matters.

Do not “fix” probes by changing backend authentication

The Part 3 experiment showed that some probes still worked when backend Anonymous Authentication was disabled. That is useful for understanding the request path, but it is not a reason to redesign the backend authentication configuration.

The documented Exchange default remains Anonymous Authentication enabled together with Windows Authentication enabled on the backend OWA application, and Microsoft advises against manually configuring backend virtual directories during normal administration.

For production troubleshooting, the better approach is to understand which probe is failing, inspect its health set and surrounding logs, and restore any unsupported IIS changes before drawing conclusions.

What this part proved

• Exchange generates OWA requests through Managed Availability that can appear beside real user traffic.
• /owa/exhealth.check continued to return 200 in the tested flow even while backend Anonymous Authentication was disabled.
• cs-username=- did not prove Anonymous Authentication was being used.
• OWA deep-test traffic could include 401 challenge responses before an authenticated HealthMailbox request completed successfully.
• The captured 241 value appeared as an intermediate IIS status in a probe sequence that subsequently reached HTTP 200; without a public Microsoft definition, I treat it as a lab correlation marker rather than a documented Exchange status code.
• Frontend health probes and backend deep tests can use different HealthMailbox identities and should not automatically be treated as one request chain.
• Probe traffic should be separated from user traffic before interpreting IIS or HttpProxy authentication failures.

Next: Windows Authentication, NTLM, Kerberos, SPNs and SSO

Part 6 moves back to interactive browser authentication. We will enable Windows Authentication on the frontend, compare Negotiate and NTLM, test NTLM-only behavior, force Kerberos-only behavior, reproduce the missing-SPN credential prompt, add the HTTP SPN, and verify the resulting Kerberos service ticket with klist.

Exchange Server OWA Authentication Deep Dive Series

1. Part 1: How OWA Authentication Really Works
2. Part 2: Forms-Based and Basic Authentication – What Really Changes?
3. Part 3: Frontend vs Backend Authentication – Controlled A/B Tests
4. Part 4: Troubleshooting OWA Authentication with IIS and HttpProxy Logs
5. Part 5: Managed Availability and OWA Health Probes — current
6. Part 6: Windows Authentication, NTLM, Kerberos, SPNs and SSO — coming soon
7. Part 7: LogonFormat, DefaultDomain and a Practical OWA Authentication Troubleshooting Playbook — coming soon

References

• Managed availability – Microsoft Learn
• Manage health sets and server health – Microsoft Learn
• Get-HealthReport – Microsoft Learn
• Get-ServerHealth – Microsoft Learn
• Get-MonitoringItemIdentity – Microsoft Learn

Ceyhun Kirmizitas

Cloud and infrastructure professional with nearly two decades of experience in enterprise IT environments, spanning public cloud, private cloud, and hybrid architectures.