Microsoft 的结构化 Active Directory 架构管理
创建一致、标准化的更改工作流
技术白皮书
本页内容
执行摘要Microsoft? Active Directory? (AD) 提供全局的标识和访问管理基础结构。此外，AD 提供一般目录功能和可扩展性，当开发中的应用程序需要目录功能时应用程序开发人员可以且应该利用这一点。使用 AD 功能对目录管理进行集中化并加以简化。AD 也可减少开发成本和增强数据的兼容性。例如，在应用程序中运用 AD 验证和授权服务互操作性即可实现上述的两个目标。它不要求创建额外的安全数据库并简化了企业安全管理。 要使用 AD 功能支持业务过程或新工具，应用程序开发人员需要扩展 AD 架构。该架构是一种 AD 组件，该组件定义目录服务用于存储数据的所有对象和属性。通常，由架构管理员独立进行架构更改，或者软件安装过程自动进行此类更改。Microsoft 建议制定更改管理系统，以提供最佳的架构更改结果。 本文借鉴了 Microsoft IT 部门通过结构化工作流管理 AD 架构更改流程的方法。结构化工作流可确保部署在林结构中的各个更改具有适合的设计、实施、用途、所有权和安全。Microsoft IT 的经验显示，基于 Microsoft? Operations Framework (MOF) 的稳定可靠、规划详细的更改管理系统有助于创建高度可管理的架构基础结构。使用 MOF，Microsoft IT 创建了包括五个阶段的流程，分别为论证、评估、测试、分段和实施里程碑。通过详细地规划和分段架构更改，在管理客户端通信和期望的同时，这五个阶段顺利地处理 AD 架构更改流程，并使对 AD 的风险降低到最小。通过提供一致且可以预见的流程，各方可将精力集中于实现业务目标。 如果企业对通过结构化工作流来确保各个架构更改的最佳结果感兴趣，则将从本文档中获益。本文是针对已经熟悉 Windows 功能、AD 和身份管理注意事项的 IT 专业人员、架构师和目录服务专业人员而撰写。通过本文可深入了解 Microsoft IT 架构更改管理解决方案。本文包括最佳实践、建议和部署注意事项。采纳者可以使用 Microsoft 产品，将更改管理设计建议、原理和技术应用于大多数企业级 IT 环境。但是，因为每个企业环境都是独一无二的，所以采纳者不应将本文用作程序性指导。每个组织应使以下信息适合其特定需要。 注意：出于安全原因，本文样例中使用的林结构名称、域名、内部资源名称、组织名称和内部开发的安全文件的名称，并不代表 Microsoft 内部使用的真实资源名称，它们仅供说明之用。 架构更改简介有经验的 Windows 应用程序开发人员创建需要目录功能的应用程序时会使用或扩展现有的 AD 功能。这包括身份管理、中央配置和访问管理，或一般目录功能。通过扩展或运用 AD 功能可使应用程序使用现有的安全子系统以及全局目录内的共享数据。因为这可实现资源效率的最大化，所以 Microsoft 建议使用或扩展现有的 AD 功能，而非在 AD 之外创建新标识数据库。 注意：扩展架构是指修改或更新架构的过程。 由于潜在的 AD 影响，所以确保架构更改不会带来意外结果是很重要的。企业可通过更改规划、测试和客户端期望管理顺利地执行架构更改。 架构基础该架构是一种 AD 组件，该组件定义目录服务用于存储数据的所有对象和属性。此目录服务使用对象作为存储单元。每次目录服务处理数据时，它都查询架构以获得相应的对象定义。根据架构中的对象定义，目录服务创建对象并存储数据。例如，管理员创建新用户对象时，AD 使用架构定义创建和配置默认的用户对象。架构的物理结构由存储在目录内各自架构分区中的对象定义组成。林结构中的所有域共享相同的架构。 对象定义控制对象可存储的数据类型以及数据语法。如图 1 所示，子类对象继承它们上面的类的特征。使用此信息，架构可确保所有对象均符合其标准定义。结果，AD 可存储、检索和验证它管理的数据，而不管生成该数据的应用程序。只有在架构中具有现有对象定义的数据才能存储在目录中。如果需要在目录中存储新的数据类型，架构管理员必须先在架构中创建新的数据对象定义。  图 1. 具有继承的架构对象类 架构修改通常，用户不每天与架构直接交互。AD 使用架构帮助创建存储在目录中的对象。用户与这些对象交互，而非架构。管理员在进行架构修改时，通过添加定义或通过修改现有定义直接与架构交互。因为访问控制列表 (ACL) 保护架构对象，所以只有经过授权的用户才能更改架构。 架构扩展默认架构是 AD 林结构提供的类和属性的基本集合。当架构中的现有类和属性定义不满足组织需要时，组织可添加或修改架构对象以扩展架构。有经验的开发人员可通过为现有类定义新类和新属性扩展架构，以在目录中存储新的信息类型。 架构管理员通常出于以下原因修改架构：
架构修改范围扩展架构属于高级操作，需要详细规划和测试。架构是林结构中 AD 的使用和操作的基础。因此，企业必须详细考虑对系统提供的基础架构所作的任何扩展或更改，以避免发生问题。架构更改可能会影响重要设置，如目录数据库索引、全局编录数据可用性和 AD 数据库大小和完整性。 一般来讲，恢复架构修改是不可能的。考虑更改时，有三个要点需要注意：
通过客户端通信和期望管理以及详细的架构更改规划和分段，管理员可顺利地处理 AD 架构更改流程，并使对 AD 的风险达到最小。 架构更改管理扩展架构执行起来既很强大也很容易。经过合理设计的更改管理系统有助于组织一致、可以预见地应用架构更改。结果，这使组织可以着重于业务或执行目标。对于组织而言，在扩展架构之前建立正式的架构更改管理流程是十分重要的。 流程设计设计精良的更改管理流程可提供确保最佳结果的标准工作流。如果具备了该流程，则责任和期望对于各方均清晰明确。该流程应提供完整工作流的详细说明。范围包括从初始更改请求发送直至确定向有关各方传送流程已成功完成的人员。 Microsoft IT 流程自从将 AD 目录服务部署为 Microsoft Windows 2000 Server 的一部分以来，Microsoft 一直通过使用 AD 功能支持 AD 和软件开发。因为 Microsoft 是一家软件开发公司，所以 AD 架构更改在 Microsoft 比在典型的企业客户站点更频繁。Microsoft 开发的软件通常使用 AD 功能。结果，内部 Microsoft IT 软件安装和测试经常涉及架构更改。而且，因为 Microsoft IT 在其生产环境中使用自己的测试版软件作为开发过程的一部分，所以他们不得不安装每个程序的多种预发行版本、过渡版本，每个版本均可能需要架构更新。 Microsoft IT 在过去的五年中至少已执行了 25 次唯一的架构更改，将其中的大多数部署到多个林结构。期间，他们创建了已随时间而演变为规范的更改流程的工作流。基于这种广泛的经验，Microsoft IT 对该工作流进行了标准化，使其成为了 Microsoft 内所有架构更改的正式更改管理系统。Microsoft IT 架构更改管理流程已帮助使架构更改实现了标准化，并通过主要软件新产品提供最佳结果，这些产品包括：
Microsoft Active Directory 环境要理解 Microsoft 中的架构更改流程，则有必要了解 AD 环境、它支持的“标识和访问管理”基础结构以及支持 AD 的团队。 基础结构概述Microsoft 标识和访问管理基础结构与其他大型企业组织环境相似。该基础结构提供对于 Microsoft 计算环境必不可少的服务集合。AD 是各个林结构中标识基础结构的基础。它提供集中的身份管理以使资源既可用又安全。该基础结构还充当 Microsoft 开发的预发行身份管理软件的试验场。 多林结构配置如图 2 所示，对多林结构的集中管理是 Microsoft 标识基础结构的一大特色。  图 2。Microsoft 标识基础结构组织 Microsoft IT 完全管理多个此类林结构。他们与各个林结构的技术团队合作共同管理其他林结构。每个林结构均与“企业林结构”共享单向或双向的信任。在 Microsoft，所用的应用程序中有 70％ 驻留在“企业林结构”中。此类林结构中的身份存储超过 35 个。这些身份存储包括 AD、SAP、Siebel、Group Membership Manager、Account Manager Application 及各种其他存储。Microsoft IT 身份管理团队使用 Microsoft Identity Integration Server (MIIS) 2003 以及用于在多身份存储间同步身份数据的 Service Pack 1 (SP1)。 在 Microsoft 需要多林结构有多个原因。开发中的软件应用程序（如 Exchange 的预发行版本）要求自己的林结构，以避免早期预发行部署和测试期间“企业林结构”的干扰。林结构的存在还出于通过外联网与外部合作伙伴合作时的安全考虑。此外，由于与 MSNBC 合资相关的法律要求，MSNBC 维护独立的林结构。最后，Microsoft IT 专门为公司内的各个业务部门（如 MSN 部门）创建了一些林结构。 网络配置Microsoft 在 Microsoft IT 所管理的五个林结构中在全球范围内拥有 215 个 DC。这包括超过 16 个域、138 个林结构 DC 和 30 个外联网 DC。有 184 个 AD 站点，其中 63 个配有 DC，这些站点每天处理 60,000 次唯一林结构登录。企业林结构拥有九个域，全部的对象超过 1 百万，全局编录文件的平均大小为 9.0 GB。该网络每秒提供的带宽平均为 1.5 MB，最小为 256 KB。 复制拓扑Microsoft IT 在站点间用五个中继段配置林结构以进行每小时的复制，这些站点提供最大为五个小时的端到端延时。他们在全世界通过超过 300 个站点维护匹配其网络拓扑的复杂站点拓扑。大部分的管理更改（包括所有架构更改）发生在美国华盛顿的 Redmond。Redmond 是最大延时为三个小时到任何其他站点的中点。 架构更改支持环境Microsoft IT 负责指导与在全球范围运行和维护 Microsoft 信息系统相关的所有活动。在 Microsoft IT 组织内，身份管理 (IdM) 团队和基础结构工程 (IEng) 团队负责 AD。IdM 团队负责跨林结构的身份管理，尤其是 AD 架构管理。IEng 团队则管理 DC 和复制。 Microsoft IT 组织Microsoft IT 负责驱动全局操作和将 IT 服务发送到整个 Microsoft 组织。Microsoft IT 指导与在全球范围运行和维护信息系统相关的所有活动。除企业和市场信息系统之外，他们还维护技术基础结构。这包括生产、分发和其他关键内部系统。Microsoft IT 致力于提供世界级的实用程序和业务操作典范。它通过在公司策略、流程和体系结构的设计和集成方面的领导地位来实现此目标。 Microsoft IT 提供各种服务，包括服务器和最终用户支持、通信管理、网络操作和信息安全。该角色包括管理全球范围内 300,000 多台个人计算机的连续。Microsoft IT 确保位于 90 个国家、400 多个 Microsoft 位置的超过 63,000 名的员工以及 35,000 位承包商和供应商，可每天 24 小时不间断地访问企业网络服务和资源。 因为 Microsoft 的主要业务是软件设计，所以 IT 拥有了全球供应商中独一无二的第二个使命。Microsoft IT 是公司技术的先行采纳者，负责在 Microsoft 产品向客户发布前对其进行测试和部署，例如，SharePoint?、Windows Server 2003、Microsoft Identity Integration Server 2003 和 Exchange Server 2003。这种预发行部署过程在 Microsoft 称作“吃自己的螃蟹”，简单说即“螃蟹”。 通过在 Microsoft 企业环境中使用预发行产品，Microsoft IT 彻底现场测试这些产品并对其商业价值进行评估。这有助于成形最终产品配置和发现指导客户进行产品部署的最佳实践。吃螃蟹式的严格企业测试环境使 Microsoft 可以自信地发行优质产品。根据此过程中获得的经验，产品组可以改进产品设计并提升最终版本的价值。 Microsoft IT 身份管理团队 (IdM)IdM 团队管理 Microsoft 身份管理基础结构。该团队管理所有相关的应用程序或工具、帐户和组以及工作流，以进行添加或更改。 IdM 团队管理所有的用户帐户。包括常规用户、提升的访问用户、服务帐户及内置帐户。他们还管理组（包括管理组）及相关的内部应用程序。此外，IdM 团队管理组织单位、组策略对象和信任。他们使用 MIIS 2003 SP1 监督林结构间的同步，以同步各种对象类型，包括用户和组、站点和子网以及打印机队列。用户在各种林结构间遍历时，这确保了一致的应用程序功能和资源使用。 IdM 团队的责任包括 AD 架构管理。因为 IdM 团队拥有目录的内容，所以他们在目录中将数据作为单个逻辑实例来管理。为维护林结构间的一致性，当 IdM 团队在某个林结构中更改架构时，他们通常也在所有其他林结构中更改架构。虽然 IdM 团队负责架构更改流程，但他们不管理该流程的每个方面。例如，他们实际上不管理 DC、复制拓扑或应用程序。IEng 团队和特定的应用程序所有者处理这些方面。 基础结构工程团队 (IEng)IEng 团队负责 Microsoft IT 的核心基础结构服务器，包括 AD 所驻留的 DC。该团队管理服务器性能、管理和配置。此外，IEng 团队还根据应用程序依赖关系和网络连接确定在网络上放置 DC 的位置。IEng 团队管理数据复制拓扑。他们在架构更改流程中负责数据复制拓扑。IEng 团队与 IdM 团队协作，以确保架构更改复制在他们管理的各个林结构中均成功。 Microsoft 架构管理在 Microsoft，软件开发是如此规模的架构更改的主要动因。每次业务单位安装或更新使用 AD 功能并修改架构的软件时，该单位均必须经历架构更改管理流程。Microsoft IT 通过在 Microsoft 生产环境中对各个产品团队的测试软件进行测试和评估来支持其开发工作。这种吃螃蟹式的测试和评估也使架构管理更为复杂，因为 Microsoft IT 经常在开发过程中安装多个过渡版本，这些版本可能会增加架构更改的次数。 更改管理系统IdM 团队设计了一个内部网站，该网站可指导任何请求架构更改的人员完成该流程。该站点提供流程概述、到相关信息的链接以及在线架构更改表单。请求者填写该表单，然后 IdM 团队对其进行检查。IdM 团队一旦确定请求者的表单填写正确且所有问题均已解决，他们即开始评估该业务论证。如果从业务角度考虑它是可以接受的，IdM 团队则将该请求放入更改队列。批准该请求表单后，他们创建架构数据包文档。架构数据包是一个活动文档，会从一开始即跟随该更改直至完成。IdM 团队输入所有其他数据，并在流程的每一步进行批准。当 IdM 团队对架构进行更改时，IEng 团队跟踪林结构中的复制并确保准确性。最后，IdM 团队将表单、脚本及所有相关的信息放入某个文件夹，然后将其存储在安全位置备份。 架构更改IdM 架构更改管理系统处理以下内容：
AD 性能AD 架构中未使用的定义不会影响 AD 性能。架构定义只会增加表大小，这一点与向数据库添加列类似。而且，架构定义不会明显增加文件的大小。在极个别的情况中，最显著的性能问题是某些架构管理工具的初始化稍有些慢。 更改管理系统体系结构考虑到 Microsoft 中的大量架构更改，实施合理的流程管理此类一直至关重要。Microsoft IT 使用 Microsoft Operations Framework (MOF) 作为其核心管理流程的基础。IdM 团队已采纳了在 MOF 中定义的更改管理流程，以管理架构更改请求、测试和实施。MOF 网站提供详细的 MOF 文档，其网址为 http://www.microsoft.com/mof。 IdM 团队的架构更改管理系统包括正式的流程、内部网站和更改管理文档。该流程定义了对 Microsoft 中的全部架构更改的管理。它详细说明了每个活动，从启动更改请求到宣布更改成功完成。IdM 团队通过利用内部网站作为管理全部架构更改的起点来强制此正式流程。该网站建立期望、回答常见问题 (FAQ) 并提供对在线更改请求表单的访问。此程序性文档提供标准工作流的结构并强制该正式流程。 架构所有权因为由于架构管理和修改带来的潜在影响，所以 IdM 团队控制 Microsoft 中的每个架构更改。该团队将架构作为单个实体来管理，累积所有架构更改。通过这种方式可以全面了解架构当前包含的全部架构元素以及其他更改的影响。 包括了解以下内容：
为维护此级别的了解，Microsoft IT 将进行架构更改的权限限制为 IdM 团队。作为看门人，IdM 团队通过有效管理所有架构更改确保 AD 架构性能。 更改策略为强制架构更改限制，Microsoft IT 将架构管理组的成员身份限制为 IdM 团队的成员。而且，IdM 团队仅临时将成员身份授予架构管理组，其时间仅够进行所批准的更改。否则，默认的架构管理组将保持为空。 IdM 团队有权设定策略，以确保使用架构更改管理系统、遵循适合的标准和设定期望。架构更改要求：
更改基础结构管理架构更改管理系统所需的基础结构是很小的。它由内部网站、IdM 团队和相应的测试环境组成。 内部网站IdM 团队创建了内部 Microsoft SharePoint 2003 网站。该网站提供 IdM 团队和架构更改请求者之间的协作界面。它是更改管理系统的起点。该流程从请求者通过在线表单提供所需信息的那一刻开始。IdM 团队实施在线表单，作为简单的 SharePoint 调查。该调查存储请求历史、启用修订和使用 SharePoint 警报机制以在发生更改时向该团队警报。IdM 团队捕获表单数据，以创建架构数据包文档。他们将该架构数据包文档维护为活动文档，并向其添加架构更改流程的每个步骤。该团队在 SharePoint 站点文档库内的项目文件夹中既维护表单也维护架构数据包文档。 IdM 团队IdM 团队收到并处理请求、检查所请求的更改、执行其自己的测试、提供相应的通信和实施更改。此过程需要访问 IdM 内部网站和 Microsoft Terminal Server 服务，而且需要访问驻留架构主列表“灵活单主机操作”(FSMO) 的 DC。它还需要具有 Schema Admin 权限的帐户和对任何所需测试环境的访问。高级技术专家执行全部的架构更改。 测试环境请求者必须测试全部的架构更改请求然后才能将其提交 IdM 团队。IdM 团队然后针对每个架构更改要求两个级别的测试。测试过程是循序渐进的，只有完成了上一步之后才能进行下一步。测试阶段包括实施测试和功能测试。 IdM 团队执行实施测试。他们先将架构更改加载到虚拟环境，然后移至实验室环境。在上述环境中的测试可暴露实施问题和命名冲突。IdM 始终使用新安装的 Windows Server 2003 配置虚拟环境，以测试系统冲突。此初始测试将验证架构更改的有效性。实验室环境包含在 Microsoft 所作的全部架构扩展，以便通过自定义或第三方扩展进行冲突测试。此第二个实施测试步骤将确定是否继续进行功能测试。 请求架构更改的团队通过将该架构更改加载到试验环境来执行功能测试。此过程允许应用程序所有者测试与更改相关的应用程序功能。试验环境是具有真实用户的受限生产林结构，这些用户依靠它们进行主要的网络访问。此过程将在受限生产环境中启动现场的应用程序测试。应用程序所有者管理该试验并判断它是否成功。 期望管理管理架构更改时，架构更改流程所涉及的主要有三方：请求方、IdM 团队和 IEng 团队。各方均有其各自的要求和责任以及不同的期望。这些期望包括（但不限于）计时、结果、责任和标准。为获得最佳结果，更改管理流程使上述不同的期望目标一致以减少混淆。IdM 团队通过从一开始即确保各方均彻底了解项目来实现此目的。从历史经验来看，更清楚、更完整的初始文档可简化流程和改进结果。Microsoft 已决定，为使期望目标一致和确保最佳结果，更改管理系统必须提供清楚的标准和过程、合理的期望以及表示清晰的时间线。 清楚的标准和过程为使三个团队顺利合作，必须先制定清楚的标准和过程。这些标准有助于消除意外，并可使流程顺利进行。IdM 团队在其内部网站中详细说明了架构更改标准。除提供流程的起点之外，该网站还提供完整的说明、策略和标准。一旦请求者完全了解了进行架构更改所需的标准，他们即可准备制定文档和提交请求。 合理的期望请求者必须完成要求的文档，并证明其目标合理且可以实现。此外，他们还必须详细说明和证明对 IdM 策略和标准的任何偏离。表单既要求业务论证也要求技术论证。 IdM 团队通常不会因为业务论证或技术论证的质量差而拒绝请求。作为顾问，他们运用此信息确定目标是否可以实现，解决方案是否为最佳。如果不是，IdM 团队则建议进行可改进结果的修改。这即消除了不必要的架构更改，或错误更改的请求。 表示清晰的时间线IdM 团队在网站上设定了期望，所有的标准更改从请求到实施至少需要七个星期，而且他们还概要介绍了该流程。这七个星期包括用于发现和检查的三个星期，和用于测试和部署的四个星期。如果是复杂的更改，IdM 团队可能要求更长的时间。 有几个因素可影响为时七个星期的标准时间线。但是，任何此类因素均不会改变更改所必须遵循的高标准。此类因素包括：
更改流程阶段架构更改流程包括五个独立的阶段：
本文档的以下部分将详细介绍各阶段的活动。 浏览更改流程下图显示了架构更改管理流程期间的活动流。  图 3. 架构更改工作流 通常，更改管理系统会传达和跟踪在 IT 的多个领域中进行的多个相关更改。因此，一项至关重要的工作是按 MOF 的定义将架构更改流程与 Microsoft IT 更改管理系统集成，以确保架构更改不与 IT 的其他领域发生冲突。可以通过在架构更改流程中加入更改控制通知这一部分来实现此目的，如图 3 所示。这会增加一个并发流程。IdM 团队批准架构更改以进行部署后，他们会就该架构更改通知变更咨询委员会 (CAB)，以便 CAB 可以对架构更改流程的其余阶段中出现的任何 IT 冲突进行管理。作为中间人，CAB 充当各个组之间的顾问。 评估请求者的专门知识架构更改请求者通常是开发新产品的产品小组、业务单位或想要进行架构扩展以支持新应用程序的 IT 基础结构小组。到目前为止，Microsoft 中数量最大的架构更改来自 Exchange 和 Windows 产品小组。IdM 团队会就架构更改和建议的实施方案向产品小组提供有价值的反馈。 例如，Microsoft Exchange Server 2003 安装提供了 forestprep.exe，用于自动更新和扩展架构、创建新对象和为新对象设置权限。而 IdM 团队原想单独扩展架构，并且是在安装文件添加对象和将数据填充到 AD 中之前进行。于是 IdM 团队要求产品小组提供 LDIF 文件选项，它后来成为了最终交付产品的组成部分。 第三方应用程序的架构更改实施起来更困难，因为许多应用程序都有隐含的架构更改要求。第三方应用程序可能会使用 .EXE 文件扩展架构，这使提取更改变得困难。而且，.EXE 文件可能只会在安装过程中导入 LDIF 文件。这使获得 LDIF 文件以进行测试变得困难。 例如，Microsoft 需要第三方架构扩展以支持 Avaya 的统一消息传递系统。该扩展通过集成语音邮件和 Exchange，可以在 Microsoft 实现统一消息传递。由于安装文件包含隐含的架构更改，从而导致安装因权限不足而失败。 提交架构更改请求所有架构更改均始于 IdM 网站。该站点供所有 Microsoft 员工在内部使用。说明中有到在线请求表单和附加信息的链接。 说明对于长度至少为三周的发现和检查规定期限，说明设置了相应的预期。如果获得了 IdM 团队的批准，则还会有长度至少为四周的规定期限用于测试和实施。对于符合突发事件条件的架构更改，他们会将其作为七周时间线的例外情况来处理。 请求表单可帮助 IdM 团队有效地设置有关实施架构更改所需知识水平的用户预期。例如，将要求请求者提供相应且唯一的对象 ID (OID)、先前测试结果及功能测试计划。此外，请求者必须以 LDIF 文本文件形式提供架构更改请求。LDIF 格式清楚地显示每个更改，并包括其权威源。 突发事件请求如果需要进行突发事件架构更改，业务单位主管必须提交请求，并证明该请求满足特定条件。条件包括工作中断、业务中断或安全性问题。IdM 团队向 IdM 主管提出建议。IdM 主管必须在部署前批准所有突发事件架构。该流程需要缩短时间线。 提供发现提交架构请求表单后，一位 IdM 团队成员会跟踪该更改请求直至完成。第一个任务是检查业务和技术依据及请求详细信息。在可能会很漫长的检查过程中，该 IdM 团队成员可能会多次返回更改文档，以检索附加信息或修复错误。当请求满足 IdM 标准时，将接受请求并继续执行下一步骤。 业务和技术依据为消除不必要的架构更改或对错误更改的请求，IdM 团队会要求请求者既提供业务依据又提供技术依据。 业务依据说明更改对于业务单位的价值。它让 IdM 团队了解请求者想要进行更改的原因和必须进行更改的期限。例如，某个产品小组可能要求将使用 AD 功能的应用程序部署到 Microsoft 生产环境中，以便在发放它以进行制造前接收反馈。 技术依据专门定义应完成哪些建议的架构更改。IdM 团队会根据技术目标检查所请求的更改，以确定该目标是否可以实现及解决方案是否最优。 虽然产品小组侧重于添加功能和保护产品，但它们要依赖 Microsoft IT 来测试应用程序对工作环境的影响。IdM 团队有时会发现重大的应用程序设计问题。例如，IdM 团队可能发现产品小组使用 AD 来捕获频繁变化的数据。数据的变化可能相当频繁，以至于数据在整个林状结构中复制尚未完成时可能又发生了变化。因此，无效数据可能会一直存在于林状结构内的某些 DC 上，从而抵消了架构更改的价值。 检查架构更改请求IdM 团队了解并同意了业务和技术依据后，就会开始对 LDIF 文件进行彻底检查。他们会查找错误、分析设计，然后向作者提供反馈。如果存在问题，这种反馈循环会帮助作者优化解决方案和重新设计待接受的请求。 检查架构文件时，检查者将：
IdM 团队使用以自动方式收集大量常规信息的脚本。如果对提交的信息感到满意，检查者会接受更改请求、制定时间线并转到实施测试。 测试实施接受架构更改请求后，IdM 团队即会将更改加入队列以进行实施测试。Microsoft 内各林状结构架构在设计上略有不同。例如，林状结构会保留不同版本的 Microsoft 软件以便提供旧版本支持和进行开发。IdM 团队不是对每个林状结构分别执行测试，而是维护一个实验室环境，该环境具有一个累积架构，包含来自每个林状结构的每个架构扩展。因此，通过在此环境中进行成功的实施测试，IdM 团队就可以在部署前确定任何林状结构中的冲突。 通过在实验室中加载 LDIF 文件，IdM 团队可以验证不存在 OID 或命名冲突以及 LDIF 文件以干净方式加载。在实施期间打开日志记录选项并检查日志中是否有错误可以验证这一点。IdM 团队会调查所有错误，如果文件需要改进，可能会将 LDIF 文件返回给请求者。最终 LDIF 文件将可正确安装，这一点应毫无疑问。 批准部署IdM 团队检查更改请求并测试实施后，将批准或拒绝部署。如果批准部署，IdM 团队会通知 CAB 并将更改请求转至功能测试。如果拒绝部署，IdM 团队会将更改请求返回给请求者，并附带对拒绝的详细解释。 通知变更咨询委员会变更咨询委员会 (CAB) 是 Microsoft IT 的一个职能部门，依据 MOF 而设立。CAB 独立于 IdM 团队。CAB 是一个跨职能小组，其设立目的是在业务需要、优先级、成本效益比及对其他系统或流程的潜在影响方面对所有 Microsoft IT 更改请求进行评估。一般来说，CAB 会提出实施、进一步分析、延期或取消建议。 当 IdM 团队向 CAB 提供更改控制通知时，CAB 会逐步完成其流程，该过程与 IdM 团队并发进行。CAB 是与 Microsoft IT 常规更改管理订票系统的集成点。 该 IT 环境极其复杂，包含许多相互依赖关系，而且往往具有全局性。CAB 确定更改对各相互依赖系统和部门的影响，并在各部门间协调这些更改。他们通过同时使用 Microsoft IT 更改管理系统和架构更改管理系统来协调这些更改。CAB 检查更改请求以确定：
检查更改请求后，CAB 会批准更改请求或将其返回并附带更改建议。如果批准了请求，CAB 会将其添加到常规更改管理系统以获得单证号，并通过电子邮件向所有相互依赖的小组发送通知。该通知使这些组可以采取必要的措施来避免冲突和协调更改。 测试应用程序功能如果 LDIF 文件在实验室环境中加载顺利，下一步将是启动第一个试验。该试验使请求者可以按功能测试规划中的规定执行功能测试。IdM 团队通常使用 Windows 开发林状结构来启动第一个试验。该林状结构是一种有限生产林状结构，其中包含使用此环境来简化吃螃蟹的用户。通常会为请求者提供一周的时间来测试功能并确定架构更改是否如预期般有效。如果请求者拥有其他可进行测试的林状结构，IdM 团队将提供进行第二个试验的机会。在每个试验阶段结束时，请求者会确认成功完成功能测试。请求者在功能测试期间可能会尝试对更改做小的改进，以修复一些小问题。不过，如果请求者发现任何重大问题，该流程都将停止，并会要求请求者重新进行架构更改。 部署到生产中实施和功能测试成功完成后，经过全面检查和测试的 LDIF 文件便可以进行部署了。接下来，IdM 团队将继续执行其架构更改部署计划。部署更改的日期和时间取决于时间线要求、更改的规模、复制影响以及 IdM 和 IEng 团队的现有工作负荷。需要由 IEng 团队对复制流程进行监控。进行适当测试后，IdM 团队将在同一天连续加载较小的更改，但将在可能的情况下分别加载重大架构更改。IdM 团队预订在每星期五傍晚（太平洋时间）进行架构更改，以确保在星期一早上（亚洲时间）之前完成复制且 AD 负载恢复正常。 通过为该流程编写脚本，IdM 团队不必进行手动操作即可为每个林状结构应用同样的更改。对于所有架构扩展，他们都是连续地为各林状结构应用更改。为确认更改流程成功完成，IdM 团队会将日志文件底部提供的成功更改数与其他林状结构中的后续更改数进行比较。如果它们不相符，IdM 团队会检查日志记录。如果发生会影响 AD 稳定性的重大错误，IdM 团队可能需要与 IEng 团队协作以启动恢复计划。 成功完成部署后，IdM 团队将压缩各个林状结构的脚本、LDIF 文件和日志文件以及错误文件（如果存在）。然后他们会在所有架构更改的更改历史文件中添加记录。 IdM 团队将更改部署到目标林状结构后，IEng 团队即开始监控复制流程，以确保在各个林状结构中复制架构时不发生任何问题。如果存在严重问题，则 IEng 团队还要负责进行恢复。如果已在各个林状结构中复制了架构更改且 IEng 团队对结果感到满意，他们将向所有相关人员发送最终电子邮件，确认架构更改复制成功。 降低风险要降低架构更改风险，企业必须了解这些风险、确定根源并采取措施来消除风险或最大限度降低风险。此外，它们还必须为可能发生的问题制定应急计划。 衡量风险Microsoft IT 使用不良事件发生的影响和可能性来确定其风险。可产生最具破坏力的影响（如系统失败）的事件通常是 Microsoft IT 首先要通过安全措施和冗余手段进行抵御的事件。这便在高风险与大影响事件间创建了一种相反关系，在这种关系中，最具破坏力的事件的发生机率往往最低。虽然为大影响事件做准备很重要，但管理具有中等发生风险事件的工作效率会更高。Microsoft 建议对以下讨论的各个风险做逐一考虑。 复制影响：低影响、中等风险AD 复制使用优先级系统，该系统会在任何数据变化前复制架构更改。这可能会增加数据在各个 DC 间会聚所需的时间。结果是，较大的架构更改可能会妨碍依赖 AD 的应用程序所需的数据更改并影响将使用该数据的应用程序。例如，在架构更改期间，在整个林状结构中完成组成员身份更改复制所需的时间可能长于标准的五小时复制延迟。这是因为组成员身份复制发生在架构扩展完成之后。 使用 AD 功能的重要应用程序（如 Exchange 2003）的实施会产生大量架构更改，这些更改可能要求根据林状结构站点拓扑每个跃点使用多个复制循环来复制架构更改。IdM 团队通常在星期五傍晚实施这些类型的更改，以最大限度减少对生产力的影响。其他可能导致额外复制工作负荷的属性包括编入索引的属性、部分属性集 (PAS) 重新生成或继承的安全性描述符 (SDProp)。有时需要进行这些更改才能实现特定系统功能，管理员无法避免这样的更改，但精心设计的实施可最大限度减少任何不良影响。 应用程序失败：中等影响、中等风险AD 在林状结构内提供了特定应用程序功能，包括安全性和对全局目录的访问。此外，扩展 AD 架构的应用程序还具有自定义功能，该功能依赖应用程序对 AD 及其扩展的访问。架构扩展提供应用程序创建某些对象时需要使用的定义，应用程序需要这些对象才能正常工作。失去对 AD 的访问可能导致应用程序失去特定功能或彻底崩溃。 设计不佳的架构更改可能会使现有元素无效，而导致问题的附属应用程序需要这些元素。此外，不良实施的架构扩展可能仅提供部分更改，并导致应用程序错误或妨碍新应用程序发挥全部功能。 系统失败：大影响、低风险AD 管理网络资源访问以及使用 AD 功能的应用程序的功能。因此，如果 AD 变得无法访问，林状结构内的用户将失去对这些资源和特定应用程序功能的访问能力。不过，要使 AD 变得无法访问，域中的所有 DC 都必须失败。单个 DC 失败不会影响整个林状结构的 AD。这是低风险事件，因为 DC 失败并不常见。 硬件或软件失败均可导致 DC 失败。DC 失败的解决方案是解决硬件失败或重新安装软件。当管理员部署多个 DC 以提供冗余功能时，DC 失败并不意味着 AD 失败。不过，如果架构更改期间架构主机失败，则管理员在使服务器恢复到在线状态以确保状态一致时应小心。 由数据失败导致的复制 AD 崩溃也非常罕见。复制 AD 崩溃的解决方案是实施灾难恢复计划。 管理风险通过了解风险，重大架构更改问题的两大主因已变得很清晰：即不佳设计和不良实施。设计问题可能会增加复制延迟或 DC 系统负荷，并可能导致应用程序不兼容或出现故障。实施问题可能包括妨碍功能的部分实施或使复制延迟超出典型阈值的不良时限。复制延迟可能会影响对延迟敏感的应用程序。因此，为最大限度降低风险或消除风险，管理架构更改设计和实施便很重要。为实现此目的，IdM 团队具有了在 Microsoft IT 管理的林状结构内进行所有架构更改的独家权限。 管理设计风险IdM 架构更改管理系统要求架构更改请求者遵循特定的更改批准指导原则。IdM 团队将推迟设计存在问题的架构更改，直到他们可以检查重新修改过的技术详细信息。更改管理系统通过执行以下功能来管理设计风险：
管理实施风险接受并设计架构更改后，即可开始进行实施和功能测试。程序包括：
规划灾难恢复有时架构更改会导致不易修复的问题。首选的恢复方法是修改架构。不过，有时修改架构并不切合实际。在这些情况下，管理员必须还原域或林状结构。 IEng 团队负责灾难恢复，拥有多个用于回滚架构更改的流程。这些流程包括：
最佳实践和 IdM 标准IdM 团队从数年的架构更改部署中获得了大量经验。这样大的架构更改量使得 IdM 团队能够不断改进其流程。通过这些改进，他们制定出一套最佳实践和标准来强化流程和确保获得最优结果。 最佳实践Microsoft IT 建议的最佳实践有：
Microsoft IT IdM 标准IdM 团队要求所有架构更改均遵循以下标准。这些标准会确保架构更改流程的一致性和提供最优结果。这些标准有：
结束语Microsoft IT 建议制定一致的 AD 架构更改流程，该流程包括论证、评估、测试、分段和实施里程碑。Microsoft IT 还建议将架构更改流程与现有更改管理系统集成，以减少冲突和风险。 Microsoft IT 为特定小组授予了处理所有架构更改和执行标准的权限。这些标准规定明确，而且可以执行。架构更改流程会执行标准和程序、适当地创建和管理预期及清晰地表示时间线。 架构更改需要积极的管理，而且可能需要多个利益关系团队之间的合作。Microsoft 架构更改流程在各方之间分配职责并提供各方之间的检查和平衡。通过遵循标准的、循序渐进的流程，消除了混淆并实现了所有要求。 通过建立架构更改流程，Microsoft IT 借助结构化工作流将架构更改标准化，该工作流执行组织标准并建立切实的预期。现在，该工作流会在流程的早期消除架构更改问题，并使参与各方明确责任。这增强了相关各方之间的协作，并确保及时得到优化的结果。 更多信息有关 Microsoft 产品或服务的更多信息，请拨打 Microsoft 销售信息中心的电话：(800) 426-9400。在加拿大，请拨打 Microsoft 加拿大信息中心的电话：(800) 563-9048。在美国 50 个州和加拿大以外的国家和地区，请联系当地的 Microsoft 子公司。要通过万维网获得信息，请访问： http://www.microsoft.com/itshowcase http://www.microsoft.com/technet/itshowcase 对本文档有任何疑问、意见或建议，或要获得有关 Microsoft IT Showcase 的其他信息，请发送电子邮件至： 有关 Microsoft Operations Framework (MOF) 的详细信息，请访问： 有关 MOF 更改管理流程的详细信息，请访问：http://www.microsoft.com/technet/itsolutions/cits/mo/smf/smfchgmg.mspx#EGAA 有关由 IdM 团队部署的更改管理流程的详细信息，请访问： 本文档所包含的信息代表 Microsoft Corporation 在发布时对所讨论问题的当前观点。因为 Microsoft 必须紧跟瞬息万变的市场形势，所以不应认为这是 Microsoft 的承诺，并且 Microsoft 无法保证发布日期之后信息的准确性。 |
|
