Monitoring Benefit
The Autodiscover test verifies that a client can find out where its mailbox lives and which service URLs to use. Everything Outlook does depends on it — profile creation, free/busy, out of office, the offline address book. When Autodiscover fails, the symptoms usually appear somewhere else, which is what makes monitoring it directly worthwhile.
This is the same test as Exchange Online - Outlook Autodiscover Status, run from a remote probe rather than from the ENow web server.
Why the probe version matters
Autodiscover is the test where location matters most, because it depends heavily on DNS — and DNS is the thing most likely to differ between your data centre and a branch office. A site with its own resolvers, a split-brain zone, or a stale internal record can send clients somewhere different from where the ENow server is sent.
A probe at that site catches it. The ENow server never will.
| Pattern | What it points at |
|---|---|
| Fails everywhere, including the ENow server | The Autodiscover endpoint, its certificate, or the test account. |
| Fails from one probe only | That site's DNS or egress. Resolve the Autodiscover name from the probe itself and compare the answer. |
| Succeeds but returns unexpected URLs | The client is being pointed at the wrong place — often an old on-premises endpoint after a migration. |
How do we verify the monitoring test results?
-
Resolve the name from the probe. On the probe machine, run
Resolve-DnsName autodiscover.<yourdomain>and compare the answer against what the ENow server gets. A difference here is usually the whole answer. - Run the Microsoft Remote Connectivity Analyzer from that site — testconnectivity.microsoft.com, Outlook Autodiscover test.
- Check the certificate presented on the Autodiscover endpoint covers the name being requested. A certificate whose subject or SAN omits the Autodiscover name fails here while the mail flow itself looks healthy.
- Confirm the probe is reporting — see Remote Probe - Connectivity Status.
Where the settings are
Probe test accounts and endpoints are set under Server > Tuning Policy > Settings > Probe Configuration > Configure Probes…. Probe thresholds are separate from server-side thresholds, under Server > Monitoring Policy > Thresholds in the Remote Probes section.
Where this is shown in the console
This check appears under Exchange Remote Probes > Outlook, which you can open directly:
https://<ENow web server>:20080/MailscapeWeb/Exchange/ExchangeOutlookRemoteProbe.aspx?server=<PROBE>The probe name in the query string carries a suffix — for example LONDON-EXCHANGE rather than LONDON. You can also reach the page by selecting the probe's row under Exchange Remote Probes on the dashboard at /MailscapeWeb/Default.aspx.
Common warning or error results, and potential solutions
| Result | Potential solution |
|---|---|
| Fails from one site only | Start with DNS at that site. Compare the resolved address against a working location before looking at anything else. |
| Certificate name mismatch | The certificate on the endpoint does not cover the Autodiscover name. Check its subject alternative names. |
| Redirect loops or unexpected endpoints returned | Often a leftover on-premises Autodiscover record or SCP after a migration. Check what the record points at. |
| Fails after a domain or DNS change | Autodiscover is frequently forgotten in DNS migrations. Confirm the record still exists and resolves at every site. |
| Intermittent from one location | Check whether that site has more than one resolver and they disagree. Inconsistent answers produce intermittent failures. |
Reference: Autodiscover service | Microsoft Learn
Comments
0 comments
Article is closed for comments.