Голосовая связь и система унифицированных коммуникаций : Cisco Unity Connection

Одиночные входящие Проблемы синхронизации с Microsoft Exchange собственные развертывания

5 апреля 2016 - Машинный перевод
Другие версии: PDF-версия:pdf | Английский (22 августа 2015) | Отзыв

Введение

Этот документ предоставляет сведения о Проблемах синхронизации, замеченных между Cisco Unity Connection (CUC) и Microsoft Exchange Собственные развертывания.

Внесенный Рэтнешем Нэтом и Анирадхом Мэвилэкэнди, специалистами службы технической поддержки Cisco.

Предварительные условия

Требования

Cisco рекомендует ознакомиться с CUC.

Используемые компоненты

Настоящий документ не имеет жесткой привязки к каким-либо конкретным версиям программного обеспечения и оборудования.

Сведения, представленные в этом документе, были получены от устройств, работающих в специальной лабораторной среде. Все устройства, описанные в этом документе, были запущены с чистой (стандартной) конфигурацией. В рабочей сети необходимо изучить потенциальное воздействие всех команд до их использования.

Проблемы

Существует три типа Проблем синхронизации:

  • No synchronization
  • Задержанная синхронизация от обеих сторон (CUC к Серверу Exchange и наоборот)
  • Задержанная синхронизация от Сервера Exchange до CUC

Устранение неполадок

Этот раздел предоставляет сведения о том, как решить эти три проблемы. Первые две проблемы объединены в один раздел, поскольку подход для решения проблем является тем же.

Задержанный или никакая синхронизация между CUC и Exchange

Могли быть различные причины, по которым нет никакой или задержанной синхронизации между CUC и Exchange. В этом сценарии проверьте сбои связи между CUC и Сервером Exchange или через CLI или регистрационным набором через устройство контроля в реальном времени (RTMT).

RTMT

Выберите Trace и Log Central> Collect Files. Выберите журналы Connection Mailbox Sync и продолжитесь.

Root

На CUC (/var/log/active/cuc) через CLI:

Для просмотра файла введите <filename> кошки или <filename> vms, где <filename> является diag_CuMbxSync_xxxxxxxx.uc.

CLI admin

Журналы могут также быть просмотрены через CLI Admin, но это довольно трудно.

Для распечатки файлов введите список файлов activelog/cuc/diag_CuMbxSync* подробный реверс.

Для просмотра файла войдите , файл просматривают activelog/cuc/diag_CuMbxSync_xxxxxxxx.uc, где xxxxxxxx является номером документа.

Для передачи файлов Безопасному FTP (SFTP) сервер войдите , файл получают activelog/cuc/diag_CuMbxSync*.

Проверьте последние журналы CuMbxSync для любых сбоев HTTP или предупреждений. Так как ошибки или предупреждения записаны по умолчанию в следах, не требуется для разрешения трассировок на этом этапе.

Сбои HTTP могли остановить (периодически или полностью) обменивающуюся сообщениями синхронизацию операции от CUC до Сервера Exchange и наоборот. Если сбои HTTP замечены в журналах, то следующий шаг должен устранить неполадки и устранить эти проблемы.

Unity Connection Одиночный Входящий документ Технических примечаний по поиску и устранению проблем предоставляет некоторую информацию о различных ошибках, замеченных в журналах CuMbxSync.

Если нет никаких ошибок / сбои в журнале CuMbxSync, то не разрешают CsEws и CuMbxSync микро трассировки - все уровни. Выберите Cisco Unity Connection Serviceability> Trace> Micro Trace. Нажмите опцию reset на странице Unified Messaging Account Пользователя и соберите журналы еще раз. Свяжитесь с Центром технической поддержки Cisco (TAC) для дальнейшей поддержки.

Задержанная синхронизация от сервера Exchange до CUC

Exchange связывается с сервером CUC на порту 7080. Этот раздел предоставляет шаги для решения проблемы.

  1. Гарантируйте, что порт 7080 открыт, и CUC слушает на этом порту.

    CLI admin

    Root

  2. Соберите сбор сетевых данных и в Сервере Exchange и в сервере CUC, чтобы подтвердить, что Сервер Exchange передает Гагатовые уведомления, и CUC получает эти Гагатовые уведомления.

    В CLI CUC введите utils сетевой перехват файла размер количества 100000 SIBTrace ALL.

    На Exchange, загрузках и выполняют Wireshark.

    В перехвате CUC необходимо видеть этот пакетный образец на порту 7080 (порт использовал получать уведомления):

    Подтвердите (с помощью IP-адреса, выделенного в снимке экрана), который уведомление было передано от Сервера Exchange до CUC а не к некоторому прокси-серверу. Если вы не видите тот же образец в порту 7080 (или не смотрите трафик на порту 7080), согласуйте с командой Сервера Exchange. Уведомления от Exchange до CUC могли иметь два типа:

    • Уведомления поддержки активности
    • Уведомление операции сообщения

    Сообщения поддержки активности передаются от Exchange до CUC. Вот типовое сообщение с уведомлением поддержки активности:

    Сервер Exchange передает это уведомление каждые пять минут (по умолчанию) за каждым подписанным пользователем. Это уведомление передается Exchange клиенту веб-служб Exchange (EWS) (CUC в этом случае) для поддержания подписок в CUC.

    Уведомления от Сервера Exchange получены в сервере CUC Причалом, который анализирует уведомления и обновляет данные в tbl_ExSubscription таблице.

    Типовые Записи в tbl_ExSubscription:

    Та же информация может быть просмотрена через CLI Admin. Войдите выполнение cuc dbquery unitydyndb выбирают сначала 10 * от команды tbl_exsubscription.

    tbl_ExSubscription хранит информацию о каждой подписке почтового ящика, зарегистрированной в Exchange через EWS. timestamputc (выделенный в предыдущем снимке экрана), один из столбцов в этой таблице. Это содержит Разовый датой во время UTC, которое указывает время, уведомление для этой подписки было в последний раз получено CUC от Сервера Exchange.

    Процесс CuMbxSync имеет поток, который контролирует для устаревших подписок каждые две минуты и делает переподписку для любых устаревших записей. В типовом журнале поток рассматривает ряд записей подписки как устаревший. Это не идеальный случай (если все прекрасно, и Exchange передает уведомления поддержки активности своевременно). Это поле используется для обнаружения устаревших подписок процессом CuMbxSync. Условие, используемое для отфильтровывания устаревших подписок, является timestamputc <(CurrentTime - 15 минут).

    Даже если нет никакого изменения в почтовом ящике подписчика в стороне Exchange, Сервер Exchange по умолчанию все еще передает уведомления за каждым абонентом (абонент на Сервере Exchange) в пятиминутном интервале.

    Уведомления поддержки активности, которые прибывают из Exchange, могут быть замечены в 'Гагатовых журналах' Соединения. Эти журналы могут быть собраны от RTMT (выберите Trace и Log Central> Collect Files> Connection Jetty и продолжитесь), или через Доступ к корневому каталогу (/usr/local/jetty/logs).

    Этот журнал показывает ответ, передаваемый соответствием CUC уведомлениям поддержки активности, передаваемым Сервером Exchange. Если уведомления поддержки активности не достигнут CUC от Exchange тогда, то подписка будет повторно подписана после каждых 16 минут (приблизительно) и только тогда делает синхронизацию почтового ящика, происходят.

    Возможные причины для такого поведения могли быть одним из них:

    • Настройка прокси в Сервере Exchange
    • Конфигурация Технологии NAT в CUC
    • Конфигурация межсетевого экрана между CUC и Сервером Exchange, и т.д.

    Вовлеките сетевую команду и команду Exchange для получения истинной причины этого поведения.

    Если CUC получает уведомление от Сервера Exchange вовремя, и обновление не отражено в почтовом ящике CUC, свяжитесь с TAC для помощи для решения проблемы.


Связанные обсуждения сообщества поддержки Cisco

В рамках сообщества поддержки Cisco можно задавать и отвечать на вопросы, обмениваться рекомендациями и совместно работать со своими коллегами.


Document ID: 118883