Home » Exchange Server » Testing Exchange Server 2013 Client Access Server Health with PowerShell

Testing Exchange Server 2013 Client Access Server Health with PowerShell

One of the interesting features of Exchange Server 2013 is the way that Managed Availability communicates the health of individual Client Access protocols (eg OWA, ActiveSync, EWS) by rendering a healthcheck.htm file in each CAS virtual directory. When the protocol is healthy you can see it yourself by navigating to a URL such as https://mail.exchangeserverpro.net/owa/healthcheck.htm.

exchange-2013-healthcheck

When the protocol is unhealthy the page is unavailable, and instead of the HTTP 200 result above you will see a “Page not found” or HTTP 404 result instead.

Note: there is no healthcheck.htm file in the file system of the server itself.

The healthcheck.htm file is used by the health monitors/probes of various load-balancers and other monitoring systems as a quick and effective way of determining protocol health. For example, if a load-balancer is distributing traffic across four available Exchange 2013 servers and detects that one of them has an unhealthy OWA protocol, it will stop sending OWA traffic to that server.

Recently I’ve worked on a number of customer support cases for Exchange Server 2013 where the problems they were experiencing were due to one or more of handful of common configuration problems:

  • Client Access namespace not well designed or not configured on all virtual directories correctly
  • SSL certificates not provisioned correctly
  • Load-balancer health monitors/probes failing but not alerting for technicians to investigate

These types of issues are so common that I have been working on integrating them into the next version of my Exchange Server health check script, which is going to be a significant overhaul of the previous version.

In this article I want to share with you some PowerShell that can be used to check your Client Access server health for some of the issues above. Here’s a breakdown of how the script works.

  • The script collects the various CAS URLs for each site where Exchange is deployed. If multiple URLs are detected for a given service a warning is thrown.
  • The script makes use of Invoke-WebRequest to test the Client Access namespaces. There are three possible results tested for so far – “OK” means the healthcheck.htm request returned a HTTP 200 as shown above, “SSL Error” means Invoke-WebRequest failed SSL negotiation, and “Error” is for anything else requiring further investigation.
  • Next, the script uses System.Net.WebClient to test each protocol on each individual CAS in the site. This will identify specific servers having problems that may not be evident because a load-balancer or round robin DNS is masking the issues from clients. Using System.Net.WebClient helped to overcome SSL trust issues for the per-server checks, and I could not have worked it out if I hadn’t found this blog post by Bhargav Shukla explaining how to handle this scenario.

Right now the script only outputs to the PowerShell console. I am planning to add HTML and email reporting as well, but this may come later as the script is rolled into the next major version of the health check script.

You can download the script from Github. Writing scripts that work for as many scenarios as possible is a challenge, so any questions or bug reports are welcome on Github or the comments below.

Simply run the script on any server or workstation that has the Exchange Management Shell available.

Here’s a few examples of the output you can expect. In this first example the Exchange servers are deployed across two sites. No duplicate CAS URLs were detected, and the per-server health checks were also clean.

exchange-2013-cashealth-01

In comparison, here is an environment with incorrectly configured CAS namespaces, some SSL errors, and what appears to be an unhealthy ActiveSync protocol.

exchange-2013-cashealth-02

As I mentioned earlier any questions or bug reports are welcome, either in the comments below or on Github. I’m hoping that this script can be improved with feedback and become a valuable resource for the community.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server

10 comments

  1. Lauri says:

    Hi,

    I had couple of days ago problem with imap on second cas server and for some reason imapproxy component was inactive. Would it be possible to add also get-servercomponentstate to health check?

    Regards
    Lauri

    • ThongDoan says:

      Yes , U can Use “get-servercomponentstate” in Server CAS and Then U can Use “set-servercomponentstate” for Imap Proxy

  2. David Hewitt says:

    Great script, as Arun said – would be great to have this formated to HTML and the option to send via email…like with the wonderful ExchangeServerHealth script of yours 🙂

  3. Mr. B says:

    I think it would be fantastic if you could combine this script with the Test-ExchangeServerHealth script that you created. I feel that this type of combined script would be just about cover everything.

  4. Mohammed says:

    Hello,
    I thank you for the wonderful contribution and excellent work you do on the site . I ask you kindly help for a problem that I have in running the script. all outcomes are OK except the rpc healthcheck.htm that ERROR . depends on what?
    thank you so much

  5. clementine says:

    hi Paul

    I have a test lab for ex2016 in my home pc ,and I want to try issuing an external certificate than requesting the certificate from the certificate authority from my test domain controller ,is there any website that give me trial certificate
    also I want to try split dns configuration ,how can I host external records for my test servers,is there any trial domain hosting service in the internet ,sorry i know it’s a silly question but I just want to know if i can do that or not
    i

    • Most certificate providers will issue trial certificates, but they aren’t trusted. There are very cheap providers out there, or you can set up a free certificate using LetsEncrypt (there’s documentation out there for it, it’s not as simple as using a traditional cert provider, but it’s free!).

      External DNS hosting is usually provided free with domain registration. Or you can use a cheap DNS solution like Amazon Route 53.

Leave a Reply

Your email address will not be published. Required fields are marked *