Exchange 2013, Outlook for Mac, Autodiscover or cert issue?

Question

• On-prem Exchange 2013 CU23 + all patches, on Server 2012 R2
• Local Windows domain is company.local, Exchange server hostname is server.company.local
• Mail domain is company.com. External DNS MX record points to mail.company.com.
• The server has a trusted 3rd-party cert for mail.company.com. There are also 2 self-signed certs for server.company.local
• Internal and public DNS are (I believe) configured properly. Both server.company.local and mail.company.com resolve properly from either outside or inside the LAN and are appropriately reachable

Everything is functional except for a couple of issues.

Outlook for Mac issue:

• MacBook Air 2020 M1 silicon, macOS Monterey 12.4
• Outlook for Mac as part of an M365 subscription, running in Legacy mode to support on-prem Exchange

Adding an Exchange account works as long as the optional server field is specified as mail.company.com. A new set of Outlook folders is created. However, connection to the server soon drops and syncs and new mail transport don't work. Outlook alternates reporting in its status area "Connecting to: {user address}" and "Last synced at {some time ago}".

Looking at the account properties...Advanced, the Microsoft Exchange Server field is https://server.company.local/EWS/Exchange.asmx , even though during setup the server was specified as mail.company.com. Outlook fails to connect even if the server can be reached (either on the LAN or via VPN); in both cases server.company.local resolves to the expected, reachable address.

If I change that field to https://mail.company.com/EWS/Exchange.asmx , it connects and works normally. However, if Outlook is closed, then re-opened, the value "reverts" back to https://server.company.local/EWS/Exchange.asmx .

Autodiscover for this Exchange server can be reached from both the LAN and the public internet. If I set up a test account in Outlook from the public internet (with VPN disconnected) the account is created but it still gets the server.company.local server name. I believe that server name must somehow be supplied by Autodiscover, because that name isn't reachable from the public internet without a VPN connection.

Second (possibly related) issue: there are multiple Windows 10 clients running Outlook for Windows as part of M365 subscriptions. These are working fine except that each time a user starts Outlook, they get a couple of certificate warnings that server.company.local uses an untrusted, self-signed cert. The users proceed anyways and everything works for them. With the current version of Outlook for Windows on M365 I don't know how to view the same server information which can be viewed in Outlook for Mac but I suspect under the hood Outlook for Windows is also being configured to talk to server.company.local.

Having said all that, I think both of these issues might be fixed if I could get Autodiscover to return mail.company.com as the Exchange server name rather than server.company.local . There is a trusted 3rd-party cert for mail.company.com, so:

• That should eliminate the cert warnings the Windows users are getting
• The "connection" issue with Outlook for Mac might be that it doesn't trust the self-signed cert(s) and, unlike Outlook for Windows, there's no way to manually bypass that. It clearly works fine when the server is manually specified as mail.company.com.

Is it possible to manually specify the server name Autodiscover returns, and if so, how?

Failing that, how might I get the MacBook to trust the Exchange server's self-signed certs (assuming that's why it's failing to "connect")?

Answer 1

Hi @Al Doman ,

Thank you, your suggestion ultimately led to the solution.

Great to know that you've already found of a solution and really appreciate it for your sharing!
By the way, since the Microsoft Q&A community has a policy that "The question author cannot accept their own answer. They can only accept answers by others.". and according to the scenario introduced here: Answering your own questions on Microsoft Q&A, I would make a brief summary of this thread:

[Exchange 2013, Outlook for Mac, Autodiscover or cert issue?]

Issue Symptom:

Adding an Exchange account works as long as the optional server field is specified as mail.company.com. A new set of Outlook folders is created. However, connection to the server soon drops and syncs and new mail transport don't work. Outlook alternates reporting in its status area "Connecting to: {user address}" and "Last synced at {some time ago}".
Looking at the account properties...Advanced, the Microsoft Exchange Server field is https://server.company.local/EWS/Exchange.asmx , even though during setup the server was specified as mail.company.com. Outlook fails to connect even if the server can be reached (either on the LAN or via VPN); in both cases server.company.local resolves to the expected, reachable address.
If I change that field to https://mail.company.com/EWS/Exchange.asmx , it connects and works normally. However, if Outlook is closed, then re-opened, the value "reverts" back to https://server.company.local/EWS/Exchange.asmx .
Autodiscover for this Exchange server can be reached from both the LAN and the public internet. If I set up a test account in Outlook from the public internet (with VPN disconnected) the account is created but it still gets the server.company.local server name. I believe that server name must somehow be supplied by Autodiscover, because that name isn't reachable from the public internet without a VPN connection.

Root cause:

A key part to get all this to work is setting up DNS properly:

• Exterior (public) DNS resolves to office WAN address
• Internal DNS resolves to server LAN address. LAN and VPN connections are both "internal"
• For each scenario, DHCP needs to provide the appropriate DNS server (external or internal), Especially, VPN connections must push the "internal" DNS server to remote VPN clients

The Solution:

The solution is to adjust the Internal URL and External URL in the Virtual Directory for each of the Exchange sites (except AutoDiscover). For all those URLs I changed references to "server.company.local" to "mail.company.com". Note that all external URLs were originally blank. Outlook for Mac is now working as expected, with no certificate issues (silent failure or otherwise). Outlook for Windows clients continue to work (albeit still receiving one certificate warning for server.company.local on Outlook start).

You could click the "Accept Answer" button for this summary to close this thread, and this can make it easier for other community member's to see the useful information when reading this thread. Thanks!

Answer 2

@Aholic Liang-MSFT : sorry for the long delay in replying. Until just now I was unable to post a comment to my own original post; I was asked repeatedly to sign in even though already signed in. I accidentally found a workaround: https://learn.microsoft.com/en-us/answers/content/idea/774717/unable-to-comment-on-a-post.html

Thank you, your suggestion ultimately led to the solution.

Re "how did [I] changed the URL?" In Outlook for Mac, legacy mode (to support on-prem Exchange), this field is shown and can be directly edited as a property of the account (advanced button). Outlook for Windows does not have this option.

The solution is to adjust the Internal URL and External URL in the Virtual Directory for each of the Exchange sites (except AutoDiscover). For all those URLs I changed references to "server.company.local" to "mail.company.com". Note that all external URLs were originally blank. Outlook for Mac is now working as expected, with no certificate issues (silent failure or otherwise). Outlook for Windows clients continue to work (albeit still receiving one certificate warning for server.company.local on Outlook start).

A key part to get all this to work is setting up DNS properly:

• Exterior (public) DNS resolves to office WAN address
• Internal DNS resolves to server LAN address. LAN and VPN connections are both "internal"
• For each scenario, DHCP needs to provide the appropriate DNS server (external or internal), Especially, VPN connections must push the "internal" DNS server to remote VPN clients

Again, thanks for the suggestion.