Home » Exchange Server » Exchange 2013 Test-ServiceHealth Doesn't Work for Client Access Servers

Exchange 2013 Test-ServiceHealth Doesn't Work for Client Access Servers

I’m a big fan of the PowerShell test cmdlets that ship with Exchange Server, so much so that I’ve written a script that makes use of many of them to produce an Exchange Server health report.

So I am a little frustrated to discover that the Test-ServiceHealth cmdlet produces some unexpected output when run against a remote Exchange 2013 server that is installed only with the Client Access server role.

To demonstrate, here is the CAS-only server running in my test lab.

Here is the Test-ServiceHealth output if I run Test-ServiceHealth against that server.

Of course this error text stands out immediately.

There are no Microsoft Exchange 2007 server roles installed…

But a quick read of the rest of the error indicates what the problem may actually be.


It appears that my CAS (E15FSW) is proxying the test to one of the mailbox servers. When you consider the role of Client Access in Exchange 2013 as a “a thin and stateless server” that provides “proxy services” I guess that makes sense.

That said, I still have the problem of an annoying bug in my script that needs a solution. So I’ve put together this proof of concept code which I am going to incorporate into the next version of Test-ExchangeServerHealth.ps1 that uses WMI instead of the Test-ServiceHealth cmdlet to assess the health of the services on an Exchange 2013 Client Access server.

Note this is proof of concept only, you can take this code and use it however you like but it is not yet intended to be a functional script.

Here is an example of a pass and fail result.

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


  1. najwan says:

    Hi Paul I noticed the same when the running this command and MS does not mention anything about it if it works on CAS or NO.I though that I have problems in the exhcange installation as I faced issues when running the POP test connectivity from powershell using the syntax: get-clientaccessserver | test-popconnectivity.
    It returns the specified computer is not a client access server noting that clients are able to configure their profiles as POP successfully and same for IMAP.
    Can you please let me know if this occurs in exchange 2013 or it is related to something wrong in the installation or configuration of CAS.
    I appreciate your reply because rare are people who are speaking of the cmdlets deprecated in MS exhcange 2013.
    I always follow your posts and it really helped me in many situations.

    • I would expect all of the Test-* cmdlets to have issues with Exchange 2013 servers that only have the CAS role installed.

      The general recommendation is to deploy multi-role Exchange 2013 servers which seem to handle these cmdlets better.

  2. Ankush Sharma says:

    Hi Paul,
    This script was really helpful thanks for sharing. Although I have one query, I was trying to edit it according to our requirement which needs us to skip one service check from Hub Transport Role. Service Name is MSExchangeEdgeSync. Could you please suggest how to attain it We are using Exchange 2010 SP3

    • This article is about Exchange 2013. You shouldn’t need to do any of the steps in this article for Exchange 2010.

      For the MSExchangeEdgeSync service, you can just enable and start the service so that the Test-ServiceHealth cmdlet reports a successful test. Otherwise you’ll need to write some script code to ignore that service.

  3. Kashif says:


    I am getting below error while installating Exchage 2013, Can you please tell me what is this error and how ti resolve this error
    The following error was generated when “$error.Clear();
    Install-ExchangeCertificate -WebSiteName “Exchange Back End” -services “IIS, POP, IMAP” -DomainController $RoleDomainController -InstallInTrustedRootCAIfSelfSigned $true
    if ($RoleIsDatacenter -ne $true -And $RoleIsPartnerHosted -ne $true)
    Install-AuthCertificate -DomainController $RoleDomainController
    ” was run: “Could not grant Network Service access to the certificate with thumbprint 377CB9F1E6BA2BAD6BDD565A6C5266DD01D50BE9 because a cryptographic exception was thrown.”.

Leave a Reply

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