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