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.

[PS] C:\>Get-ExchangeServer E15FSW | Select ServerRole

ServerRole : ClientAccess

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

[PS] C:\>Test-ServiceHealth -Server E15FSW
There are no Microsoft Exchange 2007 server roles installed
on E15FSW.exchange2013demo.com.
    + CategoryInfo          : InvalidArgument: (:) [Test-ServiceHealth],
NoExchangeRoleInstalledException + FullyQualifiedErrorId
: [Server=E15MB1,RequestId=d43bba01-2a19-42b1-a380-ecd19d6f271d,
TimeStamp=22/08/2013 10:41:09 AM] 9E9BF046,
Microsoft.Exchange.Monitoring.TestServiceHealth
+ PSComputerName : e15fsw.exchange2013demo.com

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.

Server=E15MB1

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.

#Proof of concept code to test service
#health on E15 CAS-only servers

[CmdletBinding()]
param (
	[Parameter( Mandatory=$false)]
	[string]$Server
)

$servicesrunning = @()
$servicesnotrunning = @()
$casservices = @(
	"IISAdmin",
	"W3Svc",
	"WinRM",
	"MSExchangeADTopology",
	"MSExchangeDiagnostics",
	"MSExchangeFrontEndTransport",
	"MSExchangeHM",
	"MSExchangeIMAP4",
	"MSExchangePOP3",
	"MSExchangeServiceHost",
	"MSExchangeUMCR"
	)

try {
	$servicestates = @(Get-WmiObject -ComputerName $server -Class Win32_Service -ErrorAction STOP | where {$casservices -icontains $_.Name} | select name,state,startmode)
}
catch
{
	Write-Warning $_.Exception.Message
	EXIT
}

Write-Verbose "$($servicestates.count) services found"

$servicesrunning = @($servicestates | Where {$_.StartMode -eq "Auto" -and $_.State -eq "Running"})
$servicesnotrunning = @($servicestates | Where {$_.Startmode -eq "Auto" -and $_.State -ne "Running"})

if ($($servicesnotrunning.Count) -gt 0)
{
	Write-Host -ForegroundColor Red "Service health check failed"
    Write-Host -ForegroundColor Red "Services not running:"
    foreach ($service in $servicesnotrunning)
    {
        Write-Host -ForegroundColor Red "- $($service.Name)"	
    }
}
else
{
	Write-Host -ForegroundColor Green "Service health check passed"
}

Here is an example of a pass and fail result.

PS C:\scripts> .\Test-E15CASServiceHealth.ps1 -Server E15FSW -Verbose
VERBOSE: 11 services found
Service health check passed

PS C:\scripts> .\Test-E15CASServiceHealth.ps1 -Server E15FSW -Verbose
VERBOSE: 11 services found
Service health check failed
Services not running:
- MSExchangeHM

[adrotate banner=”48″]

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Kashif

    Hi,

    I am getting below error while installating Exchage 2013, Can you please tell me what is this error and how ti resolve this error
    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.”.

  2. Ankush Sharma

    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

    1. Avatar photo
      Paul Cunningham

      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. najwan

    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.

    1. Avatar photo
      Paul Cunningham

      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.

  4. najwan

    hi Paul I noticed the same when running this command and MS dont mention anything ao

Leave a Reply