Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 4: Troubleshooting OWA Authentication with IIS and HttpProxy Logs

Summary: OWA authentication troubleshooting gets much easier when the same request is followed through all three log layers instead of reading one HTTP status in isolation. In this part, we compare successful FBA, a bad password, and a backend authentication failure across frontend IIS, Exchange HttpProxy, and backend IIS.

If you troubleshoot Exchange OWA by searching for 401 responses or treating every 302 as a successful sign-in, you can easily chase the wrong layer. This part gives you a repeatable way to correlate W3SVC1, HttpProxy, and W3SVC2 so the same request shows where it actually failed.

Part 3 showed that a valid OWA sign-in can still fail after the frontend has accepted the credentials. The browser alone cannot tell us where that failure happened. For that, I want the frontend IIS log, the OWA HttpProxy log, and the backend IIS log for the same time window.

The three log layers

The request path can be reduced to this troubleshooting map:

Browser
  ↓
W3SVC1          Frontend IIS :443
  ↓
HttpProxy\Owa   Exchange authentication and proxy context
  ↓
W3SVC2          Exchange Back End :444

The default locations used in these tests were:

Frontend IIS
C:\inetpub\logs\LogFiles\W3SVC1

Exchange HttpProxy OWA
C:\Program Files\Microsoft\Exchange Server\V15\Logging\HttpProxy\Owa

Backend IIS
C:\inetpub\logs\LogFiles\W3SVC2

Each layer answers a different question. W3SVC1 tells me what reached the frontend. HttpProxy tells me what Exchange believed about the request and where it tried to send it. W3SVC2 tells me what actually happened on the backend site.

A small W3C reminder is useful when reading these files: cs means client-to-server, sc means server-to-client, s means server, and c means client. IIS W3C timestamps are written in UTC, and the HttpProxy timestamps captured in this lab were UTC as well, so I convert the user’s reported test time before narrowing the log window.

Correlate the exact request when possible

Time-based correlation is useful, but the lab also gave us a stronger link between the frontend IIS log and the OWA HttpProxy log. The cafeReqId value in the W3SVC1 query string matched the HttpProxy RequestId for the same request.

W3SVC1
cafeReqId=64766ac5-7aa6-49b3-8a68-e5812a77753c

HttpProxy\Owa
RequestId=64766ac5-7aa6-49b3-8a68-e5812a77753c

When that identifier is available, I prefer it over relying only on nearby timestamps because it lets me follow the same request across the frontend and proxy layers directly.

Watch only new requests during a controlled test

For a clean test, I normally open the newest log file and follow only entries written after I start the capture. This avoids mixing the browser request with older health probes and unrelated traffic.

Get-Content -Path ((Get-ChildItem "C:\inetpub\logs\LogFiles\W3SVC1\u_ex*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1).FullName) -Tail 0 -Wait

Get-Content -Path ((Get-ChildItem "C:\inetpub\logs\LogFiles\W3SVC1\u_ex*.log" |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1).FullName) -Tail 0 -Wait

The same pattern can be used for W3SVC2 and for the newest file under Logging\HttpProxy\Owa. For longer investigations I usually copy the files and analyze them separately rather than keeping several live tails open.

Case 1 – Successful Forms-Based Authentication

A successful FBA sign-in starts with a POST to /owa/auth.owa. In the frontend IIS log, the important point is that the POST itself returns 302.

W3SVC1
POST /owa/auth.owa  → 302
GET  /owa/...       → application requests continue

The 302 is expected, but it is not proof by itself that the password was correct. We need to see what happens after the redirect.

In a successful request, HttpProxy carries the authenticated identity and the backend request completes successfully:

HttpProxy\Owa
AuthenticationType : FBA
IsAuthenticated    : true
AuthenticatedUser  : LAB6\auser601
HttpStatus         : 200
BackEndStatus      : 200

W3SVC2 then shows the user reaching the backend application on port 444:

W3SVC2
GET /owa/default.aspx   444   LAB6\auser601   200

Those three views together are much stronger evidence than the browser simply showing the mailbox.

Case 2 – Invalid password

The failed-password test is useful because it shows why a 302 from auth.owa is easy to misread.

The frontend still returned 302 for the POST:

POST /owa/auth.owa  → 302

But the next logon request contained a different clue:

GET /owa/auth/logon.aspx?...reason=2...

In this controlled test, reason=2 matched the intentionally incorrect password. So the correct interpretation is not “302 means authentication succeeded.” The interpretation is “Exchange processed the form submission and redirected the browser; inspect the following requests to determine the result.”

Case 3 – Frontend authentication succeeds, backend authentication fails

This is the most useful comparison because the browser can make it look like a login failure even though the frontend already accepted the user credentials.

With backend Windows Authentication disabled in Part 3, the frontend sequence was:

W3SVC1
POST /owa/auth.owa                       → 302
GET  /owa/                               → 401
GET  /owa/auth/logon.aspx?...reason=0... → 200

Now compare that with HttpProxy:

AuthenticationType : FBA
IsAuthenticated    : true
AuthenticatedUser  : LAB6\auser601
HttpStatus         : 401
BackEndStatus      : 401
ErrorCode          : ProtocolError
RoutingHint        : WindowsIdentity

This is the key evidence. Exchange still knew the authenticated user, but the proxied backend request failed with 401.

RoutingHint=WindowsIdentity is useful routing metadata, but I do not treat it as proof that the request used NTLM or Kerberos. Authentication-package verification needs provider configuration plus protocol evidence such as a Kerberos service ticket or an appropriate trace.

W3SVC2 confirmed the same failure boundary:

W3SVC2
GET /owa/   444   -   401

The frontend credential check and the backend request are therefore separate troubleshooting steps. A user can pass the first and fail the second.

Do not interpret cs-username by itself

The IIS cs-username field is useful, but it is not a direct label for the IIS authentication provider.

During the backend Anonymous-off test, /owa/exhealth.check still returned HTTP 200 while cs-username was -:

/owa/exhealth.check   444   -   200

Anonymous Authentication was disabled at that moment, so the dash cannot be used as proof that Anonymous Authentication handled the request.

The safe rule is simple: use cs-username as one observation, then correlate it with the IIS configuration, HttpProxy fields, request URI, and surrounding requests.

401 and 302 both need context

This is why I avoid troubleshooting OWA by filtering only for “401” and assuming every result means the same thing.

A practical correlation order

For a real OWA sign-in problem, I would work in this order:

1. Find the client request in W3SVC1
2. Note timestamp, URI, status, client IP and user-agent
3. Find the same time window in HttpProxy\Owa
4. Check AuthenticationType, IsAuthenticated and AuthenticatedUser
5. Compare HttpStatus with BackEndStatus
6. Check the matching W3SVC2 request on port 444
7. Only then decide whether the problem is frontend auth, proxy/routing, or backend auth

Health probes, localhost traffic, and HealthMailbox requests can create a lot of noise. Client IP, user-agent, URI, and a narrow timestamp window are usually the quickest way to keep the test request separate.

What this part proved

• A 302 from /owa/auth.owa is not enough to declare a successful login.
• In the bad-password test, the later logon request carried reason=2.
• In the backend authentication failure test, valid FBA credentials were already accepted while HttpProxy and W3SVC2 both showed backend 401.
• reason=0 and reason=2 were useful because they were correlated with the surrounding logs, not treated as a standalone error-code catalog.
• cs-username=- does not identify the authentication provider by itself.
• W3SVC1, HttpProxy, and W3SVC2 together provide a much clearer failure boundary than any one log alone.

Next: Managed Availability and OWA health probes

Part 5 will separate real user traffic from Exchange Managed Availability. We will look at exhealth.check, SelfTest, DeepTest, OWADEEPTEST, EACBACKENDLOGON, and HealthMailbox traffic, including the backend 401 challenge sequence and the unusual 241 IIS status captured during the tests.

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 — current
5. Part 5: Managed Availability and OWA Health Probes — coming soon
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

• Client Access services in Exchange Server – Microsoft Learn
• Manage health sets and server health – Microsoft Learn
• Configure logging in IIS – 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.