Post Mortem从 Exchange 5.5 迁移
Whitney Roberts
项目
肯塔基州教育局需要将其现有的 Microsoft® Exchange Server 5.5 实现迁移到 Exchange Server 2003。其系统在每个学年大约要为 600,000 名教职员工和学生提供支持。
参与方
此项目由肯塔基州教育局的“教育技术办公室”(OET) 负责，KiZAN Technologies 的顾问给予协助。OET 工作人员一直在对现有 Exchange 5.5 实现进行管理监督。Exchange 服务器的日常运行则由该学区的本地工作人员负责。
面临的难题
该教育局为肯塔基州全部 178 个学区提供技术指导。这些学区彼此通过 WAN 相连接，但每个学区都托管其自己的本地受管 Exchange 5.5 服务器，这些服务器需要分别升级。经过这次升级，系统应支持 Outlook® 2003 缓存模式客户机、改进的 Outlook Web Access (OWA) 体验、标准化的电子邮件寻址方案等等。
除了部署新的电子邮件服务器和客户机基础结构外，许多学区要增加对学生电子邮件的支持功能。州和联邦都有政策要求对学生信息加以保护，不允许将这些信息提供给各自学区外的其他学区。
计划
由于不能使用 Active Directory® Connector (ADC)，我们创建了一个新的 Exchange 组织并迁移到其中。实现电子邮件地址标准化就意味着要为各学区创建新的标识子域以及 400 多个新的收件人策略。要保护学生地址，需要构建由“全局地址列表”(GAL) 和各学区自定义地址列表组成的体系。
实际的迁移过程包括搭建新硬件、根据学区成员身份和用户类型创建并配置邮箱，以及根据学区成员身份和用户类型设置扩展属性，使用户出现在相应的地址列表中。
我们创建了一个基于 Visual Basic® 的应用程序，用以检测和更正配置不当的帐户属性或组成员身份，并正确置备新邮箱以确保维持可见性需求。此应用程序已部署到全部 178 个学区并正在学区的服务器上定期运行。
背景
表面上看，这似乎并不是一项很复杂或技术难度很高的工作。但有人曾善意地提醒过我，业务需求决定一切，而这个项目的业务需求真的是令人瞠目结舌。
多年来，分散式的管理和纷繁混杂的各种标准造成了众多的支持“真空区”，这些“真空区”常常需要由 OET 来进行管理。此外，OET 还必须确保 Exchange 5.5 实现能同时满足学区和教育局的需求。也就是说，对于引入了学生电子邮件的学区，要按州和联邦指导方针（请参见 ed.gov/policy/gen/guid/fpco/ferpa/index.html）的规定来保护学生信息，不允许将这些信息提供给各自学区外的其他学区。
在 Exchange 5.5 中，这些指导方针意味着学区内的学生信息不能复制到共享 GAL 数据的其他学区或其他州管理机构。具体来说，这就需要全部 178 个 Exchange 5.5 站点都经历一个手动的导出/导入过程：即隐藏学生，复制列表，取消隐藏学生，最后导回地址列表。通过这种方式，其他学区只能看到教工数据。本学区可以看到自己的所有数据，但只能看到其他学区的教工数据。
考虑到现有系统的优缺点，消息基础结构的升级必须满足一些具体的条件。首先，肯塔基州教育局需要在一个可读的公用 SMTP 命名方案基础上、在整个企业范围内实现标准化。这一方案需要为教工和学生提供独立的 SMTP 地址空间。
新系统还需要提供一种集中管理的服务，使学区从消息管理与可用性职责中解脱出来。也就是说，灾难恢复、邮件流和支持人员呼叫解决方案都将采用集中式的管理。这样一来，新系统就必须提供一种集中式的方法来跨所有学区实现用户配置的标准化，而无论给定用户的地理位置或学区关系如何。
此外，新系统还必须跨一个公用的统一命名空间针对所有学区提供基于 Web 和移动设备的安全电子邮件访问。
鉴于这些需求（其中许多需求在现有的 Exchange 5.5 系统中尚未实现），Exchange 2003 的升级工作真的令人望而却步。
解决方案组块
为了满足这些业务需求，我们确定了几种专门针对 Exchange 的部署方案。
由于缺乏标准化以及 Exchange 5.5 环境容量巨大，因而不能使用 ADC。因此，我们转而创建了一个新的 Exchange 组织并迁移到其中。
为了清理各学区教工和学生的电子邮件地址并实现标准化，我们创建了 400 多个新的收件人策略。此外，还根据需求为各学区建立了一个唯一的标识子域，其中包括学生的标识学区标志。例如，就 Shelby 县而言，主要子域为 shelby.kyschools.us。各学区的学生都有一个 stu. 子域标志，因此 Shelby 县学生的电子邮件地址为 stu.shelby.kyschools.us。
另一个限制条件是学生地址只能供其所在学区使用，而教工地址可跨学区使用。这意味着要构建由 GAL 和自定义地址列表组成的一套完善体系，如图 1 和图 2 中所示。迁移到 Exchange 2003 的一个好处是可以通过权限来保证地址列表的安全，通过组成员身份来控制对各地址列表的访问。我们很好地利用了这一特点，创建了两个学区级安全组（一个用于教工，一个用于学生），并为学区教工和学生 GAL 及地址列表制定了相应的安全措施，只允许特定学区内的用户帐户访问某些地址列表。删除默认 GAL 和地址列表并确保“每个人”和“通过身份验证的用户”组不在各地址列表的访问控制列表 (ACL) 中出现后，我们可以预先选择特定学区中特定用户类型能够查看的地址列表。
图 1** 基于角色的自定义地址列表 **(单击该图像获得较大视图)
然而，权限只是部分地解决了可见性问题。我们必须提供一种方法来控制在不同地址列表中哪些内容是可见的。为此，我们创建了一个基本“轻量目录访问协议”(LDAP) 查询，用以查询教工和学生的可见性；然后针对各地址列表和 GAL 对该查询稍加定制。例如，针对 Shelby 教工 GAL 的 LDAP 查询将只显示 Shelby 学区相应的教工和学生以及本州各其他学区的所有教工（但不包括学生）。而针对 Shelby 学生 GAL 的 LDAP 查询将只显示 Shelby 学区的教工和学生，并不显示本州任何其他学区的其他教工和学生。我们为该组织中的所有学区重复使用这一查询。图 3 显示了在这次复杂的迁移中所使用的一些 LDAP 查询示例。
Figure 3 地址列表 LDAP 查询
教工 GAL LDAP 查询
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
学区地址列表 LDAP 查询
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
学区学生地址列表 LDAP 查询
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
学区教工脱机地址列表 LDAP 查询
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
图 2** 将教工与学生相隔离的全局地址列表 **(单击该图像获得较大视图)
Exchange 用户属性 extensionAttribute14（自定义属性 14）和 extensionAttribute15（自定义属性 15）的自定义值是 LDAP 查询背后的区分机制。对于全州的所有教工和学生而言，其 extensionAttribute14 属性包含用于指定用户类型的特定值，extensionAttribute15 属性包含用于显示学区关系的唯一值。各学区都有唯一的学区标识值，每个用户类型又对应相同的值，这样，地址列表就可以准确地显示各学区各用户类型的所需信息。
当用户通过非缓存模式下的 Outlook 或通过 OWA 访问电子邮件时，这些地址列表的效果非常好。（我们使用 msExchQueryBaseDN 属性将各用户引向 OWA 中的正确地址列表。）但在缓存模式下运行 Outlook 的用户却面临着另外一个问题。由于 Outlook 不会将自定义的 GAL 视为指定的“脱机通讯簿”(OAB)，我们不得不创建了与 GAL 一样的附加地址列表。然后对各学区邮箱存储进行配置，使缓存模式用户使用相应的 OAB 地址列表。总而言之，这一解决方案创建了 1,500 多个地址列表，来为全部 178 个学区各种类型的用户提供完整的功能。
确保遵从性
为确保已经实现的结构能够正常工作，首要的一点是遵从新建立的各项标准。对于组织中每个启用了 Exchange 的用户，必须执行一些高级别的任务。这是因为必须要跨所有学区的 Exchange 服务器对每个用户正确定位，每个用户的信息也必须出现在正确的地址列表中。
用户必须是学区域内适当安全组的成员，因为安全组负责授予权限来打开相应地址列表。此外，还必须根据学区和组织单位 (OU) 成员身份正确设置用户的 msExchQuerybaseDN 属性。用户的 OU 决定了用户类型。
下一步是根据学区成员身份和用户类型在适当服务器上的正确存储库中建立用户邮箱。这一工作影响着服务级别、邮箱大小限制及脱机通讯簿地址列表，这样一来 Outlook 缓存模式就能够正常工作了。扩展属性基于学区成员身份和用户类型而设置，这样用户可以显示在适当的地址列表中，而在其他列表中则不出现。
最后，我们需要提供一种更正方法。如果有任何帐户的属性或组成员身份被误配置（或更改）为不适当值，这一方法可以自动进行更正。如果用户在学区的域内从一个 OU 转移到另一个，这意味着用户分类发生了变化，必须更新邮箱位置、GAL 选择及地址列表可见性。
我们需要一种置备系统，用来完成这些任务并确保 Active Directory 的一致性和精确性。于是，我们基于 Visual Basic 创建了一个基于控制台的应用程序，可以从学区 Exchange 2003 服务器上定期运行该应用程序，来检查对策略和标准的遵从性并处理新对象的创建和置备，我们将该程序部署到全部 178 个学区。
我们觉得当前的任务过于复杂，很难通过一系列脚本快速可靠地执行。因此，鉴于该基于 Visual Basic 的应用程序效率较高，具有结构化的错误和异常处理支持，而且其内部代码只需最小量的重新编写工作即可轻松适应于将来的 Microsoft Identity Integration Server (MIIS) 扩展代码，因此可视为适合于上述问题的解决方案。
我们要迁移到新组织，所以必须找到一些共存方法。新环境要支持超过 178 个遗留 SMTP 域（有些学区先前有学生电子邮件域，有些则没有），但我们奢侈地逐个迁移每个学区并将其遗留邮件和地址传递到新系统中，而不影响其他学区。然而，我们需要避免学区在从 Exchange 5.5 迁移到 Exchange 2003 时出现电子邮件流中断。这意味着要在 Exchange 2003 Active Directory 和遗留 Exchange 5.5 目录之间实现某种类型的目录同步。Microsoft 在迁移期间只授予肯塔基州教育局有限的 MIIS 使用权限，于是我们开发出了自定义的扩展代码，用来在迁移前、迁移期间和迁移后通过 MIIS 实现两个 Exchange 组织的同步。
移动到新的 Exchange 组织自然就会影响 MAPI 客户机配置。教育局面临这样一个事实：迁移期间在学区级差不多有上万个 MAPI 配置文件必须重新配置。幸运的是，Microsoft 发布了 Exchange Profile Tool (ExProfRe.exe)，学区一级配置文件的迁移就是通过这个工具实现的。我们创建了一个打包的安装程序，它以预加载的值运行 ExProfRe.exe，使学区级配置文件的迁移可以自动执行。该程序通过“组策略”调用。我们这项组织间配置文件自动迁移工作的成功率接近百分之百。
硬件升级
由于新的 Exchange 2003 服务器将取代分散在各地的 Exchange 5.5 服务器，所以从硬件方面来说，此解决方案必须与 Exchange 5.5 部署支持相同数目的用户，再加上新增的学生帐户。服务器必须由学区当地托管，因为根据 WAN 拓扑结构的设计，所有学区间流量（Internet 和内部）都通过一条专用 T1 线路（某些学区中为多条 T1 线路）流过。
由于在预算、管理及设备托管等方面的限制，Exchange 服务器不能有通过存储区域网络 (SAN) 附加的存储器，因此所有存储器必须是内部存储器或直接附加的存储器。因为多数学区没有带机架存储器和中央冷却设备的数据中心，所以服务器必须尽可能自给自足。幸而对于多数学区而言，其用户数少于 5,000，因此可以实现单服务器部署。用户较多的学区使用了更为强大的服务器（或多个服务器）及额外的存储器，有的还配有单独的前端服务器，进一步将学生与教工的流量相隔离。
在大多数学区中，我们部署了装备精良的双处理器服务器，这些服务器配置了最大数目的 15,000 RPM Ultra320 SCSI 驱动器、多个 RAID 控制器及 4GB RAM。更大的学区部署了一个或多个四处理器服务器，根据需要使用了更小的前端服务器。部署前的基准和性能测试结果表示系统不存在使用率或负载问题。而不同程度的本地使用模式将是服务器整体性能的真正决定因素。
概念证明测试
尽管此生产环境包括一个由 178 个域组成的 Active Directory 林，但概念证明 (POC) 实验室将这一环境缩减到 13 个学区域和一个空的根域。所有测试域都由从生产域导出的数据填充。虚拟 Exchange 5.5 服务器基于所选学区数据库的副本进行构建和配置，以便我们能够在计划环境之外测试迁移过程并进行构建。整个 POC 测试实验室由虚拟机构建，所以环境可以基线化、冻结，也可以根据需要重新部署。
我们设计、编码、测试并最终确定了各种脚本（使用 VBScript）、Systems Management Server (SMS) 安装程序包和控制台应用程序。最后，我们确定了执行初始 Exchange 2003 安装和配置（包括收件人策略、GAL 和自定义地址列表及权限）的脚本。此外，还通过脚本来处理迁移中所涉及的管理组配置、学区域配置（安全组创建和权限委派）及部署后配置。
Exchange 2003 服务器的搭建工作遇到了一些重大的难题。我们需要在所有 178 个域中成功地安装全部 Exchange 服务器，而且在安装时不能危及迁移工作的其他部分。Exchange 2003 不同于 Exchange 2000 的一点是，直到域中安装第一个 Exchange 2003 服务器后，特定于域的 Exchange Domain Servers 组才会添加到组织的 ACL 中。（而在 Exchange 2000 中，该组是在运行 DomainPrep 进程时添加的。）为确保 Active Directory 的组织对象中能列出所有必要的安全组，我们不得不先在一个给定域中安装，然后手动将 Active Directory 从该域复制到 Active Directory 复制中心站点，再将该复制拖动到要安装的下一学区。只有在确认组织对象上的 ACL 拥有来自前一学区的 Exchange Domain Servers 组后，才能安全地开始下一学区的安装工作。即使这一过程只在一个域中没有按正常顺序完成，该学区也都至少必须进行重新安装，否则其他学区将不能进行学区间通信，这是因为组织对象 ACL 不能正确列出所有其他学区。
我们对整个部署、配置、服务器搭建和迁移进行了多次测试，直至我们确信这一过程在 POC 环境中运行良好。
迁移与不断出现的难题
项目团队批准了这些 POC 过程和结果后，即准备开始进行迁移。OET 选择首先进行自身的迁移，这样他们可以亲身体验这一过程及之后的效果。迁移时，所有服务器均已搭建，初始环境已经验证完毕。所有前端协议服务器和邮箱服务器均已就绪，准备投入生产供用户使用。
我们的这一迁移计划执行得相当顺利，经过 21 小时服务器间的内容传输后，OET 在 Exchange 2003 上启动并正常运行。很幸运，Outlook 配置文件在从 Exchange 5.5 迁移到 Exchange 2003 时没有出现重大的问题。我们加入了一个批处理文件，它根据一些简单的逻辑来以不同的配置调用 ExProfRe.exe。然后，我们将该批处理文件和 ExProfRe.exe 发布到各学区中域控制器 (DC) 的 Netlogon 共享区，并使用“组策略”在迁移结束时针对所有客户机运行该批处理文件。这一过程在 OET 运行良好，我们确信在后面的迁移过程中也会成功实现。
此时，相关人员又根据 OET 部署的体验对迁移计划重新进行了审核和批准。在接下来的迁移中，我们选择六个学区作为首批生产站点。在各学区进行迁移前，MIIS 从 Exchange 5.5 中读取有关学区邮箱的最新信息并更新学区域中的相应用户。我们使用“Exchange 迁移向导”(Mailmig.exe) 来实际地在组织之间转移邮箱数据。在向导转移邮箱数据时，所有代理地址会从 MIIS 最初所导出的部分移动并更新到 Active Directory 中。在迁移期间，邮件在前端 SMTP 服务器上排队，然后在迁移、迁移后服务器配置和用户测试完成后发布给学区；学区准备使用 ExProfRe.exe 来执行大规模的客户端迁移。
赢得 RUS
为使 Outlook 客户端正常工作，我们需要确保置备解决方案在设置属性值方面具有绝对的权威性。我们也需要“收件人更新服务”(RUS) 来完成帐户设置工作；但 RUS 只应在置备完成后运行。为此，学区（所有 178 个学区）的 RUS 实例设置为“永不”根据其时间表运行，而置备解决方案使用了用于在置备完成后触发 RUS 的代码。
对于大多数学区而言，其用户数少于 5,000，而日常的更新量更是少之又少，再加上置备系统会在日常运行结束后触发更新工作（而不是重建），因此 RUS 很快就完成了。但有些学区的用户数超过了 10,000。在这样的环境中进行更新要费时得多，如果需要在这些大型的域中完全重建 RUS，可能要花费一周甚至更长的时间。由于 RUS 在运行时会评估所有对象类型，因此在这类大型域中进行重建将是一个极其漫长的过程。
虽然我们无法提出一个迁移策略（我们曾与 Exchange 产品小组的成员一起研究，试图提出一个解决方案），但我们增强了置备代码，使它可以处理许多通常由 RUS 执行的工作。一旦初始置备结束，就会填充用户的 showInAddressBook 和 proxyAddresses 属性，使用户无需等待 RUS 完成其工作即可立即登录。我们还创建了在其中一个前端 Exchange 2003 协议服务器上运行的手动任务。它定期执行 LDIFDE 导入并清除 RUS 网关代理地址，这样一来，如果某个收件人策略在环境中只是偶然被应用，它就不会被放入企业每个 RUS 的任务列表中。
分类程序问题
就避免学生数据泄露到学区外而言，一个令人关注的方面是通过实施控制来防止学生向本学区外的用户或者本系统外的 Internet 地址发送电子邮件。我们没有采用由连接器和相关项组成的完善系统，而是决定实现 Exchange 2003 一个鲜为人知的功能，并对学区与前端协议服务器所在中央集线器之间的现有“路由组连接器”施以连接器限制。在每个域中创建两个安全组（一个用于教工，一个用于学生），并将这些组添加到连接器限制中。
在注册表中启用连接器限制检查功能后，我们开始注意到一些显著的性能下降问题。各种邮件会在分类程序和本地传送队列中阻塞数小时，即使是要发送给同一服务器上收件人的邮件也是如此。随着时间的推移，当越来越多的学区完成迁移时，这些问题越来越严重。作为一个短期的解决方案，我们关闭了连接器限制检查功能，结果邮件传送的性能有所提高。进一步的检查表明，分类程序不仅会在邮件提交后检查自身域中两个组的组成员身份，而且还会检查其他 177 个域中相同两个组的组成员身份。对于进出服务器的每封邮件都是如此。
我们随后与 Microsoft 启动了一个支持案例。Microsoft 在进行评估后，目前正在生成一个修补程序，希望通过允许分类程序在拓扑结构复杂性更低的模式下工作，来缓解这一问题。直至发稿时，我们尚未得到有关修补程序的进一步信息，但这一程序的宗旨是提供一种设置，来允许分类程序对路由拓扑结构进行某些假设，从而不会跨所有连接器来检查组成员身份。
经验教训
如果说通过这个项目我学到一些经验教训的话，那就是对我们这些技术顾问而言，业务需求决定一切。很多时候，我们必须在业务需求的可行性和解决方案的复杂性之间进行权衡。我在本栏目中介绍的各种决策和选择都是我们认为最适合于我们的特定环境（包括我没来得及在此讨论的要素）、资源及业务需求的决策和选择。对于您而言，可能有不同的决策，但希望本栏目能给您一些启示。幸而对于我们，Exchange 2003 和 Active Directory 提供了足够的灵活性来满足这次复杂的迁移工作的所有需求。一旦解决了肯塔基州教育局部署项目最为棘手的规模问题，实际的解决方案就相当简单了，它基于 Active Directory 和 Exchange 2003 中我认为未被充分利用的功能而构建。
第二个宝贵的经验教训是，采用一种平稳的方法来实施故障排除和风险/问题管理。有时候应当在本地实施故障排除，而有时候则需要求助于 Microsoft 产品支持服务的高级资源。
展望未来
肯塔基州教育局的环境的确是独一无二的。在这次的部署过程中，我们几乎利用或定制了 Exchange 中的每项功能来满足其需求。目前整个环境已部署和迁移成功，进入实现附加功能的阶段。教育局已经看到 Windows Mobile® 平台对于学区所能带来的益处，并希望继续发展移动设备。
通过服务器合并可以获得巨大的价值。肯塔基州教育局当前正在考虑将 Active Directory 环境的某些方面虚拟化。随着 Exchange 2007 的即将推出，教育局已经开始考虑其消息系统的升级需求。
肯塔基州教育局也在考虑引入 Live Communication Server、Live Meeting Server 等工具中其他的协作功能。Microsoft Operations Manager 2005 当前也正在部署之中，准备用它来管理并监控 Exchange 和 Active Directory 服务器。
结果
这次实现的质量和普及率将影响肯塔基州公立学校体系中的每个孩子，包括我自己的孩子和这个项目中我同事的孩子。这次实现通过各种技术使肯塔基州教育局以前所未有的速度、以安全和标准化的方式获得了长足的发展。能参与这次的项目，我深感荣幸。
Whitney Roberts 是 KiZAN Technologies (www.kizan.com) 的首席顾问，从 Exchange 4.0 版起就一直在致力于 Exchange 方面的工作。
© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.