Check out this blog post from Microsoft first. Mine’s mostly based on that but tailored to my specific situation.
We have a CAS server that’s purely for internal admin ECP functions. Managed Availability was running some ActiveSync tests on it and failing (because they don’t exist) with errors like these in SCOM:
|
1 2 3 4 5 6 7 8 |
ActiveSync is failing on ClientAccess server XXXXX. Incident start time: 7/29/2018 1:54:55 PM Last failed result: Failing Component - EAS Failure Reason - Unknown Reason: 503 <snip> |
So my mission, which I’ve chosen to accept (I saw “Mission Impossible: Fallout” this weekend!) is to disable this. :)
Managed Availability has the concept of health sets. From this page which lists all the health sets in Exchange 2013:
In Managed Availability, each component in Exchange 2013 monitors itself using probes, monitors and responders. Each Exchange 2013 component that implements Managed Availability is referred to as a health set.
So what are the unhealthy health sets on my server?
|
1 |
Get-HealthReport -Identity <server name> | ?{ $_.AlertValue -ne "Healthy" } |
The result of this in my case are the following:
|
1 2 3 4 5 6 7 |
Server State HealthSet AlertValue LastTransitionTime MonitorCount ------ ----- --------- ---------- ------------------ ------------ <server> NotApplicable ActiveSync Unhealthy 7/29/2018 2:24:5... 2 <server> Offline ActiveSync.Proxy Unhealthy 4/24/2018 8:55:3... 1 <server> Offline EWS.Proxy Unhealthy 4/24/2018 8:55:4... 1 <server> Offline OAB.Proxy Unhealthy 4/24/2018 8:56:2... 1 <server> NotApplicable EWS Unhealthy 4/25/2018 12:55:... 3 |
So how do I find which monitors in these health sets are failing? The following cmdlet can help:
|
1 |
Get-ServerHealth <server name> |
I’ll just pipe both cmdlets to get a list of monitors across all unhealthy health sets:
|
1 |
Get-HealthReport -Identity <server name> | ?{ $_.AlertValue -ne "Healthy" } | %{ Get-ServerHealth -Identity <server name> -HealthSet $_.HealthSet } |
In my case I get:
|
1 2 3 4 5 6 7 8 9 10 |
Server State Name TargetResource HealthSetName AlertValue ServerComponent ------ ----- ---- -------------- ------------- ---------- --------------- <server> NotApplicable ActiveSyncCTPMonitor ActiveSync ActiveSync Unhealthy None <server> NotApplicable RequestsQueuedGt500Monitor MSExchangeSyncAppPool ActiveSync Healthy None <server> Offline ActiveSyncProxyTestMonitor MSExchangeSyncAppPool ActiveSync.Proxy Unhealthy ActiveSyncProxy <server> Offline EWSProxyTestMonitor MSExchangeServicesAppPool EWS.Proxy Unhealthy EwsProxy <server> Offline OABProxyTestMonitor MSExchangeOABAppPool OAB.Proxy Unhealthy OabProxy <server> NotApplicable EWSCtpMonitor <redacted> EWS Unhealthy None <server> NotApplicable MaintenanceFailureMonitor.EWS EWS Healthy None <server> NotApplicable MaintenanceTimeoutMonitor.EWS EWS Healthy None |
Should probably have filtered to just the unhealthy monitors:
|
1 |
Get-HealthReport -Identity <server name> | ?{ $_.AlertValue -ne "Healthy" } | %{ Get-ServerHealth -Identity <server name> -HealthSet $_.HealthSet } | ?{ $_.AlertValue -ne "Healthy" } |
Update: Re-reading this later, I realize this is all complicate and wrong. All I really need to do is Get-ServerHealth -Identity <server name>. I don’t need to loop over each health set.
Anyways, the SCOM error referred to an EAS component, but I don’t see anything with that name. ActiveSyncProxy is probably the one it was referring to?
As an aside, if I want to see the components of a health set (i.e. the monitors, probes, responders) I can do the following:
|
1 |
Get-MonitoringItemIdentity -Identity <health set name> -Server <server name> | ft Identity,ItemType,TargetResource -AutoSize |
In the case of the ActiveSync.Proxy health set (which has the ActiveSyncProxy component) I can see:
|
1 2 3 4 5 6 7 8 |
Identity ItemType TargetResource -------- -------- -------------- ActiveSync.Proxy\ActiveSyncProxyTestProbe\MSExchangeSyncAppPool Probe MSExchangeSyncAppPool ActiveSync.Proxy\ActiveSyncProxyTestMonitor\MSExchangeSyncAppPool Monitor MSExchangeSyncAppPool ActiveSync.Proxy\ActiveSyncProxyTestRecycleAppPool\MSExchangeSyncAppPool Responder MSExchangeSyncAppPool ActiveSync.Proxy\ActiveSyncProxyTestOffline\MSExchangeSyncAppPool Responder MSExchangeSyncAppPool ActiveSync.Proxy\ActiveSyncProxyTestOfflineFailedEscalate\MSExchangeSyncAppPool Responder MSExchangeSyncAppPool ActiveSync.Proxy\ActiveSyncProxyTestEscalate\MSExchangeSyncAppPool Responder MSExchangeSyncAppPool |
Note that the ActiveSyncProxyTestMonitor monitor is what was showing as unhealthy earlier.
To disable a monitor I need to use the Add-ServerMonitoringOverride cmdlet. This is of the format:
|
1 |
Add-ServerMonitoringOverride -Server <server name> -Identity <HealthSet>\<MonitoringItemName>[\<TargetResource>] -ItemType <Probe | Monitor | Responder | Maintenance> -PropertyName Enabled -PropertyValue 0 |
In my case, to disable ActiveSync.Proxy (health set) ActiveSyncProxyTestMonitor (monitoring item – you can see this in the list of unhealthy monitors as well as in the list above) I do:
|
1 |
Add-ServerMonitoringOverride -Server <server name> -Identity ActiveSync.Proxy\ActiveSyncProxyTestMonitor -ItemType Monitor -PropertyName Enabled -PropertyValue 0 |
That’s it. Wait a while and now it will appear as disabled.
|
1 2 3 4 5 6 7 8 9 |
PS> Get-HealthReport -Identity <server> | ?{ $_.alertvalue -ne "Healthy" } | %{ Get-ServerHealth -Identity <server> -HealthSet $_.HealthSet } | ?{ $_.AlertValue -ne "Healthy" } | ft -AutoSize Server State Name TargetResource HealthSetName AlertValue ServerComponent ------ ----- ---- -------------- ------------- ---------- --------------- <server> NotApplicable ActiveSyncCTPMonitor ActiveSync ActiveSync Unhealthy None <server> Offline ActiveSyncProxyTestMonitor MSExchangeSyncAppPool ActiveSync.Proxy Disabled ActiveSyncProxy <server> Offline EWSProxyTestMonitor MSExchangeServicesAppPool EWS.Proxy Unhealthy EwsProxy <server> Offline OABProxyTestMonitor MSExchangeOABAppPool OAB.Proxy Unhealthy OabProxy <server> NotApplicable EWSCtpMonitor <redacted> EWS Unhealthy None |
Next thing is how do I find out why the ActiveSync health set is unhealthy? Let’s take a look at the probes in that:
|
1 2 3 4 5 6 7 8 9 |
PS>Get-MonitoringItemIdentity -Identity "ActiveSync" -Server ca1exchangeecp | ft Identity,ItemType,TargetResource -autosize Identity ItemType TargetResource -------- -------- -------------- ActiveSync\ActiveSyncCTPProbe\MSExchangeSyncAppPool Probe MSExchangeSyncAppPool ActiveSync\ActiveSyncCTPMonitor\ActiveSync Monitor ActiveSync ActiveSync\RequestsQueuedGt500Monitor\MSExchangeSyncAppPool Monitor MSExchangeSyncAppPool ActiveSync\ActiveSyncCTPEscalate\ActiveSync Responder ActiveSync ActiveSync\RequestsQueuedGt500Escalate\MSExchangeSyncAppPool Responder MSExchangeSyncAppPool |
I can invoke the probe manually using the following cmdlet:
|
1 |
Invoke-MonitoringProbe <health set name>\<probe name> -Server <server name> |
Pipe this out as a list to read better. Here’s what I did:
|
1 |
Invoke-MonitoringProbe ActiveSync\ActiveSyncCTPProbe\MSExchangeSyncAppPool -Server <server name> | fl |
The output gives the errors encountered by the tests. I could see that it was related to EAS so decided to disable it too.
Lastly, if you are curious as to what overrides exist the following cmdlet will help:
|
1 |
Get-ServerMonitoringOverride -Server <server name> |
Also, if you want to double check that a particular component on the Exchange server is inactive (and that’s why monitors are failing) the following cmdlet will help (I sort it by state for easy reading but that’s optional):
|
1 |
Get-ServerComponentState -Identity <server name> | Sort-Object State |
The last section of the article I referred to at the beginning of this post on editing C:\Program Files\Microsoft\Exchange Server\V15\Bin\Monitoring\Config\ClientAccessProxyTest.xml to disable certain probes. Not sure why they suggest that instead of disabling probes via the cmdlet – I think that’s because the cmdlets way is more of a temporary thing (for a certain duration) while modify the config file is a permanent fix. I should probably do the config file in my case.