Troubleshooting OWA.Protocol Health Set

Applies to: Exchange Server 2013

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

Information Store
OwaDeepTestMonitor

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:

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

    3. 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
      
    4. 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: %ExchangeInstallPath%Logging\Monitoring\OWA\ProtocolProbe

    • DeepTestProbe: %ExchangeInstallPath%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:

    %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 Support for business and then select Servers > Exchange Server. 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:

    %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 Support for business and then select Servers > Exchange Server. 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 PowerShell