Autodiscover does not work - Exchange 2016

Question

Recently I've set up Exchange Server 2016, configured external DNS accrodingly. Server itself works fine, can send and receive emails. OWA is working fine aswell (externally and internally).

Issue is that Autodiscover is not working properly. I can open it externally via https://example.com/autodiscover/autodiscover.xml (it prompts for user and password), but cant set up an account automatically in Outlook. Outlook prompts for server address and domain credentials. I have no problem typing those, but I need to solve this issue due users.

When testing Autodiscover in Microsoft Connectivity Analyzer it reports no errors whatsoever.

Answer 1

There are two ways you can set up Exchange's Autodiscover service, assuming a SMTP domain called "example.com":

• You can have the DNS name "example.com" point to the Exchange server(s), and then your Autodiscover URL will be https://example.com/autodiscover/autodiscover.xml.
• You can have the DNS name "autodiscover.example.com" point to the Exchange server(s), and then your Autodiscover URL will be https://autodiscover.example.com/autodiscover/autodiscover.xml.

In both cases, the name should resolve to your Exchange server(s) both from your internal network and from the outside (usually via a reverse proxy and/or firewall); if you have more than one Exchange server, a load balancer should be placed in front of them and configuration should be modified accordingly; also, the certificate used for Exchange web services (be it on the server(s) or on the load balancer / reverse proxy) should contain as a SAN the name you are using for the service.

It seems like your external publishing of the service is ok, otherwise the Remote Connectivity Analyzer would fail; but what about your internal network?

Are you using the same name ("example.com") for both your SMTP domain and your Active Directory domain? If this is the case, the FQDN of the domain will automatically point to your domain controllers in the internal DNS, thus it can't point to your Exchange server(s).

If instead "example.com" is a different domain from your AD one, are you using split-DNS (i.e. do you have an internal DNS zone with the same name)? And in this case, did you make the FQDN of the domain point to your Exchange server(s) from inside your network, too?

TL;DR: make sure "example.com" points to your Exchange server(s) both when resolved in the internal network and when resolved outside it; if this is not feasible, switch to a specific name ("autodiscover.example.com") instead of using the FQDN of the domain; and in that case, make sure the certificate used by Exchange web services contains the appropriate SAN.

Answer 2

Are you setting up the clients externally or internally (and do both fail)? Can you scrub & post output of:

Get-OutlookProvider 
Get-OutlookAnywhere
Get-ClientAccessServer

Most of the time I see problems with those values.

AutodiscoverServiceInternalUri. InternalHostName & ExternalHostName.

Requiring SSL? Authentication method? Assume you have a CA generated certificate installed and it's trusted by clients (some CA's require the Intermediate cert installed too).

Answer 3

Do Outlook works after enter the server name (it's the Exchange GUID for user mailbox normally) and mailbox credential? Does internal Outlook client working fine with autodiscover?

I suppose the autodiscover works (get error 600 when browser autodiscover URL) and has valid certificate for autodiscover.

As we known, the MAPI over HTTP will enabled by default in Exchange 2016. Thus, run "Get-MapiVirtualDirectory" to view the URL and authentication settings of it. Also, check the settings of Outlook provider, Outlook Anywhere as Finny mentioned above. Ensure those FQDNs are valid by DNS resolution.

Answer 4

I have read the previous answers before posting, so mine is not a rehash of any of theirs so give this a try.

This answer is solely based on your statement that "the Microsoft Connectivity Analyzer reports as everything is ok" is true.

It is very odd for external autodiscover to work over internal autodiscover, simply because you don't have to do anything to configure internal autodiscover. I can only suspect that you may have broken this somehow by accident.

There are actually two methods autodiscover can use to retrieve mailbox settings. There is the DNS method (which is your description above) and is what the RCA tools uses. This method is used when an Outlook client is NOT part of an Active Directory (AD). Since the RCA tool is not part of your AD, it uses this method. This validates that this is configured correctly. However, if you are attempting to configure Outlook from a machine connected to AD, autodiscover uses a different process. It uses something called a Service Connection Point. This SCP is stored in AD in a specific location. Simply put, an internal machine connected to AD will look for this SCP record and use whatever is configured there INSTEAD of the DNS method you are using above.

Let's say your autodiscover is running on autodiscover.example.com and you have tested this successfully with RCA. But let's say the SCP record has been configured incorrectly as autodiscover.yourADdomain.local. What this means is that Outlook internally will think autodiscover is at this location instead. Please check your SCP record and (if comfortable) tell us what it says. If not, just let us know if it different to what you expect. To find the location of the SCP read this https://learn.microsoft.com/en-us/exchange/client-developer/exchange-web-services/how-to-find-autodiscover-endpoints-by-using-scp-lookup-in-exchange#locate-autodiscover-scp-objects-in-ad-ds

Again, assuming you statement about external autodiscover is true, then I can tell you with 100% certainty that the issue is with that SCP record. If you SCP record is the same URL as the DNS method (it HAS to be the full path https://xxx.example.com/autodiscover/autodiscover.xml from memory) then it means that your internal DNS does not have DNS records for xxx.example.com that point to the Exchange servers.