Monitoring Benefit
The Network test is the foundation the other probe tests stand on. It confirms that the probe's location can reach the Exchange endpoints it needs, on the ports it needs, at an acceptable latency.
Its value is in what it lets you rule out. When several probe tests at one site fail together, this check tells you immediately whether you are looking at a network problem or an Exchange problem — and those go to different teams.
How to use it
Read it before the protocol tests, not after:
| Pattern | What it means |
|---|---|
| Network fails, protocol tests fail | Network problem at that site. Work this test; the others are symptoms and will clear on their own. |
| Network passes, protocol tests fail | The path is fine. The fault is in Exchange, the namespace, the certificate, or the test account — not the network. |
| Network passes but latency is raised | Everything works, slowly. Users at that site will describe Outlook as sluggish while most indicators stay green. |
| Network fails at every probe | Not a site problem. Look at what all the probes share, or at Exchange itself. |
How do we verify the monitoring test results?
Run these on the probe machine itself — that is the whole point. The same commands from the ENow web server test a different path and will often succeed while the probe fails.
Confirm the endpoint resolves, and to what:
Resolve-DnsName <exchange namespace>Confirm the port is open and measure the round trip:
Test-NetConnection -ComputerName <exchange namespace> -Port 443 -InformationLevel DetailedTrace the path, which is what identifies where latency is being introduced:
Test-NetConnection -ComputerName <exchange namespace> -TraceRouteCompare each result against the same command run from a probe at a healthy site. A difference in the resolved address is usually the entire answer.
Where the settings are
Endpoints and ports for probe testing are configured under Server > Tuning Policy > Settings > Probe Configuration > Configure Probes…. Latency thresholds are set under Server > Monitoring Policy > Thresholds in the Remote Probes section, and are held separately from the server-side values.
Set latency thresholds per site where you can. A branch on a satellite link will never match a data centre, and holding both to the same figure produces either permanent alerts at one site or no useful alerting at the other.
Where this is shown in the console
This check appears under Exchange Remote Probes > Network, which you can open directly:
https://<ENow web server>:20080/MailscapeWeb/Exchange/ExchangeNetworkRemoteProbeSelection.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 |
|---|---|
| A port shows closed from one site | Firewall or egress policy at that location. Confirm outbound 443 to the Exchange namespace is permitted from the probe's subnet. |
| The namespace resolves to a different address than elsewhere | Split-brain DNS or a stale local record. This also breaks Autodiscover, so expect that test to fail with it. |
| Latency raised at one site only | Trace the route from that probe and compare against a healthy site. Look for the hop where the time jumps. |
| Latency raised at every site at the same time | Not the sites. Look at a shared upstream link, or at Exchange. |
| Latency that climbs through the working day | Contention rather than a fault — the link is sized for less than it now carries. |
| Everything passes but users still complain | Reachability is not experience. Check Collaboration, which exercises real mailbox operations rather than connectivity. |
Comments
0 comments
Article is closed for comments.