沟通与协作
规划向统一消息的迁移
Jeff Goodwin
概览：
- 语音邮件简介
- 规划迁移时的注意事项
- 迁移策略
- 多站点的难题
目录
语音邮件简介
规划迁移
实用的迁移策略
迁移演练
遵循规划的重要性
从传统的语音邮件系统迁移到统一消息平台是一个极具挑战性的项目。但通过一些正确的规划，就可以非常轻松地完成该迁移，尽可能减少最终用户可能遇到的中断。事实上，
将服务中断降至最低可能是您在执行此类迁移项目时的首要目标。
要明确迁移过程中需要规划哪些内容，必须首先了解公司将语音邮件视为关键任务应用程序的原因。这一基本信息将有助于您了解在迁移到“统一消息”时需要实现哪些功能以及这些功能对于管理员来说十分重要的原因。
语音邮件简介
不知起点，就不知所终，因此我先简要回顾一下语音邮件系统的起源以及构建方式。谁是第一个发明语音邮件系统的人至今仍存有争议。但是，第一款商用语音邮件系统是 VMX，表示“语音消息交换”(Voice Message Exchange)。
VMX 最初设计用于提供一种通过语音与公司内的其他人员进行交流的方法，就像现在使用的电子邮件一样。该系统包含用于发送消息、转发消息以及回复消息的命令。如果有留言，系统会通知用户。通知的方法有很多种，包括外部呼叫（使用特定电话号码致电用户）和留言灯（用户电话上的指示灯）。
随着 VMX 的逐渐普及，许多组织开始着手实现语音邮件系统的联网。这样就形成了一个企业范围的语音邮件解决方案，员工可通过它向公司通讯组列表发送广播消息。
为了能与语音邮件系统进行交互，按键式用户界面 (TUI) 随即应运而生。这些 TUI 随着时代的变迁而不断变化，但遗憾的是，至今仍没有标准的语音邮件界面。如果手机上有语音邮件，您可能对听到诸如“收取语音邮件请按 1”之类的提示习以为常了。但随着使用语音用户界面 (VUI) 的话音驱动语音邮件系统的逐渐普及，TUI 本身的重要性已不比从前。可是，不应低估用户可能对某个特定界面产生的依恋。
现在使用的企业语音邮件系统依赖于两种截然不同的体系结构：分布式和集中式。在图 1 中，西雅图、纽约和奥斯汀的办事处都使用分布式语音邮件体系结构，即每个站点都有语音邮件系统。相反地，伦敦、巴黎和格拉斯哥的办事处使用的是集中式模式，即 PBX 基础结构是联网在一起的，并且所有呼叫都会路由回位于伦敦的中心位置。两种模式都各有优缺点。但请注意，即使在分布式模式中，语音邮件系统也可联网在一起以实现站点之间的消息传递。
图 1 两种常见的语音邮件体系结构模式（单击此图像可查看大图）
组织选择使用分布式模式可能主要有以下三个原因：本地使用需要、各种不同的 PBX 系统无法联网、以及统一拨号计划限制。
一些组织对语音邮件系统的要求是：网络出现故障时，本地 PBX 和语音邮件系统仍可正常运行，确保站点保持完整的系统功能。交互式语音响应 (IVR) 系统仍可正常运行，同时外部的呼叫者仍可留言。最终用户实际不受任何影响，工作可照常进行。听起来可能有些耳熟 – 许多组织选择本地运行 Microsoft® Exchange Server 执行服务器也是出于相同的原因。组织可能希望通过风险评估来确定这种策略的必要性。
当组织由于收购而逐渐壮大时，远程站点的一些 PBX 平台常常无法与基础结构的其余部分联网。此时，组织可更换掉该 PBX，但这样成本极高；或保持这些站点不动并联网语音邮件系统以提供无缝的语音消息交换。第三方服务器也可帮助您联网完全不同的语音邮件系统。
要联网多个 PBX，需要一个统一拨号计划（即 UDP）。UDP 规定电话和语音邮件分机不能重叠。在图 1 中，您会发现西雅图、纽约和奥斯汀有重叠的分机号。这是因为美国的站点没有启用 UDP。可通过将分机范围扩大到 7 或 10 位来创建 UDP，但此操作会带来其他问题。
您可能必须更改每部电话上的拨号模板、更改 PBX 上的所有用户分机以及更改与该系统集成的所有应用程序。并且，它可能致使员工产生用户挫折感，因为他们现在必须记住并拨打 7 或 10 位的电话号码才能与楼下的某人通话。
尽管多年来一直在改进这些基本功能和体系结构难题，但语音邮件的本质依旧未变。消息交换、联网、通知方法、用户界面和体系结构都是您在规划迁移时必须牢记的重要因素。
规划迁移
“统一消息”更改了组织的方方面面 – 从用户与语音邮件的交互方式，到体系结构的设计方法，再到管理员的管理方式。在向统一消息系统迁移时，必须消除所有这些差异。下面这个检查表列出了在规划迁移时需考虑的事项。
消息联网 从传统语音邮件平台转换到“Exchange 统一消息”的所有组织都必须有一个共存期。如果组织已部署消息联网（一个互操作不同语音邮件系统的系统），只需将“统一消息”系统添加到现有系统列表即可。对于在多个位置使用单独的语音邮件或 PBX 系统的组织，强烈建议部署消息联网。
基础结构 设计“统一消息”的基础结构需要您决定联网要求、电话集成、服务器安置等问题。如果还不了解基本的部署策略，请阅读本人先前撰写的文章“使用 Exchange Server 2007 部署统一消息”（网址为 technet.microsoft.com/magazine/cc137737）。
自动助理 许多系统都包含多个自动助理，不同的助理适用于白天、夜间以及不同的部门。您需要与组织的电信小组协同工作以镜像传统语音邮件系统上的自动助理。
消息等待指示 您可能希望解决方案不需要消息等候指示器，但您的用户可能需要该功能。因此，千万不要低估用户对该红色指示灯通知的依赖程度。幸运地是，许多公司都开发了适用于 Exchange Server 的消息指示器应用程序。
传真支持 很多传统语音邮件平台都支持入站传真。Exchange 统一消息也支持入站传真功能，因此您可能希望在新部署中规划支持该功能。
交互式语音响应 某些传统语音邮件平台支持 Exchange 统一消息无法复制的交互式语音响应 (IVR) 应用程序。您可能希望在找到合适的替代方案之前先保留这些系统。
管理 Exchange 统一消息依赖于 Active Directory® 和 Exchange 邮箱服务器角色。您需要规划统一消息部署对管理、系统要求等的影响。
用户界面 在实施新 UI 时，必须对用户进行培训。Exchange 统一消息使用的界面与大多数手机界面极为相似，因此对于大多数用户而言它非常直观。它还使用语音识别，因此用户无需再使用按键。在 Exchange Server 中，此功能称为 Outlook® Voice Access。
培训 统一消息带来了用户沟通和使用语音邮件方式方面的模式转变。除 UI 外，还必须向用户提供培训，以教授最佳实践并展示更加有效的新沟通方法。例如，用户可能并不了解如何与收件箱中的语音邮件交互或者如何配置某些高级的统一消息设置。
实用的迁移策略
在将大型组织迁移到统一消息解决方案的过程中会遇到很多难题，这一点毋庸置疑。然而，在 10 年的统一通信从业过程中，我曾遇到过具有极为特殊要求的最复杂组织成功实现迁移的案例。
无论是单站点或是多站点组织，只要围绕以下五个基本步骤构建迁移策略，都会有所帮助。
- 规划和设计解决方案。
- 安装和配置统一消息服务器角色。
- 迁移试验组。
- 根据试验组的反馈修订设计。
- 迁移用户。
当然，多站点组织确实会面对在单站点情形中通常不会遇到的一些难题。我将在“多站点的难题”侧栏中单独介绍这些难题。
在迁移过程中，规划和设计解决方案是最为重要的步骤。建议为此项目分配一个“统一消息”团队。此团队应包括来自组织的各个部门且具有电信、Active Directory、Exchange、联网、安全、培训和项目管理专业知识的代表。然后，绘制一张公司现有的 PBX、语音邮件和电子邮件基础结构的详细体系结构图。
完成设计后即可安装和配置统一消息服务器角色。统一消息服务器可与现有的传统语音邮件系统并行安装。只需确保遵循所记录的最佳实践即可。
此时，您已准备好试用统一消息服务器。指定一个小型试验用户组，并将其迁移到新系统。组中包含 25 到 50 名用户即可。慎重地选择这些用户，从而创建一个由各种用户（IT 和电信员工、部门经理和销售人员）构成的试验组。通过包括如此众多的人员，可更好地确定设计是否切合目标、需考虑哪些特殊要求以及必须向用户提供哪些培训等。
收到试验组的反馈后，需修改设计以解决在测试过程中发现的所有问题。更具体地讲，重新审查我在“注意事项”中介绍的各个项目，并确保已针对您的组织适当地解决了这些要点。请注意，这里所做的最常见更改通常是为了培训。
最后一步是迁移用户。将系统迁移到整个生产环境中有多种方法和策略。其中两种主要方法是逐步迁移和快速切换。
如果选择在数周或数月时间内逐步迁移用户社区，需在原有用户和统一消息用户之间创建语音邮件岛。从而阻止用户通过语音邮件彼此转发消息。如果设计并不包括消息联网解决方案，则某些业务通信会中断。如果打算使用此方法，建议务必在初始设计中包括一个消息联网解决方案。
快速切换迁移是一次性移走所有用户。通常，组织会在周末执行此类迁移，这样他们就有足够的时间测试系统、进行配置更改并在遇到严重阻碍时撤销迁移。
无论您选择哪种方法，都务必要针对常见问题和从实验组中收集的答案对技术支持人员进行培训。还应确保技术支持人员精通于执行关键任务，包括启用用户、验证某个用户是否已启用以及更改密码。
迁移演练
在执行示例迁移的过程中，应牢记成功迁移到统一消息的主要目标是将用户的语音邮件箱从传统的语音邮件平台移到统一消息中，并且尽可能少地中断内外部用户。
图 2 详细说明了一家组织的体系结构。它不想更改这一混合 Exchange 体系结构。位于美国的多家办事处使用西雅图的主数据中心。奥斯汀的所有 IT 应用程序均由西雅图提供服务，而纽约办事处则保证本地的 Exchange 服务。美国区域内的语音邮件都利用完全不同的 PBX 基础结构进行分发。从技术上讲，无法联网 PBX 基础结构以提供集中式语音邮件。与之相反的是，欧洲的办事处则使用位于伦敦的集中式数据中心。欧洲的所有 IT 和电信应用程序都由该中心数据中心提供服务。
图 2 迁移前的示例体系结构（单击此图像可查看大图）
整个语音邮件的基础结构基于 Octel（现在称为 Avaya）平台。使用 Octel 模拟联网 (OAN) 实现所有语音邮件系统的联网，Octel 模拟联网 (OAN) 是一种专有联网协议，利用模拟电话线和长途电话来发送联网的语音邮件消息。该体系结构允许在站点之间传递公司内的语音消息。
多站点的难题
多站点组织在部署统一消息时会面对多种难题。幸运地是，可从其他组织已遇到的难题中了解到一些有用的信息。我无法在本文中罗列出所有的难题，但我可以将自己在与各种组织打交道时遇到的最常见问题介绍给您。
“我使用的是集中式 Exchange Server 体系结构和混合式电话环境。”
分布式环境比较容易设计。将统一消息服务器放在每个站点上，并将其与本地 PBX 集成。但如果使用集中式甚至是混合式环境时呢？您需要确定是否要在站点上本地留存统一消息。如在本地留存统一消息，该区域可能无法与集中式 Exchange 服务器相连，但仍提供自动助理功能且允许外部呼叫者（极有可能是客户）留言。具体方法取决于该区域中任务的重要性以及解决方案的可管理程度。
如果需要站点具备本地留存特性，在站点上安装远程统一消息服务器将是一个不错的选择。如果不需要，则可在本地站点上安装一个 SIP 网关。Exchange 统一消息非常灵活，因而并不需要联网 PBX 基础结构，也不需要统一拨号计划。
“我正在升级 Exchange 体系结构。”
许多客户正在升级 Exchange 体系结构，因而非常犹豫是否应开始“统一消息”迁移。我的建议是如果您已决定使用统一消息，那么应在升级 Exchange 服务器的同时执行迁移。只需履行您的升级计划即可，它应该不会增加此项目的复杂程度。
“我有很多不到 10 个人的小型站点，并且其中有些站点没有 PBX。”
对于现场有 PBX 的小型站点，只需在本地站点上安装 SIP 网关即可。对于现场没有 PBX 的站点，可使用电话技术将电话转发给中央 PBX 以将呼叫路由给统一消息系统。简而言之，可以用相当低的成本将统一消息服务部署到组织的小型远程站点中。
值得注意的一点是，这些小型站点实际上提供了一个极好的迁移测试平台。一个常用的迁移策略是从网络的边缘开始迁移，然后转移到核心。首先迁移小型站点，然后与统一消息团队进行总结以了解哪些方面进展顺利，同时遇到了哪些难题。然后在迁移下一个站点时吸取这些学到的经验。
统一消息团队决定从网络的边缘开始迁移到核心。对于所有区域，统一消息服务器的放置都将遵循以下 Exchange 服务器体系结构。团队为每个站点构建自己的规划文档，并且牢记在“注意事项”部分中介绍过的事项。在安装和配置服务器的过程中、用户培训过程中以及规划迁移策略时都会用到该文档。
对于每个站点，团队计划将用户快速切换到统一消息系统，同时保留传统平台以支持在找到替代解决方案之前仍会使用的 IVR 应用程序。团队决定在迁移后先等待 30 天再继续迁移下一位置。这一等待期旨在确保在移动更多用户和添加更多技术支持电话之前每个站点都已适应新平台。
组织决定首先迁移奥斯汀办事处。由于奥斯汀是由西雅图提供电子邮件服务，团队在西雅图安装统一消息服务器角色，并通过在奥斯汀安装 SIP 网关来提供 PBX 集成。由于传统语音邮件平台是联网的，团队必须通过安装消息联网服务器来解决统一消息平台的联网需求。 用户已接受新系统培训并且迁移非常顺利，因此团队决定接下来迁移纽约。
纽约办事处拥有自己的邮箱服务器和集线器传输服务器。因此，最佳实践应该是将统一消息服务器安装在纽约。团队遵循迁移规划文档安装该服务器。把该服务器添加到消息联网服务器内的节点列表内，该服务器位于语音邮件网络中。用户已接受培训且顺利地迁移到统一消息。
西雅图办事处已拥有在奥斯汀迁移阶段中所部署的统一消息服务器。团队确定该服务器的语音邮件端口足以支持西雅图和奥斯汀办事处。西雅图的用户已接受培训且迁移到统一消息。
欧洲的体系结构设计起来则要简单得多。PBX 基础结构已联网且 Exchange 为集中式。在伦敦部署统一消息服务器，然后从最小的站点开始迁移各个站点。图 3 说明了最终的体系结构。
图 3 迁移后的示例体系结构（单击此图像可查看大图）
遵循规划的重要性
我应邀解决了很多失败的统一消息迁移。许多组织都违反了一个或多个关键规则。
首先，应始终牢记它并不仅仅是一个语音邮件系统。它是一个关键任务应用程序，具备对应的特点。用户们依靠语音邮件技术来交换信息。请记住它是一个业务应用程序，迁移规划要考虑到我在本文中介绍过的所有注意事项。
向统一消息执行任何迁移均必须有电信团队的参与。电信团队最了解集成到公司基础结构中的电话应用程序。
在向统一消息迁移时，请制定企业解决方案规划。一开始可能只完成了单个站点迁移，但应始终在头脑中保持一个整体概念。例如，完成单个站点迁移却不向其他站点提供消息联网将会影响用户之间的通信。当然，它可能是一项艰巨的任务，所以请尽量向专家咨询，这样才能设计出考虑了所有 IT 应用程序的体系结构。
最后，切勿低估培训的重要性。统一消息转变了用户与语音邮件沟通和交互的模式。某些您看起来很明显的东西，对其他人却不一定显而易见。良好的培训是实现最顺利转换的关键所在。
Jeff Goodwin 是 VIA 组的高级技术专家，擅长 Exchange 和统一消息设计和部署。您可以通过 jgoodwin@theviagroup.com 与他联系。
© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利；未经允许不得复制本文的部分或全部内容。