Microsoft Exchange內部部署的單收件箱同步問題

簡介

本文檔提供有關Cisco Unity Connection(CUC)和Microsoft Exchange內部部署之間出現的同步問題的資訊。

必要條件

需求

思科建議您瞭解CUC。

採用元件

本文件所述內容不限於特定軟體和硬體版本。

本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除（預設）的組態來啟動。如果您的網路正在作用，請確保您已瞭解任何指令可能造成的影響。

問題

存在三種型別的同步問題：

• 無同步
• 兩端延遲同步（CUC到Exchange Server，反之亦然）
• 從Exchange Server到CUC的延遲同步

疑難排解

本節介紹如何解決這三個問題。前兩個問題合併為一個部分，因為解決這些問題的方法是一樣的。

CUC和Exchange之間的同步延遲或不同步

CUC和Exchange之間沒有同步或延遲同步的原因可能有多種。在此案例中，請通過CLI或通過即時監控工具(RTMT)收集日誌來檢查CUC和Exchange Server之間的通訊故障。

RTMT

選擇Trace & Log Central > Collect Files。選擇Connection Mailbox Sync logs並繼續。

根

在CUC(/var/log/active/cuc)上，通過CLI:

若要檢視檔案，請輸入cat <filename>或vi <filename>，其中<filename>是diag_CuMbxSync_xxxxxxxx.uc。

管理員CLI

日誌也可通過管理CLI檢視，但非常困難。

若要列出檔案，請輸入file list activivelog /cuc/diag_CuMbxSync* detail reverse。

要檢視檔案，請輸入file view activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc，其中xxxxxxxx是檔案編號。

若要將檔案傳輸到Secure FTP(SFTP)伺服器，請輸入file get activelog /cuc/diag_CuMbxSync*。

檢查最新的CuMbxSync日誌以查詢任何HTTP故障或警告。由於跟蹤中預設寫入錯誤或警告，因此此時不需要啟用跟蹤。

HTTP故障可能停止（間歇或完全）從CUC到Exchange伺服器的消息傳遞操作同步，反之亦然。如果日誌中出現HTTP故障，則下一步是排除故障並修復這些問題。

Unity Connection Single Inbox Troubleshooting TechNote文檔提供有關CuMbxSync日誌中可見的各種錯誤的一些資訊。

如果CuMbxSync日誌中沒有錯誤/故障，則啟用CsEws和CuMbxSync微跟蹤 — 所有級別。選擇Cisco Unity Connection Serviceability > Trace > Micro Trace。點選使用者的Unified Messaging Account頁面上的重置選項，並再次收集日誌。如需進一步的協助，請聯絡思科技術協助中心(TAC)。

從Exchange Server到CUC的延遲同步

Exchange通過埠7080與CUC伺服器通訊。本節提供的步驟用於對問題進行故障排除。

1. 確保埠7080處於開啟狀態且CUC在此埠上監聽。

   管理員CLI

   

   根

   

2. 在Exchange伺服器和CUC伺服器上收集網路捕獲，以確認Exchange伺服器傳送Jetty通知，並且CUC收到這些Jetty通知。

   在CUC CLI中，輸入utils network capture file SIBTrace count 100000 size ALL。

   在Exchange上，下載並運行Wireshark。

   在CUC捕獲中，您應該在埠7080（用於接收通知的埠）上看到以下資料包模式：

   

   確認通知已從Exchange伺服器傳送到CUC，而不是傳送到某個代理伺服器（藉助螢幕捕獲中突出顯示的IP地址）。如果您在埠7080上沒有看到相同的模式（或者沒有在埠7080上看到任何流量），請與Exchange伺服器團隊協商。從Exchange到CUC的通知有兩種型別：

   • 保持活動通知
   • 消息操作通知

   保持連線消息從Exchange傳送到CUC。以下是保活通知消息示例：

   

   

   Exchange Server每五分鐘（預設情況下）向每個訂閱使用者傳送一次此通知。此通知由Exchange傳送到Exchange Web服務(EWS)客戶端（在本例中為CUC），以便在CUC中保持訂閱狀態。

   Jetty在CUC伺服器上接收來自Exchange伺服器的通知，該伺服器會分析通知並更新tbl_ExSubscription表中的資料。

   tbl_ExSubscription中的示例條目:

   

   通過管理員CLI可以檢視相同的資訊。輸入run cuc dbquery unitydyndb select first 10 * from tbl_exsubscription命令。

   tbl_ExSubscription儲存有關通過EWS向Exchange註冊的每個郵箱訂閱的資訊。timestamputc（在前一個螢幕截圖中突出顯示）是此表中的列之一。它包含以UTC時間為單位的日期時間，該時間指示CUC上次從Exchange伺服器接收此訂閱的通知的時間。

   CuMbxSync進程有一個執行緒，該執行緒每兩分鐘監控一次過時訂閱，並對任何過時條目執行重新訂閱。在示例日誌中，執行緒認為一組預訂條目已過時。這不是理想的情況（如果一切正常，並且Exchange及時傳送保持活動狀態通知）。 此欄位用於檢測CuMbxSync進程過時的訂閱。用於篩選過時訂閱的條件是timestamputc <（CurrentTime - 15分鐘）。

   即使Exchange端的訂閱者郵箱沒有發生更改，預設情況下，Exchange Server仍會以五分鐘間隔為每個訂閱者（Exchange伺服器上的訂閱者）傳送通知。

   來自Exchange的「保持連線」通知可在「連線碼頭」日誌中看到。這些日誌可以從RTMT(選擇Trace & Log Central > Collect Files > Connection Jetty並繼續)或通過Root Access(/usr/local/jetty/logs)收集。

   

   此日誌顯示CUC傳送的響應，該響應與Exchange Server傳送的保持活動通知相對應。如果保持連線通知沒有從Exchange到達CUC，則訂閱將在每16分鐘（大約）後重新訂閱，然後才會進行郵箱同步。

   此類行為的潛在原因可能是以下之一：

   • Exchange Server上的代理配置
   • CUC的網路地址轉換(NAT)配置
   • CUC和Exchange Server之間的防火牆配置等

   讓網路團隊和Exchange團隊參與進來，以瞭解此行為的實際原因。

   如果CUC及時收到來自Exchange伺服器的通知，並且更新未反映在CUC郵箱中，請聯絡TAC以尋求解決此問題的幫助。