 TechNet Magazine April 2007

TechNet Magazine April 2007

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

在本期中，我们将深入探讨 Windows Vista 内核中的新功能。在此最终安装版本中，我们将着眼于有关可靠性、可恢复性和安全性的更改和新功能。

Mark Russinovich Windows 管理: 灾难恢复：Active Directory 用户和组

Active Directory 中的数据恢复可能非常复杂，因此制订良好的恢复计划非常重要。我们将向您展示 Active Directory 如何存储、删除、还原和复制对象，以便在下一次某个用户或组成员被意外删除时您能有所准备。

Gil Kirkpatrick Windows 管理: 为什么说 Windows XP Embedded 与您息息相关

虽然您可能还不了解 Windows XP Embedded，但它确实非常适合贵组织的 IT 阵营。通过以下内容，您可了解 Windows XP Embedded 如何降低管理开销，如何节约资金以及改善安全性。

Don Jones 管理: 使用 System Center Capacity Planner 提前进行规划

硬件不足会导致响应缓慢，而硬件太多则会浪费预算和管理资源。学习如何使用 System Center Capacity Planner 建模网络并准确评估基础结构需求。

John Savill 管理: 使用 SMS 的高级客户端清单

虽然现成的 Microsoft Systems Management Server 2003 就能够收集许多信息，但它还不能收集您可能需要的那么多信息。了解脚本、WMI 和 SMS 知识的正确组合如何帮助您扩展 SMS 清单，从而收集和报告几乎所有详细信息。

Wes Dobry 管理: 采用 SMS 2003 R2 部署自定义软件更新

Systems Management Server 2003 R2 使您可以使用管理更新功能部署自定义更新。探索两种新工具 — 自定义更新清单工具和自定义更新发布工具，了解它们如何帮助您部署您自己的更新以及来自第三方开发人员的更新。

Steve Rachui 编辑视角: 我们也可能出错……

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

Greg Steen SQL 问题与解答: 重新生成索引、磁盘队列长度和更多内容

Edited by Nancy Michell 实用工具特别推荐: Autoruns

系统启动时大量自动运行的应用程序是令人无限头痛的根源。但是通过 Autoruns，您可以调查每个自动运行的应用程序，从而可以排除冲突故障，跟踪恶意软件以及释放系统资源。

Lance Whitney 网络专家: Windows Vista 无线组策略设置

看看在 Active Directory 网络内，如何使用组策略对所有计算机进行集中配置并分发无线网络设置。

Joseph Davies Windows PowerShell: 数据的筛选与格式化

通过 Windows PowerShell，可轻松访问众多的数据。但在其原始状态下，该数据还不具备典型的业务用途。学习如何通过筛选、指定属性和应用格式化操作来自定义您收集的数据。

Don Jones 您好，脚本专家！: 本地用户和组的不成熟解决方案

看起来好像每个人都会问这些问题。现在脚本专家（最终）向您展示如何使用脚本来管理本地用户和组。

The Microsoft Scripting Guys 安全观察: 安全配置向导

安全配置向导可提供有效的方式，用以保证遍布于不同地理位置成千上万台服务器的安全。基于服务器所承担的不同角色，您需要了解此处提及的所有细节，来加强您的服务器并减少服务器的受攻击面。

John Morello 桌面文件: 我的 x64 经历

看一看在 x64 系统上实施的 Windows XP 和 Windows Server 2003，检查一下您可能遇到的一些部署优势和障碍。然后熟悉一下 Windows Vista x64 的支持、迁移和部署事宜。

Wes Miller Microsoft.com 技术内幕: 使用 Active Directory 联合身份验证服务

Microsoft 为其业务伙伴提供外联网，该外联网要求每个外部用户都拥有唯一的域账户。了解 Microsoft 如何规划使用 Active Directory 联合身份验证服务，在简化管理工作的同时来获得更佳的用户体验。

Jim Guthrie 现场注意事项: 学习中的乐趣（和痛苦）

当成为一名先行采纳者的喜悦渐渐褪去时，请记住，“知识”使技术变得简单易用和易于支持。作为 IT 专业人员,我们需要站出来研发新产品。您可能会惊讶于您的发现。

Mark D. Scott Windows 机密: 错误的力量

您为什么要打开一个错误呢？在 OS 中一些应用程序实际上是依赖于错误的。当修复了错误以后，应用程序也就不能用了。

Raymond Chen


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

了解 Windows Vista 内核：第三部分
概览:
  • 可靠性
  • 可恢复性
  • 安全性

到目前为止，该系列文章涵盖了有关进程、I/O、内存管理、系统启动、关闭和电源管理方面的 Windows Vista 内核增强功能。在此第三版暨最终版
安装中，我会着眼于可靠性、可恢复性和安全性方面的功能和改进。
本系列中没有涉及的功能之一是用户帐户控制 (UAC)，它由几种不同的技术组成，包括文件系统和注册表虚拟化（用于传统应用程序）、访问管理权限的提升同意及 Windows® 完整性级别机制（用于从相同帐户中隔离较低权限运行的进程与使用管理权限运行的进程）。请在以后发行的 TechNet 杂志中查阅我对 UAC 内部信息的深入探讨。
Windows Vista™ 通过许多新功能和改进提高了系统的可靠性和您对系统与应用程序问题的诊断能力。例如，内核 Windows 事件跟踪 (ETW) 记录程序总是处于运行状态，能够生成有关文件、注册表、中断以及其他活动类型的跟踪事件，并保存在循环缓冲区中。当出现问题时，新的 Windows 诊断基础结构 (WDI) 会捕获缓冲区快照，并进行本地分析或上载到 Microsoft 支持进行故障排除。
新的 Windows 性能和稳定性监视器可以帮助用户通过更改系统配置将错误（如崩溃和挂起）相互关联。强大的系统修复工具 (SRT) 取代了故障恢复控制台，用于不可启动系统的离线恢复。
有三个方面依靠对系统进行的内核级更改，即需要您认真阅读的本文中的以下方面：内核事务管理器 (KTM)、改进的崩溃处理和以前的版本。

内核事务管理器
软件开发中最繁琐的一个方面就是处理错误条件。特别是在进行高级操作的过程中，应用程序完成了一个或多个导致文件系统或注册表更改的子任务。例如，应用程序的软件更新服务可能要进行几次注册表更新，替换应用程序的可执行文件之一，而在它尝试更新第二个可执行文件时被拒绝访问。如果服务不想将应用程序留在因此导致的不一致状态，就必须跟踪所有更改并为撤销它们做好准备。测试错误恢复代码很困难，并经常跳过，因此恢复代码中的错误会让努力徒劳无功。
为 Windows Vista 编写的应用程序通过使用 NTFS 中新的事务支持和使用内核事务管理器的注册表，不费吹灰之力即可获得自动错误恢复能力。当应用程序想进行许多相关更改时，可以创建分布式事务处理协调器 (DTC) 事务和 KTM 事务处理，或直接创建 KTM 处理，并将对文件和注册表项的修改与事务关联起来。如果所有的更改成功，应用程序会提交事务同时更改生效，但是在此之前任何时候，应用程序可以回滚事务，然后放弃更改。
其有利因素在于，其他应用程序在提交事务后才能看到事务中的更改，而在 Windows Vista 和即将问世的 Windows Server®（代码名为“Longhorn”）中使用 DTC 的应用程序会通过 SQL Server™、Microsoft® Message Queue Server (MSMQ) 以及其他数据库协调其事务。因此，使用 KTM 事务的应用程序更新服务永远不会将应用程序留在不一致的状态。这就是 Windows Update 和系统还原使用事务的原因。
作为事务支持的核心，KTM 允许事务资源管理器（如 NTFS 和注册表）对应用程序所做的特定更改协调其更新。在 Windows Vista 中，NTFS 使用称为 TxF 的扩展来支持事务。注册表使用称为 TxR 的类似扩展。这些内核模式资源管理器与 KTM 一起协调事务状态，正如用户模式资源管理器使用 DTC 跨多用户模式资源管理器协调事务状态一样。第三方也可以使用 KTM 实施其自己的资源管理器。
TxF 和 TxR 都定义了一套新的文件系统和注册表 API（与现有的类似，只不过它们包含事务参数）。如果应用程序想在事务中创建文件，首先要使用 KTM 创建事务，然后将引起的事务处理传递给新文件创建 API。
TxF 和 TxR 都依赖在 Windows Server 2003 R2 中引入的公用日志文件系统或 CLFS (%SystemRoot%\System32\Clfs.sys) 的高速文件系统记录功能。TxR 和 TxF 使用 CLFS 永久性地存储提交事务之前的事务状态更改。这样可以让它们提供事务恢复并确保即使在断电时也可以恢复。除了 CLFS 日志，TxR 还创建了一组相关的日志文件，跟踪 %Systemroot%\System32\Config\Txr 中系统注册表文件的事务更改（如图 1 所示），同时还为每个用户注册表配置单元单独创建几组日志文件。TxF 在名为 \$Extend\$RmMetadata 的卷的隐藏目录中存储每个卷的事务数据。
图 1 系统注册表配置单元 TxR 记录文件
图 1 系统注册表配置单元 TxR 记录文件

增强的崩溃支持
当 Windows 遇到不可恢复的内核模式错误时（无论是由于设备驱动程序错误、硬件故障还是操作系统问题），在出现“蓝屏死机”现象和将物理内存的部分或所有内容写入崩溃转储文件（如果配置为执行此操作）后，它会尝试终止系统来防止磁盘数据的损坏。转储文件非常有用，因为当您在系统崩溃后重启时，Microsoft 在线崩溃分析 (OCA) 服务会分析这些文件找出根本原因。如果愿意，您也可以使用面向 Windows 的 Microsoft 调试工具自已进行分析。
不过，在以前的 Windows 版本中，只有在会话管理器 (%Systemroot%\System32\Smss.exe) 进程初始化分页文件后才会启用对崩溃转储文件的支持。这意味着在此之前任何严重错误会导致蓝屏，但没有转储文件。由于在 Smss.exe 启动之前，会出现大量的设备驱动程序初始化，所以早期的崩溃永远不会引起崩溃转储，因此使原因诊断极为困难。
在所有引导启动设备驱动程序初始化之后，但在系统启动驱动程序加载之前，Windows Vista 通过初始化转储文件支持，可减少无转储文件生成的时间窗口。由于这一更改，如果在引导过程开始时出现崩溃，系统就可以捕捉崩溃转储，让 OCA 帮助您解决问题。此外，Windows Vista 使用 64KB 块将数据存储到转储文件中，而以前的 Windows 版本使用 4KB 块写入文件。这一更改使得大型转储文件的写入速度最多可提高 10 倍。
应用程序崩溃处理功能在 Windows Vista 中也得以改进。在以前的 Windows 版本中，当应用程序崩溃时，它会执行未处理的异常处理程序。处理程序启动 Microsoft 应用程序错误报告 (AER) 进程 (%Systemroot%\System32\Dwwin.exe)，显示对话框，指明程序崩溃，并询问您是否要向 Microsoft 发送错误报告。不过，如果崩溃时进程主线程的堆栈损坏，未处理的异常处理程序执行时会崩溃，导致内核终止进程、程序窗口立即消失，并且没有错误报告窗口。
Windows Vista 将错误处理从崩溃进程的上下文移至新服务，即 Windows 错误报告 (WER)。此服务由服务托管进程中的 DLL (%Systemroot%\System32\Wersvc.dll) 实施。在应用程序崩溃时，它仍然会执行未处理的异常处理程序，但是该处理程序会向 WER 服务发送消息，并且服务会启动 WER 错误报告进程 (%Systemroot%\System32\Werfault.exe) 以显示错误报告对话框。如果堆栈损坏并且未处理的异常处理程序崩溃，处理程序会再次执行并且再次崩溃，最终消耗所有线程的堆栈（使用内存区域），此时内核会介入，并向服务发送崩溃通知消息。
在图 2 和图 3 中，您可以看到这两种方法的对比，这两幅图表明在 Windows XP 和 Windows Vista 中 Accvio.exe（崩溃的测试程序）的进程关系，并以绿色突出显示错误报告进程。新的 Windows Vista 错误处理体系结构意味着在未尝试向 Microsoft 提供获得错误报告的情况下，程序不会再在无提示的情况下终止，这有助于软件开发人员不断改进其应用程序。
图 2a Windows XP 中的应用程序错误处理
图 2a Windows XP 中的应用程序错误处理
图 2b
图 3a Windows Vista 中的应用程序错误处理
图 3a Windows Vista 中的应用程序错误处理
图 3b

卷影复制
Windows XP 引入了一种称为卷影复制的技术，可生成磁盘卷的时间点快照。备份应用程序可以使用这些快照生成一致的备份映像，但是快照却被从视图中隐藏，并仅保持备份过程所持续的时间。
快照实际上并不是卷的完整副本。更确切地讲，它们是较早还原点的卷视图，由与卷扇区副本（在生成快照后已更改）重叠的活动卷数据组成。卷快照提供程序的驱动程序 (%Systemroot\%System32\Drivers\Volsnap.sys) 监视针对卷的操作，备份扇区副本后才允许扇区更改，将与快照相关的文件中的原始数据存储到卷的 System Volume Information 目录中。
Windows Server 2003 使用其共享文件夹的影副本对服务器上的管理员和客户端系统上的用户公开快照管理。此功能启用了持续快照，用户可通过 Explorer 属性对话框中的“以前的版本”选项卡访问它，因为其文件夹和文件位于服务器的文件共享部分。
Windows Vista“以前的版本”功能为所有客户端系统提供了此支持，即自动创建卷快照（通常每天一次），您可以通过使用共享文件夹影副本所用的相同界面的 Explorer 属性对话框访问快照。这样可让您查看、还原或复制您可能意外修改或删除的文件和目录的旧版本。虽然从技术角度来讲这并不是新技术，但 Windows Vista“以前的版本”实施的卷影复制优化了 Windows Server 2003 在客户端桌面环境中使用的功能。
Windows Vista 还充分利用了卷快照，以统一用户和系统数据保护机制，避免保存冗余的备份数据。当应用程序安装或配置更改造成错误或不合需要的行为时，您可以使用“系统还原”（在 Windows NT® 系列的操作系统 Windows XP 中引入的一项功能）将系统文件和数据还原成创建还原点时其存在的状态。
在 Windows XP 中，“系统还原”使用文件系统过滤器驱动程序（可以看到在文件级别的更改的一种驱动程序类型）在系统文件更改时备份其副本。在 Windows Vista 中，“系统还原”使用卷快照。当您在 Windows Vista 中使用“系统还原”用户界面返回到还原点时，您实际上是从与活动卷的还原点关联的快照复制已修改的系统文件的较早版本。

BitLocker
Windows Vista 是迄今为止最安全的 Windows 版本。除了包含 Windows Defender 反间谍软件引擎外，Windows Vista 还引入了大量的安全和纵深防御功能，包括 BitLocker™ 整卷加密功能、内核模式代码的代码签名、受保护的进程、地址空间加载随机化以及对 Windows 服务安全和用户帐户控制的改进。
操作系统在运行时只能增强其安全策略，因此当系统的物理安全可能受到危害和从操作系统之外访问数据时，您必须采取其他措施保护数据。诸如 BIOS 密码和加密的基于硬件的机制，是通常用来防止未经授权进行访问的两种技术，尤其是便携式计算机，最有可能丢失或被盗。
Windows 2000 引入了加密文件系统 (EFS)，并且在其 Windows Vista 体现中，EFS 包括了对以前实施功能的许多改进，包括性能改进、支持分页文件的加密和在智能卡上存储用户 EFS 密钥。不过，您无法使用 EFS 保护对系统敏感区域的访问，如注册表配置单元文件。例如，如果组策略允许您登录到便携式计算机（甚至在没有连接到域时），您的域凭据验证程序会在注册表中缓存，因此攻击者可以使用工具获取您的域帐户密码哈希，并用来尝试使用密码破解程序获取您的密码。密码会让他们有权访问您的帐户和 EFS 文件（假设您没有把 EFS 密钥存储在智能卡上）。
为了易于加密整个引导卷（包含 Windows 目录的卷），包括其所有系统文件和数据，Windows Vista 引入了整卷加密功能，称为 Windows BitLocker 驱动器加密。与由 NTFS 文件系统驱动程序实施并在文件级别操作的 EFS 不同，BitLocker 在卷级别使用整卷加密 (FVE) 驱动程序 (%Systemroot%\System32\Drivers\Fvevol.sys) 进行加密，如图 4 中图解所示。
图 4 BitLocker FVE 过滤器驱动程序
图 4 BitLocker FVE 过滤器驱动程序
FVE 是过滤器驱动程序，因此它会自动查看 NTFS 发送到卷的所有 I/O 请求，在其写入时加密块，在其读取时（在初始配置使用 BitLocker 时，会使用分配到块的完整卷加密密钥 (FVEK) 读取它们）解密块。默认情况下，使用 128 位 AES 密钥和 128 位扩散器密钥加密卷。因为加密和解密发生在 I/O 系统的 NTFS 之下，所以卷在 NTFS 看来好象没有加密，并且 NTFS 甚至不需要知道已启用了 BitLocker。不过，如果您尝试从 Windows 外读取卷上的数据，它又看来象是随机数据。
FVEK 使用卷主密钥 (VMK) 加密，并存储在卷的特殊元数据区域。当您配置 BitLocker 时，会有许多关于如何保护 VMK 的选项，取决于系统的硬件功能。如果系统有符合 TPM 规范 v1.2 的受信任的平台模块 (TPM)，并有相关的 BIOS 支持，则您可以使用 TPM 加密 VMK（让系统使用存储在 TPM 中的密钥或存储在 USB 闪存设备中的密钥加密 VMK），或使用 TPM 存储的密钥和在系统启动时输入的 PIN 加密密钥。对于没有 TPM 的系统，BitLocker 提供使用存储在外部 USB 闪存设备中的密钥加密 VMK 的选项。在任何情况下，您都需要一个未加密的 1.5GB NTFS 系统卷，在该卷中存储了启动管理器和引导配置数据库 (BCD)。
使用 TPM 的优势在于，如果 BIOS 或系统启动文件在启用 BitLocker 后做出更改，BitLocker 会使用 TPM 功能确保不解密 VMK 和解除对引导卷的锁定。当您第一次加密系统卷，以及每次对提及的所有组件执行更新时，BitLocker 会借助于 TPM 设备驱动程序 (%Systemroot%\System32\Drivers\Tpm.sys) 计算这些组件的 SHA-1 哈希，并将称为测量的每个哈希存储到不同的 TPM 平台配置注册表 (PCR)。接下来，它使用 TPM 密封 VMK，该操作使用存储在 TPM 中的私钥加密 TPM 和与 BitLocker 传递到 TPM 的其他数据一起存储在 PCR 中的值。然后，BitLocker 将密封的 VMK 和加密的 FVEK 存储在卷的元数据区域。
当系统启动时，它会测量自己的哈希和 PCR 加载代码，并将哈希写入 TPM 的第一个 PCR。然后，它哈希 BIOS，并将该测量存储到相应的 PCR。接下来，BIOS 按启动序列哈希下一个组件，即引导卷的主引导记录 (MBR)，此过程会一直继续，直到测量操作系统加载器。运行的每个后续代码段负责测量其加载的代码，并将测量结果存储到 TPM 中相应的注册表。最后，当用户选择要启动哪个操作系统时，启动管理器 (Bootmgr) 会从卷读取加密的 VMK，并要求 TPM 取消密封。只有所有测量与密封 VMK 时相同时（包括可选的 PIN），TPM 才成功解密 VMK。
您可以考虑将此方案作为验证链，其中启动序列中的每个组件会描述 TPM 的下一个组件。只有所有描述与提供的原始描述相符时，TPM 才泄露其秘密。因此，即使卸下磁盘并装到其他系统、使用不同的操作系统启动系统或引导卷上未加密文件遭到破坏，BitLocker 也会保护加密数据。

代码完整性验证
作为内核模式设备驱动程序执行的恶意软件（包括 rootkit）与内核在相同的权限级别运行，因此最难识别和删除。这类恶意软件可以修改内核和其他驱动程序的行为，以便使其变得不可见。内核模式代码功能的 Windows Vista 代码完整性，也称为内核模式代码签名 (KMCS)，仅允许加载由开发人员发布和经过数字签名的设备驱动程序，这些开发人员已经过为数不多的证书颁发机构 (CA) 之一的审查。默认情况下，KMCS 在 Windows Vista 64 位系统上强制执行。
因为证书颁发机构会对其服务收取费用并进行基本的背景检查，如验证业务识别，所以很难产生在 64 位 Windows Vista 上运行的匿名内核模式恶意软件。此外，设法溜过验证进程的恶意软件可能会留下线索，这些线索在受到危害的系统发现恶意软件时，可以反击作者。KMCS 还有一些次要的用途，如在怀疑驱动程序有使客户系统崩溃的错误和解除高清晰度多媒体内容锁定（我会在稍后简单介绍）时，会向 Windows 在线崩溃分析团队提供联系信息。
KMCS 使用 Windows 十多年来一直采用的公钥加密技术，并要求内核模式代码包括由受信任证书颁发机构之一生成的数字签名。如果发布者将驱动程序提交给 Microsoft Windows 硬件质量实验室 (WHQL)，并且驱动程序通过了可靠性测试，则 Microsoft 会充当签署代码的证书颁发机构。大多数发布者将通过 WHQL 获得签名；但是如果驱动程序没有 WHQL 测试程序，发布者不想提交到 WHQL 测试，或者驱动程序是在系统启动早期加载的引导启动驱动程序，则发布者必须自己签署代码。为此，他们必须首先从 Microsoft 确定为受信任内核模式代码签名的证书颁发机构之一获得代码签名证书。然后，作者通过数字方式哈希代码，通过使用私钥进行加密来签署哈希，并将证书和加密的哈希包含在代码中。
当驱动程序尝试加载时，Windows 会使用存储在证书中的公钥解密包含在代码中的哈希，然后验证哈希与代码中包含的哈希是否匹配。证书的真实性也通过相同的方式进行检查，但使用 Windows 附带的证书颁发机构的公钥。
Windows 还检查相关的证书链，一直检查到 Windows 启动加载器和操作系统内核中嵌入的根颁发机构之一。尝试加载未签名的 64 位驱动程序不应该发生在生产系统，因此不同于“即插即用”管理器（它在指向加载没有确认是否通过 WQHL 测试签名的驱动程序时显示警告对话框），64 位 Windows Vista 在阻止加载未签名驱动程序时，在无提示的情况下随时将事件写入代码完整性应用程序事件日志，如图 5 所示。32 位 Windows Vista 也检查驱动程序签名，但允许加载未签名的驱动程序。阻止它们将会破坏升级的 Windows XP 系统（要求在 Windows XP 上加载驱动程序，并且还允许支持仅存在 Windows XP 驱动程序的硬件）。不过，32 位 Windows Vista 还会在加载未签名驱动程序时将事件写入代码完整性事件日志。
图 5 未签名的驱动程序加载尝试事件
图 5 未签名的驱动程序加载尝试事件
因为代码签名通常用来将代码标记为经过严格测试的官方发行版本，所以发布者通常并不想对测试代码签名。因此，Windows Vista 包括可以使用 Bcdedit 工具（在 TechNet 杂志 2007 年 3 月份我的文章中介绍过）启用和禁用的测试签名模式，它将加载使用由内部证书颁发机构生成的测试证书经过数字签名的内核模式驱动程序。此模式设计为供程序员在开发其代码时使用。当 Windows 处于此模式时，它会在桌面上显示标记，如图 6 中所示。
图 6 Windows Vista 测试签名模式
图 6 Windows Vista 测试签名模式

受保护的进程
下一代多媒体内容，如 HD-DVD、BluRay 和高级访问内容系统 (AACS) 下许可的其他格式，在以后几年内会变得更加常见。Windows Vista 包括许多技术，统称为受保护的媒体路径 (PMP)，AACS 标准要求在播放此类内容时使用这些技术。PMP 包括受保护的用户模式音频 (PUMA) 和受保护的视频路径 (PVP)，它们一直为音频和视频驱动程序及媒体播放机应用程序提供机制，以防止未授权软件或硬件捕获高清晰度格式的内容。
PUMA 和 PVP 定义特定于音频和视频播放机、设备驱动程序和硬件的接口和支持，但是 PMP 也依赖在 Windows Vista 中引入的一般内核机制，即称为受保护的进程。受保护的进程以标准的 Windows 进程构造为基础，该构造封装了运行的可执行映像、其 DLL、安全上下文（进程运行所在的帐户及其安全权限），及在进程内执行代码但阻止某些访问类型的线程。
标准进程实施访问控制模式，允许使用“调试程序”权限完全访问进程所有者和管理帐户。完全访问允许用户查看和修改进程的地址空间，包括映射到进程的代码和数据。用户也可以将线程注入进程。这些访问类型与 PMP 的要求不一致，因为它们允许未授权代码获取存储在播放内容的进程中的高清晰度内容和数字版权管理 (DRM) 密钥的访问权限。
受保护的进程限制访问一组受限的信息和进程管理界面，包括查询进程的映像名和终止或挂起进程。但是，内核通过一般的进程查询功能（返回有关系统上所有进程的数据）为受保护的进程提供诊断信息，因此不要求直接访问进程。访问可能会损坏只允许通过其他受保护的进程访问的媒体。
此外，为避免从内部受到危害，加载到受保护进程的所有可执行代码（包括其可执行映像和 DLL）必须由 Microsoft (WHQL) 使用受保护的环境 (PE) 标记签名，或者（如果是音频编解码器）由开发人员使用从 Microsoft 获得的 DRM 签名证书签名。因为内核模式代码可以获取任何进程的完全访问权限（包括受保护的进程），并且 32 位 Windows 允许加载未签名的内核模式代码，所以内核可为受保护的进程提供 API，以查询内核模式环境的“清洁度”，并仅在没有加载未签名代码时使用结果解除对高级内容的锁定。
识别受保护的进程
没有特定识别受保护进程的 API，但是您可以间接地根据有关它们的受限信息以及甚至无法从管理帐户进行调试来识别它们。音频设备图形隔离进程 (%Systemroot%\System32\Audiodg.exe) 用于播放使用内容加密系统 (CSS) 编码的 DVD，并在“任务管理器”窗格中标识为受保护的进程。事实上，即使使用管理权限运行，任务管理器也无法获得其命令行、虚拟化和数据执行保护状态。
查看 audiodg 受保护进程的任务管理器
查看 audiodg 受保护进程的任务管理器

地址空间加载随机化
不管采取什么措施，如数据执行保护和增强的编译器错误检查，恶意软件作者都会继续找到缓冲区溢出漏洞，这些漏洞使他们能够感染面向网络的进程（如 Internet Explorer®、Windows 服务及第三方应用程序），获得进入系统的立足点。不过，在设法感染进程后，他们必须使用 Windows API 通过修改用户或系统配置设置来完成读取用户数据或建立永久存在的最终目的。
使用 DLL 导出的 API 入口点连接应用程序，通常由操作系统加载器处理，但是这些类型的恶意软件感染不会从加载器的服务中受益。恶意软件在以前的 Windows 版本中还没有出现过此类问题，因为对于任何特定的 Windows 版本，系统可执行映像和 DLL 总在同一个位置加载，让恶意软件假定 API 驻留在固定的地址。
Windows Vista 地址空间加载随机化 (ASLR) 功能使恶意软件不可能知道 API 的位置，方法是通过每次系统启动时在不同位置加载系统 DLL 和可执行文件。在启动进程早期，内存管理器会从用户模式地址空间顶部 16MB 区域的 256 个 64KB 对齐地址中随机选取一个作为 DLL 映像加载偏差。由于在映像标头中有新的动态重新定位标记的 DLL 加载到进程中，因此内存管理器会从映像加载偏差地址开始并继续将 DLL 选取到内存中。
具有标记组的可执行文件会得到类似的处理，在存储在其映像标头中的 16MB 基本加载地址内以随机的 64KB 对齐点加载。此外，如果使用给定的 DLL 或可执行文件的所有进程卸载后再次加载它，内存管理器会重新选择一个随机的加载位置。图 7 所示为一个 32 位 Windows Vista 系统的示例地址空间布局，包括 ASLR 选取映像加载偏差和可执行文件加载地址的区域。
图 7 ASLR 对可执行文件和 DLL 加载地址的影响
图 7 ASLR 对可执行文件和 DLL 加载地址的影响
只有具有动态重新定位标记的映像（包括所有 Windows Vista DLL 和可执行文件）才能重新定位，因为移动原有映像可能会中断开发人员对其映像加载位置所做的内部假设。Visual Studio® 2005 SP1 增加了对设置标记的支持，以便第三方开发人员可以充分利用 ASLR。
将 DLL 加载地址随机分布到 256 个位置之一，并不会使恶意软件猜不出正确的 API 位置，但是它会严重限制网络蠕虫传播的速度，并且可以阻止仅有一次机会感染系统的恶意软件以可靠地运行。此外，ASLR 的重新定位策略的第二个好处是，地址空间压缩比在以前的 Windows 版本上的更加紧密，为连续内存分配创建更大的可用内存区域，减少内存管理分配以跟踪地址空间布局的页表数，以及最小化转换旁路缓冲器 (TLB) 遗漏。

服务安全性改进
Windows 服务成为理想的恶意软件目标。许多服务都提供通过网络访问其功能，这很可能会暴露远程可利用的访问系统的机会，而大多数服务运行都使用比标准用户帐户更多的权限，如果它们被恶意软件利用，则会提供在本地系统上提升权限的机会。因此，Windows 以在 Windows XP SP2 中所做的更改为始不断完善，将权限和对指定服务的访问权限降为仅其角色需要的权限。例如，Windows XP SP2 引入了本地服务和网络服务帐户（仅包括服务以前一直运行的本地系统帐户权限的子集）。这样可以在利用服务时最小化攻击者获取的访问权限。
查看运行中的 ASLR
通过使用像 Sysinternals 提供的 Process Explorer 一样的工具，在两个不同的引导会话中比较进程的 DLL 加载地址，您可以很容易看到 ASLR 的效果。在从两个不同会话截取的这两个屏幕快照中，Ntdll.dll 首先在地址 0x77A30000、然后在地址 0x77750000 加载到 Explorer。
ntdll.dll 的不同基址
ntdll.dll 的不同基址

在我以前的文章中，我介绍了服务如何在其会话中与用户帐户分开运行，但是 Windows Vista 还通过进一步降低分配给大多数服务对文件、注册表项及防火墙端口的权限和访问权限，以扩大其最小权限原则的使用。Windows Vista 为每种服务定义了一组唯一的新帐户，称为服务安全标识符 (SID)。服务可以对其资源设置权限，这样只有其服务 SID 拥有访问权限，避免在服务出现安全漏洞时以相同用户帐户运行的其他服务拥有访问权限。您可以使用 sc showsid 命令后接服务名称来查看服务的 SID，如图 8 所示。
图 8 查看服务 SID
图 8 查看服务 SID
服务 SID 保护对特定服务所拥有资源的访问权限，但默认情况下，服务对其运行的用户帐户可以访问的所有对象仍有访问权限。例如，在“本地服务”帐户中运行的服务可能无法访问在不同进程（该进程使用参考服务 SID 的权限保护其对象）中以“本地服务”运行的另一服务创建的资源；但是，它仍可以读取和写入“本地服务”（以及“本地服务”所属的任何组，如“服务组”）有权访问的任何对象。
因此，Windows Vista 引入了称为限制写入服务的新受限服务类型，可让服务仅对其服务 SID、Everyone 组及分配到登录会话的 SID 可访问的对象允许写入访问权限。为了实现这一点，它会使用重新引入 Windows 2000 的受限 SID 类型。当打开对象的进程是限制写入服务时，访问 - 检查算法会发生变化，这样尚未以受限和非受限方式分配到进程的 SID 就无法用来为进程授予对象的写入权限。您可以使用以下命令查看服务是否受限：
sc qsidtype [service]
另一个变化是让服务更容易阻止在相同帐户中运行的其他服务对其创建的服务拥有访问权限。在以前的 Windows 版本中，对象的创建者也是对象的所有者，而且所有者能够读取和更改其对象的权限，允许其对自己对象的完全访问权限。Windows Vista 引入了新的所有者权限 SID，如果在对象的权限中存在 SID，则 SID 可以限制所有者对其对象的访问权限，甚至会删除设置和查询权限的权利。
对 Windows Vista 中服务安全模式的进一步改进，可以让服务开发人员确切地指定当服务在系统上注册时，此服务需要什么安全权限才能操作。例如，如果服务需要生成审核事件，它就可以列出“审核”权限。
当“服务控制管理器”启动托管一个或多个 Windows 服务的进程时，它就为在该进程中仅包括服务所需权限的进程创建了一个安全令牌（列出进程用户帐户、组成员身份和安全权限的内核对象）。如果服务指定了其运行的帐户不可用的权限，则服务无法启动。当“本地服务”帐户进程中未运行任何需要（例如）“调试程序”权限的服务时，“服务控制管理器”会从进程的安全令牌中剥夺此权限。因此，如果服务进程被破坏，恶意代码无法利用进程中运行的服务未明确请求的权限。sc qprivs 命令会报告服务已请求的权限。

结束语
本文结束了我对 Windows Vista 内核更改分析的三部曲。有些功能和改进我没有涉及或提及，如面向应用程序开发人员的新的工作线程池、新的同步机制（如共享读取器/编写器锁定）、服务线程标记、对在线 NTFS 磁盘检查和卷大小调整的支持以及称为高级本地过程调用 (ALPC) 的新内核 IPC 机制。您可以在计划于 2007 年底发行的下一版《Windows Internals》（Windows 内部结构）中了解有关这些功能和其他功能的详细信息。
查看限制写入服务
在 Windows Vista 上只有一种托管服务进程托管受限服务，您可以使用进程查看工具（如 Process Explorer）将它识别为具有以下命令行的进程：
svchost -k LocalServiceNoNetwork
配置在此进程中运行的服务包括基本筛选引擎、诊断策略服务、Windows 防火墙、性能日志和警报及 Windows Media® Center 服务启动程序。
此屏幕显示文本格式的基本筛选引擎的服务 SID (NT SERVICE\BFE)，第一次列出时有受限标记，再次列出时没有受限标记，因此进程对该帐户可以访问的资源拥有访问权限。不过，它不必对“本地服务”帐户通常可以访问的其他对象拥有访问权限。例如，因为 NT AUTHORITY\SERVICE 帐户不会在有受限标记的进程令牌中出现，所以进程无法修改仅对令牌（有受限标记）中此帐户而不是其他帐户授予写入权限的对象。
在此进程中运行的服务还会限制其权限，因为在属性对话框底部列出的权限是可用于“本地服务”帐户的子集。
服务上的 SID 标记
服务上的 SID 标记

Mark Russinovich 是 Microsoft 平台和服务部门的技术人员。他是《Microsoft Windows Internals》（Microsoft Windows 内部结构）(Microsoft Press, 2004) 的合著者之一，并经常在 IT 和开发人员会议上演讲，包括 Microsoft Tech•Ed（微软技术大会）和 PDC（微软程序员大会）。在 Microsoft 收购了 Mark Russinovich 与其他人创办的 Winternals Software 之后，Mark Russinovich 也随之加入了 Microsoft。他还创建了 Sysinternals，在这里他发布了许多流行的实用工具，包括 Process Explorer、Filemon 和 Regmon。
© 2007 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.


 Windows 管理: 灾难恢复：Active Directory 用户和组
Windows 管理 Gil Kirkpatrick

灾难恢复：Active Directory 用户和组
概览:
  • 复制和对象链接结构
  • 使用 NTDSUTIL 备份和还原
  • 权威还原和非权威还原

Active Directory 是 Windows 网络中最为关键的服务之一。为了避免出现停机时间和损失生产力，对与 Active Directory 有关的问题制订有效的灾难恢复计划是至关重要的。这一点听起来容易，但
令人吃惊的是，有很多管理员甚至没有为最常见的一个 Active Directory® 故障方案 - 意外删除数据 - 制定计划。
意外删除对象是服务失败最常见的根本原因之一。当我参加研讨会和会议时，我常常询问有谁曾经因为意外删除数据而导致 Active Directory 失败。而每次几乎所有人都举手。
要理解为何数据恢复是如此复杂，必须先理解以下内容：Active Directory 如何恢复和复制对象、如何删除对象以及权威还原和非权威还原的结构。

存储对象
Active Directory 是一个实施 X.500/LDAP 数据模型的专门的对象数据库。数据存储（称为目录信息树或 DIT）基于可扩展存储引擎 (ESE)，这是一个索引顺序访问方法 (ISAM) 数据库引擎。从概念上说，Active Directory 将 DIT 存储在两张表中：数据表（包含实际的 Active Directory 对象和属性）和链接表（包含对象之间的关系）。
每个 Active Directory 对象存储在数据表中单独的一行，每个属性一列。数据表包含存储在域控制器 (DC) 上的所有副本的所有条目。在一个常规 DC 上，数据表包含来自域 NC（命名上下文）、配置 NC 和架构 NC 的条目。在全局编录上，数据表包含林中每个对象的条目。
Active Directory 使用可分辨名称标记 (DNT)（一个 32 位的整数）来唯一标识数据表中的每一行。用于内部引用对象的 DNT 比其他标识符如可分辨名称 (DN) 和 objectGUID（一个 16 字节的二进制结构）都小得多。但是与 objectGUID 不同的是，DNT 是一个本地标识符，并且在每个 DC 上都不同。

Active Directory 如何链接对象
Active Directory 管理 DIT 中对象间的两类关系：父子关系（也称为容器关系）和引用关系（也称为链接关系）。为了实施父子关系，Active Directory 在数据表中存储了一个称为父可分辨名称标记（或 PDNT）的附加列。该列始终包含对象的父对象的 DNT。
Active Directory 中的每个属性均由 Active Directory 架构容器中的 attributeSchema 对象定义。Active Directory 中的某些属性定义为链接属性，由 attributeSchema 对象的 linkID 属性中的一个非零偶数值确定。链接属性建立了目录中对象间的关系，可以是单值或多值。组对象的成员属性是多值链接属性的一个例子 — 它建立了组对象及其成员对象之间的链接。
即使看起来组的成员属性包含成员的 DN（例如，通过 Active Directory 用户和计算机管理单元显示），但这不是 Active Directory 存储它们的方式。当您将成员对象的 DN 添加到组的成员属性时，Active Directory 存储对象的 DNT 而并非其 DN。由于即使将对象重命名 DNT 也不会改变，因此可以重命名用户对象，而且 Active Directory 不用对系统中所有的组排序以更新每个成员属性的 DN。这就是 Active Directory 如何在 DIT 内维护引用完整性的原理。图 1 所示为一个经过大大简化的数据表和链接表如何彼此关联的示意图。这些表所示的三个用户对象（Molly Clark、Alexander Tumanov 和 Makoto Yamagishi）都是 Senior Engineers 组的成员。
Figure 1 数据和链接表如何相关 (Close Figure 1)

数据表 |  |  |
DNT | PDNT | 对象类 | Cn
14529 | 14401 | organizationalUnit | 工程师
14530 | 14529 | 组 | 高级工程师
14531 | 14529 | 用户 | Molly Clark
14532 | 14529 | 用户 | Alexander Tumanov
14533 | 14529 | 用户 | Makoto Yamagishi
链接表 |  |  |
属性 | DNT | 前向链接 |
成员 | 14530 | 14531 |
成员 | 14530 | 14532 |
成员 | 14530 | 14533 |
这些链接称为前向链接。类似地，Active Directory 还提供了后向链接属性。这为从链接指向的对象返回到引用链接的对象提供了引用，意味着该对象具有前向链接。用户和组的 memberOf 属性是后向链接属性的一个例子。属性 Schema 对象描述了一个后向链接属性，该属性具有 linkID 值，其值比相应的前向链接属性以偶数编号的 linkID 值大 1。 例如，Windows Server® 2003 R2 架构中成员属性的 linkID 值为 2，作为后向链接的 memberOf 属性的 linkID 值为 3。有关详细信息，图 2 提供了一个默认情况下 Windows Server 2003 R2 架构中定义的链接属性列表。
Figure 2 Windows Server 2003 R2 架构中的链接属性 (Close Figure 2)

前向链接属性 | linkID | 后向链接属性 | 链接的
成员 | 2 | memberOf | 3
管理员 | 42 | directReports | 43
所有者 | 44 | ownerBL | 45
siteObject | 46 | siteObjectBL | 47
nonSecurityMember | 50 | nonSecurityMemberBL | 51
queryPolicyObject | 68 | queryPolicyBL | 69
privilegeHolder | 70 | isPrivilegeHolder | 71
managedBy | 72 | managedObjects | 73
hasPartialReplicaNCs | 74 |  |
hasMasterNCs | 76 | masteredBy | 77
syncMembership | 78 |  |
serverReference | 94 | serverReferenceBL | 95
bridgeheadTransportList | 98 | bridgeheadServerListBL | 99
netbootServer | 100 | netbootSCPBL | 101
frsComputerReference | 102 | frsComputerReferenceBL | 103
fRSMemberReference | 104 | fRSMemberReferenceBL | 105
fRSPrimaryMember | 106 |  |
siteLinkList | 142 |  |
siteList | 144 |  |
msCOM-PartitionLink | 1040 | msCOM-PartitionSetLink | 1041
msDS-NC-Replica-Locations | 1044 |  |
msFRS-Hub-Member | 1046 |  |
msCOM-UserPartitionSetLink | 1048 | msCOM-UserLink | 1049
msDS-SDReferenceDomain | 2000 |  |
msDS-HasInstantiatedNCs | 2002 |  |
msDS-NonMembers | 2014 | msDS-NonMembersBL | 2015
msDS-MembersForAzRole | 2016 | msDS-MembersForAzRoleBL | 2017
msDS-OperationsForAzTask | 2018 | msDS-OperationsForAzTaskBL | 2019
msDS-TasksForAzTask | 2020 | msDS-TasksForAzTaskBL | 2021
msDS-OperationsForAzRole | 2022 | msDS-OperationsForAzRoleBL | 2023
msDS-TasksForAzRole | 2024 | msDS-TasksForAzRoleBL | 2025
msDS-HasDomainNCs | 2026 |  |
msSFU30PosixMember | 2030 | msSFU30PosixMemberOf | 2031
msDS-hasMasterNCs | 2036 | msDs-masteredBy | 2037
msDS-ObjectReference | 2038 | msDS-ObjectReferenceBL | 2039
msDFSR-ComputerReference | 2050 | msDFSR-ComputerReferenceBL | 2051
msDFSR-MemberReference | 2052 | msDFSR-MemberReferenceBL | 2053
后向链接属性总是多值的，由 Active Directory 自动维护。实际上，您不能直接修改后向链接属性。尽管看起来可以通过 Active Directory 用户和计算机 MMC 管理单元修改用户或组的 memberOf 属性，但该管理单元实际上修改的是相应组的成员属性，而 Active Directory 将在后台更新 memberOf 属性。这就是为什么无需有关用户对象的权限即可添加用户到组的原因；因为您实际上修改的是组对象的成员属性。因为每个 DC 都在本地管理其后向链接属性，所以永远不会复制对后向链接的更改。只复制对前向链接属性的更改（如组的成员属性）。
在一个常规 DC 上，数据表包含域对象的条目以及来自配置和架构容器的对象条目。但一些组类型可能包含对位于其他域中对象的引用。Active Directory 如何存储不在其数据表中的对象的 DNT？答案在于基础结构主机 FSMO（灵活单主机操作）角色所有者和称为幻影对象的对象。

幻影对象
当将一个成员从一个域添加到其他域中的组时，Active Directory 在数据表中自动创建一个称为幻影的特殊对象，它包含新成员的 objectGUID、objectSid 和 DN。这提供了可存储在组的成员属性中的 DNT。如果域控制器是全局编录，则将无需创建幻影，因为在其数据表中林中每个对象都已有一个条目。
拥有基础结构 FSMO 角色的 DC 定期根据全局编录检查其数据表中的条目，当它发现有对象被移动、重命名或删除时，它将更新数据表中的幻影并将更改复制到域中的其他 DC。根据引用计数，基础结构主机还会删除域中任何前向链接属性都不再引用的幻影。
幻影允许 DC 管理指向林内其他域中对象的引用，但前向链接属性还可以引用林外的对象 — 例如受信任的域。在这种情况下，Active Directory 在域 NC 中的 CN=ForeignSecurityPrincipals 容器内创建一个称为外部安全主体 (FSP) 的对象。FSP 包含外部对象的安全标识符 (SID) 和标识外部域中对象的其他属性，但没有流程确保 FSP 保持最新。出于数据恢复的目的，我们将象对待其他任何 Active Directory 对象一样对待 FSP。

删除对象
在这里，我将焦点主要放在还原用户及其组成员身份上。但是，同样的原则也适用于恢复其他链接属性。
当 Active Directory 删除一个对象时，它并没有从 DIT 物理删除该对象。相反地，它将该对象的 isDeleted 属性设置为 true 从而将其标记为已删除，这样使得该对象对常规目录操作不可见。按照架构定义，Active Directory 删除所有未指定要保存的属性并将对象的相对可分辨名称 (RDN) 更改为 <old RDN>\0aDEL:<objectGUID>。然后，它将对象移动到 NC 的 CN=Deleted Objects 容器。（配置 NC 中有一些对象类 Active Directory 不移动到“已删除对象”容器。）Active Directory 删除任意指向已删除对象保留的其他对象的前向链接 — 这样在链接表中降低了其引用计数。如果有其他对象包含指向现在已删除对象的前向链接，Active Directory 同样也会删除这些链接。
得到的对象称为 tombstone。Active Directory 将此 tombstone 复制到其中做了同样更改的其他 DC。请注意，Active Directory 不会复制对指向已删除对象的前向链接所做的更改。每个 DC 在本地进行同等更改，因此不需要复制更改。我将在本文稍后的部分讨论恢复组成员身份的后续结果。
Active Directory 维护 DIT 中逻辑上删除的对象由 CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=<root domain> 对象的 tombstoneLifetime 属性决定。对每个 DC 的垃圾收集流程将删除比配置的 tombstone 生存期更老的 tombstone。默认情况下，tombstone 生存期对 Windows® 2000、Windows Server 2003 和 Windows Server 2003 R2 是 60 天，对 Windows Server 2003 SP1 是 180 天。
Tombstone 生存期对还原过程有着重大意义。不能还原比 tombstone 生存期更老的备份。因为已删除并从域中作为垃圾收集的对象不再有 tombstone，所以永远不会将删除操作重新复制到还原的 DC。接下来，已删除的对象将作为延迟对象保留在还原的 DC 中，而还原的 DC 将永远不能正确地与域中其他 DC 聚合。

复制对象
无论何时域控制器执行任何类型的更新操作（例如添加对象或修改属性）时，DC 都会为更新操作分配一个唯一的 64 位数字，称为更新序列号 (USN)。Active Directory 使用 USN 标记更新的对象和属性以帮助确定是否需要复制它们。
Active Directory 逐个属性地复制对象。也就是说，如果修改一个对象的属性，Active Directory 将只复制该属性，而非整个对象。要做到这一点，Active Directory 使用复制元数据跟踪它对每个属性所做的更改。一个属性的复制元数据包括：
  • 本地 USN，标识本地 DC 上的更改操作。
  • 引起更改的 DC 的 invocationID（特别是 DC 相应的 nTDSSettings 对象的 invocationID 属性），标识域控制器上 DIT 的特定生成。
  • 源操作位于源 DC 上时的 USN。
  • 时间戳，包含进行源更改时的 DC 系统时间。
  • 32 位版本序号，每次值更改时递增。
当目标 DC 从其源 DC 合作伙伴请求更改时，它将最近成功进行复制更改的 USN 发送到源 DC，同时附带包含最大源 USN 的最新向量。这些源 USN 是目标 DC 从每个具有所复制 NC 副本的 DC 上所见的最大源 USN 。源 DC 使用此信息以便只发送目标 DC 尚未看见的那些更新。
当目标 DC 处理传入的属性更新时，它将核对每个属性的版本号。如果传入属性的版本号大于 DC 已有的该属性版本，则 DC 将存储该传入值。如果传入版本号等于 DC 已有的版本，则 DC 将比较时间戳并使用时间戳最新的属性。如果时间戳相同，目标 DC 将选择具有最大 invocationID 的值。这样可以确保每个 DC 最终为每个复制的属性确定相同的值。

链接值复制
在 Windows 2000 中，Active Directory 复制多值属性的方式与复制单值属性相同。这对那些多值成员属性可能在不同 DC 上经常更改的大型动态组对象可能带来问题。如果一位管理员添加用户到一个 DC 上的组，而另一位管理员在复制延迟窗口内添加其他用户到另一个 DC 上的组，则 Active Directory 将选择后一个添加并完全丢失前一个添加。Microsoft 在 Windows Server 2003 中使用一个称为链接值复制 (LVR) 的进程处理此问题。
凭借 Windows Server 2003 林的功能级别或过渡林的功能级别，Active Directory 分别复制多值前向链接属性的单个值，每个值拥有其自己的复制元数据。这有效解决了在 Windows 2000 中发现的问题，即在不同 DC 上几乎同步的组成员身份更新可能导致数据丢失。
但是，有一点需要指出。提升林的功能级别不会自动使用新的复制元数据修复现有的多值链接属性。只有那些在提升林的功能级别之后添加的值才有新的元数据。这对恢复组成员身份具有重大影响，您很快就会看到。

备份
Windows 包括非常基本的 NTBACKUP 实用程序，可以使用它来执行 DC 的系统状态备份。域控制器的系统状态包括其注册表、SYSVOL、Active Directory DIT 文件和关键系统文件。大多数第三方备份实用程序也有备份和还原 DC 系统状态的功能。
要执行对磁盘文件的系统状态备份，请使用以下命令：
NTBACKUP backup systemstate /F “<filename>”
此处，<filename> 是要创建的备份文件的名称，应使用 .bkf 扩展名。

执行非权威还原
从备份还原已删除的 Active Directory 对象分为两步：首先，重新启动 DC 进入目录服务还原模式 (DSRM)，然后使用 Windows NTBACKUP 实用程序或同等的第三方产品从系统状态备份还原整个 Active Directory DIT。此过程将覆盖整个 DIT。
有两种方法可以启动 DC 进入 DSRM：如果对 DC 的系统控制台有访问权限，关闭并重新启动 DC，当提示时按 F8 引出 Windows 启动菜单。从菜单中选择“目录服务还原”然后输入 DSRM 密码。
如果远程管理该服务器，则不能访问 Windows 启动菜单。替代方法是，通过从“我的电脑”选择“属性”，单击“高级”选项卡，然后按“启动和恢复”下方的“设置”按钮，更改系统启动选项。按“系统”启动区中的“编辑”按钮编辑 boot.ini 文件，然后添加开关 /SAFEBOOT:DSREPAIR 到行尾，如图 3 所示。（有关 boot.ini 开关的详细信息，请参阅 microsoft.com/technet/ sysinternals/information/bootini.mspx。）
图 3 设置 DSRM 的启动选项
图 3 设置 DSRM 的启动选项
重新启动服务器时，它将在 DSRM 中出现。请记住，当您要以正常模式重新启动 DC 时，必须从 boot.ini 删除 /SAFEBOOT 开关。
一旦使用 DSRM 密码登录后，就可以再次使用 NTBACKUP 命令还原系统状态备份而无需指定任何参数。（不能从命令行使用 NTBACKUP 还原。）当向导出现时，选择“还原文件和设置”，然后单击“下一步”。然后选择备份文件并选中“系统状态”框，如图 4 所示。
图 4 使用“备份或还原向导”还原系统状态
图 4 使用“备份或还原向导”还原系统状态
如果想在此时启动 DC 返回正常模式，Active Directory 复制进程将把还原的域控制器带回与域中其他 DC 的同步当中，所有还原的数据也将被当前数据覆盖。显然，这不是您的目标。相反地，您需要一种方法将被还原的对象强制复制到域中的其他域控制器。

执行权威还原
NTDSUTIL 还会在备份日期和还原日期之间的每天将每个属性的版本号增加 100,000。除非属性在一天内更新的次数超过 100,000 次（极不可能出现的情形），还原属性的版本号将远大于其他 DC 所持有的版本号，而权威还原的对象将复制到其他 DC。其他从备份非权威还原的对象将最终被其他域控制器的现有数据覆盖。
当完成非权威还原后，但重新启动进入正常模式之前，使用 NTDSUTIL 程序执行要恢复对象的权威还原。无论名称如何，权威还原一个对象并不会“还原”该对象，它只是确保 Active Directory 将对象复制到其他 DC。要做到这一点，NTDSUTIL 将下一个可用的 USN 分配给对象属性的本地 USN。这导致在下一次同步时将对象发送到复制伙伴。要还原单个对象，请确保 DC 以 DSRM 模式启动，并按照如下步骤操作：
  1. 打开命令窗口，键入：
    ntdsutil
  2. 在 ntdsutil 提示符下键入：
    authoritative restore
  3. 在权威还原提示符下键入：
    restore object “<DN of object to be restored>”
    例如，如果想从 DRNET 域中的 Eng OU 还原 Molly Clark 帐户，需要输入：
    restore object “CN=Molly Clark,OU=Eng,DC=DRNET,DC=com”
    如果想权威还原整个目录子树（例如一个 OU），则需要如下输入：
    restore subtree “OU=Eng,DC=DRNET,DC=com”
    （NTDSUTIL 还提供了一个还原数据库命令用于权威还原整个域以及配置 NC 和架构 NC。还原整个域充满了危险，并且我不建议您使用该选项。如果需要还原整个域，应该还原一个域控制器，然后再次提升域中的其他 DC，如“规划 Active Directory 林恢复”中所述。
  4. 当提示时，确认权威还原应增加各对象及其属性的版本号。
  5. 退出 ntdsutil（需要键入 quit 两次）。
  6. 重新启动 DC 进入正常 Active Directory 模式。
下一次当 DC 与其伙伴进行复制时，将复制您还原的用户。但是还原用户对象只解决了问题的一半。当引入诸如组及其成员之间的对象链接时，情况变得更复杂。在还原期间和还原后可能要面对一些基础问题，在下面的几节我将继续介绍。
首先让我们回顾一下当删除具有后向链接的对象时发生的情形。假设您删除了一个用户对象，它是一个组或多个组的成员。每个具有该用户对象副本的域控制器会将其转换为一个 tombstone 并从链接表中删除所有引用，因而也从用户域中的所有组成员身份删除了该用户对象。（请记住，从组成员身份删除用户不是复制的更改，因为每个 DC 都在本地更新了组成员身份。组成员属性的版本号和本地 USN 保持不变。）短时间之后，将从其他域的链接表中删除幻影对象，再一次不更新组成员属性的复制元数据。
当非权威还原用户域中域控制器上的 DIT 时，将恢复用户对象以及域中组内的所有组成员身份，因此还原的 DC 是本身一致的。当使用 NTDSUTIL 实用程序权威还原用户时，用户对象复制到域中所有其他 DC。
但是因为域中当前组的复制元数据未改变，还原的 DC 上组的成员属性与其他 DC 上组的成员属性不一致。通常情况下没有可以使之聚合的方法。因此，将不会在域中其他 DC 上还原用户的成员身份。

问题：域内的组成员身份未还原
权威还原用户对象不恢复用户的组成员身份。为什么？因为成员身份关系使用组对象的成员属性（前向链接）而非用户的 memberOf 属性（后向链接）进行存储和复制。问题是如何查找用户旧的组成员身份以及在得知其身份后如何正确恢复它们。
Microsoft 对恢复用户组成员身份的进程逐渐进行改良，因此您所使用的技术取决于运行的 Active Directory 版本。下一节主要适用于 Windows 2000 Active Directory。
确定用户旧的组成员身份非常简单：只需在还原的 DC 上检查后向链接属性 — 在这种情况下，是用户对象的 memberOf 属性。memberOf 属性将包含用户域中本地组和全局组的所有成员身份。可以使用 Active Directory 用户和计算机 MMC 管理单元 (ADUC) 或使用 LDIFDE 实用程序（该程序随 Windows Server 附带）列出还原用户的组成员身份。
以下 LDIFDE 命令行将列出 Molly Clark 所属的 DRNET 域中的组，将结果存储在 output.ldf 文件中：
C:\> ldifde –r “(distinguishedName=CN=Molly Clark,
OU=Engineering,DC=DRNET,DC=Local)” –l memberOf –p Base –f output.ldf
请注意，必须使用任何 LDAP 工具启动 DC 进入正常模式，并且再次重申，必须禁用入站复制；否则还原的数据将被覆盖。禁用入站复制最简单的方式是使用 REPADMIN 命令：
REPADMIN /options <dcname>+DISABLE_INBOUND_REPL
此处，<dcname> 是正在向其还原的 DC 名称。完成后不要忘记使用 –DISABLE_INBOUND_REPL 重新启用复制。
如果只要恢复几个用户，方法很简单，只需使用 ADUC 手动将用户添加回组。如果要恢复的用户数量较多，可以使用一些工具使某些过程自动化。Microsoft GROUPADD 实用程序（可从 Microsoft 产品支持服务获得）可以接受您创建用来列出用户旧的组成员身份的 LDIF 文件，并依次生成一个重新创建这些成员身份的 LDIF 文件。例如，可以使用此 GROUPADD 命令处理我们在前文示例中为 Molly Clark 创建的 LDIF 文件：
C:\> groupadd /after_restore output.ldf
此命令将以名称 groupadd_<domain>.ldf（其中 <domain> 是将更新其组的域的完全限定域名）为 Molly Clark 在其中具有组成员身份的每个域创建一个新的 LDIF 文件。可以使用如下命令导入上面创建的 LDIF 文件：
C:\> ldifde –i –k –f groupadd_child.drnet.net.ldf
对于 Windows Server 2003，Microsoft 改进了 NTDSUTIL，利用成员属性中出现的其他元数据支持链接值复制 (LVR)。如果还原的用户对象曾经是域中任何组的成员，而用户的组成员身份使用 LVR 元数据存储，则 NTDSUTIL 将增加成员属性相应值的版本号，从而引起还原的成员身份复制。
Windows Server 2003 SP1 的 NTDSUTIL 版本集成了 GROUPADD 功能，可以在执行用户对象的权威还原时自动创建 LDIF 文件。图 5 所示为一个 NTDSUTIL 新版本，图 6 所示为自动创建的 LDIF 文件的内容。
Figure 6 NTDSUTIL 创建的 LDIF 文件的内容 (Close Figure 6)
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngDL,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngGG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
delete: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
dn: CN=EngUG,OU=Eng Groups,DC=drnet,DC=local
changetype: modify
add: member
member: CN=Molly Clark,OU=Eng,DC=drnet,DC=local
-
图 5 内置 GROUPADD 功能的新 NTDSUTIL
图 5 内置 GROUPADD 功能的新 NTDSUTIL
如果要还原一个包含很多用户和组的整个 OU，手动将用户添加回其所在的组是很麻烦的。恢复还原的组成员身份的另一个方法是权威还原组本身。
但是权威还原组有两个问题。第一个问题是相当明显的：如果还原组，该组中的成员身份将恢复到其在备份时的状态。这意味着自从上一次备份以来所做的所有更改都必须重新应用于该组。第二个问题有些微妙，必须按 Active Directory 复制的方式处理。在权威还原用户和组后，无法确保它们复制的顺序。如果一个组对象在还原的用户对象之前复制到 DC，则复制的域控制器将自动从组删除该用户引用，因为该用户对象尚未存在于该 DC 上。当稍后用户对象复制时，不会将其添加到组。
解决此问题最简单的方法是再对组执行一次权威还原。执行首次权威还原后，重新启动进入正常模式并确保复制正确进行。然后重新启动返回到 DSRM 并运行 NTDSUTIL 执行用户所属组的权威还原。这是为了确保当启动返回到正常模式时，用户对象将在引用它的组对象复制之前完成复制。

问题：其他域内的组成员身份未还原
“此用户属于哪个组”问题实际上比我介绍的更困难。要还原的用户可能同时是本地域和其他域中通用组的成员，而进行非权威还原时，不会还原那些组成员身份。因此您如何得知用户属于其他域中的什么组呢？答案就在全局编录中。除自身域的数据外，全局编录还包含林中其他域数据的只读副本。
要利用全局编录的林范围数据，必须对全局编录执行非权威还原，这意味着您必须以备份全局编录开始。现在，当您运行 LDIFDE 标识用户的组成员身份时，就可以从其他域中找出用户的通用组成员身份。
当您列出要恢复的用户的组成员身份时，连接到全局编录端口 3268 而不是默认的 389，然后指定林的根域作为搜索基准。LDIFDE 将显示恢复的用户的组成员身份，包括其在林中所有域内的通用组中的成员身份。以下是操作方法：
C:\> ldifde –r “(distinguishedName=CN=Don Clark,
OU=Engineering,DC=DRNET,DC=Local)” -t 3268 –l memberOf –p Base –f output.ldf
如果在全局编录上运行 GROUPADD 或新的 NTDSUTIL，将会生成一个用户域的 LDIF 文件，并为还原用户所属通用组所在的每个域生成一个 LDIF 文件。当导入这些 LDIF 文件时，将还原该用户所有的组成员身份。好了，差不多了 — 接着讨论下一个问题。

问题：恢复其他域中的域本地组成员身份
在 Windows Active Directory 环境中有三种组。全局组只能包含同一个域中的成员，但可以用作其自身域和林中其他域的域本地组内的成员。全局组的成员属性不出现在全局编录中，但这不是问题，因为全局组只能包含来自其自身域的成员。通用组可以包含来自任何域的成员，可以用作林中其他通用组的成员以及用作其自身域和林中其他域的域本地组的成员。通用组的成员属性复制到全局编录。域本地组可以包含来自林中任意域的成员，但不能用作其他域中组的成员。更重要的是，域本地组的成员属性和全局组的成员属性一样，不出现在全局编录中。结果导致恢复其他域中域本地组的用户成员身份很困难。
在 Windows Server 2003 SP1 之前，恢复外部域中域本地组成员身份的唯一方式是在每个域中还原 DC，手动搜索包含该还原用户的所有域本地组的域数据，然后将用户添加回标识的组。在一个拥有众多域的大型环境中，这样会耗时太多。
Windows Server 2003 SP1 版本的 NTDSUTIL 可以帮助处理。当在域控制器上运行 NTDSUTIL 时，该实用程序创建一个包含还原的用户对象的 DN 和 GUID 的文本文件。然后，对于每个外部域，可以非权威还原单个 DC，将该文本文件复制到 DC，然后运行 NTDSUTIL 生成特定于域的新 LDIF 文件，将恢复的用户添加回其所属的域本地组。
要做到这一点，请在每个外部域的 DC 上执行以下步骤：
  1. 启动外部域中的 DC 进入 DSRM。
  2. 使用 NTBACKUP 还原包含还原用户的组成员身份的 DIT 副本。
  3. 将 NTDSUTIL 创建的 .txt 文件复制到当前 DC。
  4. 打开命令窗口，键入 ntdsutil。
  5. 键入 authoritative restore。
  6. 键入 create LDIF file(s) from <file name>（其中，<file name> 是文本文件的名称）。
  7. 键入 quit 两次以退出 ntdsutil。
  8. 重新启动 DC 进入正常 Active Directory 模式。
  9. 键入 ldifde –i –f <ldif filename>（其中，<ldif filename> 是刚才创建的 LDIF 文件的名称）。
现在，您已经还原了所有删除用户的组成员身份。

循序渐进
恢复 Active Directory 用户及其组成员身份（尤其是在一个多域环境中）是很复杂的。正确恢复组成员身份所需的具体步骤取决于运行的 Windows 版本。
如果运行的是 Windows 2003 SP1，则需要采取如下步骤：
  1. 启动 GC 进入 DSRM 并使用包含删除用户的备份执行系统状态还原。
  2. 使用 NTDSUTIL 执行已删除用户的权威还原。NTDSUTIL 将创建一个包含还原对象 DN 和 GUID 的文本文件以及一个或多个 LDIF 文件来还原用户的组成员身份。
  3. 使用 LDIFDE –i –f <LDIF filename>（其中，<LDIF filename> 是步骤 2 中创建的 LDIF 文件的名称）将组成员身份导入当前域和其他域。
  4. 重新启动全局编录进入正常模式。
  5. 在每个外部域的 DC 上，启动进入 DSRM 并使用包含还原用户的组成员身份的备份执行系统状态还原。
  6. 使用创建 ldif 文件命令运行 NTDSUTIL。
  7. 重新启动 DC 进入正常模式。
  8. 使用 LDIFDE –i –f <filename>（其中，<filename> 是在步骤 6 中创建的 LDIF 文件的名称）还原外部域中的组成员身份。
  9. 此时可以选择使用 REPADMIN /syncall 强制复制。
如果运行的 Windows Server 2003 版本没有安装 SP1 或运行的是 Windows 2000，将涉及到其他一些步骤。由于 NTDSUTIL 的较旧版本不创建 LDIF 文件，因此可以使用 GROUPADD 实用程序来创建它们。步骤如下：
  1. 启动全局编录进入 DSRM 并使用包含删除用户的备份执行系统状态还原。
  2. 禁用 NIC 或拔掉电缆阻止入站复制。
  3. 重新启动全局编录进入正常模式。
  4. 使用 LDIFDE –r "(distinguishedName=<dn>)" -t 3268 -l memberOf –p Base -f membership.ldf 使用可分辨名称 <dn> 转储用户的成员身份。
  5. 使用 GROUPADD /after_restore membership.ldf 创建 LDIF 文件。
  6. 使用 LDIFDE –i –f <filename>（其中，<LDIF filename> 是步骤 5 中 GROUPADD 创建的 LDIF 文件的名称）将组成员身份导入当前域和其他域。
  7. 使用 REPADMIN /options <dcname> -DISABLE_INBOUND_REPL 重新启用入站复制。
  8. 在每个外部域的 DC 上，启动进入 DSRM 并使用包含还原用户的组成员身份的备份执行系统状态还原。
  9. 重新启动 DC 进入正常模式。
  10. 使用 LDIFDE –i –f <filename>（其中，<filename> 是步骤 5 中 GROUPADD 创建的 LDIF 文件的名称）还原外部域中的组成员身份。
  11. 此时可以选择使用 REPADMIN /syncall 强制复制。
现在，对早于 Windows Server 2003 SP1 的环境唯一剩下的事就是恢复还原用户的外部域本地组成员身份。唯一的选择就是手动还原域本地组成员身份或从备份还原 DC 并权威还原域本地组。

总结
虽然很容易从 Active Directory 意外删除用户甚至 OU，但正确恢复删除的用户及其组成员身份可能惊人地复杂、耗时并且容易出错。要确保从这类灾难中尽可能快地恢复，必须理解对象链接、复制、删除和权威还原的结构。
您认为您在产品环境中首次尝试此操作时能正确完成所有步骤吗？为了确保下一次不得不恢复 CEO 的用户对象时有所准备，最好制订恢复删除对象的书面计划。并确保在将该计划用于实际数据之前至少练习一两次。您的老板（和 CEO）将会对此非常感激。
其他资源
  • 如何在 Active Directory 中还原删除的用户帐户及其组成员身份
  • Microsoft 产品支持服务
  • 管理 Active Directory 的分步指南

Gil Kirkpatrick 是 NetPro 的 CTO，自 1996 起便一直参与开发 Active Directory 软件。他与来自 HP 的 Guido Grillenmeier 一起创办了广受欢迎的 Active Directory 灾难恢复研讨会。Gil 也是“Directory 专家大会”的创始人 (www.dec2007.com)。


 Windows 管理: 为什么说 Windows XP Embedded 与您息息相关
Windows 管理 Don Jones

为什么说 Windows XP Embedded 与您息息相关
概览:
  • Windows XP Embedded 的组成
  • 特殊硬件选件
  • 自定义 Windows XP Embedded

Windows XP Embedded 是 Windows 的组件化版本，常与消费类电子设备（如机顶盒或机顶装置）关联使用。不过，Windows XP Embedded 也可在贵组织的信息技术阵营中发挥重要作用。虽然它可能不是每个客户的最佳解决方案，
但是，在某些特定环境中，它可以降低管理开销，节约资金，提供更紧凑的硬件，并带来更大的安全性。

什么是 Windows XP Embedded？
Windows® XP Embedded 是 Windows 三个紧凑型版本中的其中一个，另外两个分别是 Windows Embedded CE 和 Windows Embedded for Point of Service。在所有内嵌式 Windows 操作系统中，就安装到客户端计算机上的功能而言，只有 Windows XP Embedded 可以提供与 Windows XP Professional 相同的完整功能（或至少有潜力提供完整功能）。Windows XP Embedded 基于 Windows XP Professional Service Pack 2 (SP2)；但它与一般的 Windows XP 存在不同之处，它具有强大的模块化功能。Windows XP Embedded 没有所谓的标准安装映像。相反，您需要使用一个叫做 Windows Embedded Studio 的工具包，来为您正在构建的任何工具建立自定义的 Windows XP Embedded 环境，且此环境中仅包括您的设备所需的功能。如果您不需要 DirectX® 或 Windows Explorer，不安装它们便可。 在这里，模块化是指您所构建和部署的每个 Windows XP Embedded 映像将有更少的移动部件；也就是说，更容易管理，安全性更高，且能够在成本较低的硬件上运行。部分可用选件会在 Target Designer（Windows Embedded Studio 的一部分）中显示，如图 1 所示。
图 1 在 Target Designer 中选择组件
图 1 在 Target Designer 中选择组件

在企业中的应用
越来越多的用户方案适合基于 Windows XP Embedded 的设备。例如，维护大型客户服务呼叫中心的公司。很多情况下，呼叫中心的代表只需一个或两个内部开发的应用程序，或一个 Web 浏览器。他们仅使用计算机功能中很小的一部分。因此，Windows XP Embedded 可帮助将计算机的功能裁减至所需的功能。更少的功能意味着出错或受到安全攻击的可能性将减小。
因为 Windows XP Embedded 设备功能有限，因此可以在普通功能且价格较低的硬件上运行。很多制造商生产采用低功耗、Intel 兼容处理器的主板。这些主板体积极小、耗电非常少，且运行中散热很少，通常甚至不需要风扇。它们在紧凑型、只能运行有限应用程序的嵌入式设备上运作非常好。

Windows XP Embedded 的特殊强大功能
Windows XP Embedded 可提供一些非常有价值的选件，这些选件是 Windows XP 完整版中所没有的。Enhanced Write Filter (EWF) 和 Hibernate Once, Resume Many (HORM) 都可简化您的 Windows 管理任务。EWF 是一个可以添加到 Windows XP Embedded 部署中的可选组件，能够将指定磁盘卷设置为只读。对该指定磁盘的任何写操作都会转移到一个覆盖段；可将此覆盖段存放在其他磁盘，或者甚至可存放在内存中。操作系统本身会将 EWF 覆盖段及其父卷视为一个单独的单元，就像普通磁盘卷一样。但是在后台，父卷实际并未改变；只有 EWF 覆盖段发生了变化。在有些地方，这很有用。假设将一个 Windows XP Embedded 映像部署到 Compact Flash (CF) 卡（Windows XP Embedded 映像可只占据 5 MB 空间，签入时通常只占用大约 200 MB 空间，因此，CF 卡的存储空间相对就很大了）。可以通过适配器将 CF 卡接入主板的 IDE 连接器，这样 CF 卡就可以具有与普通硬盘同样的功能。目前的 CF 卡写入功能很有限（大约可写入 100,000 次），因此可利用 EWF 将 CF 卷设为只读。假设将 EWF 覆盖段放到 RAM 中：如果用户操作错误，只需执行关机操作。这样，EWF 覆盖段以及对计算机所做的任何改动都将立即消失。重新启动之后，CF 卡将返回存储的最初状态。您可以对基于 CD 或 DVD 的映像使用相同的设置；这些媒体类型本质上都是只读的，因此，EWF 可以将任何写入操作捕获到覆盖段。即使覆盖段存储在一个小的内部硬盘中，也可以确保原始的启动卷（在 CD 或 DVD 上）不会发生任何改动；如果需要将机器恢复至原始配置，仅需删除 EWF 覆盖段。
HORM，正如其名字所暗示的，允许您一次让计算机进入休眠状态，然后可多次从该休眠点处恢复。计算机可以迅速启动。简单的配置计算机并运行所需的所有应用程序，然后使计算机进入休眠状态。此后，每次打开计算机时，只需等待几秒即可启动并运行所有的应用程序。

构建 Windows XP Embedded 映像
Microsoft 发起了一项“嵌入式合作伙伴”计划，该计划包括专门开发 Windows XP Embedded 的所有公司（您可访问 microsoft.com/embedded 网站，在 Windows XP Embedded 的主页上找到这些公司）。然而，很多公司只为普通 PC 制造商提供预先设计好的映像（包括企业应用程序和特定配置）；因此，您可能想要构建您自己的 Windows XP Embedded 映像，以便与为您提供完整、紧凑型系统的“嵌入式合作伙伴”共享它们。安装于 Windows XP Professional 的 Windows Embedded Studio 可用来构建并管理 Windows XP Embedded 映像。
要使用此工具包，首先需在您计划要应用 Windows XP Embedded 系统的硬件上安装 Windows XP Pro 完整版。这样，您就可以使用完整的 Windows XP 安装例程来保证所有硬件正常运行。然后，安装 Windows Embedded Studio。这样就安装了一个用来管理嵌入式映像的数据库，而实际上，该数据库可以作为中央存储库安装在别处。接下来，您需要运行一个名为 Tap.exe 的命令行实用程序，这样可创建一个新的特殊组件，以供 Windows XP Embedded 使用。通常，组件包括各种功能，例如媒体播放机、文件系统或其他自定义应用程序；在本例中，您将创建一个包括硬件设备驱动程序（您的特殊系统需要）的组件。这一步骤必须在目标硬件上完成，这样该工具才可检测适当的硬件驱动程序并将它们包括在内。
下一步就是运行 Windows XP Embedded 组件设计器并导入由 Tap.exe 实用程序创建的组件包。如图 2 所示，组件设计器读取设备信息并组装一个完整的 Windows XP Embedded 组件。该组件将成为新的 Windows XP Embedded 映像的基础。这大大简化了准确确定给定平台所需设备驱动程序的流程。创建组件之后，您需要使用组件数据库管理器来将新的组件导入 Windows XP Embedded 组件数据库，所有已知的 Windows XP Embedded 组件均存储于此库中。将组件存在数据库中，将使其可用于 Windows XP Embedded 映像。
图 2 组件设计器
图 2 组件设计器
现在，您可以开始使用 Windows XP Embedded 目标设计器来创建新的目标配置。该工具将替您完成大部分实际工作。如图 1 所示，您可以添加任何组件来创建设备所需的一系列功能。您还需添加一些 Windows 核心组件，如 Windows 资源管理器（如果您的设备需要图形外壳程序）、NTFS 文件系统（或 FAT32）、NT Loader、语言支持、用户界面核心等等。系统默认的可用组件有一万多个。
您也可以预配置每个组件的设置。例如，可将用户界面核心组件自定义为显示 Windows“开始”菜单、桌面以及其他位置上的特定项。自定义每个组件的设置，可确保每个设备都根据您的需求来进行预配置（见图 3）。
图 3 自定义设置
图 3 自定义设置
Windows XP Embedded 映像中最棘手的部分就是依赖项。例如，要将 DirectX 组件添加到您的映像中，必须同时添加几个为 Windows 提供核心图形处理功能的组件。跟踪所有依赖项很困难，尤其对于较复杂、差不多有数千个依赖项的大型映像更是如此。组件数据库可解决这一问题。只要在目标设计器中按 F5 键，它就可以扫描每个已添加的组件，并将自动添加所列组件所需的任何依赖项。图 4 显示扫描正在进行中；扫描是将 Windows XP Embedded 高度模块化的关键步骤。如果没有目标设计器的这种智能，将很难成功地创建包括所有正确依赖项的映像。
图 4 依赖项检查
图 4 依赖项检查
添加所有组件及其依赖项之后，就可以构建 Windows XP Embedded 映像了。映像指的是需要复制到 Windows XP Embedded 设备引导卷中的文件。您不需要特殊的工具来部署它们（尽管 Windows XP Embedded 工具包包括一个远程引导服务器，具有类似于远程安装服务的功能，可将 Windows XP Embedded 映像部署到裸机硬件中）。完成这些步骤之后，您就可以看到映像的实际大小了。我曾创建过包括资源管理器外壳程序和几个应用程序（例如记事本和画图）的基本映像，也创建过不超过 90 MB 的映像。没错，您可能发现许多用户很少会对只运行记事本和画图的设备感兴趣，但它却能说明一个问题，即任务特定的映像所占的空间可以很小。

Windows XP Embedded 与 Windows XP
Windows XP Embedded 压根并非精简的操作系统选件。Microsoft 推出了预打包组件，这些组件可让运行 Windows XP Embedded 的计算机具有与 Windows XP 完整版相同的功能。其中包括 DirectX 9.0c、Microsoft® .NET Framework、Windows Media® Player 10 等安装选件。您还会发现很多描述如何构建自定义组件的开发人员文档（如代替资源管理器的自定义外壳程序），您可以借此为您的特定嵌入式设备创建合适的环境。
不过，Windows XP Embedded 并不提供 Windows XP Pro 完整版的所有功能。例如，Windows XP Embedded 中不包括 Windows 文件保护 (WFP)；也不包括一些用户友好功能（如 Windows XP Tour、初始欢迎屏幕，以及引导新用户配置计算机或进行 Windows 安装的向导等）。Windows XP Embedded 未采用 Windows 产品激活（Windows XP Embedded 映像是通过使用 Windows Embedded Studio 工具中的运行时产品密钥来激活的）。最明显的是，Windows XP Embedded 根本不使用 Windows Update，尽管其可以在您的环境中使用 Microsoft Software Update Services 服务器。最后，Windows XP Embedded 中也没有 Windows XP Pro 具有的 MSN® Explorer。
展望未来，Windows XP Embedded 仍存在广阔的开发前景：Feature Pack 2007 现已上市，增加了诸如基于 USB 的引导等新功能，这增强了 EWF 的功能，使得无需提交整个覆盖段即可将新文件提交至父卷；增加的内容还包括对 NTFS 压缩的支持等。通过不断增强，Windows XP Embedded 操作系统的灵活性得到持续提高，增加的选件也越来越多，它逐步能够与 Windows XP Professional 所拥有的功能相媲美。

构建嵌入式系统
构建嵌入式系统比构建传统的 Windows XP 系统需要作更多的工作，不过在某些方案中，嵌入式系统具有明显的优势。虽然 Windows XP Embedded 系统的功能减少了，但其所支持的硬件体积更小，功耗更低，更便于维护和维修，并且可以大幅度降低成本。更低的能耗有助于降低开销，减少热量生成，从而为设计紧凑的工作区提供更大的灵活性。Windows XP Embedded 除了用在预期的领域（消费设备、医疗设备、网亭以及其他您可能都没料到，但 Windows XP Embedded 却已被使用的地方）外，也会在您的企业中发挥重要的作用。

Don Jones 是 SAPIEN Technologies 的项目和服务主管，也是 Windows PowerShell: TFM（SAPIEN 出版社）的合著者之一。通过网站联系 Don，网址是 www.ScriptingAnswers.com。


 管理: 使用 System Center Capacity Planner 提前进行规划
管理 John Savill

使用 System Center Capacity Planner 提前进行规划
概览:
  • SCCP 基础
  • 创建新模型
  • 优化模型
  • 模拟实际用法

如今，基础结构组件对其支持的业务至关重要。但是，随着用户数量不断增加而公司变得日益分散，准确估计用于运行组件的服务器大小和
数量便日益成为一个难题。硬件不足会导致对最终用户的响应缓慢，而硬件太多则会浪费预算并增加管理负担。鉴于此，Microsoft 开发了 System Center Capacity Planner (SCCP) 2006。
使用 SCCP 可以在高水准上输入相关网络拓扑（位置、链接速度、延迟）、软件与硬件的信息，以及使用配置文件（如已发送邮件数量）。然后，SCCP 在不同的使用级别上进行模拟，列出详细的硬件和网络组件利用率。该模型可以帮助确定实施建议的配置是否能充分满足服务要求。
SCCP 无需在任何特定的服务器上运行或执行网络测试；其本质上是一款能够针对建模环境运行测试方案的模拟工具。SCCP 对系统的要求实际上很低：带有 Service Pack 2 (SP2) 的 Windows® XP、Windows Server® 2003 或带有 SP4 的 Windows 2000 外加 Microsoft® .NET Framework 2.0 即可。下一代 SCCP 预计可以与 Systems Management Server (SMS) 和 Microsoft Operations Manager (MOM) 更密切结合，自动收集某些信息，因为 MOM 已经收集了有关服务器利用率的信息，而 SMS 则维护有关硬件配置的信息。
安装 SCCP 2006 很简单；标准的安装向导只需接受许可协议以及确认安装文件夹。产品一旦安装，将会在“所有程序”菜单添加一个快捷方式。首次启动 SCCP 时，“Microsoft Capacity Planner Welcome”（欢迎来到 Microsoft Capacity Planner）屏幕将针对 Capacity Planner 全部四个组件中的三个提供访问，如图 1所示。
图 1 启动 Capacity Planner 工具
图 1 启动 Capacity Planner 工具
模型向导将询问一些有关所需环境的问题，以便创建系统体系结构模型 (SAM)。SAM 包括详细位置、用户、网络、使用模式和硬件。
通过向导或编辑器，可以使用模型编辑器对先前创建的 SAM 进行优化和修改。您可以在其中验证模型、显示模拟用法并测试其他方案，如邮件服务器的额外负荷或存在的远程用户。
Capacity Planner 预定义了许多可在 SAM 中使用的硬件类型。但是，如果您有不同的需求，Hardware Editor（硬件编辑器）还支持客户自定义硬件配置。
当选定一个模型后，Capacity Planner Simulation 允许针对所选模型执行各种测试，以确定其在真实环境下实施的可行性。
观察组件以及了解它们之间如何互操作的最佳方式，就是实际使用工具。我将首先启动该向导并运行模拟，然后通过添加自定义硬件来优化体系结构模型。在此演练中，我需要处理的是 Exchange 环境，但其过程与 MOM 相类似。

创建新模型
在规划的基础结构上执行验证或“假设分析”方案之前，或即使您只是想运行有关当前所部署基础结构的方案，也必须将环境描述给 SCCP。遗憾的是，在当前版本中不能只是简单地扫描网络。相反，必须从物理位置及其之间的连接类型、服务器的放置、邮箱与用户等不同方面来详细描述您的基础结构，并提供用户如何利用此环境的详细信息。
该工具有一些限制，这在用户指南中有详细说明。例如，在一个 Exchange 模型中，只支持单个林。这意味着不会对外部林中的域进行建模，并假定所有前端服务器在同一站点存储全局编录和邮箱。只能建模 100 个站点，其中最多 10 个中枢站点，最多 300 台服务器，只支持 Outlook® 2003 客户端（Web 或本地）。好消息是 SCCP 在中心/中枢位置可支持多达 49,999 个客户端，在分支位置最多支持 10,000 个客户端。不支持某些 Exchange 功能，例如 ActiveSync® 和 Outlook Mobile Access 连接以及原有连接选项如 POP 和 IMAP。由备份和还原操作引起的利用率以及群集配置都不考虑在内；但是，Capacity Planner 所要求的选项可以对日常邮件使用情况精确建模。
若要从“欢迎”页面开始演练，请选择“使用模型向导创建模型”并详细描述要建模的基础结构。我将要创建的公司有三个办公地点：Dallas 的总部以及分别在 Houston 和 Austin 的两个分支机构。三地都有大量的本地电子邮件用户。每个位置都无需必备自己的服务器，因此我提供了有关电子邮件用户数量和类型方面的信息；SCCP 将会计算本地 Exchange 服务器应置于何处以及用户从何处远程访问其 Exchange 服务器。
创建了企业基础结构的基本模型后，向导会询问中心站点和分支站点的数量、站点间的连接、传送邮件可占用的带宽百分比。该向导采取了一种广泛的方法使系统运行；稍后可以对向导创建的模型优化，以便更为精细地配置单独的链接。在该示例中，我可以确定一个总部和两个分支机构（见图 2）。在总部站点和分支站点之间是 T1 连接，该带宽的一半可用于传送邮件。因为只有一个中心站点，所以无需配置中心站点间的速度。
图 2 配置 WAN 拓扑和连接带宽
图 2 配置 WAN 拓扑和连接带宽
向导的下一个窗口会询问分支机构的平均用户数、电子邮件客户端（缓存模式下的 Outlook 2003 或 Outlook Web Access）以及中心站点的用户数。再次说明，这是非常高级的信息，稍后可以使用模型编辑器进行优化。在此案例中，我假定每个分支机构有 200 个用户，总部有 500 个用户，全部使用缓存模式下的 Outlook。
向导有三个默认的邮件使用级别：高、中和低。每个级别都假定一个不同的平均邮箱大小、已发送邮件数量和每个电子邮件的平均大小。如果内置类型与贵公司预期的使用模式不匹配，可针对四个不同使用性能的单个值分别予以配置。
下一步是配置硬件首选项，如图 3所示。SCCP 最多允许指定三个可能的 CPU 配置，这些配置将用于不同服务器角色的硬件型号。CPU 配置的范围从单处理器 1 GHz Pentium III Xeon 一直到四个处理器的 3.66 GHz Xeon MP。Exchange 2003 由许多角色组成，即 Mailbox Store、Bridgehead 和 Front End 以及一个附加的 Active Directory® Global Catalog 角色。如果利用率允许，该选项可用于将角色合并至更少的服务器。如果未指定服务器合并，则即使利用率没有要求，也会为每个角色配置单独的服务器。允许 SCCP 执行合并操作将提供最佳结果。
图 3 配置服务器的硬件配置文件
图 3 配置服务器的硬件配置文件
最后，可以基于接口、大小和速度来选择可用的磁盘类型。磁盘的数量不是必需的，Capacity Planner 可以自动计算这一数目。尽管目前创建群集的功能还不可用，Planner 也可用于指定存储区域网络 (SAN)。
向导的下一步是一个计算模型的摘要，将显示 SCCP 计算出的服务器最佳数量、每台服务器的角色以及诸如处理器、内存与磁盘配置等详细信息。如果选择了 SAN，也将予以显示。
请注意，因为我选择了多个位置，才有可能只显示位置子集的服务器。这是因为 SCCP 确定本地 Exchange 服务器在某些位置并不是最佳选择，而通过远程 Exchange 邮箱服务器使用邮箱效果更好，这就是本示例所要表达的内容，如图 4所示。在该案例中，400 个分支机构用户没有本地 Exchange 邮箱存储，而是被合并到位于 Dallas 的单个 Exchange 邮箱存储服务器上，该位置现在显示有 500 个用户。
图 4 初始容量规划评估摘要
图 4 初始容量规划评估摘要
到现在为止，我可以在向导上单击“上一步”和“下一步”按钮修改答案和优化模型摘要（或通过左导航窗格直接单击向导页）。当所有配置修改满意之后，单击“模型摘要”页上的“完成”按钮。就会打开模型编辑器中的模型，在这里可以进行更加精细的配置。

优化模型
模型向导是一款创建基础模型的出色工具。但是，除非各个位置都是相同的并达到平均数，否则就需要一些自定义模型以作为计算利用率真正有用的基准。常常是所有位置的用户数量有很大的不同，或可能具有不同的消息客户端组合，例如缓存模式下的一些 Outlook 2003 和一些 Outlook Web Access (OWA)。如果在模型向导中不能达这一详细程度，可以通过模型编辑器进行配置。当试图确定修改环境因素（例如添加其他位置或其他类型用户）的效果时，该工具也很有用。
模型编辑器（如图 5所示）在 .sam 文件中保存并检索模型，这是该工具的一个专有格式。执行任何操作都要养成良好的习惯，在重大更改之前将模型保存到文件，并使用描述性名称确保所操作模型不会丢失。“文件”菜单会提供一个“导出”菜单，能够以 Excel® 格式生成一个详细的摘要报告并作为模型的 Visio® 拓扑图。
图 5 在模型编辑器中调整 SAM 配置
图 5 在模型编辑器中调整 SAM 配置
模型编辑器的左窗格中是一个基本的导航区域，其中有一些选项可以用来查看全局拓扑、站点拓扑或模型摘要。全局拓扑从其他网络（如 Internet）的站点角度显示体系结构模型。站点拓扑视图显示有关选定站点或网络的信息。模型摘要显示环境的文本摘要，与您在模型向导结尾处将看到的格式相同。
无论选择了哪个选项，其详细信息将会在模型编辑器的中央窗格显示。右窗格位于新版本 Microsoft 管理控制台 (MMC) 的中心（MMC 在 Windows Server 2003 R2 内随附），是一个“操作”区，分为两个子区：上半部分提供上下文相关的操作，其变化取决于当前选定的视图或对象，而下半部分包含通用的常规操作。我可以使用后面的这些操作添加新站点、编辑用户的使用情况配置文件以及运行模拟。
当在模型编辑器的中央窗格操作时，可选择所有项目。选择一个项目后，除了当前项目操作随选定的对象变化外，我还可以向下浏览有关该对象的更多详细信息。例如，双击一个站点将切换到“站点拓扑”视图，并显示为该站点建模的对象的详细信息。因此，一个本地服务的站点将显示该位置的一个或多个服务器、网络和用户。反之，也可以双击选定对象查看其详细属性，并根据需要修改。
连接站点的线代表位置之间的网络，可以对其编辑以修正网络配置。例如，我可以指定不同的上行链路和下行链路带宽速度以及可用的带宽百分比。我们也可以配置连接延迟，对稳定通信来说，这是一个非常重要的属性。其他常见的更改包括添加其他用户类型。在本实例中，假定中心位置同时为 Outlook Web Access 和 Outlook 2003 客户端提供服务。在“站点拓扑”视图中打开 Dallas 后，我将选择“添加客户端配置文件”并添加有关基于 OWA 用户的信息，包括 OWA 客户端将使用的服务器、用户将连接的网络以及用户可使用的带宽，如图 6所示。
图 6 在模型中添加和修改元素很简单
图 6 在模型中添加和修改元素很简单
一旦 SAM 尽可能接近地反映现有或规划的基础结构，就以相应的名称进行保存，以确保可轻松地识别并将其作为将来修改的起点。在此，我倾向于运行模拟以得到模型在配置设置下执行的基准。根据该基准，我可以修改模型以测试各种“假设分析”方案，如添加新站点和用户、添加或删除服务器、在某些位置添加新用户、更改连接类型或电子邮件客户端类型。一旦使用这些新元素更新模型，就可用运行另外一个模拟查看新配置如何生效。

模拟实际用法
运行模拟非常简单，只需单击“运行”模拟常规操作或工具栏按钮。首先检查模型的运行状态：模型中的所有缺陷都将在执行模拟之前显示。例如，如果将大量 OWA 客户端添加到一个以前没有配置过 OWA 客户端和前端服务器的模型，将显示一条错误消息提示您不存在前端服务器。如果不存在此类缺陷，状态将显示为执行模拟。
一旦完成模拟，将生成一个详细的有关全部组件使用状况的信息报告，并将打开模拟结果视图。首先显示一个摘要视图，列出最高 CPU、存储和连接链路利用率（通常是瓶颈因素）以及最长事务和延迟时间的详细信息，这些会影响最终用户的体验。有关服务器、SAN、本地和外部连接确切利用率的详细信息，可以选择模拟结果左窗格中的链接进行查看，如图 7所示。
图 7 简单模型的模拟结果摘要
图 7 简单模型的模拟结果摘要
在所显示图形（如“瓶颈”分析）上按住鼠标，可以显示导致瓶颈现象的服务器及其属性。请注意左窗格的“阈值”设置。该类别允许在发出警告之前设置认为合理的使用，这是一个有用的功能。
详细的模拟报告很大，不仅仅有助于制定明智的硬件购买决策，还可以显示消息传送应用程序将使用的网络资源数量。例如，对于通过低速 WAN 链接的用户连接，报告将会指明该链接是否足够快速。如果不够快，那么只需修改模型并重新运行模拟来获得符合特定条件的结果，就可以查明不同位置间的链接速度是否应该升级或是否应该添加本地邮箱存储服务器。同样，如果服务器都在以 5％ 的 CPU 利用率运行，我可以降低服务器的规格。通过允许简单的模型修改和重新运行模拟的能力，我实际上可以自由体验不同的解决方案。掌握了来自所有测试方案中精确的指标数据后，我就可以充满信心的参加预算和规划会议了。

总结
我只是概述了一下 SCCP 如何帮助您模拟和分析 Exchange 部署。请记住，SCCP 也可以为 MOM 执行相同级别的建模和模拟操作。现在，SCCP 可以作为 MSDN® Premium 下载或 TechNet Plus 的一部分进行下载。 ¦

John Savill 是 Geniant 技术基础结构主管。他是一位 CISSP，Windows Server 2003 方面的安全和消息 MCSE，还是一位 eight-time MVP 和 Krav Maga 教师。他也是《Windows Server 2003 Active Directory 设计与实施》一书的作者，您可以从 Packt Publishing 处获取该书信息。


 管理: 使用 SMS 的高级客户端清单
管理 Wes Dobry

使用 SMS 的高级客户端清单
概览:
  • 使用 SMS 2003 硬件清单代理
  • 使用 MIF 文件扩展清单
  • 动态 MOF 文件与静态 MOF 文件对比
下载这篇文章的代码: DobrySMSInventory2007_04.exe (152KB)

每个管理员都经常遇到这样的情形：上司需要一些信息，而这些信息不经过艰巨的努力就无法收集到。但是，作为一名工作积极主动的管理员，
如果您已经收集这些数据，就可以立即为上司提供信息，从而避免不必要的停工时间和加班时间，甚至可能为公司节省一大笔开支。您可以成为公司的英雄。
现成的 Microsoft® Systems Management Server ( SMS ) 2003 就可以收集大量的信息。但不是所有的信息。例如，在默认情况下，SMS 2003 不报告本地组及其成员信息，或者本地用户及其属性信息。缺少这方面的信息可能会产生问题。比如说，当一名技术人员正将域用户或（甚至更糟的是）将每个用户名输入到他们工作的每个系统的本地管理员组中，这时麻烦就来了。或者，假设一家公司无法知道其公司反病毒/反间谍软件解决方案的排除列表中应该包括哪些本地文件和文件夹。这看起来可能不是一个大问题 — 直到有 IT 人员发现用户在排除列表中输入 c:\*.*。
凭借脚本、Windows® Management Instrumentation (WMI) 和 SMS 知识的正确组合，您可以扩展 SMS 清单，从而包含几乎所有的详细信息。通过使用 MIF（管理信息格式）和 MOF（管理对象格式）文件即可实现这一点。

盘查
凭借 SMS，各组织可以进行自定义部署、监控目标以及维护部署的系统。通过扩展 SMS 清单，您可以创建和管理自定义程度高得多的目标。例如，您可以通过对系统（用户修改其策略）部署安全策略来强制执行公司本地安全策略。也可以禁用未经授权的本地用户帐户，并删除无关的本地管理员。
当然，各组织也依赖 SMS 及时获得有关客户端系统的详细信息。扩展清单允许您创建报告，报告中包含完整的自定义信息，仅依靠默认清单不容易获得。而且这些信息可以非常详细。例如，您可能会创建一个报告，内容包含拥有某特定注册表项指向某一特定服务器场的系统数。这样管理员就可以估计在任意指定时间每个服务器场大约有多少客户端在指向它。类似地，安全团队就能够检查网络上哪些系统运行着已知为间谍软件的特定进程。
MIF 和 MOF 文件的价值在于只需要很少的转换就能够从几乎任何来源输入信息。只要信息是基于文本的，就可以使用 MOF 文件处理信息并将其置入 WMI 中，或以 MIF 文件的格式进行收集，并在下一个硬件清单周期发送。实现清单扩展需要 VBScript 或 JScript® 方面的知识，同时也需要了解关于要收集的信息的知识。考虑到可收集的信息非常广泛，所以需要具备从 WMI 到高级 SQL 等各方面的知识。当然，由于报告收集的数据时需要 SQL 方面的知识，所以无论要收集什么类型的信息，都必须了解 SQL。

清单工作原理
SMS 包含两类清单进程：硬件和软件。软件清单进程只包括与文件有关的信息，如文件的位置、版本、大小及其他文件属性。不过，软件清单进程还允许您收集文件并将其存储在站点服务器上。
硬件清单扩展很容易实现，因为硬件清单包含有关系统信息的最大阵列。硬件清单中的信息主要来自 WMI、注册表和系统 BIOS。
硬件清单按计划表收集信息，计划表在 SMS 2003 的硬件清单代理站点设置中进行设置。收集的频率可以设置为频繁至每分钟一次，也可以不频繁至每几个月一次。通常要在两者之间取得平衡：根据管理的需要以最快的速率收集信息，同时不使网络、站点服务器、管理点或客户端负担过重。
当第一次安装硬件清单代理时，会编译 sms_def.mof 文件。此文件包含 SMS 最初收集的所有信息。当编译此文件时，硬件清单列表代理所需的所有 SMS 命名空间和相关的类都在 WMI 中创建。这些大部分位于 \\.\root\CIMv2\SMS 命名空间。安装后，硬件清单代理遍历大多数类建立相关信息。然后，这些信息会发送到管理点，并最终发送到站点数据库。

MIF 文件
除了从这些 WMI 类中提取信息，硬件清单代理会在 NOIDMIF 和 IDMIF 收藏文件夹中寻找 MIF 文件。代理在这些位置找到的任何 MIF 文件经过处理会进入下一个硬件清单中。
MIF 文件提供最简单的方法来扩展 SMS 硬件清单。有两种类型的 MIF 文件 — NOIDMIF 和 IDMIF 文件。这些文件是静态的、类似 XML 的文件，它们包含几乎所有用户可能想要输入 SMS 数据库的信息。可以用创建普通文本文件的任意一种方式创建 MIF 文件。因此，这些文件可以用大多数脚本语言创建，或者仅仅手动创建。
通常，MIF 文件用于信息未包含在注册表或 WMI 中的情况，或者信息需要手动输入时。例如，当硬件部署团队提供了一个新系统时，就可以创建这些文件。部署技术人员可以导航至系统上的 HTML 应用程序，并输入所有用于更新资产管理数据库的资产信息。然后该应用程序动态创建一个 NOIDMIF 文件，并允许技术人员下载该文件到 NOIDMIF 文件的收藏文件夹中。此 NOIDMIF 文件可包含所有技术人员输入的信息，并且融进 SMS 数据库中。
NOIDMIF 文件和 IDMIF 文件只有少许不同。IDMIF 文件包含一个唯一的标头，用于提供体系结构信息和唯一的 ID。IDMIF 文件可用于将非系统设备合并到 SMS 中作为其自己的实体。例如，脚本可用于创建 SMS 中实际上是打印机的系统，并将关于它们的信息写入 SMS 数据库中。
NOIDMIF 和 IDMIF 文件均存储于标准位置，这些位置由注册表项规定。在大多数情况下，假定 SMS 代理安装于默认位置，那么它们应位于 %SYSTEMROOT%\system32\ccm\Inventory\NOIDMIF 和 ...\IDMIF。如果代理安装于自定义位置，那么 MIF 目录应位于 %CCMAGENTINSTALLDIR%\Inventory\NOIDMIF 和 ...\IDMIF。如果对这些目录的位置有什么疑问，可以到列出的以下注册表项中查找位置：
HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\NOIDMIF Directory

HKEY_LOCAL_MACHINE\Software\Microsoft\SMS\
Client\Configuration\Client Properties\IDMIF Directory
无论收集的是什么信息，MIF 文件始终保持相同的格式。请参阅图 1 中所示 MIF 文件，该文件由一个单独的组件组成，该组件包含多个组，每个组有一个单独的属性。虽然您可能只需要一个组或一个属性条目，但是所有的组和属性都是必需的。您可以将 MIF 文件中的每一组看作硬件清单中命名部分数据中的一行，组中的每个属性是该行中的一列。
Figure 1 LocalAdmins.mif (Close Figure 1)
Start Component
  Name = “WORKSTATION”
    Start Group
        Name = “Local Admins”
        ID = 1
        Class = “Microsoft|LocalAdminsMIF|1.0”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Domain Admins’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 2
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Contoso’,Name=’Technicians’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 3
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’Administrator’”
        End Attribute
    End Group
    Start Group
        Name = “Local Admins”
        ID = 4
        Class = “Microsoft|LocalAdminsMIF”
        Start Attribute
            Name = “Account”
            ID = 1
            ACCESS = READ-ONLY
            Storage = Specific
            Type = String(100)
            Value = “Win32_UserAccount.Domain=’Example-PC’,Name=’RandomUser’”
        End Attribute
    End Group
End Component
图 2 所示的示例 LocalAdmin.vbs 是一个非常简单的 VBScript。它查找 NOIDMIF 目录，如果存在临时的 MIF 文件则删除它，并创建新的临时 MIF 文件，通过一个简单的 WMI 递归查询搜集信息并写入到该文件中，删除 NOIDMIF 收藏文件夹中现有的 MIF 文件，最终将临时 NOIDMIF 移动到 NOIDMIF 收藏文件夹中。
Figure 2 LocalAdmin.vbs (Close Figure 2)
On Error Resume Next

Const ForAppending = 8

Set objWshShell = CreateObject(“WScript.Shell”)
Set objFSO = CreateObject(“Scripting.FileSystemObject”)

strTempDir = objWshShell.ExpandEnvironmentStrings(“%TEMP%”)
strWinDir = objWshShell.ExpandEnvironmentStrings(“%WINDIR%”)
strComputerName = objWshShell.ExpandEnvironmentStrings(“%COMPUTERNAME%”)
strNoIDMifRegLocation = “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\Client\Configuration\Client “ _
   & “Properties\NOIDMIF Directory”
strNoIDMifDirectory = objWshShell.RegRead(strNoIDMifRegLocation)
strMifFileName = “\LocalAdmins.mif”
strClassID = “Microsoft|LocalAdminsMIF|1.0”

If objFSO.FileExists(strTempDir & strMifFile) Then
   objFSO.DeleteFile(strTempDir & strMifFile)
End If

Set objMifFile = objFSO.OpenTextFile(strTempDir & strMifFileName, ForAppending, True)

objMifFile.Writeline “Start Component”
objMifFile.Writeline “ Name = “ & Chr(34) & “WORKSTATION” & Chr(34)

strWBEMQuery = “SELECT partcomponent FROM win32_groupuser WHERE groupcomponent = “ & Chr(34) _
   & “\\\\” & strComputerName & “\\root\\cimv2:Win32_Group.Domain=\” & Chr(34) & strComputerName _
   & “\” & Chr(34) & “,Name=\” & Chr(34) & “Administrators\” & Chr(34) & Chr(34)

Set objWBEM = CreateObject(“WbemScripting.SWbemLocator”)
Set objWBEMServer = objWBEM.ConnectServer(, “root\cimv2”)
Set colResults = objWBEMServer.ExecQuery(strWBEMQuery)

i = 1
For Each objItem in colResults
         objMifFile.Writeline “ Start Group”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Local Admins” & Chr(34)
         objMifFile.Writeline “ ID = “ & i
         objMifFile.Writeline “ Class = “ & Chr(34) & strClassID & Chr(34)
         objMifFile.Writeline “ Start Attribute”
         objMifFile.Writeline “ Name = “ & Chr(34) & “Account” & Chr(34)
         objMifFile.Writeline “ ID = 1”
         objMifFile.Writeline “ ACCESS = READ-ONLY”
         objMifFile.Writeline “ Storage = Specific”
         objMifFile.Writeline “ Type = String(100)”
         strUserName = objItem.PartComponent
         strUserName = mid(strUserName, instr(1, strUserName, chr(58)) + 1)
         If Instr(1, strUserName, Chr(92), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(92), Chr(92) & Chr(92), 1, -1, 1)
         End If
         If Instr(1, strUserName, Chr(34), 1) > 0 Then
                  strUserName = Replace(strUserName, Chr(34), Chr(39), 1, -1, 1)
         End If

         objMifFile.Writeline “ Value = “ & Chr(34) & strUserName & Chr(34)
         objMifFile.Writeline “ End Attribute”
         objMifFile.Writeline “ End Group”
         i = i + 1
Next

objMifFile.Writeline “End Component”
objMifFile.Close

If objFSO.FileExists(strNoIDMifDir & strMifFileName) Then
   objFSO.DeleteFile(strNoIDMifDir & strMifFileName)
End If

objFSO.MoveFile strTempDir & strMifFileName, strNoIDMifDir & strMifFileName
尽管 MIF 文件提供了最简单的方法来扩展 SMS 硬件清单，但是在使用它们时还有一些问题需要考虑。在每个硬件清单周期中都会处理 MIF 文件。但是既然这些文件被创建、收集、分析并最终放入清单中，那么 MIF 中包含的信息在清单中的显示可以最多推迟一个硬件清单周期。这意味着如果一家公司的硬件清单周期是一天，则站点数据库中的数据最多可能滞后两天。因此，您必须认真考虑创建 MIF 文件的程序何时得到通告，硬件清单周期何时运行。
假设一家名为 Contoso 的公司的清单周期是一天，并且在每天午夜运行。在星期一凌晨 1:00 运行 VBScript，创建一个包含 Rootkit 扫描程序输出的 NOIDMIF 文件。此输出结果在午夜收集并报告给管理点。接下来，Contoso 公司的 SMS 管理员在星期三晚上大约 10:00 查看这些信息，发现这些信息晚了 45 个小时。这是由于 SMS 管理员没有考虑应该在什么时间通告程序创建 NOIDMIF 文件。

MOF 文件
MOF 文件比 MIF 文件复杂的多。它们比 MIF 文件有优势，因为 MOF 文件直接向 WMI 中输入信息，并且使自己成为硬件清单代理的标准数据收集过程的一部分。因此，您不必反复通告 VBscript 来收集信息，这样既节省时间，又避免麻烦。相反每台计算机只需要通告 MOF 一次即可编译 MOF 文件。
MOF 文件还有一个优势就是其信息与硬件清单中的其他信息一样都是尽可能最新的。每次硬件清单代理经历其周期时，会要求类和提供程序详查 MOF 文件并迅速返回信息。当您需要迅速得到信息时，可以执行包含 MOF 文件和 VBScript 的程序包，从而启动一个硬件清单。接下来，很快就能获得您需要的信息，所花费的时间与通告程序政策周期一样短。
MOF 文件分为三类：用于现有的 WMI 类和命名空间的 MOF 文件、用于现有 WMI 提供程序的其他类的 MOF 文件以及用于没有 WMI 提供程序的其他类的 MOF 文件。
MOF 文件包含两部分。第一部分是命名空间定义部分。在这里标识 WMI 提供程序的信息。第二部分包含 SMS 报告属性。此部分告知硬件清单代理查找并处理上述 WMI 类中包含信息的位置。由于 MOF 文件直接处理 WMI，如果您打算使用这些文件，我们建议您花一些时间研究一下 Microsoft WMI 软件开发工具包 ( SDK )（请参阅 go.microsoft.com/fwlink/?LinkID=83121 以获得更多信息）。
上述每一类 MOF 文件可以是静态的，也可以是动态的。例如，如果把公司的构建过程编译成 MOF 文件（包括谁构建该系统、使用的服务器版本、最初的构建版本是什么、计算机构建的日期等），将会得到一个静态的 MOF 文件。这些信息从不需要更新，因此可以直接输入到 MOF 文件中，并通过使用 mofcomp.exe 编译到 WMI 中。完成这些后，通过向站点服务器的 sms_def.mof 文件中加入组和类信息，使硬件清单代理寻找的范围扩大。
动态 MOF 文件与静态 MOF 文件类似，除了它通过 WMI 提供程序来收集信息，而不是直接把收集到的信息写入 WMI 中。WMI 提供程序是一种插件，允许应用程序或服务直接输入信息到 WMI 中。此提供程序允许动态访问 WMI 和系统的其他区域，例如注册表、文件位置和 Windows Installer 信息。
关于使用 MOF 文件，增强硬件清单最简单的方法就是让清单目录显示更多的信息，而这些信息已经存在于 WMI 中。通过扩展 sms_def.mof 文件，或开启其他当前禁用的报告类，就可以实现上述功能。sms_def.mof 文件位于 \\siteserver\SMS_<sitecode>\inboxes\clifiles.src\hinv 文件夹。公司的所有设备都将在其下一个计算机策略周期引入新的 sms_def.mof 文件，并开始收集和报告信息。
另一方面，考虑到困难因素，使用现有的 WMI 提供程序，而不是创建一个新类。这种方法的一个示例如图 3 所示。在本例中，通过使用内置的注册表提供程序，在本地设备上创建类 CU_Desktop 和一个查询 HKEY_CURRENT_USER\Control Panel\Desktop\Wallpaper 的动态属性。此 MOF 文件在客户端编译后，SMS_Def_Extension.mof 中包含的信息（请参阅图 4）需要添加到 sms_def.mof 中。文件包含下列内容：SMS 是否应该报告该信息、组名、类 ID、硬件清单代理应该在 WMI 中查找哪些类从而找到要报告的信息以及（最后）实际值。
Figure 4 SMS_Def_Extentions.mof (Close Figure 4)
#pragma namespace ("\\\\.\\root\\CIMv2\\sms")
 [ SMS_Report    (TRUE),
  SMS_Group_Name ("Current User Desktop"),
  SMS_Class_ID   ("MICROSOFT|CU_Desktop|1.0") ]
class Power_Mgmt : SMS_Class_Template
{
    [SMS_Report(TRUE),key]
        string  index;
    [SMS_Report(TRUE)]
    sint32   CurrentUserDesktop;
};
Figure 3 CurrentUserDesktop.mof (Close Figure 3)
#pragma namespace(“\\\\.\\root\\CIMv2”)
// Registry property provider
instance of __Win32Provider as $PropProv
{
    Name    =”RegPropProv” ;
    ClsID   = “{72967901-68EC-11d0-B729-00AA0062CBB7}”;
    ImpersonationLevel = 1;
    PerUserInitialization = “FALSE”;
};
instance of __PropertyProviderRegistration
{
    Provider       =$PropProv;
    SupportsPut    =TRUE;
    SupportsGet    =TRUE;
};
[DYNPROPS]
class CU_Desktop
{
    [key]
    string  index = “current”;
    sint32 CurrentUserDesktop;
};
[DYNPROPS]
instance of CU_Desktop
{
     [PropertyContext(“local|HKEY_CURRENT_USER\\Control Panel\\Desktop|Wallpaper”),
        Dynamic, Provider(“RegPropProv”)]
        CurrentUserDesktop;
};
MOF 文件也能够访问 WMI 提供程序所提供的信息，而在系统默认状态下未包含这些信息。为了使用这些提供程序，在客户端编译 MOF 文件和扩展 sms_def.mof 文件前，必须首先分发和安装 WMI 提供程序。

总结
MIF 和 MOF 文件是快速收集实质性信息的强大工具。这些文件格式提供了框架，不必直接修改表格，即可轻松地向 SMS 数据库引入信息。只要想象得到的，几乎所有信息都可以盘查并报告。更为可喜的是，管理员能够积极主动的收集重要信息，避免出现问题。
了解 MIF 和 MOF 文件需要花一些时间。不过，我们会提供有帮助的资源，帮助您学习如何使用这些文件。对于初学者，请参阅 WMI 文档和 SDK，以及 Systems Management Server 2003 操作指南。只要您付出努力了解这些概念，您从扩展的 SMS 清单中的获益将远远物超所值。

Wes Dobry 住在佛罗里达州的奥兰多市。他为那里的一家大型医疗保健公司工作，职务是顾问兼网络管理员。他的联系方式是 wesdobry@wesdobry.com。


 管理: 采用 SMS 2003 R2 部署自定义软件更新
管理 Steve Rachui

采用 SMS 2003 R2 部署自定义软件更新
概览:
  • SMS 2003 R2 中全新的更新管理功能
  • 自定义更新发布工具
  • 自定义更新清单工具

当您需要为自己的系统部署自定义更新时，比如拿专用硬件或行业应用程序来说，很难拥有像 Windows 更新所具备的那种可管理、自动化流程优势。至少以前没有。现在，由于有了 Systems Management
Server (SMS) 2003 R2，您可以使用相同的管理更新功能部署您自己的自定义更新。SMS 2003 R2 拥有一系列新功能，其中包括对设备管理功能包的更新、指向操作系统部署 (OSD) 功能包的链接，以及其他一些增强安全监控能力的功能。该产品还有一个用来进行安全漏洞评估的扫描工具，这种工具对了解系统和网络中潜在的漏洞（如操作系统配置、用户密码、IIS 以及 SQL Server™ 配置的缺陷）至关重要。此外，该产品还包括自定义更新清单工具 (ITCU) 和自定义更新发布工具 (CUPT)。本文中，我将着重通过介绍这两种工具，来谈谈如何轻松而有效地部署自定义更新。

自定义更新发布工具
安装和使用 SMS 2003 R2 之前，首先要将包括客户端在内的层次结构更新到 SMS 2003 Service Pack 2 (SP2)。要使用 CUPT，您需更新到 Microsoft® Management Console (MMC) 3.0。您不必在 SMS 站点服务器上安装 CUPT，但至少要将其安装在 Windows® XP 中，且它还需要 SQL Server 2005 以承载其数据库；如果没有 SQL Server 2005，则必须安装 SQL Server Express Edition。CUPT 是 SMS 系统中引进和管理自定义更新的关键，在 SMS 中发布已创建的目录之前，它还能够先对这些目录进行测试。
自定义更新有两种形式 — 第三方供应商为他们生产的软件提供的更新，以及内部专为某一特定环境创建的更新。CUPT 是用来管理这两种更新的工具。使用第三方提供的自定义更新最为简便，因此我们就从这里说起。编写本文之时，有三个公司在生产可用来在 SMS 中扫描和分配适当补丁的更新目录，它们是 Adobe、1e 和 Citrix。选择自定义更新合作伙伴目录，可查看参与公司，如图 1 所示。
图 1 CUPT 操作
图 1 CUPT 操作
使用合作伙伴提供的更新很简单，只需下载目录并将其添加到 SMS 中即可。首先下载所需的更新，然后选择“操作”菜单上的选项导入更新。这时会出现一个向导，询问刚下载的 .cab 文件的位置。在向导中指定该文件的位置后，新的更新将显示在 CUPT 中，可对它们进行进一步的配置并发布到 SMS 站点服务器上。但是请注意，必须标记每个所需的更新以进行发布。如果某个更新没有被标记，则在发出发布请求的时候，它将不会被包含在其中。这一操作可以批量执行，如图 2 所示。注意，较右边的一列必须有做的标记，这样才能保证更新的正常发布。
图 2 设置发布标记
图 2 设置发布标记
如有需要，您可以进一步自定义下载的每个更新。若要自定义，只需选中更新并选择“编辑”即可进行。然而，自定义更新时需留心，因为不合适的配置会导致意想不到或不尽人意的结果。
对更新进行标记之后，就可以发布了。这一过程可以通过两种途径来实现 － 发布到外部 .cab 文件以备今后使用；或将选中的更新与 SMS 站点数据库同步，以供当前使用。为了实现与 SMS 站点数据库的同步，您需要提供配置信息，如站点服务器的名称、程序包源文件的路径等（见图 3）。
图 3 同步信息
图 3 同步信息
突出显示“自定义更新”节点，然后从“操作”菜单中选择“设置”，这样可找到这个屏幕。等您提供可访问站点服务器的名称、指向自定义更新清单工具的源目录路径之后，站点代码和状态就被更新了。
通过设置同步选项，CUPT 可以实现与 SMS 站点服务器的同步。要执行同步操作，从“操作”菜单中选择发布更新选项。这将启动发布向导。为了将更新发布到 SMS 数据库以供当前使用，请确保已选中与 Systems Management Server 站点数据库同步的选项。值得庆幸的是，该步骤伴有可视化提示：如果尚未配置同步设置，则该选项灰显。
完成向导所提示的操作之后，就可以在 SMS 管理控制台上执行自定义更新了。启动分发软件更新向导之后，会出现一个可用来操作所有可用自定义更新的选项。
通过上述内容，您已经看到了消费和使用第三方产品的供应商生产更新的过程，假设没有预先打包的更新可供使用，那供应商所提供的软件的自定义更新又如何呢？这就是 CUPT 的优势所在。借助 CUPT，您可以创建包括所有目标条件的自定义更新来满足任何情况。
创建自定义更新并不困难，但要求管理员必须了解如何为软件打补丁、使用什么条件来确定补丁是否可用，以及应使用什么目标规则来集中更新。目标规则是在更新创建过程中分别定义的。这些定义可通过选择“操作”菜单中的“管理规则”选项查看。
选择“操作”菜单中的“创建更新”选项，可启动自定义更新创建，随即会出现一个向导，您可通过此向导提供自定义更新的详细信息。本文并未具体讨论如何创建自定义更新，但文中涉及的为导入的一个自定义第三方更新选择属性的内容，具有一定的启发作用，可帮助您了解创建自己的更新时每个字段所需的内容。已配置的第三方更新的属性如图 4 所示。
图 4 第三方更新的属性
图 4 第三方更新的属性
借助自定义更新创建流程，您可以实现除更新之外的更多功能；您还可以配置要分配给客户端系统的软件。尽管这种方法可行，但务必要注意，它既不是推荐方法，也不是 CUPT 的预定用途。

自定义更新清单工具
ITCU 是一种适用于自定义更新目录的新清单工具。与它之前的扫描工具一样，ITCU 可以创建自定义集合、数据包、以及用于将扫描工具部署到企业中 SMS 客户端的公告。与使用之前的扫描工具一样，ITCU 可以从一个可访问的 SMS 分发点检索目录（本例中指自定义更新目录）、可以基于目录数据执行扫描、可将扫描得到的结果插入 Windows Management Instrumentation (WMI)，还可以通过硬件清单报告这些结果。扫描流程中主要的区别在于所用的目录。
SMS 2003 R2 的推出为现有的 SMS 安全体系增加了一个强大的工具。之前，管理员无法借助现有的 SMS 基础设施来为第三方和自定义应用程序打补丁。SMS R2 的推出因此而备受补丁管理管理员的青睐。
这样，您现在就有两种工具可供选择，来处理 Microsoft 之外的其他资源的软件更新。CUPT 和 ITCU 提供出色的可管理性和便利性，保证您的自定义更新会与您已经使用的 Windows 更新一样顺利完成。
更新管理资源
  • TechNet：更新管理
  • Webcast： IT's Showtime - SMS 2003 R2
  • Microsoft Patch Management 的十个准则

Steve Rachui 是 Microsoft 产品支持服务团队的一员，是一位负责提供可管理性支持的专家级工程师。他从 SMS 1.2 版开始为 SMS 提供支持。Steve 的联系电子邮件地址为 steverac@microsoft.com。


 编辑视角: 我们也可能出错......
编辑视角
我们也可能出错......

主要区别之一 印刷和 Web 的主要区别之一是一些东西一旦被印刷，我们就永远不能修改了。当在 Web 上发布一些信息花絮并且需要以后更新它时，只需登录即可更改需要更新的内容。没有比这更明智的了。
当然，印刷则是另一回事。一旦将一些东西送去印刷，就没有回旋的余地了。成千上万的副本被印刷出来，我们所写的一切将会在图书馆保存到最后（或者到下一个清理日）。同样，印刷常常会提供自然更新的版本，并且您知道最新的版本将会有最新的新闻和文章。
现在我们在杂志出版后也将其全部放在网上，这产生了一个新的问题。从进行在线搜索的用户的角度来看，网站上的所有内容将同时展现在他面前。那么怎样才能知道您正在查看的是不是最新的指南呢？
为了解决这一问题，几年前我们制定了一个修正政策，这一政策通过可以在线联系读者的能力，独特地改善了我们的印刷产品。在 TechNet 杂志的修正页面，您将看到我们在文章印刷后对其所做的每一处改动的完整信息。我们会标记更新片段的五个原因之一：技术、编辑、新信息、过时和安全。
例如，我们于 2006 年 5 月印刷的名为《Techniques for Simplifying Desktop Image Creation》（简化桌面图象创建的技巧）的文章中提到了一个名为 CNIC 的工具，这一工具在那时尚未可用。当 CNIC 可用后，我们在修正页面添加了更新，并对在线发布的文章添加了编者更新。单击编者更新链接即可直接转至新信息。
正如您所见，尽管 TechNet 杂志的印刷问题每月更新，修正政策帮助我们确保文章经过一段时间后仍然保持其相关性。-JOSHUA TRUPIN

衷心感谢以下 Microsoft 技术专家： Luis Botero、Derek Del Conte、John Doyle、David Feldman、Scott Hinsley、Jesper Johansson、Brian Mohr、Michael Murgolo、John Orefice、Mark Russinovich、Matt Steele、Fergus Stewart、Jason Stolarczyk、Jim Truher 和 Alan von Weltin。


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

文件和目录同步
Allway Sync
allwaysync.com

无论您从事什么样的 IT 工作，您都有可能花费大量时间在不同位置间移动文件和目录 — 或者从台式机移动到 USB key，或者在网络上的服务器之间移动。通常，保持这些目录同步非常重要，这样可确保您不会创建不必要的副本，且可确保您当前操作的是最新版本的文件。有时可能需要在多台计算机之间同步文件和目录，比如在多台 Web 服务器间部署静态 XML 或 HTML 文件时。Usov Lab 推出的 Allway Sync 对处理这类任务是非常有用的工具。
Allway Sync 提供了正真的多种同步方式，从文件和目录的单向复制到多目录双向选项，不一而同。该应用程序不仅能使本地驱动器和网络资源同步，而且还支持自动同步可移动设备，如 USB key 和可写光驱。您可以设置使 Allway Sync 在设备连接到计算机时自动启动。
其他用于同步的自动启动选项包括：当检测到文件更改时启动、当登录或注销时启动、在 Allway Sync 启动的条件下经过特定的时间间隔后启动。您甚至可以通过该应用程序的 GUI 将同步设定为计划任务。
使用 Allway Sync 同步文件和文件夹
使用 Allway Sync 同步文件和文件夹
Allway Sync 的本地数据库中会记录所有的文件修改和删除，该应用程序提供了很多选项用于对已修改文件进行版本控制、对冲突文件进行删除；对冲突文件的删除包括永久删除项目、将项目移动到回收站或移动到特定文件夹。
对每个作业，您可以指定多个包括或排除筛选器，以得到所需的文件，而忽略不需要的文件。您也可以自定义当遇到警告或错误时希望 Allway Sync 采取的操作、为每种警告或错误配置不同的操作。例如，您可以选择在错误事件中自动重试副本；您不但可以配置自动重试的次数，还可以配置两次重试之间的时延，以应对任意的网络延时或短期连接问题。
您可以配置该应用程序的日志功能详细级别，以确保得到有关作业的最详细信息。可通过 XML 将该应用程序的设置导入和导出，因此，可很容易的将这些设置进行备份或传输到其他的计算机。为了满足人们挑剔的好奇心，该应用程序还简单提供了一个使用情况统计窗口（可通过“帮助”菜单访问）。这个方便的工具很容易就可以同步文件，也很便宜。
价格：个人使用免费。商业使用 29.99 美元。

映射和监控网络
LANState Pro
10-strike.com/lanstate

快速得知网络资源的状态和可用性对主动的 IT 操作环境是至关重要的。当出现问题时，您需要先于所有人了解它。10-Strike Software 推出的 LANState Pro 网络映射器和监控器，能够对基于 Windows® 的网络进行快速可视化检查和 LAN 管理，可为您提供帮助。
当启动该应用程序开始监控网络时，您可以选择“网络映射向导”，使用它可以扫描“网上邻居”或可用主机的 IP 地址范围。如果愿意，您可以手动在主机中添加。一旦创建了网络映射，LANState 将自动开始检查配置的状态，如 TCP 端口检查或 ICMP ping 检查。响应的主机以彩色编码，而不响应的主机则灰显。然后，您可以将映射安排到适合配置的逻辑分组、可以更改任意可见的元素以及添加描述等。
使用 LANState Pro 创建逻辑网络分组
使用 LANState Pro 创建逻辑网络分组
画图和编辑工具有点粗糙，但一旦完成映射，便可以将映射保存到文件，不用重新创建。除了 TCP 端口和 ICMP ping 检查外，您可以配置 LANState Pro 来检查以下项目：文件夹或文件的存在、文件的大小，以及在一个可配置的时间间隔和超时时间内远程主机上有多少空闲磁盘空间。右键单击主机将出现一个上下文菜单，通过此菜单，您可以从远程主机收集更多的系统信息、执行路由跟踪、发送 ping、执行默认检查或发送网络邮件。
系统信息视图会显示从 NIC MAC 地址和绑定 IP 地址到网络共享、服务和本地帐户的所有信息。大多数操作系统级别的信息需要远程系统上的相应权限和开放端口，不过，您可以通过 RPC 调用获得很多有用信息。即使您没有这些权限，您也可以向远程主机发送远程开关机信号。
价格：单用户许可证为 249.95 美元。

命令行脚本
书评
www.syngress.com

交互式向导和配置 GUI 可以真正简化复杂任务。但当您是 IT 专业人士时，这些界面使用起来就相对较慢，并且不能为手边的任务提供始终充分的测度或控制。值得庆幸的是，这种级别的控制几乎总是可以通过命令行接口 (CLI) 实现。熟知 Windows 附带的工具并了解如何自定义命令提示符简化管理任务，可节约时间、提高效率并进行更精确的控制。Pawan K. Bhardwaj 编写的《How to Cheat at Windows System Administration Using Command Line Scripts》（如何使用命令行脚本在 Windows 系统管理中讨巧）（Syngress 2006 年出版）一书可以帮助您掌握 CLI 和操作系统工具。
该书全面讲述了命令外壳的自定义、使用批处理文件进行自动处理和批处理，以及计划任务的 CLI 管理。该书还介绍了 Windows 操作系统附带的实用程序，可以帮助您管理磁盘、文件和目录；掌握上述内容后，您可进一步学习这些实用程序。该书中还概述了目录服务命令（如 DSQuery 和 DSMod），结合您在前面章节中所学到的批处理技巧，您可在管理较大目录结构时节省大量时间。
您还可以学习到 Windows 网络命令 — 从 Netstat 到 Pathping — 这取决于您的安排，同样您还能学习到远程连接工具，如 TFTP、RSH 和 RCP。同样，结合您在该书第一章节中掌握的有关自动执行和计划任务的技巧，通过这些工具，您就可以提高效率。总而言之，尽管 Bhardwaj 的书不是一本 Windows 实用程序的综合参考，但绝对值得您添加到书架。
价格：直销价 39.95 美元。

硬件可靠性测试
BurnInTest
passmark.com/products/bit.htm

无论您是参与定制 PC 的生产、对基础客户端执行硬件组件更新，还是只构建新的超级管理员桌面控制，将新组件分发到用户之前确保其可靠的执行功能这一点都至关重要。PassMark Software 推出的 BurnInTest 便可做到这一点，它可对您指定的组件运行许多不同的压力测试，从而确保组件在分发时万无一失。
与所有内置软件测试一样，该应用程序尝试“锻炼”硬件，对所选的系统组件施加压力，努力在短时间内模拟一个较长的操作周期。其目的是在系统或服务投入使用前，发现任何深层的错误。使用 BurnIn Test，您可测试从 CPU、图形卡内存到硬盘驱动器、CD 刻录机的一切。
该应用程序易于使用和配置，允许在特定配置中更改每个组件单元测试的工作周期和首选项。设置了测试配置后，便可将首选项保存以备后用，从而加速您可能需要若干个月才能完全完成的下次迭代测试。
每个测试都有一个可配置的工作周期，因此您可以为每个被测组件设置一个从 1 到 100 的负载值。例如，您可以以 75％ 的负载测试 CPU 的数学运算，而同时以 90％ 的负载测试系统内存。您还可以使 BurnInTest 在一个设定的时间或操作周期后停止测试。
使用该应用程序最多可以同时测试 20 个硬盘驱动器、软盘驱动器和/或光驱；因此，在将这些组件分发到客户环境之前，您可通过批处理方式来测试它们。这在升级系统组件时可节省大量时间，因为您可一次测试所有的新组件，而不用逐个测试每个系统。我喜欢该程序提供的“智能”参数检查功能。
专业版支持对 USB 2.0、并行端口和串行端口执行各种环回测试。（硬件环回设备可从 PassMark 购买。）本版的 BurnInTest 可从 CD 或 USB key 驱动器运行，它通过降低应用程序对被测系统的影响增加了所执行测试的可信度。
价格：专业版 49 美元；标准版 24 美元。

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


 SQL 问题与解答: 重新生成索引、磁盘队列长度和更多内容
SQL 问题与解答
重新生成索引、磁盘队列长度和更多内容
编辑：Nancy Michell

问：如何重新生成 SQL Server 索引？我需要了解为什么 DBCC DBREINDEX 占用了我所有的磁盘空间以及当命令失败时为什么没有释放磁盘空间。我的数据库大小为 90GB，而最大的表格是 70GB。
当我运行 DBCC DBREINDEX 时，留出了 10 % 的可用空间，但它却占用了所有可用磁盘空间并且命令失败。最初的数据库文件是 90GB，当 DBCC 命令失败时，数据库文件增长到 160GB，额外的 70GB 从未释放，我不得不几次手动缩小数据库来回收它。
命令奏效时，数据库文件的大小也是 160 GB，但是几小时后自动收缩会自动释放空间。使用 defrag 而非 DBREINDEX 以占用更少的空间，这是否可行？我没有群集索引，我使用的是简单恢复模式。
答：在最简单的情况下，索引通过构建一份新的索引副本来重新生成，然后删除旧索引。从本质而言，这意味着短期内会存在两份索引副本。构建新索引要求与原始索引一样大小的数据库文件空间，并且如果重新生成需要排序操作，那么还需要额外 20% 的索引大小用于排序。
因此，最坏的情况重新生成索引需要的空间是旧索引空间的 1.2 倍。如果数据库文件没有足够的可用空间，那么该文件将随着操作进行不得不增大。如果自动增长未启用或者磁盘卷上没有足够的空间，那么可能无法提供足够的可用空间，而重新生成操作将失败。
无论操作失败与否，在重新生成操作完成后，均不会释放分配给数据库文件的额外空间。系统假定该空间将用于日常的数据库操作。
基于算法工作的方式，运行收缩（无论手动还是自动）几乎肯定会创建索引碎片。有关详细信息，请参阅 SQL Server 存储引擎。如果数据库需要可用空间用于日常操作，那么自动收缩特别有损性能，因为您陷于自动增长 - 自动收缩 - 自动增长 - 自动收缩的循环中，这样的循环会对碎片和性能造成巨大破坏。
使用 DBCC INDEXDEFRAG（或者 SQL Server™ 2005 的 ALTER INDEX ... REORGANIZE）的优势在于，它几乎不使用额外的数据库文件空间，但它可能花费的时间更长并且会生成比索引重新生成更多的事务记录。无论使用何种恢复模式，DBCC INDEXDEFRAG 始终会完全记录，因此在简单恢复模式中，索引重新生成将成为大容量日志记录。每种方法各有利弊，在 SQL Server 索引碎片最佳实践白皮书中更详尽地进行了说明。
在做出如何修复碎片的决定之前,首先决定到底是否要修复碎片。根据使用索引的操作类型不同，碎片可能对性能没有任何影响，因此修复本身是一种资源浪费。白皮书中有详述。
底线：确保为您的环境选择最适当的碎片删除方法，并且删除碎片对查询性能有帮助。

问：我已经在两个 SQL Server 2005 实例之间成功配置数据库镜像。我的应用程序使用 SQL Server 登录连接到 SQL Server，并且使用 ADO 和 SQL Native Client 进行构建。我的连接字符串和连接设置指定了正确的信息，包括适当的故障转移伙伴。我还在镜像服务器中创建了与在主体服务器中存在的登录相同的所有登录。一旦测试数据库出现故障，镜像会成功地担当起主体角色，在 SQL Server 实例上看起来一切正常。（我甚至能使用我的 Windows® 登录连接到镜像。）然而，应用程序重新连接失败，出现下列错误：
Cannot open database "<db name>" requested by the login. The login failed.
它显示登录与新的主体（原来的镜像）数据库中的用户没有关联。我运行 sp_change_users_login 同步用户和数据库登录，得到一条消息说它修复了多个孤立的用户。然后，我的应用程序重新成功连接到新的主体服务器。我已经尝试过多次故障转移，并且每一次我都会看到相同的行为，即登录与用户之间的关联丢失。
是否存在一种配置镜像设置的方法可以解决此问题？
答：是的。该问题基于这样一种事实，即每台服务器的 SQL Server 登录安全标识符 (SID) 不匹配，尽管其登录名称相同。这不是 Windows/域用户/组登录的问题，因为这些登录的 SID 是基于用户/组的域 SID 创建的，所以无论用户/组添加到哪个 SQL Server 中，对于同一指定的用户/组情况都相同。
为了不必进行 sp_change_users_login 同步步骤，您不仅需要使用相同的名称在映像服务器中创建 SQL Server 登录，而且需要在主体服务器上使用相同的 SID 创建 SQL Server 登录。您可以通过在映像服务器上创建登录时，在 CREATE LOGIN 语句中使用 SID 规范来实现这一点，具体如下：
CREATE LOGIN <loginname> WITH PASSWORD = <password>,
SID = <sid for
same login on principal server>,...
您可以通过查询 sys.sql_logins 目录视图从主体服务器中检索每个登录的 SID。关于查询将在指定的服务器上为每个 SQL Server/Windows 登录生成一个实际 CREATE LOGIN 语句的示例如图 1 所示。
Figure 1 生成 CREATE LOGIN 语句 (Close Figure 1)
select 'create login [' + p.name + '] ' +
case when p.type in('U','G') then 'from windows ' else '' end +
'with ' +
case when p.type = 'S' then 'password = ' + master.sys.fn_varbintohexstr(l.password_hash) +
' hashed, ' + 'sid = ' + master.sys.fn_varbintohexstr(l.sid) + ', check_expiration = ' +
case when l.is_policy_checked > 0 then 'ON, ' else 'OFF, ' end + 'check_policy = ' +
case when l.is_expiration_checked > 0 then 'ON, ' else 'OFF, ' end +
case when l.credential_id > 0 then 'credential = ' + c.name + ', ' else '' end
else '' end +
'default_database = ' + p.default_database_name +
case when len(p.default_language_name) > 0 then ', default_language = ' + p.default_language_name else '' end
from sys.server_principals p
left join sys.sql_logins l
on p.principal_id = l.principal_id
left join sys.credentials c
on l.credential_id = c.credential_id
where p.type in('S','U','G')
and p.name <> 'sa'

问：我的平均磁盘队列长度应该是多少？例如，如果我有 20 个单独的存储区域网络 (SAN)（具有 RAID 01 配置）物理心轴，我如何计算平均磁盘队列长度？它是平均磁盘队列长度/20 还是平均磁盘队列长度/2？
答：首先，您花费时间用于 SAN 环境中的平均磁盘队列长度之前，应该先看一看磁盘延迟时间。但是，这确实取决于您尝试解决的问题。您很快就会知道原因。
此计数器的解释（来自 Perfmon）是“平均磁盘队列长度是读和写请求的平均数，这些请求在采样间隔期间排队等候选择的磁盘”。这可以是物理磁盘或逻辑磁盘计数器，因此得到的数字取决于如何向操作系统提供基本储存。
让我们看看您的案例。您在 RAID 01 配置中有 20 个心轴，这意味着它们是分布且镜像（或者是镜像且分布，这取决于如何读取 01 或 10）。存储阵列的要点是条带集中有 10 个心轴。
但是我缺少必要的信息，例如条带大小是多少、您的写入多大以及您正在发出何种类型的 I/O 操作（读取、写入、顺序还是随机）。
我们暂时忽略缺少的信息。如果平均磁盘队列长度为 10，那么 OS 将使 10 个 I/O 排队到磁盘阵列。从理论上讲，那可能是一个 I/O 对应条带中 10 个镜像组中的每一个，也可能是所有 10 个 I/O 对应一个磁盘。您无法知道是哪一种。
这正是信息缺失的关键所在。让我们假定您的条带大小为 64 KB，您的写入大小为 8KB，并且您要进行一次完整的块顺序写入。这是 SQL Server 储存活动的典型情况。在此案例中，很可能 8 个 I/O 都到达第一个磁盘，而接下来的两个 I/O 到达下一个磁盘。因此，如果您尝试计算出此情况下每个磁盘的磁盘队列长度，那么第一个磁盘为 8，第二个磁盘为 2，阵列中其他 8 个磁盘为 0。
现在，让我们将情况更改为 8KB 的理论条带大小以及 64KB 的写入块大小，并且保持磁盘队列长度为 10。在此情况下，每个 64KB 块遍布在 8 个磁盘中，因此一次 I/O 会写入到 8 个磁盘，并且 10 个排队等候的 I/O 遍布到该阵列所有 10 个磁盘上的 80 个磁盘写入。如果您尝试计算该阵列中每个磁盘的磁盘队列长度，那么对阵列中的每个磁盘将是 8。
让我们更接近实际情况，在该描述中增加不同程度的不确定性。在大多数情况下，您的 SAN 存储将使用服务器中的一个或多个 HBA 连接到服务器，使用一些光纤将 HBA 连接到 SAN、SAN 前端的一些端口以及可能某种光纤交换机（位于服务器和 SAN 之间的结构中）。然后我们会研究 SAN 内的总线内部结构，以及磁盘如何连接到 SAN 前端的端口上。
您所看到的在 Perfmon 中报告的任何排队，都是在位于 OS 测量其磁盘队列长度地点和磁盘表面之间的任意位置上，延迟时间太长或者排队过长的现象。这就是为什么您应该看延迟时间和基于计数器而不是平均磁盘队列长度进行决策的原因。

问：我正在使用事务性复制，并且知道在订阅者表格中许多行已经手动更改过，因此当发布者尝试更改在订阅者中不再存在的行时，我会收到错误。
我需要知道通过复制是否有任何方法，可以只是重新初始化来自发布者的这一表格，而不必再次重新应用整个快照。我研究了 tablediff 函数，它看起来似乎可以实现我想做的事情，但是我想知道它如何与复制进行交互。
例如，tablediff 是否获取发布者表格的时间快照，并将其与订阅表格进行比较？我是否需要停止复制以使用 tablediff 实用程序来确保数据的一致性？还有什么我需要了解的吗？
答：首先，tablediff 不会获取发布或订阅表格的文字快照。关于您的特定情况，可以考虑以下几种选择。
第一个选择是暂时停止复制并运行该实用程序。如果您担心用户尝试修改数据，您可以使用 -sourcelocked 和 -destinationlocked 参数，这将在实用程序运行期间对两个表格执行独占锁定。如果不能接受这种方法，那么另外一个选择是考虑 -rc 和 -ri 参数，而保留复制运行。这将运行一次 tablediff，然后在其检测到的错误上依次运行它，从而消除由于复制传播延迟产生的错误。但要注意，使用此选项视复制延迟而定，您可能不必获取订阅者更改的所有行。

衷心感谢以下 Microsoft IT 专家，感谢他们与我们分享了技术与专业知识： Sunil Agarwal、Chad Boyd、David Browne、Gilles Comeau、Emmanuel Dreux、Amanda Foote、Matt Hollingsworth、Paul Mestemaker、Uttam Parui、Paul Randal、Dennis Tighe 和 Steven Wort。


 实用工具特别推荐: Autoruns
实用工具特别推荐
Autoruns
Lance Whitney
下载这篇文章的代码: Autoruns (490KB)

典型的运行 Windows® 的 PC 在启动时会加载一组项目，其中包括文件、驱动程序、任务和服务。在某些时候，您很可能需要查看并禁用某些启动项目，以排除启动冲突故障、跟踪自动启动序列中的恶意软件、减少 Windows 启动时间或释放内存和系统资源。
系统配置实用程序 (msconfig.exe) 可以使您查看和禁用许多启动文件和服务，但是它漏掉了许多内容 — 工具栏、浏览器帮助对象、Windows 资源管理器外壳扩展。而且，msconfig 不会共享关于这些项目的许多详细信息。一个查看和管理启动时所加载的全部内容的更好方式，就是从 Sysinternals 查看 Autoruns。
Autoruns 由 Mark Russinovich 和 Bryce Cogswell 编写，是一个免费的实用程序，它可以在安装 Windows 的 PC 中显示所有启动项目（也称作映像）。您可以在启动文件夹、注册表以及其他启动项目可能隐藏的区域中查看所有存储的映像（参见图 1）。
图 1 使用 Autoruns 查看启动项目
图 1 使用 Autoruns 查看启动项目
Autoruns 可以显示每个映像的名称和位置。对于文件它会显示目录路径，对于注册表项您会得到准确的项。Autoruns 还提供发布者的名称以及基于项目版本数据的简要说明。双击条目可以打开其目录或者注册表项；右键单击可以打开带有更多选项的弹出菜单，其中包括“属性”命令，该命令可以显示包含完整版本信息的标准“文件属性”窗口。“包括空白位置”选项可以显示所有的 PC 启动区域，无论这些区域当前是否有任何条目。您还可以选择 PC 中的其他用户帐户来查看其启动环境。
您可以通过“验证”命令检查条目的数字签名，此命令查询具有证书吊销列表 (CRL) 的网站以决定映像是否数字签名以及签名是否有效。“隐藏已签名 Microsoft 条目”选项可以排除 Microsoft 已经签名的条目，从而使您集中于第三方映像。
可以将启动项目的完整列表导入一个文本文件中 — 这样如果您想禁用任何项目并需要调整项目之前启动环境的快照就会变得非常方便。然后，您可以将导出的文本文件与已修改的启动配置进行比较，以查看您的更改。
以下仅仅是 Autoruns 包含的一些启动分类：
登录 包含用户和所有用户的启动文件夹以及可以在注册表中找到的 Run 项。
资源管理器 包括一个资源管理器外壳扩展列表、工具栏和处于活动的设置执行。
Internet Explorer 包括“浏览器帮助对象”和 Internet Explorer® 工具栏以及所有扩展。
LSA 提供程序 包括本地安全机构验证、通知和安全软件包。
在 Autoruns 中，您可以永久地删除一个启动项目或者只是禁用它。“在线搜索”选项帮助您查找可以安全禁用的项目。该选项对描述项目或者其分类的网页运行 Internet 搜索，并且建议您是否从启动中删除该项目。禁用一个项目时，Autoruns 会将项目移动到注册表或者硬盘的备份位置。
Autoruns 在所有 Windows 版本中均运行良好，其中包括 Windows XP 64 位版本和 Windows Server® 2003 64 位版本。请从 microsoft.com/technet/technetmag/code07.aspx 下载一个副本。

Lance Whitney 是一位 IT 顾问、培训师和技术撰稿人。在调整 Windows 工作站和服务器方面，他已经花费了无数的时间。15 年前，当他还是一名记者时，就开始涉足 IT 世界。


 网络专家: Windows Vista 无线组策略设置
网络专家
Windows Vista 无线组策略设置
Joseph Davies
本专栏所包含的关于 Windows Server“Longhorn”的预发布信息可能会有所变动。

作为一名管理员，如果能够对 Active Directory 网络中的所有计算机集中配置并分发无线网络设置，则您的工作可能会变得轻松一些。幸运的是，Windows 支持用于计算机配置的专用组策略扩展，可以让您来实现上述目标。这就是
无线网络 (IEEE 802.11) 策略扩展，只要是运行 Windows Vista™、Windows® XP、Windows Server® 2003 和代码名为“Longhorn”的下一版本 Windows Server 的计算机都予以支持。
其工作原理如下。无论是加入域还是启动域（和在此后的运行过程中），这些操作系统会自动下载组策略扩展中的无线设置并加以应用。您可以从组策略对象编辑器管理单元中的下列节点，为基于域的组策略对象配置无线策略：计算机配置 | Windows 设置 | 安全设置 | 无线网络 (IEEE 802.11) 策略。
图 1 显示代码名为“Longhorn”的 Windows Server 域或 Windows Server 2003 域的无线网络 (IEEE 802.11) 策略节点的位置，上述域架构已经由架构扩展文件 802.11Schema.ldf 和 802.3Schema.ldf 进行了扩展（细节描述请参阅microsoft.com/technet/network/wifi/vista_ad_ext.mspx）。
图 1 无线网络 (IEEE 802.11) 策略节点
图 1 无线网络 (IEEE 802.11) 策略节点
默认情况下并没有无线网络 (IEEE 802.11) 策略。要创建新策略，请右键单击控制台树的无线网络 (IEEE 802.11) 策略，然后单击“Create A New Windows XP Policy”（创建一个新的 Windows XP 策略）或单击“Create A New Windows Vista Policy”（创建一个新的 Windows Vista 策略）。对于每一类型，您只能创建一个单独的策略，但每个策略内可以包含多个无线网络的设置。
对于 Windows XP 策略，其策略设置与我在 2003 年 7 月专栏中撰写的内容非常类似。然而，非广播无线网络还有新的选项，那就是 Wi-Fi Protected Access 2 (WPA2) 身份验证方法和 WPA2 身份验证快速漫游。为支持这些新设置，运行 Windows XP Service Pack 2 (SP2) 的计算机必须安装 Windows XP SP2 无线客户端更新。下载位置：support.microsoft.com/kb/917021。
Windows Vista 无线策略包括专门面向 Windows Vista 和 Windows Server“Longhorn”无线客户端的策略设置。如果配置了这两类的无线策略，Windows XP 无线客户端将只使用自己的策略设置，同样，Windows Vista 无线客户端也将只使用自己的策略设置即可。如果没有 Windows Vista 策略设置，Windows Vista 无线客户端可以使用 Windows XP 设置。本文将描述可使用 Windows Vista 无线策略进行配置的设置。
在 Windows Vista 无线网络策略的“常规”选项卡上，您可以为策略配置其名称和描述，指定是否启用 WLAN AutoConfig 服务，并按优先顺序配置无线网络配置文件及其设置列表（见图 2）。您也可以选中该配置文件并单击“导出”，以 XML 文件格式导出配置文件。如果要导入 XML 文件并作为无线配置文件，请单击“导入”并指定文件位置。
图 2 无线网络策略属性
图 2 无线网络策略属性
图 3 显示了 Windows Vista 无线网络策略的“网络权限”选项卡及其默认设置。这是 Windows Vista 的新增功能，通过该选项卡，您可以使用名称指定无线网络，并允许或拒绝对无线网络的访问。例如，您可以创建一个“允许”列表以包含所有允许访问的无线网络的名称，也称之为“服务集标识符”(SSID)，Windows Vista 无线客户端可与其连接。如果网络管理员希望将组织的笔记本电脑连接到指定的一组无线网络（其中会包括该组织的无线网络和 Internet 服务提供商），则上述功能将会非常有用。
图 3 网络权限选项卡
图 3 网络权限选项卡
而通过拒绝列表，您可以使用名称指定一组无线网络，并拒绝无线客户端与其连接。如果希望禁止受管理的笔记本电脑连接到范围内的其他无线网络 — 例如，当一个组织占用一个楼层，而相邻楼层又有其他的无线网络时，上述功能就可以一显身手。使用拒绝列表，您也可以阻止受管理的笔记本电脑连接到已知为不安全的无线网络。创建无线网络列表或指定单独的一个无线网络，以允许或拒绝对其的访问，请单击“添加”，并使用名称来增加无线网络，然后指定允许访问还是拒绝访问。
在“网络权限”选项卡上，也有相关设置可以阻止连接到特定或某类结构模式的无线网络。您还可以让用户查看已配置为拒绝访问的无线网络，并创建“所有用户”配置文件。在该计算机上拥有帐户的任何用户，都可以通过此“所有用户”配置文件连接到指定的无线网络。如果该设置被禁用，那么只有“网络管理员”组或“网络操作员”组的成员才能在计算机上创建“所有用户”无线配置文件。

无线网络配置文件属性
要想通过 Windows Vista 无线策略“常规”选项卡管理无线网络配置文件，请选择现有配置文件并单击“编辑”，或者单击“添加”，然后针对特定或某类结构模式的无线网络指定新的无线配置文件。
如果希望创建新的无线配置文件，可以在“连接”选项卡上指定配置文件名称，然后创建相应的无线网络名称列表（见图 4）。您也可以在“网络名称”(SSID) 中键入并单击“添加”按钮来添加新的名称。您也可以指定：当处于既定范围之内时，使用该配置文件的无线客户端能否自动尝试连接到配置文件中列出的无线网络（取决于 Windows Vista 策略“常规”选项卡上无线配置文件列表的优先顺序）。此外，您还可以指示如果一个优先级更高的无线网络进入范围内时，是否自动断开与当前无线网络之间的连接，并指明配置文件中的无线网络为非广播网络（也称为隐藏网络）。
图 4 “连接”选项卡
图 4 “连接”选项卡
在“安全”选项卡上，如图 5 所示，您可以为配置文件中的无线网络配置身份验证和加密方法。加密方法的选择取决于对身份验证方法的选择。图 6 列出了所有可用的选择。
Figure 6 安全方法 (Close Figure 6)

身份验证方法
开放
共享
Wi-Fi Protected Access (WPA) 个人
WPA 企业
WPA2 个人
WPA2 企业
Open with 802.1X
加密方法
有线对等保密 (WEP)
临时密钥完整性协议 (TKIP)
高级加密标准 (AES)
图 5 “安全”选项卡
图 5 “安全”选项卡
如果您决定选择 WPA 企业、WPA2 企业或 Open with 802.1X 作为身份验证方法，您也可以配置网络身份验证方法（可扩展身份验证协议 [EAP] 类型）、身份验证模式（用户重新身份验证、计算机身份验证、用户身份验证或来宾身份验证）、身份验证取消前能够尝试的次数，并配置是否缓存用户信息以用于后续连接。最后的设置指定在用户注销后，从注册表中删除用户凭据数据。这样，当下一个用户登录时，系统将提示其出示凭据（如用户名和密码）。
要配置 WPA 企业，WPA2 企业和 Open with 802.1X 身份验证方法的高级安全设置，请单击“高级”。图 7 显示默认的“高级”安全设置对话框。
图 7 “高级”安全设置对话框
图 7 “高级”安全设置对话框
在“IEEE 802.1X”部分，当没有检索到初始 EAPOL-Start 消息的响应时，就可以指定连续发送 EAP over LAN (EAPOL)-Start 消息的数量；当没有检索到先前发送 EAPOL-Start 消息的响应时，还可以指定重传 EAPOL-Start 消息的时间间隔。您也可以设定，当身份验证客户端从验证程序收到身份验证失败指示后，不执行任何 802.1X 身份验证活动的时段；以及当启动端到端 802.1X 身份验证之后，身份验证客户端等待重传任何 802.1X 请求的时间间隔。
单一登录 (SSO) 可以让您相对于用户登录，配置何时进行 802.1X 身份验证，并将用户登录和 802.1X 身份验证凭据集成到 Windows 登录服务器。SSO 部分的设置，可以在用户登录进程之前或之后，立即执行无线身份验证，并可以在登录进程开始之前指定连接延迟的秒数。您也可以指示，如果身份验证方法要求用户输入其他的凭据，是否向用户提示其他的输入字段，并确定显示这些字段多长时间。您还可以指示，该配置文件的无线网络是否针对计算机或用户身份验证使用不同的虚拟 LAN (VLAN)。
在“快速漫游”部分，您可以配置成对主密钥 (PMK) 缓存和预身份验证选项。只有选择 WPA2 企业作为身份验证方法时，“快速漫游”部分才会出现。使用 PMK 缓存，无线客户端和无线访问点 (AP) 能够缓存 802.1X 身份验证结果。因此，当无线客户端漫游回到已经通过身份验证的无线访问点之后，访问速度会更快。您可以配置 PMK 缓存中保存条目的最长时间和条目的最大数量。使用预身份验证，无线客户端能够在与当前无线访问点保持连接的同时，针对其范围内的其他无线访问点执行 802.1X 身份验证。如果无线客户端漫游到一个已通过预身份验证的无线访问点，就会大幅缩减所需的访问时间。您可以针对无线访问点配置可以尝试预身份验证的最大次数。
有关 Windows 无线支持的详细信息，请参阅microsoft.com/wifi。有关 Windows 组策略的详细信息，请参阅相关资源：microsoft.com/gp。

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


 Windows PowerShell: 数据的筛选与格式化
Windows PowerShell
数据的筛选与格式化
Don Jones

毫无疑问，Windows PowerShell 在您勿需进行大量的工作的情况下，就可以返回许多宝贵的信息。以简单的 Get-WMIObject cmdlet 为例，它可以用来返回本地计算机上的服务列表。默认视图列出了所运行服务的状态、名称和启动模式，
其实质上是一种“服务”控制台的命令行视图。Windows PowerShell™ 能使其更加容易实现。
不过，还可以为服务提供大量更加有用的信息，而不仅仅是在默认视图中显示出来的部分。试试运行这个命令：
$s = get-wmiobject win32_service
$s[0] | gm
第一行命令返回所有服务的集合（或者，更确切地说是来自 Windows® Management Instrumentation 或 WMI 的 Win32_Service 类的所有实例）,并将其存储在变量 $s 中。第二行命令调用此集合中的第一个服务（在方括号中指明的序号零），并将其传送到 Get-Member cmdlet（在此使用它的别名，gm）。输出结果显示此数据类型所有可用的属性和方法。我决定使用 WMI 的 Win32_Service 类，而不用 Windows PowerShell 内置的 Get-Service cmdlet，因为与 Microsoft® .NET ServiceController 对象相比，WMI 实际上能够提供更多的信息，其中包括 StartName 属性。该属性可告诉我在其下运行服务的用户账户的名称。您可以使用如下方法检查单个实例（如第一个）的名称：
PS C:\> $s[0].StartName
LocalSystem
然而，这些服务并没有任何特定的排列顺序，所以用集合中的序号来引用服务效果不是很好。（其通常以字母顺序排列，但并非始终如此。）从管理的角度来讲，或许您最感兴趣的是全部服务的列表和每个用来登陆的账户。这样对于某些方面有相当的便利性，比如说遵从性审核。那么让我们稍作停留，来看一看 WMI 的默认设置。我将使用 Get-WMIObject 的缩写，gwmi（见图 1）。
Figure 1 使用 gwmi (Close Figure 1)
PS C:\> gwmi win32_service

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK

ExitCode  : 1077
Name      : Adobe LM Service
ProcessId : 0
StartMode : Manual
State     : Stopped
Status    : OK
显然这仅是一个示例，但是您可以看到输出结果并不太适用于管理报告。我想知道的是服务的名称和 StartName（即服务在其下运行的账户）。我也希望报告的格式可读性更强，而不是这种感觉有点笨笨的列表。这就是 Windows PowerShell 中具备强大格式化和数据筛选功能的 cmdlet 发挥作用的地方。

获取您所需要的数据
我将从 Get-WMIObject 筛选数据作为开始，因此现在显示的消息就是我感兴趣的属性。最佳的实现方式是使用 Windows PowerShell Select-Object cmdlet，其简写的别名为 select。Select 用于接收对象的集合（诸如由 Get-WMIObject 所返回的集合），并显示这些对象所需要的属性。这意味着我可以将 gwmi 的输出传送到 select，并指定我所感兴趣的两种属性。图 2 显示了结果，其中包含了用表格形式所显示的 Name 和 StartName 属性。
图 2 仅查看表格中的 Name 和 StartName 属性
图 2 仅查看表格中的 Name 和 StartName 属性
假设我是为遵从性审核目的而生成此报告，那么其中包含的信息确实多了些。由于某些服务已被禁用，因此任何读取禁用服务理论上会使用哪些账户相关的输出结果，均无实际意义。因而，我会筛选掉所有具备“禁用”启动类型的服务，也就是 Win32_Service 类的 StartMode属性。
Windows PowerShell 使用 Where-Object cmdlet（其缩写为 where）来筛选对象。where cmdlet 接收输入对象的集合并通过脚本块逐一运行，基于一套定义好的标准来决定是否每个对象都将在 cmdlet 的输出中显示。每个符合标准的对象生成的比较结果为 True，并包含在输出结果中；而产生 False 值的对象不会包含在内。
因此，我决定只需要那些 StartMode 属性设为禁用的对象。在 Windows PowerShell 内容中，该评估是这样的：
$object.StartMode –eq “Disabled”
当然，$object 仅仅是一个例子。事实上我并没有在编写脚本，而且我没有命名为 $object 的变量。在 where 使用的脚本块中，我却有一个特殊的名为 $_ 的变量，它代表当前正在被 cmdlet 评估的对象。因此我的 where 脚本块可能是这样的：
$_.StartMode –eq “Disabled”
我可以很轻松地对其进行测试：
PS C:\> gwmi win32_service | where
{$_.StartMode -eq “Disabled”}

ExitCode  : 1077
Name      : Alerter
ProcessId : 0
StartMode : Disabled
State     : Stopped
Status    : OK
当然，在此快速测试中，输出结果会以默认的列表样式返回显示。同时，为了节约空间，在此仅包含了一个服务。但您会注意到此输出是反向的。我已包含了禁用服务在内，而非将它们排除在外。这是因为得让我的脚本块反向：我需要包括所有 StartMode 属性不是禁用的服务，正如对我的示例进行修改后那样：
PS C:\> gwmi win32_service | where
{$_.StartMode -ne “Disabled”}

ExitCode  : 0
Name      : AcrSch2Svc
ProcessId : 1712
StartMode : Auto
State     : Running
Status    : OK
这样更好！现在输出结果中仅包含我真正感兴趣的服务，我能够再一次将结果传送到 select 并指定我需要的属性：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} | select name,startname
将数据从一个 cmdlet 传送到另一个再到另一个 cmdlet 的过程，真正说明了 Windows PowerShell 的功能。我依然没有编写脚本，但是我却实现了从大量数据集中筛选出我所需要的输出结果这一目的。

合适的外观
您应该注意，select 的输出仍然只是一组对象。当我使用 Windows PowerShell 检索格式美观的表格时，正是 PowerShell.exe 在对这些对象进行编译。换句话说，Windows PowerShell 知道我作为一个普通人不可能看见这些对象，因此它采用文本的形式来呈现这些对象。在这种情况下，对象以表格的形式呈现，同时每个属性都有相应的一列予以对应，如图 2 所示。
看起来这样对于审核目的已经足够了。但我想再说一遍，也许不是。不同的人有不同的需求，Windows PowerShell 并不会假设您的特定需求。相反，它为您提供最好的工具来格式化输出。四个内置的 cmdlets - Format-List、Format-Custom、Format-Table 和 Format-Wide - 用来接收对象的集合（比如由 select 返回的集合），并用不同的方式格式化这些对象。Windows PowerShell 基本上使用 Format-Table 来格式化 select cmdlet 的输出结果。想看看不同的外观，可以试一下 Format-List：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | format-list
结果有点像这个示例：
name      : AcrSch2Svc
startname : LocalSystem

name      : Adobe LM Service
startname : LocalSystem
Format-Wide cmdlet 会生成一个多栏的列表，默认情况下为每个对象的第一个属性。以下面这一行为例：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
 select name,startname | format-wide
它生成一张服务名称列表，但这并不是我想要的。输出中没有 StartName（见图 3），而在审核报告中，StartName 是我所需要的一条重要信息。
图 3 Format-Wide cmdlet 显示的输出结果中省略了关键信息 -- StartName
图 3 Format-Wide cmdlet 显示的输出结果中省略了关键信息 -- StartName
因为我仅需处理两种属性，所以 Format-Table 或 Format-List 看起来都是可以接受的。但是审核人员看到屏幕上的上述信息可能不会感到高兴。她可能更喜欢某种格式的文件。

导出数据
那么，审计人员希望如何查看数据呢？输出服务列表并登录到 CSV（逗号分割值）文件可能就足够了，因为可用 Microsoft Excel® 很方便的打开该文件。要创建一个 CSV 文件，只需将您的输出传送到 Windows PowerShell Export-CSV cmdlet：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | export-csv c:\services.csv
当然，在当今社会，CSV 似乎有一点过时。 或许审计人员会更希望数据以网页的形式显示到 Intranet 服务器上。 为了做到这一点，需要使用 ConvertTo-HTML cmdlet 将输出转换成 HTML：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html
原始的 HTML 难以查看，因此您需要将输出结果写到一个文件中：
gwmi win32_service | where {$_.StartMode -ne “Disabled”} |
select name,startname | convertto-html | out-file c:\services.html
图 4 显示的结果是一种格式美观的 HTML 页面，可以发布到任何 Web 服务器上，而不需要做进一步的修改。
图 4 用格式美观的 HTML 页面显示输出结果
图 4 用格式美观的 HTML 页面显示输出结果

相关事实
Windows PowerShell 为您提供访问大量管理数据的快速途径。然而，从业务的角度来说，这些数据在原始状态下并不是始终都有用的。
通过筛选数据（使用 where ）、选择所需要的对象属性（使用 select ）以及应用相应的格式化选项（比如 Format-Table 或 Format-List），您可以轻松快捷地将管理数据转换为有用的信息。然后，通过将数据导出为一种易于共享的文件格式，您可以将该信息进行共享并与组织内其他同事交流宝贵的信息。

Don Jones 是 SAPIEN Technologies 的项目和服务主管，也是Windows PowerShell:TFM (SAPIEN Press) 的合著者。通过网站联系 Don，网址是 www.ScriptingAnswers.com。


 您好，脚本专家！: 本地用户和组的不成熟解决方案
您好，脚本专家！
本地用户和组的不成熟解决方案
Microsoft 脚本专家
下载这篇文章的代码: HeyScriptingGuy2007_04.exe (151KB)

如何管理文件和文件夹的安全描述符？

信不信由你， 曾经一度（当然那是很久以前），脚本专家们真的并不都是那么聪明。我们知道这难以置信，但是 — 您认为不那么难以置信是什么意思呢？您觉得没有那么久以前又是什么意思呢？我们将会让您知道原因的 — 哦，好的。显然，您曾在几天前看到一位脚本专家作者努力组装一台新电视。
这位特别的脚本专家却还振振有词地辩解说，安装一台新电视不是“火箭科学”；事实上，安装电视比“火箭科学”还要复杂得多。即使仅仅安装电视本身也要涉及三根视频线和一对音频线。除此之外，您还要想办法安装一台 VCR 播放器、一台 DVD 播放器和一个 Xbox®，更不要说在“通用”遥控器上乱按一通数字让遥控器识别所有这些设备了。相比起来，将卫星发射到环绕火星的轨道上简直是小菜一碟。
不寻常的是，脚本专家实际上能够完全正确地连接好这些设备。然而，当他打开所有的设备时，却一点动静都没有。他很负责地再三检查每一处连接。他通读所有的用户手册，甚至上网查询，看看自己是不是漏掉了什么信息。可是什么都没漏掉。他简直都要用他的 MP3 播放器来祭奠电子之神来找到原因了，却突然发现他忘记了一个重要步骤：把分线盒上的电线插入墙上的插座里。
注意： 您可能认为之所以把脚本家族的代码连接起来如此之难是因为脚本家族的内容太多。事实上，脚本专家也同意这一点。不过，每一次这个家族为是否增加更多的内容而投票时，脚本专家总是以 2-0 胜出。不，不是 2-1，而是 2-0。出于某些原因，“脚本爸爸”的选票从未计算在内，而且没有档案记录。
您一定会问为什么。是的，他已经尽力争取了。但迄今为止，联合国拒绝向“脚本家族”派驻选举监督人。
当然，既然我们考虑到这个问题，脚本专家们（尤其是安装新电视的那位）也没有什么，因为他们还不成熟。例如，他们计划编写《Microsoft® Windows® 2000 Scripting Guide》（Microsoft® Windows® 2000 脚本指南），当他们拟定书中章节时，他们向许多专家寻求帮助。其中保留的一章是：管理本地用户和组。“管理本地用户和组？！？”专家们惊讶地说，“这怎么能考虑成为一章呢？谁会关心管理本地用户和组呢？”
噢，令我们感到委屈的是我们发现每个人（也许除了我们内部的“专家”之外）都关心本地用户和组的问题。每周我们收到大量的电子邮件，询问如何在本地组中进行操作，如添加一个用户、删除一个用户或更改计算机上本地管理员密码之类。
当然，在脚本中心脚本存储库中确实有一些示例脚本向您展示如何执行这类任务，但大多数这类脚本都是一次只对一台计算机有影响。这远远不够：人们想知道如何同时在多台计算机上完成这类任务。仅仅在一台破计算机上更改本地管理员密码？回到现实世界来吧，脚本专家 — 我们需要的操作是在所有的计算机上、或在一个 OU 中的所有计算机上、或在我们所有的邮件服务器上、或 — 噢，你终于明白了。
考虑到脚本指南出版于 2003 年，这意味着我们已经身陷这类同样的电邮信息中将近四年了。一位脚本专家最近谈及：“这有另一位读者询问如何从 Excel® 电子表格中读取计算机名称，然后在每一台计算机上更改本地管理员密码。”
嗯，我们花了四年的时间，但我们终于解决了这个问题。图 1 所示正是我们的解决办法。
Figure 1 我们最终解决了问题 (Close Figure 1)
On Error Resume Next

Set objExcel = CreateObject(“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open(“C:\Scripts\Test.xls”)
objExcel.Visible = True

i = 2

Do Until objExcel.Cells(i, 1).Value = “”
    strComputer = objExcel.Cells(i, 1).Value
    Set objUser = GetObject(“WinNT://” & strComputer & “/Administrator”)
    If Err = 0 Then
         objUser.SetPassword “egTY634!alK2”
         objExcel.Cells(i, 2).Value = Now
    End If
    Err.Clear
    i = i + 1
Loop
注意： 正如您看到的，我们花了四年的时间并不是因为编写这个脚本很难；我们花了四年的时间写这个脚本是因为我们需要这么长的时间来把事情的方方面面做好。这就是为什么我们绝不想错过脚本专家每年一度的新年晚会，毕竟，您不知道下一次晚会是否还会举行。
我们这个脚本的功能就是从电子表格中提取计算机名称信息，然后更改每台计算机上的本地管理员密码。为了执行这个小程序，我们从简单的情况开始，假定您有一个非常简单的小型电子表格，就如同图 2 所示的一样。（如果没有，就立即创建一个。）
图 2 必备的计算机列表
图 2 必备的计算机列表
如您所见，这没什么特别的。在第一列（列 A），我们列出了所有要更改密码的计算机名称。在第二列（列 B），我们仅仅是跟踪每台计算机上管理员密码最后一次更改的日期和时间。这样您可以很容易注意到管理员密码是否全都处于同步状态。
至于脚本本身，我们以 On Error Resume Next 语句开始。通常我们并不在脚本中加入错误处理语句，这样会麻烦许多。这并不是因为我们反对错误处理；而是因为我们想让脚本尽量简短并易于跟随。然而在本例中，On Error Resume Next 语句是至关重要的。毕竟我们的脚本将要尝试连接到许多不同的计算机上。如果其中一台计算机关闭会发生什么情况呢？嗯，有了错误处理，一切尽在掌握之中。当然，错误还会发生，但是脚本将能够对它置之不理并继续运行。没有错误处理，您遇到的情形会与那位脚本专家第一次打开新电视时遇到的如出一辙。那就是什么反应都没有。
接着，我们用下面一段代码创建一个 Excel.Application 对象的实例，使这个 Excel 实例在屏幕上可见，并打开电子表格 C:\Scripts\Test.xls：
Set objExcel = CreateObject _
    (“Excel.Application”)
Set objWorkbook = objExcel.Workbooks.Open _
    (“C:\Scripts\Test.xls”)
objExcel.Visible = True
最后，但绝不等于不重要的一步是：我们把值 2 赋给名为 i 的计数器变量。我们将用此变量跟踪电子表格中的当前行。
注意： 那么，为什么 i 的赋值为 2 呢？很简单：如果您仔细看过电子表格，就会发现我们的数据实际上是从第二行开始的。第一行仅仅是一个标题行。
看到了吗？我们也许不擅长连接 YPbPr1 电缆，但是我们确实了解一些脚本方面的知识。
不管怎样，我们有时确实能做到这一点。
现在，我们准备开始工作。首先，我们设置一个 Do Until 循环，运行该循环直到在第一列遇到一个空单元格。是的，这意味着您无论做什么，都不能在第一列留下空行。如果您的脚本遇到了一个空行，它将认为已到达数据的结尾，所以循环（和脚本）将结束。尽管有办法解决空行的问题，但是仅仅避免在您的电子表格的任何位置出现空行会使任务简单得多。
在循环内部，我们开始将第 i 行，第 1 列单元格中找到的值赋给变量 strComputer。（记住，第一次循环时，i 等于 2；因此我们处理的是第 2 行第 1 列单元格中的值。）我们接着使用该行代码为本地管理员帐户创建一个对象引用 (objUser)，帐户所在计算机通过变量 strComputer 表示：
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
如果此脚本出现错误，它将在这里失败。例如，假设网络出了问题、假设计算机关闭或假设一位脚本专家把他的 DVD 播放器安错了地方而使整个美国西部陷入了黑暗。如果出现了这方面的问题，我们将无法连接到这台计算机上。这就是为什么我们立即检查 VBScript Err 对象的值：
If Err = 0 Then
如果 Err 对象等于 0，就是说我们可以毫无问题地连接到这台计算机（以及管理员帐户）。如果 Err 不等于 0，那么就意味着一件事：我们尝试连接失败。在这种情况下，我们大可不必徒劳地去尝试更改那台计算机密码；毋庸置疑，如果我们无法连接，就更无法更改其密码。
假设一切正常，没有错误发生，则我们执行下面两行代码：
objUser.SetPassword “egTY634!alK2”
objExcel.Cells(i, 2).Value = Now
在第一行中，我们使用 SetPassword 方法为本地管理员帐户赋值新的密码 (egTY634!alK2)。（是的，我们知道：您应该不会用您孩子的名字作为密码。）在第二行中，我们把当前的日期和时间（使用 VBScript Now 函数）写到第 i 行第 2 列单元格。注意，仅当我们确实能够连接到远程计算机并更改其密码时，我们才去更新“密码更改”列。如果我们无法连接到一台计算机，则绝不会更新其相应的“密码更改”字段，这就是我们如何了解哪些操作成功和哪些操作不成功的方法。
这一切都意味着什么？这意味着，第一次循环时，我们的电子表格会如图 3 所示。
图 3 重置第一个密码后的计算机列表
图 3 重置第一个密码后的计算机列表
对计算机 1 的处理就这样结束了。现在，我们需要做一些边角余料的工作，以利再战：
Err.Clear
i = i + 1
尽管这两行代码很短，却非常重要。（脚本专家可不会编写任何不重要的代码！）第一行将 Err 对象重置为 0。如果没有错误发生，这是多余的，毕竟这时 Err 对象已经是 0 了。不过，如果确实有错误发生，那么 Err 对象绝不会等于 0。在这种情况下，我们必须手动重置 Err 对象为 0，这一点至关重要。这是为什么？因为这是 Error 对象：它只跟踪错误，而不跟踪成功的操作。例如，我们假设计算机 1 出了毛病而无法建立连接。为了叙述的方便起见，假设这导致 Error 对象被设为 99。
现在，假设我们进入下一轮循环，并成功连接到计算机 2，您觉得现在 Err 的值将会是什么？没错：不管您是不是愿意，Err 将仍然被设为 99。这是由于只有当错误发生时，Err 对象的值才会改变。如果没有错误发生，Err 对象会无限期的保持其当前值。
这对我们来说真的很重要吗？是的，应该是这样。毕竟，从技术上而言，我们即使成功连接计算机也不会更改其密码；相反地，仅当 Err 等于 0 时我们才会更改密码。而且 — 我们打开计算器的时候要好好想想 — 是的，我们是对的：99 不等于 0（当然，脚本家族选举的时候除外，“脚本爸爸”投 99 票也等于 0 票）。这对我们很重要，因为即使我们连接到计算机 2，Err 也不等于 0。而因为 Err 对象不等于 0，所以我们甚至不会尝试更改本地管理员密码。
换句话说，如果 Err 的值曾经发生变化，则需要将其值重置为 0；否则从此以后您的脚本将认为出现错误。而如何将 Err 对象重置回 0 呢？答对了：只需调用 Err.Clear。
接下来，我们令 i 的值增加 1。为什么？是这样，第一次循环时变量 i 等于 2，是因为我们想连接列表中第 2 行，第 1 列的计算机。第二次循环我们想连接第 3 行，第 1 列的计算机。如果明白了 i 表示我们要处理的那一行，我们就应该令 i 等于 3。每个人都知道，2 + 1 = 3。（幸好我们的计算器还在运行，不是吗？）只有这样，我们才进入下一轮循环并对电子表格中的下一台计算机重复此过程。
现在的结果的确很酷，但是 — 看看我们怎样变得更加成熟 — 我们非常确信，就凭这个脚本本身，我们不会再陷入堆积如山的电子邮件中了。人们会说，“那个 Excel 表格确实不错，但是我还需要更改一个 OU 上的、或一个文本文件中列出的所有计算机的本地管理员密码。或许我喜欢弹出一个计算机列表，并能从列表框中选择要处理的计算机。或许我真的喜欢......”
请放心。您的愿望就是脚本专家的神圣使命。（想想您为了让愿望变为现实，原意等上四年，这确实是我们义不容辞的责任。）事实证明，我们在脚本中心发布了许多的多计算机模板。这些模板使得对多台计算机运行脚本变得非常容易。例如，假如您确实要更改一个 OU 中所有计算机的本地管理员密码。嗨，没问题。对一个 OU 中所有机器运行脚本的模板与图 4 类似。
Figure 4 对一个 OU 运行脚本 (Close Figure 4)
On Error Resume Next

Set objOU = GetObject(“LDAP://OU=Finance,dc=fabrikam,dc=com”)
objOU.Filter = Array(“Computer”)

For Each objComputer in objOU
    strComputer = objComputer.CN

    ‘
=====================================================================
    ‘ Insert your code here
    ‘
=====================================================================

    Set objComputer = GetObject(“WinNT://” & strComputer & “”)
    objComputer.Filter = Array(“User”)
    For Each objUser in objComputer
        Wscript.Echo objUser.Name
    Next

    ‘
=====================================================================
    ‘ End
    ‘
=====================================================================

Next
看到模板中标着“在此处插入代码”的部分了吗？您所要做的就是删除该部分中的示例代码，并以更改本地管理员密码的代码（这些代码可以从本专栏复制）代替。换句话说，用下列代码代替示例代码：
Set objUser = GetObject(“WinNT://” & _
    strComputer & “/Administrator”)
If Err = 0 Then
    objUser.SetPassword “egTY634!alK2”
End If
Err.Clear
这个具体的例子不会为您记录结果，但您可以很方便地加上您自己的代码。替换示例代码，更改连接字符串 LDAP://OU=Finance,dc=fabrikam,dc=com 以指向您 OU 中的一台计算机，然后便可以开始使用了。
说实话，实际上我们一年多以前就发布这些模板了，而我们觉得这些模板应当是我们在脚本中心发布的所有项目中，最受欢迎的项目之一。我们想错了：尽管人们成天给我们发邮件，询问如何对多台计算机运行脚本，却很少有人使用这些模板。我们假设这是因为没有人意识到这些模板的存在。但现在您知道了。或者如果我们告诉您，您至少知道到哪去找这些模板：microsoft.com/technet/scriptcenter/scripts/templates。嗯，也许这就是为什么从来没有人使用这些模板的原因......
所以，既然脚本专家们成熟多了，这也意味着他们不象以前那样笨拙了吗？让我们这样来解释一下：不是很久以前，一个脚本专家决定用周末的时间修理房前屋后的几个设施。当他周一回来上班的时候，他的大拇指破了，流血不止，而腿上划了一个大口子。
仔细想来，也真的不是那么糟糕。至少对一个脚本专家来说是这样。

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


 安全观察: 安全配置向导
安全观察
安全配置向导
John Morello
本专栏所包含的关于 Windows Server "Longhorn" 的预发布信息可能会有所变动。

维护服务器的安全稳定与快捷高效是很多 IT 组织都要面临的一个挑战，而对于那些拥有大量服务器，并且这些服务器跨不同地域及组织界限的组织来说更是如此。加强一台服务器对有经验的管理员而言是一项相当简单的工作，但面对数十台、数百台甚至
数千台服务器就完全是另一个概念了。多年以来，许多组织都在为保障服务器安全献计献策，他们贡献出自己的内部检查清单或标准，亦或是将 Microsoft、美国国家标准与技术研究院或其他外部各方提供的指南汇集在一起。尽管这种文档有相当的价值，但是孤立的文档资料却不足以让各个组织将这些最佳实践在其网络应用中付诸实施。因此，很多组织要么选择保留默认安装设置，要么投入大量的时间与精力创建他们自己的脚本或策略来强化系统。
随着安全配置向导 (SCW) 在 Windows Server® 2003 Service Pack 1 (SP1) 中的出现，如今 Microsoft 可以根据不同角色的服务器，提供一种简便且易支持的方式来加强服务器，减少服务器的受攻击面。通过将 SCW 的优点与组策略的集中部署和管理功能相结合，SCW 便可扩展至最大型的 IT 企业。我将在本月专栏中加以概述，IT 组织如何使用更为安全稳定的 SCW 和组策略方式来管理他们的服务器，并同时降低部署和运营成本。

SCW 是什么？
SCW 是一个可选组件，通过“添加/删除 Windows® 组件”控制面板进行安装，Windows Server 2003 SP1 系列产品和 Windows Server 2003 R2 皆包含该组件。管理员针对目标服务器运行 SCW 可以确定服务器的角色。此时管理员就可以在 SCW 帮助下创建安全策略，进而使用最低权限方案加强服务器。也就是说，SCW 帮助确保只有服务器功能角色中要求的那些服务、应用程序功能和端口才可以使用；而服务器角色特定需要范围之外的一切都将禁用。这一方法还可以减少目标服务器的受攻击面。假使您运行了服务器角色范围之外的服务，将会增加服务器的网络风险，而且在性能与功能方面也不会有任何提高。禁用这些服务可以降低风险并改进服务器的性能。
Microsoft 针对 Windows Server 2003 进行了多项安全改进，相对于之前的 Windows Server 版本，Windows Server 2003 的整体受攻击面大大减少，而且与 Windows Vista™ 和即将推出的代码名为 "Longhorn" 的 Windows Server 版本不同之处在于，它并非建立在同样高度组件化的核心之上。因此，在 Windows Server 2003 的默认安装下，一些服务器角色配置中并非必需的服务也会启用并运行。例如，后台打印程序服务在默认情况下是启用的，但对于一台仅作为数据库应用的服务器来说，这项服务并不是必需的。

实现基于角色的安全性
在过去数年间，Microsoft 已经发布了众多专注于安全性的文档，这些文档帮助管理员了解不同的服务器角色都需要哪些服务，同时为像 Web 服务器这样众所周知的角色提供预建模板。然而，在大型环境中执行那些 Windows Server 2003 安全指南中的操作指导是极具挑战性的，当这些环境中运行了比 IIS 或 SQL Server 安装还要复杂的应用程序时尤其如此。更为复杂的是，在企业所使用的数量庞大的第三方应用程序中，很多都依赖于多服务器角色，但其应用与服务要求却经常没有很好地定义。
SCW 将指南中所有的相关知识和最佳实践封装至一个由管理员运行的向导，一举解决了所有问题。比方说，一个管理员当前正在部署同时需要 SQL Server™ 和 IIS 的新型行业 (LOB) 应用程序，但他不再需要花费大量的时间详查安全指南，也不用开发自定义依赖项清单。相反，他只需在服务器上安装应用程序并启动 SCW 即可。SCW 会自行检测当前运行的服务，然后提交一份清单以供管理员选择服务器的角色。SCW 会根据管理员做出的选择生成一个策略，并根据角色依赖矩阵禁用所有不需要的服务。此外，SCW 还会提供加强注册表项的选项，阻止不需要的网络通信并应用有效的审核策略。运行 SCW 之后，管理员可以将 SCW 策略另存为一个 XML 文件，并且可在运行相同 LOB 应用程序的其他服务器上应用此策略。
因此，相比传统方式而言，运行 SCW 拥有三个强大的优势，并可提供更多手动方式来维护 Windows Server 的安全。首先，在为特定工作负荷明确所需的服务和设置时，即便不能完全消除，也可以大幅降低管理员查阅产品文档的频繁程度。所有知识都会内置于 SCW，问题驱动的界面则简化了管理员提供所需细节的工作量。其次，SCW 将不同领域的指南结合在一起，这些指南包括服务强化、减少网络受攻击面、LDAP 与 SMB 服务强化以及锁定 IIS 等众多方面。而在此之前，完成这些配置任务需要用到多个实用工具，并且这些工具都有其各自的界面与方法。最后，由于 SCW 能够将设置另存为一个 XML 策略文件，所以“一劳永逸”是其最好的写照。无论您部署一台或是一百台服务器来支持特定的 LOB 应用程序，可以轻松地将相同的 SCW 策略应用到每一台服务器。这能够让我们保持完全一致的安全设置，从而降低运营成本。同时也使 SCW 策略的回滚操作更为简便。

SCW 组件
相比所提供的功能与优点而言，SCW 是一个非常简易的工具，共包括三个主要组成部分：向导界面、命令行界面和安全配置数据库 (SCD)。中小型企业的管理员也许只用向导界面就可以完成所有任务。但在大型甚至更为复杂的环境下，管理员就需要用到命令行界面来协助自己实现 SCW 任务的自动化，例如将一个 SCW 策略转换为组策略对象 (GPO)。通常，只有高级管理员在创建自定义 SCW 角色时才会修改 SCD。
如图 1 所示，向导界面允许管理员针对目标服务器进行创建、编辑、应用和安全设置回滚操作。这就为管理员在稳定的工作流程里提供了多种选择，首先是检查服务与设置，其次是网络连接，然后是安全审核策略，最后为 IIS 设置。
图 1 SCW 界面
图 1 SCW 界面
SCW 命令行界面有三项基本功能：允许管理员分析并配置多台服务器（本地或远程均可），以及执行策略回滚操作；将 XML 格式的 SCW 策略自动转换为可供标准 GPO 管理工具（如组策略管理控制台）本身使用的 GPO；图 2 中所示的 SCW 命令行工具可用于注册任意的新安全配置数据库扩展组件。
图 2 SCW 命令行工具
图 2 SCW 命令行工具
SCD 仅是一个 XML 文件集，详述了每一个 SCW 角色所需的特定服务和设置。这些文件的路径为 %windir%\security\msscw\kbs。默认情况下，SCW 附带了大量的核心 Windows Server 角色，以及十二个预定义应用程序角色，其中包括：BizTalk®、Commerce Server、Exchange Server、Host Integration Server、Internet Security and Acceleration Server、Microsoft Identity Integration Server、Microsoft Operations Manager、Small Business Server、SharePoint® Portal Server、SharePoint Team Services、SQL Server 和 Systems Management Server。每个角色都有各自的 XML 文件（见图 3）。任何时候只要创建一个新的角色定义，就会将其相应的 XML 文件放置在此目录中。这些都是标准的 XML 文件，可以使用任何支持 XML 的文本查看器或应用程序读取（见图 4）。
图 3 预定义角色
图 3 预定义角色
图 4 角色配置文件
图 4 角色配置文件

SCW 与组策略的结合
SCW 本身就是个极好地工具，但是只有在与组策略相结合时才会显示出最为强大的一面。自从 Windows® 2000 发布以来，Microsoft 对于维护 Windows 服务器安全的建议一直集中在使用组策略来提供一致、稳定以及集中管理的策略应用程序方面。根据服务器的不同角色将其归入相应的组织单位，管理员可以在整个企业范围内部署标准的安全配置，而无需逐台服务器进行重复作业。基于标准的组策略累积和应用程序逻辑，组织可以设计分层的服务器角色层次结构，如此一来，只需运用少量的主策略即可确保数百以至数千台单个服务器的安全。当单一服务器角色要求主策略进行变化时，将会在 OU 层次结构中“更加靠近”服务器本身的位置创建更小的、基于角色的增量策略。这也就是说可以进行小的改动来启用特定于角色的功能，而无需复制全部的组策略，使得大型企业在享有集中管理策略优势的同时具备一定的灵活性，以适应特定的应用程序。
这种方法最大的困难在于如何实现。要知道大型企业拥有许多不同的应用程序和服务器角色，创建一组正确的策略不但困难而且费时，而这在 SCW 出现之前事实如此。通过使用 SCW 生成策略并将那些策略附加至相应的 OU，那么无论是按照现有的工作负荷还是未来调整之后，您都可以大幅缩减部署主机目录和基于角色安全策略所需的时间。为了更好的描述如何进行这项工作，我们先大概了解一下大型企业中 SCW 和 基于角色的 GPO 的实施过程。

企业中的 SCW
在这个例子中，我将引入虚构的 Contoso 网络。Contoso 是一家巨大、复杂并且地理位置分散的 IT 企业。为了降低运营成本并提升服务器的安全性，Contoso 依照 Microsoft 的指南创建了一个基于角色的 OU 层次结构，该层次结构根据工作负荷来分拆与组织服务器。此外，Contoso 还应用 SCW 创建了可附加至这些 OU 的策略。
由于 SCW 并非默认安装，因此 Contoso 需要在其无人参与安装映像下单独启用 SCW 组件。要进行此操作，需要在 Unattend.txt 的 [Components] 部分添加新命令行：SCW=On。因此，所有利用该映像构建的新系统在设置期间都会自动安装 SCW 组件。要注意的是，如果仅仅配置 SCW 以进行安装的话，在构建时不会针对服务器应用任何的策略。
要在设置期间应用默认的策略，Contoso 需要根据下列选项在调用 scwcmd 的映像中编辑 cmdlines.txt 文件的 [Commands] 部分。
scwcmd configure /p:ContosoBaselinePolicy.xml
文本文件与 XML 文件都应位于映像的 $OEM$ 目录内。为什么 Contoso 在构建时要应用基准策略，而不仅是依赖附加在目录中顶级 OU 的策略呢？通过在构建时应用策略，Contoso 可以确保一致的基准，而无需考虑某台服务器是否已加入 Active Directory®。举例来说，假设以测试为目的构建一台服务器，那么在构建过程中应用基准策略的话，即使服务器始终没有加入产品 Active Directory，至少也可以保证其会遵循组织的标准安全策略。如果服务器之后又加入 Active Directory，组策略应用程序与优先级算法将会用域或 OU 级设置的策略覆盖本地设置（切记策略应用程序的优先顺序依次为本地、站点、域、OU）。
安装 SCW 之后，Contoso 就可以开始创建自有基准策略。基准策略应该部署在基于角色安全性 OU 层次结构的顶层，并且应该是层次结构中限制性最强的策略。这一设想以尽可能保证默认安全为目的，然后只开启那些服务器角色针对相应工作负荷而要求的服务和端口。因此，基准策略应该在新构建的空白服务器上进行创建，添加标准的 Contoso 管理工具和实用程序堆栈，然后运行 SCW。例如，基本的 Windows 安装完成之后，Contoso 就可以在服务器上安装（手动或使用 cmdlines.txt 文件）标准的反病毒、备份、管理及监控工具。由于这些工具中的每一个都可能创建自身的 Windows 服务，因此在创建基准策略前将其置于服务器内，然后使用 SCW 在服务锁定阶段对其提高警惕。
一旦服务器构建成功，Contoso 便可以运行 SCW。SCW 即可以本地运行，也可以远程运行，但是只有该服务器的本地管理员组成员才有运行权限。如果 SCW 正在远程运行，会提供一个选项用于指定远程主机下拥有运行权限的用户帐户；如果 SCW 正在本地运行，则可以使用 runas.exe 来完成相同的操作。SCW 执行的第一项任务是对本地服务器上运行的服务进行评估，然后显示哪些角色当前业已安装（见图 5）。
图 5 选择并查看服务器角色
图 5 选择并查看服务器角色
由于 Contoso 的基准服务器专门设计用于高度受限状态，因此不应选择任何角色。服务器承担的角色选定之后，下一步便是确定所需的客户端功能以便启用自动更新、Active Directory 或 FTP 客户端等功能。对于大部分组织而言，接受 SCW 默认设置（如图 6 所示）可以提供重要的功能（例如加入域的能力），同时禁止不太重要的功能（如 FTP 客户端）。
图 6 安装功能
图 6 安装功能
接下来 SCW 提示您选择哪些特定管理工具和非默认服务。这些非默认服务选项就是安装标准的 Contoso 服务器管理堆栈之后运行 SCW 的原因所在。当防病毒、备份以及相关应用程序安装好之后，SCW 便可以加载这些服务的知识，进而将其包含在生成的策略设置之中。
服务加强部分的最后一个问题是如何处理未指定的服务。即使未指定服务并没有运行在最初创建策略的计算机上，我们在应用了 SCW 策略的其他计算机上还可能会遇到这些服务。例如，假设在一台安装有若干新款第三方应用程序的新建服务器上应用基准策略，那么此应用程序安装的任何服务都将依照管理员所做的决定进行处理。SCW 既允许管理员不改变服务的启动模式，也允许管理员将其禁用。选择禁用是更为安全的选择，但在应用时要小心谨慎，因为这样的话，任何未明确允许运行的服务都将禁用。因此，对于高安全性、组织良好的环境，这是最合适不过的选项。而对于组织的其他部分，建议选择不改变启动模式。因此在 Contoso 示例中，选取此选项。在该任务的服务器加强部分完成之前，SCW 会向管理员提交一份服务将被更改的报告。
在服务加强结束之后，SCW 则会给出限制入站网络访问的选项。与特定角色要求的服务列表一样，特定工作负荷要求的端口列表包含在 SCW 的 XML 数据库中。
管理员可以根据需要配置其他端口，并制定每一服务端口的准则，如图 7 所示。对于 Contoso 基准服务器来说，只允许诸如远程桌面这种最基本的服务。除此以外，所有服务都将在 OU 层次结构之下基于角色的策略中进行配置。
图 7 查看和允许端口
图 7 查看和允许端口
SCW 允许管理员选择注册表选项，例如签署文件和打印通信。在基准配置中，我再次向您推荐选择最安全的默认设置作为最佳实践。
下面一组选择会涉及系统审核策略。在大多系统下，最好选择审核成功活动选项；审核所有活动会占用大量的处理器能力并在审核日志中生成大量数据。当怀疑遭到攻击或急需更加详细的分析结果时，就会在特定的服务器上启用失败审核。
最后，SCW 将会向管理员提供加强 IIS 的选项。这些选项与 IIS Lockdown tool 中可用的选项非常相似，而现在则直接集成到 SCW 策略之中。
在所有步骤完成之后，SCW 会提示管理员保存 XML 文件。保存后的文件被转换成组策略本身可以理解的格式。Scwcmd.exe 会将 XML 文件保存到一个 GPO 之中。需要输入的命令如下：
scwcmd transform /p:ContosoPolicy.xml /g:ContosoBaselineSecurityPolicy
在 Active Directory 下自动创建该策略，并附加至 Contoso 基于角色的强化 OU 层次结构的顶层。
而只要此策略应用到层次结构的顶层，则任何加入到该 OU 层次结构中的机器都将继承其设置。当新添加机器后需要对此策略进行修改时（像加入 IIS 服务器要求运行 W3SVC 服务），Contoso 管理员会针对新的服务器角色重新运行 SCW，并把此新策略转换为 GPO，然后将此 GPO 附加到包含该服务器中的子 OU 结构下。由于距离服务器最近的 GPO 拥有优先权，因此最终会导致全部的基准设置都将沿用，但那些要求修改以启用 OU 所需角色功能的设置除外（见图 8）。
图 8 Contoso 的策略应用程序
图 8 Contoso 的策略应用程序
越是大型组织或是部署众多服务器，越能够体现这种方法的真正价值。一旦创建初始 SCW 策略并附加至 OU，那么只需要将后续服务器添加到该 OU 就可以自动继承合适的安全策略。因此，只要创建初始的一组策略并加入到 Active Directory，那么之后部署新服务器或替换现有服务器的过程将会变得简单而且快捷。

预先准备
在下一版本的 Windows Server "Longhorn" 中，Microsoft 操作系统已经极大程度地实现了组件化，与现在相比，最终只会产生简化与有限的受攻击面。管理员再也不必将精力浪费在最低限度的默认安装方面，而是使用服务器管理器工具在每台服务器上添加其所需的角色和工作负荷。服务器管理器的工作方式与 SCW 很相似，其内部依赖关系数据库允许安装程序只添加那些要求的功能，以得到所需要的角色服务。更为重要的是，本文所讨论的应用组策略集中管理并基于角色的安全性，可通过大幅扩展的 GPO 控制功能集而得到进一步的加强。简而言之，拥有更高灵活性与更强大安全性的 Windows Server "Longhorn"，已将独有的 SCW 概念引领一个新的高度。
SCW 资源
下列网页会为您提供一些使用 SCW 的入门提示：
  • 安全配置向导文档
  • Windows Server 2003 安全配置向导
  • Windows Server "Longhorn"

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


 桌面文件: 我的 x64 经历
桌面文件
我的 x64 经历
Wes Miller

Windows XP 本身对 64 位体系结构支持已有五年之久。但除非您是 Intel Itanium 处理器的先行采纳者之一（与 Windows XP 同一天发行的 Itanium 专用 Windows XP），您也许最近才听说有可以在 x64 体系中应用的 Windows XP 和 Windows
用于 x64 系统的 Server 2003 版本。x64（在业界也称为 x86-64）是对 AMD 的 AMD64 体系结构和 Intel 的 EM64T 的统称。而如果您是去年前后才购买的新 PC ，那么它很可能支持 64 位，即使当前还只是 32 位系统（最有可能的情况）。
如今我为德克萨斯州奥斯汀市的一家小型创业公司工作。由于我们产品之一的体系结构，我们对利用 x64 体系结构中某些特定的优点很感兴趣 — 这很像 Microsoft® Exchange 2007 团队，他们开创了只面向 x64 体系结构单独开发的先河。类似地，我所管理的开发和测试团队在开发工作站、笔记本电脑、服务器和生产服务器的时候，只在 Windows® XP 和 Windows Server® 2003 的 x64 版本上进行部署。此外，我还在自己的笔记本电脑上运行 Windows XP Professional x64 Edition 以便测试并调试我们的产品。
有趣的是，当我提到运行 64 位 Windows（尤其是在移动系统上）时，大多数人的第一反应都是非常困惑的神情。而如果他们熟悉 64 位计算，就感觉像怀疑遭到了别人的不屑与惊讶 — 因为人们通常都认为很难为 64 位系统找到设备驱动程序。在本月的专栏中，我将说明自己如何并且为什么在 x64 系统中的 64 位模式下使用 Windows XP 和 Windows Server 2003，同时我还会介绍一些您可能会遇到的部署优势（和障碍）。我还会深入探究 Windows Vista™ x64 的支持、迁移和部署事宜。

历史一瞥
正如我前面所说的，最初 Windows 中的 64 位支持确实是从支持 Intel Itanium 处理器开始的。（虽然 Windows 支持 64 位 Alpha 处理器，但却从未真正在 Alpha 上运行过 64 位。）Windows XP 和 Windows Vista 不支持 Itanium，所以 x64 体系结构目前也只是对 64 位 Windows 客户端计算的单相思。如今许多版本的 Windows Server 2003 都支持除 Itanium（基本上它已经只面对超高端数据中心负荷）外的 64 位，我认为这种趋势会持续应用到发售代码名为“Longhorn”的下一个 Windows Server 版本。
安装 Windows Server 2003 Service Pack 1 (SP1) 之后，Windows即可支持 x64 平台。这虽然有些令人困惑（当 x64 版本的 Windows XP 可用时也是如此），但也意味着 Windows XP 32 位产品和 64 位产品来源于 Windows 内部截然不同的代码树。现在 32 位产品已经有了第二版可用的 service pack；而从技术上来讲，64 位版本的 Windows XP 还根本没有 service pack（或者您可以认为它已经补充集成了 Windows Server 2003 SP1）。
为了运行 64 位 Windows（Windows XP、Windows Server 2003、Windows Vista 或 Windows Server“Longhorn”），系统的需求实际上是相同的。显然，首先要拥有 64 位处理能力的处理器。对 AMD 而言，这意味着寻找极力推崇 AMD64 兼容性（请参阅 amd.com/us-en/Processors/ProductInformation/0,,30_118,00.html）的单核、双核或四核系统。对 Intel 而言，这意味着寻找推崇 EM64T 支持或 Intel 64 体系结构（请参阅 intel.com/technology/intel64）的单核、双核或四核系统。请注意，细节决定一切。例如，Intel Core Duo 系统不支持 64 位。而 Intel Core 2 Duo 系统却是支持 64 位的 — 虽然它可能只是称为 Centrino Duo（我的笔记本电脑所使用的）。

与 x64 同在
一旦您确定了系统是否原本就支持 64 位 Windows 版本，您就需要处理设备支持的问题。遗憾的是，尽管 Microsoft 一直在鼓励供应商和 OEM（至少在过去两年的 WinHEC 会话中是如此）为其设备和系统创建并验证 64 位驱动程序，但您在使用 Windows x64 时遇到的最大难题依然是找到硬件设备的驱动程序或软件。以我的经验来看，要在服务器（其中必要的设备支持受到限制）上运行 x64 取得最大的成功，利用 x64 的优点则是最合乎逻辑的。
最困难的是寻找桌面和移动系统的驱动程序。通常情况下，如果您主要的 OEM 供应商或系统创建于企业级组件（商用的可能性迫使供应商或 OEM 创建并签署支持 x64 的驱动程序），那您就交到好运了。
对于 Windows Vista，这一情况变得越来越好。但人们都喜欢 x86 体系结构，而忽视大多数硬件可用驱动程序都很有限的 x64 体系结构，这也是事实。对于 Windows Vista，设备供应商必须提交 x64 驱动程序进行兼容性测试。事实上，提交不需要也包括 x86 驱动程序，当然也可以包括在内。从概念上来讲，这意味着某些硬件（尤其是那些利用 Windows Vista 新性能的设备）也许实际上只能支持 x64 Windows，而不支持 x86。
现实是，当您尝试运行 64 位 Windows 本身时，驱动程序只是您将遇到的其中一个问题。还有更棘手的问题（或者说迁移）等待解决，我会在后面讨论。

为什么使用 64 位？
当然了，AMD、Intel 和 Microsoft 并不是为了寻开心才涉足 64 位体系结构的。转移至 64 位会带来几个主要的益处。正如您在图 1 中所看到的，x64 体系结构提供的最重要的改进就是寻址更多的内存（最高可达 16TB）；相对而言，32 位 Windows 却只能寻址 4GB 内存。请注意，虽然 64 位指针寻址的上限为 16TB，但应用程序却只能访问最多大约 8TB。
Figure 1 内存地址空间限制 (Close Figure 1)

地址空间 | 64 位 Windows | 32 位 Windows
虚拟内存 | 16TB | 4GB
页面文件 | 512TB | 16TB
分页池 | 128GB | 470MB
非分页池 | 128GB | 256MB
系统缓存 | 1TB | 1GB
此外，Windows 的 x64 版本还提供了基于硬件的数据执行保护 (DEP) — 在有 NX（无执行）支持的 x86 系统上同样适用。这样做可以防止 Windows 利用的硬件驱动解决方案缓冲区溢出。它还防止从内存的数据页进行代码执行 — 请参阅 support.microsoft.com/kb/875352 了解关于本主题的更多信息。
与 x86 版本的 Windows 一样，x64 版本的 Windows 允许本身支持多处理器或多核 CPU。但在所有 Windows x64 安装过程中，单一硬件抽象层 (HAL) 的使用消除了映像 Windows XP 系统这个最复杂的难题 — 再也不必为识别非 ACPI 或单 CPU 系统中的 HAL 而烦恼了。
从本质上讲，Windows x64 作为体系结构允许使用现有的管理基础结构和现有的 32 位软件（通过模拟）以及拥有访问这种增强内存能力的 64 位软件。实际上，向 Windows x64 转变唯一的负面影响是：完全不支持 16 位应用程序（包括象带有 16 位安装程序的 32 位应用程序）；当硬件 DEP 启用时应用程序不能可靠运行的问题（尽管可以逐个进程停用 DEP，并且 Windows Application Compatibility 团队修补了一些 DEP 启用后无法正确运行的应用程序）；最后，事实上 64 位 Windows Vista 中的所有驱动程序必须进行数字签名。
加入最后一项是为了防止对内存中 Windows 内核的恶意篡改，这是 rootkit 经常使用的技术。我们的预期是，既然 x64 是第一个 Microsoft 鼓励供应商开发驱动程序（目的是通过 Windows 硬件质量测试得到驱动程序）的体系结构，那么要求也许并非象过去那么可怕。
在考虑面向 x64 系统的 Windows 时，还要注意其他一些要点。面向 x64 系统的 Windows XP 版本中并没有 Windows Media® Center Edition 或 Windows Tablet PC Edition 中所包含的功能。然而，这一情况在 Windows Vista 中却发生了改变，其中 Windows 的 x64 版本拥有与 x86 版本相同的功能。

虚拟化
有一件事之前我并没有提到，那就是虚拟化。我说的并不是 Microsoft Virtual PC 或 VMWare PC 虚拟化产品；而是指面向 32 位执行程序的操作系统虚拟化。在 Windows 的 32 位版本中，16 位应用程序全部运行于 NTVDM（一个 MS-DOS® 虚拟机）环境中。正如之前我提到的，Windows 的 64 位版本不支持 16 位应用程序。相反地，大多数 Windows 集成组件本身都以 64 位二进制程序运行，而部分组件和许多第三方程序以 32 位应用程序运行。
Windows 为您提供了一个全新的称为“窗中窗”(WOW) 的模拟层，以便查看这些 32 位应用程序在操作系统中的不同视图 — 在 Windows 的 32 位版本中运行颇为有效。在 WOW 下，x86 应用程序可以轻松地将 Program Files (X86) 看作“程序文件”。同样地，%WINDIR%\SysWOW64 对于 x86 应用程序显示为 %WINDIR%\System32。x86 应用程序查看注册表项 HKLM\SOFTWARE\Wow6432Node 就像查看 HKLM\SOFTWARE 节点本身一样。
通过使用 Process Explorer 工具，您可以从虚拟化的另一个角度进行查看。由于许多 32 位应用程序都预期与集成的 32 位 Windows 二进制程序相交互，因此许多这类二进制程序都同时提供 64 位和 32 位版本。通过对 Process Explorer 添加附加列，您可以方便地观察到这一点。在图 2 中，您会注意到 cmd.exe 的两个实例 — 一个是 32 位版本而另一个是 64 位版本。请注意，在突出显示的 32 位实例中，您可以看到若干加载于 32 位进程中的 wow64* DLL。这些文件显示了虚拟化的执行，即在 64 位 Windows 下实现 32 位应用程序的功能。同时注意 cmd.exe 64 位和 32 位版本使用的工作目录（路径）。
图 2 Process Explorer 显示 cmd.exe 的 32 位和 64 位版本
图 2 Process Explorer 显示 cmd.exe 的 32 位和 64 位版本
关于虚拟化问题最后要注意的一点 — 当 Windows 将 explorer.exe 作为本机 64 位应用程序运行时，有利也有弊。最大的弊端就是要使任意 Explorer 外壳扩展工作必须面向 64 位重新编译（大部分尚未重新编译）。
相反的 Internet Explorer® 也一样 — 它本身默认以 32 位版本运行。这基本上已经实现，因此如今已大量运用于 Internet 上的 ActiveX® 控件还将继续取得成功。但如果不是这样，由于 64 位应用程序不能加载 32 位的 DLL 或进程中的驱动程序，因此也就无法有效的加载 32 位 ActiveX 控件，而在 64 位浏览器中，几乎所有目前可用的 ActiveX 控件都是 32 位的 — 这意味着将无法访问 Internet 上相当数量的内容。结合实例看一下，尝试在一个 64 位 Windows 系统中加载 C:\Program Files\Internet Explorer\iexplore.exe 并任意访问一个加载 ActiveX 控件内容（甚至是 Windows Update）的站点 — 结果就是会出现不同程度的加载失败。Windows Update（参见图 3）现在已经更新了在这种情况下打开 Internet Explorer 的 32 位实例的方式。将来，一些更新内容并利用 64 位 Internet Explorer 的 ActiveX 控件一定会出现。但在大多数 Windows 系统都运行纯 32 位 Windows 的今天，更新 ActiveX 控件内容并不是至关重要的。我希望这一转变不要来的太晚。
图 3 32 位 ActiveX 控件在 64 位 Internet Explorer 中加载失败
图 3 32 位 ActiveX 控件在 64 位 Internet Explorer 中加载失败

Pluck 公司的 x64 Windows
在本文的开始部分我曾说过，Pluck 公司已经开始转向 x64 Windows。我们已经在三个不同版本的 Windows 中完成了这项工作：Windows XP Professional x64 Edition、Windows Server 2003 Enterprise Edition x64 和 Windows Vista x64。
当我们最新的产品开发起步时，我们的组织规模很小，但我们已经可以进行向面对 x64 的 Windows 迁移并且利用了它的优势。这样做意味着确保我们定购的所有新硬件均支持 x64。实际上，正是虚拟化对 x64 扩展性能的影响才促使我们以这种方式运行产品。我们所有的物理服务器都作为 64 位虚拟服务器运行在 64 位主机服务器上。每一台主机服务器拥有 16GB 的 RAM，然后分配到位于其中的虚拟服务器中（大体是每一个分段虚拟主机或 VM 分配 2GB，而每一台生产 VM 分配 3GB）。
同时通过使用 tier 1 系统和虚拟的硬件，我们几乎实现了 100％ 的设备支持率。例如，我的笔记本电脑就有三个没有可用 x64 驱动程序的设备。这些如背板类型的设备并不重要，缺少了它们系统依旧可以正常运行。有趣的是，Windows Vista RC1 x64 有一项安装的设备支持完全相同 — 虽说我的系统有支持 Windows Vista 的徽标，然而供应商还是会在最短的时间内将您缺少的驱动程序交到您手中。
由于我们使用的系统主要限于 Microsoft Office、Visual Studio® 和一些开发和构建流程中用到的附加工具，因此在迁移的过程中不会遇到太多原有应用程序所引起的兼容性问题。在许多组织还在使用 Windows 的 32 位版本时，我们就已经在新硬件上开始了相对顺利的 64 位迁移历程。

x64 部署与迁移
关于部署需要考虑以下几点注意事项。Microsoft 提供了一个特别针对 x64 体系结构的 Windows 预安装环境 (Windows PE) 版本。然而，由于在 x64 系统上也有相同的 x86，那么您可能也打算使用 x86 Windows PE 进行部署 — 尤其当您使用的是映像解决方案时。如果您正在使用无人参与的安装来部署 Windows XP，那么 Windows PE 就必须拥有特定的体系结构 — 因为 winnt32.exe 必须在它所部署的相同体系结构下运行。由于 Windows PE 不具备 32 位兼容性层，而在 x64 下的 winnt32.exe 又是 64 位应用程序，因此 32 位的 Windows 就需要 32 位的 Windows PE。这同样适用于 Windows 的 64 位版本，它要求的是 64 位的 Windows PE。
在这方面远程安装服务 (RIS) 却是不同的，出于此原因，我们 Pluck 应用 RIS。RIS 最早应用于 Windows Server 2003 SP1，它可以部署 Windows 的 x64 及 x86 或 Itanium 体系结构。当一个 x64 系统连接到一台 RIS 服务器时，服务器（在默认配置下）将提供 x86 和 x64 的 RISetup 或 RIPrep 映像。我们还可以配置 RIS 同时提供 x64 客户端专用 x86 映像或专用 x64 映像。这一默认选项为 x64 硬件的应用带来了最佳体验。
请注意，我还没有提过升级。这样做是有原因的。不幸的是，对整个操作系统进行从 x86 到 x64 的升级是一件相当繁琐的事情。出于此原因（以及对 Windows XP Pro x64 Edition 的部署加以限制），您既不能从任何 x86 版本升级到 Windows XP x64，也无法从任何 Windows XP (x86 或 x64) 版本升级到 Windows Vista x64。同之前的 Windows XP Pro x64 Edition 一样，x64 系统上的 Windows Vista 也是只能进行全新安装的产品。因此，许多组织只有在硬件经常刷新时才会考虑移植到 x64 — 他们期望使用同 Windows Vista 本身类似的策略（同时使用双跳可能是个合乎逻辑的选择）。
但那却并不意味着从 x86 Windows 转向 x64 Windows 的个人或组织没有任何现成的工具 — 事实上肯定是有的。面向 Windows XP 和 Windows Vista 的两个用户状态迁移工具 (USMT) 版本都已扩展，用以支持从一个 Windows 安装到另一个安装的迁移（相对于操作系统的带内升级）。这是如今多数组织在不考虑擦除并重新加载的情况下最常用的方式（甚至是在同一台 PC 上），因此利用相同的机制迁移到一个全新体系结构的 Windows 时不应制造比原来更大的麻烦。

结束语
尽管我们这个小型组织向 x64 的逐步迁移也许会比大型组织所面对的庞大迁移进程简单许多，但每个 IT 专家都应该开始考虑最终转向 x64 体系结构了。事实是，虽然在今后十年间 x86 体系结构和 x86 本身的 Windows 版本仍将占有一席之地，但 x64 体系结构肯定是企业计算的将来。随着 Microsoft Exchange Server 和其他一些产品全面转向 x64，您首先需要开始了解 x64 系统将在安装在您体系结构中的何处，它们在您的 Windows Vista 迁移计划中起到什么作用，以及您正在使用的 Windows XP 或 Windows Server 2003 本身是否如今已经运行于 x64 系统中。

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


 Microsoft.com 技术内幕: 使用 Active Directory 联合身份验证服务
Microsoft.com 技术内幕
使用 Active Directory 联合身份验证服务
Jim Guthrie

Microsoft 能够为业务伙伴提供外联网，使他们得以访问重要的内部资源。外联网的体系结构要求组织外的每个参与者都要在该空间中拥有唯一的域帐户。由于众所周知的原因，是 Microsoft 工作人员而不是业务伙伴
来创建和管理该帐户。否则的话，用户体验就可能达不到令人满意的效果，而管理如此众多的伙伴用户也会给 Microsoft 造成相当的资源负担。
这就是为什么使用外联网的道理。当客户或合作伙伴登录一项应用程序时，需要输入其凭据。在同样的会话期间，如果用户决定访问不同的资源，系统还会提示其输入凭据。只要持续访问不同的资源，就要不断的输入凭据。如果用户登录一项单独的应用程序，而该应用程序又涉及到多种资源，例如财务数据库，则用户需要针对所有不同的资源进行身份验证。这对于用户可说是既麻烦又费时的使用体验。
幸好，使用 Active Directory®联合身份验证服务 (ADFS)，我们能够非常轻松地解决多个身份验证的问题，您也一样。ADFS 是一个 Windows Server® 2003 R2 组件，能够增强两个或多个组织间的信任机制，使他们共享多个资源，同时又保证了每个组织管理自己用户组的能力。在本专栏中，我将阐明 Microsoft 是如何规划使用 ADFS 来解决此多资源外联网问题，这将为您实施类似解决方案提供必要的参考信息。在讨论细节问题之前，我们先看图 1来熟悉一些基本的 ADFS 术语。
Figure 1 ADFS 术语 (Close Figure 1)

术语 | 定义
联合身份验证 | 建立 Active Directory 联合身份验证信任的一对领域或域。
联合身份验证服务资源 (FS-R) | 向 FS-A 和所需资源输入身份验证请求的路由。
联合身份验证服务帐户 (FS-A) | 提供 FS-R 身份验证要求的帐户令牌。
联合身份验证服务代理 (FS-P) | 为 FS 服务器提供入站 Internet 通信隔离层。
声明 | 服务器关于客户端作出的声明（例如名称、标识、密钥、组、权限或功能）。
领域发现 | 每个 FS-A 都有一个域或领域，登录凭据就储存在这里。领域发现决定 ADFS 会话使用哪一个 FS-A。

ADFS 解决方案
当用户试图访问可识别 ADFS 的应用程序时，会将浏览器发送到联合身份验证服务资源 (FS-R) 以进行领域发现。用户可选择在会话期间使用哪一组凭据。基于客户端选择的领域，用户会被重定向到联合身份验证服务帐户 (FS-A) 服务器。用户将从该服务器收到一个基于用户输入凭据的有效帐户令牌（存储在 cookie 中），该凭据以下列形式输入：Windows Live™ ID（以前的 Passport 帐户）、Windows 集成身份验证或 SSL 身份验证（见图 2）。在该模型中，由各组织自行维护他们自己的帐户联合身份验证服务器。有了 Microsoft 业务伙伴的服务器，就省去了 Microsoft.com 在此环境下管理所有帐户的负担。当然，如果您担负起了相应的责任，就必须仔细选择与之联合的组织，并保证这些组织能够积极地管理他们的帐户信息。
图 2 ADFS 流程
图 2 ADFS 流程
路由的下一站是返回到 FS-R 服务器，将帐户令牌换为资源令牌。在此配置下，该令牌包含了用户在 FS-R 上执行声明映射过程而获得的完整的权限列表。一旦收到令牌，在整个会话开启期间或者在默认的 24 小时（可自行配置）内，用户将针对可识别 ADFS 的应用程序获得单一登录 (SSO) 能力。结论就是您能够在可识别 ADFS 的应用程序上启用 SSO，进而是更加安全和高效的客户体验。欲完整了解 ADFS 身份验证过程，请参阅 Matt Steele 于 2006 年 7 月在 TechNet 杂志上发表的文章，标题是：使用 ADFS 简化单一登录操作。
为了保证 Microsoft 企业资源的安全，我们将外联网面向 internet 的一端和公司端隔离开来，这就是说每个服务器潜在都是双宿主服务器。我们允许来自公司内部用户的单向信任，并使用服务器提供所需的保护。我们也为外联网空间建立了单独的域，这样外部用户可以访问他们需要的资源。
实施过程中应加以关注的两个主要领域是负载平衡和 ADFS 策略文件更改。负载平衡对全局和局部而言都是一个挑战。最初，我们在两个区域的前端 Web 服务器群集使用了内容传送网络 (CDN) 合作伙伴 Akamai 或 Savvis 提供的全局负载平衡。这将保证系统对最终用户的可用性，即使是在双区域服务器脱机这种极少发生的情况下，也是如此。通过 CDN 提供的服务器运行状态检查服务，自动进行故障转移而实现上述目标。而且，将来我们能够很轻松地加入更多群集。为节省成本，我们的预运行部署选择了不使用 CDN 服务。
在区域性水平上，我们通过网络负载平衡 (NLB) 群集，配对服务器使其具备本地故障转移功能。我们没有使用任何特殊的负载平衡功能，所以仅仅通过硬件就能轻松完成该工作，而这里我们为了节省成本再次使用 NLB。在其支持的所有环境下，该配置将保证超过 99.9% 的正常运行时间的稳定性。
我们面对的另一个挑战是：在整个环境中，确保 ADFS 策略文件和ADFS 主干线的正确分布，并且能复制对其所做的任何更改。为了实现这一点，我们利用 Windows Server 2003 R2 的另一内置功能 — 分布式文件系统复制 (DFS-R)，一种基于状态的新型多主机复制引擎。在每台后端服务器上，我们启用一个 24 小时的交错复制 DFS-R 组成员身份。现在，无论对策略文件做什么更改，都会分发到所有的服务器上。只要我们控制了更改文件的权限，我们就拥有稳定的、高可用性的服务。
我们已经努力促使所有的更改都能通过 ADFS 管理单元进行，但事实上我们有时不得不手动更新文件。当手动更新时，切记要让 ADFS 跟踪该文件的版本。因此您必须添加该文件，这样你的更改会反映在环境中：
<TrustPolicyEntryUri>urn:federation:parttestint</TrustPolicyEntryUri>
<TrustPolicyVersion>127
</TrustPolicyVersion>
还要记住，像所有的 XML 一样，策略 XML 文件也区分大小写。在整个策略 XML 文件中，有许多对应用程序或其他 ADFS 服务器的引用。在这种情况下，必须将其逐字逐句地从一个服务器复制到另一个服务器。请注意下列的常见示例：第一，RevocationCheckFlags 是由手动输入；第二，在 UI 上改变一个受信任应用程序的 URL。
<RevocationCheckFlags>None
</RevocationCheckFlags>
<TrustPolicyEntryUri>https://adfstest.parttest.extranettest.microsoft.com/NTApp/
</TrustPolicyEntryUri>
对于其他的安全级别，我们使用另一个 ADFS 组件，联合身份验证服务代理 (FS-P)，保证有传入的 Internet 请求时，FS-R 保持为一层而不被直接访问。Microsoft.com 实施代理的独特方式是：在预运行中使用单独的一组代理，作为几个 ADFS 环境的宿主。有趣的是，开发此技术之初，我们发现需要简单地修改一下注册表项才可以实现上述功能。该注册表项位于 HKLM\Software\Microsoft\WebSSO。简单修改一下该注册表项的初始目录值，能够让您在几个环境下使用该代理。其默认位置是：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttestint”
如切换环境，注册表项会有如下变化：
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WebSSO]
“InitialDirectory”=”E:\\\\ADFS\\\\parttest”
创建批处理文件可以简化这一过程的管理。然而当前版本的 ADFS MMC 管理单元不支持环境切换，因为代理和资源或帐户服务器之间是一对一关系。这是代理服务器利用率实现最大化的唯一方式。最终会节省巨额成本，因为无论选择多少不同的环境作为宿主，所需物理服务器的数量是有限的。
从体系结构的角度来讲，我们是在虚拟机上运行预运行环境，这又是一种节约成本的方式。可以省去额外购置六台服务器的需求。至今还没有出现过任何性能方面的问题。然而，为了满足运行环境方面急剧增长的需求，我们选择了使用更高性能的物理机器。

不仅仅是 Active Directory
Microsoft.com 不仅使用 Active Directory 帐户进行身份验证，而且与 Windows Live ID 帐户也成功地进行了集成。我们发现通过使用 Windows Live ID (WLID) 4.5，就能在单独的 Windows Live ID 中使用客户声明转换来代理访问 Microsoft 资源。这是实现 SSO 身份验证的巨大胜利，因为我们不再需要特定的域帐户。

挑战依然存在
我们眼前最大的挑战就是共享令牌签名证书的 ADFS 管理工作。我们使用仍然有效的标准证书，尤其是那些尚未续订、有效期为一年的证书。续订时，每台适当的服务器都需要进行相应的更新，这将对 FS-R 产生重要的影响。尽管可以管理大约 15 到 20 个联合身份验证，但是我们希望的规模即使达不到数千个，也至少是数百个联合身份验证。这样，就需要有全职员工在单独的环境下管理 SSL 证书。我们有几个团队正在探寻使上述解决方案实现自动化的最佳方法，但其执行过程还没有最终确定下来。
另一个的挑战是迄今为止，并不是所有的应用程序都能识别 ADFS。这就需要站点进行一些编程才能利用 ADFS 的优势。我们正与 Microsoft® Office SharePoint® 服务团队紧密合作，确保下一代 SharePoint 能够支持 ADFS 的实施要求。

结束语
如果您决定转到 ADFS 模式，那么还需要另外考虑一些因素。其中之一是客户可以访问的资源数量。在组织之间建立联合信任也许是个普通任务，但也需要时间和精力来编写、检查和执行可以接受的访问策略。因此，如果仅有一个资源供客户访问，那么您就要考虑是否有这个必要建立联合信任。但是，随着资源数量的增加，所能得到的好处也会增加。
更多信息请参阅ADFS 概述和Active Directory 联合身份验证服务：联合身份验证和访问管理路径。

Jim Guthrie 是 Microsoft.com 运营团队中的一员，而且除了是 ADFS（Active Directory 联合身份验证服务）的工作成员外，他还是企业门户平台支持团队的系统工程师。


 现场注意事项: 学习中的乐趣（和痛苦）
现场注意事项
学习中的乐趣（和痛苦）
Mark D. Scott

我记得 当开发出一些新产品时我曾经的表现 — 先于大多数人接触到最新的技术时的激动，仔细研究该产品，学习它的工作原理以及投入使用。作为一个先行采纳者，我开始迅速成长为一名行业专家，一个别人都来讨教专业知识的奇才。
但是，在这个过程中，喜悦慢慢地消失了。我不确定是为什么。也许是因为凌晨三点还在努力地尝试使关键任务应用程序奏效的挫折让我丧失了喜悦感。也许是随着被我看错当成企业邮件服务器的产品文档一起去了南方（那时一台服务器就已经足够了）。也许是我老了，变得愤世嫉俗了。没有关系。现在熬夜的确已经没有了十几年前的那种兴奋。但这并不意味着我可以停止学习。不久前，我更加坚定了这一想法。
我最近刚升级到 Microsoft® Outlook® 2007，我非常喜欢它。但是，我还是一个 MSN® 高级订阅者；我的 ISP 提供订阅作为其服务的一部分。在上一版本的 Outlook 中，我需要一个特殊软件调用连接器以访问我的 MSN 电子邮件地址。这一软件连接器在 Outlook 2007 中无法使用，因此我联系了 MSN 的相关人员。MSN 人员让我跟 ISP 联系。最后，我的 ISP 告诉我 Outlook 2007 不支持 MSN Outlook 连接器。经过反复的邮件、聊天和语音联系，最终得出的就是这个消息。
这时我的脑中灵光一现 — 可能我不再需要连接器。我启动 Outlook 2007，在不使用连接器的情况下配置了一个到 MSN 的新连接。Outlook 接入 Internet，找到了服务器，并且毫无阻碍地配置好账户。我其他几个 POP3 账户也是这样配置的。就这样，我获得了访问电子邮件的方法，并且学到了该产品的一个非常不错的新功能。
现在，我有了做这一切事情的动力。如果支持团队中有人不怕麻烦而仔细研究过新产品，他很可能会告诉我根本就不需要连接器，这样会节省我们双方很多时间。
也许从这个角度来说，如果我一开始就自己研究该产品的话，我将很可能自己找到解决的办法。但是，那时我只想要别人告诉我答案。因为没有人花时间去研究一些（尽管）对我们日常生活很重要的东西，所以我们都浪费了比如果我们自己深入研究并解决问题（无论如何，我最终还是做到了这一点）更多的时间。
技术的变革战胜了我们预先的假设。作为 IT 专业人员，我们不应该先入为主。我们尽最大努力获得的知识将不可避免地为新技术所取代 — 因为知识的更替正是技术变得更简单易用的原因。学无止境，我们不能把神秘的知识作为永远的竞争优势。真正的优势不在于过去技术的累积，而在于掌握新概念和技术的能力。通过持续学习，将学习作为日常生活的一部分，我们仔细研究这些技巧。随着大量新产品的不断涌现，学习是我们的终身追求。
所以，如果您需要联系我，请随意向我的 Microsoft 或 MSN 账户发电子邮件 — 在 Outlook 2007 中，这两个账户的邮件我都可以收到。

Mark D. Scott 是 Microsoft Consulting Services 的一名高级顾问。他与客户紧密合作，帮助设计和实现大型的、以数据为中心的应用软件。您可以通过 granddaddy2002@msn.com 或 mascott@microsoft.com 发邮件联系 Mark。


 Windows 机密: 错误的力量
Windows 机密
错误的力量
Raymond Chen

在 Windows 95 中， 您可以进入“故障排除”页面选择“禁用同步缓冲提交”。但您知道这一复选框是干什么用的吗？或者为什么要这样做呢？
MS-DOS® Commit 功能的正常行为是将某一特定文件的所有未写入数据冲洗到磁盘，并等候直到确认数据已写入后才返回。当选中“禁用同步缓冲提交”选项时，调用将会立即返回，而不必等待数据的写入。当然，这违背了要求调用在数据写入后才能返回的功能规范。这增加了知识库文章 139669 中婉称为“文件完整性问题”的风险，因为它会导致程序发出冲洗请求，认为磁盘上的数据是安全的，但是事实上不是。
数据库程序可能使用“提交”功能来建立一些点，在这些点上，磁盘上文件的状态和程序所希望的状态一致。如果计算机在更新过程中断电，那么数据库程序可以使用最后提交点记录的信息来重新建立数据库的完整性。如果“提交”在提交未完成之前立即返回，则将会丢失此完整性检查点。后果是您的数据库会损坏。
如果后果是如此的糟糕，那为什么还提供此选项呢？原因是：在 Windows® 3.11 中有一个错误。
图 1 在 Windows Server 2003 中启用错误行为
图 1 在 Windows Server 2003 中启用错误行为
Windows 3.11 引入了“32 位文件访问”，它是一个底层文件 I/O 接口的 32 位实施。但“提交”功能的实施包含一个错误，它有效地忽略了冲洗文件缓存的请求。如果您在 Windows 3.11 中运行程序来冲洗文件缓存，则冲洗调用无效。因此，如果您的计算机在不适当的时间断电，您将得到一个损坏的数据库。
Windows 95 文件系统的工作人员修复了这个错误，但是陆续产生新的错误报告。一些人的帐户支付程序运行开始变得非常缓慢。接着，其他人的数据库程序也出现了同样的问题。这是怎么回事？
原来，这些程序不断地发出冲洗调用。编程人员注意到在 Windows 3.11 中冲洗调用非常快，因此他们在程序中无限制地大量调用。写入一个字节，冲洗。写入一个字符串，冲洗。由于冲洗速度很快，因此应用程序可以在每次操作后将数据提交到磁盘，而没有注意到性能的降低。但是一旦 Windows 95 修复了这一错误，这些程序开始运行非常缓慢，因为这些提交的调用突然开始真正工作。
当然，如果文件系统小组没有做任何事，这些程序将会一直运行缓慢，而用户就会得出问题在于 Windows 95 的结论。“Windows 95 运行的非常慢”，他们将会这样告诉其他人。另一方面，如果文件系统还原到旧版的 Windows 3.11 行为，则它们将再次引入将会导致这些讨厌的“文件完整性问题”的错误。
所以他们的结论是，修复这个错误但增加一个复选框（虽然隐藏在“故障排除”页面），以便让运行程序时遇到因为修复错误而引起问题的人们返回到 Windows 3.11 行为。
事实证明，历史经常重演。在 Windows Server® 2003 中，I/O 人员发现了一个错误，即标记为“Forced Unit Access (FUA)”的请求会丢失 FUA 标记并作为正常 I/O 执行。它是忽略冲洗请求的“现代版”！他们修复了该错误，但是留下了返回到旧的错误行为的选项。此复选框的 Windows Server 2003 版本称为“启用高级性能”，但现在您知道它的真实含义是“还原旧的错误行为”。

Raymond Chen的网站旧事重提及其同名书 (Addison-Wesley, 2007) 介绍的是 Windows 历史和 Win32 编程。他没有忘记 tag。