⌚ About 2 min read

Microsoft 365. Intermediate. 15-30 min

This BAOI guide provides a structured method for cleaning an old auto-Catch exchange without multiplying unnecessary changes.

Avant de commencer : adaptez toujours les commandes et manipulations à votre environnement. Sur un système de production, prévoyez une backup ou un retour arrière lorsque l’action peut modifier la configuration.

Étapes à suivre

1

Set perimeter

Identify the equipment, service, affected users and start time.
2

Collect Elements

Record the exact messages, logs and useful settings.
3

Test methodically

Start with the basic dependencies before the application components.
4

Apply correction

Change only the identified parameter or component.
5

Validate

Rewrite the full scenario and document the result.

À retenir

Keep the initial values for a backwards.
Avoid multiple simultaneous changes.
Compare with a functional configuration when possible.

Technical deep dive

Outlook / Autodiscover: identify the configuration source actually used

Technical checkpoints

Autodiscover can use AD SCP, DNS, HTTPS redirects and Microsoft 365 services depending on scenario; a stale on-prem endpoint can remain influential in some environments.
Outlook stuck loading a profile can come from profile/MAPI, OST, add-ins or authentication, not only Autodiscover.
Tests should keep the URL and result of each step to avoid fixing the wrong Autodiscover source.

Client diagnosis

Test Autodiscover first, then create a fresh profile only if network/configuration is healthy.

Test-OutlookWebServices / Microsoft Remote Connectivity Analyzer
Outlook /safe

Topic-specific pitfalls

Removing an SCP or DNS record without an inventory can break remaining on-prem/hybrid clients.
Deleting OST before ruling out a server-side problem can trigger unnecessary heavy resynchronization.

How to validate

The client retrieves expected endpoints and authentication succeeds without stale URLs.
A representative profile opens the mailbox and remains stable after restart.

Operational context

When Outlook still tries to reach an old Exchange server, trace Autodiscover from DNS and Active Directory through to the client before deleting cached profiles or registry values. The objective is to remove the obsolete authority, not only hide one client symptom.

Step-by-step checks

Run Outlook Autodiscover tests and identify every URL returned for the affected mailbox.
Check public and internal Autodiscover DNS records and compare them with the intended Microsoft 365 or Exchange endpoint.
If on-premises Exchange remains or was recently decommissioned, inspect the Service Connection Point and confirm no old server still publishes an Autodiscover URI.
Only after server-side discovery is correct, clear stale Outlook profile/cache data on a test workstation and retest.

Useful verification commands

Use commands only on systems you administer and capture the read-only output before making a configuration change.

Resolve-DnsName autodiscover.example.com

Get-ClientAccessService | Select-Object Name,AutoDiscoverServiceInternalUri

How to validate the result

A fresh Outlook profile and an existing corrected profile must both resolve Autodiscover to the intended service without contacting the retired Exchange host.

Evidence to keep

Keep the tested mailbox, DNS answers, returned Autodiscover URLs, SCP values and a timestamped before/after Outlook test result.

Frequently asked question

Should I delete the Outlook profile first?

No. Correct DNS/SCP authority first. Recreating a profile can temporarily mask a server-side Autodiscover error and makes the root cause harder to prove.

Related BAOI resources: IT tools · procedures · IT dictionary.