이 문서에서는 Cisco CUC(Unity Connection)와 Microsoft Exchange On-Premises 구축 간에 발생하는 동기화 문제에 대한 정보를 제공합니다.
Cisco는 CUC에 대해 알고 있는 것을 권장합니다.
이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.
이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다.이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다.현재 네트워크가 작동 중인 경우, 모든 명령어의 잠재적인 영향을 미리 숙지하시기 바랍니다.
다음과 같은 세 가지 유형의 동기화 문제가 있습니다.
이 섹션에서는 세 가지 문제를 해결하는 방법에 대해 설명합니다.처음 두 문제는 문제를 해결하는 방식이 동일하므로 한 섹션으로 통합됩니다.
CUC와 Exchange 간에 동기화가 없거나 지연되는 다양한 이유가 있을 수 있습니다.이 시나리오에서는 CLI를 통해 또는 RTMT(Real-Time Monitoring Tool)를 통한 로그 수집을 통해 CUC와 Exchange Server 간의 통신 장애를 확인합니다.
RTMT
Trace & Log Central > Collect Files를 선택합니다.연결 사서함 동기화 로그를 선택하고 계속합니다.
루트
CLI를 통해 CUC(/var/log/active/cuc)에서 다음을 수행합니다.
파일을 보려면 cat <filename> 또는 vi <filename>을 입력합니다. 여기서 <filename>은 diag_CuMbxSync_xxxxxxxx.uc입니다.
관리자 CLI
Admin CLI를 통해 로그를 볼 수도 있지만 매우 어렵습니다.
파일을 나열하려면 activelog /cuc/diag_CuMbxSync* detail reverse를 입력합니다.
파일을 보려면 파일 보기 activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc을 입력합니다. 여기서 xxxxxx는 파일 번호입니다.
파일을 SFTP(Secure FTP) 서버로 전송하려면 get activelog /cuc/diag_CuMbxSync*를 입력합니다.
HTTP 오류 또는 경고에 대한 최신 CuMbxSync 로그를 확인합니다.오류나 경고는 추적에 기본적으로 기록되므로 이 시점에서는 추적을 활성화할 필요가 없습니다.
HTTP 실패가 CUC에서 Exchange 서버로의 메시징 작업 동기화를 중지(간헐적으로 또는 완전히)하거나 그 반대로 중지할 수 있습니다.HTTP 오류가 로그에 표시되면 다음 단계는 이러한 문제를 해결하고 수정하는 것입니다.
Unity Connection Single Inbox Troubleshooting TechNote 문서는 CuMbxSync 로그에 표시되는 다양한 오류에 대한 몇 가지 정보를 제공합니다.
CuMbxSync 로그에 오류/오류가 없는 경우 CsEws 및 CuMbxSync 마이크로 추적을 활성화합니다. 모든 레벨입니다.Cisco Unity Connection Serviceability > Trace > Micro Trace를 선택합니다.User(사용자)의 Unified Messaging Account(통합 메시징 계정) 페이지에서 재설정 옵션을 클릭하고 로그를 다시 한 번 수집합니다.자세한 내용은 Cisco TAC(Technical Assistance Center)에 문의하십시오.
Exchange는 포트 7080의 CUC 서버와 통신합니다.이 섹션에서는 문제를 해결하기 위한 단계를 제공합니다.
관리자 CLI
루트
CUC CLI에서 utils network capture file SIBTrace count 100000 size ALL을 입력합니다.
Exchange에서 Wireshark를 다운로드하여 실행합니다.
CUC 캡처에서는 포트 7080(알림을 수신하는 데 사용되는 포트)에서 다음 패킷 패턴을 확인해야 합니다.
화면 캡처에 강조 표시된 IP 주소의 도움말과 함께 Exchange 서버에서 CUC로 알림이 전송되었는지 확인하고 일부 프록시 서버에는 보내지 않습니다.포트 7080에서 동일한 패턴이 표시되지 않거나 포트 7080에서 트래픽이 표시되지 않는 경우 Exchange 서버 팀에 문의하십시오.Exchange에서 CUC로의 알림은 다음 두 가지 유형이 될 수 있습니다.
Keep-alive 메시지는 Exchange에서 CUC로 전송됩니다.다음은 keep-alive 알림 메시지의 예입니다.
Exchange 서버는 가입된 모든 사용자에 대해 5분마다(기본값) 이 알림을 전송합니다.이 알림은 Exchange에서 CUC에서 등록을 유지하기 위해 CUC(Exchange Web Services) 클라이언트(이 경우 CUC)로 전송됩니다.
Exchange 서버의 알림은 Jetty가 CUC 서버에서 수신하며, Jetty는 알림을 구문 분석하고 tbl_ExSubscription 테이블의 데이터를 업데이트합니다.
tbl_ExSubscription의 샘플 항목:
Admin CLI를 통해 동일한 정보를 볼 수 있습니다.run cuc dbquery unityddb select first 10 * from tbl_exsubscription 명령을 입력합니다.
tbl_ExSubscription은 EWS를 통해 Exchange에 등록된 각 사서함 구독에 대한 정보를 저장합니다. timestamputc(이전 스크린샷에서 강조 표시됨)는 이 테이블의 열 중 하나입니다.Date-time(UTC 시간)이 포함되는데, 이 시간은 Exchange 서버에서 CUC가 이 구독에 대한 알림을 마지막으로 수신한 시간을 나타냅니다.
CuMbxSync 프로세스에는 부실 서브스크립션을 2분마다 모니터링하고 오래된 엔트리에 대해 재서브스크립션을 수행하는 스레드가 있습니다.샘플 로그에서 스레드는 서브스크립션 항목 집합을 오래된 것으로 간주합니다.이는 이상적인 경우가 아닙니다(모든 것이 정상이고 Exchange에서 적시에 Keep-Alive 알림을 보내는 경우). 이 필드는 CuMbxSync 프로세스에서 오래된 등록을 탐지하는 데 사용됩니다.오래된 구독을 필터링하는 데 사용되는 조건은 timestamputc < (CurrentTime - 15분)입니다.
Exchange 측의 가입자 사서함에 변경 사항이 없는 경우에도 기본적으로 Exchange Server는 5분 간격으로 각 가입자(Exchange 서버의 가입자)에 대한 알림을 전송합니다.
Exchange에서 오는 Keep-alive 알림은 'Connection Jetty' 로그에서 확인할 수 있습니다.이러한 로그는 RTMT에서 수집(Trace & Log Central > Collect Files > Connection Jetty를 선택하고 진행)하거나 루트 액세스(/usr/local/jetty/logs)를 통해 수집할 수 있습니다.
이 로그는 Exchange Server에서 보낸 연결 유지 알림에 해당하는 CUC에서 보낸 응답을 표시합니다.Exchange에서 CUC에 Keep-Alive 알림이 도착하지 않으면 약 16분(약)마다 구독이 다시 구독되며 사서함 동기화가 발생합니다.
이러한 동작의 잠재적 원인은 다음 중 하나일 수 있습니다.
네트워크 팀과 Exchange 팀을 참여시켜 이러한 행동의 실제 원인을 파악합니다.
CUC가 Exchange 서버에서 정시에 알림을 수신하고 업데이트가 CUC 사서함에 반영되지 않은 경우 TAC에 문의하여 문제를 해결하십시오.