Probleme bei der internen Synchronisierung von Microsoft Exchange

Einführung

Dieses Dokument enthält Informationen zu Synchronisierungsproblemen, die zwischen Cisco Unity Connection (CUC)- und Microsoft Exchange On-Premises-Bereitstellungen aufgetreten sind.

Voraussetzungen

Anforderungen

Cisco empfiehlt, über CUC zu verfügen.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardwareversionen beschränkt.

Die Informationen in diesem Dokument wurden von den Geräten in einer bestimmten Laborumgebung erstellt. Alle in diesem Dokument verwendeten Geräte haben mit einer leeren (Standard-)Konfiguration begonnen. Wenn Ihr Netzwerk in Betrieb ist, stellen Sie sicher, dass Sie die potenziellen Auswirkungen eines Befehls verstehen.

Probleme

Es gibt drei Arten von Synchronisierungsproblemen:

• Keine Synchronisierung
• Verzögerte Synchronisierung von beiden Seiten (CUC zu Exchange Server und umgekehrt)
• Verzögerte Synchronisierung von Exchange Server zu CUC

Fehlerbehebung

Dieser Abschnitt enthält Informationen zur Behebung der drei Probleme. Die ersten beiden Probleme werden in einem Abschnitt zusammengefasst, da der Ansatz zur Fehlerbehebung derselbe ist.

Verzögert oder keine Synchronisierung zwischen CUC und Exchange

Es kann verschiedene Gründe geben, aus denen die Synchronisierung zwischen CUC und Exchange nicht oder nur verzögert erfolgt. In diesem Szenario überprüfen Sie Kommunikationsfehler zwischen CUC und dem Exchange Server entweder über die CLI oder durch Protokollerfassung über das Real-Time Monitoring Tool (RTMT).

RTMT

Wählen Sie Trace & Log Central > Collect Files aus. Wählen Sie Connection Mailbox Sync logs aus, und fahren Sie fort.

Wurzel

Auf CUC (/var/log/active/cuc) über die CLI:

Um die Datei anzuzeigen, geben Sie cat <Dateiname> oder vi <Dateiname> ein, wobei <Dateiname> diag_CuMbxSync_xxxxxxxx.uc ist.

Administrator-CLI

Die Protokolle können auch über die Admin-CLI angezeigt werden, aber es ist ziemlich schwierig.

Um die Dateien aufzulisten, geben Sie die Dateiliste activelog /cuc/diag_CuMbxSync* detail reverse ein.

Um eine Datei anzuzeigen, geben Sie file view activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc ein, wobei xxxxxxxx für die Dateinummer steht.

Um die Dateien auf einen sicheren FTP-Server (SFTP) zu übertragen, geben Sie file get activelog /cuc/diag_CuMbxSync* ein.

Prüfen Sie die aktuellen CuMbxSync-Protokolle auf HTTP-Fehler oder -Warnungen. Da Fehler oder Warnungen standardmäßig in den Ablaufverfolgungen geschrieben sind, müssen Sie zu diesem Zeitpunkt keine Ablaufverfolgungen aktivieren.

HTTP-Fehler können die Synchronisierung der Messaging-Operation vom CUC zum Exchange-Server beenden (gelegentlich oder vollständig) und umgekehrt. Wenn HTTP-Fehler in den Protokollen angezeigt werden, besteht der nächste Schritt darin, diese Probleme zu beheben und zu beheben.

Das TechNote-Dokument zur Fehlerbehebung in einem Posteingang von Unity Connection enthält einige Informationen zu den verschiedenen Fehlern, die in den CuMbxSync-Protokollen angezeigt werden.

Wenn das CuMbxSync-Protokoll keine Fehler/Fehler enthält, aktivieren Sie CsEws und CuMbxSync micro traces - all levels. Wählen Sie Cisco Unity Connection Serviceability > Trace > Micro Trace aus. Klicken Sie auf der Seite für das Unified Messaging-Konto des Benutzers auf die Option zum Zurücksetzen, und sammeln Sie die Protokolle erneut. Weitere Unterstützung erhalten Sie vom Cisco Technical Assistance Center (TAC).

Verzögerte Synchronisierung von Exchange Server zu CUC

Exchange kommuniziert auf Port 7080 mit dem CUC-Server. In diesem Abschnitt werden Schritte zur Behebung des Problems beschrieben.

1. Stellen Sie sicher, dass Port 7080 offen ist und CUC auf diesem Port lauscht.

   Administrator-CLI

   

   Wurzel

   

2. Erfassen Sie eine Netzwerkerfassung sowohl auf dem Exchange-Server als auch auf dem CUC-Server, um zu bestätigen, dass der Exchange-Server Jetty-Benachrichtigungen sendet und der CUC diese Jetty-Benachrichtigungen empfängt.

   Geben Sie in der CUC-CLI die Netzwerkerfassungsdatei utils SIBTrace count 10000 size ALL (ALLE 100000-Größe) ein.

   Laden Sie Wireshark auf Exchange herunter und führen Sie es aus.

   In der CUC-Erfassung sollte dieses Paketmuster auf Port 7080 (Port zum Empfang von Benachrichtigungen) angezeigt werden:

   

   Bestätigen Sie (mithilfe der in der Screenshot-Erfassung hervorgehobenen IP-Adresse), dass die Benachrichtigung vom Exchange-Server an CUC und nicht an einen Proxy-Server gesendet wurde. Wenn Sie nicht dasselbe Muster an Port 7080 sehen (oder keinen Datenverkehr an Port 7080 sehen), wenden Sie sich an das Exchange-Server-Team. Benachrichtigungen von Exchange an CUC können zwei Arten haben:

   • Keep-Alive-Benachrichtigungen
   • Meldung von Vorgängen

   Keep-Alive-Nachrichten werden von Exchange an CUC gesendet. Im Folgenden finden Sie eine Beispiel-Keep-Alive-Benachrichtigungsmeldung:

   

   

   Der Exchange-Server sendet diese Benachrichtigung standardmäßig alle fünf Minuten für jeden abonnierten Benutzer. Diese Benachrichtigung wird von Exchange an den Exchange Web Services (EWS) Client (in diesem Fall CUC) gesendet, um Abonnements in CUC am Leben zu erhalten.

   Benachrichtigungen vom Exchange-Server werden vom Jetty auf dem CUC-Server empfangen, der die Benachrichtigungen analysiert und die Daten in der tbl_ExSubscription-Tabelle aktualisiert.

   Beispieleinträge in tbl_eSubscription:

   

   Dieselben Informationen können auch über die Admin-CLI angezeigt werden. Geben Sie den Befehl run cuc dbquery unitydyndb ein, und wählen Sie die ersten 10 * aus dem Befehl tbl_exsubscription aus.

   tbl_ExSubscription speichert Informationen über jedes Mailbox-Abonnement, das bei Exchange über EWS registriert ist. timestamputc (im vorherigen Screenshot hervorgehoben) ist eine der Spalten in dieser Tabelle. Es enthält Date-Time in UTC-Zeit, die angibt, wann eine Benachrichtigung für dieses Abonnement zuletzt vom Exchange-Server beim CUC empfangen wurde.

   Der CuMbxSync-Prozess verfügt über einen Thread, der alle zwei Minuten auf veraltete Abonnements überwacht und bei veralteten Einträgen eine Neuabonnement durchführt. Im Beispielprotokoll betrachtet der Thread eine Reihe von Abonnementeinträgen als veraltet. Dies ist kein idealer Fall (wenn alles in Ordnung ist und Exchange laufend Benachrichtigungen sendet). Dieses Feld wird verwendet, um veraltete Abonnements durch den CuMbxSync-Prozess zu erkennen. Die Bedingung für das Herausfiltern veralteter Abonnements ist timestamputc < (CurrentTime - 15 Minuten).

   Selbst wenn es keine Änderung in einer Abonnenten-Mailbox auf der Exchange-Seite gibt, sendet der Exchange-Server standardmäßig immer noch Benachrichtigungen für jeden und jeden Abonnenten (Abonnenten auf Exchange-Server) in einem fünfminütigen Intervall.

   Keep-alive-Benachrichtigungen, die von Exchange kommen, können in 'Connection Jetty'-Protokollen angezeigt werden. Diese Protokolle können vom RTMT (wählen Sie Trace & Log Central > Collect Files > Connection Jetty und fahren Sie fort) oder über Root Access (/usr/local/jetty/logs) gesammelt werden.

   

   Dieses Protokoll zeigt die Antwort, die vom CUC entsprechend den vom Exchange Server gesendeten Keep-Alive-Benachrichtigungen gesendet wird. Wenn die Keep-Alive-Benachrichtigungen nicht von Exchange bei CUC eintreffen, wird das Abonnement nach allen 16 Minuten (ungefähr) neu abonniert, und nur dann erfolgt die Mailbox-Synchronisierung.

   Mögliche Gründe für ein solches Verhalten könnten folgende sein:

   • Proxy-Konfiguration am Exchange-Server
   • Network Address Translation (NAT)-Konfiguration im CUC
   • Firewall-Konfiguration zwischen CUC und dem Exchange-Server usw.

   Beziehen Sie das Netzwerkteam und das Exchange-Team ein, um den tatsächlichen Grund für dieses Verhalten zu ermitteln.

   Wenn der CUC rechtzeitig eine Benachrichtigung vom Exchange-Server erhält und die Aktualisierung nicht in der CUC-Mailbox angezeigt wird, wenden Sie sich an das TAC, um Unterstützung bei der Behebung des Problems zu erhalten.