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

ダウンロードオプション

PDF (691.9 KB)
Adobe Reader を使ってさまざまなデバイスで表示
ePub (473.6 KB)
iPhone、iPad、Android、ソニーの Reader、または Windows Phone 上で、さまざまなアプリを使って表示
Mobi (Kindle) (455.6 KB)
Kindle デバイスで、または Kindle アプリを使って複数のデバイスで表示

Updated: 2015 年 4 月 2 日

Document ID:118883

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

シスコは世界中のユーザにそれぞれの言語でサポートコンテンツを提供するために、機械と人による翻訳を組み合わせて、本ドキュメントを翻訳しています。ただし、最高度の機械翻訳であっても、専門家による翻訳のような正確性は確保されません。シスコは、これら翻訳の正確性について法的責任を負いません。原典である英語版（リンクからアクセス可能）もあわせて参照することを推奨します。

内容

概要

前提条件

要件

使用するコンポーネント

問題

トラブルシュート

CUCとExchange間の遅延または同期なし

Exchange ServerからCUCへの遅延同期

概要

このドキュメントでは、Cisco Unity Connection(CUC)とMicrosoft Exchange On-Premisesの導入間で発生する同期の問題について説明します。

前提条件

要件

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

使用するコンポーネント

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

このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期（デフォルト）設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。

問題

同期の問題には、次の3種類があります。

No synchronization
両側からの遅延同期（CUCからExchange Serverへ、またはその逆）
Exchange ServerからCUCへの遅延同期

トラブルシュート

このセクションでは、3つの問題のトラブルシューティング方法について説明します。最初の2つの問題は、問題のトラブルシューティング方法が同じであるため、1つのセクションに結合されます。

CUCとExchange間の遅延または同期なし

CUCとExchangeの間で同期が行われなかったり、同期が遅れたりする理由は様々です。このシナリオでは、CUCとExchange Server間の通信障害を、CLI経由またはReal-Time Monitoring Tool(RTMT)経由のログ収集によって確認します。

RTMT

[Trace & Log Central] > [Collect Files]を選択します。[Connection Mailbox Sync logs]を選択し、続行します。

Root

CLIを使用してCUC(/var/log/active/cuc)で次を実行します。

ファイルを表示するには、cat <filename>またはvi <filename>と入力します。ここで、<filename>はdiag_CuMbxSync_xxxxxx.ucです。

管理 CLI

ログはAdmin CLIでも表示できますが、非常に困難です。

ファイルをリストするには、ファイルリストactivelog /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の単一受信トレイのトラブルシューティングに関するTechNoteドキュメントには、CuMbxSyncログに表示されるさまざまなエラーに関する情報が記載されています。

CuMbxSyncログにエラー/障害がない場合は、CsEwsとCuMbxSyncマイクロトレース（すべてのレベル）を有効にします。[Cisco Unity Connection Serviceability] > [Trace] > [Micro Trace]の順に選択します。ユーザの[Unified Messaging Account]ページで[reset]オプションをクリックし、ログを再度収集します。さらにサポートが必要な場合は、Cisco Technical Assistance Center（TAC）に連絡してください。

Exchange ServerからCUCへの遅延同期

Exchangeはポート7080でCUCサーバと通信します。このセクションでは、問題をトラブルシューティングするための手順について説明します。

ポート7080が開いており、CUCがこのポートでリッスンしていることを確認します。
管理 CLI
Root
ExchangeサーバがJetty通知を送信し、CUCがこれらのJetty通知を受信することを確認するために、ExchangeサーバとCUCサーバの両方でネットワークキャプチャを収集します。
CUC CLIで、utils network capture file SIBTrace count 100000 size ALLと入力します。
Exchangeで、Wiresharkをダウンロードして実行します。
CUCキャプチャでは、ポート7080（通知の受信に使用されるポート）に次のパケットパターンが表示されます。
ExchangeサーバからCUCに通知が送信され、一部のプロキシサーバには送信されていないことを（画面キャプチャで強調表示されたIPアドレスを使用して）確認します。ポート7080で同じパターンが表示されない（またはポート7080でトラフィックが表示されない）場合は、Exchangeサーバチームに確認してください。ExchangeからCUCへの通知には、次の2種類があります。
- キープアライブ通知
- メッセージ操作通知
キープアライブメッセージがExchangeからCUCに送信されます。キープアライブ通知メッセージの例を次に示します。
Exchangeサーバは、サブスクライブされたすべてのユーザに対して、この通知を5分（デフォルト）ごとに送信します。この通知は、ExchangeからExchange Web Services(EWS)クライアント（この場合はCUC）に送信され、CUCでサブスクリプションを維持します。
Exchangeサーバからの通知はJettyによってCUCサーバで受信され、Jettyは通知を解析し、tbl_ExSubscriptionテーブルのデータを更新します。
tbl_ExSubscriptionのエントリ例:
同じ情報は、Admin CLIで表示できます。run cuc dbquery unitydyndb select first 10 * from tbl_exsubscriptionコマンドを入力します。
tbl_ExSubscriptionは、EWS経由でExchangeに登録された各メールボックスのサブスクリプションに関する情報を格納します。timestamputc（前のスクリーンショットで強調表示されています）は、この表の列の1つです。CUCがExchangeサーバからこのサブスクリプションの通知を最後に受信した時刻を示すUTC時刻が含まれます。
CuMbxSyncプロセスには、古いサブスクリプションを2分ごとに監視し、古いエントリの再サブスクリプションを実行するスレッドがあります。サンプルログでは、スレッドは一連のサブスクリプションエントリを古いと見なします。これは理想的なケースではありません（すべてが正常で、Exchangeがキープアライブ通知をタイムリーに送信する場合）。このフィールドは、CuMbxSyncプロセスによって古いサブスクリプションを検出するために使用されます。古いサブスクリプションを除外するために使用される条件はtimestamputc < （CurrentTime - 15分）です。
Exchange側のサブスクライバメールボックスに変更がない場合でも、Exchange Serverはデフォルトで、5分インターバルの間に各サブスクライバ（Exchangeサーバのサブスクライバ）に通知を送信します。
Exchangeからのキープアライブ通知は、「Connection Jetty」ログで確認できます。これらのログは、RTMT([Trace & Log Central] > [Collect Files] > [Connection Jetty]を選択して続行)またはルートアクセス(/usr/local/jetty/logs)から収集できます。
このログは、Exchange Serverから送信されたキープアライブ通知に対応するCUCから送信された応答を示します。キープアライブ通知がExchangeからCUCに届かない場合、サブスクリプションは16分（約）ごとに再サブスクリプションされ、その後にメールボックスの同期が行われます。
このような動作の考えられる理由は、次のいずれかになります。
- Exchange Serverでのプロキシ設定
- CUCでのネットワークアドレス変換(NAT)の設定
- CUCとExchange Server間のファイアウォール設定など
この動作の実際の理由を調べるには、ネットワークチームとExchangeチームを関与させます。
CUCがExchangeサーバから通知をオンデマンドで受信し、その更新がCUCメールボックスに反映されない場合は、TACに連絡して問題のトラブルシューティングを依頼してください。