Microsoft Exchange内部部署的单收件箱同步问题

简介

本文档提供有关Cisco Unity Connection(CUC)和Microsoft Exchange本地部署之间出现的同步问题的信息。

先决条件

要求

思科建议您了解CUC。

使用的组件

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

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

问题

同步问题有三种类型：

• 无同步
• 从两端延迟同步（CUC到Exchange Server和反之）
• 从Exchange Server到CUC的延迟同步

故障排除

本节提供有关如何排除这三个问题的信息。前两个问题合并到一个部分，因为故障排除方法相同。

CUC和Exchange之间延迟或无同步

CUC和Exchange之间没有同步或延迟同步可能有多种原因。在此场景中，通过CLI或通过实时监控工具(RTMT)的日志收集检查CUC和Exchange Server之间的通信故障。

RTMT

选择跟踪和日志中心>收集文件。选择“连接邮箱同步日志”并继续。

根

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

要查看文件，请输入cat <filename>或vi <filename>，其中<filename>为diag_CuMbxSync_xxxxxxxxxx.uc。

管理CLI

日志也可以通过管理员CLI查看，但是这相当困难。

要列出文件，请输入file list activelog /cuc/diag_CuMbxSync* detail reverse。

要查看文件，请输入文件查看活动/cuc/diag_CuMbxSync_xxxxxxxx.uc,其中xxxxxxxx是文件编号。

要将文件传输到安全FTP(SFTP)服务器，请输入file get activelog /cuc/diag_CuMbxSync*。

检查最新的CuMbxSync日志，查找任何HTTP故障或警告。由于默认情况下错误或警告会写入跟踪，因此此时无需启用跟踪。

HTTP故障可能会停止（间歇或完全）从CUC到Exchange服务器的消息传送操作同步，反之亦然。如果日志中出现HTTP故障，则下一步是排除故障并解决这些问题。

Unity Connection单收件箱故障排除技术说明文档提供了CuMbxSync日志中出现的各种错误的一些信息。

如果CuMbxSync日志中没有错误/故障，则启用CsEws和CuMbxSync微跟踪 — 所有级别。选择Cisco Unity Connection Serviceability > Trace > Micro Trace。点击用户的Unified Messaging Account页面上的重置选项，并再次收集日志。请联系思科技术支持中心(TAC)获取进一步帮助。

从Exchange Server到CUC的延迟同步

Exchange与端口7080上的CUC服务器通信。本部分提供排除故障的步骤。

1. 确保端口7080已打开，CUC在此端口上侦听。

   管理CLI

   

   根

   

2. 在Exchange服务器和CUC服务器上收集网络捕获，以确认Exchange服务器发送Jetty通知，而CUC接收这些Jetty通知。

   在CUC CLI中，输入utils network capture file SIBTrace count 100000 size ALL。

   在Exchange上，下载并运行Wireshark。

   在CUC捕获中，您应该在端口7080（用于接收通知的端口）上看到以下数据包模式：

   

   确认（借助屏幕截图中突出显示的IP地址）通知已从Exchange服务器发送到CUC，而不是发送到某些代理服务器。如果您在端口7080上没有看到相同的模式（或在端口7080上没有看到任何流量），请与Exchange服务器团队联系。从Exchange到CUC的通知可以有两种类型：

   • 保持连接通知
   • 消息操作通知

   保持连接消息从Exchange发送到CUC。以下是保持连接通知消息的示例：

   

   

   Exchange服务器每五分钟（默认情况下）为每个订用用户发送一次此通知。此通知由Exchange发送到Exchange Web Services(EWS)客户端（本例中为CUC），以使订用在CUC中保持活动状态。

   Jetty在CUC服务器接收来自Exchange服务器的通知，该服务器解析通知并更新tbl_ExSubscription表中的数据。

   tbl_ExSubscription中的条目示例:

   

   同样的信息可通过管理CLI查看。输入run cuc dbquery unitydyndb select first 10 * from tbl_exsubscription命令。

   tbl_ExSubscription存储有关通过EWS向Exchange注册的每个邮箱订阅的信息。timestamputc（在上一屏幕截图中突出显示）是此表中的列之一。它包含以UTC时间表示的日期时间，表示CUC上次从Exchange服务器接收此订用通知的时间。

   CuMbxSync进程有一个线程，每两分钟监控一次过期订阅，并对任何过期条目执行重新订阅。在示例日志中，线程将一组订用条目视为过期。这不是理想情况（如果一切正常，并且Exchange及时发送保活通知）。 此字段用于检测CuMbxSync进程的过时订用。用于过滤过时订用的条件是timestamputc <（CurrentTime - 15分钟）。

   即使Exchange端的用户邮箱没有更改，Exchange Server默认仍会以五分钟间隔发送每个用户（Exchange服务器上的用户）的通知。

   来自Exchange的保持连接通知可在“连接码”日志中查看。这些日志可以从RTMT(选择跟踪和日志中心>收集文件>连接码并继续)或通过根访问(/usr/local/jetty/logs)。

   

   此日志显示CUC发送的响应，该响应与Exchange Server发送的保持连接通知对应。如果保持连接通知未从Exchange到达CUC，则订用将在每16分钟（大约）后重新订用，只有到那时才会进行邮箱同步。

   这种行为的潜在原因可能是以下原因之一：

   • Exchange Server上的代理配置
   • CUC上的网络地址转换(NAT)配置
   • CUC和Exchange Server之间的防火墙配置等

   让网络团队和Exchange团队参与，以便了解此行为的实际原因。

   如果CUC按时收到来自Exchange服务器的通知，且CUC邮箱中未反映更新，请联系TAC以寻求问题故障排除的帮助。