We have found this new problem when migrating a client from Google Suite over to Office 365, affecting mainly the Outlook service.
Back in the day, just pointing the autodiscovery CNAME record would do the trick.
Nowadays, they base this on a secondary service that was called ampli.net, nowadays outlookmobile.com.
This caches MX records of the domain and autofills as they please, before even touching the autodiscover record.
To see if our migration is having issues with this new and very convenient service, you can run the following powershell:
Invoke-WebRequest -Uri 'https://prod-autodetect.outlookmobile.com/detect?services=office365,outlook,google,icloud,yahoo&protocols=rest-cloud,rest-outlook,rest-office365,eas,imap,smtp' -Headers @{'x-email'="[email protected]"} | ConvertFrom-Json
This will give out where the auto detect is pointing at:
As you can see, the cache still shows that this service is in Google, where all our records are pointing at Office 365.
We have waited for 3 days with no changes, and the only solution so far we have found is to escalate this issue via a support ticket with Microsoft.
There are solutions on which you can do registry changes to force the domain autodiscover process, but having more than a few users will complicate matters worse.
Hi do you have the registry fix for this? I have not cutover the MX records yet. But i would have thought the autodiscover would work as it’s a microsoft product. I’ve tried it in a new machine that has never seen the domain before and it’d still signing in to gmail by default. This is happening on iPhones and android. It seems to be seeing the MX records are google and going there automatically… so much for autodiscover settings!
The registry fix would only work for Windows, not for iPhones/Android. I can’t seem to find the document I was referencing on this post, I had to do the switch over to the new service and wait for replication sadly.