Monitoring Benefit
Outlook Anywhere — RPC over HTTP — is the predecessor to MAPI/HTTP. This test confirms that a client can still reach the mailbox over that path from the probe's location.
It matters where older Outlook clients remain in use, where a migration has not finished, or where MAPI/HTTP has been disabled for a subset of users. If your estate is entirely modern and MAPI/HTTP is enforced, this test tells you little that MAPI/HTTP Status does not — but it is worth keeping until you are certain nothing depends on it.
Why the probe version matters
Like MAPI/HTTP, Outlook Anywhere holds a connection open, so the quality of the site's path matters more than a simple reachability check would suggest. A probe at the site tests the route those clients take, including proxies and inspection devices that the ENow web server never passes through.
| Pattern | What it points at |
|---|---|
| Fails everywhere | Exchange, the namespace, or the test mailbox — or Outlook Anywhere has been disabled organisation-wide. |
| Fails from one probe only | That site's path. RPC over HTTP is often the first thing a proxy or inspection device mishandles. |
| Outlook Anywhere fails, MAPI/HTTP passes | Frequently expected rather than a fault — see below. |
The most common cause is not a fault
Microsoft has moved clients off Outlook Anywhere in favour of MAPI/HTTP, and many organisations have disabled it deliberately or had it disabled for them. If this test fails while MAPI/HTTP passes, establish whether Outlook Anywhere is still meant to be enabled before troubleshooting anything. Chasing a protocol you have intentionally retired is wasted effort, and the fix is to stop monitoring it rather than to restore it.
How do we verify the monitoring test results?
- Confirm Outlook Anywhere is enabled and expected for the organisation and for the test mailbox.
- Run the Microsoft Remote Connectivity Analyzer from that site — testconnectivity.microsoft.com, Outlook connectivity test, which covers the RPC over HTTP path.
- Check Autodiscover if this and MAPI/HTTP are both failing — see Exchange Remote Probe - Outlook - Autodiscover Status.
- Confirm the probe is reporting — see Remote Probe - Connectivity Status.
Where the settings are
Probe test accounts 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 while MAPI/HTTP passes | Check whether Outlook Anywhere is still enabled. If it has been retired deliberately, exclude this test rather than investigating it. |
| Authentication failures | Outlook Anywhere authentication settings are configured separately from other protocols. Confirm the method in use matches what the client and any intermediate proxy expect. |
| Fails from one site only | Check that site's proxy and inspection devices. RPC over HTTP is handled poorly by some appliances that pass ordinary HTTPS without trouble. |
| Connects then drops | Idle timeouts in the path. The connection is long-lived and will be cut by aggressive timeout settings. |
| Certificate errors from one site | TLS inspection presenting its own certificate. Exempt the namespace or trust the appliance certificate on the probe. |
Reference: Outlook Anywhere | Microsoft Learn
Comments
0 comments
Article is closed for comments.