Problèmes de synchronisation de la boîte de réception unique avec les déploiements Microsoft Exchange sur site

Options de téléchargement

PDF (619.0 KB)
Consulter à l'aide d'Adobe Reader sur un grand nombre d'appareils
ePub (482.0 KB)
Consulter à l’aide de différentes applications sur iPhone, iPad, Android ou Windows Phone
Mobi (Kindle) (464.5 KB)
Consulter sur un appareil Kindle ou à l’aide d’une application Kindle sur plusieurs appareils

Mis à jour:2 avril 2015

ID du document:118883

Langage exempt de préjugés

Dans le cadre de la documentation associée à ce produit, nous nous efforçons d’utiliser un langage exempt de préjugés. Dans cet ensemble de documents, le langage exempt de discrimination renvoie à une langue qui exclut la discrimination en fonction de l’âge, des handicaps, du genre, de l’appartenance raciale de l’identité ethnique, de l’orientation sexuelle, de la situation socio-économique et de l’intersectionnalité. Des exceptions peuvent s’appliquer dans les documents si le langage est codé en dur dans les interfaces utilisateurs du produit logiciel, si le langage utilisé est basé sur la documentation RFP ou si le langage utilisé provient d’un produit tiers référencé. Découvrez comment Cisco utilise le langage inclusif.

À propos de cette traduction

Cisco a traduit ce document en traduction automatisée vérifiée par une personne dans le cadre d’un service mondial permettant à nos utilisateurs d’obtenir le contenu d’assistance dans leur propre langue. Il convient cependant de noter que même la meilleure traduction automatisée ne sera pas aussi précise que celle fournie par un traducteur professionnel.

Contenu

Introduction

Conditions préalables

Conditions requises

Components Used

Problèmes

Dépannage

Synchronisation retardée ou non entre CUC et Exchange

Synchronisation différée entre Exchange Server et CUC

Introduction

Ce document fournit des informations sur les problèmes de synchronisation observés entre les déploiements Cisco Unity Connection (CUC) et Microsoft Exchange sur site.

Conditions préalables

Conditions requises

Cisco vous recommande de connaître CUC.

Components Used

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

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.

Problèmes

Il existe trois types de problèmes de synchronisation :

Aucune synchronisation
Synchronisation retardée des deux côtés (CUC vers Exchange Server et vice versa)
Synchronisation retardée entre Exchange Server et CUC

Dépannage

Cette section fournit des informations sur la façon de résoudre les trois problèmes. Les deux premiers problèmes sont regroupés en une seule section, car l'approche de dépannage est la même.

Synchronisation retardée ou non entre CUC et Exchange

Il peut y avoir plusieurs raisons pour lesquelles il n'y a pas de synchronisation ou de retard entre CUC et Exchange. Dans ce scénario, vérifiez les échecs de communication entre CUC et Exchange Server soit via l'interface de ligne de commande (CLI), soit par la collecte de journaux via l'outil de surveillance en temps réel (RTMT).

RTMT

Choisissez Trace & Log Central > Collecter les fichiers. Choisissez Connection Mailbox Sync logs et continuez.

Racine

Sur CUC (/var/log/active/cuc) via CLI :

Pour afficher le fichier, entrez cat <nom du fichier> ou vi <nom du fichier>, où <nom du fichier> est diag_CuMbxSync_xxxxxxxx.uc.

CLI Admin

Les journaux peuvent également être affichés via l'interface de ligne de commande Admin, mais c'est assez difficile.

Afin de lister les fichiers, entrez file list activelog /cuc/diag_CuMbxSync* detail inverse.

Pour afficher un fichier, entrez file view activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc où xxxxxxxx est le numéro de fichier.

Afin de transférer les fichiers vers un serveur FTP sécurisé (SFTP), entrez file get activelog /cuc/diag_CuMbxSync*.

Vérifiez les derniers journaux CuMbxSync pour détecter les pannes HTTP ou les avertissements. Puisque les erreurs ou les avertissements sont écrits par défaut dans les traces, il n'est pas nécessaire d'activer les traces à ce stade.

Les échecs HTTP peuvent arrêter (de façon intermittente ou complète) la synchronisation des opérations de messagerie de CUC vers le serveur Exchange et vice versa. Si les échecs HTTP sont visibles dans les journaux, l'étape suivante consiste à dépanner et résoudre ces problèmes.

Le document Unity Connection Single Inbox Troubleshooting TechNote fournit des informations sur les différentes erreurs vues dans les journaux CuMbxSync.

Si le journal CuMbxSync ne contient aucune erreur ou défaillance, activez les micro-traces CsEws et CuMbxSync - tous niveaux. Choisissez Cisco Unity Connection Serviceability > Trace > Micro Trace. Cliquez sur l'option de réinitialisation sur la page Compte de messagerie unifiée de l'utilisateur et collectez à nouveau les journaux. Contactez le centre d'assistance technique Cisco (TAC) pour obtenir de l'aide.

Synchronisation différée entre Exchange Server et CUC

Exchange communique avec le serveur CUC sur le port 7080. Cette section décrit les étapes à suivre pour résoudre le problème.

Assurez-vous que le port 7080 est ouvert et que CUC écoute sur ce port.
CLI Admin
Racine
Collectez une capture réseau sur le serveur Exchange et le serveur CUC afin de confirmer que le serveur Exchange envoie des notifications Jetty et que CUC reçoit ces notifications Jetty.
Dans la CLI CUC, saisissez le fichier de capture réseau utils SIBTrace count 100000 size ALL.
Sur Exchange, téléchargez et exécutez Wireshark.
Dans la capture CUC, vous devriez voir ce modèle de paquet sur le port 7080 (port utilisé pour recevoir des notifications) :
Confirmez (à l'aide de l'adresse IP mise en surbrillance dans la capture d'écran) que la notification a été envoyée du serveur Exchange à CUC et non à un serveur proxy quelconque. Si vous ne voyez pas le même modèle sur le port 7080 (ou si aucun trafic n'est présent sur le port 7080), vérifiez auprès de l'équipe du serveur Exchange. Les notifications d'Exchange à CUC peuvent être de deux types :
- Notifications de maintien en vie
- Notification d'opération de message
Les messages Keep-alive sont envoyés d'Exchange à CUC. Voici un exemple de message de notification de maintien en vie :
Le serveur Exchange envoie cette notification toutes les cinq minutes (par défaut) pour chaque utilisateur abonné. Cette notification est envoyée par Exchange au client Exchange Web Services (EWS) (CUC dans ce cas) afin de conserver les abonnements actifs dans CUC.
Les notifications du serveur Exchange sont reçues sur le serveur CUC par Jetty, qui analyse les notifications et met à jour les données dans la table tbl_ExSubscription.
Exemples d'entrées dans tbl_ExSubscription :
Les mêmes informations peuvent être affichées via l'interface de ligne de commande Admin. Entrez la commande run cuc dbquery unitydyndb select first 10 * from tbl_exsubscribe.
tbl_ExSubscription stocke des informations sur chaque abonnement de boîte aux lettres enregistré auprès d'Exchange via EWS. timestamputc (mis en surbrillance dans la capture d'écran précédente) est l'une des colonnes de ce tableau. Il contient la date et l'heure UTC qui indique l'heure à laquelle CUC a reçu une notification pour cet abonnement pour la dernière fois du serveur Exchange.
Le processus CuMbxSync a un thread qui surveille les abonnements périmés toutes les deux minutes et réabonne les entrées périmées. Dans l'exemple de journal, le thread considère un ensemble d'entrées d'abonnement comme obsolète. Il ne s'agit pas d'un cas idéal (si tout va bien et si Exchange envoie des notifications de maintien en vie en temps opportun). Ce champ est utilisé pour détecter les abonnements périmés par le processus CuMbxSync. La condition utilisée pour filtrer les abonnements obsolètes est timestamputc < (CurrentTime - 15 minutes).
Même s'il n'y a aucune modification dans la boîte aux lettres d'un abonné côté Exchange, le serveur Exchange envoie toujours par défaut des notifications pour chaque abonné (abonné sur le serveur Exchange) à un intervalle de cinq minutes.
Les notifications Keep-alive provenant d'Exchange peuvent être vues dans les journaux 'Connection Jetty'. Ces journaux peuvent être collectés à partir de RTMT (choisissez Trace & Log Central > Collect Files > Connection Jetty and continue) ou via Root Access (/usr/local/jetty/logs).
Ce journal affiche la réponse envoyée par CUC correspondant aux notifications de conservation d'activité envoyées par Exchange Server. Si les notifications de conservation d'activité n'arrivent pas à CUC à partir d'Exchange, l'abonnement sera réinscrit après 16 minutes (environ) et la synchronisation des boîtes aux lettres aura lieu.
Les raisons possibles de ce comportement pourraient être les suivantes :
- Configuration du proxy sur le serveur Exchange
- Configuration de la traduction d’adresses de réseau (NAT) à CUC
- Configuration du pare-feu entre CUC et Exchange Server, etc.
Impliquez l'équipe réseau et l'équipe Exchange afin d'obtenir la véritable raison de ce comportement.
Si CUC reçoit une notification du serveur Exchange à temps et que la mise à jour n'est pas répercutée dans la boîte aux lettres CUC, contactez le TAC pour obtenir de l'aide pour résoudre le problème.