Autodiscover failing on Exchange Server: fixing SCP, DNS, 401 and certificate errors

Autodiscover tells Outlook where a mailbox lives on Exchange Server and which URLs to use for MAPI over HTTP, EWS and the offline address book. When it breaks, new profiles fail, Out of Office stops working and users click through certificate warnings. In this post I'll show how clients find Autodiscover, how to read the Test E-mail AutoConfiguration log, and how to fix SCP, DNS, 401, 404 and certificate failures.

Symptoms#

• Creating an Outlook profile fails or never finishes, while OWA works for the same user.
• Out of Office, free/busy or the address book fail while mail flows.
• Every Outlook start shows a security alert naming an internal server such as ex01.contoso.local: The name on the security certificate is invalid or does not match the name of the site.
• The Remote Connectivity Analyzer reports The Microsoft Connectivity Analyzer failed to obtain an Autodiscover XML response.

Hold Ctrl, right-click the Outlook icon in the notification area and choose Test E-mail AutoConfiguration. Enter the address, keep Use AutoDiscover ticked, clear the two Guessmart boxes and click Test. On failure the Results tab says Autoconfiguration was unable to determine your settings! and the Log tab looks like this:

Attempting URL https://ex01.contoso.local/Autodiscover/Autodiscover.xml found through SCP
Autodiscover to https://ex01.contoso.local/Autodiscover/Autodiscover.xml starting
GetLastError=12007; httpStatus=0.
Autodiscover to https://ex01.contoso.local/Autodiscover/Autodiscover.xml Failed (0x800C8203)
Autodiscover to https://contoso.com/autodiscover/autodiscover.xml starting
GetLastError=12029; httpStatus=0.
Autodiscover to https://contoso.com/autodiscover/autodiscover.xml Failed (0x800C8203)

The GetLastError and httpStatus values tell you which layer failed:

Why it happens#

Outlook tries a fixed sequence and uses the first answer that returns valid settings:

1. SCP lookup (domain-joined computers on the network). Outlook queries Active Directory for service connection point objects stamped with 77378F46-2C66-4aa9-A6A6-3E7A48B19596. Exchange publishes one per server, holding that server's AutoDiscoverServiceInternalUri, and SCPs scoped to the client's AD site are preferred.
2. DNS (no SCP found). Outlook tries https://contoso.com/autodiscover/autodiscover.xml, then https://autodiscover.contoso.com/autodiscover/autodiscover.xml, then an HTTP redirect check on http://autodiscover.contoso.com, then the SRV record _autodiscover._tcp.contoso.com.

The usual culprits:

• The SCP points at a server FQDN. Setup publishes https://<server FQDN>/Autodiscover/Autodiscover.xml, which usually isn't on your certificate. That's the internal-name security alert, and it returns every time you install a server.
• Stale SCPs from servers never removed cleanly send clients to hosts that don't answer.
• Missing internal DNS. The SCP says autodiscover.contoso.com, but the internal zone has no record (12007).
• The root domain answers. The public website responds for contoso.com with an error or another name's certificate, before Outlook tries autodiscover.contoso.com.
• Authentication (401). Changed virtual directory authentication, Extended Protection behind an SSL-offloading load balancer, or load-balanced Kerberos without an alternate service account.

How to fix it#

1. Check and correct the SCP#

Get-ClientAccessService | Format-Table Name, AutoDiscoverServiceInternalUri, AutoDiscoverSiteScope -AutoSize
Get-ClientAccessService | Set-ClientAccessService -AutoDiscoverServiceInternalUri "https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml"

Every server should publish the same load-balanced name, and that name must be on the certificate. Run the Set-ClientAccessService line on each new server as soon as setup finishes. To see what a client sees, including SCPs left behind by old servers, query AD from any domain-joined machine:

$cfg = ([ADSI]"LDAP://RootDSE").Properties["configurationNamingContext"].Value
$s = [adsisearcher]"(&(objectClass=serviceConnectionPoint)(keywords=77378F46-2C66-4aa9-A6A6-3E7A48B19596))"
$s.SearchRoot = [ADSI]"LDAP://$cfg"
$s.FindAll() | ForEach-Object { [pscustomobject]@{ Url = $_.Properties["servicebindinginformation"][0]; Path = $_.Path } }

An SCP under a server that no longer exists means its removal never completed; finish it properly rather than deleting objects by hand.

2. Fix DNS for every path you rely on#

Resolve-DnsName autodiscover.contoso.com
Resolve-DnsName _autodiscover._tcp.contoso.com -Type SRV
Test-NetConnection autodiscover.contoso.com -Port 443

Internally the name must resolve to your load balancer or Exchange servers; externally, to the published address. If autodiscover.contoso.com can't go on the certificate, an SRV record (port 443, target mail.contoso.com) works, but Outlook asks users to allow the redirect. If the root-domain website gets in the way, have it return a quick 404 for /autodiscover; the client-side ExcludeHttpsRootDomain value under HKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover is only a workaround.

3. Test the endpoint directly#

Browse to https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml and sign in. XML with error code 600 and Invalid Request is the expected answer to a plain GET: DNS, TLS and authentication all work. For a real request, post what Outlook posts:

$body = '<Autodiscover xmlns="http://schemas.microsoft.com/exchange/autodiscover/outlook/requestschema/2006"><Request><EMailAddress>jane@contoso.com</EMailAddress><AcceptableResponseSchema>http://schemas.microsoft.com/exchange/autodiscover/outlook/responseschema/2006a</AcceptableResponseSchema></Request></Autodiscover>'
$r = Invoke-WebRequest -Uri "https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml" -Method Post `
    -Body $body -ContentType "text/xml" -UseDefaultCredentials -UseBasicParsing
([xml]$r.Content).Autodiscover.Response.Account.Action

Run it as the user. settings means Exchange returned the configuration; redirectAddr means the mailbox lives elsewhere, typically Exchange Online in a hybrid setup (see Autodiscover troubleshooting for Exchange Online).

4. Clear 401, 404 and 500 responses#

Get-AutodiscoverVirtualDirectory -Server EX01 | Format-List Server, *Authentication*
$proxy = Join-Path $env:ExchangeInstallPath "Logging\HttpProxy\Autodiscover"
Get-ChildItem $proxy | Sort-Object LastWriteTime | Select-Object -Last 1 | Select-String "jane" | Select-Object -Last 5

• 401: Windows authentication must stay enabled on the virtual directory. In the IIS log (C:\inetpub\logs\LogFiles\W3SVC1), a 401 immediately followed by a 200 for the same POST is the normal handshake; a 401 with nothing after it is the failure. Behind a load balancer, check Extended Protection, which doesn't support SSL offloading.
• 404: the request reached something other than Exchange, such as a website or reverse-proxy rule.
• 500: Exchange itself failed. Compare the HttpProxy log with the Application log; failed or non-elevated updates are a classic cause (see installing Exchange security updates). Admins also report leftover IIS URL Rewrite rules from old mitigations causing it.

Verify the fix#

• Test E-mail AutoConfiguration shows Attempting URL https://autodiscover.contoso.com/Autodiscover/Autodiscover.xml found through SCP followed by Succeeded (0x00000000), and the Results tab lists your namespace, not server FQDNs, for the MAPI, EWS and OAB URLs.
• From outside, the Outlook Autodiscover test on the Exchange Server tab of the Microsoft Remote Connectivity Analyzer passes.
• Outlook starts without a certificate prompt and Out of Office opens.

Prevent it next time#

• Make setting AutoDiscoverServiceInternalUri part of every server build, straight after setup.
• Keep the Autodiscover name on the certificate and track expiry; see renewing the SAN and Auth certificates.
• Keep internal and external DNS in step, and remove client registry workarounds once the root cause is fixed.
• Run the Health Checker after every update.

References#

• Autodiscover service in Exchange Server (Microsoft Learn)