Checklist
Outlook can't connect (MAPI/HTTP) checklist
Based on the article: "The connection to Microsoft Exchange is unavailable": fixing Outlook on Exchange Server · 4 min read
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.
Symptoms to confirm
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.
Likely causes
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.
| 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 |
Checklist
- 1
Rule out the mailbox's protocol settings
powershellGet-CASMailbox jane@contoso.com | Format-List *Mapi* Get-OrganizationConfig | Format-List MapiHttpEnabled Set-CASMailbox jane@contoso.com -MAPIEnabled $trueMAPIEnabledmust beTrue; when it'sFalse, Outlook shows exactly the errors above. The mailbox-levelMapiHttpEnabledis normally empty, which means it follows the organization setting. - 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.comon your namespace. - 3
Check the MAPI virtual directory on every server
powershellGet-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
ExternalUrlis empty, clients outside the network aren't offered MAPI over HTTP. - 4
Check components, health and app pools
powershellGet-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, StateForwardSyncDaemonandProvisioningRpsare normally Inactive on-premises. Anything else Inactive, such asServerWideOffline, usually means a server was left in maintenance mode after patching:powershellSet-ServerComponentState EX01 -Component ServerWideOffline -State Active -Requester Maintenance - 5
Test healthcheck.htm and fix the load balancer
powershellInvoke-WebRequest https://mail.contoso.com/mapi/healthcheck.htm -UseBasicParsing | Select-Object StatusCode, ContentA healthy server answers
200with200 OKand 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. - 6
Check the client
A
MapiHttpDisabledDWORD set to1underHKCU\Software\Microsoft\Exchangestops 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
- 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.