Kicking the Tires

Exchange 2013 initially supported Remote Procedure Call (RPC) over HTTP for Outlook Anywhere as the only access protocol. Although it offered many benefits, it also put obstacles in the way of many a migration. This article introduces the new protocol, Messaging Application Programming Interface (MAPI) over HTTP and looks to facilitate the transition.

RPC over HTTP has established itself over the years as a transport protocol standard for accessing Outlook and enjoyed a good reputation, in terms of stability. However, the protocol was not intended for constant network changes, and deficits began to show, especially through the spread of Office 365. To better meet current requirements and to enable a faster connection between the client and server, a new protocol with a simpler architecture was introduced in 2014.

Background

The user experience is greatly enhanced with the MAPI over HTTP protocol. For example, the majority of clients establishes a connection within approximately 30 seconds after first launching Outlook, instead of taking 90 seconds as with Outlook Anywhere. Also, on re-establishing the connection after sleeping or changing the network, Outlook connects to the server faster than before. It supports the continuation of an interrupted connection, meaning that short interruptions no longer lead to a reconnect. The client continues the communication at the point before it broke down, if it is no longer than 15 minutes [1].

MAPI over HTTP offers several advantages not only for users, but also for administrators. The access log is no longer double wrapped. Therefore, the Internet Information Services (IIS) and HTTP proxy protocols offer far more information, much like Outlook Web Access, thus making it worthwhile to take a look at the logfiles of the various protocols. The authentication configuration has also been simplified. With MAPI over HTTP, the client automatically receives authentication settings from the server during the process of establishing a connection, meaning that they are no longer specified by AutoDiscover.

The negative effect of MAPI over HTTP should also be noted at this point: The volume of traffic increases by 5 to 10 percent. Also, the CPU load nearly doubles on the Client Access server compared with Exchange 2013 Release to Manufacturing (RTM), and they are still below the requirements of Exchange 2010. Microsoft is working to reduce the requirements in the future. The adjustments were incorporated into the Exchange Server Role Requirements Calculator, and you will want to double-check your environment before enabling.

Access to public folders is easy with Outlook if the folder resides on an Exchange 2013 or Exchange 2016 server. If you work with Exchange 2013, and if you still have Exchange 2007/2010 server public folders in your organization, access issues can occur for clients under MAPI over HTTP. Note Exchange 2013 Cumulative Update 7 (CU7) and the detailed article on the Exchange Team Blog [2].

How MAPI over HTTP Works

In Exchange 2010, Outlook communicated directly with the server using RPC, which includes the MAPI commands. Using RPC over HTTP, the requests were alternatively encapsulated in HTTP packets; this was initially the only access option with Exchange 2013 RTM. This meant that the client first had to packetize the RPC requests, and the server had to unpack them again. MAPI over HTTP gets rid of the RPC layer and sends MAPI statements directly to the server via HTTP, so that RPC communication is no longer needed. The complexity of Outlook Anywhere, which was created by the dependence on RPC technology, is thus also eliminated (Figure 1).

In the context of an AutoDiscover request, Outlook sends the new X-MapiHTTPCapability attribute with a value of 1. This flag signals to the server that the client supports MAPI over HTTP, and if the client is indeed using MAPI over HTTP, the server sends the client details of how to reach the mailbox using the protocol.

For a new type of connection that Outlook still does not use, Outlook will prompt you to reboot with a message like, "The Microsoft Exchange administrator made a change that requires a restart of Outlook." Until then, Outlook continues to use Outlook Anywhere. If all Outlook updates are installed, the client will not explicitly prompt for a reboot but will automatically use the new protocol after a reboot.

You can see the AutoDiscover results in Outlook via Test E-mail AutoConfiguration. Right-click the Outlook icon in the info area of the taskbar while holding down the Ctrl key. You will now find a Test E-mail AutoConfiguration item. Start the AutoDiscover test and check the feedback on the MAPI over HTTP protocol (Figure 2). The feedback on the new protocol is limited to a few lines, which is clear evidence of simplification. If Outlook via MAPI over HTTP fails to establish a connection, the client automatically falls back to RPC over HTTP.

Prerequisites for MAPI over HTTP

On the server side, you must have at least Service Pack 1 for Exchange 2013 installed or use Exchange 2016. Almost all current Outlook clients can be used as clients, including:

• Outlook 2016
• Outlook 2013 Service Pack (SP)1
• Outlook 2010 SP2 Updates KB2956191 and KB2965295

Outlook 2007 or older clients cannot use MAPI over HTTP, and it was disabled by default in Exchange 2013. If you are using Exchange 2013, note that you can enable the access log for the entire organization and that targeted activation for a range of users is only possible as of Exchange 2016, where you can select the protocol, such as IMAP or Outlook Web Access (OWA), in the user's mailbox features (Figure 3). For an overview of the status of MAPI over HTTP for the users in your organization, try this PowerShell query:

> Get-CASMailbox | ft Name, MapiEnabled -AutoSize

By default, the log is active; you can disable it in PowerShell with the command:

> Set-CasMailbox User -MAPIEnabled $False

You can enable MAPI over HTTP accordingly with

Set-CasMailbox User -MAPIEnabled $True

In addition to server-based management, you always have the option of managing the use of MAPI over HTTP in the client regardless of the servers that are used with the DWORD registry value MapiHttpDisabled, which you need to set below key HKEY_CURRENT_USER\Software\Microsoft\Exchange.

The value affects whether the MAPI over HTTP flag is sent during the AutoDiscover request. If the value is set to 0, MAPI over HTTP is used, whereas for a value of 1, it is not used. The client thus does not receive any settings for the protocol, and RPC over HTTP is used automatically.

Performance with Exchange 2013 SP1

In the case of Exchange 2013 SP1, the use of MAPI over HTTP can cause performance problems on the client. If this is the case in your environment, the SP1 release notes [3] describe in detail how to handle the problem.

Provisioning

With Exchange 2013, first make sure that all Exchange servers have SP1 and .NET Framework 4.5.2 in place. In the next step, update the system variables on the Client Access servers as described here. Open the systempropertiesadvanced system property and set the variable COMPLUS_DisableRetStructPinning to a value of 1.

A new virtual directory for MAPI is created automatically during the installation of Exchange 2016 or of Exchange 2013 SP1. You can check the directory with:

Get-MapiVirtualDirectory -servername

Next you define the internal and external URLs with PowerShell. The procedure is identical for Exchange 2013 and Exchange 2016:

> Set-MapiVirtualDirectory -Identity "mapi (Default Web Site)" -InternalUrl https://contoso.com/mapi -ExternalUrl https://contoso.com/mapi -IISAuthenticationMethods Negotiate

The specified URLs must be stored in the certificate for the IIS log, and the client must trust the certificate. (See Table 1 for other PowerShell configuration commands.) The fastest way to check this is by accessing the OWA website. If necessary, proceed to modify the load balancers or firewall rules, so the clients can access the virtual directory for MAPI over HTTP. Finally, enable MAPI over HTTP with PowerShell:

> Set-OrganizationConfig -MapiHttpEnabled $true

Check that this worked as follows:

> Get-OrganizationConfig | fl Name, MapiHttpEnabled

After restarting Outlook, the connection uses MAPI over HTTP.

Functional Test

You can test the MAPI over HTTP connection on the server with the -OutlookConnectivity test command. You need to use the OutlookMapiHttpSelfTestProbe module here:

> Test-OutlookConnectivity -RunFromServerId Server -ProbeIdentity OutlookMapiHttpSelfTestProbe

If you see a success message, everything is set up correctly and the Microsoft Exchange Integrity Service (MSExchangeHM) is running.

On the client, you can see the connection type in the Outlook connection status. To display it, Ctrl+right-click the Outlook icon in the notification area. If the MAPI over HTTP connection is active, you will see HTTP instead of RPC/HTTP displayed in the log. Additionally, the Proxy Server column will be blank and you will see the current server instead of the GUID for Outlook Anywhere (Figure 4) as the server. Furthermore, you will find new logs for MAPI over HTTP activities in the following directories:

• %ExchangeInstallaPath%Logging\MAPI AddressBook Service\
• %ExchangeInstallPath%Logging\MAPI Client Access\
• %ExchangeInstallPath%Logging\HttpProxy\Mapi\

Conclusions

MAPI over HTTP is a fast access protocol that has rapidly established itself as a new standard by Office 365. The change occurred transparently without affecting end users. You can benefit especially from the improved user experience in the case of frequent network changes, and Microsoft has integrated mechanisms for multifactor authentication so that the protocol will offer even more benefits in the future.