Microsoft Exchange オンプレミス導入での単一受信トレイの同期に関する問題

概要

この資料は Cisco Unity Connection （CUC）と Microsoft Exchange オン前提配備の間で見られる同期に関する問題で情報を提供したものです。

前提条件

要件

CUC について十分に理解しておくことをお勧めします。

使用するコンポーネント

このドキュメントは、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されたものです。 このドキュメントで使用するすべてのデバイスは、クリアな（デフォルト）設定で作業を開始しています。 ネットワークが稼働中の場合は、コマンドが及ぼす潜在的な影響を十分に理解しておく必要があります。

問題点

同期に関する問題には 3 つの型があります:

• No synchronization
• 両側（CUC からの Exchange サーバへの遅らせられた同期またその逆にも）
• Exchange サーバからの CUC への遅らせられた同期

トラブルシューティング

このセクションは方法で情報を 3 つの問題を解決する提供します。 最初の 2 つの問題は 1 セクションに問題を解決するアプローチが同じであるので結合されます。

遅らせられるまたは CUC と Exchange 間の同期無し

または CUC と Exchange 間の遅らせられた同期ないさまざまな原因がある可能性があります。 このシナリオでは、実時間監視 ツール（RTMT）によって CLI によってまたはログ 収集によって CUC と Exchange サーバ間の通信障害をチェックして下さい。

RTMT

『Trace』 を選択 して下さい及びログ本部は > ファイルを集めます。 メールボックス同期化ログを『Connection』 を選択 し、続行して下さい。

root

CLI による CUC （/var/log/active/cuc）:

<filename> が diag_CuMbxSync_xxxxxxxx.uc であるところで、ファイルを表示するために、cat <filename> または VI を <filename> 入力します。

Admin CLI

ログはまた Admin CLI によって調べることができますがそれはかなり困難です。

ファイルをリストするために、ファイル リスト activelog /cuc/diag_CuMbxSync を入力して下さい*反転を詳述して下さい。

ファイルを表示するために、xxxxxxxx がファイル番号であるファイル ビュー activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc を入力します。

ファイルを FTP セキュア（SFTP）サーバに転送するために、ファイル名を得ます activelog /cuc/diag_CuMbxSync を入力して下さい*。

あらゆる HTTP 失敗か警告があるように CuMbxSync 最新のログを確認して下さい。 エラーか警告がトレースにデフォルトで書かれるので、トレースをこの時点で有効に する必要がありません。

HTTP 失敗は CUC から Exchange サーバに（断続的または完全に）メッセージング オペレーション 同期をまたその逆にも停止する可能性があります。 HTTP 失敗がログで見られる場合、次 の ステップはこれらの問題を解決し、解決することです。

Unity Connection 単一 インボックス トラブルシューティングTECHNOTE 資料は CuMbxSync ログで見られるさまざまなエラーで情報を提供したものです。

CuMbxSync の No エラー/あったら障害が記録 して下さい、CsEws を有効に すれば CuMbxSync マイクロは-すべてのレベルをトレースします。 Unity Connection サービサビリティ > トレースを > マイクロ トレース 『Cisco』 を選択 して下さい。 ユーザの Unified Messaging アカウント ページの Reset オプションをクリックし、ログをもう一度集めて下さい。 さらにサポートが必要な場合は、Cisco Technical Assistance Center（TAC）に連絡してください。

Exchange サーバからの CUC への遅らせられた同期

Exchange はポート 7080 の CUC サーバと通信します。 このセクションは問題を解決するためにステップを提供します。

1. ポート 7080 を開いています確認すれば CUC はこのポートで受信します。

   Admin CLI

   

   root

   

2. Exchange サーバが突堤通知を送信 し、CUC がこれらの突堤通知を受信することを確認するために Exchange サーバおよび CUC サーバ両方でネットワーク キャプチャを集めて下さい。

   CUC CLI では、utils ネットワーク キャプチャ ファイル SIBTrace 数 100000 サイズをすべて入力して下さい。

   Exchange で、Wireshark をダウンロードして実行して下さい。

   CUC キャプチャでは、ポート 7080 （通知を受信するのに使用されるポート）のこのパケット パターンを見るはずです:

   

   確認して下さい（スクリーンキャプチャーで強調表示される IP アドレスの助けによって）通知がから CUC とないプロキシサーバに Exchange サーバ 送信 された。 ポート 7080 で同じパターンを見なければ（またはポートのトラフィックを、チェックします Exchange サーバ チームと 7080）参照しないで下さい。 Exchange からの CUC への通知は 2 つの型である可能性があります:

   • キープアライブ通知
   • メッセージ オペレーション 通知

   キープアライブ メッセージは Exchange から CUC に送られます。 サンプル キープアライブ 通知 メッセージはここにあります:

   

   

   Exchange サーバは 5 分毎にこの通知を各定期講読されたユーザ向けの（デフォルトで）送信 します。 この通知は Exchange Web サービス（EWS）クライアント（CUC この場合）に Exchange によって CUC でサブスクリプションを稼働した保存するために送信 されます。

   Exchange サーバからの通知は通知を解析し、tbl_ExSubscription 表のデータをアップデートする突堤によって CUC サーバで受信されます。

   tbl_ExSubscription のサンプル エントリ:

   

   同じ情報は Admin CLI によって表示することができます。 * tbl_exsubscription コマンドからの…実行 cuc dbquery unitydyndb 選定された最初 10 を入力して下さい。

   tbl_ExSubscription は EWS によって Exchange に登録されている各メールボックス サブスクリプションについての情報を保存します。 timestamputc は（前のスクリーン ショットで強調表示される）この表のカラムの 1 つです。 それは示す UTC 時間にこのサブスクリプションのための通知が Exchange サーバから CUC によって最後に受信された時間ことを日付時刻が含まれています。

   CuMbxSync プロセスに古いサブスクリプションのための監視が 2 分毎にあらゆる古いエントリのための resubscription をするスレッドがあり。 サンプル ログでは、スレッドは古いように一組のサブスクリプション エントリを考慮します。 これは（すべてがうまくあり、Exchange がキープアライブ通知をタイムリーに送信 すれば）理想的なケースではないです。 このフィールドが CuMbxSync プロセスによって古いサブスクリプションを検出するのに使用されています。 古いサブスクリプションをフィルタ・アウトするのに使用される条件が timestamputc < です（CurrentTime - 15 分）。

   加入者のメールボックスに変更が Exchange 側になくても、Exchange サーバはまだ 5 分間隔でデフォルトで各サブスクライバ（Exchange サーバのサブスクライバ）のための通知を送信 します。

   Exchange から来るキープアライブ通知は「接続突堤」ログで見られる場合があります。 これらのログは RTMT から（『Trace』 を選択 して下さい及びログ本部は > ファイル > 接続突堤を集め、続行します）またはルートアクセス（/usr/local/jetty/logs）によって集めることができます。

   

   このログは Exchange サーバによって送信 される キープアライブ通知に相当して CUC によって返される応答を示します。 それからサブスクリプションが 16 分毎に後に（およそ）および再サブスクライブされるキープアライブ通知が Exchange からの CUC で着かなければそれからメールボックス 同期だけを発生しますします。

   そのような動作のための潜在的な理由はこれらの 1 つである可能性があります:

   • Exchange サーバのプロキシコンフィギュレーション
   • CUC のネットワーク アドレス変換（NAT） 設定
   • CUC と Exchange サーバ間のファイアウォール構成、等

   この動作の実際の原因を得るためにネットワーク チームおよび Exchange チームを含んで下さい。

   CUC が Exchange サーバ オン・タイムから通知を受信し、アップデートが CUC メールボックスに反映されなかったら、問題を解決する支援に関しては TAC に連絡して下さい。