疑難排解 EWS 健全設定

適用於:Exchange Server 2013

Exchange Web 服務 (EWS) 健全設定會監視 EWS 服務的整體健康情況。 EWS 健康情況集與下列健康情況集密切相關:

疑難排解 EWS.Protocol 健全設定

疑難排解 EWS.Proxy 健全設定

如果您收到指定 EWS 狀況不良的警示,這表示可能會導致使用者無法與 Exchange Server 通訊的問題。

說明

使用下列探查和監視器來監視 EWS。

探針 健全設定 相依性 關聯的監視器
EwsCtpProbe EWS 資訊儲存庫

Active Directory Domain Services (AD DS)
EwsCtpMonitor (EWS 健全設定)
EwsSelfTestProbe EWS。協定 Active Directory Domain Services (AD DS) EWSSelfTestMonitor
EwsDeepTestProbe EWS。協定 資訊儲存庫 EWSDeepTestMonitor

此探查會使用監視帳戶,執行從用戶端存取伺服器 (CAS) 到信箱伺服器的完整 EWS 登入。 此探查會在 EWS 上呼叫 GetFolder 方法。 如需探查和監視的詳細資訊,請參閱 伺服器健康情況和效能

常見問題

下列任一常見原因都可能導致此探查失敗:

  • 探查所使用的驗證機制與 CAS 虛擬目錄上使用的驗證機制之間存在不符的情況。
  • CAS 中受監視的 EWS 應用程式集區沒有回應。
  • CAS 連線到信箱伺服器時遇到網路問題。
  • CAS 連線到網域控制站時遇到通訊問題。
  • 網域控制站無回應。
  • 位於一或多部信箱伺服器上的 EWS 應用程式集區沒有回應。
  • 使用者的資料庫未掛接,或資訊存放區無法用於特定信箱。
  • 一或多部信箱伺服器上的資訊存放區服務發生問題。

使用者動作

服務可能會在發出警示之後復原。 因此,當您收到指定健康情況設定為狀況不良的警示時,請先確認問題仍然存在。 如果問題確實存在,請執行下列各節中所述的適當復原動作。

確認問題仍然存在

  1. 識別警示中的健全設定名稱和伺服器名稱。

    當您接收來自此 HealthSet 的警示時,郵件會包含下列資訊:

    1. 警示源自的 CAS 名稱

    2. 探查監視為目標資源的信箱伺服器名稱

    3. 上一個錯誤的完整例外狀況追蹤,包括診斷資料與特定的 HTTP 標頭資訊

    4. 事件的發生時間

    5. 使用的驗證機制和認證資訊

    例外狀況追蹤資訊提供探查失敗原因的最重要線索。 呈報訊息也包含下列 HTTP 標頭:

    1. X-FEServer:指出探查執行所在的 CAS

    2. X-TargetBEServer:指出要求路由至哪個 MBX 伺服器

    3. X-DiagInfo:指出收到要求的 MBX 伺服器

  2. 訊息詳細資料會提供警示確切原因的相關資訊。 在大部分情況下,訊息詳細資料會提供足夠的疑難排解資訊來識別根本原因。 如果訊息詳細資料不清楚,請執行下列動作:

    1. 開啟 Exchange 管理命令介面,然後執行下列命令以擷取發出警示之健全狀況集的詳細資料:

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

      例如,若要擷取有關 server1.contoso.com 的 EWS 健康情況集詳細資料,請執行下列命令:

      Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "EWS"}
      
    2. 檢閱命令輸出,以判斷報告錯誤的監視器。 發出警示之監視器的 AlertValue 值會是 Unhealthy

    3. 針對處於狀況不良狀態的監視器,重新執行相關聯的探查。 請參閱說明一節中的表格,以尋找相關聯的探查。 若要執行此動作,請執行下列命令:

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

      針對 EWS 健康情況集,假設失敗的監視器是 EWSCtpMonitor。 與該監視器相關聯的探查是 EWSCtpProbe。 若要在 server1.contoso.com 上執行該探查,請執行下列命令:

      Invoke-MonitoringProbe EWS\EWSCtpProbe -Server server1.contoso.com | Format-List
      
    4. 在命令輸出中,檢閱探查 的結果 值。 如果值為 Succeeded,則問題為暫時性錯誤,且不再存在。 否則,請參閱下列各節中所述的復原步驟。

EwsCtpMonitor 復原動作

  1. 啟動 IIS 管理員,然後連線到回報問題的伺服器,以判斷 MSExchangeServicesAppPool 應用程式集區是否同時在 CA 和信箱伺服器上執行。

  2. 找出失敗探查的 MailboxDatabase。 ,確認信箱伺服器的信箱資料庫為作用中,且資訊存放區狀況良好。

  3. 按一下 [應用程式集區],然後執行下列命令來回收 MSExchangeServicesAppPool 應用程式集區:

    %SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool
    
  4. 重新執行關聯的探查,如Verifying the issue still exists一節中的步驟 2c 所示。

  5. 如果問題仍然存在,請使用 IISReset 公用程式來回收整個 IIS 服務。

  6. 重新執行關聯的探查,如Verifying the issue still exists一節中的步驟 2c 所示。

  7. 如果問題仍然結束,請檢閱 CA 和信箱伺服器上的通訊協定記錄檔。 CAS 的通訊協定記錄位於 %ExchangeInstallPath%Logging\HttpProxy\Ews 資料夾中。 在信箱伺服器上,記錄位於 %ExchangeInstallPath%Logging\Ews 資料夾中。

  8. 建立測試使用者帳戶,然後針對指定的 CAS 執行測試使用者帳戶來登入。 例如,使用下列專案登入: https://<servername>/ews/exchange.asmx 。 如果問題仍然存在,請嘗試不同的 CAS 來判斷問題的範圍是否為該 CAS,而不是信箱伺服器。 如果測試使用者名稱通過,問題可能會影響監視信箱所在的特定信箱資料庫或信箱伺服器。 嘗試使用信箱資料庫中存在的測試帳戶來重複此步驟。

  9. 檢查 CA 與信箱伺服器之間的網路連線能力。

  10. 檢查 EWS 上的任何警示。Proxy 健全狀況集合,可能表示會影響特定 CAS 的問題。

  11. 檢查 EWS 上的任何警示。通訊協定健全狀況集合,可能表示會影響特定信箱伺服器的問題。

  12. 如果問題仍然存在,請重新啟動伺服器。 若要這樣做,請先容錯移轉伺服器上裝載的資料庫。 若要執行此動作,請執行下列命令:

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

    注意:在此和所有後續程式碼範例中,將 server1.contoso.com 取代為實際的伺服器名稱。

  13. 確認所有資料庫都已移出報告問題的伺服器。 若要執行此動作,請執行下列命令:

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

    如果命令輸出顯示伺服器上沒有主動副本,請重新啟動伺服器。

  14. 重新啟動伺服器之後,重新執行關聯的探查,如Verifying the issue still exists一節的步驟 2c 所示。

  15. 如果探查成功,請執行下列命令,將資料庫容錯移轉回信箱伺服器:

    Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $false
    
  16. 如果探查持續失敗,請尋求協助以解決此問題。 請連絡 Microsoft 支援人員以解決此問題。 若要連絡Microsoft 支援服務專業人員,請造訪商務支援,然後選取[伺服器>Exchange Server] 。 由於您的組織可能擁有直接連絡 Microsoft 產品支援服務的特定程序,因此請務必先檢閱組織的指南。

相關資訊

Exchange PowerShell

Exchange 2013 的新功能