This is one of those handy little tricks to keep in a toolbox to narrow down issues when troubleshooting. It can be useful to understand if the client is connecting via Outlook Anywhere or MAPI/HTTP. To troubleshoot such issues MAPI/HTTP can be disabled on the client, and then re-tested to see if the issue continues. Note that permanently disabling MAPI/HTTP is not an acceptable solution, and the below should be used for specific testing purposes. There have also been issues when re-enabling MAPI/HTTP where Outlook requires a new profile to connect.
MAPI/HTTP is enabled globally within the Exchange 2013 or 2016 organization by using Set-organizationConfig. For example:
Set-OrganizationConfig –MapiHttpEnabled $True
Note that enabling MAPI/HTTP is something that you must correctly plan and implement. There are client, server and reverse proxy considerations. When mailboxes are located in Office 365 you do not need to worry about the server side considerations, your focus is on the client side. For on-premises customers, Exchange 2013 SP1 and later support MAPI/HTTP.
At the time of writing MAPI/HTTP is supported on Outlook 2016, Outlook 2013 SP1, and also on Outlook 2010 SP2 with a post SP2 update. Note that SP2 is now required for Office 2010 support, and Office 2013 requires SP1 to be supported. Outlook 2010 also requires a post SP2 Outlook update to enable the MAPI/HTTP feature. It is strongly recommended that the latest updates are installed for Outlook. This is to resolve issues such as authentication prompts from MAPI/HTTP, being unable to connect to mailboxes or archive mailboxes and to suppress the message stating that an administrator has made a change and an Outlook restart is required. Do not overlook updating Outlook!
Test Lab Configuration
This test lab is an Exchange 2010 SP3 RU12 lab deployed in a hybrid configuration with Office 365. The Outlook client is Outlook 2010 SP2 with the August 11, 2015, update for Outlook 2010 (KB3055041) installed. This is Outlook 2010 build 14.0.7155.5000, and was the latest when this post was written.
Since the mailbox is located in Office 365, and MAPI/HTTP is enabled in the tenant for both Outlook 2010 and Outlook 2013 we can see below that the Outlook 2010 client is connecting using MAPI/HTTP. Note that the protocol is HTTP and the proxy Server column is empty.
To disable MAPI/HTTP for a single mailbox we can edit the local workstation’s registry to disable MAPI/HTTP and this will force the client to use classing Outlook Anywhere (RPC/HTTPS).
Controlling Via Registry
To disable MAPI/HTTP and force RPC/HTTP to be used, set the following registry key:
To enable, either remove the MapiDisabledHttp key or set the value to 0.
Checking Via Command Prompt
Using Reg.exe we can quickly check for the current value set:
REG.exe Query HKEY_CURRENT_USER\Software\Microsoft\Exchange /V MapiHttpDisabled
Disabling Via Command Prompt
To disable MAPI/HTTP using the command line:
REG.exe Add HKCU\Software\Microsoft\Exchange /V MapiHttpDisabled /T REG_DWORD /D 0x1 /F
(Note that the above is one line that may wrap)
Enabling Via Command Prompt
To allow MAPI/HTTP remove the MapiHttpDisabled DWORD, or set it to a value of 0 as shown below:
REG.exe Add HKCU\Software\Microsoft\Exchange /V MapiHttpDisabled /T REG_DWORD /D 0x0 /F
(Note that the above is one line that may wrap)
Working With PowerShell
We can retrieve the current configuration using the first two commands, whilst the third one disables MAPI/HTTP and the final command enables MAPI/HTTP:
Get-ItemProperty -Path HKCU:Software\Microsoft\Exchange -Name MapiHttpDisabled | select MapiHttpDisabled | Ft –AutoSize
New-ItemProperty -Path HKCU:Software\Microsoft\Exchange -Name MapiHttpDisabled -PropertyType DWORD -Value "0x1" –Force
New-ItemProperty -Path HKCU:Software\Microsoft\Exchange -Name MapiHttpDisabled -PropertyType DWORD -Value "0x0" –Force
(Note that the above are all one line that may wrap)
Testing When MAPI/HTTP Disabled
For reference, Outlook 2010 connection information is show. Note that MAPI/HTTP is being used:
After disabling MAPI/HTTP using one of the above methods, reg.exe or PowerShell, we can then look to see how Outlook is connecting. Note that you may have to wait for Outlook to perform an Autodiscover request and automatically update itself, or alternatively run a profile repair to force a full Autodiscover. Deleting the Outlook profile would also force the change, but that is not recommend in production unless it is the last resort. Deleting Outlook profiles causes OAB downloads, OST downloads, possibly adding PST files back into the profile and may also impact mobile devices.
In the below screenshot we can se that the client is now kicking it old skool. The protocol type has changed, and there is now a proxy server specified. This was taken after restarting Outlook.
Crossing The Streams
It’s worth mentioning that having both RPC/HTPS and MAPI/HTTP active at the same time is supported and maybe expected depending upon the environment. For example in this example organization, the mailbox could be located on-premises with the online archive mailbox in Office 365. When looking at the Outlook connection status you could see something like the below: