Problemen met synchronisatie van één postvak in met on-premises implementaties van Microsoft Exchange

Downloadopties

PDF (241.2 KB)
Met Adobe Reader op diverse apparaten bekijken
ePub (92.0 KB)
Bekijken in diverse apps op iPhone, iPad, Android, Sony Reader of Windows Phone
Mobi (Kindle) (77.5 KB)
Op Kindle-apparaat of via Kindle-app op meerdere apparaten bekijken

Bijgewerkt:2 april 2015

Document-id:118883

Inclusief taalgebruik

De documentatie van dit product is waar mogelijk geschreven met inclusief taalgebruik. Inclusief taalgebruik wordt in deze documentatie gedefinieerd als taal die geen discriminatie op basis van leeftijd, handicap, gender, etniciteit, seksuele oriëntatie, sociaaleconomische status of combinaties hiervan weerspiegelt. In deze documentatie kunnen uitzonderingen voorkomen vanwege bewoordingen die in de gebruikersinterfaces van de productsoftware zijn gecodeerd, die op het taalgebruik in de RFP-documentatie zijn gebaseerd of die worden gebruikt in een product van een externe partij waarnaar wordt verwezen. Lees meer over hoe Cisco gebruikmaakt van inclusief taalgebruik.

Over deze vertaling

Cisco heeft dit document vertaald via een combinatie van machine- en menselijke technologie om onze gebruikers wereldwijd ondersteuningscontent te bieden in hun eigen taal. Houd er rekening mee dat zelfs de beste machinevertaling niet net zo nauwkeurig is als die van een professionele vertaler. Cisco Systems, Inc. is niet aansprakelijk voor de nauwkeurigheid van deze vertalingen en raadt aan altijd het oorspronkelijke Engelstalige document (link) te raadplegen.

Inhoud

Inleiding

Voorwaarden

Vereisten

Gebruikte componenten

Problemen

Problemen oplossen

Vertraagde of geen synchronisatie tussen CUC en Exchange

Vertraagde synchronisatie van Exchange Server naar CUC

Inleiding

Dit document bevat informatie over de synchronisatieproblemen die zijn opgetreden tussen Cisco Unity Connection (CUC) en on-premises implementaties van Microsoft Exchange.

Voorwaarden

Vereisten

Cisco raadt je aan om kennis te hebben van 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 soorten synchronisatieproblemen:

Geen synchronisatie
Vertraagde synchronisatie van beide zijden (CUC naar Exchange Server en vice versa)
Vertraagde synchronisatie van Exchange Server naar CUC

Problemen oplossen

In dit gedeelte vindt u informatie over het oplossen van de drie problemen. De eerste twee problemen worden gecombineerd in één sectie, omdat de aanpak voor het oplossen van problemen hetzelfde is.

Vertraagde of geen synchronisatie tussen CUC en Exchange

Er kunnen verschillende redenen zijn waarom er geen of vertraagde synchronisatie is tussen CUC en Exchange. Controleer in dit scenario communicatiefouten tussen CUC en de Exchange Server via de CLI of door logboekverzameling via de Real-Time Monitoring Tool (RTMT).

RTMT

Kies Trace & Log Central > Bestanden verzamelen. Kies Synchronisatielogs voor verbindingspostvak en ga verder.

wortel

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

Om het bestand te bekijken, voert u cat <bestandsnaam> of vi <bestandsnaam> in, waarbij <bestandsnaam> diag_CuMbxSync_xxxxxxx.uc is.

Opdrachtregelinterface van beheerder

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

Als u de bestanden wilt weergeven, voert u de activelog /cuc/diag_CuMbxSync* van de bestandenlijst in.

Als u een bestand wilt bekijken, voert u de bestandsweergave in activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc in, waarbij xxxxxxxx het bestandsnummer is.

Als u de bestanden wilt overbrengen naar een Secure FTP-server (SFTP), voert u het bestand get activelog /cuc/diag_CuMbxSync* in.

Controleer de nieuwste CuMbxSync-logs op eventuele HTTP-fouten of -waarschuwingen. Aangezien fouten of waarschuwingen standaard in de sporen worden geschreven, is het op dit moment niet nodig om sporen in te schakelen.

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

Het document Unity Connection Single Inbox Troubleshooting TechNote bevat informatie over de verschillende fouten die worden gezien in de log-bestanden van CuMbxSync.

Als er geen fouten / fouten zijn in het CuMbxSync-log, schakel dan CsEws en CuMbxSync micro-sporen in - alle niveaus. Kies Cisco Unity Connection Serviceability > Trace > Micro Trace. Klik op de resetoptie op de pagina Unified Messaging Account van de gebruiker en verzamel de logs opnieuw. Neem contact op met het Cisco Technical Assistance Centre (TAC) voor verdere hulp.

Vertraagde synchronisatie van Exchange Server naar CUC

Exchange communiceert met de CUC-server op poort 7080. Dit gedeelte bevat stappen om het probleem op te lossen.

Zorg ervoor dat poort 7080 open is en CUC luistert naar deze poort.
Opdrachtregelinterface van beheerder
wortel
Verzamel een netwerkopname op zowel de Exchange-server als de CUC-server om te bevestigen dat de Exchange-server Jetty-meldingen verzendt en CUC deze Jetty-meldingen ontvangt.
Voer in de CUC-CLI hulpprogramma's in voor het vastleggen van netwerkbestanden SIBTrace count 100000 size ALL.
Op Exchange kunt u Wireshark downloaden en uitvoeren.
In de CUC-opname moet u dit pakketpatroon zien op poort 7080 (poort die wordt gebruikt om meldingen te ontvangen):
Bevestig (met behulp van het IP-adres dat in de schermafbeelding is gemarkeerd) dat de melding van de Exchange-server naar CUC is verzonden en niet naar een of andere proxyserver. Als u niet hetzelfde patroon ziet op poort 7080 (of geen verkeer ziet op poort 7080), neemt u contact op met het Exchange-serverteam. Meldingen van Exchange naar CUC kunnen van twee typen zijn:
- Keep-alive-meldingen
- Berichtenbewerkingsmelding
Keep-alive berichten worden verzonden van Exchange naar CUC. Hier is een voorbeeld van een keep-alive-melding:
De Exchange-server verzendt deze melding elke vijf minuten (standaard) voor elke geabonneerde gebruiker. Deze melding wordt door Exchange verzonden naar de Exchange Web Services (EWS)-client (CUC in dit geval) om abonnementen in CUC in leven te houden.
Meldingen van de Exchange-server worden op de CUC-server ontvangen door Jetty, die de meldingen analyseert en gegevens bijwerkt in de tabel tbl_ExSubscription.
Voorbeeldvermeldingen in tbl_ExSubscription:
Dezelfde informatie kan worden bekeken via de Admin CLI. Voer de run cuc dbquery unitydyndb selecteren eerste 10 * uit tbl_exsubscription opdracht.
tbl_ExSubscription slaat informatie op over elk postvakabonnement dat via EWS bij Exchange is geregistreerd. tijdstempel (gemarkeerd in de vorige schermafbeelding) is een van de kolommen in deze tabel. Het bevat Datum-tijd in UTC-tijd die aangeeft wanneer een melding voor dit abonnement voor het laatst door CUC is ontvangen van de Exchange-server.
Het CuMbxSync-proces heeft een thread die elke twee minuten controleert op verouderde abonnementen en een herinschrijving doet voor verouderde vermeldingen. In het voorbeeldlogboek beschouwt de thread een reeks abonnementsvermeldingen als stabiel. Dit is geen ideaal geval (als alles in orde is en Exchange tijdig keep-alive-meldingen verzendt). Dit veld wordt gebruikt om stabiele abonnementen te detecteren via het CuMbxSync-proces. De voorwaarde die wordt gebruikt om de verouderde abonnementen uit te filteren, is timestamputc < (CurrentTime - 15 minuten).
Zelfs als er geen wijziging is in een abonneemailbox aan de Exchange-kant, verzendt de Exchange Server standaard nog steeds meldingen voor elke abonnee (abonnee op de Exchange-server) met een interval van vijf minuten.
Keep-alive meldingen die afkomstig zijn van Exchange zijn te zien in 'Connection Jetty'-logs. Deze logs kunnen worden verzameld via RTMT (kies Trace & Log Central > Bestanden verzamelen > Verbindingssteiger en doorgaan) of via Root Access (/usr/local/jetty/logs).
Dit logboek toont het antwoord dat door CUC is verzonden en dat overeenkomt met de Keep-Alive-meldingen die door de Exchange Server zijn verzonden. Als keep-alive-meldingen niet bij CUC van Exchange aankomen, wordt het abonnement na ongeveer elke 16 minuten opnieuw geabonneerd en vindt alleen dan postvaksynchronisatie plaats.
Mogelijke oorzaken van dergelijk gedrag kunnen een van deze zijn:
- Proxyconfiguratie op de Exchange Server
- Network Address Translation (NAT)-configuratie bij CUC
- Firewallconfiguratie tussen CUC en de Exchange Server, enzovoort
Betrek het netwerkteam en het Exchange-team om de werkelijke reden van dit gedrag te achterhalen.
Als CUC op tijd een melding van de Exchange-server ontvangt en de update niet wordt weergegeven in het CUC-postvak, neemt u contact op met de TAC voor hulp bij het oplossen van het probleem.