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!