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.

Symptoms

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.

Resolution

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:

mapiblock01

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

mapiblock02

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

With external information

mapiblock03

Without external information

mapiblock04

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.

Conclusion

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.

10 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.

    Like

  2. Hey Ingo,
    We are trying to achieve the same thing with our organization. we want to block external connectivity for the whole organization and let only user internally or on a VPN connect to outlook.
    should we try using Split-Dns. which you mentioned in the comments or just use the command BlockExternalactivity to achieve this. we don’t have any Mac devices on our Environment. so i was just curious.

    Like

    • Hi,
      if you don’t plan to have any integration with partners or M365, you could use the parameter. However, test this in your environment and also take your internal LoBs applications into consideration.
      For full flexibility, I would suggest to use only one namespace, which can be resolved only internal. This would keep things simple and you would have always the possibility to integrate something like Org Relationship or M365 hybrid.
      I hope this makes sense!?
      Ciao,
      Ingo

      Like

  3. Hey Ingo,
    We did some digging, kept the hostname as only one namespace as it was before. we achieved our goal by disabling the hostname on external DNS so that clients won’t be able to connect through internet. If we were on the network or on the VPN we were fine connecting to the exchange. However, when we removed the hostname on external DNS, the mobile clients were not able to access Exchange using the internet and were able to connect if on VPN. Although we didn’t change anything for Activesync, we had this problem. I just wanted to ask, if you have seen anything happen to Activesync clients when you hostname is only resolved internally?
    we also tried disabling Mapi on the LB but that did not serve the purpose as no Internal or External Outlook clients were able to access Exchange.

    Like

    • Hi,
      sorry for the late response!
      I think this is by design as you removed the DNS entry and therefore no client is able to resolve the name. Unless you would use for EAS a dedicated name. I’m wondering if you are using L7 load balancing?
      Ciao,
      Ingo

      Like

      • Hey
        Hope you are doing well!
        yes we have a L7 Loadbalancer, recently I tried something with the LB where i was able to place a match content rule with certain Flag involving a match string of IPs that were for our network. I applied these rules on MAPI Virtual services on L7 LB and was able to see the results. we were successful in trying to block external IPs.
        Thanks 🙂
        Manil

        Like

      • I was asking as depending on your setting you know where the request is coming from and if you have for each Exchange protocol a pool you could drop requests from external, based on the client IP addresses (as you know your internal IP ranges, right!).
        Ciao,
        Ingo

        Like

Leave a comment