Reliably Monitoring Exchange Server for DNS Failover or Load Balancing

On occasion we receive a request seeking assistance creating monitors to determine the availability of Microsoft Exchange, such as Internet-facing ActiveSync or OWA. After helping many customers, we have determined what works well, and what doesn’t work at all. Here are our tried and true suggestions for reliably monitoring your Exchange environment.

Exchange 2013, 2016 and 2019

With the release of Microsoft Exchange 2013, monitoring became easier and highly reliable. If OWA is exposed, there is a special health check page that you can use. Here is the type of monitor we highly recommend creating.

1. Create an HTTP-CONTENT monitor
2. On the Standard Parameters tab:
   1. Check the “secure” checkbox and ensure the port is also set to 443
   2. Set the “Custom Header” value to be the domain for OWA. For example, “webmail.example.com” or “mail.example.com”
3. On the Special Parameters tab:
   1. Adjust the Send String from being “GET /” to be “GET /owa/healthcheck.htm”
   2. In the Receive String box enter “200 OK” (without the quotes)

This monitor will load a special page created just for this purpose that spits out the words “200 OK” when all of the behind-the-scenes checks pass the test. This test is also very light and does not put any significant load on the server, at least as far as we can tell.

Exchange 2010

Exchange 2010 has always been a bear to monitor, and if you place it behind a Threat Management Gateway it acts even stranger. We hope you’re not using this version that is no longer supported, but if you are, here is a reliable way of monitoring OWA to detect availability.

1. Create an HTTP monitor
2. On the Standard Parameters tab:
   1. Check the “secure” checkbox and ensure the port is also set to 443
   2. Set the “Custom Header” value to be the domain for OWA. For example, “webmail.example.com” or “mail.example.com”
3. On the Special Parameters tab:
   1. Adjust the HTTP Request from being “HEAD /” to be “HEAD /owa”. This forces it to look in the OWA directory.
   2. In the Response Codes, add 301 and 302 as acceptable

This will properly detect the redirect that OWA and IIS generates and can be safely used to ensure that your server is up without creating any significant load.