Thursday, May 8, 2014

How To: Exchange 2013 SP1 and MAPI over HTTP: #MSExchange #iammec

The list of features available with Exchange 2013 SP1 when combined with Outlook 2013 SP1 is certainly compelling. This specific combination, in particular, introduces a new client connection mechanism using Messaging Application Programming Interface (MAPI) over HTTP. Why the change in the client connection method? The reliability of the existing RPC over HTTP connection method between the Client Access server and Outlook client became problematic within certain network environments. The complexities of load balanced VIP’s along with connected Outlook clients changing networks (LAN to WLAN) proved to tax the performance of the legacy RPC Proxy found within IIS. Enter MAPI over HTTP! This connection method will allow Outlook to dump the aging RPC protocol in favor of an HTTP-based protocol. There are two clear benefits to using the MAPI over HTTP protocol. First, performance gains will be recognized because only TCP connections need to be reestablished after network hiccups not the full range of RPC connections. This allows Outlook clients to recover quickly and reconnect to the users mailbox when changing WLAN networks, connecting to a wireless hotspot (MiFi), or resuming a laptop from a hibernated state. Secondly, MAPI over HTTP allows Exchange to own the user session data and is not solely dependent on the current session (like RPC).

Autodiscover

To provide backwards compatibility, Exchange 2013 SP1 servers are able to respond to AutoDiscover requests for MAPI over HTTP or RPC over HTTP requests. The method by which MAPI over HTTP clients actually receive Exchange URL’s does not change. Outlook clients will have to inform Exchange though of the connection protocols they can support. Configured MAPI over HTTP clients will send Exchange an AutoDiscover request using a specific x-header (x-MapiHttpCapability). An Exchange 2013 SP1 server will then validate AutoDiscover requests that include an x-MapiHttpCapability header. This is to ensure that the header value is greater than zero and that the server itself supports the mapiHttp protocol. If this process works, and the x-MapiHttpCapability headers are valid, the server provides the MAPI over HTTP URL’s. If this process does not work for some reason then Exchange will present the RPC over HTTP URL’s. Backwards compatibility makes life easy!

Caveats

As with most new software features there are significant caveats and a supported configuration that must be met in order to utilize MAPI over HTTP.

First, your Client Access and Mailbox environment must be running Exchange 2013 SP1 with .NET Framework 4.5.1.

Secondly, your mail clients need to be running Outlook 2013 SP1.

Next, you need to ensure that the performance of your Client Access Servers is in line with the new sizing guidance from the product group. The CPU requirements for Client Access Servers configured to support MAPI over HTTP has increased by 50% over traditional RPC over HTTP sizing guidance.

Lastly, MAPI over HTTP clients’ can/will have connectivity issues to public folders that reside on legacy Exchange servers (2007/2010). MAPI over HTTP configured clients’ will need to access 2013 modern public folders. If you are not using legacy public folders this does not apply to you (lucky!).

How to Configure MAPI over HTTP

Let’s first verify what the standard Outlook 2013 SP1 connection status looks like. In the screenshot below you will see a standard RPC over HTTP connection. Notice the protocol column is showing RPC/HTTP. 



Next we need to take a look at what our InternalUrl is set to on our Client Access Servers.
Get-MapiVirtualDirectory | fl server,internalurl


Since the InternalUrl is set to a FQDN that is not on our certificate, we need to change the InternalUrl to https://mail.contoso.local/mapi.
Set-MapiVirtualDirectory -Identity "srv3\mapi (Default Web Site)" -InternalUrl https://mail.contoso.local/mapi -IISAuthenticationMethods Negotiate



Alternatively you can set the InternalUrl on all Exchange 2013 SP1 servers this way:
Get-MapiVirtualDirectory | Set-MapiVirtualDirectory -InternalUrl https://mail.contoso.local/mapi


Next, we need to enable MAPI over HTTP at the organization level. First lets verify that MAPI over HTTP is not enabled.
Get-OrganizationConfig | FL *mapi*








We see that MapiHttpEnabled is set to false within our organization. 

In order to enable MAPI over HTTP we issue the following command.
Set-OrganizationConfig -MapiHttpEnabled $true

After setting this parameter we can then verify the change.








Several minutes will go by and then any user connected with Outlook 2013 SP1 will receive a prompt that Outlook will need to be restarted. A fix to suppress this client-side alert is in the mix for an upcoming CU release this summer.

















After restarting Outlook 2013 SP1 you will see a standard MAPI over HTTP connection. Notice the protocol column is now showing HTTP. 



Additionally, the AutoDiscover log for this Outlook session generated by Test E-mail AutoConfiguration will display the new MAPI over HTTP Autodiscover provider listed.




Administration and Troubleshooting

It is noteworthy that Microsoft has provided several different methods to troubleshoot MAPI over HTTP.

First, a URL has been provided that displays basic connectivity diagnostics. The page displays the Client Access and Mailbox server that we have connected to, Exchange version, and vdir path. This page can be accessed using the following URL.

https://mail.contoso.local/mapi/emsmdb






Secondly, we have three different log locations that can be reviewed. The MAPI over HTTP logs can be found here:
%ExchangeInstallPath%Logging\MAPI Address Book Service\
%ExchangeInstallPath%Logging\MAPI Client Access\
%ExchangeInstallPath%Logging\HttpProxy\Mapi\

Lastly, we can use the Test-OutlookConnectivity cmdlet to verify that MAPI over HTTP is working on our server (SRV3) by way of the Microsoft Exchange Health Manager service. Make sure this service is started prior to running the Test-OutlookConnectivity cmdlet. 

Test-OutlookConnectivity -RunFromServerId srv3 -ProbeIdentity OutlookMapiHttpSelfTestProbe





Conclusion

The addition of an HTTP-based protocol for the myriads of mobile Outlook users will be a welcome change! The layers between the end user and the Exchange server has been simplified, thus providing the ability for users to switch from a work WLAN to their personal hotspot (and back again!) with minimal disruption to the Outlook session. Deploying MAPI over HTTP within a large enterprise will definitely be challenging given the significant caveats and supported configurations that must be met. I’m sure over time the enterprises' that have already invested in Exchange 2013 will address these caveats and reap the rewards of MAPI over HTTP. 

Simplicity is magical when it works!



No comments:

Post a Comment