Monitoring Benefit
Custom URL monitoring checks web addresses you define yourself, from the remote probe's location. It exists because no monitoring product ships with a test for the things specific to your organisation — an intranet page, a line-of-business application, a vendor portal, an OWA vanity address, a load balancer health endpoint.
The probe requests each URL you configure and reports whether it responded, and how quickly.
Why the probe version matters
This test is arguably more valuable from a probe than from the ENow web server, because the URLs people add are usually internal, and internal resources are exactly what differ by location. A site with its own DNS, its own proxy, or a firewall policy that does not match head office can fail to reach an intranet application that works perfectly everywhere else.
Where the same URL is monitored from several probes, the comparison localises the fault immediately:
| Pattern | What it points at |
|---|---|
| Fails from every probe and the ENow server | The target itself is down or has changed. |
| Fails from one probe only | That site's DNS, proxy, routing or firewall. |
| Fails only from external probes | An internal-only resource. Check whether it is meant to be reachable from there at all before treating it as a fault. |
Configuring the URLs
URLs are defined in the ENow Admin Console. For probe monitoring, they are set alongside the other probe settings under Server > Tuning Policy > Settings > Probe Configuration > Configure Probes…, and thresholds are held under Server > Monitoring Policy > Thresholds in the Remote Probes section.
Two things are worth getting right when you add a URL:
- Point at something meaningful. A URL that returns a page whether or not the application behind it is working will report green through an outage. A health-check endpoint, or a page that genuinely exercises the application, is worth far more than a landing page.
- Decide whether every probe should test it. Monitoring an internal-only URL from an external probe produces a permanent red indicator that trains people to ignore the dashboard.
How do we verify the monitoring test results?
Test from the probe machine itself, not from the ENow web server — that is the path in question. On the probe:
Invoke-WebRequest -Uri "<the configured URL>" -UseBasicParsing | Select-Object StatusCode, StatusDescriptionIf that fails, work down the stack:
Resolve-DnsName <host>
Test-NetConnection -ComputerName <host> -Port 443 -InformationLevel DetailedThen open the same URL in a browser on a workstation at that site. A URL that works in a browser but fails from the probe usually means the probe's service account is being challenged for authentication, or the browser is using a proxy the probe is not.
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 |
|---|---|
| Works in a browser, fails from the probe | Usually authentication or proxy. A page requiring sign-in returns a challenge to the probe rather than content. Point the check at an endpoint that does not require authentication. |
| Certificate errors from one site | TLS inspection presenting its own certificate, or an internal certificate authority the probe does not trust. Install the internal CA on the probe, or exempt the host. |
| Intermittent failures | Often one unhealthy node behind a load balancer. Test the individual nodes directly rather than the shared name. |
| Fails immediately after a URL is added | Check the URL exactly as entered, including scheme and any port. A missing https:// is the most common cause. |
| Returns success but the application is broken | The URL is not exercising the application. Repoint it at a health endpoint or a page that depends on the back end. |
| Permanently red from external probes only | An internal-only resource being tested from outside. Remove it from those probes rather than leaving a known-red indicator on the dashboard. |
Comments
0 comments
Article is closed for comments.