0x80040115: Outlook cannot reach Exchange over MAPI over HTTP any more

Fix it now

0x80040115 is MAPI_E_NETWORK_ERROR, published as an operation that was unsuccessful because of a problem with network operations or services. Outlook built the profile and then could not hold a session to the server. Establish the scope first: everyone points at the server, its certificate or the network, and one machine points at that machine.

Get-MapiVirtualDirectory | Format-List Server,InternalUrl,ExternalUrl
Get-OrganizationConfig | Format-List MapiHttpEnabled
Get-ExchangeCertificate | Format-List Subject,CertificateDomains,NotAfter,Services
Test-OutlookWebServices

1. Ask how many people are affected before touching anything. One machine is a client problem; everyone at once is not.
2. On an affected client, hold Ctrl, right-click the Outlook icon in the notification area and choose Connection Status. Whether any connections are listed, and over which protocol, tells you how far it got.
3. On the server, confirm the MAPI virtual directory has internal and external URLs set and that they use names the certificate covers.
4. Check the certificate is current and enabled for IIS. A renewal that was installed but never assigned produces this on the day the old one expires.
5. For a single machine, create a fresh Outlook profile against the same mailbox and test in that before changing anything else.

0x8004011D and 0x80040119 appear alongside this one and Microsoft publishes no meaning for either. Do not let a code you cannot look up steer the investigation; work from the scope and from what the server says.

If clients reconnect, stop here. If they do not, the next section covers what Outlook is trying to do and the four places it fails.

Why it happens

Outlook used to reach Exchange by wrapping RPC inside HTTP, the mechanism everyone called Outlook Anywhere. Current Exchange offers MAPI over HTTP instead, a simpler protocol carried over ordinary HTTPS, and Microsoft describes it as the default protocol for Outlook in Exchange Server SE. Which one a client uses is decided by Autodiscover and the organisation’s configuration, not by the client’s preference.

0x80040115 is raised after all of that has been negotiated. The published meaning is precise and it is worth taking literally: NetworkError, MAPI_E_NETWORK_ERROR, “An operation was unsuccessful because of a problem with network operations or services.” It is not a statement about the mailbox, about permissions or about the client’s version. It says the session could not be carried.

That matters because the two codes that keep it company are unhelpful. 0x8004011D and 0x80040119 do not appear in Microsoft’s published error-code table and have no documented meaning, so any confident explanation of them is somebody’s inference. Treat them as company rather than evidence.

On the question of client versions: Microsoft’s supportability matrix lists Microsoft 365 Apps for enterprise, Outlook 2024, 2021, 2019 and 2016 as supported clients for Exchange Server SE, 2019 and 2016. So an old-but-listed Outlook is not by itself an explanation for this error. What is true, and is a separate argument, is that Office 2016 and Office 2019 reached the end of support on 14 October 2025 and receive no further fixes of any kind – which is a reason to move them, not a diagnosis for today’s outage.

Full reference

Scope first, then layer

The endpoints Outlook depends on

The rule that saves time here is that these have to agree with each other and with the certificate. A MAPI virtual directory pointing at one name while Autodiscover hands out another produces intermittent failures that look like network problems, because for some clients the cached configuration is still the old one.

Two codes with nothing behind them

0x8004011D and 0x80040119 are absent from Microsoft’s published MAPI error-code table, and there is no vendor page describing either. In practice they appear alongside 0x80040115 in the same Outlook error dialogs. Record them, note that the vendor does not publish a meaning, and diagnose from the code that does have one and from the scope of the failure. Any article that tells you precisely what they mean is filling a gap the vendor has left.

Where the client version genuinely does matter

• Microsoft lists Microsoft 365 Apps for enterprise, Outlook 2024, 2021, 2019 and 2016 as supported clients for Exchange Server SE, 2019 and 2016, so all of those should connect.
• Office 2016 and Office 2019 reached the end of support on 14 October 2025. Being listed as a supported client is not the same as being a supported product: those builds receive no further security or reliability fixes.
• Office LTSC 2021 reaches the end of support on 13 October 2026, which is close enough to plan around now rather than later.
• A build that receives no fixes will, in time, fall behind a change made on the server side. That is a reason to plan a refresh, not an explanation for a failure today.
• If you are weakening a server’s TLS or authentication configuration so that one old client keeps working, you have moved the risk rather than fixed the problem.

Confirming the fix from the client rather than the console

Outlook caches a great deal, so a server-side change is not visible immediately. After a URL or certificate change, test on a client that has been closed and reopened, and prefer a machine that was failing rather than the one you happen to be sitting at. Connection Status, reached by holding Ctrl and right-clicking the Outlook icon in the notification area, shows the server names and protocol actually in use and is a faster answer than another round of cmdlets.

Every code this article covers

Confirm the fix worked

1. Get-MapiVirtualDirectory shows internal and external URLs that the certificate covers.
2. Get-ExchangeCertificate shows a current certificate assigned to IIS that includes the client namespace and the Autodiscover name.
3. Test-OutlookWebServices completes without an error.
4. Connection Status on a previously failing client lists connections to the server you expect.
5. A second client at the same site connects as well, which rules out one machine.

Questions people ask about this