Blog: Office 365

I recently worked with two Outlook 2016 installs that had been working fine for months, then both experienced an issue when attempting to launch Outlook. They were 'randomly' getting one of the following errors:
 
Your mailbox has been temporarily moved to Microsoft Exchange server.
A temporary mailbox exists, but might not have all of your previous data.
You can connect to the temporary mailbox or work offline with all of your old data.
If you choose to work with your old data, you cannot send or receive e-mail messages.
 
'AD lookup for email address failed "0x800500d"'
 
When attempting to create a new mail profile for testing, the new profile would come up in the following format - outlook_[letters and numbers]@outlook.com
 
During this time, both Outlook Web Access and ActiveSync access were working properly, along with building a mail profile using Outlook 2010 or 2013. I later found out that both clients had their email address for AspireMail added as an alias to a Microsoft account. We considered removing the alias, but we eventually came across the following article: https://blog.skykick.com/new-microsoft-direct-connect-feature-may-prematurely-connect-outlook-to-office-365
 
Starting in Outlook 2016 version 16.0.6741.2017, Microsoft enabled a new feature called Direct Connect to Office 365. It was designed to quickly connect Outlook 2016 to Office 365.
 
However, if Microsoft's Autodiscover is not working on the source server or the connection between a computer and the source email server is interrupted, Direct Connect may cause Outlook to connect to Office 365 prior to cutover, even though the Autodiscover DNS path is still pointing to the source server.
 
Once we added the DWORD registry key ExcludeExplicitO365Endpoint Value : 1 to the HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\AutoDiscover, Outlook 2016 was then able to successfully authenticate the email account, finding the appropriate Autodiscovery DNS path.

 

I found out last week how easily one can get a certificate from GoDaddy with a SAN (Subject Alternative Name) for a non-registered domains name. This would include domains that end in .dom or .local that do not have a public registrar. Since GoDaddy cannot retrieve a WHOIS record for the domain, their authorization email only needs to be approved by the account that requests the certificate. This vulnerability removes a significant barrier for a man-in-the-middle attack, since the certificate would be trusted and the name would match the URL requested by the users.

Additionally, Office 365 AD Sync (needed for password synchronization) will not work with these type of non-registerable DNS names in a UPN suffix. While the UPN suffix can be changed to be different than the domain name, the problem would not exist for domains that use names like “internal.registereddomain.com”.