可用來疑難排解 Exchange ActiveSync 問題的指令碼

英文原文已於 2012 年 1 月 2 日星期三發佈

• ActiveSyncReport 指令碼
• 下載 (可能為英文網頁)

Exchange 支援團隊經常接到使用 Exchange ActiveSync (EAS) 通訊協定的行動裝置，因為發送過多要求給 Exchange 伺服器，導致伺服器資源耗盡，而遭到「阻斷服務」(DOS) 攻擊的狀況。這個狀況的最壞結果，將導致即使其他使用者未使用 EAS 通訊協定進行連線，仍也無法使用伺服器。我們已經將這個狀況及其可能的預防方式記載於下述的 KnowledgeBase 文章：

2469722 (可能為英文網頁) 因 Exchange 資源耗盡而無法使用 Exchange ActiveSync 進行連線

這個狀況的一個最新範例是 Apple iOS 4.0 裝置每隔 30 秒就試圖進行一次完整同步處理 (請參閱 TS3398 (可能為英文網頁))。另一個例子是某些裝置無法處理來自 Exchange 伺服器的「信箱已滿」回應，導致多次重複連線。因此，這類裝置會試圖在一分鐘之內，連線並同步處理信箱 60 次以上，不但消耗裝置的電力，更導致伺服器的效能問題。

對 IT 管理員而言，管理不同用戶端類型中的行動裝置並平衡可用的伺服器資源，是一項令人望而生畏的挑戰。要在 Exchange 2010/2007 Client Access 伺服器 (CAS) 或 Exchange 2003 Front-end (FE) 伺服器上，追查是哪一台裝置導致資源消耗不是一個簡單的工作。如前篇文章所述，您可使用 Log Parser，從 IIS 記錄檔擷取有用的統計資料(請參閱下面的附註)，但大多數的系統管理員既無時間也無能力撰寫查詢，從龐大的記錄檔擷取這類資訊。

本文章的目的在為 Exchange 社群的每位成員介紹一個新的 PowerShell 指令碼，用它來找出耗用資源的裝置、協助確認效能趨勢並自動產生報表以進行持續監控。您可使用這個指令碼輕易找出使用者的 EAS 活動，當處理可能累積到數 GB 大小的 IIS 記錄檔時，這會是一項主要的工作。這個指令碼也有助於找出使用多個 EAS 裝置的使用者。您可將指令碼當作是一個工具，用來建立在正常 EAS 活動期間的基準，並將所獲得的基準作為情況惡化時的比較及報告依據。這個指令碼也具備可用於接收電子郵件通知的自動監視功能。

附註：這個指令碼適用於 Exchange 2010、Exchange 2007 及 Exchange 2003 伺服器上的 IIS 記錄檔。
使用 EAS 通訊協定及使用 Microsoft Exchange 的行動裝置間的所有通訊，都會以 W3C (可能為英文網頁) 格式，記錄在 CAS/FE 伺服器上的「IIS 記錄」中。用於記錄的預設 W3C 欄位在 IIS 6.0 及 7.0/7.5 中會不相同 (IIS 7.0 與 7.5 的欄位相同)。這個指令碼兩個版本都適用。

IIS 記錄

因為 EAS 使用 HTTP，所以所有的 EAS 要求都會記錄在 IIS 記錄裡 (IIS 記錄預設為啟用)。在某些情況下，系統管理員會停用 IIS 記錄功能，以節省伺服器上的磁碟空間。請務必檢查記錄功能是否啟用，並按下列步驟確定記錄檔的位置：

IIS 7

1. 展開 [IIS 管理員] 下的伺服器名稱，例如 [ExchangeServer (Contoso\Administrator)]
2. 在 [功能檢視] 中，按兩下 [IIS] 區段內的 [記錄]。

IIS 6

1. 在 [IIS 管理員] 中，用滑鼠右鍵按一下網站名稱 (多數情況下名稱都是 [Default Web Site])，然後選擇 [內容]
2. 按一下 [網站] 索引標籤。

與伺服器通訊時，行動裝置負責的項目

在切入指令碼的細節前，讓我們先來回顧一下在使用 EAS 與 Microsoft Exchange 通訊時，一些行動裝置的重要需求。

• 行動裝置收到伺服器傳回的非預期回應時，裝置本身需負責處理此回應，並在合理的時間內進行適當的重試。此外，裝置也需要負責處理發生在 IIS 外，可能因網路延遲而導致的逾時。
• 在裝置傳送給 IIS/Exchange 的每個要求中，也應該報告使用者代理程式 (可能為英文網頁)。

使用這個指令碼看到的結果為何？

這個指令碼利用 Microsoft Log Parser 2.2 來分析 IIS 記錄檔並產生結果。它會根據您所使用的參數，建立不同的 SQL 查詢供 Log Parser 使用 (請參閱下表)。先前的一篇有關 Log Parser 的部落格文章 Exchange 2003 - Active Sync 報告 (可能為英文網頁)曾提到類似的概念。該文的資訊一樣適用於 Exchange 2010 及 2007。從那篇部落格文章發佈之後，EAS 通訊協定 (可能為英文網頁)已新增多個指令，而這個新指令碼也利用它們來處理記錄檔。

以下即為指令碼在結果中報告的 EAS 指令清單：

Sync、SendMail、SmartForward、SmartReply、GetAttachment、GetHierarchy、CreateCollection、DeleteCollection、MoveCollection、FolderSync、FolderCreate、FolderDelete、FolderUpdate、MoveItems、GetItemEstimate、MeetingResponse、Search、Settings、Ping、ItemOperations、Provision、ResolveRecipients、ValidateCert

如需各 EAS 指令的詳細資訊，請參閱 MSDN 上的 ActiveSync HTTP 通訊協定規範 (可能為英文網頁)。

除這些指令之外，這個指令碼也會記錄下列參數。

1. 使用者

2. 使用者名稱

3. 裝置類型

4. 裝置 ID

5. 使用者代理程式

6. sc-bytes：在 IIS 記錄中啟用這個索引標籤後，才可使用此參數。

7. cs-bytes：在 IIS 記錄中啟用這個索引標籤後，才可使用此參數。

8. time-taken (毫秒)：在 IIS 記錄中啟用這個索引標籤後，才可使用此參數。

9. 要求總數或按 [裝置 ID] 的要求總數

10. 所有 4xx 狀態碼的總數

11. 所有 5xx 狀態碼的總數 (如需相關資訊，請參閱 KB：318380 (IIS 6.0) 及 KB：943891)

12. 409 狀態碼：409 (衝突) - 在建立一或多個中繼集合前，無法於 Request-URI 建立集合。伺服器「絕不能」自動建立這些中繼集合 (參考資料：RFC 4918 (可能為英文網頁))

13. 500 狀態碼：裝置傳送 OPTIONS 指令後，可能會從伺服器收到 500 回應的 MissingCscCacheEntry 錯誤。因為下列親和性的問題則可能導致此狀況：您擁有一個網際網路對向 CAS 陣列 Proxy 處理要求到內部 CAS 陣列。當網際網路對向陣列將要求傳送到內部陣列時，CAS 伺服器會回應第一個 401 狀態碼。下次通訊時，會由內部陣列中的另一個 CAS 伺服器來處理要求。解決問題的方法是使用內部 CAS 陣列來解決此親和性的問題。

14. 503 狀態碼：伺服器目前因暫時性的負載過重，或者正在維護而無法處理要求。這表示此為暫時性的問題，稍待一會兒後問題就會獲得解決。若已知延遲的時間長短，則可能會顯示在 Retry-After 標頭中。若未提供 Retry-After 時，用戶端應以與處理 500 回應的相同方式來處理這個回應。

    附註：503 狀態碼的存在並不代表伺服器在負載過重時必須使用此狀態碼。某些伺服器可能會直接選擇拒絕連線。(參考資料：RFC 2616 (可能為英文網頁))

15. 507 狀態碼：507 (儲存空間不足) 狀態碼表示因為伺服器無法儲存完成要求所需的表示法，以致無法在資源上執行方法。這是一個暫時的情形。收到此狀態碼的要求如為使用者動作所引起，則在被另一使用者要求前絕不可再重複該要求。(參考資料：RFC 4918 (可能為英文網頁))

16. 451 狀態碼：Exchange 2007/2010 在判定裝置應該使用「較好的」CAS 進行 EAS 連線時，會對 EAS 用戶端發出 HTTP 451 回應。用於判定某個 CAS 是否「較好」的邏輯是根據 Active Directory 網站及 CAS 是否被認為是網際網路對向。如果已經指定 Microsoft-Server-ActiveSync 虛擬目錄上的 ExternalUrl 內容時，該 CAS 將被認為是網際網路對向的 EAS 連線。 (參考資料：TechNet 文章 Exchange ActiveSync 傳回 HTTP 451 錯誤及了解 Proxy 與重新導向)

17. TooManyJobsQueued 錯誤：如需 TooManyJobsQueued 的詳細資訊，請參閱如上已提供的 KB：2469722 (可能為英文網頁)

18. OverBudget：預算是使用者或應用程式對個別設定擁有的存取量。預算代表的是使用者可擁有的連線數，或在每分鐘內允許使用者的活動量。(參考資料：TechNet文章)

19. 遵循一般狀態碼 (可能為英文網頁)的子集：

    InvalidContent、ServerError、ServerErrorRetryLater、MailboxQuotaExceeded、DeviceIsBlockedForThisUser、AccessDenied、SyncStateNotFound、DeviceNotFullyProvisionable、DeviceNotProvisioned、ItemNotFound、UserDisabledForSync

您可以此指令碼做什麼？

您可使用此指令碼處理記錄，以擷取下列詳細資訊：

1. 依使用者/裝置 ID 區分的連線次數 (傳送最多要求到伺服器的使用者/裝置)
2. 每小時/日的連線次數 (協助判斷使用者/裝置傳送要求的頻率，輸入時間以秒為單位)
3. 依具有特定臨界值限制的裝置區分的連線次數 (您可在此指定連線/要求次數限制，即每小時/日傳送 1000 個要求的所有使用者等)
4. 匯出結果 (CSV 格式)
5. 結果的 HTML 報告
6. 監控的電子郵件報告 (CSV/HTML 格式)

先決條件：

使用本指令碼前，請確認您電腦上已安裝下列軟體：

• Log Parser 2.2 (可能為英文網頁)。
• Windows PowerShell 2.0 (Windows 7 及 Windows 2008 R2 已依預設安裝)

指令碼參數

本指令碼的使用方法

下列範例 (與指令) 說明如何使用指令碼，以及使用情境。

連線次數大於 1000

下列指令會剖析 W3SVC1 資料夾中所有的 IIS 記錄，並僅依使用者/裝置報告大於 1000 的連線次數。

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000

[在上述指令中，指令碼 ActiveSyncReport.ps1 位於磁碟 C 的根目錄下；「-IISLog」切換控制指定 IIS 記錄的預設位置；「-LogparserExec」將點切換至可執行 Log Parser 應用程式檔案的位置；「-ActiveSyncOutputFolder」切換控制提供輸出或結果檔案的儲存位置；設定值為 1000 的「MinimumHits」 為上表所說明的指令碼參數]

輸出格式：

若裝置每天傳送超過 1000 個要求，通常即會視為「高用量」。連線 (要求) 次數超過 1500 時，則裝置或環境可能有問題。有此種情形時，應進一步調查裝置與其使用者活動。

在真實案例中，我們注意到的一種情況是多位使用者透過 EAS 大量 (約 2.5 萬次，每小時 1000 次) 連線至其 Exchange Server，導致伺服器資源用盡。深入調查後，發現這些使用者的要求，是後端電子郵件伺服器的 507 錯誤所造成的。與這些 EAS 使用者討論後發現，這段時間以來他們的信箱大小皆已達到上限 (25 MB)，且試圖刪除各個資料夾內的電子郵件，以降低信箱檔案大小。在此情況下，您亦可能在 EAS 要求的 IIS 記錄中看到 HTTP 503 (‘TooManyJobsQueued’) 回應，如 KB：2469722 (可能為英文網頁) 所述

隔離特定裝置 ID

下列指令會剖析 C:\IISLogs 資料夾下所有的 IIS 記錄，並尋找裝置 ID xxxxxx，顯示其每小時統計資訊。

.\ActiveSyncReport.ps1 -IISLog " C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports –DeviceID xxxxxx -Hourly

輸出格式：

藉由上述資料，您可挑選個別的使用者/裝置，並查看其每小時趨勢。這有助於確定問題是使用者或程式動作所造成。

在真實案例中，我們必須找出到底是哪一個裝置在修改行事曆項目。我們從檢查使用者/裝置的活動著手，將使用者/裝置傳送到伺服器的不同指令排序，然後集中檢查是哪些使用者/裝置在傳送 MeetingResponse 指令及其傳送頻率、期間、與其他相關細節。這樣有助於將問題縮小到相關使用者與其行事曆專有的活動，以更妥善的處理根本的行事曆問題。

另一個要觀察的裝置相關命令與錯誤為 Options 指令，如果裝置對此一指令的執行不成功，則會將 HTTP 409 錯誤碼傳回 IIS 記錄中。

隔離單一日期

下列命令僅會剖析 W3SVC1 資料夾中符合 12-24-2011 這個日期的檔案，且僅報告大於 1000 的連線次數。

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 –Date 12-24-2011

輸出格式：

您可藉由上述資訊，識別出傳送大量要求的使用者。同時，您可在本欄內看到使用者傳送的指令類型。這有助於提出更直接且有效的疑難排解技巧。

您應該注意哪些現象？

以本指令碼協助分析 IIS 記錄時，您應該注意一再重複傳送的某個特定指令。特定指令的傳送頻率非常重要，經常失敗的任何命令也非常重要，應進一步探究。我們應觀察與比較特定指令執行前後的等待時間。一般而言，執行時間過長或導致伺服器延遲回應的指令，都可能有問題且應深入調查。但請注意一個例外現象：指令 Ping 雖然執行時間長且常在記錄檔案內出現，但這是可預期的正常現象。

如果持續無法連線到某個裝置且出現 403 錯誤碼時，表示該裝置未啟用 EAS 式存取。有時行動裝置使用者抱怨連線問題時，並未意識到他們其實未正確輸入認證資料 (行動裝置上這類的失誤顯然難以避免)。查看記錄時，您可專注於該一使用者，且可能發現該使用者的裝置在發出 Provision 指令後失敗。

產生監控報告

您可能會想要建立報告，或產生包含使用者活動報告及其細節的電子郵件。

下列指令會剖析 W3SVC1 資料夾內所有的 IIS 記錄檔案，且僅報告大於 1000 的連線次數，並產生 HTML 格式的結果報告。

.\ActiveSyncReport.ps1 -IISLog "C:\inetpub\logs\LogFiles\W3SVC1" -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -MinimumHits 1000 -HTMLReport

下列指令會剖析 C:\Server1_Logs 及 D:\Server2_Logs 資料夾內的所有檔案，並將所產生的報告以電子郵件寄到 user@contoso.com。

.\ActiveSyncReport.ps1 -IISLog "C:\Server1_Logs",”D:\Server2_Logs” -LogparserExec “C:\Program Files (x86)\Log Parser 2.2\LogParser.exe” -ActiveSyncOutputFolder c:\EASReports -SendEmailReport -SMTPRecipient user@contoso.com –SMTPSender user2@contoso.com -SMTPServer mail.contoso.com

我們誠摯地希望此指令碼對您有益。若此指令碼有助於減輕您的負擔，請不吝與我們分享，也請提供讓我們能進一步改進的寶貴意見。

Konstantin Papadakis 及 Brian Drepaul

特別致謝：
M. Amir Haque、Will Duff、Steve Swift、Angelique Conde、Kary Wall、Chris Lineback 及 Mike Lagase

這是翻譯後的部落格文章。英文原文請參閱 A script to troubleshoot issues with Exchange ActiveSync