Voix et communications unifiées : Cisco Unity Connection

Questions simples de synchronisation de boîte de réception avec des déploiements de Sur-sites de Microsoft Exchange

17 décembre 2015 - Traduction automatique
Autres versions: PDFpdf | Anglais (22 août 2015) | Commentaires

Introduction

Ce document fournit des informations sur les questions de synchronisation vues entre le Cisco Unity Connection (CUC) et les déploiements de Sur-sites de Microsoft Exchange.

Contribué par Ratnesh Nath et Anirudh Mavilakandy, ingénieurs TAC Cisco.

Conditions préalables

Conditions requises

Cisco recommande que vous ayez la connaissance de CUC.

Composants utilisés

Ce document n'est pas limité à des versions de matériel et de logiciel spécifiques.

Les informations contenues dans ce document ont été créées à partir des périphériques d'un environnement de laboratoire spécifique. Tous les périphériques utilisés dans ce document ont démarré avec une configuration effacée (par défaut). Si votre réseau est opérationnel, assurez-vous que vous comprenez l'effet potentiel de toute commande.

Questions

Il y a trois types de questions de synchronisation :

  • Aucune synchronisation
  • Synchronisation retardée des deux côtés (CUC au serveur exchange et vice versa)
  • Synchronisation retardée de serveur exchange à CUC

Dépannez

Cette section fournit des informations sur la façon dont dépanner les trois questions. Les deux premières questions sont combinées dans une section car l'approche pour dépanner les questions est identique.

Retardé ou aucune synchronisation entre CUC et échange

Il pourrait y avoir de diverses raisons pour lesquelles il y a aucun ou synchronisation retardée entre CUC et échange. Dans ce scénario, pannes de communication de contrôle entre CUC et le serveur exchange par l'intermédiaire du CLI ou par la collecte de log par l'intermédiaire de l'outil de suivi en temps réel (RTMT).

RTMT

Choisissez le suivi et le central de log > collectent des fichiers. Choisissez les logs de sync de boîte aux lettres de connexion et poursuivez.

Racine

Sur CUC (/var/log/active/cuc) par l'intermédiaire du CLI :

Afin de visualiser le fichier, écrivez le <filename> de cat ou vi <filename>, où le <filename> est diag_CuMbxSync_xxxxxxxx.uc.

Admin CLI

Les logs peuvent également être visualisés par l'intermédiaire de l'admin CLI, mais il est tout à fait difficile.

Afin de répertorier les fichiers, écrivez l'activelog /cuc/diag_CuMbxSync de liste de fichier * détaillez l'inverse.

Afin de visualiser un fichier, écrivez l'activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc d'affichage de fichier où xxxxxxxx est le nombre de fichier.

Afin de virer les fichiers sur un serveur sécurisé de FTP (SFTP), introduisez le fichier obtiennent l'activelog /cuc/diag_CuMbxSync *.

Vérifiez les derniers logs de CuMbxSync pour tous les pannes ou avertissements de HTTP. Puisque des erreurs ou les avertissements sont écrits par défaut dans les suivis, il n'y a aucun besoin d'activer des suivis en ce moment.

Les pannes de HTTP pourraient arrêter (par intermittence ou complètement) la synchronisation d'exécution de Messagerie de CUC au serveur exchange et vice versa. Si des pannes de HTTP sont vues dans les logs, alors l'étape suivante est de dépanner et réparer ces questions.

La boîte de réception simple d'Unity Connection dépannant le document de TechNote fournit quelques informations sur les diverses erreurs vues dans les logs de CuMbxSync.

S'il n'y a aucune erreur/panne dans le CuMbxSync connectez-vous, alors activez les suivis micro de CsEws et de CuMbxSync - tous les niveaux. Choisissez l'utilité > le suivi de Cisco Unity Connection > suivi micro. Cliquez sur l'option de remise à la page de compte de messagerie unifiée de l'utilisateur et collectez les logs de nouveau. Entrez en contact avec le centre d'assistance technique Cisco (TAC) pour davantage d'assistance.

Synchronisation retardée de serveur exchange à CUC

L'échange communique au serveur CUC sur le port 7080. Cette section fournit des étapes afin de dépanner la question.

  1. Assurez que le port 7080 est ouvert et CUC écoute sur ce port.

    Admin CLI

    Racine

  2. Collectez une capture de réseau au serveur exchange et au serveur CUC afin de confirmer que le serveur exchange envoie des notifications de jetée et CUC reçoit ces notifications de jetée.

    Dans le CUC CLI, écrivez la taille TOUTE du compte 100000 de SIBTrace de fichier de capture de réseau d'utils.

    Sur l'échange, le téléchargement et le passage Wireshark.

    Dans la capture CUC, vous devriez voir ce modèle de paquet sur le port 7080 (port utilisé pour recevoir des notifications) :

    Confirmez (avec l'aide de l'adresse IP mise en valeur dans la capture d'écran) que la notification a été envoyé du serveur exchange à CUC et pas à un certain serveur proxy. Si vous ne voyez pas le même modèle au port 7080 (ou ne voir l'aucun trafic sur le port 7080), vérifiez avec l'équipe de serveur exchange. Les notifications de l'échange à CUC ont pu être de deux types :

    • Notifications de keep-alive
    • Notification d'exécution de message

    Des messages de keep-alive sont envoyés de l'échange à CUC. Voici un message de notification de keep-alive d'échantillon :

    Le serveur exchange envoie à cette notification toutes les cinq minutes (par défaut) pour chaque utilisateur abonné. Cette notification est envoyée par échange au client des services Web d'échange (EWS) (CUC dans ce cas) afin de maintenir des abonnements actifs dans CUC.

    Des notifications du serveur exchange sont reçues au serveur CUC par la jetée, qui analyse les notifications et met à jour des données dans la table de tbl_ExSubscription.

    Entrées témoin dans le tbl_ExSubscription :

    Les mêmes informations peuvent être visualisées par l'intermédiaire de l'admin CLI. Écrivez l'unitydyndb de dbquery de cuc de passage 10 choisis premiers * de la commande de tbl_exsubscription.

    le tbl_ExSubscription stocke des informations sur chaque abonnement de boîte aux lettres inscrit à l'échange par l'intermédiaire d'EWS. le timestamputc (mis en valeur dans le tir d'écran précédent) est l'une des colonnes dans cette table. Il contient la date-heure dans le temps UTC qui indique que le temps où une notification pour cet abonnement a été pour la dernière fois reçue par CUC du serveur exchange.

    Le processus de CuMbxSync a un thread que les moniteurs pour des abonnements éventés toutes les deux minutes et fait un resubscription pour toutes les entrées éventées. Dans le log témoin, le thread considère un ensemble d'entrées d'abonnement comme éventé. Ce n'est pas un cas idéal (si tout est bien et l'échange envoie des notifications de keep-alive en temps utile). Ce champ est utilisé pour détecter des abonnements éventés par le processus de CuMbxSync. La condition utilisée pour filtrer les abonnements éventés est timestamputc < (CurrentTime - 15 minutes).

    Même s'il n'y a aucun changement d'une boîte aux lettres d'abonné sur le côté d'échange, le serveur exchange par défaut envoie toujours des notifications pour chaque abonné (abonné sur le serveur exchange) à un intervalle cinq minute.

    Des notifications de keep-alive qui proviennent l'échange peuvent être vues dans des logs « de jetée de connexion ». Ces logs peuvent être collectés de RTMT (choisissez le suivi et le central de log > collectent les fichiers > la jetée de connexion et poursuivent) ou par l'intermédiaire de la racine Access (/usr/local/jetty/logs).

    Ce log affiche la réponse envoyée par CUC correspondant aux notifications de keep-alive envoyées par le serveur exchange. Si les notifications de keep-alive n'arrivent pas à CUC d'échange alors que l'abonnement resubscribed après toutes les 16 minutes (approximativement) et fait seulement alors la synchronisation de boîte aux lettres se produisent.

    Les raisons potentielles pour un tel comportement ont pu être l'une de ces derniers :

    • Configuration de proxy au serveur exchange
    • Configuration de Traduction d'adresses de réseau (NAT) à CUC
    • Configuration de Pare-feu entre CUC et le serveur exchange, et ainsi de suite

    Impliquez l'équipe de réseau et permutez l'équipe afin d'obtenir la raison réelle de ce comportement.

    Si CUC reçoit la notification de la période active de serveur exchange et la mise à jour n'est pas reflétée dans la boîte aux lettres CUC, entrez en contact avec le TAC pour que l'aide dépanne la question.


Conversations connexes de la communauté de soutien de Cisco

Le site Cisco Support Community est un forum où vous pouvez poser des questions, répondre à des questions, faire part de suggestions et collaborer avec vos pairs.


Document ID: 118883