示例:Exchange Server 站点合并 - Proseware, Inc.

 

上一次修改主题: 2005-04-29

本主题说明了 Proseware, Inc.(虚构公司)的 Exchange Server 站点合并项目的示例。Proseware, Inc. 在全国五个办事处雇用了 500 多位员工。西雅图公司总部是最大的办事处,拥有 200 多位员工。公司在丹佛、菲尼克斯、洛杉矶和迈阿密有四个使用高带宽连接的区域办事处。

其 Exchange 服务分布如下:

  • 西雅图公司总部有一个 Exchange 5.5 服务器,其上存放着公用文件夹和 200 多个用户的邮箱。
  • 每个区域办事处有一个 Exchange 5.5 服务器,其上存放着公用文件夹和 50 到 100 个用户的邮箱。

每个区域办事处都有专职的 IT 管理员来管理本地服务器。但是,大多数服务器都是由西雅图的 IT 组织来设置和管理的。Proseware, Inc. 计划升级到 Exchange 2003,并在此过程中合并其 Exchange 站点。他们近来已集中了他们的支持和监视操作,并希望对 Exchange 管理也执行同样的操作。此外,用户基础继续增长、邮箱数据和公用文件夹的使用也继续增加,并且 Exchange 服务器快要到达使用期限。

为了解决这些顾虑,Proseware, Inc. 计划建立西雅图数据中心来向所有站点提供 Exchange 服务。Proseware, Inc. 将升级到 Outlook 2003 并使用缓存 Exchange 模式。为了最大限度地实现可用性和可伸缩性,数据中心将利用 Microsoft Windows Server™ 2003 中的群集功能和卷影复制服务备份功能。

尽管通常的建议是在合并站点前切换到 Exchange 纯模式下,但是由于将 Exchange 5.5 服务器升级到 Exchange 2003 的相关成本问题,Proseware, Inc. 决定不采用此方法,而是使用 Exchange 2003 SP1 提供的站点合并工具将 Exchange 数据转移到中心站点,并报废其 Exchange 5.5 服务器。

本主题的剩余部分描述了 Proseware, Inc. 的站点合并过程。

首先,Proseware, Inc. 研究了站点合并工具、问题及需求。他们确定在西雅图数据中心是否有足够的服务器资源来支持所有区域办事处的所有 Exchange 服务。

在他们调查用户电子邮件需求的过程中,他们发现在丹佛区域办事处的工程师经常使用电子邮件传送很大的文件。由于此站点要求能够通过 WAN 来传输较大的文件,因此,将 Exchange 服务器从丹佛站点移到中心站点是不可行的。因此,Proseware, Inc. 决定保留丹佛办事处的 Exchange 服务器。他们将服务器从 Exchange 5.5 升级到 Exchange 2003。

在他们确定要合并的站点后,Proseware, Inc. 创建了站点合并规划,并确定了每个区域办事处的过渡时间。由于复制会导致网络延迟问题,因此他们决定在周末,即网络活动量最低的时间,移动公用文件夹和邮箱。

在开始站点合并进程前,Proseware, Inc. 在西雅图数据中心部署了 Exchange 2003 以确保 Exchange 运行在混合模式下。具体地说,他们使用了 Exchange Server 部署工具中的步骤和工具来部署第一个 Exchange 2003 服务器,并建立了 Exchange 5.5 和 Exchange 2003 的共存。

因为他们想使用缓存 Exchange 模式,所以 Proseware, Inc. 还将所有四个区域办事处的所有客户端计算机升级到 Outlook 2003。他们将打开缓存 Exchange 模式以创建每个用户邮箱的本地副本。通过在移动邮箱前创建本地副本,Proseware, Inc. 避免了在将邮箱移出本地站点后可能出现的下载流量很大的情况。

最后,在他们进行实际的站点合并过程前,Proseware, Inc. 利用测试邮箱运行整个过程。通过测试他们可以验证站点合并过程并收集有关对网络有影响的数据以及复制持续时间。

Proseware, Inc. 开始对菲尼克斯办事处进行站点合并处理,这是第一个要合并的站点。他们根据 Exchange Server 部署工具中所描述的过程执行下列步骤:

  1. Proseware, Inc. 确保将所有 ADC 服务器更新为 Exchange 2003 SP1 版本的 ADC。然后,他们使用 ADCTools 验证是否所有 ADC 连接协议都已正确配置。
  2. Proseware, Inc. 使用 DS/IS 一致性调整程序的修补程序更新全部四个区域办事处的所有 Exchange 5.5 公用文件夹服务器。
  3. 在星期五晚上,Proseware, Inc. 使用 PFMigrate 向西雅图的 Exchange 2003 服务器添加公用文件夹副本。他们允许复制过程持续整个周末。

Proseware, Inc. 确认公用文件夹复制完成后,将继续合并菲尼克斯站点。由于移动邮箱和使用对象重新连接工具可能会导致过长的等待期,因此他们决定在周末运行此阶段。他们使用 Exchange Server 部署工具来执行下列步骤:

  1. Proseware, Inc. 使用移动邮箱向导将邮箱从菲尼克斯移动到中心站点。
  2. Proseware, Inc. 创建了当用户在星期一上午登录时将会运行 Exprofre.exe 的登录脚本。此脚本将更新用户的 Outlook 配置文件,从而使他们反映新的站点。
  3. Proseware, Inc. 再次运行 ADC 工具来验证是否设置了正确的连接协议。他们将确保目录复制已完成。
  4. 他们使用对象重新连接工具来更新在菲尼克斯的自定义收件人和通讯组列表,以反映西雅图站点。
  5. 对象重新连接工具完成后,他们再次运行 ADC 工具来验证是否设置了正确的连接协议。他们将确保目录复制已完成。
  6. 在菲尼克斯的 Exchange 5.5 服务器上,他们运行 DS/IS 一致性调整程序来清理公用文件夹 ACL。

完成阶段 2 后,Proseware, Inc. 将确保所有的 Exchange 数据都显示在西雅图的 Exchange 2003 服务器上。然后,他们将报废菲尼克斯的 Exchange 服务器。他们使用 Exchange Server 部署工具来执行下列步骤:

  1. Proseware, Inc. 运行 PFMigrate 来删除来自菲尼克斯站点的公用文件夹副本。
  2. Proseware, Inc. 使用 ADC 工具来验证是否设置了正确的连接协议。他们将确保公用文件夹复制已完成。
  3. Proseware, Inc. 使用对象重新连接工具来生成报告,从而确保从菲尼克斯的服务器上成功删除通讯组列表和自定义收件人。
  4. Proseware, Inc. 采取下列步骤来删除菲尼克斯区域办公室的 Exchange 5.5 服务器。

在洛杉矶和迈阿密区域办公室,Proseware, Inc. 重复了同样的过程。完成这些步骤以后,Proseware, Inc. 在西雅图有一个存放菲尼克斯、洛杉矶和迈阿密用户的 Exchange 2003 服务器,而在丹佛仅有一个存放本地用户的 Exchange 2003 服务器。最后,由于他们不再运行 Exchange 5.5,于是 Proseware, Inc. 切换到了纯模式。

 
显示: