Problemi di sincronizzazione della cartella Posta in arrivo con le distribuzioni locali di Microsoft Exchange

Introduzione

In questo documento vengono fornite informazioni sui problemi di sincronizzazione rilevati tra le distribuzioni locali di Cisco Unity Connection (CUC) e Microsoft Exchange.

Prerequisiti

Requisiti

Cisco raccomanda la conoscenza di CUC.

Componenti usati

Il documento può essere consultato per tutte le versioni software o hardware.

Le informazioni discusse in questo documento fanno riferimento a dispositivi usati in uno specifico ambiente di emulazione. Su tutti i dispositivi menzionati nel documento la configurazione è stata ripristinata ai valori predefiniti. Se la rete è operativa, valutare attentamente eventuali conseguenze derivanti dall'uso dei comandi.

Problemi

Esistono tre tipi di problemi di sincronizzazione:

• Nessuna sincronizzazione
• Sincronizzazione ritardata da entrambi i lati (da CUC a Exchange Server e viceversa)
• Sincronizzazione ritardata da Exchange Server a CUC

Risoluzione dei problemi

In questa sezione vengono fornite informazioni sulla risoluzione dei tre problemi. Le prime due problematiche sono riunite in un'unica sezione, in quanto l'approccio per la risoluzione dei problemi è lo stesso.

Sincronizzazione ritardata o assente tra CUC ed Exchange

È possibile che esistano diversi motivi per i quali non esiste una sincronizzazione tra CUC ed Exchange o vi è un ritardo nella sincronizzazione. In questo scenario, controllare gli errori di comunicazione tra CUC ed Exchange Server tramite la CLI o la raccolta dei log tramite lo strumento di monitoraggio in tempo reale (RTMT, Real-Time Monitoring Tool).

RTMT

Scegliete Trace & Log Central > Raccogli file. Scegliere Connetti registri sincronizzazione cassetta postale e continuare.

Radice

Su CUC (/var/log/active/cuc) tramite CLI:

Per visualizzare il file, immettere cat <nomefile> o vi <nomefile>, dove <nomefile> è diag_CuMbxSync_xxxxxxxx.uc.

CLI di amministrazione

I log possono essere visualizzati anche tramite la CLI di amministrazione, ma è abbastanza difficile.

Per elencare i file, immettere file list activelog /cuc/diag_CuMbxSync* detail reverse.

Per visualizzare un file, immettere file view activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc dove xxxxxxxx è il numero di file.

Per trasferire i file su un server FTP protetto (SFTP), immettere file get activelog /cuc/diag_CuMbxSync*.

Verificare nei log CuMbxSync più recenti eventuali errori o avvisi HTTP. Poiché gli errori o le avvertenze vengono scritti per impostazione predefinita nelle tracce, non è necessario abilitare le tracce a questo punto.

Errori HTTP possono interrompere (in modo intermittente o completo) la sincronizzazione delle operazioni di messaggistica da CUC al server Exchange e viceversa. Se nei log vengono rilevati errori HTTP, il passaggio successivo consiste nella risoluzione dei problemi e nella relativa risoluzione.

Il documento Unity Connection Single Inbox Troubleshooting TechNote fornisce alcune informazioni sui vari errori rilevati nei log di CuMbxSync.

Se non ci sono errori nel log di CuMbxSync, abilitare CsEws e CuMbxSync micro traces - tutti i livelli. Scegliere Cisco Unity Connection Serviceability > Trace > Micro Trace. Fare clic sull'opzione di reimpostazione nella pagina Account di messaggistica unificata dell'utente e raccogliere nuovamente i log. Per ulteriore assistenza, contattare il Cisco Technical Assistance Center (TAC).

Sincronizzazione ritardata da Exchange Server a CUC

Exchange comunica con il server CUC sulla porta 7080. In questa sezione vengono illustrati i passaggi per risolvere il problema.

1. Verificare che la porta 7080 sia aperta e che CUC sia in ascolto su questa porta.

   CLI di amministrazione

   

   Radice

   

2. Raccogliere un'acquisizione di rete sia sul server Exchange che sul server CUC per confermare che il server Exchange invia le notifiche Jetty e CUC riceve tali notifiche.

   Nella CLI di CUC, immettere utils network capture file SIBTrace count 100000 size ALL.

   In Exchange, scaricare ed eseguire Wireshark.

   Nell'acquisizione CUC, dovrebbe essere visualizzato questo modello di pacchetto sulla porta 7080 (porta utilizzata per ricevere le notifiche):

   

   Confermare (con l'aiuto dell'indirizzo IP evidenziato nella schermata) che la notifica è stata inviata dal server Exchange a CUC e non ad alcuni server proxy. Se non viene visualizzato lo stesso schema sulla porta 7080 (o se non viene visualizzato alcun traffico sulla porta 7080), rivolgersi al team del server Exchange. Le notifiche da Exchange a CUC possono essere di due tipi:

   • Notifiche keep-alive
   • Notifica operazione messaggio

   I messaggi keep-alive vengono inviati da Exchange a CUC. Di seguito è riportato un esempio di messaggio di notifica keep-alive:

   

   

   Per impostazione predefinita, il server Exchange invia questa notifica ogni cinque minuti per ogni utente sottoscritto. Questa notifica viene inviata da Exchange al client Exchange Web Services (in questo caso CUC) per mantenere le sottoscrizioni attive in CUC.

   Le notifiche dal server Exchange vengono ricevute dal server CUC da Jetty, che analizza le notifiche e aggiorna i dati nella tabella tbl_ExSubscription.

   Voci di esempio in tbl_ExSubscription:

   

   Le stesse informazioni possono essere visualizzate tramite la CLI di amministrazione. Immettere il comando run cuc dbquery unitydyndb select first 10 * from tbl_exsubscription.

   tbl_ExSubscription archivia le informazioni relative a ogni sottoscrizione della cassetta postale registrata con Exchange tramite EWS. L'indicatore orario (evidenziato nello screenshot precedente) è una delle colonne di questa tabella. Contiene la data e l'ora UTC che indica l'ora dell'ultima ricezione di una notifica per questa sottoscrizione da parte di CUC dal server Exchange.

   Il processo CuMbxSync dispone di un thread che monitora le sottoscrizioni non aggiornate ogni due minuti ed esegue una nuova sottoscrizione per tutte le voci non aggiornate. Nel log di esempio, il thread considera non aggiornato un set di voci di sottoscrizione. Questo non è il caso ideale (se tutto funziona correttamente e Exchange invia notifiche keep-alive in modo tempestivo). Questo campo viene utilizzato per rilevare le sottoscrizioni non aggiornate dal processo CuMbxSync. La condizione utilizzata per filtrare le sottoscrizioni non aggiornate è timestamp < (CurrentTime - 15 minuti).

   Anche se la cassetta postale del sottoscrittore sul lato Exchange non viene modificata, per impostazione predefinita Exchange Server invia notifiche per ogni sottoscrittore (sottoscrittore sul server Exchange) a un intervallo di cinque minuti.

   Le notifiche keep-alive provenienti da Exchange possono essere visualizzate nei log 'Connection Jetty'. Questi log possono essere raccolti da RTMT (scegliere Trace & Log Central > Raccogli file > Jetty di connessione e procedere) o tramite Root Access (/usr/local/jetty/logs).

   

   In questo registro viene mostrata la risposta inviata da CUC corrispondente alle notifiche keep-alive inviate da Exchange Server. Se le notifiche keep-alive non arrivano a CUC da Exchange, la sottoscrizione verrà nuovamente sottoscritta ogni 16 minuti (circa) e solo allora viene eseguita la sincronizzazione della cassetta postale.

   Le possibili cause di questo comportamento possono essere le seguenti:

   • Configurazione proxy sul server Exchange
   • Configurazione NAT (Network Address Translation) presso CUC
   • Configurazione del firewall tra CUC ed Exchange Server e così via

   Coinvolgere il team della rete e il team di Exchange per conoscere il motivo reale di questo comportamento.

   Se CUC riceve la notifica dal server Exchange puntualmente e l'aggiornamento non è riportato nella cassetta postale CUC, contattare il centro TAC per assistenza nella risoluzione del problema.