このドキュメントでは、Cisco Unity Connection(CUC)とMicrosoft Exchangeのオンプレミス導入の間で見られる同期の問題について説明します。
CUC について十分に理解しておくことをお勧めします。
このドキュメントの内容は、特定のソフトウェアやハードウェアのバージョンに限定されるものではありません。
このドキュメントの情報は、特定のラボ環境にあるデバイスに基づいて作成されました。このドキュメントで使用するすべてのデバイスは、クリアな(デフォルト)設定で作業を開始しています。対象のネットワークが実稼働中である場合には、どのようなコマンドについても、その潜在的な影響について確実に理解しておく必要があります。
同期に関する問題には、次の3つのタイプがあります。
このセクションでは、3つの問題のトラブルシューティング方法について説明します。最初の2つの問題は、問題のトラブルシューティングのアプローチが同じであるため、1つのセクションに組み合わされます。
CUCとExchangeの間で同期が行われない、または同期が遅延する理由はさまざまです。このシナリオでは、CLIを使用するか、Real-Time Monitoring Tool(RTMT)を使用してログを収集することにより、CUCとExchange Serverの間の通信障害を確認します。
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を使用して表示することもできますが、非常に困難です。
ファイルを一覧表示するには、file list 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 Single Inbox Troubleshooting TechNote』ドキュメントには、CuMbxSyncログに記録されるさまざまなエラーの情報の一部が記載されています。
CuMbxSyncログにエラーまたは障害がない場合は、CsEwsおよびCuMbxSyncマイクロトレースを有効にします(すべてのレベル)。Cisco Unity Connection Serviceability > Trace > Micro Traceの順に選択します。ユーザのユニファイドメッセージングアカウントページでリセットオプションをクリックして、ログをもう一度収集します。さらにサポートが必要な場合は、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分ごとに送信します(デフォルト)。この通知は、CUCでサブスクリプションを維持するために、ExchangeからExchange Web Services(EWS)クライアント(この場合は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はデフォルトで、すべてのサブスクライバ(Exchangeサーバ上のサブスクライバ)に対して5分間隔で通知を送信します。
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
|
初版 |