On Exchange Server 2016 and later, Outlook reaches the mailbox with MAPI over HTTP, and when any link in that path breaks, users see "The connection to Microsoft Exchange is unavailable" or a status bar stuck on Disconnected. In this post I'll walk the chain from the user's protocol settings through Autodiscover, the MAPI virtual directory and the app pools to the load balancer, with a check and a healthy result for each link.
Errors this guide fixes
The connection to Microsoft Exchange is unavailable. Outlook must be online or connected to complete this action.Outlook (new profile)+1 more guideMicrosoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance.Outlook (public folders, online archive)DisconnectedOutlook status barCannot expand the folder.Outlook (public folders, online archive)
Symptoms#
Creating a profile fails, often right after Autodiscover seemed to succeed:
The action cannot be completed. The connection to Microsoft Exchange is unavailable.
Outlook must be online or connected to complete this action.- Existing profiles show
Disconnectedin the status bar. - Opening public folders or an online archive fails with
Cannot expand the folder. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance. - OWA works for the same user, so the account and the mailbox database are fine.
- If users fail on and off, suspect one server behind the load balancer; if everyone fails right after patching, suspect server state.
Why it happens#
Outlook gets its MAPI over HTTP URLs from Autodiscover, then opens HTTPS sessions to /mapi/emsmdb (the mailbox) and /mapi/nspi (the address book) on your namespace. The front end on any Mailbox server proxies them to the Exchange Back End website on the server that holds the active database copy. A break anywhere on that path produces the same message:
| Layer | What goes wrong | Check |
|---|---|---|
| Mailbox | MAPI disabled for the user, or MAPI over HTTP turned off with no working fallback | Get-CASMailbox |
| Autodiscover | No settings, or URLs pointing at the wrong name | Test E-mail AutoConfiguration |
| Virtual directory | Missing URLs, changed authentication | Get-MapiVirtualDirectory |
| Server | MAPI app pools stopped, components left Inactive after maintenance | Get-ServerComponentState, IIS |
| Load balancer | Probe checks only OWA, SSL offloading with Extended Protection | /mapi/healthcheck.htm |
| Client | Registry value that disables MAPI over HTTP | HKCU\Software\Microsoft\Exchange |
How to fix it#
1. Rule out the mailbox's protocol settings#
Get-CASMailbox jane@contoso.com | Format-List *Mapi*
Get-OrganizationConfig | Format-List MapiHttpEnabled
Set-CASMailbox jane@contoso.com -MAPIEnabled $trueMAPIEnabled must be True; when it's False, Outlook shows exactly the errors above. The mailbox-level MapiHttpEnabled is normally empty, which means it follows the organization setting. If someone set it to False while testing, clear it with Set-CASMailbox jane@contoso.com -MapiHttpEnabled $null.
2. Confirm Autodiscover returns MAPI URLs#
Run Test E-mail AutoConfiguration (Ctrl + right-click the Outlook icon in the notification area). The Results tab should list URLs such as https://mail.contoso.com/mapi/emsmdb/?MailboxId=<GUID>@contoso.com on your namespace. If Autodiscover fails, fix that first with Autodiscover troubleshooting for Exchange Server; Outlook can't connect to URLs it never received.
3. Check the MAPI virtual directory on every server#
Get-MapiVirtualDirectory | Format-List Server, InternalUrl, ExternalUrl, IISAuthenticationMethods
Set-MapiVirtualDirectory -Identity "EX01\mapi (Default Web Site)" `
-InternalUrl https://mail.contoso.com/mapi -ExternalUrl https://mail.contoso.com/mapiBoth URLs should use the load-balanced name on your certificate, identical on every server. If ExternalUrl is empty, clients outside the network aren't offered MAPI over HTTP. IISAuthenticationMethods normally includes Ntlm, Negotiate and OAuth; keep OAuth if you use Hybrid Modern Authentication.
4. Check components, health and app pools#
Get-ServerComponentState EX01 | Where-Object State -ne "Active" | Format-Table Component, State
Get-HealthReport EX01 | Where-Object { $_.HealthSet -like "*Mapi*" -or $_.HealthSet -like "Outlook*" } |
Format-Table HealthSet, AlertValue
Import-Module WebAdministration
Get-ChildItem IIS:\AppPools | Where-Object { $_.Name -like "MSExchangeMapi*" } | Select-Object Name, StateForwardSyncDaemon and ProvisioningRps are normally Inactive on-premises. Anything else Inactive, such as ServerWideOffline, usually means a server was left in maintenance mode after patching:
Set-ServerComponentState EX01 -Component ServerWideOffline -State Active -Requester MaintenanceThen complete the remaining exit steps from DAG maintenance mode. The MAPI app pools (MSExchangeMapiFrontEndAppPool, MSExchangeMapiMailboxAppPool and MSExchangeMapiAddressBookAppPool) must all be Started. Restart-WebAppPool MSExchangeMapiFrontEndAppPool recycles one without an iisreset; if a pool keeps stopping, look for w3wp.exe crashes in the Application log.
5. Test healthcheck.htm and fix the load balancer#
Invoke-WebRequest https://mail.contoso.com/mapi/healthcheck.htm -UseBasicParsing | Select-Object StatusCode, ContentA healthy server answers 200 with 200 OK and its own FQDN in the body. Each protocol has its own page (/owa, /ews, /mapi, /rpc, /oab, /Microsoft-Server-ActiveSync, /autodiscover), and it stops returning 200 when Managed Availability takes that protocol offline or its component is set Inactive. If your load balancer probes only /owa/healthcheck.htm, a server whose MAPI stack is down keeps receiving Outlook traffic, so probe /mapi/healthcheck.htm for the MAPI service. Also make sure the load balancer doesn't offload SSL, which Extended Protection doesn't support, and that its certificate is valid for the namespace.
6. Check the client#
A MapiHttpDisabled DWORD set to 1 under HKCU\Software\Microsoft\Exchange stops Outlook from using MAPI over HTTP; it's sometimes left behind by an old script or policy. Remove it unless you deliberately rely on Outlook Anywhere, then restart Outlook.
Verify the fix#
- Ctrl + right-click the Outlook icon › Connection Status: every line shows Established with protocol HTTP, and the Req/Fail column shows no new failures.
- A new profile completes, and the Outlook tests on the Exchange Server tab of the Microsoft Remote Connectivity Analyzer pass from outside.
- The HttpProxy log shows successful requests for the user:
$log = Join-Path $env:ExchangeInstallPath "Logging\HttpProxy\Mapi"
Get-ChildItem $log | Sort-Object LastWriteTime | Select-Object -Last 1 | Select-String "jane" | Select-Object -Last 5Prevent it next time#
- Probe each protocol separately on the load balancer, and drain servers through maintenance mode before patching.
- After every update, confirm all components are Active and run the Health Checker; install updates elevated, as covered in installing Exchange security updates.
- Keep virtual directory URLs identical on every server and covered by the certificate.
- Record any per-mailbox protocol changes made during testing, and undo them afterwards.

