使用 Exchange Server 2007 部署统一消息

假设您已决定要在您的环境中部署 Exchange Server 2007 统一消息。您已安装了统一消息服务器角色，并已将其与现有的 PBX 集成。现在，您和另外 10 位员工将语音邮件、电子邮件和传真消息存储在 Exchange 中。完成后，您

可能觉得这已是一项重要成就。但是，您如何在不影响业务运营的前提下，跨多个站点为数千名订阅者部署同样的功能呢？

我希望本文会对您有所帮助。本文旨在帮助您了解如何在您的环境中部署统一消息，并阐明与此类部署相关的电话概念。如果您需要有关 Exchange Server 2007 统一消息的安装、配置或功能方面的帮助，请参阅本文末尾的“统一消息资源”边栏。此外，Microsoft 已经确定了一些公司作为统一消息专家，协助客户解决有关 Exchange Server 2007 统一消息的咨询、设计和部署问题。这些专家也已在边栏中列出，如果需要安装、配置或部署方面的帮助，请联系他们。

统一消息技术对于 Exchange 而言并非是新技术；许多组织都提供与 Exchange 集成的统一消息产品。但是，这是第一个本身支持统一消息的 Exchange 版本。此版本问世后，许多客户都在其组织内部的小组中部署了 Exchange Server 2007 统一消息。但是，由于种种原因，这些客户并不总是对其所有用户部署统一消息。其中的一个问题是，许多 Exchange 管理员不熟悉实现统一消息服务所需的电话概念与技术，在其企业内部设计和部署这些解决方案让他们苦恼不已。

与所有的部署项目一样，分阶段部署通常可以得到最佳结果。规划体系结构、测试解决方案、试验用户群体、培训和将用户迁移到新系统这五个阶段，涵盖了统一消息项目需要考虑的方方面面。计划项目时，关键是要将 IT 组和电信组同时包含在组织中。

必须复制用户在传统的语音邮件平台上应具备的许多功能，如果无法进行复制，则应设计一个替代解决方案，以降低实现新系统时对用户群体的影响。此部分非常关键，必须由电信小组协助完成。同时，电信小组还需要从 IT 团队了解在进行部署时如何管理、支持新语音邮件平台及进行故障排除。

了解基础体系结构、呼叫流以及与统一消息相关的一些术语后，就会觉得进行规划要容易得多了。图 1 展示了一个集成到现有公司电话系统中的统一消息解决方案示例。现在，让我们来详细了解一下在进行此类部署时可能遇到的一些最常见的概念和技术。

Figure 1 A PBX-to-Unified Messaging solution (单击该图像获得较小视图)

Figure 1 A PBX-to-Unified Messaging solution (单击该图像获得较大视图)

专用交换分机 (PBX) 是企业内部使用的专用电话网络。在此类系统上，通常每位用户都拥有一部连接到 PBX 的桌面电话，以便内部用户之间通过拨打分机号码（通常是四位或五位数字）向对方发出呼叫，以及拨打外部电话。

如果企业客户拥有多个 PBX 位置，有时会决定使用 PBX 供应商专有的联网技术将这些系统连接在一起。这样，联网的 PBX 上的所有用户只需拨打分机号码即可相互发出呼叫。

统一消息涉及以下两个不同系统的集成：Exchange 邮件系统和物理电话系统。统一消息服务器和电话体系结构之间的通信是使用会话初始协议 (SIP) 完成的。某些 PBX 技术可以通过 SIP 直接与统一消息服务器通信，另外一些技术则需要 SIP 网关。在图 1 中，PBX 是通过 T1 线路连接到 SIP 网关的。当某个呼叫被转发到统一消息时，PBX 会向 SIP 网关发送信息（呼叫方电话号码、被叫方电话号码及某种类型的原因代码），以使统一消息服务器知道被叫方是谁。

某些 PBX 可通过 IP 网络联在一起。电话网络可通过 IP 网络将呼叫重定向到集中式语音邮件解决方案。例如，如果您看过图 2，会注意到苏黎世已被连接回伦敦。

Figure 2 A more complex Unified Messaging deployment (单击该图像获得较小视图)

Figure 2 A more complex Unified Messaging deployment (单击该图像获得较大视图)

假设外部呼叫者拨打了某位统一消息订阅者的电话。此时，该统一消息订阅者不在办公室，故无人接听电话。您可以参考图 1 中的消息路径。

PBX 将呼叫发送至 SIP 网关，此网关将通过基于 TCP 的 SIP 与统一消息服务器协商该呼叫。服务器将收到来自 SIP 网关的用以指明被叫方的集成数据。然后，统一消息服务器将播放此订阅者的问候语，并允许外部呼叫者录制留言。接着，此留言被传送到此统一消息订阅者的 Exchange 邮箱。

此呼叫流是对这种情况的一种经过大幅简化的描述。重要的是了解当录制留言时，统一消息服务器会通过 SMTP 将留言转发到集线器传输服务器，以便将留言传送到邮箱服务器。

现在，作为统一消息订阅者，用户已能够通过电话（使用 Outlook^® Voice Access）或计算机（使用 Outlook 2007 或 Outlook Web Access）访问其 Exchange 邮箱。不过，通过 Outlook 2007 或 Outlook Web Access 的“在电话上播放”功能，订阅者还能够使用电话访问留言；利用此功能，订阅者可使统一消息通过拨打指定电话来播放所选消息，而不是通过计算机访问所选消息。使用此方法时，统一消息服务器将同时与客户端访问服务器和邮箱服务器进行交互。了解这一点很重要，因为如果您将统一消息服务器置于没有本地客户端访问服务器的远程办公室中，统一消息服务器就需要通过 WAN 连接到客户端访问服务器，而这将导致性能降低。

客户的核心 Exchange 体系结构设计分为以下两种：集中式或非集中式。通常，统一消息体系结构遵循 Exchange 体系结构，这意味着无论您在哪里部署邮箱服务器，都会在该位置部署统一消息服务器。当然，任何规则都有例外。

设计统一消息体系结构时，必须注意五个基本方面。

• 服务器位置
• 统一消息服务器的数量
• SIP 网关
• 邮箱存储
• 统一消息站点配置

此外，不能忽略业务连续性。通常，与 Exchange 相关的灾难恢复计划可用于确定统一消息的相关元素。

部署方案示例可帮助您了解统一消息服务器角色。图 2 清楚地展示了具有统一消息功能的 Exchange Server 2007 的大型企业部署情况。

在这个较复杂的设计中，主数据中心在西雅图和伦敦。位于这两个位置的统一消息服务器为各自的用户群体服务，这是因为邮箱服务器和集线器传输服务器均在本地。这两个站点都具有 IP PBX，可提供本地统一消息服务器进行呼叫应答的呼叫范围。

中型站点位于纽约和格拉斯哥。位于这两个位置的统一消息服务器为各自的用户群体服务，这是因为邮箱服务器和集线器传输服务器均在本地。与主数据中心相同，这两个站点也具有 IP PBX，可提供本地统一消息服务器进行呼叫应答的呼叫范围。

较小的站点没有本地邮箱服务器或集线器传输服务器，但能够通过主数据中心提供统一消息功能。奥斯汀有一个 NEC PBX，它使用模拟连接与本地 SIP 网关连接。对本地最终用户的呼叫将被转发到 SIP 网关，此网关将与西雅图的统一消息服务器协商，以便在统一消息上提供呼叫应答。

苏黎世设有通过 IP 网络与伦敦的 Avaya 通信管理器联网的 Avaya 通信管理器。对本地用户的呼叫将通过 Avaya 通信管理器网络转发，此网络将与伦敦的统一消息服务器协商，以便在统一消息上提供呼叫应答。

在此示例中，西雅图站点在同一物理位置上设有 Exchange 邮箱服务器和统一消息服务器。当处理单一站点体系结构时，所有服务器（邮箱服务器、统一消息服务器、客户端访问服务器等）和 PBX 设备都包含在同一站点内。对于具有多个站点的公司，设计起来会比较复杂。这种复杂性看似令人生畏，但只要正确理解了统一消息的一些基本原理，还是可以解决的。

如图 2 所示，如果某站点中包含邮箱服务器，则建议也在此站点设置统一消息服务器。西雅图、伦敦、纽约及格拉斯哥都符合这种设计。奥斯汀和苏黎世在本地都没有邮箱服务器，但借助于 IP 网络，仍可以为这些位置提供统一消息服务。奥斯汀设有本地模拟 PBX。在这种情况下，必须使用 SIP 网关提供与西雅图的统一消息服务器的 IP 网络连接。苏黎世设有通过网络连接到伦敦 PBX 的本地 IP PBX。因此，对苏黎世用户的呼叫会通过电话网络传回到伦敦 PBX 和统一消息服务器。

由于对苏黎世订阅者的呼叫会穿越网络，然后由伦敦的集中式统一消息系统处理，所以如果网络中断，则在网络修复前，对苏黎世所有订阅者的呼叫都将没有应答。如果发生网络中断事件时需要保持本地网络通信正常工作，则应在苏黎世设置一台统一消息服务器。网络中断期间，统一消息服务器将继续应答呼叫，并在网络修复后传送这些呼叫。

设计适合您环境的体系结构时，服务器位置可能是最重要的考虑因素。图 3 中的流程图可帮助您确定适当的服务器位置。

Figure 3 Determining server placement (单击该图像获得较小视图)

Figure 3 Determining server placement (单击该图像获得较大视图)

需要考虑的下一个方面是您需要多少台统一消息服务器来支持用户群体。需要的数量实际上取决于该站点的具体因素。

统一消息的可伸缩性取决于服务器可支持的并发呼叫（在电话领域称为端口）数量。传入系统的每个呼叫都需要统一消息服务器提供网络、CPU、内存和磁盘资源。通过增加这些资源，统一消息服务器可以支持更多的并发呼叫。由于此类资源总是有限的，因此统一消息服务器只能处理一定数量的并发呼叫，否则会导致资源耗尽。

您可以通过 Erlang 流量分析计算来确定支持特定数量的订阅者所需的端口数，在此不作详细介绍。确定所需端口数的简单方法是直接询问电话管理员现有语音邮件系统上正在使用的语音邮件端口数量。根据现场经验，传统的语音邮件系统和统一语音邮件系统对端口的要求应该是非常类似的。

通常情况下，建议您在单一服务器上实现的端口数不要超过 60 个。这与软件或硬件限制无关，而是因为具有 60 个端口的单一服务器可支持近 5000 个用户。如果此单一服务器出现中断，就会使单一服务器故障波及整个（非常大）订阅者群体。

当实现统一消息服务器时，您可以考虑在体系结构中设计 N+1 冗余配置。图 4 显示了一个完全冗余的服务器和 SIP 网关设计。使用此设计，如果统一消息服务器 1 出现中断，来自 SIP 网关 1 的呼叫将自动与统一消息服务器 2 协商呼叫。您也可以对 PBX 进行编程设计，以在各个 SIP 网关之间平均分配呼叫负荷。例如，传入系统的第一个呼叫被路由到 SIP 网关 1，而下一个呼叫被路由到 SIP 网关 2。在各网关之间交替的呼叫可在统一消息服务器之间提供平均呼叫分配和共享负载。

Figure 4 Distributing calls between servers for redundancy (单击该图像获得较小视图)

Figure 4 Distributing calls between servers for redundancy (单击该图像获得较大视图)

目前，Exchange Server 2007 统一消息解决方案支持以下两个 SIP 网关提供程序：AudioCodes 和 Dialogic。如果您的设计中需要 SIP 网关，请确保购买的网关支持设计所需的会话（端口）数量。例如，如果设计需要 32 个端口，就需要购买至少支持此会话数目的网关。

如果不清楚您的 PBX 是否适用于统一消息，或者不知道应使用哪种网关，请查看“统一消息资源”边栏。该边栏列出了 Mcrosoft 特定指南的链接，还列出了统一消息专家目录的链接，这些专家可帮助您评估组织的特定需求。根据我的个人经验，此边栏列出的 PBX 几乎都能与 SIP 网关和 Exchange 统一消息一起使用，并且部分 PBX 自身还可使用基于 TCP 的 SIP 与统一消息服务器通信。

Exchange 统一消息支持使用以下三种音频编码解码器来存储语音邮件：G.711 PCM Linear、GSM 06.10 和 Windows Media^® Audio (WMA)。每个 PCM Linear WAV 文件中每秒的音频大约占用 16 KB。WMA 是统一消息的默认音频编码解码器，它将每秒的音频压缩到 1.1 kb，标头占 7 KB。GSM 06.10 将每秒的音频压缩到 1.6 kb，但它的标头比 WMA 编码的标头小。

WMA 和 GSM 06.10 编码提供的语音邮件的语音质量都可以接受。根据使用 WMA 或 GSM 编码解码器的现场经验，您可以根据组织对语音邮件的依赖程度将邮箱存储大小提高 10% 到 20%。

确定在环境中使用哪种音频编码解码器时，请留意最终用户可能使用的移动设备和其他操作系统。与本主题有关的大多数问题都是关于用户是否可以在其 Windows Mobile^® 设备上接听语音邮件的。但其他操作系统也是一个考虑因素：您可能会大规模部署无法播放 WMA 文件的 Linux 计算机。无论是哪种情况，请记住，此类因素都将提高对服务台资源的要求，需要在培训时加以考虑。

无论统一消息体系结构是集中的还是分散的，在组织中部署统一消息前，都必须考虑很多语音邮件要求。“统一消息检查表”边栏详细列出了项目团队需要讨论的主题。应为要在其中部署统一消息的每个站点收集所有主题的信息。请记住，IT 小组和电信小组需要共同协作来综合考虑这些主题。

设计并配置好系统后，需要对系统进行测试以验证设计。在多站点设计中，我建议至少测试两个独立站点，以验证概念并确认设计正常工作。

应根据配置要求制定功能测试计划，然后完成计划。功能测试计划应包括订阅者访问方法（电话、Outlook 2007 和 Outlook Web Access）、管理方法以及硬件停用和网络中断。

如果测试完成，并且所有人都同意统一消息将复制旧的语音邮件系统的功能，或已设计出替代解决方案来支持无法复制的配置或功能，则应选择某个用户试验小组来测试该系统。启用试验小组将演示在实际环境中将订阅者从旧的语音邮件系统移动（电话术语叫“切换”）到统一消息所需的步骤。一般来讲，切换订阅者需要执行以下步骤：

1. 对订阅者禁用现有语音邮件系统。
2. 通过 Exchange 管理控制台在统一消息的 Active Directory 中启用订阅者。
3. 将电话的覆盖路径更改为统一消息试验号码。

对订阅者禁用现有语音邮件系统至关重要，否则会将邮件发送到旧邮箱。

在试验阶段，应记录订阅者遇到的所有系统功能问题。记录这些细节可以在培训阶段解决常见问题。

要成功进行切换，培训是很关键的。用户习惯于使用特定用户界面通过电话访问语音邮件。例如，一些语音邮件系统要求用户按 5 来接听邮件。Exchange 统一消息要求用户按 1 或说“语音邮件”（或者使用 Outlook 2007 或 Outlook Web Access 来播放语音邮件）。您的统一消息订阅者培训应包含电话用户界面导航、Outlook Voice Access 导航和 Outlook/Outlook Web Access 导航。

使用 Exchange 2007 统一消息时，Outlook Voice Access 已内置了声控功能。一些用户热衷于体验系统的新功能，这种新奇感可能有助于轻松实现从一种用户界面到另一种用户界面的过渡。

Exchange 统一消息可以将自定义文本电子邮件发送到每位用户（如果这些用户已启用）。这些自定义邮件可用于提供指向常见问题 (FAQ) 的重要 Web 链接、订阅者文档以及服务台电话号码等。邮件中还可能包含有关如何访问语音邮件系统和订阅者唯一密码的信息。这是您在启用最终用户时可以利用的最强大功能之一。

将系统迁移到整个生产环境中有许多不同的方法，其中两种主要方法是逐步迁移和快速切换。无论您选择哪种方法，都要针对在实验组中记录的常见问题对技术支持人员进行培训。另外，请务必向他们演示如何启用用户，如何验证用户是否已启用，以及如何更改密码。

将用户从旧的语音邮件系统迁移到统一消息非常简单，但需要注意一个重要问题：语音邮件联网。就像电子邮件系统允许您将电子邮件发送、转发和回复到其他电子邮件用户和系统的情况一样，语音邮件也允许您发送、转发和回复到其他语音邮件用户和系统。

假设 Alice 和 Brian 目前都使用旧语音邮件系统。Brian 被迁移到统一消息，他希望向使用旧语音邮件系统的 Alice 发送邮件。因为这两个用户处于各自独立的系统上，所以他们不再能够彼此发送、转发或回复语音邮件；很不幸，语音邮件孤岛形成了。

传统语音邮件系统通过使用某种类型的联网协议转换器将异类系统联在一起来解决此问题。但是，目前并没有允许异类系统联网到 Exchange Server 2007 统一消息的联网协议转换器。尽管这对于您的组织而言可能并不重要，但当选择迁移小组中的用户时，就需要对此有所了解。

我的首选方法是按站点对所有用户执行快速切换。快速切换可以实现从一个系统到另一个系统的完全迁移。此操作一般在周末进行；用户星期五回家，星期一回去工作时就可使用新语音邮件系统。一些管理员说，快速切换应仅用于小型企业客户或远程站点。我不同意这种说法。我曾在一个拥有 7000 位用户的大型站点应用过快速切换，而只有不到 1% 的员工需要呼叫技术支持人员请求支持。如果已计划好并成功执行了项目的其他所有阶段，则应该能顺利切换到完整生产系统。

但是，在将多个站点切换到完整的生产系统时，应考虑首先每次切换一个较小的远程站点，最后切换最大的站点。认真总结从较小站点得到的经验教训，据此对项目计划进行必要的更改。

通常，在实时切换系统前，应完成所有用户培训，并为统一消息启用所有用户。以下是一个分步方法，可用于为快速切换语音邮件系统做准备。

首先，验证已完整安装、配置和测试统一消息系统。

以小组形式进行培训。向参加培训的用户说明其邮箱将在系统正式投入使用前先行启用，鼓励他们登录自己的邮箱，通过更改密码并录制问候语对邮箱进行初始化。培训完成时，立即启用这些用户，以便用户能在进行切换前初始化自己的邮箱。

最后，当所有培训完成时，选择在周末对所有用户禁用旧的语音邮件系统，并将其电话转发到 Exchange 统一消息。在星期一早晨，您的系统即可供组织中的所有用户使用。

无论您是要支持单一站点还是支持拥有多个站点的大型组织，本文中介绍的信息都应对您有所帮助。多站点组织设计起来比较复杂，但无论您拥有 50 位用户还是 5000 位用户，基本要求都是相同的。

我特别强调的一点是：部署统一消息解决方案时，IT 小组和电信小组必须相互协作。根据我的经验，虽然很多因素都会导致统一消息项目偏离正轨，但如果 IT 小组和电信小组不能协作以及无法在解决方案上达成一致，项目注定会失败。技术的结合并不太困难，但可能需要组织外部既了解 IT 又了解电信的人员的帮助，以使两个小组进行协作或规划成功的项目部署。