無法使用因為 Exchange 資源消耗的 Exchange ActiveSync 連線


狀況


初始徵狀會包括使用者無法與 Exchange。同步化他們的裝置 此外,可能會發生下列徵狀:
  • 在應用程式記錄中的 Exchange 伺服器上,您可能會看到下列事件:

事件來源: 伺服器動態同步
事件識別碼: 3007
描述:
交換信箱伺服器回應逾時: 伺服器: [mail.contoso.com] 使用者: [user@contoso.com]。Exchange ActiveSync 伺服器無法及時與 Exchange 信箱伺服器。請確認 Exchange 信箱伺服器運作正常且沒有超載。

事件來源: 伺服器動態同步
事件識別碼: 3014
Description:
Exchange 信箱伺服器: [mail.contoso.com] 已達到其逾時臨界值。信箱伺服器會防止新的要求,[60] 秒。

  • 允許到信箱伺服器的 RPC 連線的數目可能會超過建議的限制。
    可以在任何時候資訊儲存庫可讓您開始拒絕新的連線之前執行的 RPC 要求的最大數目是 Exchange 2007 的 500,而 2010年,但是計數器應低於 70 根本的時間。這個上面的任何項目表示效能瓶頸。若要確認此行為,其中一個可以檢查效能監視器計數器 」 MSExchangeIS\RPC 要求 」 會顯示伺服器是否上述建議的限制。

    請參閱http://technet.microsoft.com/en-us/library/bb201689%28EXCHG.80%29.aspx

  • 在 W3SVC 記錄檔中,您會看到 HTTP 409 」 和 「 動態伺服器 Microsoft 同步要求傳回的 503 回應。
    您也可能會看到傳回"TooManyJobsQueued"的 W3SVC 記錄檔中的錯誤。請參閱下列的範例:

    2010-09-09 21:35:35 W3SVC1 10.0.0.10 文章 /Microsoft-Server-ActiveSync/default.eas 使用者 = < 使用者 > & DeviceId = < DeviceID > & DeviceType = < 類型 > & Cmd = 同步 = Ping = < 資料 > 443 網域 \ 使用者 < 使用者 > 代理 10.0.0.20503 0 0

    2010-09-15 00:00:02 W3SVC1 155.109.199.51 張貼 /Microsoft-Server-ActiveSync/default.eas Cmd = Ping & 使用者 = < 使用者 > & DeviceId = < DeviceID > & DeviceType = < 類型 > & 記錄 = 錯誤: TooManyJobsQueued_ 443 網域 \ 使用者10.0.0.20 < 使用者代理 > 503 0 0

  • 檢查 HTTPErr 記錄檔會顯示 Connection_Dropped 的 /Microsoft-Server-ActiveSync 要求。
    您應該可以看到 s 連接埠或來源的連接埠 Connection_Dropped 來自達到相當高的數字。為例:

    2010-09-09 00:27:25 10.0.0.10 64637 10.0.0.20 443 HTTP/1.1 張貼 /Microsoft-Server-ActiveSync?使用者 = < 使用者 > & DeviceId = < DeviceID > & DeviceType = < 類型 > & Cmd = Ping-1 的 Connection_Dropped MSExchangeSyncAppPool
  • 的 Exchange 2003 中,會耗盡伺服器的未分頁集區 (NPP) 記憶體。
    達到連線限制時,即佔去 NPP 而且 HTTP.sys 可讓您開始捨棄 HTTP 連線,一旦伺服器便開始尖峰 100 mb 的 NPP,視伺服器組態而定。一旦伺服器使其更靠近達到到 108 mb,HTTP.sys 會失敗,所有的連線。使用 [工作管理員檢視效能並檢查 [核心記憶體,就可以檢查 NPP。   
  • 如需 Exchange 和 NPP 周圍的詳細資訊,請參閱http://technet.microsoft.com/en-us/library/aa996269(EXCHG.80).aspx

    有關使用 Netstat 之詳細資訊,請參閱http://technet.microsoft.com/en-us/library/cc940097.aspx

    如需下載和使用 TCPView 容器的資訊,請參閱 http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx

     

    原因


    可能因為以下原因是的行動裝置連線和 (或) 裝置軟體的問題。 有幾個的連線失敗的主要原因和耗用記憶體的原因:

    1.伺服器可讓您開始捨棄連線,因為伺服器的要求數目,或要求已經超過允許的應用程式集區 IIS 連線的數目。同樣地,是在 Exchange 伺服器上的 TCP 連接埠限制的原因。

    附註:多個可能的是,伺服器可能會碰到的其他限制 (應用程式集區佇列長度在 CA 或 RPC 要求在信箱伺服器上) 之前已經接近 TCP 連接埠耗盡的其中一個。

    下列的文件討論連接埠耗盡:
    http://technet.microsoft.com/en-us/library/cc540453(EXCHG.80).aspx

    下列的文件更別提使用中視窗和 Exchange MaxUserPort 和 TCP 連線

    http://technet.microsoft.com/en-us/library/cc940037.aspx

    http://technet.microsoft.com/en-us/library/bb397382(EXCHG.80).aspx

    2.使用 Exchange ActiveSync 行動裝置同步處理可能會模擬對伺服器的 DOS 攻擊的行為。中的下列文件所列的一些範例:
    http://technet.microsoft.com/en-us/library/cc182260.aspx

    3。 應用程式集區會接收要求超出它能處理它們的速度。 請將下列的文件的討論:
    http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/9701f9dd-d40b-4d24-a2df-1d1abc13f764.mspx?mfr=true

     

    解決方案


    若要停止這些裝置無法使用 Exchange 資源,並防止可疑的裝置應該封鎖的負擔。 

    重要:使用 iPhone OS 4.0 使用者代理程式 801.293- http://support.apple.com/kb/TS3398所定義的已知問題

    任何包含這個使用者代理程式的 IIS 記錄檔應該加上標幟,並以 OS 4.1 或更快,應該更新該裝置的擁有者 (最好 Io 版本 4.3.x)。建議,這些使用者會封鎖在這個過渡時期。

    裝置可能會封鎖,停用 Exchange ActiveSync 存取裝置擁有者、 關閉裝置,或使用 「 網際網路安全性與加速 (ISA) 或 ForeFront 威脅管理閘道 (TMG) 的篩選器。

    如需有關封鎖的裝置的詳細資訊,請參閱 Microsoft Exchange 小組 (EHLO) 部落格上的下列文章:

    http://msexchangeteam.com/archive/2008/09/05/449757.aspx

    附註:某些裝置可能會繼續嘗試連線到 Exchange 伺服器 (導致大量 TCP 連線) 甚至當使用者停用 Exchange ActiveSync 使用。我們建議您關閉裝置,或封鎖裝置使用的 ISA 篩選條件。

    Exchange Server 2010

    如果可疑的裝置使用者與使用者有 Exchange 2010 信箱,節流可啟動和所有的 Exchange ActiveSync 使用者,若要防止裝置 overburdening Exchange 伺服器。請參閱下列文件從 Microsoft TechNet 線上:

     http://technet.microsoft.com/en-us/library/dd297964.aspx

    若要執行這項操作的步驟會包含在文章中,然而以下是一些範例:

    $ = Get ThrottlingPolicy |Where 物件 {$_。找到 – eq $true}

    $ |設定 ThrottlingPolicy – EASMaxConcurrency 10

    如需有關如何設定節流原則的詳細資訊,請參閱下列主題從 TechNet 線上:

     http://technet.microsoft.com/en-us/library/dd298094.aspx

    若要檢查的其他因素會影響每一裝置的連線

    1. 在 [主要] 資料夾 (主資料夾收件匣) 上有高的項目計數嗎?當 [收件匣] 資料夾中有數個數千個項目並裝置嘗試同步所有這些項目時,您會看到來自這個裝置的連線/要求數量龐大,才能下載所有這些項目。這個方案包括:

      a 設定裝置只同步處理的最後一天,或根據項目數目不超過 3 天該使用者會收到一天。
      b 減少信箱中的項目計數
    2. 使用者帳戶停用的 「 Exchange ActiveSync?這可能會增加裝置與伺服器連線的數目。如果裝置仍然在幾個要求傳送至伺服器,然後關閉該裝置,或篩選器置於封鎖 DeviceID ISA 上的位置。
    3. 使用者已經超過信箱配額限制?如果是的話,裝置就會將無法同步到信箱的新項目,而且可以繼續不斷地嘗試。
    4. 有設定組織中的郵件大小限制嗎?如果沒有任何限制,您可能嘗試同步處理大量資料的裝置。

      附註:除了上述的持續監視使用 Log Parser 可疑的裝置的裝置連線。若需使用 Log Parser 協助,請參閱其他相關資訊。

    找到可疑的裝置時,我們建議客戶連絡裝置廠商,以取得協助判斷為何裝置正在傳送要求的數目太多給 Exchange。

    請參閱一節 「將幫助系統管理員,疑難排解的步驟:"額外巨集指令的 [更多資訊] 區段中,系統管理員可以用來嘗試改善效能,同時疑難排解。

    更多的資訊


    懷疑有哪些裝置?
    通常如果裝置傳送每日超過 1000 個要求,我們建議您調查。

    如果上述 1500年點選率 (要求),可能是裝置或環境上的問題。在裝置與使用者的活動應該加以調查。

    請參閱下列文章從 Exchange 小組部落格和。可以使用 Windows Powershell 用來剖析任何版本的 Exchange Server 的 IIS 記錄檔的 PS1 檔案。

    指令碼,以疑難排解 Exchange ActiveSync 的問題
    http://blogs.technet.com/b/exchange/archive/2012/01/31/a-script-to-troubleshoot-issues-with-exchange-activesync.aspx

    ActiveSyncReport 指令碼
    http://gallery.technet.microsoft.com/scriptcenter/ActiveSyncReport-script-a2417a84

    記錄剖析器可以用不需要指令碼,但是指令碼設計用來篩選根據使用的命令列中指定的準則。 使用上述指令碼,電子郵件警示] 或 [報表也可以建立。

    將幫助系統管理員,疑難排解的步驟執行:

    下列選項會無法解決問題他們會給您更多時間來剖析 IIS 記錄檔,來決定裝置為可疑。

    • 減少傳送持續作用每隔 30 分鐘到 CA 而不是每隔 2 小時的 Exchange 信箱伺服器上的 Keep Alive 時間值。

      在登錄中,下列 「 Microsoft 知識庫 」 中線上文件所述,持續作用值設定為 [30 分鐘 (1800000):
      http://support.microsoft.com/kb/324270  

      以下是登錄值的資訊:
      路徑:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters\
      數值名稱: KeepAliveTime
      實值型別: REG_DWORD-時間 (毫秒)
      有效範圍: 1 0xFFFFFFFF
      預設值: 7200000 (兩小時)

      這個值控制 TCP 嘗試確認閒置的連線仍然原封不動,持續作用封包傳送頻率。如果仍然連線到遠端電腦,它會告知收到持續作用封包。依預設不會傳送持續作用封包。您可以使用程式在連線上設定此值。建議的設定的值是 1800000 (等於 30 分鐘)。(十進位)(需要重新啟動伺服器)

      監督這項設定,如果伺服器連接埠仍被用盡時,則這可能需要降低為 [15 分鐘,而非 30 分鐘。
    • 增加在 IIS 中的 IIS 連線逾時

      預設和建議的值應該是 120 秒。如果它在較高的值進行設定,它應該將設定 120 秒的時間最小建議值為 300 的第二個最大值。
      請參閱下列主題在 TechNet 的線上如需詳細資訊:

      http://technet.microsoft.com/en-us/library/cc182260.aspx

      這可以經由透過屬性的預設的網站中藉由修改連線逾時值 (以秒為單位)。
    • 在 Exchange 2003 信箱及前端伺服器上 ExchangeApplicationPool 為增加 IIS 連線 (佇列長度) 的數目:


      若要關閉背景工作處理序回收 IIS 6.0 中使用網際網路資訊服務管理員
      1。 啟動網際網路資訊服務 (IIS) 管理員。
      2。 展開本機電腦,展開 [應用程式集區、 ExchangeApplicationPool 應用程式集區中,以滑鼠右鍵按一下,然後按一下內容。
      3。 按一下以清除 [資源回收背景工作處理序 (以分鐘為單位)] 核取方塊,然後再按一下 [確定]。

      使用網際網路資訊服務管理員來增加在 IIS 6.0 中的佇列長度
      1。 啟動網際網路資訊服務 (IIS) 管理員。
      2。 展開本機電腦,展開 [應用程式集區、 ExchangeApplicationPool 應用程式集區中,以滑鼠右鍵按一下,然後按一下內容。
      3。 會按一下 [效能] 索引標籤,然後修改 [要求佇列限制] 方塊中的值。預設值為 1000年取代 4000。
      4。 按一下 [確定]。
    • 在 Exchange 2007 和 Exchange 2010 用戶端存取伺服器上 MSExchangeSyncAppPool 增加 IIS 連線 (佇列長度) 的數目

      若要關閉背景工作處理序回收 IIS 7.0 中和其上使用網際網路資訊服務管理員 (這應該停用預設為 MSExchangeSyncAppPool)

      1。 啟動網際網路資訊服務管理員。
      2。電子xpand 本機電腦,然後按一下 [應用程式集區。
      3。n 應用程式集區] 窗格中,按一下適當的應用程式集區,例如 MSExchangeSyncAppPool 或在建立時,新應用程式集區,然後按一下 [進階設定。
      4。 在回收的區段中,修改規則的時間間隔 (分鐘)] 的值。1740 的預設值取代為 0 (零)。零值會關閉背景工作處理序回收。
      5. Click OK.
    • 使用網際網路資訊服務管理員來增加 IIS 7.0 中和其上的佇列長度

      1。 啟動網際網路資訊服務管理員。
      2。 展開本機電腦,然後按一下 [應用程式集區。
      3。 在應用程式集區] 窗格中,按一下適當的應用程式集區,例如 MSExchangeSyncAppPool 或在建立時,新應用程式集區,然後按一下 [進階設定。
      4。 在 [一般的區段中,修改佇列長度值。預設值為 1000年取代 10000。
    • 5. Click OK

    注意: 如果在 Windows 2003 (IIS 6) 上執行 Exchange 2007,請遵循上述步驟,以增加 MSExchangeSyncAppPool 的要求佇列限制。

    如需有關為何,都可能會將它重要 < how="" to=""> 資訊應用程式集區和額外的連結變更這些值的詳細資訊,請參閱下列主題從 TechNet 線上:

    http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/9701f9dd-d40b-4d24-a2df-1d1abc13f764.mspx?mfr=true