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

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

20 октября 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> кошки или vi <filename>, где <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 для помощи для решения проблемы.



Document ID: 118883