 TechNet Magazine February 2007

TechNet Magazine February 2007

Windows 管理: 了解 Windows Vista 内核：第一部分

对于 Windows Vista，对操作系统内核所做的更改使内存管理到可靠性再到安全性等多个方面都有所提高。我们开始编写此系列文章是要说明内核是如何在进程、线程和 I/O 方面提供改进的。

Mark Russinovich Windows 管理: 在 Active Directory 中委派权限

在 Active Directory 中实现委派可以增强安全性并简化管理任务，且入门也比您料想的要容易。下面是一些简单的委派模型，几乎不做修改即可应用到大多数 IT 基础结构中。

Joel Yoker and Rob Campbell Windows 管理: 深入探讨 Windows Vista 中的新组策略模板

Windows Vista 的组策略模板进行了重大更改。了解所有需要了解的有关新格式（称为 ADMX）的信息，以及这些更改如何改善系统配置的管理。

Darren Mar-Elia Windows 管理: 组策略故障排除指南

要查明组策略的问题根源所在可能非常困难，但了解组策略的工作原理及可能出现问题的位置会使事情变得更容易一些。本概述会帮助您准确地排除各种组策略问题。

Derek Melber Windows 管理: 使用 MOM 监控 Active Directory

Microsoft Operations Manager 2005 管理包可让您更加有效的监控您的 IT 基础结构。了解一下这五种管理包可如何帮助您监控 Active Directory 环境的运行状况、安全性和可靠性。

John Hann Windows 管理: 在安全环境中玩游戏

不管您在家是忙于工作还是沉溺于玩游戏，以受限用户身份运行有许多安全方面的好处。遗憾的是，如果不使用管理员身份的话，则某些游戏将无法正常运行。下面我们来看一看其中的一些常见问题及其解决方法。

Matt Clapham 编辑视角: 内部原理

Joshua Trupin 工具箱: 面向 IT 专业人员的新产品

Greg Steen SQL 问题与解答: 数据库大小、镜像、标记事务及其他

Edited by Nancy Michell 实用工具特别推荐: 组策略库存

Greg Steen 网络专家: Windows 中的 QoS 支持

Joseph Davies Windows PowerShell: 一次编写一行脚本

Don Jones 您好，脚本专家！: 追汽车……和 XML

The Microsoft Scripting Guys 安全观察: 部署 EFS：第一部分

John Morello 桌面文件: 扩展 Windows PE

Wes Miller 现场注意事项: 它只是停止工作

R'ykandar Korra'ti Windows 机密: 祸福参半

Raymond Chen


 Windows 管理: 了解 Windows Vista 内核：第一部分
Windows 管理 Mark Russinovich

了解 Windows Vista 内核：第一部分
概览:
  • 线程优先级和计划
  • 基于文件的符号链接
  • 取消 I/O 操作

这是系列文章的第一部分，探讨的是 Windows Vista 内核中的新增内容。在这一期中，我将着重说明在进程、线程和 I/O 方面的更改；在将来几期内容中将涉及到内存管理、启动和关闭、可靠性和恢复以及安全性方面的内容。
本文的范围仅限于对 Windows Vista™ 内核的更改，尤其是对 Ntoskrnl.exe 和与其紧密关联的组件的更改。请记住，在 Windows Vista 中还存在许多其他重大更改，但这些却超出了内核的范围，因此本文将不予以说明。其中包括对外壳（如集成的桌面搜索）、网络（如新的 IPv6 堆栈和双向防火墙）和下一代图形模型（如 Aero™ Glass、Windows® Presentation Foundation、桌面窗口管理器和新图形驱动程序模型）的改进。而且未涉及的内容还包括新的 Windows 用户模式和内核模式驱动程序框架（UMDF 和 KMDF），因为在较早的 Windows 版本上它们在后级别才是可安装的。

CPU 时钟周期计数
Windows Vista 包含了进程和线程方面的大量增强功能，其中包括使用 CPU 时钟周期计数器以较公平地进行 CPU 分配，以及使用新的多媒体类计划程序服务 (MMCSS)，它有助于媒体应用程序提供稳定的播放。
所有 Windows NT® 版本，包括 Windows Vista 程序在内，大约在每 10 ms 或 15 ms（毫秒）执行一次间隔计时器中断例程，间隔取决于硬件平台。该例程查看它所中断的线程并更新线程的 CPU 使用统计数据，就好像该线程在整个间隔期间都在运行，而事实上，线程可能仅在间隔就要结束前才开始执行。而且，从技术上讲，可能已经为线程分配了 CPU，但却一直没有机会运行，因为执行的是硬件和软件中断例程。
虽然对于报告线程和进程 CPU 使用情况的诊断工具来说，基于时钟的时间计算是一个好方法，但是，若由线程计划程序使用该方法将导致不公平的 CPU 分配。默认情况下，Windows 客户端版本上的线程最多可运行 2 个时钟节拍（如果是在前台中运行则为 6 个时钟节拍）。然而，根据线程在系统上的行为和其他活动，线程实际上可能在 CPU 上根本没有时间或是最多得到 6 个时钟节拍（如果是在前台中运行则为 18 个时钟节拍）。
图 1 显示了两个具有相同优先级的线程同时准备好运行时发生的不公平情况。计划程序假定线程 A 在整个间隔期间内运行时，线程 A 一直运行到下一时间片间隔过期，因此也就可以确定线程 A 已运行完毕。而且，在线程 A 运行期间发生的中断应由线程 A 完全负责。在下一间隔内，计划程序挑选线程 B 来接续，并且要在整个间隔内运行。
图 1 不公平的线程计划
图 1 不公平的线程计划
在 Windows Vista 中，计划程序使用现代处理器的时钟周期计数器寄存器精确地跟踪线程所执行的 CPU 时钟周期数。通过估计 CPU 在一个时钟间隔内能够执行的时钟周期数，它可以更准确地在 CPU 上布置轮循。另外，Windows Vista 计划程序不会根据线程的轮循计数中断执行。这就意味着，在 Windows Vista 上，线程始终会得到至少一次在 CPU 上运行的机会，而且永远不会执行多个额外时钟间隔，这使应用程序的行为更公平，也更具确定性。图 2 显示了 Windows Vista 如何响应图 1 中所示的情况，方法是为两个线程提供至少一个时间片的执行间隔。
图 2 Windows Vista 基于时钟周期的计划
图 2 Windows Vista 基于时钟周期的计划
“查看进程的 CPU 使用情况”边栏说明了用户如何通过使用 Process Explorer 实用工具监视进程的 CPU 时钟周期使用情况。

多媒体类计划程序服务
用户期望多媒体应用程序（包括音乐和视频播放器）能够提供无缝的播放体验。然而，其他同时运行的应用程序（如防病毒、内容索引甚至是邮件客户端）对 CPU 的要求会带来不和谐的因素。为了提供更佳的播放体验，Windows Vista 引入 MMCSS 来管理多媒体线程的 CPU 优先级。
像 Windows Media® Player 11 这样的多媒体应用程序使用能够表明其多媒体特性的新 API，通过 MMCSS 进行注册，它必须与下列按名称排列的注册表项之一匹配：
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\Tasks
图 A查看 Process Explorer 中的 CPU Time 和 Cycles Delta

图 3 多媒体类计划程序音频任务定义
图 3 多媒体类计划程序音频任务定义
在 %SystemRoot%\System32\Mmcss.dll 中实现且在服务主机 (Svchost.exe) 进程中运行的 MMCSS 具有可在优先级 27 运行的优先级管理线程。（Windows 中线程优先级的范围是从 0 到 31。）此线程将已注册的多媒体线程的优先级推进到另一个范围内，该范围与任务注册表项（如图 4 所示）的计划类别值相关联。在 Windows 中，线程优先级 16 及更高级别处在实时优先级范围内并且高于系统上的其他所有线程（除了内核的内存管理器工作线程，该线程在优先级 28 和 29 运行）。仅管理帐户（如执行 MMCSS 的“本地系统”帐户）具有设置实时线程优先级所需的提升优先级权限。
Figure 4 MMCSS 线程优先级 (Close Figure 4)

计划类别 | 提升的线程优先级
高 | 23-26
中等 | 16-23
在播放音频文件时，Windows Media Player 注册音频任务线程；在播放视频时，Windows Media Player 注册播放任务线程。对于已经指明它们在拥有前台窗口的进程中运行时并且在将任务的定义注册表项中的 BackgroundOnly 值设置为 True 时将同时传递流的所有线程，MMCSS 服务会对其进行提升。
但是在 MMCSS 想要帮助多媒体线程获得所需的 CPU 时间的同时，它还想确保其他线程至少也能获得一些 CPU 时间，这样，系统和其他应用程序才能保持响应能力。因此，MMCSS 为其他活动保留了一定百分比的 CPU 时间，并在以下注册表值中进行指定：
HKLM\Software\Microsoft\Windows NT\Currentversion\Multimedia\SystemProfile\SystemResponsiveness
默认情况下，此比例为 20%；MMCSS 监视 CPU 的使用情况，以确保在其他线程需要 CPU 时，在 10 ms 期间内提升多媒体线程所占的时间不超过 8 ms。为了使多媒体线程不占用剩下的 2 ms，计划程序将其优先级设置在 1-7 级的范围内。
您可以通过阅读“查看 MMCSS 优先级提升”边栏了解 MMCSS 是如何提升线程优先级的。

基于文件的符号链接
Windows Vista I/O 的相关更改包括基于文件的符号链接、更有效的 I/O 完成处理、对 I/O 取消的全面支持以及优先 I/O。
终于在 Windows Vista 中见到符号文件链接（或如在 UNIX 中那样称作软链接）了，许多人认为它是 NTFS 中缺少的文件系统功能。NTFS 的 Windows 2000 版本引入了符号目录链接（称为目录接合），允许用户创建指向其他目录的目录，但是在 Windows Vista 版本发布之前，NTFS 仅支持文件的硬链接。
Windows 解决符号链接和目录接合所采用的方式的最大区别在于处理所发生的位置。Windows 在本地系统上处理符号链接，即使它们引用远程文件服务器上的位置。Windows 在服务器本身上处理引用远程文件服务器的目录接合。因此，服务器上的符号链接可以引用仅从客户端才能访问的位置（如其他客户端卷），而目录接合则做不到。为了解决这个问题，Windows Vista 支持适用于文件和目录的新符号链接类型。
已经对许多文件系统命令进行了更新，以了解符号链接的含义。例如，Delete 命令知道不要跟随链接（这样会导致目标的删除），而是要删除链接。然而，由于不是所有的应用程序都能正确地处理符号链接，因此，创建符号链接需要新的创建符号链接权限，而默认情况下，仅有管理员才具有该权限。
您可以在命令提示符下使用 Mklink 命令创建符号链接。命令提示符的内置目录命令通过用 <SYMLINK> 标记符号链接并在括号中显示目标的方式标识符号链接，如图 5 中所示。Windows 资源管理器也可识别符号链接，并使用快捷方式箭头显示。可以通过将“链接目标”列添加到浏览窗口中来查看资源管理器中的链接目标。查看 MMCSS 优先级提升
您可以通过以下方法见证 MMCSS 服务应用到 Windows Media Player 线程的线程提升：播放视频或音频剪辑，运行性能监视器，将图形标尺设置为 31（Windows 线程最高优先级）以及将 Windows Media Player (Wmplayer.exe) 线程对象中所有实例的当前优先级计数器添加到显示内容中。一个或多个线程将在优先级 21 运行。
图 BWindows Media Player 的线程优先级提升

图 5 使用 Mklink 创建符号链接
图 5 使用 Mklink 创建符号链接

I/O 完成和取消
对 I/O 系统所做的大量更改可改进服务器应用程序的性能。这些应用程序通常使用称为完成端口的同步对象来等待异步 I/O 请求的完成。在 Windows Vista 之前，当此类 I/O 完成时，已发布 I/O 的线程将执行 I/O 完成工作，这可切换到线程所属的进程并中断所有正在进行的其他工作。然后，I/O 系统将更新完成端口的状态，以唤醒正在等待完成端口进行状态更改的线程。
在 Windows Vista 上，I/O 完成处理不必非由已发布 I/O 的线程执行，但是必须由等待完成端口将其唤醒的线程来执行。这个相对较小的更改避免了不必要的线程计划以及可能造成应用程序和系统整体性能下降的上下文切换。为了进一步提高性能，服务器可以从一个请求的完成中检索多个 I/O 操作的结果，避免转换到内核模式。
从最终用户的角度来看，I/O 系统中最可见的更改可能是 Windows Vista 所支持的取消同步 I/O 操作。如果曾经执行过 net view 命令或试图使用 Windows XP 或 Windows Server® 2003 访问过脱机远程系统的共享，您就已经体验到了无法取消的 I/O 操作问题：直到网络超时过期后，命令或文件浏览器才能响应。应用程序没有选择，只能等待，直至操作失败，因为它没有办法告知正在执行 I/O 的设备驱动程序不需再理会 I/O 了。
在 Windows Vista 中，大多数 I/O 操作都可以取消，包括 Net View 和资源管理器使用的打开文件 I/O。然而，必须更新应用程序以响应最终用户的取消 I/O 请求，而且许多与具有超时设置的设备进行交互的 Windows Vista 实用工具已得到必要的支持。例如，实际上由每个 Windows 应用程序（包括第三方应用程序）使用的文件打开和保存对话框现在允许在试图显示文件夹内容时启用“取消”按钮。在按 Ctrl+C 时，Net 命令也可取消其同步 I/O。
可以通过在 Windows Vista 上打开命令提示符并键入以下内容来查看 I/O 取消所带来的好处：
net view (\\nonexistentmachine)
在 Windows 试图联系不存在的系统时该命令将挂起，但可以通过键入 Ctrl+C 来终止该命令。在 Windows XP 中，Ctrl+C 不会产生影响，并且直到网络操作超时后命令才会返回。
在 Windows 以前的版本中会引发用户问题的另一类 I/O 就是设备驱动程序不能正确取消的 I/O，因为设备驱动程序轻易不会知道它们应该这样做。如果曾经终止过进程，但随后发现它在进程查看工具中有所延迟，那么，您已经亲眼目睹了设备驱动程序无法对进程终止做出响应，并且取消由未完成进程发布的 I/O 这两个过程。直到所有进程的 I/O 已经完成或已被取消，Windows 才能执行最终进程清理。在 Windows Vista 中，设备驱动程序能够很容易地注册进程终止的通知，因此，大多数无法终止的进程问题也就迎刃而解了。

I/O 优先级
虽然 Windows 始终支持 CPU 使用情况的排列优先级，但是却未包括 I/O 优先级这一概念。如果没有 I/O 优先级，搜索索引、病毒扫描和磁盘碎片整理等后台活动会对前台操作的响应性带来严重的影响。例如，用户在另一进程正在执行磁盘 I/O 时启动应用程序或打开文档，则该用户将体验到延迟，因为前台任务要等待磁盘访问。同样的干扰也会影响到多媒体内容（如硬盘上的歌曲）流播放的质量。
为了有助于前台 I/O 操作获取首选项，Windows Vista 引入了两个全新类型的 I/O 优先级排列：单独 I/O 操作的优先级和 I/O 带宽保留。Windows Vista I/O 系统内部包括对五个 I/O 优先级的支持，如图 6 所示，但是仅使用了四个优先级（Windows 的未来版本可能支持“高”优先级）。
Figure 6 Windows Vista I/O 优先级 (Close Figure 6)

I/O 优先级 | 使用情况
关键 | 内存管理器
高 | 未使用
普通 | 默认优先级
低 | 默认任务优先级
非常低 | 后台活动
I/O 具有“中等”默认优先级，内存管理器想要在低内存情况下将脏内存数据写到磁盘中从而为其他数据和代码在 RAM 中留出空间时，将使用“关键”优先级。Windows Task Scheduler 将具有默认任务优先级的任务 I/O 优先级设置为“低”，并将由执行后台处理的应用程序（为 Windows Vista 而编写）指定的优先级设置为“非常低”。所有 Windows Vista 后台操作（包括 Windows Defender 扫描和桌面搜索索引）均使用“非常低”I/O 优先级。查看“非常低”I/O 优先级
Process Monitor 是 Sysinternals 的实时文件系统和注册表监视实用工具，它可以收集读写文件系统操作的详细信息，包括它们在 Windows Vista 上的 I/O 优先级。突出显示的行显示了由 SuperFetch 发布的优先级非常低的 I/O 示例（这将在下期内容中进行探讨）。
图 C在 Proces Monitor 中查看“非常低”I/O 优先级

系统存储类设备驱动程序 (%SystemRoot%\System32\Classpnp.sys) 强制使用 I/O 优先级，因此也就自动应用于指向大多数存储设备的 I/O。类和其他存储驱动程序将“中等”I/O 插入到队列内优先级为“低”和“非常低”的 I/O 之前，但是至少应每秒发布一个等待“低”或“非常低”I/O 的操作，这样后台进程才可以向前进行。使用“非常低”I/O 读取数据还会使缓存管理器立刻将修改写入磁盘，并绕过读取操作的预读逻辑，否则它会优先从正在访问的文件中进行读取。请将边栏“查看“非常低”I/O 优先级”作为使用 Process Monitor 实用工具的“非常低”I/O 优先级的示例了解一下。
Windows Vista 带宽保留支持对于媒体播放机应用程序非常有用，Windows Media Player 将其连同 MMCSS 优先级提升一起使用，以提供对本机内容近乎稳定的播放体验。媒体播放机应用程序要求 I/O 系统确保它能够以指定速率读取数据，如果设备能够以请求的速率传递数据而且现有保留也允许的情况下，它将针对发布 I/O 的频率以及 I/O 应具有的大小两方面为应用程序提供指导。I/O 系统不会为其他 I/O 提供服务，除非它能够满足在目标存储设备上做出保留的应用程序的要求。
在 I/O 系统中值得一提的一个最终更改与 I/O 操作的大小有关。因为第一版 Windows NT、内存管理器和 I/O 系统已将单独存储 I/O 请求所处理的数据数量限制为 64KB。因此，即使应用程序发布了一个更大的 I/O 请求，也会被分解为最大大小为 64KB 的多个请求。每个 I/O 都导致了转换到内核模式的开销并在存储设备上启动 I/O 传输，因此在 Windows Vista 中，存储 I/O 请求大小将不再受限。已对一些 Windows Vista 用户模式组件进行了修改，以利用对更大 I/O 的支持，包括资源管理器的复制功能和命令提示符的 Copy 命令（现在发布 1MB 的 I/O）。

预告
现在，您已经了解了 Windows Vista 内核功能增强的两个方面。预期您可以在《Windows Internals》（Windows 内部结构）（与 David Solomon 共同执笔）一书的下一版本中了解到更详细的信息，计划与 Windows Server 的下一版本（代码名为“Longhorn”）同时推出。在下期内容中，我将继续通过探讨内存管理以及系统的启动和关闭来为您介绍新的内核。

Mark Russinovich 是 Microsoft 平台和服务部门的技术人员。他是《Microsoft Windows Internals》（Microsoft Windows 内部结构）(Microsoft Press, 2004) 的合著者之一，并经常在 IT 和开发人员会议上演讲。作为 Winternals Software 的创办者之一，他随着 Microsoft 对该公司最近的收购加入到了 Microsoft。他还创建了 Sysinternals，在这里他发布了 Process Explorer、Filemon 和 Regmon 实用工具。
© 2007 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.


 Windows 管理: 在 Active Directory 中委派权限
Windows 管理 Joel Yoker and Rob Campbell

在 Active Directory 中委派权限
概览:
  • 定义管理角色
  • 开发 OU 和安全组模型
  • 使用辅助帐户
  • 委派权限的工具

Active Directory 中的委派功能非常强大，可以解决大量安全问题并简化管理任务。通过在 Active
Directory® 中正确地委派权限，您可以在环境中强制指定的角色，限制出现管理错误的可能性及其影响，以及在您的整个基础结构中应用最低权限原则。然而，许多依赖 Active Directory 的组织尚未领略到委派的强大力量。从表面来看，部分原因在于为企业部署 Active Directory 委派模型似乎相当复杂。尽管最大的障碍是开发出的委派模型必须满足组织的特殊需要，但事实上仍然存在一些非常简单的模型，这些模型几乎无需修改即可应用到大多数 IT 基础结构中。
虽然每个环境在某些方面（如规模或形式）有所不同，但实际上，大多数大型企业在许多方面是相似的，它们也面临同样的 IT 难题。例如，许多组织都有不同的部门分散在不同的地理区域，它们从独立的 IT 工程或运营支持团队发展而来，且拥有独立的业务单位。并且许多大型组织必须处理诸如权限升级、服务帐户滥用和“信任”等问题。
信任是一个有趣的术语，经常会成为拥有多个 Active Directory 林结构的依据。信任问题通常来源于某个部门或地区的能力，这种能力会影响另一部门或地区的系统可用性。通常来说，不同组织之间的技能水平有所差异，且缺乏对支持特殊地区或业务单位所需的特定系统的深入了解。因此，各部门通常不希望放弃对中央群组的管理权限。
同时，要实施任何 Active Directory，管理员均须对利用 Active Directory 基础结构的应用程序的使用规则加以定义。一个常用的方法（该方法经常在应用程序安装指导中提到）是让服务帐户成为域管理员组的一员。不过，这种方法产生的问题是服务帐户实质上成了通用帐户。在向这些帐户授予域管理员权限时，将会为 IT 环境带来很大的危险。服务帐户很容易被那些恶意或粗心的管理员不当使用，或者被洞悉应用程序内部潜在安全问题的攻击者所利用。
尽管这些障碍看起来不可逾越，但也为实现 Active Directory 委派模型提供了一个最好的方案。开发委派模型是一个交互式的设计过程，建议您遵照以下步骤：
  1. 在您的组织内定义 IT 管理角色。
  2. 开发组织单位和安全组模型。
  3. 为 IT 管理员建立辅助帐户。
  4. 委派权限。
让我们进一步了解一下这些步骤。

定义角色
彻底了解服务管理和数据管理是角色定义过程的第一步。这些概念是任何 Active Directory 委派模型的基础。
本质上，服务管理是对关键目录服务基础结构组件的管理，例如 Exchange 服务器和域控制器。数据管理是对对象的管理，例如驻留在这些服务中的邮箱和用户帐户。在 Active Directory 范围内，服务管理员最终对目录服务的交付和可用性负责，而数据管理员则负责管理用户和服务器帐户、组和其他域资源。
Active Directory 支持在组织单位 (OU) 中进行权限的精细委派。OU 通常可以量身定制，以提供与管理员可在现有目录服务或域模型所使用的权限级别相同的权限。但有很重要的一点要了解，某些功能根本无法委派，必须由一个受信任组或实体来管理。
任务分析也很关键。您需要知道哪些任务由管理员执行，以及这些任务如何映射到各个角色。例如，Active Directory 站点创建是服务管理任务，而安全组成员身份的修改则通常由数据管理负责。每项任务的频率、重要性及难度均应予以评估。上述内容是任务定义的重要方面，因为它们决定了权限是否应该委派。那些定期执行、风险低且容易完成的任务是绝佳的候选委派对象。另一方面，那些很少执行、对组织影响很大且需要较高熟练程度的任务，尽量不予委派。实际上，升级（临时将某帐户提升为所需的角色或重新分配任务）对这些任务来说是个不错的选择。
既然大型组织的许多特征是相似的，则不妨假定通用委派模型可以实现。为使本文更具说服力，我们将提供一组角色的示例集，这些角色会启用管理功能，且不超出组织界限并试图防止出现信任问题（例如域控制器等企业资产的可用性）。请注意，此模型只是一个示例，尽管对于在您的组织内进行角色讨论其不失为一个良好的开端，但不应盲目照搬本指南。
有些角色已由 Active Directory 定义，有些角色则必须从头创建以适合委派模型。适合许多大型 Active Directory 环境的角色示例集可能包括用于服务管理的企业管理员、域管理员和 Tier4 管理员，以及用于数据管理的 Tier3 管理员、区域管理员、Tier2 管理员和 Tier1 管理员。有关这些角色及其职责列表，请参阅图 1。
Figure 1 定义角色和职责 (Close Figure 1)

服务管理员 | 说明
企业管理员 | 负责整个企业的顶级服务管理。不应包含永久成员。
域管理员 | 负责整个域的顶级服务管理。应仅包含受信任管理员，且数量少并不超出管理能力。
Tier 4 管理员 | 负责整个域的服务管理。仅应授予其管理所需服务所需的权限。可作为数据管理员的升级起点。
数据管理员 | 说明
Tier 1 管理员 | 负责目录对象的常规管理，执行如密码重置、修改用户帐户属性等等之类的任务。
Tier 2 管理员 | 负责为其地区或组织有选择性地创建和/或删除用户和计算机帐户。
区域管理员 | 负责管理其本地 OU 结构。被授予在其 OU 内创建大多数对象的权限。
Tier 3 管理员 | 负责管理所有数据管理员。可作为顶层服务台和所有区域管理员的升级起点。

服务管理员
让我们进一步了解一下这些服务管理员角色。服务管理员管理关键基础结构组件，所有此类管理员均具有很高的权限。因此，在这种情况下强烈建议使用最小权限策略，即仅授予执行所需任务时所必需的最少权限。
企业和域管理员 Active Directory 定义两组特殊的管理员，他们的安全上下文是目录中的关键功能所需的。这些组（企业管理员和域管理员）负责管理顶级服务。为减少此类高权限组的内在风险，强烈建议您限制这些组的成员身份。事实上，企业管理员组不应具有永久成员，而域管理员组应该仅包含数量不多且容易管理的受信任成员，并且从组织的全职员工中选择这些成员。
当需要执行企业管理任务（比如 DHCP 服务器授权或 Active Directory 站点创建）时，Active Directory 林结构根域中的域管理员可通过管理企业管理员组的成员身份来升级权限。这些权限只能短期授予，以免在企业管理员组中创建永久成员。当然，在给定的 Active Directory 林结构中，域管理员组的所有成员必须获得平等的信任。
部署委派模型时，大多数组织的一个常见缺陷是丧失或削弱这些内置角色。修改默认角色可能会产生不可预见的后果，且不担保服务包修订或产品升级会保留这些设置。此外，此类修改会创建一个超出组织范围且不受支持的环境。一个实用的方法是使用内置的组和角色，但要对其成员身份进行限制。为此，您可能需要为先前依赖组（如域管理员组）中成员身份的管理员创建新角色。
Tier4 管理员 Tier4 管理员组应该由为所有企业服务提供支持的集中服务管理员组成。由于该角色已经创建，因此可以针对您组织的特定需求来量身定制目录服务和系统访问权限。虽然该组的成员是服务管理员，但是他们也可以偶尔在林结构范围内执行数据管理任务。由于系统类繁多且各区域的职责也不尽相同，因此在目录内将 Tier4 角色分成了各种子组。例如，应该创建独立的 Tier4 组，以独立管理特定系统（如 Exchange 服务器）。该组还是数据管理员的升级起点。
通常，人们希望获得域管理员组成员身份的一个原因，是想获取给定域中所有系统的管理权限。要让这些服务管理员在最低权限模式下运行，方法是允许 Tier4 管理员控制企业服务器，但不允许他们成为域管理员。为防止权限升级，不应将域控制器上 BUILTIN\Administrators 组中的成员身份授予 Tier4 管理员，因为该组有许多针对目录服务的底层权限无法分离。例如，某给定域的 BUILTIN\Administrators 组的一名成员可以管理域管理员组的成员身份，允许成员不经任何检查和平衡即升级权限。
切记不得随意更改默认权限的规则，令 Tier4 组成为服务器操作员和 DNS 管理员内置域组的嵌套成员可缓解此风险。这样既可本地管理域控制器，又限制了 Tier4 管理员升级权限的能力。对于大多数系统（域控制器和证书服务器等除外），应该允许 Tier4 管理员组成为本地管理员组中的一员。嵌套的本地组成员身份可利用组策略中的“受限制的组”功能自动获取。

数据管理员
现在，让我们来研究一下数据管理角色。在设计上，这些角色的权限应该是不断累积的，即 Tier2 管理员应该具有 Tier1 管理员的所有权限再加上一些其他权限，以此类推。基于此，我们按照自下至上的顺序来查看这些组。
Tier1 管理员 Tier1 管理员组应提供对先前创建的目录对象的常规管理。本组适用于培训程度最低或执行单独任务（如密码重置）的管理员。在其组织单位内部授予本组权限，如修改用户帐户属性、重置用户帐户密码、解锁帐户、启用/禁用用户帐户、添加和重置工作站计算机帐户以及修改非管理组的组对象成员身份。
Tier2 管理员 本组应有选择性地管理和创建对象，允许仅在 Tier1 管理员的管理范围内创建对象。（例如，安全组只能在 OU 组中创建）。Tier2 管理员可以添加和修改 Tier1 管理员帐户；添加、修改和删除 OU 的用户帐户；删除 Workstation 计算机对象；添加、修改和删除 Server、Contact 和 Shared Folder 对象。
区域管理员 本组被授予对其区域 OU 结构的独占权限。不过，他们不能管理目录内的其他区域 OU 结构。区域管理员帐户应该具有很高的权限，因此，这些帐户存储在独立的 OU 层次结构中，并由 Tier4 Admin 服务管理员管理。区域管理员可以在其 OU 结构内不受限制地创建大部分对象（但无法在其他组织单位中创建对象），由此带来的附加风险是其所创建的对象可能无法在较低的层次中管理。
Tier3 管理员 许多组织拥有集中式服务台，或在上层有服务台。该角色填充数据管理员列表，为所有区域管理员提供数据管理员组。权限并未明确地委派到目录内的这些组中；相反，它们是借助每个区域管理员组中的嵌套成员身份而委派的。这为所有数据管理员提供了一个顶级升级起点，也为升级到服务管理组提供了切入点。

构建 OU 和安全组模型
一旦在组织中定义了角色，就必须定义 OU 和安全组模型。在 Active Directory 中创建 OU 主要有两个原因：委派权限和创建一个可以链接组策略对象的点。OU 在目录内定义管理范围 (SOM)，用来限制各级对象的权限。因此，选择如何委派权限应该是如何实现 OU 结构的一个主要因素。
记住了这一点，就应该直接在域下面创建顶级 OU（或 OU 系列）来存储所有对象。此 OU 的专门用途就是为 Tier4 管理员定义最高级别的 SOM。通过创建顶级 OU，可以在 OU 级别而非域级别显式启动目录服务权限。从顶级 OU 而非域中委派可降低用户通过操作前述内置域组来升级权限的风险。
在顶级 OU 之下，应该创建单独的子 OU 层次结构来表示每个具有独立数据管理团队的地区或业务单位。每个区域子 OU 均应拥有一个通用且不可扩展的 OU 层次结构来管理目录对象。由于许多权限委派将自动进行，因此一致性对于当前的管理很重要。这是一个很严格的要求，因为每个地区可能需要唯一的 OU。但是 IT 管理员必须坚持己见，如果某个地区需要扩展，则子 OU 结构必须对所有地区均进行扩展。刚开始似乎很难，但是如果组织为对象提供通用的存储方式，则情形会逐渐好转起来。
最后，创建子管理员组和帐户，以禁止管理员为每个子 OU 层次结构（如 Tier1 管理员、Tier2 管理员和区域管理员组）升级权限。将这些帐户放在单独的 OU 中，可以限制对其自身级别或下面级别的管理。因而，如果所有 Tier1 管理员帐户和相关的安全组驻留在 OU 中而又没有权限，则这些管理员将无法劫持其他管理员帐户，或将其他管理员的权限升级到与自己相同的级别。例如，域管理员组的任何成员都可以使域中的任何其他用户帐户成为域管理员。但是，使用上述 OU 模型，该风险就会显著降低。OU 结构及相关安全组示例如图 2 所示。
图 2 OU 结构及相关安全组
图 2 OU 结构及相关安全组

建立辅助账户
一个成功的委派模型，其关键是强制实施最低权限原则。实际上，安全原则意味着只能拥有执行其给定角色所需任务的能力，仅此而已。很可惜，许多 IT 管理员对目录管理和各项日常任务（如 Web 浏览和阅读电子邮件）均使用同样的安全原则。如果具有单独的帐户，分层管理员可降低以下风险：由于误操作而损坏目录服务，或者成为攻击的受害者（这些攻击通过日常应用程序来实施，但目标却是目录管理员）。
要完成上述操作而又无需用户注销和重新登录，可使用 Secondary Logon 服务 (Runas.exe)。当用户在服务器和工作站上执行脚本或可执行文件时，可通过提供一组替代凭据集来升级用户权限。
组织不时会发现，使用最低权限帐户的概念虽然相对简单，但强制实施起来却很困难，因为原有的 IT 习惯往往很难改变。阻止使用具有一定权限的帐户来处理日常任务的直接方法，就是不要在 Exchange Server 中提供对这些帐户进行邮件访问的权限，这可通过组织内的管理策略强制实施。这种相对简单的方法可明显降低使用此类帐户处理日常非管理任务的可能性。

委派权限
开发委派模型的最后一步是在 Active Directory 内实际委派权限。该步骤需要针对目录中存储的数据，对访问控制项 (ACE) 和访问控制列表 (ACL) 进行操作。Active Directory 容器中的 ACL 定义了可以创建的对象以及管理这些对象的方式。权限的委派涉及对象的基本操作，如查看对象、创建指定类的子对象或者读取指定类上的对象的属性和安全信息等能力。除这些基本操作外，Active Directory 还定义了扩展权限，这些权限启用诸如“代理发送”和“管理复制拓扑”之类的操作。
在前面的步骤中，我们讨论了创建映射到已定义组织角色的安全组。这表明，每个角色都有一个相关的子 OU 结构安全组。要实施委派模型，需要针对目录中的对象为这些组分配权限。进行到这一步，您不会希望再重新开始并创建一个高度自定义的环境。相反，如果可能，可尝试利用内置组和权限。比方说，一个特殊的角色需要管理林结构的 DNS 记录。不要试图通过容器和命名与 Active Directory（集成 DNS）相关的上下文来委派权限；相反，只需利用域中的 BUILTIN\DNS 管理员组即可。此外，可通过组策略扩展用户权限和其他权限，以提供给定角色管理特定系统类所需的附加权限。
使用委派分配权限时，应限制甚至避免在目录中使用“拒绝 ACE”。它们会让故障排除变得很棘手。更好的方法是使用显式的“允许 ACE”为代表您角色的自定义组授予权限。记住，用户定义的角色（如 Tier4 管理员）只拥有该角色所定义的显式权限。
继承对 Active Directory 安全而言至关重要，它定义了如何将特定的 ACL 应用至给定容器或子容器中的子对象。确保应用可继承的 ACE 时使之与目标对象尽可能接近，这样就可始终明确继承的范围。应用至父对象的可继承拒绝权限优先于应用至祖父对象的可继承拒绝权限，这也是不建议在实际委派中使用“拒绝 ACE”的主要原因之一。并且，可继承权限不能覆盖对象的显式 ACE。因此，建议您限制或取消分层管理员修改目录对象自由访问控制列表的能力（通过删除“写入 DACL”权限）。（请注意，对象的创建者自然具有这些权限。）经验告诉我们，如果管理员拥有更改对象 DACL 的权限，通常都会尝试一下。不要让侥幸心理和潜在的管理错误，将自己组织实施委派模型的艰苦努力付之东流。
要正确实施 Active Directory 委派模型，您需要用到大量的工具。对于大多数组织而言，使用内置的委派向导在目录中分配权限是一项令人望而却步的任务，各种管理错误可能随时发生。相反，应坚持使用自动化分配以确保委派模型记录良好、可受支持，并且在设置意外丢失或被更改时提供恢复选项。
实施委派所需的主要工具是 DSACLS.EXE，它是命令行工具，用于操作对象的目录服务 ACL。此工具还允许在父对象上为 DACL 指定继承标志。（继承标志包括该对象及子对象、仅子对象，并且仅传播一个级别的可继承权限。）如果继承标志设置不正确，则 DSACLS 命令最终会失败，因此使用此工具时测试变得至关重要。下面是一个 DSACLS 语法示例，委派在目标演示 OU 中创建计算机对象的能力：
dsacls.exe ou=demo,dc=contoso,dc=com /I:T /G contoso\dataadmin:CC;computer
DSACLS 区分对象类型的大小写。也就是说，试图为对象类“cn=Computer”而不是“cn=computer”委派权限将不起作用（请参见图 3）。
图 3 由于区分大小写而造成的错误
图 3 由于区分大小写而造成的错误
某些对象需要特定的权限集才能创建。这必须处理对象的“必须包含”和“可以包含”属性。据我所知，解释此概念的最形象的比喻是汉堡模型。汉堡必须是一个圆面包夹一片肉可称其为汉堡。它们就是汉堡对象类的“必须包含”属性。像泡菜、番茄酱和莴苣等则是“可以包含”属性。如果我们扩展对象类来定义干酪汉堡，则“必须包含”属性列表中还要加上干酪。
用户对象的工作原理也一样。假设我们要根据汉堡模型来使用下面的 DSACLS 语法创建用户对象：
dsacls ou=demo,dc=contoso,dc=com /I:T /G contoso\demodata:CC;user
在创建用户对象期间，管理员可能会遇到几个错误。我们需要授予一些必需的权限才能设置所需的用户对象属性，包括设置密码。如下面的附加 DSACLS 语法中所示。
第一步，授予写入“必须包含”属性的权限，方法是将“通用读/通用写”授予用户类的所有属性：
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:GRGW;;user
下一步，授予更改密码的扩展权限：
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:CA;"Reset Password";user
最后一步，为“上次设置的密码”属性的“读属性”和“写属性”授予权限：
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;pwdLastSet;user
委派了正确的权限之后，所定义的角色将会仅限于管理在容器的 DACL 中所定义的对象类。使用先前的计算机对象示例，Active Directory 用户和计算机中的上下文菜单会限制新建对象的列表，这些对象只能由委派了新建权限的用户创建（请参见图 4 中的限制列表）。
图 4 新建对象限制列表
图 4 新建对象限制列表
DSACLS 还可以自动部署复杂的权限。下面是一些 DSACLS 命令，这些命令可以委派权限，以在给定容器中操作用户对象的常用地址属性：
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;c;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;co;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;l;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postalCode;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;postOfficeBox;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;st;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;streetAddress;user
dsacls ou=demo,dc=contoso,dc=com /I:S /G contoso\demodata:RPWP;telephoneNumber;user
像这样的示例通用于大多数委派模型，并可与先前定义的角色联合使用。
另一个用于实施委派的工具是 DSREVOKE.EXE，管理员可以根据对象的特定安全原则，使用该工具在目录中查找和删除委派权限。尽管该工具可能非常有用，但是它特定于安全原则，且不能评估安全组内部的嵌套成员身份。
除这些命令行工具以外，我们还强烈建议将“用户权限分配”和“受限制的组”与组策略同时使用。如前所述，“用户权限分配”允许 IT 管理员在特定目标系统上的针对各种用户组扩展或删除低级权限（比如远程访问和重启系统的权限）。“受限制的组”可用来指定和强制林结构内的本地组和域组成员身份。结合使用这些工具，您可以从容地自动实施 Active Directory 委派模型。

总结
虽然开发 Active Directory 委派模型的任务可能看起来很复杂，而事实上，大多数 IT 基础结构均可采用非常简单的模型。实际部署委派模型时，最重要的步骤之一是明确定义角色。应该定义少量的角色，且不超出管理能力。做到平衡并非易事，因为角色太多会导致角色无法使用，而角色太少又无法进行角色分离。
请记住，定义任务时，请按使用频率、重要程度和难易程度进行分类。定义角色之后，开发一组使用案例，以帮助确定每个角色的职责范围以及实现测试过程自动化。准备充分的使用案例有助于向您组织负责人解释这些角色，并且能够在出现由于自动操作而导致的错误时缓解紧张感。
最后要说的是，在开发委派模型时，灵活采取切实可行的方法始终不失为上策。请记住，简单意味着高可支持度，若要在 Active Directory 环境内部控制管理权限，可支持度高的委派模型会让您大受裨益。
其他资源
  • Design Considerations for Delegation of Administration in Active Directory（英文）
  • Best Practices for Delegating Active Directory Administration（英文）

Joel Yoker 是 Microsoft Federal 团队的高级顾问。Joel 和 Rob 均专注于为美国联邦政府客户开发和部署安全解决方案。
Rob Campbell 是 Microsoft Federal 团队的高级技术专家。Joel 和 Rob 均专注于为美国联邦政府客户开发和部署安全解决方案。


 Windows 管理: 深入探讨 Windows Vista 中的新组策略模板
Windows 管理 Darren Mar-Elia

深入探讨 Windows Vista 中的新组策略模板
概览:
  • 了解 ADMX
  • 编辑 ADMX 文件
  • ADM 和 ADMX 文件的区别
  • 创建中心库

在 Windows Vista 之前，可在组策略中设置的注册表值是由 ADM 文件控制的，该文件不但语法晦涩，而且属于专有性质。如果您希望控制 Microsoft 与标准 ADM 文件一同附带的注册表值之外的其他注册表值，则您需要学习此语法，
并创建自定义 ADM 文件。此外，这些 ADM 文件与每个组策略对象 (GPO) 一同存储在 Active Directory® 环境中，且每个 GPO 及其附带的 ADM 文件会被复制到域中的所有域控制器内。
随着 Windows Vista™ 的发布，Microsoft 在基于组策略的注册表模板方面有了很大的进步。Windows Vista 在 ADM 文件（现在称为 ADMX）的格式以及这些文件的存储方式方面做了重大更改。在本文中，我将深入介绍新的 ADMX 格式，并讨论这些文件与 ADM 的区别。我还将介绍如何在 Windows Vista 环境中存储这些文件。

ADMX 的不同之处
新的 ADMX 文件格式和自 Windows NT® 4.0 起便存在的旧 ADM 格式最大的区别在于，ADMX 采用了 XML 标准来描述注册表策略的设置。这种方式很好，有多个原因。首先，编辑 XML 的工具要远多于编辑 ADM 语法的工具。其次，由于 XML 是架构化的，因此最终会比较容易构建一些工具，来帮助您在正确位置放置正确的标记，进而创建结构良好的 ADMX 文件。其中架构化是指，对于给定的 XML 应用程序（如 ADMX 格式），有一个文档化的架构来描述可能用到的元素和属性以及它们的组织方式。本文后面的部分将对一个示例进行分析。
ADMX 和 ADM 的另一个主要区别在于，主 ADMX 文件的字符串部分分到了语言特定的 ADML 文件中。如果您熟悉 ADM 文件，就会知道每个文件的结尾会有一个以“[strings]”标记分隔的部分，其中您可以为字符串赋值，该字符串会在您使用组策略编辑器和管理模板时显示。例如，您单击给定策略的“解释”选项卡时所看到的文本，就存储在该字符串部分中。问题是，字符串存储在 ADM 文件中，如果您希望在其他语言的 Windows® 系统上使用该 ADM，则需要创建一个新的 ADM 文件，并加上适用于该语言的字符串部分。
如果 Windows 法语版本的用户想要编辑英语版 ADM 使用的现有 GPO，问题就更加复杂了。法语管理员在组策略编辑区中只能看到英语。为了解决这一问题，Windows Vista 将 [strings] 部分分成基于 XML 的 ADM 语言（或者 ADML）文件。ADML 文件能以任何支持的语言交付，并可被简单地更改为支持任何新语言，而不需更改存储策略的主 ADMX 文件。更重要的是，当该法语管理员从其 Windows Vista 工作站编辑 GPO 时，组策略编辑器将检测到正在使用 Windows 的法语版本，并会自动为该 GPO 加载法语 ADML 文件。
安装 Windows Vista 时所附带的所有 ADMX 和 ADML 文件，可以从 c:\windows\policydefinitions 文件夹中查看（请参阅图 1）。
图 1 Windows Vista 中的 ADMX 文件
图 1 Windows Vista 中的 ADMX 文件
请注意，在图 1 列出的文件中，顶部有一个名为 en-us 的文件夹。这便是语言特定的文件夹，您在 PolicyDefinitions 文件夹中所看到的 ADMX 文件的 ADML 文件就存在这里面 - 在本例中为美国英语。每个 ADMX 文件都有一个 ADML 文件。在撰写本文时，Windows Vista 默认包含 132 个 ADMX/ADML 文件。这是 Windows Vista 较之以前版本的另一个明显的不同之处：Windows XP 创建的 GPO 通常具有五个 ADM 文件，最大的是 System.adm，该文件保存着策略控制的大部分 Windows 组件的策略项目。在 Windows Vista 中，Microsoft 决定根据功能将 ADMX 文件分开，因此会具有更多数量的 ADMX 文件。每个 ADMX 通常涉及单个 Windows 组件（如控制面板、DNS 客户端、Windows 资源管理器等）。

了解 ADMX
正如我前面所说，用 XML 编写 ADMX 是一大进步。但是，许多管理员不知道如何编写 XML，更不用说了解 ADMX 用于创建策略扩展的架构了。尽管有关自定义 ADMX 创建的教程超出了本文的范围，我们还是来了解一下 ADMX 是如何构成的。
您可以用任何文本编辑器（甚至是 Notepad）打开 ADMX 或 ADML 文件，但是，除非编辑者了解 XML 语法，否则意义不大。我使用 Visual Studio®，因为它的 IntelliSense® 功能可帮助您完成特殊的元素。图 2 显示了 Windows Vista 附带的其中一个 ADMX 的前几行。
Figure 2 ADMX 文件中的部分 XML (Close Figure 2)
<?xml version="1.0" encoding="utf-8"?>
<policyDefinitions xmlns:xsd="http://www.w3.org/2001/XMLSchema"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" revision="0.9" schemaVersion="0.9"
  xmlns="http://www.microsoft.com/GroupPolicy/PolicyDefinitions">
  <policyNamespaces>
    <target prefix="AxInstSv" namespace="Microsoft.Policies.ActiveXInstallService" />
    <using prefix="windows" namespace="Microsoft.Policies.Windows" />
  </policyNamespaces>
如果您不熟悉 XML，可能看不懂，但在任何 ADMX 文件中都可以找到这些 XML 元素。例如，policyNamespaces 元素可在所有 ADMX 文件领域内唯一标识此 ADMX 文件。
我们知道，在 Windows 的以前版本中创建自定义 ADM 文件，需要采用一组标记（如 Category、Policy、ListBox 和 ActionList）来定义策略设置，这些策略设置将出现在组策略编辑器中。这些标记大都保持原样，或者仅在 ADMX 格式上有略有变化，但是看起来却迥然不同，因为它们被表示为 XML。例如，我编写了一个自定义 ADM 文件用于组策略故障排除，该文件会在 Windows 中启用各种类型的日志记录。图 3 显示了该自定义 ADM 的一部分。我将此文件转为新的 ADMX 格式，如图 4 所示。
Figure 4 转换为 ADMX 文件的 ADM 文件 (Close Figure 4)
<policy name="Folder Redirection Logging" class="Machine" displayName="$(string.FolderRedirLogging)" explainText="$(string.FolderRedirLogging_Help)" key="Software\Microsoft\Windows NT\CurrentVersion\Diagnostics" valueName="FDeployDebugLevel">
      <parentCategory ref="PolicyLogging" />
      <supportedOn ref="windows:SUPPORTED_Win2K"/>
      <enabledValue>
        <decimal value="15"/>
      </enabledValue>
      <disabledValue>
        <decimal value="0" />
      </disabledValue>
    </policy>
Figure 3 自定义 ADM 文件 (Close Figure 3)
CLASS MACHINE
  CATEGORY !!System
    CATEGORY !!GroupPolicy
    CATEGORY !!Logging
POLICY !!FolderRedir
EXPLAIN !!FolderRedir_HELP
KEYNAME "Software\Microsoft\Windows NT\CurrentVersion\Diagnostics"
VALUENAME "FDeployDebugLevel"
VALUEON NUMERIC 15
VALUEOFF NUMERIC 0
END POLICY ;FolderRedir
      END CATEGORY ;Logging
   END CATEGORY ;GroupPolicy
 END CATEGORY ;SYSTEM
此段 ADMX 文件的很多方面都要比其相应的 ADM 文件更易于理解，因为它更加简洁。policy 元素指定了此策略的用途（文件夹重定向日志记录）。以“$(string.”为前缀的属性是对相应 ADML 字符串元素的引用。很显然，key 和 valuename 属性指定此策略可以修改的注册表项和值。parentCategory 元素控制此策略在组策略编辑器管理模板层次结构中出现的位置。supportedOn 元素指示此策略适用于哪个操作系统版本。最后，enabledvalue 和 disabledvalue 元素指定将此策略设置为启用和禁用时，在注册表中写入的值。
这是一个很简单的开/关策略。在 ADM 语法中，组策略编辑器可以创建更加复杂的 UI 元素。当您在 ADMX 中创建元素时，会更多地涉及到语法，且语法还包含一个表示属性，该属性引用了一部分包含 UI 元素文本标签的 ADML 文件。除此之外，ADMX 语法的确不是很复杂。请记住，ADM 和 ADMX 的一些标记名称有所不同。例如，ADM 有“edittext”和“listbox”标记。而在 ADMX 中，您会发现这些标记在 ADMX 文件中被称为“text”和“list”。在指定其伴随显示文本的 ADML 文件中，这些元素具有相应的条目。
正如您所知，管理员可将自定义（传统）ADM 文件加载到 Windows Vista 组策略对象编辑器中。人们经常问我，Microsoft 是否会提供实用工具，用于将自定义 ADM 文件转换为 ADMX 语法。实际上，Microsoft 与 FullArmor Corp. 合作发布了一个免费工具，称为 ADMX Migrator。此工具有两个用途。第一个用途，它可以将您原来的自定义 ADM 文件转换为 ADMX 格式（有关使用此工具转换我的自定义 gpolog.adm 的示例，请参阅图 5）。
图 5 ADMX Migrator
图 5 ADMX Migrator
第二个用途，它提供一个 ADMX 编辑器，您可以用它从头创建新的 ADMX 文件。可以从 go.microsoft.com/fwlink/?LinkID=77409 下载此工具。

ADMX 存储
我要讨论的另一个显著变化是如何存储 ADMX 和 ADML 文件以供使用的。在 Windows Vista 以前的 Windows 版本中，当您编辑新的 GPO 时，会自动将 ADM 文件从本地工作站（您执行编辑任务的位置）复制到 Active Directory 域中域控制器上的 GPO 的 SYSVOL 部分中。然后会将这些 ADM 复制到域中的每个 DC，供创建的每个 GPO 使用。这样会浪费大量网络带宽和磁盘存储空间，尤其在有几十个甚至数百个 GPO 的大型环境中。Windows Vista 从根本上改变了这一过程。默认情况下，当您从 Windows Vista 工作站创建基于 Active Directory 的 GPO 时，组策略编辑器中显示的管理模板策略是从 c:\windows\policydefinitions 文件夹加载的，该文件夹位于您正在编辑 GPO 的计算机上。
ADMX 和 ADML 文件不会复制到 SYSVOL - 它们仅用作本地引用之目的。这就消除了 ADM 为组策略环境带来的存储和网络负担。但是我们还能做得更好。Windows Vista 同时支持一个中心库，它是管理模板的存储库。这样一来，您就可以有效地控制用于编辑 GPO 的 ADMX 文件了，而无论是谁在编辑它们。方法是：将所有正式 ADMX 和 ADML 文件（以及您所创建的任何自定义文件）复制到网络位置，然后从 Windows Vista 工作站编辑的所有后继组策略均会引用这些基于网络的版本，而不是分别引用本地版本。建立中心库是一项简单的任务，且每个域只需执行一次。遵循“创建中心库”边栏中的步骤即可。

总结
相对于以前操作系统版本所使用的 ADM 文件，Windows Vista 新的 ADMX 格式有了明显的改进。XML 的使用，为编辑和搜索这些文件提供了更为清洁的框架。语言特定字符串向单独文件的转换，使得多语言组策略编辑能够无缝进行，同时，中心库消除了将所有 GPO 与 ADM 文件的副本一同存储并更新的必要性。所有这些使得了解 ADMX 成为明智之举。
创建中心库
创建中心库相对简单。请遵循以下简单步骤在您的 Active Directory 域中创建一个中心库：
步骤 1： 打开资源管理器，浏览至环境中 PDC 仿真器 DC 上的 SYSVOL 共享（您可以使用任何 DC，但是 PDC 角色所有者通常是组策略更改的关注焦点）。
步骤 2： 打开 SYSVOL 下的 Policies 文件夹，新建一个名为 PolicyDefinitions 的文件夹。
步骤 3： 将 Windows Vista 工作站上 C:\windows\policydefinitions 文件夹的内容复制到新的 PolicyDefinitions 文件夹中，其中 ADML 文件夹根据语言确定（例如，美国英语计算机上的 en-us）。
将 ADMX 和 ADML 文件复制到中心库文件夹后，Windows Vista 上的组策略对象编辑器将开始引用此处的文件并忽略本地存储的文件！

Darren Mar-Elia是 Microsoft 组策略 MVP，他创建了流行的组策略站点 - www.gpoguy.com，并且是《Microsoft Windows Group Policy Guide》（Microsoft Windows 组策略指南）（Microsoft Press，2005）的执笔者之一。他还是 SDM Software, Inc. 的 CTO 和创始人。您可以通过发送电子邮件到 Darren@gpoguy.com 与他联系。


 Windows 管理: 组策略故障排除指南
Windows 管理 Derek Melber

组策略故障排除指南
概览:
  • 常见 GPO 问题
  • 组策略规则
  • GPO 问题故障排除
  • 故障排除工具

Microsoft Active Directory 已成为许多 IT 基础结构的重要组件。Active Directory 的最重要功能之一便是组策略，该策略允许管理员集中管理域控制器、成员服务器和桌面。
尽管组策略具有许多明显的优点，但还是有一个小缺陷。那就是在大型组织中的设计和实施会很复杂，如果出现问题则故障排除工作会更加棘手。本文将详细介绍组策略的构造方式，然后向您说明如何排除故障。文章结束时，您处理几乎任何组策略问题都会得心应手。

麻烦的设置
组策略中有许多移动部件，尤其是与整体 Active Directory® 设计和实施的连接方式。要排除多种因访问权限和网络问题造成的故障，则您在寻找解决方案时，Active Directory 和组策略实施的基础始终不可或缺。在故障排除过程开始之前，让我们先来看一下可能配置错误的组策略设置，然后再探讨可能引起组策略出现故障的更为复杂的问题。
由 Active Directory 管理员使用模板文件（ADM 或 ADMX 文件）和“组策略对象编辑器”或 GPEdit（通过运行 gpedit.msc 启动）来查看组策略设置。管理员使用 GPEdit 创建“组策略对象”文件，即 GPO。将 GPO 配置为应用（或不应用）于 Active Directory 结构内的计算机和用户。有许多规则 GPO 必须遵守方可正常发挥功能。让我们马上查看这些规则。
必须链接 GPO 新建的 GPO 可能与 Active Directory 中的任何节点都不相连。尽管此时也可以编辑和修改 GPO，但只有将其链接到某节点之后才会影响对象。为确保 GPO 正确链接，可以查看组策略管理控制台 (GPMC) 中的信息窗口，如图 1 所示。
图 1 GPO 链接清晰显示
图 1 GPO 链接清晰显示
GPO 必须以正确的对象为目标 如您所知，组策略必须以 Active Directory 中的正确对象为目标。不过，有时在故障排除练习期间会忽略这一点。在 GPO 中，有两大主要类别：计算机和用户。配置 GPO 时，一定要注意是为计算机对象还是为用户对象进行配置。然后，您可以验证在链接了该 GPO 的组织单位 (OU) 中是否放置了正确的对象类型。
GPO 并不应用于组 尽管您希望如此，但 GPO 无法应用于 Active Directory 安全组对象。GPO 设置仅能配置两个对象，即计算机和用户。GPO 不能通过组成员身份配置对象。例如，如果 GPO 链接到财务 OU，如图 2 所示，则只有 Derek 和 Frank 两个对象受到设置的影响。GPO 中的设置将不会影响市场组的成员，无论谁具有该组的成员身份。
图 2 财务 OU 及其中的对象
图 2 财务 OU 及其中的对象
目标对象必须位于 GPO 路径之中 如果您注意到 GPO 设置未按其应有的方式影响对象，则请查看一个更重要的设置，即对象必须位于 GPO 的管理范围 (SOM) 之中。这意味着对象必须位于链接 GPO 的节点之下（即使有足够多的子节点亦需如此）。例如，链接到财务 OU 的 GPO 不会影响市场 OU 中的任何对象，如图 3所示。GPO 的 SOM 来自与其相链接的节点，沿着 Active Directory 结构向下。
图 3 如果所有 OU 位于同一级别，则 GPO 仅应用于其所链接的 OU
图 3 如果所有 OU 位于同一级别，则 GPO 仅应用于其所链接的 OU
需要启用 GPO 创建 GPO 时，其配置是对目标对象不做任何修改。不过，计算机和用户部分均会启用该 GPO。如果以上任一部分禁用，则跟踪起来就有些麻烦。因此，您在针对未应用 GPO 进行故障排除时，检查是否有部分或全部 GPO 遭到禁用实为良策。方法是在 GPMC 中打开“组策略对象”|“帐户策略”，然后查看 GPO 状态。
有些设置需要重新启动 GPO 设置未正常发挥作用时，可能是由于 GPO 的内在处理所致。触发 GPO 的定期后台刷新只能处理某些 GPO 设置，但并非全部。因此尽管您可能已经创建了一个设置，但可能尚未令其生效。有些设置被归类为前台策略，因此只有在重新启动计算机或用户先注销然后再重新登录后这些设置才会得到应用。以这种方式应用的设置示例包括软件安装、文件夹重定向和脚本应用程序。

设置的同步和异步应用程序
在 GPO 中，您可以配置启动和登录时策略应用程序的发生方式。您所做的更改，即可于策略仍在应用时提供对桌面的立即访问，也可确保在用户拥有对桌面的访问权限之前应用所有策略。图 4 显示了默认情况下每个操作系统的行为方式。如果您要改变此行为，可以修改以下策略设置：
Computer Configuration | Administrative Templates |
System | Logon | Always wait for the network at computer startup and logon
Figure 4 客户端上的默认处理 (Close Figure 4)

操作系统 | 启动 | 登录 | 策略刷新
Windows 2000 | 同步 | 同步 | 异步
Windows XP Professional | 异步 | 异步 | 异步
Windows Server 2003 | 同步 | 同步 | 异步
大多数管理员喜欢选择同步策略应用程序，以确保在用户可以访问桌面之前已应用所有策略。这样能够保证用户在完成任何工作之前即已应用所有的安全和配置设置。请注意，这不是 Windows® XP Professional 中的默认状态，而是为加快登录速度所进行的优化。

变更默认继承
可以使用四种不同的方法来改变 GPO 处理的默认继承。这些选项功能强大，应谨慎使用，因为它们会导致组策略处理行为的重大改变。如果出现问题则故障排除工作也会非常困难。改变默认继承的选项包括以下四种设置和配置：
  • 阻塞策略继承
  • GPO 执行
  • 访问控制列表 (ACL) 的 GPO 过滤
  • Windows Management Instrumentation (WMI) 过滤器
既然应该谨慎使用这些设置，因此记录它们的使用时间应该不难。想知道这些选项是否在用，请查看 GPMC。阻塞继承在 GPMC 中的域或组织单位 (OU) 节点处执行。在各自的 GPO 上设置 GPO 执行、ACL 过滤和 WMI 过滤。
或者，可以从目标计算机中运行 Gpresult 命令，以获悉上述的某些设置是否在阻止策略应用。要获得被应用策略结果集的更详细视图，可在 Gpresult 命令后添加 /v 开关，这样即可获得详细的输出。

ADM 模板问题
当您试图在“管理模板”部分下配置 GPO 中的设置时，您所使用的是 ADM 模板。除随附于操作系统的 ADM 模板外，您可以自定义在 GPO 中使用的自有模板。ADM 模板中的代码会在“管理模板”节点下的“组策略编辑器”中创建文件夹和策略。不过，如果 ADM 模板损坏、丢失或配置错误，则可能在编辑器中无法看到部分或全部设置。下面有一些其他问题在使用 ADM 模板时要注意避免。
丢失 ADM 模板 如果在编辑 GPO 时发现有些自定义 ADM 模板中的设置未显示在编辑器中，则需要将 ADM 模板导入到 GPO 中。只需右击编辑器上的“管理模板”节点，然后选择“添加/删除模板”即可。
丢失首选项 在自定义 GPO 中可以创建两种类型的设置：首选项和策略。策略是默认的 Microsoft 设置，全部属于注册表中四个子项其中之一，每个设置末尾均为文本“Policies”。首选项则是“老式类型”的注册表修改，它们不属于四个子项其中之一，并且一经配置就很难反转。默认情况下，这些首选项不显示在编辑器中。需要显示它们的话，可通过工具栏上的“视图”菜单进行。选择“视图”菜单中的“过滤”，然后选中“只显示能完全管理的策略设置”复选框。随即就会显示在自定义 ADM 模板（已经导入）中所配置的首选项。

便捷工具
有大量工具可用来帮助您跟踪组策略问题。有些内置在操作系统中，另外一些则可以下载安装。接下来，我将讨论一些合适的工具，以便您可以针对自己的任务来选择正确的工具。
Dcgpofix 如果以下两个默认 GPO 中的一个出现了问题，则可以使用该工具：默认域策略和默认域控制器策略。如果其中一个或全部两个 GPO 损坏，程度严重到仅靠配置方式已经无法修复，或者存在一些其他未知问题，则可以使用 dcgpofix 工具将其还原为默认状态。此工具包含在 Windows Server® 2003 中。不应在 Windows 2000 域控制器上运行此工具；可使用 Recreatedefpol 来代替。请记住，使用此工具后会丢失所有自定义设置。
Recreatedefpol 该工具类似于 Dcgpofix，但只用于 Windows 2000 服务器。可将两个默认的 GPO 返回到其刚安装的状态。此工具应仅用于灾难恢复，不可用于 GPO 的日常维护。单击此处下载该工具。
事件查看器 事件查看器含有丰富的有关组策略的信息。很可惜，只有查遍所有不同的日志文件才能找到组策略条目。您会在其中找到与策略应用程序、策略复制、策略刷新等相关的条目，在尝试跟踪问题时所有这些条目均会派上用场。在事件日志中并非始终包含关于特定组策略错误的大量信息，但是如果有些错误您无法确定，TechNet 会随时为您提供帮助。
Gpresult 此工具只能在目标计算机上本地运行，但是它会提供有关策略的结果集 (RSoP)、阻塞的 GPO、GPO 上的权限等更多信息。使用 /v 开关命令会显示大量有关正在影响计算机的 GPO 信息，以及与当前登录会话相关联的用户帐户信息。
Gpupdate 如果您要实施新的 GPO 设置或试图确保所有 GPO 处理均已发生，请使用 Gpupdate 工具。这是一款随附于操作系统（Windows XP 及更高版本）的命令行工具。运行此工具时，将会触发后台刷新，将会应用所有符合此刷新类型的 GPO 设置。如果添加 /force 开关，则将会重新应用所有 GPO 设置，即使自上次刷新以来尚未对 GPO 做出任何更改。在运行 Gpresult 命令之前先运行此命令对于跟踪 GPO 问题极其有效。
Gpotool 由于 GPO 是从域控制器（最初先在此域控制器中进行更改，然后扩展到所有其他域控制器）复制的，因此可能会出现复制失败或聚合无效的现象。结果可能是对各目标计算机所适合应用的更改不一致或失败。像 Gpresult 和 RSOP 这样的工具可以帮助确定应用了哪些 GPO，而 Gpotool 工具则可以帮助确定每个域控制器上的 GPO 是否一致。此工具是 Windows Server 2003 Resource Kit 的一部分，其网址为 go.microsoft.com/fwlink/?LinkId=77613。
Replmon 从一个域控制器到另一个域控制器进行 GPO 的故障排除复制时，知道使用哪些工具可帮助您成功复制是很重要的。由于 GPO 有两部分必须复制，因此也有两个问题需要解决。第一，由文件复制服务 (FRS) 控制每个域控制器上的 SYSVOL 内容。除禁用和启用该服务以帮助其触发复制间隔外，您可以对此复制执行控制的内容着实不多。GPO 的另一部分，在 Active Directory 中存储哪些内容则由 Active Directory 复制控制。可使用“Active Directory 站点和服务”在同一 Active Directory 站点的域控制器间控制此复制。不过，如果您需要在不同 Active Directory 站点中触发域控制器间的复制，则需要使用工具 Replmon。Replmon 可以跨站点界限强制 Active Directory 数据库的复制，而“Active Directory 站点和服务”则不能。因此，如果您发现有不匹配的组策略信息（存储在 Active Directory），则可以使用 Replmon 触发复制过程以将该信息聚合到每个域控制器上。Replmon 是 Resource Kit 和 Windows XP 支持工具的一部分。可以从 go.microsoft.com/fwlink/?LinkId=77614 下载此工具。
RSOP 与命令行工具 Gpresult 非常相似，RSOP 为查看由所有 GPO 应用的设置提供了一个图形界面。RSOP.MSC 是一款 Windows XP Professional 和 Windows Server 2003 的内置工具。该工具采用与组策略对象编辑器相类似的格式为您提供所有已应用策略的结果，如图 5 所示。
图 5 策略工具的结果集
图 5 策略工具的结果集

总结
组策略问题的故障排除并非是像您以前执行过的那些简单任务。实际上，正如本文所述，组策略是相当的复杂。当您着手进行故障排除时，您需要了解其核心体系结构以及典型的组策略整体处理过程。还需要了解 GPO 的更新、复制、处理和应用方式。如果您对所有这些概念均有了一个通透的了解，则排除任何具体的组策略问题故障都会容易一些。遵照本文中的原则并使用合适的工具，您可以随时处理所遇到的各种组策略问题。

Derek Melber是 DesktopStandard（Microsoft 独资子公司）的教育、证书及遵从性解决方案主管。Derek 参与编著了《Microsoft Windows Group Policy Guide》（Microsoft Windows 组策略指南）（Microsoft Press，2005）。他还编写了有关审核 Windows 安全性的一系列书籍 (www.theiia.org)。可通过 derekm@desktopstandard.com 与他取得联系。


 Windows 管理: 使用 MOM 监控 Active Directory
Windows 管理 John Hann

使用 MOM 监控 Active Directory
概览:
  • Active Directory 管理包
  • MOM 的自定义提示
  • 警报调节

管理包是 Microsoft Operations Manager (MOM) 2005 不可或缺的重要部分，这也是它区别于其他管理产品之处。MOM 使用管理包将规则、报告、任务和视图结合到一起，而且它可以被限制在特定应用程序或服务的范围内，
如 Active Directory。Microsoft 产品团队创建管理包目的是用于他们所开发的应用程序，确保 MOM 反映出团队深厚的产品知识。此外，管理包还可以进行定制，以适合您的 IT 环境。这样，您便拥有了可以监控和管理产品的规则了，这些规则以您的特定服务器和应用程序环境为基础。
不仅 Active Directory® 有特定的管理包，还有很多其他管理包，用于测量从 Windows Server® 基础操作系统到动态主机配置协议 (DHCP)、DNS 和文件复制服务 (FRS) 的目录服务运行状况。我们来详细介绍一下这些管理包，以便您更好地了解通过 MOM 进行的 Active Directory 端到端管理。

DHCP 管理包
DHCP 服务管理包可监控运行于 Windows NT®、Windows® 2000 和 Windows Server 2003 上的 DHCP 服务。监控 DHCP 是个好主意，您可以了解客户端在连接到网络时是否出现问题。当您的环境中存在恶意（未经授权）DHCP 服务器时，您也会收到警报。此管理包的下载包中包含一份指南，该指南介绍了规则、报告以及监控方案和部署。TechNet MOM 2005 网站 (microsoft.com/technet/prodtechnol/mom/mom2005) 还提供了其他文档和指导集锦。
运行 DHCP 服务的 Windows 的版本越新，MOM 2005 所提供的用于管理它的规范和功能就越多。因此，您将了解到的有关 Windows Server 2003 DHCP 服务器的信息会多于 Windows NT DHCP 服务器。例如，DHCP 管理包可以监控运行于 Windows Server 2003 上的 DHCP 服务器的超级作用域，但却仅可监控 Windows 2000 DHCP 服务器的普通领域。作用域可以排除在监控范围之外，方法是将该作用域作为监控脚本的参数进行排除。
如前所述，DHCP 管理包支持 DHCP 服务器在 Windows NT、Windows 2000 Server 和 Windows Server 2003 上运行。通过使用操作系统版本的公式，并根据服务器是否托管 DHCP 服务器服务，来填充计算机组。
DHCP 管理包不支持低权限配置。代理操作帐户必须是本地管理员组的成员。支持无代理监控，但在无代理配置中不支持任务。图 1 列出了 DHCP 管理包提供的报告。
Figure 1 DHCP 服务报告 (Close Figure 1)

所有 DHCP 服务器
所有授权的 DHCP 服务器
性能历史-活动队列长度
性能历史-冲突检查队列长度
性能历史-每秒拒绝数
性能历史-每秒发现数
性能历史-每包毫秒数 (Avg)
性能历史-每秒 NACK 数
性能历史-领域空闲地址数
性能历史-使用中的领域地址数
性能历史-超级领域空闲地址数
性能历史-使用中的超级领域地址数
您可以从 go.microsoft.com/fwlink/?LinkId=79527 下载 DHCP 管理包。

DNS 管理包
域名服务管理包可监控运行于 Windows 2000 Server 和 Windows Server 2003 上的 DNS 服务。由于它是 Active Directory 实施的整体运行状况的主要部分，因此使用 MOM 2005 监控 DNS 是至关重要的。DNS 管理包可监控名称解析问题、数据库问题、注册表问题、运行时事件和错误，以及相关的性能计数器。
Windows 2000 Server 必须安装 Windows Management Instrumentation (WMI) DNS 提供程序。具体而言，此提供程序允许 DNS 管理包查询 WMI DNS 命名空间，以获取信息并进行测试。
计算机组通过使用操作系统版本的公式并根据该服务器是否托管 DNS 服务器服务进行填充，以确定组成员身份。DNS 管理包只在 Windows Server 2003 上支持低权限。在 Windows 2000 上，操作帐户必须是本地管理员组的成员。在 Windows Server 2003 上，操作帐户必须是本地用户和性能监控用户组的成员。此外，操作帐户必须拥有“管理审核和安全日志”(SeSecurityPrivilege) 以及“允许本地登录”(SeInteractiveLogonRight) 权限。图 2 列出了 DNS 管理包提供的报告。
Figure 2 DNS 服务报告 (Close Figure 2)

所有 Windows DNS 服务器
所有 Windows DNS 服务器（按区域排列）
所有 Windows DNS 区域（按服务器排列）
Marcus Oh（Microsoft® Systems Management Server (SMS) 的 MVP）开发了一个测试 DNS 服务器的脚本，该脚本通过调用 nslookup 来验证 DNS 服务器解决问题的能力。有时间可以看一下他的博客，网址为 marcusoh.blogspot.com/2006/05/mom-monitoring-dns-synthetically.html。您会希望将此脚本集成到您的 DNS 管理包中。
您可以从 go.microsoft.com/fwlink/?LinkId=79528 下载 DNS 管理包。

FRS 管理包
Windows 文件复制服务管理包可监控运行于 Windows 2000 和 Windows Server 2003 上的 FRS 服务。FRS 是域控制器用来复制登录脚本和组策略信息的。FRS 管理包会详细记录每个域控制器的 FRS 服务的运行状况。
FRS 管理包采用了 Ultrasound 工具，该工具可从 go.microsoft.com/fwlink/?LinkId=79529 下载。Ultrasound 可为 FRS 在每个域控制器上创建 WMI 命名空间。请注意，Ultrasound 需要数据库才能运行，且会将来自 WMI 命名空间的信息存储在每个域控制器上以监控运行状况。通过使用来自 Ultrasound 的信息，FRS 管理包可监控副本集、成员、连接、FRS 服务本身，以及 Ultrasound 控制器服务。
实际上，您应该将 Ultrasound 安装在管理服务器之外的独立服务器上。Ultrasound 规则可代替其他计算机生成事件和警报。为了使 Ultrasound 规则正确处理数据，必须在每台运行 Ultrasound 的服务器上的 MOM 管理员控制台中启用代理代表。图 3 列出了 FRS 管理包提供的四个服务报告。
Figure 3 FRS 服务报告 (Close Figure 3)

Ultrasound-经常检测到的问题-最可能有问题的连接
Ultrasound-经常检测到的问题-最可能有问题的成员
Ultrasound-经常检测到的问题-最可能有问题的副本集
Ultrasound-经常检测到的问题-摘要
与此管理包相关的计算机组包括运行于 Windows 2000 Server 和 Windows Server 2003 上的 Microsoft Ultrasound 1.0 服务器和 FRS 服务器。计算机组通过使用操作系统版本的公式并根据该服务器是否托管 FRS 服务进行填充，以确定组成员身份。当服务器上安装了 Ultrasound 时会填充 Ultrasound 服务器组。
将 FRS 管理包配置为低权限时，任务不会工作，但支持管理包的其他功能。操作帐户必须具有 Ultrasound 数据库的读取访问权，以及 GetControllerStatusForMOM001 存储过程的运行权限。FRS 管理包支持监控无代理以及代理管理的计算机。
您可以从 go.microsoft.com/fwlink/?LinkId=79530 下载 FRS 管理包。

Windows 服务器管理包
Windows 基础操作系统管理包可监控 Windows NT 4.0 Server、Windows 2000 Server 和 Windows Server 2003。该管理包将向您的域管理器报告操作系统的运行状况，同时还会监空系统的根服务。该管理包提供核心 Windows 服务、内存和处理器效能以及磁盘可用空间和磁盘执行时间的状态。此管理包和本文中所介绍的其他管理包的监控规则之间有一些重叠，但是它可针对域控制器的运行状况提供出色的自下而上的视图。
图 4 显示了基础操作系统管理包提供的报告。对于其他管理包，所有计算机组均通过使用操作系统版本的公式来填充。
Figure 4 基础操作系统报告 (Close Figure 4)

磁盘性能分析
操作系统配置
操作系统性能
操作系统因事件关闭
操作系统因服务器关闭
操作系统存储配置
安装的软件和应用程序（按应用程序排列）
安装的软件和应用程序（按实例排列）
安装的软件和应用程序（按服务器排列）
可靠性-应用程序故障（按应用程序排列）
可靠性-应用程序故障（按计算机排列）
可靠性-应用程序故障（按事件排列）
可靠性-操作系统故障（按计算机排列）
可靠性-操作系统故障（按事件排列）
可靠性-操作系统故障（按停止代码排列）
性能历史-性能历史
性能历史-其他报告
将基础操作系统管理包配置为低权限进行操作时，Windows 2000 需要操作账户是本地管理员组的成员。Windows Server 2003 需要操作账户是本地用户和性能监控用户组的成员，并具有“管理审核和安全日志”(SeSecurityPrivilege) 以及“允许本地登录”(SeInteractiveLog-onRight) 权限。无代理监控的计算机支持除任务外的大多数基础操作系统管理包。
您可以从 go.microsoft.com/fwlink/?LinkId=79531 下载基础操作系统管理包。

Active Directory 管理包
Active Directory 管理包内容十分广泛，其规则涉及 Windows 2000 Server 和 Windows Server 2003。Active Directory 管理包包括五方面的规则：客户端监控、信任监控、复制监控、拓扑发现，以及涵盖 Windows 2000 Server 和 Windows Server 2003 操作系统的规则。如前所述，Windows 的版本越新，启用的规范就越多，因而执行的监控也就越多。例如，管理包在 Windows Server 2003 上支持信任监控，但在 Windows 2000 上却不支持。
Active Directory 管理包创建了很多组，它使用这些组将规则应用于特定的计算机。客户端监控规则使用名为“Active Directory 客户端监控”的组。将安装有 MOM 代理的计算机置于此组中，以监控和管理这些规则。我将几台已获代理许可的台式计算机以及部分 Exchange 服务器置于此组中。Exchange Server 广泛使用 Active Directory，而且是开发问题的主要指示器。该组中的台式计算机可帮助您衡量最终用户体验。客户端监控规则利用脚本测试域控制器的连接性，通过 LDAP 查询，并报告故障。需要注意重要的一点是，客户端监控规则仅适用于代理管理的计算机，这些计算机必须启用代理但不能是域控制器。
信任监控规则使用名为“Active Directory 信任监控”的组。Windows Servers 2003 计算机会置于此组中以测试信任。Windows Server 2003 具有一个 WMI 命名空间，用于监控信任。这些规则使用一个脚本来查询 WMI 命名空间。当检测到其他域发生信任错误时，这些规则会向您发送警报。
有很多 Active Directory 管理包规则适用于 Windows 2000 Server 或 Windows Server 2003。这些规则区分了 Active Directory 在这两种操作系统中的不同实施方式。但是，大部分 Active Directory 管理包都是两种操作系统规则的结合体。其中部分规则包含脚本，用以测试域控制器之间的连接，验证灵活单主机操作 (FSMO) 角色所有者、目录信息树 (DIT) 数据库的大小，验证组策略处理过程、知识一致性检查器 (KCC) 检查以及站点间的消息服务测试。
复制监控是 Active Directory 管理包的中心内容。有两个组，Active Directory 复制执行时间数据集合（源和 Active Directory 复制执行时间数据集合）目标，可让您配置仅用于报告复制监控的域控制器。数据集合组的每个成员均会计算复制执行时间。性能计数器会使用它的更新时间来填充，以复制到每个组成员。如果企业范围的复制执行时间超过了定义的阈值，则会进行计算并报告（同时生成警报）。请注意，Windows 2000 Server 上必须安装用于监控复制的 WMI 命名空间。
Active Directory 管理包中的拓扑发现用于创建您的实施图表。这些图表大有用处，并可导出到 Microsoft Office Visio®。图表由 MOM 实时构建，因此您可在几秒内可创建一个最新版本。
在 MOM 2005 操作员控制台的图表视图下，有三个 Active Directory 管理包图表。“中断的连接对象”图表（请参阅图 5）将显示任何错误连接。如果没有错误连接，则此图表为空白。
图 5 中断的连接会在图表视图中突出显示
图 5 中断的连接会在图表视图中突出显示
“连接对象”图表会突出显示 DC 之间的连接。“站点链接”图表会显示每个 Active Directory 站点，该站点中相应的域控制器和连接站点链接将被封装。
由于 MOM 这些视图创建的图表是动态的，因此您可以将其导出到 Visio，以便进行编辑和自定义。例如，图 6 显示了正在 Visio 中编辑的站点链接图表。
图 6 在 Visio 中编辑站点链接图表
图 6 在 Visio 中编辑站点链接图表
图 7 列出了 Active Directory 管理包提供的报告。图 8 显示了与此管理包相关的计算机组。如图所示，Active Directory 计算机组由明确的成员身份进行填充；Windows 计算机组根据操作系统的版本以及计算机是否为域控制器进行填充。
Figure 8 计算机组 (Close Figure 8)

Active Directory 客户端监控
Active Directory 复制执行时间数据
集合-源
Active Directory 复制执行时间数据
集合-目标
Active Directory 信任监控
Windows 2000 Server 域控制器
Windows Server 2003 域控制器
Figure 7 Active Directory 报告 (Close Figure 7)

AD 域控制器
AD 角色所有者
AD 复制连接对象
AD 复制站点链接
AD DC 磁盘空间
AD 域更改
AD 机器账户验证故障
AD 复制带宽
AD 复制执行时间
可在 Windows Server 2003 域控制器上将 Active Directory 管理包配置为低权限。此管理包不支持无代理监控。在 Windows 2000 Server 上，代理操作账户必须处于域管理员组或者本地管理员组中。在 Windows Server 2003 域控制器上，代理操作账户配置的其他权限也必须配置为低权限，包括用户和性能监控用户组的成员身份，事件日志的访问权，以及 SeSecurityPrivilege、SeAuditPrivilege 和 SeInteractiveLogonRight 权限。此外，还需要以下访问权：对 Active Directory 中的 CN=MomLatencyMonitors 容器的完全访问权，以用于监控复制；对包含 NTDS.dit 数据库和日志文件的目录的读取访问权；以及对以下注册表项的读取访问权：
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Service\NTDS\Parameters
如果您在 Windows Server 2003 中监控信任，则请注意：脚本 AD 监控信任需要代理操作账户具有域管理员组或管理员组成员身份。
您可以从 go.microsoft.com/fwlink/?LinkId=79540 下载 Active Directory 管理包。

自定义 Active Directory 的 MOM
必须配置 Active Directory 管理包，否则警报会将您的控制台填满。Active Directory 管理包最繁忙的时间出现在域控制器重新启动的时候 - 好像每个可以触发的警报都触发了。不幸的是，这一情况很难消除。您最好的选择是利用 MOM 中的“维护模式”，在预期的维护窗口中控制警报。维护模式的目的是自动解决针对域控制器的警报，以保持控制台不被填满。
请确保通过将客户端计算机和适当的服务器置于组中，以配置 Active Directory 客户端监控组。与此组相关的规则有助于确定您的 FSMO 及其连接的运行状况。
有些性能规则使用阈值绑定到 FSMO（使用 LDAP、PING 和 DNS）以验证连接。这些规则位于 Active Directory 可用性性能规则中。您应该通过设置警报严重性来定制这些规则所使用的阈值。例如，FSMO 绑定使用以秒为单位的属性值。每个 FSMO 角色的性能规则均使用此方法创建警报。
了解状态规则的警报严重性计算设置的工作原理是很重要的。此对话框将 If-Else 条件用作属性值，并相应地设置警报严重性（请参阅图 9）。当规则收集 AD Op 主响应脚本创建的“上次绑定”性能计数器时，它会与这些规则设置的条件阈值进行对比检查。需要为您的环境配置这些不同的警报级别。
图 9 设置警报严重性规则
图 9 设置警报严重性规则
请记住每个域控制器的复制日程安排。如果给定的域控制器其日程安排与其他域控制器不同，则它将改变复制执行时间结果，此时您需要调高阈值的设置。您将需要设置复制脚本的参数，以满足您特定环境的需要。有重要的一点需要注意，当任何域控制器出现故障或发生复制问题时，即使这些组中的其他各域控制器不是直接复制合作伙伴，它们也可报告该域控制器的复制故障。因此，即使您将出现问题的域控制器置于维护模式中，其他域控制器也可报告复制故障。
调节 Active Directory 管理包时，您应重点监控复制。您需要在环境中运行管理包几个星期，以查看它发送警报的情况。一旦发现有任何趋势，即可使用报告概述执行时间并相应地调节阈值。
最后，您应利用 Alert Tuning Solution Accelerator（英文）中所提供的指导。

展望未来
MOM 2005 以及 Active Directory 管理包可让您切实有效地监控组织的 Active Directory 实施情况。通过 Active Directory、DHCP、DNS、FRS 和 Windows Server 基础操作系统管理包，您可以更好地监控基础结构的大部分内容、保护 Active Directory 基础结构及用户的良好运作。使用您的报告数据仓库收集到的大量数据，您可以对性能和事件数据进行分析，以帮助制定容量规划和性能趋势。
有关我在本文中讨论的管理包以及其他大量内容，请参阅 Management Pack Catalog（英文）。
Active Directory 管理包的下一次更新将包括常用修补程序集合，以及几个阀值的调整程序。更加有趣的是为产品（称为“System Center Operations Manager 2007”）的下一个版本而规划的新功能，这些功能包括：监控单个配置组的多个林结构，定义域控制器组（每个域控制器都在其他组之间具有自己的预期复制执行时间），以及监控运行于下一个 Window Server 版本上的域控制器。有关详细信息，请参见 MOM 网站 microsoft.com/mom，并以此结束本文。

John Hann从 MOM 2000 开始便一直从事 MOM 工作，且自 2004 起他便是一位 MOM MVP。John 还为 MyITForum.com、MOMCommunity.com 和 LearnMOM.com 等网站撰稿。您可以通过他的博客与他联系。


 Windows 管理: 在安全环境中玩游戏
Windows 管理 Matt Clapham

在安全环境中玩游戏
概览:
  • 写入受保护的文件夹和注册表项
  • 复制保护故障
  • 防火墙问题
  • 企业客户端问题

白天，我的工作是 Microsoft 安全方案经理。我还常常为 TechNet 杂志写一些安全性方面的文章。不用说，我非常重视安全问题。但是我也有其他的
爱好。在业余时间，我喜欢玩基于 Windows® 的游戏。其中最喜欢第一人称射击游戏、模拟游戏、角色扮演游戏和实时战略游戏。这里有个问题。和朋友 Jesper Johansson 和 Aaron Margosis 一样，除非绝对必要，否则我不会以管理权限运行。我之所以这么做，部分原因是为了确定：如果我在网络游戏中输得很惨，是由于我自己能力不够，而不是由于对方使用 Rootkit 作弊才取得胜利（请参阅“资源”边栏中列出的 Quake 3 Buffer Overflow Advisory）。
正是这种固执使我经常无法玩最新的游戏（请参见图 1）。如果一款游戏加入到 Small Business Server (SBS) 域的客户端上，在使用管理员帐户安装和更新之后，还不能使用“受限用户帐户”(LUA) 运行的话，我会立即卸载该游戏。对于这么差劲的作品没有什么好说的，再说我也从来不缺游戏玩。听起来似乎有些偏激，但我始终坚持这一点。尽管如此，为了获得极其美好的玩游戏机会，我并不反对解决几个小问题，这正是我在这里要讨论的内容。因此，请允许我分享一些我遇到的与玩游戏有关的问题，以及我发现比较可行的解决方法。有关最佳实践的简短摘要，请参阅“以受限用户身份玩游戏的技巧”边栏。
图 1 执行手动更新时的文件访问问题
图 1 执行手动更新时的文件访问问题

常见问题
这种权限问题并不新鲜。有许多游戏以及其他类型的程序，用户必须拥有管理权限才能正常运行。请参阅知识库文章“使用受限用户帐户登录时某些程序不能正常运行”(support.microsoft.com/kb/307091)。文章列出了近 200 种由受限用户运行时会出现问题的游戏和应用程序，其中有来自 Microsoft 的几款程序。
需要说明的是，我认为使用管理权限安装或（手动）更新游戏程序不是什么问题。在我们有能力完成 Windows 上的常规按用户安装之前，这通常是必需的。那一天快来了，但现在还没到。但是，一旦游戏程序安装和更新完成，则系统上的任何用户应该都可以玩，甚至是受限权限用户也毫不例外。
尝试写入受保护的文件夹和注册表项 我发现的一个最常见问题是：在启动游戏时或在游戏过程中，会是试图写入受保护的文件夹或注册表项时出现故障（此问题常见于许多基于 Windows 的应用程序）。默认情况下，只有管理员（和反对使用的 Power User）能够写入某些文件夹（如 %PROGRAMFILES%）和注册表配置单元（如 HKEY_LOCAL_MACHINE）。由此产生的错误相对明显："Error 42:Can't write log files to C:\Program Files\CoolGamesInc\NewestFPS\Logs\”（错误 42：无法将日志文件写入 C:\Program Files\CoolGamesInc\NewestFPS\Logs\）或“Game not installed properly, reinstall and restart.”（游戏安装不正确，请重新安装并重启。）在游戏过程中也遇到一些问题。例如，在保存进度时，系统显示一些错误消息。有时，游戏程序编写者至少会警告用户，目前需要拥有管理权限才能正常运行游戏的某项功能，Age of Mythology® 就是这样。大型多人在线网络游戏 (MMOG) 常常会遇到权限问题，因为这种游戏要频繁自我更新，而从技术上来说解决自我更新角问题要更棘手一些。我大致看了一下 EVE Online 测试版，注意到它所遭受的问题不仅包括将日志文件放入不适当的位置，而且包括试图自我更新游戏程序内容数据到安装文件夹。
复制保护故障 游戏无法启动的第二个最常见的原因是：以受限用户身份运行游戏时，游戏程序的内置复制保护（或其他反盗版功能）不起作用。其原因可能是驱动程序未正常启动或者某一后台服务未运行。这个问题的最常见表现形式是：即使所需媒体已经放入驱动器，系统还是要求用户插入磁盘。我还发现，游戏程序要求必须拥有管理员权限是因为相信只有管理员才能正常运行复制保护检查。最差劲的情况是给出一些无确实根据的毫无意义的错误消息，其中没有任何关于游戏程序支持站点的参考信息。
无法请求防火墙例外 可在本地网络或 Internet 上运行的多人游戏非常普遍。Windows XP Service Pack 2 (SP2) 增加一个警告消息，如果应用程序试图监听网络，系统会通知用户。这使涉及到我发现的另一个常见问题：游戏程序需要防火墙例外，但在安装游戏程序时不询问是否添加防火墙例外。由于受限用户不能更改防火墙配置，如果管理员不参与完成一些配置工作，则无法补救此警告（请参见图 2）。还有更糟的，有时问题不明显，因为警告显示在 Windows 外壳中，而不是显示在游戏程序的界面中。事实上，我通常是在退出游戏程序之前连错误消息都看不到。
图 2 防火墙设置阻挡了所有娱乐
图 2 防火墙设置阻挡了所有娱乐
企业客户端问题 我发现的另一个问题与以受限用户身份运行不直接相关。虽然如此，还是值得讨论一下。我家的计算环境象小型企业一样运行。（在这里我不想详细说明，但您可以通过阅读文章了解一下“Master Your Domain:Build a Corporate Network at Home”，这是 Jesper Johansson 和我为 2006 年十月份的 TechNet 杂志撰写的文章。）使用 SBS 2003 (R2)，我利用重定向到服务器共享的“我的文档”文件夹设置了一个完整的 Windows 域。就是这样发现我将讨论的最后一个最常见问题：游戏无法处理企业客户端。
我注意到 Age of Empires® III (AoE3) 有两大不足之处。开发团队值得赞扬，以受限用户身份也可以正常启动和玩游戏。但是，由于通过网络写入大量的记录数据，导致游戏每一关的加载都很慢。另外，只要我退出 AoE3，该游戏就会丢失我所作的配置、保存的游戏和进度。毫无疑问，文件保存在“我的文档”文件夹中，只是游戏没有加载它们而已。特别是想到与 AoE3 相比，该系列游戏的早期版本是那么的 LUA 友好，就更是令人扫兴。
我已经了解到有一款游戏至少已承认这类企业客户端问题。当我尝试 Fable®:The Lost Chapters™ 时，该游戏程序考虑得非常周到，它告诉我不支持远程“我的文档”文件夹，然后温文尔雅地退出。对于开发团队承认不支持的关予以并取消，我是极为赞赏。但是，如果游戏程序只是由于要在“我的文档”文件夹中放入几兆字节的数据就尽力阻止用户使用，就有点奇怪了。

简单的解决方法
我再三遇到这些问题，已经记不清涉及多少款游戏了。幸运的是，大多数问题都有简单方便的解决方法。我最喜欢的解决方法是完全丢弃这个游戏，改玩同一流派中其他发行商的 LUA 友好游戏。当然，这还是有点走极端。而且，对于刚刚花 60 美元买的新游戏来说，由于包装盒已打开不能退货，所以这不是最好的解决方法。那么，还是看看有什么方法来修理一下已经拥有的新游戏。以受限用户身份玩游戏的技巧
  • 升级到 Windows Vista。
  • 购买前试一下演示版本。很可能发现完全版本存在的所有 LUA 问题。
  • 查看一下在 LUA () 下运行时会出现问题的已知程序列表。
  • 寻找带有 Designed for Windows 徽标的游戏。
  • 安装后，在以受限用户身份运行之前更新游戏程序。
  • 如果您发现以受限用户身份无法正常运行某个游戏，请向发行商和公司的技术支持部门报告您的问题。
  • 如果您必须运行该游戏，请使用系统本地 Power User 帐户。

解决复制保护问题 首先，我们来解决复制保护驱动程序问题。复制保护系统还在，但并不意味着它们就应该阻止非管理员运行游戏！大多数游戏程序使用 Macrovision 的 SafeDisc 复制保护机制，该机制安装了驱动程序来检查原始游戏盘。默认情况下，将该驱动程序配置为按需启动（不允许受限用户使用的功能）。Microsoft 和 Macrovision 都有分布式修复程序，但我发现另一个解决方法：
  1. 使用管理员帐户打开“设备管理器”。
  2. 转到“查看”菜单，然后选择“显示隐藏设备”。
  3. 展开“非即插即用驱动程序”节点。
  4. 打开“Security”或“SecDrv”驱动程序的属性（请参见图 3）。
  5. 将启动类型更改“自动”。
图 3允许复制保护正常运行
由于现在启动计算机同时启动驱动程序，所以用户插入磁盘运行游戏程序时驱动程序已准备就绪。
解决文件系统和注册表访问问题 假定能够无拘无束地访问文件系统或注册表的任何部分是当前许多程序和原有程序存在的常见问题，不仅仅局限于游戏。Aaron Margosis 的文章“权限问题：查找和修复 LUA 错误”详细讨论了导致需要管理员权限的各种问题的解决方案。
跟踪访问问题有点棘手。但是，一旦知道哪些文件、文件夹和注册表项是必需的，则直接了当地开放访问控制列表 (ACL)，以允许受限用户玩游戏，即可解决问题。下面的方法极其成功：
  1. 从 microsoft.com/technet/sysinternals 获得最新版本的 Filemon 和 Regmon。
  2. 以管理员身份运行这些工具，并让它们开始收集记录。
  3. 以管理员身份玩几分钟游戏，执行最常用的任务（启动新战役、保存游戏、托管网络游戏等等）。
  4. 筛选 Filemon 和 Regmon 的结果，集中了解所测试游戏的访问情况。
  5. 如果需要，开放有问题的文件夹和注册表项的 ACL。
  6. 以非管理员身份运行该游戏，确保它现在可以正常运行。
关于开放 ACL，我有一句警告：开放范围不要太宽（如“每个人”—“完全控制”）或开放级别不要太高（如 HKEY_CLASSES_ROOT）。也最好避免更改系统文件夹（如 %SYSTEMROOT% 和 %PROGRAMFILES%）的任何权限，以避免完全破坏 Windows 或使系统处于不安全状态。
另一个可能的解决方法是以系统本地 Power User 身份运行游戏。这不是我的第一选择，但通过使用系统的本地帐户，如果出现故障，至少可以将影响范围限制在一个工作站内。我发现这个方法可以修复大多数只有以管理员身份才能正常运行的游戏。
有点离题了，我发现暂时以管理员身份运行游戏是使游戏自我更新的最简便方法。我通常是以管理员身份运行游戏，调用其更新选项，退出游戏，然后恢复使用受限用户帐户实际玩游戏。（值得一提的是，如果修补程序由原始发行商签发，则 Windows Vista™ 允许受限用户更新应用程序。)
Windows Vista 还可帮助游戏和其他应用程序解决文件和注册表的访问问题。默认情况下，由受限用户运行的程序会将对这些被误导的重定向文件和注册表访问执行的虚拟化修补程序转到特定于用户的缓存。我亲眼看见在 Windows 9x 时期设计的游戏程序（例如“粘土世界”）在 Windows XP 上不能正常运行（由于权限问题），而在使用默认修补程序的 Windows Vista 上却运行得非常好。我希望在 Windows Vista 上测试一些其他有问题的游戏程序，但我预感要找到 Windows Vista 不能正确修复的游戏会很困难。
解决防火墙问题 最好在第一次安装游戏程序时解决防火墙问题。但游戏的安装程序还没有智能到查询和配置必备的防火墙调整程序。下面推荐一个效果不错的方法：
  1. 以管理员身份登录。
  2. 打开“Windows 防火墙控制面板”。
  3. 选择向防火墙例外列表添加程序。
  4. 提示时从列表中选择游戏或浏览到游戏可执行程序。
通过向防火墙例外添加游戏可执行程序，保证允许游戏访问正常运行所需的所有端口。现在可以痛快淋漓地玩游戏了！
解决企业客户端问题 游戏在企业客户端上遇到的问题迟早会消失。使用宽带的多计算机家庭数量在增加，在家运行 SBS 的用户群也在增加。但目前仍需相应的解决方案。
就我的具体情况而言，我发现系统本地 LUA 可以解决重定向“我的文档”问题。只要不将“我的文档”文件夹重定向到网络文件夹，以受限用户身份运行“帝国时代 3”和“神鬼寓言：失落之章”的效果都会非常好。资源
  • Quake 3 Buffer Overflow Advisory
  • Windows Vista Application Development Requirements for User Account Control Compatibility
  • Applying the Principle of Least Privilege to User Accounts on Windows XP
  • Aaron Margosis’ LUA Buglight tool
  • Standard User Analyzer
  • Master Your Own Domain:Build a Corporate Network at Home
  • 权限问题：查找和修复 LUA 错误
  • 使用受限用户帐户登录时某些程序不能正常运行

结束语
强烈建议以受限用户身份运行，这样您可以利用以管理员身份运行所没有的帮助。在一个企业连接的权限最少的环境中，玩游戏不一定容易，但也不是完全不可能。过去这些年，我发现每个流派都有许多游戏以受限用户身份运行得很好。我还发现，通过执行一些修补程序也可以玩许多其他游戏。同时，通过使用 Windows Vista 中的虚拟化功能，过去以受限用户身份在 Windows XP 上不能玩的游戏又可以玩了。

Matt Clapham 是 Microsoft 的安全方案经理，西雅图 IT 安全社区的积极参与者和 IT 孵化项目风险管理团队成员。


 编辑视角: 内部原理
编辑视角
内部原理

WINDOWS VISTA 无疑 在 2007 年对企业的 IT 部门产生了巨大的影响。正如《InformationWeek》（信息周刊）中所报告，近期的 IDC 报告预计，由于 Windows Vista 的“活跃”，所造成的直接结果是美国今年将会产生 100,000 个 IT 职位。今年，全球将有大约 9 千万台新计算机预装 Windows Vista，到明年年底，80% 的计算机将会预装 Windows Vista。同时，您需要决定您的组织是否需要部署该操作系统了。我们可以为您提供帮助。
《TechNet Magazine》（TechNet 杂志）本月刊开办了一个系列板块，将深入探讨是什么使 Windows Vista 如此隆重 - 内核。诚然，Windows Vista 具有出色的新的用户体验功能，但是，如果这就是要更换系统的主要原因的话，我们就要小心了。内核象征着操作系统的本质，且在 Windows Vista 的内核在工作方式上也有显著改善。
没有人比 Mark Russinovich 更适合就这些变化撰文以飨读者，他对 Windows 内核的了解无人能及。他与 David Solomon 共同撰写的《Windows Internals》（Windows 内部结构）已经成为内部原理探寻爱好者的首选资源。
本月，Mark 会为我们介绍 CPU 分配的改进，这一改进会使桌面应用程序的响应更快，另外，他还将介绍 Windows Vista 如何在内核级别上增强多媒体性能。文章还会介绍 Windows Vista 中 I/O 模型的重要变化，包括基于文件的符号链接、取消同步 I/O 操作的新功能（依我看来，这是主要变化），以及 I/O 优先级的概念。在基于您的环境对 Windows Vista 进行评估时，请务必阅读 Mark 的综合性文章。
当然，日常任务仍然无法回避，我们同样会帮助您解决。本刊涵盖了许多 Windows 管理领域，其中的文章内容涉及在 Active Directory 中委派权限、Windows Vista 中的新组策略模板、组策略故障排除，以及使用 MOM 监控 Active Directory 等各个方面。
最后，如果您希望在玩游戏的同时保持系统安全，那么您可能希望了解一下在安全环境中玩游戏的功能。您知道他们所说的关于只工作不娱乐的谚语吧。—JOSHUA TRUPIN

衷心感谢以下 Microsoft 技术专家： Matt Ayers、Eugene Bak、Vijay Bharadwaj、Michael Fortin、David Hicks、Khushru Irani、Mehmet Iyigun、Arun Kishan、Mark Lawrence、Pavel Lebedynskiy、Ben Mickle、Michael Murgolo、John Orefice、Ravisankar Pudipeddi、Jeffrey Richter、David Solomon、Jim Truher、Landy Wang 和 Andy Zeigler。


 工具箱: 面向 IT 专业人员的新产品
工具箱
面向 IT 专业人员的新产品
Greg Steen

转移数据
SQL Examiner Bundle
www.sqlaccessories.com
无论在组织内您的角色是 DBA、开发人员、操作专家还是多面手，如果您使用 SQL Server™，您就可能要在各环境之间转移数据，同时要确保数据的完整性和数据结构原封不动。当然，SQL Server 有许多内置的复制和同步功能，但是如果您要检查您的 QA 数据库与开发数据库是否完全匹配，那么象 TulaSoft 的 SQL Examiner Bundle 这样的工具功效非凡，它会为您节省时间和精力。
只需单击几下鼠标，该应用程序即可找出两个数据库实例之间在数据库结构上或数据本身的差异。您只要简单地将应用程序指向希望检查的数据库并继续即可。顾名思义，SQL Examiner Bundle 捆绑了两个应用程序：SQL Examiner 和 SQL Data Examiner。SQL Examiner 查看数据库的结构，而 SQL Data Examiner 则查看所有数据并突出显示所有不同之处。
SQL Examiner 查看并比较数据库实例中的每项内容，上至表和存储过程，下至全文目录和 XML 架构集合。对于使用 SQL Server 2005 的数据库，您还可以比较公共语言运行库 (CLR) 程序集。比较数据库之后，SQL Examiner 会让您选择应该同步的数据库对象以及同步的方向。
使用 SQL Examiner 查看并比较您的数据库
使用 SQL Examiner 查看并比较您的数据库
该应用程序真正让人赞叹的功能之一是，它会生成创建对象的 SQL 脚本，并在所生成的脚本中突出显示数据库之间的不同之处。这将是在构建目标数据库的结构时，创建脚本和迁移脚本失败后突出显示错误的一个好方法。（“哦，我就在那儿漏掉了群集索引！”）您可以单独运行所生成的脚本、保存这些脚本以待稍后运行，或是仅仅单击“同步”按钮让应用程序替您完成这一切工作。
另一个很好的功能是可以选择向比较添加排除项，如忽略注释、触发器、索引或对象的扩展属性。查看结构比较之后，SQL Data Examiner 允许您浏览数据并查看所有不同之处。您可以选取哪些表要进行比较以及这些指定表的哪些列要进行比较。数据表的比较完成之后，您可以查看哪些行是相同的、哪些行是不同的、以及哪些行仅存在于其中的一个数据库中。
与 SQL Examiner 一样，SQL Data Examiner 允许您单击一个按钮即可同步表，或者您也可以选择应该传送哪些数据以及传送的方向。两个应用程序均允许您将设置保存为一个项目，这样您就不必每次都重新创建任务。每个应用程序均可单独购买，但根据我的经验，您一定会全买。
价格：单用户许可证 299.95 美元。

搜索重复文件
zsDuplicateHunter (Professional Edition)
Zizasoft
如果您从事台式机管理工作，那么您肯定遇见过计算机上“空间不足”的用户。一项调查显示，尽管您已经针对用户群体设置了一个用于存储文件的备份“网络附加存储”(NAS) 系统，但该用户每次进行编辑时仍会复制他的文档。或者，您有一个使用批处理的日志服务器，管理了大量的重复日志，因此占用了所有已分配的服务器空间。对这些问题的解决方案之一或许是 zsDuplicateHunter Professional Edition，这是一个可在 Windows®、Linux 或 Mac OS X 上运行的、基于 Java 的副本查找器。
您可以利用此应用程序轻松地搜索驱动器、目录或网络共享并找出可能的副本。此应用程序并非仅限于名称比较，它允许您按文件大小、文件校验和、甚至文件摘要计算来分组文件，以确保您在清理的文件确实是不同的。另外，您不必永久删除副本。作为一项防范措施，此应用程序允许您将所有经过标记的副本移至指定的文件夹中。
另一个很好的功能是“Keep Files in this Folder, Delete Duplicates Elsewhere”（保留此文件夹中的文件，删除其他位置的副本）选项，它允许您选取干净的源目录，删除可能在磁盘上的任何其他副本。在搜索结果中，您还可以双击任何文件以使用相关的文件查看程序打开它、将文件排序以及选择文件以得到您所需要的精确结果。其优秀的“IT pro”（IT 专业人员）功能可让您在搜索副本时调整允许该应用程序所占用的内存量。作为一个附加的保护，您还可以禁用搜索隐藏文件或系统文件，以确保不会删除任何不应该删除的内容，或者不会删除操作系统或其他应用程序所管理的任何文件。
Professional Edition 还提供了针对您搜索结果的精细过滤器，让您可以使用正则表达式来查找要清除的准确文件。
价格：单用户许可证 39.95 美元。

应用程序与您形影相随
MojoPac
www.mojopac.com
如果您辗转于各种环境之间，因而丢失了您最喜爱的应用程序和桌面设置，或者您不愿意将自己的操作痕迹留在其他人的桌面上，那么源于 RingCube 技术的 MojoPac 或许能助您一臂之力。
尽管名字不太好听，但利用 MojoPac 您就可以在 USB 硬盘驱动器（可通过 USB 2.0 与主机系统相连的个人介质设备，如 Zune 或 iPod，甚至是具有足够存储空间的手机）上将您的设置和应用程序携带到任何 Windows XP 系统（Home、Professional、Media Center 或 Tablet）。撰写此文时，该产品尚未支持 Windows Vista™ 和 Windows 2000 主机，但据此产品网站上的文档讲，很快便会提供支持这些 OS 的升级。
使用 MojoPac 携带您的设置
使用 MojoPac 携带您的设置
目前，MojoPac 要求主机系统上的管理员权限，但正在开发的 2.0 版本将会支持受限的用户模式。该工具主要运行主机 OS 与存储设备之间的互相操作。在将应用程序安装到便携式设备后首次启动时，MojoPac 触发初始的 Windows 帐户设置以开始运行，为您的 MojoPac 用户将您的个人设置配置到 MojoPac 设备上。
启动并运行之后，在主机系统和 Mojo 系统之间切换很容易：只需单击屏幕顶部的工具栏（它可以最小化）即可。在 MojoPac 处于活动状态时，将应用程序正常安装到您的 Mojo 设备即可。只要在自述文档中注意到有关安装到默认目录的醒目警告，就应按其要求执行。
总之，对于任何奔波于各种环境之间，然而需要其个性设置的 IT 专业人员而言，MojoPac 可能是一笔宝贵的财富。例如，您可以在 MojoPac 上拥有所有的系统实用程序、封包探测器以及流量监控器，然后在您组织中的任何 PC 上进行故障排除而不留下任何操作痕迹。
价格：单用户许可证 49.99 美元。

书评
SQL Server 2005 管理员指南
www.aw-bc.com
越来越多的 IT 团队意识到 SQL Sever 2005 所提供的强大潜在功能和广泛的应用范围。从扩展的 XML 数据支持，到 SQL Server Integration Services (SSIS)，再到 SQL Server 2005 Service Broker，该应用程序添加了大量实用的增强功能。为帮助您实现自己的升级路径或管理您最近发布的 SQL Server 2005 实例，Buck Woody 撰写了一本优秀的参考指南 - 《Administrator’s Guide to SQL Server 2005》（SQL Server 2005 管理员指南）（Addison-Wesley Professional，2006）。
本书可帮助您深入了解应用于新服务器平台的实用管理实践，并且与许多其他参考资料不同的是，本书简明扼要。本书开篇介绍了如何正确调整您的基础结构以适合您的应用程序需要，以及在各种不同的情形之下应适合使用哪个 SQL Server 版本。关于如何构建您的基础结构方可确保不会由于安装时可避免的性能瓶颈问题而导致失败，也可在本书中找到满意的答案。
然后，本指南会介绍 SQL Server 所提供的各种不同工具，如增强的 SQL Server Profiler 和新的 SQL Server Management Studio。您还会深入了解维护和自动化任务，以及了解如何规划基于服务器配置文件的增长和如何为您的实施提供合适的维护计划。
在有关安全的一章中，您还会通过 OS 和 SQL Server 实例探索如何方能确保您的安装（从网络和硬件）安全。您还可以通过本书了解新平台所提供的新增的加密、证书和密钥管理服务。
另一章说明了确保您系统高可用性（基于您的实施需要）的现有机制。您会将群集、数据库镜像、复制和日志传送作为获取最新需求的方法。由于虚拟化逐渐成为既可获取高可用性而又不会因为基础结构物理差异影响系统开销的一种好方法，因此本书会指导您使用 Microsoft Virtual Server 逐步设置一个两个节点的群集。
有关 SSIS 的一章不仅为您讲解了如何使用新工具（再见了，DTS！）来开发和部署提取、转换和加载 (ETL) 功能，还讲解了如何使用这些服务来创建监控、电子邮件通知和备份任务。
最后，本书结尾的几章深入研究了新 SQL Server 平台所提供的报告和分析服务。在这里，您将接触到报告设计和创建、管理报告系统以及维护分析服务部署所涉及的内容。
总之，《Administrator’s Guide to SQL Server 2005》（SQL Server 2005 管理员指南）是快速管理、监控和升级到 SQL Server 2005 的绝佳途径。
价格：49.99 美元。


 SQL 问题与解答: 数据库大小、镜像、标记事务及其他
SQL 问题与解答
数据库大小、镜像、标记事务及其他
编辑：Nancy Michell

移动群集
问：对于下面的两个物理服务器，如果将 SQL Server 2000 群集（以及 Windows® 群集和 SQL Server™ 群集）移动到新 IP 地址。我需要重建整个解决方案吗？
答：不需要，您只需要运行 SQL Server 安装程序和修改 IP 地址。下面的知识库文章会介绍详细步骤。

数据库大小
问：我目前使用的 SQL Server 2000 SP4 中有一个差不多 10GB 的关键任务数据库、一个 SIMPLE 恢复模型、一个 9,850MB 的主文件和一个 88MB 的事务日志文件。数据库备份差不多也有 10GB。为了提高性能，我应该减少数据库大小吗？如果是的话，我应该使用 DBCC SHRINKDATABASE 还是 DBCC SHRINKFILE？（问题在于，我没有空闲的非高峰时间来进行这种维护。）
答：只有当数据库经历许多删除和更新并导致数据量变少时，DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 才有帮助。但真正的问题是您为什么会在意这些？目前，10GB 的磁盘只卖 20 来美元。再加大约 100GB 的磁盘空间并运行起来不是更有意义吗？可用空间中的碎片越多，性能越恶化。但如果您不能进行任何维护，您的选择范围就很小了。在这种情况下，有时人们使用数据库的另一个副本。他们通过复制使备份副本保持最新，对备份副本进行维护，然后将应用程序切换到备份副本。显而易见，这需要进行一些代码更改和离开 SIMPLE 恢复模型（到 FULL 或 BULK_LOGGED），这是个很好的长期解决方案。

升级和性能
问：我需要将两个应用程序从 SQL Server 2000 移动到 SQL Server 2005。在升级过程中，我如何才能避免对性能产生不良影响？
答：在升级过程中，下面这些失误通常会造成性能降级，所以应努力避免出现这些错误：
  1. 升级到 SQL Server 2005 后没有重建统计数据。
  2. JOINS 和 WHERE 子句会比较两个不同的数据类型，从而导致性能下降，特别是在服务器以前运行 SQL Server 2000 SP3 或更低版本的情况下（请参阅 support.microsoft.com/kb/271566/）。
  3. SQL Server 2005 实例没有正确配置；内存、地址窗口化扩展插件 (AWE)、驱动程序等均未正确配置。运行 SQL Server 2000 的方框已调整，执行操作的人已离开但未记录，所以在 SQL Server 2005 实例上从未完成过。
  4. 硬件出现故障。购买新硬件常常是因为广告上看起来很好，但在现实生活中却并不实用。
在生产系统中采用 SQL Server 实例之前，应先设立一个性能基准，以确定可实现预期性能。这样会排除可能出现问题的基础结构。另外还需要查看 Perfmon 计数器（如磁盘、I/O 和内存），并在实例之间进行比较。

数据库镜像
问：我目前使用数据库镜像，并想启用 READ_COMMITTED_SNAPSHOT 数据库选项。设置镜像后，我试图启用该选项，但我收到一个异常消息，声明数据库正在镜像会话之中，无法运行该命令。
答：出现这个问题的原因是，设置 READ_COMMITTED_SNAPSHOT 选项后，需要重启数据库才能生效。所以，您需要断开镜像会话，设置选项，然后重启数据库。完成这些步骤后，就可以重建镜像了。建立会话后，镜像数据库可选中该选项，并在发生故障转移时使用。

问：我试图设置异步镜像，但是收到 1418 错误。运行 Netstat -ano 显示 SQL Server 正在监听所有服务器上的正确端口。在我试图启动镜像时显示该错误。这是怎么回事？
答：一种可能性是防火墙拦截了通信；这个问题相对来说比较普遍，您应该进行调查。有关更多帮助，请查阅下面的白皮书：对数据库镜像设置进行故障排除和 MSSQLSERVER_1418。
不过请注意，这个问题不是异步镜像所特有的。事实上，同步镜像也会发生这样的问题。
您收到的错误（“The server network address "%.*ls" cannot be reached or does not exist.Check the network address name and reissue the command”（服务器网络地址 "%.*ls" 无法访问或不存在。请检查网络地址名称，然后重新发布命令））是正确的。通常不是远程合作伙伴不存在，只是无法访问而已。
如果远程合作伙伴停机或未监听端口，甚至端点停机，都可能发生上述问题。（如果远程合作伙伴不能协商相同的加密机制或有一些其他身份验证问题，就可能发生端点停机。）如果发出命令的合作伙伴的防火墙拦截了合作伙伴与外界的通信，也会发生这种故障。
您还要排除一些其他问题，其中包括数据源名称 (DSN) 问题和名称解析问题。通常会建议您使用完全限定域名。所以请记住，如果您的防火墙经常出现问题，肯定是另有隐情。

问：我想使用 SQL Server 2005 镜像；但是，我听说如果在同一 SQL Server 实例上有多个应用程序连接到多个数据库，则不建议使用镜像。是这样吗？
答：事实上，根据您是每个应用程序都有自己的数据库还是多个应用程序使用跨数据库事务或分布式事务处理协调器 (DTC) 事务，答案是不同的。如果使用跨数据库事务，则镜像会引起逻辑矛盾，无法按预期提交事务。有关在此情形下会发生状况的详细讲解，请单击此处。
如果多个应用程序使用多个数据库，并且每个应用程序都有自己的数据库，则镜像不会造成这些问题。

标记事务
问：“标记事务”的确切含义是什么？它们是不是可在一个数据库是 SQL Server 而另一个数据库是 Oracle 的情况下使用？
答：标记事务是指 DBA 定期在所有日志中的同一位置放置标记。此操作结合使表格恢复事务标记的能力，允许您将所有数据库恢复到同一点。执行此操作非常痛苦，因为您必须恢复涉及到的所有数据库，还将丢失所有数据库中的数据，因此您必须确保不丢失日志文件，以避免发生问题。标记事务是特定于 SQL Server 的，因此如果您的分布式事务包括非 SQL Server 数据库，这些数据库不能参与事务标记。总的来说，很少有分布式数据库系统使用事务标记。只是将丢失一个事务日志视为灾难性事件，从中恢复需要许多手动工作。

Access-To-T-SQL 转换工具
问：是否有可供存储过程使用的自动执行 Access™-SQL 到 T-SQL 的转换工具？
答：试一下 SQL Server Migration Assistant (SSMA) for Access，点击下载此工具。这里还有 SQL Server Migration Assistant for Oracle、SQL Server Migration Assistant for Sybase 和 Migrating Informix Databases to Microsoft® SQL Server 2000。
要从 Access 升迁到 SQL Server，可使用 Office 升迁向导。但 SSMA for Access（图 1 所示）有更多功能，包括转换评估报告和网络扫描。SSMA for Access 还可以修复目前 Office 升迁向导无法正确处理的许多问题。
图 1 SQL Server Migration Assistant for Access
图 1 SQL Server Migration Assistant for Access

非群集索引
问：我有一个表格，其主键由两个 GUID（假设为 GUID1 和 GUID2）构成。在 GUID1 和 GUID2 上已有唯一的群集索引。现在因为性能上的要求，需要在 GUID2 和 GUID1 上创建第二个非群集索引。如果我将该索引声明为唯一，是否会对性能产生影响？
答：将非群集索引声明为唯一不会对性能产生任何负面影响。事实上，这样做会减少索引树层次。
如果将非群集索引声明为非唯一，会将行定位器追加到根页面和非叶页面中索引条目的键部分。这样做是为了方便删除和更新索引条目，如果有键副本，可避免扫描同义字链 — 通过对键加定位器执行系统搜索操作找到要更改的特定条目。结果是这些条目较长（与您选择的群集键相比，这些条目相当长）。因此，根页面和非叶页面自然会更快地填满。如果索引是唯一的，您应如此声明。
要点是，不管表格是否有群集索引，表格中未声明为唯一的任何非群集索引均会将定位器追加到根页面和其他非叶页面中的索引条目。
另外，如果您使用 int 标识符列作为代理键，然后增加两个唯一的索引（GUID1、GUID2）和（GUID2、GUID1），则会改善性能，因为这些索引有 4 字节群集键，而不是 32 字节群集键。

更新锁
问：如果存储过程的结构如下：
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
BEGIN TRANSACTION

-- Get The lock if available
UPDATE    ProcessingInstances
SET       LockHolder = @MessageId
WHERE     ( InstanceId = @InstanceId )
AND       ( LockHolder IS NULL )

COMMIT TRANSACTION
此存储过程只允许一个调用者获得锁，任何其他调用者均需等待。我能通过降低隔离级别达到相同的行为吗？
好像 READ COMMITTED 是正确的隔离级别，因为这个事务只有一个查询，如果另一个事务正在更新同一个记录，则这个事务只能等待另一个事务。是这样吗？
答：在您的示例中，不是序列化设置使其他调用者等待，而是更新本身让其他调用者等待。是的，您可以将隔离级别设置为 READ COMMITTED，无论更新使用什么索引，都会自然获得更新锁。这会给执行同一条语句的其他进程造成问题，所以在更新完成之前会阻止其他进程的执行。（另外，如果更新是唯一的语句，则不需要显式事务；如果语句不在显式事务中，则每个语句在其自己的事务中是隐式的。）
但是，如果 UPDATE 语句中没有与 WHERE 子句相匹配的行，则使用序列化隔离级别可防止其他事务插入或修改这样的行。如果您要在 READ COMMITTED 隔离级别中运行 UPDATE，就不会发生上述问题，其他事务也能够引入适合于更新的行。如果存储过程代码确实是如您所示的代码，则采取这些措施（序列化或事务）没有什么意义；您只需执行更新即可。

衷心感谢以下 Microsoft IT 专家，感谢他们与我们分享了技术与专业知识： Gaurav Aggarwal、Anthony Bloesch、Todd Briley、Shaun Cox、Roberto Di Pietro、Michael Epprecht、Kevin Farlee、Umachandar Jayachandran、Chuck Ladd、Kaloian Manassiev、Luciano Moreira、Ward Pond、Mark Prazak、Arunachalam Thirupathi、Roger Wolter、Clement Yip 和 Frankie Yuen。


 实用工具特别推荐: 组策略库存
实用工具特别推荐
组策略库存
Greg Steen
下载这篇文章的代码: GPInventory.exe (150KB)

您如何 知道您会遇到什么情况，如果不进行跟踪？每当召开预算分配会议和进行年度审计的时候，可随时获得库存详细信息会让您从许多令人头痛的事务中解脱出来。当然，主管们似乎总是想知道每个人的问题和原因，以及这一重大升级要花费多少时间。
使用“组策略库存”(GPInventory.exe) 工具会让这一切问题迎刃而解，该工具包含在 Windows Server® 2003 Resource Kit 中。利用该程序，您可以使用“用户策略结果集”(RSOP) 和/或 Windows® Management Instrumentation (WMI) 查询，从多个远程主机中查询和检索系统信息，如图所示。无需诧异，该程序不仅可以轻松检索组策略信息，还可以有效提炼出详细的系统信息，比如已安装的应用程序、处理器的名称及速度，或者所安装的修补程序列表。另外，还有更多好处！因为它是 Windows Server 2003 Resource Kit 的一部分，因此完全免费。
图 1 使用 GPInventory 收集信息
图 1 使用 GPInventory 收集信息
GPInventory.exe 有多种不同的使用方法。例如，如果您需要验证担保状态，则可以通过网络收集 PC 的序列号或服务号，而不必将每台机器都搬来一一查看。或者，如果您拥有实验室环境并希望知道某台机器当前是否正在使用，只需在座位上查询当前登录到系统的用户。如果您安装了一台刀片服务器，并用它定期下载映像（如用于清理和还原 QA 环境），则可以查询 PC 的安装日期以验证上次应用映像的时间。
GPInventory 的使用也相当简单。将该工具指向要盘点的计算机的列表文件，选择要运行的查询，然后处理该列表。该工具随即会运行，并连接到列表中的每台计算机进行查询。若要执行快速查询，还可以从 Active Directory® 中直接选择目标计算机，并从“查询”菜单中选择要执行的查询操作。
要在计算机上运行 RSOP 查询，您需要拥有“生成策略的结果集(记录)”权限（默认情况下，域管理员和受委派的管理员具有该权限）。WMI 查询需要拥有远程计算机的管理权限，除非您使用 WMI Control MMC 管理单元授予备选用户 root\cimv2 命名空间的“启用帐户”和“远程启用”权限。
运行查询之后，可以将结果保存为制表符分隔的文本文件或 XML。这两种类型的文件均可导入到 Microsoft® Excel® 中进行分析。您可以通过排序及应用自动过滤器来查找所有详细信息。
GPInventory 也支持命令行，因此，您可以轻松建立查询系统信息的计划任务，然后不必使用 GUI 即可将查询结果直接保存为 XML 文件。这非常适用于需要长时间运行且无人看管的查询。
该工具的默认设置为 RSOP 和 WMI 查询，但是如果您所需要的查询未在其中，可以利用自己的自定义列表添加、编辑和更新查询文件。所包含的帮助文档会向您说明如何在查询列表 XML 文件中定义新查询。
GPInventory.exe 非常适合于在网络内收集运行 Windows 的计算机的信息，无论是库存、组策略还是状态信息。“组策略库存”工具的链接位于我们网站的下载部分。

Greg Steen 是一位技术专家和企业家，他酷爱钻研技术。他总是在寻找能便于 IT 专业人员进行操作和开发的新工具和新方法。


 网络专家: Windows 中的 QoS 支持
网络专家
Windows 中的 QoS 支持
Joseph Davies
这篇文章基于 Windows Server“Longhorn”的预发布版。文中的所有信息可能会有所变动。

服务质量 (QoS) 中包括一组技术，可用于以经济有效的方式管理网络通信，以增强家庭和企业环境中的用户体验。利用 QoS 技术可测量带宽、检测不断变化的网络状况（如拥塞或带宽的可用性），
并对通信排列优先级或进行遏制。例如，QoS 可应用于对延迟敏感的通信（如语音或视频应用程序）传送排列优先级，并控制对延迟敏感的通信（如大量数据传送）的影响。为 TCP/IP 通信提供优先传送需要主机和网络基础结构设备的支持。本专栏说明了将 QoS 与基于 Microsoft® Windows® 的主机配合使用的方法。
为 TCP/IP 网络定义 QoS 的中心问题在于如何指定并提供 IP 通信的优先传送。虽然 IP 的原始 RFC 791 定义了在“服务类型”(TOS) 字段可以指定优先级、延迟、吞吐量、可靠性和成本特征，但 IP 原则上是一项基于数据报尽力传送的数据包交换技术，它通常根据先到先得的原则对每个数据包一视同仁。

配置优先传送
要提供优先传送服务，有几种方法您可以试试看。您可以配置网络基础结构为标记的通信提供特殊处理，然后使发送主机标记它们的传出通信。或者，可以使发送主机动态地编制网络基础结构的程序，以根据其传出通信的特征（如地址和端口号）提供特殊处理。
对于 TCP/IP 通信，可以使用几种不同的方法来提供优先传送。例如，在以太网的网络接口层，IEEE 802.1p 标记会将主机发送的帧标记为优先传送，方法是使用以太网帧的虚拟局域网 (VLAN) 报头中的 3 位“优先级”字段。VLAN 报头位于以太网报头内的“源地址”字段和“长度”字段（对于 IEEE 802.3 帧）或“以太类型”字段（对于以太网 II 型帧）之间。
在发送主机上实现 802.1p 标记要求网络适配器和设备驱动程序支持 802.1p，并且网络适配器已启用 802.1p 支持。通常可以从网络适配器驱动程序属性的“高级”选项卡启用 802.1p 支持。以太网交换机也必须启用 802.1p 支持。
在 IEEE 802.11 无线的网络接口层上，Wi-Fi 多媒体 (WMM) 的 Wi-Fi 联盟证书为优先网络通信定义了四个访问类别。这些访问类别（按最高到最低的优先级）分别是语音、视频、尽力传送和背景。WMM 优先顺序的主机支持需要无线网络适配器及其驱动程序支持 WMM。无线访问点 (AP) 必须启用 WMM。
在 Internet 层，可以使用“差分服务”并在 IP 报头中设置“差分服务代码点”(DSCP) 的值。如 RFC 2472 中定义的一样，DSCP 值是 IP 版本 4 (IPv4) TOS 字段和 IP 版本 6 (IPv6) 通信类字段的高阶 6 位。
大多数现代企业路由器都支持 DSCP 通信差分，但通常默认情况下它被禁用。在转发期间，支持 DSCP 的路由器会读取 DSCP 值并将数据包置于特定队列中。例如，您可以根据定义的 DSCP 值配置路由器，将转发的数据包置于高优先级、尽力传送或低于尽力传送的队列中。通过配置队列和 DSCP 值，标有 DSCP 的通信可以具有不同级别的服务。例如，会首先转发关键任务网络通信，而不会被其他更低优先级的大量数据通信延迟。WMM 规范定义了如何将 WMM 访问类别映射到 DSCP 值。支持 WMM 的无线 AP 根据其访问类别读取 DSCP 值并处理通信。
在 Internet 层上，也可以使用“资源预留协议”(RSVP)，即 RFC 2205 中定义的信号协议。主机可以使用此协议尝试将网络带宽预留给一个端点。然而，RSVP 并未在网络上广泛使用，而且当前在 Windows XP、Windows Server® 2003、Windows Vista™ 或代码名为“Longhorn”的 Windows Server 下一版本（当前为测试版）中均不支持它。
要发送标记为优先传送的数据包，应用程序或操作系统组件必须能够指定 802.1p 优先级的值或 DSCP 值。以下部分介绍 Windows 组件或基于 Windows 的应用程序如何为以太网帧指定 802.1p 优先级或为 TCP/IP 通信指定 DSCP 值。

Windows XP 和 Windows Server 2003 中的 QoS
Windows XP 和 Windows Server 2003 提供了为通信分配 QoS 参数的 API。应用程序开发人员可以使用 Windows Sockets (Winsock) 和“常规服务质量”(GQoS) API 在应用程序级别逐个套接字应用 QoS 参数。网络管理员可以使用为调用“通信控制”(TC) API 而编写的通信管理工具在主机级别应用 QoS 参数。
您可以使用 Winsock 和 IP_TOS 套接字选项为套接字的传出数据包设置 DSCP 值。但是，默认情况下，TCP/IP 堆栈忽略 IP_TOS 套接字选项。要使用 IP_TOS 套接字选项，必须首先在下列注册表项下创建和设置 DWORD 注册表值 DisableUserTOSSetting=0（请参阅图 1）：
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
图 1 设置 DisableUserTOSetting 的注册表值
图 1 设置 DisableUserTOSetting 的注册表值
必须重新启动计算机，方可使此注册表设置生效。
要在不必使用 IP_TOS 套接字选项的情况下指定通信的 DSCP 值，可以使用 GQoS API。GQoS 是 Windows Sockets 2.0 (Winsock2) 的一部分。大多数启用 QoS 的应用程序使用 GQoS API 来调用 Windows 中的 QoS 功能。Windows XP Service Pack 2 (SP2) 中的 GQoS 允许应用程序设置 DSCP 值并遏制其出站通信。要在运行 Windows XP SP2 的计算机上设置 802.1p 优先级，必须使用 TC API。
TC API 提供访问通信控制机制的途径，这些机制调整本地主机上的网络通信。 它允许直接控制 DSCP 值、802.1p 标记和节流率。网络管理员可以使用通信管理程序来代表不识别 QoS 的应用程序直接调用 TC API。因为 TC API 是比 GQoS API 级别低的 API，所以它需要管理员级别的权限。
与 GQoS API 不同，TC API 允许同一发送主机上多个应用程序的通信聚合在一个 QoS 流中。作为此聚合的一部分，通信可以由其源 IP 地址和目标 IP 地址、源端口和目标端口以及协议（TCP 或 UDP）的组合进行标识。例如，特定目标 IP 地址的所有通信（任何源端口和目标端口，与主机上的发送应用程序无关）都可以包括在一个 QoS 流中。另一方面，GQoS API 允许应用程序定义自己对通过套接字所发送数据的 QoS 处理方法。
要支持 QoS 功能，基于 Windows XP 和 Windows Server 2003 的计算机必须安装 QoS Packet Scheduler 组件，并在“网络连接”文件夹的网络连接属性中启用该组件（请参阅图 2）。在运行 Windows XP 的计算机中，默认情况下，已安装并启用 QoS Packet Scheduler 组件 (Psched.sys)。可以在 Windows Server 2003 上安装 Packet Scheduler 组件。
图 2 配置 QoS Packet Scheduler
图 2 配置 QoS Packet Scheduler

Windows Vista 和 Windows Server“Longhorn”中的 QoS
Windows Vista 和 Windows Server“Longhorn”中的 QoS 支持已得到了增强和简化。对于 IT 人士，现在可以使用基于策略的 QoS 来设置 DSCP 值和控制应用程序发送率，不必使用 API 或修改现有应用程序。对于开发人员，虽然 Windows 的未来版本未计划支持这些 API，但却支持 GQoS 和 TC API。另外，已删除 IP_TOS Winsock 选项。为替换 GQoS 和 TC API 并简化升级应用程序或未来应用程序中的 QoS 支持，Windows Vista 和 Windows Server“Longhorn”都支持新的 QoS2 API，也称为“高质量 Windows 音频视频体验”(qWAVE)。
Windows Server“Longhorn”和 Windows Vista 中基于策略的 QoS 允许您提供更好的终端用户体验、控制带宽成本或者与带宽提供商或业务部门协商获得更好的服务级别。您可以在整个 Active Directory® 基础结构中集中管理运行 Windows Vista 或 Windows Server“Longhorn”的计算机的网络带宽，而不必考虑应用程序。因为通信管理位于应用程序层之下，所以不需要针对基于策略的 QoS 通信管理修改现有应用程序。
Windows Server“Longhorn”和 Windows Vista 中基于策略的 QoS 设置允许您根据下列条件划分传出通信发送率的优先顺序或对其进行管理：
  • 发送应用程序（可执行程序的路径和名称）
  • 源或目标 IPv4 或 IPv6 地址或地址前缀
  • 协议（TCP、UDP 或两者）
  • 源或目标端口或端口范围（TCP 或 UDP）
QoS 策略作为链接到 Active Directory 容器（如域、站点或组织单元 (OU)）的“组策略对象”(GPO) 的一部分应用于用户登录会话或计算机，或者 QoS 策略可应用于安全组。作为“组策略”的一部分，QoS 策略构建于现有的 Active Directory 管理基础结构之上。
基于策略的 QoS 允许您定义通信的优先级。可以将 QoS 策略配置为使用特定 DSCP 值标记出站 IPv4 或 IPv6 通信。也可以管理出站通信的带宽使用。可以使用出站通信的节流率配置 QoS 策略。通过节流，QoS 组件将限制聚合传出网络通信为指定速率。对于计算机，可以管理入站通信的带宽使用，配置高级设置来指定 TCP 通信的入站吞吐量，方法是设置 TCP 接收窗口大小的最大值。
在 Windows Vista 和 Windows Server“Longhorn”中，默认情况下，已安装并启用 QoS Packet Scheduler。Pacer.sys 组件是新增的“网络设备接口规范”(NDIS) 6.0 小型筛选驱动程序，它为基于策略的 QoS 和支持 QoS 的应用程序的通信控制数据包调度。Pacer.sys 取代了 Windows XP 和 Windows Server 2003 中的 Psched.sys。
要在 Intranet 上部署基于策略的 QoS，请配置基于用户或计算机的 QoS 策略，并将其应用到相应的 Active Directory 容器。基于 Windows Vista 或 Windows Server“Longhorn”的计算机会在更新“用户配置”或“计算机配置组策略”时下载和应用其基于策略的 QoS 设置。
由于数据和音频/视频 (AV) 应用程序日益增长地分享着网络，因此需要 QoS 解决方案，以便可以在数据通信中优先处理与时间相关的 AV 通信。另外，网络正逐步地发展为无线网络，这会为延迟和带宽敏感的应用程序带来其他的复杂因素。
Windows Vista 中的 qWAVE 功能提供了与 QoS 相关的软件模块集合，解决了由 AV 应用程序和无线网络引起的网络难题。qWAVE 集成在 QoS 子系统中，并与多个 Internet 和网络接口层数据包优先级技术配合使用。qWAVE 同时支持多个 AV 流（实时流需要 QoS）和数据流（尽力传送流，如电子邮件或文件传送）。
qWAVE 技术的集合会检测并监控 LAN 带宽、发现网络的 QoS 功能以及为网络带宽的合理和一致使用提供分布式许可控制。这些技术启用了高级 AV 流技术，以便应用程序可以动态地适应不断变化的网络状况，并且仅通过 QoS2 API 供开发人员使用。
Windows Vista 和 Windows Server“Longhorn”中的 QoS2 API 取代了 GQoS API 和 IP_TOS Winsock 选项，并且您会发现它比 GQoS API 更方便易用。

更多信息
要了解 QoS 的详细信息，有许多可通过 TechNet 获取的优秀来源。从 Microsoft 服务质量网站（英文）开始。请参阅 Windows 核心网络博客（英文）的 QoS 部分。

Joseph Davies是 Microsoft 的一位技术撰稿人，从 1992 年起一直在培训和编写 Windows 网络主题。他曾为 Microsoft Press® 编写了五本著作，并且是每月的 TechNet 网络专家专栏的作者。


 Windows PowerShell: 一次编写一行脚本
Windows PowerShell
一次编写一行脚本
Don Jones

在过去的专栏中，我强调了 Windows PowerShell 是一种外壳这一事实。它应被交互式使用 — 与您可能已经很熟悉的 cmd.exe（或命令提示符）外壳并无不同。PowerShell 仍然支持脚本语言 — 一种比 cmd.exe 的批处理语言更稳定可靠的语言。并且它
同某些语言（如 VBScript）一样功能强大（如果不如其功能强大的话）。但是，Windows PowerShell™ 是一种交互式外壳的事实，使得编写脚本非常容易学习。实际上，您可以在外壳内部交互式地开发脚本，从而可以一次编写一行脚本，并立即看到自己努力的成果。
此迭代的脚本编写技术还使调试变得更加容易。由于您立即看到了脚本的结果，因此您就可以在脚本不能按预期方式运行时快速地对其进行修订。
在此专栏中，我将向您介绍一个在 Windows PowerShell 中进行交互式脚本编写的示例。我将创建一个脚本，该脚本从文本文件读取服务名称并将每个服务的启动模式设置为“Disabled”（禁用）。
我想要您从这次演练中领会到在小段代码中构建 Windows PowerShell 脚本（而不是试图在大段代码中应对整个脚本）的概念。您可以采用需要完成的任何管理任务并将其分成组成自身的多段代码，然后确定使每段代码独立工作的方法。您将看到，Windows PowerShell 提供了将那些段代码联系起来的绝佳方法。并且您将发现，一次处理多个小段代码，您就会更轻松地开发最终脚本。

从文件读取名称
确定在 Windows PowerShell 中读取文本文件的方法可能令人沮丧。如果我运行 Help *file*，那么我只能获得 Out-File cmdlet（用于将文本发送到文件）的帮助，而不会从中进行读取。根本没有帮助！但是，Windows PowerShell cmdlet 名称遵循一种使用时对自己有利的逻辑。Windows PowerShell 进行检索时，cmdlet 名称通常以 Get 开始。因此我在运行 Help Get* 显示出那些 cmdlet 后，就接着滚动列表并看到 Get-Content。看来大有希望！因此我运行 Help Get-Content 以了解更多与 Get-Content 的用途有关的信息（见图 1），并且看来 Get-Content 将能够满足我的需求。
图 1 运行 Help Get-Content 获得更多信息
图 1 运行 Help Get-Content 获得更多信息
Windows PowerShell 将几乎每件事情都作为对象来处理，文本文件也不例外。文本文件从技术上说是行的集合，文件中的每一行都可充当一种独立对象。因此，如果我已经创建了一个名为 C:\services.txt 的文本文件，并在其中填充了服务名称（在文件内部将每个名称放置在其本身的行上），Windows PowerShell 可以使用 Get-Content cmdlet 逐个读取这些名称。由于此次演练的目的是显示交互式开发脚本的方法，因此我首先只运行 Get-Content，为其赋予我的文本文件的名称，然后再查看发生了什么：
PS C:\> get-content c:\services.txt
messenger
alerter
PS C:\>
正如所料，Windows PowerShell 读取文件并显示名称。当然，只显示这些名称并不是我真正想要的，但现在我知道 Get-Content 正在以我所期望的方式工作。

更改服务
下一件我要做的事就是更改服务的启动模式。同样，我首先试图找到正确的 cmdlet。因此我运行 Help *Service*。此语句返回的列表很短，并且看起来只有 Set-Service cmdlet 才符合我的要求。在尝试将此 cmdlet 合并到脚本中之前，为了确保我了解它的工作方式，我要对其进行测试。运行 Help Set-Service，这将向我显示该 cmdlet 的工作方式，并且可通过快速测试进行确认：
PS C:\> set-service messenger -startuptype
    disabled
PS C:\>

组合各部分
现在我需要将从文件中读取服务名称的功能同 Set-Service cmdlet 相组合，并且这正是 Windows PowerShell 的功能强大的管道功能起作用之处。使用此管道，一个 cmdlet 的输出可以作为输入传递给第二个 cmdlet。管道传递整个对象。如果将对象的集合放入管道，那么每个对象将单独通过管道。这意味着，Get-Content 的输出（请记住，这是对象的集合）可以通过管道输送到 Set-Service。因为 Get-Content 传递的是集合，所以集合中的每个对象（或文本行）将单独通过管道输送到 Set-Service。其结果是对文本文件中的每一行都要执行一次 Set-Service。命令如下所示：
PS C:\> get-content c:\services.txt |
 set-service -startuptype disabled
PS C:\>
以下为将发生的情况：
  1. Get-Content cmdlet 执行，从而读取整个文件。将文件中的每一行都作为唯一的对象进行处理，将它们放在一起就是对象的集合。
  2. 将对象的集合通过管道输送到 Set-Service。
  3. 对于每个输入对象，管道都执行一次 Set-Service cmdlet。对于每次执行，都要将输入对象作为 cmdlet 的第一个参数（即服务名称）传递到 Set-Service。
  4. Set-Service 使用其第一个参数的输入对象和指定的任何其他参数（在本例中是 -startuptype 参数）执行。
有趣的是，我实际上在此时已经完成了我的任务，可我甚至还不曾编写脚本。在 Cmd.exe 外壳中将很难实现相同的操作，而且需要若干行 VBScript 代码.但是 Windows PowerShell 可以在一行中处理所有的代码。我的工作仍然没有完全完成。正如您所见，我的命令并没有提供大量的状态输出或反馈。除了没有出错误外，很难看出是否真正发生了什么。既然我已经掌握了完成任务所需的功能，那么我就可以开始通过了解真正的脚本编写来使其更好看。
Michael Murgolo 所做的 Windows PowerShell Prompt Here
“Open Command Window Here”（在此处打开命令窗口）工具是最受欢迎的（也是我最喜爱的）Microsoft® PowerToys for Windows® 之一。“Open Command Window Here”（在此处打开命令窗口）可以作为 Microsoft PowerToys for Windows XP 的一部分或可在 Windows Server® 2003 Resource Kit Tools 中使用，使用它可以在 Windows 资源管理器中右键单击文件夹或驱动器以打开指向所选文件夹的命令窗口。
当我学习 Windows PowerShell 时，发现自己希望它具有相同的功能。因此，我从 Windows Server 2003 Resource Kit Tools 获取“Open Command Window Here”（在此处打开命令窗口）的安装 .inf 文件 cmdhere.inf，然后对其进行修改，以创建 Windows PowerShell Prompt Here 上下文菜单。此 .inf 文件包括在此边栏所基于的原始博客文章（可从 leeholmes.com/blog/PowerShellPromptHerePowerToy.aspx 获得）内。要安装此工具，只需右键单击 .inf 文件并选择“Install”（安装）即可。
创建此工具的 Windows PowerShell 版本时，我发现原来的版本有错误 — 如果卸载“Open Command Window Here”（在此处打开命令窗口），它将留下失效的上下文菜单项。因此，我已经提供了一个 cmdhere.inf 的更新版本（还可以从原始博客文章中获得）。
这两种 PowerToy 都利用了以下的事实：这些上下文菜单项在注册表中与 Directory 和 Drive 对象类型关联的注册表项下配置。执行此操作时采用的方式与上下文菜单操作与文件类型相关联的方式相同。例如，在 Windows 资源管理器中右键单击 .txt 文件后，您就可以在列表顶部获得几种操作（如“打开”,“打印”和“编辑”）。要了解这些项的配置方式，让我们看一下 HKEY_CLASSES_ROOT 注册表配置单元。
如果您打开注册表编辑器并展开了 HKEY_CLASSES_ROOT 分支，您就会看到根据文件类型命名的注册表项（如 .doc、.txt 等等）。如果单击 .txt 注册表项，您就会看到 [“Default”（默认）] 值为 txtfile（见图 A）。这是与 .txt 文件相关联的对象类型。如果向下滚动并展开 txtfile 注册表项，然后在其下展开 shell 注册表项，您将看到根据 .txt 文件的某些上下文菜单项命名的注册表项。（您将不会看到所有的注册表项，因为还有创建上下文菜单的其他方法）。在这些注册表项的每一个下面都有一个命令项。命令项下面的 [“Default”（默认）] 值是命令行，选择该上下文菜单项时由 Windows 执行该命令行。
用于 cmd 提示符和 Windows PowerShell 提示符的工具使用此技术来配置“Open Command Window Here”（在此处打开命令窗口）和 Windows PowerShell Prompt Here 上下文菜单项。没有任何文件类型与驱动器和目录相关联，但在 HKEY_CLASSES_ROOT 下却有与这些对象相关联的注册表项“Drive”（驱动器）和“Directory”（目录）。
图 A 在注册表中配置上下文菜单项
图 A 在注册表中配置上下文菜单项

Michael Murgolo 是 Microsoft Consulting Services 的一名高级基础结构顾问。他关注的领域有操作系统、部署、网络服务、Active Directory、系统管理、自动化和补丁管理。

交互式脚本编写
我需要做的一件事就是针对 C:\services.txt 中列出的每个服务执行多个 cmdlet。这样，我就可以输出自己所喜欢的服务名称和任何其他信息，从而跟踪脚本的进度。
之前，我使用管道将对象从一个 cmdlet 传递到另一个 cmdlet。但是，这一次我要使用的称为 Foreach 构造的技术（我在上个月的专栏中进行过介绍）更像脚本。Foreach 构造可以接受对象的集合，并且它将针对该集合中的每个对象执行多个 cmdlet。我指定了一个变量，该变量表示每次通过循环时的当前对象。例如，构造可能这样开始：
foreach ($service in get-content c:\services.txt)
我仍将执行相同的 Get-Content cmdlet 来检索文本文件的内容。这一次我要求 Foreach 构造遍历由 Get-Content 返回的对象的集合。每个对象执行一次循环，而当前对象则放在变量 $service 中。现在我只需要指定想在循环中执行的代码。我将首先尝试复制原始的单行命令（这将最小化复杂性并确保我不会丢失任何功能）：
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> }
>>
PS C:\>
此时发生了一些有趣的事情。请注意，我使用一个左花括号结束了 Foreach 构造的第一行。左花括号和右花括号中的所有内容都被认为在 Foreach 循环内，并且针对输入集合中的每个对象都将执行一次该内容。在我键入 { 并按下 Enter 之后，请注意，Windows PowerShell 将其提示符更改为 >>（见图 2）。这表示它知道我已开始进行某种构造，并且正在等待我完成构造。接下来我键入我的 Set-Service cmdlet。这一次，我使用 $service 作为第一个参数，这是由于 $service 表示的是从我的文本文件读取的当前服务名称。在下一行，我使用右花括号结束构造。按 Enter 两次后，Windows PowerShell 立即执行我的代码。
图 2 Windows Powershell 知道已启动某构造
图 2 Windows Powershell 知道已启动某构造
没错，立即执行。我键入的内容看起来像脚本，但 Windows PowerShell 实际上正在实时执行它，而且它并没有存储在文本文件中的任何地方。现在我将重新键入全部内容，添加一行代码以输出当前服务名称：
PS C:\> foreach ($service in get-content c:\services.txt) {
>> set-service $service -startuptype disabled
>> "Disabling $service"
>> }
>>
Disabling messenger
Disabling alerter
PS C:\>
请注意，我正在要求它显示内容，并且我已经将要显示的内容括在双引号内。引号告诉 Windows PowerShell，这是一个文本的字符串，而不是另一个命令。但是，当您使用双引号（而不是单引号）时，Windows PowerShell 会扫描文本字符串中的任何变量。如果它找到了任何变量，它会将变量名替换为变量的实际值。因此，执行此代码时，您可以看到正在显示当前服务名称。
这仍不是脚本！
到现在为止，我一直在交互式地使用 Windows PowerShell，这是立即看到我所编写的内容的结果的好方法。但是，在某些时候，重新键入这些代码行将变得十分单调乏味。这是 Windows PowerShell 也可以运行脚本的原因。实际上，Windows PowerShell 脚本遵循的是脚本一词最为文字化的定义：Windows PowerShell 基本上只在脚本文本文件中进行读取，然后“键入”它所发现的每一行，看来与手动键入行极其相似。这意味着到现在为止我所执行的每项内容都可以粘贴到脚本文件中。因此，我将使用记事本创建名为 disableservices.ps1 的文件，然后在其中粘贴以下内容：
foreach ($service in get-content c:\services.txt) {
 set-service $service -startuptype disabled
 "Disabling $service"
 }
我已将此文件放在名为 C:\test 的文件夹中。现在我将试图从 Windows PowerShell 内部运行此文件：
PS C:\test> disableservices
'disableservices' is not recognized as a cmdlet, function, operable program, or
<script file.
At line:1 char:15
+ disableservices <<<<
PS C:\test>
哎哟。出什么问题啦？Windows PowerShell 现在显示位于 C:\test 文件夹，但它并没有找到我的脚本。这是为什么？由于安全约束，Windows PowerShell 设计为不能运行来自当前文件夹的任何脚本，以防止任何脚本劫持操作系统命令。例如，我无法创建一个名为 dir.ps1 的脚本并用它覆盖正常的 dir 命令。如果我需要运行当前文件夹中的脚本，就必须指定相对路径如下：
PS C:\test> ./disableservices
The file C:\test\disableservices.ps1 cannot be loaded.
The execution of scripts is disabled on this system.
Please see "get-help about_signing" for more details.
At line:1 char:17
+ ./disableservices <<<<
PS C:\test>
现在要做什么？它仍然不正常工作。我已经指定了正确的路径，但 Windows PowerShell 却说它无法运行脚本。那是因为，默认情况下，Windows PowerShell 无法运行脚本。同样，这个安全措施旨在防止发生我们使用 VBScript 时已经遇到的问题。默认情况下，恶意脚本无法在 Windows PowerShell 下执行，这是因为在默认情况下任何脚本都不能执行！为了运行脚本，我需要显式更改执行策略：
PS C:\test> set-executionpolicy remotesigned
使用 RemoteSigned 执行策略，未签名的脚本可以从本地计算机执行（下载的脚本仍然必须签名后才可运行）。更好的策略是 AllSigned，该策略仅执行已使用受信任发布方所颁发的证书进行过数字签名的脚本。但是，我手边没有证书，因此我无法对我的脚本进行签名，这种情况下 RemoteSigned 就是一种不错的选择。现在我再次试图运行我的脚本：
PS C:\test> ./disableservices
Disabling messenger
Disabling alerter
PS C:\test>
我要指出的是，我们正在使用的 RemoteSigned 执行策略并不是一个极佳的选择，它只是一个较好的选择而已。但是还有一个更好的解决方案。获取代码签名的证书，使用 Windows PowerShell Set-AuthenticodeSignature cmdlet 来对我的脚本进行签名，然后将执行策略设置为更加安全的 AllSigned 策略，这样做将安全得多。
还有另一种策略 Unrestricted（您一定要避免使用）。使用此策略，所有的脚本（甚至来自远程位置的恶意脚本）可以不受限制地在您的计算机上运行，这会将您置于很危险的境地。因此，我建议无论如何都不要使用 Unrestricted 策略。

即时结果
使用 Windows PowerShell 中的交互式脚本编写功能，您可以快速地建立脚本的原型或甚至只是小段脚本的原型。您获得了即时结果，因此可以轻松地调整您的脚本以获得真正想要的结果。操作结束时，您可以将代码移动到 .ps1 文件中，使其成为永久代码并且将来也容易找到。还要记住：理想情况下，您应该对那些 .ps1 文件进行数字签名，从而您可以将 Windows PowerShell 设置为 AllSigned 执行策略，这是允许脚本执行的最安全的策略。

Don Jones 是 SAPIEN Technologies 的首席脚本权威和《Windows PowerShell: TFM》的合著者（网址为 www.SAPIENPress.com）。请通过 don@sapien.com 与 Don 联系。


 您好，脚本专家！: 追汽车......和 XML
您好，脚本专家！
追汽车......和 XML
Microsoft 脚本专家
下载这篇文章的代码: HeyScriptingGuy2007_02.exe (150KB)

“我不知道 为什么我家的狗老是追汽车”，这是一个广为流传的老笑话，“就算有一天它真的追上一辆，又能怎么样呢？”
问得好，这是一个脚本专家都无法回答的问题。不过，Lucy（沿着大街追汽车的那条狗）除外。毫无疑问，这条狗不可能会抢劫一家酒水店，然后驾车逃之夭夭。不过，基于目前的情况，我敢打赌，她不会再造访沿途的任何其他店铺，您知道我们是指什么。
如果要在当今的高科技时代对这句陈词滥调进行更新的话，它可能会类似于此：“我不知道为什么系统管理员老是想精通 XML。就算她真的精通了，又能怎么样呢？”
请注意，在我们的辩词中只是说要更新那条令人厌倦的老笑话，而从未说过能让它好笑。
老实说，XML 可能是一项有些宣传过度的技术，至少对于系统管理员来说是如此。事实上，许多系统管理员从未编写过一个可与 XML 文件相交互的脚本，但却过着长寿而幸福的生活，而我们并不期望在不久的将来改变这一情况。
据说越来越多的应用程序采用了 XML 作为数据存储的标准，实情也的确如此。为什么不呢？因为没有什么比美化文本文件更为重要了，这些 XML 数据文件创建起来迅速而容易，可以跨平台使用，并且无需任何复杂（更谈不上昂贵）的数据库程序。您是否拥有操作系统和文本编辑器？如果有，那么您便可创建 XML 数据库。
当然，这意味着系统管理员至少可以用 XML 做一件事情：编写查询 XML 文件的脚本，就好像该文件是个功能齐全的数据库一样。到此，问一下，有没有谁可以就此情况提出比脚本专家更好的几点建议？
好吧，说的对。不过，如果必须大胆猜测的话，我敢打赌 Lucy 可能正在忙于钻研别人的精华，以便撰写一篇关于 XML 的专栏。
开始之前，让我们来看一个简单的 XML 文件（请参阅图 1）。这是一个数据库文件，由四部分脚本组成，我们在每日的“您好，脚本专家！”专栏中可以看到这个文件。
Figure 1 您好，脚本专家！XML 脚本 (Close Figure 1)
<?xml version="1.0" encoding="ISO-8859-1"?>
<Repository>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Print a Microsoft Access Report?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1020.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Access</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Compact a Microsoft Access Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1009.mspx</URL>
  </Script>
  <Script>
    <Category>Microsoft Office</Category>
    <Subcategory>Microsoft Word</Subcategory>
    <Keyword>hyperlinks</Keyword>
    <Title>How Can I Change an Existing Hyperlink in a Microsoft Word Document?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
  <Script>
    <Category>Enterprise Servers</Category>
    <Subcategory>Microsoft SQL Server</Subcategory>
    <Keyword>databases</Keyword>
    <Title>How Can I Create a Table in a SQL Server Database?</Title>
    <URL>http://www.microsoft.com/technet/scriptcenter/resources/qanda/oct06/hey1016.mspx</URL>
  </Script>
</Repository>
正如您所看到的，这是个非常简单的小文件。每个单独脚本均归于 <Script> 标记下。从现在开始，我们将这些脚本作为记录加以引用。是的，您说对了，XML 迷们决不会将这些脚本作为记录进行引用。不过没关系，我们这里的目的是为了向您展示，如何对新的和不同种类的数据源应用您已经了解的东西，即数据库查询技术。我们认为，首先应当集中于如何完成工作，然后以后或许会回到这个话题，并为您提供相应的术语。
好了，现在回过头来看看这些记录。每条记录中均包含以下字段：<Category>、<Subcategory>、<Keyword>、<Title> 和 <URL>。
嗯，您并不像我们想象的那样印象深刻。如果我们向您展示一个可打开此 XML 文件并回显以下内容的脚本，可能会有所帮助：
Set xmlDoc = CreateObject("Microsoft.XMLDOM")
xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Scripts.xml")

Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")

For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
千万注意：这些标记名称区分大小写。这里是“/Repository/Script”，而不是“/repository/script”或“/REPOSITORY/SCRIPT”。
当然，这也并不是特别令人印象深刻。但关键在于：这一切并不像您可能预期的那么难。
在代码中您可以看到，我们一开始便创建了一个 Microsoft.XMLDOM 对象（用于与 XML 文件一同使用的 COM 对象）的实例。之后，我们将 Async 属性设置为 False；这有助于确保在控件返回脚本之前将整个文件读入内存中。然后使用 Load 方法读取文件 C:\Scripts\Scripts.xml：
xmlDoc.Load("C:\Scripts\Scripts.xml")
一旦文件载入内存中，我们便可使用 selectNodes 方法从数据库中选择指定的记录：
Set colNodes = xmlDoc.selectNodes _
("/Repository/Script/*")
仔细看看传递给 selectNodes 的参数。原来，这代表 XML 文件中的路径。我们的 XML 文件具有以下结构：
<Repository>
    <Script>
        <Category></Category>
        <Subcategory></Subcategory>
        <Keyword></Keyword>
        <Title></Title>
        <URL></URL>
    </Script>
</Repository>
您是否应该加以关注？一句话，是！处理 XML 文件时，结构十分重要。例如，我们如何来影响某个记录的各属性呢？很简单：我们访问后面跟有各属性标记的 <Script> 标记之前的 <Repository> 标记即可。猜猜看？这与我们作为参数指定给 selectNodes 的路径相同。我们只不过是在该路径后加了 /*，这意味着“选择这些记录的所有属性”。换言之，我们返回的集合将由数据库中所有记录的所有属性组成，类似于 Windows® Management Instrumentation (WMI) 中的“Select * From”查询。
注意，用该脚本试试，您便会了解我们的真正用意所在。
脚本的其余部分很简单，我们所需做的只是设置一个 For Each 循环遍历此集合，然后回显各项和各属性的 Text 属性值：
For Each objNode in colNodes
   Wscript.Echo objNode.Text
Next
比追汽车更容易的方法。
但您说对了：如果我们只是要回显该文件的整个内容，那么可以绕过所有的 XML 内容，只需使用 FileSystemObject 即可。（这可能有点儿复杂，但仅仅复杂一点儿而已。）如果我们的意图使您迷惑，并使您认为“哇，XML 内容还是相当便利的”，那么，我们仍有很长一段路要走。
接下来，让我们看看可以对此做些什么。在第一个脚本中，我们返回了所有记录的所有属性值。这很好，但假设我们真正要返回的是脚本的标题，能做到吗？嗯，稍等片刻......
好了，照 Lucy 看来，我们要做的只是修改 selectNodes 命令，将关注的属性添加到该路径的结尾。换句话说：
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/Title")
我们发现，第一次返回所有属性的唯一原因是我们使用了 * 通配符。现在，我们只返回了 Title 属性。这是为什么？因为这是我们要返回的唯一属性值。
注意，看这里：XML 将为您提供精确的所需。Lucy，别不高兴，我们的确认为 XML 是人们最好的新朋友！
当然，您可返回多个属性。例如，此修改的命令将会返回 Title 和 URL 属性的值：
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL)")
无可否认，这语法看上去有点笨，但一旦您习惯了，这并不算太糟糕。开始之前，我们指定路径的母体部分，正如之前所做的那样：
    /Repository/Script/
然后加入一组括号，并在这些括号中指定要返回的属性（请注意，我们使用管道分隔符（| 字符）将各属性分开）。换句话说：
    (Title | URL)
正如我们前面所说的，它可能有点笨，但的确起作用。
而且，您不是只能返回两个属性，这没有限制。只要添加管道分隔符，您便可返回所有想要的信息。例如，以下命令将会返回三个属性（Title、URL 和 Keyword）：
    Set colNodes=xmlDoc.selectNodes _    ("/Repository/Script/(Title | URL |          Keyword)")
酷吧？
是的，我们认为它很酷。你们这些家伙真是难以对付。不过，需要再次指出的是，您说得很对：目前我们所做的一切只是检索数据库中与所有记录相关的信息。不过，这没有什么不对。通常这恰恰是您想要做的。另一方面，很多时候也存在这种情况，即我们要检索的信息只是与这些记录中的一个子集相关。例如，或许我们只是想要返回 Keyword 等于 databases 的脚本的相关信息。您知道，可以使用类似如下的查询：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]")
同样，这语法有点儿奇怪。不过，从好的方面看来，此语法同样很简单直接。指定母体路径后，我们将“Where”子句（例如，where x = y）置于方括号中，类似如下：
/Repository/Script [Keyword = ‘databases’]
您可能已经想到了，我们的 Where 子句等式将告诉脚本“仅返回其中 Keyword 属性为 databases 的项”。请注意，databases 括在单引号中。这样做不但相当整洁，而且还非常必要。如果筛选术语括在双引号中，那么您在运行该脚本时会提示语法错误。
说到为什么？请记住，因为整个查询字符串 "/Repository/Script [Keyword = ‘databases’]" 被括在双引号中。
当然，筛选数据时您不必限于使用等号 (=)。可使用大于 (>) 或小于 (<) 符号，以及自己喜好的方式，小于或等于 (<=) 以及大于或等于 (>=) 符号。您还可以在任何符号之前加一个惊叹号使之相反。例如，此命令将会请求所有脚本，其中 Keyword 不等于 databases（请注意 !=）：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword != ‘databases’]")
稍等一下：是谁说“当然，您可以设置筛选器，但我敢打赌，您无法设置筛选器并指定想要返回的属性”？当然可以：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’]/Title")
如果运行正常，此命令将仅会返回所有 Keyword 为 databases 的脚本的 Title 属性。让我们看看它是否起作用：
    How Can I Print a Microsoft Access Report?
    How Can I Compact a Microsoft Access Database?
    How Can I Create a Table in a SQL Server     Database?
让我们看看在调用它之前，是否可以再添加一条其他命令。尽管有所进步，但返回的记录可能还是会比真正想要返回的记录多。毕竟，我们之前的命令将返回 Microsoft® Access® 脚本和 Microsoft SQL Server™ 脚本混合。（为什么呢？因为所有这些脚本的 Keyword 均使用 databases。）要是我们想要限制返回数据的脚本 Keyword 为 databases 并且 Subcategory 为 Microsoft SQL Server，那该怎么办？能否通过多重标准进行筛选呢？
看来您要问：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Keyword = ‘databases’ and " & _
    "Subcategory = ‘Microsoft SQL Server’]")
其具有相同的基本语法；我们只不过使用了两个单独的条件（即，Keyword = ‘databases’ 和 Subcategory = ‘Microsoft SQL Server’），并使用 AND 运算符将这两个条件连接起来而已。
是的，您说对了：通过这个简单的 XML 小文件，我们可以只请求其 Subcategory = Microsoft SQL Server 的所有脚本。但这并不十分有趣，因为其根本不具指导意义。
您也可使用 OR 子句。例如，假设我们有一大批 Microsoft Office 脚本，其中包括子分类等于 Microsoft Excel®、Microsoft PowerPoint®、Microsoft Outlook® 等条件的脚本。能否限制仅返回来自子分类 Microsoft Word 或 Microsoft Access 的脚本数据呢？当然可以：
    Set colNodes=xmlDoc.selectNodes _
    ("/Repository/Script " & _
    "[Subcategory = ‘Microsoft Word’ " & _
    "or Subcategory = ‘Microsoft Access’]")
看上去是这个样子吗？诚然，本专栏可能永远没有资格成为一个可以改变您生活的专栏；不过以这种方式查询 XML 文件还是迟早可能会派上用场的。但决定权在于你们：您可以学习一些基本的 XML 技巧，也可以去追汽车。这由您来决定。（如果您选择后者，而又碰巧遇见 Lucy （沿着大街追汽车的那条狗），那么，请代脚本专家向它问好。还有告诉它不要呆在我们的院子里！）
您好，脚本专家！- 每天
您可能刚刚仔细读完本月的“您好，脚本专家！”专栏，并且认为它是您读过的最有收获的技术资料。您甚至可能会说这是迄今为止撰写的最好的资料。甚或，您正急切地徘徊于邮箱旁期盼着下一期的 TechNet 杂志，这样您便可读到更多类似于此的文章。
究竟您在等待什么？想知道更多关于 Lucy（邻居家的狗）的事，还是阅读有关“脚本小子”的最新成果呢？听说过去年的年度 Turducken 投球赛是如何过去的吗？请每天阅读（没错，我们说的是每天）“您好，脚本专家！”专栏，保持与这些重大事件齐头并进。每个星期一到星期五（除了重大的节假日和脚本专家的假期），您都可以读到所有关于中学棒球比赛、学院足球比赛和篮球比赛的赛况信息，偶尔也会看到当地的天气预报。（当然，这里所说的“本地”是指雷蒙德，但不想知道雷蒙德天气情况的人又该怎么办呢？）
不仅如此，实际上您每天还可以学到一些有关脚本的新知识。是的，所有如此吸引人的嵌入内容实际上是脚本信息。每篇专栏中，脚本专家都将回答他们认为是由真人提出的真实问题。您可以在线阅读每日的专栏，其网址为：microsoft.com/technet/scriptcenter/resources/qanda。同样，因为他们已经解答了很多问题，所以存档文件数量相当大，因而形成了巨大的脚本信息资源（请参阅：microsoft.com/technet/scriptcenter/resources/qanda/hsgarch.mspx）。
有问题要问脚本专家吗？您可以将问题提交给 scripter@microsoft.com，有少许机会可以得到回答。（相比之下，如果您不提交问题的话，您就没有机会得到回答，所以提交有什么损失呢？这不像彩票，这可是免费的，并且比中彩票的机会稍大一些。）

Microsoft 脚本专家为 Microsoft 工作，也就是说受雇于 Microsoft。在没有玩/指导/观看棒球（及其他各种娱乐活动）时，他们会管理 TechNet 脚本中心。要查找所需信息，请登录网站 www.scriptingguys.com。


 安全观察: 部署 EFS：第一部分
安全观察
部署 EFS：第一部分
John Morello

到目前为止，相信很多人都听说过类似报道，即由于便携式计算机的被盗或遗失而导致个人数据或敏感数据的丢失。便携式计算机定期丢失数据。由于身份盗用越来越严重，而规定符合性相比以往也日益重要，则对移动计算系统中所有数据的全面保护也就成为重中之重。
一种实现方案是使用加密文件系统 (EFS)，Windows 2000 之后的 Windows® 中皆包含此系统，可提供基于磁盘的内置高性能加密方式。EFS 与 Windows Explorer 无缝集成，因此最终用户经常不知道他们所使用的文件何时被加密。此外，EFS 同样适用于本机 Windows 身份验证和访问控制技术，因此用户无需记住各个密码来访问数据。最后，EFS 提供可管理的选项，能够在用户丢失其加密密钥的访问权限时（如用户配置文件删除或损坏，或是其智能卡丢失）恢复数据。
EFS 使用 Windows 内置加密技术生成、存储和部署强加密密钥，以保护数据。在 Windows XP Service Pack 1 (SP1) 及其更高版本中，EFS 利用 256 位密钥的高级加密标准 (AES) 算法对磁盘上的数据进行加密。然后，使用非对称 (RSA) 密钥对来保护这些对称密钥。EFS 使用 AES 密钥为每个文件进行加密，之后通过用户的 RSA 密钥对该密钥进行加密并将结果存储在文件中。有关 EFS 加密的详细信息，请参阅“EFS 资源”边栏。现在，我将略过 EFS 的技术支持，将重点集中在如何部署 EFS 并使其在您的环境中可用。由此，本文假设读者已经预先了解 EFS 加密概念的相关知识。

EFS 安全性注意事项
一些应用程序宣称能够破解 EFS 加密技术。请注意，这些应用程序实际上是通过解密 AES（或是数据加密标准，DES；又或是扩展数据加密标准，DESX）加密密文，而非强行破解用户密码来获取用户 EFS 私钥访问权限的。需要记住，有关 EFS 加密最重要的一点，私钥是利用数据保护 API (DPAPI) 来生成和保护加密数据的。DPAPI 使用用户登录凭据派生来保护数据，最终结果是使用 EFS 保护数据与使用用户密码保护数据的效果一样好。如果使用的是 Windows Vista™，现在即可将 EFS 加密证书存储在智能卡上，这将更改此范例，并且极大地提高 EFS 所保护数据的相关安全性。
多长的密码才能抵抗这些攻击？鉴于如今的硬件功能和现代密码攻击算法，推荐使用 11 个字符或更长的密码（更准确地说是密码短语）。11 个字符或更长的密码短语可更好地抵抗如今大多数的高级攻击方法，其中包括预先计算的哈希攻击（如 Rainbow Table；有关详细信息，请参阅“资源”边栏中列出的博客文章《Why you shouldn't be using passwords of any kind on your Windows networks》（不应在 Windows 网络上使用任何种类密码的原因））。

是否使用 PKI？
对于 EFS，最常见误解之一是 EFS 需要使用公钥基础结构 (PKI) 工作。尽管 EFS 可以轻松地与 PKI 集成并且对其加以利用（贵公司应该已经拥有 PKI），但这绝对不是必需的。也就是说，关于是否在 EFS 部署中使用 PKI 的决定将会影响到日后的众多部署决策，最好是三思而后行。
将 PKI 和 EFS 结合使用的主要优势在于能够执行密钥存档和密钥恢复。仅使用 EFS 时即允许管理员执行数据恢复操作，而自动密钥恢复仅在运行 PKI 时可用，甚至是仅在将 Windows Server® 2003 Enterprise Edition 作为证书颁发机构 (CA) 时可用。用户在丢失对加密密钥的访问权限后，向指定管理员，也称为数据恢复代理 (DRA)，提供其加密数据，然后该管理员可解密此数据并将其返回到用户，或者将此数据重新进行加密以通过一个新的私钥来使用，这一过程就叫做数据恢复。DRA 就像用户加密流程的影子，即用户使用密钥加密任何内容都会使用 DRA 密钥副本重复相同的操作。因此，用户丢失密钥之后，可通过 DRA 来获取密文数据，再将 DRA 密钥应用到其中进行解密（或重新加密），最后将数据返回到用户。DRA 方法的工作效果非常好，但是，如果用户拥有大量加密数据或者没有本地 IT 人员承担 DRA 职责，其管理工作就会比较困难。
另一方面，密钥恢复需要 CA 在密钥创建过程中对用户的加密密钥进行备份，并安全地将该密钥副本存储到 CA 的数据库中。然后，当用户丢失加密文件的访问权限后，CA 管理员仅需进入此数据库并检索用户的密钥。这样的话，无需使用 DRA 进行恢复操作，用户便能立即重新获取对数据的访问权限。按照此方法可以更加快速高效地恢复密钥。但是请注意，最佳实践是始终设置 DRA，即使在使用密钥恢复时也是如此，用来为密钥丢失事件提供备份机制。还支持大型组织采用分布式恢复系统，本地 IT 管理员无需加入到 PKI 管理员组即可恢复用户数据。
将 PKI 和 EFS 结合使用可能带来的另一个优势是更易于共享加密文件。注意，EFS 不仅仅限于便携式计算机系统；它在任何不能保证计算机的物理安全性的情况下一样非常有用。在这些情况下，可能存在多个用户需要访问同一加密数据的情况。虽然 Windows 仅允许共享单个文件，而非目录，也因此对共享加密文件的支持会受到一些限制，但还不失为一个有用的工具。要简化 EFS 文件的共享，则正在共享文件的用户就必须具有访问与之共享文件的用户公钥的权限（如果这些用户具有向 Active Directory® 中的帐户发布的有效 EFS 证书，这将非常简单）。虽然能够手动执行发布，但使用安装在 Enterprise（与 Active Directory 集成）模式中的 Windows CA 可将整个过程完全自动化。

EFS 密钥管理
如果您使用的是基于 Windows Server 2003 的 PKI，则用户 EFS 证书生成会是一个非常简单的过程。Windows Server 2003 CA 带有一组默认的证书模版，其中包括 Basic EFS。然而，此模版属于版本 1 模版，不支持密钥存档。因此，使其可在 CA 上使用之前，您需要复制模版，以创建新的版本 2 模版（例如，可以称其为带有密钥存档的 EFS，如图 1 所示）。在这个新模版上，请转至“处理请求”选项卡，然后选中可存档用户加密密钥的选项。请注意，在启用此选项之前，您需要在 CA 上正确配置密钥存档。资源部分包括此过程的最佳演练。您还应该使用此模版来替换 Basic EFS 模版，以确保客户端能够使用到此新版本（参见图 2）。
图 1 带有密钥存档的 EFS
图 1 带有密钥存档的 EFS
图 2 替换 Basic EFS 模版
图 2 替换 Basic EFS 模版
接下来，您需要在此模版上设置适当的权限，以允许指定的用户组具有相应的注册访问权限。由于在第一次使用 EFS 时，Windows 中的 EFS 组件会自动请求证书，所以通常情况下，无需让用户针对 EFS 模版进行自动注册。事实上，除非确定所有自动注册的用户都使用 EFS，否则建议您不要启用 EFS 证书的自动注册。图 3 显示了 EFS 注册设置。通过向可能从未使用过 EFS 的用户颁发证书，您能够扩大 CA 数据库的规模，但这样做却毫无益处。尽管 CA 数据库在规模上未受到限制，但如果证书的颁发数量不断增多的话，数据库的管理工作会越发困难（采用 Microsoft 管理控制台 (MMC) 的情况下尤为明显）。
图 3 设置 EFS 用户权限
图 3 设置 EFS 用户权限
最后，如果需要支持加密文件的共享，最好是让 CA 自动向 Active Directory 发布用户证书。
一旦您在 CA 上对模版进行了正确的配置，用户在第一次通过 EFS 加密文件时，将会从您的 CA 处获取证书，同时 CA 也将自动对其私钥进行存档。

DRA 密钥管理
如果使用了 PKI，那么下一个需要考虑的问题就是：是否使用 CA 生成的 DRA 证书。为什么不想使用来自 PKI 的 DRA 证书呢？请考虑这种情况，即颁发 CA 的证书有效期相当短（两年甚至更短）。该 CA 不能颁发任何有效寿命比其自身有效期更长的证书，这意味着您的 DRA 证书最多只能有两年的使用期限。这就造成了极其复杂的数据恢复局面。下面对这个假定示例进行说明。
  1. 用户在 2006 年 1 月加密了一个文件；通过组策略向其计算机颁发的 DRA 证书的有效期为两年（于 2008 年 1 月过期）。
  2. 用户继续使用 EFS 加密新文件。
  3. 在 2008 年 1 月 DRA 证书过期后，管理员通过组策略颁发新的证书。
  4. 从现在起，将使用新 DRA 证书完成所有的加密操作（包括打开那些通过原有 DRA 证书加密的所有文件，在保存时会使用新的 DRA 进行加密），但是用户没有动过的文件仍然是受到原有 DRA 的保护。
  5. 如果用户无意中破坏了配置文件并需要进行数据恢复。
  6. 则 IT 管理员就必须要提供两组 DRA 证书：步骤 3 之后改动过的文件使用新 DRA 证书，而未改动过的文件使用原有的 DRA 证书。
虽然 IT 管理员在步骤 3 之后能够通过运行脚本，使用新的 DRA 来更新全部文件（使用 cipher.exe /u），但是这一过程却要耗费大量时间。而更确切地说，尽管在恢复策略中包含过期 DRA 证书的情况下，EFS 组件将不允许任何新的加密操作，DRA 密钥对在过期之后也不是全无用处。毫无疑问，由过期 DRA 密钥对加密的旧文件仍可以由它们来恢复。因此，即使 DRA 密钥对已经过期也不要丢弃它们，说不定日后还会用到。
因此我建议，证书使用期限较短的 CA 所处的环境中应采用拥有较长使用期限的自签名 DRA 证书。密码实用程序包括一个可自动创建具有 100 年使用期限 EFS 恢复代理密钥对的开关（参见图 4）。之后，此密钥对中的证书可附加到组策略对象 (GPO)，并作为整个组织的 DRA 加以使用。由于 EFS 组件不会检查 DRA 证书的信任链，所以，无需在系统上对受信任根证书颁发机构的列表进行改动，即可使用这些自签名证书。无论组织的 CA 的使用期限有多长，始终推荐至少创建一个使用寿命较长的 DRA 证书并将其附加到域范围 GPO 中。这是在所有其他选项都不可用的情况下所使用的备用数据恢复选项。缺少 CA 密钥存档的情况下使用 CA 生成的 DRA 密钥尤为重要。如果 DRA 证书已经受损，则可以通过新的证书来更新 GPO，并使用上述的 cipher.exe /u 来更新文件。
图 4 运行 Ciquer /R
EFS 资源
可以访问以下站点来获取更多有关 EFS 细节和最佳实践的详细信息。
  • Why you shouldn’t be using passwords of any kind on your Windows networks（英文）
  • Implementing Key Archival Walkthrough（英文）
  • Encrypting File System in Windows XP and Windows Server 2003（英文）

部署 KRA 和 DRA
密钥存档支持 CA 管理员代表用户恢复托管加密密钥。很明显，这是一种既敏感又强大的能力，因为它允许 CA 管理员对组织中任何使用由 CA 签名的密钥的数据进行解密。因此，应谨慎对待密钥存档和恢复，并且仅向少数受信任的安全人员授予权限。鉴于密钥恢复的敏感性质，如果您想要将其作为重新获取 EFS 加密数据访问权限的主要机制，明确定义要发送到 CA 管理员团队的恢复请求升级进程十分重要。仅在对请求进行全面检查后才能启动恢复过程。之后，一旦密钥被实际恢复，应该通过一种安全的方式（换言之，就是不要使用电子邮件）将其提供给用户，因为恢复的密钥提供了对用户所有受 EFS 保护数据进行访问的权限。
密钥恢复代理（或 KRA 密钥）由 CA 管理员生成和保管，并且不会通过组策略进行通告。事实上，EFS 自身不能确定其所使用的密钥是否已存档；它只是和往常一样执行加密操作。另外，在 CA 上创建的 KRA 密钥不以任何方式特定于 EFS。使用密钥存档的 CA 将在 CA 级使无限多个 KRA 密钥附加到其上，可用来保护由 CA 存档的全部密钥。这些密钥包括与 EFS、安全电子邮件或任何其他包括加密的证书用途一同使用的密钥。应由专用的密钥恢复代理安全地存储 KRA 密钥，并且至少要有两个 KRA 以备发生密钥丢失现象。
管理员首次在新创建的域中登录域控制器时，将使用存储在 DC 管理员配置文件中的自签名证书和密钥对，在域级别创建默认恢复策略。此 DRA 证书具有三年的有效使用期限。推荐方法是删除此默认证书，并代以使用期限更长的自签名证书或 PKI 颁发的证书。如果未删除此默认自签名证书，则三年后，由它创建的 EFS 将在整个域内停止对新文件进行加密。这是因为证书已过期，如果 EFS 恢复策略中包含过期 DRA 证书的话，EFS 将会阻止对任何的数据进行加密。虽然在不具有恢复代理策略的情况也可以操作 Windows XP 及更高版本的系统，但是强烈建议不要如此。这样做就意味着，如果用户出于某种原因丢失了对其加密密钥的访问权限，而且不能恢复密钥的话，则该用户的所有数据将无法挽回。
正如之前所说，DRA 密钥可以是自签名，也可以由 CA 颁发。在大多数情况下，将二者混合使用最佳，在企业范围内使用至少两个长寿命的自签名 DRA 作为恢复代理的最后选项。由于 DRA 证书是通过组策略对象部署，因此具有与其他 GPO 相同的继承功能。换句话说，用于控制其他 GPO 设置应用程序的标准本机、站点、域、组织单位 (OU) GPO 累积和应用算法同样适用于 DRA。因此，对于 DRA，组织可以轻松地实现分层方法，中央 IT 组拥有访问企业每个部分的权限，但是本地 IT 组也保留了对其所负责特定区域的访问权限。这对于大型且地理位置分散的组织来说是一项极有助益的资产，因为它可缓解通过 WAN 链接进行大量加密数据传输的需要，有助于数据恢复。图 5 说明了一个典型的多层式 DRA 部署。
图 5 多层 DRA 部署
图 5 多层 DRA 部署
在这种情况下，Baton Rouge OU 中的用户将最终得到每个加密文件的六个 DRA：两个来自本地管理员，两个来自北美 IT 组，两个来自域级别。因此，如果用户丢失了对加密数据的访问权限，可以通过 Baton Rouge 中的本地 DRA 或北美 IT 组进行恢复。作为最后的备用，如果这四个 DRA 都不可用或都已丢失，也可以通过域级别的 DRA 恢复数据。无论哪个 DRA 执行恢复操作，其过程基本上相同。用户首先使数据对 DRA 可用。DRA 采取必要的步骤来确定请求是合法的，而且来自数据的真正所有者，这点非常重要。这一步完成后，DRA 将加载 DRA 证书，并解密（最好是重新加密）数据，然后将数据返回到最终用户。一些组织还选择执行本地恢复，DRA 将物理访问发生问题的用户，将其 DRA 密钥对加载到配置文件中，然后解密数据并删除该密钥对。之后，用户将以明文形式获取对数据的访问权限，并可以使用新的密钥重新进行加密。应该注意的是，此方法的安全性较低，因为 DRA 密钥对被复制到本地计算机上（即使是暂时的），但是这种方法可以节省时间，尤其是在必须恢复大量数据的情况下。
请注意，如果通过密钥的存档和恢复为用户提供恢复，则处理恢复请求的方法将完全不同于上述过程。完全不使用 DRA，用户的密钥恢复请求将转到 CA 管理员，管理员在检查请求之后，再转到存档中并检索用户的私钥。之后，他们让用户能够安全地使用此私钥，如将其放在一个安全的网站上，以供下载。（如果用户使用智能卡存储其 EFS 密钥，并且在 Windows Vista 上可用，那么该密钥也应该重新发布。）用户将此密钥加载到配置文件中，就可即时访问所有的加密数据。
由于 DRA 和 KRA 密钥对都可以用于解密敏感数据，因此，它们应受到适当的保护，这一点很重要。DRA 和 KRA 密钥对不应存储在管理员的常规桌面配置文件（即管理员为完成每天任务所要用到的配置文件）中。而是将这些密钥对安全地脱机存储到软盘、光盘或闪存等媒体，并将这些媒体保存在物理安全的位置。然后，在需要恢复时，恢复代理能够将密钥对从媒体加载到恢复工作站，执行恢复操作，最后删除密钥对。在某些安全性极其敏感的组织内，可指定专用的工作站进行恢复，以进一步提高这些密钥对的安全性，但不是所有组织都需如此。

下期内容
既然已对密钥管理、数据恢复和 Active Directory 方面的 EFS 规划进行了介绍，在该主题的第二部分中，我将着重说明客户端部署方面的问题，敬请关注。届时将涉及到诸如通过组策略控制 EFS 的使用、选择要加密的内容、通过登录脚本自动加密数据，以及改进 Windows Explorer 客户端以更简便地使用 EFS 保护的数据等方面的内容。

John Morello 以最优异的学业成绩毕业于 LSU，在 Microsoft 的六年工作期间担任过许多不同的职务。作为高级顾问，他曾经为财富 100 强企业以及联邦民用和国防客户设计安全性解决方案。目前，他是 Windows Server 组的项目经理，负责安全性和远程访问技术方面的工作。


 桌面文件: 扩展 Windows PE
桌面文件
扩展 Windows PE
Wes Miller

甚至在五年前我们还没有发布 Windows PE 的时候，就已经有心急的客户在要求更多的功能了。遗憾的是，Windows PE 不像 Windows XP Embedded 那样能够通过在操作系统的附加层中添加更多的功能轻松地进行扩展。当然，Windows PE 必须具有基本的
Win32® 支持（从而可以运行大多数 Windows® 应用程序）以及网络连接和大容量存储支持（以通过网络进行通信并能够安装 Windows）。但是甚至从一开始我们就想要限制使用外壳；由于使用了 cmd.exe 而不是传统的 Windows Explorer 外壳，我们限制了 Windows PE 环境的功能范围，但更重要的是，我们可以在默认环境下针对所有自动化任务轻松地进行脚本化。
您仍然可以扩展 Windows PE — 只是您必须记住的是它受到了限制。您可以预计如果您的应用程序需要图 1 中列出的任何技术（此列表并不全面），它就可能无法运行或可能出现错误的行为。
Figure 1 缺少的 Windows API (Close Figure 1)

.NET Framework（任何版本）
Active Directory® Services Interfaces (ADSI)
DirectX®
Microsoft 数据访问组件 (MDAC)
Jet (Access)
Visual Basic®（包括 .NET 之前的版本）
需要不使用 Windows 进行本机安装的框架的任何可执行文件类型。
Windows 资源管理器或 Internet Explorer
Windows Media® Player
SAPI、MAPI、TAPI（分别为 Windows Speech、Mail、Telephony 的 API）
如果您不知道您的应用程序依赖什么，就需要查明。不过，该如何查明呢？当我们尝试在发布 Windows PE 之前获取在 Windows PE 下运行的 ADO、HTML Applications (HTA) 和 Windows Script Host (WSH) 组件时，我们面临着相同的问题。不过，应当注意，虽然本文将介绍追踪这些依赖项的方法，但是最终用户许可协议 (EULA) 并不涵盖将 MKIMG 命令所包含的 Windows 二进制文件之外的任何二进制文件添加到 Windows PE 映像。为了在您的环境中进行实质性的更改，您将需要从 Microsoft 获得许可附录。

了解依赖项
如果您在记事本中打开应用程序的 .inf 文件并对其进行仔细检查，就会了解到大量的信息。实际上，通常这是搞清楚某应用程序并查看其所具有的依赖项的最容易的方法。要了解 Windows PE，重要的在于了解通常它的简化程度极高，因此您必须调试多个级别的依赖项 — 应用程序自身的直接依赖项和那些直接依赖项中的每个依赖项可能引入的依赖项 — 以便使应用程序能够可靠地运行。其实，如果您不小心，就可能会发生相当大的依赖项层叠。通过一些意外（或有意）的组件添加，您的映像会在大小和复杂性方面显著增长。
如果您有用于介绍该应用程序的 .inf 文件，就可以通过查找 .inf 添加到系统的注册表项和文件来获得有关依赖项的线索。查找 CopyFiles 部分和 AddReg 部分。这些条目将指向应用程序、DLL 和应用程序所依赖的其他文件。在 Windows PE 的三个加载项（ADO、HTA 和 WSH）中，创建方法最简单的是 WSH。因为 WSH 的可再发行版本仍可用于 Windows 的早期版本，并且因为在现在的 Windows 中内置了一个执行针对 WSH 的文件关联的 .inf 文件（位于 %windir%\inf\wsh.inf），所以将其安装到 Windows PE 中就相对容易。

Orca 和快照
如果所讨论的应用程序作为 Microsoft® 安装程序 (MSI) 文件分发，您可以做两件事来查找依赖项。如果您是一位 MSI 权威，您就可以使用 Orca（一种用于编辑 Windows 安装程序文件的工具，该工具作为 Windows Server® 2003 R2 Platform SDK 的一部分分发：go.microsoft.com/fwlink/?LinkId=77941）进行查看。您还可以为您想要的组件安装 MSI，从而对已发生变化的文件和注册表项执行前后对比分析。您可以转储注册表，安装应用程序，再次导出注册表，然后针对注册表运行 WinDiff [请参阅“Using WinDiff”（使用 WinDiff）边栏]。接着可以将运行结果用作更改的模板（需要对注册表进行这些更改）。问题在于可以虚构更改的数量。不过，如果您手边没有 .inf（或应用程序的作者），那么它可能是最佳选项。
您可能很熟悉应用程序快照的过程。其实，它就是为了运行应用程序而执行的同一前后对比分析。Microsoft 以前分发过（随 Windows 2000）执行此操作的工具，但该工具不能与任何更新版本的 Windows 协同工作。许多商业应用程序（安装重新打包程序）可以执行此操作，但一些免费的实用工具也可以执行此操作。针对一个解决方案，安装 Platform SDK（请参阅前一段中的链接），其中包括 WinDiff。请注意，要执行 WinDiff 比较，理想情况下，您要在 Windows Server 2003、Service Pack 1 (SP1) 上安装该应用程序，因为该版本正是您应该使用的 Windows PE 版本 — Windows PE 1.6 作为 Standard Edition 或 Enterprise Edition (with SP1) 的内部版本。在 Windows Server 2003 上执行此任务，您将使此环境与在 Windows PE 上运行时的环境最为接近（很明显，您无法在 Windows PE 上执行 MSI）。遵循“Using WinDiff”（使用 WinDiff）边栏中的步骤。
此边栏将向您显示大量已更改的信息。遗憾的是，并没有一种简单的方法来从注册表或文件捕获中导出已更改的信息，从而创建某些类型的指令清单以安装应用程序。您需要手动合并这些更改。这正是我们使用第一版 Windows PE 时遇到某些最困难的问题的地方。使 HTA 组件处理所有问题很复杂，因为在 Microsoft 内部并没有对这些组件进行定义（在 Internet Explorer® 之外）。通过使用差分化，我们能够手动接合足够的 HTA 支持，以便其能够起作用。虽然可以将这些注册表项手动添加到 Windows PE 注册表，但您可能想要在 Windows PE 启动后再添加这些注册表项。您可以通过 Windows PE 构建工具中包括的 buildoptionalcomponents.vbs 脚本来查看用于将 HTA、WSH 和/或 ADO 支持安装到 Windows PE 的 OC.bat 文件和 OC2.bat 文件。

有用的工具
甚至在隔离了直接依赖项后，您通常也无法找到应用程序所依赖的每个二进制文件。例如，您不会知道是否需要另一个 DLL 或 OCX 才能执行某些任务。那么，如何进行分辨？Sysinternals fame 的 Mark Russinovich（现在是 Microsoft 的一位技术人员）编写的一个称为 listdlls 的小巧实用工具所做的正是这件事情。可从 microsoft.com/technet/sysinternals/utilities/ListDlls.mspx 下载 Listdlls。要使用此实用工具，请运行命令 listdlls.exe > dlls.txt，然后检查输出。图 2 显示了 listdlls 在其自身上运行的输出信息。可以将此列表同 Windows PE 中包含的 DLL 文件和 OCX 文件进行比较，以确定应用程序的所有依赖项是否具备（就 listdlls 而言，所有依赖项都已显示）。对于 Windows PE 中的 HTA 支持，listdlls 对于识别某些依赖项很关键（否则无法识别）。
图 2 Lisdlls 在其自身上运行的输出
图 2 Lisdlls 在其自身上运行的输出
但是仅因为列出了 DLL，并不一定意味着应用程序需要该 DLL 才会起作用。例如，如果您加载了记事本，您就将看到它加载 uxtheme.dll。在 Windows PE 下，此 DLL 不可用，并且实际上，由于没有使用 Windows 主题，也就将永远不会加载 uxtheme.dll。确实必须了解 listdlls 向您显示 DLL 中哪些是您实际需要的以及哪些是 Windows 按需加载的，遗憾的是，这是一种不公开的技术，您将需要大量的试验和错误或者您变得非常熟悉 Windows 的低层方面（为此，我建议阅读 Mark Russinovich 和 David Solomon 合著的书《Microsoft Windows Internals, Fourth Editio》[Microsoft Windows 内核（第四版）] (Microsoft Press®, 2004）。
实际上，Mark 还在取代 Windows 任务管理器免费的 Process Explorer 中包含了相同的功能。区别在于，listdlls 创建的输出（在我看来）更易于编写脚本和用于查找和收集缺少的依赖项。
请注意，甚至在您将一个 DLL 添加到映像中之后，您可能仍然要做一些工作。就是说，有两种类型的 DLL：需要注册的 DLL 和不需要注册的 DLL。遗憾的是，除了试图注册每一个 DLL 以外，并没有能够轻松的将它们区别开来的方法。为了注册 DLL（或 OCX），请运行 regsvr32 dllname.dll。如果它能正确运行，您将收到一个对话框，告诉您注册了该 DLL。如果它不能正确运行，您可能收不到消息或更有可能的是，您将看到一个对话框，通知您该 DLL 注册失败或无法注册。在开发用于 Windows PE 的 HTA 和 ADO 可选组件时，我们发现 DLL 在执行其注册时需要可写存储器，以临时写入用于安装的 .inf 文件或记录某些其他的依赖项（比如，他们所必需的特定目录）。在 Windows PE 中，这在以前就意味着失败。谢天谢地，使用 Windows PE 2.0，由于默认情况下可以使用暂存空间，与这些相类似的任务将恰好起作用。
Mark 创建并于最近发布的第三个工具称为 Process Monitor。可以将 Process Monitor 看作 Regmon 和 Filemon 的一个超集，它提供的细节仍明显多于 Regmon 和 Filemon 提供的细节，同时添加了一个全新的进程间通信层。这个功能非常强大的工具会帮助您排除 Windows 中应用程序的故障，并帮助您回答有关 DLL 相互依赖关系到底发生了什么的问题。可以下载 Process Monitor。

删除 Windows PE 文件
除了能够向 Windows PE 添加内容，另一个常见的请求是就如何使 Windows PE 变小进行指导。您可以采取几个步骤将 Windows PE 的大小减小一点。已获得许可的 Windows PE 应该包括构建工具的集合和一些文档。其中的一个文档是名为 winpe.chm 的一个帮助文件。如果您打开此文件并浏览“Windows Preinstallation Environment User’s Guide”（Windows 预安装环境用户指南）部分，就会看到一个标题为“Reducing the Size of Windows PE”（减小 Windows PE 的大小）的主题。此部分列出可以安全删除的文件的集合（假定您不需要这些文件）。您将发现与可删除文件相关的三个部分：
  • 始终可以安全删除字体文件。
  • 虽然可以删除与网络连接相关的 .inf 文件和实用工具，但仅限在您根本不打算在网络上使用内部版本时方可如此。
  • 不应该删除命令行实用工具。建议不要删除这些命令行实用工具中的任何一个，除非您明确了解该实用工具的用处以及如果将其删除可能会发生什么。
决定了可以安全地排除哪些文件后，您就可以直接编写批处理文件或其他脚本，并在 mkimg.cmd 完成内部版本后将它们从 Windows PE 内部版本中删除。

修改 Windows PE 注册表
您可以设法使我们在构建时有意不安装那些可选组件。尽管这意味着运行时间会稍长，但也意味着我们不必设计一个全新的方法来将这些组件接合回 Windows PE — 我们没有时间这样做，并且这也很可能意味着将完全忽略这些组件。但是，如果您想要更改注册表（如为应用程序添加注册表更改的变化量）或只是想要编辑某个可能会保持应用程序运行的注册表项，该怎么办？使用图 3 中显示的 regedit 就可以很容易地完成此任务。请遵循以下的步骤：
  1. 运行 regedit 并选择 HKEY_LOCAL_MACHINE 配置单元。
  2. 选择“File”（文件）|“Load Hive”（加载配置单元），然后浏览到 Windows PE 内部版本的位置。在 I386\System32\（或者如果这是放置在硬盘驱动器上的映像，则在 MiniNT\System32 下选择 setupreg.hiv。
  3. 输入配置单元的临时名称（如 WinPE），然后在 HKLM 下浏览到该节点。
  4. 相应地修改此注册表项。有趣的是，请注意，此节点在效用上与将在正常 Windows 安装中出现的节点 HKLM\System 相同。
  5. 做出修改后，请在 HKLM 下选择您在步骤 3 中创建的注册表项（正确地执行这一操作很重要，否则将损害您的系统）。
  6. 选择“File”（文件）|“Unload Hive...”（卸载配置单元...），并确认“Yes”（是）|“No”（否）对话框，并且由于锁定此注册表将阻止 Windows PE 的成功构建，因此要确保每次都卸除该注册表。
图 3 打开 Windows PE 注册表
图 3 打开 Windows PE 注册表
遵循以下的步骤就可以修改 HKLM\System。在 I386\System32 下还有另两个可用来修改注册表其他区域的注册表项：DEFAULT 和 SOFTWARE，前者是用户的默认配置单元（甚至在您使用 Windows PE 时会以 SYSTEM 身份运行），而后者与 HKLM\Software 相同。通常在修改注册表时要多加小心并仅在需要时进行修改。
现在可以利用一些方法帮助您开始将喜爱的故障排除或恢复工具迁移到 Windows PE 上。下个月，我将讨论 PSTools 套件 — 这还是由 Mark Russinovich 编写的非常有用的系统管理工具的集合。
使用 WinDiff
WinDiff 可以帮助您查找应用程序的依赖项。只需遵循以下步骤就可以成功地进行安装和执行：
  1. 使系统做好安装准备 — 您要将安装时间降至最低并最小化初始快照和最终快照之间的任何文件或注册表更改。
  2. 打开命令提示符并运行 reg export HKLM C:\HKLM1.reg 以完全导出 HKEY_Local_Machine 注册表配置单元。
  3. 运行 dir C:\*.* /S > C:\C1.txt 以完全转储 C: 驱动器（假定 C: 为您的系统驱动器）上的所有文件。
  4. 安装应用程序并配置任何安装后设置。
  5. 运行 reg export HKLM C:\HKLM2.reg。
  6. 运行 dir C:\*.* /S > C:\C2.txt。
  7. 打开 WinDiff，选择“File”（文件）|“Compare Files...”（比较文件...），然后在第一个“File Open”（文件打开）对话框中选择 HKLM1.reg，并在第二个“File Open”（文件打开）对话框中选择 HKLM2.reg。
  8. 您会看到显示为红色的消息，这表明该消息是更新的消息。别急；由于 HKLM 导出文件可能会很大，这可能会花上一点时间。
  9. 双击红色的文本以扩展这些差异。
  10. 您可能想要通过选中“Options”（选项）|“Show Right-Only Lines”（仅显示右边文件中的行）来配置在比较中显示的内容。此操作将只显示在第二个比较文件中新添加的行（因此将仅显示新文件和新注册表项）。
请注意，您可能需要使用 Find 函数来找到与应用程序相关的注册表项。在图 A 和图 B 中，您可以看到我所创建的虚构应用程序的文件和注册表更改。令人高兴的是，在 WinDiff 中可以使用复制和粘贴操作。要使用这些功能，只需单击 !> 行并选择所需的行即可。
图 A WinDiff 条目
图 A WinDiff 条目
图 B WinDiff 中的特定注册表项
图 B WinDiff 中的特定注册表项

Wes Miller 是德克萨斯州奥斯汀市 Pluck 公司 (www.pluck.com) 的一位开发经理。在这之前，Wes 在位于奥斯汀市的 Winternals Software 公司任职，并曾在微软担任 Windows 程序经理和产品经理。Wes 的联系方式如下：technet@getwired.com。


 现场注意事项: 它只是停止工作
现场注意事项
它只是停止工作
R'ykandar Korra'ti

“我不知道， 我只是不再做了而已。”
“每天的任何时候吗？当这个发生时，您正在做什么特定的工作吗？您连接着什么特定的计算机吗？”
“事实并非如此。一开始是，后来就不是了。哦！没有。”
“你知道，这些信息还不够。拜托，透露一点。一个暗示、一个线索，什么都可以。”
“我已经把我所了解的全部告诉你了。有时我也懵了。你能解决吗？”
我告诉她我来解决。路由器日志中未提供太多信息，但是，偶尔流量确实是下降了，这说明已经出现问题了，但每次仅仅是一两分钟的时间，之后就又恢复正常了。没有错误、没有模式，仅是经常出现没有流量的情况。太奇怪了。然后，幸运之神眷顾了我们：
Ring Ring 是附加到 DSL 的电话。
Thunk Die 是 IP 连接。
我想，你在跟我开玩笑吧，可是，它又重复强调：如果有人呼叫 DSL 电话号码，而这个号码又是一个没人使用更没人去理会的电话号码，我们的连接就完了。电话公司声称您永远不必担心会有重大事故出现,这是它最引以为豪的服务卖点,但突然间,灾难从天而降。
可是，我们距离变电所只有 900 英尺。这根本就不可能发生。我检查了电缆，重新设置了一切，甚至清理了连接，看看这些是否有帮助。当然，还是没起作用。因此我将打电话到电话公司。“您知道您的员工是如何承诺的吗？他们说，连接永远不会因为打入电话而中断。”看看都发生什么了？我们可能被电话推广员愚弄了。”
可能是铜......
第二天,一个技术团队来查找问题根源,令人难以置信的是,他们是在离变电所 3,000 英尺之外的地方进行测试，在这么远的距离上,一个捣蛋鬼使用小型罗盘磁体就能切断我们的通信。最终，我们发现当我们的邻居接线时，中断又发生了，所有电话线都被绑到一起，而且每根电话线被接到这一街区的每幢建筑上，这样做曾经可以避免运行新电缆。如果整个世界是模拟语音，这样做固然很好，但从 DSL 角度来看，这些分支的每线性英寸都是从变电所开始算起的距离，距离越远，信号强度越弱。
高兴的是，问题已经既快速又轻松地解决了。电话线上的所有侧分支都已断开，并在上面加了一条标语“不要重新连接。DSL 部分正在使用。”没错！仅 900 英尺的距离，强度更大的信号，最重要的是打电话时，没有载波损失。
故事所传达的道理是：不要假设连接问题非常深奥或甚至是由软件所致。有时，问题就出现在铜身上。一定要让电话公司的员工在安装时检查实际的 DSL 信号强度，即使他们保证不必如此；因为您永远也不会知道可能还存在什么问题，仅能到出问题时才头痛。而且，不要相信他们与至变电所的距离有关的片面之词。您不知道那些电线接到何处，他们也不知道。那就找吧。他们有工具；他们有技术，可以让他们利用这些工具和技术。您这样做会感到非常愉快。尤其是在电话推广员找到您的 DSL 号码时。

R'ykandar Korra'ti 是一家小型合作 ISP 的邮局主管，同她的合作伙伴 Annag 一起住在西雅图附近。以前在 Microsoft 寄运邮件产品，现在正在查看某领域的毕业生学校，如此秘密以至于真的没有一个名字。潜在的教师顾问可以通过 darako@murkworks.net 与她联系。


 Windows 机密: 祸福参半
Windows 机密
祸福参半
Raymond Chen

插入 CD 或 DVD 时 ，外壳将“探查”磁盘以确定磁盘上驻留着什么类型的内容。接着，此确定将引导外壳就其应该执行哪种自动播放操作做出决定。关于探查的执行情况的准确的详细信息并没有被记录，这是因为它们是试探性方法，如果在将来找到了更好的算法，则可以更改。
正式记录算法将使其成为合同，从而阻止在随后的发布中对算法进行调整。因此，正式的做法是，将算法的详细信息保留为未指定状态。
如果您从未为 SDK 编写过文档，您可能就不曾意识到文档会产生合同。一旦您依据的是以某种方式行为的记录，就无法改变它。如果您改变它，依赖这种行为的人就会说，“嗨，文档上没这么说。游戏已经开始了，您竟然要更改规则。”
由于那个不显眼的警告，下面将以快速且惊人地过度简化的方式来介绍如何使用 Windows® XP Service Pack 2 (SP2) 分类缺少 autorun.inf 文件的数据 CD 和数据 DVD 的内容。（将来的服务包和将来的 Windows 版本可能有不同的行为。）我说“惊人地过度简化”是因为实际的算法是一个 61 步决策表，它考虑了各种信息（如前台应用程序是否响应过“Query cancel autoplay”（查询取消自动播放）通知，全屏程序是否正在运行，甚至还有计算机是不是最近插接或移除的便携式计算机）。但是我只想了解内容探查步骤。
首先，外壳将检查用户是否已将“Take no action”（不采取任何措施）指定为适用于所有内容类型的操作。如果已指定，则探查将毫无意义。决策只是“Take no action”（不采取任何措施）。
如果未指定，则外壳将做一些工作。它将查看磁盘上的每个文件（多达 4 个目录深）并根据所察觉的类型将这些文件放入以下的类别之一：图像、音乐、电影。
不适用于这些类别中任何一个的文件将被忽略。如果检查过的所有文件只表示了一个类别（比方说，例如，磁盘上的所有文件都是音乐文件），那么就以该类别来建立磁盘类型。如果表示了三个类别中的多个，那么磁盘就被认定为混合内容。
这意味着，您的装满音乐文件的 CD 上的唱片集画面会导致 CD 被 Windows XP SP2 作为混合内容处理。这是可能经受某种调整的那些内容之一。但是假设此算法经过了调整，而且我们确定，在装满 MP3 的 CD 上偶尔有一幅图片不会将天平倾向混合内容。一些公司的 CD 上可能有大量的音频文件和少数图片。这家公司（的确）依赖的就是检测为混合内容的 CD。但是当算法发生变化后，CD 会被误分类为音乐。现在那家公司很烦恼。但是这个问题该怪谁呢？可以怪公司依赖探查算法的详细信息吗？或者怪 Windows，因为它要为更改算法负责？
您瞧，在 Windows Vista™ 中，算法已经做出了更改（尽管只是略有更改）。在 Windows Vista 中，为了缩短某些著名的磁盘布局的算法，会预先进行若干检查。例如，如果磁盘的根目录中存在一个 DCIM 文件夹，那么就假定该文件夹由数字图片组成。现在我们将拭目以待，看看是否有人注意到这些。

Raymond Chen 的网站 The Old New Thing（英文）和他的与网站同名的书 (Addison-Wesley, 2007) 介绍的是 Windows 历史和 Win32 编程。Raymond 想了解这个世界。