Exchange 2016: HealthCheck URLs for load balancers

The status of individual Exchange protocols can be easily determined via a URL. This is particularly interesting for load balancers, as it is easy to determine whether the protocol is available on the respective server. Querying the respective URLs is more meaningful than simply checking whether the port on the Exchange server is still open, but is not as load-intensive as logging on to a mailbox.

The Exchange HealthCheck URLs allow load balancers to determine whether connections should continue to be sent to the server or whether the server should be removed from the pool.

The HealthCheck pages themselves offer little information:

Load balancer

"200 OK" can be used as an indication for the load balancer to continue sending connections to the server. For other status codes, the load balancer should remove the server from the pool. Elaborate tests of load balancers with login to a mailbox etc. can therefore be omitted and do not cause any additional load on the Exchange servers.

The URLs for Exchange 2016 and Exchange 2013 SP1 are as follows:

  • https:///owa/healthcheck.htm
  • https:///ecp/healthcheck.htm
  • https:///rpc/healthcheck.htm
  • https:///mapi/healthcheck.htm
  • https:///ews/healthcheck.htm
  • https:///oab/healthcheck.htm
  • https:///Microsoft-Server-ActiveSync/healthcheck.htm
  • https:///autodiscover/healthcheck.htm

The HealthCheck URLs can also be helpful for error diagnosis, for example if the ComponentStates are not set to the "Active" status again after an update.

With this small PowerShell script, the HealthCheck URLs can be queried:

$ExchangeServer = "EXSRV1.frankysweb.local"
#$AllProtocols = [System.Net.SecurityProtocolType]'Tls11,Tls12'
#[System.Net.ServicePointManager]::SecurityProtocol = $AllProtocols
$OWA = "https://$ExchangeServer/owa/healthcheck.htm"
$ECP = "https://$ExchangeServer/ecp/healthcheck.htm"
$RPC = "https://$ExchangeServer/rpc/healthcheck.htm"
$EWS = "https://$ExchangeServer/ews/healthcheck.htm"
$MAPI = "https://$ExchangeServer/mapi/healthcheck.htm"
$OAB = "https://$ExchangeServer/oab/healthcheck.htm"
$EAS = "https://$ExchangeServer/Microsoft-Server-ActiveSync/healthcheck.htm"
$AutoDiscover = "https://$ExchangeServer/autodiscover/healthcheck.htm"
$OWAResponse = (Invoke-WebRequest -Uri $OWA).RawContent
if ($OWAResponse -match "200 OK
")
{
write-host "OWA: OK" -foregroundcolor green
}
else
{
write-host "OWA: Error" -foregroundcolor red
}
$ECPResponse = (Invoke-WebRequest -Uri $ECP).RawContent
if ($ECPResponse -match "200 OK
")
{
write-host "ECP: OK" -foregroundcolor green
}
else
{
write-host "ECP: Error" -foregroundcolor red
}
$RPCResponse = (Invoke-WebRequest -Uri $RPC).RawContent
if ($RPCResponse -match "200 OK
")
{
write-host "RPC: OK" -foregroundcolor green
}
else
{
write-host "RPC: Error" -foregroundcolor red
}
$EWSResponse = (Invoke-WebRequest -Uri $EWS).RawContent
if ($EWSResponse -match "200 OK
")
{
write-host "EWS: OK" -foregroundcolor green
}
else
{
write-host "EWS: Error" -foregroundcolor red
}
$MAPIResponse = (Invoke-WebRequest -Uri $MAPI).RawContent
if ($MAPIResponse -match "200 OK
")
{
write-host "MAPI: OK" -foregroundcolor green
}
else
{
write-host "MAPI: Error" -foregroundcolor red
}
$OABResponse = (Invoke-WebRequest -Uri $OAB).RawContent
if ($OABResponse -match "200 OK
")
{
write-host "OAB: OK" -foregroundcolor green
}
else
{
write-host "OAB: Error" -foregroundcolor red
}
$EASResponse = (Invoke-WebRequest -Uri $EAS).RawContent
if ($EASResponse -match "200 OK
")
{
write-host "EAS: OK" -foregroundcolor green
}
else
{
write-host "EAS: Error" -foregroundcolor red
}
$AutodiscoverResponse = (Invoke-WebRequest -Uri $Autodiscover).RawContent
if ($AutodiscoverResponse -match "200 OK
")
{
write-host "Autodiscover: OK" -foregroundcolor green
}
else
{
write-host "Autodiscover: Error" -foregroundcolor red
}

The output of the script is simple and can therefore only be used for initial diagnosis (if at all):

image

2 thoughts on “Exchange 2016: HealthCheck URLs für Loadbalancer”

  1. Ich erhalte beim Aufruf des Invoke-WebRequest folgende Fehlermeldung:

    Invoke-WebRequest : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.
    At line:12 char:17
    + $OWAResponse = (Invoke-WebRequest -Uri $OWA).RawContent
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebException
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand
    OWA: Fehler

    Any idea?

    Kann es am TLS liegen?
    [Net.ServicePointManager]::SecurityProtocol
    Tls, Tls11, Tls12, Tls13

    Reply
  2. Hallo Franky, das schöne Script hat bei mir zu Hause 3 Fehler aufgeführt. EWS, MAPI und Autodiscover. Habe mal ein Get-ServerHealth meinserver.domaene.de | ?{$_.HealthSetName -eq „EWS“} ausgeführt und Fehler im EWSCtpMonitor angezeigt bekommen. Mit einem Invoke-MonitoringProbe habe ich dann mir anzeigen lassen wo der Fehler ist. Komisch ist nur das die gleiche Einrichtung eines anderen Exchange-Servers in der Firma ohne Fehler funktioniert hat. Habe schon diverse Parameter im IIS verglichen ohne abweichungen zu sehen…..vielleicht hat jemand das Problem gelöst… Rückmeldung 401 hat doch mit dem IIS zu tun.

    Hier der Auszug:

    EwsUrl=https://localhost/ews/exchange.asmx
    UserName/Password=HealthMailbox………@MeineDomaene.de/:XIR6E7FO;)ng)tLb2
    /y!fSuAKfLKI%{[r77cp$6oAmr]ch+b*SwC3ZH^Nd9=X=_jTZaoK6m2V&Z!3F|MzT%8Tf[Tn^Ei6vZ(RgSyJ9S^e[==d%iT+G=
    %n.TG(;SbxQ)
    AuthMethod=Negotiate
    GetFolder (Attempt #0) Status=The request failed. Der Remoteserver hat einen Fehler
    zurückgegeben: (401) Nicht autorisiert.
    GetFolder (Attempt #0) Latency=141,1585
    (Attempt #0) X-FEServer=MeinServer
    GetFolder (Attempt #1) Status=The request failed. Der Remoteserver hat einen Fehler
    zurückgegeben: (401) Nicht autorisiert.
    GetFolder (Attempt #1) Latency=46,8636
    (Attempt #1) X-FEServer=MeinServer

    bei Microsoft.Exchange.Monitoring.ActiveMonitoring.Ews.Probes.EWSCommon.RetrySoapActionAndThrow
    (Action operation, String soapAction, ExchangeServiceBase service, CancellationToken
    cancellationToken, Boolean trackLatency)
    bei Microsoft.Exchange.Monitoring.ActiveMonitoring.Ews.Probes.EWSGenericProbeCommon.PerformEWSO
    peration(ExchangeService service, String operation, Boolean trackLatency, CancellationToken
    cancellationToken)
    bei Microsoft.Exchange.Monitoring.ActiveMonitoring.Ews.Probes.EWSGenericProbeCommon.ExecuteEWSC
    all(String endPoint, String operation, Boolean verifyAffinity, CancellationToken
    cancellationToken, Boolean trackLatency)
    bei Microsoft.Exchange.Monitoring.ActiveMonitoring.Ews.Probes.EWSGenericProbeCommon.DoWorkInter
    nal(CancellationToken cancellationToken)
    Exception : System.Exception: System.Exception: System.Exception:
    >>> PRIMARY ENDPOINT VERIFICATION

    Reply

Leave a Comment