Outlook credential prompts after an Exchange datacenter move: Autodiscover, DNS, and the SCP trap

TL;DR: After a lift-and-shift or a front-door IP change, some users see random Windows Security prompts in Outlook even though mail still flows. That usually means Outlook is occasionally walking the Autodiscover chain, hitting a stale DNS name, a wrong TLS certificate, or an on-premises SCP object that still advertises a dead URL. This article walks through DNS + TLS checks in PowerShell, explains why SCP still wins on domain-joined PCs, and lists the edge cases you will not fix with a five-minute Google — because the failures are order-dependent and feel “random” to end users.

Problem

You cut over MX, moved VIPs, or decommissioned an old Exchange CAS array. Helpdesk says: “Outlook asks for a password every hour, Cancel still works, mail keeps coming.” Sometimes only ~10% of users see it, which makes reproducing the issue in a lab almost impossible.

From the user’s chair it looks like Windows broke. From your chair it is usually one of three mechanisms: (1) the root-domain probe https://contoso.com/autodiscover/autodiscover.xml returns HTTP 200 from a generic web host, and Outlook treats that as a valid Autodiscover response and tries to authenticate there; (2) Active Directory SCP still advertises https://legacy.contoso.com/autodiscover/autodiscover.xml with a certificate that does not match the user’s SMTP address; (3) token drift after hybrid moves — WAM has a good token for outlook.office365.com, but a secondary Autodiscover hop still triggers a basic-auth style prompt against a hostname that never completes OAuth.

A recent r/sysadmin thread about credential prompts after a datacenter migration matches this pattern: mail flows because the primary path is fine, but a secondary Autodiscover hop periodically wakes up and throws MFA/basic loops.

Why it happens

Classic Outlook does not have a single canonical configuration URL. Microsoft documents multiple Autodiscover methods. For domain-joined machines, SCP in AD is early in the list — that is intentional so on-prem Exchange can steer clients. If you left SCP behind after moving mailboxes to Exchange Online, Outlook will still try the advertised URL first, get TLS or auth errors, and surface the Windows credential UI.

Separately, the HTTPS root-domain probe is a notorious foot-gun: any hosting provider that serves a 200 OK (even HTML) under /autodiscover/autodiscover.xml can confuse older Outlook builds. Even when the mailbox is cloud-only, the client still executes parts of the chain.

Finally, OAuth configuration matters: if OAuth2ClientProfileEnabled is off in the tenant (rare but seen after aggressive hardening templates) or Conditional Access interrupts token refresh for the Exchange resource, you will see credential prompts that “feel” like Autodiscover but are actually authorization failures.

Step-by-step remediation

Step 1 — prove what DNS and TLS really say

On an affected workstation (not on the Exchange server):

Resolve-DnsName autodiscover.contoso.com -Type A,CNAME -ErrorAction SilentlyContinue |
  Select-Object Name,Type,IPAddress,NameHost
Resolve-DnsName mail.contoso.com -Type A,CNAME -ErrorAction SilentlyContinue |
  Select-Object Name,Type,IPAddress,NameHost

You are hunting for split-brain DNS (internal vs 1.1.1.1), stale A records, or wildcard *.contoso.com that catches autodiscover.contoso.com and lands on a parking page.

Then validate the certificate the client would see:

$tcp = New-Object System.Net.Sockets.TcpClient('autodiscover.contoso.com',443)
$ssl = New-Object System.Net.Security.SslStream($tcp.GetStream(),$false,({$true}))
$ssl.AuthenticateAsClient('autodiscover.contoso.com')
$ssl.RemoteCertificate.Subject
$ssl.Dispose(); $tcp.Close()

If the subject is your CDN or hosting provider and not *contoso.com, Outlook will throw security prompts even when M365 otherwise works.

Step 2 — inventory SCP in Active Directory

On a management server with RSAT:

Get-ADObject -SearchBase (Get-RootDSE).configurationNamingContext `
  -LDAPFilter "(objectClass=serviceConnectionPoint)" -Properties keywords |
  Where-Object { $_.Name -match 'Autodiscover' } |
  Select-Object Name,DistinguishedName,@{n='Keywords';e={$_.keywords}}

If keywords still reference a decommissioned URL, update Exchange autodiscover virtual directories or remove the stale SCP objects in a controlled change window. If you are cloud-only and SCP is pure technical debt, Microsoft documents ExcludeScpLookup under HKCU\Software\Microsoft\Office\16.0\Outlook\AutoDiscover (16.0 is the common key for current channel builds — adjust for your branch). Treat that as a scalpel, not a chainsaw: you are changing precedence order for all Autodiscover methods.

Step 3 — narrow it down to Exchange Online auth

# Exchange Online PowerShell
Get-OrganizationConfig | Select-Object OAuth2ClientProfileEnabled, DefaultAuthenticationPolicy

If OAuth is disabled, fix that before chasing DNS ghosts. Pair this with Entra ID Sign-in logs filtered to the user and Office 365 Exchange Online to catch CA policies that block token refresh while IMAP/SMTP still appear to “work” in other tools.

Step 4 — controlled cache reset

Close Outlook, then remove only Autodiscover XML fragments:

Remove-Item "$env:LOCALAPPDATA\Microsoft\Outlook\*.xml" -Force -ErrorAction SilentlyContinue

Document that you destroyed local evidence. If the issue persists, create a new Outlook profile (not a new Windows profile) to rebuild the Autodiscover state machine from scratch.

Step 5 — coordinate with whoever owns the public website

If https://contoso.com/autodiscover/autodiscover.xml returns anything other than a deliberate 404/redirect chain per Microsoft guidance, fix the web stack. Exchange admins cannot “Outlook repair” their way out of a poisoned root-domain response.

Traps and edge cases

1. Internal DNS vs public DNS divergence — classic VPN vs office behavior. Always compare Resolve-DnsName on-net and off-net.

2. Orphaned SCP after hardware decommission — the Exchange server is gone, LDAP objects remain, Outlook keeps trying dead URLs with exponential backoff that looks random to users.

3. Duplicate credentials in Windows Credential Manager — stale basic entries pointing at legacy hosts fight with WAM tokens. Removing Office-related entries is ugly but effective when telemetry proves token refresh failures.

4. Click-to-Run vs MSI builds — different registry hives (16.0 vs 15.0) mean your carefully crafted GPO might only hit half the estate.

5. Conditional Access targeting the wrong cloud app — users pass Outlook connectivity tests but fail silent token refresh for the Exchange resource; the UI still looks like “password please”.

Summary

• Treat Autodiscover as its own migration workstream, not an MX follow-up task.
• Start with DNS + TLS SNI proof on the exact hostname Outlook probes.
• SCP is the prime suspect for domain-joined clients after on-prem to cloud moves.
• Validate OAuth + CA before you reimage laptops.
• Fix root-domain hosting responses before blaming Microsoft patches.

Step 6 — client-side logging when DNS checks out clean

When you suspect Outlook itself rather than infrastructure, enable short-lived logging (do not leave unmanaged in regulated industries):

HKCU\Software\Microsoft\Office\16.0\Outlook\Options\Mail — DWORD: EnableLogging = 1

Review the generated logs for Autodiscover hop order and HTTP status codes. If add-ins interfere, Outlook.exe /safe is a quick isolation test before you burn a profile.

Step 7 — new profile vs reinstall policy

Enterprise support rule I use: one new Outlook profile before anyone suggests reinstalling Office. A new profile forces a full Autodiscover walk and clears stale 302 redirect chains cached from an ancient marketing site that once answered on /autodiscover/autodiscover.xml (yes, that happens — marketing rotates CDN, Outlook still remembers the first redirect target).

If 9 out of 10 users are clean after a new profile, roll the fix as Group Policy using the official Autodiscover exclusion keys documented under “How to control AutoDiscover via Group Policy” on Microsoft Learn, instead of hand-editing every workstation.

Bonus: on-premises Test-OutlookWebServices

If you still run hybrid with Exchange Server 2016/2019:

Test-OutlookWebServices -ClientAccessServer 'cas01.contoso.local' -MailboxCredential (Get-Credential)

This does not replace endpoint DNS tests from the user laptop, but it proves whether CAS still publishes consistent WebServicesUrl values after you moved databases or renamed namespaces.

Operational note for MSPs

Document the exact public resolver you used (dig @1.1.1.1 vs internal DNS IP) in the ticket closure notes. Half of “it came back” regressions are someone “fixing” split DNS two months later without change control.

Finally: if prompts appear only on guest Wi-Fi, inspect SSL inspection on the perimeter firewall. Some appliances re-sign only selected SNI names, which mimics a broken Autodiscover host while corporate Ethernet works fine. A quick packet capture from the laptop comparing certificate chains on-office vs at-home often ends the argument in minutes instead of days.

For regulated tenants, add a permanent monitoring probe: scheduled Test-NetConnection autodiscover.contoso.com -Port 443 from an internal bastion plus an external Azure Function hitting the same hostname — alert when the returned thumbprint changes without a matching change ticket.

Practical PowerShell: compare internal vs public resolver

$names = 'autodiscover.contoso.com','mail.contoso.com'
foreach ($n in $names) {
  '--- ' + $n
  Resolve-DnsName $n -Type A,CNAME -Server 10.0.0.1 -ErrorAction SilentlyContinue | ft -Auto
  Resolve-DnsName $n -Type A,CNAME -Server 1.1.1.1 -ErrorAction SilentlyContinue | ft -Auto
}

When the two tables differ, fix DNS before touching Outlook. When they match but prompts remain, pivot to token and CA analysis.

Version pinning note

Office Monthly Enterprise Channel can change Autodiscover client behavior faster than your runbook updates. Record the build number (File → Office Account → About Outlook) in the ticket — it saves hours when Microsoft releases a regression fix two builds later and half the fleet is mid-rollout.

Document the Outlook build, DNS resolver IPs, and SCP keyword snapshot in your CMDB when you close the incident — future you will thank present you.