HealthSet Guide

Contents
Exchange 2013 Management Pack Health Sets

Troubleshooting ActiveSync Health Set
Troubleshooting ActiveSync.Protocol Health Set
Troubleshooting ActiveSync.Proxy Health Set
Troubleshooting AD Health Set
Troubleshooting Antimalware Health Set
Troubleshooting AntiSpam Health Set
Troubleshooting Autodiscover Health Set
Troubleshooting Autodiscover.Protocol Health Set
Troubleshooting Autodiscover.Proxy Health Set
Troubleshooting Classification Health Set
Troubleshooting ClientAccess.Proxy Health Set
Troubleshooting Compliance Health Set
Troubleshooting DataProtection Health Set
Troubleshooting DiskSpace Health Set
Troubleshooting ECP Health Set
Troubleshooting ECP.Proxy Health Set
Troubleshooting EDS Health Set
Troubleshooting EventAssistants Health Set
Troubleshooting EWS Health Set
Troubleshooting EWS.Protocol Health Set
Troubleshooting EWS.Proxy Health Set
Troubleshooting FfoQuarantine Health Set
Troubleshooting FfoTransport Health Set
Troubleshooting FfoUmc Health Set
Troubleshooting FfoWebService Health Set
Troubleshooting FIPS Health Set
Troubleshooting FreeBusy Health Set
Troubleshooting FrontendTransport Health Set
Troubleshooting HubTransport Health Set
Troubleshooting IMAP Health Set
Troubleshooting IMAP.Protocol Health Set
Troubleshooting IMAP.Proxy Health Set
Troubleshooting MailboxMigration Health Set
Troubleshooting MailboxSpace Health Set
Troubleshooting MailboxTransport Health Set
Troubleshooting Mailflow Health Set
Troubleshooting Memory Health Set
Troubleshooting MessageTracing Health Set
Troubleshooting Monitoring Health Set
Troubleshooting MRS Health Set
Troubleshooting MSExchangeCertificateDeployment Health Set
Troubleshooting Network Health Set
Troubleshooting OAB Health Set
Troubleshooting OAB.Proxy Health Set
Troubleshooting Outlook Health Set
Troubleshooting Outlook.Protocol Health Set
Troubleshooting Outlook.Proxy Health Set
Troubleshooting OWA Health Set
Troubleshooting OWA.Protocol Health Set
Troubleshooting OWA.Protocol.Dep Health Set
Troubleshooting OWA.Proxy Health Set
Troubleshooting POP Health Set
Troubleshooting POP.Protocol Health Set
Troubleshooting POP.Proxy Health Set
Troubleshooting PowershellDataProvider Health Set
Troubleshooting PublicFolders Health Set
Troubleshooting PushNotifications.Protocol Health Set
Troubleshooting RemoteMonitoring Health Set
Troubleshooting RPS Health Set
Troubleshooting RPS.Proxy Health Set
Troubleshooting Search Health Set
Troubleshooting SiteMailbox Health Set
Troubleshooting SMTP Health Set
Troubleshooting Store Health Set
Troubleshooting Transport Health Set
Troubleshooting UM Health Set
Troubleshooting UM.CallRouter Health Set
Troubleshooting UM.Protocol Health Set
Troubleshooting UserThrottling Health Set
10/5/2018 • 2 minutes to read • Edit Online
Exchange 2013 Management Pack Health Sets

Topic Last Modified: 2013 -05 -17
The Exchange Server 2013 Management Pack relies on the Managed Availability feature in Microsoft Exchange
Server 2013. In Managed Availability, each component in Exchange Server 2013 monitors itself using probes,
monitors, and responders. Any component that implements Managed Availability is referred to as a health set. The
following list provides troubleshooting guidance for all the health sets available in Exchange 2013:
Troubleshooting MSExchangeCertificateDeployment Health Set
For more information

Exchange Server 2013 Management Pack Guide
Server health and performance

Applies to: Exchange Server 2013
The Exchange ActiveSync health set monitors the overall health of the ActiveSync service for mobile clients in
your organization. The ActiveSync health set is closely related to the following health sets:
If you receive an alert that indicates that the ActiveSync health set is unhealthy, this indicates an issue that may
prevent your users from accessing their mailboxes by using ActiveSync.
Explanation
The ActiveSync service is monitored using the following probes and monitors.
PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS
ActiveSyncCTPProbe ActiveSync Active Directory ActiveSyncCTPMonitor

(ActiveSync health set)
Authentication
Mailbox Server
Authentication
Information Store
High Availability
Network
ActiveSyncProxyTestPro ActiveSync.Proxy - ActiveSyncProxyTestMo

be nitor (ActiveSync.Proxy
health set)
ActiveSyncDeepTestProb ActiveSync.Protocol Active Directory ActiveSyncDeepTestMon

e itor (ActiveSync health
Authentication set)
Information Store
High Availability
ActiveSyncSelfTestProbe ActiveSync.Protocol Active Directory ActiveSyncSelfTestMonit

or (ActiveSync.Protocol
Authentication health set)
RequestsQueuedGt500
Monitor (ActiveSync
health set)
For more information about probes and monitors, see Server health and performance.
User Action
It's possible that the service recovered after it issued the alert. Therefore, when you receive an alert that specifies
that the ActiveSync health set is unhealthy, first verify that the issue still exists. If the issue does exist, perform the
appropriate recovery actions outlined in the following sections.
Verifying the issue

1. Identify the health set name and server name that are given in the alert.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to help identify the root cause. If the message details
are not clear, do the following:
a. Open the Exchange Management Shell, and run the following command to retrieve the details of the
health set that issued the alert:
Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}
For example, to retrieve the ActiveSync health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "ActiveSync"}
b. Review the command output to determine which monitor reported the error. The AlertValue value
for the monitor that issued the alert will be Unhealthy.
c. Rerun the associated probe for the monitor that’s in an unhealthy state. Refer to the table in the
Explanation section to find the associated probe. To do this, run the following command:
Invoke-MonitoringProbe <health set name>\<probe name> -Server <server name> | Format-List
For example, assume that the failing monitor is ActiveSyncCTPMonitor. The probe associated
with that monitor is ActiveSyncCTPProbe. To run this probe on server1.contoso.com, run the
following command:
Invoke-MonitoringProbe ActiveSync\ActiveSyncCTPProbe -Server server1.contoso.com | Format-List
d. In the command output, review the “Result” section of the probe. If the value is Succeeded, the
issue was a transient error, and it no longer exists. Otherwise, refer to the recovery steps outlined in
the following sections.
ActiveSyncDeepTestMonitor and ActiveSyncSelfTestMonitor Recovery
Actions
This monitor alert is typically issued on Mailbox servers. To perform recovery actions, follow these steps:
1. Start IIS Manager, and then connect to the server that is reporting the issue. Click Application Pools, and
then recycle the ActiveSync application pool that’s named MSExchangeSyncAppPool.
2. Rerun the associated probe as shown in step 2c in the Verifying the issue section.
3. If the issue still exists, recycle the entire IIS service by using the IISReset utility.
5. If the issue still exists, restart the server. To do this, first failover the databases that are hosted on the server
by using the following command:
Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $true
In this and all subsequent code examples, replace server1.contoso.com with the actual server name.
6. Next, verify that all databases have been moved off the server that is reporting the issue. To do this, run the
following command:
Get-MailboxDatabaseCopyStatus -Server server1.contoso.com | Group Status
7. If the command output in step 6 shows no active copies on the server, restart the server. If the output does
show active copies, run steps 5 and 6 again.
8. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue section.
9. If the probe succeeds, failover the databases by running the following command:
Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $false
10. If the probe still fails, you may need further assistance to resolve this issue. Contact a Microsoft Support
professional to resolve this issue. To contact a Microsoft Support professional, visit the Exchange Server
Solutions Center. In the navigation pane, click Support options and resources and use one of the options
listed under Get technical support to contact a Microsoft Support professional. Because your
organization may have a specific procedure for directly contacting Microsoft Product Support Services, be
sure to review your organization's guidelines first.
ActiveSyncCTPMonitor Recovery Actions

This monitor alert is typically issued on CA servers (CAS ).
then recycle the ActiveSync application pool that is named MSExchangeSyncAppPool.
5. If the issue persists, you must verify the health status on the corresponding Mailbox server. The name of
the Mailbox server is the _Mbx: value that’s given in the error message.
a. Run the following command for the appropriate Mailbox server. For example, run the following
command a Mailbox server that’s named mailbox1.contoso.com:
Get-ServerHealth mailbox1.contoso.com | ?{$_.HealtSetName -like "ActiveSync*"}
b. If any of the monitors that are listed in the command output are reported to be unhealthy, you must
address those monitors first. To do this, follow the troubleshooting steps that are outlined in the
ActiveSyncDeepTestMonitor and ActiveSyncSelfTestMonitor Recovery Actions section.
6. If all monitors on the Mailbox server are healthy, restart the CAS.
7. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue section.
8. If the probe continues to fail, you may need further assistance to resolve this issue. Contact a Microsoft
Support professional to resolve this issue. To contact a Microsoft Support professional, visit the Exchange
Server Solutions Center. In the navigation pane, click Support options and resources and use one of the
options listed under Get technical support to contact a Microsoft Support professional. Because your
RequestsQueuedGt500Monitor Recovery Actions

This monitor alert is typically issued on CA servers.
then recycle the ActiveSync application pool that is named MSExchangeSyncAppPool.
2. Wait 10 minutes to see whether the monitor remains healthy. After 10 minutes, run the following
command for the appropriate server. For example, run the following command for server1.contoso.com:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -like "ActiveSync*"}
3. If the issue persists, recycle the entire IIS service by using the IISReset utility.
4. Wait 10 minutes, and then run the command shown in step 2 again to see whether the monitor remains
healthy.
5. If the issue persists, restart the server. If the server is a CAS, just restart the server. If the server is a Mailbox
server, do the following:
a. Failover the databases that are hosted on the server. To do this, run the following command:
Note In this and all subsequent code examples, replace server1.contoso.com with the actual server
name.
b. Verify that all the databases have been moved off the server that is reporting the issue. To do this,
run the following command:
If the command output shows no active copies on the server, restart the server.
6. After the server restarts, wait 10 minutes, and then run the command shown in step 2 again to determine
whether the monitor remains healthy.
7. If the monitor remains healthy, and if this is a Mailbox server, failover the databases by running the
following command:
8. If the probe continues to fail, you may need further assistance to resolve this issue. Contact a Microsoft
Support professional to resolve this issue. To contact a Microsoft Support professional, visit the Exchange
Server Solutions Center. In the navigation pane, click Support options and resources and use one of the
options listed under Get technical support to contact a Microsoft Support professional. Because your
For More Information

Exchange ActiveSync
Mobile devices
Exchange ActiveSync virtual directory management tasks

The ActiveSync.Protocol health set monitors the overall health of the Exchange ActiveSync communications
protocol on your Mailbox servers. If you receive an alert that specifies that the ActiveSync.Protocol health set is
unhealthy, this indicates an issue that may affect the ActiveSync components on the Mailbox server indicated in
the alert.
Explanation
The ActiveSync.Protocol health set works in conjunction with the ActiveSync health set. For detailed information
about the ActiveSync health set, see Troubleshooting ActiveSync Health Set.
User Action
It’s possible that the ActiveSync service recovered after it issued the alert. Therefore, when you receive an alert
that indicates that the ActiveSync health set is unhealthy, first verify that the issue still exists. For more information,
see Troubleshooting ActiveSync Health Set.

Exchange ActiveSync
Mobile devices

The ActiveSync.Proxy health set monitors the health of the Exchange ActiveSync infrastructure on your Client
Access servers (CAS ). If you receive an alert that specifies that the ActiveSync.Proxy health set is unhealthy, this
indicates an issue that may affect the Exchange ActiveSync components on the CAS indicated in the alert.
Explanation
The ActiveSync.Proxy health set works in conjunction with the ActiveSync health set. For detailed information
about the ActiveSync health set, see Troubleshooting ActiveSync Health Set.
User Action
The ActiveSync service might have been able to recover after it issued the alert. Therefore, when you receive an
alert that indicates that the ActiveSync health set is unhealthy, first verify that the issue still exists. For more
information, see Troubleshooting ActiveSync Health Set.

Exchange ActiveSync
Mobile devices

Thanks for clicking the link that brought you to this page. Although we don’t currently have troubleshooting
guidance for this health set, your attempt to locate content helps us prioritize the Exchange 2013 Management
Pack troubleshooting guidance articles. Here are some recommended actions that may help you troubleshoot this
health set:
Review the Application log and System log on your computers running Exchange 2013 for events related to
this feature.
Search the Microsoft Knowledge Base. For example, search the Knowledge Base for this health set. If you
find error events in the Event log, search for the Event Source and Event ID associated with this health set.
View the content available from the Exchange 2013 Forum. You can also post a question on the forum.
View the content available from the Exchange Server Community.
If you still can't resolve the issue, contact Microsoft Customer Service and Support. To contact support, go
to Exchange Server 2013 for IT Pros and click on Contact a Microsoft support professional.

health set:
this feature.

health set:
this feature.

The Autodiscover health set monitors the overall health of the Autodiscover service for clients.
If you receive an alert that specifies that Autodiscover is unhealthy, this indicates an issue that may prevent users
from accessing their mailbox by using the Autodiscover process.
Explanation
The Autodiscover service is monitored by using the following probes and monitors.
AutodiscoverCtpProbe Autodiscover Active Directory AutodiscoverCtpMonito

r
Common issues
This probe can fail for any of the following common reasons:
The Autodiscover application pool (MSExchangeAutodiscoverAppPool) that is hosted on the monitored
Client Access server (CAS ) is not responding. Or, the Autodiscover application pool that is hosted on one or
more mailbox servers is not responding.
The CAS is experiencing networking issues and cannot connect to the Mailbox server or Domain Controller.
The monitoring account credentials are incorrect.
The Domain Controllers are not responding.
User Action
It’s possible that the service recovered after it issued the alert. Therefore, when you receive an alert that specifies
that the health set is unhealthy, first verify that the issue still exists. If the issue does exist, perform the appropriate
recovery actions outlined in the following sections.
Verifying the issue still exists

1. Identify the health set name and the server name in the alert.
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
For example, to retrieve the Autodiscover health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "Autodiscover"}
for the monitor that issued the alert is Unhealthy .
For example, assume that the failing monitor is AutodiscoverCtpMonitor. The probe associated
with that monitor is AutodiscoverCtpProbe. To run that probe on server1.contoso.com, run the
following command:
Invoke-MonitoringProbe Autodiscover\AutodiscoverCtpProbe -Server server1.contoso.com | Format-

List
d. In the command output, review the Result value of the probe. If the value is Succeeded, the issue
was a transient error, and it no longer exists. Otherwise, refer to the recovery steps outlined in the
following sections.
AutodiscoverCtpMonitor Recovery Actions

When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
Name of the Mailbox server that the probe was monitoring
Time and date when the alert occurred
Authentication mechanism used, and credential information
Full exception trace of the last error, including diagnostic data and specific HTTP header information
You can use the information in the full exception trace to help troubleshoot the issue. The exception generated by
the probe contains a Failure Reason that describes why the probe failed. For example, the Failure Reason might be
one of the following:
X-FEServer Indicates on which CAS the probe was run
X-CalculatedBETarget Indicates the Mailbox server to which the request is routed
X-DiagInfo Indicates the Mailbox server that received the request
To troubleshoot this issue, follow these steps:
1. Review the protocol logs on the CA and Mailbox servers. By default, Protocol logs on the CAS are located in
the <exchange server installation directory>\Logging\HttpProxy\Autodiscover folder. By default,
Protocol log files on the Mailbox server are located in the <exchange server installation
directory>\Logging\Autodiscover folder.
2. Create a test user account, and then log on to the CAS by using the test user account. For example, log on
by using: https://<servername>/autodiscover/autodiscover.xml.
If test user account name passes, an issue may affect the mailbox server that’s hosting the monitored
mailbox.
Try to repeat the previous steps by using a test account on the Mailbox server. If this attempt fails, try to
perform the test against a different CAS to verify that the problem is occurring on a specific CAS and not on
the Mailbox server.
3. Verify the network connectivity between the CA and Mailbox servers. Use ping.exe to verify that each server
is responding.
4. Check for alerts on the Autodiscover.Proxy Health Set that may indicate an issue that affects a specific
Mailbox server. For more information, see Troubleshooting Autodiscover.Proxy Health Set.
5. Check for alerts on the Autodiscover.Protocol Health Set that may indicate a problem that affects specific
Mailbox servers. For more information, see Troubleshooting Autodiscover.Protocol Health Set.
6. Start IIS Manager, and then connect to the server that is reporting the issue. Verify that the
MSExchangeAutodiscoverAppPool application pool is running on the CA and Mailbox servers.
7. In IIS Manager, click Application Pools, and then recycle the MSExchangeAutodiscoverAppPool
application pool by running the following command from the Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeAutodiscoverAppPool
8. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
9. If the issue still exists, recycle the IIS service by using the IISReset utility or by running the following
command:
Iisreset /noforce
11. If the issue still exists, restart the server.
12. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
13. If the probe continues to fail, you may need assistance to resolve this issue. Contact a Microsoft Support
listed under Get technical support to contact a Microsoft Support professional. Because your organization
may have a specific procedure for directly contacting Microsoft Product Support Services, be sure to review
your organization's guidelines first.

What's new in Exchange 2013
Exchange 2013 cmdlets

The Autodiscover.Protocol health set monitors the Autodiscover communications protocol on the Mailbox server.
If you receive an alert that specifies that Autodiscover.Protocol is unhealthy, this indicates an issue that may
prevent users from accessing their mailboxes.
Explanation
The Autodiscover.Protocol service is monitored by using the following probes and monitors.
AutodiscoverSelfTestPro Autodiscover.Protocol Active Directory AutodiscoverSelfTestMo

be nitor
Common issues
The Autodiscover application pool (MSExchangeAutodiscoverAppPool) that is hosted on the monitored
Client Access server (CAS ) is not responding. Or, the Autodiscover application pool that is hosted on one or
more Mailbox servers is not responding.
User Action

a. Open the Exchange Management Shell, and then run the following command to retrieve the details
of the health set that issued the alert:
For example, to retrieve the Autodiscover.Protocol health set details about server1.contoso.com, run
the following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "Autodiscover.Protocol"}
for the monitor that issued the alert will be Unhealthy .
For example, assume that the failing monitor is AutodiscoverSelfTestMonitor. The probe
associated with that monitor is AutodiscoverSelfTestProbe. To run that probe on
server1.contoso.com, run the following command:
Invoke-MonitoringProbe Autodiscover.Protocol\AutodiscoverSelfTestProbe -Server

server1.contoso.com | Format-List
following sections.
AutodiscoverSelfTestProbe Recovery Actions

Name of the Mailbox server that sent the alert
Name of Mailbox server being monitored
You can use the information in the full exception trace to help troubleshoot the issue. The exception generated by
the probe contains a Failure Reason that describes why the probe failed.
1. Review protocol logs on the Mailbox servers. By default, Protocol log files on the Mailbox server are located
in the <exchange server installation directory>\Logging\Autodiscover folder.
2. Create a test user account, and then log on to the Mailbox server by using the test user account in the
address. For example, log on by using: https://<servername>:444/autodiscover/autodiscover.xml.
If the test user account name passes, an issue may affect the mailbox server that’s hosting the monitored
mailbox.
3. Try to repeat the previous steps by using a test account on the Mailbox server.
4. Check for alerts on the Autodiscover.Proxy Health Set that may indicate an issue that affects a specific
Mailbox server. For more information, see Troubleshooting Autodiscover.Proxy Health Set.
5. Check for alerts on the Autodiscover Health Set that may indicate a problem that affects specific Mailbox
servers. For more information, see Troubleshooting Autodiscover Health Set.
6. Start IIS Manager, and then connect to the Mailbox server that is reporting the issue. Verify that the
MSExchangeAutodiscoverAppPool application pool is running on the Mailbox server.
7. In IIS Manager, click Application Pools, and then recycle the MSExchangeAutodiscoverAppPool
application pool by running the following command from the Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeAutodiscoverAppPool
9. If the issue still exists, recycle the IIS service using the IISReset utility or by running the following
command:
Iisreset /noforce
section.


The Autodiscover.Proxy health set monitors the availability of the Autodiscover proxy infrastructure on the Client
Access server (CAS ). The Autodiscover.Proxy health set is closely related to the following health set:
If you receive an alert that specifies that the Autodiscover.Proxy is unhealthy, this indicates an issue that might
prevent your users from discovering their mailboxes by using the Exchange Autodiscover process.
Explanation
The Autodiscover service is monitored by using the following probes and monitors.
AutoDiscoverProxyTestP Autodiscover.Proxy Active Directory AutodiscoverProxyTestM

robe onitor
Common issues
The application pool that’s hosted on the monitored CAS is not working correctly.
User Action


following sections.
AutodiscoverProxyTestMonitor Recovery Actions

Name of the CAS that sent the alert
You can use the information in the full exception trace to help troubleshoot the issue.
Time and date when the issue occurred
1. Review the protocol logs on the CAS. Protocol logs are located in the <exchange server installation
directory>\Logging\HttpProxy*\<protocol>* folder on the CAS.
by using: https:// <servername>/owa.
3. Start IIS Manager, and then connect to the server that’s reporting the issue. Verify that the
MSExchangeAutodiscoverAppPool is running on CAS.
4. Click Application Pools, and then recycle the MSExchangeAutoDiscoverAppPool application pool by
running the following command from the Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeAutoDiscoverAppPool
6. If the issue still exists, recycle the IIS service by using the IISReset utility.
section.

Autodiscover service

health set:
this feature.

health set:
this feature.

health set:
this feature.

Applies to: Exchange Server 2013, Project Server 2013
The DataProtection Health set monitors the redundancy of databases in a database availability group (DAG ).
If you receive an alert that specifies that DataProtection is unhealthy, this indicates an issue that may affect the
replication or cluster components, and that can prevent access to the Exchange databases.
Explanation
The DataProtection Health service is monitored by using the following probes and monitors.
ClusterEndpointProbe DataProtection Active Directory ClusterEndpointMonitor
ClusterGroupProbe DataProtection Active Directory ClusterGroupMonitor
ClusterNetworkProbe DataProtection Active Directory ClusterNetworkMonitor
ClusterServiceCrashProb DataProtection Active Directory ClusterServiceCrashMoni

e tor
ServerOneCopyProbe DataProtection Active Director ServerOneCopyMonitor
ServerOneCopyInternal DataProtection Active Directory ServerOneCopyInternal

MonitorProbe MonitorMonitor
ServiceHealthMSExchang DataProtection Active Directory ServiceHealthMSExchang

eReplEndpointProbe eReplEndpointMonitor
ServiceHealthMSExchang DataProtection Active Directory ServiceHealthMSExchang

eReplCrashProbe eReplCrashMonitor
ServerSiteFailureProbe DataProtection Active Directory ServerSiteFailureMonitor

StorageApparentControl DataProtection Active Directory StorageApparentControl

lerIssuesProbe lerIssuesMonitor
DatabaseHealthTooMan DataProtection Active Directory DatabaseHealthTooMan

yMountedDatabaseProb yMountedDatabaseMon
e itor
User Action

Review the command output to determine which monitor reported the error. The AlertValue value
b. Identify the probe that the monitor is based on. Note that most probes share the same name prefix.
By using the previous example, search for “ClusterNetwork*”:
Get-MonitoringItemIdentity -Identity DataProtection -Server server1.contoso.com | ?{$_.Name -like

"ClusterNet ItemType
work*"}
The returned results should resemble the following.
ItemType HealthSetName Name TargetResource
Probe DataProtection ClusterNetworkProbe MSExchangeRepl


following sections.
Troubleshooting steps
Authentication mechanism that was used, and credential information
You can use the information in the full exception trace to help troubleshoot the issue. The exception
generated by the probe contains a failure Reason that describes why the probe failed.
For most issues that occur in high availability environments, you can run the Test-ReplicationHealth cmdlet to
help troubleshoot the cluster/networking/ActiveManager/services. Other HealthSet/Components will have
different Test-* cmdlets.
For example:
Test-ReplicationHealth <ServerName>
The returned results will resemble the following:
Server Check Result
<ServerName> ClusterService Passed
<ServerName> ReplayService Passed
<ServerName> ActiveManager Passed
<ServerName> TasksRpcListener Passed

<ServerName> TcpListener Passed
<ServerName> ServerLocatorService Passed
<ServerName> DagMembersUp Passed
<ServerName> ClusterNetwork Passed
<ServerName> QuorumGroup Passed
<ServerName> FileShareQuorum Passed
<ServerName> DatabaseRedundancyCheck Passed
<ServerName> DatabaseAvailabilityCheck Passed
<ServerName> DBCopySuspended Passed
<ServerName> DBCopyFailed Passed
<ServerName> DBInitializing Passed
<ServerName> DBDisconnected Passed
<ServerName> DBLogCopyKeepingUp Passed
<ServerName> DBLogReplayKeepingUp Passed
If all components display Passed in the Result column, try to rerun the associated probe as shown in step 2c in the
Verifying the issue still exists section.
If the issue still exists, restart the server. After the server restarts, rerun the associated probe as shown in step 2c in
the Verifying the issue still exists section.
If the probe continues to fail, you may need assistance to resolve this issue. Contact a Microsoft Support
professional to resolve this issue. To contact a Microsoft Support professional, visit the Exchange Server Solutions
Center. In the navigation pane, click Support options and resources and use one of the options listed under Get
technical support to contact a Microsoft Support professional. Because your organization may have a specific
procedure for directly contacting Microsoft Product Support Services, be sure to review your organization's
guidelines first.


health set:
this feature.

The Exchange Control Panel (ECP ) health set monitors the overall health of the Exchange Administration Center
(EAC ) and of the Outlook Web App (OWA) user setting service. The ECP health set is closely related to the
following health set:
If you receive an alert that specifies that the ECP health set is unhealthy, this indicates an issue that may prevent
users from accessing the EAC.
Explanation
The EAC service is monitored by using the following probes and monitors.
EacSelfTestProbe ECP Active Directory EacSelfTestMonitor
EacDeepTestProbe ECP Active Directory EacDeepTestMonitor
User Action
Authentication and credential information
Note You can use the information in the full exception trace to help troubleshoot the issue.

not clear, follow these steps:
Get-ServerHealth -Identity <ServerName> -HealthSet <HealthSetName>
For example, to retrieve the ECP health set details about server1.contoso.com, run the following
command:
Get-ServerHealth -Identity server1.contoso.com -HealthSetName ECP
Invoke-MonitoringProbe <HealthSetName>\<ProbeName> -Server <ServerName> | Format-List
For example, assume that the failing monitor is EacSelfTestMonitor. The probe associated with that
monitor is EacSelfTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe ECP\EacSelfTestProbe -Server server1.contoso.com | Format-List
following sections.
EacSelfTestMonitor and EacDeepTestMonitor Recovery Actions

1. Start IIS Manager, and then connect to the server that’s reporting the issue. Click Application Pools, and
then recycle the ECP application pool named MSExchangeECPAppPool.
5. If the probe fails, restart the server.
section.
Exchange admin center in Exchange 2013

The ECP.Proxy health set monitors the availability of the Exchange Administration Center (EAC ) proxy
infrastructure on the Client Access server (CAS ). The ECP.Proxy health set is closely related to the following health
set:
If you receive an alert that specifies that the ECP.Proxy is unhealthy, this indicates an issue that might prevent you
from using the EAC.
Explanation
The EAC service is monitored by using the following probes and monitors:
ECPProxyTestProbe ECP.Proxy Active Directory ECPProxyTestMonitor
Common issues
This probe may fail for any of the following common reasons:
User Action

For example, to retrieve the ECP.Proxy health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "ECP.Proxy"}
b. Review the command output, and determine which monitor reported the error. The AlertValue
value for the monitor that issued the alert will be Unhealthy .
c. Rerun the associated probe for the monitor that is in an unhealthy state. Refer to the table in the
For example, assume that the failing monitor is ECPProxyTestMonitor. The probe associated with
that monitor is ECPProxyTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe ECP.Proxy\ECPProxyTestProbe -Server server1.contoso.com | Format-List
following sections.
ECPProxyTestMonitor Recovery Actions

1. Review the protocol logs on CA servers. Protocol logs are located in the <exchange server installation
2. Create a test user account, and then log on to the CAS by using the test user account name. For example,
log on by using: https:// <servername>/owa.
3. Start IIS Manager, and then connect to the server that is reporting the issue. Verify that the
MSExchangeServicesAppPool is running on the CAS.
4. Click Application Pools, and then recycle the MSExchangeECPAppPool application pool by running the
following command from the Exchange Management Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeECPAppPool
section.


health set:
this feature.

health set:
this feature.

The Exchange Web Services (EWS ) health set monitors the overall health of the EWS service. The EWS health set
is closely related to the following health sets:
If you receive an alert that specifies that EWS is unhealthy, this indicates an issue that may prevent your users
from communicating with the Exchange server.
Explanation
EWS is monitored by using the following probes and monitors.
EwsCtpProbe EWS Information Store EwsCtpMonitor (EWS

health set)
Active Directory Domain
Services (AD DS)
EwsSelfTestProbe EWS.Protocol Active Directory Domain EWSSelfTestMonitor

Services (AD DS)
EwsDeepTestProbe EWS.Protocol Information Store EWSDeepTestMonitor
This probe performs a full EWS logon from the Client Access server (CAS ) to a Mailbox server by using a
monitoring account. This probe calls the GetFolder method on EWS. For more information about probes and
monitors, see Server health and performance.
Common issues
A mismatch exists between the authentication mechanism that is used by the probe and the authentication
mechanism that is used on the CAS virtual directory.
The EWS Application pool in the CAS that’s being monitored is not responding.
The CAS is experiencing networking issues when it connects to the Mailbox server.
The CAS is experiencing communication issues when it connects to Domain Controllers.
The EWS Application pool that resides on one or more Mailbox servers is not responding.
The user’s database is not mounted, or the Information Store is unavailable for a specific mailbox.
The Information Store service on one or more Mailbox servers is experiencing issues.
User Action

When you receive an alert from this HealthSet, the email message contains the following information:
a. Name of the CAS on which the alert originated
b. Name of Mailbox server that the probe was monitoring as a target resource
c. Full exception trace of the last error, including diagnostic data and specific HTTP header information
d. Time when the incident occurred
e. Authentication mechanism that was used, and credential information
The exception trace information provides the most important clue as to why the probe is failing. The
escalation message also contains the following HTTP headers:
a. X-FEServer Indicates on which CAS the probe was run
b. X-TargetBEServer Indicates to which MBX server the request is routed
c. X-DiagInfo Indicates the MBX server that received the request
For example, to retrieve the EWS health set details about server1.contoso.com, run the following
command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "EWS"}
c. Rerun the associated probe for the monitor that‘s in an unhealthy state. Refer to the table in the
For the EWS health set, assume that the failing monitor is EWSCtpMonitor. The probe associated
with that monitor is EWSCtpProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe EWS\EWSCtpProbe -Server server1.contoso.com | Format-List
following sections.
EwsCtpMonitor Recovery Actions

1. Start IIS Manager, and then connect to the server that’s reporting the issue to determine whether the
MSExchangeServicesAppPool application pool is running on both CA and Mailbox servers.
2. Locate the MailboxDatabase for the failed probes. The, verify that the Mailbox database is active for the
Mailbox server, and that the Information Store is healthy.
3. Click Application Pools, and then recycle the MSExchangeServicesAppPool application pool by
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool
7. If the issue still exits, review the protocol log files on the CA and Mailbox servers. The protocol logs for the
CAS reside in the <exchange server installation directory>\Logging\HttpProxy\Ews folder. On the Mailbox
server, the logs reside in the <exchange server installation directory>\Logging\Ews folder.
8. Create a test user account, and then log on by running the test user account against the given CAS. For
example, log on by using: https:// <servername>/ews/exchange.asmx. If the issue still exists, try a different
CAS to determine whether the problem is scoped to that CAS and not to the Mailbox server. If the test user
name passes, an issue may affect the specific Mailbox database or Mailbox server on which the monitoring
mailbox is located. Try to repeat this step by using a test account that exists in the Mailbox database.
9. Check network connectivity between the CA and Mailbox server.
10. Check for any alerts on the EWS.Proxy Health Set that might indicate a problem that affects a specific CAS.
11. Check for any alerts on the EWS.Protocol Health Set that might indicate a problem that affects a specific
Mailbox server.
12. If the issue still exists, restart the server. To do this, first failover the databases that are hosted on the server.
To do this, run the following command:
Note In this and all subsequent code examples, replace server1.contoso.com with the actual server name.
13. Verify that all the databases have been moved off the server that is reporting the issue. To do this, run the
following command:
section.
15. If the probe succeeds, failover the databases back to the Mailbox server by running the following command:
16. If the probe is still failing, you may need assistance to resolve this issue. Contact a Microsoft Support


The EWS.Protocol health set monitors the Exchange Web Services (EWS ) communications protocol on the
Mailbox server. The EWS.Protocol health set is closely related to the following health sets:
If you receive an alert that specifies that the EWS.Protocol is unhealthy, this indicates an issue that may prevent
your users from accessing Exchange.
Explanation
The EWS.Protocol health set is composed of the following probes:
1. EwsSelfTestProbe
2. EwsDeepTestProbe
The EwsSelfTestProbe does not depend on the Information Store. However, the EwsDeepTestProbe probe
depends on the Information Store. Both of these probes perform EWS operations on the Mailbox server, and they
use the same authentication method as a Client Access server (CAS ). EwsSeftTestProbe calls the ConvertId
method, and EwsDeepTestProbe calls the GetFolder method.
EwsSelfTestProbe EWS.Protocol Active Directory EWSSelfTestMonitor
EwsDeepTestProbe EWS.Protocol Information Store EWSDeepTestMonitor
When you receive an alert from this HealthSet, the email message contains the following information:
1. Name of the Mailbox server on which the alert originated
2. Full exception trace of the last error, including diagnostic data and specific HTTP headers information
3. Time when the incident occurred
Common issues
The EWS Application pool on the monitored Mailbox server is not functioning correctly.
The Domain Controllers are not responding, or they cannot communicate with the Mailbox server.
The user’s database is not mounted, or the Information Store is unavailable for a specific mailbox.
User Action

For example, to retrieve the EWS.Protocol health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "EWS.Protocol"}
For example, assume that the failing monitor is EWSSelfTestMonitor. The probe associated with
that monitor is EWSSelfTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe EWS.Protocol\EWSSelfTestProbe -Server server1.contoso.com | Format-List
following sections.
EWSSelfTestMonitor and EWSDeepTestMonitor Recovery Actions

This monitor alert is typically issued for Mailbox servers.
MSExchangeServicesAppPool is running on both CA and Mailbox servers.
2. Locate the MailboxDatabase for the failed probes, and then verify that the MailboxDatabase is active for the
MailboxServer, and that the Information Store is healthy.
5. If the issue still exists, restart the IIS service by using the IISReset utility.
7. If the issue still exits, review the protocol log files on the Mailbox server. On the Mailbox server, the logs
reside in the <exchange server installation directory>\Logging\Ews folder.
8. Create a test user account, and then log on by using the test user account against the given Mailbox server
on port 444 https://<servername>:444/ews/exchange.asmx. If the test is successful, an issue may affect the
specific mailbox database or Mailbox server on which the monitoring mailbox is located. Try to repeat this
step by using a test account on that database.
9. Check for any alerts on the EWS.Protocol Health Set that might indicate a problem that affects the specific
Mailbox server.
10. If the issue still exists, restart the server. To do this, first failover the databases hosted on the server by using
In this and all subsequent code examples, replace server1.contoso.com with the actual server name.
11. Verify that all the databases have been moved off the server that is reporting the issue. To do this, run the
following command:
If the command output shows no active copies on the server, the server is save the restart. Restart the
server.
section.
14. If the probe is still failing, you may need assistance to resolve this issue. Contact a Microsoft Support

The EWS.Proxy health set monitors the availability of the Exchange Web Services (EWS ) proxy infrastructure on
the Client Access server (CAS ). The EWS.Proxy health set is closely related to the following health set:
If you receive an alert that specifies that the EWS.Proxy is unhealthy, this indicates an issue that may prevent users
from accessing the EWS service.
Explanation
The EWS service is monitored by using the following probes and monitors.
EWSProxyTestProbe EWS.Proxy Active Directory EWSProxyTestMonitor
Common issues
User Action

For example, to retrieve the EWS.Proxy health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "EWS.Proxy"}
Verifying the issue still exists section to find the associated probe. To do this, run the following
command:
For example, assume that the failing monitor is EWSProxyTestMonitor. The probe associated with
that monitor is EWSProxyTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe EWS.Proxy\EWSProxyTestProbe -Server server1.contoso.com | Format-List
following sections.
EWSProxyTestMonitor Recovery Actions

When you receive an alert from a health set, the email message will contain the following information:
1. Review the protocol logs on CA servers. Protocol logs are located in the <exchange server installation
2. Create a test user account, and then log on to the CAS by using the test user account. For example, use the
following logon address: https:// <servername>/owa
MSExchangeServicesAppPool application pool is running on the CAS.
section.


health set:
this feature.

health set:
this feature.

health set:
this feature.

health set:
this feature.

The FIPS health set monitors the overall health of the Federal Information Processing Standards (FIPS ) settings
on Exchange servers. For more information about FIPS 140, see FIPS 140 Validation.
If you receive an alert that indicates that the FIPS health set is unhealthy, this indicates an issue that may prevent
your Exchange server from using FIPS 140-compliant components and processes.
Explanation
The FIPS service is monitored using the following probes and monitors.
PROBE HEALTH SET ASSOCIATED MONITORS
none (notification or check) FIPS CrashEvent.scanningprocess
none (notification or check) FIPS MaintenanceFailureMonitor.FIPS
none (notification or check) FIPS MaintenanceTimeoutMonitor.FIPS
none (notification or check) FIPS PrivateWorkingSetWarning.scannin

gprocess
none (notification or check) FIPS PrivateWorkingSetError.scanningpr

ocess
none (notification or check) FIPS ProcessProcessorTimeWarning.scan

ningprocess
none (notification or check) FIPS ProcessProcessorTimeError.scannin

gprocess
User Action
that the FIPS health set is unhealthy, first verify that the issue still exists. If the issue does exist, perform the
appropriate recovery actions outlined in the following section.
Verifying the issue

For example, to retrieve the FIPS health set details about server1.contoso.com, run the following
command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "FIPS"}

health set:
this feature.

health set:
this feature.

The HubTransport health set monitors the overall health of the transport pipeline on Mailbox servers that's
responsible for routing mail in your organization. For more information, see Mail flow.
If you receive an alert that indicates that the HubTransport health set is unhealthy, this indicates an issue that may
prevent mail from being routed and delivered.
Explanation
The HubTransport service is monitored using the following probes and monitors.
ActiveQueueDrainFailureProbe HubTransport ActiveQueueDrainFailureMonitor
DiagnosticsAggregationLocalSnapsh HubTransport DiagnosticsAggregationLocalSnaps

otProbe hotMonitor
DiagnosticsAggregationWebService HubTransport DiagnosticsAggregationWebService

Probe Monitor
HubAvailabilityProbe HubTransport HubAvailabilityMonitor
HubTransportServiceRunning HubTransport HubTransportServiceRunningMonit

or
ShadowQueueDiscardDrainFailurePr HubTransport ShadowQueueDiscardDrainFailureM

obe onitor
ThrottlingServiceRunning HubTransport ThrottlingServiceRunningMonitor
TransportEdgeSync.Service.Probe HubTransport TransportEdgeSync.Service.Monitor
TransportLogSearchRunningProbe HubTransport TransportLogSearchRunningMonito

r
none (notification or check) HubTransport BootloaderOutstandingItemsTrigger

Monitor
none (notification or check) HubTransport CrashEvent.edgetransport
none (notification or check) HubTransport CrashEvent.msexchangethrottling
none (notification or check) HubTransport CrashEvent.msexchangetransport
none (notification or check) HubTransport CrashEvent.msexchangetransportlo

gsearch
none (notification or check) HubTransport EdgeTransportBackpressureSustaine

dTimeMonitor
none (notification or check) HubTransport FederatedDecryptionAgentFailedTo

XDecryptMonitor
none (notification or check) HubTransport HubTransport.ServiceInconsistentSt

ate.Monitor
none (notification or check) HubTransport IsMemberOfResolverExpandedGrou

psCacheSizeMonitor
none (notification or check) HubTransport IsMemberOfResolverResolvedGrou

psCacheSizeMonitor
none (notification or check) HubTransport Messages.failed.to.be.made.redunda

nt.Monitor
none (notification or check) HubTransport MessagesDeferredDuringCategoriza

tionMonitor
none (notification or check) HubTransport MessageTrackingLogsDirQuotaMon

itor
none (notification or check) HubTransport PrivateWorkingSetError.edgetransp

ort
none (notification or check) HubTransport PrivateWorkingSetError.msexchaha

ngetransportlogsearch
none (notification or check) HubTransport PrivateWorkingSetError.msexchang

ethrottling
none (notification or check) HubTransport PrivateWorkingSetError.msexchang

etransport
none (notification or check) HubTransport PrivateWorkingSetWarning.edgetra

nsport
none (notification or check) HubTransport PrivateWorkingSetWarning.msexcha

ngethrottling

ngetransport

none (notification or check) HubTransport ProcessProcessorTimeError.edgetra

nsport
none (notification or check) HubTransport ProcessProcessorTimeError.msexcha

ngethrottling

ngetransport

none (notification or check) HubTransport ProcessProcessorTimeWarning.edge

transport
none (notification or check) HubTransport ProcessProcessorTimeWarning.msex

changethrottling

changetransport

changetransportlogsearch
none (notification or check) HubTransport QueueExternalAggregateMonitor

none (notification or check) HubTransport QueueInternalAggregateMonitor
none (notification or check) HubTransport QueueInternalAggregateNormalPri

orityMonitor
none (notification or check) HubTransport QueueInternalHubRetryMonitor
none (notification or check) HubTransport QueueInternalHubRetryNormalPrior

ityMonitor
none (notification or check) HubTransport QueueMailboxRetryMonitor
none (notification or check) HubTransport QueueNonSMTPRetryMonitor
none (notification or check) HubTransport RuleEvaluationFailureEventLogMoni

tor
none (notification or check) HubTransport RuleEvaluationIgnoredFailureEventL

ogMonitor
none (notification or check) HubTransport RuleEvaluationIgnoredFipsFailureEv

entLogMonitor
none (notification or check) HubTransport RuleEvaluationSmallScaleFailureEven

tLogMonitor
none (notification or check) HubTransport RuleEvaluationSmallScaleFipsFailure

EventLogMonitor
none (notification or check) HubTransport RuleExcessiveForkingEventLogMoni

tor
none (notification or check) HubTransport RuleLoadFailureEventLogMonitor
none (notification or check) HubTransport RuleLoadSmallScaleFailureEventLog

Monitor
none (notification or check) HubTransport SmtpProxyEhloOptionsDoNotMatc

hContinueProxyingMonitor
none (notification or check) HubTransport SubmissionQueueMonitor

none (notification or check) HubTransport TlsDomainClientCertificateSubjectMi

smatchMonitor
none (notification or check) HubTransport Total.Shadow.Queue.Length.Above.

Threshold.Monitor
none (notification or check) HubTransport TotalE2ELatencyHighForMSExchang

eTransportMonitor
none (notification or check) HubTransport TotalE2ELatencyLowForMSExchange

TransportMonitor
none (notification or check) HubTransport TotalE2ELatencyNormalForMSExcha

ngeTransportMonitor
none (notification or check) HubTransport Transport.CatExpiry.Monitor
none (notification or check) HubTransport Transport.Critical.Storage.Recovery.F

ailed.Monitor
none (notification or check) HubTransport Transport.DatabaseMoved.Monitor
none (notification or check) HubTransport Transport.DomainSecureCert.Monit

or
none (notification or check) HubTransport Transport.DomainSecureCertAuth.

Monitor
none (notification or check) HubTransport Transport.DomainSecureServerCertF

ailed.Monitor
none (notification or check) HubTransport Transport.DomainSecureServerDom

ainCertFailed.Monitor
none (notification or check) HubTransport Transport.FailedToCreatePickupDire

ctory.Monitor
none (notification or check) HubTransport Transport.InvalidAcceptedDomain.

Monitor
none (notification or check) HubTransport Transport.LowDiskSpace.Monitor

none (notification or check) HubTransport Transport.Messages.Completing.Cat

egorization.Monitor
none (notification or check) HubTransport Transport.NDRForUnrestrictedLarge

DL.Monitor
none (notification or check) HubTransport Transport.PickupDelete.Monitor
none (notification or check) HubTransport Transport.PickupIsBadmailingFile.M

onitor
none (notification or check) HubTransport Transport.SendConn.AuthKerb.Moni

tor
none (notification or check) HubTransport Transport.SendConnAuth.Monitor
none (notification or check) HubTransport Transport.SendConnTLS.Monitor
none (notification or check) HubTransport Transport.ServerCertExpireSoon.Mo

nitor
none (notification or check) HubTransport Transport.ServerCertMismatch.Moni

tor
none (notification or check) HubTransport Transport.ServiceStartError.Monitor
none (notification or check) HubTransport Transport.SmtpSendDirectTrustFaile

d.Monitor
none (notification or check) HubTransport Transport.TemplateDoesNotExist.M

onitor
none (notification or check) HubTransport Transport.TLSValidate.Monitor
none (notification or check) HubTransport Transport.UnknownTemplateInPubli

shingLicense.Monitor
none (notification or check) HubTransport TransportCategorizerJobAvailability

Monitor
none (notification or check) HubTransport TransportDatabaseCorruptMonitor

none (notification or check) HubTransport TransportDeliveryFailures544Monit

or
none (notification or check) HubTransport TransportDeliveryFailuresDeliverySt

oreDriver520Monitor
none (notification or check) HubTransport TransportLogGenerationCheckpoint

DepthMonitor
none (notification or check) HubTransport TransportLogSearchLogPathInvalid

Monitor
none (notification or check) HubTransport TransportMaxLocalLoopCountMoni

tor
none (notification or check) HubTransport TransportPickupReadMonitor
none (notification or check) HubTransport TransportPoisonMessageMonitor
none (notification or check) HubTransport TransportRejectingMessageSubmissi

onsMonitor
none (notification or check) HubTransport TransportServerCertPersonalStoreM

onitor
none (notification or check) HubTransport UnreachableQueueMonitor
none (notification or check) HubTransport XProxyToTransientInvalidArguments

Monitor
User Action
that the HubTransport health set is unhealthy, first verify that the issue still exists. If the issue does exist, perform
the appropriate recovery actions outlined in the following section.
Verifying the issue

For example, to retrieve the HubTransport health set details about mailbox1.contoso.com, run the
following command:
Get-ServerHealth mailbox1.contoso.com | ?{$_.HealthSetName -eq "HubTransport"}
For example, assume that the failing monitor is ActiveQueueDrainFailureMonitor. The probe
associated with that monitor is ActiveQueueDrainFailureProbe. To run this probe on
mailbox1.contoso.com, run the following command:
Invoke-MonitoringProbe HubTransport\ActiveQueueDrainFailureProbe -Server mailbox1.contoso.com |

Format-List
d. In the command output, review the "Result" section of the probe. If the value is Succeeded, the issue
was a transient error, and it no longer exists.

The IMAP health set monitors the availability of the IMAP4 proxy infrastructure on the Client Access server (CAS ).
The IMAP health set is closely related to the following health sets:
If you receive an alert that specifies that IMAP is unhealthy, this indicates an issue that may prevent your users
from accessing their mailboxes by using IMAP.
Explanation
The IMAP4 service is monitored by using the following probes and monitors.
ImapCTPProbe IMAP Active Directory ImapCTPMonitor (IMAP

health set)
Authentication
Mailbox Server
Authentication
High Availability
Networking
ImapProxyTestProbe IMAP.Proxy Active Directory ImapProxyTestMonitor(I

MAP.Proxy health set)
Authentication
ImapDeepTestProbe IMAP.Protocol Active Directory IMAP.Protocol

(IMAP.Protocol health
Authentication set)
Information Store
High Availability
ImapSelfTestProbe IMAP.Protocol Active Directory IMAP.Protocol

(IMAP.Protocol health
Authentication set)
AverageCommandProce
ssingTimeGt60sMonitor
(IMAP health set)
User Action

For example, to retrieve the IMAP health set details about server1.contoso.com, run the following
command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -like "IMAP*"}
For example, assume that the failing monitor is ImapCTPMonitor. The probe associated with that
monitor is ImapCTPProbe. To run that probe on server1.contoso.com, run the following command:
Invoke-MonitoringProbe IMAP\ImapCTPProbe -Server server1.contoso.com | Format-List
following sections.
ImapTestDeepMonitor and ImapSelfTestMonitor Recovery Actions
1. Restart the Exchange IMAP4 service on the back-end server. For more information about how to stop and
start the IMAP4 service, see Start and stop the IMAP4 services.
3. If the issue still exists, you must failover the databases hosted on the mailbox server by using the following
command:
Set-MailboxServer -Identity <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $true
4. Verify that all databases have been moved off the server that’s reporting the issue. To do this, run the
following command:
ImapCTPMonitor Recovery Actions

This monitor alert is typically issued on CAS servers.
1. Restart the Exchange IMAP4 service on the backend server. For more information about stopping and
starting the IMAP4 service, see Start and stop the IMAP4 services
2. Rerun the associated probe as shown in step 2.c. in the Verifying the issue still exists section.
3. If the issue still exists, you must turn on IMAP protocol logging to help resolve the issue. To do this, follow
these steps:
a. In Windows PowerShell, run the following command:
Set-ImapSettings -server <CAS server name> -ProtocolLoggingEnabled $true
b. Restart the Exchange IMAP4 service on the backend server. For more information about how to stop
and start the IMAP4 service, see Start and stop the IMAP4 services
c. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
d. Run the following command, and then determine the location of the log file. To do this, run the
following command:
Get-ImapSettings -server <CAS server name>
e. Determine the mailbox that is serving this command. The name of the mailbox server is the value for
_Mbx: value in the error message.
f. Run the following command:
Get-ServerHealth mailbox1.contoso.com | ?{$_.HealtSetName -like "IMAP*"}
Note In this command, replace mailbox1.contoso.com with the actual Mailbox server name.
g. If any of the monitors that are listed in the command output are reported as unhealthy, you must
address those monitors first. Follow the troubleshooting steps outlined in the ImapTestDeepMonitor
and ImapSelfTestMonitor Recovery Actions section.
4. If the Mailbox server is reported as healthy, restart the CAS.
section.
6. Turn off protocol logging. To do this, run the following Windows PowerShell command:
Set-ImapSettings -server <CAS server name> -ProtocolLoggingEnabled $false
7. Restart the IMAP4 service.

ImapProxyTestMonitor recovery actions

1. Restart the IMAP4 service.
3. If probe is still failing, restart the CAS.
section.
AverageCommandProcessingTimeGt60sMonitor
RequestsQueuedGt500Monitor Recovery Actions
This monitor alert is typically issued on CA and Mailbox servers.
1. Restart the Exchange IMAP4 service on the back-end server or CAS. For more information about how to
stop and start the IMAP4 service, see Start and stop the IMAP4 services
2. Wait 10 minutes to see whether the monitor stays healthy. After 10 minutes, run the following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -like "IMAP*"}
Note In this command, replace server1.contoso.com with the actual server name.
3. Wait 10 minutes, and then run the command shown in step 2 again to see whether the monitor stays
healthy.
4. If the issue still exists, you must restart the server. If the server is a CAS, just restart the server. If the server
is a Mailbox server, do the following:
a. Failover the databases that are hosted on the server. To do this, run the following command:
name.
b. Verify that all databases have been moved off the server that is reporting the issue. To do this, run
5. After the server restarts, wait 10 minutes, and then run the command shown in step 2 again to see whether
the monitor stays healthy.
6. If the monitor stays healthy, and if this is a Mailbox server, failover the databases by running the following
command:

POP3 and IMAP4
Enable IMAP4 in Exchange 2013
Test-ImapConnectivity

The IMAP.Protocol health set monitors the IMAP4 protocol on the Mailbox server. If you receive an alert that
specifies that the IMAP.Protocol health set is unhealthy, this indicates an issue that affects the IMAP4 protocol on
the Mailbox server that’s indicated in the alert.
Explanation
The IMAP.Protocol health set works in conjunction with the IMAP health set.
User Action
For more information about the IMAP health set, see Troubleshooting IMAP Health Set.

POP3 and IMAP4

The IMAP.Proxy health set monitors the availability of the IMAP4 proxy infrastructure on the Client Access server
(CAS ). If you receive an alert that specifies that the IMAP.Proxy health set is unhealthy, this indicates an issue that
affects the IMAP components on the CAS that’s indicated in the alert.
Explanation
The IMAP.Proxy health set works in conjunction with the IMAP health set.
User Action
For more information about the IMAP health set, see Troubleshooting IMAP Health Set.

POP3 and IMAP4

health set:
this feature.

health set:
this feature.

The MailboxTransport health set monitors the overall health of the Mailbox Transport Submission and Mailbox
Transport Delivery services on Mailbox servers. These services are responsible for sending mail to and from
mailbox databases. For more information, see Mail flow.
If you receive an alert that indicates that the MailboxTransport health set is unhealthy, this indicates an issue that
may prevent mail from being sent or received from mailbox databases.
Explanation
The MailboxTransport service is monitored using the following probes and monitors.
MailboxDeliveryAvailability MailboxTransport MailboxDeliveryAvailabilityMonitor
MailboxDeliveryAvailabilityAggregat MailboxTransport MailboxDeliveryAvailabilityAggregat

ionProbe ionMonitor
MailboxDeliveryInstanceAvailabilityP MailboxTransport MailboxDeliveryInstanceAvailability

robe Monitor
MailboxTransportDeliveryServiceRun MailboxTransport MailboxTransportDeliveryServiceRu

ning nningMonitor
MailboxTransportSubmissionService MailboxTransport MailboxTransportSubmissionService

Running RunningMonitor
Mapi.Submit.Probe MailboxTransport Mapi.Submit.Monitor
none (notification or check) MailboxTransport CrashEvent.msexchangedelivery
none (notification or check) MailboxTransport CrashEvent.msexchangesubmission
none (notification or check) MailboxTransport DeliveryBackpressureSustainedTime

Monitor
none (notification or check) MailboxTransport DeliveryInterceptorStoreDriverAgen

tPctPermFailedMonitor
none (notification or check) MailboxTransport MailboxTransportUserQuarantineM

onitor
none (notification or check) MailboxTransport MBTSubmissionInterceptorSubmissi

onAgentMonitor
none (notification or check) MailboxTransport MSExchangeAsstAvgEventProcessin

gTimeSubmissionMonitor50
none (notification or check) MailboxTransport MSExchangeAsstAvgEventProcessin

gTimeSubmissionMonitor70
none (notification or check) MailboxTransport PrivateWorkingSetError.msexchang

edelivery
none (notification or check) MailboxTransport PrivateWorkingSetError.msexchang

esubmission
none (notification or check) MailboxTransport PrivateWorkingSetWarning.msexcha

ngedelivery
none (notification or check) MailboxTransport PrivateWorkingSetWarning.msexcha

ngesubmission
none (notification or check) MailboxTransport ProcessProcessorTimeError.msexcha

ngedelivery
none (notification or check) MailboxTransport ProcessProcessorTimeError.msexcha

ngesubmission
none (notification or check) MailboxTransport ProcessProcessorTimeWarning.msex

changedelivery
none (notification or check) MailboxTransport ProcessProcessorTimeWarning.msex

changesubmission
none (notification or check) MailboxTransport SubmissionBackpressureSustainedTi

meMonitor
none (notification or check) MailboxTransport SubmissionInterceptorSubmissionA

gentPctPermFailedMonitor
none (notification or check) MailboxTransport TransportDeliveryFailuresDeliverySt

oreDriver560Monitor
User Action
that the MailboxTransport health set is unhealthy, first verify that the issue still exists. If the issue does exist,
perform the appropriate recovery actions outlined in the following section.
Verifying the issue

For example, to retrieve the MailboxTransport health set details about mailbox1.contoso.com, run
Get-ServerHealth mailbox1.contoso.com | ?{$_.HealthSetName -eq "MailboxTransport"}
For example, assume that the failing monitor is MailboxDeliveryAvailabilityMonitor. The probe
associated with that monitor is MailboxDeliveryAvailability. To run this probe on
mailbox1.contoso.com, run the following command:
Invoke-MonitoringProbe MailboxTransport\MailboxDeliveryAvailabilityMonitor -Server

mailbox1.contoso.com | Format-List
d. In the command output, review the "Result" section of the probe. If the value is Succeeded, the issue
was a transient error, and it no longer exists.

health set:
this feature.

health set:
this feature.

health set:
this feature.

health set:
this feature.

The Mailbox Replication Service (MRS ) health set monitors the overall health of the MRS service.
Explanation
The MRS service is monitored by using the following probes and monitors.
MRSServiceCrashingPro MRS Information Store MRSServiceCrashingMo

be nitor
User Action

For example, to retrieve the MRS health set details about server1.contoso.com, run the following
command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "MRS"}
For example, assume that the failing monitor is MRSServiceCrashingMonitor. The probe
associated with that monitor is MRSServiceCrashingProbe. To run that probe on
Invoke-MonitoringProbe MRS\MRSServiceCrashingProbe -Server server1.contoso.com | Format-List
following sections.
Common Issues
You can use the information in the full exception trace to help troubleshoot the issue. The exception
generated by the probe contains a Failure Reason that describes why the probe failed.
Mailbox Locked
When a Mailbox is locked, you may receive an alert that resembles the following:
MailboxIdentity: namprd03.prod.outlook.com/Microsoft Exchange Hosted Organizations/example.com/User6
MailboxGuid: Primary (00000000 -abcd -01234 -5678 -1234567890ab ) RequestFlags: IntraOrg, Pull, Protected
Database: exampledb -db089 Exception: MapiExceptionADUnavailable: Unable to prepopulate the cache for user
…
This indicates that a mailbox is locked. To unlock the mailbox, run the following command:
New-MailboxRepairRequest -CorruptionType LockedMoveTarget -Identity <mailboxIdentity> [-Archive]
Note In this command, replace <mailboxIdentity> with the name of the mailbox that’s provided in the email
message as MailboxIdentity. If the mailbox is an archive mailbox, you must include the –Archive flag. You can
determine whether a mailbox is a primary or archive mailbox by viewing the MailboxGuid field in the alert.
Corrupt Migration Job
When a corrupted migration job occurs, you may receive an alert that resembles the following:
Notification thrown by MailboxMigration at 9/7/2012 9:08:32 PM. Details: Diagnostic Information:
ProcessCacheEntry: First Organization :: /o=ExchangeLabs/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT )/cn=Recipients/cn=e80fc128879e452ebc882f6bca7007fa -Migration.8
Corruption occurs when the migration meta-data has encountered issues. Upon corruption, Microsoft will receive
a Watson report that will be investigated.To recover from this issue, you must remove the migration batch, and
then re-create the batch. To do this, follow these steps:
1. To remove the corrupted batch, run the following command:
Remove-MigrationBatch -Identity
2. To re-create the batch job, run the following command:
New-MigrationBatch -Local -Name
For more information, see Exchange 2013 cmdlets

MailboxMigration alert: CriticalError
When a critical error occurs during mail migration, you may receive an alert that resembles the following:
Notification thrown by MailboxMigration at 9/7/2012 9:08:32 PM. Details: Diagnostic Information:
ProcessCacheEntry: First Organization :: /o=ExchangeLabs/ou=Exchange Administrative Group
(FYDIBOHF23SPDLT )/cn=Recipients/cn=e80fc128879e452ebc882f6bca7007fa -Migration.8
To resolve this issue, you must retry the migration. To do this, run the following command, or press the Start
button on the Exchange Administration Center (EAC ).
Call start-migrationbatch -Identity batchName
When this issue occurs, a Dr. Watson message is sent to Microsoft for investigation.
The Migration Exchange Replication Service is not running
When you see this error reason, you can verify the health of the service by running the following command:
Test-MRSHealth <servername> -MonitoringContext:$true
You can also try to start the service by running the following command:
Start-Service msexchangemailboxreplication
MSExchangeMailboxReplication RCP Ping Failed

When you see this error reason, you may receive an alert that resembles the following:
An issue with MRS was detected at 6/26/2012 6:08:47 AM. Details: MRS RPC Ping check for server
<ServerName> failed with the following error: The RPC endpoint for the Microsoft Exchange Mailbox Replication
service couldn't respond:
When this issue occurs, you can verify the health of the service by running the following command:
You can also try to restart the service by running the following command:
Restart-Service msexchangemailboxreplication
MSExchangeMailboxReplication Service is repeatedly crashing
When the MSExchangeMailboxReplication service crashes or stops responding, you may receive an alert that
resembles the following:
The MRS process has crashed at least 3 times in last 01:00:00. <b>Watson Message:</b> Watson report about to
be sent for process id: 41432, with parameters: E12, <ServerName>, 15.00.0516.024,
MSExchangeMailboxReplication, M.Exchange.MailboxReplicationService, M.E.M.BaseJob.BeginJob,
System.ApplicationException, 7ec9, 15.00.0516.024. ErrorReportingEnabled: True.
MSExchangeMailboxReplication is not scanning MDB queues

When the MSExchangeMailboxReplication service fails to scan queues, you may receive an alert that resembles
the following:
An issue with MRS was detected at 6/12/2012 6:20:44 PM. Details: MRS queue scan check for server
<servername> failed with the following error: The Microsoft Exchange Mailbox Replication Service isn't scanning
mailbox database queues for jobs. Last scan age: 04:38:02.1959439..
Additional troubleshooting steps

1. Start IIS Manager, and then connect to the server that is reporting the issue to verify that the
MSExchangeServicesAppPool application pool is running.
2. In IIS Manager, click Application Pools, and then recycle the MSExchangeServicesAppPool application
pool by running the following command from the Shell:
4. If the issue still exists, recycle the IIS service by using the IISReset utility, or by running the following
command:
Iisreset /noforce
section.

Troubleshooting MSExchangeCertificateDeployment Health

Set
health set:
this feature.

health set:
this feature.

health set:
this feature.

The OAB.Proxy health set monitors the availability of the offline address book (OAB ) proxy infrastructure on the
Client Access server (CAS ).
If you receive an alert that specifies that the OAB.Proxy is unhealthy, this indicates an issue that may prevent you
from using the OAB.
Explanation
The OAB service is monitored by using the following probes and monitors.
OABProxyTestProbe OAB.Proxy Active Directory OABProxyTestMonitor
Common issues
User Action

For example, to retrieve the OAB.Proxy health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "OAB.Proxy"}
For example, assume that the failing monitor is OABProxyTestMonitor. The probe associated with
that monitor is OABProxyTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe |OAB.Proxy\OABProxyTestProbe -Server server1.contoso.com | Format-List
following sections.
OABProxyTestMonitor Recovery Actions

1. Review the protocol logs on CAS. Protocol logs are located in the <exchange server installation
MSExchangeOABAppPool application pool is running on the CAS.
4. Click Application Pools, and then recycle the MSExchangeOABAppPool application pool by running the
following command from the Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeOABAppPool
section.

Offline address books

health set:
this feature.

health set:
this feature.

The Outlook.Proxy health set monitors the availability of the Outlook Anywhere proxy infrastructure on the Client
Access server (CAS ).
If you receive an alert that specifies that the Outlook.Proxy service is unhealthy, this indicates an issue that may
prevent users from accessing their mail.
Explanation
The Outlook.Proxy service is monitored by using the following probes and monitors.
OutlookProxyTestProbe Outlook.Proxy Active Directory OutlookProxyTestMonit

or
Common issues
The application pool that is hosted on the monitored CAS is not working correctly.
User Action

For example, to retrieve the Outlook.Proxy health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "Outlook.Proxy"}
For example, assume that the failing monitor is OutlookProxyTestMonitor. The probe associated
with that monitor is OutlookProxyTestProbe. To run that probe on server1.contoso.com, run the
following command:
Invoke-MonitoringProbe Outlook.Proxy\OutlookProxyTestProbe -Server server1.contoso.com | Format-

List
following sections.
OutlookProxyTestMonitor Recovery Actions

The time and date when the issue occurred.
1. Review the protocol logs on the CA servers. Protocol logs are located in the <exchange server installation
3. Start IIS Manager, and then connect to the server that’s reporting the issue to determine the
MSExchangeOABAppPool application pool is running on CAS server.
4. Click Application Pools, and then recycle the MSExchangeRpcProxyAppPool application pool by
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeRpcProxyAppPool
section.

Outlook Anywhere

The Outlook Web App (OWA) health set monitors the overall health of the Outlook Web App service.
If you receive an alert that specifies that Outlook Web App is unhealthy, this indicates an issue that may prevent
users from accessing their mailboxes by using Outlook Web App.
Explanation
The Outlook Web App service is monitored by using the following probes and monitors.
OwaCtpProbe Outlook Web App Active Directory OwaCtpMonitor

Information Store
Common issues
This probe can fail for several reasons. The following are some of the more common reasons:
The Outlook Web App application pool that’s hosted on the monitored Client Access server (CAS ) is not
responding, or the application pool that’s hosted on the Mailbox server is not responding.
The CAS is experiencing networking issues, and it can’t connect to the Mailbox server or the Domain
Controller.
The user’s database is not mounted, or the Information Store is inaccessible for that mailbox.
The Information Store is not responding.
User Action

a. Open Exchange Management Shell, and then run the following command to retrieve the details of
the health set that generated the alert:
Outlook Web App health set details about server1.contoso.com, run the following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "OWA"}
for the monitor that issued the alert is Unhealthy .
For example, to create an Exchange ActiveSync monitoring probe on server1.contoso.com, run the
following command:
Invoke-MonitoringProbe -Identity ActiveSync.Protocol\ActiveSyncSelfTestProbe -Server

server1.contoso.com
following sections.
OwaCtpMonitor Recovery Actions

An email alert from a health set contains the following information:
Note You can use the information in the full exception trace to help troubleshoot the issue. The exception
generated by the probe contains a Failure Reason that describes why the probe failed. For example, the
exception contains the following:
MissingKeyword An expected keyword was not found in the server response. In this case, the
exception contains the expected keywords.
NameResolution DNS resolution is failing to resolve a given server name.
NetworkConnection The Probe is receiving a network connection failure when it tries to connect
to the OWA app pool on CAFE.
UnexpectedHttpResponseCode Response had an unexpected HTTP code. For example, the
server returned a 503 HTTP code.
RequestTimeout The server took too long to respond to a client request.
ScenarioTimeout The probe finished successfully, but it took more than one minute to do this.
This usually indicates a system that is being overloaded.
OwaErrorPage Outlook Web App returned an error page. The name of the error that caused the
failure is usually available in the exception message.
OwaMailboxErrorPage Outlook Web App returned an error page that contains a Mailbox Store-
related error. This typically indicates that the Mailbox Store is down or that mailboxes are being
dismounted.
The exception trace contains an important field named FailingComponent. The probe tries to determine
the failure, such as in the following example:
Mailbox The probe can reach Outlook Web App, but it can’t connect to the Mailbox Store. In this
case, the probe failed, or the mailbox access latency caused the probe to fail and generate a
ScenarioTimeout error. When these kinds of failures occur, you should check the health of the
Mailbox servers.
Active Directory The probe can reach Outlook Web App, but it can’t connect to Active Directory.
In this case, the probe failed or the Active Directory call latencies may have caused the probe time-
out. When these types of failures occur, you should check the health of the Domain Controllers, and
also check the network connections between the CA and Mailbox servers, and Domain Controllers.
Owa This typically means that an error occurred inside the Outlook Web App layer. When these
kinds of failures occur, you must verify the health of the Outlook Web App process on the CA and
Mailbox servers, and also check the network connections.
The exception also contains the most recent HTTP request and response information that was received
before the probe failed. The escalation body contains the path to probe logs. You can use this information to
determine the full HTTP web requests and responses that were sent when the probe failed. This file
contains data only for failed probes because only failed attempts are logged. You can use this information to
obtain a more complete view of why the test failed.
How low the availability metric dropped (x%).
The full path to the folder that contains the full HTTP request traces for the probe. By default, this
information is located in the <ExchangeServer>\Logging\Monitoring\OWA\ClientAccessProbe folder.
The time and date when the alert occurred.
by using https:// <servername>/owa.
If this fails, test by using a different CA server to verify that the problem is occurring on a specific CAS, and
not on the Mailbox server.
2. Verify network connectivity between the CA and Mailbox servers. Use ping.exe to verify that each server is
responding.
3. Check for alerts on the OWA.Protocol health set that may indicate an issue that affects a specific Mailbox
server. For more information, see Troubleshooting OWA.Protocol Health Set.
4. Start IIS Manager, and then connect to the server that’s reporting the issue to verify that the
MSExchangeOwaAppPool application pool is running on the CAS.
5. In IIS Manager, verify that the Default website is running.
6. Locate the Mailbox Database for failed probes, and verify that the Mailbox database is active on a Mailbox
server and that the Mailbox Store is healthy. To locate the failed database GUID information, open the full
exception trace information. Each failure should contain an entry that resembles the following example:
Starting Owa probe with Target: https://localhost/owa/, Username:
*HealthMailboxdf8b87828ab0427cb91e985bbdfcec62@yourdomain.com*
7. Copy the HealthMailbox GUID, and then run the following command in the Shell:
Get-Mailbox -Monitoring -Identity <username>
For example, run the following command:
Get-Mailbox -Monitoring -Identity HealthMailboxdf8b87828ab0427cb91e985bbdfcec62@yourdomain.com
In the returned object, you can locate the user’s database name, and you can also determine where the
currently active database resides.
8. If you have configured redirection between sites, you may see probes failing and generating a
MissingKeyword error. This occurs because, by default, CA probes are run on accounts for any location, and
also because the probe does not try to test a CAS on a different site when it uses redirection. To resolve this
problem, make sure that the servers on each site are contained in MonitoringGroups. CA servers in a given
monitoring group test only together with Mailbox servers in the same group.
To determine the monitoring groups for your servers, run the following command:
Get-ExchangeServer | ft MonitoringGroup
To modify the monitoring group on a server, use the MonitoringGroup parameter together with the Set-
ExchangeServer cmdlet. For example, use the following:
Set-ExchangeServer -Identity "ServerName" -MonitoringGroup "Primary"
9. In IIS Manager, click Application Pools, and then recycle the MSExchangeOWAAppPool application
pool by running the following command from the Exchange Management Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeOWAAppPool
10. Rerun the associated probe, as shown in step 2c in the Verifying the issue still exists section.
command:
Iisreset /noforce
12. Rerun the associated probe, as shown in step 2c in the Verifying the issue still exists section.
14. After the server restarts, rerun the associated probe, as shown in step 2c in the Verifying the issue still exists
section.
15. If the probe continues to fail, you may require assistance to resolve this issue. Contact a Microsoft Support


The OWA.Protocol health set monitors the Outlook Web App protocol on the Mailbox server.
If you receive an alert that specifies that OWA.Protocol is unhealthy, this indicates an issue that may prevent users
from accessing their mailboxes by using Outlook Web App.
Explanation
The OWA service is monitored by using the following probes and monitors.
OwaSelfTestProbe OWA.Protocol None OwaSelfTestMonitor
OwaDeepTestProbe OWA.Protocol Active Directory OwaDeepTestMonitor

Information Store
The OwaSelfTestProbe probe sends a single HTTP request to the following address:
https://localhost:444/owa/exhealth.check. The probe confirms that the application pool is responding by returning
a 200 OK status code. This probe has no dependency on any other Exchange component.
The OwaDeepTestProbe probe is run against each Mailbox database by using copies on the current server. The
probe determines that a full logon can be made against that server. To do this, it simulates the type of traffic that’s
generated by a Client Access server (CAS ) against that specific server. The probe depends on Active Directory
Domain Services (AD DS ) for authentication, and on the Mailbox Store for mailbox access. For more information
about probes and monitors, see Server health and performance.
Common issues
The OWA application pool that’s hosted on the monitored CAS is not responding, or the application pool
that’s hosted on the Mailbox server is not responding.
The CA or Mailbox server is experiencing networking issues, and it can’t connect to the other server or to a
Domain Controller.
The user’s database is not mounted, or the Information Store is inaccessible for that mailbox.
The Information Store is not responding.
User Action

For example, to retrieve the OWA.Protocol health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "OWA.Protocol"}
b. Review the command output to determine which monitor reported the error. The AlertValue for the
monitor that issued the alert will be Unhealthy .
For example, assume that the failing monitor was OwaSelfTestMonitor. The probe associated with
that monitor is OwaSelfTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe OWA.Protocol\OwaSelfTestProbe -Server server1.contoso.com | Format-List
following sections.
Type of probe that failed (SelfTest or DeepTest)
Path to the folder in which you can find the full HTTP request traces for the probe
By default, the trace files are located in the following folders:
SelfTestProbe: <ExchangeServer>\Logging\Monitoring\OWA\ProtocolProbe
DeepTestProbe: <ExchangeServer>\Logging\Monitoring\OWA\MailboxProbe
generated by the probe contain a Failure Reason that describes why the probe failed. The Failure Reason
may be any of the following:
MissingKeyword An expected keyword was not found in the server response. In this case, the
exception contains the expected keywords.
NameResolution The DNS resolution is failing to resolve a given server name.
NetworkConnection The probe is receiving a network connection failure when it tries to connect
to the OWA application pool on CAFE.
UnexpectedHttpResponseCode The response contained an unexpected HTTP code. For example,
the server returned a 503 HTTP code.
RequestTimeout The server took too long to respond to a client request.
UnexpectedHttpResponseCode The response returned an unexpected HTTP code. For example,
the server returned a 503 HTTP code.
ScenarioTimeout The probe finished successfully, but took more than one minute to do so. This
usually indicates a system that’s being overloaded.
OwaErrorPage OWA returned an error page. The name of the error that caused the failure is
typically available on the exception message.
OwaMailboxErrorPage OWA returned an error page that contains a Mailbox Store-related error.
This usually indicates such problems as the Mailbox Store being down, or mailboxes that are being
dismounted.
The exception trace contains an important field named FailingComponent, in which the probe makes an
effort to try to determine and categorize the failure. For example, the probe may return any of the following
values:
Mailbox The probe can reach OWA, but it can’t connect to the Mailbox store. In this case, the probe
failed or the mailbox access latency caused the probe to fail and generate a ScenarioTimeout error.
When these types of failures occur, you should check the health of the Mailbox servers.
Active Directory The probe can reach OWA, but it can’t connect to AD DS. In this case, the probe
failed, or the AD DS call latencies may cause the probe to time-out. When these kinds of failures
occur, you should check the health of the Domain Controllers, and also check the network
connections between the CA and Mailbox servers and the Domain Controllers.
OWA This typically means that an error occurred inside the OWA layer. When these kinds of
failures occur, you must verify the health of the OWA process on the CA and Mailbox server, and also
check the network connections.
The exception also contains the most recent HTTP request and response information that was received
before the probe failed.
The escalation body contains the path to the probe logs that can be used to verify the full HTTP web
requests and responses that were sent when the probe failed. This file contains data only for failed probes
because only failed attempts are logged. You can use this information to obtain a more complete view of
why the test failed.
OwaSelfTestProbe Recovery Actions

Because this probe has very few dependencies, failures typically occur when the OWA application pool process is
not responding.
1. Click the probe trace log URL in the alert email message body to verify that new failures are occurring.
2. Create a test user account on the same server on which the mailbox is mounted. Try to log on to determine
whether the problem can be reproduced.
3. Check for alerts on the OWA health set that may indicate an issue that affects a specific Mailbox server. For
more information, see Troubleshooting OWA Health Set.
pool by running the following command from the Exchange Management Shell:
command:
Iisreset /noforce
section.
OwaDeepTestProbe Recovery Actions

1. To determine whether the issue still exists, create a test user account on the same server on which the
mailbox is mounted, and then try to log on to OWA. For example, try to log on by using: https://
<servername>/owa.
2. Check for alerts on the OWA health set that may indicate an issue that affects a specific Mailbox server. For
more information, see Troubleshooting OWA Health Set.
3. Start IIS Manager, and then connect to the server that is reporting the issue to determine whether the
5. Locate the Mailbox database for failed probes, and verify that the Mailbox database is active on the Mailbox
server and that the Mailbox Store is healthy. To locate the failed database GUID information, open the full
exception trace information. Each failure should contain an entry that resembles the following:
Starting Owa probe with Target: https://localhost/owa/, Username:
HealthMailboxdf8b87828ab0427cb91e985bbdfcec62@yourdomain.com
6. Copy the HealthMailbox GUID, and then run the following command in the Shell:
Get-Mailbox -Monitoring -Identity <username>
For example, run the following command:
Get-Mailbox -Monitoring -Identity HealthMailboxdf8b87828ab0427cb91e985bbdfcec62@yourdomain.com
In the returned object, you can locate the user’s database name, and you can also determine where the
currently active database resides.
command:
Iisreset /noforce
section.


The OWA.Protocol.DEP health set monitors the overall health of instant messaging (IM ) services in Outlook
Web App that are integrated between Lync 2013 and Exchange 2013. For more information about enabling instant
messaging in Outlook Web App, see Integrating Microsoft Lync Server 2013 and Microsoft Outlook Web App
2013.
If you receive an alert that indicates that the OWA.Protocol.DEP health set is unhealthy, this indicates an issue
that may prevent instant messaging from working correctly in Outlook Web App.
Explanation
The OWA.Protocol.DEP service is monitored using the following probes and monitors.
none (notification or check) OWA.Protocol.DEP OwaIMInitializationFailedMonitor
none (notification or check) OWA.Protocol.DEP WacDiscoveryFailureEventMonitor
User Action
that the OWA.Protocol.DEP health set is unhealthy, first verify that the issue still exists. If the issue does exist,
perform the appropriate recovery actions outlined in the following sections.
Recovery actions for error:

"InstantMessageOCSProvider.InitializeEndpointManager. No registry
setting for IM Provider."
This error indicates a required registry key is missing on the Mailbox server. This registry key should have been
configured when the Microsoft Unified Communications Managed API (UCMA) 4.0 was installed on the server.
The missing registry key is:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchange OWA\InstantMessaging
This key should contain an ImplementationDLLPath string that points to the Microsoft.Rtc.Internal.Ucweb DLL.
The default location is C:\Program Files\Microsoft UCMA 4.0\Runtime\SSP\Microsoft.Rtc.Internal.Ucweb.dll .
To fix this issue, reinstall UCMA 4.0 or manually create the registry key. You can download UCMA 4.0 here: Unified
Communications Managed API 4.0 Runtime.
Recovery actions for error:

"InstantMessageOCSProvider.InitializeEndpointManager. IM provider
not found."
This error indicates the Microsoft.Rtc.Internal.Ucweb DLL file is missing on the Mailbox server. This file should
have been installed when UCMA 4.0 was installed on the server. The default location is
C:\Program Files\Microsoft UCMA 4.0\Runtime\SSP .
To fix this issue, reinstall UCMA 4.0. For more information, see Unified Communications Managed API 4.0
Runtime.
Recovery actions for error: "Instant Messaging Server name is set to

null or empty on web.config."
This error indicates the Lync 2013 server isn't defined in the Outlook Web App application configuration
(web.config) file on the Mailbox server. This web.config file is located at %ExchangeInstallPath%ClientAccess\Owa ,
and should contain a key named IMServerName that specifies the FQDN of the Lync 2013 server. To fix this
issue, follow these steps:
1. In a Command prompt window, open the Outlook Web App web.config file in Notepad by running the
following command:
Notepad %ExchangeInstallPath%ClientAccess\Owa\web.config
2. Search for a key named IMServerName. If it's found, verify the FQDN of the Lync 2013 server. If the key is
not found, add it by performing the following steps.
a. Find the tag named <appSection>.
b. In the <appSection> node, add the following line:
<add key="IMServerName" value="Lync Server FQDN" />
For example:
<add key="IMServerName" value="lync01.contoso.com" />
c. To apply the changes in Outlook Web App, run the following command:
%windir%\system32\inetsrv\appcmd.exe recycle apppool /apppool.name:"MSExchangeOWAAppPool"
Recovery actions for error: "Instant Messaging Certificate Thumbprint

is null or empty on web.config."
This error indicates the certificate that's used to integrate Lync 2013 and Outlook Web App isn't defined in the
Outlook Web App application configuration (web.config) file on the Mailbox server. This web.config file is located
at %ExchangeInstallPath%ClientAccess\Owa , and should contain a key named IMCertificateThumbprint that
specifies the certificate's thumbprint (hash).
You can get the certificate's thumbprint value by using the Get-ExchangeCertificate cmdlet, or in the Exchange
admin center (EAC ) at Servers > Certificates.
To fix this issue, follow these steps:
1. In a Command prompt window, open the Outlook Web App web.config file in Notepad by running the
following command:
Notepad %ExchangeInstallPath%ClientAccess\Owa\web.config
2. Search for a key named IMCertificateThumbprint. If it's found, verify the thumbprint value is correct. If
the key is not found, add it by performing the following steps:
a. Find the tag named <appSection>.
b. In the <appSection> node, add the following line:
<add key="IMCertificateThumbprint" value="thumbprint"/>
For example:
<add key="IMCertificateThumbprint" value="35CB4C441D55506C88E59B7946B567A4F45B3B5C" />
c. To apply the changes in Outlook Web App, run the following command:
%windir%\system32\inetsrv\appcmd.exe recycle apppool /apppool.name:"MSExchangeOWAAppPool"
Recovery actions for error: "IM Certificate with thumbprint

<value> could not be found."
This error indicates the certificate that's used to integrate Lync 2013 and Outlook Web App isn't found on the
Mailbox server. This certificate must be installed on the Mailbox server and the Lync 2013 server, and must be
trusted by both servers. For more information about the certificate requirements, see the Enabling Instant
Messaging on Outlook Web App section in Integrating Microsoft Lync Server 2013 and Microsoft Outlook Web
App 2013.
You can match he thumbprint value in the error to the certificate by using the Get-ExchangeCertificate cmdlet,
or in the Exchange admin center (EAC ) at Servers > Certificates.
Recovery actions for error: "IM Certificate has expired."

This error indicates the certificate that's used to integrate Lync 2013 and Outlook Web App has expired. To resolve
this error, you need to renew the certificate.
You can match he thumbprint value in the error to the certificate by using the Get-ExchangeCertificate cmdlet,
or in the Exchange admin center (EAC ) at Servers > Certificates.
Recovery actions for error: "IM Certificate has not become valid yet."
This error indicates the certificate that's used to integrate Lync 2013 and Outlook Web App has invalid dates. To
resolve this error, you need to configure a new certificate, and you need to add the new thumbprint value in the
IMCertificateThumbprint key in %ExchangeInstallPath%ClientAccess\Owa\web.config . For more information
about the certificate requirements, see the Enabling Instant Messaging on Outlook Web App section in Integrating
Microsoft Lync Server 2013 and Microsoft Outlook Web App 2013.
Recovery actions for error: "IM Certificate does not have a private key."
This error indicates the certificate that's used to integrate Lync 2013 and Outlook Web App does not have a private
key. To resolve this error, you need to configure a new certificate that has a private key, and you need to add the
new thumbprint value in the IMCertificateThumbprint key in %ExchangeInstallPath%ClientAccess\Owa\web.config
. For more information about the certificate requirements, see the Enabling Instant Messaging on Outlook Web
App section in Integrating Microsoft Lync Server 2013 and Microsoft Outlook Web App 2013.

The OWA.Proxy health set monitors the overall health of the Outlook Web App service.
If you receive an alert that specifies that the OWA.Proxy is unhealthy, this indicates an issue that may prevent users
from using the Outlook Web App service.
Explanation
The Outlook Web App service is monitored by using the following probes and monitors.
OWAProxyTestProbe OWA.Proxy Active Directory OWAProxyTestMonitor
OWAanonymouscalenda OWA.Proxy Active Directory OWAProxyTestMonitor

rProbe
Common issues
The application pool that’s hosted on the monitored Client Access server (CAS ) is not working correctly.
User Action

For example, to retrieve the OWA.Proxy health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "OWA.Proxy"}
For example, assume that the failing monitor is OWAProxyTestMonitor. The probe associated with
that monitor is OWAProxyTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe OWA.Proxy\OWAProxyTestProbe -Server server1.contoso.com | Format-List
following sections.
OWAProxyTestMonitor Recovery Actions

1. Review the protocol logs on the CA servers. Protocol logs are located in the <exchange server installation
MSExchangeServicesAppPools application pools are running on the CAS.
4. Click Application Pools, and then recycle the MSExchangeOWAAppPool and
MSExchangeOWACalendarAppPool application pools by running the following command from the
Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle APPPOOL MSExchangeOWAAppPool
%SystemRoot%\System32\inetsrv\Appcmd recycle APPPOOL MSExchangeOWACalendarAppPool
section.

Managing Outlook Web App

The POP health set monitors the overall health and availability of the Microsoft Exchange POP3 service and POP3
client connectivity. The POP health set is closely related to the following health sets:
If you receive an alert that specifies that the POP service is unhealthy, this indicates an issue that may prevent
users from accessing their mailboxes by using POP3 in the Exchange environment.
Explanation
The POP service is monitored by using the following probes and monitors.
PopCTPProbe POP Active Directory PopCTPMonitor (POP

health set)
Authentication
Mailbox Server
Authentication
Information Store
High Availability
Network
PopProxyTestProbe POP.Proxy None PopProxyTestMonitor

(POP.Proxy health set)
PopDeepTestProbe POP.Protocol Active Directory PopDeepTestMonitor

(POP.Protocol health
Authentication set)
Information Store
High Availability
PopSelfTestProbe POP.Protocol None PopSelfTestMonitor

(POP.Protocol health
set)
AverageCommandProce
ssingTimeGt60sMonitor
(POP health set)
User Action

For example, to retrieve the POP health set details about server1.contoso.com, run the following
command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "POP"}
For example, assume that the failing monitor is PopCTPMonitor. The probe associated with that
monitor is PopCTPProbe. To run that probe on server1.contoso.com, run the following command:
Invoke-MonitoringProbe POP\PopCTPProbe -Server server1.contoso.com | Format-List
following sections.
PopTestDeepMonitor and PopSelfTestMonitor Recovery Actions

This monitor alert is typically issued on Mailbox servers.
1. Restart the POP3 back-end service. For more information, see Start and stop the POP3 services.
3. If the probe still fails, failover the databases that are hosted on the Mailbox server by using the following
command:
4. After all the databases are removed from the Mailbox server, you must verify that the databases have been
moved successfully. To do this, run the following command:
Get-MailboxDatabaseCopyStatus -Server <ServerName> | group status
5. Make sure that the server does not host any active copies of the database. Then, restart the server.
6. After the server has successfully restarted, rerun the associated probe as shown in step 2c in the Verifying
the issue still exists section.
Set-MailboxServer -Identity <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $false
POPCTPMonitor Recovery Actions

This monitor alert is typically issued on CA servers (CAS ).
1. Restart the POP3 service on the servers that are running the CAS role. For more information, see Start and
stop the POP3 services.
3. If the issue still exists, run the following commands in Windows PowerShell:
a. Set-PopSettings -server <CAS server name> -ProtocolLoggingEnabled $true
b. Restart the POP3 service on the servers that are running the CAS role.
c. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
d. Run the following command, and then find the location of the log file:
Get-PopSettings -server <CAS server name>
e. Run the following command to determine which mailbox is serving the command by comparing
time stamps with the probe:
Get-ServerHealth <mailbox server name> | ?{ $_.HealthSetName -like "POP*"}
f. If any of these servers are reported as unhealthy, follow the steps listed in the PopTestDeepMonitor
and PopSelfTestMonitor Recovery Actions section.
4. If the Mailbox server is reported as healthy, restart the CAS.
5. After the server restarts, rerun the associated probe as described in step 2c in the Verifying the issue still
exists section.
6. Turn off protocol logging by running the following command:
Set-PopSettings -server <CAS server name> -ProtocolLoggingEnabled $false
PopProxyTestMonitor recovery actions

3. If the probe continues to fail, restart the CAS.
4. After the server restarts, rerun the associated probe as described in step 2c in the Verifying the issue still
exists section.
AverageCommandProcessingTimeGt60sMonitor recovery actions

This monitor alert is typically issued on CA or Mailbox servers.
1. Restart the POP3 service on the CA or Mailbox servers. For more information, see Start and stop the POP3
services.
2. Wait 10 minutes to see whether the monitor stays healthy. After 10 minutes, run the following command
(the example uses server1.contoso.com).
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -like "POP*"}
3. If the issue still exists, you need to restart the server. If the server is a CAS, just restart the server. If the
server is a Mailbox server, you must failover the database, and verify the results. To do this, follow these
steps:
a. Failover the databases hosted on the server by using the following command:
name.
b. Verify that all databases have been moved off the server that’s reporting the issue. To do this, run the
following command:
Get-MailboxDatabaseCopyStatus -Server <ServerName> | group status
4. After the server restarts, wait 10 minutes, and then run the command shown in step 2 again to see whether
the monitor stays healthy.
5. If the monitor is healthy, and this is a Mailbox server, failover the databases back to the Mailbox server by
running the following command:
Set-MailboxServer -Identity <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $false

Start and stop the POP3 services
Test-PopConnectivity

The POP.Protocol health set monitors the Microsoft Exchange POP3 protocol on the Mailbox server. If you receive
an alert that specifies that the POP.Protocol health set is unhealthy, this indicates an issue that affects the POP3
protocol on the Mailbox server indicated in the alert.
Explanation
The POP.Protocol health set works in conjunction with the POP health set. For detailed information about all POP
health sets, see Troubleshooting POP Health Set.

POP3 and IMAP4

The POP.Proxy health set monitors the availability of the Microsoft Exchange POP3 proxy infrastructure on the
Client Access server (CAS ). If you receive an alert that specifies that the POP.Proxy health set is unhealthy, this
indicates an issue that affects the POP components on the CAS indicated in the alert.
Explanation
The POP.Proxy health set works in conjunction with the POP health set.
User Action
For detailed information about the POP health set, see Troubleshooting POP Health Set.

POP3 and IMAP4

health set:
this feature.

health set:
this feature.

health set:
this feature.

health set:
this feature.

health set:
this feature.

The RPS.Proxy health set monitors the overall health of the Remote PowerShell service.
If you receive an alert specifying that the RPS.Proxy is unhealthy, this indicates an issue that might prevent you
from using Remote PowerShell to access Exchange.
Explanation
The RPS service is monitored using the following probes and monitors:
RPSProxyTestProbe RPS.Proxy Active Directory RPSProxyTestMonitor
Common issues
When this probe fails there can be multiple reasons for the problem. Some of the more common issues include the
following:
The application pool that is hosted on the monitored CAS server is not working properly.
User Action
It is possible that the service was able to recover after issuing the alert. Therefore, when you receive an alert that
specifies that the health set is unhealthy, the first thing you should do is to verify that the issue still exists. If it does,
then perform the appropriate recovery actions outlined in the following sections.

2. The message details provide information about what exactly caused the alert to be raised. In most cases, the
message details would provide sufficient troubleshooting information to identify the root cause. If the
message details are not clear, do the following:
a. Open Exchange Management Shell and run the following command to retrieve the details of the
For example, to retrieve the RPS.Proxy health set details on server1.contoso.com run the following
command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "RPS.Proxy"}
b. Review the command output and determine the monitor that reported the error. The AlertValue for
the monitor that issued the alert will read Unhealthy .
c. Rerun the associated probe for the monitor that is in unhealthy state. Refer to the table in the
Explanation section to find the associated probe. To do so, run the following command:
For example, let's assume that the failing monitor was RPSProxyTestMonitor. The probe associated
with that monitor is RPSProxyTestProbe. To run that probe on server server1.contoso.com, run the
following command:
Invoke-MonitoringProbe RPS.Proxy\RPSProxyTestProbe -Server server1.contoso.com | Format-List
d. In the command output, review the Result of the probe. If the value is Succeeded, then the issue
was a transient error and no longer exists. Otherwise refer to the recovery steps outlined in the
following sections.
RPSProxyTestMonitor Recovery Actions

When receiving an alert from a health set, the email will contain the following information:
The name of the CAS server that sent the alert.
Full exception trace including eroor messages, diagnostic data and specific HTTP header information. The
information in the full exception trace can be used to help troubleshoot the issue.
The time and date when the issue occurred.
To help troubleshoot this issue, perform the following:
1. Review the protocol logs on CAS servers. Protocol logs are located in the <exchange server installation
directory>\Logging\HttpProxy*\<protocol>* folder on the CAS server.
2. Create a test user account, and then logon to the CAS server by using the test user account, for example
https:// <servername>/owa
3. Start IIS Manager and connect to the server that is reporting the issue and verify that the
MSExchangePowerShellFrontEndAppPool is running on CAS server.
4. Click on Application Pools, and then recycle the MSExchangePowerShellFrontEndAppPool
application pool by running the following command from the Exchange Management Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangePowerShellFrontEndAppPool
6. If the issue still exists, recycle the IIS service using the IISReset utility.
9. After the server restarts, rerun the associated probe as shown in step 2.c. in the Verifying the issue still exists
section.
10. If the probe continues to fail, you may need assistance in resolving this issue. Contact a Microsoft Support


health set:
this feature.

The SiteMailbox Health set monitors the overall health and accessibility of the site mailboxes in your organization.
If you receive an alert that specifies that SiteMailbox is unhealthy, this indicates that the contents of a user’s
mailbox are not in a synchronized state.
Explanation
The SiteMailbox monitoring system receives passive sync results from the background synchronization service.
This system does not use any probes. The passive synchronization results are written to the SiteMailbox
monitoring system after every synchronization attempt. Synchronizations are also triggered when the following
events occur:
Users access their site mailboxes by using Outlook or Outlook Web App
You run the Update-SiteMailbox command
You open the Outlook Web App Options window, and then you click the Start Sync button on the Sync
Status page for the selected site mailbox
For more information about the Update-SiteMailbox cmdlet, see: Update-SiteMailbox
Common issues
The synchronization monitoring service typically triggers an alert when site-wide spread synchronization issues
occur. An alert is not sent when a single site mailbox fails to synchronize. To determine the cause of an above-
threshold alert for a single site mailbox, we recommend that you review the site mailbox synchronization log files.
User Action

For example, to retrieve the SiteMailbox health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "SiteMailbox"}
Background synchronization errors
When the background synchronization process fails, you may receive an alert that resembles the following:
The Site Mailbox background sync is failing at least 25%: 41 failures out of 87 attempts.Sample sync result:
[Message:The remote server returned an error: (401) Unauthorized.][Type:System.Net.WebException]
This alert is triggered when a consistently high percentage of synchronization failures have occurred during the
previous four hours. To avoid false negatives, an alert is sent only when the following conditions are met within a
15-minute window during the previous four hours:
At least 20 failures occur within a 15-minute window.
The percentage of failures compared to total attempts exceed 25 percent within a 15-minute window.
Every site mailbox in Exchange is linked to an SharePoint site. For each of the site mailboxes on a given Exchange
server that is hosting the Mailbox role, the server synchronizes site mailbox-related information from SharePoint.
Two types of syncs take place during this process: membership sync and document sync. The metadata for these
sync processes originates from different web services. Additionally, a given Exchange server may contain site
mailboxes that are linked to several SharePoint servers or farms. Therefore, the alert may originate from multiple
Mailbox servers, depending on the following conditions:
1. How actively-used site mailboxes in the organization are distributed
2. The SharePoint servers to which the actively-used site mailboxes are linked
3. Whether the Mailbox server has sufficient sync volume to meet alert thresholds
To help resolve this issue, the sample synchronization result in the alert may help determine the cause of the
failure. Details about the success or failure of each sync attempt is recorded in the *<exExchangeSvrNoVersion
installation directory>*Logging\TeamMailbox folder. Review the most recent
Microsoft.Exchange.ServiceHost_TeamMailboxSyncLog* files for failures by searching on the term failed. You can
also use the Test-OAuthConnectivity, Test-SiteMailbox, and Get-SiteMailboxDiagnostics cmdlets to
troubleshoot further.
The MSExchangeServiceHost service is not running
If the MSExchangeServiceHost service is not running, you receive an alert that resembles the following:
The 'MSExchangeServiceHost' service is not running after the recovery attempts. The service may be disabled or
in crash loop.
To resolve this issue, verify that the MSExchangeServiceHost service is running on the server that sent the alert. If
the service is running, review the Windows event logs for indications of why the service may not have been
running earlier, such as manual service control or repeated crashes of the service.
The MSExchangeServiceHost service has crashed
If the MSExchangeServiceHost service crashes, you receive an alert that resembles the following:
The MSExchangeServiceHost process has crashed at least 3 times in last 60 minutes.
Watson Message:
<Message>
To resolve this issue, review the Windows Application event log on the server that sent the alert for 4999 events
regarding the MSExchangeServiceHost service. The detail text can provide information about the cause of the
issue.


health set:
this feature.

health set:
this feature.

health set:
this feature.

The Unified Messaging (UM ) health set monitors the overall health of the UM service in your organization.
If you receive an alert that specifies that UM is unhealthy, this indicates an issue that may prevent users from
using the UM service in your organization. The UM health set is closely related to the following health sets:
Explanation
The UM service is monitored by using the following probes and monitors.
UMSelfTestProbe UM.Protocol Active Directory Domain UMSelfTestMonitor

Services (AD DS)
UMCallRouterTestProbe UM.CallRouter Active Directory Domain UMCallRouterTestMonit

Services (AD DS) or
User Action

For example, to retrieve the UM.Protocol health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "UM.Protocol"}
For example, assume that the failing monitor is UMSelfTestMonitor. The probe associated with
that monitor is UMSelfTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe UM.Protocol\UMSelfTestMonitor -Server server1.contoso.com | Format-List
following sections.
Sip Options to UM Service have failed
Determine whether the UM service is disabled. If the UM service is not started or disabled, restart the UM service.
More than {0}% of Inbound Calls were Rejected by the UM Service Over the Last Hour
Review the event logs on the Client Access server (CAS ) to determine whether the UM objects, such as
umipgateway and umhuntgroup, are configured correctly.
If the event logs do not contain enough information, you may have to enable UM event logs at the Expert level,
and then review the UM trace log files.
More than {0}% of Inbound Calls were Rejected by the UM Worker Process Over the Last Hour
Review the event logs on the CAS to determine whether the UM objects, such as the umipgateway and
umhuntgroup objects, are configured correctly.
Less than {0}% of Messages were Successfully Processed Over the Last Hour
The Microsoft Exchange Unified Messaging service rejected a call because the UM pipeline is full
The A/V Edge service is misconfigured or is not running
1. Review the event logs on Mailbox server to try to determine why calls from the Lync server are failing.
Then, do the following:
Make sure that the Lync pool that is selected by the UM service is operational.
To use a specific Lync server, run the following command:
Set-UMServer ExchangeUMServer -SIPAccessService <ServerName>
The UM server was unable to acquire credentials successfully with the Communications Server A/V
Edge service
Review the event logs to investigate which Lync pool is selected, and to verify that the selected Lync pool is
operational.
The Communications Server Audio/Video Edge was unable to open a port or allocate resources while
attempting to establish a session
Review the event logs to investigate which Lync pool is selected, and to verify that the selected Lync pool is
operational.
The Microsoft Exchange Unified Messaging service certificate is nearing its expiration date
Renew the UM service certificate on the Mailbox server.
Additional troubleshooting steps:
1. Start IIS Manager, and connect to the server that’s reporting the issue to determine whether the
pool. To do this, run the following command from the Exchange Management Shell:
command:
Iisreset /noforce
section.


The Microsoft Exchange Unified Messaging (UM ) Call Router health set monitors the overall health of the UM
Call Router service.
If you receive an alert that specifies that UM is unhealthy, this indicates an issue that may prevent users from
using the UM service in your organization. The UM health set is closely related to the following health sets:
Explanation
The UM.Protocol service is monitored by using the following probes and monitors
UMCallRouterTestProbe UM.CallRouter Active Directory Domain UMCallRouterTestMonit

Services (AD DS) or
User Action

For example, to retrieve the UM.CallRouter health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "UM.CallRouter"}
For example, assume that the failing monitor is UMCallRouterTestMonitor. The probe associated
with that monitor is UMCallRouterTestProbe. To run that probe on server1.contoso.com, run the
following command:
Invoke-MonitoringProbe UM.CallRouter\UMCallRouterTestProbe -Server server1.contoso.com | Format-

List
following sections.
Sip Options to UM Call Router Service have failed
Determine whether the UM Call Router service is disabled. If the UM Call Router service is not started or disabled,
restart the UM service.
More than 50% of Inbound Calls were Rejected by the UM Call Router over the Last Hour
Review the event logs on the Client Access server (CAS ) to determine whether the UM objects, such as
umipgateway and umhuntgroup, are configured correctly.
More than {0}% of Missed Call Notification Proxy failed at UM Call Router over the Last Hour
Review the event logs on the CAS to determine whether the UM objects, such as umipgateway and
umhuntgroup, are configured correctly.
The Microsoft Exchange Unified Messaging Call Router certificate is nearing its expiration date
Renew the UM Call Router service certificate on the CAS.
Additional troubleshooting steps:
command:
Iisreset /noforce
section.


The UM.Protocol health set monitors the Unified Messaging (UM ) protocol on the Mailbox server.
If you receive an alert that specifies that UM.Protocol is unhealthy, this indicates an issue that may prevent users
from using the UM service in your organization. The UM.Protocol health set is closely related to the following
health sets:
Explanation
The UM.Protocol service is monitored by using the following probes and monitors.
UMSelfTestProbe UM.Protocol Active Directory Domain UMSelfTestMonitor

Services (AD DS)
User Action

For example, to retrieve the UM.Protocol health set details about server1.contoso.com, run the
following command:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "UM.Protocol"}
For example, assume that the failing monitor is UMSelfTestMonitor. The probe associated with
that monitor is UMSelfTestProbe. To run that probe on server1.contoso.com, run the following
command:
Invoke-MonitoringProbe UM.Protocol\UMSelfTestMonitor -Server server1.contoso.com | Format-List
following sections.
For more information about troubleshooting UJM alert messages, see Troubleshooting UM Health Set


health set:
this feature.

HealthSet Guide

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

HealthSet Guide

Enviado por

Direitos autorais:

Formatos disponíveis

Contents

Exchange 2013 Management Pack Health Sets

Exchange 2013 Management Pack Health Sets

For more information

Troubleshooting ActiveSync Health Set

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

ActiveSyncCTPProbe ActiveSync Active Directory ActiveSyncCTPMonitor

ActiveSyncProxyTestPro ActiveSync.Proxy - ActiveSyncProxyTestMo

ActiveSyncDeepTestProb ActiveSync.Protocol Active Directory ActiveSyncDeepTestMon

ActiveSyncSelfTestProbe ActiveSync.Protocol Active Directory ActiveSyncSelfTestMonit

Verifying the issue

Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}

Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "ActiveSync"}

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

Invoke-MonitoringProbe ActiveSync\ActiveSyncCTPProbe -Server server1.contoso.com | Format-List

Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $true

Get-MailboxDatabaseCopyStatus -Server server1.contoso.com | Group Status

Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $false

ActiveSyncCTPMonitor Recovery Actions

Get-ServerHealth mailbox1.contoso.com | ?{$_.HealtSetName -like "ActiveSync*"}

RequestsQueuedGt500Monitor Recovery Actions

Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -like "ActiveSync*"}

Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $true

Get-MailboxDatabaseCopyStatus -Server server1.contoso.com | Group Status

Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $false

For More Information

Troubleshooting ActiveSync.Protocol Health Set

For More Information

Troubleshooting ActiveSync.Proxy Health Set

For More Information

Troubleshooting AD Health Set

Troubleshooting Antimalware Health Set

Troubleshooting AntiSpam Health Set

Troubleshooting Autodiscover Health Set

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

AutodiscoverCtpProbe Autodiscover Active Directory AutodiscoverCtpMonito

Verifying the issue still exists

Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}

Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "Autodiscover"}

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

Invoke-MonitoringProbe Autodiscover\AutodiscoverCtpProbe -Server server1.contoso.com | Format-

AutodiscoverCtpMonitor Recovery Actions

%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeAutodiscoverAppPool

For More Information

Troubleshooting Autodiscover.Protocol Health Set

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

AutodiscoverSelfTestPro Autodiscover.Protocol Active Directory AutodiscoverSelfTestMo

Verifying the issue still exists

Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "Autodiscover.Protocol"}

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

Invoke-MonitoringProbe Autodiscover.Protocol\AutodiscoverSelfTestProbe -Server

AutodiscoverSelfTestProbe Recovery Actions

%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeAutodiscoverAppPool

For More Information

Troubleshooting Autodiscover.Proxy Health Set

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

AutoDiscoverProxyTestP Autodiscover.Proxy Active Directory AutodiscoverProxyTestM

Verifying the issue still exists

Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}

Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "Autodiscover.Protocol"}

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

Invoke-MonitoringProbe Autodiscover.Protocol\AutodiscoverSelfTestProbe -Server

AutodiscoverProxyTestMonitor Recovery Actions