Outlook Autodiscover Weirdness

Office 365 Autodiscover to… Gmail??

I ran into an issue recently while performing a G Suite to Office 365 migration where my Outlook 2016 clients would begin to Autodiscover as normal, but rather than redirecting to Office 365 as I expected, they would actually present me with a Gmail IMAP login prompt.

The oddest part about it is that Autodiscover was configured correctly – even doing an Autodiscover test on https://exrca.com would work correctly with no issues. And yet, when I was configuring Outlook 2016, I kept getting the following popup:


At first, I thought that maybe it was just an additional popup, and tried to authenticate as normal, but with no success:


This behavior can also happen with the Outlook mobile app, as reported on the forums. It was actually this forum that gave me an idea on how to start troubleshooting the issue to see if it was affecting me as well.

Sure enough, once I started a network trace through Fiddler I noticed that there was an autodetect step taking place before I would even get to the Autodiscover lookup, and this was going to prod-global-autodetect.acompli.net. You can see from my screenshot below that I haven’t even entered the password for my account yet, and it’s already done its lookup and is waiting for me to continue:


Inspecting this traffic, I saw that it was actually giving me my Gmail account information back long before it got to the Autodiscover portion of the lookup – in essence, my Autodiscover records didn’t have a chance to resolve correctly before my account was being pushed to a Gmail login:


This “feature” is part of the Simplified Account Creation in Outlook 2016 (and newer), and this lookup occurs before the normal Autodiscover lookup. Essentially, Microsoft took a page from their Outlook mobile app and has started using the Rest API to call the Acompli.net service, which in turn has cached information based on your domain’s DNS records, MX records, etc. The good news is that this behavior is expected, and not something wrong with your network or GPO/proxy settings like I had originally thought. The bad news, however, is that if you’ve got the wrong information in your Acompli cache, you’re going to get stuck like I was – and you don’t have a way of updating this cache on your own.

Using a Rest lookup to query the Acompli cache

In order to test this out, you can use the Advanced Rest Client – I just ended up using the ARC plug-in for Chrome, which worked really well and got me the results I was looking for. Once you’ve installed the Rest client or plugin, use the following settings:

Method: Get
Request URL: https://prod15-files.acompli.net/autodetect/detect?services=office365,outlook,yahoo,google,icloud&protocols=eas,imap,smtp,rest-cloud
Accept-Language: en_US
X-Email: user@yourdomain.com

I found I was able to get the results I needed without specifying the User Agent and host information below, but I include it as it was recommended on the forum post explaining how to check. If you’re not getting the results you’re expecting with just the default settings, then try adding the agent info to see if your mobile experience is different.

User-Agent: Outlook-Android/2.2.17.224.prod Dalvik/2.1.0 (Linux; U; Android 6.0.1; D5803 Build/23.5.A.1.291)
Host: prod15-files.acompli.net
Connection: Keep-Alive
Accept-Encoding: gzip


** Edit – November 29th ** Mike Crowley gives an awesome explanation on what’s happening with this problem on the forums, as well as a way of performing the REST lookup through PowerShell. I’m updating it here since a) I’m a big fan of Mike Crowley, and b) I love PowerShell!

To perform this same lookup through PowerShell, use the following code block:

$headers = @{
"Accept-Encoding" = 'gzip'
"User-Agent" = 'Outlook-Android'
"X-Email" = 'username@domain.com'
}
$Response = Invoke-WebRequest "https://prod15-files.acompli.net/autodetect/detect?services=office365,outlook,yahoo,google,icloud&protocols=eas,imap,smtp,rest-cloud" -Headers $headers
$Response.Content | ConvertFrom-Json | select -ExpandProperty protocols

Here’s what my account looked like through the inspector:


You can see right away that the information I have in the Acompli cache is going to push me over to Gmail, again even before Autodiscover has a chance to run. For comparison, here’s the same information, using my own Office 365 account instead:


Fixing the problem

There are essentially two ways that you can resolve this problem, or you can simply wait it out – eventually, your acompli cache will update once you’ve moved your MX records over to Office 365. However, if you can’t wait (in the middle of a migration, much?), or if you know it’s going to be a while before you’re able to move your MX records over to Office 365, then there’s another path you can take.

Option 1 is actually fixing the problem, and Option 2 is a workaround. You might need the workaround until your migration completes though, or until you’re actually able to use Option 1 to fix the problem.

Option 1: Request the cache to be cleared

If you’ve moved your MX records over already, and you’re still getting the wrong cache data, you can request to clear data from prod-nam-autodetect.acompli.net service – I’m not sure whether or not Microsoft is still taking requests from that forum thread, but you can also open a ticket with Microsoft to request the same thing.

Option 2: Disable Outlook 2016 Simplified Account Creation

Disabling Simplified Account Creation will essentially force Outlook 2016 / Pro Plus / 2019 to bypass the REST lookup, and instead, walk through the normal Autodiscover process. Microsoft gives you the information on how to disable this feature, but only as a preference, not as a troubleshooting step.

With all this in mind, here are the steps to follow:

In the registry, navigate to HKEY_CURRENT_USERSOFTWAREPoliciesMicrosoftOffice16.0Outlooksetup and create a new DWORD key named DisableOffice365SimplifiedAccountCreation.


Set the Value to 1 (true), and save your changes.


Go ahead and re-open Outlook, and attempt to create an email profile – you’ll notice immediately that your account creation experience is back to the old style, which, while it still won’t let you enter your server settings, will at least do a proper Autodiscover lookup, and not go through acompli.net. Of course, once your cache has been cleared, and your domain’s MX records are pointing correctly to Office 365, you can re-enable the Simplified Account Creation and let Outlook use the new way of doing lookups – it’s really only if you’re in the middle of things that you’ll want to disable this (or if your users are complaining over the new interface – but that’s more than likely not what’s happening!)

All fixed!



This was definitely an odd problem – hope you found it helpful!

12 thoughts on “Outlook Autodiscover Weirdness

    1. Clever solution… forcing the acompli.net lookups to fail like that is a good idea, plus you can manage it centrally and just delete the empty zone when your acompli cache is updated. I like it!

      Like

  1. Hey Jeremy, thank you for your detailed article. I stumbled upon it while searching for the reason Autodiscover does not work with my Outlook 365. My domain does not use Office 356, Active Directory or G Suite, yet the “Simplified Account Creation” Setup does not find my settings (https://domain.tld/autodiscover/autodiscover.xml). It does work with the “classic” Account Setup Assistant. The URL prod15-files(dot) acompli(dot)net/autodetect… does not seem to work anymore. Do you have another idea how to troubleshoot and solve this?

    Like

    1. Hey Ryan,
      I’m missing a few pieces here – are you using Office 365 for licensing, but you’re not using it for your domain? Where is your email hosted if it’s not Office 365 or Active Directory / Exchange?

      Looking at the documentation for Simplified Account Creation, it states that:
      “The Simplified Account Creation feature was first introduced in Click-to-Run installations of Outlook, starting with version 16.0.6769.2015. You must be signed in to an Office 365 account to activate this feature.”

      If you’re not using Office 365 at all, the simplified account creation (SAC – they need to come up with better acronyms!) wouldn’t be working for you either.

      Where is your email hosted, and does your autodiscover work correctly on exrca.com?

      Like

      1. Thank you for your reply. Yes that’s correct, we only use Office 365 for licensing the Office 365 software suite (Outlook, Word, Excel, PowerPoint). We do not have Active Directory or Exchange. The domain for e-mail is not even the domain we used for our Office 365 accounts, so this should not have any influence. Our e-mail is hosted with IMAP at a 3rd party provider. We need to use their server name during setup (that’s why Autodiscover would come in handy, we wouldn’t have to tell our users to manually setup the account).
        The autodiscover.xml is correct imho, it works when I disable the SAC in the registry.
        How can I test Autodiscover on exrca.com? I’m being redirected to https://testconnectivity.microsoft.com/tests/o365 and I only see tests for Exchange, however we are only using IMAP.

        Like

      2. Most of my experience is working with Exchange – the extent of my experience with hosted email systems outside of Exchange is basically migrating away from them, not configuring 🙂

        The Exchange Remote Connectivity Analyzer (EXRCA) might not be that useful to you in this scenario, but you can try heading over to the Exchange side (https://testconnectivity.microsoft.com/tests/exchange) and use those tests. They will test your autodiscover capabilities and let you know how your mail clients will get information from your server. Hopefully that will give you an idea of whether it’s working properly or not.

        Like

      3. “If you’re not using Office 365 at all, the simplified account creation (…) wouldn’t be working for you either.” So you mean SAC only works for Office 365 or Exchange accounts, not for IMAP accounts?

        Like

  2. Thank you for your assistance so far Jeremy! So as you said you only work with Exchange and not IMAP, you may no longer be able to help me. I decided to give you an update anyways. I tested “Outlook Connectivity” on https://testconnectivity.microsoft.com/tests/Ola/input and here is the result (specific data anonymised): https://pastebin.com/XiPAQgCy
    Interestingly, it says “Autodiscover was tested successfully”, but “No account settings were returned from the Autodiscover response”. Maybe it’s because this test is intended for Exchange, not IMAP?
    Testing with the (local) Outlook “Test E-mail AutoConfiguration” tool works btw. I think if this can’t be resolved, we will have to tell our users to disable SAC (they’re not managed by our company so we can’t roll out a group policy).

    Like

    1. Hey Ryan,
      I think you’ve arrived at your only usable answer, I’m afraid, which is to tell your users how to disable SAC manually – looking through that data you posted, the reason why you have some successes in that Autodiscover testing chain is that it starts out by testing your domain name, testing to see if it gets a response at the domain.com on 443, and then checking for certain URLs (interesting that it finds an Autodiscover URL there). Regardless, because it’s not an Exchange server, it ultimately does not get the response it’s looking for – even though it has “successes” along the way.

      Sorry, I don’t have more good news for you – looks like this is just a feature you have no real need for, and isn’t helping your setup in any way 😦

      Like

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.