Enkelvoudige Inbox-synchronisatieproblemen met Microsoft Exchange On-Premises-implementaties

Inleiding

Dit document bevat informatie over de synchronisatieproblemen die worden gezien tussen de implementaties van Cisco Unity Connection (CUC) en Microsoft Exchange On-Premises.

Voorwaarden

Vereisten

Cisco raadt u aan kennis te hebben over CUC.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

De informatie in dit document is gebaseerd op de apparaten in een specifieke laboratoriumomgeving. Alle apparaten die in dit document worden beschreven, hadden een opgeschoonde (standaard)configuratie. Als uw netwerk live is, moet u de potentiële impact van elke opdracht begrijpen.

Problemen

Er zijn drie synchronisatiekwesties:

• Geen synchronisatie
• Uitgestelde synchronisatie vanuit beide kanten (CUC to Exchange Server en vice versa)
• Uitgestelde synchronisatie van Exchange Server naar CUC

Problemen oplossen

Deze sectie verschaft informatie over het oplossen van de drie problemen. De eerste twee kwesties worden in één sectie gecombineerd omdat de benadering van het oplossen van problemen dezelfde is.

Vertraagde of geen synchronisatie tussen CUC en Exchange

Er zouden verschillende redenen kunnen zijn waarom CUC en Exchange niet of met vertraging op elkaar zijn afgestemd. In dit scenario, controleer communicatiefouten tussen CUC en de Exchange Server via de CLI of door logverzameling via het Real-Time Monitoring Tool (RTMT).

RTMT

Kies Central overtrekken en loggen > Verzamelen van bestanden. Kies de verbinding van de brievenbus synchrone logbestanden en ga verder.

roet

Op CUC (/var/log/active/cuc) via de CLI:

Om het bestand te bekijken, voert u cat <filename> of vi <filename>, waarbij <filename> diag_CuMubxSync_xxxxxx.uc is.

Admin CLI

De logboeken kunnen ook via de Admin CLI worden bekeken, maar het is vrij moeilijk.

Geef een lijst op van de bestanden door achtereenvolgens de lijst met bestanden op te geven: activelog /cuc/diag_CuMbxSync* .

Als u een bestand wilt weergeven, voert u het activelogvenster voor bestandweergave in op /cuc/diag_CuMbxSync_xxxxxxxx.uc waar xxxxxx het bestandsnummer is.

Om de bestanden naar een Secure FTP-server (SFTP) over te brengen, voert u het bestand activelog/cuc/diag_CuMbxSync* in.

Controleer de nieuwste CuMbxSync logs op fouten of waarschuwingen van HTTP. Aangezien fouten of waarschuwingen standaard in de sporen zijn geschreven, hoeft u momenteel geen sporen meer in te schakelen.

HTTP-fouten kunnen de synchronisatie van berichtenverkeer vanaf CUC naar de Exchange-server stoppen (met tussenpozen of volledig) en vice versa. Als HTTP-fouten in de logbestanden worden gezien, is de volgende stap het oplossen van problemen en het oplossen van deze problemen.

Het TechNotes-document Unity Connection met één vakje voor probleemoplossing in één vakje voor TechNotes bevat informatie over de verschillende fouten die in de logbestanden van CuMbxSync worden gezien.

Als het logbestand van CuMbxSync geen fouten/fouten bevat, schakelt u CsEws en CuMbxSync microsporen in - alle niveaus. Kies Cisco Unity Connection Services > Trace > Micro Trace. Klik de resetoptie op de Unified Messaging Account-pagina van de gebruiker aan en verzamel de logbestanden opnieuw. Neem contact op met het Cisco Technical Assistance Center (TAC) voor verdere assistentie.

Vertraagde synchronisatie van Exchange Server naar CUC

De uitwisseling communiceert aan de CUC server op haven 7080. Deze sectie verschaft stappen om het probleem op te lossen.

1. Zorg ervoor dat poort 7080 open is en CUC luistert op deze poort.

   Admin CLI

   

   roet

   

2. Verzamel een netwerkopname op zowel de Exchange server als de CUC server om te bevestigen dat de Exchange server Jetty-kennisgevingen verstuurt en CUC deze Jetty-kennisgevingen ontvangt.

   Voer in de CUC CLI een bestand voor het opnemen van een utils-netwerk in met SIBTracebestand met een grootte van 100000 ALL.

   Download en loop Wireshark in.

   In de CUC-opname dient u dit pakketpatroon te zien op poort 7080 (poort gebruikt om meldingen te ontvangen):

   

   Bevestig (met de hulp van het IP adres dat in de schermopname wordt gemarkeerd) dat het bericht is verzonden van de Exchange server naar CUC en niet naar een proxy server. Als u niet hetzelfde patroon ziet in poort 7080 (of geen verkeer ziet op poort 7080), controleer dan met het Exchange server team. Aanmeldingen van uitwisseling naar CUC kunnen van twee soorten zijn:

   • Doorlopende meldingen
   • Bericht

   Houd-levendige berichten worden verzonden van Exchange naar CUC. Hier volgt een melding van het bewaren van de steekproef:

   

   

   De uitwisselingsserver stuurt deze kennisgeving elke vijf minuten (standaard) voor elke geabonneerde gebruiker. Dit bericht wordt door Exchange naar de Exchange Web Services (EWS)-client (in dit geval CUC) verstuurd om abonnementen in CUC levend te houden.

   Meldingen van de Exchange server worden op de CUC-server ontvangen door Jetty, die de kennisgevingen en updates in de tbl_ExSubscriber-tabel ontleent.

   Vermeldingen in voorbeeld in tbl_ExSubscriber:

   

   Deze informatie kan ook worden bekeken via de Admin CLI. Voer de run cuc dbquery unitydyndb selecteer eerst 10 * uit tbl_exabonnement opdracht.

   tbl_ExSubscrieption slaat informatie op over elke postvakabonnement dat bij Exchange is geregistreerd via EWS. timestamputc (gemarkeerd in het vorige screenshot) is een van de kolommen in deze tabel. Het bevat Datum-tijd in UTC-tijd die aangeeft op welk tijdstip een bericht voor deze abonnement voor het laatst door CUC van de Exchange-server is ontvangen.

   Het CuMbxSync-proces heeft een thread die elke twee minuten controleert op stabiele abonnementen en een herabonnement op alle vaste items uitvoert. In het voorbeeldlogboek beschouwt de draad een reeks abonnementsingangen als een stap. Dit is geen ideaal geval (als alles goed is en Exchange tijdig inlevingskennisgevingen verstuurt). Dit veld wordt gebruikt om vaste abonnementen op te sporen via het CuMbxSync proces. De voorwaarde die wordt gebruikt om de vaste abonnementen te filteren is timestamputc < (CurrentTime - 15 minuten).

   Zelfs als er geen verandering is in een abonnee-postvak aan de kant Exchange, verstuurt de Exchange Server standaard nog steeds kennisgevingen voor elke abonnee (abonnee op Exchange server) met een tussenpoos van vijf minuten.

   Regelmatige meldingen die afkomstig zijn van Exchange kunnen worden bekeken in de logboeken van 'Connection Jetty'. Deze logbestanden kunnen vanaf RTMT worden opgehaald (kies Overtrek & Log Centraal > Verzamel bestanden > Verbonden verbinding en ga verder) of via Root Access (/usr/local/jetty/logs).

   

   Dit logbestand geeft de reactie weer die door CUC is verstuurd en die overeenkomt met de meldingen tijdens het leven die door de Exchange Server worden verstuurd. Als de meldingen zonder behoud niet bij CUC van Exchange aankomen, wordt het abonnement na elke 16 minuten (bij benadering) opnieuw geabonneerd en gebeurt alleen daarna postvaksynchronisatie.

   Mogelijke redenen voor dit gedrag kunnen zijn:

   • Proxyconfiguratie bij de Exchange Server
   • Configuratie van netwerkadresomzetting (NAT) in CUC
   • Firewallconfiguratie tussen CUC en de Exchange Server, enzovoort

   Betrok het netwerkteam en het uitwisselingsteam om de eigenlijke oorzaak van dit gedrag te krijgen.

   Als CUC op tijd een melding van de Exchange server ontvangt en de update niet wordt weergegeven in de CUC-brievenbus, neemt u contact op met de TAC voor ondersteuning bij het oplossen van de kwestie.