Устранение неполадок набора данных о работоспособности OWA

  • Статья

Область применения: Exchange Server 2013 г.

Набор работоспособности Outlook Web App (OWA) отслеживает общую работоспособность службы Outlook Web App.

Если вы получаете оповещение о том, что Outlook Web App неработоспособен, это указывает на проблему, которая может помешать пользователям получить доступ к своим почтовым ящикам с помощью Outlook Web App.

Объяснение

Служба Outlook Web App отслеживается с помощью следующих проб и мониторов.

Зонд Настройки работоспособности Зависимости Связанные мониторы
OwaCtpProbe Outlook Web App Active Directory

Банк данных		 OwaCtpMonitor

Дополнительные сведения о пробах и мониторах см. в разделе Работоспособность и производительность сервера.

Распространенные проблемы

Этот зонд может не работать по нескольким причинам. Ниже приведено несколько распространенных причин.

  • Outlook Web App пул приложений, размещенный на отслеживаемом сервере клиентского доступа (CAS), не отвечает или пул приложений, размещенный на сервере почтовых ящиков, не отвечает.
  • В cas-сервере возникают проблемы с сетью, и ему не удается подключиться к серверу почтовых ящиков или контроллеру домена.
  • Введены неправильные данные учетной записи наблюдения.
  • База данных пользователя не подключена или хранилище сведений недоступно для этого почтового ящика.
  • Банк данных не отвечает.
  • Контроллеры доменов не отвечают.

Действия пользователя

Служба может восстановить работу после отображения оповещения. Поэтому если вы получите оповещение о неработоспособном состоянии настроек работоспособности, сначала убедитесь в наличии данной проблемы. Если проблема не устранена, выполните соответствующие действия по восстановлению, указанные в приведенных ниже разделах.

Проверка наличия проблемы

  1. Определите имена настроек работоспособности и сервера, указанные в оповещении.

  2. В сообщении приводятся подробные сведения о точной причине возникновения оповещения. В большинстве случаев в сообщении приводится достаточно сведений по устранению неполадок для определения основной причины проблемы. Если в сообщении приводятся непонятные сведения:

    1. Откройте командную консоль Exchange и выполните следующую команду, чтобы получить сведения о наборе работоспособности, который создал оповещение:

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

      Outlook Web App сведения о наборе сведений о работоспособности server1.contoso.com выполните следующую команду:

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

    2. Просмотрите выходные данные команды, чтобы определить монитор, сообщивший об ошибке. Значение AlertValue для монитора, выдавшего оповещение, — Unhealthy.

    3. Повторно запустите связанную пробу для монитора, который находится в неработоспособном состоянии. Обратитесь к таблице в разделе Explanation, чтобы найти связанный зонд. Для этого выполните следующую команду.

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

      Например, чтобы создать пробу мониторинга Exchange ActiveSync на server1.contoso.com, выполните следующую команду:

      Invoke-MonitoringProbe -Identity ActiveSync.Protocol\ActiveSyncSelfTestProbe -Server server1.contoso.com

    4. В выходных данных команды просмотрите значение параметра Результат зонда. Если этот параметр имеет значение Succeeded, ошибка была временной и в настоящее время устранена. В противном случае обратитесь к действиям по восстановлению, приведенным в следующих разделах.

Действия по восстановлению монитора OwaCtpMonitor

Уведомление по электронной почте, отправляемое настройками работоспособности, содержит следующие сведения.

  • Имя сервера, отправившего оповещение.

  • Полная трассировка исключения, связанного с последней ошибкой, включая диагностические данные и конкретные сведения о заголовке HTTP.

    Примечание. Сведения в полной трассировке исключений можно использовать для устранения проблемы. Исключение, создаваемое зондом, содержит поле "Причина сбоя" с описанием причины сбоя. Например, исключение содержит следующие сведения:

    • MissingKeyword: ожидаемое ключевое слово не найдено в ответе сервера. В этом случае исключение содержит ожидаемые ключевые слова.

    • NameResolution: разрешение DNS не удается разрешить заданное имя сервера.

    • NetworkConnection. Проба получает сбой сетевого подключения при попытке подключиться к пулу приложений OWA в CAFE.

    • UnexpectedHttpResponseCode: в ответе был непредвиденный КОД HTTP. Например, сервер вернул код HTTP 503.

    • RequestTimeout: серверу потребовалось слишком много времени, чтобы ответить на запрос клиента.

    • ScenarioTimeout: проба успешно завершена, но для этого потребовалось более одной минуты. Обычно это указывает на перегрузку системы.

    • OwaErrorPage: Outlook Web App вернул страницу ошибки. Обычно в сообщении об исключении приводится имя ошибки, которая привела к сбою.

    • OwaMailboxErrorPage: Outlook Web App вернул страницу ошибки, содержащую ошибку, связанную с хранилищем почтовых ящиков. Это обычно указывает на неработоспособность хранилища почтовых ящиков или отключение почтовых ящиков.

    Трассировка исключения содержит важное поле FailingComponent. Зонд пытается определить причину сбоя, как, например, в следующем примере.

    • Почтовый ящик: проба может связаться с Outlook Web App, но не может подключиться к хранилищу почтовых ящиков. В этом случае возник сбой зонда, или задержка доступа к почтовому ящику привела к сбою зонда и созданию ошибки ScenarioTimeout. При таких сбоях следует проверить работоспособность серверов почтовых ящиков.

    • Active Directory: проба может достичь Outlook Web App, но не может подключиться к Active Directory. В этом случае проба завершилась сбоем или задержка вызова Active Directory могла привести к истечению времени ожидания пробы. При возникновении таких типов сбоев необходимо проверить работоспособность контроллеров домена, а также проверить сетевые подключения между ЦС и серверами почтовых ящиков, а также контроллерами домена.

    • Owa: обычно это означает, что внутри слоя Outlook Web App произошла ошибка. При возникновении таких сбоев необходимо проверить работоспособность процесса Outlook Web App на серверах ЦС и почтовых ящиков, а также проверить сетевые подключения.

      Исключение также содержит сведения о последнем HTTP-запросе и ответе, полученным до сбоя зонда. Текст сообщения об эскалации содержит путь к журналам зонда. Эти сведения можно использовать для определения полного веб-запроса HTTP и ответов, отправленных при сбое зонда. Этот файл содержит данные только для неисправных зондов, поскольку в журнал записываются исключительно неудачные попытки. Эти сведения можно использовать для получения более подробной информации о сбое при тестировании.

  • Насколько опустилась метрика доступности (x%).

  • Полный путь к папке, которая содержит полные трассировки HTTP-запроса для зонда. По умолчанию эти сведения находятся в папке %ExchangeInstallPath%Logging\Monitoring\OWA\ClientAccessProbe .

  • Время и дата возникновения оповещения.

Для устранения данной проблемы выполните действия, указанные ниже.

  1. Создайте тестовую учетную запись пользователя, а затем войдите из нее на сервер клиентского доступа. Например, войдите в систему с помощью https://<servername>/owa.

    Если не удается войти в систему, выполните проверку, используя другой сервер клиентского доступа, чтобы убедиться, что проблема возникает на определенном сервере клиентского доступа, а не на сервере почтовых ящиков.

  2. Проверьте сетевое подключение между серверами клиентского доступа и почтовых ящиков. С помощью служебной программы ping.exe убедитесь, что отвечает каждый сервер.

  3. Проверьте наличие оповещений, которые связаны с настройками работоспособности OWA.Protocol и могут указывать на проблему с определенным сервером почтовых ящиков. Подробнее см. в разделе Troubleshooting OWA.Protocol Health Set.

  4. Запустите диспетчер IIS, а затем подключитесь к серверу, который сообщает о проблеме, чтобы убедиться, что пул приложений MSExchangeOwaAppPool работает в cas-сервере.

  5. В диспетчере IIS убедитесь, что запущен веб-сайт по умолчанию.

  6. Найдите неисправные зонды в базе данных почтовых ящиков и убедитесь, что она активна на сервере почтовых ящиков, а также что хранилище почтовых ящиков работоспособно. Чтобы получить сведения о GUID неисправной базы данных, откройте сведения о полной трассировке исключения. Каждый сбой должен содержать запись, похожую на следующий пример.

    Starting Owa probe with Target: https://localhost/owa/, Username: _HealthMailboxdf8b87828ab0427cb91e985bbdfcec62@yourdomain.com*

  7. Скопируйте GUID HealthMailbox, а затем выполните в командной консоли следующую команду.

    Get-Mailbox -Monitoring -Identity <username>

    Например, выполните следующую команду:

    Get-Mailbox -Monitoring -Identity HealthMailboxdf8b87828ab0427cb91e985bbdfcec62@yourdomain.com

    В возвращаемом объекте можно найти имя базы данных пользователя, а также определить, где находится текущая активная база данных.

  8. Если между сайтами настроено перенаправление, можно наблюдать за сбоями зондов и созданием ошибки MissingKeyword. Это происходит в связи с тем, что по умолчанию зонды сервера клиентского доступа запускаются в учетных записях для любого расположения, а также с тем, что зонд не пытается выполнить проверку сервера клиентского доступа на другом сайте при использовании перенаправления. Чтобы устранить эту проблему, убедитесь, что серверы на каждом сайте содержатся в MonitoringGroups. Серверы клиентского доступа в заданной группе мониторинга выполняют проверку только совместно с серверами почтовых ящиков в той же группе.

    Чтобы определить группы мониторинга для своих серверов, выполните следующую команду.

    Get-ExchangeServer | ft MonitoringGroup

    Чтобы изменить группу мониторинга на сервере, используйте параметр MonitoringGroup вместе с командлетом Set-ExchangeServer. Например, введите следующее:

    Set-ExchangeServer -Identity "ServerName" -MonitoringGroup "Primary"

  9. В диспетчере IIS щелкните Пулы приложений, а затем перезапустите пул приложений MSExchangeOWAAppPool , выполнив следующую команду:

    %SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeOWAAppPool

  10. Повторно запустите связанную пробу, как показано на шаге 2c в разделе Проверка наличия проблемы.

  11. Если проблема не устранена, перезапустите службы IIS с помощью служебной программы IISReset или следующей команды.

    Iisreset /noforce

  12. Повторно запустите связанную пробу, как показано на шаге 2c в разделе Проверка наличия проблемы.

  13. Если проблема не устранена, перезапустите сервер.

  14. После перезапуска сервера повторно запустите связанный зонд, как показано в шаге 2c раздела Verifying the issue still exists.

  15. Если зонд все еще не работает, вам понадобится помощь для устранения данной проблемы. Для решения этой проблемы обратитесь к специалисту службы технической поддержки Майкрософт. Чтобы обратиться к специалисту по служба поддержки Майкрософт, перейдите в службу поддержки для бизнеса, а затем выберите Серверы>Exchange Server. Так как обращение непосредственно в службу технической поддержки Майкрософт в вашей организации может регламентироваться, сначала ознакомьтесь с инструкциями организации.

Дополнительные сведения

Что нового в Exchange 2013

Exchange PowerShell