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

选择Trace & Log Central > Collect Files。选择Connection Mailbox Sync日志并继续。

根

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

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

管理员CLI

日志也可通过管理CLI查看，但非常困难。

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

要查看文件，请输入file view activelog /cuc/diag_CuMbxSync_xxxxxxxx.uc，其中xxxxxxxx是文件编号。

要将文件传输到安全FTP(SFTP)服务器，请输入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 > 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（用于接收通知的端口）上看到以下数据包模式：

   

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

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

   保活消息从Exchange发送到CUC。以下是保活通知消息示例：

   

   

   Exchange服务器每五分钟（默认情况下）向每个订阅用户发送一次此通知。此通知由Exchange发送到Exchange Web服务(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(选择Trace & Log Central > Collect Files > Connection Jetty并继续)或根访问权限(/usr/local/jetty/logs)收集。

   

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

   此类行为的潜在原因可能是以下其中一项：

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

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

   如果CUC及时从Exchange服务器收到通知，并且更新未反映在CUC邮箱中，请联系TAC以寻求故障排除帮助。