Why using MAPIBlockOutlookExternalConnectivity is a bad idea

A while ago we had a special request: For a dedicated AD site, only a subset of users should be able to access their mailbox with Outlook for Windows from outside the corporate network. My first thoughts were this is not possible. I wasn’t aware of any setting to limit Outlook Anywhere or MapiHttp external access on user base.

But we were told by a PFE that there is a way:

Combining MAPI over HTTP configurations and internal or external connections

There is always something new, you can learn!

We did some testing and the results were very promising. So we were able to fulfill the request.

But the description of Set-CASMailbox for the parameter MAPIBlockOutlookExternalConnectivity and the article doesn’t reflect all consequences and soon we received a lot of complains, reports about connectivity issues with devices and applications other than Outlook for Windows.


A few users are using a Mac and therefore Outlook for Mac, which uses Exchange Web Services to access a mailbox. These users were no longer able to access their mailbox, once they were not connected to the corporate network. Others reported issues with their Skype for Business Client and the calendar integration.


On the first look, it was not really clear what happened as also users were affected, which had the property MAPIBlockOutlookExternalConnectivity not set to True. But we resolved all issues by reverting for all mailboxes this value to its default:False.

Behind the curtain: How it really works

After all users got back to normal, I started investigation about this feature. I wanted to know how it really works and soon I’ve found it.

When the value is set to True, Exchange strips off all information, which are necessary for external connectivity. Thus means as the client doesn’t have any information about the external endpoints, no connection is possible.

Here is an example for a mailbox. I used the script Get-AutoD.ps1 to retrieve the Autodiscover response:


As you can see there is a huge difference. All the external information are missing.


To be on the safe side, I captured the response with Fiddler.

With external information


Without external information


The description of the parameter is very misleading and in the end incomplete

The MAPIBlockOutlookExternalConnectivity parameter enables or disables external access to the mailbox in Outlook by using Outlook Anywhere or MAPI over HTTP. Valid values are:

  • $true   External Outlook clients can’t use Outlook Anywhere or MAPI over HTTP to access the mailbox.
  • $false   External Outlook clients can use Outlook Anywhere or MAPI over HTTP to access the mailbox.

In fact this affects not only Outlook for Windows using Outlook Anywhere or MAPI over HTTP. When you set on a mailbox this value to True, the following services and features are also affected:

  • Outlook for Mac (external connectivity)
  • Skype for Business (e.g.: Calendar integration)
  • cross-premises F/B look-up (this includes Hybrid Configuration)

Note: Not only this mailbox is affected. When someone, which has not set the value to True, is outside the corporate network and wants to look-up F/B, it will fail due to the missing external information in the Autodiscover response.


Besides the fact that the description is incomplete and the naming of this parameter is very misleading, you have to be very careful with.

I recommend to look into different options to limit external access on user and protocol level. ADFS and Conditional Access (in addition with Application Proxy) might be one solution. But this needs additional infrastructure and licenses.

I’m looking forward to claims-based authentication for MAPI virtual directory as it already exist for OWA and EAC.

3 thoughts on “Why using MAPIBlockOutlookExternalConnectivity is a bad idea

  1. Interesting article, as I am looking to block Outlook access externally. I was wondering how you managed to have an internal .local domain and an external domain for your services? As i understand you can only assign an SSL certificate per service.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s