Neowin first reported the change alongside this month’s Exchange security release. Microsoft had announced the retirement on July 8, warning that the August 2026 update would disable and remove the legacy client. The advance notice matters because OWA Light was often an invisible dependency: an old bookmark, a mailbox policy assigned years ago, a kiosk workflow, an accessibility workaround, or a nonstandard browser that only ever reached mail through the simplified interface.
Microsoft’s own language leaves little room for a rollback plan. OWA Light is being removed rather than merely hidden, so administrators should treat the August update as the final cutover to the standard Outlook on the web experience for on-premises Exchange.
OWA Light’s removal is a policy and compatibility change
OWA Light arrived with Exchange Server 2007 for a web that looked very different from today’s. It offered a simplified interface for older browsers, constrained devices, slow links, and environments where JavaScript-heavy web applications were impractical or prohibited. It was also used as a fallback when the full Outlook Web App experience could not run.
That historical role explains why the removal can still surprise an organization in 2026. The people who deliberately chose OWA Light may be long gone; the configuration they left behind may not be. A mailbox policy can enable the light interface per user, while the OWA virtual directory can expose a light-mode choice on the sign-in page. Neither setting proves users still rely on the experience, but both are useful indicators that the dependency has never been cleaned up.
Microsoft recommends moving users to standard Outlook on the web and reviewing internal documentation, bookmarks, training, helpdesk scripts, and accessibility workflows. The company’s pre-retirement guidance provided two controls to remove OWA Light before the update:
Set-OwaMailboxPolicy -OwaLightEnabled $false
Set-OwaVirtualDirectory -LogonPageLightSelectionEnabled $falseThe first setting only has effect where the relevant OWA mailbox policy is actually assigned to mailboxes. The second removes the light-client choice from the sign-in page. Those commands were valuable as a controlled transition before August; they are not a post-update escape hatch now that the component itself has been removed.
The practical task is therefore broader than checking whether a policy exists. Administrators should identify who receives an OWA mailbox policy, inspect devices and browsers used for webmail access, and make sure the modern client works in the environments where the light client had been retained. Locked-down workstations, embedded-browser deployments, jump hosts, remote kiosks, and older Linux endpoints are the most likely places for a hidden failure to appear.
Microsoft is shrinking an exposed Exchange web surface
Microsoft describes OWA Light as a legacy compatibility surface that adds ongoing engineering and security burden. That is a reasonable assessment. Exchange’s web-facing components have repeatedly demanded urgent attention over the years, and maintaining two rendering paths means maintaining separate behavior, controls, compatibility assumptions, and security review paths.
The company is not saying that OWA Light is being removed because of a newly disclosed vulnerability. The August update also addresses a small set of Exchange spoofing and elevation-of-privilege flaws, but the client retirement was planned separately and publicly announced a month earlier. Conflating the two would overstate the immediate security rationale.
Still, the security consequence is real: organizations that eliminate an obsolete public-facing mail client have less code and fewer configuration paths to secure. Microsoft’s announcement explicitly frames the standard Outlook on the web experience as the place where it intends to focus cross-browser support, accessibility work, and security improvements. In other words, the company has decided that keeping the old path viable competes with hardening the path nearly everyone else uses.
The relevant distinction for Exchange administrators is that removing OWA Light does not secure an unpatched server. The August update should be deployed for the security fixes it contains; the OWA Light retirement is a useful reduction in legacy exposure, not a substitute for patch management, Extended Protection, modern authentication, external-access controls, or monitoring of Exchange web endpoints.
Exchange 2016 and 2019 remain a licensing and lifecycle problem
The August update covers Exchange Server Subscription Edition publicly. Exchange Server 2016 and Exchange Server 2019 receive this month’s security update only for organizations enrolled in Microsoft’s Period 2 Extended Security Update program.
That limitation deserves more attention than the OWA Light headline. Exchange 2016 and 2019 reached end of support on October 14, 2025. Microsoft’s second ESU period runs from May 2026 through the end of October 2026, and Microsoft has said there will be no third extension. A server can therefore be technically capable of receiving the August update but still be excluded because its organization did not purchase the separate Period 2 ESU contract.
For organizations still running 2016 or 2019, this creates a short and concrete decision window. The security updates remain conditional for roughly another two and a half months, while the OWA Light retirement removes a legacy option that some environments may still have been using to defer browser or client remediation. The update should prompt two checks at once: whether the server is entitled to receive the patch, and whether the user population has been tested against the full web interface.
Microsoft’s Exchange Team has positioned Exchange Server Subscription Edition as the on-premises destination for customers that cannot move mailboxes to Exchange Online. For an organization staying on-premises, this is increasingly a migration requirement rather than an aspirational modernization project. At the end of October 2026, Exchange 2016 and 2019 will fall off the security-update path regardless of whether OWA Light had any remaining users.
The hybrid shared-mailbox bug has a workaround today
The August release also continues to carry a known issue first introduced by the June 2026 Exchange security update. In a specific hybrid configuration, mail sent as or on behalf of an Exchange Online shared mailbox can arrive in that shared mailbox’s Inbox as an attachment inside a wrapper message.
The affected arrangement is narrow but common enough to matter: the shared mailbox is in Exchange Online; the sending user’s mailbox remains on-premises; the user has Send As or Send on Behalf rights; and the shared mailbox has either MessageCopyForSentAsEnabled or MessageCopyForSendOnBehalfEnabled enabled so a sent-item copy is retained centrally.
Neowin correctly notes that Microsoft has not yet delivered a permanent product fix. But Microsoft Support’s published record contains an important detail absent from that account: there is already a supported mitigation. Administrators can disable the transport change introduced in the June update with a setting override:
New-SettingOverride -Name "DisableBlockSharedAndUserMailboxHeaders" -Component Transport -Section BlockSharedAndUserMailboxHeaders -Parameters @("Enabled=false") -Reason "Mitigate Sent Items issue in Exchange hybrid"
Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument RefreshMicrosoft says it is still investigating the issue. That means the override should be documented as a temporary exception and revisited when a later Exchange update changes the behavior. But hybrid administrators do not need to accept Inbox clutter, false-looking mail copies, or user confusion while waiting for an unspecified future release.
Before applying the mitigation, verify the affected path rather than assuming any shared-mailbox sent-item issue is the same defect. The condition depends on both mailbox location and the shared mailbox’s sent-copy settings. A message-routing or transport-rule problem can look superficially similar but would need a different investigation.
What administrators should do this week
The immediate response to this update should be operational rather than dramatic:
- Install the August Exchange security update on Exchange Server Subscription Edition and on Exchange 2016 or 2019 servers that are properly enrolled in Period 2 ESU.
- Inventory OWA mailbox policies and OWA virtual-directory settings for remaining OWA Light enablement, then identify the users and endpoints tied to those settings.
- Test modern Outlook on the web from any kiosk, constrained browser, locked-down endpoint, or accessibility workflow that may have depended on OWA Light.
- Review helpdesk material and internal URLs so users are not sent toward a client that no longer exists.
- Check hybrid shared-mailbox sent-item behavior after patching, and apply Microsoft’s documented setting override if the June-era wrapper-message issue is present.
OWA Light survived long enough to become the kind of Exchange dependency that administrators discover only after changing it. With the August 2026 update, discovery after the fact is no longer an option: the legacy web client is gone, and organizations still relying on Exchange 2016 or 2019 now have until the end of October 2026 before the patches themselves stop arriving.