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:
"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):
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
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