Microsoft 的结构化 Active Directory 架构管理

最新推荐文章于 2024-03-21 19:30:18 发布

dugufeiyun

最新推荐文章于 2024-03-21 19:30:18 发布

阅读量1.9k

点赞数

分类专栏： Windows 文章标签： microsoft 测试扩展 exchange 文档脚本

Windows 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Microsoft 的结构化 Active Directory 架构管理

创建一致、标准化的更改工作流

技术白皮书

本页内容

	执行摘要
	架构更改简介
	Microsoft Active Directory 环境
	更改管理系统体系结构
	浏览更改流程
	降低风险
	最佳实践和 IdM 标准
	结束语
	更多信息

执行摘要

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 功能的应用程序可通过添加定制对象定义以在目录中存储信息，从而修改架构。例如，Microsoft Office Live Communications Server 2003 将新对象类和其他属性添加到架构以处理状态信息。
•	使用 AD 功能的内部应用程序。安装使用 AD 功能的自定义应用程序可能需要进行架构修改。

架构修改范围

扩展架构属于高级操作，需要详细规划和测试。架构是林结构中 AD 的使用和操作的基础。因此，企业必须详细考虑对系统提供的基础架构所作的任何扩展或更改，以避免发生问题。架构更改可能会影响重要设置，如目录数据库索引、全局编录数据可用性和 AD 数据库大小和完整性。

一般来讲，恢复架构修改是不可能的。考虑更改时，有三个要点需要注意：

•	架构扩展是全局的。架构主列表会将对架构所作的任何更改复制到林结构中的每个域控制器 (DC)。
•	与系统有关的架构类是不可修改的。系统管理员无法修改 AD 架构内的默认系统类。但是，管理员可修改其添加的可选系统类。
•	架构类和属性不可删除。向架构添加新类或属性后，管理员可通过将其标记为无效来取消激活该类或属性。虽然管理员无法彻底删除类或属性，但他们可在创建后修改某些属性或类属性。例如，如果某个现有对象需要更改某个无法更改的属性，管理员可通过将初始对象标记为无效然后更改该对象的“相对唯一的名字”(RDN) 来实现这一点。这便允许用更正后的属性值创建新对象实例。有关详细信息，请参阅：http://msdn.microsoft.com/library/en-us/ad/ad/disabling_existing_classes_and_attributes.asp。

通过客户端通信和期望管理以及详细的架构更改规划和分段，管理员可顺利地处理 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 架构更改管理流程已帮助使架构更改实现了标准化，并通过主要软件新产品提供最佳结果，这些产品包括：

•	Exchange Server 2003。Microsoft IT 安装了六个 Exchange 的预发行过渡版本以用于测试，而且每次在四到六个生产环境中更改架构。他们实现了这一点，而未对网络造成任何破坏。
•	Data Protection Manager (DPM)。Microsoft IT 将 DPM 预发行版本安装到四个生产环境。该架构更改启用了一项功能，该功能允许最终用户恢复其存放在文件服务器共享目录中的文件。
•	Avaya Unified Messaging。Microsoft IT 毫无问题地将 Avaya 的扩展部署到三个生产环境。

返回页首

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 架构更改管理系统处理以下内容：

•	扩展。在 Microsoft，最常见的架构更改是扩展。在三个架构管理选项中，扩展比较容易，带来的潜在影响也更小。添加新定义而不是更改现有定义会消除影响现有应用程序的可能性。
•	修改。架构修改与扩展相比不太常用。如果某个现有对象被更改，这可能会反过来影响依赖于该对象的应用程序。因此，IdM 团队会详细检查任何对现有架构对象的更改，而且只有在他们完全了解其后果时才继续。而且，Microsoft 不认为 Windows Server System 提供的任何属性是未使用的，因为它们都有一个目的。因此，修改未使用的定义仅适用于自定义属性。
•	取消激活。Microsoft IT 很少禁用未使用的定义。相反，当他们不再需要属性或对象数据，Microsoft IT 会删除该属性值或对象实例。这是因为未使用的架构对象不占用重要资源。事实上，Microsoft 专门设计了 AD 以包含稀疏数据。而且，架构管理员无法取消激活默认的 Windows 架构对象。他们只可以取消激活自定义架构对象。

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 中的每个架构更改。该团队将架构作为单个实体来管理，累积所有架构更改。通过这种方式可以全面了解架构当前包含的全部架构元素以及其他更改的影响。

包括了解以下内容：

•	设计。IdM 团队分析各个架构元素的设计，以确定其遵循了已定义的架构方法。本文档中的“最佳实践和 IdM 标准”部分包含已定义的架构方法的完整列表。
•	实施和用途。虽然与设计和所有权密切相关，但此部分包括管理员完成架构扩展的方式以及在目录内填充元素实例的方法。
•	所有权。IdM 团队跟踪自定义架构元素的所有权，以确保对可能影响该元素的任何未来更改都存在一个接触点。
•	安全。必须对架构元素安全进行确定、跟踪和管理。每个元素都必须支持所有权、对象权限代理和更大的企业安全目标。

为维护此级别的了解，Microsoft IT 将进行架构更改的权限限制为 IdM 团队。作为看门人，IdM 团队通过有效管理所有架构更改确保 AD 架构性能。

更改策略

为强制架构更改限制，Microsoft IT 将架构管理组的成员身份限制为 IdM 团队的成员。而且，IdM 团队仅临时将成员身份授予架构管理组，其时间仅够进行所批准的更改。否则，默认的架构管理组将保持为空。

IdM 团队有权设定策略，以确保使用架构更改管理系统、遵循适合的标准和设定期望。架构更改要求：

•	IdM 批准。所有架构更改均要求 IdM 团队的批准。
•	架构更改管理系统使用。所有架构更改均需要通过 IdM 团队的 AD 架构流程和批准服务。
•	前期测试。架构更改请求者负责测试架构更改的功能。这包括实施方法。如果没有相应的测试，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 团队可能要求更长的时间。

有几个因素可影响为时七个星期的标准时间线。但是，任何此类因素均不会改变更改所必须遵循的高标准。此类因素包括：

•

突发事件条件。IdM 团队自动为符合既定突发事件条件的请求授权优先级状态，并提供加速的时间线。IdM 团队已在架构更改网站上公布了此条件。

•

紧急情况。虽然架构更改可能不符合既定的突发事件条件，但如果情况紧急，可能仍具备缩短时间线的充分理由。例如，某个架构请求者可能需要将某些 AD 用户属性设置为失效。这样会强制使用新的全局业务应用程序中的其他属性。在这种情况下，请求者可以请求缩短时间线。IdM 团队可能会视该请求的复杂程度、可用资源和其他优先请求的情况批准该请求。

•

其他优先架构更改。通常由 IT 环境中级别最高的团队成员处理架构更改。这些人员通常相当繁忙。请求者必须将任何新架构更改请求添加到现有队列的尾部，但满足突发事件条件的请求例外。在异常繁忙的时期，可能需要留出更多的时间来完成更改。

注意： 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 团队的批准，则还会有长度至少为四周的规定期限用于测试和实施。对于符合突发事件条件的架构更改，他们会将其作为七周时间线的例外情况来处理。

图 4. 架构请求表单
查看实际尺寸图像

请求表单可帮助 IdM 团队有效地设置有关实施架构更改所需知识水平的用户预期。例如，将要求请求者提供相应且唯一的对象 ID (OID)、先前测试结果及功能测试计划。此外，请求者必须以 LDIF 文本文件形式提供架构更改请求。LDIF 格式清楚地显示每个更改，并包括其权威源。

突发事件请求

如果需要进行突发事件架构更改，业务单位主管必须提交请求，并证明该请求满足特定条件。条件包括工作中断、业务中断或安全性问题。IdM 团队向 IdM 主管提出建议。IdM 主管必须在部署前批准所有突发事件架构。该流程需要缩短时间线。

提供发现

提交架构请求表单后，一位 IdM 团队成员会跟踪该更改请求直至完成。第一个任务是检查业务和技术依据及请求详细信息。在可能会很漫长的检查过程中，该 IdM 团队成员可能会多次返回更改文档，以检索附加信息或修复错误。当请求满足 IdM 标准时，将接受请求并继续执行下一步骤。

业务和技术依据

为消除不必要的架构更改或对错误更改的请求，IdM 团队会要求请求者既提供业务依据又提供技术依据。

业务依据说明更改对于业务单位的价值。它让 IdM 团队了解请求者想要进行更改的原因和必须进行更改的期限。例如，某个产品小组可能要求将使用 AD 功能的应用程序部署到 Microsoft 生产环境中，以便在发放它以进行制造前接收反馈。

技术依据专门定义应完成哪些建议的架构更改。IdM 团队会根据技术目标检查所请求的更改，以确定该目标是否可以实现及解决方案是否最优。

虽然产品小组侧重于添加功能和保护产品，但它们要依赖 Microsoft IT 来测试应用程序对工作环境的影响。IdM 团队有时会发现重大的应用程序设计问题。例如，IdM 团队可能发现产品小组使用 AD 来捕获频繁变化的数据。数据的变化可能相当频繁，以至于数据在整个林状结构中复制尚未完成时可能又发生了变化。因此，无效数据可能会一直存在于林状结构内的某些 DC 上，从而抵消了架构更改的价值。

检查架构更改请求

IdM 团队了解并同意了业务和技术依据后，就会开始对 LDIF 文件进行彻底检查。他们会查找错误、分析设计，然后向作者提供反馈。如果存在问题，这种反馈循环会帮助作者优化解决方案和重新设计待接受的请求。

检查架构文件时，检查者将：

•	记下架构更改所需的新属性和对象类以协助进行测试。
•	检查默认安全性描述符更改以确定是否有多余的权限和代理。
•	查找添加到系统工作负荷中的对象，如编入索引的属性、部分属性集 (PAS) 重新生成或 SDProp。
•	评估可能更改的范围，并确保它们全部符合 AD 架构最佳实践以及 IdM 标准。
•	检查每个 OID 以确保其唯一且已注册。可在以下位置执行此检查：http://asn1.elibel.tm.fr/oid/index.htm。
•	检查架构元素以确保存在适当的定义、一致的值和有意义的说明。
•	检查是否有一致的、符合 Microsoft 标准的命名约定。请参阅 Microsoft 网站，网址为：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/ad/ad/naming_attributes_and_classes.asp。

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 检查更改请求以确定：

•	授权。进行更改的各方的权限。
•	相互依赖关系。更改可能会影响许多不同的小组及其服务级别协议 (SLA)。
•	冲突。由于可以更全面地了解 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 团队将推迟设计存在问题的架构更改，直到他们可以检查重新修改过的技术详细信息。更改管理系统通过执行以下功能来管理设计风险：

•	文档管理。不良文档可能导致实施难题。为消除此问题，请求者必须在检查开始前提交标准化的文档。
•	设计分析。IdM 团队根据 IdM 标准分析架构设计，将设计不佳的更改请求返回给作者，并附带意见和建议。
•	标准设立。IdM 团队执行一套高水平标准和最佳实践，它们定义了可接受的架构更改。这些标准将与现有架构对象发生冲突的风险降至最低水平。它们侧重于发现导致复制工作负荷高峰的属性使用。本文档的“最佳实践和 IdM 标准”部分介绍了这些标准。
•	第三方供应商责任。供应商并不一定会提供用于设计或安全性评估的 LDIF 文件或架构安全性描述符。由于规章遵循方面的问题，管理员彻底检查第三方架构安全性描述符并获得和验证所制定的架构更改具有重要意义。

管理实施风险

接受并设计架构更改后，即可开始进行实施和功能测试。程序包括：

•

为流程编写脚本。IdM 团队使用标准脚本将 LDIF 文件实施到所有林状结构，从而确保它们在整个企业内均使用正确、一致的参数。这可消除实施过程中常见的人为错误，这些错误可能导致架构更改不完整。

•

实施测试。通过在实验室环境中测试 LDIF 文件实施，可在将文件部署到生产环境之前发现并改正错误和冲突。

•

功能测试。通过在有限环境中试验进行架构更改，可由请求者确定应用程序功能。试验的结果决定 IdM 团队是否实施架构更改。这会消除实施功能不良的架构设计所带来的风险。

•

实施标准。IdM 团队已制定了可最大限度降低风险的实施标准和最佳实践。它们包括：

•	直接架构主机实施。IdM 团队使用 Terminal Server 在架构主机上以本地方式实施架构更改，这样实施便不易发生工作站问题或网络连接问题。这会消除由这些问题导致的架构更改实施不完整的风险。
•	复制影响注意事项。IdM 团队通常在星期五傍晚实施架构更改，以使复制在周末进行。这会将对其它复制通信的任何影响降至最低水平。
•	成功复制验证。IEng 团队会验证在整个林状结构中进行的架构更改复制是否成功。这会减少架构更改复制不完全时生产环境中发生意外应用程序行为的机率。

规划灾难恢复

有时架构更改会导致不易修复的问题。首选的恢复方法是修改架构。不过，有时修改架构并不切合实际。在这些情况下，管理员必须还原域或林状结构。

IEng 团队负责灾难恢复，拥有多个用于回滚架构更改的流程。这些流程包括：

•

备份和还原。要使此方法奏效，企业必须执行定期 DC 系统状态备份、验证备份有效性并定期执行还原流程。IEng 团队定期执行还原流程的方法是：每月执行一次非正式还原来测试流程；每三到四个月执行一次正式还原来为丢失数据的用户提供协助。如果是架构更改，则需要进行林状结构还原。这是备份和还原方案的扩展版本。IEng 团队每年在实验室中执行一次林状结构还原来测试流程。在以上两个方案中，备份和还原是 IEng 团队的首选方法，因为它最容易执行。

•

架构主机离线。通过在直接对架构主机进行架构更改时断开其与网络的连接，IdM 团队可在使架构主机恢复在线状态之前验证实施是否成功。因此，如果他们需要取消架构更改，他们可以将架构主机作为单个 DC 进行恢复。这并不会提供验证应用程序的机会。不过，它确保了架构安装正确。

返回页首

最佳实践和 IdM 标准

IdM 团队从数年的架构更改部署中获得了大量经验。这样大的架构更改量使得 IdM 团队能够不断改进其流程。通过这些改进，他们制定出一套最佳实践和标准来强化流程和确保获得最优结果。

最佳实践

Microsoft IT 建议的最佳实践有：

•

标准化更改管理流程。设计合理的更改管理流程可为组织提供确保获得最优结果的标准化工作流。流程就位后，责任和预期也就明确了。该流程应包含完整的工作流，即从以可接受的格式发送初始更改请求直至确定由谁向有关各方通告流程已成功完成。

•

以独立于应用程序安装的方式扩展架构。当安装要求架构更改的应用程序时，以独立于应用程序安装的方式扩展架构。使用 LDIF 文件扩展架构是首选方法，因为该方法提供的更改详细信息最为详尽。IdM 团队要求内部产品小组和外部供应商均提供 LDIF 选项。IdM 团队只允许安装在其单独扩展架构成功之后才能创建对象、设置权限和填充数据。

•

实施前进行全面测试。在将所有架构更改实施到生产环境中之前对它们进行全面测试。这包括实施测试和功能测试。对所有内部开发的应用程序执行功能测试。成品可能不需要进行功能测试。

•

了解每个架构更改对 AD 的影响。架构更改的影响是广泛的，可能会影响对象安全性、在目录中发布的数据类型、目录数据库索引编制、目录更新成本、全局目录中的数据可用性以及 AD 数据库的大小。因此，在生产环境中扩展架构之前，确定更改将对 AD 的各个方面（如安全性、数据使用、基础结构要求、复制及附属应用程序）产生怎样的影响有重要意义。

•

为流程编写脚本。使用标准化的脚本来运行所有架构更改，以提供流程一致性。该脚本使用所需的 ldifde.exe 命令行开关运行 LDIF 文件更改并处理其中的任何变量。这会避免遗漏并确保所有架构更改均遵循标准程序和返回一致的结果。标准化的脚本包括：

•	林状结构命名自动化。LDIF 文件指定添加或修改的每个对象的区别名 (DN)。由于此 DN 必须包含林状结构根域组件，所以必须使用目标林状结构的特定 DC 元素更改它们。LDIF 文件的事实标准是使用 DC=X 作为 DC 元素的占位符。通过在 LDIF 文件中使用 DC=X，该脚本确定当前域名上下文并用有意义的值来替换它。这使 LDIF 文件非常易于移植，而且使同一脚本可以在各个林状结构中运行，而无需对 LDIF 文件进行手动修改。这还消除了版本控制问题。
•	正确的命令行开关用法。脚本使用一组标准参数来操作 LDIFDE.exe 命令行工具。它使用命令参数 J 来产生文本日志文件。脚本通过使用查找和替换，借助命令参数 C 来自动进行林状结构名称更改。通过使用命令参数 K 选项，如果架构更改流程中发生任何错误，脚本将继续且不会创建缺少的元素。这一点也很重要，因为管理员往往会图方便而将附加架构更改添加到原始架构更改的底部。运行脚本时，重复的架构更改会以错误形式出现，而不会使脚本失败。执行验证测试时，检查日志时应小心，因为命令参数 K 在发生任何约束违反错误后仍将继续。确保任何记录的错误都有合理的解释。
•	林状结构一致性。对所有林状结构均使用相同脚本而无需进行手动修改可提高林状结构间架构的一致性。手动更改 LDIF 文件可能导致引发架构更改不完整的错误。
•	流程一致性。如果不为流程编写脚本，操作员必须每次都输入正确的参数。这会带来发生人为错误的风险。例如，如果已不带参数 J 运行流程，操作员将无法创建日志文件。此外，忘记使用参数 K 可能导致架构更改不完整且需要调查日志。

•

在架构主机上进行本地更改。进行架构更改时，使用 Terminal Server 会话登录架构主机。由于 Terminal Server 在架构主机本地上运行更改，因此这会减少可能导致架构更改不完整问题的潜在网络和客户端问题。

•

保留架构更改历史。保留与每次架构更改有关的所有记录的副本。这会创建更改历史和结果摘要以供必要时进行搜索。此外，通过保留这些文件，管理员可以向 LDIF 文件尾部添加附加更改，从而简化了以后的更改。每次架构更改后，Microsoft IT 均会压缩每个林状结构的脚本、LDIF、日志以及错误文件。

•

对顺序架构更改进行一并测试。强烈建议管理员在部署顺序架构更改前执行特定的顺序测试。请分别执行架构更改以为各更改保留其各自的脚本。

•

从不需要的架构对象中删除旧数据。如果未用数据在 AD 中，最好先删除数据，然后通过生成简单的脚本来回收资源。这不但会释放文件空间，还会减少索引建立和复制过程中服务器的负荷。最后，清除旧数据可防止无意的保留和可能发生的潜在机密或敏感数据的泄露。

Microsoft IT IdM 标准

IdM 团队要求所有架构更改均遵循以下标准。这些标准会确保架构更改流程的一致性和提供最优结果。这些标准有：

•

架构设计

•	所有架构元素均要求有效的 OID。
•	遵循 Microsoft 建议的命名约定。
•	管理员应只为唯一且需要广泛填充的元素编制索引。
•	仅在需要时在部分属性集中进行添加。
•	自定义属性集的所有者必须批准对该集的任何更改。
•	AD 内的单个对象不应大于 1MB。

•

架构所有权

•	架构元素的所有者必须为全职员工。
•	对于内部开发的应用程序，在扩展实施前定义每个架构元素的所有权。
•	所有者负责向 IdM 团队发送有关未用架构元素的通知并使它们失效。

•

架构实施和使用

•	不能存在具有完全相同用途的架构元素。
•	使用 LDIF 脚本进行所有架构修改。如果第三方产品使用可执行文件或安装包装程序，请使 LDIF 文件可用于检查、手动安装之一或两者。
•	存档所有 LDIF 文件以供未来参考。
•	对于任何 Microsoft IT 管理的林状结构，只有 IdM 团队可以实施对架构的更改。
•	为建议的架构扩展所经历的测试级别形成文档。
•	提供用于实施任何使用 LDIF 脚本、程序可执行文件、安装包装程序等的架构修改的实施程序。

•

架构安全性

•	IdM 团队在更改架构元素的默认安全性描述符时会格外小心，因为它会影响网络安全性。

•

多林状结构分段

•	工作应保持一致，也必须切合实际。IdM 将不同林状结构中的架构更改进行分段，以验证实施方法、确定任何兼容性冲突以及确保林状结构间的一致性。

返回页首