Ceyhun KIRMIZITAS

Applies to: Exchange Server SE / 2019 / 2016 Summary: OWA logon format settings define the documented sign-in format, while the lab showed that some alternate identity formats could still be accepted. In this final part, we compare FullDomain, UserName, PrincipalName, and DefaultDomain, then turn the findings from the full series into a practical OWA authentication troubleshooting workflow. OWA incidents become much slower when troubleshooting starts by changing settings instead of first locating the failure. This final part turns the series into a practical workflow: start from the symptom, identify the correct Exchange layer and evidence, and only then decide what needs to be changed. Part 1: How OWA Authentication Really WorksPart 2: Forms-Based and Basic Authentication – What Really Changes?Part 3: Frontend vs Backend Authentication – Controlled A/B TestsPart…

Applies to: Exchange Server SE / 2019 / 2016 Summary: Windows Authentication can make OWA sign-in look simple because the browser may open the mailbox without showing a credential prompt. That does not mean Kerberos is being used. In this part, we enable Windows Authentication, compare Negotiate and NTLM, force an NTLM-only test, reproduce a Kerberos failure caused by a missing HTTP SPN, add the SPN, and verify the resulting Kerberos service ticket. Seamless Exchange OWA sign-in is not evidence that Kerberos is working; NTLM can look exactly the same to the user. This part shows how to verify what is actually happening with provider configuration, SPN ownership, and Kerberos ticket evidence instead of relying on the browser experience. Part 1: How OWA Authentication Really WorksPart 2: Forms-Based and Basic…

Applies to: Exchange Server SE / 2019 / 2016 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 1: How OWA Authentication Really WorksPart 2: Forms-Based and Basic Authentication – What Really Changes?Part 3: Frontend vs Backend Authentication – Controlled A/B TestsPart 4: Troubleshooting OWA Authentication with IIS and HttpProxy LogsPart…

Applies to: Exchange Server SE / 2019 / 2016 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 1: How OWA Authentication Really WorksPart 2: Forms-Based and Basic Authentication – What Really Changes?Part 3: Frontend vs Backend Authentication – Controlled A/B TestsPart…