You are on page 1of 152

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

For more information


Exchange Server 2013 Management Pack Guide
Server health and performance
10/5/2018 • 7 minutes to read • Edit Online

Troubleshooting ActiveSync Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting ActiveSync.Protocol Health Set
Troubleshooting ActiveSync.Proxy Health Set
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
PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

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.
4. Rerun the associated probe as shown in step 2c in the Verifying the issue section.
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 ).
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 is 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.
4. Rerun the associated probe as shown in step 2c in the Verifying the issue section.
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
organization may have a specific procedure for directly contacting Microsoft Product Support Services, be
sure to review your organization's guidelines first.

RequestsQueuedGt500Monitor Recovery Actions


This monitor alert is typically issued on CA servers.
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 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:

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

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:

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

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:

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

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
organization may have a specific procedure for directly contacting Microsoft Product Support Services, be
sure to review your organization's guidelines first.

For More Information


Exchange ActiveSync
Mobile devices
Exchange ActiveSync virtual directory management tasks
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting ActiveSync.Protocol Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2013 -02 -06
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.

For More Information


Exchange ActiveSync
Mobile devices
Exchange ActiveSync virtual directory management tasks
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting ActiveSync.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2014 -09 -22
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.

For More Information


Exchange ActiveSync
Mobile devices
Exchange ActiveSync virtual directory management tasks
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting AD Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Antimalware Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting AntiSpam Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 5 minutes to read • Edit Online

Troubleshooting Autodiscover Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

AutodiscoverCtpProbe Autodiscover Active Directory AutodiscoverCtpMonito


r

For more information about probes and monitors, see Server health and performance.

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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to 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 Autodiscover health set details about server1.contoso.com, run the
following command:

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

b. Review the command output to determine which monitor reported the error. The AlertValue value
for the monitor that issued the alert is 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 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

10. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
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
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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 4 minutes to read • Edit Online

Troubleshooting Autodiscover.Protocol Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

AutodiscoverSelfTestPro Autodiscover.Protocol Active Directory AutodiscoverSelfTestMo


be nitor

For more information about probes and monitors, see Server health and performance.

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 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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 Autodiscover.Protocol health set details about server1.contoso.com, run
the following command:

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

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

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.

AutodiscoverSelfTestProbe Recovery Actions


When you receive an alert from a health set, the email message contains the following information:
Name of the Mailbox server that sent the alert
Name of Mailbox server being monitored
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.
To troubleshoot this issue, follow these steps:
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

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 using the IISReset utility or by running the following
command:

Iisreset /noforce

10. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
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
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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 3 minutes to read • Edit Online

Troubleshooting Autodiscover.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting ClientAccess.Proxy 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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

AutoDiscoverProxyTestP Autodiscover.Proxy Active Directory AutodiscoverProxyTestM


robe onitor

For more information about probes and monitors, see Server health and performance.

Common issues
This probe can fail for any of the following common reasons:
The application pool that’s hosted on the monitored CAS is not working correctly.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 Autodiscover.Protocol health set details about server1.contoso.com, run
the following command:

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

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

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.

AutodiscoverProxyTestMonitor Recovery Actions


When you receive an alert from a health set, the email message contains the following information:
Name of the CAS that sent the alert
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.
Time and date when the issue occurred
To troubleshoot this issue, follow these steps:
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.
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>/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

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, recycle the IIS service by using the IISReset utility.
7. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
8. If the issue still exists, restart the server.
9. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
10. 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.

For More Information


What's new in Exchange 2013
Autodiscover service
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Classification Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting ClientAccess.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Compliance Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 4 minutes to read • Edit Online

Troubleshooting DataProtection Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED 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


PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

StorageApparentControl DataProtection Active Directory StorageApparentControl


lerIssuesProbe lerIssuesMonitor

DatabaseHealthTooMan DataProtection Active Directory DatabaseHealthTooMan


yMountedDatabaseProb yMountedDatabaseMon
e itor

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 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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 Autodiscover.Protocol health set details about server1.contoso.com, run
the following command:

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

Review the command output to determine which monitor reported the error. The AlertValue value
for the monitor that issued the alert will be Unhealthy .
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


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

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.

Troubleshooting steps
When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
Time and date when the alert occurred
Authentication mechanism that was 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 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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting DiskSpace Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 3 minutes to read • Edit Online

Troubleshooting ECP Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting ECP.Proxy 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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

EacSelfTestProbe ECP Active Directory EacSelfTestMonitor

EacDeepTestProbe ECP Active Directory EacDeepTestMonitor

For more information about probes and monitors, see Server health and performance.

User Action
When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
Time and date when the alert occurred
Authentication and credential information
Full exception trace of the last error, including diagnostic data and specific HTTP header information
Note You can use the information in the full exception trace to help troubleshoot the issue.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, follow these steps:
a. Open the Exchange Management Shell, and then run the following command to retrieve the details
of the health set that issued the alert:

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

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

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.

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.
2. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
3. If the issue still exists, recycle the entire IIS service by using the IISReset utility.
4. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
5. If the probe fails, restart the server.
6. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
7. 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.
For More Information
What's new in Exchange 2013
Exchange 2013 cmdlets
Exchange admin center in Exchange 2013
10/5/2018 • 3 minutes to read • Edit Online

Troubleshooting ECP.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting ClientAccess.Proxy 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:

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

ECPProxyTestProbe ECP.Proxy Active Directory ECPProxyTestMonitor

For more information about probes and monitors, see Server health and performance.

Common issues
This probe may fail for any of the following common reasons:
The application pool that’s hosted on the monitored CAS is not working correctly.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 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
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 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

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.

ECPProxyTestMonitor Recovery Actions


When you receive an alert from a health set, the email message contains the following information:
Name of the CAS that sent the alert
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.
Time and date when the issue occurred
To troubleshoot this issue, follow these steps:
1. Review the protocol logs on CA servers. Protocol logs are located in the <exchange server installation
directory>\Logging\HttpProxy*\<protocol>* folder on the CAS.
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

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, recycle the IIS service by using the IISReset utility.
7. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
8. If the issue still exists, restart the server.
9. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
10. 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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting EDS Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting EventAssistants Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 6 minutes to read • Edit Online

Troubleshooting EWS Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting EWS.Protocol Health Set
Troubleshooting EWS.Proxy Health Set
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED 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
This probe can fail for any of the following common reasons:
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 Domain Controllers are not responding.
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
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.
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
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 EWS health set details about server1.contoso.com, run the following
command:

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

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

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.

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
running the following command from the Shell:

%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool

4. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
5. If the issue still exists, recycle the entire IIS service by using the IISReset utility.
6. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
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:

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

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:

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

If the command output shows no active copies on the server, restart the server.
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 succeeds, failover the databases back to the Mailbox server by running the following command:

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

16. If the probe is still failing, 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.

For More Information


Exchange 2013 cmdlets
What's new in Exchange 2013
10/5/2018 • 5 minutes to read • Edit Online

Troubleshooting EWS.Protocol Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting EWS Health Set
Troubleshooting EWS.Proxy Health Set
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

EwsSelfTestProbe EWS.Protocol Active Directory EWSSelfTestMonitor

EwsDeepTestProbe EWS.Protocol Information Store EWSDeepTestMonitor

For more information about probes and monitors, see Server health and performance.
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
This probe can fail for any of the following common reasons:
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
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 EWS.Protocol health set details about server1.contoso.com, run the
following command:

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

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 is 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 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

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.

EWSSelfTestMonitor and EWSDeepTestMonitor Recovery Actions


This monitor alert is typically issued for Mailbox servers.
1. Start IIS Manager, and then connect to the server that’s reporting the issue to determine whether the
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.
3. Click Application Pools, and then recycle the MSExchangeServicesAppPool application pool by
running the following command from the Shell:

%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool

4. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
5. If the issue still exists, restart the IIS service by using the IISReset utility.
6. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
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
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.
11. Verify that all the 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

If the command output shows no active copies on the server, the server is save the restart. 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 succeeds, failover the databases by running the following command:

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

14. If the probe is still failing, 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.
For More Information
What's new in Exchange 2013
10/5/2018 • 3 minutes to read • Edit Online

Troubleshooting EWS.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting ClientAccess.Proxy 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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

EWSProxyTestProbe EWS.Proxy Active Directory EWSProxyTestMonitor

For more information about probes and monitors, see Server health and performance.

Common issues
This probe can fail for any of the following common reasons:
The application pool that’s hosted on the monitored CAS is not working correctly.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 EWS.Proxy health set details about server1.contoso.com, run the
following command:

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

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 is in an unhealthy state. Refer to the table in the
Verifying the issue still exists 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 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

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.

EWSProxyTestMonitor Recovery Actions


When you receive an alert from a health set, the email message will contain the following information:
Name of the CAS that sent the alert
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.
Time and date when the issue occurred
To troubleshoot this issue, follow these steps:
1. Review the protocol logs on CA servers. Protocol logs are located in the <exchange server installation
directory>\Logging\HttpProxy*\<protocol>* folder on the CAS.
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
3. Start IIS Manager, and then connect to the server that’s reporting the issue to determine whether the
MSExchangeServicesAppPool application pool is running on the CAS.
4. Click Application Pools, and then recycle the MSExchangeServicesAppPool application pool by
running the following command from the Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, recycle the IIS service by using the IISReset utility.
7. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
8. If the issue still exists, restart the server.
9. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
10. 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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting FfoQuarantine Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting FfoTransport Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting FfoUmc Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting FfoWebService Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting FIPS Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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

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


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 FIPS health set details about server1.contoso.com, run the following
command:

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

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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting FreeBusy Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting FrontendTransport Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 4 minutes to read • Edit Online

Troubleshooting HubTransport Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET ASSOCIATED 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
PROBE HEALTH SET ASSOCIATED MONITORS

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
PROBE HEALTH SET ASSOCIATED MONITORS

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

none (notification or check) HubTransport PrivateWorkingSetWarning.msexcha


ngetransport

none (notification or check) HubTransport PrivateWorkingSetWarning.msexcha


ngetransportlogsearch

none (notification or check) HubTransport ProcessProcessorTimeError.edgetra


nsport

none (notification or check) HubTransport ProcessProcessorTimeError.msexcha


ngethrottling

none (notification or check) HubTransport ProcessProcessorTimeError.msexcha


ngetransport

none (notification or check) HubTransport ProcessProcessorTimeError.msexcha


ngetransportlogsearch

none (notification or check) HubTransport ProcessProcessorTimeWarning.edge


transport

none (notification or check) HubTransport ProcessProcessorTimeWarning.msex


changethrottling

none (notification or check) HubTransport ProcessProcessorTimeWarning.msex


changetransport

none (notification or check) HubTransport ProcessProcessorTimeWarning.msex


changetransportlogsearch

none (notification or check) HubTransport QueueExternalAggregateMonitor


PROBE HEALTH SET ASSOCIATED MONITORS

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


PROBE HEALTH SET ASSOCIATED MONITORS

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


PROBE HEALTH SET ASSOCIATED MONITORS

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


PROBE HEALTH SET ASSOCIATED MONITORS

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

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


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 HubTransport health set details about mailbox1.contoso.com, run the
following command:

Get-ServerHealth mailbox1.contoso.com | ?{$_.HealthSetName -eq "HubTransport"}

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 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.
10/5/2018 • 7 minutes to read • Edit Online

Troubleshooting IMAP Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting IMAP.Protocol Health Set
Troubleshooting IMAP.Proxy Health Set
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED 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
PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

ImapSelfTestProbe IMAP.Protocol Active Directory IMAP.Protocol


(IMAP.Protocol health
Authentication set)
AverageCommandProce
ssingTimeGt60sMonitor
(IMAP 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 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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 IMAP health set details about server1.contoso.com, run the following
command:

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

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 is 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 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

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.
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.
2. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
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:

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

If the command output shows no active copies on the server, restart the server.
5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the probe succeeds, failover the databases by running the following command:

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

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

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.
5. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
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.


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

ImapProxyTestMonitor recovery actions


1. Restart the IMAP4 service.
2. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
3. If probe is still failing, restart the CAS.
4. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
5. 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.

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:

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

Note In this and all subsequent code examples, replace server1.contoso.com with the actual server
name.
b. 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

If the command output shows no active copies on the server, restart the server.
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:

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

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

For More Information


POP3 and IMAP4
Enable IMAP4 in Exchange 2013
Test-ImapConnectivity
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting IMAP.Protocol Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2013 -02 -07
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.

For More Information


POP3 and IMAP4
Enable IMAP4 in Exchange 2013
Test-ImapConnectivity
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting IMAP.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2013 -02 -07
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.

For More Information


POP3 and IMAP4
Enable IMAP4 in Exchange 2013
Test-ImapConnectivity
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting MailboxMigration Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting MailboxSpace Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting MailboxTransport Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET ASSOCIATED 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
PROBE HEALTH SET ASSOCIATED MONITORS

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
PROBE HEALTH SET ASSOCIATED MONITORS

none (notification or check) MailboxTransport SubmissionInterceptorSubmissionA


gentPctPermFailedMonitor

none (notification or check) MailboxTransport TransportDeliveryFailuresDeliverySt


oreDriver560Monitor

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


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 MailboxTransport health set details about mailbox1.contoso.com, run
the following command:

Get-ServerHealth mailbox1.contoso.com | ?{$_.HealthSetName -eq "MailboxTransport"}

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 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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Mailflow Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Memory Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting MessageTracing Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Monitoring Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 6 minutes to read • Edit Online

Troubleshooting MRS Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

MRSServiceCrashingPro MRS Information Store MRSServiceCrashingMo


be nitor

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 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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 MRS health set details about server1.contoso.com, run the following
command:

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

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 is 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 MRSServiceCrashingMonitor. The probe
associated with that monitor is MRSServiceCrashingProbe. To run that probe on
server1.contoso.com, run the following command:

Invoke-MonitoringProbe MRS\MRSServiceCrashingProbe -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.

Common Issues
When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
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.
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:

Test-MRSHealth <servername> -MonitoringContext:$true

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.
When this issue occurs, you can verify the health of the service by running the following command:

Test-MRSHealth <servername> -MonitoringContext:$true

You can also try to restart the service by running the following command:

Restart-Service msexchangemailboxreplication

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..
When this issue occurs, you can verify the health of the service by running the following command:

Test-MRSHealth <servername> -MonitoringContext:$true

You can also try to restart the service by running the following command:

Restart-Service msexchangemailboxreplication

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:

%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool

3. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
4. If the issue still exists, recycle the IIS service by using the IISReset utility, or by running the following
command:

Iisreset /noforce

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, restart the server.
7. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
8. 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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting MSExchangeCertificateDeployment Health


Set
Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Network Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting OAB Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 3 minutes to read • Edit Online

Troubleshooting OAB.Proxy Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

OABProxyTestProbe OAB.Proxy Active Directory OABProxyTestMonitor

For more information about probes and monitors, see Server health and performance.

Common issues
This probe may fail for any of the following common reasons:
The application pool that’s hosted on the monitored CAS is not working correctly.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 OAB.Proxy health set details about server1.contoso.com, run the
following command:

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

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 is 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 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

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.

OABProxyTestMonitor Recovery Actions


When you receive an alert from a health set, the email message contains the following information:
Name of the CAS that sent the alert
Full exception trace of the last error, including diagnostic data and specific HTTP header information
Note You can use the information in the full exception trace to help troubleshoot the issue.
Time and date when the issue occurred
To troubleshoot this issue, follow these steps:
1. Review the protocol logs on CAS. Protocol logs are located in the <exchange server installation
directory>\Logging\HttpProxy*\<protocol>* folder on the CAS.
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>/owa.
3. Start IIS Manager, and then connect to the server that’s reporting the issue to determine whether the
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

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, recycle the IIS service by using the IISReset utility.
7. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
8. If the issue still exists, restart the server.
9. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
10. 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.

For More Information


Offline address books
What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Outlook Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Outlook.Protocol Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 3 minutes to read • Edit Online

Troubleshooting Outlook.Proxy Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

OutlookProxyTestProbe Outlook.Proxy Active Directory OutlookProxyTestMonit


or

For more information about probes and monitors, see Server health and performance.

Common issues
This probe may fail for any of the following common reasons:
The application pool that is hosted on the monitored CAS is not working correctly.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 Outlook.Proxy health set details about server1.contoso.com, run the
following command:

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

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 is 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 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

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.

OutlookProxyTestMonitor Recovery Actions


When you receive an alert from a health set, the email message contains the following information:
Name of the CAS that sent the alert
Full exception trace of the last error, including diagnostic data and specific HTTP header information
Note You can use the information in the full exception trace to help troubleshoot the issue.
The time and date when the issue occurred.
To troubleshoot this issue, follow these steps:
1. Review the protocol logs on the CA servers. Protocol logs are located in the <exchange server installation
directory>\Logging\HttpProxy*\<protocol>* folder on the CAS.
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>/owa.
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
running the following command from the Shell:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeRpcProxyAppPool

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, recycle the IIS service by using the IISReset utility.
7. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
8. If the issue still exists, restart the server.
9. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
10. 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.

For More Information


Outlook Anywhere
What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 7 minutes to read • Edit Online

Troubleshooting OWA Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

OwaCtpProbe Outlook Web App Active Directory OwaCtpMonitor


Information Store

For more information about probes and monitors, see Server health and performance.

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 monitoring account credentials are incorrect.
The user’s database is not mounted, or the Information Store is inaccessible for that mailbox.
The Information Store is not responding.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details 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 then run the following command to retrieve the details of
the health set that generated the alert:

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

Outlook Web App health set details about server1.contoso.com, run the following command:

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

b. Review the command output to determine which monitor reported the error. The AlertValue value
for the monitor that issued the alert is 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, 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

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.

OwaCtpMonitor Recovery Actions


An email alert from a health set contains the following information:
Name of the server that sent the alert
Full exception trace of the last error, including diagnostic data and specific HTTP header 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.
To troubleshoot this issue, follow these steps:
1. 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>/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.
11. If the issue still exists, recycle the IIS service by using the IISReset utility or by running the following
command:

Iisreset /noforce

12. Rerun the associated probe, as shown in step 2c in the Verifying the issue still exists section.
13. If the issue still exists, restart the server.
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
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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 9 minutes to read • Edit Online

Troubleshooting OWA.Protocol Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED 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
This probe may fail for any of the following common reasons:
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 monitoring account credentials are incorrect.
The user’s database is not mounted, or the Information Store is inaccessible for that mailbox.
The Information Store is not responding.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 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 .
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 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

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.
When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
Type of probe that failed (SelfTest or DeepTest)
Time and date when the alert occurred
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
Full exception trace of the last error, including diagnostic data and specific HTTP header information
Note You can use the information in the full exception trace to help troubleshoot the issue. The exception
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.
To troubleshoot this issue, follow these steps:
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.
4. Start IIS Manager, and then connect to the server that’s reporting the issue to determine whether the
MSExchangeOwaAppPool application pool is running on the CAS.
5. In IIS Manager, verify that the Default website is running.
6. 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

7. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
8. If the issue still exists, recycle the IIS service by using the IISReset utility or by running the following
command:

Iisreset /noforce

9. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
10. If the issue still exists, restart the server.
11. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
12. 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.

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
MSExchangeOwaAppPool application pool is running on the CAS.
4. In IIS Manager, verify that the Default website is running.
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.
7. In IIS Manager, click Application Pools, and then recycle the MSExchangeOWAAppPool application
pool by running the following command from the Shell:

%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeOWAAppPool

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

10. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
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
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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 5 minutes to read • Edit Online

Troubleshooting OWA.Protocol.Dep Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -11 -10
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.

PROBE HEALTH SET ASSOCIATED MONITORS

none (notification or check) OWA.Protocol.DEP OwaIMInitializationFailedMonitor

none (notification or check) OWA.Protocol.DEP WacDiscoveryFailureEventMonitor

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


&lt;value&gt; 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.
10/5/2018 • 3 minutes to read • Edit Online

Troubleshooting OWA.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

OWAProxyTestProbe OWA.Proxy Active Directory OWAProxyTestMonitor

OWAanonymouscalenda OWA.Proxy Active Directory OWAProxyTestMonitor


rProbe

For more information about probes and monitors, see Server health and performance.

Common issues
This probe may fail for any of the following common reasons:
The application pool that’s hosted on the monitored Client Access server (CAS ) is not working correctly.
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 OWA.Proxy health set details about server1.contoso.com, run the
following command:

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

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

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.

OWAProxyTestMonitor Recovery Actions


When you receive an alert from a health set, the email message contains the following information:
Name of the CAS that sent the alert
Full exception trace of the last error, including diagnostic data and specific HTTP header information
Note You can use the information in the full exception trace to help troubleshoot the issue.
Time and date when the issue occurred
To troubleshoot this issue, follow these steps:
1. Review the protocol logs on the CA servers. Protocol logs are located in the <exchange server installation
directory>\Logging\HttpProxy*\<protocol>* folder on the CAS.
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>/owa.
3. Start IIS Manager, and then connect to the server that’s reporting the issue to determine whether the
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

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, recycle the IIS service by using the IISReset utility.
7. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
8. If the issue still exists, restart the server.
9. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
10. 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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
Managing Outlook Web App
10/5/2018 • 7 minutes to read • Edit Online

Troubleshooting POP Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting POP.Protocol Health Set
Troubleshooting POP.Proxy Health Set
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.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED 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
PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

PopSelfTestProbe POP.Protocol None PopSelfTestMonitor


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

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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 POP health set details about server1.contoso.com, run the following
command:

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

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

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.

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.
2. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
3. If the probe still fails, failover the databases that are hosted on the Mailbox server by using the following
command:

Set-MailboxServer -Identity <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $true

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.
7. If the probe succeeds, failover the databases by running the following command:

Set-MailboxServer -Identity <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $false

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

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.
2. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
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

7. Restart the POP3 service on the servers that are running the CAS role. For more information, see Start and
stop the POP3 services.
8. 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.

PopProxyTestMonitor recovery actions


1. Restart the POP3 service on the servers that are running the CAS role. For more information, see Start and
stop the POP3 services.
2. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
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.
5. 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.

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:

Set-MailboxServer -Identity <ServerName> -DatabaseCopyActivationDisabledAndMoveNow $true

Note In this and all subsequent code examples, replace server1.contoso.com with the actual server
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

If the command output shows no active copies on the server, restart the server.
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

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

For More Information


Start and stop the POP3 services
Test-PopConnectivity
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting POP.Protocol Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2013 -02 -11
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.

For More Information


Test-PopConnectivity
POP3 and IMAP4
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting POP.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2013 -02 -11
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.

For More Information


Test-PopConnectivity
POP3 and IMAP4
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting PowershellDataProvider Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting PublicFolders Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting PushNotifications.Protocol Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting RemoteMonitoring Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting RPS Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 3 minutes to read • Edit Online

Troubleshooting RPS.Proxy Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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:

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

RPSProxyTestProbe RPS.Proxy Active Directory RPSProxyTestMonitor

For more information about probes and monitors, see Server health and performance.

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.
The monitoring account credentials are incorrect.
The Domain Controllers are not responding.

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.

Verifying the issue still exists


1. Identify the health set name and the server name in the alert.
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
health set that issued the alert:
Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}

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:

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

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

5. Rerun the associated probe as shown in step 2.c. in the Verifying the issue still exists section.
6. If the issue still exists, recycle the IIS service using the IISReset utility.
7. Rerun the associated probe as shown in step 2.c. in the Verifying the issue still exists section.
8. If the issue still exists, restart the server.
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
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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Search Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 4 minutes to read • Edit Online

Troubleshooting SiteMailbox Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2013 -02 -11
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
For more information about probes and monitors, see Server health and performance.

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
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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 SiteMailbox health set details about server1.contoso.com, run the
following command:

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

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 .

Troubleshooting steps
When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
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
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.
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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting SMTP Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Store Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting Transport Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2012 -10 -11
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.
10/5/2018 • 5 minutes to read • Edit Online

Troubleshooting UM Health Set


Applies to: Exchange Server 2013, Project Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting UM.CallRouter Health Set
Troubleshooting UM.Protocol Health Set

Explanation
The UM service is monitored by using the following probes and monitors.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

UMSelfTestProbe UM.Protocol Active Directory Domain UMSelfTestMonitor


Services (AD DS)

UMCallRouterTestProbe UM.CallRouter Active Directory Domain UMCallRouterTestMonit


Services (AD DS) or

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 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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 UM.Protocol health set details about server1.contoso.com, run the
following command:

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

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 is 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 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

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.

Troubleshooting steps
When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
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
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.
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.
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.
Less than {0}% of Messages were Successfully Processed 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.
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.
The Microsoft Exchange Unified Messaging service rejected a call because the UM pipeline is full
Review the event logs on the CAS to determine whether the UM objects, such as the umipgateway and
umhuntgroup objects, 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.
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
MSExchangeServicesAppPool application pool is running.
2. In IIS Manager, click Application Pools, and then recycle the MSExchangeServicesAppPool application
pool. To do this, run the following command from the Exchange Management Shell:

%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool

3. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
4. If the issue still exists, recycle the IIS service by using the IISReset utility or by running the following
command:

Iisreset /noforce

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, restart the server.
7. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
8. 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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
2/14/2019 • 4 minutes to read • Edit Online

Troubleshooting UM.CallRouter Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2019 -02 -04
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:
Troubleshooting UM Health Set
Troubleshooting UM.Protocol Health Set

Explanation
The UM.Protocol service is monitored by using the following probes and monitors

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

UMCallRouterTestProbe UM.CallRouter Active Directory Domain UMCallRouterTestMonit


Services (AD DS) or

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 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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 UM.CallRouter health set details about server1.contoso.com, run the
following command:

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

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 is 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 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

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.

Troubleshooting steps
When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
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
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.
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.
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 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.
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.
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:
1. Start IIS Manager, and then connect to the server that’s reporting the issue to determine whether 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:

%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool

3. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
4. If the issue still exists, recycle the IIS service by using the IISReset utility or by running the following
command:

Iisreset /noforce

5. Rerun the associated probe as shown in step 2c in the Verifying the issue still exists section.
6. If the issue still exists, restart the server.
7. After the server restarts, rerun the associated probe as shown in step 2c in the Verifying the issue still exists
section.
8. 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.

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting UM.Protocol Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2015 -03 -09
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:
Troubleshooting UM Health Set
Troubleshooting UM.CallRouter Health Set

Explanation
The UM.Protocol service is monitored by using the following probes and monitors.

PROBE HEALTH SET DEPENDENCIES ASSOCIATED MONITORS

UMSelfTestProbe UM.Protocol Active Directory Domain UMSelfTestMonitor


Services (AD DS)

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 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.
2. The message details provide information about the exact cause of the alert. In most cases, the message
details provide sufficient troubleshooting information to identify the root cause. If the message details are
not clear, do the following:
a. Open the Exchange Management Shell, and then 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 UM.Protocol health set details about server1.contoso.com, run the
following command:

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

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

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.

Troubleshooting steps
When you receive an alert from a health set, the email message contains the following information:
Name of the server that sent the alert
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
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 more information about troubleshooting UJM alert messages, see Troubleshooting UM Health Set

For More Information


What's new in Exchange 2013
Exchange 2013 cmdlets
10/5/2018 • 2 minutes to read • Edit Online

Troubleshooting UserThrottling Health Set


Applies to: Exchange Server 2013
Topic Last Modified: 2012 -10 -11
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.