Autodiscover 404

Question

After much research and testing, I have implemented the redirect rules to have autodiscover check elsewhere than on my web server. With this post, I am trying to figure out what may be wrong (could be nothing is wrong, I just want to tripe check) as to why the redirects I have in place are not working in my virtual host within my Apache web server. I have included my three redirects I have saved in the 443 virtual host:

Redirect permanent /autodiscover/autodiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml
Redirect permanent /AutoDiscover/AutoDiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml
Redirect permanent /Autodiscover/Autodiscover.xml https://outlook.office365.com/owa/plymouthinc.com/Autodiscover/Autodiscover.xml

After re-starting Apache, I ran the https://testconnectivity.microsoft.com/ tool to make sure that the redirects are working and I still see the following in my error logs.

192.168.9.16 - - [15/Aug/2018:16:05:12 -0700] "POST /Autodiscover/Autodiscover.xml HTTP/1.1" 404 38531 "-" "Microsoft Office/15.0 (Windows NT 6.2; Microsoft Outlook 15.0.4615; Pro; MS Connectivity Analyzer)"
192.168.9.16 - - [15/Aug/2018:16:05:13 -0700] "POST /Autodiscover/Autodiscover.xml HTTP/1.1" 404 38556 "-" "Microsoft Office/15.0 (Windows NT 6.2; Microsoft Outlook 15.0.4615; Pro; MS Connectivity Analyzer)"

Now this is purely cosmetic in nature to get this resolved -- all of my users are able to send and receive emails with no issues, this is just something we on the IT team would like to correct. My error logs are not full of 404 errors, the above listed errors only show up when the tool is ran --- not if/when a user is setting up their email clients (desktop or phone); I have tested this and watched the logs to see if anything appeared in the logs that would relate to the results of the connectivity analyzer results...nothing.

I have reached out to Microsoft themselves, provided them the results of the connectivity analyzer tool and their response back was "Your account is properly configured and there is no need for further test and this is an expected result." I wasn't holding my breath to get an actual answer back from them, but I thought I would try at least. As I mentioned, this is something we on the IT would like to resolve, but it does not affect my users in anyway.

Has anyone else, that has their company web server hosted internally that use Office365 encountered this issue in the past? If so, what did you do to correct it - if you did anything? Any Linux/Apache guru's out there see something I am not catching?

I am more than willing to provide any additional information you may need to provide assistance; as always, if this does not meet the formatting guidelines or needs more information, please let me know and I will make the change or provide the additional information. Thank you very much!

Answer 1

Your account is properly configured and there is no need for further test and this is an expected result.

This IS an actual answer: there is no problem with not redirecting /Autodiscover/Autodiscover.xml. Despite utilizing the HTTPS protocol, Outlook is not a web browser and it shouldn't be treated like one. Outlook doesn't care about your redirects. Instead, given 404 (or any other than 200) response it moves on to the next candidate, as explained in both Overview of the Autodiscover process and Autodiscover service.

So, effectively your autodiscover.plymouthinc.com. IN CNAME autodiscover.outlook.com. does the trick. As stated in your question, the clients don't even use plymouthinc.com for autodiscovery, and if they did, it's not considered an error. That's why it really is an expected result. Stop worrying.

---

Another misconception, unrelated to the Autodiscovery: if you ever actually need to redirect POST requests, keep in mind that the Redirect permanent returns status code 301 Moved Permanently, causing the URL from the Location: header retrieved using the GET method. If you need to preserve the POST data, use the status code 307 Temporary Redirect, instead. (See RFC 7231 6.4.2. & 6.4.7.)