Outlook still tries to, use an old infrastructure.
Probable causes
- SCP
- DNS
- cache profile.
Verifications.
- Limit the impact. — Identify whether an endpoint, service, or whole site is affected.
- Collect evidence. — Keep the exact error message, timestamp, and associated logs.
- Test the simplest hypothesis first. — Compare the affected system with a known-good path.
- Correct the confirmed cause and validate the result. — Apply one controlled change at a time and retest.
Solutions.
- Correct the confirmed cause rather than the symptom.
- Document the change and its result.
- Establish monitoring if the fault can recur.
When to escalate?
Escalate if the impact expands, data are at risk, or remediation requires an irreversible change.
Autodiscover source focus
When Outlook or another Exchange client discovers a retired server, locate the exact discovery source instead of changing DNS blindly. Internal Active Directory clients and external clients can obtain Autodiscover information from different paths.
What to verify
- Check public and internal Autodiscover DNS records and confirm they resolve to the current service.
- In on-premises or hybrid environments, inspect Service Connection Point values that may still reference the old Exchange server.
- Review reverse proxies, load balancers and migration-era redirects that can return a legacy hostname.
- Test with a new profile or a clean client to separate server-side discovery from cached profile information.
Resolution path
Remove or update only the stale discovery source and allow directory or DNS changes to propagate. Do not keep the retired server online solely to satisfy an obsolete Autodiscover reference.
Validation
Run a fresh Autodiscover test and confirm every returned endpoint uses the intended Exchange or Microsoft 365 service before retesting the user profile.