One item found in external DNS records was a cname record for autodiscover that needed to be removed.
See... https://www.thirdtier.net/setting-up-autodiscover-for-sbs-2011/ the SRV record was already set and correct from what I could tell. I did request the website host to provide a redirect to have the voxtm.ca xml file request actually get pushed to the correct site/server that hosts the Exchange and therefore the xml file. He said he would look into it but I have not been advised there was a change made. I have tested an OL2016 install to add the specific users account to Outlook and all worked properly when necessary account entries have been made. I think the cname was the bigger block to going forward. Thanks everyone. Cal -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of James Hill Sent: January 24, 2017 5:22 PM To: [email protected] Subject: [Exchange] RE: issue with autodiscover for Outlook 2016 (and no doubt O365) not resolving properly Hi Calvin, You have two options here. 1. Remove the A record from the public DNS for voxtma.ca (Which is a bad idea as no one bothers putting in www anymore and) 2. Have the SSL certificate renewed on the voxtma.ca web site so that https://voxtma.ca doesn't report an error (the certificate has been revoked currently. Or have voxtma.ca not respond to https requests. I've come across this issue several times and I wish Microsoft would change the Autodiscover process so that it doesn't look for a cert in the root domain first as most Exchange Admins don't also manage the domains website. James. -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Calvin McLennan Sent: Wednesday, 25 January 2017 1:39 AM To: Calvin McLennan <[email protected]> Subject: [Exchange] issue with autodiscover for Outlook 2016 (and no doubt O365) not resolving properly I have an SBS 2011 (Exchange 2010) server fully patched and working fine internally and for lower version Outlook remote connections. If a PC is set up internally (OL2013/2016) things go OK for autoconfiguration. Externally - ie - not on the local network for OL2013/2016 - autoconfigure does not work properly. Manual configuration of OL2013 needs to be done... But of course manual configuration of OL2016 doesn't exist. Domain DNS (GoDaddy) seems to have what I believe are proper records. Just spent 1/2 hour with their support - www.voxtm.ca and voxtm.ca go to the required offsite web host - autodiscover, MX, etc go to the onsite SBS2011 office.voxtm.ca I have done testexchange tests and found a strange certificate in play (ie - not the valid third party cert that is on the SBS2011 box). In hindsight I recall seeing a similar notice when setting up internal OL systems - but was able to get past any cert issue easily. I think is happening for external setup of OL2013/16... - autodiscover (and the exchange test itself) try's voxtm.ca (resolves to the offsite web host) first - that gets the strange certificate error - test completes with warnings I expect that OL2016 and probably O365 get the same and fail Recommendations? Fixes? I was thning maybe I could ask the web host to temporarily redirect voxtm.ca to office.voxtm.ca as a test. GoDaddy says I should not change the DNS records so far as www and voxtm.ca. Your consideration is appreciated! NOTE: curiously I cannot view certificates for these sites in IE or EDGE. Some secure sites show the certs. But not the ones I am trying to work with. That becomes a problem of course when you are trying to confirm the cert/site is proper. Cal
