Sometimes you’re not at work and you suspect there is something wrong with your Exchange 2013 servers and you can’t access your environment remotely for whatever reason. Well, in some cases you can check this with just a browser.
For each Exchange protocol, there is an URL you can use to check the health. The format would be:
https://<External FQDN>/<protocol>/healthcheck.htm
If the specific protocol is working correctly, the Exchange server will respond with:
200 OK SERVER.CONTOSO.LOCAL
The server.contoso.local would be the server FQDN.
The possible protocol values are:
-
OWA for Outlook Web App
-
ECP for Exchange Control Panel (i.e. User Options in OWA)
-
OAB for Offline Address Book
-
AutoDiscover for the Autodiscover process (also something that is used by Lync clients)
-
EWS for Exchange Web Services (i.e. Mailtips, Free/Busy etc. Also used by Lync clients, Outlook for Mac etc.)
-
Microsoft-Server-ActiveSync for Exchange ActiveSync
-
RPC for Outlook Anywhere
-
MAPI for the new MAPI/HTTPS (successor to the RPC over HTTPs protocol used in Outlook Anywhere). You’ll need at least Exchange 2013 SP1.
The <webmail FQDN> is something you should know and has to be externally accessible. If you’ve chosen to use a separate FQDN for each Exchange protocol, the external FQDN is then dependent on the protocol. i.e. if you want to test ActiveSync the URL could be something like:
https://mobile.contoso.com/Microsoft-Server-ActiveSync/healthcheck.htm
While for Outlook Web App this could be something like:
https://webmail.contoso.com/owa/healthcheck.htm
So, be sure to check whether you separated each protocol per FQDN.
This is actually a health check that can be used by Load Balancers in order to check server health, or in this case even protocol health. Previously with Exchange 2010, only simple tests were possible, which didn’t always tell you if a service was behaving correctly. This is something the Managed Availability feature in Exchange 2013 does and the results are indicated in the health check response.
Please take note of some caveats:
-
The paths need to be published to the internet, some proxies (like the late TMG) can limit access based on the URL path. For instance: if your organization won’t allow OWA, then the /owa path is probably not published and this test won’t work (externally).
-
If you have multiple Exchange (CAS) servers behind a load balancer, you will only get a response from one server at a time. Depending on the load balancer configuration resubmitting the request a moment later could result in another server responding.
-
If a server has an issue, you can expect other types of responses than “200 OK” or just a timeout.
-
You do not need to authenticate.
-
You can use this tip for internal servers as well, just use the server FQDN and you’d probably have to ignore the certificate warning (if the server FQDN is not included in the certificate, which is highly probable). If you have configured split DNS, you can use the same URLs as externally
