第十四章：监测和维护活动目录(三)

前言:

windows server 2008系统相信大家也都接触了有段时间了,尤其最近打上了sp2补丁以后变得更加成熟和完善.

不知道大家的企业有没有已经开始使用windows server 2008 功能级别的活动目录了呢?或者有打算近期将2003升级到2008活动目录环境呢?

呵呵,2008 R2都要马上放出RTM版本了,我们还是赶紧深入了解一下windows server 2008 功能级别下的活动目录吧~

说明:

本文是<WindowsServer2008ActiveDirectoryResourceKit>从这本牛书中摘出来,的,由于原作为全英文并且博大精深,所以可能不少网友都读起来十分头疼.出于此点考虑,本人及夫人合作翻译了其中部分章节,希望能和大家一起学习一起交流,翻译中如有纰漏也希望大家指正,同时因为原作章节内容繁多,加之本人精力有限,所以会以连载的方式刊出.谢谢~

接上篇 : 第十四章：监测和维护活动目录(二)

我们继续来看 ...

 

如何监测活动目录？

可靠性和性能监测器揭露了很多种活动目录计数器和追踪事件可用于实现有效的系统监测。活动目录监测过程包括了追踪这些关键的性能指标并将它们和服务处于正常水平参数的基准条件进行对比。目前监测结果和初始的基准值之间的差距会帮助你判断目录服务当前或潜在的一些问题。

正如前面提到的，一个数据采集设置包含有性能计数器报警器。当一个性能计数器超过特定的性能边界值，可以设置一个报警来通知网络管理部门（在大型组织中往往是监测操作者）。也可以在数据采集设置中配置自动执行的动作，当性能计数器超过边界值时，自动采取措施来补救问题或是采取措施来降低对系统健康或性能造成的损害。

以下是对活动目录监测过程的高度概括：

1. 决定在你的组织中，需要监测哪些数据采集器取得哪些指标。这些会包括性能计数器，追踪信息和注册表项。你所在组织的服务水平协议（SLA）会提供信息帮助你设定性能指示的预期指标和边界值。

2. 创建一个数据采集设置囊括所有的需要的数据采集器。

3. 运行数据采集设置来建立和记录你的基准性能水平。

4. 决定性能指标的边界值。（换句话说，决定你要采取行动避免损害的服务水平）

5. 设计必需的报警系统。你的报警系统需要包括以下：

操作者通报

如果合适的话，采取自动的动作

操作者采取行动

6. 设计抓取活动目录系统健康的历史数据的报告系统。你可以使用报告节点根据数据采集设置运行的日期来记录报告。

7. 执行你的监测方案，按照一个日程表监测关键指标的性能，监测指标的变化和每一个指标对活动目录安全的影响。

接下来的部分讲述监测的详细过程。

建立基准和边界值

当定义了需要监测的数据采集器和性能计数器后，你需要通过创建和运行一个准数据采集设置来收集这些指标的基准数据。基准数据采集设置表示每一类型的数据采集器在标准极限下运行。“标准极限”包括特定性能计数器和事件追踪的最低值和最高值。你需要收集足够长时间的性能信息才能反映出某一特定参数在最高最低活动时的数据范围。举个例子，你要建立验证信息要求的性能基准，要确认监测的时间段有最大限度的用户登录。

当你确定了你的基准值，记录这个信息，并要注明该版本文件的日期。除了用于设定边界值，这些基准数值在判断性能趋势的时候也是有用的。可以建立一张电子表格，记录每个计数器的最低值、平均值和最高值，以及报警的边界值。

提示：当你的活动目录环境发生改变（如用户数量增加或是域控制器的硬件改变），需要重新建立基准。基准需要反映最近的活动目录状态。一个过时的基准对于分析性能数据是没有帮助的。

当你决定了基准，接下来需要决定产生报警和任务的边界值。除了微软的建议之外，并没有可以决定边界值的神奇公式。因为情形不同，你必须根据你的网路架构来决定什么样的性能水平会导致服务中断。对于边界值的确立，开始时要保守一些。（使用微软的建议值或是更低的值）作为结果，你将处理很大数量的警报。当你收集了更多的数据，可以通过提升边界值减少报警的数量。这一过程可能要花费数月，但是会最终为活动目录的某项执行进行微调。

设计一个应对警报的计划是基本的。当你定义你的计数器、基准和边界值时，要确保记录将指标拉回正常范围的补救措施。这个措施应该要包括排错（例如，是域控制器重新联机）转让操作主机角色。如果你的系统达到它的最大容量，你必须增加磁盘空间或记忆体来改正这种状态。其他的报警会促发你去进行活动目录维护，例如碎片整理活动目录数据文件。这些会在稍后的章节“离线碎片整理活动目录数据库”中进行讨论。

性能计数器和边界值

下列的表格中列举了一些对监测和记录活动目录性能有帮助的关键的性能计数器和边界值。需要记住的是每一个企业环境都有独一无二的特性影响着这些值的应用。以这些边界值为出发点，修正这些值以反映你的企业环境的需求。

活动目录性能 表14-1罗列的性能计数器监测着活动目录的核心功能和服务。除非特别指出的，这些边界值都有基准监测决定。这些计数器可以被添加到性能监测器查看即时数据，你也可以添加一个性能计数器数据采集器或是性能计数器报警到数据采集设置中来记录活动目录性能日志和提供报警。

表14-1 核心的活动目录服务和性能

复制性能计数器 表14-2中讨论的性能服务器监测复制数据的数量。除非特别指出，边界值由你之前建立的基准来决定。

表14-2 复制性能计数器

安全子系统性能 表14-3罗列的性能计数器监测关键安全量。除非特别指出，边界值由基准监测决定。

表14-3 关键安全量

核心操作系统性能 表14-4中罗列的性能计数器监测核心操作系统指标，对活动目录性能有直接的影响。

使用事件查看器监测活动目录

除了使用可靠性和性能监测器来监测活动目录，你还可以通过使用事件查看器管理工具来查看事件日志的内容。一般情况下，事件查看器显示下列5项日志：

应用 包含应用软件和程序记录的事件。

安全 包含合法和不合法的登陆企图这一类的事件，以及与资源使用相关的事件例如创建、打开、删除文件或其他对象。

启动 包含启动时操作系统和应用软件记录的事件。

系统 包含Windows系统组件记录的事件。

转发活动 用以存储从其他远程计算机收集的事件。你必须设定一个订阅，来收集远程计算的事件。

另外，对于配置为域控制器的windows server 2008的服务器，以下事件日志会被记录在事件查看器的应用程序和服务日志节点。

目录服务 包含活动目录记录的事件。

DFS 复制 包含分布文件系统记录的事件。这个日志会提供SYSVOL复制相关的信息。

如果windows server 2008域控制器同时也是DNS服务器，下列日志会被显示：

DNS 服务器 包含DNS服务器服务记录的事件。

从管理器工具文件夹中点击时事件查看器查看事件日志。选择你想要监测的服务的事件日志。图14-6的左窗格显示一台同时也是DNS服务器的运行windows server 2008的域控制器。

图14-6 事件查看器管理工具的事件日志

从事件日志中，可以查看错误和警告的事件类型。双击事件来显示日志中的时间细节。图14-7显示目录服务日志中的警告事件（事件ID2886）的细节。

图14-7 事件日志登录的时间属性表

监测什么

监测活动目录整个系统安全，你需要监测服务相关的性能呢个和服务相关的性能指标。你必须确保活动目录和其所在的域控制器处于最佳的运行状态。当你设计监测方案时，需计划监测下列的性能区域。

活动目录服务 使用可靠性和性能监测器中的目录服务计数器和事件追踪来监测这些性能指标。

活动目录复制   复制性能是确保所维护的域内的数据完整性的基本条件。

活动目录数据存储 保存活动目录数据库 Ntds.dit 文件和 .log 文件的的磁盘空间需由足够的剩余空间来保证正常的增长和操作。

DNS 性能和服务器健康 因为活动目录依赖于 DNS 作为服务定位， DNS 服务器和服务必须在活动目录正常限制内操作来满足服务水平要求。

文件复制服务（ FRS ）和分布式文件系统复制（ DSFR ） FRS 必须在正常限制值内运行以确保 SYSVOL 能在整个域内复制。如果你运行 windows server 2008 功能模式，你可以使用 DFSR 来进行 SYSVOL 复制。这需要被监测来保证运行。

域控制器系统健康    监测这个区域需要覆盖整个系统健康，包括记忆体计数器，处理器利用率和页面调度。你还必须确保适宜的时间和时区设置在服务器之间同步，这对于复制和必要的验证十分关键。

林健康 这个区域需要被监测校验可信和站点可用。

操作主机和全局目录角色 对每一个操作主机角色，监测以确保服务器的健康。同时也监测确保全局目录可用来实现用户登录和全局组成员列举。

直接来源：监测活动目录，第二部分

监测活动目录是一个很大的研究课题。如前面提到的，从整体上监测活动目录是十分关键的。因此，即使在本章中我们关注与活动目录的外在信息， Windows 中仍然有一些活动目录外围的东西值得被监测。这样，你才能够监测活动目录生态系统的一般健康状态。例如，这也包括时间同步避免域控制器之间超过五分钟的时间滞后（如果多于五分钟，这个差异会使得 Kerberos 票据无效并且阻止域控制器和用户的验证）。你也可以监测活动目录基本服务，类似于 NTFRS ， DFSR 和 KDC W32 时间。这些服务都依赖于活动目录或为活动目录提供支持，在整个活动目录生态系统中是十分关键的。其他更普遍的方面类似于系统磁盘的磁盘空间和活动目录的数据库大小也是值得追踪的。

一些通常人们不监测东西在某些情形下非常有用 - 尤其是在大型活动目录架构 - 这就是 KCC CPU 利用率。 KCC 指的是知识一致性检查器，它负责通过创建必要的链接对象来确认和构建活动目录拓扑。尽管在 Windows 2000 中， KCC 的性能已经显著提高，监测你的域控制器上的 KCC 的 CPU 利用率会非常有趣，尤其是那些位于你活动目录构建中 hub 上的。

你可以通过简单地改变 KCC 诊断水平到 3 来侦查 KCC 的活动。设置“ 1 知识一致性检查器”注册表项值到 3. 该注册表项位于 HKLM\ SYSTEM \CurrentControlSet\Services\NTDS\Diagnostics 。将其设置为 3 后，每次它触发后， KCC 会在目录事件日志中创建事件日志登录。带有 NTDS KCC 来源名称的事件 1009 和 1013 会显示 KCC 的开始时间和停止时间。然后你可以同时追踪 CPU 利用率查看在这过程中 KCC 是如何影响 CPU 的。这对于划分服务器计算拓扑和服务器执行验证请求的负载时十分有用的。

总而言之，当监测活动目录时，需要从大处着眼。这会避免很多副作用和意外，因为你会习惯于将整个活动目录生态系统作为整体考量，而不是每次只关注一个软件部分。

Alain Lissoir

高级项目经理

活动目录 - 连接系统部门

 

监测复制

如果你的组织中有多于一个的域控制器，其中最重要的一个部分是你需要监测活动目录复制。域控制器之间的复制通常使用管理工具来监测如 Repadmin.exe, Dcdiag.exe 和目录活动日志（在前面的事件查看器中描述的）。

Repadmin 是一个命令行工具用于报告两个复制伙伴之间的复制链接错误。下面的命令显示在 Contoso.com 域中 DC1 域控制器的复制伙伴和任何复制链接错误。

repadmin / showrep dc1.contoso.com

Dcdiag 是一个命令行工具可用于监测域控制器的 DNS 注册项，用于查看命名上下文的安全标识是否有复制的适当许可，分析林或企业中的域控制器的状态。对于 Dcdiag 选项的完整列表，键入 dcdiag/? 。接下来的命令用于检查域控制器之间的任何复制错误。

Dcdiag /test: replications

最后，目录服务日志报告一个复制链接被建立后产生的复制错误。特别指出的是，对于事件类型是错误和警告的复制事件，你需要查看目录服务日志。下面是两个显示在目录服务日志中的常见复制错误的例子：

事件 ID1311 活动目录站点和服务管理工具的复制配置信息没有准确地反映网络的物理拓扑。该类错误说明一个或多个域控制器或桥头堡服务器断线，或是桥头堡服务器没有充当需求的 NCs 的主机。

事件 ID1265 （访问被拒） 这类错误产生于当创建复制链接或是尝试通过已有连接复制是本地域控制器验证其复制对象失败时。这类错误通常发生在当域控制器从网络其它部分断开连接一段时间的时候以及计算机的帐号密码和存储与目录上复制对象的帐号密码不同步的情形。

 

直接来源：监测活动目录复制

监测活动目录复制可以有很多方法来实现。如在这节中介绍的，可以通过验证配置来确保活动目录满足恰当复制的必须条件。你可以通过类似于 Dcdiag 的工具来实现。这是一个在你遭遇麻烦之前的预先验证。然而，你也可以在“事后”通过查看复制活动中的错误来监测你的活动目录复制。你可以通过验证事件日志中的报告事件或是 REPADMIN 的复制错误来实现后一种监测方式。

另一个验证活动目录的方式是阅读活动目录域控制器的共享设置，例如 FSMO 角色。如果一切看起来不错，特定林中的特定域中的 FSMO 角色会和给定的域和林中的所有域控制器一致。如果你在每个域控制器水平搜集到这个信息比集中报告（将这些搜集的结果共享），所有域控制器的 FSMO 角色可以很容易被对比。所报告的 FSMO 角色的不一致表示面临着域控制器报告不同结果的复制问题。

最后但并非最不重要，一个监测活动目录复制的好办法是基于改变射入轨道。该技术包括基于复制监测的目的去更新一个给定的特定的 AD 对象。例如，你可以写一个基于 ADSI 的脚本来修改选定域控制器中的 AD 对象（这个脚本可以根据任务排程的前后关系有规律的执行）该修改仅简单地包括的一个日期和时间在用户对象描述的字符串属性中的的写入操作。因为活动目录自动复制这一类型的变化，可以期望在其他活动目录域服务器的某个点看到该信息的更新。同时，所有其他这些域控制器可以有规律地运行一个补充脚本来读取同一对象，并且将日期、时间的描述属性和 whenchanged 属性的值做对比。

这样做，这最后的脚本可以决定两件事情：第一，可以确定最后一次预期的改变被成功复制（描述属性包括更新日期 / 时间）。第二，可以通过最初写入描述属性的时间 / 日期和 whenchanged 属性中的时间 / 日期的差值计算复制变化产生所消耗的时间。这会帮助你确定所谓的目录的复制潜伏期。除了确定复制工作，复制潜伏期会告诉你活动目录的设计和架构在复制改变速度方面是否达到你的预期值。因此，这也是一个验证你的设计选择和采取措施达到复制 SLA 的好办法。

当然，这些监测需要一些脚本。你也可以参考我网页上 http://www.lissware.net 的白皮书部分去获取一些 ADSI 脚本案例来创建你自己的脚本。

另外，微软操作管理器 2005 和 2007 的微软活动目录管理包严密地执行这一逻辑并且调节 MOM 来巩固和对比这些收集自你的林中的所有域控制器的结果来决定复制潜伏期。

Alain Lissoir

高级项目经理

活动目录 - 连接系统部门