疑難排解 EWS 健全設定
適用於:Exchange Server 2013
Exchange Web 服務 (EWS) 健全設定會監視 EWS 服務的整體健康情況。 EWS 健康情況集與下列健康情況集密切相關:
如果您收到指定 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 應用程式集區沒有回應。
- 使用者的資料庫未掛接,或資訊存放區無法用於特定信箱。
- 一或多部信箱伺服器上的資訊存放區服務發生問題。
使用者動作
服務可能會在發出警示之後復原。 因此,當您收到指定健康情況設定為狀況不良的警示時,請先確認問題仍然存在。 如果問題確實存在,請執行下列各節中所述的適當復原動作。
確認問題仍然存在
識別警示中的健全設定名稱和伺服器名稱。
當您接收來自此 HealthSet 的警示時,郵件會包含下列資訊:
警示源自的 CAS 名稱
探查監視為目標資源的信箱伺服器名稱
上一個錯誤的完整例外狀況追蹤,包括診斷資料與特定的 HTTP 標頭資訊
事件的發生時間
使用的驗證機制和認證資訊
例外狀況追蹤資訊提供探查失敗原因的最重要線索。 呈報訊息也包含下列 HTTP 標頭:
X-FEServer:指出探查執行所在的 CAS
X-TargetBEServer:指出要求路由至哪個 MBX 伺服器
X-DiagInfo:指出收到要求的 MBX 伺服器
訊息詳細資料會提供警示確切原因的相關資訊。 在大部分情況下,訊息詳細資料會提供足夠的疑難排解資訊來識別根本原因。 如果訊息詳細資料不清楚,請執行下列動作:
開啟 Exchange 管理命令介面,然後執行下列命令以擷取發出警示之健全狀況集的詳細資料:
Get-ServerHealth <server name> | ?{$_.HealthSetName -eq "<health set name>"}
例如,若要擷取有關 server1.contoso.com 的 EWS 健康情況集詳細資料,請執行下列命令:
Get-ServerHealth server1.contoso.com | ?{$_.HealthSetName -eq "EWS"}
檢閱命令輸出,以判斷報告錯誤的監視器。 發出警示之監視器的 AlertValue 值會是
Unhealthy
。針對處於狀況不良狀態的監視器,重新執行相關聯的探查。 請參閱說明一節中的表格,以尋找相關聯的探查。 若要執行此動作,請執行下列命令:
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
在命令輸出中,檢閱探查 的結果 值。 如果值為 Succeeded,則問題為暫時性錯誤,且不再存在。 否則,請參閱下列各節中所述的復原步驟。
EwsCtpMonitor 復原動作
啟動 IIS 管理員,然後連線到回報問題的伺服器,以判斷 MSExchangeServicesAppPool 應用程式集區是否同時在 CA 和信箱伺服器上執行。
找出失敗探查的 MailboxDatabase。 ,確認信箱伺服器的信箱資料庫為作用中,且資訊存放區狀況良好。
按一下 [應用程式集區],然後執行下列命令來回收 MSExchangeServicesAppPool 應用程式集區:
%SystemRoot%\System32\inetsrv\Appcmd recycle MSExchangeServicesAppPool
重新執行關聯的探查,如Verifying the issue still exists一節中的步驟 2c 所示。
如果問題仍然存在,請使用 IISReset 公用程式來回收整個 IIS 服務。
重新執行關聯的探查,如Verifying the issue still exists一節中的步驟 2c 所示。
如果問題仍然結束,請檢閱 CA 和信箱伺服器上的通訊協定記錄檔。 CAS 的通訊協定記錄位於 %ExchangeInstallPath%Logging\HttpProxy\Ews 資料夾中。 在信箱伺服器上,記錄位於 %ExchangeInstallPath%Logging\Ews 資料夾中。
建立測試使用者帳戶,然後針對指定的 CAS 執行測試使用者帳戶來登入。 例如,使用下列專案登入:
https://<servername>/ews/exchange.asmx
。 如果問題仍然存在,請嘗試不同的 CAS 來判斷問題的範圍是否為該 CAS,而不是信箱伺服器。 如果測試使用者名稱通過,問題可能會影響監視信箱所在的特定信箱資料庫或信箱伺服器。 嘗試使用信箱資料庫中存在的測試帳戶來重複此步驟。檢查 CA 與信箱伺服器之間的網路連線能力。
檢查 EWS 上的任何警示。Proxy 健全狀況集合,可能表示會影響特定 CAS 的問題。
檢查 EWS 上的任何警示。通訊協定健全狀況集合,可能表示會影響特定信箱伺服器的問題。
如果問題仍然存在,請重新啟動伺服器。 若要這樣做,請先容錯移轉伺服器上裝載的資料庫。 若要執行此動作,請執行下列命令:
Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $true
注意:在此和所有後續程式碼範例中,將 server1.contoso.com 取代為實際的伺服器名稱。
確認所有資料庫都已移出報告問題的伺服器。 若要執行此動作,請執行下列命令:
Get-MailboxDatabaseCopyStatus -Server server1.contoso.com | Group Status
如果命令輸出顯示伺服器上沒有主動副本,請重新啟動伺服器。
重新啟動伺服器之後,重新執行關聯的探查,如Verifying the issue still exists一節的步驟 2c 所示。
如果探查成功,請執行下列命令,將資料庫容錯移轉回信箱伺服器:
Set-MailboxServer server1.contoso.com -DatabaseCopyActivationDisabledAndMoveNow $false
如果探查持續失敗,請尋求協助以解決此問題。 請連絡 Microsoft 支援人員以解決此問題。 若要連絡Microsoft 支援服務專業人員,請造訪商務支援,然後選取[伺服器>Exchange Server] 。 由於您的組織可能擁有直接連絡 Microsoft 產品支援服務的特定程序,因此請務必先檢閱組織的指南。