Outlook Click-to-Run Optimizes AutoDiscover for Office 365

Autodiscover Makes Life Easier

Years ago, we had to configure Outlook profiles manually to connect to the right mailbox and server. This wasn’t a good experience. Then Microsoft came up with the idea that computers could probably figure out how to find someone’s mailbox and the Autodiscover feature was born.

In a cloud service like Exchange Online, it is literally impossible for a user to know what server hosts the active copy of a mailbox at any time. With an infrastructure spanning over 175,000 physical servers, Exchange Online is a beast. Autodiscover is hugely important because it makes it easy for users to configure Outlook even when the choice of mailbox servers is massive.

With that in mind, it seems reasonable that the Outlook team would “continue to optimize for the Office 365 experience.” Unfortunately, in this zero-sum game, optimization for the cloud means pain for on-premises users. At least, that’s the impression given by Outlook.

Spreading Happiness in UserVoice

The statement about optimizing for the cloud is from the Outlook team’s December 8 response to a UserVoice request asking Microsoft to adjust a change made to optimize Autodiscover queries for Office 365. If you use the click to run version of Outlook 2016 for Windows, Outlook checks Office 365 first and has done so since the 16.0.6741.2017 update.

Checking Office 365 works well if you have an Exchange Online mailbox. Office 365 will respond to the Autodiscover request and return details of your mailbox and other associated services (like public folders). However, in certain circumstances, the query runs into problems. The two examples cited in UserVoice are when someone has been assigned an Exchange Online (or Office 365) license but their “live” mailbox is on-premises, or when someone with a personal Office subscription uses their business email address to configure Outlook. In the latter example, the business email address belongs to an Office 365 tenant, so that’s where Outlook heads for Autodiscover.

Because Autodiscover fails, Outlook prompts for user credentials. But the credentials go back to Office 365 and fail when Azure Active Directory tries to check the account. The problem is present for both existing and new profiles.

Other problems have been reported by people who use Outlook to connect to Exchange on hosted platforms other than Office 365. The Outlook team probably overlooked this use case, probably because they don’t expect the Click-to-Run version to be used in these circumstances. And of course, if Autodiscover is not configured properly inside an on-premises deployment, changes made to make things run more smoothly for the cloud are likely to accentuate and reveal flaws.

Outlook mobile for iOS and Android also use Autodiscover, but the change doesn’t affect them because these clients use AutoDetect to figure out what email service they need to connect to before calling Autodiscover.

Instruct Autodiscover to Ignore Office 365

The workaround is described in a Microsoft Knowledge Base article and requires a change to the system registry to insert a new DWORD value to exclude Office 365 (ExcludeExplicitO365Endpoint) from the list of locations checked by Autodiscover. Again, this sounds reasonable, but you’d have to know about how Autodiscover works and be prepared to update the system registry on affected PCs. Also, the change must be reversed if the user’s mailbox eventually moves to Exchange Online.

The Logic Behind the Change

It’s easy to understand why the Outlook team made the change. With 155 million people using Office 365, we’re at a point where most Exchange users are now in the cloud (probably), so optimizing the click-to-run version of Outlook for Windows for Office 365 makes sense, especially as this is a version designed for use with Office 365. Most on-premises customers use the MSI version of Outlook 2016, which isn’t affected, or run an earlier version of Outlook (some going back as far as Outlook 2007).

No Sympathy from Outlook

The response from the Outlook team is blunt. It doesn’t convey much sympathy to the on-premises community who hope that Outlook might give them some TLC in the future and that’s regrettable. Someone in the Outlook team could do with some coaching on how to write UserVoice responses. It’s also regrettable that the Outlook team didn’t accommodate some of the edge cases that are now causing problems.

While the change is understandable, some of the online commentary is simply off the wall. Like “One would hope that these on-premises authentication requests hitting Microsoft’s O365 servers are just authentication requests, and Microsoft are not keeping these credentials. If they were, this would be a directory harvesting exercise to the likes we have never seen before.” That’s just too much, even in the silliness surrounding the holiday season.