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