Outlook Autodiscover

[al_platt]

Hi,

I'm hoping someone here may have come across this before. We use a mixture of Apple Mail and Outlook 2016.

Apple Mail does a good job of knowing if it's on an internal or external connection and adjusts accordingly.

Outlook always seems to stick with the internal auto discover address though. I'm forcing outlook to not use auto discover at all and only use the external webmail address below with Apple Script but it's not ideal as i have around 40 users in a different country.

I'm assuming that our DNS records for Auto Discover work as Mail seems to see them.

We have

Internal https://mail.fqdn.local/EWS/Exchange.asmx

External https://webmail.fqdn.com/EWS/Exchange.asmx

Any help much appreciated.

Thanks

Al

[talkingmoose]

You're definitely going to have a conundrum with Outlook for Mac if you disable Autodiscover but have different internal and external server URLs. Mail handles it by having the two fields and never really needs to use Autodiscover.

This is something you need to raise to your Exchange or network administrators. Does Autodiscover not work correctly to point Outlook to an internal address while on the network and an external address when off network?

Maybe your network administrators could add a "mail" CNAME to your external DNS and point it to "webmail".

[al_platt]

Hi @talkingmoose We only disable Autodiscover locally as Outlook won't connect when the Macs are off the LAN or VPN. Forcing them to use the webmail.fqdn.com ensures they connect everywhere but we shouldn't need to do that. I'm assuming our Autodiscover works as it should as the PCs connect everywhere with no issues but since the Macs don't we must be missing something somewhere!

Our DNS is as follows....

> set type=srv

> _autodiscover._tcp.fqdn.com 8.8.8.8

Server: [8.8.8.8]

Address: 8.8.8.8

Non-authoritative answer:

_autodiscover._tcp.fqdn.com SRV service location:

priority = 10

weight = 10

port = 443

svr hostname = autodiscover.fqdn.com

> set type=cname

> autodiscover.fqdn.com 8.8.8.8

Server: [8.8.8.8]

Address: 8.8.8.8

Non-authoritative answer:

autodiscover.fqdn.com canonical name = webmail.fqdn.com

> set type=A

> webmail.fqdn.com 8.8.8.8

Server: [8.8.8.8]

Address: 8.8.8.8

Non-authoritative answer:

Name: webmail.fqdn.com

Address: our.external.ip

[talkingmoose]

@al_platt, your network folks need to make sure Autodiscover works correctly both internally and externally. Its primary purpose is for DNS to point your client to the correct server but it's also used for things like keeping your Offline Address Book (OAB) up-to-date.

Outlook for Windows uses a different set of protocols for connecting to Exchange internally (MAPI) and externally (RPC over HTTP). While they will utilize Autodiscover, they won't rely on it as heavily as Outlook for Mac.

I'm not an expert in Autodiscover. I suggest you point your folks to Microsoft's analyzation tool to see what it says about your external Autodiscover setup. It'll test and offer you solutions for fixing it.

https://testconnectivity.microsoft.com

[AVmcclint]

I don't know if our situation is the same as yours but there be a similarity. Our internal DNS & DHCP sucks. It is just configured poorly from top to bottom. We have repeatedly shown our network engineers the many ways in which it fails to work as desired, but they just shrug it off and ignore us. The best example of this is that users on Ethernet get via DHCP the search domains "company.com" and "company.net" (because they are both used). Users on Wifi, however, get "wifi.company.com" as the lone search domain. Of course this fails when computers try to connect to just a hostname because there is no "servername.wifi.company.com" in existence here. When I setup Outlook on a Mac connected via Ethernet, the Autodiscover works. When I setup Outlook on a Mac connected via WiFi, Autodiscover fails every time. Because of this, we have to setup users while on Ethernet, and also force users to specify the full FQDN when connecting to ANY of our servers regardless of how they are connected to the network.

[al_platt]

Our DNS tends to work well, don't have any other issues apart from this and a weird thing with Any Connect not using the company DNS servers for certain things.

https://testconnectivity.microsoft.com shows all working as it should do which makes the issue all the stranger.

I'll keep pushing on with our Exchange guy and see what we come up with.

Thanks

Al