Outlook profile doesn't resolve via Autodiscover for user mailbox moved to Office 365

  • Article

 

As you can imagine there are many reasons which could prevent Microsoft Outlook connecting to Office 365, most commonly because the Outlook software version is not patched to the minimum required level, or firewall / proxy issues. However in this article, I specifically wanted to cover scenarios that comes up which are related to the autodiscover service, and how this may prevent Outlook connecting to Office 365 (Exchange Online) mailbox, or even resolving correctly in updating or creating an Outlook profile.

The scenarios I describe below cover what should happen when the autodiscover DNS record(s) point to on-premises Exchange, but the users mailbox is in Office 365 (Exchange Online). Then, I cover three scenarios which I have seen which break this model.

What should happen

Microsoft Outlook connects to the local Exchange autodiscover service, which in turn redirects Outlook to Office 365, because the mailbox has been moved there. This is because the user object in on-premises Exchange is a remote-mailbox with a forwarding address to Office 365. Fiddler is a very handy tool (or even the test email connectivity dialog built into Outlook), to understand what is going on, and therefore determine where Outlook might be having an issue connecting. In most environments, you should see Outlook connect to CAS server on-premises, and then connect to the following addresses (because it is redirected), in the order shown below:

 

  1. Internal requests to CAS Servers using SCP (AD method for determining autodiscover location), and requests to external autodiscover address e.g. autodiscover.contoso.com/autodiscover/autodiscover.xml (note, there will be a few similar requests to the autodiscover web address as it tries various formats). One of these should succeed, and it will then tell Outlook to redirect the request for autodiscover to the internal O365 email address for the user i.e. alias@tenantname.mail.onmicrosoft.com. This should result in the following web addresses successfully being access by Outlook.
  2. https://autodiscover.tenantname.mail.onmicrosoft.com/autodiscover/autodiscover.xml (note HTTP, not HTTPS)
  3. https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml
  4. At this point, Outlook should now know where the mailbox CAS services is and connect to it (hopefully now using MAPI over HTTP)

If you see different behavior to the above, then that can help you troubleshoot issue. Also, a simple test would be, can the user, via their web browser, access these autodiscover end points? Perhaps their proxy server is preventing access to one of them e.g. *.outlook.com. There are 3 common scenarios that you might come across worth covering.

Scenario 1

Companies block access to consumer email services, and in this case outlook.com. A URL in outlook.com is used to return autodiscover information (autodiscover-s.outlook.com), so a users PC needs access to this end point.

Scenario 2

Outlook correctly connects to the autodiscover end points in Office 365, and does connect to the final endpoint which is https://autodiscover-s.outlook.com/autodiscover/autodiscover.xml, but yet it still doesn’t setup the Outlook profile. This can happen when an Outlook client is getting many responses from internal CAS servers through SCP lookup, all correct responses i.e. redirecting Outlook to the forwarding email address, but because there are so many responses coming back from internal CAS, Outlook stops attempting to discover. This is a design feature of Outlook (and in theory all autodiscover clients), they should stop attempting to autodiscover after 10 responses from autodiscover services. This is designed to prevent infinite loops. This behavior can be seen when a PC is a member of an AD site, which doesn’t have a CAS server associated to it, and so many (in some cases all) internal CAS servers respond, and if you have more than 10 CAS servers, you can see this behavior. To test if this is something that is occurring in your environment, use the steps in the following KB article (https://support.microsoft.com/kb/2212902), to disable SCP i.e. just add ExcludeScpLookup as Dword and set to 1. This will force Outlook to only use the DNS record for autodiscover. Disabling SCP is not the ultimate solution, but perhaps configuring AD to have a CAS for the site is a better e.g. a set of CAS servers which should primarily respond to autodiscover request for PCs in that site. Here is the autodiscover design article which talks about the max 10 responses, and here is an article which talks about configuring a site to use specific CAS, using autodiscoversitescope feature.

Scenario 3

You haven't deployed a hybrid solution, and have created mailboxes in Office 365 with a different SMTP domain name to on-premises Exchange. So you don’t have autodiscover redirection setup in on-premises Exchange for mailbox in Office 365, but have created a DNS record to point autodisover.domainname.com to Exchange Online. In this case, on-premises AD SCP will mess you around even if the SMTP domain name between your existing on-premises Exchange mailboxes are different to Office 365 SMTP address. When the PC is on your network, it will still try and resolve the end point using SCP. As a test on the user’s PC, you want to disable SCP lookup and force the user’s PC to only use the DNS record for autodisover.domainname.com. As described in step above.

 

Please note: this information was accurate at the time of writing this article (30 April 2015). Service endpoints, such as autodiscover addresses in Office 365, may change over time, which would make some of the information in this article redundant. Keep in mind, Fiddler is a great friend.

Hope this information helps,

Michael