语音和统一通信 : Cisco Unity Connection

与Microsoft Exchange现场部署部署的单个收件箱同步问题

2015 年 8 月 28 日 - 机器翻译
其他版本: PDFpdf | 英语 (2015 年 4 月 23 日) | 反馈

简介

本文在同步问题提供信息被看到在Cisco Unity Connection (CUC)和Microsoft Exchange现场部署部署之间。

贡献用Ratnesh奈斯和Anirudh Mavilakandy, Cisco TAC工程师。

先决条件

要求

思科建议您有CUC知识。

使用的组件

本文档不限于特定的软件和硬件版本。

本文档中的信息都是基于特定实验室环境中的设备编写的。本文档中使用的所有设备最初均采用原始(默认)配置。如果您使用的是真实网络,请确保您已经了解所有命令的潜在影响。

问题

有同步问题的三种类型:

  • 没有同步
  • 从两边(对Exchange服务器的CUC的延迟的同步反之亦然)
  • 延迟的同步从Exchange服务器到CUC

故障排除

此部分提供信息关于怎样排除故障三个问题。因为排除故障问题的方法是相同的,前两个问题被结合到一个部分。

延迟或在CUC和Exchange之间的没有同步

可能有没有的多种原因或延迟在CUC和Exchange之间的同步。在此方案中,请检查在CUC和Exchange服务器之间的通信故障通过CLI或由日志集通过实时监控工具(RTMT)。

RTMT

选择Trace &记录中央印制厂>收集的文件。选择连接邮箱同步日志并且继续。

在CUC (/var/log/active/cuc)通过CLI :

为了查看文件,回车cat <filename>或者vi <filename>,其中<filename>是diag_CuMbxSync_xxxxxxxx.uc。

Admin CLI

日志可能通过Admin CLI也查看,但是相当困难。

为了列出文件,回车文件列表activelog /cuc/diag_CuMbxSync *请选派反向

为了查看文件,回车文件视图activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc xxxxxxxx是文件号的地方。

为了转接文件到一个安全FTP (SFTP)服务器,回车文件获得activelog /cuc/diag_CuMbxSync *

检查最新的CuMbxSync日志所有HTTP失败或警告。默认情况下因为错误或警告在跟踪写入,没有需要这时启用跟踪。

HTTP失败可能从CUC终止(间歇地或完全)消息传送操作同步到Exchange服务器反之亦然。如果HTTP失败在日志看到,则下一步是排除故障和调整这些问题。

Unity Connection单个收件箱故障排除TechNote文档在CuMbxSync日志看到的多种错误提供若干信息。

如果没有错误/失败CuMbxSync日志的,则请启用CsEws和CuMbxSync简单跟踪-所有级别。选择Cisco Unity Connection维护性> Trace >微Trace。点击在用户的统一消息帐户页的Reset选项并且再次收集日志。请与进一步协助的Cisco技术支持中心(TAC)联系。

延迟同步从Exchange服务器到CUC

Exchange通信到在端口7080的CUC服务器。此部分提供步骤为了排除故障问题。

  1. 保证端口7080是开放的,并且CUC在此端口侦听。

    Admin CLI

  2. 收集网络捕捉在Exchange服务器和CUC服务器为了确认Exchange服务器发送跳船通知,并且CUC接收这些跳船通知。

    在CUC CLI中,回车使用情况网络捕捉文件SIBTrace计数100000大小全部

    在Exchange,请下载并运行Wireshark

    在CUC捕获,您应该看到在端口7080 (用于的端口的此数据包模式接收通知) :

    确认(在用屏幕截图突出显示的IP地址帮助下)通知从Exchange服务器发送到CUC和不到一些代理服务器。如果在端口7080看不到同一个模式(或请看不到在端口7080)的所有流量,请检查与Exchange服务器团队。从Exchange的通知到CUC能是两个类型:

    • keep-alive通知
    • 消息操作通知

    keep-alive信息从Exchange传送到CUC。这是示例keep-alive通知消息:

    Exchange服务器发送此通知每五分钟(默认情况下)每个订阅的用户的。此通知由Exchange在CUC发送给Exchange网站服务(EWS)客户端(CUC在这种情况下)为了保留订阅运行。

    从Exchange服务器的通知接收在CUC服务器由跳船,在tbl_ExSubscription表里解析通知并且更新数据。

    tbl_ExSubscription的示例条目:

    同一信息可以通过Admin CLI查看。输入运行cuc dbquery unitydyndb挑选前10 *从tbl_exsubscription命令。

    tbl_ExSubscription存储关于每邮箱订阅的信息注册与Exchange通过EWS。timestamputc (突出显示用上一个屏幕画面)是其中一列在此表里。它包含在指示的UTC时间的日期-时间时期通知的此订阅是从Exchange服务器的CUC接收的为时。

    CuMbxSync进程有过时的订阅的监视器每两分钟和执行所有过时的条目的一resubscription的一个线索。在示例日志,线索一套订阅条目把过时视为。这不是一个理想的案件(如果一切优良是,并且Exchange以适时的方式发送keep-alive通知)。此字段用于由CuMbxSync进程检测过时的订阅。用于的情况过滤过时的订阅是timestamputc < (CurrentTime - 15分钟)

    即使没有在用户邮箱上的变化在Exchange侧,默认情况下Exchange服务器仍然发送每个用户的(Exchange服务器的用户通知)在五分钟间隔。

    来自Exchange的keep-alive通知在‘连接跳船’日志能被看到。这些日志可以收集从RTMT (请选择Trace &记录中央印制厂>收集的文件>连接跳船并且继续)或通过根访问权限(/usr/local/jetty/logs)。

    此日志显示CUC发送的答复与Exchange服务器发送的keep-alive通知相应。如果keep-alive通知不到达在从Exchange的CUC订阅在每16分钟之后然后将被重预订(近似),并且那时执行邮箱同步发生。

    这样行为的潜在原因能是这些中的一个:

    • 在Exchange服务器的代理配置
    • 在CUC的网络地址转换(NAT)配置
    • 在CUC和Exchange服务器之间的防火墙配置,等等

    涉及网络团队和Exchange团队为了获得此行为实际原因。

    如果CUC接收从Exchange服务器准时的通知,并且更新在CUC邮箱没有反射,请与协助的TAC联系能排除故障问题。


相关的思科支持社区讨论

思科支持社区是您提问、解答问题、分享建议以及与工作伙伴协作的论坛。


Document ID: 118883