Recently, I was working on a project to migrate mailboxes from on-premises Exchange to Office 365 as part of a domain consolidation project. As a result of some of the complexities of the project, we decided to use a tool for mailbox migrations, which seemed to be working fine. One of the complexities we had to deal with was that the custom domain we needed to migrate was previously registered on an Office 365 tenant run by 21Vianet.
While this tenant was not in any way used for email, we still needed to remove the domain from the Office 365 tenant run by 21Vianet and add it to the target tenant, which was a normal Microsoft Office 365 tenant (just for clarity; this was a US client so all services were hosted out of the US). The domain removal was completed without issue and was the same process as removing a custom domain from a normal Microsoft run tenant. We then successfully added the custom domain to the target tenant and migrated all of the mailbox data.
THE PROBLEM
When it came time to test; after all the accounts were migrated to the new AD domain, we hit a hurdle. Users were able to login to OWA and the Office 365 portal fine, but when they attempted to configure their Outlook profile, or license their Office 365 ProPlus install they got errors. After confirming all the Office 365 related external DNS settings were configured correctly, including autodiscover, we were stumped. We even ruled out anything related to the customer’s internal DNS by attempting to configure a Windows client on completely unrelated network, with no luck. Everything pointed to something somewhere which was still routing this authentication piece to the Office 365 tenant run by 21Vianet; so we logged a ticket with Microsoft thinking it was something within the Microsoft network.
THE SOLUTION
After some days of troubleshooting and escalations, we finally got on to with a Microsoft engineer who pointed us to the client’s external DNS again and a CNAME record called MSOID. Years ago, this was required for all Microsoft Office 365 tenants to point to the correct authentication endpoint for your location, which ensured rapid authentication response times. These days it’s not required, EXCEPT if you are configuring an Office 365 tenant run by 21Vianet! Once we had another look at external DNS, low and behold an MSOID CNAME record was configured pointing to clientconfig.partner.microsoftonline-p.net.cn. Once we deleted the record and allowed for DNS replication, everyone was able to license their Office 365 ProPlus instance and configure their Outlook profile.
You can see the reference to the MSOID configuration for Office 365 tenants run by 21Vianet here and here. I hope this helps someone else avoid this frustrating issue!
