Contenido

Introducción

Prerequisites

Requirements

Componentes Utilizados

Problemas

Troubleshoot

Retrasado o No hay sincronización entre CUC y Exchange

Sincronización retrasada de Exchange Server a CUC

Introducción

Este documento proporciona información sobre los problemas de sincronización observados entre las implementaciones in situ de Cisco Unity Connection (CUC) y Microsoft Exchange.

Prerequisites

Requirements

Cisco recomienda que tenga conocimiento de CUC.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Problemas

Hay tres tipos de problemas de sincronización:

- Sin sincronización

- Sincronización retrasada de ambos lados (CUC a Exchange Server y viceversa)

- Sincronización retrasada de Exchange Server a CUC

Troubleshoot

Esta sección proporciona información sobre cómo resolver los tres problemas. Los dos primeros problemas se combinan en una sección, ya que el enfoque para solucionar los problemas es el mismo.

Retrasado o No hay sincronización entre CUC y Exchange

Puede haber varias razones por las que no hay sincronización ni se retrasa la sincronización entre CUC y Exchange. En este escenario, verifique las fallas de comunicación entre CUC y Exchange Server a través de la CLI o mediante la recopilación de registros a través de la herramienta de supervisión en tiempo real (RTMT).

RTMT

Elija Trace & Log Central > Collect Files. Elija los registros de sincronización de buzón de conexión y continúe.

Raíz

En CUC (/var/log/active/cuc) a través de la CLI:

Para ver el archivo, ingrese cat <filename> o vi <filename> , donde <filename> es diag_CuMbxSync_xxxxxxxx.uc.

CLI de administración

Los registros también se pueden ver a través de la CLI de administración, pero es bastante difícil.

Para enumerar los archivos, ingrese file list activelog /cuc/diag_CuMbxSync* detail reverse.

Para ver un archivo, ingrese file view activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc donde xxxxxxxx es el número de archivo.

Para transferir los archivos a un servidor FTP seguro (SFTP), introduzca file get activelog /cuc/diag_CuMbxSync*.

Verifique los últimos registros CuMbxSync para ver si hay fallas o advertencias HTTP. Dado que los errores o advertencias se escriben de forma predeterminada en los seguimientos, no es necesario habilitar seguimientos en este momento.

Los errores HTTP podrían detener (intermitente o completamente) la sincronización de la operación de mensajería de CUC al servidor Exchange y viceversa. Si se ven fallas HTTP en los registros, el siguiente paso es resolver y solucionar estos problemas.

El documento Unity Connection Single Inbox Troubleshooting TechNote proporciona información sobre los diversos errores que se ven en los registros CuMbxSync.

Si no hay errores / fallas en el registro CuMbxSync, habilite los micro seguimientos CsEws y CuMbxSync - todos los niveles. Elija Serviciabilidad de Cisco Unity Connection > Trace > Micro Trace. Haga clic en la opción reset (Reinicio) de la página Unified Messaging Account (Cuenta de mensajería unificada) del usuario y vuelva a recopilar los registros. Póngase en contacto con el centro de asistencia técnica Cisco Technical Assistance Center (TAC) para obtener más ayuda.

Sincronización retrasada de Exchange Server a CUC

Exchange se comunica con el servidor CUC en el puerto 7080. Esta sección proporciona los pasos para resolver el problema.

1. Asegúrese de que el puerto 7080 esté abierto y CUC escuche en este puerto.
CLI de administración

Raíz

2. Recopile una captura de red tanto en el servidor Exchange como en el servidor CUC para confirmar que el servidor Exchange envía notificaciones Jetty y CUC recibe estas notificaciones Jetty.
En CUC CLI, ingrese utils network capture file SIBTrace count 100000 size ALL.

En Exchange, descargue y ejecute Wireshark .

En la captura CUC, debe ver este patrón de paquetes en el puerto 7080 (puerto utilizado para recibir notificaciones):

Confirme (con la ayuda de la dirección IP resaltada en la captura de pantalla) que la notificación se ha enviado desde el servidor Exchange a CUC y no a algún servidor proxy. Si no ve el mismo patrón en el puerto 7080 (o no ve ningún tráfico en el puerto 7080), verifique con el equipo del servidor Exchange. Las notificaciones de Exchange a CUC pueden ser de dos tipos:

- Notificaciones "Keep-alive"

- Notificación de operación de mensaje

Los mensajes "Keep-alive" se envían de Exchange a CUC. A continuación se muestra un ejemplo de mensaje de notificación de "keepalive":

El servidor Exchange envía esta notificación cada cinco minutos (de forma predeterminada) para cada usuario suscrito. Exchange envía esta notificación al cliente de Exchange Web Services (EWS) (CUC en este caso) para mantener las suscripciones activas en CUC.

Jetty recibe las notificaciones del servidor Exchange en el servidor CUC, que analiza las notificaciones y actualiza los datos en la tabla tbl_ExSubscription.

Entradas de muestra en tbl_ExSubscription:

La misma información se puede ver a través de la CLI de administración. Ingrese el comando run cuc dbquery unitydyndb select first 10 * from tbl_exsubscription.

tbl_ExSubscription almacena información sobre cada suscripción de buzón registrada en Exchange a través de EWS. timestamputc (resaltado en la captura de pantalla anterior) es una de las columnas de esta tabla. Contiene Fecha y hora en hora UTC que indica la hora en que CUC recibió por última vez una notificación de esta suscripción del servidor Exchange.

El proceso CuMbxSync tiene un subproceso que monitorea las suscripciones obsoletas cada dos minutos y realiza una resuscripción para cualquier entrada obsoleta. En el registro de ejemplo, el subproceso considera un conjunto de entradas de suscripción como obsoletas. Este no es un caso ideal (si todo está bien y Exchange envía notificaciones de mantenimiento de forma oportuna). Este campo se utiliza para detectar suscripciones obsoletas por el proceso CuMbxSync. La condición utilizada para filtrar las suscripciones obsoletas es timestamputc < (CurrentTime - 15 minutos).

Incluso si no hay cambios en un buzón de correo del suscriptor en el lado de Exchange, el servidor Exchange de forma predeterminada sigue enviando notificaciones para cada suscriptor (suscriptor en servidor Exchange) en un intervalo de cinco minutos.

Las notificaciones "Keep-alive" que vienen de Exchange se pueden ver en los registros "Connection Jetty". Estos registros se pueden recopilar desde RTMT (elija Trace & Log Central > Recopilar archivos > Conexión y continúe) o a través de Acceso raíz (/usr/local/jetty/logs).

Este registro muestra la respuesta enviada por CUC que corresponde a las notificaciones de mantenimiento enviadas por Exchange Server. Si las notificaciones "keep-alive" no llegan a CUC desde Exchange, la suscripción se volverá a suscribir cada 16 minutos (aproximadamente) y sólo entonces se produce la sincronización del buzón.

Una de las posibles razones de ese comportamiento podría ser la siguiente:

- Configuración de proxy en el servidor Exchange

- Configuración de traducción de direcciones de red (NAT) en CUC

- Configuración del firewall entre CUC y Exchange Server, etc.

Involucrar al equipo de red y al equipo de Exchange para obtener el motivo real de este comportamiento.

Si CUC recibe la notificación del servidor Exchange a tiempo y la actualización no se refleja en el buzón de correo de CUC, póngase en contacto con el TAC para obtener ayuda para resolver el problema.