Configuration is as follows:

  1. Domain hosting.contoso.com hosts an on-premises Exchange 2013 organization, that hosts several second level domains, including the contoso.com domain. The domain is in a separate forest, and has a forest trust with domain office.contoso.com, which is also a root domain of a separate forest.
  2. There is a VPN connection established between office.contoso.com and hosting.contoso.com, and all Exchange servers are available to both sides via internal IP ranges.
  3. Users in domain office.contoso.com have an UPN suffix of contoso.com, and connect to Exchange organization via MAPI over HTTPS resolved to external IP ranges of Exchange servers on hosting.contoso.com domain.
  4. The contoso.com name server is a standalone DNS server exposed as NS1.contoso.com to the Internet, and hosts all required MX, A, TXT and SRV records for contoso.com Exchange organization necessary to locate it from outside. OWA is also published and working.
  5. The office.contoso.com domain has recently been integrated with AD FS to Microsoft Office 365 tenant organization, which happens to have an Exchange organization of their own, however none of the DNS records of contoso.com are pointing to microsoft.com, office.com, outlook.com or elsewhere from Microsoft. All configuration is complete, neither side reports problems with AD integration.

A user from office.contoso.com has sent a message with Outlook 2016 from within internal network of office.contoso.com domain to a third party, with a CC address of one of public folder mailboxes in on-premises Exchange organization, and didn't get the message in that public folder. Investigation eventually discovered that the e-mail got sent via Office 365's Exchange organization which does not have the public folder's e-mail address registered, therefore an NDR was generated and placed into a cloud-based Exchange mailbox associated with this user. The third party had received the message properly, despite the SPF record of contoso.com domain that should have prevented Microsoft's servers to successfully send that email, as their external IP addresses do not reversely resolve to any of the contoso.com DNS names. (Third party mail server configuration is out of scope of this question)

The question is:

  1. HOW can Outlook discover that there is another Exchange organization set up to both connect and send e-mails for domain office.contoso.com?
  2. WHY did it actually decide to connect elsewhere but the primary Exchange account already configured to use the address from @contoso.com?
  3. WHY did Outlook NOT show the contents of the wrong mailbox after such a failover, and WHY did Outlook post the "Sent" message to the right mailbox, while sending it via wrong mailbox?
  4. HOW COME Office 365's Outlook installed on a PC in an external network connects to Office 365's organization despite valid autodiscover address existing in contoso.com domain? If a standalone installation of same Office version that's not using Office 365 for activation is used, autodiscovery process completes in a snap, with it getting connected with RPC/MAPI over HTTPS to the on-premises Exchange CAS server.
  5. What should the systems administrator of office.contoso.com domain perform to BOTH allow Office 365's Exchange organization to exist, and completely eliminate any chance of users' Outlooks to ever connect to it unless directly specified?

I have managed to find the answer for this question. The link to the fully explained answer is here: How Outlook (2016) performs autodiscovery. Excerpt is as follows:

Step 4: Check for O365 as Priority

Outlook uses a set of heuristics to determine whether the user account provided comes from Office 365. If Outlook determines confidently that you are an O365 user, a try is made to retrieve the Autodiscover payload from the known O365 endpoints (typically https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml or https://autodiscover-s.partner.outlook.cn/autodiscover/autodiscover.xml). If this step does not retrieve a payload, Outlook moves to step 5.

The policy control value for this step is as follows: ExcludeExplicitO365Endpoint.

As this guide explains, Outlook 2016 uses "heuristics" to determine whether to check Office 365 for Exchange organization being provisioned. More, this step 4 is done way before any other step configurable in Active Directory or Autodiscover sites. Therefore, the answer is simple: Add either a registry preference, or a proper policy with Office 2016 ADM templates installed. The registry key is HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\16.0\Outlook\AutoDiscover\ExcludeExplicitO365Endpoint, type REG_DWORD, value 1. Simple as heck when it comes to making Outlook 2016 not try going into the cloud.

The remaining question is #3, "why does Outlook not display proper contents of connected mailbox", but it's answered with Outlook normally working in cached mode, so it displays local cache and occasional changes downloaded with pull requests from Exchange. In this case the contents of on-premises Exchange mailbox was downloaded locally prior to Outlook doing his probability dance and connecting to the cloud, so it just displayed them along with the message just sent through the cloud, providing the described effect.

And finally, the standalone version happened to be Outlook 2013, which does not yet use such heuristics by design, therefore worked as expected.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.