Устранение неполадок в наборе средств проверки работоспособности службы RPS.Proxy

 

Применимо к:Exchange Server 2013

Последнее изменение раздела:2015-03-09

Набор для контроля работоспособности службы RPS.Proxy отслеживает состояние общей работоспособности службы Remote PowerShell.

Получение предупреждения о неработоспособности службы RPS.Proxy указывает на проблему, которая может препятствовать использованию службы Remote PowerShell для доступа к Exchange.

Работа службы RPS отслеживается с помощью перечисленных ниже зондов и мониторов.

 

Зонд Настройки работоспособности Зависимости Связанные мониторы

RPSProxyTestProbe

Служба RPS.Proxy

Active Directory

RPSProxyTestMonitor

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

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

  • Пул приложений, расположенный на отслеживаемом сервере CAS, работает неправильно.

  • Введены неправильные данные учетной записи наблюдения.

  • Контроллеры доменов не отвечают.

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

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

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

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

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

      Например, для получения сведений о наборе контроля работоспособности RPS.Proxy на server1.contoso.com, выполните следующую команду:

      Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "RPS.Proxy"}
      
    2. Ознакомьтесь с выходным потоком команды, чтобы определить монитор, который сообщил об ошибке. Значение параметра AlertValue для монитора, который создал предупреждение будет равно Unhealthy.

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

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

      Допустим, что отказал монитор RPSProxyTestMonitor. С этим монитором связан зонд RPSProxyTestProbe. Для запуска этого зонда на server1.contoso.com выполните следующую команду:

      Invoke-MonitoringProbe RPS.Proxy\RPSProxyTestProbe -Server server1.contoso.com | Format-List
      
    4. В выходном потоке команды проверьте значение параметра зонда Результат. Если это значение равно Выполнено успешно, то проблема была связана с временной ошибкой и теперь отсутствует. В противном случае воспользуйтесь инструкцией по восстановлению, приведенной в следующих разделах.

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

  • Имя сервера CAS, который отправил предупреждение.

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

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

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

  1. Просмотрите журналы протоколов на серверах клиентского доступа. Журналы протоколов расположены в папке <каталог установки exchange server>\Logging\HttpProxy\<протокол> на сервере CAS.

  2. Создайте тестовую учетную запись пользователя, а затем с ее помощью войдите на сервер CAS, например на https:// <имя_сервера>/owa

  3. Запустите диспетчер IIS, подключитесь к серверу, который сообщил о проблеме, и убедитесь, что пул приложений MSExchangePowerShellFrontEndAppPool запущен на сервере CAS.

  4. Выберите пункт Пулы приложений, а затем повторно запустите пул приложений MSExchangeRpcProxyAppPool, выполнив следующую команду из командной консоли Exchange:

    %SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangePowerShellFrontEndAppPool
    
  5. Перезапустите связанный зонд, как показано в действии 2.c. в разделе Проверка наличия проблемы.

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

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

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

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

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

 
Показ: