When it comes to monitoring Exchange, there are multiple choices, involving products that can monitor every aspect of the platform.
However sometimes it is useful to have a quick overview of whether the Exchange services are available, and with the increasing dependence on mobile working, whether they are available from the outside world.
Fortunately, Exchange 2013 and higher provides a built in mechanism that allows you to build a quick and easy overview of Exchange using a free monitoring service.
The External Service
For the purposes of this article, we are using Uptime Robot https://uptimerobot.com/
. This provides a five minute check for up to fifty checks, and also provides a publicly available status page. That is useful to distribute to end users to check whether Exchange is available or not.
The Exchange Mechanism
Introduced with Exchange 2013, each of the core Exchange web based services has a health check page. This can be checked with no authentication required and will confirm if the service is working or not. Primarily designed for use with load balancers, so they can check if the server is available, it is also useful for the purpose of monitoring.
If you browse to the following URL, then you will see what I mean: https://host.example.com/owa/healthcheck.htm (where host.example.com is the host name used by your Exchange server).
You should see something like this:
The full list of URLs that can be checked in that way are:
- Outlook Anywhere (aka RPC over HTTP): /rpc/healthcheck.htm
- MAPI/HTTP: /mapi/healthcheck.htm
- Outlook Web App (aka Outlook on the web): /owa/healthcheck.htm
- Exchange Control Panel: /ecp/healthcheck.htm
- Exchange ActiveSync: /Microsoft-Server-ActiveSync/healthcheck.htm
- Exchange Web Services: /ews/healthcheck.htm
- Offline Address Book: /oab/healthcheck.htm
- AutoDiscover: /Autodiscover/healthcheck.htm
Setting up the Checks
The type of monitor you want is "Keyword". Enter a friendly name for the monitor - this is what will be seen by anyone browsing to the public status page.
For the URL, use your public URL, in the format above.
For the keyword, use the name of the server as it appear when you browse to the server. In most cases this will be the server name in all upper case. That the name doesn't resolve externally doesn't matter. You need to change it to "Keyword NOT exists".
You can then add an alert contact. An external email address would be a good option here, but there is also an App available.
Repeat for all of the URLs listed above, until you get a list like this:
I have added in a check on the SMTP port as well. If you publish IMAP/POP3 then add those ports too.
That is all there is to it. If you stop the IIS services then you will get a screen like this:
Within the Uptime Robot site you can then create a public status site - which uses a CNAME on your domain to point to a site on their server - secured with an SSL certificate by default.
This is a link to a screenshot of the status site for the above checks:
This URL can be included in any pre-populated bookmarks that are pushed to users - including on phones using your MDM product, so end users can check whether Exchange is available and whether it has been down earlier.
Furthermore, as it is an externally hosted service it also can give you a quick overview from inside the office if things are working correctly. Just remember to add the same internal CNAME entry if you are using the same domain internally and externally via split DNS.
What if you are behind a load balancer already?
In that case, give each server a unique URL (which is good practise anyway) and then configure Uptime Robot to connect to it directly. The IP addresses for the monitors are on their web site:
A similar practise would allow you to monitor Exchange if behind a device in a DMZ.
The SMTP Port Monitor doesn't confirm it is working?
Indeed that is the case - Transport can often stop accepting emails, but will still have the port open. For proper testing of SMTP traffic, you need to use a round trip mail monitor. https://www.everycloudtech.com/free-mail-flow-monitor
. That will alert you as the administrator directly if mail flow stops for whatever reason. Again use an external email account, rather than one on Exchange.
Now starting to see more implementations of Windows 2016 and Exchange 2016, so odd issues are starting to come to light.
One that I have seen a few times is a problem with Macs connecting to EWS on the 2016 versions of Exchange and Windows.
Going through the logs, there are 401 errors (unauthorised), yet the same credentials work with OWA.
Further troubleshooting with the web server and a hint on an Apple forum suggested that Windows 2016 was using HTTPS 2 by default and that the Mac was having some problems working with that for authentication.
The fix was to downgrade to HTTP 1.1.
New DWORD values
Set both to a value of 0.
The first one is for HTTP, the second for HTTPS. I set both, even though in most cases only HTTPS is allowed to the server and being used.
Reboot the server (restarting the IIS services does not appear to work).
Here is the registry value content to create a reg file for easy installation:
Windows Registry Editor Version 5.00
From an operational point of view, I cannot see any loss of functionality. OWA is designed to work with Windows 2012 R2 which still uses HTTP 1.1. In very large environments you might see a small performance hit because of the loss of the optimisations provided by HTTP 2, but most systems will not see anything.