使用ADMT v3.0 域迁移-4
详细信息，请访问以下 URL：
www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/msa
/default.asp
迁移准备规划
开始迁移之前，需要确保实际迁移期间所需要的人员、过程和技术都已就位。
合并和迁移项目的执行规划
在项目规划中，要确保即将使用的资源（不论是硬件、软件、人员还是网络带宽）在计划中的迁移项目启动后能够到位。在前期创建初始计划时考虑了这些因素后，应该检查各项业务条件是否已随着项目的进展发生了变化。
在迁移期间检查支持工作是否就绪
在迁移期间，需要确保相应的支持人员能随时做出响应。这包括各种支持人员。支持人员必须熟悉各自的职责，并且一旦发生相关的迁移问题应该知道向迁移团队的哪个成员反映问题。根据具体的支持服务结构，您可以建立一个迁移问题服务台，并且告诉用户，如果在收到用户帐户或工作站正在迁移的通知后出现了连接问题，可以拨打这个号码。如果选择了合并域，支持人员应该知道哪些用户必须登录不同的域以及哪些帐户名称已因为名称冲突而被更改。
如果作为迁移选项之一选择了域合并，则您可能要重新分配职责。例如，各个站点、域或组织单位中哪些人有权重置密码，以及谁有权为文件共享和打印机分配权限等等。不论是否选择了对域进行合并，都必须培训支持人员，让他们学习新的操作步骤和工具，因为它们与 Windows NT 4.0 已经大不相同。迁移之前，您可能还希望对他们进行自定义工具（比如taskpads）或第三方实用工具方面的培训。
审查和精炼问题跟踪流程
对迁移期间及迁移之后发生的任何问题都应该记录在案并且保持跟踪，直到问题解决。您应该对现有的问题记录和解决流程进行审查，确定它是否适用于新环境。如果不适用，则应安排针对新流程和可能用到的新工具的培训。
跟踪迁移问题的职责应分配给具体人员。所有网络支持人员都必须了解负责记录问题和负责解决问题的人员，以及谁将负责审查问题，确保问题得到及时解决。一旦解决了问题，应该将这些信息记录备案，并且将其提供给所有支持人员，以便处理将来发生的类似问题。
用于迁移的工具
域的重建所涉及的任务范围很广，从日常的简单任务到复杂任务，无所不包，具体要取决于域帐户的大小和数量以及所涉及的资源域数量。Microsoft 及其多个独立软件供应商 (ISV) 伙伴均提供了有助于域重建的工具。
Microsoft ADMT v2 提供了一种方便、安全和快捷的方式，无论是从 Windows NT 4.0 升级为 Active Directory 服务，还是在森林间或森林内重建 Active Directory 域，它都能胜任。该工具在迁移域之间的用户、组和计算机时，用户始终可以访问他们的资源和应用。版本 2.0 包含了新功能，比如密码迁移、脚本接口和命令行界面，这些使得迁移更加方便。
通过评估可用的工具，您可以确定对环境最适宜的工具。如果希望获得完整的升级工具列表，请访问以下地址：
www.microsoft.com/windowsserver2003/upgrading/nt4/tooldocs/default.mspx.
更新风险评估状态
在 Microsoft Solutions Framework (MSF) 下，随着经历不同的项目阶段，需要在每个重大阶段重新评估风险。在完成规划阶段时，不论是否使用了 MSF 方法，您都应该对风险表进行重新评估。该过程应该有整个团队的介入，只有这样，才能找出以前未发现的风险，并且根据对商业的影响以及各自几率列出风险的等级。在 MSF 中，影响和几率的乘积被称为“exposure”（发生几率）。通过按发生几率排列风险等级，您可能发现此前确定的某些风险已不再值得关心——例如，硬件供应商到期不能交付服务器的风险可能已不复存在，因为该供应商已如期供货。
针对新环境的风险会存在重大变化。例如，由于对 DNS 服务器和全局编录服务器的访问是一个关键性的 Windows Server 2003 域功能，因此当从 Windows NT 4.0 迁移时，这种访问能力能否实现将导致相应的风险几率重大变化。另一个可能导致风险几率变化的是，对 PDC 的网络访问能力不再需要，因为 Windows Server 2003 中的所有域控制器都有可写入的 Active Directory 数据库副本。有些环节的风险会降低，而有些会变化。因此，您应该更新您的风险评估状况，并且在开始实际迁移前与团队一起制定防范这些风险的对策。
审阅规划和重新获得管理层批准
同样地，如果使用 MSF，当在规划阶段的末尾时，您需要举行一个由团队重要成员和企业管理层参加的会议， 让他们有机会审查您制订的规划。您可能已安排了任务、分配了资源和设计了防范潜在风险的对策。不论是否遵循 MSF，在启动阶段开始之前进行这样的复查都能让每个人确信：项目仍然符合商业需求，并且所有的可能问题都得到考虑并且进行了相应规划。
总结
到此，您已经完成了所有的迁移规划，并且根据 IT 基础结构做出了针对迁移目标的决策。您已经重新评估了迁移风险，并且规划了风险防范对策。所有规划都已得到迁移团队关键成员和商业管理层的复审。一旦所有计划得到审阅和批准，即可开始执行迁移前任务。
第 7 章 迁移前的工作
为保证迁移的成功性，在执行迁移之前首先需要完成某些任务。其中包括技术上的特定考虑，比如清理域、创建用于恢复的备份和确保环境的安全。此外还应执行相应的沟通计划，以通知最终用户可能对他们带来影响的环境变化。
清理陈旧对象
许多拥有 Windows NT 4.0 域的机构都存在大量陈旧对象，比如网络中已不存在的机器的计算机帐户或已离开机构的用户的帐户。进行清理之前（如果决定在迁移之前执行清理），首先需要识别哪些是陈旧对象，然后才可以根据公司要求进行删除或变动。此时请确保 Windows NT 4.0 中的 SAM 数据库组织良好，并且没有包含不必要的用户帐户、组帐户或计算机帐户。
如果此时清理 Windows NT 4.0 SAM 的任务过于艰巨，您可能会将所有对象都迁移到 Windows Server 2003 Active Directory。一旦域的功能级别为 Windows Server 2003，Logon Timestamp（登录时间戳）就会被复制到所有的域控制器。如果此时查询 Active Directory 域中登录时间戳早于某个指定时间值的用户或计算机帐户，可以简化陈旧对象的查找过程。
备份和验证备份
开始任何迁移或升级操作前都应该制作最新备份。在迁移之前应对所有受影响的服务器执行完全的系统状态和数据备份。备份为机构提供了恢复的手段（如果需要）。另外，还应确保在完成备份时对其进行了验证。
细化迁移计划
规划过程是迁移成功所不可或缺的。您的规划必须定义相关步骤、这些步骤的顺序以及各个步骤的负责人。如果没有按正确顺序执行和完成步骤，可能导致迁移失败并且也无法恢复为原始状态。在升级或重建 Windows NT 4.0 域之前，您应该有一个详细的迁移计划。该计划应当包括：
需要执行和验证哪些备份？
谁将执行所需的备份？
迁移的各个步骤如何，应该以什么样的顺序完成它们？
迁移的各个步骤将由谁执行？
各个步骤的预定计划如何？
谁将根据迁移目标来验证迁移是否已完成？
迁移期间的安全事项
对大多数机构而言，Windows NT 4.0 域的迁移目标之一是不能对安全策略有任何负面影响。为符合该目标，迁移期间及之后的安全水平都必须与 Windows NT 4.0 域模型的相同或者更高。本节详细介绍了您必须根据所选的迁移路径对环境进行的可能更改。此外还指明了这些更改任务所允许占用的时间。如果了解这些更改对您机构的影响，可以规划适当的迁移步骤和顺序，以维护相应的安全水平。
服务管理和物理性安全
对加入森林或域体系的组织或资源而言，它必须选择信任该森林和所有域中的服务管理员。由于服务管理员必须是高度可信的，因此不难理解 Active Directory 中的管理员组为何是服务管理员组以及这些组应该遵守什么样的最佳实践。
Active Directory 中的管理员组包括可执行以下操作的任何组：
合法更改目录配置设置。
安装域控制器。
安装或修改域控制器上的软件。
修改另一个服务管理员组的成员身份。
对于 Windows 2000 和 Windows Server 2003 Active Directory，这些组包括：
由森林所有者控制的组
Domain Admins (森林的根域)
Enterprise Admins (森林的根域)
Schema Admins (森林的根域)
由域所有者控制的组
Domain Admins
Builtin\Administrators
Builtin\Server Operators
Builtin\Backup Operators
为降低服务管理员或者他人通过物理性地访问域控制器而进行攻击的机会，建议遵守以下最佳实践：
将服务管理员组的成员数目控制在最低限度。
仅允许服务管理员组之间相互修改成员身份。
在森林的服务管理员组中不要包括来自外部受信任森林的用户或组，除非来自该外部森林的服务管理员与您所在域的服务器管理员同样可信。
对服务管理员组的成员身份变动进行审核。
仅在绝对必须的情况下才使用服务管理员凭证登录；对于日常工作，可为管理员提供备用的用户帐户。
仅允许服务管理员组管理服务管理员使用的工作站。
限制服务管理员物理性地访问域控制器；不将域控制器放在无法保护其安全的地方。
限制服务管理员物理性地访问域控制器的系统状态备份；不将系统状态备份存放在无法保护其安全的地方。
将在域控制器上运行的软件数目控制在最低限度。
准备和实行森林范围的业务恢复计划。
告诫服务管理员，让他们明白遵守最佳实践的重要性。
您可能希望确定域中有哪些用户属于 Domain Admins 全局组。Domain Admins 组的成员可以在升级过程中管理域。请注意，不要让 Domain Admins 组的成员在完成作业任务所要求的权限上继承更大的权限（对森林的根域）。如果要升级的 Windows NT 4.0 域是 Windows Server 2003 森林中的第一个域，则会出现这种情况。在升级到 Windows Server 2003 前，请删除 Domain Admins 组中您不希望授予其 Enterprise Admins 用户权限的任何成员。
信任关系
要将来自 Windows NT 4.0 源域的帐户和资源迁移到 Windows Server 2003 目标域，必须首先建立外部信任关系。根据将要在两个域之间迁移的对象的类型以及所用工具集对所需信任关系的影响，可能需要在域迁移期间为环境添加额外的信任关系。一旦完成域的迁移，即可将任何临时添加的信任删除。
Windows NT 4.0 帐户域和目标域之间必须存在两个单向的信任关系，以便：
Active Directory Migration Tool 可以成功迁移帐户域中的用户。
帐户域中的用户可以访问目标域中的资源。
从 Windows NT 4.0 资源域到目标域必须存在单向信任，以便：
您可以迁移资源域中的服务帐户和本地用户配置文件。
区域域中的已迁移用户可以访问资源域中的资源。
SIDHistory
在 Windows 2000 和 Windows Server 2003 中有一个名为 SIDHistory 的属性。借助该属性，可以非常容易地将一个域的安全主体迁移到另一个域中。SIDHistory 是一个 Active Directory 安全主体属性，用于存储已转移对象（比如用户和安全组）的原有 SID。当用户登录系统时，系统会检索该用户 SIDHistory 中的条目和该用户的组成员身份，然后将它们添加到该用户的访问令牌中。
由于组也可能转移，因此系统还会检索该用户所隶属的所有组的 SIDHistory 属性，然后将它们添加到用户的访问令牌中。在授权检查期间，系统会将这些访问令牌中的 SIDHistory 条目视作常规的组成员身份，因此即使在早期版本的操作系统上，它们也能授予相应的访问权限，并且没有额外的软件要求。
建议各个机构在完成域迁移后删除 SIDHistory 属性。有关从域中删除 SIDHistory 的详细信息，请参考 Microsoft 知识库文章 295758，地址：
support.microsoft.com/default.aspx?scid=kb;en-us;295758
有关 SID 筛选及其对 SIDHistory 影响的详细信息，请访问下列 URL：
www.microsoft.com/technet/security/bulletin/MS02-001.asp
迁移密码
为了利用 ADMT v2 的密码迁移功能，需要在源域的域控制器上安装密码迁移动态链接库 （DLL）。这个域控制器被指定为“密码导出服务器”。通过在受保护的本地系统上下文中运行，密码将被加密，即使是操作系统也无法以纯文本的形式查看密码。该 DLL 的安装受 ADMT v2 创建的密钥保护，并且只有管理员才能安装。安装该密码导出服务器时的另一个要求是，只有将 Everyone 组添加到内置的“Pre-Windows 2000 Compatibility Access”组才能支持该功能。启用“Pre-Windows 2000 Compatibility Access”选项将允许匿名用户读取域中的信息。完成密码迁移后，应从“Pre-Windows 2000 Compatibility Access”组中删除 Everyone 组。
制订沟通计划
沟通计划应该包括何时将域名更改信息提前通知给用户以及通知多少次。资源域中的用户需要了解域的变动何时进行、他们的新域名是什么以及如何登录新域。对于那些因为域合并而导致用户帐户名冲突的用户，您不仅告知他们新的域名，而且还要告知其新的帐户名。例如，在实际迁移之前，可使用电子邮件将预计的变动通知给每位用户，并且在接连的几天中发送四次邮件。计划将确定通知的频度和时间。发送给用户的电子邮件应该通知他们哪些服务在迁移期间将变得不可用并且这种中断预计将持续多长时间。实际迁移之前，应该为支持人员提供一个将要迁移到不同域名的用户帐户列表。此外还应告诉他们哪些用户帐户名将被更改。支持人员也应接受培训，以了解如何帮助用户登录新域。为使域成员身份的变动生效，资源域中的工作站和服务器都必须首先关闭，然后重新启动。这种关闭和重启只能是机器的重启，并且只能在脱机所造成影响最小的时段进行。
制订角色和职责体系
为了有助于迁移工作的规划和部署，应该制订一个全面的角色和责任体系。该体系对分配、通知和跟踪支持问题也很重要。
对 Windows NT 4.0 帐户域进行升级锁定
在将 Windows NT 4.0 域升级为 Windows Server 2003 Active Directory 之前，应该将前者暂时锁定。锁定 Windows NT 4.0 域意味着您的迁移团队将在升级开始之前指定一段时间，在这期间，无论是用户还是管理员都不能对帐户和 Windows NT 4.0 SAM 数据库进行任何更改。
对于域迁移，里程碑事件应该紧接在域同步和将用于恢复的 BDC 脱机之后。以此表示管理员在将 PDC 升级为 Windows Server 2003 和 Active Directory 之前，不会再发生任何域的变动。
总结
到此，您已经完成了规划并且已开始执行迁移项目的初始步骤了。上文介绍的部分步骤（比如删除旧帐户）可以在迁移开始之前或在迁移之后执行。而有些步骤，比如密码迁移步骤，则要取决于您在密码迁移方面所做的决定：有些机构会选择迁移密码，而有些机构则不会。在域的升级方面，您必须安排一个锁定期。一旦完成了这些迁移前的准备工作，即可开始迁移组帐户和用户帐户。
第 8 章 迁移过程规划选项
迁移现有的域可以通过多种方式来实现。迁移规划团队需要针对现有的每一个域和服务创建具体的规划。所选的迁移和合并方法决定了需要执行的任务以及可能的迁移顺序。
规划各个目标域的迁移路径
域的迁移路径是指用来将 Windows NT 4.0 域迁移到 Windows Server 2003 的具体方法。大型机构通常有多个 Windows NT 4.0 域，包括主用户域 (MUD) 和资源域。当规划每个域的总体迁移时，您需要评估哪种迁移类型最适合该域，应该就地升级还是重建？采用何种域迁移路径取决于迁移目标和机构的商业目标、Windows Server 2003 域的 Active Directory 设计以及现有域的配置和用途。
迁移事项
在评估每个域最适用的迁移技术时，您应该考虑多种因素。
现有域的结构。您现有的 Windows NT 4.0 域在多大程度上同您规划的 Active Directory 域模型相适应？是否或者能否基于现有的域构建所规划的 Active Directory 域结构？是否有合理的理由在待建的结构中原封不动地保留现有域？停用现有的域有意义吗？
机构的抗风险能力。就当前域的生产环境来看，机构的抗风险程度如何（权衡风险和其它的迁移目标和优点）？所规划的 PDC 停机时间有何影响？
预算限制。每个项目都有必须要考虑的预算。这种预算会如何影响现有域所要求的时间安排和资源可用性？
时间限制。快速迁移当前域是否会为商业部门或技术部门带来直接好处？如果域的迁移工作耗时较长，是否会对商业造成重大影响？
迁移资源的可用性。对于迁移工作所要求的资源，包括人员和硬件资源，其可用性会对当前域的时间安排或选择有何影响？从当前的服务器硬件来看， 对当前域所要求的新硬件有何影响？
应用程序的兼容性。域控制器上运行的应用程序是否会受迁移路径的影响？
通常而言，就地升级选项极其适用于帐户域，这些域含有机构的大多数安全主体（用于控制对商业数据的访问）。帐户域的就地升级可为待建的 Active Directory 结构提供一个基础。另外，它还是最快捷和占用资源最少的迁移方式，通过该选项，商业部门可以尽快享受到 Windows Server 2003 域的优点。
在将帐户域就地升级为 Windows Server 2003 之后，您可以将其它域升级或重建为 Active Directory 森林。这要归功于 Active Directory 已得到大幅度改进的可扩展性，同 Windows NT 域数据库相比，Active Directory 可以容纳更多的安全对象。Windows NT 4.0 只能容纳 40,000 个左右的对象，其最大容量为 40 MB；而 Windows Server 2003 Active Directory 可以容纳数以百万计的对象。
一旦完成了本节的规划步骤，就应该可以确定为现有域选择特定迁移路径的理由。例如，您的团队可能为主要帐户域选择执行就地升级，因为这样风险最小，并且业务部门可以直接受益于 Exchange Server 2003 的 Active Directory 功能。在为每个 Windows NT 4.0 域选择了迁移路径后，您可以接着规划每个域的部署，然后规划域迁移的顺序。
对各个目标域的初步部署规划
此时可根据每个域的迁移规划制订各个域的初步部署计划。这有助于检查所选的迁移路径是否正确。该阶段的部署规划需要列出从 Window NT 4.0 域迁移为 Windows Server 2003 Active Directory 结构所要求的任务。这种域部署规划将包含在测试、试运行、撤销迁移和全面展开方面的高级策略。
规划域的迁移顺序
迁移团队确定了各个域的迁移路径和高级部署规划后，需要决定按照何种顺序来升级和重建域。确定现有 Windows NT 4.0 域的迁移顺序，为机构转移到 Windows Server 2003 Active Directory 的整体迁移战略提供了基础。
考虑域的迁移顺序时，第一个必须回答的问题是，“您将如何构建 Active Directory 的基础域或者说第一个域？”。创建第一个域将创建 Active Directory 森林。在 Active Directory 设计和为现有域选择的迁移路径前提下，您可能无法使用某些创建首个域的选项。
迁移顺序选项
要考虑的选项包括：
创建空的森林根域。如果设计指明 Active Directory 将使用空的森林根域，则不必升级或重建现有域即可构建该域。
将帐户域升级为森林根域。将现有的 Windows NT 4.0 帐户域升级，从而形成 Active Directory 森林。
创建森林根域，然后引入重建的域。首先创建一个纯粹的 Active Directory 森林根域，以备引入重建后的 Windows NT 4.0 域。
帐户域所包含的对象通常比资源域多，因此，如果在迁移过程的早期就将帐户域迁移，机构就可以尽快利用 Active Directory 的优点和功能。机构可通过帐户域升级来获得的功能包括 Active Directory 更高的可扩展性以及通过采取管理委派而实现的更高安全性。
如果机构有多个要迁移的帐户域，您可以使用下列问题帮助您规划域的迁移顺序：
如果帐户域将是 Active Directory 结构的森林根域，则必须将其首先升级。
如果帐户域将用作其它域重建的目标域，则应考虑在该过程的早期升级帐户域，以便可以开始域重建。
请升级对域控制器的物理性访问不会构成风险的帐户域。意即，所选的第一个帐户域应该位于迁移团队对域控制器的物理性访问不受限制的位置。
如果应用程序要求 Active Directory 功能，请升级相应位置的所有帐户域（如将使用 Exchange 2003 的帐户域）。
通常而言，帐户域的升级应在资源域之前，因为资源域将被重建到新的 Active Directory 域中。资源域的重建顺序取决于各个域的价值，也就是说，停用资源域所节省的成本以及它对 Windows Server 2003 Active Directory 功能的使用情况。
确定待升级和待合并的服务器
在规划过程的这个阶段，您已经确定了各个域的迁移路径及其迁移顺序。此时需要考虑是升级各个域的域控制器，还是停用它们，抑或将其重新部署为新的角色。硬件对 Windows Server 2003 操作系统的支持能力将是决定 Windows NT 4.0 域控制器命运的因素之一。对于已确定进行就地升级的 Windows NT 4.0 域而言，其 PDC 的硬件是否适宜将尤其重要。
域迁移策略
域迁移计划需要论证下列决定：
各个域的迁移路径。
各个域的部署规划。
域的升级和重建顺序。
域控制器的升级顺序。
在各个域中，对象的重建顺序
以下各节详细介绍了将 Windows NT 4.0 域升级和重建为 Windows Server 2003 域所要求的部署规划。
升级 Windows NT 4.0 域
如果已决定对 Windows NT 4.0 域执行就地升级，在准备升级该域时，您必须完成多个选择。
升级事项
一个主要的规划要求是配置和检查对 Active Directory 结构的 DNS 支持。Windows Server 2003 借助 DNS 提供定位服务（该服务允许客户端计算机查找其它计算机和查找 Active Directory 服务）。Microsoft 建议使用 Windows Server 2003 DNS 作为支持 Active Directory 的 DNS 服务器（不是必需的）。您使用的 DNS 服务器必须支持 SRV 资源记录 (SRV RR) (RFC 2052)。
建议使用能够同时支持动态更新协议 (RFC 2136) 的 DNS 服务器，这样可以简化对 Active Directory 的配置和管理工作。版本 8.1.2 和更高版本的 BIND（一种流行的 DNS 服务器实现方式）可同时支持 SRV RR 和动态更新。如果使用的 BIND 版本不支持动态更新，您必须用手工向 DNS 服务器添加记录。另外请注意：Windows NT Server 4.0 附带的 DNS 版本并不支持 SRV 记录，因此无法用来支持 Active Directory。
在对域进行就地升级的过程中，待升级的域控制器必须指向一个可以支持 Active Directory 的 DNS 服务器。如果当前的 DNS 主服务器不满足 Active Directory 的要求，您可以有多种选择，其中包括：
在将要升级的 Windows NT 4.0 PDC 上安装 DNS 服务。在就地升级 PDC 期间选择在当前服务器上配置 DNS，这会使得 DNS 支持动态更新和 SRV 记录。
将现有的 DNS 服务器升级或替换为运行 DNS 服务的 Windows Server 2003 服务器，然后将主分区转移到该 Windows Server 2003 DNS 服务器。
安装运行 Windows Server 2003 的新服务器。然后从现有的主 DNS 服务器启动一个区域传输。成功传输了该分区后，将新的 Windows Server 2003 DNS 服务器配置为主 DNS 服务器。然后可以配置这个新的主服务器的转发查询区域，以实现动态更新。
应该注意的是，如果将 Windows Server 2003 Active Directory DNS 分区转移到 Windows NT 4.0 DNS 服务器，DNS 管理器中的 SRV 记录将显示为主机记录（A 记录）。借助这些主机记录，可以成功对 Windows NT 4.0 DNS 服务器进行 SRV 查询。
升级域控制器
对域的就地升级要求至少将一个操作系统从 Windows NT 4.0 升级为 Windows Server 2003。第一次的升级必须在待升级域的 PDC 上进行。升级了 PDC 之后，您可以有多种选项来配置其它的域控制器。这包括对现有的 NT 4.0 BDC 进行就地升级、在 Windows Server 2003 操作系统中试运行新的域控制器或者停用现有的 BDC。
硬件要求
在迁移项目的早期评估阶段，您已经为目标域收集了当前域控制器的硬件规格信息。这种硬件评估为确定域控制器是否适合升级到 Windows Server 2003 操作系统提供了有用信息。此时您的 IT 团队应该设定一个 Windows Server 2003 域控制器所要求的最小硬件规格。
有多种因素会影响域控制器的性能，包括域中的对象数量、登录到域中的用户数量、域控制器的角色以及在域控制器上安装的服务和应用。
下表根据所列出的负载类型给出了推荐的域控制器硬件要求。
| 每个站点的用户数量 |
每个站点的最小域控制器数量[1] |
域控制器的最低 CPU 速度 |
域控制器的最少内存数量 |
| 1 – 499 |
1 |
单处理器，850 MHz 或更高 |
512 MB |
| 500 – 999 |
1 |
双处理器，850 MHz 或更高 |
1 GB |
| 1,000 – 2,999 |
2 |
双处理器，850 MHz 或更高 |
2 GB |
| 3,000 – 10,000 |
2 |
四处理器，850 MHz 或更高 |
2 GB |
| > 10,000 位用户 |
每 5,000 位用户一个 |
四处理器，850 MHz 或更高 |
2 GB |
表 4. 建议的域控制器硬件要求
域控制器的升级顺序
域控制器的升级顺序取决于服务器的硬件配置、服务器的位置、Active Directory 设计的限制以及所规划的 Active Directory 性能。
在 Windows NT 4.0 中必须第一个升级的服务器是拥有 PDC 角色的服务器。如果当前 PDC 的硬件条件不充分，则需要引入具有相应硬件的 Windows NT 4.0 BDC 并将其提升为 PDC 角色，然后才能执行升级。
成功升级了 PDC 后，您应该升级、更换或停用其余的 BDC。升级顺序可能取决于各个在 BDC 上运行的应用，以及它们与 Windows Server 2003 操作系统的兼容性，否则可以用任何顺序升级 BDC。对 Windows NT 4.0 BDC 上的不兼容应用系统，可将其转移到 Windows NT 4.0 成员服务器上，直到该应用系统的兼容性问题得到解决。BDC 如果在远程位置，也可能影响升级、更换或停用的时间安排。
配置互操作性
在任何迁移工作中，保持互操作性都是取得项目成功和实现生产环境的稳定性所不可或缺的。Windows Server 2003 具有很好的互操作性。但此时您仍要考虑几个互操作性问题和决定。
保留登录脚本和系统策略的复制
在 Windows NT 4.0 域中，登录脚本和系统策略的复制功能使用了 LMRepl 服务。Windows Server 2003 不支持 LMRepl，它使用文件复制服务 (FRS) 来复制登录脚本和组策略对象。因此，若要在就地升级后保留 Windows NT 4.0 的登录脚本和组策略对象复制功能，需要配置相应的复制通道。
运行LMRepl 导出角色的 Windows NT 4.0 域控制器应该是最后一个被升级的域控制器。如果 Windows NT 4.0 域中驻留该导出角色的服务器是 PDC，则应将导出服务器角色转移给 BDC 或将当前的 PDC 降级，然后为该域引入新的 PDC。将 PDC 升级为 Windows Server 2003 后，可配置 FRS 和 LMRepl 之间的通道。详细信息，请参阅 Microsoft 知识库文章 317368。地址：
support.microsoft.com/default.aspx?scid=kb;[LN];317368
域升级期间防止首个域控制器过载
在将多个 Windows NT 4.0 域控制器中的第一个升级为 Windows Server 2003 后，所有域的 Windows 2000 Professional 和更高版本的客户端都会连接到该域控制器进行身份验证。这些客户端不会连接到其它任何域控制器，因此，这个升级的域控制器可能发生过载。此外，您还可能丧失容错功能。
在将 Windows Server 2003 安装到 Windows NT 4.0 PDC 之前，可对该域控制器进行配置，让它仿真为基于 Windows NT 4.0 的域控制器，从而将其屏蔽。将该域控制器屏蔽后，运行 Windows 2000、Windows® XP 和 Windows Server 2003 的客户端就不会再将其视作 Active Directory 域控制器。客户端将使用新的 Windows Server 2003 域控制器进行身份验证（就如同它是 Windows NT 4.0 域控制器那样），这样就可以防止因为来自 Active Directory 客户端的身份验证请求而使该域控制器过载。除非每个站点都有足够的 Windows Server 2003 域控制器为所有的 Active Directory 客户端提供服务，否则您应该维持这种仿真设置。对于每一个要升级为 Windows Server 2003 的 Windows NT 4.0 域控制器，您都应根据需要执行这种仿真设置。
在对 PDC 进行过载保护之后，必须在计划升级的任何其它域控制器上禁止这种仿真。要成功安装 Active Directory，同一域的其它域控制器都必须能和它们所在域的 Active Directory 域控制器联系。在 Windows NT 4.0 BDC 上，请首先设置 NT4Emulator 注册表项，只有这样，操作系统升级才会保护域控制器不过载。如果之后立即设置 NeutralizeNT4Emulator 注册表项，BDC 可以同设置了 NT4Emulator 注册表项并且已成功安装 Active Directory 的Active Directory 域控制器联系。有关禁止 Windows NT 4.0 仿真的详细信息，请参阅本章稍后部分的“禁止 Windows NT 4.0 域控制器仿真”。
升级了所有域控制器后，或者已经有足够的 Windows Server 2003 域控制器对域中运行 Windows 2000、Windows XP 和 Windows Server 2003 的客户端进行身份验证时，可以通过再次编辑注册表并删除 NT4Emulator 注册表项来进行反向配置。有关执行 NT4Emulation 的详细信息，请参阅 Microsoft 知识库文章 298713。地址：
support.microsoft.com/default.aspx?scid=kb;en-us;298713&Product=win2000
Active Directory 域的“堆积”现象
除了上述的过载影响外，还必须考虑“堆积”现象（取决于待升级域的配置）。详细信息，请参阅 Microsoft 知识库文章 305027。地址：
support.microsoft.com/default.aspx?scid=kb;[LN];305027
Windows Server 2003 功能级别
在 Windows Server 2003 中，域和森林的功能级别定义了在该域或森林中可用的一组高级 Windows Server 2003 Active Directory 功能。域和森林的功能级别还定义了一组可在该域或森林的域控制器上运行的 Windows 操作系统，它并未定义在森林中支持的客户端操作系统。Windows Server 2003 域可能包括四个功能级别，而森林包括三个功能级别。
表 5 列出了 Windows Server 2003 域的功能级别及其在每个域功能级别上支持的操作系统。
| Windows Server 2003 域功能级别 |
支持的域控制器操作系统 |
| Windows 2000 混合 |
Windows NT 4.0 Windows 2000 Windows Server 2003 |
| Windows 2000 本机 |
Windows 2000 Windows Server 2003 |
| Windows 2003 临时 |
Windows NT 4.0 Windows Server 2003 |
| Windows Server 2003 |
Windows Server 2003 |
表 5. Windows Server 2003 域功能级别
表 6 列出了 Windows Server 2003 森林功能级别及其在每个森林功能级别上支持的操作系统。
| Windows Server 2003 森林功能级别 |
支持的域控制器操作系统 |
| Windows 2000 |
Windows NT 4.0 Windows 2000 Windows Server 2003 |
| Windows 2003 临时 |
Windows NT 4.0 Windows Server 2003 |
| Windows Server 2003 |
Windows Server 2003 |
表 6. Windows Server 2003 森林功能级别
详细信息，请参阅 Microsoft TechNet 文章“功能级别背景信息”，地址：
www.microsoft.com/technet/prodtechnol/windowsserver2003/proddocs/deployguide
/dssbk_pfl_usxz.asp
在创建首个 Windows Server 2003 域时，该域和森林的默认功能级别被设为最低级别 －Windows 2000 混合，从而可提供最大的域控制器互操作性。“Windows 2000 混合”功能级别提供了基于 Windows NT 4.0、Windows 2000 Server 和 Windows Server 2003 操作系统的域控制器。但是，如果已确定域的升级将仅使用基于 Windows NT 4.0 和 Windows Server 2003 的域控制器，则建议选择“ Windows Server 2003 临时”模式，因为后者提供了更强的功能。
Windows Server 2003 中的“Pre-Windows 2000 Compatible Access”组
Pre-Windows 2000 Compatible Access 组用于向后兼容运行 Windows NT 4.0 和更早版本的计算机。该组的成员对域中的所有用户和组拥有读访问权限。只有当用户使用 Windows NT 4.0 或更早版本时，才应将他们添加到该组中。
当把基于 Windows NT 4.0 的远程访问服务 (RAS) 或路由和远程访问服务 (RRAS) 服务器设为 Windows Server 2003 域的成员时，必须确保该服务器可以访问域帐户的远程访问凭证。本文介绍了向 Pre-Windows 2000 Compatible Access 组添加 Everyone组的方法。如果这样，可允许 Windows NT 4.0 RAS 服务器对任何 RAS 调用程序进行身份验证。详细信息，请参阅 Microsoft 知识库文章 325363，地址：
support.microsoft.com/default.aspx?scid=kb;en-us;325363&Product=winsvr2003
Windows Server 2003 域中的 Windows 95 或 Windows NT 4.0 客户端
默认情况下， Windows Server 2003 域控制器上启用的安全策略是服务器消息块 (SMB) 数据包签署和安全通道签署。默认情况下，对运行 Windows Server 2003 的域控制器而言，其安全设置的配置有助于防止恶意用户拦截或篡改域控制器的通讯。如果机构中有运行 Windows NT 4.0 SP2（或更早版本）或 Windows 95 的客户机，由于使用了 SMB 数据包签署的安全策略，它们将无法对 Windows Server 2003 域控制器进行身份验证。
如果机构中有运行 Windows NT 4.0 SP2（或更早版本）的计算机，建议升级操作系统或安装 Service Pack 6a（从 Service Pack 4 开始支持 SMB 签署）。
如果机构拥有运行 Windows 95 的计算机，建议升级操作系统来解决该问题，或者安装Active Directory Client。
有关 Active Directory Client 扩展程序的详细信息，请访问下列 Microsoft 网站：
www.microsoft.com/windows2000/server/evaluation/news/bulletins/adextension.asp
您可以禁止所有运行 Windows Server 2003 的域控制器要求 SMB 签署，但 Microsoft 不推荐这样做。要配置该安全设置，请遵照 Microsoft 知识库文章 811497 的说明。地址：
support.microsoft.com/default.aspx?scid=kb;%5bLN%5d;811497
还原注意事项
在对生产系统进行更改之前，首先必须对还原计划进行测试和验证，然后再进行全面部署。在从 Windows NT 4.0 域到 Windows Server 2003 的就地升级中，有两种基本的还原设计方式：
· 至少备份 PDC 和一个 BDC。
· 将 PDC 升级为 Windows Server 2003 之前先将某个 BDC 脱机。作为测试，执行以下步骤（然后再开始迁移）：
· 将脱机的 BDC 提升为 PDC，然后检查数据。
· 让该 PDC 脱机并在迁移后可用，另外要确保对其余的 BDC 进行经常性的备份。
重建 Windows NT 4.0 域
域的升级过程在设计上应尽可能多地保留当前环境，包括域结构。另一方面，Windows NT 4.0 域的重建过程允许您根据机构的需求重新设计森林。尽管通过重建可以实现多种目标，但最通常的目标是合并当前结构，从而转变为数目更少、更大型的域体系。
有多种非 Microsoft 的目录管理工具都可以提供对 Windows NT 的域重建支持。Windows 2000 和 Windows Server 2003 提供了支持域重建的天然功能，即：
可将安全主体从一个域转移到另一个域，并且保留原有的资源访问权限。
不用完全重新安装操作系统，即可将 Windows 2000 和 Windows Server 2003 域控制器从一个域转移到另一个域。
Microsoft 还提供了一个图形化工具（即 ADMT v2）来简化域的重建任务，并且通过脚本化的组件对象模型 (COM) 组件和命令行实用工具提供了帮助。Active Directory Migration Tool 可在执行下文的任务时为大多数用户提供帮助。如果用户要求更高级的图形化工具，可以使用多个 ISV 提供的第三方工具。这些工具提供了域重建和域迁移功能。详细信息，请访问以下 URL：
www.microsoft.com/windowsserver2003/upgrading/nt4/tooldocs/default.mspx
本章的其余部分使用 ADMT v2 提供了域重建期间的迁移过程示例。
{0>Best Practices for Performing the Domain Restructure<}0{>域结构重组的最佳实践<0}
{0>This section details best practices for when you are performing a domain restructure using the Active Directory Migration Tool, with the overall rule being that you should follow the migration procedures presented in the following sections.<}0{>本节内容详细介绍了在使用 Active Directory Migration Tool 执行域结构重组时所需遵循的最佳实践，以及在以下章节介绍具体迁移过程中应该遵循的总体原则。<0}
{0>Time synchronization.<}0{>时间同步。<0} {0>Synchronize the time on all computers participating in the migration.<}0{>对参与迁移过程的所有计算机的时间进行同步。<0} {0>This helps when while troubleshooting using the event log.<}0{>这可以为使用事件日志解决遇到的故障提供帮助。<0}
{0>Empty recycle bin.<}0{>清空回收站。<0} {0>Before you migrate user profiles, empty the Recycle Bin on any computer that is used by a user whose profile will be migrated or apply the hot fix detailed in Microsoft Knowledgebase article 819766,available at the following URL:<}0{>在迁移用户配置文件之前，首先清空其配置文件将要被迁移的用户所使用的计算机上的回收站，或者应用Microsoft知识库文章 819766中所详细介绍的热修补程序，可以通过以下地址访问该知识库文章：<0}
{0>support.microsoft.com/default.aspx?scid=kb;en-us;819766<}0{>support.microsoft.com/default.aspx?scid=kb;en-us;819766<0}
{0>Failure to empty the Recycle Bin without the hot fix results in a "Recycle Bin corrupted" error.<}0{>如果没有应用该热修补程序将无法清空回收站，并产生“回收站损坏”错误。<0}
{0>Uninterrupted migration.<}0{>不中断的迁移。<0} {0>Allow the migration process to finish without interruption.<}0{>让迁移过程连续执行直到完成，不发生中断。<0} {0>If you interrupt the migration process before it is finished, accounts may exist without correctly set properties.<}0{>如果您在迁移过程完成之前中断了该过程，帐户可能会存在，但是属性却得不到正确的设置。<0}
{0>Access to same Protar.mdb. When performing a lengthy migration, you should always run Active Directory Migration Tool from the same computer.<}0{>访问相同的Protar.mdb。在执行一个需要花费较长时间的迁移过程时，应该总是在同一台计算机上运行Active Directory Migration Tool。<0} {0>Active Directory Migration Tool stores information used during the migration process in a file on the computer on which the tool is run.<}0{>Active Directory Migration Tool 将迁移过程所需使用的信息保存在运行该工具的计算机上的一个文件中。<0} {0>If you must change computers during the migration, you can move this information to the new computer by copying the Protar.mdb file to the Active Directory Migration Tool folder on the new computer.<}0{>如果在迁移过程中您必须更换计算机，可以将Protar.mdb文件移动到新计算机上的Active Directory Migration Tool文件夹内，从而将这些信息移动到新的计算机上。<0} {0>(Protar.mdb resides in the Active Directory Migration Tool installation directory which you selected during your installation of the tool.)<}0{>（Protar.mdb 位于您在安装该工具时所指定的Active Directory Migration Tool 的安装目录中。）<0}
{0>Passwords meet new policy.<}0{>密码符合新策略的要求。<0} {0>When migrating user accounts between domains in the same forest, user passwords are migrated to the target domain.<}0{>在同一个森林的不同域之间迁移用户帐户时，用户的密码也被迁移到目标域。<0} {0>Verify that the passwords of the source domain user accounts match the password policy of the target domain.<}0{>验证源域中用户帐户的密码是否与目标域中的密码策略相匹配。<0} {0>If the source user accounts have passwords that violate the password restrictions (such as minimum length) in the target, then the affected migrated accounts cannot log on until the password has been set to a value that fits the target domain password policy and the affected migrated accounts have been marked as enabled.<}0{>如果源帐户的密码违反了目标域的密码策略的限制（例如有关密码最小长度的限制），那么受影响的被迁移帐户将无法登录，直到密码被设定为一个符合目标域密码策略的值，而且受影响的被迁移帐户也已经被标记为启用。<0}
{0>Service accounts.<}0{>服务帐户。<0} {0>If you perform an intra-forest migration of service accounts, ensure that all computers with the services on them are available when you perform the migration.<}0{>如果您正在执行森林间的服务帐户迁移工作，请确保运行这些服务的所有计算机在执行迁移时均处于可用状态。<0} {0>When you perform an intra-forest migration of accounts, you are actually moving the account because the two accounts cannot exist in the same forest.<}0{>在执行森林间的帐户迁移时，您实际上在移动这些帐户，因为两个帐户不能存在于同一个森林中。<0} {0>If a computer that uses one of these service accounts is not available, the service on that computer may stop working until it gets the service account updates.<}0{>如果使用这些服务帐户的某台计算机不可用，那么该计算机上的服务可能会停止工作，直到它升级了服务帐户。<0}
{0>ADMT log entries.<}100{>ADMT 日志条目。<0} {0>To read Active Directory Migration Tool event log entries, read the log from a computer on which Active Directory Migration Tool is installed.<}100{>为了阅读Active Directory Migration Tool 事件日志条目，可以在安装了Active Directory Migration Tool的计算机上阅读日志。<0} {0>The Active Directory Migration Tool agent may write event log entries on the computer where it runs.<}100{>Active Directory Migration Tool 代理可能会在运行它的计算机上写入事件日志条目。<0} {0>As the agent software is removed when the agent tasks are completed, you should view the event log entries from a remote computer which has the Active Directory Migration Tool installed.<}100{>由于在代理任务完成之后，代理软件便被删除，所以您应该在安装了Active Directory Migration Tool的远程计算机上查看事件日志条目。<0}
{0>Single ADMT.<}100{>单一的ADMT。<0}{0>Two or more users in the same domain should not run Active Directory Migration Tool at the same time.<}0{>同一个域中的两个或更多的用户不应该同时运行Active Directory Migration Tool。<0} Active Directory Migration Tool 收集与数据库中将要被迁移对象有关的信息。然后，该工具使用这些信息执行迁移工作。如果两人或者更多的人试图同时使用Active Directory Migration Tool，对数据库的访问会发生冲突。
迁移最新内容。因为代理被派遣到远程计算机，在运行（ADMT v2 计算机迁移和安全性转换向导）之前，应该校验是否跨越目标域的所有域控制器对最新内容进行了复制。如果在域控制器上运行该工具，远程计算机可能会查询一台域控制器，而不是正在运行Active Directory Migration Tool的那一台计算机，以获得操作所使用的帐户和组信息。如果某些特定的修改没有被复制到域中的所有域控制器，那么代理可能会收到过期的信息，计算机迁移或者安全性转换工作可能因此而失败。
故障处理日志。Migration. log 和 Dispatch. log 文件有助于解决ADMT v2 Computer Migration Wizard发生的问题。您还可以使用Event Viewer（事件查看器）在源计算机、目标计算机以及派遣了代理的任何计算机上查看“应用程序和安全性”日志条目。
为迁移准备源域和目标域
在执行域重建的时候，隐含地会创建一个Windows Server 2003 域，以便将Windows NT 4.0 域迁移到新的环境。这个新环境被称作目标域。
启用审核
如果您正在从源域向目标域迁移密码，必须在两个域中启用审核。之所以必须在源域和目标域中启用审核，是因为SIDHistory API 操作需要接受审核，以确保源域和目标域的管理员能够检测到该功能何时开始运行。SIDHistory API 在每个域中校验Audit Mode（审核模式）是否为开启状态，以及“成功/失败”事件的Account Management （帐户管理）审核是否开启。在目标域中，会为每个成功或失败的SIDHistory API操作产生一个独一无二的“Add Sid History”（添加Sid历史）审核事件。
配置Pre-Windows 2000 Compatible Access
如果您正在从源域向目标域迁移密码，必须运行对目标域进行匿名的空会话访问。执行迁移期间，“Everyone”组应该是目标域中的Pre-Windows 2000 Compatible Access（Windows 2000 之前操作系统的兼容访问）组的成员。
添加TcpipClientSupport 注册表键
以下注册表值必须添加到源域的PDC中，以便实现TCP传输之上的RPC调用。请修改如下注册表键值，将DWORD 的值修改为1。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\TcpipClientSupport
无论从哪个方面来看，设置该值都不会损害系统的安全性。如果该值被创建或者被修改，源域控制器必须重新启动，让该设置生效。
创建源域本地组
出于审核的目的，必须在源域上建立一个名为<SrcDomainName>$$$的新的本地组。这个本地组的名称<SrcDomainName>$$$包括了源域的NetBIOS名以及三个美元符号（$），必须在迁移SIDHistory之前在源域控制器上创建该组。迁移操作所针对的每个源域用户和全局组都应该添加到该组中，然后从组的成员关系中删除。这样会在源域中产生“添加成员和删除成员”审核事件，可以搜索引用了该组名的事件来监视它。
安装128位高强度加密包
128位高强度加密包（High Encryption Pack）是运行Active Directory Migration Tool的Windows Server 2000 和Windows Server 2003计算机以及作为Password Export Server（密码导出服务器）的服务器所必需的，密码导出服务器是源域中的任何一台BDC或PDC，在它上面安装了支持密码迁移的DLL。默认情况下，Windows Server 2003已经安装了128位的加密包；您可能需要在Windows NT 4.0 Password Export Server上安装它。可以通过以下URL安装128位高强度加密包：
www.microsoft.com/ntserver/nts/downloads/recommended/SP6/128bitX86.
创建密码导出服务器
利用Active Directory Migration Tool迁移密码需要引入密码导出服务器（PES）的概念，以便驻留支持密码迁移的DLL。PES可以是源域中的任何一台域控制器。但是，如果指定的PES不是PDC，那么必须在域控制器上安装128位高强度加密包。如果不打算迁移任何密码，则不需要安装密码导出服务器。请确保密码导出服务器满足最小的软件要求，也就是：安装了SP5的 Windows NT 4.0、安装了128位高强度加密包的Windows 2000或Windows Server 2003。
Active Directory Migration Tool不能校验目标域的密码策略。如果源用户帐户设置的密码违反目标域的密码限制（例如不能满足对最小长度的要求），会强迫受影响的帐户在下一次登录时修改密码。
迁移过程结束之后，应该卸载PES，减少IT环境的攻击表面积。
提升域的功能级别
为了将SIDHistory 从源域迁移到目标Active Directory 域，域的功能级别必须被提升到Windows 2000本机或者更高。如果Active Directory域的功能级别为Windows 2000本机模式或者更高级别，用户的登录操作会创建一个包含了用户的主帐户SID和组SID信息的访问令牌，以及用户在所在组中的用户SIDHistory和组的SIDHistory。源域可以为早于Windows NT 4.0的操作系统，或者任何版本的Windows Server 2000或Windows Server 2003功能级别。源域和目标域不能在同一个森林中（Windows NT 4.0域被定义为不属于同一个森林）。这个森林间的约束条件确保不会在同一个森林中创建重复的SID（无论是显示为主SID还是SIDHistory值）。
建立信任关系
为了从Windows NT 4.0源域向Windows Server 2003目标域迁移帐户和资源，必须建立外部信任。需要建立哪些信任关系由所迁移对象的类型决定。Windows NT 4.0帐户域和目标域之间必须存在两个单向的信任关系，以便于：
Active Directory Migration Tool 可以成功地从帐户域中迁移用户。
帐户域中的用户可以访问目标域中的资源。
Windows NT 4.0资源域和目标域之间应该存在一条单向的信任关系，以便于：
能够迁移资源域中的服务帐户和本地用户配置文件。
被迁移的用户可以访问资源域中的资源。
配置目标 OU 结构
OU 的结构基于设计团队所创建的OU设计。可以使用“Active Directory 用户和计算机”控制台来配置OU的结构和进行管理。您将指定使用ADMT v2进行迁移的对象的目标OU。由于对象可以轻松地在Active Directory中的OU间移动，您应该考虑为每一个迁移创建OU，并将其作为一个占位符。在解决了所有问题之后，对象便可以移动到它们的最终目的地。
迁移对象
本节内容讨论了Windows NT 4.0 域对象的迁移以及安全主体的转换。在迁移过程中，理解需要从Windows NT 4.0域进行迁移的对象的类型十分重要。您应该考虑在Windows NT 4.0源域上执行以下迁移过程：
1. 迁移组对象
2. 迁移域帐户
3. 迁移用户工作站
4. 迁移服务帐户
5. 迁移成员服务器
6. 转换资源上的安全原则
7. 升级Exchange 5.5 Primary NT 帐户
本节没有介绍迁移帐户域或资源域的具体步骤，而是介绍了在执行上述操作的情况下所必须完成的迁移操作。根据域中的对象类型的不同（用户、组、计算机），需要执行的迁移操作也各不相同。
开发一个对象迁移策略
机构的迁移策略的细节和顺序取决于诸多因素，例如域的模型、管理模型和迁移团队的大小等等。如果不考虑这些因素的影响，使用Active Directory Migration Tool v2 将Windows NT 4.0域的结构重新调整为Windows Server 2003 Active Directory 域可以按照图2所示的具体步骤进行。如果您的机构需要对大量的Windows NT 4.0 域进行重建，那么需要重复执行这个迁移过程，直到达到想要的最终状态。该过程是Windows NT 4.0 域重建的最佳实践。
图 2. 域迁移操作
在验证了迁移过程将按照希望的方式进行之后，使用向导迁移组、用户和计算机，然后使用ADMT v2 Security Translation Wizard 升级计算机上的ACL。在整个迁移过程中，您应该：
生成迁移报告。
分析报告。
根据需要修正问题。
重复迁移、分析和修正问题的过程，直到完成整个迁移。
迁移组
从源域向目标域迁移组的工作应该由Active Directory环境的系统管理员进行。此时最好不要迁移组成员关系，而是仅仅迁移组本身。组成员关系将在用户帐户迁移过程（迁移用户帐户）中迁移。所有组都应该从源域迁移到Active Directory目标域。这样可以确保使用了源域组的所有ACL都能够得以保留。在以后的时间，您还可以从Active Directory域中删除过期的对象。
全局组的成员只能是它所在域的用户。如果用户帐户从一个域迁移到另一个域，Active Directory Migration Tool在目标域中创建的新帐户不能是源域全局组的成员。
为了保留用户的全局组成员关系，必须首先对全局组进行“克隆”。也就是为源域中存在的每一个全局组在目标域中也创建一个相应的全局组。在目标域中新创建的全局组会获得一个新的主SID，这个SID包含了目标域的域标识符。源域中全局组的主SID将被添加到新创建的组的SIDHistory属性中。
全局组的迁移涉及如下步骤：
1. Active Directory Migration Tool 读取源域中的全局组对象。
2. 在目标域中创建新的全局组对象。为新域中的对象创建新的主SID。
3. 源域中的全局组的SID被添加到目标域中新的全局组的SIDHistory属性中。
4. 在源域和目标域的日志中记录事件。
本地组可以包含在其他域中定义的成员。所以，与处理全局组和用户帐户相比，本地组的处理要更为复杂一些。在目标域中添加本地组的时候，Active Directory Migration Tool 会按照如下顺序处理组成员：
1. 如果源成员也被迁移，Active Directory Migration Tool将复制出来的帐户添加到目标域的本地组中。
2. 如果源成员在目标域中是已知的，则按照它的安全标识符进行添加。为了让目标域知道该成员，必须在被源域和目标域都信任的域中定义用户帐户或组。
3. 如果源成员的名称存在于目标域中，该名称被解析为目标域的安全标识符。
4. 如果源成员的名称在目标域中不存在，则在受目标域信任的域中搜索该名称，然后将名称解析为它的安全标识符。如果没有找到名称，Active Directory Migration Tool不会添加该成员。
共享的本地组有时用在域控制器上，以便组织访问权限。如果使用了共享的本地组，应该使用ADMT v2 Group Migration Wizard将所有共享的本地组迁移到目标域，升级域控制器，然后将它们移动到目标域。
在迁移组之前，可以使用ADMT v2 Group Mapping and Merging Wizard （组映射和合并向导）将源域中的组映射到目标域的不同组。将一个组映射为另一个组实质上是将源域的组的成员关系移动到目标域中的新组或不同的组。将多个组合并为一个组则是将源域中几个组的成员关系综合到目标域的一个组中。
在执行用户帐户的迁移之前，必须首先让以下项目就位：
Windows NT 4.0 SP4、Windows 2000 或 Windows Server 2003中的源域。如果需要迁移密码，Password Export Server 需要实现安装Windows NT4 SP5、Windows 2000或Windows Server 2003以及128位高强度加密包。
目标域的功能级别为“Windows 2000 本机”或者更高。
源对象的SID必须不存在于目标森林中，无论是作为一个主帐户SID还是在帐户的SIDHistory中。
源域和目标域之间必须建立一条信任关系（源域信任目标域），为ADMT提供必要的安全上下文环境。为了让被迁移用户能够访问资源，还需要在现有的资源域和目标帐户域之间建立信任关系。
在源域上建立一个名为<sourcedomainname>$$$ 的新的本地组，供ADMT的内部审核使用。
源域的PDC必须拥有TcpipClientSupport 注册表条目。
必须在源域和目标域上都启用审核。
再次迁移全局组
大型的用户帐户迁移需要花费较长的时间。这可能会迫使用户定期重新将全局组从源域克隆到目标域，以反映源域发生的变化。例如，为了在不覆盖先前迁移的用户帐户的情况下更新全局组成员关系，您应该：
启用“复制组成员”（Copy group members）。
禁用“更新先前迁移的对象”（Update previously migrated objects）。
如果帐户名称发生冲突，为了确保新的成员可以被附加到组成员关系中，您可以：
启用“替换发生冲突的帐户”（Replace conflicting accounts）。
禁用“删除现有用户权限” （Remove existing user rights），或者“删除被替换组的现有成员”（Remove existing members of groups being replaced）。
有数不清的迁移选项可供使用。在迁移组和用户之前，应该对您特殊的迁移策略进行彻底的测试。另外，您还可以定义一个计划任务，在每天晚上重复执行这个过程。这需要使用Active Directory Migration Tool的命令行接口重新克隆全局组。
迁移用户帐户
在组被迁移到目标域之后，可以将用户帐户从Windows NT 4.0 环境迁移到新的Windows Server 2003 Active Directory域。
如果打算迁移密码，可以将如下注册表键值修改为一个等于“1”的DWORD值。为了最大限度实现安全性，在为迁移做好准备之前，请不要进行此修改。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA\AllowPasswordExport
如果需要，可以分阶段执行这项工作，但是首先应该使用一个用户组进行试验，测试新环境以及检查所有资源访问权限是否得到保留。在确认作为示范的迁移项目取得成功之后，可以分为多个步骤逐渐迁移越来越多的用户。
在迁移帐户的时候，必须将SID迁移到目标域。这样会更新帐户的SIDHistory 。如果迁移了帐户，但是没有更新这些帐户的SIDHistory，那么新的帐户将无法访问原始帐户能够访问的资源，直到转换了安全性和Exchange目录。
将用户帐户作为一个被禁用的用户对象迁移到Windows Server 2003 Active Directory域之中是一种最佳做法。然后，在用户的工作站被迁移到Active Directory之时，用户帐户可以被启用。
在执行组迁移之前，如下项目必须已经就位：
源域运行Windows NT 4.0 SP4、Windows 2000 或 Windows Server 2003。
目标域的功能级别为“Windows 2000 本机”或者更高。
源对象的SID必须不存在于目标森林之中，无论是作为一个主帐户SID还是在帐户的SIDHistory之中。
必须在源域和目标域之间建立一条信任关系（源域信任目标域），为ADMT提供必要的安全上下文环境。为了让被迁移用户能够访问资源，还需要在现有的资源域和目标帐户域之间建立信任关系。
在源域上建立一个名为<sourcedomainname>$$$ 的新的本地组，供ADMT的内部审核使用。
源域的PDC必须拥有TcpipClientSupport 注册表条目。
必须在源域和目标域上都启用审核。
使用“存放”OU
在就地升级过程中，域的安全主体被放置在默认容器（“用户和计算机”）中。在升级了PDC后，针对您的Active Directory进行了规划的OU结构必须被创建，而安全主体将被移动到正确的OU中，以确保必需的组策略应用到用户和计算机帐户。
如果您还需要重新对第二个主控用户域的迁移进行结构调整，可能希望使用ADMT工具，将被迁移的用户和组放置在一个“存放 OU”中，例如“\Migrated\<NetBIOS Domain Name>\Users”和“\Migrated\<NetBIOS Domain Name>\Groups”，在这里，<NetBIOS Domain Name> 是源域的NetBIOS 名称。在迁移了对象之后，可以将它们移动到在设计之时指定的正确OU之中。
与此类似，在移用Windows NT 4.0 资源域中的计算机时，可以将它们放在一个临时的OU之中，直到迁移过程接近完成的时候，再将它们移动到正确的最终OU。
迁移工作站
既然用户和组驻留在Windows Server 2003 Active Directory 环境中，那么就可以将资源（例如工作站）迁移到新的域。工作站和成员服务器拥有它们自己的SAM数据库。如果在域间移动它们，它们总是会随身带着这个数据库。如果在本地SAM数据库（例如本地组）中定义的帐户被授予了访问资源的条件，它们将总是随计算机一起移动。因此，不需要迁移这些帐户。
通过使用ADMT v2 Computer Migration Wizard （计算机迁移向导）和Security Translation Wizard（安全性转换向导），您可以将用户的工作站迁移到目标域，同时保留原有的用户体验。与用户和组的迁移类似，在迁移剩余的工作站之前，应该首先迁移测试工作站上作为示范的组。一旦工作站上的示范项目经过确认取得了成功，那么剩余的用户工作站便可以被迁移到新的Active Directory 环境。
在从Windows NT 4.0 域迁移计算机帐户的时候，Active Directory Migration Tool 无法迁移计算机描述，因为计算机描述属性没有保存在Windows NT 域的 SAM 数据库中。该描述保存在本地计算机上。（ADMT v2 会迁移Windows 2000或Windows Server 2003 源域中计算机帐户的非空计算机描述。）在将工作站从Windows NT 4.0源域迁移到Windows Server 2003 Active Directory 域时，应该执行以下工作。
图 3. 工作站的迁移操作
工作站的迁移可以由本地负责支持工作站的桌面支持人员来执行。尽管可以通过广域网（WAN）远程执行迁移工作，但是在本地站点执行工作站的迁移可以提高迁移速度和效率。为了执行迁移，本地管理员必须拥有工作站的管理员权限。工作站将要迁移到的目标OU可以通过配置，实施委派控制，以便桌面支持人员可以使用Active Directory Migration Tool v2创建新的计算机对象。
Computer Migration Wizard（计算机迁移向导）对于可以一次迁移的工作站数量没有限制。但是，根据内部测试的结果，Microsoft认为，为了更容易地实现成功迁移，每次迁移的工作站数量实际应该在500台以内。
合并Windows NT 4.0 系统策略
在重建之后，来自源域的系统策略不会由在目标域中接受身份验证的被迁移客户端计算机自动进行处理。为了允许系统策略继续在运行Windows NT 4.0的计算机上得到处理，必须将LAN Manager复制服务和FRS集成在一起，以便在两个FRS之间实现同步，或者将系统策略迁移到Windows Server 2003。
下表详细展示了对策略的影响：
| 状态 |
影响 |
| Windows Server 2003 域控制器验证运行 Windows 2000 或 Windows XP 的客户端计算机的身份 |
组策略被应用 |
| Windows NT 4.0 域控制器验证运行 Windows 2000 或Windows XP 的客户端计算机的身份 |
系统策略被应用 |
| 计算机帐户位于 Windows NT 4.0 域中 |
系统策略被应用到计算机上 |
| 用户帐户位于 Windows NT 4.0 域中 |
系统策略被应用到用户帐 |
| 计算机帐户或者用户帐户位于 Windows Server 2003域中 |
如果计算机运行 Windows 2000 或 Windows XP，组策略将被应用到帐户。 |
表 7. 迁移系统策略造成的影响
为了确保系统策略可以在Windows Server 2003域的Windows NT 4.0计算机帐户上继续得到处理，必须把名为Ntconfig.pol的 Windows NT 4.0系统策略文件迁移到Windows Server 2003的NETLOGON 共享文件夹。为了连接到NETLOGON 共享文件夹，以便在Windows Server 2003网络中利用系统策略，可以在LAN Manager复制服务和文件复制系统（File Replication System，FRS）之间架起一座桥梁（参考上文的“配置互操作性”部分）。
为了把系统策略迁移到组策略，请完成以下工作：
确定哪些运行Windows NT 4.0的被迁移客户端计算机需要系统策略。只有运行Windows NT 4.0并且包含已经被移动到目标域的帐户的客户端计算机才需要来自NETLOGON共享文件夹的系统策略。
确定系统策略中的哪些设置必须应用到已经升级到Windows 2000或者Windows XP的客户端计算机。系统策略设置可以使用Microsoft Windows Server 2003 Server Resource Kit（资源工具包）中的Gpolmig.exe工具迁移到组策略。该工具将当前的系统策略设置转换为组策略设置，并且把必要的注册表设置映射为Windows 2000或Windows XP的注册表设置。
确定需要在OU结构的什么地方部署组策略。可以在Active Directory结构的不同层次上应用组策略。在部署组策略的时候，必须确定哪些策略必须应用到域级别，而哪些策略必须应用到Active Directory结构中的特定OU。
确定系统策略是否必须在源域中被撤销。只有当运行Windows NT 4.0的所有客户端计算机都升级到Windows 2000或Windows XP后，才可以从NETLOGON共享文件夹中删除系统策略，然后使用组策略替换它们。对于重建，可以在所有客户端计算机迁移到Windows 2000或Windows XP后，删除系统策略。
为了删除系统策略，可以从Windows Server 2003域控制器的NETLOGON共享文件夹中删除Ntconfig.pol 文件。FRS将确保文件从域中的所有域控制器上被删除。
生成SID映射文件
对网络资源（打印机、文件、文件夹和共享）的访问要受包含在与每个资源相关联的安全描述符中的ACL的限制。Active Directory Migration Tool v2 可以将引用了用户帐户或者源域中的某个组的安全描述符修改为引用目标域中的另一个用户帐户或组。如果您的机构拥有各种帐户和资源域，那么必须为资源迁移生成一些SID映射（SID Mapping）文件。
在转换安全性的时候，ADMT v2 使用有关被迁移帐户的内部信息决定哪些ACL需要被转换以及应该如何加以转换。您可以使用一个SID映射文件覆盖该信息，然后将资源对象映射到目标对象。这个SID映射文件可以用作一个输入文件，用于安全转换。通过使用这个文件，可以转换那些没有使用Active Directory Migration Tool进行迁移的帐户（例如在某个ACL中引用的Domain Admins）的安全性，或者独立于被迁移对象执行安全性转换。
SID映射文件指定了源对象的名称或SID，后面跟着一个逗号，然后是目标对象的名称或SID。每个源对象/目标对象组合必须放在它自己的行中。
以下例子展示了SID映射文件中的一行，文件使用SID来标识源对象，使用名称标识目标对象：
S-1-5-21-397955417-626881126-188441444-1234, DOMAINA\GRP4354
S-1-5-21-122355417-626881432-323453434-3321, DOMAINB\GRP7765
如果在一台Active Directory Migration Tool迁移计算机上执行用户和组对象的迁移工作，可以使用单一的Active Directory Migration Tool 数据库 protar.mdb来生成SID映射文件。Domain Consolidation and Migration Implementation Guide （域合并和迁移实现指南）提供了一个伪脚本示例，从Active Directory Migration Tool数据库中提取出一个SID映射文件。与选择应用到被迁移工作站的安全主体相比，从映射文件中获得所有被迁移的用户和组通常要更容易一些。
在该文件创建之后，它被复制到将要执行工作站迁移的Active Directory Migration Tool 工作站。SID 映射文件在Security Translation Wizard（安全性转换向导）运行期间会被使用到。
另外，您可能希望把完整的protar.mdb 文件复制到执行工作站迁移的工作站。在这种情况下，切记不要覆盖执行组和用户对象的迁移工作的工作站上的主控 ADMT 数据库protar.mdb，这一点十分重要。
验证工作站迁移的必备条件
在执行迁移之前，应该确认您的环境满足各项必备条件。
执行示范性的迁移
示范性的迁移工作涉及：选择一个作为示范的工作站组以及相应的用户帐户，确保计算机成功迁移，同时保持用户对网络资源的访问能力。示范性的迁移与“执行工作站迁移”部分中介绍的完全一样，唯一的差别是迁移的内容是示范性的工作站和用户。在示范的工作站被迁移和完成了用户接受度测试完成之后，便可以着手迁移工作站了。
执行工作站的迁移
工作站的迁移涉及转换本地安全性引用和修改计算机的域成员关系，这需要重新启动计算机，以便让修改生效。由于需要重新启动，用户这一次不应该登录到计算机上，应该在对最终用户影响最小的情况下执行迁移（例如在下班之后）。
为了进行迁移，Active Directory Migration Tool v2 会在计算机上远程部署一个代理。ADMT v2 代理可以在运行如下操作系统的计算机上工作：
Windows NT 4.0 （安装了Service Pack 4 或者更新版本的服务包）
Windows 2000 Server 或者 Professional
Windows XP
Windows Server 2003 家族
代理负责转换安全性和修改计算机的域成员关系。在这些工作完成之后，代理会自动将自己从工作站上卸载。出于故障处理的需要，代理的日志文件可以在被迁移工作站的Windows 的“Temp”目录中找到。
转换工作站上的安全性引用
在对域进行修改之前，应该转换工作站的安全性，这样，在域成员关系要求重新启动之后，就完成了工作站的迁移工作。Security Translation Wizard会更新涉及以下领域的对源域安全性进行的引用。
表 8. 安全性转换对象选项
在从主控的用户域——资源域模型——进行迁移的时候，需要指定在上节生成的SID映射文件的路径。
本地配置文件
Windows NT 4.0、Windows 2000和Windows XP均支持本地配置文件，本地配置文件包含了用户的桌面状态和用户数据。只有运行Windows NT 4.0的工作站才需要迁移本地配置文件。其他操作系统，例如Windows 95，不支持本地用户配置文件，所以也无需迁移。
共有两种不同类型的配置文件：漫游配置文件和本地配置文件。表9列出了机构可以用来管理用户配置文件的两种方法，对方法的简短描述以及每种方法的迁移要求。
表 9. 机构管理用户配置文件的方法
如果机构打算对用户配置文件加以维护，那么应该在迁移了每批用户之后和用户在新域登录之前立即迁移这些用户的本地配置文件。这样可以确保用户在新域首次登录时，仍然能够使用当前的个性化桌面。
此外，可以检查工作站上的 dctlog.txt ，看看期待的配置文件是否已经被转换。
修改工作站的域成员关系
为了修改计算机的域成员关系，必须在完成修改之前重新启动计算机。ADMT v2代理会自动部署在工作站上，并且在事先定义的时间期限后重新启动计算机。如果迁移的工作站与先前迁移到Active Directory 中的用户和组对象位于同一个域中，那么可以通过ADMT v2 Computer Migration Wizard转换安全对象。
工作站迁移之后的操作
现在，工作站已经成为了Windows Server 2003 Active Directory 域的成员，可以开始启用Active Directory用户对象，禁用Windows NT 4.0用户帐户和更新Exchange 5.5目录了。用户现在需要使用他们的Active Directory用户对象登录到域。可以通过迁移项目的沟通计划来清楚地告知用户这一点。
更新 Exchange 5.5目录
在工作站和用户迁移到Windows Server 2003 Active Directory域之后，需要更新Exchange 5.5 Directory中对Primary Windows NT Account的引用。Exchange Directory Migration Wizard将读取Exchange 5.5 Directory，然后更新对邮箱的Primary NT Account属性中旧的源Windows NT 4.0域的引用。这项工作应该由Exchange 5.5管理员进行。可以在迁移过程的末期执行此工作，用户能够通过SIDHistory继续访问他们的Exchange 5.5邮箱。
迁移成员服务器
Windows成员服务器从资源域到Windows Server 2003 Active Directory 域的迁移过程与工作站的迁移基本类似。在开始迁移之前，首先鉴别成员服务器上现存的所有应用程序十分重要。某些应用程序不支持计算机在域间的移动。对于这种情况，应该咨询应用程序的生产商，确定最为恰当的迁移过程。
此外，在为服务器向目标域的迁移确定最适当的时间时，还必须考虑到用户的影响。由于服务器需要重新启动，以提交域成员关系发生的变化，应该对工作时间的损失预先进行计划，并将这种损失告知用户。在安全性转换过程中，用户不会受到任何影响。
在安全性转换期间，很多机构还选择添加安全描述符，而不是替换原有的引用。通过将目标域中的帐户的SID添加到安全描述符中现有的CL和SACL里，对象可以同时包含源域中的原始帐户和目标域中该帐户的SID。这种方式为目标域中的帐户赋予了与所选对象在源域中所拥有的权限完全相同的权限。在确认已经添加了正确的安全性之后，可以重新运行ADMT v2 Security Translation Wizard，删除源域的安全主体。这两个步骤为机构根据需要还原到现有环境提供了一种更加简便的手段。
还原的考虑事项
制定一个还原计划十分重要，以免迁移到Windows Server 2003中的帐户和资源不能满足用户提出的条件。Windows NT 4.0帐户域的帐户仍然是完整无缺的，并且可以在用户迁移过程结束之后被启用，从而轻松返回到现有的环境。在迁移过程中不会删除源域中的任何对象。如果需要还原，那么，可以通过手动操作，或者使用ADMT v2 Undo Wizard，逆向执行最后一次的迁移操作。可以运行Undo Wizard取消某个迁移工作的结果，也可以反向迁移用户、组和计算机。ADMT v2 Undo Wizard只能够撤销用户、组和计算机的迁移。在迁移过程中执行的任何安全性转换或者配置文件转换都不可逆转和撤销。
在迁移过程中需要加倍小心，例如执行一个“add”（添加）安全性函数，而不是替换ACL中的现有安全主体。
撤销域控制器
在所有的资源都从Windows NT 4.0域中迁移出去之后，应该完成帐户域的重建工作。为了完成帐户域的重建：
只需要管理Windows Server 2003目标域中的用户和组帐户。
在Windows NT 4.0资源域中保留两台可操作的域控制器，直到完成了域的所有重建操作。
对Windows NT 4.0资源域中的两台域控制器进行磁带备份，直到完成了域的所有重建操作。
在完成了Windows NT 4.0资源域的重建之后，便可以撤销Windows NT 4.0域了。
说明：确保为每个帐户域的PDC保留一份完整的系统备份。如果为每个帐户域保留了一份完整的系统备份，便可以重新让帐户域投入运行。
为了撤销Windows NT域：
1. 删除Windows NT 4.0域和目标域之间的所有信任关系。
2. 将现有的所有帐户域控制器改作其他用途。
3. 禁用在先前迁移步骤中创建的所有帐户，包括那些分配了管理权限的帐户。
迁移网络服务
在从Windows NT 4.0域迁移的时候，应该考虑到针对DNS、DHCP和WINS基础结构进行的修改（如果有）。
域名系统（DNS）
可以通过三种方法，将DNS服务从 Windows NT 4.0 Server迁移到运行Windows Server 2003 的DNS服务器。联机帮助的“迁移服务器：DNS”一节详细介绍了这些方法。这三种方法分别是：
1. 将DNS服务器从Windows NT 4.0就地升级到Windows Server 2003。
2. 您可以手动将DNS区域文件从运行DNS的服务器移动到Windows Server 2003 DNS 服务器。
3. 使用DNS复制将Windows NT 4.0的区域信息移动到运行DNS的 Windows Server 2003 服务器。
具体选择何种迁移方法取决于当前DNS服务器的硬件配置以及被迁移DNS服务的版本。例如，BIND DNS服务器的迁移就需要管理员使用上面列出的第二种或第三种方法进行迁移。
如果您拥有一个 Windows NT 4.0 DNS 服务器，那么应该使用就地升级方式，只要当前的硬件支持 Windows Server 2003，而该服务器在新的基础结构服务器中仍然作为DND服务器使用。这是最简单的迁移方法，而且是在服务器启动了Windows Server 2003安装程序之后自动完成的。此外，与该DNS服务器进行复制的服务器不需要升级，因为该服务器仍然是DNS基础结构的一部分。
DNS区域文件可以手动移植到Windows Server 2003 DNS服务器。这种方法的主要缺点在于，区域文件需要针对Windows Server 2003 DNS进行重命名，以便能够被识别。另外，手动编辑区域文件可能会破坏标准的记录格式，如果发生这种情况，DNS服务器会在加载该文件的时候发送一条错误信息。最后，根据具体的使用情况，新的DNS服务器需要将它的IP地址添加到相应位置的基础结构中。例如，需要修改客户端DNS解析程序的配置，或者修改转发者，委派记录也可能需要修改。
迁移DNS区域的第三种方法是通过DNS复制。新的DNS服务器被配置为每个待迁移区域的备用服务器。DNS服务器通过正常的DNS区域传输获得所有区域数据的一个副本。此时，服务器可以被配置为新的主服务器，可以对DNS基础结构进行相应配置，以便正确地使用新的DNS服务器。这种方法更加干净彻底，而且在操作上可能要比手动移动区域数据文件简单。
DHCP
迁移DHCP服务可以使用以下几种方法：
将DHCP服务器从 NT 4.0就地升级到 Windows Server 2003。
只导出NT 4.0 DHCP 配置，再导入到运行Windows Server 2003的新服务器上。
导出NT 4.0 DHCP配置和数据库；再导入到运行 Windows Server 2003的新服务器上。
如果Windows NT 4.0 DHCP 服务器的硬件可以支持Windows Server 2003，而且该服务器仍然在新的基础结构中作为DHCP服务器使用，那么应该使用就地升级方法。这是最简单的迁移方法，而且可以在运行Windows Server 2003安装程序之后自动完成。本方法对DHCP环境带来的影响最小。可以维持范围配置和与IP地址分配有关的信息。
第二种方法需要从运行DHCP的Windows NT 4.0服务器上导出DHCP的范围信息，再将信息导入到运行Windows Server 2003的新服务器中。这种方法不会迁移实际的IP分配信息。您应该认真规划这个过程，因为它可能会导致IP冲突和对网络连接造成不良影响。通过使用Windows Server 2003上的DHCP 租约时间和服务器端冲突检测，可以将此项修改带来的影响降至最小。例如，可以采取如下步骤：
1. 将被迁移范围的租约时间缩短到1天。在进行迁移之前，至少应当将租约时间缩短为当前时间的一半。例如，如果给定范围的租约时间为7天，在开始迁移之前，可以将它缩短到1天（至少3到4天）。
2. 从Windows NT 4.0服务器中导出范围。
3. 将范围导入到 Windows Server 2003上，但是不激活它们。重新为每个范围配置正确的租约时间。
在Windows Server 2003上配置服务器端的冲突检测。
在应该发生转变的时间，应该采取以下步骤：
1. 在NT 4.0的DHCP服务器上禁用范围。
2. 在Windows Server 2003 DHCP 服务器上启用范围。
3. 更新负责转发DHCP请求的路由器或服务器上的IPHelper地址。
在 X 时间后（X 时在NT 4.0 DHCP服务器范围上设置的临时租约时间），可以在Windows Server 2003服务器上进行服务器端冲突检测。
应该注意到，服务器端的冲突检测依靠Internet Control Message Protocol（ICMP）数据包才能正常发挥作用。如果ICMP被客户端或者路由器阻止，这种方法就会失败，因为DHCP分配的IP地址是已经分配过的地址。有关数据库导出和导入的具体步骤，请参阅“Microsoft Windows Server 2003 Deployment Kit”的“部署网络服务指南”中的“部署DHCP”一节。
第三种方法类似于上一种方法，但是它实际上将包含已分配IP地址的数据库也一起转移到了Windows Server 2003服务器。迁移服务的步骤如下所示：
1. 从Windows NT 4.0 DHCP服务器上导出DHCP配置。
2. 将DHCP配置导入到新的Windows Server 2003 DHCP服务器中。
3. 禁用Windows Server 2003 DHCP服务器上的范围。
4. 迁移DHCP知识库，具体步骤参见Microsoft知识库文章 Q130642：如何将DHCP数据库移动到另一台Windows服务器，地址：
support.microsoft.com/support/kb/articles/q130/6/42.asp&NoWebContent=1
5. 此时，应该进行交接（switch-over），应该采取以下步骤：
a. 禁用Windows NT 4.0 Server上的范围。
b. 启用Windows Server 2003 上的范围。
c. 更新转发DHCP请求的路由器或服务器上的IPHelper地址，或者将新的DHCP服务器的IP地址重新设置为原始DHCP服务器的IP地址。
这种方法无需进行冲突检测——如果禁用了ICMP，冲突检测会失败；而且无需修改范围配置。这并不能解决将多个数据库合并到一个数据库的问题，也不能解决范围合并的问题，也就是将一种分割的范围设计合并到一个单一的范围之中。
Windows Internet 命名服务（WINS）
可以使用以下三种方法之一，将WINS 服务从Windows NT 4.0 Server迁移到Windows Server 2003：
对WINS服务器执行从NT 4.0到Windows Server 2003的就地升级。
将Windows NT 4.0 WINS服务器数据库文件移动到一个运行Windows Server 2003的新服务器，然后升级数据库。
使用复制，将数据库信息从 Windows NT 4.0 WINS 服务器移动到运行WINS的新Windows Server 2003服务器。
具体选择哪一种方法主要取决于当前运行Windows NT 4.0 WINS服务的服务器是否在升级之后仍然会被用作环境中的WINS服务器。在选择一种迁移方法之前，应该评估当前的WINS实现方式，看看当前部署的基础结构是否能够满足企业的当前需要。例如，是否基于NetBIOS的系统（例如基于Windows 9x的操作系统或依赖NetBIOS的应用程序）已经被淘汰，或者当前的基础结构与负载相比是否已经过剩。如果是这种情况，应该在决定保留或删除哪些服务器之前设计一个新的基础结构。有关设计WINS服务器的具体方法，请参阅《 MSA 2.0 规划指南 》的“网络服务”一节，地址：
www.microsoft.com/technet/itsolutions/msa/default.asp
如果当前的硬件可以支持Windows Server 2003而且服务器在新的基础结构之中仍然作为一台WINS服务器使用，应该使用就地升级的迁移方式。这是最简单的迁移方式，因为在服务器上启动了Windows Server 2003安装程序之后，整个迁移过程是完全自动化的。此外，与WINS服务器进行复制的服务器不需要升级，因为该WINS服务器仍然是WINS基础结构的一部分。
如果服务器无法运行Windows Server 2003，或者服务器在新的环境中不再作为一台WINS服务器，那么应该选择不同的数据库迁移方法。
将数据库从运行WINS的 Windows NT 4.0 Server手动移动到Windows Server 2003 WINS服务器。这允许您将数据库移动到“退休”的Windows NT 4.0 WINS服务器上，然后在运行WINS的新的Windows Server 2003服务器上对其进行升级。您可以在运行Windows Server 2003的任何服务器上的联机帮助中找到执行上述操作的具体步骤。包含这些信息的页面题为“将WINS迁移到Windows Server 2003”，位于“实现WINS解决方案”一栏中。这种迁移方法与在就地升级过程中对数据库所执行的操作完全一样。此外，这种做法会产生一点网络流量，所有的处理工作都在新的WINS服务器上进行。该方法允许您迁移WINS服务器上的数据库，它可能藏在一个饱和的网络连接之后。但是，可能还需要进行其他配置，特别是复制伙伴关系和客户端TCP/IP WINS配置，以便新的WINS服务器可以使用正确的数据库信息进行名称解析。
迁移WINS的第三个方法是使用 WINS复制。新的 Windows Server 2003 WINS服务器被配置为现有Windows NT 4.0 WINS服务器的复制伙伴。新的WINS数据库通过正常的WINS复制过程来获得信息。与手动移动数据库一样，您可能需要执行附加的配置过程，特别是复制伙伴和客户端TCP/IP配置。本方法会在一段时间内产生一些网络流量；具体的时间长度取决于数据库的初始大小。在为初始复制选择复制伙伴时，应该将这些网络流量纳入考虑范围之内。例如，如果决定将新的WINS服务器配置为与同一个网络中的系统开展复制，或者与一个保护网络连接之后的系统进行复制，那么应该选择一个驻留在相同网络中的计算机。
保留校验用户功能
当迁移操作完成的时候，必须对用户功能进行验证。可以使用一个非管理用途的帐户进行测试，以确保用户能够登录到网络，访问主目录，访问相应的文件共享、打印机和商业应用程序。这些测试可以确保用户权限的正确设置，而且用户能够尽可能无缝地过渡到新系统。在测试中，您还可以执行名称解析测试。如果迁移的最终状态没有问题，还应该对能够访问Internet加以测试。
测试目录服务和新服务器
您的IT部门应该测试Active Directory服务的功能。这包括登录、查询Active Directory、添加用户帐户和添加安全组。此外，还包括测试从域控制器到域控制器的复制，检查站点、域和OU的权限分配。您应该确保网络服务均可操作——DHCP、DNS、WINS。如果迁移了文件和打印服务器，应该不仅检查它们的基本功能，对于打印机，还应该检查是否设置了具有“管理打印机”权限的本地用户。
确定迁移是否成功
作为最后一个步骤，应该重新阅读设想说明，并且确认预定的迁移目标都得到了满足。如果还留下一些重要的问题有待解决，那么应该如何解决它们？在所有问题被解决之后，主要出资人就可以签字确认项目结束了。
总结
现在，您已经决定了迁移路径，并且完成了所有的规划。规划工作的内容涉及决定在哪些域中执行就地升级，以及在哪些域中执行重建。此外，对于那些需要执行重建的域，您也考虑和规划了迁移期间维持用户及应用程序的访问这个问题。此外，您的规划还包括一份带有相关沟通计划的详细迁移日程，让迁移团队、支持队伍和用户了解迁移的进度安排以及迁移可能带来的影响。在执行了这些迁移步骤之后，您还需要为测试工作安排相应的时间和资源，确保迁移工作的连续进行，和避免出现不必要的还原操作。既然已经完成了迁移，那么您的迁移团队现在可以转向“后迁移”阶段了。
第9章 迁移后的工作
在成功进行迁移之后，还应该执行其他操作，确保新环境的连续操作，以及恢复迁移之前的现有在员。这些操作包括：监视、备份和恢复、以及撤除不再能够被新环境利用的硬件或改变硬件的用途。
监视合并后的环境
通过从Windows NT 4.0迁移到Windows Server 2003，您的机构可能合并了大量的服务器和域。合并可以减少系统的数量；所以合并后的服务可能会具有更高的弹性。您应该考虑购买一个操作管理产品（如果现在还没有使用此类产品的话）。操作管理产品可以帮助您有预见性地对环境加以监视。
Microsoft推出的Microsoft Operations Manager 2000具有企业级的操作管理能力，它提供了完善的事件管理、有预见性的监视和报警、报告以及趋势分析。该应用程序以管理包（Management Pack）的形式提供了包罗万象的产品支持知识库，是降低与Windows IT基础结构的应用和服务有关的日常支持成本的一把利器。Microsoft Operations Manager 2000 Management Packs 提供了保证任务关键级应用程序和系统（例如您的目录服务）顺畅运营所需的操作知识。
确认备份和恢复过程
在完成了向Windows Server 2003 Active Directory的迁移之后，应该对备份和恢复系统以及相关操作流程加以检查。不应该仅仅保证新的Windows Server 2003域控制器能够按照预定日程进行备份，还应该测试和验证这些备份，确保在未来需要的时候能够正常使用。为了彻底测试备份，应该对恢复过程执行测试。
让源服务器“退休”或另作他途
在合并了源服务器之后，可能会发现应该让这些服务器 “退休”了，并且淘汰原有的硬件，或者将其用作他途。应该考虑执行以下步骤之一，撤换所有的源服务器：
使用监视系统，删除服务器及其应用程序
将源服务器从域中断开（如果该服务器为一台成员服务器）
删除源服务器在域中的帐户
删除磁盘上的所有数据；如果源服务器包含敏感数据，应该考虑用其他数据多次覆盖磁盘上的数据
淘汰或者重新利用服务器硬件
获得反馈和不断改进
在实施迁移之后，应该收集所有用户和主要出资人的反馈意见。应当汇总反馈结果并形成报告。请试着完成此工作，因为您总是会遗漏某些事情，并且可以做得更好。在迁移过程中，您可能会发现一些问题和一些在未来的项目中能够加以改进的地方——请以文档形式记录这些问题和可供改进之处。如果发现了一些潜在的风险，应该利用新信息更新风险评估文档。在MSF和MOF中，这个过程被称作“Post-Implementation Review”（实施后的审查）。
Post-Implementation Review 让团队和企业管理人员能够评估项目是否达到了预期的目标，以及是否应该采取更进一步的措施。评估可以得出以下三个结果之一：
项目是成功的；它满足了预定目标。
项目已经完成；某些功能和目标没有实现。当前状态对于商业运营和IT操作来说也可以接受。无需采取进一步的工作。
项目已经完成；某些功能或目标没有实现，而这些目标仍然需要被实现。应该启动一个新项目或者一个修改请求，解决遗留下来的未完成目标。
总结
在迁移项目完成之后，您需要修改业务流程和操作步骤，以便于成功管理和监视新的IT环境。在大多数情况下，您应该执行一些测试，包括本章建议的一些测试。因为迁移的起始状态对于每个机构来说都各不相同，应该考虑执行其他测试，确保项目的最终迁移状态满足您的特殊需要。在验证了基本功能之后，您可能希望建立一个有预见性的监视解决方案。Windows Server 2003中的备份和恢复过程与您的现有系统具有显著的不同。应该对新环境的备份和恢复步骤加以验证。在确认新的IT基础结构能够按照预期正常工作之后，可以将注意力转移到删除冗余的旧服务器这一工作上。在完成了Post-Implementation Review 之后，项目便可以结束了，每个人都需要签字，确认迁移项目成功完成。
第 10 章 总结
《迁移规划指南》是为目前仍在使用Windows NT 4.0但是考虑迁移到Windows Server 2003的IT机构撰写的系列最佳实践指南中的一篇。《迁移和合并概述》文档是本文档的前一篇，它介绍了在准备迁移一个Windows NT 4.0域环境时需要掌握的知识和信息。本指南，即规划指南，着重介绍了在开始迁移之前和执行迁移过程中规划人员所面临的各项选择。
本文档在Microsoft Operations Framework（MOF）框架——Microsoft用来为Microsoft操作环境提供最佳实践的生命周期框架——之内为用户提供了指导。MOF得到了采纳，并且改编自British IT Infrastructure Library——独立于平台的IT最佳实践指南的世界标准。由于这个系列的文档关注于迁移和合并方面的最佳实践，我们使用了MOF作为介绍迁移过程的框架。
本指南首先定义了指南的目标读者，以及在阅读本文之前应该具有的知识水平，然后介绍了执行迁移或合并的理由。在决定进行迁移之后，便可以开始迁移过程了。为了成功进行迁移，需要理解商业目标。这意味着必须对迁移的目标、需要达到的最终状态有一个非常清楚的认识。这些目标与迁移团队在迁移过程中所要实现的目标截然不同。文章对两种类型的目标都进行了介绍。在确定了目标之后，就可以开始考虑将Windows NT 4.0域迁移到Windows Server 2003域所使用的具体方法了。
指南介绍了两种主要的方法——就地升级和重建，以及如何结合使用这两种方法实现最终的商业目标。在确定了具体的迁移方法后，指南继续介绍有助于实现成功迁移的过程，包括评估当前环境和预迁移规划。只有当所有适当的预迁移工作完成之后，才应该开始执行迁移。第8章详细描述了在设计域的迁移策略时可供挑选的选项。在完成了迁移过程并且在Windows Server 2003域环境中得到了成功部署后，还有一些Post-Implementation Review工作需要完成。迁移之后的审查工作对是否需要进一步的操作来满足商业目标加以评估，其目的在于闭合整个规划循环。