服务管理功能
目录服务管理
目录服务管理
本页内容
文档用途本指南为那些已在其数据中心或其他类型的企业计算环境中部署了（或正考虑部署）Microsoft 技术的组织提供了关于服务管理功能 (SMF) 中目录服务管理的详细信息。这是 Microsoft® Operations Framework (MOF) 中定义和描述的 20 种 SMF 中的一种。本指南假定读者已熟悉 MOF 的用途、背景和基本概念，以及所讨论的 Microsoft 技术。 用户可从服务管理功能简介指南中获得有关 MOF 及其相关产品 Microsoft Solutions Framework (MSF) 的概述信息。此概述指南还提供了 MOF 中定义的每种服务管理功能的摘要信息。有关每个框架的概念及原则的详细信息，还可通过以下网站的技术文档获得：http://www.microsoft.com/solutions/msm/. 摘要目录是用于存储相关对象信息的信息或数据来源。电话目录存储电话订户的相关信息。在文件系统中，目录存储文件的相关信息。 目录服务使得用户和应用程序能够通过网络查找网络资源，如用户、服务器、应用程序、工具、服务和其他信息。目录服务的设计目标是确保任何得到授权的请求者都可以通过一种简单的有组织过程，通过网络获取其所需信息。 联机目录的设计通常要兼顾动态、灵活、安全和个性化。之所以要动态是因为目录会随用户和网络资源的移动而频繁更改，要灵活是因为必须要能够用程序设计来包括新类型的信息，要安全是因为目录中的个别对象应被限制为仅供特定用户、特定组或特定类型的访问使用，要个性化是因为目录信息要切合需求，以对特定用户或特定组提供自定义响应。 进程与活动目录服务管理概述目录服务是扩展计算机系统中最重要的组件之一。虽然用户和管理通常不知道他们感兴趣对象的确切名称，但他们可能知道该对象的一个或几个属性，可以查询目录以获得一个匹配这些属性的对象列表。 目录服务可以：
目录服务既是管理工具，也是最终用户工具。随着网络中对象数量的增长，目录服务也变得越来越重要。目录服务就像中心点，而一个大的分布式目录围绕该中心运作。 过去，目录服务主要用于命名和定位网络资源。现在，这些功能得到了扩展，目录服务也变成 Internet/Intranet 基础结构内的一个重要组件，提供类似参考目录、白页和黄页、电子邮件目录之类的服务。 目录服务还启用了在不同电子邮件系统之间传递和集成电子邮件的功能。目录服务在应用程序集成所扮演的角色越来越重要，它就好像是一个涵盖了所有应用程序、访问和安全信息的中央存储库。 如今推出的许多应用程序中都启用了新型目录，它们将目录作为网络基础结构的一个重要组成部分。目录被看作是一个具有特殊用途的自定义数据库，只要安全地连接到这个数据库，用户和应用程序便可以轻松地查找、读取、添加、删除和修改信息。然后，此信息便可以自动分布到网络中的其他目录服务器。 这些启用了目录的应用程序依靠成熟的目录服务来执行其他三种关键角色：身份验证和授权、命名和定位，以及网络资源的支配和管理。 目标与任务目录服务管理的目标是确保任何得到授权的请求者都可以通过一种简单的有组织过程，通过网络获取其所需信息。 范围目录服务使得用户和应用程序能够通过网络查找网络资源，如用户、服务器、应用程序、工具、服务和其他信息。目录服务管理负责处理企业目录的日常操作、维护和支持。目录服务管理涵盖以下内容：
主要定义警报。重要事件的指示。警报由处理规则定义。 属性。计算机特征，通常由注册表项或值定义。 身份验证。用户向系统证明其身份的方法。身份验证用在密码、智能卡和生物识别等方面。 授权。 确认用户具有访问域中资源的适当权利或权限的处理过程。 备份。此术语通常用来表示计算机磁盘上所有文件的副本，该副本定期保存到磁带或其他可移动媒体上（也称为“转储”）。 客户端。通过某种协议向另一个计算机系统或进程（服务器）请求服务并接受服务器响应的计算机系统或进程。客户端是“客户端-服务器”软件体系结构的一部分。例如，向文件服务器请求文件内容的某个工作站便是文件服务器的一个客户端。 目录。计算机文件的集合。目录在具有图形用户界面，并提供图形文件浏览器的系统中最为常见，在这些系统中，目录常被描述为文件夹（外形像一个小公文包）。 事件。 系统或应用程序中发生的，需要用户注意或作为条目添加到日志中的重要事项。 防火墙。包含了特殊安全防范的专用网关机器。其作用是将一组管理较为松散的机器隐藏于其后，保护它们免受黑客的攻击。典型的防火墙是普通成本的 Unix 计算机，配备有调制解调器和公共网络端口，计算机上不放置重要数据，只是有一个被密切监视的连接，该连接通向群集中的其他计算机。特殊防范可能包括威胁监视、回调，甚至是一个完整的铁盒子，专门处理特定的连入 ID 或活动模式。 轻型目录访问协议 (LDAP)。LDAP 允许应用程序以相同的方式访问任意目录，一切与目录供应商或目录的实现方式无关。大多数一般用途的目录都可通过 LDAP 来访问。使用 LDAP 的应用程序可以通过一种简单的途径访问不同目录中的多种信息。 元目录。元目录产品其实就是目录的目录。元目录作为各种不同目录上的一般用途基础结构，利用单一、透明的用户界面，定向查询和返回响应。元目录使分散于多处的目录能够集成和统一。 网络操作系统 (NOS)。通过网络，利用软件与其他计算机进行通信的操作系统。网络操作系统的存在使得诸如文件、应用程序、打印机等资源可以在计算机间共享。 服务器。通过网络为与其相连的其他计算机提供某种服务的计算机。最常见的服务器是文件服务器，它具有一个本地磁盘，并接受来自远程客户端在该磁盘上读取和写入文件的服务请求。 简单网络管理协议 (SNMP)。SNMP 允许管理应用程序对网络中某实体的状态进行监视。当某事件或错误发生时（如服务器进程异常终止时），SNMP 陷阱机制还可使管理应用程序获得异步通知。 主要进程目录服务管理流程可分为五个主进程和若干个子进程：
 图 1：目录服务流程图 目录类型以下各节从较高层面对当前的目录技术，以及用户已经部署，或将于不久的将来部署的目录类型进行了讨论。 一般用途的目录或标准目录一般用途的目录，或称标准目录，并不依附于任何用户或任何特定的应用程序或服务，与任何特定网络操作系统 (NOS) 并无唯一关联，也并非为任何单一用途而部署。相反，这些目录的设计目标是满足众多服务的要求。轻型目录访问协议 (LDAP) 便是这种目录的一个示例。LDAP 可以很好地满足任何启用了目录的实际应用程序的需求。 大多数一般用途的目录都可以通过 LDAP 来访问。LDAP 允许应用程序以相同的方式访问任意目录，一切与目录供应商或目录的实现方式无关。使用 LDAP 的应用程序可以通过一种简单的途径访问不同目录中的多种信息。 特殊用途（应用）和 NOS 目录特殊用途或应用的目录是与特定应用程序（或应用程序套件）存在唯一关联的目录。它们与一般用途目录之间的区别在于其与特定应用程序之间的紧密集成，以及它们所使用的专用接口和协议。通常，如果启用目录的应用程序在设计上不支持这些目录，就无法使用它们。 这类目录中还包括 NOS 特定目录：与特定操作系统建立特殊关联的目录。虽然大多数基于 NOS 的目录都作为专用产品推出，但现在还是有相当多的目录开始接受 Internet 标准（即 LDAP），这使得它们可以更广泛地支持启用目录的应用程序。 目录操作的文档重点本文中提供的材料主要围绕组织目录部署后的操作、支持、管理和维护。如此设计是出于这样一种认知，即大多数的客户早已在其计算环境中部署了一个或多个一般用途或特殊用途的目录，以满足其业务需求。例如，公司可能已经有一个与其人力资源管理系统、电话系统、电子邮件系统或企业资源规划系统相关联的联机（电子）目录。 从操作的角度出发，将目录环境移至一个适用于所有目录解决方案的单点管理和操作环境十分重要。 了解目录环境要了解所部署的目录解决方案，最好的方法就是将其任一方面的部署视为与其他部署同等重要。只有对目录的每个功能和战略方面都做到完全了解、对每个方面进行了记录、配备了适当的人员、予以妥善地监视、管理、支持并取得了资金来源后，解决方案部署才算完成。 了解所拥有的环境在用户开始对其目录进行真正有意义的或正面控制之前，他必须首先了解他都拥有哪些东西，其运作方式如何，这些组件、系统或应用程序彼此之间如何通信或互操作，以及谁负责什么项目。想一想有多少组织在没有完全了解这些元素的情况下就开始着手部署一个或多个目录服务，真是让人吃惊。而多数目录部署一开始就面临预算、时间和资源的种种限制，结果忽视了重要的文档记录和控制元素。 许多公司试图在事后进行补救，希望在部署完毕后回过头来对其部署过程进行记录并实施一些适当的控制机制（监视、委托管理职责、提供服务台服务等等）。然而由于业务环境的快速成长和业务环境的动态本质，使得这一愿望很难得到实现。 前两段中提到，出于很多原因，这种主动的知识获取以及运作准备工作有时并不能得到很好地实现。尽管如此，这些工作还是一定要做的，而且必须及时办妥，这样才不致使解决方案的部署失去控制，在满足业务需求的部署初衷道路上越走越远。如果出现以下症状，则表明已经面临危机：
大多数公司都介于纯运转的理想状态与全面的危机管理状态之间。不管公司的状况如何，此份文档接下来的讨论都非常有价值，它可以帮助评估组织的运作准备工作，并帮助企业执行必要的更改以实现解决方案的目标：可用性 (availablity)、可靠性 (reliability)、可管理性 (manageability) 以及可支持性 (supportability)，也就是“ARMS”。 目录集成挑战本节描述目录的使用方式并引入了目录集成的概念。 随着多种、不同的一般用途或特殊用途的目录的引入，管理这些目录的任务逐渐成为问题。管理不同的目录既浪费成本，又多余，而且其实现途径和技术也不规范。 目录技术现已成熟，可以支持启用目录的办公自动化应用程序，其中包括电子商务和一般性企业计算。 目录服务的使用方式过去，目录服务主要用于命名和定位网络资源。现在新的目录服务应用程序包括公司电话簿、Internet 白页/黄页、不同电子邮件系统之间的电子邮件传递和集成，以及包含用户信息的中央储存库。 目录服务产品利用安全服务来跟踪用户对网络资源和信息的访问权利。目录服务能够有效地管理资源的安全性，因为从逻辑上而言，目录代表企业内所有的资源。此外，目录服务还可作为进入网络的单一入口点。只要向目录服务中表明一次自己的身份，用户便可获得对允许资源的访问权限。 目录的使用可分为以下四个主要领域：
身份验证和授权 有些应用程序特定的工具允许网络操作系统和电子邮件程序跟踪用户、其密码、以及跟踪许多应用程序的相关首选项和配置信息，这些工具可说是一般用途目录的先驱。 在网络服务模型内，目录和安全服务逐渐成为截然不同的组件。不过，这两种服务仍然密切地交织在一起，提供身份验证和授权功能。安全和目录服务协同运转。最初，目录必须提供身份验证和访问控制信息，以便控制哪些用户可以访问和修改目录。此外，目录还为日益增多的一般用途的安全机制提供了一个基础。 身份验证 身份验证允许用户和应用程序通过调用可担保或可验证其身份的安全服务来识别其身份。在过去，网络操作系统和应用程度曾使用系统特定的基于密码的身份验证方法。不过，企业 Intranet 的出现和 Internet 的快速增长需要一种一般用途的安全基础结构。 目录必须提供一种可控制用户对目录数据库访问权限的身份验证机制。目录可以通过多种方法对客户端进行身份验证，其中包括匿名连接、明文密码，或复杂的密码哈希和会话加密例程。虽然这些方法可能是保护目录中内容的重要手段，但它们更多的是一种传统的系统特定的身份验证机制，而非一般用途的身份验证机制。 随着 Internet 上电子商务和通信的爆炸，人们对一般用途身份验证机制的要求更加强烈，在这种强烈的需求之下，公钥基础结构 (PKI) 作为用户和应用程序身份验证的实际标准应运而生。PKI 可以很好地适应这种形式的分布式计算环境。在多种安全应用程序中，PKI 都是一个进行身份验证的重要工具，例如安全套接字层 (SSL)、安全多用途 Internet 邮件扩展 (S/MIME)、安全电子交易 (SET) 和同时用于 Java 和 Microsoft ActiveX® 控件的代码签名服务。由于 PKI 产品将使用目录来存储、分发、查找和检索数字证书及公钥（有些情况下为私钥），因此目录在支持安全服务方面扮演着相当重要的角色。 除了为 PKI 服务存储和管理组件外，目录还对其他身份验证机制起着帮助作用，在服务交付上扮演着支持角色。当使用密钥系统（如 Kerberos 第 5 版协议）时，目录为唯一 ID (UID) 提供了存储位置，而且其自身也要通过 Kerberos 服务的身份验证。此外，伴随着一般用途目录越来越广泛的应用，安全管理员将使用目录的继承属性来强制实施目录中存储的安全策略。 随着这些交互式身份验证机制的逐步改善，使用户可以访问网络上所有操作系统、服务和应用程序的单一登录也开始变得可行。虽然完全交互式的身份验证在某种程度上还属于新兴服务，用户还是可以使用目录服务，并借助元目录服务通过其他异类环境的代理登录的方式来实现单一登录的用户“感觉和体验”。有关元目录、其功能及其重要性的详细信息，将在后文中进行讨论。 身份验证 在安全服务对客户端和应用程序的网络身份进行了验证之后，便应该赋予它们访问资源的权限。与身份验证一样，操作系统、消息系统（例如电子邮件）和其他服务器也以各系统特定的模式来执行授权功能（也称为访问控制）。这些系统在验证用户身份时，还同时检查其内部系统以确定给定用户对给定资源（例如文件系统目录）的访问权限级别。不过，随着一般用途身份验证机制的出现，目录在访问控制中所扮演的角色将有所减轻。 目录支持访问控制的方式有两种：
例如，安全管理员可能主张“帐户组中的所有成员都可能使用工资单应用程序”或“只有管理薪水水平达到某个级别的员工才可以审批差旅报销单”。虽然这两种方法都代表可接受的授权控制形式，但后者无疑提供了一种更为简单、更为一致的授权和策略实施方法。 在目录标准研究组织还在继续研究标准访问控制列表 (ACL) 机制的同时，开发人员有两个选择。他们可以在其产品中写入平台特定的访问控制机制并创建平台特定的依赖项。或者，他们可以编写其自己的访问控制机制，在其中启用目录，但仍是应用程序特定的机制。 如果平台独立性是主要考虑事项，那么后面一种选择则可在易用性（利用目录来提供可管理、可伸缩的基础结构）和应用程序灵活性（允许开发人员调整特定的授权要求以匹配应用程序）两者之间提供一种折衷的方法。而另一方面，虽然创建平台依赖项会给支持多平台带来更多困难，但在平台中写入访问控制机制却可以节省时间和精力。 网络资源的命名和定位 目录的核心功能及其传统角色是查找内容。命名和定位网络资源是目录在网络环境中的一项重要功能。 命名和定位资源功能的三个主要方面分别为：
标准命名 目录对组织施加一种标准的命名约定。命名约定提供了一种上下文环境，应用程序、服务和人们可在该环境中建立关联并发现对方。 标准命名的一个好处是它将物理实体从逻辑概念中分离了出来。命名约定以用户（和应用程序）易于理解的术语来描述网络资源，而不需要求他们了解网络的详尽特性（例如，建筑物、路由器、集线器、子网，以及易变动但不会通知的 IP 地址）。因此，用户和应用程序可以更多地从整体上，而不只是所在地域的角度浏览网络及其资源。人员以及启用目录的应用程序无需了解网络布局就可以搜索和定位资源。他们可以按名称搜索资源。或者，他们还可以按属性搜索资源。这一能力将资源从特定拓扑中解放了出来，赋予了资源位置一定的独立性。 位置独立 位置独立显著影响着网络的方方面面。目录通过两种方式实现了位置独立：
虽然目录不包含所有这些信息，但它知道这些信息存储在哪里，因而可以帮助存储信息的服务适当地运用这些信息。这种功能改善了最终用户和系统管理员的处境。用户和应用程序有了一个参考点。而另一方面，IT 管理员将能够集中管理和控制公司桌面、软件许可及分发。此外，IT 管理员无需重新配置底层应用程序或亲临每个桌面便可移动、替换服务，或是平衡服务负载。这种无需重新配置便可处理服务的能力简化了管理员的工作，使得网络更易管理，而伸缩性也更强。 例如，对于公司桌面，位置独立便意味着用户可以通过任何设备连接到网络，同时还保留自己的个人首选项和设置。 目录还允许其他实体（例如应用程序或网络服务）定位它们所需的资源。在分布式应用程序中，给定应用程序可能需要查找和使用某个软件组件，如 COM 或 CORBA 对象。通过在目录中包括对象的定义、属性和方法，开发人员能够创造出可通过目录进行集中管理和修改的分布式应用程序，而不用更改和重新发布底层应用程序。 与之相似，通过搜索目录，应用程序可以找到它们所需的组件。应用程序不需要知道组件的实际位置，而且在组件的实际位置发生更改后，应用程序也不会失效。 涉及的群体 除了提供标准命名约定和启用位置独立之外，目录还能存储关于人员和组织的额外信息。这一额外信息允许目录基础结构在涉及客户、提供商、合作伙伴、同事和团队的新型公司范例中营造一种群体意识。目录使跨不同时区和不同地域的人们能够在一起合作，其中包括虽在同一组织内却必须跨 Intranet 和 Extranet 才能完成的合作。 在某些情况下，个人加入到某个群体中的过程是自动发生的，例如，某公司中的所有秘书或在同一栋大厦里工作的所有人。在其他情况下，用户可以选择他们想要加入的群体，例如好友列表，或兴趣爱好小组。 长期以来，目录一直在电子社区中扮演着其角色。第一个群件应用程序社区基于电子邮件，最简单的异步通信手段。最近，一种被称为即时消息的同步连接进一步提升了消息系统的能力和应用。随着更加先进的实时协作模式的诞生，例如视频会议、组创作工具、Internet 电话技术等，目录将继续为这些网络服务提供帮助和支持，以便用户和应用程序可以基于名称和属性找到彼此。 不同目录和元目录元目录产品其实就是目录的目录。元目录作为各种不同目录上的一般用途基础结构，利用单一、透明的用户界面，定向查询和返回响应。元目录在集成和统一不同的目录方面起着一定的作用。 客户必须支持多种目录，至少在可以预见的将来是这样，因为这些目录各自承担着不同的功能。元目录服务用于解决每个企业目录产品都必须解决的基础实现问题。 在超大型、高度分散的组织中，元目录要比独立目录更具优势：
不过，随着目录基础结构中目录数目的减少和复杂度的降低，元目录的优势也会随之减弱。因此在决定是否实施元目录前，应仔细评估 IT 组织。 为了更好地理解元目录技术，本文介绍了以下元目录概念：
元目录同步 同步可让元目录汇总元目录数据库中的内容。 在使用同步方法时，元目录必须通过构建良好的关系来与其他的连接目录进行互操作。在涉及目录基础结构的日常管理时，通过目录间的关系来进行管理控制是一个重大的问题。通过同步和复制来汇总目录内容明确地阐释了这一挑战。其关键问题就是由谁来创建和删除联接中的对象，以及如何执行这些操作。 这些都是基本的控制问题。当组织考虑实施和委派控制之时，元目录服务必须具有足够的灵活性。网络规划人员必须在元目录以及与之进行互操作的连接目录之间创建特定的关系。 控制对象 企业目录包含许多对象。这些对象表示各种资源，其中包括人员、物理位置、应用程序（如数据库和消息服务器）和系统（如服务器和工作站）等。问题是：管理员如何在企业目录中创建对象和属性，以代表实际存在于网络中的对象和属性？ 如果是从企业目录集中管理连接目录的情况，目录服务管理员就可以在企业目录中创建对象。企业目录接着会将这些对象传播到连接目录中。 然而，其他部门或分公司可能在本地管理其他的连接目录。在这种情况下，连接目录必须能够在企业目录中创建对象。 还有一些状况是，相应的对象（如用户 ID）早已存在于企业目录和连接目录之中。因此，企业目录必须能够在连接目录中的现有对象与企业目录中的对象之间建立一种稳固的关系。元目录必须能够在所有这些环境中创建对象。为了清晰地了解这些不同的情况，可通过三种角色来看待元目录：主目录、从属目录或对等目录。 主目录角色 在主目录角色中，元目录会在连接目录中创建对象并管理连接目录。主角色使公司可以使用企业目录来集中管理和控制任何连接目录。下图阐释了主目录角色。 在这种情况下，元目录服务允许企业目录完全管理集成目录的内容。元目录服务可将管理员在企业目录中所执行任何更改，例如添加和删除用户，自动传播到受影响的连接目录。企业目录变成了管理连接目录的一个管理工具，代替了网络或应用程序中原有的目录管理工具。 主角色带来了严重的同步问题，例如，如果连接目录的用户使用网络或应用程序环境中原有的管理工具在连接目录中执行了更改怎么办？在这种情况下，元目录还必须足够灵活，允许管理员确定最佳操作方法。 从属目录角色 虽然许多 IT 组织都想集中控制所有系统，但这个目标通常很难实现。 在许多组织中，自治部门或分公司都控制着自己的系统。集中式的信息技术部门通常很难或者根本不可能强制这种部门加入到消除其自治性的任何技术提案中来。还有一些系统，如人力资源数据库，目录服务管理员需要从中获得信息，但却没有足够的访问权限。 不过，在这种情况下，仍需要有一些目录信息能够从本地管理的目录流向元目录，继而流向其他连接目录。例如，许多公司都希望使用 HR 数据库作为所有用户对象的主要来源。并通过网络或应用程序环境的原有管理工具创建用户对象。因此，元目录必须能够接受在连接目录中创建的对象。元目录只从连接目录导入对象，将它们包括在企业目录中，然后再根据需要将它们传播到连接的其他目录。 元目录通过其自己的数据存储来同步在连接目录本地所执行的任何更改，以确保数据的完整性。 在这种情况下，元目录将扮演子服务器角色，因为它只是反映连接目录中创建的对象。下图阐释了这种关系。 对等角色 在这两种角色中，元目录或连接目录实际上都在元目录数据库中创建对象。在目录的持续维护中，这两种角色同样重要。许多企业早已在多个系统中创建了大量目录对象，其中许多代表着相同的资源或人员。 以用户 ID 为例。如果公司有电子邮件、安全通行证和人力资源 (HR) 数据库，则任何给定员工即便不能同时存在于这几个环境中，至少也会存在于其中的几个环境中。而这些系统中的命名约定通常是各不相同。每个单独的目录都包含用户属性；其中有些相同（如地址和电话号码），有些则不同（如应用程序特定的属性）。 要想让所有这些连接目录的管理员更改现有的命名约定，并接受大量他们要管理的新属性，是不切合实际的。在技术上也可能不可行，或不切实际。例如，有些应用程序特定的目录无法支持公司可能使用的复杂命名约定或扩展属性。最好的办法是保留本地的命名约定和目录结构。 元目录必须能够在元目录中的对象与其他所连接目录中的现有对象之间建立关系。这种关系常被称为对等关系，或叫关联，因为它在现有对象彼此之间建立平等的关系或关联。下图显示了“对等”关系。 例如，元目录将使用不同命名约定的连接目录中的对象视为与元目录中的对象平等，并在两者之间建立稳固清晰的关系。 如下图所示，元目录能够理解元目录中定义的 Jeff Smith 与 SMTP 地址中的“jsmith”以及 HR 数据库中的“Jeff Smith”都是同一个人。 与连接目录相比，元目录中的属性控制 对象可以具有这三种角色中的一种：主目录角色、从属服务器角色，或对等角色。元目录不应强制这些对象的属性继承同样的关系。在某些情况下，本地管理员或用户需要在连接目录中的本地控制对象属性，即使元目录扮演该连接目录对象的主角色也是如此。 同时，管理员还需要灵活地控制元目录中的属性。例如，在很多情况下，用户对象的地址和电话号码属性都应当由用户定义。中心管理员强制更改用户的家庭地址和电话号码并无意义。 即使目录服务管理员在元目录命名空间中集中创建了用户对象并随后将用户对象传播到了连接目录（从安全角度来说算是合理），用户还是有权控制其中的某些属性。这既可以通过元目录实现，也可以通过连接目录在本地实现。下图显示了该级别的属性控制。 从 HR 数据库的例子中可以看到，灵活的属性控制能为企业元目录的实施带来诸多好处。许多公司都希望把 HR 数据库作为创建用户的权威来源。每当招收新员工并将其添加到 HR 数据库中时，HR 数据库可以充当一个主角色，为元目录中的那些用户实际创建对象。但元目录可以赋予用户控制其个人属性的权利，其中包括家庭地址、电话号码和紧急联系人。当用户在元目录中更改了这些属性后，这些更改可以流回 HR 数据库，即使 HR 数据库是创建此用户对象的主角色也不例外。 对象和属性筛选 不管任何给定连接目录和元目录之间的关系如何，都有一个需要考虑的重要方面，即应在元目录中加入哪些信息，加入多少。还要有一种机制来控制有哪些信息将被随后传播到其他集成目录当中。 由于许多目录都有特定的任务，因此将所有信息传播至其他目录中的每个目录并无多大意义。特定于一个目录的对象对另一个目录可能毫无意义。而连接目录中的某些对象对元目录来说也没什么意义，只会制造不必要的混乱。还有一些信息不应当传播到其他的连接目录，例如薪水信息或网络路由表。 元目录控制必须达到能够按照逐个案例的基础进行导入和导出的级别。它必须足够灵活，以便包含给定连接目录中的所有内容或是包含其内容中的指定子集。元目录必须允许管理员有选择地传播元目录内容到任何给定的连接目录。明确地说，元目录服务必须支持同时在对象级别和对象属性级别对导入和导出操作进行筛选。 通过管理员定义的对象筛选器，元目录可以导入某些对象，排除其他对象。下图显示了导入过程中的对象筛选。例如，系统管理员可能希望将 NetWard NDS 中的所有用户对象导入到元目录中，但不希望将 NetWare 存储的路由信息导入到目录中。元目录必须支持在导出操作中使用这些对象筛选器。 与之相似，通过管理员定义的属性筛选器，元目录可以导入某些属性，排除其他属性。例如，管理员可能希望从 HR 数据中导入一个用户名、地址、电话号码和标题，但不希望导入用户的薪水和福利信息。元目录必须支持在导入操作中使用这些属性筛选器。下图显示了导入过程中的属性筛选。 目录信息代理 信息代理使元目录可以访问其他目录中的数据，而无需实际包含这些数据。元目录充当所需数据的指针。 同步方法为在联接中汇总目录内容提供了一个强大的功能集。由于元目录在多个位置间复制和同步数据，因此搜索核心目录服务，而非元目录本身这种局部搜索通常可获得更高的性能。在几个位置之间复制数据还可确保不出现单点故障，因此可增强系统的整体可靠性。 虽然具备这些优点，但同步和复制也并非可适应任何情况的目录集成最佳途径。当数据量非常大时，创建多个目录数据的副本并通过网络复制它们的效率将会很低，尤其是在用户不常访问这些数据时，更没有这个必要。 解决这些问题的常见方法是：
例如，LDAP 第 3 版中就包括客户端引用。使用此模型，当目录服务器不具备客户端所搜索的信息时，可以将客户端指向另一台服务器。然后客户端便可通过向引用的服务器发布后续查询来自动继续其搜索。 虽然这些面向客户端的方法很有用，但它们还不能完全满足企业目标基础结构的需要。LDAP 引用对于将客户端引用到其他目录很有效，尤其是企业之外的那些目录，但它们并不能消除企业对于一个可合理复制目录内容的基础结构的需求。而且，如果开发人员将汇总的数据负载完全加诸在客户端和应用程序上，还是不能为组织创建一个可以集成方式管理大量目录的基础结构。 因此，使用元目录服务器作为信息代理相比之下更具吸引力。代理服务同时包括相对静态的操作和越来越多的动态操作集。 静态代理功能从本质上与 X.500 标准所定义的链接 (chaining) 概念相同。通过允许目录服务器以客户端或服务器的身份访问其他目录中的数据，链接启用了与连接目录的实时连接。如果目录服务器了解其他目录服务器中都包含了哪些内容，它就可以作为其客户端访问这些数据。下图阐释了此概念。 目录客户端从元目录服务器请求实际包含在应用程序或 NOS 特定目录服务器中的信息。由于它知道应用程序或 NOS 目录中的内容，因此元目录可以作为客户端来访问其中的信息，然后再把信息返回给客户端。这种链接的、或代理的请求对客户端是透明的。 链接可以发生在单一目录内，也可以发生在两个不同目录之间。它基于标准的协议或是以供应商特定协议为依据的集成接口。这样，元目录服务器便可以透明地赋予客户端访问其他目录的权限，因而减少了复制和同步的需求。 不过，虽然静态代理或链接请求消除了某些复制和同步的需求，但它同时还引入了其自身的问题。例如，目录间的连接必须始终可用，而且 WAN 和 LAN 之间的性能也可能会是一个问题。 如果 WAN 或 LAN 链接断掉，通过代理访问的目录数据将不再可用。缓存数据可以解决这一问题，但同步副本和同步缓存之间的差异也会成为一个问题。 在 WAN 中搜索，甚至在较大的 LAN 中搜索都可能出现问题。要想制作一个包含代理内容的目录信息逻辑集合，使大型企业中的员工能够轻松搜索其中的信息并非易事。出于这些原因，代理模型不能保证 WAN 或大型 LAN 中的可靠性能和访问功能。 信息代理还支持更富动态的实时功能。当与一般用途的事件和对象模型结合在一起时，目录服务可以代理多种动态功能。应用程序可以注册特定类型的目录事件，例如登录到网络或更改给定对象的特殊属性。这些事件可以触发特定的操作，例如数据库查询或与给定路由器或交换机相关联的参数重新配置。 元目录信息流 元目录可以复制或同步连接目录中的数据，它还可以充当代理，以客户端和其他服务器的身份透明地访问其他目录中的数据。 使用同步方法，目录服务管理员可以将连接目录中的内容导入到元目录中。在导入数据后，元目录会将其自身与连接目录同步。当管理员在元目录中执行更改时，元目录会根据需要将所做的更改传播到连接目录。同样，当本地管理员在连接目录中执行了更改后，元目录也会反映所做的更改。元目录还可以在适当的时候和适当的场合将连接目录中的信息传播到其他目录。 使用代理方法，元目录中的条目（常被称为别名）可提供指向其他连接目录中数据的指针。当客户端搜索和访问数据时，元目录服务器会充当代理，以客户端和其他服务的身份检索数据。 元目录与多个连接目录同时执行这些管理和访问操作，创建出一个比其各部分之和更大的目录，如下图所示。  图 10：元目录信息流 不管资源位于哪个目录之中，最终用户都可以搜索元目录和并查找其所需的资源。在适当的时间和场合下，用户还可以在元目录中放置和修改消息。 目录联接 元目录是组织中所有目录的联接。“联接”功能使得用户可以绘制一幅包含组织中所有资源的总体画卷。通过创建联接，元目录可以创建一幅关于组织、其人员以及其他资源的权威的“大图景”。 下图以人员/用户为例阐释了这一概念。 每个连接目录中的对象都只定义用户特定于该系统的某些方面/属性。例如，电子邮件目录仅定义 Fred 与电子邮件相关的方面。它并不考虑 HR 或网络目录中定义的 Fred 与组织之间的其他关系。另一方面，元目录中的 Freds 对象表示完整的 Fred，因为它汇总了每个连接目录中定义的他的属性，组成了一个表示 Fred 及其与企业之间关系的对象。元目录通过两种目录集成方法来创建联接：同步和代理。 本地数据集支持应用程序并启用数据的本地控制。这种数据分布方法无论是从地理位置和企业角度分析，还是从性能和应用程序的立场分析都十分适合。 联接由来自许多来源的数据组成，它不仅是所有目录信息的实际联接，还是一种同等程度的虚拟联接。元目录数据库包含来自其他目录的数据，而且它还可能实际替换某些目录。它还会同步其他目录中存储的数据。有些情况下，元目录包含指向其他目录中数据的指针，而非数据本身。 目录命名空间集成 命名空间是定义目录中对象的命名方式的规则集。命名方式的不同通常是目录实施过程中最显著的可视差异。例如，在层次结构中允许的层次数目以及名称各部分的长度（字符数）这两个方面，目录可能会有不同的规定。 为了有效地支持目录服务的不同要求，元目录必须支持在其数据存储区中使用多重目录命名空间。尤其是，元目录数据库应当支持元目录命名空间和每个连接目录所原有的命名空间。 元目录命名空间是组织中所有目录的交叉点，形成企业的，或全局的目录。 除元目录命名空间以外，每个连接目录都有其连接目录命名空间。了解连接目录本身与元目录数据库中连接目录命名空间之间的差别十分重要。元目录数据库中的连接目录命名空间包含连接目录中的部分或所有内容，而连接目录则是让用户提取信息的个别目录。 每个连接目录命名空间都只包含连接目录中特定类型的对象和属性。换而言之，每个连接目录命名空间都支持其内容来源环境的本机命名空间。下图阐释了此概念。  图 12：多重命名空间支持 可将这些不同的命名空间设想为元目录数据库中数据的不同“视图”。元目录命名空间提供了一个由管理员设计的包含企业目录的视图。不同的连接目录命名空间按照对象和属性在连接目录中的位置和形式给出了数据中特定类型对象和属性的独占视图。连接目录命名空间的内容在管理员看来就如同它们在连接目录本身中一样。之所以需要连接目录命名空间的原因如下：
以系统管理员使用元目录来管理连接目录为例。如果该目录有问题，系统管理员不应该彻底搜查过整个元目录命名空间，只为管理该连接目录。管理员应该使用可使其直接转至该问题的元目录视图。连接目录命名空间允许系统管理员处理系统特定的元目录子集。 对多重命名空间的支持也是完整、启用目录的管理工具的重要一环。对多重命名空间的支持让系统管理员真正将对象与元目录命名空间集成前，能有空间来放置连接目录对象。接着管理员可以原有格式查看连接目录，以及元目录命名空间。例如，当元目录正常运作时，NOS 目录和应用程序特定目录将逐渐与元目录集成。系统管理员应该能够以不损及元目录的方式，将目标目录的内容集成到元目录命名空间。 多重命名空间支持使得集中目录管理模型变得可能。因为元目录数据库能够支持元目录命名空间和每个连接目录的命名空间，该数据库内包含未驻留在元目录命名空间的目录对象。虽然元目录不会将这些对象传播到其他连接目录，但确实会让系统管理员有空间来管理从连接目录命名空间而来的对象。 身份管理问题 元目录也提供了身份管理问题的解决方案。以下段落的信息是先前讨论的进一步延伸。 如下图所示，人员、应用程序和资源可能散布在企业的各个目录和数据库中，而身份身份是其相关的信息摘要。与人员相关的身份数据包括姓名、邮件信箱、薪水和职称。应用程序身份信息包括可供客户端寻找服务器的网络地址。它还包括应用程序可提供的服务列表。网络资源，例如打印机，也具有身份属性，包括位置和所支持的打印功能。 身份管理的挑战 各式各样的身份数据以及这些数据的众多的存放位置，使得相关管理面临以下的挑战：
常见身份管理案例 多数大型公司已经开始着手某些形式的身份管理项目。常见的包括： 全局地址簿应用程序。 将公司内不同电子邮件目录的信箱信息同步，让用户能够跨越不同的系统寻找其他用户和发送电子邮件给对方。 雇用/解雇的方案。将新进员工的信息传播到所有需要身份数据的系统上，使得服务能够快速地创建。为了预防安全漏洞的发生，员工离职时，系统也必须反向地迅速运行类似的处理程序。 电子商务应用程序。 让企业的身份信息，像是供应商和外部网络用户的数字签名，也能够与防火墙外的目录进行同步处理。 单一登录策略。 跨越不同的平台和应用程序来管理用户名、密码和访问权限信息。 解决方案要求 过去，许多公司都尝试创建含有所有企业身份信息的单一目录。但这样的努力大多失败，原因如下： 许多应用程序都无法轻易更改为能够使用目录。 有些应用程序需以自己的格式保存身份信息是基于重要的原因，例如复制和安全要求。 有时技术上可行，但因为政治界线的影响使得阻碍了完全集成的实现。 这意味着身份数据将继续存放在不同的地方。公司需要查找方法，以便不同的目录服务和应用程序保存机制能够共同运作。假设同时有多个身份储存库，那么身份管理解决方案必须能做到下列各项：
连接要求 身份管理解决方案能够连接越多的目录服务、数据库和应用程序，就越有用。如下图所示，某个储存库中未知的数据可从另一个储存库取得。如果身份管理解决方案能够做到下列事项，就是可以连接到某个储存库：
完整的解决方案需能以下列方式连接数据：
信息管理流程 信息管理流程是管理身份信息在储存库之间移动的处理流程。为了管理身份信息在储存库之间的移动，信息管理流程必须能够做到下列事项：
更改事件处理 每当系统管理员、用户或应用程序对储存库中的某身份数据进行添加、删除或更改动作时，都会生成“更改事件”。如果不管理身份更改，很快就会导致混乱。因此身份管理解决方案必须提供功能来检测更改、运行必要的数据格式转换，然后将应该反映该项更改的所有储存库都更新。例如，如果系统管理员在 HR 数据库内添加了一笔员工数据，这样的更改事件需要让该名人员使用的系统都反映这一添加事项。在下图中，该项更改被传播到其他目录和应用程序。  图 15：更改事件处理 数据汇总能力 当身份信息存放在整个组织的各个地方时，包含来自其他许多储存库之汇总身份数据的目录将非常有用。元目录概念由 Burgon Group 提出，他以术语联接来代表企业身份数据的汇总视图。 有了元目录，应用程序就能够使用单一访问方式和安全性模型访问某个地方的各种信息，而不需要与来源储存库逐一交互。 元目录也能够使性能最大化，因为数据是以索引的形式保存的。在运行时，不需要从可能是跨越 WAN 连接的来源提取数据。为了体现最大的价值，数据汇总能力必须能够做到下列各项：
 图 16：元目录中的数据汇总 相关对象跟踪 系统管理员部署身份管理解决方案时，必须要让身份管理流程引擎了解，Jeff Smith、jsmith 和 smithj 都是同一人。接着，如下图所示，当身份数据随着组织重整而变动时，引擎必须能跟踪这些关系。用户在目录树结构中的位置更改，例如从会计部移到业务部，解决方案绝对不能因此就失去对用户的跟踪。 完整性管理 完整性管理是确保更改发生时，身份数据不会因此损坏或是失去储存库之间的同步。完整性管理功能必须做到下列各项：
所有权 企业身份管理的一个重要方面是认识到应用程序和数据之间的所有权关系必须细心维护。例如，某人的邮箱名称归管理该邮箱的电子邮件系统所有。在大多数的公司内，人力资源系统则拥有识别某个人员是否为现职员工的数据。如果没有企业身份管理基础结构，这些所有权关系在默认的情况下会保留，因为其他应用程序均无权访问及更新电子邮件和人力资源数据。但是，如果部署了同步连接器和信息流程管理，情况就会不同。 举例来说，如下图所示，邮箱信息与 HR 目录之间的同步是由某个连接器负责。 如果某个连接器的配置设置不正确，用户可能在 HR 系统内更改邮箱属性，而连接器可能在电子邮件目录中覆写邮箱的值，进而引起很大的混乱。这种问题的解决并不是单纯地预防更改回流到电子邮件目录即可。HR 系统所拥有的信息，如该人员的主管名称，也会回流到电子邮件目录。 其他的属性，像是该人员的办公室电话可能没有明确定义所有权，而这些数据任何人都可以更新。 解决这种问题的方案，必须能够让系统管理员在属性级别定义和强制实施所有权关系。如果更改合乎所有权规定，则可扩大生效，否则应予以阻挡或回复。例如，如果某人更改了 HR 目录内的邮箱属性，身份管理解决方案就会将属性设置回电子邮件目录内所含的值。 失败管理 将更改传播到多个储存库的能力是身份流程管理技术的关键需求。然而，每当引擎进行多重更新，就有可能发生其中一个或多个更新失败的情况，而使不同储存库中的数据变得不一致。 例如，如果某个人员的职称、薪水和费用额度有所变动，但元目录无法更新应用程序内的用户职称，就会使身份数据处于混乱的状态。通常，这意味着系统管理员必须要调查情况，进行修正。 在数据库系统中，这种挑战通常可通过确保全部更新作为同一个单位一起成功发生或一起取消的事务处理方式来解决。但不幸的是，多数的目录服务和应用程序接口并不支持事务。这表示身份管理解决方案必须以其他方式（如日志式、需求状态机制等）在获得确认前继续提出更改要求，以确保所有的储存库最终都能反映该更改。 参考完整性 身份管理方案与数据库共同面临的另一个挑战是维护储存库之间的参考完整性。参考完整性是指需要维护不同位置中相关数据组的值之间的关系。例如，身份管理方案必须能够确保 HR 系统中所列出的某人员职称与采购系统内该人员的费用额度是一致的。数据库解决这个挑战的方法，是利用存储过程和触发功能，让系统管理员在每次数据值更改时，运行某个业务规则。 现今的目录服务并未提供类似的功能。因此身份管理解决方案必须有能力运行业务规则，拒绝不符合参考完整性要求的更改。只有元目录解决方案能够解决所有这些问题。 以元目录作为企业的解决方案如果 Internet/Intranet、专属电子邮件，和其他目录内只包含关于某地某人的身份信息，则元目录能够包含关于每地每人的身份信息。元目录使管理员可以任何虚拟格式集成任意数量的身份库。因此，元目录成为了企业内身份信息的对象根目录。元目录提供对身份对象合理和统一的视图，而这些对象包含来自各种目录的属性。这样的集成可降低系统管理成本、消除重复、降低差异，并使身份信息得到广泛地应用。元目录有足够的弹性，可以自我调整，以适应任何企业组织、结构、政治，和管理风格，并有足够的动力可随之更改。 来源 元目录会从企业中的其他连接目录和储存库收集身份信息。几乎所有的电子邮件、数据库，和其他目录应用程序都可以用某种形式来导出内容。元目录可通过文件数据交换、或是通过联机、协议驱动的传输来收集电子邮件消息的数据。目录管理员或最终用户可以添加其他的元目录身份信息。 内容 目录通常被认为包含关于人员的身份信息，如电子邮件地址，但这是个狭义的观点。元目录能包含关于现实对象的极多信息。以下这些都可作为对象：
元目录的唯一要求是这些对象必须以某种层次结构形式组织起来。例如，对某个人员的描述可能是某个 Internet 域或某个国家内某个组织某个部门的一员。或者，在跨国公司中，某个员工可能是组织树中，该公司位于某个国家内某个部门的一员。 层次结构中最底部的级别并非都是人员。例如，属于该名人员的文档或是便携式计算机可能表示为某个目录项，并在树状目录中列于该人员之下。 管理 元目录内容和安全性的管理可以集中、分散或两者兼具的方式来进行。创建元目录时，可指定某些数据项的更改只能在连接目录中进行，然后再导入元目录。对其他数据项的更改只能在元目录内进行，然后传播到连接目录。元目录的不同部分可由不同的人员管理。控制级别不但可以延伸到数据项本身，更可延伸到个别属性。因此，用户可管理一些与自己身份相关的信息，例如，电话号码和地址。元目录不会导入任何管理模型。而是让适当人员创建目录，符合其所管理组织的真实情况、安全性和访问控制要求。 记录目录服务体系结构目录解决方案的管理、支持、操作和维护的进行都有赖于对目录服务部署的正确记录。在主动管理、操作、支持或维护任何东西之前，都必须先了解对象、其运作方式、各组织的负责人，以及其在正常负载情况下的功能情况。 六个希格玛价值六个希格玛 (Six Sigma) 价值，取自同中书籍（由 Harry, Mikel, Ph.D. 和 Richard Schroeder 共同编写的Six Sigma.由 Doubleday Press 在 2000 年 2 月出版。书中有下列陈述：
这些价值清楚指地出您需要了解自己拥有的东西，这样才能以有意义的方式影响自己所拥有的东西。这些价值也阐明对 IT 资产的职责和任务。以下段落讨论文档记录和操作。 操作和文档记录 对目录及其支持服务的准确文档记录相当重要。目录体系结构和架构描述的完整正确记录是保持目录健康发展的第一步。 文档记录并不是一次性的程序；目录的记录是延续性的工作，每当更改发生时就必须更新。除了公司目录管理日常所需，文档记录对于企业并购和业务分出这类重大议题也很重要。 良好的文档记录有下列的好处：
操作团队所制作和使用的文档记录通常可按照来源加以分类，例如，根据硬件厂商、软件厂商、服务台、应用程序开发和支持服务分类。 记录内容及记录方法请注意，记录目录体系结构由多个相关的部分组成，这一点相当重要。这些部分包括，但不限于：
以下示例表述了其中应包含的一些内容。 硬件和软件供应商手册 要使用和维护目录产品及解决方案（软件和硬件），就一定要有供应商的产品手册。为了方便所有负责操作、管理或维护目录的个人、小组或部门的使用，这些资料应存储在支持组织的中央存储库中。在硬件和软件版本发生更改时，必须要更新这些资料。 操作手册 操作手册根据目录小组的不同而采用不同的形式。以下段落举例说明了如何根据小组的需求将文档编译成工作手册。 服务台 例如，假设服务台（第一层支持）在响应客户问题的同时，还起着监视系统监督员的作用。这种情况下就需要为此小组建立一组清晰的文档。其中应包括：
当然，这完全基于服务台的能力、组织的规模，以及是否有其他支持小组来监视和响应目录问题而定。 目录操作 目录操作（第二线支持）是负责服务器维护、备份和还原以及监视（性能、状态等等）的小组。 目录操作应该有清楚、一致且最新的手册，详列以下项目：
目录体系结构 目录体系结构由系统架构师、工程师以及所有第三方顾问或系统集成商组成，他们协助目录的设计、部署、支持和升级。此小组需要以正式操作手册的形式访问下列信息：
并不是所有的支持组织都象上述示例一样构建而成，但是为了使支持生产目录解决方案的作业达到最佳执行效果，每个支持层都应具有最新的正确信息，这一点至关重要。 自下而上记录（物理设计） 首先要了解目录部署的物理布局（体系结构），这一点是非常重要的。如果企业具有多个目录，且正在将之移动到元目录解决方案中，以简化和集中化管理，合并服务，从而更好地实施启用目录的应用程序，就需要仔细记录落入此范围的所有目录解决方案。 最可能的情况是，协助初步设计和部署的系统集成商、增值代理商以及顾问或目录供应商，能够帮助您完成这一重要步骤。最理想的状况是已拿到物理设计的图表（基础结构设计、体系结构配置、服务器位置、服务等），作为目录设计和部署合作项目的一部分。如果还未提供，建议向相关对象请求项目的所有文档。 有各式各样的工具和实用程序可协助目录解决方案的图表绘制。例如，绘图和图表软件 Microsoft Visio® Technical Edition 已推出多年，该软件很适合创建计算机和基于网络的部署的绘图。除了这个不错的选择外，还有许多的其他程序也可以很好地完成工作，且更加易于使用和更新。不管使用哪种工具来获取此信息，都必须确保信息的准确性和最新性。 自上而下记录（逻辑设计） 了解数据在逻辑上如何流过目录（进程、应用程序、自动化工具等等）和了解物理设计（服务器在网络中的位置）同样重要。如果不了解目录在逻辑上和物理上如何运作，就无法主动监视性能、完整性和可靠性。还有在出现问题时，也不能够准确地排除问题。 在将物理体系结构绘制成图表时，下一步骤便是返回并记录：
除了记录构成目录的所有进程组件外，还应该确切地描绘出数据如何流过系统，以及哪些进程和应用程序必须依赖他者运行。若要详细描述要记录的重要信息，至少要了解下列信息：
监视目录组件监视目的监视是判断所部署目录解决方案运行状况如何的唯一途径。实践证明，未启动主动监视功能的公司总是会面临危急状况（本来可预见及可避免的灾难），很快进入进退维谷的境地，必须要不断地对受到故障或服务中断影响的客户做出响应。客户或最终用户对某一服务中断报告了多少次（通常通过致电服务台，说明连接或访问系统或服务的问题）？经过深思熟虑后，可以实施主动监视计划，这最终会节省时间，节省资金，并可以大速度地提高客户满意度。 监视简介目录是计算环境的心脏和灵魂，用户可用来登录网络，验证服务和应用程序，并在网络范围查找其他的用户和资源。这些核心目录服务的中断会导致用户和应用程序当机，可直接导致生产效率下降和资金损失。 通过监视目录，只要发生中断，马上便可知晓，在有些情况下，甚至在中断发生之前，便可获悉。使用更加复杂的工具，可以进一步预测失败，了解存在性能降级的发生点，并使用所捕获的信息调整系统。 监视系统由三个元素组成：
下图描述了这些信息，并在接下来的段落中进行了详细的解释。 设备和应用程序探测。此元素为函数或进程，负责定期检查被监视服务、设备、主机、应用程序或其他系统的状态。当设备不能响应指定的探测时，便会生成警报，说明故障设备及故障的特性。 事件相关性模块。此元素接收来自探测模型的输入，并对这些输入进行相关性，以确定故障根源。然后再抑制可能会由于其他事件发生的事件。例如，如果路由器出现故障，便会影响所有主机、系统或设备，并延伸至下游设备，从而使其暂时无法使用。抑制间接事件后，该模块便构造一个多个警报，将这些警报转发给通知模块。 通知模块。此模块接收来自相关模块的警报，并为相应（预编程）响应者或负责方生成通知。此模块还可能为预编程的自动响应系统生成通知，以重新启动服务或一些专为解决故障而设计的其他补救措施。 上图显示的监视系统是一个概念模型。模块中的任何一个元素都可由人员或是软件应用程序来运行。其目的是使这些元素尽可能地实现自动化，并集成在一个用于满足特定监视需求的富有凝聚力的可预测解决方案中。 监视和监视系统的类型从实质上讲，监视器共分为三种类型：硬性错误监视器、软错误监视器和性能监视器。 硬性错误通常作为硬件或网络故障的直接结果出现（也就是说，当目录服务器崩溃或丢失磁盘时，导致目录功能和服务的丢失）。 软性错误通常是由编程或数据问题引起，导致目录中数据不正确或不一致。 性能监视则针对系统的性能提供宝贵的反馈消息，并且识别瓶颈、争用点和性能降级。性能监视还可以提供基本信息，允许管理员捕获趋势信息，这种信息对了解何时执行容量规划或何时升级目录基础结构非常有用。 市面上有许多监视系统可用，而且很可能都涵盖上述全部或多数的核心元素。选择解决方案的决定因素有：目录解决方案、产品、生成方式（集中式或分布式）以及与管理和客户签署的服务级别协议。 监视方法有许多方法可用于实施监视。本节讨论最流行且经过证明的方法。 简单网络管理协议 (SNMP)。虽然 SNMP 是网络硬件（如交换机、集线器和路由器）管理中使用最广泛的应用程序，但 SNMP 还可用于监视和管理在服务器和其他支持设备上运行的应用程序和进程。SNMP 允许管理应用程序监视网络上实体的状态。当某事件或错误发生时（如服务器进程异常终止时），SNMP 陷阱机制还可使管理应用程序获得异步通知。 LDAP 探测。监视目录最直接有用的一种方式是通过从客户端连接并发布 LDAP 命令和/或请求来探测目录。例如，简单的探测工具连接到目录，并搜索预确定的条目（为此目的专门建立的条目）。如果响应位于预先指定的响应窗口内，则可视为目录运作正常。如果未在预指定的窗口中，探测工具则会生成错误（或警报，或自定义通知）。 操作系统特定的探测。大多数现行的操作系统都附带一些为监视各自服务而提供的工具，其中包括其本机目录服务。这种信息可协助判断目录是否因为操作系统的关系而发生问题。 间接监视。 对直接接触（使用或访问）目录的应用程序进行监视可提供较接近用户观点的系统响应和系统可靠性消息。 日志文件分析。可自动扫描目录的日志文件，查找指出错误条件的事件。此外，它还可以监视说明性能问题的条件。日志文件分析还是执行主动监视的一个好方法。 一般监视规则本节详细描述了监视目录的一些基本概念和规则。 低调监视 应该清楚了解监视策略的含义。设计不良或实施不佳的解决方案可能会对目录解决方案的性能和操作造成负面影响。总之，应努力让监视尽可能不引人注目地进行，而同时又能记录到所需信息。 如何让解决方案不引人注目？必须尽可能地实施轻型但能提供所有相关信息的解决方案。例如，如果使用探测器，便足以检索单个条目，这说明目录是功能条目，而不是多个或无数条目。此外，只有在绝对必要的时候才探测，保持适当的响应。如此可限制对目录的额外负担，并试图限制对服务的额外负载。每 5 秒探测一次目录，尽快返回失败数据，但这可能会给服务施加过量的负载。每一分钟或者甚至每 15 分钟探测一次通常效果也是很不错的。当然，探测频率通常要视现有服务等级协议而定。 连串失败 如果出现失败，还可能触发监视解决方案中的其他警报。例如，如果一组复制的目录服务器出现故障，这便可能给其他服务器施加额外的负载，结果让这些仍在正常运作的服务器生成警报。如果发生这种情况，则可禁用非关键服务或应用程序，以减轻施加到其他服务器上的负载。或者，可主动地重新检查容量功能，提供一片适度的空间，避免类似事件再度发生。 维护问题历史记录 对监视加以设计，便可以提供事件和问题的准确历史记录。例如，如果使用以标准格式记录事件的商业网络管理和监视系统，则要定期提取目录相关的条目，并将这些日志编译和保存到中央位置，供以后定期查看。这些提取出的日志可提供关键的趋势数据，帮助识别再现问题（有用的因果信息）、帮助进行容量规旬，并提供与目录系统有关的整体可靠性和可用性的完整信息。 维护书面计划 最后，为故障、事件或问题的每种类型或实例，创建一份书面计划，提供及时、精确、一致且“可重复使用”的反馈信息。重点在于可重复使用。如果对重复发生的事件和运行解决问题的一致计划没有加以记录留存，那么时间、资源和金钱就都浪费了！ 通知技术 如果没有通知负责人，使其可以采取行动计划，那么积极捕获实时事件信息也是没有任何价值的。事件通知可实现四个重要目标：
一旦检测到问题，系统就应通知负责修复问题的人员。这通常是较高级别的资源，如系统设计师、工程师或顾问，解决方案就是他们设计和部署的。根据问题的本质和严重性，以及事件回应能力的复杂度而言，这样的人员可能是适当训练过的系统管理员或技术人员，负责响应目录中断事件。这种类型的通知通常很紧急，特别是在目录作为关键任务以 24/7 模式运作时，更是如此。通知的形式通常为电话或页面。 通知系统还应通知负责目录管理的小组。这种类型的通知通常是知会性质的，可能采用电子邮件的形式通知负责小组：存在问题，而且问题正在解决中。负责修复问题的人员与提供管理支持的小组应保持密切协作，这一点极为重要。 用户和客户可能还需要知道是否有中断发生，最不希望见到的情况是由用户或客户首先通知有问题发生。虽然客户不需要知道问题本质的细节，但最好还是让他们知道有中断发生（或预期中断的到来），并在故障期间提供一些反馈信息。这样的通知可能采用电子邮件的形式进行；或者，如果电子邮件系统也受到了事件的波及，则可能用网页列出系统的故障信息，或是用全球电话语音邮件消息，甚或是简单的服务台人员通知，让他们在客户来电求助时告知相关信息。 采取行动在捕获到事件，并以适当的方式通知了适当的人员后，便应采取下列行动：
这些可能听起来都是常识，但是这个关键阶段常常因为频繁的危急模式或资源限制而被忽略。但如果已经实施了本文其他段落所列的主动式步骤，那么绝大部分的工作可说是都已完成。 除了因果分析以外，在日常的操作和技术中还可窥见长期、持久解决方案所需的多数工具和技巧。关于如何采取适当行动的进一步信息，请参考本文的“管理目录”和“维护目录”两节。 管理目录管理目录解决方案与软硬件组件所提供的安全、防护和功能等日常进程有所关联。软硬件组件的安全和防护是有待解决的最关键问题。MOF 安全文档中非常详细地介绍了这些问题。 目录服务体系结构由两个基础部分组成：物理（硬件）组件和编程（软件）组件。主动管理可提供可靠性、可用性、可支持性和可预见性等优点。以下的几节讨论如何维护目录硬件和软件，以及如何实现这些收益。 硬件管理概述硬件管理与前面各节所讨论的目录体系结构有着密切的关联。正如前面所提到的，如果不知道系统的位置、功能、依赖性、与其他进程、功能或应用程序的交互关系的话，就不可能管理系统。如果还未完成管理计划的文档记录阶段，请先回头继续完成该过程，再来尝试本段所列的软硬件管理过程。 这个主题也与监视部分也高度相关，原因在于能够主动管理某个硬件的能力，与监视系统状态的进程良好与否密切相关。 软件管理概述软件管理还与前面所讨论的目录体系结构有着密切的关联。如前所述，如果不懂系统的话，就不可能管理系统。如果尚未完成管理计划的文档记录阶段，请先回头继续完成该过程，再来尝试本段所列的软硬件管理过程。 如同以上硬件管理段落所述，软件管理也与监视部分高度相关。原因在于能够前主动管理某个程序组件的能力，与监视系统状态的进程良好与否密切相关。 总之，管理目录服务硬件就要知道各个硬件所在的确切位置、其用途，以及其在部署环境中执行功能的状况如何，是否能够满足要求。同时还要实施流程，以便在出现问题时藉此来以层状方式利用可用的支持资源。这意味着要定义一个适合于体系结构的层状支持系统，与可用的支持小组结成联盟。在设计目录的支持模型时，要考虑的重点有：
维护目录本节详细描述维护目录及支持目录服务的过程。管理计划的这一阶段详述通过备份和还原方式保护目录的日常过程，然后阐释了如何解决更加广泛的灾难恢复。对于灾难恢复，相关计划必须包含一系列步骤、过程和方法，其中涉及灾难准备、灾难避免，然后才是灾难恢复。以这种方式制定计划降低了使用计划内恢复部分的可能性。 创建目录的备份和还原计划目录中包含的数据对组织的基本操作和生产效率至关重要，或在不久的将来会非常重要。如果目录由于某种原因（例如设备故障或数据损坏）而变得不可用，企业将遭受生产力下降和财务方面的损失。开发关于目录及支持系统组件的健全备份和还原程序可确保不会损失重要的目录数据或配置设置信息。 开发备份和还原步骤本身也同样重要。只有一个磁带备份过程，而没有一个经流程负责人员定期测试的清晰、简洁、彻底的可执行还原计划会将企业置于一个危险的境地，当尝试快速设计这些细节时，可能给企业带来数据损失或严重的系统当机时间。 备份和还原目录的基础和文件系统一样，目录数据存储在大容量存储设备上，如硬盘驱动器。数据可能由于下列原因而遭到破坏或损坏：
如果上述任何事项影响到目录，都需要通过一种方式来恢复到原来正常的生产操作状态。用户可通过从目录尚是完整时所做的备份来还原目录（数据和配置）。 目录备份的方法有两种：
使用传统的媒体备份和还原 就和存储在磁盘子系统中的文件系统一样，也可以将目录数据和配置文件备份到传统媒体中，如磁带。用户还可以将其备份到单独的本地或网络磁盘驱动器。如果出现服务中断，便可以使用这些备份来还原丢失或遭到破坏的数据。 虽说如此，备份目录在下列方式上却还是有别于备份文件系统：
除了上述的磁带媒体外，还可以使用磁盘镜像技术来保护数据。镜像是一种技术，其中写入主磁盘的数据也同时写入辅助磁盘。如果主磁盘发生失败，辅助磁盘便可作为备份使用。 无论是媒体还是技术，都迫使用户使用可定期传输到公司外部地点的媒体。如果备份在灾难发生时也受到损坏，那么备份也就再没任何用处了。 使用复制技术备份和还原 虽然传统的备份和还原技术可以保护数据免于丢失，但这些技术却有一个大的缺陷：数量巨大的还原可能需要花费数个小时才能完成。在恢复生产系统联机中，这种延迟可能背离了既定的可用性和可靠性承诺。使用复制作为提供数据容错和冗余可有助于避免与传统还原技术相关的昂贵的当机时间。 副本是目录数据的联机副本。一旦服务器发生失败，对等的副本便可在失败服务器修复期间提供持续的服务和数据访问。在恢复服务器时，可以将之作为副本服务器恢复到文件夹中。如果副本设计中留有足够的容量（服务器数量以及服务器围绕体系结构的分布方式），用户将不会受到单一服务器失败的影响（事实上，用户决不应该知道存在这种问题）。 目录复制还有另一个优点：因为目录复制通常始终是最新的，管理员不必顾虑还原过期的目录副本，还需执行增量更新，或再次重新与其他的目录副本同步。虽然这是比较明显的优势，但用户还必须要知道大多数的目录支持“松散”一致性，在这种情况下，对目录所做的更改一般在传播到复制服务器的其他部分之前，先存储在一个复制中一段时间。同时还要了解并无法保证所有复制始终具有最新的更改。副本数据的一致性和同步属于设计问题，而且基于特定的性能要求。 复制可以通过两种形式进行：单一主机和多重主机。在单一主机操作中，只有一台服务器（主机）能够接受目录更改，所有其他副本都是只读的。如果主机服务器发生失败，则在主机恢复，或将另一副本升级为主机角色之前（假定目录解决方案支持这种升级），都无法对目录进行更改。 多重主机则是较为强大也比较灵活的解决方案，即便发生失败也比较容易恢复，因为服务器集中的其他副本主机可接受和处理对目录所做的更改。在多重主机环境中，如果某一主机发生失败，只需简单地将其脱机恢复，然后待准备停当后再将之重新建立为副本即可。 将传统的备份技术和复制技术结合起来进行数据保护虽然复制可以提供效果最佳的实时联机数据保护，但传统的备份则是大范围恢复的最佳方式，例如在出现站点灾难的情况下或从目录中损坏或不正确数据恢复时。 最佳途径是合并这两种技术，形成最广泛、最灵活的数据保护方法。在网络范围内的同步和更新、负载平衡以及容错中使用复制是当前分布式目录技术中的最佳方法。但是，还要定期针对整个目录和配置信息执行集中化传统媒体备份，提供必要的多一层保护。将这些媒体的其中几份副本存放在公司之外的地点，可确保不论发生哪种灾难，最终都可以恢复工作生产的完整状态。有些公司自己提供公司外的存储和磁带轮转、拿取以及递交服务。其他公司则与第三方厂商达成协议，有偿提供这些服务。不要考虑如何决定去做，想做就做吧！ 目录备份和还原计划注意事项创建数据保护计划的第一个步骤是评估当前以及预期的生产状态。要这一步骤完成时，应能够轻松回答下列专为帮助评估数据保护需求而设计的问题。
排除目录体系结构的故障在目录生命周期期间，难免偶尔出现故障。根据问题的类型和严重性，遇到的问题可能从性能的轻微降级，到目录服务的完全失败。当有问题发生时，目标是最小化损坏程序、尽快使目录恢复完全服务，并了解这种问题，以便可以采取一定的步骤防止其再次发生。 目录问题可划分为以下三种类别：
本部分详细讨论了这三大类别，旨在通过有意义的故障排除提高意识级别，并增强对问题的主动响应能力。 发现问题重中之重：在进行故障排除流程之前，首先了解如何发现目录中的问题，这一点是非常重要的。下列是发现目录服务内问题的几个常见方式：
失败可能由以上的一个、一些或所有来源同时检测到和报告。例如，如果目录服务器无法访问，网络管理或监视解决方案可能会报告这一问题，与此同时，最终用户也以电话通知服务台。如上所述，最终用户可能便是报告依存服务访问问题的人员。 操作人员则可能在运行计划维护和数据更新过程时报告问题。无论如何，发现问题的进程部分就是确立事件之间的相关性，这样才能够了解影响依存进程的根本问题。 最为理想情况下，应努力消除最终用户首先发现和报告问题的可能性。这一点可通过设计良好并经过深思熟虑的监视和通知计划的方式完成。这虽然需要仔细制定计划，但最终结果却是非常显著的。 遭遇到问题时，应与最终用户、服务台、操作人员、系统管理员和负责服务级别协议的经理就受影响的系统进行适当可行地沟通。适当的沟通可以采用下列形式进行： 存在已知问题的发生。
预先就如何在存在失败或中断时通知所有受影响和相关方的问题妥善规划。常用的方法包括将故障信息发布到网站、通过电子邮件的方式发送全局或组/应用程序特定的消息、将中断信息发布到 Usenet 新闻组，以及通过录音的电话消息提供状态信息。 问题类型如同先前段落所述，目录问题可分为三种基本类型。下一部分将以更加详细的信息讨论这些不同的问题，从而提供根本原因和解决方案信息，以帮助处理这些在引发时产生的问题。 目录中断第一种类型的问题是目录中断。当全部或局部的目录服务变得无法使用时，就可能导致目录中断。可能是因为网络问题使其中一台或多台服务器变得无法访问，或是因为目录服务器硬件或软件发生失败而引发中断。当中断发生时，用户无法接收任何服务。 目录中断的原因 目录中断的成因不外乎两大类：硬件失败和软件失败。可发生失败的硬件包括网络组件（如路由器、交换机以及网络接口卡和线缆）和服务器组件（如处理器、内存、磁盘系统以及电源供应系统）。中断也可能是电源中断的结果。 软件失败可包括操作系统或程序、应用程序以及支持目录的服务。也有可能是同时在目录服务器上运行的其他软件发生失败，造成目录服务的中断。 目录中断的征兆 当发生目录中断时，用户和启用目录的应用程序都完全无法接收到任何目录服务。因为 LDAP 是客户端服务器协议，因而这种失败在连接到目录服务失败时发现。目录中断共有三种基本症状：连接超时、连接拒绝和连接中断。 目录中断的解决 如果目录中断的根本原因是硬件失败，常规操作则是替换失败的系统，并重新启动。例如，如果中断原因是供电系统发生失败，那么只需简单地替换失败单元并重新启动服务器/服务即可。 但并非所有中断都这么容易修复。假设中断不仅仅造成目录服务的中断，还在系统失败时造成了数据的损坏。这是一种全然不同的挑战，它不同于简单替换失败组件并重新启动设备。在这种情况下，需要进行规划的不仅仅是硬件的替换。还需要考虑灾难恢复计划上下文中数据的一致性、可用性、可靠性和容错。这些问题都在服务级别协议的规范范围内；考虑小组对当机的可忍受程度，然后制定硬件冗余计划，在某一场所存储空闲部件，以及将硬件故障移动到相应的设计中。除硬件中断之外，还要与负责灾难恢复计划的员工协调这种类型中断的响应。 性能问题另一类常见目录问题是目录运行性能不良所引发。性能不良的现象包括：目录的整体性能可能极差，或特定类型的目录操作（如电话号码更新）可能变得很慢。性能问题可能持续发生，或是偶尔发生。这类问题的故障排除需要仔细分析并特别注意细节。 性能问题的起因 不恰当的配置软件是目录服务较差执行效果最为常见的原因。设置不当的目录服务器可能不是以最佳状态执行，或可能根本无法执行。例如，大多数的目录服务器软件使用基于 RAM 的缓存来临时存储频繁访问的命令或数据。如果缓存空间太小，服务器响应可能会非常缓慢，或根本无法响应（似乎被挂起）。 另一方面，如果缓存空间过大，服务器的虚拟内存系统可能要发生过度的分页处理。无论哪种情况，都需要执行适当的系统分析，并调整所有影响性能的参数，以便整个系统可在最佳状态下运行。目录产品供应商能够提供可帮助提高性能的性能调整规范。此外，还需要执行额外的调整，以满足部署的特定要求（也就是如何使用解决方案）。 另一个常见问题是服务器处理的目录搜寻类型缺乏适当的索引而导致。大多数的目录产品支持对属性的搜索。然而，如果是对未创建索引的属性进行搜索，性能可能会相当差，因为服务器可能要找遍数据库中的每笔数据，以找出符合的项目。如果服务器需要花费相当长的一段时间来响应简单搜索，则应检查客户端是否在其搜索筛选器中使用未加索引的属性。 最后，还可能在目录服务器软件或操作系统中遇到性能降级的错误。软件供应商越来越普遍采用 World Wide Web 来通知客户相关的补丁程序、升级或修复，并发布包含其产品相关重要且实用信息的知识库。此外，Usenet 新闻组是了解已知错误、问题、变通方法和补丁程序的超大型资源。应熟悉所有供应商和基于 Web 的相关知识，以及产品的特定故障排除资源。 性能问题的征兆 性能问题的征兆范围从服务极为轻微的服务降级到彻底失败。所出现的症状可能会影响所有用户，或是只对一小部份的用户产生负面影响。例如，不适当配置的缓存可以导致所有用户以及启用目录的应用程序性能不佳，而丢失属性索引则可能只导致频繁查询该属性的用户的性能下降。 性能问题的解决 在排除性能问题时，必须要按照一定的逻辑步骤谨慎行事。仔细记录，精确地描述报告的问题，然后自己再尝试重建问题。如果问题无法重现，则应考虑从个别环境之间的差异入手。这些环境是否连接到同一台服务器？是经过身份验证，还是以匿名方式连接？他们是否位于临近服务器的网络中？可尝试着排除每种独立差异，直至用户问题可精确重现为止。 如果需要进行小规模的配置更改，问题的修复就是小事一桩，而如果发现软件错误，需要升级其中某个目录支持应用程序，那么问题的修复则可能需要一个详尽的修复过程。 如果没有可以使用的修复程序，是否有短期的变通方法？能否以某些方式重新配置目录来缓解这些影响？ 无论哪种补救方法，都要投入一定的时间详细记录问题、原因、短期修复或变通方法以及长期最终的解决方案。软件问题可能很复杂；能够与同事或操作小组共享越多的故障排除心得，整个小组就越能够有效地为用户提供高质量的解决方案。 目录数据问题目录数据问题可能由于信息的遗失、多余或不正确而导致。在最坏的情况下，目录服务器数据库可能会受到软件错误、操作系统错误或操作系统错误的破坏。总的说来，这是最为常见的目录数据问题类型。 数据问题通常是一些其他问题的产物，如不适当地配置软件。其他情况下，数据问题可能由目录管理员的不恰当操作所引起（根级别的管理员，甚或是启用目录的、应用程序特定的管理员）。数据问题本身也会引起其他的问题。例如，如果访问控制属性被错误更改，用户便可能无法再访问其完全有权查看的数据，也可能为用户提供错误信息或他们无权查看的信息。 目录数据问题的起因 当目录中出现不正确数据时，则必是某些人员（或某一进程）将该数据放置到了目录中。例如，要删除某个离职员工的数据时，误删了某个现职员工的数据。从更大的范围讲，协调人力资源数据库数据库记录的自动更新服务可能会由于软件错误，而将不正确的员工信息放置在目录中。 除非是数据被破坏到服务器崩溃或无法启动的地步，否则通常监视软件是不会检测到这种类型的问题的。如果不主动监视数据的质量，则通常要等到用户反映问题时，管理员才会得知问题的发生。 若要具备更高的主动性，请考虑在目录中开发监视数据量的工具，或在用于与外部数据源同步目录的软件中，内置验证工具。这种工具可以在最终用户识别和报告前，或成为从根本上妨碍目录最终运行的更大问题之前检测到问题。 目录数据问题的征兆 当目录中有不正确的数据出现时，应用程序可能开始表现得容易出错或不正确。例如，如果有效的用户条目被错误删除，用户电子邮件会被退回给发送人，因为目录服务中的查找或转发代理无法识别该用户。 一般而言，如果目录的运作看起来正确无误，但用户不断报告有不正确或错误的行为，那么就需要检查相关/相对目录项目的内容。 如果目录包含有关网络资源（如文件服务器或打印机）的信息，甚至可能会发生更加细微的错误。如果相应于这些设备的目录条目被删除或破坏，这些设备所提供的服务也将不再可用。 此外，如果数据库文件遭到损坏，征兆可能会非常微小，也可能非常明显。目录中的所有条目都可能会消失（这种就很明显），也可能在执行特定类型的查询或搜索时，无法返回特定条目或属性。强大的服务器软件可以预防其中大部分的问题，但是在用户试图使用目录进行正常操作时，操作员失误可以引入许多类型的数据不一致，从而造成严重的破坏。 如果损坏非常微小，可能发生了好一段时间都无法察觉。在处理损坏的数据时，要始终明确一种可能性，即这种损坏实际上已发生了一段时间，只是现在才刚刚察觉。 目录数据问题的解决 如果已确定目录中存在数据问题，首先要做的是确定数据的破坏程度。若要进行此操作，管理员需要了解目录中应具有的确切内容。好的开端是查看目录内容。目录中的条目数量是否正确？如果条目太少，则说明条目已被删除，为了谨慎起见，可能要关闭一些或所有自动或依赖服务或应用程序。例如，如果整个部门或组的条目全部丢失，则应谨慎关闭该组的电子邮件服务，以便在未找到该组的有效目录条目时不会将其邮件返回给发件人。 如果有所怀疑，最安全的做法是关闭受影响的服务器。启用目录的应用程序（但必须是那些编写良好的应用程序）通常可以注意到目录不可用、报告有意义的错误，然后在稍后的时间再次尝试操作。如果问题服务器没有关闭，并有数据遗失，或包含不良数据，则访问或使用该目录的应用程序也可能由于使用损坏数据而开始出现失败。 损坏程度确定后，管理员则需要开始着手修复数据。修复数据方式取决于损坏的程度、问题原因的了解程度以及目录内容相关信息的数量和准确度。例如，如果只是单个用户条目丢失，则最好是简单地重新创建用户，并还原安全和应用程序属性。如果整个目录都被错误进程或过于疲惫的操作员删除，最好是现在便立即移动至灾难恢复模式，并开始使用恢复计划还原目录。 在还原目录时，管理员需要完全了解所发生的事情，并执行因果分析。在执行因果分析时，需考虑以下问题：
无论问题的原因是什么，也无论找出问题需要花费多少时间，管理员都需要完成这一关键步骤，直至完全了解所发生的事情，并采取适当的步骤来防止问题的再度发生。 故障排除流程图以下的流程图以故障排除的形式显示了执行正确且适当的问题管理所必需的步骤。  图 21：故障排除流程图 故障排除检查清单在使用目录遇到问题时，可以使用下面的检查清单。该检查清单涵盖了前面讨论的三种问题类型，同时还包含若干与安全有关的问题。本文档并未涉及安全问题。有关安全的详细信息，请参阅 MOF 安全管理白皮书。 目录中断
性能问题
目录数据问题
安全问题
角色与职责目录服务管理的主要角色和相关职责都是根据业界的最佳实践进行定义的。根据组织规模、组织结构以及 IT 部门与其所服务的企业间现有的基本服务层协议的不同，组织可能需要合并其中的某些角色。 以下段落描述了与目录服务有关的角色和职责。 目录管理员目录管理员是进程的所有者，负责端对端的目录管理进程。目录管理员是 MOF 团队模型中定义的操作角色群集的组成部分。 关于进程设计和/或重建工作，由于目录服务经理是进程的所有者，负责带领并说明此进程及目录管理进程执行期间所执行的所有活动，因而目录服务管理员对此进程负最大责任。 因此，目录管理员负责所有关于目录管理和其活动的流程改善。目录管理员也应该投入相当的时间设计流程改善，并与各不同业务单位的管理阶层和进程成功的受益者维持良好关系。 目录管理员：
目录设计师目录设计师的任务是创建这样一种目录，该目录应能够将正确的信息提供给那些最需要这些信息的用户或应用程序。良好的设计应要求使用尽可能低的网络带宽、处理器和内存资源及操作员时间，为用户提供信息。 目录设计师：
与其他进程的关系随着目录逐渐成为计算环境基本操作的中心，了解支持目录影响其他操作进程的影响方式也变得越来越重要。下图描述了操作象限中目录服务管理与其他 MOF SMF 之间的关系。  图 22：操作象限中与其他 SMF 之间的关系 系统管理系统管理处理组织所用的管理模型。有些组织偏好这样一种模型，在这种模型中某个站台所有的 IT 功能都由同处该地的一个 IT 专业团队运行。其他的组织则更喜欢使用分布式的分支机构模型，在这种模型中技术和支持员工按地理位置分布。系统管理考查每种模型的优缺点。每种类型的系统管理模型都有其独特的目录要求。例如，目录中存储的用户帐户可能必须要位于用户的临近位置，才能最小化登录所用的时间。分布式管理模型可能还需要目录中对象的委派访问权限。 安全管理安全管理包括规划、选择、实施、管理和检查安全控制所必需的信息。其中还包括响应安全事件所需的进程和过程。由于现在的目录可以提供许多的安全功能，因此这对于目录的操作尤为重要。 服务监视和控制服务监视和控制会监视系统性能的不同方面，以确保满足服务级别协议的要求。负责监视系统性能的管理员必须要确保目录不会变得过于庞大，或者目录不会过度使用网络带宽量。 网络管理网络管理处理组成组织网络的物理组件（如服务器、路由器、交换机、防火墙等等）的维护。目录复制可能需要大量的网络带宽。可用的网络带宽量对目录设计具有一定的影响。 打印和输出管理打印和输出管理处理打印或编译成报告的所有数据，报告可分发给组织中的不同成员。可用打印机及其位置的记录通常作为对象存储在目录中。 配置管理配置设置管理负责跟踪内部所用软件的版本。对于管理员而言，清晰了解并完全控制网络计算机上运行的操作系统、数据库管理系统和所有应用程序的版本是非常重要的。至于目录服务，配置管理则专门控制正在运行的目录版本、部署启用目录的应用程序的版本以及正在运行的支持、自定义生成或第三方工具的版本。 可用性管理可用性管理负责处理整个系统的可用性和当机时间的管理。由于今天大多数的组织在系统当机时，都是处于瘫痪状态，因此管理员应恰当配置和监视系统，以最大化正常运行时间以及重大失败之间的间距时间，这一点对管理员而言极为重要。可用性管理与服务级别协议密切相关，从实质上讲，它是对最终用户在目录可靠性和可用性上的管理承诺。 容量管理容量管理对目录当前和持续操作至关重要。负载容量管理负责在当前系统资源使用的增加，开始接近满载点时，规划额外的资源。目录的执行（响应时间）和扩展须同时满足当前和将来用户的需求至关重要。 故障转移和恢复故障转移和恢复负责在服务器临时当机时，自动变换到备用服务器，然后在该故障服务器修复可用后，再转移回主服务器。由于目录逐渐成为计算环境基本操作的中心，这一点便显得特别重要。 服务连贯性管理危机应变计划与故障转移和恢复密切相关，但处理的是更大规模的灾难。危机应变计划负责处理由于供电意外故障、洪灾、火灾、恐怖行动等原因而导致的整个数据中心失败。如果必须实作危急应变计划，那么目录的还原将是其主要考虑事项之一。 贡献者 本文档所描述的许多实践都来源于 Accenture、Avanade、Microsoft Consulting Services、Fox IT、Hewlett-Packard Company、Lucent Technologies/NetworkCare Professional Services 和 Unisys Corporation 多年的 IT 实施经验。 Microsoft 诚挚感谢上述公司慷慨协助，提供本文档的参考数据。 项目管理团队Jeff Yuhas, Microsoft Corporation William Bagley, Microsoft Corporation 主要作者Stephen Barnard, Microsoft Corporation 协助作者William Bagley, Microsoft Corporation Vicky Howells, Fox IT Jeff Yuhas, Microsoft Corporation 编辑Steve Morgan, Fox IT Patricia Rytkonen, Volt Technical Services
|
|
