When you first install Exchange 2016, MAPI over HTTP isn’t enabled and you’ll see a warning like the one below. In this post, we’ll look at what MAPI over HTTP is, the benefits and impact then how to configure it.
MAPI over HTTP, the preferred Outlook desktop client connectivity with Exchange server, is currently not enabled. Consider enabling it using: Set-OrganizationConfig -MapiHttpEnabled $true
What is MAPI over HTTP?
In Exchange 2010, internal clients connected using RPC and external clients connected using RPC over HTTP (Outlook Anywhere). Exchange 2013 no longer supports RPC and all clients (internal and external) need to connect using RPC over HTTP.
MAPI over HTTP was released with Exchange 2013 SP1 and is the preferred connectivity method for Outlook for Exchange 2013 SP1 and later.
How can I work out if MAPI over HTTP is already enabled?
In Outlook, you can see how you are connected. To do this, hold down CTRL and right click on the Outlook icon on the system tray then click on Connection Status. You should see a window like the one below.
Above, we can see that we’re connected to Exchange using RPC/HTTP.
You can also check using Exchange by running the command below:
Get-OrganizationConfig | fl *mapi*
As you can see above, MAPI over HTTP is not enabled.
What are the benefits of MAPI over HTTP?
- More visibility of transport errors
- Enhanced recoverability
- Faster reconnection times after resuming from hibernation or switching networks
What is the impact of MAPI over HTTP?
When you enable MAPI over HTTP, any Outlook clients that are running will prompt for a restart of Outlook. RPC over HTTP remains active so if for some reason the clients cannot connect using MAPI over HTTP, they can still connect using RPC over HTTP. This is the case for earlier versions of Outlook that don’t support MAPI over HTTP. See the MAPI over HTTP requirements below.
If you’re still using public folders on Exchange 2010 or 2007 then you shouldn’t enable MAPI over HTTP until the public folders have been moved to Exchange 2013 as there may be problems where Outlook clients connecting using MAPI over HTTP are unable to connect to the public folders.
What are the requirements for MAPI over HTTP?
MAPI over HTTP requires both your CAS servers running Exchange 2013 SP1 or later and either Outlook 2013 SP1 or Outlook 2010 SP2 with KB2956191 and KB2965295.
Upgrading the MBX servers is also recommended to remove the Outlook client restart requirement after a database failover.
There are reports of poor performance with Outlook 2013 and MAPI over HTTP but this has been fixed in this hotfix.
How do you enable MAPI over HTTP?
To enable MAPI over HTTP, go through the steps below:
1) Upgrade all clients to Outlook 2013 SP1 or Outlook 2010 SP2 with KB2956191 and KB2965295
2) Upgrade all CAS and MBX servers to Exchange 2013 SP1 or later
3) Ensure Microsoft .NET Framework 4.5.2 is installed on the Exchange 2013 servers.
This is part of the pre-requisites for Exchange 2013 and Exchange 2016. If you have installed a previous version then install .Net 4.5.2 from here. Accept the license terms and click install:
4) Add the COMPLUS_DisableRetStructPinning windows environment variable
Open the command prompt and run systempropertiesadvanced
Click on environment variables:
Click New to add a new system variable and enter the below details:
Click OK. You should now see your new entry:
Click OK twice to close the windows and save your changes.
5) Configure SSL certificates
In this example, I have an Exchange server called LITEX01 running Exchange 2013 CU10 and another server called LITEX02 running Exchange 2016 RTM am using the FQDN mail.litwareinc.com for Outlook Anywhere.
I already have mail.litwareinc.com as a name on the certificate I’m using for the IIS service on both servers. You can continue to use the same name as you use for Outlook Anywhere or you can use a different name. If you use a different name then you need to make sure that this is included on your SSL certificate. If you find that you need to add a new name to your certificate see here on instructions to generate a new certificate.
6) Configure MAPI virtual directory
MAPI over HTTP requires configuration. You can configure it as you configure other virtual directories such as the OAB virtual directory. Run the commands below to configure the MAPI virtual directory for each server:
Get-MapiVirtualDirectory -Server litex01 | Set-MapiVirtualDirectory -InternalUrl https://mail.litwareinc.com/mapi -ExternalUrl https://mail.litwareinc.com/mapi
Get-MapiVirtualDirectory -Server litex02 | Set-MapiVirtualDirectory -InternalUrl https://mail.litwareinc.com/mapi -ExternalUrl https://mail.litwareinc.com/mapi
7) Recycle the MSExchangeAutodiscoverAppPool
Exchange will eventually start pushing out the new MAPI virtual directory settings to clients but if you want to force Exchange to do this immediately then recycle the MSExchangeAutodiscoverAppPool from IIS Manager by highlighting the app pool and then clicking on recycle on the right.
8) Update your load balancer and reverse proxy rules
If you’re using a load balancer or reverse proxy then you may need to configure it to accept the new protocol.
9) Enable MAPI over HTTP in your Exchange Organization
To do this, run the below command:
Set-OrganizationConfig -MapiHttpEnabled $true
9) Test Outlook AutoConfiguration
To do this, hold CTRL and right click on the Outlook icon in the system tray then click on Test E-mail AutoConfiguration. Untick all options except for Use Autodiscover then enter your email address and password then click on Test. You should see a window like below:
As you can see above, there is a new MAPI HTTP section in the Autodiscover response
10) Confirm Outlook is now using MAPI over HTTP
To do this, hold CTRL then right click on the Outlook icon on the system tray and click on Connection Status.
As above, you can see that Outlook is connecting using HTTP instead of RPC/HTTP and that it is using the new MAPI virtual directory (https://mail.litwareinc.com/mapi).
11) Test Outlook Connectivity
To do this, run the below commands to check MAPI over HTTP is working on your Exchange servers. In our case we will check both our Exchange 2013 server, Litex01 and our Exchange 2016 server, Litex02:
Test-OutlookConnectivity -RunFromServerId litex01 -ProbeIdentity OutlookMapiHttpSelfTestProbe
Test-OutlookConnectivity -RunFromServerId litex02 -ProbeIdentity OutlookMapiHttpSelfTestProbe
As you can see below, our tests have come back successful:
MAPI over HTTP is now enabled and configured correctly.