このドキュメントでは、Cisco Unity Connection(CUC)とMicrosoft Exchange On-Premisesの導入間で発生する同期の問題について説明します。
CUC について十分に理解しておくことをお勧めします。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、初期(デフォルト)設定の状態から起動しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
同期の問題には、次の3種類があります。
このセクションでは、3つの問題のトラブルシューティング方法について説明します。最初の2つの問題は、問題のトラブルシューティング方法が同じであるため、1つのセクションに結合されます。
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はポート7080でCUCサーバと通信します。このセクションでは、問題をトラブルシューティングするための手順について説明します。
管理 CLI
Root
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チームを関与させます。
CUCがExchangeサーバから通知をオンデマンドで受信し、その更新がCUCメールボックスに反映されない場合は、TACに連絡して問題のトラブルシューティングを依頼してください。
改定 | 発行日 | コメント |
---|---|---|
1.0 |
02-Apr-2015 |
初版 |