域服务器合并与迁移解决方案加速器：从Windows NT 4.0到Windows Server 2003--规划指南
Posted on 2004-11-08 17:17 mahq 阅读(2549) 评论(0) 收藏 举报
规划指南
域服务器合并与迁移解决方案加速器：从Windows NT 4.0到Windows Server 2003
本文档所提供的信息（包括引用的URL及其它Internert网站）均可能在不予通知的情况下发生变更。用户所面临的全部风险或因使用本文档导致的后果均由用户自行承担。
除非另有说明，本文档用来举例的公司、机构、产品、域名、电子邮件地址、徽标、人员、场所及事件均纯属虚构。请不要将它们推想或引申为任何真实的公司、机构、产品、域名、电子邮件地址、徽标、人员、场所及事件。
遵守所有适用版权法律是文档使用者所应承担的义务。Microsoft公司虽未在版权保护下就与本文档相关的权利做出任何限定，但是，任何人未经Microsoft公司书面授权许可，均不得出于任何目的、以任何形式、利用任何手段（电子、机械、影印、录音等）将本文档的任何组成部分制作成拷贝、存储或引入检索系统、亦或向任何对象进行传送。
Microsoft公司可能就本文档所涉及的主题拥有专利、专利申请、商标、版权或其它形式的知识产权。除非已同Microsoft公司签订书面许可协议，并根据协议条款获得明确授权，任何出示本文档的行为均无法使您具备针对上述专利、商标、版权或其它知识产权加以利用的许可权限。
© 2004年，Microsoft公司。版权所有，保留所有权利。
Microsoft、Active Directory、Windows、Windows 2000、Windows 98、Windows NT和Windows XP均系Microsoft公司在美国和/或其它国家所拥有的注册商标或商标。
本文档所涉及的其它公司和产品的真实名称均为其各自所有者持有的商标。
Microsoft Corporation • One Microsoft Way • Redmond, WA 98052-6399 • USA 00
目录
Microsoft Operations Framework (MOF)
将 Exchange 对象放置到 Active Directory 中
Windows Server 2003 中的“Pre-Windows 2000 Compatible Access”组
Windows Server 2003 域中的 Windows 95 或 Windows NT 4.0 客户端
配置Pre-Windows 2000 Compatible Access
第 1 章 引言
本文档为有关域的迁移或合并的常见概念和注意事项提供了一个面向过程的指南。本指南立足于所有可能的选择，而不是在特定机构中可以考虑的迁移选项。这意味着，您在此处看到的内容只是您在从 Windows NT® 4.0 环境迁移到 Windows Server™ 2003 环境时可能做出的选择。
注意： 本文档使用“Windows Server 2003”指代除Windows Server 2003 Web Server 版（该版本不能作为域控制器使用，故此排除在外）之外的所有 Windows Server 2003 版本 。
本文档介绍了从 Windows NT 4.0 迁移到 Windows Server 2003 的过程。在附带的《域的合并和迁移实现指南》中，您会看到一个用于演示该过程的示例性应用。这个指南同样也介绍了上述迁移过程，只不过它侧重于信息技术（IT）部门在面对本文档所描述的选项时应该如何进行选择。当然对较大型的公司而言，您可能会选择仅对一部分域进行升级，而对其它的域进行重建。
本章介绍了使用 Microsoft® Operations Framework（MOF）和 Microsoft Solutions Framework（MSF）执行迁移和（或）合并的具体过程，从而满足了在《域的合并和迁移概述》指南中所介绍的商业需求。下一章介绍了迁移和合并的优点以及项目团队在迁移期间的目标。本指南随后介绍了主要的迁移和合并选项，然后是为了实现成功的迁移需要进行的步骤和建议方法。迁移过程的第一步是评估当前的环境，并且分析 Windows NT 4.0 环境的不足和迁移到 Windows Server 2003 所能实现的优点。
然后，本指南根据最佳实践，详细介绍了从 Windows NT 4.0 域迁移到 Windows Server 2003 Active Directory® 时（其中包括网络服务的迁移）在概念和注意事项上的一些可用选择。
在了解了可以采用的选项后，您需要设计测试环境，然后根据您的 选择开始迁移过程。
Microsoft Operations Framework (MOF)
Microsoft 很早就认识到，当前在 IT 服务管理方面的行业最佳实践文献中，最优秀的当属英国政府商务署 (OGC) 制订的 IT Infrastructure Library（ITIL，IT 基础结构库）。但是，该规范侧重于服务管理和商业。
OGC 编撰委员会为此与全球知名的 IT 公司进行了密切合作，共同编制和校核了 IT 服务管理实践中的最佳规范。ITIL 当前包含七种核心出版物，此外还有一系列补充性的专门出版物。核心 ITIL 文集包括： Service Support（服务支持）、Service Delivery（服务递送）、Planning to Implement Service Management（服务管理的实现规划）、Information and Communication Technology (ICT) Infrastructure Management（信息和通讯技术基础结构管理）、Security Management（安全性管理）、Application Management and The Business Perspective（应用管理和商业前景）。由于该规范与平台无关，因此，往往会针对特定的操作环境采用 ITIL 规范，然后根据具体的平台和产品对其进行改编。
MOF 扩展了 ITIL 服务管理的最佳实践，以适用于各种商业情境下的 Microsoft 平台。为了支持分布式 IT 环境和当前的行业标准（如应用程序托管、移动设备计算和基于 Web 的事务系统和电子商务系统，MOF 扩展了 ITIL 的实践代码。由于 MOF 往往会用于各种商业情境，因此本指南介绍了在 MOF 上下文中实现平滑迁移的步骤和章程。
本指南是为那些参与域的最终设计和 Active Directory 设计——包括域名系统 (DNS)、动态主机配置协议 (DHCP) 和 Windows® Internet 名称服务（WINS）等辅助性服务——的人员编写的。因此，IT 管理负责人、负责 Windows Server 2003 Active Directory 迁移任务的团队以及任何参与基础结构设计的人员都应阅读本指南。迁移团队的任何人都可以阅读本指南，从而了解选择某个选项的原因所在。
本文档假定您是 Windows Server 2003 或 Windows® 2000 的 Microsoft 认证系统工程师 （MCSE），并且至少有两年的实际经验。此外，还假定您对商业的需求和不足之处有充分的把握，并且对可用于域的迁移或合并资源有良好了解。对商业需求胸有成竹，就可以根据自己的特定环境来权衡正反两方面的意见；对商业不足之处有良好把握，就可以根据商业要求实现正确的资源分配。资源不仅包括员工，而且还包括时间、设备和资金。
由于本指南介绍了 MOF 上下文中的最佳迁移步骤和过程，并且使用了来自 MOF 的概念和术语，因此您可以从本指南汲取更大的价值，并且实现对 MOF 的通透了解。在 Microsoft 网站的 MOF Resource Library（MOF 资源库）中可以找到 MOF Executive Overview（MOF 执行概述），其中对 MOF 进行了更高层次的介绍。请访问以下 URL：
如果希望获得更进一步的了解，请阅读有关流程模型、团队模型和风险管理的其他白皮书。
Windows Server 2003 的功能和优点
当前任何使用 Windows NT 4.0 的机构在升级到 Windows Server 2003 操作系统家族后，都将可以享受到超强的稳定性和新集成的一系列功能。Microsoft 在开发 Windows Server 2003 时考虑了如何让该操作系统实现与 Windows NT Server 4.0 的良好共存，因此各个机构可以方便地享受新操作系统带来的优点。
Windows Server 2003 提供了超强的可靠性（当然还包括更好的内存管理和对程序内核的其它改善），仅仅该功能一项就足以成为大多数机构的升级理由。有关 Windows Server 2003 功能和优点的进一步信息，请访问下列 URL：
www.microsoft.com/windowsserver2003/evaluation/features/default.mspx
ADMT v2： Active Directory Migration Tool，版本 2。它是 Microsoft提供的一个工具，旨在帮助管理员执行迁移任务。借助它，管理员不必购买第三方工具即可执行多种迁移任务。版本 2 添加了 GUI 功能。该工具可通过 GUI（图形用户界面）使用，也可以通过脚本使用。版本 2 还添加了迁移用户密码的能力。
克隆： 在本指南中，“克隆”一词是指复制某一个域的安全主体然后在另一个域中创建这些安全主体的过程。借此，管理员可以新建域环境并对其进行测试，而不失去原始域的任何功能。
合并： 在本指南中，“合并”一词是指将两个或多个域的对象组合成一个域的操作。Windows NT 4.0 存在一个限制，即保存安全主体的数据库只能保存 40,000 个对象（数据库的容量上限为 40 MB）。在因为此限制而对 Windows NT 4.0 域环境进行迁移时，通常会发生该操作。合并服务器的含义还可能是：减少执行某个任务或支持某个应用的服务器的数量。
DNS： 域名系统。在 Internet 上使用的名称解析系统。
IT： 信息技术。该词用来表示同计算机（有时还包括移动通讯）有关的一切内容。
ITIL： Information Technology Infrastructure Library（信息技术基础结构库）。ITIL 是一组已公布的准则，描述了通用的 IT 最佳实践方法。该规范同平台无关，其重点在“服务支持”和“服务交付”方面，并且没有涉及特定平台的操作规范。通常需要在该规范的基础上进行改编。
迁移： 在本指南中，“迁移”一词是指将某一个域的安全主体转移到其它域的工作。这同“克隆”形成了对比，后者是在另外的域中创建原始安全主体的副本。
MOF： Microsoft Operations Framework。这是 Microsoft 为成功运转使用 Microsoft 产品的 IT系统而采纳和改编的规范。它使用了在“流程模型”中介绍的 IT 生命周期方法，带有 20 种服务管理功能（Service Management Function，SMF）和四种业务运营管理审查（Operations Management Review）。它有四种业务运营管理审查。另外还有一个作为补充的“团队模型”和一个“风险管理规则”。
源域： 本指南中，“源域”即指原始域。在介绍迁移和合并时都会使用该术语。对应的域为“目标域”。
目标域： 本指南中，“目标域”即指转移或复制安全主体的目的地域。该域通常是经过升级或新建的 Windows Server 2003 域，因为 Windows Server 2003 域可以在它们的 Active Directory 数据库中包含数以百万计的对象。
WINS： Windows Internet 名称服务。这是 Windows Server 2000 家族之前的 Microsoft 系统使用的 Microsoft NetBIOS 名称服务。使用 Windows Server 2000 产品家族后，仍然需要使用 WINS，因为许多应用程序都依靠 WINS 进行名称解析。
第 2 章 域合并和域迁移的优点
在域合并和域迁移项目的规划阶段，应该同时考虑商业需求和 IT 需求。如果以 IT 目标和商业目标为中心，可以实现更为成功的技术部署。
当使用 ITIL（IT 基础结构库）或 MOF 流程来评估 IT 环境的任何变动时，这种变动的主要目标应该符合商业需求。因此，当对从 Windows NT 到 Windows Server 2003 的迁移进行评估时，分析过程的第一步必须着眼于那些迫使您（作为 IT 专业人员）考虑迁移的商业动机。
商业需求可能是由多种因素推动的，包括需要更为安全或更为可靠的 IT 环境、需要降低成本或降低风险等。一个引发操作系统升级需求的常见原因是：业务系统需要一个新的应用程序或新版本的应用程序，但该版本的应用程序只能在新版本的操作系统上安装和运行。如果供应商停止支持 IT 基础结构中的某个项目（硬件或软件），通常也会导致需要升级，即使此前并未发生任何事故或问题。您的升级决定应该来源于您对潜在问题的风险评估。决策者可以将停留在目前水平所可能导致的损失同升级和避免这种损失所带来的益处进行对比。
随着 IT 环境变得日益复杂，以及您的业务对 IT 系统服务的依赖性逐渐增大，您的业务面临 IT 问题的机会将增加。这为升级到 Windows Server 2003 提供了另一个理由 —— 这种新的操作系统允许 IT 设施执行更多任务，并且变得更为方便、更为安全，而且一旦发生灾难，可以更为迅速地实现恢复。IT 设施可以更好地支持业务系统因此也就成为迁移到 Windows Server 2003 的另一个商业动机。您还可以从 IT 体系本身来确定升级到 Windows Server 2003 的商业需求，比如借助技术上的改进，IT 体系将可以使用更少的服务器、更少的员工来提供同水平或更高水平的服务。
IT 推动力
负责 IT 基础结构的部门在评估服务器合并和整合的必要性时，相应的理由通常来自该部门自身。但是，这些部门应该首先审视的是商业上的需求。如果 IT 部门使用 Microsoft 的 MOF 流程模型，它将很自然地发现首先评估的将是商业上的需求，然后才是 IT 基础结构可以通过升级获得哪些好处。
商业－ IT 关系和 MOF
在给定的商业需求下，IT 部门必须考虑如何才能最好地满足这些需求。当前的大多数商业机构都要求增加服务，同时削减成本。尽管这些要求在某些情况下都是不现实的，但通过实施 MOF 流程和不断地改进流程和过程，IT 部门可以提供更高水平和更为可靠的服务。另外，如果 IT 部门在评估过程中多同商业经理沟通，则它不仅能更有效地向业务领域靠拢，而且还可以通过在 IT 方面的投资获得更为强劲的商业环境。如果商业经理按照 MOF 的要求介入了每一个业务运营管理审查流程，他们的需求将可以按照所审核的服务水平协议（SLA）、按照建议、重要程度和安排上的变化以及按实现目标得到满足和重视。如果商业经理看不到 IT 投资的必要性或好处，在制订预算时，他们可能会更为挑剔和更为积极地争抢预算指标。如果 IT 改造的动力源于商业原因，需要这些改造的商业经理会拥护 IT 预算要求，因为这可以提供或改进他们所急需的服务。
由于 Windows NT 4.0 的支持生命期已非常有限，因此在使用该操作系统时，商业部门所面临的风险也是 IT 部门所面临的风险。IT 风险是：如果商业部门选择继续使用 Windows NT 4.0，则商业部门对 IT 部门的要求会更高，而此时 IT 部门正面临着削减成本的压力。随着硬件的过时，以及随着各种应用程序纷纷升级到需要新型操作系统的版本，IT 基础结构将显得落后于时代。供应商不再努力为 Windows NT 4.0 等操作系统提供专用的软件或硬件驱动程序。当供应商转移到新操作系统时，IT 专业人员也是如此。一旦公司的 IT 部门面临人事调整，招聘精通 Windows NT 4.0 的员工将十分困难，因此您的 IT 基础结构将难以正常有效地提供商业支持。
您需要立足于当前 Windows NT 4.0 环境的不足来考虑迁移到 Windows Server 2003 后带来的商业优势。随着管理压力的增大，您可能考虑如何才能减少 IT 部门管理的服务器数量，因而削减支持成本并且减少对物理空间的要求。减少服务器数量不仅可以减少服务支持时间，同时还可以实现其它方面的改进。如果域的管理不是分布式的（由 Windows NT 4.0 的多域环境造成），而是集中的，并且只需少量管理员就可以管理合并后的域，您会意识到这些好处。
合并后的环境将需要更少的管理员，比如在整个域策略的制订方面。在单一域环境中，IT 管理员只需使用组策略在域级别实施一次公司策略即可，这不仅确保了一致性，而且还加快和简化了实施步骤。您还可以看到，通过合并服务器以及域，IT 员工可以对不断变化的商业环境做出更快的响应。原因很简单，因为一个复杂程度低的 IT 环境将更易于管理。另外，单从减少了域和域管理员的数量来看，安全性也会得到提高，因为您在安全方面要配置的域管理员和域的数量都得到了降低。
从多域的 Windows NT 4.0 环境迁移到 Windows Server 2003 Active Directory 环境后，可以实现许多颇富意义的改进。通过这种迁移，可以实现域的合并，并因而减少需要维护的域控制器数量。通过服务器合并可以减少要支持的服务器数量，可以更轻松地保证各个服务器都具有标准化的设置和标准化的流程。这二者使得您可以更容易地部署、管理和维护服务器。由于这种环境要求的人力更少并且可以从中央位置执行更为简化的流程，因此将更易于管理。IT 环境的复杂程度降低，还使得您在发生站点或服务器故障时可以更快速、更简便地实现灾难恢复。
借助良好的风险管理体制，您可以在一个整合的环境中更轻松地防范服务器故障，因为随着单点失败隐患的减少，您的规划和员工可以更加具有针对性。在合并服务器后可以更容易地制订高可用性规划，因为需要故障转移保护的服务器数量更少。您的风险评估要考虑因为单点失败隐患减少而导致风险升高的问题，因为它们的影响面扩大了。换言之，一方面是可能发生故障的服务器数量减少了，另一方面是任何关键任务服务器的故障都将可能对业务造成更为广泛和深远的影响。
在将域合并和迁移到 Windows Server 2003 域环境后，域控制器故障的影响会变弱，因为当前环境中的域控制器可使用多主控复制功能。在 Windows NT 4.0 域中，如果主域控制器 (PDC) 失败，将无法对帐户数据库进行任何更改，即使在配备有备份域控制器（BDC）的环境中身份验证仍然可以正常工作。
迁移到 Windows Server 2003 后，还可以使用 Active Directory 组策略获得增强的安全性。在 Window Server 2003 下，您可以创建并集中管理组策略。通过创建更为简单、更为合理的安全组体系，可以简化对资源访问权限的管理。在实现迁移之前，可以对在 Windows NT 4.0 域中创建的组进行简化和清理，也可以将所有组迁移，然后在迁移后简化这些组的结构。排除多用户域后，通常会使用户组数量减少。
评估域迁移的价值时，首先应着眼于商业需求以及在保持现状情况下会存在哪些商业风险。这种评估必须有商业经理和 IT 管理人员的介入。要了解哪些人员应该参与该项评估，请参阅 MOF 团队模型白皮书。如果让每一个团队角色都派一名代表参与，可以更有效地确定和评估与是否进行迁移有关的重要商业风险和重大商业价值。确定了迁移到 Windows Server 2003 的商业需求后，您可以放心大胆地执行迁移过程，因为您知道您的计划是基于最充分的考虑做出的。
第 3 章 域合并和域迁移的目标
通常应该考虑两种类型的目标，即迁移期间的项目目标和迁移之后的目标，这两个目标相互重叠又相互影响。
同迁移项目及其步骤有关的目标可分为人员、过程和技术方面的目标。
在人员方面的迁移过程目标可分为对最终用户的影响、对管理员的影响以及对 IT 人员的影响。这些影响同规划期间的选择有关，但同迁移项目的复杂程度无关。您可能希望考虑以下目标：
· 一致的用户体验。
· 不增加管理工作的复杂程度，否则需要额外的管理员。
· 明晰的角色和责任。
· 达成团队共识
最终用户的体验应该保持一致，并且可控制。如果选择了域合并而且在域合并过程中发生了名称冲突，某些用户的登录名可能需要更改。从一个域转移到另一个域的用户帐户也将具有新的登录域。这些细微变化不应对业务产生过大的影响。对于受到影响的最终用户，应该为其提供最起码的培训，并且需要配备某些专职的支持服务人员。
迁移到 Windows Server 2003 后，可以选择将 Windows NT 4.0 的多域体系合并为单一域。如果这样，则需要对项目进行周密规划，以确保每一个迁移阶段及其相关的其它工作职责都能分配给管理人员。根据商业和 IT 体系制订迁移过程、周密设计和检验该过程以及做到职责分明，可以确保当前的管理人员能在迁移后适应 Windows Server 2003 的管理工作。
为了确保每个迁移步骤都按正确的序列和相应的位置执行，不仅需要计划详细的操作步骤，而且必须明确地分配每一个步骤和任务。就此而言，在风险评估过程中应该指定后备人员，以便在正选人员缺席时有人接替其工作。您还必须就迁移过程所引发的问题设计问题提交流程。
最后一个人员方面的迁移目标是达成共识。整个团队需要了解团队在迁移期间的目标以及迁移目标：公司为何希望迁移到 Windows Server 2003。每个团队成员能否了解他对于整个项目获得成功而肩负的责任，将直接影响项目的成败与否，迁移过程的任何一个环节失败，都可能导致整个迁移项目的失败。基于共识的团队精神、合作和工作热情将意味着整个迁移项目可以在职责分明的前提下平稳进行。
一旦商业管理层和 IT 管理层决定需要迁移到 Windows Server 2003，您就拥有了在 MOF 中所说的变动请求（Request for Change，RFC）。此时，在给定的资源和所需变动的复杂程度下，您要针对该迁移实施某些项目管理流程。Microsoft 为项目开发和部署提供了完备的框架，即 Microsoft Solutions Framework。同 MOF 一样，该框架也提供了一个生命周期模型，并且集成了团队模型和风险管理规定。
简而言之，MSF 生命周期涵盖了从预测到规划直至开发、稳定性测试和部署的整个项目阶段。由于对项目（比如迁移）使用了结构化的方法，因此不论使用 MSF 还是使用其它手段，您都可以增大实现平稳部署的机会，从而确保同商业需求一致。它减少了因不可预计的问题导致迁移延期或受到损害的几率。该框架在动态的机制中集成了 MOF 生命周期，您可以在得到核准的情况下采取变动措施并且管理流程，从而保证开发和部署的平稳性以及符合商业需求和尽量避免意想不到的后果。
迁移过程的目标非常简单，就是要保证迁移的平稳性和正确性。您可以将这些目标细分为以下目标：
· 确保迁移过程不会影响商业。
· 尽量减少整个迁移过程中的停机时间。
· 实现迁移流程和任务的自动化。
· 保持良好沟通。
您可以并且应该考虑人员、过程和技术上的特定目标。
由于迁移项目的主要目标是增强业务服务，因此在迁移过程中出现任何本可避免的服务降级都是您不愿看到的。这意味着需要周密评估迁移过程对服务和基础结构的影响。就像您将看到的，迁移项目的启动阶段将包括一个环境评估过程，这为您了解迁移活动可以动用的能量提供了丰富的参考信息。此外，在规划阶段，您的计划方案需要有商业经理的参与和首肯，这样不仅可让您的团队注意到那些通常不应损害的商业活动（比如季度末的业务运行），而且还可以让他们对那些本来不会引起 IT 部门关注的特定事件保持警惕。
毫无疑问的是，在规划迁移、安排流程以及明晰责任时必须牢记，整个迁移过程必须避免停机或尽量减少停机。如果在规划时安排了一定量的停机时间，则可能导致停机时间远远超出计划的长度。这可能意味着，您必须杜绝停机要求，并且被迫选择其它的迁移手段。
流程和任务的自动化有助于实现更为平稳的迁移，因为只有这样，才可以完善地定义和测试流程。此外，这还可以将由于个别决定而导致的变动减小到最低程度。
在下节中，您将了解到如何实现角色和职责的明晰化。如果团队成员知道需要同谁以及在什么时候沟通，则可以更为容易地实现畅通的交流。重要的是，不仅要让整个团队对项目进度了如指掌，而且还要将这些信息传达给用户群体和商业经理。只要坚持项目管理规定（如 MSF）及其内部和外部约束条件，即可保证信息的透明性以及能将信息传达给相应的人员或受众。
就像对基础结构进行的任何重大变动一样，迁移过程也会产生技术问题。从商业的角度看，迁移的目标可能是为了降低成本。勿庸置疑的是，只要选择了对域进行合并，就可能遇到技术性问题。这些问题的范围非常广泛，从由于仅需要更少的域控制器而要求对硬件和基础结构进行变动，直到那些只会在迁移过程中遇到的归属性问题，无所不包。某些问题只有在迁移用户和其它安全主体时才会碰到，而有些问题会在选择升级一个或多个域时引发。
为了对域帐户数据库进行更改，多域环境中的每个 Windows NT 4.0 域都必须有一个 PDC。修改的内容包括：用户更改密码、管理员添加用户帐户、添加计算机帐户、添加安全组或更改安全组的隶属关系。为了防止 PDC 在升级过程中变得临时不可用，每个域还应拥有进行身份验证的 BDC。在完成了升级过程后，尤其是在选择了合并域的时候，可以发现系统管理变得更为容易，并且业务流程也变得简化。但是，随着这些流程变化，您需要更新业务流程的规范，因为 Windows NT 4.0 的流程说明已不能满足新的情况。
项目前景声明的目的是设置项目的高级发展方向。通过对任何产品类型都使用“产品前景”（product mindset）的概念，您可以限定和管理作用范围，并且利用重点的项目管理技术。这将确保在解决方案的实现和部署方面获得更大程度的成功。使用这类方法时，第一步是确定“前景”。在一开始就制订前景声明，将有助于确定最终的结果。如果您和您的团队不知目标为何，您将无法衡量您的成功。如果没有前景声明，您的团队将无法确定迁移项目是否已完成。借助前景声明，您可以清晰定义项目的时间框架和迁移项目团队的职责范围。这有助于将迁移或合并过程中的项目职责变动同项目团队隔离开来。如果商业管理层或 IT 管理层可以向一个项目中添加任务，您将发现该项目很难完成。
因此，您的前景声明必须清晰，不能过于冗长。以下示例表明了一个清晰的迁移项目前景声明：
“在支持整个机构实现目录服务的目标中，域合并项目将提供可靠、有效和集中的目录服务解决方案，该项目是将来其它项目的基础”。
正如前文所说的，一个优秀的规划过程将包括风险评估。MOF 拥有自己所关联的风险管理规定，后者同其它风险管理实践类似。无论您在启动迁移项目之前进行了何种风险评估，您都必须随着项目的发展对它们进行反复评估。虽然一个公司在商业和 IT 环境方面的风险会同其它公司不同，但就项目流程自身而言，不论选择升级还是重新构造和迁移安全主体，它们都具有某些固有风险。
在执行目录服务迁移和合并时，您可能面临以下（但不限于）潜在困难和阻力：
· 领导能力、政策性和组织性挑战：
· 缺少高级管理层的支持和积极参与。
· 领导能力较差或临时性的领导。
· 服务内容同高级管理层的期望存在差距。
· 难以转移到其它的成本分配或费用缩减的方法。
· 业务部门和开发部门如何选择和分配服务器和域的归属。
· 用户对于将要实现的服务存在不同的认识。
· 服务用户和业务部门认识到控制权和灵活性将丧失。
· 财务挑战：
· 如果需要，必须权衡投资新型服务器硬件的性价比。
· 架构和技术上的事宜：
· 服务能力的更为集中，导致风险增大和对该服务的依赖性更大。
· 对网络服务的可靠性、可恢复性和性能有更高要求。
· 迁移整合的目录服务时具有更大的错误风险。
· 应用程序版本冲突和客户端共存问题。
· 运营上的挑战：
· 损失了经验丰富的员工或关键性员工。
· 更为严格的变更管理，妨害了服务灵活性。
· 服务部门的标准实施情况较差，导致没有提供充分的帮助。
从项目审批到前景预测，从每个项目阶段直至项目的全部完成，您都需要对以上各个风险进行评估。通过对迁移或合并项目中面临的风险进行评估，可以明确地向利害关系人传达所存在的挑战和难点。通过同利害关系人探讨这些风险，并且向他们提供相应对策（如果在某些情况下补救措施的成本过于高昂，可能承担该风险），您会获得业务部门对风险抑制计划的支持。您还应该允许业务部门根据自己的认识提出他们认为最重要的风险，这样，可以正确安排风险抑制工作的轻重缓急。如果项目遭受无法预见的挫折，则相应的后果会由所有参与风险规划的人员共同承担。通过同利害关系人以及商业经理等不断对风险进行重新评估，可以确保项目计划和风险抑制工作是以商业需求为中心的。有关风险评估 的详细信息，请参阅 MOF 白皮书的风险管理部分。地址：
www.microsoft.com/technet/itsolutions/tandp/opex/mofrl/MOFRisk.asp
同迁移项目相关的财务目标及其过程可分为人员、技术和配套设备上的节省目标。
如果选择需要合并的域的数量，可以减少域控制器的数量。而域控制器的减少又可以减少硬件和备份服务器的维护以及服务包和热修补程序的维护工作，这些可以减少必需的域管理员的人数。
合理安排负责提供域服务的服务器的数量，从而用更少、更大型的服务器来完成相应工作，从而提高硬件的利用水平——这将有助于降低存储成本。在计算成本节省时，必须考虑待合并服务器的当前使用情况。通过合并减少服务器的数量，可以降低租赁或折旧成本。
域控制器的减少又可以减少硬件和备份服务器的维护以及服务包和热修补程序的维护工作。通过减少服务器数量，可以降低备份存储成本和提高硬件的利用率。
域控制器的减少，意味着所使用的服务器软件许可证、防病毒软件许可证以及备份软件也将减少。
通过减少数据中心的服务器数量，可以节省室内空间和降低成本。同时所需的支持硬件也更少，例如服务器机架、键盘/视频/鼠标交换设备 (KVM) 以及空气管理设备等。
运营目标集中在 MOF 的服务管理功能（SMF）上，比如变更管理、配置管理和可用性。
如果决定实现更为正规的变更管理，您将发现在一个简化的环境中更容易达到该目标。在复杂的环境中，若要实现良好的变更管理，您必须对角色和流程进行精细的定义。
如果您拥有某种水平的配置管理，迁移过程可能会使配置管理数据库 (CMDB) 的问题暴露出来。那些未经授权的变更将必须经过复审并且必须完成变更管理流程，目的是保证将来的 CMDB 能够反映现存的 IT 基础结构。
如果尚未拥有完备的 CMDB，您可以借助迁移创建一个 CMDB 或者对已有数据库进行改进。所有的项目文件都可以作为该 CMDB 的信息来源。如果已拥有完善的变更管理流程，您可以在迁移期间这样做，否则请在迁移之后执行该任务。
您已经知道，域数量的减少可以促成更为简单的管理。这种整合将影响 IT 业务的方方面面，包括容量管理、可用性管理和服务连续性管理。
由于用户和资源驻留在经过合并的 Active Directory 森林环境中，因此迁移后的服务故障可能具有更大的影响面。即使这样，服务合并的主要目标之一仍是提供高可用性。Windows Server 2003 借助于现代化的硬件，可为实现高可用性的目录服务提供多种技术，包括多主控 Active Directory 复制、存储区域网络 (SAN) 支持、不间断电源 (UPS) 支持以及在电源和网络组件方面的冗余支持。
在早期版本的 Windows NT 4.0 服务器中，只有一个域控制器（PDC）可以接受对域数据库的更新。在具有大型网络的机构中，该限制使得 PDC 的高可用性难以确保，因为在发生网络故障时，负责网络某一部分的管理员无法对域进行更新。Active Directory 域支持多主控复制，从而可同步每个域控制器上的数据，并且动态地确保信息的一致性。多主控复制功能可在对等的域控制器之间复制 Active Directory 信息，因此每个域控制器都有一个可读写的活动目录副本。
对具有多个域、域控制器和站点，或者由于提供关键业务应用而经受不起服务中断带来的生产能力丧失的大型机构而言，它们必须使用企业级的监视解决方案，比如 Microsoft Operations Manager（MOM）。为确保 Active Directory 的方方面面都能正常工作，请使用最适合您要求的监视解决方案来监视重要的表象。MOM 可以监视所有的重要表象。在生产环境中部署监视解决方案之前，请首先对其进行测试。
许多用户均坦承：安全性目的是推动他们迁移和合并目录服务的主要动力之一。目录服务合并为清理过时对象、实现更高强度的身份验证和减少通过委派授权而产生的特权帐户数量提供了良机。
在迁移期间必须坚持安全策略，并且不能由于安全管理方面的弱化而使现有环境受到威胁。随着迁移的继续，Windows Server 2003 的许多新的安全功能都可以被采纳。通过相互间的身份验证，客户端现在可以首先校验服务器的身份，然后再向它传输敏感数据。借助公钥安全性支持，用户可以使用智能卡登录，而不是使用密码。通过集成目录服务，可以更好地管理业务增长、控制安全性和控制信息访问能力，并且可以对不断变化的商业需求做出快速响应。
合并后的目录服务需要根据当前和今后的身份验证要求提供相应的容量。容量监控应该着眼于模拟将来在目录复制和用户需求（比如改进目录查询速度）方面的走向。
容量监控需要涵盖为用户提供的所有“端到端”服务。丰富的性能数据有助于管理员准确提供有关用户服务的报告。这一点非常关键，因为在合并某项服务时，用户会理所当然地认为他们将能获得更高质量的服务。
同 Windows NT 4.0 和 Windows 2000 Server 相比，Windows Server 2003 Active Directory 的容量和性能得到了大幅度改进。例如，Windows NT 4.0 中的安全帐户管理器 (SAM) 数据库存在每个域 40,000个对象的限制。而 Active Directory 可以轻松扩展到每个域数以百万计的对象。通常不必为了处理更多对象而创建额外的域。
在启动迁移或合并项目之前，首先需要确定这些项目将为机构带来哪些价值。如果没有清楚了解 IT 机构执行这些项目的动机，不仅项目团队可能失去工作重心，而且在项目规划阶段也可能遭遇严重的挑战。一旦了解了所希望实现的价值，就可以开始评估各种可帮助您达到目标的途径。在下一章中，您将了解域合并的选项以及有关从属服务和应用的选项。
第 4 章 迁移规划
随着启动从现有 Windows NT 4.0 域体系向 Windows Server 2003 Active Directory 迁移的规划，您必须了解和考虑哪些选项可供您实现这种迁移。在执行这种类型的迁移时，您还必须针对可能实现的合并考虑其各个环节并且做出相应规划。以下各节介绍了从 Windows NT 4.0 域迁移到 Active Directory 时的可用选项。
执行 Windows NT 4.0 域的就地升级是指通过在 Windows NT 4.0 域控制器上安装 Windows Server 2003 来创建 Active Directory 域。域的重建是指将 Windows NT 4.0 源域中的安全主体克隆到新建或经过升级的 Windows Server 2003 Active Directory 域中。为了实现最终的 Active Directory 功能，可能会同时执行升级和重建。
选项 1：就地升级
从本白皮书的目的来看，域的升级在定义上是指将以下对象上的 Windows NT 4.0 软件升级为 Windows Server 2003 的过程：域的 PDC、部分或所有 BDC。升级和合并的最大区别是：在升级中，您需要保持现有的域结构。
考虑就地升级时非常重要的一点是：了解对域控制器和安全主体的影响和变动。就地升级需要保持当前的配置，比如域的信任关系、用户、组和计算机帐户。它将保留包括现有域的 NetBIOS 名称在内的域结构。在保持 NetBIOS 名称方面，如果该名称已同您的机构无关或者从行政上说已经不正确，您仍然可以考虑以就地方式升级到 Windows Server 2003，因为可以使用具有 Windows Server 2003 功能级别的森林的域重命名功能来更改 NetBIOS 名称。有关 Windows Server 2003 域重命名功能的详细信息，请参考知识库文章 819145，地址：
support.microsoft.com/default.aspx?scid=kb;enus;819145&Product=winsvr2003 o
首先升级的服务器必须是 Windows NT 4.0 域的 PDC。该 PDC 在升级后仍然可以在剩余的 Windows NT 4.0 BDC 之间同步安全主体，此时，这些剩余的 Windows NT 4.0 BDC 会认为该 PDC 是复制的主控服务器。您可能会觉得在以下环境中进行域的升级是比较适当的：
· 现有的域符合新森林的要求：现有的域结构同待建 Active Directory 域的结构一致。此时执行升级将显得比较适宜，因为通过升级可以保持相同的结构，并且可以照搬现有域的安全主体和设置。
· 现有域的结构仍然适宜：现有的域结构仍然符合业务和技术上的要求。如果现有域符合业务部门的应用和网络要求，则可以使用升级方式将该域作为 Windows Server 2003 Active Directory 域使用。
· 需要实现最快捷的迁移：如果机构要求迁移到 Active Directory 的工作在尽可能短的时间内完成，则可以使用升级方式。域的升级是迁移到 Active Directory 的最快捷方式，因为这种迁移只需对 Windows NT 4.0 PDC 进行升级。
· NetBIOS 名称必须保留：Windows NT 4.0 域的 NetBIOS 域名必须保留一致。如果机构不希望修改该域名，唯一可行的选项便是升级。
对 Windows NT 4.0 域执行就地升级的优点包括：
· 有效：由于保留了安全主体和系统设置，因此该选项最为有效和风险最小。
· 快捷：可以快速享受到 Windows Server 2003 和 Active Directory 的优点。.
· 权限得以保留：对网络资源（如应用数据和文件）的权限得以保留。
执行就地升级的不足之处在于：
· 最新的域结构不适宜：如果域的配置（包括 NetBIOS 名称）不再与机构有关，在就地升级期间将无法更改这些配置。当然，在该域已迁移到 Windows Server 2003 功能级别后，可以更改域名和配置。
· 造成用户不便：用户在升级 PDC 期间无法更改其域密码。如果他们的密码将在 PDC 升级过程中失效，用户在此期间将无法登录该域。
第二种方法调整域的结构。该方法是指将 Windows NT 4.0 域的安全主体复制或克隆到新建或已升级的 Windows Server 2003 Active Directory 域中。这种使用 ADMT（Active Directory Migration Tool）等工具进行的帐户克隆没有破坏性，也就是说，Windows NT 4.0 源域的帐户将完好如初地保留。
对迁移项目而言，在三种情况下需要执行域的重建：
1. 在已经完成了域的升级后：在完成升级后紧接着要求进行域重建是执行域重建的最常见原因。也就是说，迁移的第一个阶段是将帐户域升级，第二个阶段是通过重建从资源域中获取帐户资源（因此，该资源域的使命也将终止）。
2. 作为域升级的替代办法：在考虑了迁移选项后，某些机构可能决定将现有的 Windows NT 4.0 域的结构重新调整为新设计和构造的 Windows Server 2003森林和域。在这种情况下，重建将作为主要的迁移技术，现有 Windows NT 4.0 域的安全主体将被迁移到新的 Windows Server 2003 环境（因此，Windows NT 4.0 帐户域和资源域的使命也将终止）。
3. 在升级到 Windows Server 2003 Active Directory 之后：在成功迁移到 Windows Server 2003 Active Directory 结构后，可能要求执行重建（作为域的整个重新设计工作的一部分）。当机构变动或发生并购或资产分离时，可能需要重新设计。
以下的图 1 显示了这三种需要执行域重建的情况：
图 1. 域结构的调整
ADMT v2 等用于实现域重建的工具可在无损伤的情况下将 Windows NT 4.0 源域的帐户克隆到 Windows Server 2003 Active Directory 目标域中。此外，借助 ADMT v2 帐户克隆功能，还可以在 Windows Server 2003 Active Directory 中创建新帐户和存储 Windows NT 4.0 源域帐户的安全标识符 (SID)。通过将 Windows NT 4.0 SID 存储在克隆后的 Windows Server 2003 帐户的 SIDHistory 属性中，可以在登录 Active Directory 时保持对 Windows NT 4.0 域的访问能力，这也为随着时间的推移而执行迁移过程创造了条件。
在以下情况中考虑进行域的重建可能比较适宜：
· 当前的域结构不符合迁移目标或机构的商业目标。
· 迁移的时间框架足够长，可以执行因为重建而导致的额外任务。
· 如果要在不升级先前 Windows NT 4.0 帐户的情况下考虑重建过程，必须购买额外的硬件才能构建纯粹的森林和域。
· 有足够的人力资源执行迁移。
· 在重建过程中，转换业务数据和共享资源的访问权限存在较高的复杂性和风险，对此您已经做好了准备。
与升级相比，域重建的优点是：
· 对最终的域结构具有更大的控制能力：在将现有域结构迁移到新建和新设计的域结构时，可以控制 Active Directory 的配置。
· 可保持迁移期间的访问能力：在执行分步迁移时，可以使用克隆的帐户以及 SIDHistory 属性保持访问能力。
同升级相比，域重建的不足之处在于：
· 时间框架较长：要克隆和迁移所有的帐户和资源可能需要更多的时间。
· 需要额外测试：所有驻留在源域中的服务器应用都需要进行测试，以验证它们在发生域变化后的效力。
· 迁移期间存在额外工作量：将服务器应用迁移到新的 Active Directory 域时，需要对域进行维护。
许多机构的迁移策略通常都组合了升级和重建两种方法：首先至少执行一个帐户域的升级，然后是 Windows NT 4.0 资源域的重建。通过采用这种迁移策略，机构不仅可以获得帐户域升级优点（比如时间短、风险小），并且还可以享受到重建的好处（域环境的简化）。
非常重要的一点是，注意区分物理合并、应用程序合并和位置合并三种选项。所有这些选项类型都可以节省拥有总成本 (TCO)，但原因各不相同。
通过合并服务器，可以减少用来提供服务的物理组件的数量，而这又可以降低成本和提高服务质量。企业用户发现，小型服务器资源的不断增长对商业是不利的，因为这些服务器需要经常性的维护成本，并且往往同商业活动无关。随着 Windows 服务器环境在支持技术上的进步，减少提供特定服务的系统的数量已变得正确且可行。
执行 Windows NT 4.0 域迁移时，服务器合并往往会通过将 Windows NT 4.0 资源域合并到 Active Directory 环境来实现。另外，由于 Windows Server 2003 Active Directory 域控制器的性能更高，因此它们可以处理更多数量的客户端身份验证，而这也为实现合并提供了机会。
本指南中，“应用合并”是指目录服务应用的合并。因此，此处的合并指得是将 Windows NT 4.0 域升级或重建为 Active Directory 森林。执行这种迁移过程后，Windows NT 4.0 域的数量将减少。例如，Windows NT 4.0 资源域可能被重建为 Active Directory 组织单位 (OU)。
在合并服务器时，可以选择是否减少用来提供服务器资源的站点的数量。位置合并提供了以下优点：
提高了物理意义上的安全性，降低了服务设备损坏的风险。
通过合并，减少了不值得配备支持人员的小型站点，从而降低了管理成本。
降低了与存储和备份要求对应的基础结构成本。
通过建立一个将支持人员和业务流程集成在一起的服务体系，促进了业务增长和商业灵活性。
位置合并包括重新设计目录服务体系（以减少物理站点的数量）和重新设计提供域控制器服务所需的数据线路。大多数同域有关的站点合并都包括转移域控制器及其支持体系（从地理上分散的位置转移到新位置或现有的区域性或全国性数据中心）。
本规划指南没有介绍域控制器的站点合并。有关域控制器布局的详细信息，请参阅 Windows Server 2003 虚拟会议：分支机构的部署，地址： www.microsoft.com/technet/prodtechnol/windowsserver2003/evaluate/technologies/deploy/VCON31.asp
通过本章，您了解了在规划 Windows NT 4.0 域的迁移时需要考虑的选项。在确定要使用的选项之前，您需要了解有关IT 基础结构的基本信息，包括网络架构、安全性、客户端和支持服务（支持服务包括备份和恢复服务、邮件、文件和打印服务）。一旦透彻了解了迁移的入手点，即可开始规划到 Windows Server 2003 域环境的迁移过程。
评估当前部署的企业环境有助于迁移决策的制订。通过考察当前环境中的内容，项目规划团队可以更有效地利用现有硬件，并根据实际情况做出购买新硬件或附加硬件的决定。
在开始详细规划迁移之前，您应该对多个环境进行评估和备案。这些环境包括：
目录服务基础结构。
网络基础结构。
安全性基础结构。
客户端环境。
备份和恢复的流程以及环境。
消息传递基础结构。
文件和打印基础结构。
商业和管理结构。
您可以用不同方式执行这种环境评估。一些供应商提供了自动化工具。借助这些工具，可以捕获现有网络及其相连系统的配置和安全设置信息。使用这些工具，并且同关键的 IT 人员交流，通常是非常有益的方法。本文稍后部分详细介绍了从不同方面评估当前环境的具体方法。您可以找到用于记录当前系统及其配置的检查清单。这些检查清单是 Windows Server 2003部署工具包的一个组件，地址：
www.microsoft.com/downloads
/details.aspx?FamilyID=edabb894-4290-406c-87d1-607a58fc81f0&DisplayLang=en
为了对机构内的当前环境进行最准确地评估，需要通过不同手段获取最丰富的信息。这些过程将在评估期间执行，包括使用自动化工具、工作表、模板以及与员工沟通。
机构的文化和管理结构对 IT 体系的设计具有重大影响。您的迁移团队能否了解这些独特的约束条件，将直接决定迁移规划之前的环境评估结果。要调查的环节包括：
管理职权的归属模型：有些机构将所有 IT 管理职权集中在一个部门中，而有些将管理职权委派或授权给区域性环节或各个业务部门。最为常见的方法是以上两者的组合：对某些 IT 功能（比如网络储备和安全）集中管理，同时将其它功能（比如用户帐户管理和邮件管理）分配到以地理或业务加以划分的区域机构。这些管理模型将影响您配置新域的管理组的方法。
用户帐户的管理模型：同网络管理一样，负责创建和删除用户帐户、管理密码、分配帐户资源等常见任务的模型可能是集中、非集中或这两者的组合。借助迁移，您可以转移到能更轻松地适应变化的结构，从而保证商业体系始终能面对将来的挑战。
业务部门结构：虽然不必费尽心思地探究业务部门或机构分支机构之间的相互关系，但对这些关系的某些方面进行审视仍将是有益的。例如：
各个独立的业务部门或分支机构之间是否需要有安全界限？如果需要，则要求一个多森林的设计，这同时还意味着需要考虑目录同步和信息交换。
不同的业务部门之间是否需要沟通？例如，整个机构是否需要有一个统一的目录或地址列表？不同的业务部门之间是否需要安排会议或其它形式的协作？如果需要，新的 Active Directory 设计将必须考虑和规划将来如何迁移到 Exchange Server 2003。
如何控制跨部门的通讯？换言之，哪个组将负责查找和解决那些妨碍不同部门的用户和资源进行相互通讯的身份验证、网络或协议问题？
业务部门的应用系统是否需要自己的用户目录？它们如何处理跨部门的访问？谁将管理这些目录？在元目录或跨目录连接或者在协调帐户和密码方面是否有值得考虑的事项？
在迁移规划期间，同任何技术性变动一样，您需要评估业务计划和安排，以便制订出能符合业务安排的项目时间表。在业务规划上需要收集和确认的信息包括：
在哪些业务时间段不能执行项目。除非重要的更新和变动，否则在这些时间中不能执行项目。例如，在一个财年的末尾。
其它已规划的技术或业务升级或变动。这包括影响技术环境的业务结构重大调整和重要的应用系统更新。
在制订任何详细的迁移规划之前，您必须对 Windows NT 4.0 域环境的某些配置进行评估。这些配置包括：
当前 的Windows 域、名称、大小、用途（帐户域或资源域）以及所有者。
域之间存在的信任关系和信任目录。
当前域控制器的配置和位置；它们在各个域中发挥哪些作用；它们的实际位置，升级到 Windows Server 2003 所要求的硬件规格，服务器提供的服务，当前操作系统版本和修补程序级别，以及其它已安装的应用程序。
商业系统当前如何使用目录服务，当前的目录服务结构是否存在问题或限制？
对网络基础结构和服务做出精确的评估将至关重要，因为您的商业部门要求目录服务和网络都能有效为客户端提供服务。
在网络基础结构方面要捕获的重要信息将包括：
机构物理站点的位置和数量。
各个位置的计算机和服务器的分布以及域成员关系
每个远程站点的用户数量和该站点通往企业网络中其余站点的链路速度。
物理站点同这些站点中所使用的IP 子网之间的拓扑映射，这在规划 Active Directory 站点设计时非常有用。
在更改或更新站点之间的网络链路方面是否存在非技术性的限制（包括地理、政策或成本上的限制）。
公司网络中是否使用了虚拟局域网 (VLAN)？如果是这样，这些 VLAN 的配置方式如何？
网络服务用于提供名称解析和 IP 配置信息，从而保证应用系统和基础结构能够正常工作。对任何目录服务升级或迁移项目都极为重要的网络服务包括 DNS、WINS 和 DHCP。为了提供名称解析服务，机构内普遍部署了 DNS 和 WINS。对 DNS 和 WINS 重要的评估信息包括：
谁负责名称解析服务？尤其是由谁来维护和管理机构的 DNS 服务器？
当前使用了是哪种类型的 DNS 软件？它是否可以处理 SRV 记录（这是 Windows 2000 Active Directory 以及更高版本所必需的）？
谁负责分配机构内的 DNS 名称和域？是否有一个统一部门专门负责 DNS 命名空间的规划和控制？
DNS 和 WINS 主机位于网络的什么位置？
是否存在任何终止使用 WINS 的计划？
哪些 DNS 服务器是客户端所使用的？
DHCP 是一种从中央服务器为客户端提供 IP 地址的服务。DHCP 主要用于机构内的工作站，作为服务器时则使用静态 IP 地址信息进行配置。在评估 DHCP 环境时应该考虑以下的配置项目：
DHCP 服务器的数量和位置。
通过 DHCP 分配的是何种名称解析模式（如果有的话）？
是否有子作用域？如果有，它们的位置如何，它们是在哪些 DHCP 服务器上配置的？
信息安全是个复杂的话题。您可能发现，确定当前环境的哪些安全信息有助于规划域的迁移或重建往往非常困难。您可以像 Microsoft 那样使用三种类别来分析安全问题：人员、过程和技术。基于这三个类别，可以对现有安全体系进行评估。
以下关于用户的问题有助于您组织您的安全体系：
当前使用的是哪种密码策略或限制？
是否在适当的地方使用了“两人负责制”的管理控制手段来防止单个管理员非法访问关键数据？
对于高价值资产是否提供了充分的物理性安全控制？
网络中是否使用了两种身份验证系统（例如，标准身份验证系统和 RSA SecurID）？如果是这样，则它们是仅局限于少部分群体还是普遍适用？
安全章程包括您用来实施或审核密码策略以确保一致性应用的安全步骤。您可能发现这些步骤和过程是通过多种方式（包括技术方式和管理方式）应用的。以下问题有助于您确定这些安全过程：
用于监视、检测和对入侵企图做出响应的系统都有哪些？谁负责监视这些系统？
是否存在补丁程序管理和分发系统？如果没有，关键级系统是否在补丁程序发行后的合理期限内应用了补丁程序？
是否使用 Windows NT 4.0 策略来应用安全策略？
机构是否需要遵守行业（如美国银行协会）或政府（如通用情况）的安全标准？如果需要，则已经对域体系进行了哪些修改来确保这种遵从性？
在变动成员身份之前，是否存在让服务的所有者批准特权组（管理员组）成员的过程？
在技术安全性上，您的主要关注的区域是域控制器（以及 DNS 服务器等目录服务基础结构服务器）。您应该考虑以下问题：
各个域中实施的是哪种 Windows NT 4.0 帐户策略？
哪些客户端设置是由 Windows 策略控制的？
为确保域控制器基础操作系统的安全，都采取了哪些措施？补丁程序和升级管理以及有效的配置跟踪将非常重要。详细信息，请访问以下地址：
www.microsoft.com/technet/security
要了解同服务器基线安全性相关的检查表，请访问以下地址：
www.microsoft.com/technet/security/tools/tools.asp
当前的信任关系如何？是否都是必需的？是否有任何信任关系削弱了 Windows NT 4.0 域模型的安全？
采取了哪些措施来防止域管理员以外的用户访问域控制器？
除上述问题外，MSA 实现工具箱 中的 MSA 2.0规划指南 还将与安全有关的企业服务分为了多种类别。目录服务类别是这些类别中最值得关注的。详细信息，请访问以下地址：
www.microsoft.com/technet/itsolutions/msa/msa20ik/VMHTMLPages/VMHtm2.asp
Microsoft 的“企业安全最佳实践”文档集包括几个白皮书。在评估机构现有的技术安全状态时，您可以利用这些白皮书所介绍的内容作为参考。详细信息，请访问以下地址：
www.microsoft.com/technet/security/bestprac/bpent/bpentsec.asp
您可能发现往往很难准确了解网络中使用的客户端的情况。对于管理严密的网络，往往使用 Microsoft Systems Management Server (SMS) 等清单和控制工具或脚本以及 Windows Management Instrumentation (WMI) 来了解现有系统的运行情况，以及这些系统的硬件和配置。对于管理较差的环境，其配置数据的更新情况可能不够精确或不够及时。客户端的情况是否精确，通常与域迁移的关系不大，但也有例外。这些例外包括：
现有多少台客户端计算机，它们在网络的什么位置？这两个因素会影响客户端计算机的迁移安排以及将客户端计算机迁移到 Windows Server 2003 Active Directory 环境使用的具体方法。
客户端正在运行哪些操作系统？某些较早版本的 Windows（比如 Windows 95 和 SP2 之前的 Windows NT 4.0）需要安装额外组件才能加入 Windows Server 2003 域。
是否存在重新部署、更新或更换客户端的计划？您的 IT 机构在域迁移之前、之中或之后可能有这样的计划。了解您将针对哪种情况做出部署规划是非常重要的。
是否有商业数据或用户数据存储在客户端计算机中？如果有，是哪些类型的数据？哪些客户端计算机使用本地存储？
对于该评估过程，应关注包括与现有域和支持设备的备份和恢复有关的系统和流程信息。您的备份系统可能是集中式的高级自动化系统或者本地管理的简单系统。高级系统可能是一个中央备份系统，可将多个服务器自动备份（通常借助 SAN 或专用于备份的局域网）到磁带设备上；而非集中式的本地管理系统可能是由技术型的最终用户操作的本地磁带驱动器。备份过程的差别也很大，具体情况取决于是进行详细、面面俱到的备份还是进行参考性的备份。MSA 参考架构工具箱 的“备份和恢复服务设计”介绍了备份系统的设计细节，但是如果需要更多地着眼于目录服务来进行评估，则要求研究以下主题：
需要备份哪些服务器？备份是集中的还是非集中的？
对于域控制器，需要备份哪些方面的系统数据？备份步骤、备份计划和备份类型（完全、仅系统数据、增量式）又该如何？
如何备份DNS、WINS 和 DHCP 服务器？是集中备份还是非集中备份？
保证备份成功的步骤是什么？谁执行这些步骤？换言之，由谁来对备份进行测试？按照何种计划执行？
如果存在消息环境，对其功能的评估将非常重要。本节之前的评估项目同消息传递系统所依赖的下级支持系统有关。这些项目包括：
当前服务器的配置和位置如何？服务器的物理位置如何？各个邮箱位于哪些服务器上，服务器之间如何联系？
如何同 Internet 交换邮件？
邮件服务器是否为 Windows NT 4.0 域的成员？服务帐户驻留在何处，它们要求怎样的权限？
对邮箱和服务器应用了何种级别的安全性？
随着目录服务的变化，您需要透彻了解文件和打印基础结构，以确保对业务数据的访问不会受到损害。您应该评估和备案的文件和打印服务信息包括：
现有文件和打印服务器的名称和位置如何？这些文件和打印服务器的域成员身份怎样？
文件和打印服务器的共享目录是什么？
共享目录、其它目录、文件和打印机的访问控制列表 (ACL) 如何？
目标状态评估必须立足于迁移的商业目标和 IT 目标。如果您的主要目标是合并，则这会驱使您对整个 Windows NT 4.0 域进行合并停止其使命。当成功达到目标状态时，即表明迁移或合并项目的结束。项目的作用范围决定了目标状态。您的目标状态可能同原始状态拥有相同数目的域。而另一方面，您也可能决定在该项目中合并若干数量的域。无论如何，您的目标状态都将由您的项目规划来确定。
但在迁移规划中，您需要致力于目标环境的设计、构建和测试事宜。这将包括新服务的设计、硬件选择和规划，以及测试标准。本指南没有对目标状态环境的设计、构建或测试加以介绍。有关设计、实现和配置目标状态的方法，请参阅 MSA 2.0 文档。MSA 2.0 文档为设计 Active Directory 森林和域模型、配置域控制器和网络服务以及它们的易管理性提供了指南。详细信息，请访问以下地址：
www.microsoft.com/technet/itsolutions/msa/default.asp
迁移到 Windows Server 2003 Active Directory 时，您需要规划如何放置来自 Windows NT 4.0 域的对象。此外还需要就管理和安全要求做出规划。Active Directory 的设计和用户、组和计算机的放置情况将影响 Windows NT 4.0 域的迁移过程。这种迁移过程还必须符合机构的商业目标。
利用迁移或合并项目提供的机会，您可以实施更为严格的安全策略（以创建和实现新的名称约定）和委派机构内的管理任务，前提是这些能改进对商业部门的服务。
规划目标状态的设计时应包括下列任务：
规划可将哪些 Windows NT 4.0 域升级或重建为 Active Directory 森林。
根据各个 Windows NT 4.0 域的角色，规划其迁移过程。
根据要支持的预期负载，规划域控制器硬件的容量。
规划网络服务的迁移过程，以支持 Windows Server 2003 平台。
为采用安全策略、委派管理和服务管理等事宜进行规划。
对该环境中的低层次工作站进行处理规划。
确定域迁移任务的角色和职责。
设计了目标状态后，您要确定目标状态是否符合迁移项目结束时应达到的目标。您将要：
确定目标状态是否符合在规划过程中制订的可用性目标。
确保目标状态能够按照客户端的需要提供相应的身份验证功能。
确保网络服务可为客户端提供对目标状态的访问能力。
确保资源的安全主体得到维护并且已同 Active Directory 关联。
确保已保留了对未迁移域的访问能力。
对 IT 体系当前状态的评估关系到能否正确规划迁移或合并项目。在确定所希望实现的最终迁移目标之前，您需要这方面的评估信息。您可能会发现，由于某些商业需求的存在，一些域必须保留，这意味着您需要执行就地升级。而在另外的情况中，您可以断定，通过更改目录服务结构的设计可以满足商业需求，而这将影响在迁移过程中采取的措施。评估的一个重点是，不仅要审视您当前的状态，而且还要评估“您希望在项目结束时达到何种状态”。为保证实际的迁移过程能够平稳和按时进行，可以在测试环境中执行各个迁移步骤，从而让您的 IT 团队和商业管理层有更大的把握。
在项目启动前需要进行适当的规划。这包括了解目录服务、消息服务、网络服务和客户端配置等环境的最终状态。除了基础结构的设计问题外，您还需要做出其它决定，包括使用何种工具、确定一个服务何时迁移以及整个项目所可能面临的风险。
目录服务是一个机构的技术基础结构中最重要的组件之一。目录是一种信息源，用于存储机构所关注的对象的信息。这些对象包括打印机、应用程序服务器、数据库、用户和组等。通过目录，可向那些希望查找和使用上述对象的用户提供信息，并且为管理员管理这些对象创造了条件。目录服务由目录和提供该目录信息的服务构成。目录服务可以：
实施管理员定义的安全水平，以保证入侵者不会损害信息的安全。
将目录分发到网络中的多个计算机。
复制目录，以便更多的用户能使用，并且防范故障。
将目录拆分成多个存储位置，以存储庞大数量的对象。
Window Server 2003 使用Active Directory作为它的目录服务。在机构中，Active Directory 的部署范围通常都非常广泛，因为它要包括众多对象的信息：机构内的用户和组（以实现业务数据和应用程序的安全）、待访问的计算机甚至应用数据（例如，邮件系统、商业应用系统的数据）。
机构的 Active Directory 设计必须着眼于下列环节：
规划森林和域的设计。
规划组织单位（OU）的结构。
规划 Active Directory 站点结构。
规划 DNS 环境来支持 Active Directory。
规划 Active Directory 域控制器的分布。
在执行任何目录服务设计项目之前，都必须首先确定目录服务的目标。这些目标必须源自商业和 IT 部门的要求，比如提供 Active Directory 服务的时间框架以及长期目标（如“使用管理委派增强安全性”）。
在 Windows Server 2003 环境中部署 Active Directory 之前，您必须根据您的环境来规划和设计 Active Directory 逻辑结构。Active Directory 逻辑结构确定了目录对象的组织方式，并且为管理网络帐户和共享资源提供了有效方法。对 Active Directory 逻辑结构的设计将是您定义机构的网络基础结构的重要组成部分。要设计 Active Directory 的逻辑结构，首先需要确定机构所要求的森林数目，随后是制订域、DNS 和组织单位的设计。
设计了 Active Directory 体系的逻辑结构之后，您必须设计网络的站点拓扑。站点拓扑是物理性网络的逻辑表示，它将被存储在 Active Directory 中。站点拓扑含有以下对象的信息：Active Directory 站点的位置、各个站点内的 Active Directory 域控制器以及支持在站点之间复制 Active Directory 的站点链路。
为了获得高效的 Active Directory 性能，您必须为每个站点确定适宜的域控制器数目，并且检查它们是否符合 Windows Server 2003 的硬件要求。对域控制器的容量进行周密规划，可以保证您不会低估硬件要求，否则可能导致域控制器的性能和应用响应时间不尽人意。
Windows Server 2003 Active Directory 的功能级别允许您实现新功能，比如在要求所有加入域或森林的域控制器都运行 Windows Server 2003 的架构和森林信任关系中，改进对组成员关系的属性和类进行的复制、停用和重新定义功能。Active Directory 设计过程的一部分是确定机构要求哪种水平的域（和森林）功能。要在机构中实现这些 Windows Server 2003 Active Directory 功能，您必须首先部署 Windows Server 2003 Active Directory，然后再将森林和域提升到相应的功能级别。
上一节介绍了设计 Active Directory 环境的基本准则。如果已经部署了 Active Directory，则需要了解现有的 Active Directory 结构以及 Exchange 将如何适应这种结构。如果尚未部署 Active Directory，您可以在考虑 Exchange 的前提下更好地设计 Active Directory 体系。
同早期版本的 Exchange 和 Windows NT 不同，Active Directory 仅含有一个具有默认用户属性和 Exchange 特定属性的对象。如果机构内包含早期版本的 Exchang，则在将该机构的用户对象添加到 Active Directory 中时，它们在 Active Directory 中将不包含特定于 Exchange 的属性。如果安装 Exchange Server 2003，Exchange 会扩展 Active Directory 中的用户对象，从而让其包括特定于 Exchange 的属性。
由于 Exchange 5.5 有自己的目录服务（默认情况下，该服务无法同 Active Directory 和 Exchange Server 2003 通讯），因此您还将需要引入 Active Directory Connector (ADC)。借助 Exchange Server 2003 ADC，可以在 Exchange 5.5 目录和 Active Directory 之间执行同步和通讯。ADC 可以用来自 Exchange 5.5 的邮箱、自定义收件人、分发列表和公共文件夹信息填充 Active Directory，并且保持这些信息的同步。同样道理，ADC 也可以用来自 Active Directory 的用户、联系人和组信息填充 Exchange 5.5 目录，并且保持信息的同步。
Active Directory 森林可能仅包括一个 Exchange 组织。原因是，所有身份验证都是在森林的边界执行的，并且全局地址列表 (GAL) 是根据 Global Catalog（全局编目）的内容构建的。该森林中的所有 Exchange 服务器都共享公共的安全上下文和 GAL。
各个 Active Directory 森林都可以包含一定数量的域。Exchange 配置数据的存储将作为森林的配置名称上下文的一部分进行，因此，Exchange 服务器可以位于任何域中，就如同用户帐户那样。借助 Global Catalog，Exchange 等支持目录的应用程序可以访问关于森林中所有域的信息。
要部署 Exchange，您首先需要有一个稳定工作的 Active Directory 体系。如果将从 Windows NT 4.0 环境升级，部署 Exchange 的最好时机是当所有 Windows NT 帐户和资源都已迁移到 Active Directory 时。当然，即使您正在将 Windows NT 对象迁移到 Active Directory，或者您需要保留 Windows NT 域以保持若干资源对象，您也可以部署 Exchange。
对当前使用 Exchange 5.5 的机构而言，最好不要基于现有的 Exchange 5.5 站点构建 Active Directory 结构。此时您应该根据所要求的管理模型来规划您的 Active Directory 环境。
实现 Exchange 同 Active Directory 的集成时，主要有四个选项：
单个森林。用户及其邮箱包含在同一个森林中。
专用的 Exchange 森林（资源森林）。专门使用一个森林来运行 Exchange 和寄存 Exchange 邮箱。同各个邮箱对应的用户帐户可以包含在一个或多个不同的森林中。
多个运行 Exchange 的森林（传统的多森林）。Exchange 在不同的森林中运行，但邮件功能可跨森林使用。
合并和获取。合并和获取（Mergers and acquisitions）通常是指 Exchange 组织并存，直到将它们合并。这种规划选项类似于多森林的情形，在迁移时都需要额外关注。
您可以参阅 Exchange 2000 的 Active Directory 设计最佳实践技术白皮书，地址：
go.microsoft.com/fwlink/?LinkId=17837
该白皮书针对 Exchange 2000，但其中的信息对 Exchange Server 2003 同样适用。
在迁移到 Exchange Server 2003 之前，请确保您的网络和服务器的系统符合下列要求：
拥有 Windows 2000 Server Service Pack 3 (SP3) Active Directory 或 Windows Server 2003 Active Directory。
可以通过网络访问 Active Directory 全局编录服务器，该服务器包括了所有的 Active Directory 站点。
在 Windows 2000 或 Windows Server 2003 站点中正确配置了 DNS 和 WINS。
已在 Exchange 5.5 组织和 Active Directory 域控制器之间建立了 NetBIOS、Remote Procedure Call (RPC) 和 TCP/IP 连接。
已备份了 Exchange 5.5 数据库，并且服务器运行的是 Windows 2000 或 Windows Server 2003。
为实现 Exchange 5.5 目录和 Active Directory 之间的同步，每个 Exchange 站点中至少有一台运行 Exchange 5.5 SP3 的服务器。
将 Exchange 对象放置到 Active Directory 中
组织单位 (OU) 为基于策略和管理方面的考虑而将相关的资源和帐户分组提供了简单途径。在引入 Exchange Server 2003 或 Active Directory Connector 之前，必须首先考虑 Active Directory 中的对象放置。对象类型（比如邮件用户列表、邮件安全列表和分发列表以及联系人）应位于 OU 中，这样可以方便地进行管理和应用组策略。
为了管理 Exchange 对象和用户（这是 Active Directory 管理员和 Exchange 管理员共同要求的），可能应该考虑创建额外的组织单位。在 Exchange 5.5 中，用户管理以站点为界限，在 Active Directory 中，用户管理的委派通常在组织单位的级别进行。您可以在各个森林中将管理 Windows Server 2003 和 Exchange 的资源组合在一起，也可以分别管理这些资源。Exchange 与 Windows Server 2003 的集成为上述组合提供了可能。
为支持 Exchange，请创建用来包含下述各个对象类型的组织单位：
Exchange 特定对象。
因为不匹配的 Active Directory Connector 复制而被禁用的对象
联系人
分发列表
隐藏的 Exchange 对象
Exchange 服务器的计算机帐户
许多机构会在开始部署 Active Directory 之后即决定扩展其 Active Directory 森林架构。如果您的机构正在计划部署扩展 Active Directory 架构的软件产品，比如 Exchange、SMS 和 Office Live Communications Server，您可能希望在一开始就扩展 Active Directory 架构，因为这样可以降低架构复制流量所带来的影响。
Exchange Server 2003 架构扩展可定义若干新的对象类型和属性。这些 Exchange 属性的数量、种类、数据类型和许可值由 Active Directory 架构定义（随其它的目录属性一起）。一个森林中有一个架构，后者由拥有特殊角色（架构主控）的域控制器维护。在安装 Exchange 的过程中，可通过添加与 Exchange 有关的属性来扩展 Active Directory 架构。Exchange Server 2003 部署指南 对这种森林的准备过程进行了更为详细的介绍。该指南位于 TechNet 的以下地址：
www.microsoft.com/technet/prodtechnol/exchange/Exchange2003/proddocs/library
/DepGuide.asp
这种扩展过程会永久性地更改架构，并且新的架构定义会被复制到 Exchange 组织中的其它全局编录服务器。基于这些原因，许多机构都将架构主控放在单独的 Active Directory 站点中，并且使用较长的复制周期。可以首先对变动进行测试，如果它们对其它系统造成了影响时能够恢复。
在 Windows 2000/XP Professional 提供的Active Directory 功能中，许多都是基于 Windows 95/98 和 Windows NT 4.0 的客户端所不具备的。Directory Services Client （目录服务客户端）是为 Windows® 95、Windows® 98 和 Windows NT 4.0 准备的升级或修补程序。您应该评估 Directory Services Client 软件包提供的功能，并且确定您所在机构的要求。Directory Services Client 软件包支持下述 Active Directory 功能：
站点感知。功能包括：可以登录到网络中离客户端最近的域控制器；可以在任何基于 Windows Server 2003 的域控制器（而不是 PDC 仿真设备）上更改密码。为了享受这种新功能，安装了该客户端扩展程序的计算机对象必须位于 Windows 2000 或 Windows Server 2003 域中。
Active Directory 服务接口 (ADSI)。ADSI 允许使用 Active Directory 脚本，并且为 Active Directory 编程人员提供了共同的应用编程接口 (API)。
分布式文件系统 (DFS) 容错客户端。提供了根据 Active Directory 指定的内容访问 Windows 2000 和 Windows Server 2003 DFS 容错和故障转移文件共享的能力。为了享受这种新功能，安装了该客户端扩展程序的计算机对象必须位于 Windows 2000 或 Windows Server 2003 域中。
Active Directory Windows 地址簿（WAB）属性页。允许具有相应权限的用户通过用户对象页更改用户对象的属性（比如，电话号码和地址）。单击“开始”菜单，然后指向“搜索用户”，可以访问用户对象页。其中还包括了对显示说明符（允许呈现在 Active Directory 中存储的与用户对象有关的新架构元素）的支持。
NTLM 版本 2 身份验证。该客户端扩展程序利用了 NTLM 版本 2 提供的增强身份验证功能。
规划 Active Directory 命名空间时，应同时做出 DNS 名称的规划。Active Directory 直接依赖于 DNS，因此规划不当的 DNS 体系可能对它造成负面影响。此外，所创建的 Active Directory 专用分区不应允许公共访问。如果规划不当，DNS 服务可能会将这些分区暴露给外界。
要实现有效的 DNS 服务，必须对以下问题做出选择：
命名空间的设计。
DNS 主机的位置。
一旦解决了这些问题，即可进行更详细的规划，尤其是在命名空间较为复杂时，比如企业所要求的命名空间。其它的设计问题还包括：
如何托管内部和外部的命名空间？
采用哪种 DNS 技术？
如何设计 DNS 分区？
如何确定对企业适宜的 DNS 服务器数量？
如何优化客户端的 DNS 查询，包括如何将名称解析查询转发给其它的名称服务器？
如何配置 DNS 同其它名称解析系统（如 WINS 和 DHCP 等其它技术）的互操作？
回答了这些问题后，您可以进入下述的设计决定环节并且选择对应的选项：
|
设计决策 |
设计选项 |
|
名称解析服务技术 |
1. 静态 HOSTS 文件 2. DNS 服务 |
|
命名空间设计 |
1. 使用单一的企业命名空间 2. 使用内部域作为子域 3. 内部和外部名称无关联 4. 内部和外部名称相同 |
|
DNS 托管 |
1. 外部根 2. 内部根 |
|
托管内部和外部命名空间 |
1. 完整 DNS 2. 拆分 DNS 3. 拆分 DNS 和拆分 DNS |
|
DNS 技术 |
1. 标准 DNS 2. 动态 DNS 3. 同 Active Directory 集成的 DNS 4. 同 Active Directory 集成的主分区和基于文件的辅助分区 |
|
要部署的 DNS 服务器数量 |
1. 一个分区一个 DNS 服务器 2. 一个 DNS 服务器，带有网络负载均衡功能 3. 每分区两个 DNS 服务器 4. 每分区多个 DNS 服务器 |
|
优化 DNS 查询 － 服务器配置 |
1. 委派 2. 转发 3. 辅助分区 |
|
DNS 安全策略 |
1. 低级 DNS 安全策略 2. 中级 DNS 安全策略 3. 高级 DNS 安全策略 |
表 1. DNS 设计决策和选项
确立了 NetBIOS 名称解析的要求之后，应该考虑若干会对设计造成影响的因素。要根据给定情况确定相应的配置，您应该考虑下列事项：
网络基础结构应满足何种可用性和伸缩性要求？
网络服务的哪些用户配置文件需要 NetBIOS 支持？例如，用户是否只是在上班时间访问资源？
哪些服务需要使用 NetBIOS？例如，是否只是为了支持文件和打印服务而需要 NetBIOS？
为IT 架构的管理使用何种基础结构？例如，是集中的还是分布式的？
通过上述信息可以定义相应的 NetBIOS 名称解析技术。如果选择了 WINS，则需要选择 WINS 复制方法。
|
设计决策 |
设计选项 |
|
NetBIOS 名称解析 |
1. 广播 2. LMHOSTS 文件 3. HOSTS 文件 4. DNS 5. WINS |
|
WINS 复制 |
1. Push 复制 2. Pull 复制 3. Push/Pull 复制 |
|
WINS 拓扑 |
1. 集中式 WINS 2. 全网格拓扑 3. 环形拓扑 4. 中心辐射式拓扑 |
|
可用性 |
1. WINS 群集 2. 冗余的 WINS 服务器 |
表 2. WINS 设计决定和选项
对特殊 的IP 地址分配和管理服务（比如 DHCP）的选择不能凭空进行。这应该是确定企业网络架构过程中的一个步骤。通常而言，DHCP 是大多数机构最适合的选项；然而，它不是唯一的。因此，首要步骤是确定最适宜的 IP 地址分配方法。
有关网络架构设计及其遵循的决定步骤的详细信息，请参考架构设计 指南的“MSA 网络架构”章节。地址：
www.microsoft.com/technet/itsolutions/msa/default.asp
确定了 IP 地址分配和管理要求后，可通过以下问题确定相应的配置：
网络基础结构必须满足何种可用性和伸缩性标准？
从要管理的 IP 地址来看，该环境的范围有多大？
可以使用哪些管理资源来管理选择的选项？
IT 架构的现有管理体系如何？例如，是集中式的还是分布式的？
通过这些信息可以定义相应的 IP 地址选项组合。
|
设计决策 |
设计选项 |
|
IP 地址管理 |
1. 手工配置 IP 地址 2. Bootstrap 协议 (BOOTP) 3. DHCP |
|
DHCP 可用性和容错 |
1. 拆分作用域 2. DHCP 群集 3. 备用服务器 |
|
可路由网络上的 DHCP |
1. 多个 DHCP 服务器 2. 路由器上的 BOOTP/DHCP 转发 3. BOOTP/DHCP 中继代理 4. 多宿主 DHCP 服务器 |
|
静态 IP 地址 |
1. 手工配置的静态地址 2. DHCP/BOOTP 保留 |
表 3. DHCP 设计决策和选项
第 6 章，服务设计指南的“网络服务”详细介绍了 DNS、WINS 和 DHCP 设计过程。此外，Windows Server 2003 开发工具箱 也含有这三个核心网络服务的设计信息。
详细信息，请访问以下 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 基础结构做出了针对迁移目标的决策。您已经重新评估了迁移风险，并且规划了风险防范对策。所有规划都已得到迁移团队关键成员和商业管理层的复审。一旦所有计划得到审阅和批准，即可开始执行迁移前任务。
为保证迁移的成功性，在执行迁移之前首先需要完成某些任务。其中包括技术上的特定考虑，比如清理域、创建用于恢复的备份和确保环境的安全。此外还应执行相应的沟通计划，以通知最终用户可能对他们带来影响的环境变化。
许多拥有 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 资源域到目标域必须存在单向信任，以便：
您可以迁移资源域中的服务帐户和本地用户配置文件。
区域域中的已迁移用户可以访问资源域中的资源。
在 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 Server 2003 Active Directory 之前，应该将前者暂时锁定。锁定 Windows NT 4.0 域意味着您的迁移团队将在升级开始之前指定一段时间，在这期间，无论是用户还是管理员都不能对帐户和 Windows NT 4.0 SAM 数据库进行任何更改。
对于域迁移，里程碑事件应该紧接在域同步和将用于恢复的 BDC 脱机之后。以此表示管理员在将 PDC 升级为 Windows Server 2003 和 Active Directory 之前，不会再发生任何域的变动。
到此，您已经完成了规划并且已开始执行迁移项目的初始步骤了。上文介绍的部分步骤（比如删除旧帐户）可以在迁移开始之前或在迁移之后执行。而有些步骤，比如密码迁移步骤，则要取决于您在密码迁移方面所做的决定：有些机构会选择迁移密码，而有些机构则不会。在域的升级方面，您必须安排一个锁定期。一旦完成了这些迁移前的准备工作，即可开始迁移组帐户和用户帐户。
迁移现有的域可以通过多种方式来实现。迁移规划团队需要针对现有的每一个域和服务创建具体的规划。所选的迁移和合并方法决定了需要执行的任务以及可能的迁移顺序。
域的迁移路径是指用来将 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 域执行就地升级，在准备升级该域时，您必须完成多个选择。
一个主要的规划要求是配置和检查对 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
除了上述的过载影响外，还必须考虑“堆积”现象（取决于待升级域的配置）。详细信息，请参阅 Microsoft 知识库文章 305027。地址：
support.microsoft.com/default.aspx?scid=kb;[LN];305027
在 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 升级为 Windows Server 2003 之前先将某个 BDC 脱机。作为测试，执行以下步骤（然后再开始迁移）：
· 让该 PDC 脱机并在迁移后可用，另外要确保对其余的 BDC 进行经常性的备份。
域的升级过程在设计上应尽可能多地保留当前环境，包括域结构。另一方面，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 之前操作系统的兼容访问）组的成员。
以下注册表值必须添加到源域的PDC中，以便实现TCP传输之上的RPC调用。请修改如下注册表键值，将DWORD 的值修改为1。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\TcpipClientSupport
无论从哪个方面来看，设置该值都不会损害系统的安全性。如果该值被创建或者被修改，源域控制器必须重新启动，让该设置生效。
出于审核的目的，必须在源域上建立一个名为<SrcDomainName>$$$的新的本地组。这个本地组的名称<SrcDomainName>$$$包括了源域的NetBIOS名以及三个美元符号（$），必须在迁移SIDHistory之前在源域控制器上创建该组。迁移操作所针对的每个源域用户和全局组都应该添加到该组中，然后从组的成员关系中删除。这样会在源域中产生“添加成员和删除成员”审核事件，可以搜索引用了该组名的事件来监视它。
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设计。可以使用“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 注册表条目。
必须在源域和目标域上都启用审核。
在就地升级过程中，域的安全主体被放置在默认容器（“用户和计算机”）中。在升级了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的计算机上得到处理，必须将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将确保文件从域中的所有域控制器上被删除。
对网络资源（打印机、文件、文件夹和共享）的访问要受包含在与每个资源相关联的安全描述符中的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服务从 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服务器从 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，冲突检测会失败；而且无需修改范围配置。这并不能解决将多个数据库合并到一个数据库的问题，也不能解决范围合并的问题，也就是将一种分割的范围设计合并到一个单一的范围之中。
可以使用以下三种方法之一，将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。如果迁移了文件和打印服务器，应该不仅检查它们的基本功能，对于打印机，还应该检查是否设置了具有“管理打印机”权限的本地用户。
作为最后一个步骤，应该重新阅读设想说明，并且确认预定的迁移目标都得到了满足。如果还留下一些重要的问题有待解决，那么应该如何解决它们？在所有问题被解决之后，主要出资人就可以签字确认项目结束了。
现在，您已经决定了迁移路径，并且完成了所有的规划。规划工作的内容涉及决定在哪些域中执行就地升级，以及在哪些域中执行重建。此外，对于那些需要执行重建的域，您也考虑和规划了迁移期间维持用户及应用程序的访问这个问题。此外，您的规划还包括一份带有相关沟通计划的详细迁移日程，让迁移团队、支持队伍和用户了解迁移的进度安排以及迁移可能带来的影响。在执行了这些迁移步骤之后，您还需要为测试工作安排相应的时间和资源，确保迁移工作的连续进行，和避免出现不必要的还原操作。既然已经完成了迁移，那么您的迁移团队现在可以转向“后迁移”阶段了。
在成功进行迁移之后，还应该执行其他操作，确保新环境的连续操作，以及恢复迁移之前的现有在员。这些操作包括：监视、备份和恢复、以及撤除不再能够被新环境利用的硬件或改变硬件的用途。
通过从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 之后，项目便可以结束了，每个人都需要签字，确认迁移项目成功完成。
《迁移规划指南》是为目前仍在使用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工作需要完成。迁移之后的审查工作对是否需要进一步的操作来满足商业目标加以评估，其目的在于闭合整个规划循环。
Windows Server 2003主页：
www.microsoft.com/windowsserver2003/default.mspx
Windows Server 2003 Deployment and Resource Kit:
www.microsoft.com/windows/reskits/default.asp
Windows Server 2003 Resource Kit Tools:
www.microsoft.com/downloads
/details.aspx?familyid=9d467a69-57ff-4ae7-96ee-b18c4790cffd&displaylang=en
浙公网安备 33010602011771号