Autodiscover points to incorrect location after cpanel update

For a domain on Office365, I had autodiscover stop working.  My main clues were that user setups would not autoconfigure and Outlook would lose its Outlook RPC over HTTPS settings.

The problem was that a cpanel update created an autodiscover entry that superseded the standard autodiscover entry that Microsoft suggested customers put in place.  This would affect domains in these situations:

1) Use Exchange as their email server (Office365 or any other Exchange server, on premise or outsourced)
2) Have a valid third party SSL certificate on their web site
3) Use WHM/cpanel on their web server

My clue that autodiscover was pointing to the wrong location (aside from the aforementioned problems) was that server replying with autodiscover.xml information was the domain's web server when running the Outlook Autodiscover test from https://testconnectivity.microsoft.com.

Implementations vary, but typically autodiscover (for Office365 at least) will be configured by a CNAME record of autodiscover.domain.com to autodiscover.outlook.com.  In the case here, a WHM/cpanel update created a autodiscover response at https://domain.com/Autodiscover/Autodiscover.xml.  Outlook checks https://domain.com/Autodiscover/Autodiscover.xml before it checks https://autodiscover.domain.com so if Outlook finds a response at https://domain.com/Autodiscover/Autodiscover.xml, you will have a problem.

In the case of the WHM/cpanel update, https://domain.com/Autodiscover/Autodiscover.xml would forward to https://cpanelemaildiscovery.cpanel.net/autodiscover/autodiscover.xml - which gave the incorrect autodiscover response.

There are two fixes.

The first/proper fix is to disable autodiscover using WHM.  Log into your WHM in your web browser and log in as root.  In my case, I logged in to my BlueHost WHM via http://123.123.123.123/whm (where 123.123.123.123 is your server's IP address).  Go to Server Configuration -> Tweak Settings.  Make sure Proxy subdomains is turned ON.  Make sure Thunderbird and Outlook autodiscover and autoconfig support are turned OFF.

The second/manual fix (courtesy of comment at 2/14/2015 10:21 AM at http://community.office365.com/en-us/f/156/t/293985.aspx):

• Log in as root on your web server
• Edit /etc/httpd/conf/httpd.conf
• Search for autodiscover, you should find a ScriptAlias line referencing it
• Comment this line out or remove it completely
• Edit /usr/local/cpanel/APACHE_CONFIG and find the same line and remove it or comment it out
• on BlueHost, run "/usr/local/cpanel/bin/apache_conf_distiller --update"
• run "service httpd graceful" to restart apache

Afterwards, test your autodiscover via https://testconnectivity.microsoft.com and presuming a successful tests - all is well since the web server is no longer responding to autodiscover requests.

Manual setup of Office365 (on Exchange 2013)

If for some reason autodiscover isn't working or you can't put autodiscover in place, here are manual instructions for setting up Outlook for Office365 (when using Exchange 2013):

http://blogs.perficient.com/microsoft/2014/01/manually-configuring-outlook-for-office-365-exchange-2013/

SSL cert errors for old Exchange server after you've already moved to Office365

My users began getting SSL cert errors in Outlook after the SSL cert on my old mail server expired.  This was weird because I had moved my company's email to Office365 more than a year earlier.  It looked something like this:

Quick research led to the idea that Outlook was looking at the autodiscover for the internal server when connected to the LAN as opposed to the CNAME record that pointed to autodiscover.outlook.com

The fix . . .

First run this on your old mail server in an Exchange shell to see where your autodiscover is currently pointing:
Get-ClientAccessServer | fl AutoDiscoverServiceInternalUri

If it's pointing to your internal server with the expired certificate, that's a problem.  To fix that, run this command in the Exchange shell (assuming your server is named server1):
Set-ClientAccessServer -Identity "server1" -AutoDiscoverServiceInternalUri "https://autodiscover.outlook.com" -AutoDiscoverSiteScope "Mail"

or I could disable internal autodiscover via this command (assuming your server is named server1):
Set-ClientAccessServer -Identity “server1″ -AutoDiscoverServiceInternalUri $NULL

setting up autodiscover SRV records for SBS 2008 for complete functionality (including out of office assistant)

Exchange 2007 (and 2010) rely on DNS for certain functionality more than Exchange 2003 did. Particularly, I mean the autodiscover record.

A great example is the out of office assistant. This will not work on your Exchange 2007 box unless you have your autodiscover information set properly.

There are a couple ways to do set it up, but I'll cover what seems to be the easiest and least costly way - the SRV record.

Some nameservers support SRV records, and some don't (it's different from an A, MX, or CNAME record) - which is where it can get weird, but presuming you have a nameserver that does, you can set up an SRV record with these properties:

Service: _autodiscover
Protocol: _tcp
Port Number: 443
Host: remote.yourdomain.com

Once that record propagates, your autodiscover will work properly (because SBS autocreates the appropriate information at remote.yourdomain.com/autodiscover)

There are other options like getting an SSL certificate that encompasses autodiscover.domain_name.com - but that requries more cost and isn't really necessary.

If you can create the SRV record with your nameserver, that's the best method in my opinion.

If you'd like to check on the status of an SRV record, you can follow these instructions or use Microsoft's site at https://www.testexchangeconnectivity.com

Hopefully, this will help someone. As I was investigating why my out of office assistant wasn't working, I feel like all the resources available to me were pretty vague about what was needed and how to go about it.

UPDATE:
A good tutorial from Susan Bradley is here (which includes screen shots of setting up an SRV record on godaddy's DNS).

checking autodiscover SRV records using nslookup

There are a couple ways to add autodiscover - which is required by Exchange 2007 (and presumably Exchange 2010) for full functionality (more coming on this concept).

One method is to add an SRV record. Because nothing is easy, not all DNS editors allow you to create SRV records. Sometimes, you can add them yourself. Sometimes, you have to write to support. Sometimes, it can't be done. But when it is done, here is how to check on it:

In a DOS prompt, type "nslookup"
Then "set type=srv"
Then the record you want - such as "_autodiscover._tcp.exampledomain.com"

Here's what a properly configured autodiscover looks like: