Hi, we've just got SCOM up and running and one of our servers is returning the below (summarized)

Alert description: The Ehlo options for the client proxy
target server did not match while setting up proxy for user  on inbound session 08D24FG691A527F4. The
critical non-matching options were <maxSize>. The non-critical
non-matching options were <NONE>. Client proxying will continue.Probe Result Name:
'Transport/SmtpProxyEhloOptionsDoNotMatchContinueProxying'

According to the alert I should go here https://technet.microsoft.com/en-us/library/ms.exch.scom.hubtransport(v=exchg.150).aspx

and re-run the probe to see if the error was transient

So I do this 

Invoke-MonitoringProbe hubtransport\SmtpProxyEhloOptionsDoNotMatchContinueProxyingMonitor -Server server | fl

and get

WARNING: Could not find assembly or object type associated with monitor identity
'hubtransport\SmtpProxyEhloOptionsDoNotMatchContinueProxyingMonitor'. Please ensure that the given monitor identity
exists on the server.

So I double check the probe name

Get-ServerHealth shfmail01 | ?{$_.HealthSetName -eq "HubTransport" -and $_.alertvalue -eq "unhealthy"} | fl

SerializationData       : {0, 1, 0, 0, 0, 255, 255, 255, 255, 1, 0, 0, 0, 0, 0, 0...}
RunspaceId              : d05aa519-8faa-4250-bce6-3379bd20e150
Server                  : server
CurrentHealthSetState   : Online
Name                    : SmtpProxyEhloOptionsDoNotMatchContinueProxyingMonitor
TargetResource          : HubTransport
HealthSetName           : HubTransport
HealthGroupName         : ServiceComponents
AlertValue              : Unhealthy
FirstAlertObservedTime  : 01/05/2015 09:58:29
Description             :
IsHaImpacting           : False
RecurranceInterval      : 0
DefinitionCreatedTime   : 30/04/2015 14:38:59
HealthSetDescription    :
ServerComponentName     : HubTransport
LastTransitionTime      : 01/05/2015 09:58:29
LastExecutionTime       : 01/05/2015 09:58:29
LastExecutionResult     : Succeeded
ResultId                : 135254084
WorkItemId              : 709
IsStale                 : False
Error                   :
Exception               :
IsNotified              : False
LastFailedProbeId       : -229450476
LastFailedProbeResultId : 115283907
ServicePriority         : 2
Identity                : HubTransport\SmtpProxyEhloOptionsDoNotMatchContinueProxyingMonitor\HubTransport
IsValid                 : True
ObjectState             : New

Why isn't this probe working?

Thanks

Hi cwilliams40,

Basically what the "WARNING: Could not find assembly or object type associated with monitor identity" trying to say is,  even though there is a Associated Monitor for the HealthSet there is no Probe.

The article says: Rerun the associated probe for the monitor thats in an unhealthy state. 

Get-ServerHealth Server1 gives you the HealthSetName and Monitor Name only not the probe name.

HealthSetName           : HubTransport

Name                    : SmtpProxyEhloOptionsDoNotMatchContinueProxyingMonitor

Next it says Refer to the table in the Explanation section to find the associated probe.

Probe:    none (notification or check)
Health Set: HubTransport
Associated Monitors:  SmtpProxyEhloOptionsDoNotMatchContinueProxyingMonitor

To do this, run the following command:

Invoke-MonitoringProbe <health set name>\<probe name> -Server <server name> | Format-List

In your case, the failing monitor is SmtpProxyEhloOptionsDoNotMatchContinueProxyingMonitor. The probe associated with that monitor is none. To run this probe on Server1, run the following command:

Invoke-MonitoringProbe HubTransport\<probe name not available> -Server Server1 | Format-List

You can't run this ofcourse.

If you note the below example and check the link, you will notice that all probes ends with 'probe'. Which is not there for your case.

Invoke-MonitoringProbe HubTransport\ActiveQueueDrainFailureProbe -Server mailbox1.contoso.com | Format-List

Look for Eventlogs or additional notifications on that server. Check the performance, queues etc.

There are three primary categories of probes: recurrent probes, notifications, and checks.

Notifications are probes that are not run by the health manager framework, but by some other service on the server. You wont see these probes in the ProbeDefinition channel, as this channel only describes probes that will be run by the Managed Availability framework.

Checks are probes that only log events when a performance counter passes above or below a defined threshold. They are really a special case of notification probes, as there is a service monitoring the performance counters on the server and logging events to the ProbeResult channel when the configured threshold is met.

References:

Managed Availability Components

Explanation section to find the associated probe Hub Transport.