Exchange Server Auth Certificate Field Guide: Validation, Rotation, Recovery, and Time Zone Issues

Exchange Server Auth Certificate Field Guide: Validation, Rotation, Recovery, and Time Zone Issues

Exchange, Exchange Server SE / 2019 / 2016
Applies to: Exchange Server SE / 2019 / 2016 In a healthy Exchange Server environment, Exchange Server Auth Certificate renewal should normally be a straightforward process. In the field, however, I have seen cases where this process did not go as expected. Sometimes the certificate is still healthy. Sometimes it is close to expiration. In other cases, it is already expired, invalid, or missing from one or more Exchange servers. The correct action is not the same in every case. Because of this, I wanted to put together a practical guide based on the Exchange Server Auth Certificate cases I see in real environments. This guide shows how to check the current state, choose the correct path, renew or replace the certificate when needed, validate the result, and complete the…
Read More
Recover the Microsoft Exchange Self-Signed Certificate Without EMS

Recover the Microsoft Exchange Self-Signed Certificate Without EMS

Exchange, Exchange Server SE / 2019 / 2016
Applies to: Exchange Server SE / 2019 / 2016 / 2013 Exchange Server creates a self-signed certificate during setup. Its friendly name is normally Microsoft Exchange, and its subject is the Exchange server name. For example, if the server name is EX1901, the certificate subject is CN=EX1901. Normally, you do not need to touch this certificate. But if it is removed, or if the Exchange Back End HTTPS binding loses the certificate, OWA, ECP, ActiveSync, and Exchange Management Shell can be affected. Microsoft documents this problem and uses New-ExchangeCertificate to create a replacement certificate. One of the possible symptoms is that Exchange Management Shell itself cannot connect. This post shows a practical recovery path when EMS is not available. Microsoft's recovery article is scoped to Exchange Server 2013 and 2016;…
Read More
Windows 11 25H2 System Tray Disappears After KB5121003 and KB5120998 – Reproduced and Tested

Windows 11 25H2 System Tray Disappears After KB5121003 and KB5120998 – Reproduced and Tested

Windows 11, Windows Client
Applies to: Windows 11 25H2 Summary: On a Windows 11 25H2 test VM, the entire system tray disappeared after installing KB5121003 and disappeared again after installing the later KB5120998 cumulative preview. Removing KB5121003 rolled the VM back to OS Build 26200.8037 and immediately restored the clock, network, volume and notification area. This post documents the reproduction, rollback, temporary block and the follow-up test with KB5120998. This is a controlled reproduction on one Windows 11 25H2 VM, not a claim that every Windows 11 25H2 device will experience the same problem. At the time of writing, Microsoft does not list this exact whole-system-tray symptom as a known issue for KB5121003. In This Article 1. Environment and Starting Point 2. What the Problem Looked Like 3. Roll Back KB5121003 4. Result After…
Read More
Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 7: LogonFormat, DefaultDomain and Troubleshooting Playbook

Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 7: LogonFormat, DefaultDomain and Troubleshooting Playbook

Exchange
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…
Read More
Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 6: Windows Authentication, NTLM, Kerberos, SPNs and SSO

Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 6: Windows Authentication, NTLM, Kerberos, SPNs and SSO

Exchange
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…
Read More
Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 5: Managed Availability and OWA Health Probes

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

Exchange
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…
Read More
Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 4: Troubleshooting OWA Authentication with IIS and HttpProxy Logs

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

Exchange
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…
Read More
Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 3: Frontend vs Backend Authentication – Controlled A/B Tests

Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 3: Frontend vs Backend Authentication – Controlled A/B Tests

Exchange
Applies to: Exchange Server SE / 2019 / 2016 Summary: In Part 2, we changed the frontend authentication methods and watched the browser behavior change with them. In this part, the frontend stays on the normal FBA configuration while we change only the backend OWA authentication settings. The goal is to separate “the user authenticated at the frontend” from “the request reached the backend successfully.” A user can enter valid credentials and still be returned to the Exchange OWA logon page because the failure happened after frontend authentication. This part shows how to prove where the failure occurs instead of assuming the password or the frontend authentication method is the problem. Part 1: How OWA Authentication Really WorksPart 2: Forms-Based and Basic Authentication – What Really Changes?Part 3: Frontend vs…
Read More
Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 2: Forms-Based and Basic Authentication – What Really Changes?

Exchange Server SE / 2019 OWA Authentication Deep Dive – Part 2: Forms-Based and Basic Authentication – What Really Changes?

Exchange, Exchange Server SE / 2019 / 2016
Applies to: Exchange Server SE / 2019 / 2016 Summary: In Part 1, we mapped the OWA authentication layers and captured the default configuration. In this part, we change only the frontend OWA authentication settings and watch what happens in Exchange, IIS, and the browser. Changing one Exchange OWA authentication setting can completely change what IIS allows and what the browser shows. Understanding those differences makes it much easier to tell a real authentication failure from an expected 401 challenge, a Basic prompt, or the normal Exchange OWA sign-in flow. Part 1: How OWA Authentication Really WorksPart 2: Forms-Based and Basic Authentication – What Really Changes? — you are herePart 3: Frontend vs Backend Authentication – Controlled A/B TestsPart 4: Troubleshooting OWA Authentication with IIS and HttpProxy LogsPart 5: Managed…
Read More