Microsoft Exchange Infrastructure Monitoring with ipsonic-probe

This example pack provides a layered monitoring baseline for an existing Microsoft Exchange environment. It targets self-hosted Exchange deployments and similar environments where these protocols and endpoints are intentionally enabled. It does not assume every protocol is enabled, nor that every endpoint is reachable from the public Internet.

1. Define the topology and monitoring locations

Record the approved Exchange namespaces, load balancer VIPs, backend addresses, DNS zones, internal resolvers, and monitoring vantage points. Replace all example.com domains and 192.0.2.x documentation IPs before execution. Deploy separate checks for internal and external access if needed.

2. Choose only enabled services

Layer	YAML	What is verified	What is not verified
OWA user portal	`121-exchange-owa-portal.yaml`	HTTPS, certificate, expected response code	Login, mailbox UI, real user workflow
ECP/admin portal	`122-exchange-ecp-portal.yaml`	Endpoint reachability	Administrative sign-in or authorization
Autodiscover	`123-exchange-autodiscover.yaml`	HTTPS endpoint response	Full Autodiscover negotiation
EWS	`124-exchange-ews.yaml`	HTTPS endpoint response	EWS operation success
MAPI/HTTP	`125-exchange-mapi.yaml`	HTTPS endpoint response	Outlook connectivity
ActiveSync	`126-exchange-activesync.yaml`	HTTPS endpoint response	Device synchronization
SMTP relay	`127-exchange-smtp-relay.yaml`	TCP/25 connect	SMTP banner, STARTTLS, message delivery
SMTP submission	`128-exchange-smtp-submission.yaml`	TCP/587 connect	SMTP AUTH, STARTTLS, delivery
SMTPS (if enabled)	`129-exchange-smtps.yaml`	TCP/465 connect	TLS handshake or SMTP transaction
IMAPS (if enabled)	`130-exchange-imap-tls.yaml`	TCP/993 connect	IMAP TLS handshake, login, mailbox commands
IMAP STARTTLS (if enabled)	`131-exchange-imap-starttls.yaml`	TCP/143 connect	STARTTLS negotiation
POP3S (if enabled)	`132-exchange-pop3-tls.yaml`	TCP/995 connect	POP3 TLS handshake, login, message retrieval
POP3 STARTTLS (if enabled)	`133-exchange-pop3-starttls.yaml`	TCP/110 connect	STARTTLS negotiation
Mail routing DNS	`134-exchange-dns-mx.yaml`	MX record exists	Actual SMTP mail delivery
Autodiscover DNS	`135-exchange-dns-autodiscover.yaml`	CNAME exists	SRV-based or alternate configurations
Sender policy	`136-exchange-dns-spf.yaml`	TXT includes SPF marker	Full SPF syntax or email authentication
Backend nodes	`137-exchange-backend-https.yaml`	HTTPS reachability per backend IP	Exchange replication, database health

Important: POP3 and IMAP are often disabled by design. TCP/465 is not a universal Exchange requirement. Do not alert on services that your installation does not provide. Exchange Online and hybrid setups have different topology and responsibilities.

3. Run the probes

Install using distribution repositories only:

# Debian / Ubuntu
sudo apt-get install -y python3 python3-requests python3-yaml

# AlmaLinux / Rocky Linux
sudo dnf install -y python3 python3-requests python3-pyyaml

Execute the desired checks from the project root:

python3 ipsonic-probe.py --output nagios examples/121-exchange-owa-portal.yaml
python3 ipsonic-probe.py --output nagios examples/127-exchange-smtp-relay.yaml
python3 ipsonic-probe.py --output nagios examples/130-exchange-imap-tls.yaml
python3 ipsonic-probe.py --output nagios examples/134-exchange-dns-mx.yaml

Run individual YAML files as separate monitoring services so that a failure identifies its layer. Use your Nagios/Icinga 2/Checkmk scheduling, alert routing, and dependencies for correlation. ipsonic-probe itself does not provide a native service dependency graph or a bundled scheduler.

4. Suggested monitoring dependencies

A useful logical dependency chain is DNS resolution → network route/firewall → load balancer VIP → Exchange HTTPS frontend → Exchange backend. Mail flow additionally depends on MX records → TCP/25 reachability → SMTP service → transport queues and mail routing. For client access, OWA/EWS/MAPI/ActiveSync depend on HTTPS and certificates, while IMAP/POP3 depend on their optional services and protocol-specific TLS/authentication.

Use existing monitoring-platform dependency rules to suppress downstream alarms when an upstream component fails. This pack tests the reachable endpoints but cannot directly determine Active Directory health, Exchange database availability, transport queues, DAG replication, message tracking, spam filtering, mailbox access, or end-to-end mail flow. Those need additional Exchange-specific telemetry or synthetic protocol transactions.

5. Proxy and private CA considerations

HTTP(S) probes can use proxy.mode: environment or an explicit proxy and a private CA bundle through tls.ca_file_env. Do not route POP3, IMAP or SMTP checks through the HTTP proxy; the TCP probe connects directly. HTTP(S) advanced TLS inspection features may require a direct connection depending on proxy configuration.

6. Operational baseline and acceptance

Start with OWA, SMTP/25, MX, and whichever client protocols are actually enabled. Add Autodiscover, EWS, MAPI, ActiveSync, SPF, and backend checks as appropriate. Review the expected HTTP codes against your actual authentication and reverse-proxy behavior. A 401 or 403 can mean the endpoint is present, not that it is usable by an authenticated user. Do not interpret these checks as a complete Exchange health or security assessment.

All checks use placeholder values. Adapt service names, thresholds, DNS expectations, and response statuses before treating them as customer acceptance criteria.

Maintainer and disclaimer

Maintained by mati peterson (ipsonic@mailbox.org). Official project URL: https://ipsonic.com/probe/.

Disclaimer: This software and its examples are provided AS IS, without warranty of any kind. Use at your own risk. Review and validate configurations before production deployment.

ipsonic-probe ✦