Background. Outlook Autodiscover has a certain order of trying to figure out configuration, and it's somewhat unchangeable, at least for Office 365 users with BYOD devices:
- Domain apex
https://example.com:443/Autodiscover/Autodiscover.xml. As this is typically a public web site hosted elsewhere, this seems like an unnecessary step for most. https://autodiscover.example.com:443/Autodiscover/Autodiscover.xmlis a way more reasonable alternative. Unfortunately, as of Sep 2019, Microsoft has screwed this up: for Office 365 users this is instructed to be aCNAME autodiscover.outlook.com., but...$ curl -vvv https://autodiscover.outlook.com:443/Autodiscover/Autodiscover.xml * Trying 40.101.49.88... * TCP_NODELAY set * connect to 40.101.49.88 port 443 failed: Connection refused * Trying 40.101.65.216... * TCP_NODELAY set * connect to 40.101.65.216 port 443 failed: Connection refused * Trying 40.101.126.120... * TCP_NODELAY set * connect to 40.101.126.120 port 443 failed: Connection refused * Trying 40.101.126.216... * TCP_NODELAY set * connect to 40.101.126.216 port 443 failed: Connection refused * Trying 2603:1026:207:15::8... * TCP_NODELAY set * connect to 2603:1026:207:15::8 port 443 failed: Connection refused * Trying 2603:1026:207:109::8... . . .Fallback to HTTP redirect method, the only method working.
This time
http://autodiscover.example.com:80/Autodiscover/Autodiscover.xml, configured as aCNAME autodiscover.outlook.com., answers with a redirect to a working site.Location: https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xmlThis one is serving correctly in most cases, although lines seems to be long for new Application Passwords to make it this far. This, how ever, takes a lot of request and additional time. (Also, this makes it harder to debug why certain versions of Outlook can't currently connect to Office 365 at all, but must be ugraded before even trying...)
Possible solution to make this faster is to add a reverse proxy at the domain apex, pointing to the working Office 365 Autodiscover site. E.g. with Apache this is as easy as enabling the module with a2enmod proxy_http and adding a simple configuration to the VirtualHost:
# Office 365 Autodiscover Hack 20190918
SSLProxyEngine on
ProxyPass "/Autodiscover/" "https://autodiscover-s.outlook.com/Autodiscover/"
ProxyPassReverse "/Autodiscover/" "https://autodiscover-s.outlook.com/Autodiscover/"
According to the Microsoft Remote Connectivity Analyzer test for Outlook Autodiscover this seems to work perfectly fine, and it also seems to make Outlook Autodiscovery seemingly faster on actual Outlook installations.
As this is a hack rather than an actual solution documented anywhere, my question: is there any possible consequences from this approach you could think of?
Is the autodiscover-s.outlook.com for example a static hostname for the service, or does it ever give other redirects? Wouldn't Outlook just continue with steps 2 & 3 in any case this proxy gives unexpected results?
