 TechNet Magazine May 2008

TechNet Magazine May 2008

Windows 管理: Windows Server 2008 中的 Active Directory 备份和还原

Windows Server 2008 及新的 Windows Server Backup 实用工具带来了许多变化和广受欢迎的备份增强功能。本文作为一个指南，深入介绍了如何在新的服务器操作系统中备份和还原 Active Directory。

Gil Kirkpatrick Windows 管理: 设计有效的 OU 结构

很多管理员都低估了拥有设计精良的组织单位结构的重要性。了解为什么拥有可靠的 OU 策略非常重要，并为您的组织确定一个最佳 OU 结构。

Ken St. Cyr Windows 管理: 扩展 Active Directory 架构

许多依赖 Active Directory 的应用程序都会定义自己的架构变更内容。但是，必须要确保这些变更不会影响其他应用程序。概述如何通过 classSchema 和 attributeSchema 对象来扩展 Active Directory。

Vikas Malhotra System Center: System Center Mobile Device Manager 简介

新的 System Center Mobile Device Manager 提供了一整套的工具，可以通过 MMC 管理单元或 Windows PowerShell 来管理 Windows Mobile 设备。了解这些必需工具将如何帮助您管理移动设备、提高安全性以及提供移动 VPN 功能。

Matt Fontaine System Center: System Center Essentials SP1 的新增功能

Service Pack 1 为 System Center Essentials 2007 引入了重要的增强功能。本文将探讨可改善用户体验并简化管理的一些关键变化。

Pete Zerger 编辑寄语: 热烈欢迎“深入剖析 SharePoint”

Joshua Hoffman 读者来信: 读者心声

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

Greg Steen Exchange 问题与解答: Exchange 2007 SP1 部署

在本期内容中，我们将回答有关 Exchange Server 2007 SP1 方面的问题。

Nino Bilic 实用程序特别推荐: SharePoint 容量规划

探索 SharePoint 容量规划工具，介绍如何为部署 SharePoint 设计拓扑结构，并在运行负载和使用模拟之后修改该拓扑。

Peter Skjøtt Larsen and Satish Mathew 深入剖析 Sharepoint: 构建 SharePoint 基础结构

虽然 SharePoint 功能非常强大，但其复杂性会使部署变得非常具有挑战性。新的 SharePoint 专栏可帮助您解决此问题。在此第一期专栏中，我们将概要介绍 SharePoint 体系结构，并向您展示如何使用 WSS 3.0 建立基本的 SharePoint 基础结构。

Pav Cherny Windows PowerShell: 自动化目录管理

第 1 版 Windows PowerShell 提供的令人印象深刻的 Active Directory 管理功能较少。了解如何使用加载项提供更有力的方式，以使用 Windows PowerShell 处理 Active Directory 对象。

Don Jones 您好，脚本专家！: 正则表达式令您耳目一新

脚本专家们参观了卢浮宫、给出了艺术评论，并向您展示了如何在脚本中使用正则表达式来执行搜索和替换。

The Microsoft Scripting Guys 安全观察: 量子安全性原理

了解海森堡不确定性原理和量子物理学的其他元素如何对制定安全策略产生借鉴意义。（注意：在本文写作期间没有猫受到伤害。）

Jesper M. Johansson 桌面文件: 让管理员退居幕后

为什么每个人都以 Administrator 身份运行？Wes Miller 介绍了以 Administrator 身份运行的风险，并探讨将您的用户（包括您自己）转换成以 User 身份运行的好处。

Wes Miller 领域备注: 一台 PC，多个鼠标

如果学生人数超过教室中所配备的计算机数量时，您该怎么办？Microsoft 印度研究中心已开发出一种名为“MultiPoint”的解决方案，它允许在一台计算机上同时使用多个鼠标。

Kentaro Toyama Windows 机密: 16 位图标已经过时了

Raymond Chen 在本文中讲述了 Windows Vista 不再支持 16 位图标的原因，并希望了解是否有人注意到这一点。

Raymond Chen


 Windows 管理: Windows Server 2008 中的 Active Directory 备份和还原
Windows 管理 Gil Kirkpatrick

Windows Server 2008 中的 Active Directory 备份和还原
概览:
  • NTBACKUP 与 Windows Server Backup
  • 备份工具和选项
  • 恢复工具和选项
  • 可靠 Active Directory 备份策略的关键

大家都知道 Active Directory 域服务 (ADDS) 是 Windows 基础结构中针对关键任务的组件。如果 Active Directory 出现故障，网络实际就崩溃了。因此，Active Directory 的备份和恢复计划是
安全性、业务连续性和法规遵从性的基础。
Windows Server® 2008 为 Active Directory® 带来了许多新功能，其中对备份和恢复计划具有重大影响的两个功能是：新的 Windows Server Backup 实用工具，以及获取和使用 Active Directory 的“卷影复制服务”快照的能力。在本文中，我将介绍这些增强功能所带来的变化，以及如何利用这些变化来简化 Active Directory 备份活动。

NTBACKUP 与 Windows Server Backup
组策略设置
Windows Server Backup 提供了若干组策略设置，使您可以在一定程度上控制备份在您服务器上的工作方式。使用这些备份策略，人们通过未经授权的备份访问未授权数据的风险会降低。选项包括：
仅允许系统备份 如果设置了此选项，则 Windows Server Backup 只能备份关键的系统卷。它无法执行卷备份。
不允许本地附加的存储作为备份目标 如启用此设置，它不允许备份至本地附加的驱动器。只能备份至网络共享。
不允许网络作为备份目标 此设置不允许备份至任何网络共享。
不允许光学媒体作为备份目标 如设置了此选项，Windows Server Backup 无法备份至任何光学媒体，例如可记录的 DVD 驱动器。
不允许一次性运行备份 此设置不允许 Windows Server Backup 运行非计划的特定备份。仅通过 Windows Server Backup MMC 管理单元计划的备份可以运行。

您所了解和喜爱的 NTBACKUP 自 Windows NT® 3.5 之后已消失。代替它的是 Windows Server Backup。这一新工具不是仅仅对 NTBACKUP 的改进；它是一个全新的备份技术，使您必须重新思考备份系统的方法。
尽管 Windows® Server 备份是 Windows Server 2008 唯一的现成备份解决方案，但它并不是替换 NTBACKUP 的另一种功能。最大的差异在于：Windows Server Backup 是磁盘到磁盘的备份解决方案；它不支持备份至磁带。您可以在直接附加的磁盘卷、网络共享，甚至是外部 USB 硬盘和可记录的多卷 DVD 上创建备份映像。但您不能备份至磁带。这里明确一点，您仍可以在 Windows Server 2008 服务器上挂接磁带驱动器，并将 Windows Server Backup 生成的备份映像复制到磁带驱动器——但您必须使用其他方软件才能完成此操作。
NTBACKUP 是基于文件的备份和还原工具，而 Windows Server Backup 是以卷和块为基本对象。Windows Server Backup 将其备份源处理为卷集，每个卷均作为一个磁盘块集合。与通过文件系统备份文件相比，这样效率要提高很多。以块为基础处理备份还使 Windows Server Backup 能利用“卷影复制服务”快照来执行块级别增量备份，以及在目标卷上创建快照以简化多个备份的使用（并减少其所占用的空间）。
即使您正在执行的是完整备份，Windows Server Backup 也能在目标磁盘上提供很大的空间效率。例如，您可对同一卷执行多个完整备份。由于 Windows Server Backup 在存储备份映像的目标磁盘上使用“卷影复制服务”快照，因此，快照将仅存储已发生更改的块。这极大地减少了多个完整备份所占用的空间。这样即不必通过执行多个还原操作恢复增量备份。尽管快照仅存储每个备份的变化量，但“卷影复制服务”会确保每个备份的完整性。
不过，请注意，您只有在备份至本地硬盘时才能从目标上的“卷影复制服务”快照中受益——Windows Server Backup 无法对存储在 DVD 或网络共享上的备份执行“卷影复制服务”操作。
Windows Server 备份以 Microsoft® 虚拟硬盘 (VHD) 格式存储备份映像，这会产生额外的益处。您可以实际获取备份映像，在 Microsoft Virtual Server 2005 下运行的虚拟机中将其安装成一个卷。您只需在虚拟机中安装 VHD 并浏览特定文件即可，不必通过测试还原磁带来查看哪个磁带上具有文件。（特别注意：您不能从备份映像中启动虚拟机。由于备份的硬件配置与虚拟机的配置不搭配，因此，无法将 Windows Server 备份用作物理到虚拟的迁移工具。）
Windows Server Backup 的卷和块定向有一个缺点。因为此新工具将备份源视为一组卷和块，所以它不允许您仅备份选定文件。必须备份整个卷。此外，默认情况下，无法将备份映像存储在所备份的一个卷上（有一些方法可就此进行配置；请参阅 support.microsoft.com/kb/944530）。我将在本文稍后的部分讨论系统状态备份的深刻含义。

安装 Windows Server Backup
Windows Server Backup 是 Windows Server 2008 中的一项“功能”，默认情况下并不安装。在使用 Windows Server Backup 执行备份之前，必须使用“服务器管理器”或 SERVERMANAGERCMD 命令行实用工具安装该功能：
C:\> servermanagercmd -install Backup-Features
Windows Server Backup 包括两个子功能，Windows Server Backup 和 Command-line Tool。请注意，Command-line Tool 是指一组 Windows PowerShellTM cmdlet——而非 WBADMIN .EXE 命令行工具。因此，如果您选择安装这两个子功能，则必须安装 Windows PowerShell 功能。
安装 Windows Server Backup 后，您可以在“服务器管理器”的“存储”节点下以及“管理工具”菜单上找到 Microsoft 管理控制台 (MMC) 管理单元。如果您是在 Windows Server 2008 Server Core 安装中安装 Windows Server Backup，请使用 OCSETUP 命令（请注意，OCSETUP 命令区分大小写，这一点非常重要）：
C:\> ocsetup WindowsServerBackup
可从 go.microsoft.com/fwlink/?LinkId=113146 获得安装过程的完整说明。
请注意，Windows Server Backup 不能还原使用 NTBACKUP 创建的映像。为应对这种极特殊的情况，Microsoft 已为 Windows Server 2008 提供了可下载的 NTBACKUP（请参阅 go.microsoft.com/fwlink/?LinkId=113147）。

Windows Server Backup 组件
组建 Windows Server Backup 应用程序的方式反映出了产生的重大变化。新的备份解决方案由四个组件组成：
  • MMC 用户界面 (WBADMIN.MCS)
  • 命令行界面
(WBADMIN.EXE)
  • 备份服务 (WBENGINE.EXE)
  • Windows PowerShell cmdlet 集
将该应用程序拆分为客户端和服务有若干好处，最重要的是提高了可靠性。无论是从 MMC 客户端还是从命令行界面启动备份，均由 WBENGINE 服务完成主要工作。客户端程序只报告备份的状态。因此，终止客户端不会导致备份中途停止。客户端将停止，而服务将继续完成。当然，如果您确实想停止备份，也可以实现，但必须明确执行相应操作。
此拆分的体系结构的另一好处是，您可以使用客户端管理远程计算机上的备份。如果必须备份 Windows Server 2008 Core 计算机，这一长处尤其值得称道。
Windows Server Backup 支持使用 Windows 恢复环境（即 WinRE）进行裸机还原，Windows Server 2008 安装介质上就有 WinRE。WinRE 简化了从头开始恢复服务器的过程。我将在本文后面的内容中讨论如何执行裸机还原。在此有必要指出，Windows Server Backup 支持几个用于管理备份的“组策略”设置——“组策略设置”侧栏中有这些设置的概述。

卷影复制服务
Windows Server Backup 以三种不同的方式使用“卷影复制服务”。当您在 Windows Server 2008 上启动完整备份时，应用程序首先制作一个所有源卷的卷影副本。执行此操作会为备份软件提供一致的文件系统视图供其使用。（这与 NTBACKUP 所执行的操作类似。）Windows Server Backup 然后逐个将这些块从源卷复制到备份目标，在此过程中会为每个已备份的卷构建 VHD 映像。
除非另行指定，否则 Windows Server Backup 还会创建源卷的快照，以便“卷影复制服务”跟踪卷上所有发生更改的块。这使得 Windows Server Backup 可以创建块级别增量备份，它们仅需要读取源卷中发生更改的块。Windows Server Backup 可以只读取和写入发生更改的块，而不会因为文件有一点更改便读取和写入整个文件。
这使得增量备份效率很高，但代价是源卷的写入操作需要额外的磁盘 I/O。如果您要备份特别繁忙或性能关键的卷，则应禁用源卷上的“卷影复制服务”快照，方法是选择“Configure Performance Settings”（配置性能设置）链接，然后禁用此卷上的增量备份（如图 1 所示）。
Figure 1 Disable incremental backups on busy volumes
Figure 1 Disable incremental backups on busy volumes
当备份完成时，Windows Server Backup 会获取目标卷的快照（假设您是备份到本地连接的硬盘上）。在下一备份期间，会覆盖目标 VHD 文件。但是，由于“卷影复制服务”一直保持目标卷的卷影副本，因此实际上，与每个完整备份相对应的各个 VHD 文件都会有多个版本。您实质上花费的是一个完整备份和更改块的成本，而获得的是多个完整备份。

备份至网络共享
备份至网络共享就象备份至本地卷一样轻松。两者的主要差异是，它不能创建远程卷的“卷影复制服务”快照。因此，每个完整备份都将覆盖前一完整备份，从而在网络共享上仅为您留下每个服务器的最新完整备份映像。由于此限制，您不能使用 Windows Server Backup 计划程序来计划到网络共享的备份。不过，您可以使用 Windows Task Scheduler 来运行 WBADMIN 命令行程序，执行到网络共享的完整备份。如果您选择以此方式来计划到网络共享的完整备份，请更改每个备份的目标文件夹以避免覆盖先前备份。

备份至可记录的 DVD
Windows Server Backup 还支持备份至光学媒体，例如可写入的 DVD。您还可以创建包含多个卷的备份集。Windows Server Backup 始终将备份压缩至 DVD，这意味着，您从 DVD 仅可以还原完整系统或完整卷。Windows Server Backup 不支持使用 DVD 执行系统状态或文件级别的备份和还原。而且，您不能对备份至 DVD 进行计划。

系统状态备份和还原
系统状态备份仅包括选定的文件和某些应用程序数据库（而不是整个卷），它虽简单但通常却至关重要。但是，在 Windows Server 2008 的早期版本中，并不支持系统状态备份和还原。备份工具只备份关键的系统卷（即，恢复和重新启动操作系统及关键应用程序所必需的任何卷）。这些关键系统卷等同于面向卷的系统状态备份。
应客户反馈的要求，Microsoft 向 Windows Server Backup 添加了系统状态备份和还原功能。该应用程序会创建多个 VHD 文件，每个托管系统状态数据的卷一个 VHD 文件，但它仅将必要的文件和数据库复制到 VHD 中。另一个问题是，当您执行系统状态备份时，Windows Server Backup 并不创建目标卷的快照，这一点与正常的备份过程不同。而是每个系统状态备份生成一个全新的 VHD 文件集，这意味着没有基于快照的卷备份所具备的空间效率。
您仅可以使用 WBADMIN.EXE 命令行程序执行系统状态备份——MMC 管理单元不提供此选项。要执行系统状态备份，请使用以下命令：
C:\> wbadmin start systemstatebackup
–backuptarget:e:
WBADMIN 然后会将关键系统文件和应用程序数据库备份至目标卷（在为系统状态备份而保留的文件夹中）。系统状态备份在具有默认目录信息树 (DIT) 的 32 位 Windows Server 2008 域控制器 (DC) 上运行时要稍大于 6GB——这比在 Windows Server 2003 上大 5GB，部分原因是 Windows Server Backup 捕获核心操作系统文件，而 NTBACKUP 并不捕获此类文件。
如您所料，备份系统状态所需的时间也会更长。当然，这些初始数字是以操作系统的预发布版本为基础的。您必须在自己的环境下对此进行测试，如果您要将域控制器移至 Windows Server 2008，您需要针对更大的系统状态备份（以及更长的备份时间）做出计划。

使用 MMC 备份服务器
运行 Windows Server Backup MMC（请参见图 2）时，您可以选择设置备份计划或立即运行特定备份。在本例中，我选择“Backup once”（立即备份）以立即执行备份。
Figure 2 Windows Server Backup MMC
Figure 2 Windows Server Backup MMC
如您在图 3 中所见，我可以选择是备份服务器上的所有卷，还是只备份所选的特定卷。如果选择“Full server”（完整服务器），则 Windows Server Backup 将备份所有装入的卷，但我无法备份至装入的硬盘驱动器——只能备份至可记录的 DVD 或网络共享。
Figure 3 Using the backup configuration dialog to specify all or select volumes
Figure 3 Using the backup configuration dialog to specify all or select volumes
在本示例中，我希望备份至本地硬盘驱动器，因此，我选择“Custom”（自定义）选项。然后会显示一个对话框，让我选择要备份的卷（请参见图 4）。默认情况下，Windows Server Backup 会选中“Enable system recovery”（启用系统恢复）框，这会让 Windows Server Backup 选择引导卷、操作系统卷，以及具有关键系统文件和应用程序数据库的任何其他卷。在 DC 上，这包括托管 SYSVOL、Active Directory DIT 以及 Active Directory 日志的卷。这等同于系统状态备份，但它备份所有关键卷，而不仅仅是这些卷上的关键文件。实际上，我甚至可以从系统恢复备份集执行系统状态恢复。
Figure 4 Selecting specific volumes to back up
Figure 4 Selecting specific volumes to back up
在选择目标类型（本地驱动器或网络共享）并指定目标后，Windows Server Backup 会提示我选择“VSS copy”（VSS 副本）备份或“VSS full”（VSS 完整）备份。这个术语有点令人困惑，因为这两个选项均将完整地备份选定卷。区别在于备份源文件后 Windows Server Backup 处理它们的方式。如果您选择副本选项，则 Windows Server Backup 将原样保留备份的文件。如果您选择完整选项，Windows Server Backup 将随后重置存档。

从命令行备份服务器
如果您要编写备份过程的脚本，或在 Server Core 安装上备份服务器，则可以使用 WBADMIN.EXE 命令行程序。WBADMIN 提供一个完整的选项集，这些选项实质上执行与 MMC 管理单元相同的功能，包括管理备份计划。
假设我想启动 WBENGINE 服务，它会随后执行备份。我仅需输入以下命令即可：
C:\> wbadmin start backup –include:c:,d:
–backuptarget:e:
若要备份所有关键的系统卷，可以输入以下命令：
C:\> wbadmin start backup -allcritical
–backuptarget:e:
启动备份后，WBADMIN 继续运行并显示备份进度。如果终止 WBADMIN，则备份将继续在后台执行。然后可以使用以下命令重新将 WBADMIN 连接至正在运行的备份：
C:\> wbadmin get status
如果希望终止正在运行的备份，只需输入以下内容：
C:\> wbadmin stop job

使用 MMC 计划备份
与 Windows Server Backup 集成的备份计划程序实际上是为专门完成一项任务：简化每日对本地磁盘卷做完整系统备份的计划。您可以使用内置的计划程序自动在多个目标卷中轮换备份。如果您具有便于移动的硬盘驱动器（或者正在使用通过 USB 连接的硬盘驱动器），则可以使用此功能来建立转换方案，在此方案中，您取下备份磁盘并将其存储在外部，然后将最早的备份磁盘返回到服务器以供下一个计划的备份使用。
Windows Server Backup 计划程序仅让您计划始终每日发生的备份。也就是说，没有单独针对各个星期一、星期三和星期五计划备份的方法。因此，如果您不希望每日都运行计划的备份，就必须直接使用 Windows Task Scheduler。
当建立到本地磁盘的计划备份时，Windows Server Backup 负责磁盘，即格式化磁盘、建立特定的文件夹结构，并使 Windows 资源管理器中不显示目标磁盘。目标磁盘必须为基本卷——Windows Server Backup 无法备份至被配置为动态卷的磁盘。
通过 MMC 管理单元计划备份十分容易。在此示例中，我首先选择“Backup Schedule”（备份计划）链接、指定备份类型以及要备份的卷，然后 Windows Server Backup 即会显示“Specify backup time”（指定备份时间）对话框（请参见图 5）。
Figure 5 Specifying when daily backups should occur
Figure 5 Specifying when daily backups should occur
选择希望备份执行的时间后，我可以选择备份的一个或多个目标卷。在本例中，我选择备份卷 E:，如图 6 所示。Windows Server Backup 会尽量为您选择一个合适的目标卷，但是，如果您要备份的目标磁盘未出现，则可以使用“Show All Available Disks”（显示所有可用磁盘）按钮来查看所有连接的磁盘设备。在显示两个“confirm”（确认）对话框之后，Windows Server Backup 会格式化目标卷并使用 Windows Task Scheduler 来计划备份任务。
Figure 6 Specifying the destination disk for a scheduled backup
Figure 6 Specifying the destination disk for a scheduled backup
每次计划的备份完成时，Windows Server Backup 都会获取目标卷的快照。而且每隔七天，它会创建一个新的基本映像。活动则记录在 Microsoft/Backup/Operational 日志中。您可以在那里检查备份是否成功完成，也可以将某一任务（例如发送电子邮件消息）与成功和失败事件相关联，以便始终了解计划备份的状态。

从命令行计划备份
如果您正在计划 Server Core 安装上的备份，或者只是想编写该过程的脚本，则可以使用 WBADMIN 命令行来管理备份计划。要添加计划的备份，可使用 WBADMIN ENABLE BACKUP 命令指定目标、源以及计划的时间，如下所示：
C:\> wbadmin enable backup –addtarget:e:
-include:c:,d: -schedule:06:00,12:00,18:00
此命令会每天将 C: 和D:驱动器备份至 E:驱动器三次，时间分别为早上 6:00、中午 12:00 和下午 6:00。（请注意，所有时间均使用 24 小时制指定）。要备份所有关键的系统卷（从其可执行裸机还原或系统状态还原），请使用 –allcritical 替换 –include 开关。
也可以使用 WBADMIN 禁用所有计划的备份，如下所示：
C:\> wbadmin disable backup
此命令将删除所有由 Windows Server Backup 计划程序创建的计划备份工作，并释放所有备份目标卷以供正常使用。请注意，您始终可以使用 WBADMIN MMC 管理单元远程管理 Server Core 服务器的备份和还原活动。

域控制器的裸机恢复
备份和恢复最激动人心的改进之一是 WinRE 并入安装过程的方式。从安装媒体中启动 Windows Server 2008 时，您可以选择“Repair your computer”（修复计算机）选项，如图 7 所示。由于这一选项极易被错过，所以在此专门做个提醒。
Figure 7 The Repair your computer option is available on the installation screen
Figure 7 The Repair your computer option is available on the installation screen
在安装屏幕上选择修复选项后，Windows 会让我选择一个恢复选项，如图 8 所示。在本例中，我选择“Windows Complete PC Restore”（Windows 完整 PC 还原），这会调用 Windows 恢复环境。
Figure 8 Specifying system recovery options
Figure 8 Specifying system recovery options
在选择要修复的操作系统（通常只有一个选择）后，WinRE 允许您选择要从其进行还原的备份。默认情况下，WinRE 选择最近的完整系统备份，但您可以指定存储在本地磁盘上的其他备份，或在网络中搜索存储在其他服务器文件共享中的备份。
在我的示例中，我选择最近的完整系统备份。下一对话框（如图 9 所示）让我先格式化所有磁盘并重新分区，然后再进行还原。如果您正从某种磁盘故障所导致的问题中恢复，或者已替换了服务器中的一个或多个磁盘驱动器，则这是一个合适的选项。
Figure 9 You can easily format and repartition disks before they're restored
Figure 9 You can easily format and repartition disks before they're restored
在两个确认对话框之后，WinRE 启动还原进程，而且服务器重新启动。此方法极为适合在服务器上执行裸机恢复。

域控制器的系统状态恢复
如果您需要从某种与 Active Directory 相关的问题中恢复（例如从备份中恢复删除的 OU），则应将 Active Directory 域服务 (ADDS) 数据库还原至早期状态，而不是还原整个系统。尽管您可以像在 Windows Server 2008 中的服务那样停止 ADDS，但仍需将服务器引导到目录服务还原模式 (DSRM) 中，以对域控制器执行系统状态还原。
更改引导选项以将 Windows Server 2008 引导到 DSRM 中并不像以前那样容易。整个 Windows 引导环境经过了重新设计，以支持新的可扩展固件接口 (EFI)，而老式的 boot.ini 文件不再存在。Windows Server 2008 代之以使用引导配置数据 (BCD) 来管理引导过程。
管理 BCD 的最简单方法是使用 BCDEDIT 命令行程序。说明所有 BCDEDIT 命令和选项需要一整篇文章，我在此处只向您显示某些有用的示例。
要将 Windows Server 2008 DC 重新引导到 DSRM 中，请使用以下命令：
C:\> bcdedit /set safeboot dsrepair
这将为默认的引导加载程序项设置安全引导选项。在全新的 Windows Server 2008 安装中，只有一个引导加载程序项 WINLOAD.EXE。要删除安全引导选项并重新引导到正常模式中，请使用以下命令：
C:\> bcdedit /deletevalue safeboot
您可在 DC 上配置两个引导加载程序项——一个用于正常引导，一个用于 DSRM 引导，这样更为便利。您也就可以使用“System Settings”（系统设置）下提供的“Startup and Recovery”（启动和恢复）设置对话框来更改引导选项。要添加新的引导加载程序项，请使用以下命令：
C:\> bcdedit /copy {default}
/d "Directory Service Repair Mode"
此操作将通过复制默认的引导加载程序项创建一个新的引导加载程序项。BCDEDIT 将显示与下面类似的内容：
The entry was successfully copied to
{c50d4710-a1f0-11dc-9580-0003ff402ae9}.
GUID 会识别新项。然后，使用以下命令为 BCD 中新的引导加载程序项设置安全引导选项：
C:\> bcdedit /set {<GUID for new entry>}
safeboot dsrepair
您现在可以使用“Startup and Recovery”（启动和恢复）设置（如图 10 所示）从正常引导模式切换到 DSRM 引导模式。
Figure 10 Disable incremental backups on busy volumes
Figure 10 Disable incremental backups on busy volumes
在使用 WBADMIN 启动系统状态还原之前，必须确定要从其进行还原的备份。WBADMIN 可以从完整系统备份、只包含关键系统卷的备份或系统状态备份执行系统状态还原。在上述任一情况下，必须指定要使用的备份版本。确定可用备份版本的最简单方法是使用下面的 WBADMIN 命令：
C:\> wbadmin get versions
WBADMIN 然后将以与图 11 中所示信息类似的形式显示备份版本。请注意，每个备份都有一个备份时间、备份目标、版本标识符（顺便说一下，它是备份以“通用平均时”启动的时间和日期）以及一个可支持恢复操作的类型列表。
Figure 11 确定恢复可用的备份 (Close Figure 11)
wbadmin 1.0 - Backup command-line tool
(C) Copyright 2004 Microsoft Corp.
Backup time: 11/30/2007 3:47 PM
Backup target: Fixed Disk labeled E:
Version identifier: 11/30/2007-22:47
Can Recover: Application(s), System State
Backup time: 12/1/2007 10:46 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/02/2007-05:46
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/2/2007 5:58 PM
Backup target: Fixed Disk labeled Backup(E:)
Version identifier: 12/03/2007-00:58
Can Recover: Volume(s), File(s), Application(s), Bare Metal Recovery, System State
Backup time: 12/3/2007 11:25 AM
Backup target: Fixed Disk labeled E:
Version identifier: 12/03/2007-18:25
Can Recover: Application(s), System State
在本例中，我选择最近的备份，并使用以下 WBADMIN 命令启动系统状态还原：
C:\> wbadmin start systemstaterecovery
–version:12/03/2007-18:25
这将执行非权威还原。如果您希望执行 SYSVOL 的权威还原，只需将还原的 SYSVOL 副本标记为权威即可，方法是将 authsysvol 选项添加至 WBADMIN 命令。有关此过程的详细信息，请参阅 go.microsoft.com/fwlink/?LinkId=113152。

制作 Active Directory 快照
在 Active Directory 的备份方面，最激动人心的变化之一就是根本不再与 Windows Server Backup 发生关联。在 Windows Server 2008 中，Active Directory 能够提供“卷影复制服务”快照，这可充分利用这一功能。这些快照是正在运行的 Active Directory 服务的极轻型时间点备份。更为可喜的是，它们仅需几秒钟即可创建！随后，您可以装入这些快照并使用基于 LDAP 的正常实用工具（例如 LDP 工具）访问它们。
使用如下所示的 NTDSUTIL 命令制作 ADDS 或 Active Directory 轻型目录服务 (ADLDS) 的快照：
ntdsutil: snapshot
snapshot: activate instance ntds
Active instance set to "ntds".
snapshot: create
Creating snapshot...
Snapshot set {42c44414-c099-4f1e-8bd8-4453ef2534a4} generated successfully.
snapshot: quit
ntdsutil: quit
此 NTDSUTIL 命令序列会创建包含 Active Directory DIT、日志和 SYSVOL 的卷的“卷影复制服务”快照。即使 Active Directory 仍在更新，“卷影复制服务”也会使用写入时复制策略来确保正确维护已制作的快照。请注意，快照不是 DIT 的完整副本。它们实际上只是 DIT 中制作快照后经过修改的磁盘块的集合。通过将这些块与 DIT 的当前副本组合在一起，VSS 所呈现的 Active Directory DIT 正是其在快照时的状态。图 12 显示如何删除旧的或不需要的快照。
Figure 12 删除不需要的快照 (Close Figure 12)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: delete 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>

装入 Active Directory 快照
为了使用这些快照之一，您必须首先指示“卷影复制服务”使快照可供文件系统使用。为达此目的，可使用 ntdsutil 命令列出可用快照，然后装入感兴趣的快照（请参见图 13）。
Figure 13 使用 ntdsutil 装入快照 (Close Figure 13)
C:\> ntdsutil
ntdsutil: snapshot
snapshot: list all
 1: 2007/12/03:23:18 {42c44414-c099-4f1e-8bd8-4453ef2534a4}
 2:   C: {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022}
 3:   D: {2bbd739f-905a-431b-9449-11fba01f9931}
snapshot: mount 1
Snapshot {c0dd71ba-5bcd-4daf-9fbb-5cfbdd168022} mounted as C:\$SNAP_200712032318_VOLUMEC$\
Snapshot {2bbd739f-905a-431b-9449-11fba01f9931} mounted as C:\$SNAP_200712032318_VOLUMED$\
snapshot: quit
ntdsutil: quit
C:\>
"list all" 命令列出了当前由“卷影复制服务”维护的所有可用 Active Directory 快照。"mount 1" 命令装入 Active Directory DIT 和日志卷的选定快照，然后使它们在文件系统中可用。它们位于 C:\$SNAP_200712032318_VOLUMEC$\ 和 C:\$SNAP_200712032318_VOLUMED$\ 中。
如果您查看这些文件夹，则会看到这些卷的整个内容与制作快照时相同。不过，请注意，装入的快照为只读，即：您无法修改已装入快照中的任何文件。

从 Active Directory 快照恢复数据
装入包含 Active Directory 的卷的快照这一任务看起来有些神秘。该如何访问这些快照中所包含的 Active Directory 数据呢？DSAMAIN 命令就是其中的关键。它是运行 ADLDS 的可执行程序。实质上是一个独立的 LDAP 服务器，几乎与 ADDS 共享其所有代码。您可以使用 DSAMAIN 使装入的快照看起来像只读 LDAP 服务器（包含制作快照时的 Active Directory 数据）。
请考虑以下命令：
C:\> dsamain –dbpath
c:\$snap_200712032318_volumed$\ntds\dit
\ntds.dit -ldapport 10000
这会装入位于 c:\$snap_200712032318_volumed$\ntds\dit 文件夹中的 ntds.dit 文件，并使其可供 TCP 端口 10000（或您指定的任何开放端口）上的 LDAP 操作使用。DSAMAIN 将在所指定数字加一的端口（在本例中为 10001）上打开 LDAPS 端口（用于 LDAP over SSL 的端口）、在所指定数字加二的端口 (10002) 上打开 GC 端口（用于全局编录连接的端口），在所指定数字加三的端口 (10003) 上打开 GCS 端口（全局编录 over SSL）。
您可以使用任何 LDAP 程序（例如 LDP）访问指定端口上装入的 DIT。但在 Windows Server 2008 中，Active Directory 用户和计算机 (ADUC)、站点和服务、域和信任关系以及 ADSIEDIT 均已经过修改，以允许您使用 DSAMAIN 将它们连接到装入的 DIT。如果您右键单击任何 ADUC 导航窗格中的顶层节点，并选择“Change Domain Controller”（更改域控制器），则会看到图 14 中所示的对话框。如果您只键入托管已装入快照的服务器的名称或 IP 地址以及端口（在我的示例中为 localhost:10000），则 ADUC 将连接装入的快照，从而允许您浏览目录的内容（与制作快照时相同）。非常了不起，不是吗？
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
Figure 14 Connecting Active Directory users and computers to a mounted snapshot
能够以此方式访问目录数据使多种数据恢复任务都比以前容易多了。例如，要从备份恢复删除的对象，以前需要对现有 DC 执行备份的非权威还原，然后执行已删除对象的权威还原。如果您还原的备份没有正确数据，则必须使用其他备份再次全部启动。现在，使用逻辑删除恢复和快照，您可以快速找到并恢复删除的数据，甚至不必使域控制器脱机即可执行此操作。
不过，有一些限制。例如，每个活动快照都会增加与写入到目录操作关联的磁盘 I/O，因此，生产 DC 任意时间点的活动快照不应超过一或两个。此外，快照保持活动状态的时间越长，“卷影复制服务”变化量存储就会越大——这也会影响性能。当然，简单恢复删除的对象只是恢复问题的第一部分。您可能还必须恢复对象的链接属性，例如组成员身份等。但是，即使在此情况下，快照也可以帮助您确定已删除对象所属的所有组。

可靠的 Active Directory 备份和恢复策略
Windows Server 2008 带来了一个全新的备份和恢复系统。某些变化起初可能会让人感到不满。但是，一旦 IT 组织接受这些变化并将新的备份技术融入到日常操作中，更加有效的备份和恢复实施将会使其为之一振。
即使 Windows Server 2008 中备份服务器的方法发生了诸多变化，备份和恢复 Active Directory 的基本策略实际上并无太大变化。因此，在规划策略时，请确保记住这些最佳实践：
  • 计划定期完整备份系统，这样您便可以在硬件出现故障后恢复 DC。计划 DC 完整备份的频率取决于数据更新的频率、停机时间和/或数据丢失的容差，以及从头开始重新构建 DC 可能需要的工作量。
  • 计划经常性系统状态备份以备份 Active Directory 中的更改。执行系统状态备份的频率取决于丢失 Active Directory 数据的容差。但是，您一天应至少执行一次这种备份。如果您有硬件，则至少在本地磁盘上保持一个或两个系统状态备份，并将旧的系统状态版本复制到 DVD 或网络共享。
  • 确保至少对每个域中的两个 DC 执行系统状态备份。这将在其中一个备份出现错误或不可用时提供一些保障。
请确保使用应用程序分区副本（如果它们已定义）来备份 DC。同时，考虑在 DC 上创建 Windows 恢复环境，以便您可以在关键系统驱动器出现故障时能快速引导到 WinRE 中。

Gil Kirkpatrick 是 NetPro 的 CTO，他自 1996 年起便一直参与开发 Active Directory 软件。他与来自 HP 的 Guido Grillenmeier 一起创办了广受欢迎的 Active Directory 灾难恢复学习班。Gil 还是目录专家会议（请参阅 www.dec2008.com）的创始人。
© 2007 Microsoft Corporation 和 CMP Media, LLC。保留所有权利；未经允许不得复制本文的部分或全部内容.


 Windows 管理: 设计有效的 OU 结构
Windows 管理 Ken St. Cyr

设计有效的 OU 结构
概览:
  • 良好 OU 设计的关键原则
  • 常用 OU 设计模型
  • 记录您的 OU 设计

切勿低估设计良好的组织单位 (OU) 结构的重要性和复杂性。我发现 IT 部门经常盲目行事，他们
有时过分关注 OU 结构，有时又不对其进行认真思考。总之，这会导致 Active Directory® 模型发生问题。
过度强调 OU 结构就会忽略 Active Directory 设计的其他方面，例如规划站点拓扑或考虑域控制器大小。另一方面，如 OU 规划不受重视，组策略和委派将会受到不良影响。
我曾听到的一种托辞是 OU 结构很灵活，如果不合适，之后可以进行更改。的确，OU 结构很灵活；不过，管理员通常发现后期更改 OU 结构要比他们原来预期的困难。当然，可以添加新 OU，但旧 OU 却很难清除。
计划欠佳的 OU 结构往往会我行我素。如果在目录中创建了一个新对象，但管理员不知道将其置于 OU 结构中的什么位置，他只能选择要么创建一个新 OU，要么将该对象放在某个不相干的位置。这两种情况都比较危险。创建一个新 OU 很容易做到，但从长远角度来看很难进行跟踪。猖獗的 OU 创建形成了混乱的 OU 结构，而且易于让各种内容蔓延到未记录的目录中。另一方面，如果您将某个对象添加到与其不相干的现有 OU 中，则此新对象可能会接收它不应获得的策略，或者该对象的权限可能被委派给非目标用户。
设计 OU 结构时，应记住一个基本等式：简单性 + 适用性 = 可持续性。如果您的设计过于简单，则它可能并不适用，因此将不得不过于频繁地进行更改。如果您的设计适用性过强，则所有内容都将被分类，这会使情况变得过于复杂。
有三个关于组策略、委派和对象管理的关键原则，它们可为您的设计决策提供指导。这些原则可被归结为三个您应自问的问题，帮助确保所创建的 OU 结构体经得起时间和组织更改的考验：
  1. 是否需要创建此 OU 结构，以便可对其应用唯一的组策略对象 (GPO)？
  2. 特定管理员组是否需要对此 OU 中的对象具有权限？
  3. 此新 OU 是否会使其内部对象管理变得更为轻松？
如果上述任一问题的答案均为“是”，则您可能应创建此 OU。如果所有三个问题的答案均为“否”，则您应重新考虑布局并确定其他设计是否更加合适。但是，在我对此做更深入的探讨并为您显示如何应用这些原则之前，我应首先解释这些原则之所以重要的原因。

原则 1：组策略
OU 设计的第一个原则是考虑将应用于 OU 的组策略对象。GPO 允许您强制对用户和计算机设置进行配置。您可以在 Active Directory 中定义多个 GPO，并将其应用于整个域、各种 OU 乃至域中的站点。GPO 分为两类—一类用于用户，一类用于计算机。
计算机策略和用户策略可在同一 GPO 中定义。GPO 的“用户配置”大多定义用户登录时的体验。这些设置类型也存在于“计算机配置”中，但此部分还包含与计算机安全性相关的更多设置，例如谁可在本地登录到计算机或如何加密数据。
以下是您在定义支持 GPO 的 OU 时需要记住的一些基础知识。首先，仅仅因为用户和计算机策略可在同一 GPO 中定义，就认为最好将用户和计算机对象放入同一 OU 中是错误的。将它们合并到同一 GPO 中会使 GPO 应用更难以进行故障排除。当您启用环回策略时，这一点非常明显。
其次，许多人会忘记您可以在站点级别应用 GPO，因此为与 GPO 的应用目标相符，应模拟其站点结构设计 OU 结构。这是 OU 设计的一种常见模型，称为“地理模型”。我将进一步探讨此模型。我必须承认“地理模型”在 OU 设计中的地位，但正如您稍后将看到的，我不认为 GPO 应用是实施此模型的主要原因。
此外，当根据 GPO 考虑 OU 结构时，目标应该是消除复杂性。请确保将 OU 添加到 GPO 继承流中。如果您 OU 所包含的服务器要求与其他服务器相同的策略，请考虑将这些计算机对象置于范围更广的服务器 OU 下，并在此服务器 OU 下为不同的服务器类型创建多个 OU（请参阅图 1）。这可以简化策略应用程序，因为更低层 OU 中的每个计算机对象将从服务器 OU 获取策略，还会获取特定于此特定服务器类型的任何其他策略。
Figure 1 Creating multiple OUs for different server types
Figure 1 Creating multiple OUs for different server types
另一基础知识是确保不要创建或链接多个不必要的 GPO。使用 GPO，您可以创建一个策略并将其应用于多个 OU。这有时是有益的，但也可能是有害的。如果您必须更改 GPO 设置，而且链接的 GPO 系统过于复杂，则会偶然将更改应用于错误对象。您创建的链接越多，掌握策略范围的难度就越大。同样，您应避免使用与其他策略相同的设置来创建附加策略。如果您发现您经常如此，则考虑修改您的 OU 结构以应用新的 GPO 继承模型。
最后，您应尽量始终为用户对象和计算机对象创建新的 OU。默认情况下，用户和计算机对象被置于容器中，这不允许您将 GPO 与这些对象直接链接。可将 GPO 应用于域中的用户和计算机容器，但除非您在其他位置阻止继承，否则，这些策略将应用于域中的每个用户和计算机。在 Windows Server® 2003 中，您可以使用 rediruser.exe 和 redircomp.exe 工具将用户对象和计算机对象的默认位置更改为您为其创建的 OU。

原则 2：委派
您创建 OU 结构的方式与在域中委派权限的方式一致，这一点非常重要。请记住，当在 Active Directory 中委派权限时，权限更改仅对对象生效。因此，如果您为某位用户授予了对特定计算机对象的“完全控制”，则此人员可以修改该对象的属性，但其并不具有对计算机本身的“管理员”权限。
以下是对您在设计 OU 结构时进行委派的一些建议做法：
设计时应注意权限继承 例如，假设您希望第 1 层管理员能够更改大多数帐户的密码。对于特殊的用户组，管理员不应具有重设密码的能力，但他们确实应该可以更改有关这些帐户的显示名称。
在此，您实际上有两个选项。第一，您可以创建两个单独的并行 OU，然后将特殊用户与普通用户分隔开来。不过，这意味着如果您要更改所有用户的委派选项，则必须在两个单独的位置更改这些权限。这还与不链接多个不必要策略的方法相抵触（请参阅图 2）。
Figure 2 Maintaining two separate parallel OUs
Figure 2 Maintaining two separate parallel OUs
另一个选项是创建嵌套式 OU，然后对具有特殊用户的 OU 实施显式拒绝权限。任何委派专家都会告诉您显式拒绝不可取—但在此情况下，您需要从两者中选择一个不利因素相对较少的一个（请参阅图 3）。您可以在两个单独的 OU 上复制和维护这些设置，也可以对其中一个 OU 实施显式拒绝。实际上，显式拒绝是更好的长期决策。
Figure 3 Using an explicit deny permission
Figure 3 Using an explicit deny permission
注意 AdminSDHolder 本示例适用于大多数情况，除非特殊用户全部都属于一个管理员组（域管理员、架构管理员、企业管理员或管理员），因为这些组中的帐户权限的处理方式不同。原则是您不希望意外地为某个人授予管理员帐户权限。
如果您为管理员创建单独的 OU，则会发现委派给他们的权限均消失。这由 AdminSDHolder 所致，它是一个特殊的容器，可根据指定间隔将其“访问控制列表”应用于每个管理员帐户。结果是，如果尚未对 AdminSDHolder 容器进行更改，则将取消您对管理员帐户所做的任何委派更改。因此，出于委派目的，您不应将管理员帐户与其他帐户分开。但对于组策略，最好将管理员帐户分出来—在您可以拥有多个密码策略 Windows Server 2008 中，这一点尤为突出。

原则 3：对象管理
OU 应有助于对象的管理。将对象归组到同一 OU 中通常更易于执行大量更改。Active Directory 用户和计算机管理单元允许您在选择多个对象时编辑某些属性。因此，如果您必须定期更改某个对象组的属性，则此操作在这些对象全部位于同一 OU 中时更易于完成。
当您使用脚本进行更新时，这一点也特别有用。脚本编写语言可以非常轻松地枚举 OU 中的所有对象并逐个进行处理。另一个选项是搜索并分别修改各个对象。只需将对象放入同一 OU 中进行管理，有时便可以节省您每周不必要的工作时间。
另一个有助于对象管理的方法是根据类型将对象分到不同的 OU 中。为打印机对象或发布的共享创建单独的 OU，可确保您在对 OU 中的其他对象执行管理时不必清除这些对象。这一原则与不将用户和计算机帐户归组到同一 OU 中的原则也是一致的。

选择模型
既然我已经提到了 OU 设计的原则，那么我可以进一步查看某些常用设计模型。请注意，由于篇幅所限，还有许多模型我无法在此一一介绍。您不要限于仅使用单一模型。您可以拾取每个模型的片段来构建您自己的混合模型，从而解决特定需求。
几乎任何模型都可以实现小范围的成功，但随着企业的扩大，您对环境的处理能力会逐渐缩减。因此，请确保首先在充分的实验室环境中对您的模型进行全面测试。请记住，尽管您最初可以很轻松地更改 OU 结构，但这些结构实施的时间越长，就越难以更改。

浅模型
“浅模型”的名称源自它大多保持平整这一事实。在此模型中，几个高级别的 OU 包含绝大多数对象（请参阅图 4）。此模型主要在小型企业中运用，在此类企业中，有一个小型 IT 商店，没有过多的部门，或者人员往往扮演多个角色。为避免对性能产生负面影响，我通常建议子 OU 数不要超过 10 个，尽管 Microsoft 提出的子 OU 限制数是 15 个。
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
Figure 4 The Shallow Model has a few high-level OUs that contain the majority of objects
如果人力资源人员同时也是您工资单中的人员，则为“人力资源”和“工资单”创建两个单独的 OU 毫无意义。在“浅模型”中，可将所有用户对象归组到一个大的帐户 OU 中，也可将其保留在默认用户容器中。最起码，您的用户对象应与计算机对象分开。
对于此模型，我还建议您进一步将工作站与服务器分开。然后，您至少可以应用不同的组策略，而无需定义一个使用 Windows® Management Instrumentation (WMI) 查询过滤出工作站或服务器的 GPO。
保持 OU 结构范围广泛（而不是深度）的一个优势是 Active Directory 搜索速度将更快。我通常会建议子 OU 数不要超过 10 个。虽然在此模型中您对对象的控制不是非常精准，但是，如果您管理的是小型企业中的对象，则不需要这种精准控制。因而，此模型很难在大型企业中成功使用，但其在小型组织中的效果却非常好。

地理模型
在地理模型中，您针对不同的地理区域创建单独的 OU。此模型最适合用于 IT 部门分散但不希望因操作多个域而带来成本的组织（请参阅图 5）。
Figure 5 The Geographic Model separates OUs by geographical region
Figure 5 The Geographic Model separates OUs by geographical region
假设您的办事处设在亚特兰大、巴尔的摩和西雅图。如果每个站点管理它自己的用户和计算机，则就委派而言这可能是一个很好的方法。但如果西雅图用户飞到巴尔的摩参加培训，然后封锁了其帐户，将会怎样？如果位于巴尔的摩的 IT 人员没有被委派该用户帐户的权限，则他们可能无法为其提供帮助。如果在巴尔的摩是上午 8 点，那么在西雅图就是上午 5 点，这意味着该用户可能必须等待几个小时才能在西雅图办事处找到可以提供帮助的人员。
一些全球性的公司使用“全天候”模型，在其中，帮助台呼叫被路由到当前采用标准工作时间的时区中的站点。这意味着公司不必在每个站点都运行 24 小时帮助台，但仍可以为夜班员工提供必要的帮助，例如解除对其帐户的锁定。
如果您采用的是这一模型，那么对于您的运营需求而言，根据地理位置创建单独的 OU 可能不是最佳选择。您必须将单独的权限委派到用户各个 OU 中的每一区域帮助台。不过，如果您的站点确实拥有它们自己的 IT 部门，则实际上对于您的组织而言，地理模型可能是理想之选。
此外，由于域操作方式的性质，很难在单个域中实现地理模型。某个域的安全模型往往与其他域的不同。当您查看企业范围的应用程序（如 Microsoft® Exchange）时，这一点更为明显。
位于亚特兰大的 Exchange Server 可能定义了不同的消息策略，但该企业中的所有 Exchange Server 可能应用同一 GPO。如果是这种情况，则按区域将 Exchange Servers 置于单独的 OU 中将导致您不必要地将同一 GPO 链接到多个 OU。就委派而言，您必须询问 Exchange 管理员是否确实需要 Exchange Server 计算机对象的唯一权限。在大多数情况下，被拆分到地理 OU 中的计算机对象是为组策略（而非委派）做此处理。

基于类型的模型
基于类型的模型按用途来分类对象（请参阅图 6）。当您创建上一个用户对象时，它是用于普通用户帐户、管理帐户还是服务帐户？在基于类型的模型中，上述每种对象的处理方式均不同。
Figure 6 The Type-Based Model groups objects according to their functions
Figure 6 The Type-Based Model groups objects according to their functions
在大多数情况下，您应针对策略区分用户对象的不同类别。您的策略将很可能根据用户帐户类型而有所不同。例如，允许人员使用服务帐户登录计算机通常是一个糟糕的业务惯例。服务帐户密码通常在许多人员之间共享，因此，如果某个人使用服务帐户登录，则其身份是匿名的。如果发生什么事情，您很难跟踪到事件发生时所登录的用户。在本示例中，您需要对服务帐户设置一个防止交互登录的策略。这非常适合层次模型，如图 3 所示。
此时，可利用 GPO 继承为您带来益处。例如，您可以具有“所有用户”策略，它是指用于所有用户对象的策略。另外，您还可以针对服务帐户具有独立但截然不同的策略（它基于“所有用户”策略而构建）。这一方法可确保您的服务帐户与所有其他帐户具有相同的基础策略集，同时还具有特定的登录限制。
此方法还对委派十分有效，在其中，您使用权限继承而非 GPO 继承。假定您希望第 2 层管理员可以重设除第 3 层管理员帐户之外的所有帐户的密码。使用平面 OU 结构，您必须将权限委派给持有用户帐户的每个 OU。不过，在具有层次结构的基于类型的模型中，您可以在帐户 OU 上为第 2 层的组授予“重设密码”权限，然后在第 3 层 OU，您只需取消继承这些权限，甚至可以为第 2 层设置显式拒绝来重设密码。
这对于计算机对象同样有效。服务器和工作站可以分开，从而允许对它们应用不同的策略。服务器然后可被进一步细分为多个功能（请参阅图 1）。在本设计中，您可以对服务器 OU 设置影响所有服务器的高级别策略，同时仍对每个低级别 OU 设置单个策略。
例如，假设您有一个 Microsoft Operations Manager (MOM) 服务帐户。使用此分层模型，您可以创建一个 MOM GPO 并将其应用于 MOM 服务器 OU。然后在此 GPO 内部，您可以授予 MOM 服务帐户权限，从而以服务形式登录。这仅适用于此 OU 中的 MOM 服务器。MOM 服务器仍将从高级别服务器 OU 获取服务器 GPO，但它们还将获得在 MOM OU 链接的专用 MOM GPO。

记录设计
设计一个经受得起 Active Directory 环境所遇到的多种变化的 OU 结构非常有意义。但是，您需要设法跟踪 OU 的动态特征。如果您不具备此条件，则会很快失去对环境的掌控。如果内容确实需要更改，而且需要添加或删除 OU，则就所执行操作必须要有明确的指导，以确保您的模型继续沿袭设计模型，从而遵循三个指导原则。这就是您为什么必须对设计进行完整文档记录的原因。
Microsoft 在 Windows Server 资源工具包中提供了文档指南。如果您的结构是一个较为可靠的框架，而且您不想进行太多更改，则这些指南会提供很好的帮助。但是，大多数组织的结构都十分动态，需要频繁更改。因此，下面提供了一些重要提示，以确保您的 OU 结构有完整的文档记录，而且能够支持动态环境。
确保所有信息均相关 我对有针对性的文档十分信赖。过多的操作性文档包含如此多的无关信息，以致于难以找出相关资料。切勿仅仅为了记录而执行记录过程。您真的需要包括每个 OU 中的对象数，或者 OU 访问控制列表上的每个访问控制项 (ACE) 吗？对于 OU 文档，以下信息通常已经足够：
  • OU 名称
  • 简要说明
  • 创建者—或者更多信息或更改的相关联系人
  • 创建时间
不要使更新变得困难 如果您不得不乏味地更新一些复杂的 Microsoft Word 文档，则拖延输入更新的可能性会更大。当您知道马上就要有大量更新输入时，拖延输入少量更改是可以的。遗憾的是，人们往往忘记这些小部分更改，或者只是将其一直拖延下去，进而导致作业从未完成过。因此，更新文档必须要非常轻松，免得您泄气。在大多数情况下，只有几列的简单 Microsoft Excel® 电子表格将非常有效。
针对对象本身进行注释 OU 对象具有一个描述属性，您可在其中输入注释。请考虑将注释置于描述属性中，而不是在设计文档中编写它们，以便其他人可以立即说出 OU 的用途。如果您需要包括更多的详细信息，则在描述属性中输入简要说明，然后在 OU 文档中加入更多详细信息。
自动化文档 可以编写一个脚本以将 OU 结构的内容转储到文本文件、Excel 电子表格乃至 HTML 文件中。每天晚上都可以对计划好的任务运行这一脚本。当您将注释合并到 OU 的说明字段中时，这会非常有用。之后只需将描述属性转储到文件中，您即会自动获得一个记录完整、始终为最新的 OU 结构。如果您每次运行该脚本时都创建一个新文件，而不是覆盖现有文档，则可以保留有关 OU 结构如何随时间变化的历史记录。
遗憾的是，大多数管理员直到他们确实需要一个完善的 OU 结构文档时才意识到它的重要性。但到那时（凌晨 3 点），不执行还原几乎不可能查明哪些其他 OU 已被意外删除。
请不要等到此刻才幡然醒悟。强烈建议您在此方面积极行动起来，立即启动 OU 文档并指定一名人员负责其更新。如果您遵循使文档易于更新这一规则，这将只是一个需要反复执行的极小任务。

Ken St. Cyr 是 Microsoft 的一位顾问，拥有 10 年的 IT 行业工作经验。自 Active Directory 问世以来，他已据其设计和实施了多种目录解决方案。


 Windows 管理: 扩展 Active Directory 架构
Windows 管理 Vikas Malhotra

扩展 Active Directory 架构
概览:
  • 了解默认的 Active Directory 架构
  • 添加 classSchema 或 attributeSchema 对象
  • 获得并使用对象标识符
  • 使用 .ldif 文件扩展架构
下载本文中所用的代码: Schema2008_05.exe (151KB)

自从在 Windows 2000 中开始引入 Active Directory 以来，Microsoft 已向众多客户提供了用于实施 Active Directory 的基本架构定义。
Active Directory® 的出现也标志着 Windows® 中许多应用程序的写入和实施方式都发生了转变。在此之前，应用程序（如 Microsoft® Exchange 5.5）必须要自行加以构建来包含其自身的目录结构。Active Directory 出现后，许多应用程序（无论是 Microsoft 的还是其他公司的）都开始充分利用它所提供的底层结构，而不再从头开始构建自己的架构。
这些应用程序首先使用 Active Directory 提供的基本体系结构，然后根据需要再加以扩展。以 Microsoft Exchange 2000 为例，它利用 Active Directory 来实现消息传递，并进而定义了未来的 Microsoft 消息传递体系结构。
现在，许多被编写为在 Active Directory 环境中运行的应用程序都依赖其底层架构来发挥作用，并且有些还会根据需要来定义自己的架构变更内容。当然，正如我将在本文中介绍的，这需要一个可扩展的架构。并且，由于如此众多的应用程序都依赖于 Active Directory 中的基本定义，因此核心架构的持续稳定性至关重要。因为许多应用程序都需要在同一个 Active Directory 中彼此配合工作，因此对任意应用程序的变更均不能影响其他应用程序。

什么是架构？
对许多人来说，Active Directory 架构是个黑盒子，修改自身架构这一想法让人觉得有点恐怖。当然，扩展 Active Directory 架构并不是每天都要执行的操作，但特定的应用程序或业务需求可能会需要此操作。因此，了解架构是什么以及它都包含哪些内容非常重要，并且由于 Active Directory 在许多组织中都是非常重要的资产，因此如果因更新有误而致使其出现故障可能会造成严重的影响。
作为一种策略，许多组织都在考虑将 Windows Server® 2008 中的“Active Directory 轻型目录服务”(ADLDS) 或 Windows Server 2003 中的“Active Directory 应用程序模式”(ADAM) 作为一种替代方案加以测试，或者直接实施自定义的架构定义而不扩展 Active Directory 架构。
架构是一种提供目录服务格式的底层结构。Active Directory 架构可以定义“Active Directory 域服务”(ADDS) 中使用的对象类和属性。核心架构定义了许多众所周知的类（如 user、computer 和 organizationalUnit）和属性（如 telephoneNumber 和 objectSID）。核心架构定义中出现的对象被称为“类别 1”对象，而添加的对象被称为“类别 2”对象。
Active Directory 架构可在路径 cn=Schema, cn=Configuration,dc=X 所定义的容器中找到，其中 X 是 Active Directory 林的命名空间。请注意，Active Directory 林仅包含一个架构；对林中的架构定义进行变更会影响该林中的所有域。图 1 显示了对于不同版本的 Windows Server，在 Active Directory 架构中添加的类和属性的数量。
Figure 1 类和属性的数量 (Close Figure 1)

版本 | 添加的属性数量 | 添加的类数量 | 架构扩展文件
Windows Server 2003 | 208 | 49 | Sch14.ldf 到 sch30.ldf
Windows Server 2003 R2 | 81 | 29 | Sch31.ldf
Windows Server 2008 | 136 | 10 | Sch32.ldf 到 sch44.ldf
在不同版本的 Windows Server 中，架构的更新都是使用名为 Adprep 的实用工具来完成的。在 Windows Server 2003 R2 的更新版本中，架构版本更新为 31，在 Windows Server 2008 中会改为 44。
要对此进行核对，可使用 ADSIEdit 等工具来检查 Active Directory 中 cn=Schema,cn=Configuration,dc=X 的 objectVersion 属性值。请注意，Exchange Server、System Management Server (SMS) 等应用程序或依赖于 Active Directory 的其他一些应用程序可能会根据应用程序的需求来修改架构。

具体细节
Active Directory 包括两种对象类型：classSchema（简称为类）和 attributeSchema（简称为属性）。如果组织希望将数据存储到未包含在现有架构中的特定属性内，通常会考虑扩展 Active Directory 架构。要在 Active Directory 架构中创建属性，首先要在架构容器中指定一个 attributeSchema 对象，然后为该新对象定义必要的属性。
在 go.microsoft.com/fwlink/?LinkId=110445 中提供了 attributeSchema 对象相关属性的列表以及其他一些信息。正如您所看到的，可为 attributeSchema 对象定义多个属性；这些属性中很多都是必需的。
除常规属性以外，架构中还有一些被称为链接属性的特殊属性，它们都是通过提供前向链接和后向链接来成对实施的。以 Active Directory 中的组成员身份为例。任意组（例如，名为 ContosoEmployees 且包含一个名为 John Doe 成员的组）的 member 属性为前向链接，而成员对象的对应 memberOf 属性为后向链接（因此，当查询 John Doe 的 memberOf 属性时，会计算 ContosoEmployees 组的可分辨名称，即 DN）。
前向链接的行为方式与其他所有属性都非常相似。其值可以是单值或多值（与 member 属性一样，可包含多个对象作为组成员），并与目录中的父对象存储在一起。
另一方面，后向链接是由系统维护的，以确保引用的完整性。查询后向链接属性的值时，会根据所有匹配的前向链接值来计算结果。后向链接始终是多值链接。
ADDS 中的每个对象类都由架构容器中的 classSchema 对象所定义。在 go.microsoft.com/fwlink/?LinkId=110445 中提供了对成功定义 classSchema 对象至关重要的一些属性的列表。
可以指定下列三种类型的类：Structural、Abstract 和 Auxiliary。它们由 objectClassCategory 属性的值定义。（第四种类型称为 88，它包括在 X.500 1993 标准之前定义的所有类。这种类型的类由 objectClassCategory 属性中的值 0 来指定。这种类型的类不应该再定义。）

获得并使用标识符
目录中每个 classSchema 和 attributeSchema 对象的身份都是使用“强制对象标识符”(OID) 定义的，此标识符的定义依据是 classSchema 对象的 governsID 和 attributeSchema 对象的 attributeID。这些是由特定的颁发机构所提供的唯一数字值，可用于识别对象。编号方式由 LDAP 协议 (RFC 2251) 的定义进行管理。Active Directory 架构中的某些 OID 是由“国际标准化组织”(ISO) 颁发的，而有些是由 Microsoft 颁发的。OID 对于目录中的对象而言必须唯一。
OID 是一个数字字符串，如 1.2.840.113556.1.y.z（如图 2 所示）。例如，由此可以得出用户 classSchema 对象的 OID 为 1.2.840.113556.1.5.9。
Figure 2 用户对象的标识符 (Close Figure 2)

值 | 含义 | 说明
1 | ISO | 标识根颁发机构。
2 | ANSI | ISO 指定的组名称。
840 | 美国 | 组织指定的国家/地区代码。
113556 | Microsoft | 国家/地区指定的组织名称。
1 | Active Directory | 由组织（如本例中的 Microsoft）指定。
Y | 对象类型 | 定义不同对象类型（类别）（如 classSchema 或 attributeSchema）的数字。例如，5 定义对象类。
Z | 对象 | 标识类别中特定对象的数字。例如，用户类被指定的数字是 9。
当组织打算扩展架构时，必须要确保 OID 的唯一性，为此首先要获取自己的 OID 根号，然后开始分支，为组织所创建的新对象类和属性提供唯一的 ID。OID 根可直接从 ISO 国家注册机构 (NRA) 获取，该机构在美国属于“美国国家标准协会”(ANSI)。
可通过 ansi.org 来了解获取根 OID 所需的程序和费用。对于其他地区，请联系相应的 ISO 成员组织；ISO 在 iso.org/iso/about/iso_members.htm 提供了其成员组织的列表。
在过去，组织可通过向 schemreg@microsoft.com 发送电子邮件来从 Microsoft 获取 OID。但是现在，它会提供一个自动回复，提示请求者从 go.microsoft.com/fwlink/?LinkId=110453 下载并运行 VBScript。
对于 Microsoft 颁发的 OID，该数字是在 Microsoft OID 数字空间下指定的：1.2.840.113556.1.8000.x，其中 x 是指定给组织的唯一编号。组织可能会进一步拆分这些 OID 来指定对象。这样，组织可以使用 1.2.840.113556.1.8000.x.1.y 来代表新的 classSchema 对象，使用 1.2.840.113556.1.8000.x.2.z 来代表 attributeSchema 对象（其中，x 代表组织的唯一编号，y 和 z 分别代表指定给特定的 classSchema 和 attributeSchema 对象的编号）。另外还建议用户在这些对象的名称中使用组织特定的前缀以区分它们。

定义链接属性
前向链接的 attributeSyntax 值为 2.5.5.1, 2.5.5.7（或 2.5.5.14），这一点非常重要。这些值对应于包含可分辨名称的语法，例如 Object (DS-DN) 语法。
后向链接的 attributeSyntax 值必须为 2.5.5.1，这是 Object (DS-DN) 语法。按照惯例，后向链接属性将被添加到顶层抽象类的 mayContain 值中。这将允许从任意类的对象中读取后向链接属性，因为后向链接属性实际上并非存储在对象中；它们都是根据前向链接值计算得来的。
Windows Server 2003 引入了如下所示的一个新功能，组织可使用此功能来链接架构中的两个对象：自动生成 linkID。利用此功能，当属性的 linkID 属性设为 1.2.840.113556.1.2.50 时，系统会自动为新链接属性生成一个 linkID。通过将 linkID 设置为前向链接的 attributeId 或 ldapDisplayName，可创建对应的后向链接。在创建前向链接之后及创建后向链接之前，必须重新加载架构缓存。否则，在创建后向链接时将无法找到前向链接的 attributeId 或 ldapDisplayName。架构缓存可根据需要重新加载，在架构更改后几分钟内或域控制器重新启动后也会重新加载。
如果您的 Active Directory 是在 Windows 2000 级别，则必须向 schemreg@microsoft.com 发送一封电子邮件，向 Microsoft 请求 linkID。在自动回复邮件中，您会看到：“对于发送到 schemreg@microsoft.com 的电子邮件，只有那些与原有环境下的 linkID 注册问题相关的邮件才会得到处理。”为此，请在电子邮件中提供以下信息：公司名称、联系人姓名、电子邮件地址、电话号码、注册的前缀（如果适用）、注册的 OID（如果适用）。

准备扩展架构
假设您已决定扩展您的 Active Directory 架构。在确信它已无法再满足要求后，此分析结果可能会建议减少使用 ADLDS（或 Windows Server 2003 中的 ADAM）实现的替代目录。接下来，确定要添加到架构中的新 attributeSchema 对象，这样做之后，可以定义指定这些新对象所需的所有值（例如 cn、ldapDisplayName 等）。在定义对象的属性值时，还从 Microsoft 或其他机构获取了 OID。您实际上已将上述内容记录为业务需求和技术规范。而且已实施了模拟 Active Directory 的实验室环境并已准备好进行测试。
许多组织实际都设有委员会来批准或拒绝此类变更并且会设置实施它们的过程。由于在许多组织中 Active Directory 都被用作权威的信息源，因此此类检查和平衡至关重要，而且在变更后认真加以贯彻和执行也极为重要，无论怎样强调也不为过。
当组织决定了继续推行后，就必须制定有关此项目的测试和实施计划。要对架构进行扩展，您可以使用 Microsoft 管理控制台 (MMC) 中的 Active Directory 架构管理单元来添加新对象，也可以使用编程或半编程方法来扩展架构（如使用 LDIFDE 来导入 .ldif 格式文件；使用 CSVDE 导入 .csv 格式文件；或使用 Active Directory 服务接口 (ADSI) 脚本）。
无论使用哪种方法，都必须在 Active Directory 林中，在连接到或拥有架构主机的“灵活单主机操作”(FSMO) 角色的服务器上执行此功能。并且，由于用来更新架构的帐户必须具有足够的管理权限才能执行更新，因此应使其成为“架构管理员”组的成员。最后，必须启用林的架构更新（默认为禁用）。
除非变更非常简单，否则都应以自动方式执行，以便促进测试和生产实施阶段之间的标准化并减少可能会因手动操作而产生的错误。让我们假设您已决定使用 LDIFDE 来实施变更。要在扩展架构时应用更新，您应添加新属性和类，向类添加新属性，然后触发缓存重新加载。让我们先来看几种方案。

添加属性
为了叙述方便起见，假设名为 Contoso 的组织希望将新属性添加到其 Active Directory 中，用来标识每名员工的鞋码。Active Directory 林有两个域：contoso.com 和 employees.contoso.com。具体要求是使用用户类定义创建的所有对象都应包含这一新属性。
您必须要记住的一点是，架构变更对这两个域都会产生影响，因为它们位于同一林中。假设您已从 Microsoft 获得 OID 1.2.840.113556.8000.9999 并已将其拆分为 1.2.840.113556.8000.9999.1（代表 Contoso 的 classSchema 对象）和 1.2.840.113556.8000.9999.2（代表 Contoso 的 attributeSchema 对象）。现在要为这一新对象定义所有属性值（如图 3 所示）。
Figure 3 定义 contosoEmpShoe 属性 (Close Figure 3)

属性 | 值 | 注释
Cn | contosoEmpShoe |
lDAPDisplayName | contosoEmpShoe |
adminDisplayName | contosoEmpShoe |
attributeSyntax | 2.5.5.12 | 指定一个 Unicode 字符串。
oMSyntax | 64 | 表示一个 Unicode 字符串。
objectClass | top, attributeSchema |
attributeID | 1.2.840.113556.8000.9999.2.1 | 如组织所定义。
isSingleValued | TRUE | 只能存储一个鞋码值。
searchFlags | 1 | 您的分析结果表明您希望为此属性编制索引。备注：您需要在实验室环境下执行压力测试分析。
isMemberOfPartialAttributeSet | TRUE | 您希望此属性出现在全局编录中。
而且，尽管 contosoEmpShoe 属性需要可供创建为用户类对象的所有对象使用，但并不建议您对用户类的默认定义进行修改。相反，应定义一个名为 contosoUser 的辅助类，它具有指定为 contosoEmpShoe 的 mayContain 值（如图 4 所示）。然后，将为 contosoUser 辅助类定义的属性添加到用户类中。
Figure 4 定义 contosoUser 类 (Close Figure 4)

属性 | 值
Cn | contosoUser
lDAPDisplayName | contosoUser
adminDisplayName | contosoUser
governsID | 1.2.840.113556.8000.9999.1.1（如组织所定义）
mayContain | contosoEmpShoe
possSuperiors | organizationalUnit, container
objectClassCategory | 3（定义辅助类）
既然已经执行了分析并定义了值，就可以开始创建 .ldif 文件了（类似于图 5 所示的代码）。您可将图 5 中的内容复制到记事本并将其保存为 contosoUser.ldif（或者，也可以在 technetmagazine.com 的代码下载部分找到此代码的副本）。
Figure 5 .ldif 文件（用于扩展架构） (Close Figure 5)
#Attribute definition for contosoEmpShoe

dn: CN=contosoEmpShoe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: contosoEmpShoe
attributeID: 1.2.840.113556.1.8000.9999.2.1
attributeSyntax: 2.5.5.12
isSingleValued: TRUE
adminDisplayName: contosoEmpShoe
adminDescription: contosoEmpShoe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: contosoEmpShoe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

# Classes

dn: CN=contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: classSchema
cn: contosoUser
governsID: 1.2.840.113556.1.8000.9999.1.1
mayContain: contosoEmpShoe
rDNAttID: cn
adminDisplayName: contosoUser
adminDescription: contosoUser
objectClassCategory: 3
lDAPDisplayName: contosoUser
name: contosoUser
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

dn: CN=User,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: auxiliaryClass
auxiliaryClass: contosoUser
-

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
生成 .ldif 文件后，您需要在实验环境中对实施进行全面的测试、验证域和林的端对端复制情况，还需要在林中启用架构更新。此时，应以具有“架构管理员”权限的帐户身份登录。您可能希望禁用架构主机（将在其中执行变更）上的出站复制，然后再运行以下命令来导入 .ldif 文件：
ldifde –i –f <Path>\contosoUser.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
变更发生后，启用架构主机上的出站复制并验证所有域控制器都已执行复制操作。
来一次深呼吸——大功告成啦！您已在架构中定义了一个新属性，它将与使用用户类（即用户帐户）创建的对象相关联。
要验证变更，请打开 Active Directory 用户和计算机，连接到 employees.contoso.com 域，浏览到用户组织单元 (OU)，创建一个名为 ContosoTestUser 的新用户帐户。现在，打开 adsiedit.msc 控制台并连接到域分区 dc=employees,dc=contoso,dc=com，展开用户组织单元，右键单击 ContosoTestUser，打开“Properties”（属性）页面。浏览查找 contosoEmpShoe 属性。可编辑此属性以输入一个值。也可使用 Ldp.exe 实用工具来验证和修改属性。
现在让我们来看一个定义和链接两个属性的示例，假设 Contoso 非常看重员工的鞋码并希望能通过某种方式跟踪公司中负责测量鞋码的员工的年度表现。这听起来可能有点好笑，但让我们进一步假设，Contoso 不仅希望跟踪负责测量员工鞋码的人员，还希望跟踪他们测量了哪些人的鞋码以及总人数（所有这些都通过查询一个属性来完成）。（您可能会认为此数据更适合存储在数据库表中，但此处只是为了解释前向链接和后向链接的工作机制）。
当然，您会首先执行我在先前的示例中提到过的相同类型的分析。但是，在此我们要继续生成 .ldif 文件 linkids1.ldif 和 linkids2.ldif（如图 6 所示）。然后运行以下命令来导入 .ldif 文件：
Figure 6 前向链接和后向链接 .ldif 文件 (Close Figure 6)

#linkids1.ldif
#Attribute definition for Forward Link Attribute

dn: CN=ContosoShoeSizeTaker,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizeTaker
attributeID: 1.2.840.113556.1.8000.9999.2.2
LinkID: 1.2.840.113556.1.2.50
attributeSyntax: 2.5.5.1
isSingleValued: TRUE
adminDisplayName: ContosoShoeSizeTaker
adminDescription: ContosoShoeSizeTaker
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizeTaker
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Reload schema

#linkids2.ldif

#Attribute definition for Backward Link Attribute

dn: CN=ContosoShoeSizesTakenByMe,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemaadd
objectClass: top
objectClass: attributeSchema
cn: ContosoShoeSizesTakenByMe
attributeID: 1.2.840.113556.1.8000.9999.2.3
LinkID: 1.2.840.113556.8000.9999.2.2
attributeSyntax: 2.5.5.1
isSingleValued: FALSE
adminDisplayName: ContosoShoeSizesTakenByMe
adminDescription: ContosoShoeSizesTakenByMe
oMSyntax: 64
searchFlags: 1
lDAPDisplayName: ContosoShoeSizesTakenByMe
systemOnly: FALSE

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add ContosoShoeSizeTaker and ContosoShoeSizesTakenByMe Attribute as MayContain in
#contosoUser class

dn: CN= contosoUser,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizeTaker
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1
-

#Add Backward Link Attribute as MayContain in Top

dn: CN=Top,CN=Schema,CN=Configuration,DC=X
changetype: ntdsschemamodify
add: mayContain
mayContain: ContosoShoeSizesTakenByMe

dn:
changetype: modify
add: schemaUpdateNow
schemaUpdateNow: 1

ldifde –i –f <Path>\linkedids<>.ldif –b
<username> <domain> <password> -k –j. –c
"CN=schema,CN=Configuration,DC=X"
#schemaNamingContext
在创建完用户对象后，它还会使 ContosoShoeSizeTaker 和 ContosoShoeSizesTakenByMe 作为其属性。当为某个人员（比如 John）创建用户对象时，ContosoShoeSizeTaker 属性将被填写为测量鞋码人员（即名为 Frank 的人员）的 DN。现在转到 Frank 的用户对象属性并查询 ContosoShoeSizesTakenByMe 属性，结果将包含 John 的以及 Frank 所测量的所有其他人的 DN。在我们方案的最后，管理层会根据 Frank 用户帐户的 ContosoShoeSizesTakenByMe 属性中存在的 DN 总数来奖励他。

系统检查和平衡
如果没有对体系结构需求的检查，将无法执行关键更新（如架构修改）。通过这些一致性检查和安全检查，Active Directory 可以验证无论何时对 Active Directory 执行添加或修改操作，这些变更都不会导致任何不一致情况或其他问题。
首先，每个类的 governsID 值在架构内必须唯一。在定义 schemaClass 对象时，在 systemMayContain、mayContain、systemMustContain 和 mustContain 列表中定义的所有属性必须都已经存在。同时，在 subClassOf、systemAuxiliaryClass、auxiliaryClass、systemPossSuperiors 和 possSuperiors 列表中定义的所有类也必须都已经存在。
并且，systemAuxiliaryClass 和 auxiliaryClass 列表中的所有类的 objectClassCategory 必须为 88 类或 Auxiliary 类。类似地，systemPossSuperiors 和 possSuperiors 列表中的所有类的 objectClassCategory 也必须被指定为 88 类或 Structural 类。
在定义各种类时，Abstract 类只能从其他 Abstract 类继承，Auxiliary 类无法从 Structural 类继承，而 Structural 类也无法从 Auxiliary 类继承。此外，在 rDNAttID 属性中指定的属性必须使用 Unicode 字符串作为其语法并且必须为单值。
这些是与 classSchema 对象相关的一些规则。那 attributeSchema 对象的规则呢？与类的 governsID 值一样，attributeID 的值也必须唯一。同样，mAPIID（如果有）的值也必须唯一。并且，如果存在 rangeLower 和 rangeUpper，rangeLower 必须小于 rangeUpper。attributeSyntax 和 oMSyntax 的值必须匹配。如果属性为对象型语法 (oMSyntax =127)，它必须具有正确的 oMObjectClass。linkID（如果有）必须唯一。此外，后向链接必须有一个对应的前向链接。

如果出了差错该怎么办？
使用新对象（类和属性）对架构进行扩展后，这些新对象将无法再删除。但是，可通过将架构对象的属性 isDefunct 设为 TRUE 来取消激活类或属性。不过对于随 Active Directory 一同提供的作为默认架构一部分的架构对象（“类别 1”对象），将无法取消激活它们。您只能取消激活被添加到默认架构中的对象；即，只有“类别 2”对象能被禁用，并且必须要经过 Active Directory 验证，确认该类未用于任何现有非无效类的 subClassOf、auxiliaryClass 或 possSuperiors 列表中。
如果试图将某个属性设为无效，Active Directory 会检查以确认任何现有非无效类的 mustContain 或 mayContain 中都未使用该属性。可通过将属性 isDefunct 设为 FALSE 来恢复被禁用的对象。如果您的 Active Directory 是在 Windows Server 2003 级别，则可重用被禁用对象的 ldapDisplayName、schemaIdGuid、OID 和 mapiID 值。

总结
在架构中添加或修改类或属性定义涉及到添加或修改对应的 classSchema 对象或 attributeSchema 对象。此过程类似于在 Active Directory 中添加或修改任意对象，不同之处在于需要执行额外的检查来确保变更在今后不会在架构中导致不一致情况或其他问题。
尽管修改 Active Directory 架构非常简单，但必须要了解架构的构成以及它是如何实施这些变更的。对生产型 Active Directory 架构进行任何变更前都需要进行周密的规划，并且执行时务必要小心谨慎。对新对象而言，为其定义业务需求和技术规范并执行大量的实验室测试至关重要。由于变更可能会产生深远的影响，因此建议只有在绝对必要的情况下才扩展 Active Directory 架构。

Vikas Malhotra 就职于纽约的 Microsoft Consulting Services。在 12 年的职业生涯中，他曾与许多大型和中型企业的 IT 组织一起工作，研究他们的基础设施体系结构需求（如目录、消息传递、安全性以及数据联网等）。他拥有电子和电信工程学学士学位以及电信（技术）管理理学硕士学位。可通过电子邮件 vikasmal@microsoft.com 与他联系。


 System Center: System Center Mobile Device Manager 简介
System Center Matt Fontaine

System Center Mobile Device Manager 简介
概览:
  • 典型的 Mobile Device Manager 系统
  • 将 Active Directory 扩展到 Windows Mobile
  • 注册、置备和清点 Windows Mobile 设备

对于管理公司网络中的 Windows Mobile 设备的 IT 专业人员而言，Microsoft System Center Mobile Device Manager 2008 的发布是一件令人兴奋的盛事。通过在单一产品中提供设备管理、安全管理和移动虚拟专用网 (VPN)
功能，这一新产品可以有助于降低管理负担并提高移动设备的投资回报 (ROI)。
Mobile Device Manager 可使 IT 专业人员利用现有的 Active Directory® 和组策略基础架构对设备进行设置。IT 专业人员可使用无线 (OTA) 设备管理功能轻松地向设备提供更新和应用程序，而 OTA 自置备功能可使部署更加轻松且更具伸缩性。移动 VPN 使最终用户能够访问防火墙后的数据和应用程序，同时向管理员提供永不间断的连接以便于其控制部署的设备。由于在一个可扩展、可自定义且可伸缩的产品中提供了所有这些功能，因此 Mobile Device Manager 对如今的 IT 专业人员而言是一个不可或缺的工具。

管理需求
据预测，在随后的几年中移动员工的数量仍会继续保持快速增长势头。由于移动性这一事实，移动设备历来都要比其他网络设备更难于管理。它们以各种方式连接到网络，并且有些设备的安全性要比其他设备差一些——它们可能位于防火墙以外、它们使用不同于客户端设备的操作系统，而且它们一般都很小，容易忘记放置位置或丢失。
现在的移动设备所具有的扩展功能向企业和最终用户展示了众多诱人的优点，但这也使得对这些设备的支持更加复杂。它可能会使公司数据和网络面临更多的安全风险，尤其是使用此类设备访问敏感的业务线 (LOB) 应用程序和客户数据时。如果此类设备丢失、被盗或使用不当，可能会带来严重的安全问题。
由于移动设备与传统网络客户端之间的功能沟壑已消失，因此越来越需要像管理便携式计算机或台式计算机一样来管理移动设备。这就是 Mobile Device Manager 的设计初衷。由于 Windows Mobile® 平台在业务用户中越来越普及，因此 Mobile Device Manager 将成为基于 Windows® 的 IT 管理系统的最关键环节。
Mobile Device Manager 的设计目标就是使 Windows Mobile 设备能够像联网的计算机或便携式计算机一样，轻松地进行端对端管理和控制。它包含以下三个关键功能：
设备管理 将 Windows Mobile 设备的置备、监控和管理功能集中在一起，使每个服务器都可以扩展到成千上万个用户。
安全管理 是一种用来保护敏感数据和跟踪设备的非常出色的机制。
移动 VPN 更好地访问防火墙后的数据和应用程序且永不间断。
Mobile Device Manager 符合整体的 System Center 基本原则，即优先为 IT 专业人员配备管理公司资产所需的工具——等同于台式和便携式计算机。它还提供了使用过其他 System Center 产品的人员所熟悉的用户界面。
这也意味着，由于采用了现有的基于 Windows 的基础结构设计，因此 Mobile Device Manager 的工作效果非常出色。例如，它使用 Active Directory 和组策略；它使用现有的 Microsoft 分析和报告工具（如 SQL Server®）；并且它可以使用 Microsoft® 管理控制台管理单元和 Windows PowerShellTM cmdlet 进行扩展。

Mobile Device Manager 系统
Mobile Device Manager 的扩展性很强，可以在单个实例上支持成千上万的设备，另外还有多个配置选项。一般来说，Mobile Device Manager 的服务器端有四个主要系统组件：网关服务器、设备管理服务器、注册服务器和 SQL Server 数据库（请参见图 1）。
Figure 1 Typical Mobile Device Manager system
Figure 1 Typical Mobile Device Manager system
网关服务器通常安装在外围网络中。它充当设备的网络连接终端、验证传入的设备连接、为设备提供稳定的 IP 地址以及执行其他与设备或网络连接相关的功能。
设备管理服务器是设备管理的中心，包括组策略实施、OTA 软件分发以及设备擦除等。它使用现有的域控制器。设备管理服务器充当 Windows Mobile 设备的代理网络客户端，从而使这些设备可以与其他系统进行通信。
注册服务器可创建代表域控制器中的移动设备的 Active Directory 域服务对象，以便能够像管理其他域成员一样管理这些设备。此服务器还处理移动设备的证书请求和检索。在接受或发出注册证书之前，它基于 Active Directory 对设备进行身份验证。SQL Server 数据库提供了一个用来存放有关设备配置、任务、状态设置等各种信息的存储库。
启动并运行基础结构后，Mobile Device Manager 与移动设备之间有三种类型的交互：设备注册、建立移动 VPN 连接和设备管理。设备注册是设备加入 Active Directory 域的过程。Mobile Device Manager 使用“共享机密”（一个会过期的一次性密码）来使设备能够通过非安全的连接进行注册。注册之后，设备即可与网关服务器进行移动 VPN 连接，届时设备的网络流量都将通过此网关服务器进行路由。使用移动 VPN 连接，管理员或系统可执行设备管理并将软件和设置推送给设备。

将 Active Directory 扩展到 Windows Mobile
混合的或专门的 IT 安全方法可能会比完全集成的安全方法更具风险性。Mobile Device Manager 旨在通过使用现有的 Active Directory 域服务基础结构提供一种移动设备管理方法（如 Windows PC）来帮助降低此类风险。最终会得到简化的身份和访问管理、更一致的策略目标和一站式的安全配置。
就像 PC 或服务器一样，与 Windows Mobile 设备相关的组策略对象可指定给组织单位 (OU)、安全组以及 Windows 管理规范 (WMI) 筛选器。管理员也可以阻止特定的设备获取组策略设置。
Windows Mobile 设备拥有 130 余个设置和策略，可以精准地控制各种功能。以下是一个示例：
  • 密码设置包括密码要求、类型和最小长度、密码过期时间以及经过指定次数的失败尝试后执行本地设备擦除（包括通知用户剩余尝试次数）。
  • 平台锁定设置使管理员能够有选择地启用或禁用设备功能，包括照相机、无线 LAN、红外线、蓝牙和可移动存储等。邮局协议 (POP)、Internet 消息访问协议 (IMAP)、短消息服务 (SMS) 和多媒体消息服务 (MMS) 等都可以被关闭，并且可以禁用 Windows Mobile 的 Windows Update。
  • Mobile Device Manager 提供精细的应用程序控制。它可以阻止设备运行未签名的应用程序或具有未批准签名的应用程序，还可以根据管理员的判断允许特定的未签名应用程序。
  • 为帮助保护数据，管理员可以强制加密在可移动存储卡上创建的文件（使用与设备相关的加密密钥）。设备加密还可以用来保护设备上的敏感数据。除默认被保护的文件以外，管理员还可以指定要加密的其他文件。
  • 移动 VPN 设置可用来决定用户对其设备的 VPN 连接具有何种控制，还可用来设置数据加密级别。
  • ActiveSync® 设置可设定消息格式、电子邮件有效期限筛选器、大小限制以及同步设置等。
  • S/MIME 设置可能需要消息签名、消息加密或使用特定算法。
这些设置以及其他设置都支持范围很广的各种方案。它们使 IT 专业人员能够决定在哪些设备上可以运行哪些类型的应用程序。可通过无线方式启用或禁用硬件功能，例如，可禁用照相机以帮助防止意外或故意泄露敏感信息。可强制在设备上、可移动存储卡上或同时在这两者上执行数据加密，以降低因设备或存储卡丢失或被盗而致使专有数据落入未授权个人手中的可能性。
其他一些安全管理工具也是 Mobile Device Manager 的一部分。由于可供 Windows Mobile 设备使用的应用程序成千上万，因此显然需要由管理员来控制能够安装的和不能安装的应用程序。为此，Mobile Device Manager 允许您创建并强制执行应用程序的允许和阻止列表。它还提供功能强大的远程擦除功能。由于与设备之间存在永不间断的 VPN 连接，因此不必等待其连接到网络并同步即可立即擦除设备。远程擦除设备后，会将其从域控制器中删除并吊销其证书。如果以后恢复设备，可使用新的一次性密码重新注册，然后即可将其设置为重新加入域。

持续检查移动设备
Mobile Device Manager 可以在单一解决方案中提供完整的设备管理功能，这最大程度地简化了管理网络上各种 Windows Mobile 设备的工作，包括 OTA 置备、OTA 软件和更新分发以及全面、集中的清单管理。
OTA 自注册功能可能会赢得忙碌的 IT 专业人员和最终用户的欢心。用户只需在 Windows Mobile 6.1 设备上输入电子邮件地址，它就会尝试根据给定的电子邮件地址查找移动设备管理服务器。如果找不到服务器，它会提示用户手动输入管理服务器的地址。找到服务器并确定该用户可以注册后，它会要求用户输入管理员预先生成的一次性验证码。
电子邮件地址和验证码将用于对用户进行身份验证并在管理服务器中注册其设备。一切都完成后，管理员定义的设置和策略将被推送到设备中。自注册方法旨在增强 Windows Mobile 设备部署的可伸缩性并减少启动和运行此类设备所需的时间和金钱。
Mobile Device Manager 的 OTA 软件分发功能基于 Windows Software Update Services (WSUS) 3.0（世界各地的众多 IT 专业人员一直都在使用的一款软件更新工具包）而开发。如图 2 所示，WSUS 3.0 提供了各种可满足复杂 IT 需求的定位和应用程序打包功能。它可以根据管理员所设置的规则和策略自动为适当的设备提供软件。与服务器和客户端更新一样，可使用 WSUS 3.0 来自动安装移动设备的更新程序和修补程序。同样至关重要的一点是，在部署规划和测试时可关闭自动更新功能。
Figure 2 Software distribution wizard
Figure 2 Software distribution wizard
管理大规模部署的移动设备的最大挑战之一是如何能够简单地进行跟踪。Mobile Device Manager 集中了清单信息并提供了基于 SQL Server 2005 的灵活、可自定义的报告——同样，可以使用许多用户都已熟悉的软件来执行这些工作。管理员可收集超过一百项清单信息，包括（但不限于）操作系统和版本、设备型号、已安装的应用程序以及安全策略等。清单是可扩展的，这将允许管理员添加项目和注册表设置。
如需更多的灵活性，可借助其他工具对 Mobile Device Manager 进行控制，如果喜欢图形用户界面，可使用 Microsoft 管理控制台管理单元（请参见图 3），如果喜欢命令行，可使用 Windows PowerShell 控制台。在任何一种方法中，系统都可以进行扩展和自定义——对于希望使软件符合其组织要求的企业用户而言，这一点至关重要。
Figure 3 Mobile Device Manager Console
Figure 3 Mobile Device Manager Console

移动 VPN
多年以来，许多信息工作者一直都在通过移动设备来发送电子邮件和传递消息。现在，移动设备技术领域最有用的发展之一是可以访问防火墙之后的业务数据和应用程序。随着访问能力的改善，新的安全风险也随之上升，因此必须谨慎地管理增加的功能以防止出现漏洞。Mobile Device Manager 提供了先进的移动 VPN 功能，使用户可以访问 intranet 中的各种数据，从 Microsoft DynamicsTM 客户关系管理 (CRM) 到 SAP 再到 Siebel 等。另外还构建了一种模型来匹配台式计算机或便携式计算机的现有远程访问策略（请参见图 4）。
Figure 4 Mobile VPN settings
Figure 4 Mobile VPN settings
移动 VPN 使用双围安全功能来将设备连接到网关服务器，并以 SSL 加密格式通过 IPsec 加密通道来传输数据。设备通过身份验证后，用户即可根据资源特定的策略和用户凭据来访问资源。
Mobile Device Manager 所使用的移动 VPN 技术可建立永不间断的连接，这不仅为用户提供了增强的访问能力，而且有助于确保 IT 专业人员即时更新设备的策略和设置，并可以在设备丢失或被盗时立即擦除设备。在会话中断的情况下，快速重连功能可确保设备会话继续进行，而无需重新进行身份验证。Mobile Device Manager 可在保持连接不断的情况下实现 Wi-Fi 和移动电话网络之间的平稳转换。
Mobile Device Manager 移动 VPN 中所使用的安全技术都是以行业标准为基础的，包括设备管理开放移动联盟 (OMA DM)、因特网密钥交换 (IKE) 第 2 版以及 OMA 软件组件管理对象 (SCOMO) 等。这将有助于针对 IT 专业人员所处的复杂环境中的特定情形来扩展和自定义系统。

完整的解决方案
Mobile Device Manager 提供了一整套的工具，可以通过单一的界面来管理 Windows Mobile 设备。它利用 Active Directory 和组策略来提供用来保护数据、设备和网络的安全工具。通过 OTA 注册、置备和更新以及强大的清单工具，可更加轻松地对设备进行管理。移动 VPN 旨在不影响安全的情况下提供企业和用户所需的功能。
所有这一切都体现了这一理念，即优先考虑通过网络进行管理的移动设备，从而使 IT 专业人员的工作更加轻松。Mobile Device Manager 使 IT 专业人员能够提供优质的最终用户体验、降低管理开销并提供更高的管理投资回报——这的确是一种值得选择的组合。
感谢以下人员对完成本文所做的贡献：Brian Hoskins、Derek Snyder、Prithvi Raj、Lax Madapaty 以及 Katharine Holdsworth。

Matt Fontaine 就职于 BuzzBee 公司，是一名自由技术撰稿人和顾问。他从事过多种行业的工作，包括高性能计算、企业软件、保险计算员、商业房地产、工程、建筑以及大众消费品。Matt 毕业于常青州立学院。


 System Center: System Center Essentials SP1 的新增功能
System Center Pete Zerger

System Center Essentials SP1 的新增功能
概览:
  • 使用集成安装程序包更轻松地实现安装
  • 用于微调管理包的增强覆盖功能
  • 支持工作组
  • 新的运行状况重新计算任务

通过去年七月发布的 System Center Essentials 2007，Microsoft 很好地完成了对中型企业的承诺，它在昂贵且复杂的企业级工具与共享软件
解决方案之间搭起一座桥梁，从而为 IT 操作提供了统一的管理解决方案。Essentials 2007 专为解决 IT 专业人员常常需要执行大量任务的中型企业所面临的挑战而设计。
Essentials 易于安装和配置，从而使得 IT 专业人员可主动监控和管理客户端及服务器，并可跟踪硬件和软件资产。它旨在简化传统的复杂任务，如应用程序和 IT 服务监控、客户端和服务器软件部署以及桌面问题的故障排除。
从初始版本起，Microsoft 就从使用 Essentials 来管理其 IT 基础结构的客户处收集了大量的反馈意见，并且这些信息已合并到此产品的第一个 Service Pack 中。除提供错误修复外，SP1 还引入了一些重要的增强功能，从而使此产品在满足各种部署环境中的客户需求方面变得更加灵活。此外，它带来的性能改进可显著增强用户体验并简化管理。
在本文中，我将讲解 Essentials 2007 SP1 中提供的关键改进功能。我还将介绍这些功能可如何帮助您更加轻松地管理您的环境。

安装更轻松
SP1 集成安装程序包汇集了目前为止的所有 Essentials 修补程序，从而使安装过程变成只需几次单击操作即可完成的一个简单任务。现在，还可在 Essentials 服务器驻留在 32 位 Windows Server® 2003 实例的同时，将 Essentials 配置为使用远程 64 位 SQL Server® 2005 实例。这样，管理员可在分布式 Essentials 部署拓扑中更加灵活地利用其环境中的现有服务器基础结构。此外，Essentials 2007 SP1 服务器、控制台和代理将支持 Windows Server 2008 平台。在 Windows Server 2008 投入生产之后，预计它将很快提供对该新操作系统的全面支持。

控制台性能更好
如果使用过 Essentials 2007 的 RTM 版本，您将会非常喜欢 SP1 中响应速度显著提高的 Essentials 控制台界面。“Alert”（警报）、“Event”（事件）、“Performance”（性能）、“State”（状态）和“Task Status”（任务状态）视图的性能均已得到增强。例如，在所有“Alert”（警报）视图中，数据提取（检索）方面的更改使得警报数据的选择快了三倍。现在，操作和报告都是在后台进行提取，因而进一步改善了 UI 的性能。同样地，基于上下文的“Tasks”（任务）和“Reports”（报告）（显示在“Operations Console”（操作控制台）右侧的“Actions”（操作）窗格中）是在后台进行加载，这使得视图能更快地响应您的选择。
现在，可根据用户的喜好通过单击“Show Knowledge”（显示知识）或“Hide Knowledge”（隐藏知识）链接（请参阅图 1），显示或隐藏在“Alert Details”（警报详细信息）窗格中显示的警报知识。在查看以后的警报时，程序将记住此首选项。管理员现在还可以使用标准的键盘快捷方式（例如 Ctrl+C 和 Ctrl+V）来执行警报详细信息的复制和粘贴操作。
Figure 1 Alert Details pane with Show/Hide Knowledge links
Figure 1 Alert Details pane with Show/Hide Knowledge links

覆盖增强功能
覆盖可用于调整管理包、在不需要的地方禁用规则和监控以及调整各种阈值。与覆盖相关的多项重大改进不仅使环境中规则和监控的调整更加轻松，而且还可更加深入地了解 Essentials 环境中已存在的覆盖。其结果是创建自定义规则的需要减少了，并且缩短了确定当前环境中已存在覆盖的时间。
例如，在为任意管理包对象创建覆盖后，现在可在“Overrides Summary”（覆盖摘要）框中查看该对象类型的覆盖摘要。Essentials 2007 SP1 确保了覆盖目标说明的完整性。例如，如果为 Server1 的 C:\ 驱动器创建了“逻辑磁盘可用空间”覆盖，则摘要将显示“server1/c:”。下面的示例可说明此更改的重要性。
请注意，图 2 显示了 Essentials 2007 RTM 版本中 Windows Server 2003 逻辑磁盘可用空间的“Overrides Summary”（覆盖摘要），该摘要无法说明作为覆盖目标的 C:\ 驱动器实例位于哪台计算机上。而在 Essentials SP1 的相同“Overrides Summary”（覆盖摘要）中，可以看到在“Name”（名称）列中不仅显示目标驱动器实例，而且还显示有托管该驱动器的计算机（请参阅图 3）。
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 2 Overrides Summary in Essentials 2007 RTM
Figure 3 The same Overrides Summary in Essentials 2007 SP1
Figure 3 The same Overrides Summary in Essentials 2007 SP1
警报严重性可对管理员所收集的警报流量产生重大影响。到目前为止，如果将密封管理包中的“Essentials 规则”配置为生成一个对某些服务器并不重要的关键警报，那么管理员将无法调整该设置，因为规则覆盖中不会出现警报严重性和优先级。唯一的解决方法是花费大量时间和精力来创建覆盖以针对这些计算机禁用规则，然后在可操作警报参数的未密封管理包中重新创建规则 — 但从管理角度来看，显然并非理想的解决方案。
SP1 对此问题的处理非常巧妙，它将警报严重性和优先级都作为覆盖参数显示在所有的密封管理包规则中（如图 4 所示）。这样，管理员可通过创建覆盖来快速且轻松地降低或提高由 Essentials 2007 中规则生成的警报的严重性和优先级。
Figure 4 Alert severity and priority rule overrides
Figure 4 Alert severity and priority rule overrides
您可能还注意到图 4 中的“Enforced”（强制执行）复选框，在 Essentials RTM 版本的控制台界面中并无此复选框。如果为一个对象启用了多个覆盖，则选中“Enforced”（强制执行）标记的覆盖的优先级更高。在为两组对象设置相同的覆盖并且某些对象同时属于这两个组时，该选项就可派上用场。通过为希望优先处理的覆盖设置“Enforced”（强制执行）选项，就可确定应用的是哪个覆盖设置。
为更加轻松地创建新的管理包，Essentials 2007 SP1 引入了将视图从现有的管理包复制到未密封管理包的功能。复制操作受所有类型的视图（如“Event”（事件）、“Alert”（警报）、“Performance”（性能）、“Dashboard”（仪表板）和“Diagram”（图表））的支持，并可在“Monitoring”（监控）区域中执行。例如，如果为 Active Directory® 覆盖创建了管理包，并且希望使用 Active Directory 覆盖管理包中的一个 Active Directory 管理包视图，只需选择想要的视图，然后将其复制并粘贴到“Monitoring”（监控）区域的“Navigation”（导航）窗格中的自定义管理包文件夹中即可。

新的覆盖报告
同样值得一提的是 Microsoft® 通用报告库中的新覆盖报告（位于 Essentials 控制台的“Reporting”（报告）窗格中）。该报告从存储覆盖的管理包角度或根据将它们应用到其中的管理包角度来进行描述（请参阅图 5）。用户可设置报告参数来从报告排除密封 MP 覆盖。它是一个非常重要的筛选选项，因为 Microsoft 和其他公司的密封管理包中包含在报告自身环境中所做更改时您不会注意到的许多覆盖。
Figure 5 Overrides Report parameters
Figure 5 Overrides Report parameters
如果遵循 Microsoft 的最佳实践为每个密封管理包创建单独的自定义管理包（一个用于 Active Directory MP，一个用于 Exchange MP 等），那您将可以更加有效地缩小报告范围，查看应用到特定管理包的覆盖。
选择适当的未密封管理包后，就可运行报告（它将显示如图 6 中所示的输出）。请注意，该报告清楚地显示了覆盖应用到的规则或监控（“Affected element”（受影响的元素）列）以及监控的“Installed”（安装）和“Deleted”（删除）日期和时间。它说明了“覆盖报告”不仅会列出活动覆盖，而且还是一个覆盖配置更改历史记录报告。
Figure 6 Overrides Report detail
Figure 6 Overrides Report detail
最后，在每个受影响“Rule”（规则）或“Monitor”（监控）的详细视图底部，都有一个“Rule configuration view”（规则配置视图）超链接。该链接可启动独立的“Rule”（规则）视图或“Monitor”（监控）视图，并且该视图的范围为受影响的对象类型。例如，如果单击图 6 中所示覆盖的“Rule configuration view”（规则配置视图）链接（该覆盖针对目标为 Active Directory Domain Controller Server 2003 Computer 角色的规则），请注意得到的“Rule”（规则）视图将仅显示目标为该对象类型的规则。

支持工作组计算机
客户反馈的重点之一与管理工作组配置中的服务器和工作站的需求相关。许多环境中都至少有一台服务器位于未加入域的外围网络或分支机构中。由于 Essentials 需要在 Essentials 服务器和代理管理的计算机之间进行相互验证，因此位于 Essentials 服务器信任边界以外的工作组计算机同样不属于 Essentials 代理部署范围之列。在许多环境中，它意味着基础结构的重要组件可能无法得到监控并处于 Essentials 补丁管理过程之外。如何安全地管理这些计算机呢？
SP1 为无法使用 Active Directory 和 Kerberos 身份验证的场合引入了基于证书的身份验证。它要求 Essentials 服务器和代理管理的计算机都安装 X.509 数字证书。该数字证书可由 Windows® 单机版或企业根证书颁发机构颁发。如果环境中目前并无 Windows 证书颁发机构，则可在环境（包括 Essentials 服务器）中的域控制器或成员服务器上通过“添加/删除程序”来安装此功能。有关 Windows Server 2003 中证书服务和公钥基础结构 (PKI) 的详细信息，请参阅 microsoft.com/windowsserver2003/technologies/pki。
要在 Essentials 中配置基于证书的身份验证，首先申请证书并向 Essentials 服务器和要管理的目标计算机颁发证书。可通过作为证书颁发机构的服务器上的网站提交申请。
颁发并安装证书后，必须通过使用 MOMCertImport 命令行实用工具进行“注册”才能用于 Essentials。要完成证书配置，只需将证书导出为文件（以 .pfx 格式），并使用以下命令在本地计算机上运行 MOMCertImport：
MOMCertImport.exe <cert path \ name>
在 Essentials 服务器和要管理的目标计算机上执行完所有这些步骤后，这些系统将可以相互验证，并且通过加密通道安全地交换数据。要完成代理部署过程，只需在目标计算机上手动安装 Essentials 代理即可。

网络和设备监控
Essentials 2007 提供了网络设备监控功能，能够发现许多启用 SNMP 的网络设备的常用属性。虽然 SNMP 版本 2c (SNMPv2c) 是现在使用最广泛的版本，但是并非所有网络设备都使用该版本。因此，SP1 还支持 SNMP 版本 1 (SNMPv1)，以便监控各种较旧的网络设备（如不支持 SNMPv2c 的一些 UPS、路由器和打印服务器）。如图 7 所示，管理员可通过“Computer and Device Management Wizard”（计算机和设备管理向导）中附加的下拉字段告诉 Essentials 使用哪个 SNMP 版本。
Figure 7 Enhanced interface for network device discovery
Figure 7 Enhanced interface for network device discovery

增强的更新管理功能
SP1 中的更新管理也有重大改进。Windows Server Update Services (WSUS) 3.0 自动审批规则允许指定不同的产品和更新分类，如自动审批 Microsoft Word 的更新定义。
Essentials 中还添加了对多条自动审批规则的支持，从而使其功能可与 WSUS 3.0 平台相媲美（请参见图 8）。管理员可利用该功能为多种更新创建自动审批，包括 Windows Vista® 关键更新和 2007 Office 系统的 Service Pack。然后，自动审批规则将应用于 WSUS 服务器上当前所有的更新。因此，通过单击“Auto-Approvals”（自动审批）对话中的“Run Rule(s) Now”（立即运行规则）任务，管理员就可对 Essentials 控制台中的现有更新立即应用更改。
Figure 8 Auto-Approvals in Update Management
Figure 8 Auto-Approvals in Update Management
凭借在工作组配置中的计算机上执行代理部署这一新增支持功能，管理员将能够从 Essentials 控制台控制整个环境的更新管理。

计算对象运行状况
在过去，在 Health Explorer 中查看监控状态时，管理员必须等待监控状态的定期刷新才能确定“恢复”或其他纠正操作是否成功。Health Explorer 的 SP1 版本新增了“Recalculate Health”（重新计算运行状况）任务，该任务可根据需要重新计算监控运行状况（请参阅图 9）。由于省去了等待查看监控状态是否恢复正常时纠正操作之间的等待时间，它显著加快了故障排除过程。
Figure 9 Recalculate Health Task in Health Explorer
Figure 9 Recalculate Health Task in Health Explorer
同样，自 RTM 版开始提供的“Reset Health”（重置运行状况）任务也提供一些重要的改进功能，从而确保每个监控都可以实际响应将其运行状况重置为正常情况（绿色）的请求。这甚至对于针对 Essentials 服务器自身执行的重置请求也同样适用，但在 RTM 版本中，它并不能始终响应重设请求。

脚本化诊断
诊断是 Essentials 2007 中新增的特殊内嵌任务类型，它允许在触发警报时自动或按需执行数据收集任务。自动诊断是配置为只要监控进入错误状态就执行的一种诊断。诊断结果将显示在 Health Explorer 的“State Change Events”（状态更改事件）选项卡的“Details”（详细信息）窗格中。按需诊断将作为超链接出现在相同区域中，并且通过单击链接就可执行。结果将显示在本地计算机的弹出窗口中。
如图 10 所示，SP1 允许在诊断任务中使用脚本（而不像 RTM 那样只能使用命令行响应），从而扩展了诊断功能。因此，在遇到错误情形时，可执行更加详细且不同的自动数据收集响应。请注意，可在这些诊断任务中使用 VBScript 和 JScript®。
Figure 10 Alert Details pane with Show/Hide Knowledge links
Figure 10 Alert Details pane with Show/Hide Knowledge links

导出为 Visio
SP1 中的另一项新功能是支持将图表导出为 Microsoft Visio® 2007 格式，当用户选择图表视图后，工具栏上将出现对应的导出按钮。这是一项非常方便的文档功能，因为 Active Directory 和 Exchange Server 2003 管理包提供了现成的详细拓扑结构图，因而可以节省管理员编写文档所需的宝贵时间。此外，还可以保存图表布局首选项。在下次选择图表视图时，Essentials 控制台将记住这些首选项。

更好的备份和恢复指导
安装 Essentials 2007 SP1 之后，安装向导紧跟着会自动提示用户备份 Essentials 管理服务器加密密钥（请参阅图 11）。操作数据库中“Run As Credentials”（作为凭据运行）的安全存储中的 Essentials 服务器将使用该密钥对。如果必须从备份恢复 Essentials 服务器，也会需要使用这些密钥。如果缺少该密钥对，则需要从头开始重新安装和配置 Essentials。
Figure 11 Essentials encryption key backup
Figure 11 Essentials encryption key backup

管理包质量得以改进
除了 Essentials SP1 中提供的许多改进功能以外，通过更多更严的测试程序以及与各产品团队和应用程序主题事项专家进行更加深入的交流，Essentials 产品团队在提高 Essentials 平台的管理包质量方面取得了巨大进步。其结果将反映在利用 Microsoft 监控平台新功能的更多管理包中，包括自我调整阈值、使用分布式应用程序模型执行面向服务的监控以及功能强大的报告引擎。
从 2008 年起，Microsoft 将开始发布更多采用 Essentials 新功能的本机管理包。可从 System Center 管理包目录下载用于 Essentials 2007 的管理包，网址为 go.microsoft.com/fwlink/?LinkId=112399。

尝试一下
SP1 提供的性能增强功能使 System Center Essentials 2007 成为管理中型企业的 IT 基础结构的明智投资。如果您的环境中已部署 Essentials 2007，那您可以下载一个 SP1 副本，并亲自体验它所带来的功能和性能改进。如果尚未部署 Essentials 2007 并希望尝试一下 Essentials 2007 和 SP1，那您可下载集成了 SP1 的安装程序包。Essentials 2007 主页中提供了这两个程序包以及其他产品信息，网址为 microsoft.com/systemcenter/essentials。

Pete Zerger 是 AKOS Technology Services 公司的咨询合作伙伴，并拥有九年在 IT 行业工作的经验。主攻设计和部署企业操作管理、目录服务和消息传递解决方案。他是一位消息传送 MCSE、SQL Server 2005 MCTS，并且还是 Microsoft Operations Manager 的 Microsoft MVP。同时，他是 systemcenterforum.org 的创始人，这个广受欢迎的社区站点介绍了 Essentials 2007 和 System Center 系列方面的主题。


 编辑寄语: 热烈欢迎“深入剖析 SharePoint”
编辑寄语
热烈欢迎“深入剖析 SharePoint”

您可能还记得在上月的“编者按”中，在与“网络专家”栏目道别之后，我曾提到过本期《TechNet 杂志》将推出一个全新的栏目。让我们热烈欢迎“深入剖析 SharePoint”，此月刊将介绍 IT 专业人员在构建、部署、保护、维护和支持 SharePoint 基础结构方面需要了解的所有知识。正如我们承诺的那样，Pav Cherny 将首先概要介绍灵活的 SharePoint 基础结构的关键要素。下个月将接着介绍 SharePoint 站点管理。并且，我们仍期待着您的回应：如果您有特别希望我们介绍的 SharePoint 主题，请发送邮件至 tnmag@microsoft.com。
同样，在本月期刊中，Gil Kirkpatrick 将继续深入而全面地概述 Windows Server 2008 中的 Active Directory 备份与恢复过程。在许多（如果并非大部分）面向 Windows 的网络中，Active Directory 都是标识和访问信息的权威来源（我想我们都会认同它的重要性）。它还是 Exchange、SharePoint、Configuration Manager 等部署的关键基础结构要素。然而，上个月我在芝加哥参加目录专家会议时，当 Gil 在他的会议中问及在场与会者中有多少人为 Active Directory 提供了全面的灾难恢复计划时，诺大的房间中仅有寥寥几人举手。这足以说明大家都应该好好阅读一下 Gil 的文章。
如果碰巧 Active Directory 不是您的专长，那也不用担心 — 我们还为您准备了更多的内容。Matt Fontaine 将为我们介绍 System Center Mobile Device Manager（如果负责管理组织中的 Windows Mobile 设备，则它是您必备的新技术），Pete Zerger 将带我们了解 System Center Essentials SP1 的新增功能，Jesper Johansson 将告诉我们如何将海森堡不确定性原理应用到 IT 安全领域。“脚本专家”一如既往地陪伴着我们，并继续提供“Exchange 问题与解答”以及更多精彩内容。
最后，我们正在努力建立一个出色的新《TechNet 杂志》网站（网址仍为 technetmagazine.com）。一些我们非常喜爱的作者正在开发“使用方法”屏幕广播 — 它是即将与我们的文章一起在线提供的视频，帮您逐步了解所述内容。我们非常乐于听取您的建议，欢迎告诉我们您最希望在这些屏幕广播中看到哪些主题和技术。同样，请发送电子邮件至 tnmag@microsoft.com。谢了！ —Joshua Hoffman


 读者来信: 读者心声
读者来信
读者心声

Windows 群集
Windows® 计算群集服务器与传统的 Windows 群集有什么不同？
—来自 blogs.technet.com/tnmag

这是个很有典型意义的问题！当讨论 Windows 计算群集服务器 (CCS) 时，我常被问及许多有关可用性群集（故障转移群集）的问题。计算群集与“可用性群集”不同，后者提供的是系统间的服务故障转移。
计算群集使用作业队列或调度程序将任务分配给群集中的不同系统。调度程序（在群集的头节点上运行）接收作业调度程序的请求，并随后将工作分配给群集中的其他计算节点。简单地说，CCS 使您能够在计算机之间划分工作，而可用性群集则致力于提供无中断的服务。
—John Kelbley，高级技术产品经理

Robocopy GUI
感谢你们提供的 Robocopy GUI 专栏（2006 年 11 月，technetmagazine.com/issues/2006/11/UtilitySpotlight）。它使 Robocopy 变得更易于使用，而且选项卡分组使我能够更轻松地理解许多命令行选项。
—Biff M。

非常感谢您的反馈！听到这个工具能助您一臂之力我们深感欣慰。像往常一样，如果您希望《TechNet 杂志》介绍任何其他工具，请告诉我们您的想法！请发送电子邮件至 tntools@microsoft.com 与我们联系。

设备驱动程序
如何列出与特定设备驱动程序相关联的所有特定文件呢？
—T.P.

如果您试图确定支持特定驱动程序安装的所有不同文件的列表，很遗憾，没有完美的解决方案。最好的折衷方法是查看指定驱动程序中包含的 INF 文件——特别是通常标记了 *.copyfiles 的内容，因为它与该驱动程序的即插即用 ID (PnPID) 有关。它将列出驱动程序安装过程中复制的文件。
但是，如果某些驱动程序调用 "CoInstallers" 作为自身的一部分（其中某个 CoInstaller 可能又会实际提取或安装其他文件），则情况会更加复杂。但在大多数情况下，解析 CopyFiles 可以为您提供绝大部分文件——您需要做的就是仔细查看并理解 INF 的内容。
—Wes Mille，专栏作家，桌面文件

Windows 身份验证
我一直在找提供有关 Windows 身份验证方面信息的文章或白皮书。我特别希望学习更多有关在 Windows 2000 Active Directory® 域中无线使用 Internet 身份验证服务 (IAS) 的信息。您可否向我推荐一些包含此类信息的文章？
—Brett M.

此类主题最好的来源是 TechNet 的 IAS 技术中心，网址是：technet.microsoft.com/network/bb643123。它包括有关使用 IAS 进行身份验证的大量文章和白皮书的链接。
另一个讨论此类问题的在线论坛是 Windows 2000 服务器安全新闻组，地址是：microsoft.com/technet/community/newsgroups/dgbrowser/en-us/default.mspx?dg=microsoft.public.win2000.security。

一位充满感激之情的读者
我已经拜读了您在 2007 年 12 月刊中发表的非常有意义的文章“基本计算机取证”（可从 technetmagazine.com/issues/2007/12/Forensics 获得）。首先，我想祝贺您发表了如此重要的信息。还要祝贺合著者 Tom Cloward，他是 Microsoft 的项目经理，为我们展现了他在安全领域的丰富经验。并感谢合著者 Frank Simorjay，Microsoft 的技术项目经理和安全事务专家。您们涉足安全领域的工作，并且同意分享在解决由 Internet 安全攻击导致的安全问题方面的大量知识。这一点非常值得称道。由衷表示感谢。
—Mr. S.

感谢 Mr. S. 的评价。我们也认为这的确是非常重要的主题，并且计划在新一期的《TechNet 杂志》中继续讨论更多这方面的内容，希望能够对您有所帮助。再次表示感谢！


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

分析磁盘空间
FolderSizes
foldersizes.com
如何能够知道究竟是什么占用了客户端计算机的所有空间？您可能正在使用磁盘空间监视器来了解计算机何时接近最大容量，但是确定如何清理磁盘以重新获得正常比率的可用空间有时可能是一项艰巨的任务。FolderSizes 是 Key Metric Software 公司出品的一款实用工具，它可以帮助您确定究竟是什么占用了磁盘空间。
首次启动此应用程序时，它会让您快速了解其用户界面以便于您继续操作（虽然此应用程序非常简单）。要分析某个驱动器或文件夹，只需在分层式 Folder Browser 面板中双击即可。FolderSizes 扫描完目标后，程序会提供一个磁盘使用情况图表和一个文件夹视图，显示出每个父文件夹的内容所占用的空间大小。只需一个单击操作，即可将文件夹的显示格式切换成饼图或条形图，从而更直观地了解磁盘空间的占用位置。从个人角度来讲，我觉得在处理大量同级目录时饼图更合适。
双击某个条形、扇区或文件夹可向下浏览至子文件夹。此导航方式可以迅速方便地放大潜在的问题点，如用户 Sales Presentations 的“隐藏”的 mp3s 目录。或者，如果有个用户是个文档迷，喜欢在计算机中存放各种文档，则他可以通过对上次修改日期进行排序来了解哪些文档已经很久没有访问过了。这可以为该用户提供充分的信息，使他可以决定是将文件归档到 CD 还是永久删除而不会产生任何问题。
另一个很酷的功能是 FolderSizes 可以让您自定义希望在图表中显示的级数。例如，您可以一次性查看驱动器上每个文件夹的图表（按从大到小的顺序），从而找出问题点。找到问题点后，可右键单击访问“command prompt from here”（从此处获得命令提示）和“explore this folder”（浏览此文件夹）操作。这将允许您运行所需的任意其他实用工具或检查程序。
FolderSizes 还包括一个内置的 Report Generator，可以为您提供目标文件系统内容的另一组视图。例如，您可以查找系统中特定类型的最大文件或最先创建的文件；可查找临时文件或重复文件；可查找所有只读文件；还可以确定文件服务器中属于特定所有者的所有文件。诸如此类还有很多。生成报告后，可以筛选视图、打印视图，甚至可以将其导出到 XML、HTML 或 CSV 中。
除此之外，FolderSizes 还提供一种不错的方法来简化备份，确保您只遴选真正需要归档的文件。您还可以使用应用程序的命令行界面来编写脚本及自动化客户端或服务器系统的检查任务。因此，如果希望快速找出究竟是什么占用了服务器或客户端计算机的磁盘空间，可以考虑试一试 FolderSizes。
价格： 起价 50 美元（单用户许可证）。
FolderSizes offers chart visualization of system folders
FolderSizes offers chart visualization of system folders

管理用户帐户
Inactive Users Tracker
netwrix.com/inactive_users_tracker_freeware.html
组织规模越大，就越不容易跟踪非活动用户帐户。并且基于安全方面的考虑，最好能够使用某个进程来轻松地跟踪这些非活动用户帐户并可以禁用或删除它们，从而消除潜在的安全隐患。NetWrix Corporation 的一款免费实用工具 Inactive Users Tracker 可以轻松实现此目的。
此工具可以定期扫描 Active Directory® 域以找出非活动用户，并通过电子邮件将非活动帐户列表发送到您选定的管理电子邮件地址。您可以指定希望管理的域以及哪个帐户有权扫描 Active Directory 来查找非活动帐户。此外，您还可以设置帐户必须处于非活动状态多少天后才“标记”为非活动并将其包括在电子邮件通知中。当然，您也可以计划进程的启动时间。
除此之外，您还可以通过对 SMTP 服务器进行配置来将通知电子邮件传送到管理地址，并可以指定是否希望此实用工具使用名称筛选器来筛选非活动用户帐户（例如，可能所有顾问帐户都设为以“c_”开头）。
同时还有一个商业版本可供选用（其价格视购买产品的客户而定）。此版本可自定义发送给用户的电子邮件消息、支持自动禁用非活动用户帐户，此外还包括技术支持。
价格：免费
Inactive Users Tracker notifies you about inactive users
Inactive Users Tracker notifies you about inactive users

增强电子邮件通信
Exclaimer Mail Utilities 2007
exclaimer.com/MailUtilities2007.aspx
一方面，由于现今世界越来越注重诉讼和法规，因此对您的组织而言，保护其电子邮件通信非常重要。同时，一致的通信和品牌认知有助于组织在其自身以及与其通信的对象之间建立更加融洽的关系。Exclaimer Mail Utilities 2007 是一款设计用于 Exchange Server 2007 部署的实用工具，它在这两方面均可以为您提供帮助。
此应用程序包括以下三个基本功能，可帮助您统一和保护组织的电子邮件通信：免责声明、品牌和签名。此外，它还可以添加有助于防御垃圾邮件和病毒的模块。
在免责声明方面，Exclaimer Mail Utilities 可以在从组织发出的每一封邮件中都添加一则自定义消息（显示在电子邮件正文之前或之后），这不但有助于减少遭到诉讼的风险，而且还增加了对法规（如 HIPAA 法案及 Circular 230）的遵从性。至于品牌，您可以方便地在发送的每封邮件中都添加一个图像和品牌标记，从而确保与客户之间通信的一致性。对于签名，它可以确保对每封邮件都应用自动签名，无论该邮件是从智能设备、Microsoft® Outlook® Web Access 还是标准 Outlook 客户端发出的。该签名可根据您存储在 Active Directory 树中的数据自动生成。可以对此工具进行配置，使其根据多个要素（例如该电子邮件是发送给内部人员还是外部人员、发件人是谁、收件人是谁以及邮件包含的主题是什么等）自定义签名。
Exclaimer Mail Utilities 2007 的价格视用户而定，起价为 245 美元（25 用户），数量增加可享受折扣。此外，反垃圾邮件模块、防病毒模块以及技术支持也会增加基本价格。第一年必须购买支持，起价为 55 美元（25 用户）。由于性能原因，您的计算机需要运行 64 位 Windows Server® 2003 或 Windows Server 2008 才能运行 Mail Utilities。如果您对此工具感到满意，但是仍在运行 Exchange Server 2003，还有另一个版本供您选择。
价格： 起价 245 美元（25 用户）。

书评
《How to Cheat at Securing SQL Server 2005》
syngress.com
作为 IT 专业人员，我们都知道安全是实施基础结构时首先要考虑的因素。想想现在的互连环境以及系统中存有多少敏感信息。对于 SQL Server® 实例而言尤其如此，因为它们可能是敏感信息的集中源。此外，由于现在实施了旨在保护人们隐私的法规（如 Sarbanes-Oxley 和 HIPAA），因此如果发生意外事件并导致此数据被泄露，您可能会面临让人头痛的法律和财务问题。
在考虑保护 SQL Server 2005 实例时，您可以读一读《How to Cheat at Securing SQL Server 2005》一书。书名可能有误导之嫌——本书并不提供“骗术”，只是提供一些锁定 SQL Server 2005 部署的分步参考。具体策略遵循的是“最低访问”这一基本原则，您只被允许使用处理业务所需的最低权限而所有其他权限均被关闭。
在简介之后，本书开始介绍如何使用外围应用配置工具来减少 SQL Server 2005 实例的外围应用。在安装 SQL Server 2005 时，安装程序会向您提示一些非常有用的信息，如默认服务及其默认启动（手动、自动或禁用）选项。在下一章中，您将了解到 SQL Server 角色及其如何能够显著简化管理任务。例如，本书介绍了如何将某个角色与某个 Windows® 组相关联。这样，如果向该组添加新用户，他就会自动被授予对该角色可用资源的访问权限。
在有关身份验证和详细访问的章节中介绍了 Windows 和 SQL Server 的登录及其各自的优缺点。它还介绍了与身份验证相关的 Microsoft 最佳实践。接下来本书又介绍了授权，其中涵盖了一些您的用户可以对实例执行的微调选项（或者从数据库角度说，您的主体可得到的权限）。您还会了解到其他一些功能，如“专用管理员连接”(DAC)，它可以提供仅限管理员使用的本地连接，当某个查询或进程占用了所有资源致使服务器无法响应时，可使用它来连接到实例。这是 SQL Server 2005 之前的版本中所没有的一项有用功能。
在 SQL Server 2005 中，架构和用户被分成了不同的实体。有一章专门介绍了如何通过 T-SQL 和 SQL Server Management Studio 来定义、更新和删除架构。在本节中，您还将了解到一些有用的技巧，例如在 SQL Server 2005 中如果不想创建新架构，则不要使用 sp_adduser 存储过程创建新用户。相反，应该使用 CREATE USER T-SQL 语句来单独创建用户。
当然，密码是保护设置的另一个重要环节，因此在接下来的章节中将详细介绍密码策略以帮助您在帐户间实现统一的安全级别。作者探讨了不同的实施情形，旨在引导您选择最适合您的环境的策略和策略类型。接下来将介绍“数据定义语言”(DDL) 触发器，以及它们如何帮助防范意外的结构更改并提供对服务器登录更改的审核追踪。
在下一章中，您会看到 SQL Server 2005 用于加密数据和架构以保护敏感信息的许多方法。在最后，本书概要介绍了 SQL Reporting Services、SQL Analysis Services 和 SQL Server Integration Services (SSIS)，包括与安全相关的最佳实践指导方针。两个附录也非常有用，它们深入介绍了当组策略和 Active Directory 与 SQL Server 2005 相关时，应如何来保护和实施它们。
我发现有两个贯穿整本书的结构成分特别有用。第一个是每章都包含的“解决方案快速跟踪”部分，它可以为您提供该章节中所述内容的特点、事实以及最佳实践等要点概述。第二个是“常见问题”部分，它可以快速回答有关管理 SQL Server 2005 实例的问题。如果您希望从安全角度出发快速实现 SQL Server 2005 管理，则应考虑将《How to Cheat at Securing SQL Server 2005》添加到您的参考书架中。
价格：电子书为 19.98 美元，纸质书为 49.95 美元

功能强大的屏幕捕获
ScreenHunter 5 Pro
wisdom-soft.com/products/screenhunter_pro.htm
屏幕捕获非常适合于记录分步的用户操作指示、例举应用程序中发生的错误消息或合成一个快速功能演示。当然，Windows 本身已内置了屏幕捕获功能（PrtScr 用于全屏捕获，Alt-PrtScr 仅捕获活动窗口）。但是，操作系统中内置的捕获功能非常有限。如果希望更精细地控制捕获内容及捕获时间，或者希望捕获电影播放的屏幕，则需要使用一些可用来帮助实现这些功能的第三方屏幕捕获实用工具。Wisdom Software 就是其中的一款，它由 ScreenHunter Pro 出品。这款实用工具虽然价格低廉，但却提供了许多非常有用的功能，利用这些功能可以量身定制屏幕捕获内容从而更好地满足您的特定需求。
其用户界面非常简单。您只需使用适当的“From”（来源）和“To”（目标）选项卡选择屏幕捕获来源和存放目标即可。至于捕获内容，应用程序允许捕获可调的或固定的矩形区域、特定的对象或窗口、活动窗口、活动窗口的特定部分、整个屏幕、DirectX® 或屏幕保护程序源、电影播放画面甚至更复杂的形状（定义的徒手画、椭圆或多边形区域）。您还可以同时捕获多个窗口对象或消息框（非常适合于仅捕获活动应用程序及其对话框或其他窗口界面）。随后可将屏幕捕获转储到剪贴板、指定的查看器或编辑器、打印机或文件。甚至可以选择将其发送到某个电子邮件地址。
捕获的图像可保存为各种图像质量的 BMP、PNG、JPEG 或 TIFF 文件。此外，可以使应用程序将捕获的内容自动缩放到特定大小、添加边框或在捕获内容上添加水印，从而减少对图像执行后期处理时所需的工作量。您甚至可以将应用程序设置为经过指定时间间隔后自动捕获屏幕，从而有效地记录计算机中的活动。
另一个非常出色的功能是 ScreenHunter Pro 支持自动滚动功能，利用这一功能可以捕获一些特殊的内容，例如页面可视区域扩展到屏幕可视区域以外的一个很长的 Web 页面。与许多 IT 专业人员一样，我拥有多个监视器，因此我喜欢多监视器捕获支持功能，这样就可以通过一个捕获操作获取屏幕上的所有信息。
此实用工具还包括一个内置的图像编辑器，您在同一个应用程序环境中就可以量身定制图像。如果不需要某些更高级的功能（如自动发送电子邮件、定时捕获、水印以及多监视器捕获），则可以使用更为便宜的 ScreenHunter Plus 版本。此外还提供免费的精简版。
价格： ScreenHunter Pro 为 29.95 美元
ScreenHunter Pro lets you specify when and what you capture
ScreenHunter Pro lets you specify when and what you capture

Greg Steen


 Exchange 问题与解答: Exchange 2007 SP1 部署
Exchange 问题与解答
Exchange 2007 SP1 部署
Nino Bilic

问：我想知道 Exchange Server 2007 SP1 是否只提供 64 位版本？如果它确实还提供 32 位版本，那该版本是否支持生产环境？
答：在这方面，Exchange 2007 最初版本 (RTM) 和 SP1 版本之间没有任何区别。SP1 提供 32 位和 64 位两种版本。但是，需要记住的是，与 RTM 版本一样，生产环境中只有 64 位版本支持已安装的服务器角色。您可以使用 32 位 SP1 版本运行多种 /prepare 安装开关并管理 64 位服务器，这与 RTM 版本一样。

问：我是否需要先完全安装 Exchange 2007 的 RTM 版本，然后才能应用 SP1 得到 SP1 服务器？
答：这正是 Exchange 2007 SP1 与 Exchange 以前版本的服务包相比截然不同的特性。SP1 程序包实际上是内置了 SP1 的 RTM，这表示您不必使用 RTM DVD 安装新的 Exchange 2007 SP1。
因此，要安装新的 Exchange 2007 SP1 服务器，只需部署 SP1 程序包即可。举例来说，即使是将第一个 Exchange 2007 加入到 Exchange Server 2003 组织中，您还是能够立即从 SP1 起步。
问：我有一台在 Windows Server® 2003 上运行 Exchange 2007 RTM 的服务器，我现在正准备将 Exchange 2007 SP1 安装到该机器上。因为 Microsoft 说 Windows Server 2008 支持 Exchange 2007 SP1，所以我计划稍后就地升级到 Windows Server 2008。您认为怎样？
答：遗憾地说，这并不是个好主意。安装 Exchange 2007 RTM 或 SP1 的服务器并不支持从 Windows Server 2003 就地升级到 Windows Server 2008。这其中有很多技术原因，而且您还应该清楚如果执行这样的就地升级，已安装的 Exchange 将停止服务。
有关这方面的更多信息，请参阅“Mission Impossible:In-Place Upgrading Microsoft® Exchange Server 2007 from Windows Server 2003 to Windows Server 2008”（不可完成的任务：将 Microsoft® Exchange Server 2007 从 Windows Server 2003 就地升级到 Windows Server 2008），网址是 msexchangeteam.com/archive/2007/10/04/447188.aspx。

问：我从没有为我的几台实验室服务器输入过产品 ID。因此，当我启动 Exchange 管理控制台时，系统弹出警告说使用时间只剩下“0 天”。我是否能够在不为这些服务器输入产品密钥的情况下升级到 Exchange 2007 SP1？
答：可以。Exchange 2007 SP1 安装（请参见屏幕快照）不会检查已安装服务器的试用期剩余时间。在这种情况下升级不会遇到任何阻碍。

问：我已在邮箱服务器上安装了Exchange 2007 SP1。现在，我希望将客户端访问服务器角色添加到该服务器中。我是否需要使用 Exchange 2007 RTM 或新的 Exchange 2007 SP1 程序包？
答：如果已经应用了 Exchange 2007 SP1，您需要使用 Exchange 2007 SP1 程序包安装其他服务器角色。如前所述，Exchange 2007 SP1 是完整的产品，它包含运行 Exchange 2007 所需的所有文件。一旦成功安装 SP1，您就不再需要 Exchange 2007 RTM 程序包了。
当然，如果在计划升级到 Exchange 2007 SP1 的服务器上存在多个服务器角色，那么应用 SP1 时会自动升级所有已安装的角色。您不能仅将 SP1 应用到相同物理服务器上的部分角色。

问：我的 Exchange 组织有多台 Exchange 2007 服务器，服务器角色分布在其中的几台服务器之内。我应该首先升级哪些服务器角色？
答：建议您首先下载并阅读 Exchange 2007 SP1 发行说明 (go.microsoft.com/fwlink/?LinkId=112364)，其中包含有关对现有安装应用 SP1 方面的重要信息。
为直接回答您的问题，下面是从 SP1 发行说明中摘录的解决您所提问题的方法：

“建议您在升级了运行客户端访问服务器角色、统一消息服务器角色、集线器传输服务器角色或边缘传输服务器角色的服务器之后，升级运行邮箱服务器角色的服务器。如果按此顺序升级服务器，可以避免潜在的服务中断。（以这种顺序升级角色将确保邮箱服务器的“前端”功能能够无中断地与邮箱服务器通信，反之，容易在尝试与发挥主要功能的后端服务器通信时出现故障。）还建议您在升级没有 Internet 连接的站点中的客户端访问服务器之前，先升级面向 Internet 的站点中的客户端访问服务器。
如果您在 Exchange 组织中运行的是边缘传输服务器角色，而且已创建边缘订阅，则参与 EdgeSync 进程的所有传输服务器必须运行相同版本的 Exchange 2007。在参与边缘订阅过程的任何传输服务器首次升级到 Exchange 2007 SP1 的 15 天内，必须在边缘传输服务器已进行订阅的 Active Directory® 站点中升级所有订阅的边缘传输服务器以及所有集线器传输服务器

问：我已经在 Exchange 2007 RTM 服务器上安装了 ForefrontTM Security for Exchange Server。在我升级到 Exchange 2007 SP1 之前，是否必须完成某些特别的工作？
答：Forefront Security for Exchange Server 的 RTM 版本与 Exchange 2007 SP1 不兼容。您需要在升级之前先删除 Forefront Security for Exchange Server，或将其升级到更新的版本。SP1 发行说明将为您提供更多详细信息。
并且，随便提一句，Exchange 2007 SP1 安装程序包含一项新的先决性条件检查，如果您试图在这种情况下升级，该检查将向您发出警告信息。

问：我已在 Exchange 2007 RTM 上安装了 RTM 后期 Rollup Update (RU)。在应用 Exchange 2007 SP1 之前，我是否必须先卸载 RU？
答：您不必在安装 Exchange 2007 SP1 之前手动卸载任何 RU。在将 SP1 应用到计算机之前，Exchange 2007 SP1 安装程序会先删除任何需要卸载的更新。

Nino Bilic 是 Exchange Server 的可支持性项目经理。他在识别和防范大规模黑客活动方面具有很深的造诣。


 实用程序特别推荐: SharePoint 容量规划
实用程序特别推荐
SharePoint 容量规划
Peter Skjøtt Larsen and Satish Mathew

规划大型 Microsoft® Windows® SharePoint® Services (WSS) 和 Microsoft Office SharePoint Server (MOSS) 的安装是一件非常复杂的工作。在确定最经济高效的拓扑、硬件和带宽要求时需要考虑很多因素。根据系统不同的用途，还需要考虑大量配置选项。通常，管理员和规划人员只能通过极有限的经验法则来帮助确定系统规模。
值得庆幸的是，Microsoft 发布了第二代 Microsoft System Center Capacity Planner (SCCP) 2007，它是一种能将各种应用程序模型与模拟器组合的通用工具，通过模拟器可以估计这些应用程序在特定部署环境中的行为。此次发布引入了新的 SharePoint 容量规划工具，它将 WSS 3.0 和 MOSS 2007 的两种新模型加入了该引擎。
SharePoint 容量规划工具和 SCCP 2007 可以从 Microsoft 下载中心免费下载，网址为 microsoft.com/systemcenter/sccp/default.mspx。
SharePoint 容量规划工具通过归纳您对预期使用和运行条件的回答收集组织的需求。为生成最初的设计，向导会提示您输入与结构和 SharePoint 项目需求相关的信息，包括用户数量和类型（身份验证用户或匿名用户）、网络参数、硬件配置、使用模式（例如发布或协作）、存储需求，以及索引和查询需求。
Results of a simulation in the SharePoint Capacity Planning Tool
Results of a simulation in the SharePoint Capacity Planning Tool
然后，该工具将使用特定于您自身安装的名称生成建议的基本拓扑。您可以根据建议的拓扑运行负载和使用模拟，以便查看在各种不同的条件下建议的安装如何工作。
您还可以使用模型编辑器修改最初的拓扑，然后还可以运行“假设分析”方案模拟使用量增长、企业分支机构扩大、添加新硬件和增加带宽带来的影响。如屏幕快照所示，模拟过程生成估计的服务器负载和用户体验报告，使您可以根据参数（例如成本、性能和可用硬件）优化配置。您可以将详细或摘要报告导出为 Excel® 电子表格，并将拓扑图导出为 Visio® 文件。
SharePoint 容量规划工具使您能够测试各种环境以获得合理的初始配置，帮您减轻新部署的负担。因为您还可以通过该工具建模现有的拓扑并运行各种“假设分析”方案，所以它对探索现有部署的可能更改也非常有用。

Peter Skjøtt Larsen 是 Microsoft Solution Accelerator 团队的高级产品经理。他已在 Microsoft 工作了四年，主要从事 UNIX 迁移和通信与协作方面的工作。
Satish Mathew 是 Microsoft Solution Accelerator 团队的项目经理。他已在 Microsoft 工作了将近五年，在转入目前所在的团队之前，他一直在 Windows PowerShell 团队工作。


 深入剖析 Sharepoint: 构建 SharePoint 基础结构
深入剖析 Sharepoint
构建 SharePoint 基础结构
Pav Cherny
下载本文中所用的代码: SharePoint2008_05.exe (412KB)

如同电子邮件消息传递改变了业务通信一样，基于 Web 的协作正在改变着人们协同工作和共享信息的方式。作为一个不错的示例，让我们来看一看 SharePoint 技术所提供的功能。通过使用 Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server
(MOSS) 2007，可创建团队网站、门户网站、Web 内容管理解决方案、文档库和搜索中心，更不用说 2007 Microsoft® Office 系统集成、基于 XML 的表单、工作流、移动性支持等。
然而，SharePoint ® 入门却并非易事。术语可能会令人困惑。系统体系结构可能非常复杂，而且 SharePoint 要求您处理多个组件，包括 IIS、Microsoft .NET Framework、SQL Server® 和其他可能的技术（如商业智能、InfoPath® 窗体服务、权限管理服务 (RMS)、Exchange Server 以及 ForefrontTM Security）。
您可能很快就会在集成和自定义中转昏了头，它们为您提供了多种用于创建 SharePoint 解决方案的方法（无论是通过内置用户界面还是以编程方式）。此外，如果 SharePoint 应用程序不起作用，其故障排除操作可能会相当复杂。通常，必须具备应用程序开发人员的思维才能理解所涉及的组件以及它们的交互方式。由于存在这些挑战，您应从何处着手才能构建一个稳定、可扩展且易于管理的 SharePoint 基础结构呢？
在本专栏中，我将首先讨论有关体系结构的基础知识，然后再深入探讨 WSS 的部署，包括非常基本的品牌标记自定义功能。通过使用 WSS 3.0 的“自助站点管理”功能，您将了解到如何在维持对 SharePoint 基础结构的集中管理控制的同时，将创建和管理 SharePoint 站点的权限委派给单个用户。
通过首先了解 SharePoint 体系结构，您将更容易理解实施灵活且可扩展的基础结构所必需的部署和配置步骤。因此，让我们先大致浏览一下依赖关系，然后直奔主题介绍 WSS 3.0 的部署。如需详细的部署说明，请参考附属材料。可在《TechNet 杂志》网站的下载区找到此材料，网址为 technetmagazine.com。

SharePoint 体系结构
在使用 SharePoint 时，最好是站在系统架构师的角度来考虑此技术。不必了解所有的细枝末节，但是如果熟悉 SharePoint 体系结构提供的总体依赖关系，您将可以更快地得出解决方案，因为您可以预见到需要配置哪些组件以及其配置原因。
SharePoint 是一种用于配置 Web 应用程序和站点的技术。它是基于 IIS 的网站解决方案，通过 ASP.NET 与 IIS 相集成，并依靠后端的 SQL Server 数据库来存储配置数据和内容。简而言之，SharePoint 组合了三种不同的体系结构（IIS、.NET 和 SQL Server）作为其核心，如图 1 所示。
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
Figure 1 WSS 3.0 architecture based on IIS 6.0 and ASP.NET 3.0
千万别被这张图吓倒了。由于组件数量很大，所以一开始此体系结构看上去可能非常吓人。但经过系统地研究之后，您会发现所有这些组件都可嵌入到一个逻辑框架当中，这样您就可深入了解组件间的依赖关系。
如图所示，SharePoint 依靠 IIS 和 ASP.NET 处理 HTTP 请求和响应。标准 IIS 组件（如 HTTP 内核模式驱动程序 (http.sys) 和工作进程 (w3wp.exe)）首先执行请求的初始排队和路由操作，直至请求到达 ASP.NET ISAPI 筛选器 (aspnet_isapi.dll)。在安装 .NET Framework 时，安装例程将在 IIS 元数据库 (C:\Windows\System32\Inetsrv\metabase.xml) 中注册 aspnet_isapi.dll，如下所示：
InProcessIsapiApps="C:\WINDOWS\system32\inetsrv\httpext.dll
C:\WINDOWS\system32\inetsrv\httpodbc.dll
C:\WINDOWS\system32\inetsrv\ssinc.dll
C:\WINDOWS\system32\msw3prt.dll
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll"
一旦 IIS 加载 ASP.NET ISAPI 筛选器，网站的所有传入请求就可传到 ASP.NET，这一点非常重要，因为 SharePoint 最终必须通过 ASP.NET 接收这些请求。为此，SharePoint 通过添加一个通配符应用程序映射（无论文件扩展名是什么，它都会将所有传入请求路由到 ASP.NET ISAPI 筛选器）扩展选定网站的配置。
在使用“Basic”（基本）安装选项安装 WSS 3.0 之后，就可在 IIS 管理器中看到此过程。WSS 安装例程停用了服务器上现有的默认 IIS 网站，并在端口 80 上创建定义了 ASP.NET 通配符应用程序映射的一个新默认网站（如图 2 所示）。
Figure 2 Wildcard application map for ASP.NET ISAPI filter
Figure 2 Wildcard application map for ASP.NET ISAPI filter
为使 ASP.NET 能够依次将请求传到 SharePoint，SharePoint 还必须通过一个自定义 HttpApplication 对象扩展 HTTP 请求管道，该对象可通过 Microsoft.SharePoint 程序集中名为 SPHttpApplication 的一个类来实现。SharePoint 在 ASP.NET 应用程序文件 (global.asax)（位于 SharePoint 扩展网站的根文件夹的文件系统中）中定义该自定义应用程序对象。以下代码列出了 global.asax 文件的内容：
<%@ Assembly Name="Microsoft.SharePoint"%>
<%@ Application Language="C#" Inherits="Microsoft.SharePoint.ApplicationRuntime.SPHttpApplication" %>
ASP.NET 动态解析并编译该文件以实例化 SharePoint 应用程序对象。
对于收到的每个请求，ASP.NET 都会触发 Web 应用程序可处理的一系列事件（如 BeginRequest、AuthenticateRequest、ProcessRequest 和 EndRequest）。事件处理的详细信息超出了部署和管理 SharePoint 的范围，但必须了解以下信息：除了在 global.asax 中指定的 SPHttpApplication 以外，SharePoint 还实现了在站点的 web.config 文件中定义的自定义 HTTP 处理程序和模块。例如，SharePoint 使用基于 SPRequestModule 类的 HTTP 模块，并将其注册为在标准 ASP.NET 模块之前的首个 HTTP 模块。SPRequestModule 会初始化 SharePoint 运行时环境，如通过使用 ASP.NET 注册 SPVirtualPathProvider 组件。尽管 SPRequestModule 是供 SharePoint 内部使用，但是 SharePoint 解决方案开发人员可修改 web.config 文件来注册其他组件（如自定义 HTTP 处理程序和模块）。通过自定义 HTTP 模块和标准 HTTP 模块，SharePoint 可在严格控制到 SharePoint 应用程序的所有请求的同时，利用 ASP.NET 的优势。
请注意，在使用 SharePoint 3.0 中心管理网站创建 Web 应用程序时，WSS 将把 ASP.NET 通配符应用程序映射添加到选定的 IIS 网站，并在该网站的根文件夹中创建 global.asax 和 web.config 文件。每个 Web 应用程序都使用自己的一组顶层 global.asax 和 web.config 文件。
为处理请求并将有意义的信息返回给浏览器，WSS 3.0 和 MOSS 2007 依赖于标准的 ASP.NET 页面分析程序，该程序会编译请求的 ASP.NET 页面或在无编译模式下处理它们。但是，SharePoint 传给 ASP.NET 分析程序的 ASP.NET 页面并不一定位于它们应该存在的地方。例如，在 SharePoin 扩展网站（如 SharePoint 3.0 中心管理网站）的根文件夹中找不到 default.aspx 文件，但在显示该网站的主页时，您仍会打开 default.aspx。实际上是 SPVirtualPathProvider 组件虚拟化了环境，即从本地文件系统或 SQL Server 内容数据库加载页面内容，然后将其作为虚拟文件传给 ASP.NET 页面分析程序。对于中心管理网站来说，SharePoint 从 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\SiteTemplates\CentralAdmin 文件夹加载 default.aspx 文件。
主页（以及大部分其他 SharePoint 站点页面）会链接到用于实现菜单和导航控件的常规布局的 ASP.NET 母版页 (default.master)。Default.master 位于 C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Template\Global 文件夹中，它包含用于未来内容页面的已命名占位符（这些内容页面也可以位于本地文件系统或 SQL Server 内容数据库中）。重点在于在 Web 浏览器中打开 SharePoint 站点时，实际看到的信息是来自并不一定位于本地 Web 服务器上并且按照母版页中定义的布局来排列的一组内容页面。
通常，未修改页面（即 SharePoint 术语中的未自定义页面）作为页面模板存储在每个 SharePoint 服务器的本地文件系统中，而自定义页面将被写入到内容数据库中以便 Web 场中的所有 SharePoint 服务器都可以访问相同的一组页面（请参见图 3）。假定 Web 场中所有服务器和站点中的未自定义页面都完全相同。但是，如果在 SharePoint 站点中自定义了内容页面或母版页（如通过使用 Office SharePoint Designer 2007），则 SharePoint 会自动将自定义页面存储在内容数据库中。
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
Figure 3 Uncustomized and customized ASP.NET pages in a SharePoint application
除自定义页面和其他网站内容外，SharePoint 还将配置数据存储在 SQL Server 数据库中。SharePoint 把配置数据与内容分开保存，其原因是配置数据本质上是全局的，而内容则特定于每个单独的 Web 应用程序和站点集合。因此，一个 Web 场只能有一个配置数据库，但它可以有多个内容数据库。
Web 场中的所有 WSS 服务器使用相同的配置数据库来共享 Web 场中每个 SharePoint 扩展 IIS 网站的元数据、配置设置和相关信息。而另一方面，各个 Web 应用程序可与一个或多个内容数据库相关联（尽管每个内容数据库仅可与一个 Web 应用程序相关联）。
IIS 网站、Web 应用程序、站点集合、站点和内容数据库之间的关系可能有点混乱。在 SharePoint 术语中，术语 Web 应用程序是指 SharePoint 扩展 IIS 网站。Web 应用程序可包括多个站点集合，而每个站点集合又可以包括共享相同配置设置的顶层站点和子层站点。
此外，创建多个站点集合还可将站点集合管理权限委派给不同的用户和组。单个站点集合不能跨越多个内容数据库，但 Web 应用程序可将多个内容数据库用于多个站点集合，从而增加可伸缩性并缓解在其他 SharePoint 站点上产生大量数据库活动的大型站点的性能影响。但是，将每个 SharePoint 站点放在自己的站点集合中并不是个好主意，因为这种部署方式限制了跨站点的能力。
WSS 3.0 不支持在多个站点集合之间进行内容搜索。此类搜索需要用到 MOSS 2007 或 Microsoft Search Server 2008。例如，可为 http://contoso 创建一个 Web 应用程序和顶层站点，并且站点集合管理员可使用 SharePoint 用户界面创建子层站点（如 http://contoso/info 和 http://contoso/events）。由于属于相同的站点集合，所有这些站点都存储在相同的内容数据库中。
作为场管理员，还可使用托管路径（如 /sites），然后在 SharePoint 3.0 管理中心中定义其他站点集合（如 http://contoso/sites/IT 和 http://contoso/sites/HR）。这三个站点集合（http://contoso、http://contoso/sites/IT 和 http://contoso/sites/HR）可拥有不同的站点集合管理员、配置设置和内容数据库，但它们仍然都是通过相同的 IIS 网站 (http://contoso) 进行访问，并且使用相同的 Web 应用程序的应用程序池标识。
当然，还有许多更为详细的信息，但 IIS、ASP.NET 和 SQL Server 之间的关系对于理解和熟悉 SharePoint 来说特别重要。如果有兴趣阅读有关 SharePoint 体系结构的更多信息，建议您阅读一下《MSDN® 杂志》中 Ted Pattison 的文章“探寻 SharePoint Services 中为开发人员提供的重大改进功能”，网址为 msdn.microsoft.com/msdnmag/issues/06/07/WSS30Preview。

SharePoint 基础结构要素
现在，让我们把目光从简要的体系结构讨论转向灵活的 SharePoint 基础结构。正如您肯定已注意到的，我们需要 Windows Server®、IIS、.NET Framework 3.0 （用于 ASP.NET 和 Windows® Workflow Foundation）、WSS 3.0 或 MOSS 2007 以及 SQL Server。尽管您可能期待着 Windows Server 2008 中的 IIS 7.0，但在这里我们还是使用 Windows Server 2003 中的 IIS 6.0，因为在撰写本文时，IIS 6.0 仍是最常部署的版本。我们仍将使用 WSS 3.0，因为对于最初的 SharePoint 试验来说，不需要使用 MOSS 2007 特有的功能。
为简便起见，可在一台计算机上安装 WSS 3.0 以及所有必需组件（按 WSS 3.0 on a single computer.pdf 所述执行安装，可从本专栏的附属材料中获得该文件），它足以满足实验室服务器或小型工作组环境的要求。但是，如果打算把重点放在 SharePoint 基础结构的灵活性上，则不应该在生产环境中建立一个独立的部署。出于可用性和未来可伸缩性方面的原因，最好首先建立一个多层基础结构，并且根据需要添加更多服务器。
如果您需要直观且灵活的系统配置，那我推荐图 4 中所示的 SharePoint 基础结构。它包括由两台 SharePoint 服务器组成的一个 Web 场以及一台单独运行 SQL Server 的计算机。该配置消除了 Web 服务器上的数据库处理开销、增加了可用性、可伸缩性并使系统更易于维护。请注意，Active Directory® 为必需项，因为这是 Web 场部署中的 WSS 3.0 的软件要求。如需分步部署说明，请参阅附属材料中的 Basic SharePoint Infrastructure.pdf 文件。
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
Figure 4 Basic SharePoint infrastructure that can accommodate future growth
在此布局方式中，用于部署 SharePoint 的域帐户需要具有 Web 服务器的本地管理员权限。此外，还必需将此帐户添加到 SQL Server 角色 dbcreator 和 securityadmin 中以及 SQL Server 2005 中主数据库的数据库角色 db_owner 中（如 Basic SharePoint Infrastructure.pdf 所示）。然后，可在 WSS 3.0 安装过程中使用“SharePoint Products and Technologies Configuration Wizard”（SharePoint 产品和技术配置向导）为 Web 服务器场创建必需的配置数据库并为 SharePoint 3.0 中心管理站点创建一个内容数据库。否则，SQL Server 管理员必须为您配置这些数据库，并将 WSS 系统帐户添加到 db_owner 角色中。
请务必记住，用于安装 SharePoint 的用户帐户并非 SharePoint 用于访问配置数据库或中心管理站点的内容数据库的帐户。SharePoint 使用的是配置为 SharePoint 3.0 中心管理站点的应用程序池标识的系统帐户。
“SharePoint Products and Technologies Configuration Wizard”（SharePoint 产品和技术配置向导）将提示您输入帐户信息。使用专用域用户帐户（如 CONTOSO\WssConfigAdmin）是个不错的主意。我通常的做法是针对之后创建的每个其他 Web 应用程序使用单独的专用用户帐户。针对每个 Web 应用程序使用单独的应用程序池有助于确保进程隔离，并且针对每个应用程序池使用不同的用户帐户有助于保持安全隔离。应当注意的是，尽管这只是一种方法，但是应根据自身的环境和业务需求评估可管理性和可能的性能影响。
域管理员还需为您创建的另一个重要的系统帐户是搜索服务帐户。可使用 Central Administration 帐户，但为确保安全，最好使用没有管理权限且无法修改任何内容的一个专用搜索帐户（如 CONTOSO\WssSearch）。对内容数据库的写入权限并不是必要的，因为搜索服务仅出于索引目的而爬网内容并将搜索数据存到一个单独的数据库中。
在服务器场中创建 Web 应用程序时，可将该内容数据库与搜索服务器相关联，这样就暗中向 Web 应用程序的“完全读取”策略添加了相应的搜索服务帐户。搜索服务器是运行 Windows SharePoint Services Search 服务的 SharePoint 服务器。如果遵循 Basic SharePoint Infrastructure.pdf 文件中的分布说明执行操作，则已将两台 Web 服务器配置为搜索服务器，这样就可分摊对多个内容数据库执行爬网和索引的负载。但是，也可在 Web 场中配置一个专用搜索服务器，除网络负载平衡和客户端连接之外，这样还可使客户端连接不受爬网活动的影响。

自助站点管理
当基本的 SharePoint 基础结构部署到位之后，就可将站点集合和站点的管理权限委派给单个部门和用户，同时仍可集中管理控制 Active Directory、Web 服务器场或 SQL Server 数据库。作为场管理员，您可以与 Active Directory 和 SQL Server 管理员协同工作来为 Web 应用程序配置应用程序池帐户和内容数据库。然后，在这些 Web 应用程序中创建站点集合，并将创建子层站点的权限委派给站点集合管理员。这样，各部门内部的站点集合管理员就可以自行管理其 SharePoint 资源，从而尽可能地减少 IT 部门的工作（如图 5 所示）。
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
Figure 5 Decentralized site administration in a centralized SharePoint infrastructure
还可授予用户在托管路径（例如，/sites 路径或在 SharePoint 3.0 管理中心中创建的包含通配符的其他托管路径）下创建站点集合的权限。如果在 Web 应用程序中启用“自助站点管理”功能，则用户可以在 SharePoint 用户界面中创建自己的站点集合并管理站点组和权限。与子层站点不同，站点集合不会继承父站点的权限。
“自助站点管理”并不适用于所有 SharePoint 环境，并且默认情况下为禁用状态。如果启用该功能，您的内容数据库中可能出现大量不常用的站点集合。但是，这项功能非常生动地展示了 SharePoint 管理的灵活性，因此建议您在试验部署中试用一下此功能。（此外，SharePoint 中还包含用于通知用户和/或管理员出现非活动站点的选项，这样就可在必要时删除这些站点。）必须为 Web 应用程序显式启用“自助站点管理”功能（如附属材料中的 Enabling Self-Service Site Management.pdf 文件所示）。

SharePoint 自定义和添加品牌标记
Sharepoint 资源
  • Windows SharePoint Services 技术中心
  • Windows SharePoint Services 开发人员中心
  • Microsoft SharePoint 产品和技术团队博客
  • 逻辑体系结构组件
  • 设计服务器场和拓扑

此时，希望在 SharePoint 用户界面中包含公司的徽标、名称和颜色是再自然不过的需要了。但请注意，您将把 SharePoint 项目提到 ASP.NET 开发人员级别。至少需要一个开发系统（如安装了 Microsoft Office SharePoint Designer 2007 的一个独立 WSS 3.0 服务器）（请参阅附属材料中的 SharePoint Designer Installation.pdf），这样才可在不影响生产环境的情况下创建和测试自定义设置。还应访问 Windows SharePoint Services 开发人员中心（网址是 msdn2.microsoft.com/sharepoint）以深入了解 SharePoint 所提供的大量自定义选项。
虽然 SharePoint 开发超出了本专栏的讨论范围，但我还是要指出以下需要注意的一些方面。SharePoint 将自定义页面保存在相应站点集合的内容数据库中。换句话说，SharePoint 站点中应用到站点页面、应用程序页面、母版页、样式表等的所有自定义都仅在站点集合或站点级别应用。这一点对于希望使用 SharePoint Designer 2007 来调整站点外观的各个站点集合管理员来说非常棒；但对于希望在 Web 场中的所有 Web 应用程序、站点集合和站点间强制实施公司标识的场管理员来说，却不太妙。
可基于标准 SharePoint 主题或站点定义的副本来创建自定义站点主题或自定义站点定义。也可创建自定义母版页，并将它们添加到母板页库中。但是，如果启用了“自助站点管理”功能，则这些选项都无法强制实施全局品牌标记，因为拥有创建站点集合或站点权限的用户仍然可以选择不显示公司标识的标准站点模板。
全局品牌标记要求替换掉默认 SharePoint 组件，这样才能改用自定义组件。开发人员会尽力在不修改原始文件的情况下实现此目的。一种方法是更改 IIS 管理器中虚拟目录的配置，并将其指向包含自定义文件的新文件夹。另一种方法是使用自定义 HTTP 模块或 ISAPI 筛选器，它们会重写 URL 以将特定默认页面的请求重定向到自定义版本的页面。

结束语
在本文中，我重点介绍了使用 WSS 3.0 来建立 SharePoint 基础结构的要点。我并未介绍其他功能（如工作流、调查、消息传递集成和防病毒），也没有介绍 MOSS 2007 特有的功能（如门户、站点目录和业务数据目录）。我还简要介绍了 SharePoint 中可能出现的站点管理和公司品牌标记自定义设置。可在 Visual Studio® 中编写自定义应用程序来使用 WSS 3.0 执行更多的自定义功能。
如添加更多的 Web 服务器或数据库服务器，则该基础结构足以适应未来的增长需求。通过试验性实施几个自定义功能，用户将可以创建单个站点并大致熟悉 SharePoint。这样就建立了用户站点、硬件和软件的核心组件，它们非常灵活足以适应变化并且可用作成熟生产实施的基础。

Pav Cherny 是一位 IT 专家和撰稿人，擅长协作和统一通信方面的 Microsoft 技术。他的出版物包括着重介绍 IT 操作和系统管理的白皮书、产品手册以及书籍。Pav 是 Biblioso Corporation 的总裁。


 Windows PowerShell: 自动化目录管理
Windows PowerShell
自动化目录管理
Don Jones

第一版 Windows PowerShell 最遗憾的事情之一是其时间安排。Windows PowerShell 团队是在一定的压力之下推出此产品的（需发布一个名为 Exchange Server 2007 的小产品并且这取决于 Windows PowerShell），而 Active
Directory 团队的时间却较宽裕（另一个名为 Windows Server® 2008 的小产品也在开发中）。因此，Windows PowerShell 所提供的高级 Active Directory® 管理功能较少。
清楚点讲，Windows PowerShell® 并非完全缺少 Active Directory 功能。实际上，Windows PowerShell 团队在最后一小时仍在顽强拼搏，实现了对 Active Directory 服务接口 (ADSI)（VBScript 用户已非常熟悉的一项易于进行脚本编写的技术）的有效支持。

ADSI 方法
ADSI 的工作方式类似于 Windows® 管理规范 (WMI)。您发出一个使用特殊语法编写的查询。该查询将被传输到远程计算机（如域控制器），然后执行它。查询结果为一个 Active Directory 对象或对象集合（如一个用户或一个用户组），并且您将获得该对象（之后可以使用）的引用。 您可以修改对象的属性或执行方法以保存更改、创建新对象、删除对象等等。例如，要创建用户，可查询希望用户所在的组织单元 (OU) 或容器。返回的对象具有一个 Create 方法，可使用此方法来创建用户。
从某个甚为基本的层面来言，在 Windows PowerShell 中使用 ADSI 简单且直接。例如，以下命令将检索某个用户并显示他的 Company 属性：
$user = [ADSI]"LDAP://cn=Ringo,ou=Singers,dc=company,dc=pri"
$user.Get("Company")
您可以通过管道将用户传送到 Get-Member 以查看其属性和方法。遗憾的是，Windows PowerShell 1.0 在实现这些目录对象方面实际并未全力以赴。如图 1 所示，外壳不会枚举对象的目录属性，也不会显示对象的方法（如我使用的 Get 方法）。
Figure 1 Piping the user to Get-Member to see its properties
Figure 1 Piping the user to Get-Member to see its properties
在 Windows PowerShell 2.0 社区技术预览版 (CTP) 中，此支持有所改善，但仅是在一定程度上的改善。关键问题在于底层 Microsoft® .NET Framework 使管理员无法轻松地看到他们所希望的内容—毕竟，Framework 最初是为开发人员而设计的。另一个问题是 Windows PowerShell 团队只能做到这些，更棒的 Active Directory 支持需要那些极其精通目录的人员来完成。换句话说，即 Active Directory 团队。我相信很快就会实现—毕竟，Windows PowerShell 尚处于早期阶段。但同时又该如何做呢？
您可能还记得，我在本专栏的 2007 年 6 月刊 (technetmagazine.com/issues/2007/06/PowerShell) 中介绍过使用 Windows PowerShell 中的 ADSI 技术。如果需要有关该“本机”技术的更多详细信息，建议您返回去阅读该专栏。在本月的内容中，我将介绍几种其他方法。

丰富生态系统
Windows PowerShell 架构师 Jeffrey Snover 常常提到有关 Windows PowerShell 的丰富生态系统。它的含义就是团队全力以赴确保 Microsoft 中的每个人（不仅仅是程序员）均可扩展 Windows PowerShell 的功能。众多公司均已通过创建本机 Windows PowerShell cmdlet（允许您通过命令行来管理其产品）来实现这一目的—VMWare、IBM、Citrix 和 Foundry 仅是迄今为止的几家大公司。
我最喜欢的该丰富生态系统的示例之一来自 Quest software。该公司提供了一组设计用于 Active Directory 管理、免费且非商业性的 cmdlet。您可从 quest.com/powershell 下载它们。他们还提供了 PowerGUI (powergui.org)，该免费且非商业性的图形化 UI 构建在 Windows PowerShell 的基础之上，适用于那些尚不熟悉命令行的人员。PowerGUI 可使了解如何使用 Active Directory 管理 cmdlet 变得更加轻松。并且，我深信 cmdlet 会对您具有吸引力。这些 cmdlet 使您可轻松地实现史无前例的 Active Directory 管理功能。（如果想要阅读有关 PowerGUI 的更多信息，在 2008 年 1 月刊的工具箱专栏中实际已包括此内容，网址为 technetmagazine.com/issues/2008/01/Toolbox。）

Windows PowerShell 方法
涉及 cmdlet 的所有内容实际均为 Windows PowerShell 所用的处理方法。不必处理传统外观的脚本或奇特的编程对象。以下是我最喜欢的单行式命令。它是一个单独的命令行，即导入一个 CSV 文件并使用其中的信息创建数十甚至数百个新的 Active Directory 用户：
Import-CSV 'C:\provision1.csv' |
ForEach-Object {New-QADUser -organizationalUnit 'company.pri/Singers' -name ($_.'First Name' + '.' + $_.'Last Name')
-samAccountName $_.'Logon name' -city $_.city -title $_.'Job title' -department $_.department}
它确实是个很长的命令，但功能却强大得令人惊讶。首先是 Import-CSV（本机外壳 cmdlet），它只需读取一个 CSV 文件并返回对象。CSV 文件中的每一行都是一个单独的对象，并且 CSV 文件的列将成为对象的属性。在 Provision1.csv 文件中，列名类似于 "Logon Name" 和 "First Name"—这一点非常有趣，因为列名不会直接映射到 Active Directory 用户属性。我发现，文件（比如此文件）通常都是使用听起来熟悉的列名，而非特定于 Active Directory 的名称。毕竟，您可能是从公司人事部的某个人那里收到的此文件，他们不太可能知道 Last Name 在 Active Directory 实际是 sn 属性。
一旦将 CSV 文件中的所有数据导入并转换成对象，这些对象即会被通过管道传送到 ForEach-Object cmdlet，它将针对每个对象执行代码块（刚才的单行式命令的花括号中的内容）。即，对 CSV 文件中的每一行均执行一次该脚本。在该脚本中，特殊的 $_ variable 为当前对象（或 CSV 文件的当前行）的引用。
您可以看到，对于每个对象，我都执行了 New-QADUser cmdlet。它是 Quest 加载项中大约十几个 cmdlet 中的一个。名称 QADUser 值得关注一下。您可能已猜到，Q 代表 Quest。该命名约定旨在避免与 Microsoft Active Directory 团队将来可能推出的终极版 New-ADUser cmdlet 发生冲突。这样，如果同时将这两个 cmdlet 加载到外壳中，您和外壳将能够更加轻松地区分它们。
单行式命令的剩余部分包含 New-QADUser cmdlet 的参数。它首先指定 organizationalUnit，即您希望在其中创建所有新用户的位置。接下来是 name 属性，我已将它设置为 First Name 列的内容、句点以及 Last Name 列的内容。
最后一个有趣的事实是：city 参数实际会实际更改 Active Directory 中的 l 属性（或 Locality-Name）。cmdlet 还接受名为 l 的参数，所实现的功能完全相同。大多数情况下，引用 Active Directory 属性的参数可使用 Active Directory 用户和计算机工具的属性名称或文本标签。

其他 Windows PowerShell 方法
Active Directory 是分层存储，Windows PowerShell 的优势之一是能够将任意分层存储显示为磁盘驱动器，从而使您可以使用一组熟悉的命令（如 Dir、Del、Ren、Copy 等）来管理各种存储。不幸地是，Windows PowerShell 1.0 并未附带用于 Active Directory 的 PSDrive 提供程序，即意味着外壳无法将 Active Directory 本身显示为驱动器。
幸运地是，该丰富生态系统使 PowerShell Community Extensions 重新有了用武之地。它是一个免费的开源加载项，可从 codeplex.com/powershellcx 获取。安装后，PowerShell Community Extensions 使您可轻松将外壳指向域名，从而像驱动器一样管理目录。
CD COMPANY:
CD SINGERS
DIR
这些命令将更改到 COMPANY 域，更改到 Singers OU，然后显示对象列表（如图 2 所示）。可在那里使用 Del 这类命令来删除用户、使用 Md 来创建新 OU 等等。在 Community Extensions PSDrive 提供程序中有许多捕获。它们实质上必须与这样的功能打交道：您期望执行但又因为没有映射为 Active Directory 本身工作的方式而尚不可用。并且，您必须非常细心：更改为域的根目录以及运行 del * -recurse 实际上会删除域中的所有对象（如果您拥有权限）。甚至默认情况下，它不会询问“是否确定”。可以肯定，命令行的功能非常强大，但该功能也会给技术不熟练且不细心的人员带来风险。
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory
Figure 2 Using the PowerShell Community Extensions to direct the shell and manage the directory

立即开始使用外壳
我班上的学生们总是询问现在使用 Windows PowerShell 能做些什么。毕竟，并非每个 Microsoft 产品都为使用 Windows PowerShell 而进行了重新设计，并且您可能还认为 Windows PowerShell 仍在等待一个更好的时机。
事实上，这个时机已经来到。即使 Microsoft 尚未利用 Active Directory 来实现命令行管理，但其他人已在尽力尝试且做得非常不错。可使用 Windows PowerShell 来执行许多管理任务，包括自动化一些最耗时且繁琐的任务，如创建多批新用户。技巧是发现社区正在做的某些事情来使 Windows PowerShell 更加有用。（您可能希望探究 PowerShellCommunity.org，它是 Microsoft 联合赞助且由我帮助管理的一个网站。）将正确的工具加载到 Windows PowerShell 中后，可针对您不想执行的一些最耗时的管理任务编写脚本，并开始成为更有效且高效的管理员。

Don Jones 是《Windows PowerShell:TFM, 2nd Edition》的合著者、《VBScript, WMI, and ADSI Unleashed》的作者以及 PowerShellCommunity.org 的主管。


 您好，脚本专家！: 正则表达式令您耳目一新
您好，脚本专家！
正则表达式令您耳目一新
The Microsoft Scripting Guys
下载本文中所用的代码: HeyScriptingGuy2008_05.exe (150KB)

时间倒回至 2007 年 11 月 ，在去巴塞罗那参加 TechEd IT 论坛的途中，脚本专家们在巴黎逗留了一天。在中转途中的这一天里，我们有幸参观了卢浮宫 — 巴黎闻名于世的艺术博物馆。
那脚本专家们是如何找到卢浮宫的？这很简单：我们走向巴黎圣母院，然后左转。
噢，您想问的是我们在卢浮宫愉快吗？大部分时间都非常愉快。。唯一的问题是，卢浮宫像许多博物馆一样，“只准看，不准摸”。每个人都知道,如果为蒙娜丽莎添上眉毛的话，那她看上去会更漂亮。但不知什么原因，如果您妄图修改任何一幅画，都会让管理卢浮宫的人员气急败坏。
备注：实际上，两位脚本专家都非常喜欢蒙娜丽莎。这也是一个惊喜；尽管有诸多宣传，但我们仍担心看到的可能是一幅仿制品。不过它的确是真品；酷毙了。（尽管它可以添上一些眉毛。）但是，有趣的是我们都对同具盛名的“米洛的维纳斯”感到失望。我们两个都没发现它有什么吸引人的地方，而且撰写本专栏的脚本专家对于“米洛的维纳斯”所传达的总体思想感到非常迷惑。一尊没有手臂的女性雕像？那她该如何拖地或洗盘子呢？！
至可敬的女性读者（假设她们当中还有人没有拂袖而去）：明显这是一个拼写错误。我们其实想说的是：一尊没有手臂的女性雕像？但是，她仍可以完成比任何男人多一倍的工作，而且完全不会出现一丝差错。
脚本专家对于最初的陈述可能产生的误解深感抱歉。
不管怎样，当我们把目光投向卢浮宫的稀释珍宝时，两位脚本专家突然冒出同样的想法：卫生间在哪里？在寻找途中，撰写本专栏的脚本专家又有了一个想法：脚本专家真虚伪。虽然我们对卢浮宫不让我们修改“蒙娜丽莎”感到有点气愤，但我们自己还不是犯过类似的错误。在 2008 年 1 月刊的《TechNet 杂志》中，我们曾写过有关在脚本中使用正则表达式的文章。该文章是“只准看，不准摸”的最佳示例：我们介绍了如何使用正则表达式来找出文本文件中的问题，但我们并未介绍如何解决这些问题。见鬼！
备注：既然脚本专家是在 2007 年 11 月去的卢浮宫，那撰写本专栏的脚本专家是如何突然想起 2008 年 1 月才出版的《TechNet 杂志》中的一篇文章呢？喔；简直是个谜，不是吗？大概与雷蒙德与巴黎之间的时差有关吧。
然而幸运的是，与管理卢浮宫的人有所不同，脚本专家们非常乐意承认自己犯过的错误。我们不应该只向您说明如何使用正则表达式执行搜索；还应说明如何使用正则表达式来执行替换。实际上，我们应向您展示类似图 1 中所示的脚本。
Figure 1 搜索和替换 (Close Figure 1)
      Set objRegEx = _
    CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.IgnoreCase = True
objRegEx.Pattern = "Mona Lisa"

strSearchString = _
    "The Mona Lisa is in the Louvre."
strNewString = _
    objRegEx.Replace(strSearchString, _
                     "La Gioconda")

Wscript.Echo strNewString
现在，实话告诉您，这才是正则表达式最常见的用途：即将字符串值 Mona Lisa 的所有实例替换成 La Gioconda（意大利语“现在，我应该把这些眉毛放在哪里？”）。不可否认，使用 VBScript Replace 函数执行此替换操作要简单得多。但是，不用担心：我们将使用这个简短的脚本来解释如何使用正则表达式执行搜索和替换操作。完成后，我们将介绍可使用这些表达式实现的一些更为奇特的功能。
正如您所看到的那样，这个脚本实际上没有太多的内容。首先创建一个 VBScript.RegExp 对象实例；毫无疑问，该对象是为了使我们能够在 VBScript 脚本中使用正则表达式。创建对象之后，为对象的三个属性赋值：
Global 通过将此属性设为 True，我们告知脚本搜索（并替换）在目标文本中找到的所有 Mona Lisa 实例。如果 Global 属性为 False（默认值），则脚本将仅搜索并替换第一个 Mona Lisa 实例。
IgnoreCase 将 IgnoreCase 设为 True 即告诉脚本搜索不区分大小写，换句话说，我们希望将 mona lisa 和 Mona Lisa 视为相同的字符串。默认情况下，VBScript 执行区分大小写的搜索，即意味着由于大写字母和小写字母的原因，mona lisa 和 Mona Lisa 将被视为完全不同的值。
Pattern Pattern 属性保存我们要搜索的值。在本例中，我们仅搜索一个简单的字符串值：Mona Lisa。
接下来，将要搜索的文本分配给名为 strSearchString 的变量：
strSearchString = "The Mona Lisa is in the Louvre."
然后，调用正则表达式方法 Replace，并为该方法传递两个参数：要搜索的目标文本（变量 strSearchString）和替换文本（La Gioconda）。即以下表达式所实现的功能：
strNewString = objRegEx.Replace(strSearchString, "La Gioconda")
就是这样。修改后的文本将存储在变量 strNewString 中。如果现在回显 strNewString 的值，我们将得到以下结果：
The La Gioconda is in the Louvre.
虽然语法可能有点问题，但可以获得个大致的了解。
正如我们前面提到的，一切都进行得很好很顺利，但太过于复杂了；我们可使用以下几行代码来实现完全相同的功能（实际上，如果希望的话，我们甚至可在一行代码中实现此功能）：
strSearchString = "The Mona Lisa is in the Louvre."
strNewString = Replace(strSearchString, "Mona Lisa", "La Gioconda")
Wscript.Echo strNewString
换句话说，让我们来想一想有没有使用正则表达式可以做到而使用 VBScript 的 Replace 函数无法实现的一些非常有趣的功能。
没人知道吗？好的，这里就有一个。我们脚本专家常常不得不将文本从一种类型的文档复制到另一种类型的文档。有时一切顺利；而有时则不起作用。在不起作用时，我们常常会遇到奇怪的单词间距问题，从而产生类似以下的文本：
Myer Ken, Vice President, Sales and Services
呀；看看这些附加的空格！而且，在这种情况下，Replace 函数的功能有限。为什么呢？好吧，让我们看看包含随机数量附加空格的情况：单词之间可能会有 7 个空格，也可能只有 2 个空格，或者也可能有 6 个空格。这样使得很难使用 Replace 来更正此问题。例如，如果尝试搜索 2 个连续的空格（使用 1 个空格替换这 2 个空格），那我们可以得到以下字符串：
Myer Ken, Vice President, Sales and  Services
这样虽然好一些，但好不了多少。还有一个办法，但它需要我们搜索任意数量的空格（如 39 个）；执行替换；然后从起始数字减去 1；搜索 38 个空格；执行替换；依此类推。此外，可使用简单得多（且更加万无一失）的以下正则表达式脚本：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = " {2,}"

strSearchString = _
"Myer Ken, Vice President, Sales and Services"
strNewString = objRegEx.Replace(strSearchString," ")

Wscript.Echo strNewString
此脚本的关键（同时也是大多数正则表达式的关键）是 Pattern：
objRegEx.Pattern = " {2,}"
即搜索 2 个（或更多）连续的空格。我们如何知道此 Pattern 是搜索 2 个（或更多）空格？好的，在双引号标记内，我们可以看到一个空格，后面跟着这样的结构：{2,}。在正则表达式语法中，它表示搜索至少 2 个连续的前导字符（在本例中，即一个空格）的实例。如果有 3 个、4 个或 937 个连续的空格呢？没问题；也可将它们统统找出来。（如果出于某种原因，我们希望找出至少 2 个但不超过 8 个空格，那我们可使用语法 {2,8}，其中 8 指定最大匹配数。）
换句话说，每当发现 2 个或更多连续的空格，我们都可以找出所有此类连续的空格，并使用 1 个空格来替换它们。它会对我们最初的那个包含附加空格的字符串值造成什么影响呢？结果如下：
Myer Ken, Vice President, Sales and Services
看到了吗？脚本专家确实可让事情变得更好。现在，要是卢浮宫的管理员能给我们一次修改“蒙娜丽莎”的机会该有多好啊。
还一个非常有趣而且并不罕见的情况。假设贵公司有一个电话号码簿，所有电话号码的格式均如下所示：
555-123-4567
但是现在，您的老板决定将所有电话号码更改为以下格式：
(555) 123-4567
您究竟该如何重新设置这些电话号码的格式呢?嗯，如果足够勇敢，我们可能会建议您使用类似如下的脚本：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString, "($1) $2-$3")

Wscript.Echo strNewString
它实现的功能是搜索后跟破折号的 3 个数字 (\d{3})，然后是另外 3 个数字和破折号，接着是 4 个数字。换句话说，我们将搜索以下字符串，其中每个 X 代表从 0 到 9 的一个数字：
XXX-XXX-XXXX
备注：我们如何知道 \d{3} 会告诉脚本搜索 3 个连续的数字？喔，最好回忆一下，我们好像在哪里见过这样的情况。事实上，应该是在电影“达芬奇密码”令人震惊的最后一幕中，或者是在线 MSDN® 的 VBScript 语言参考中（请参阅 go.microsoft.com/fwlink/?LinkID=111387）。
现在，最酷的是我们可以使用正则表达式来搜索任意电话号码。但是，还有一个大问题。毕竟，我们无法使用任意电话号码替换该电话号码，相反，必须使用完全相同的电话号码，只是格式稍有不同。我们究竟该如何做呢？
为什么不试一试使用以下替换文本：
"($1) $2-$3"
$1、$2 和 $3 是正则表达式“反向引用”的示例。反向引用仅指可保存并重用的文本部分。在此特殊脚本中，我们将查找三个“子匹配”：
  • 一组 3 位数字
  • 另一组 3 位数字
  • 一组 4 位数字
自动向每个子匹配分配一个反向引用：第一个子匹配是 $1；第二个是 $2；以此类推，直到 $9。换句话说，在本脚本中，电话号码的三个部分都被自动分配了一个反向引用（如图 2 所示）。
Figure 2 电话号码反向引用 (Close Figure 2)

电话号码部分 | 反向引用
555 | $1
123 | $2
4567 | $3
在替换字符串中，我们使用这些反向引用来确保重用正确的电话号码。我们的替换文本表示：提取第一个反向引用 ($1)，并将其放在括号中。留一个空格，然后插入第二个反向引用 ($2)，后面跟一个破折号。最后，添加第三个反向引用 ($3)。
该脚本将为我们带来什么结果呢？它将提供如下所示的电话号码：
(555) 123-4567
还不错吧，应该说很不错。
还可对此电话号码脚本进行变更。假设您的组织安装了全新的电话系统，并且由于方案变更，所有电话号码现在都将拥有相同的前缀，比如以前以 666、777 或 888 打头的号码现在都将以 333 打头。我们能否同时重新设置电话号码的格式并更改电话号码的前缀？噢，当然可以：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\d{3})-(\d{3})-(\d{4})"

strSearchString = "555-123-4567"
strNewString = objRegEx.Replace _
(strSearchString,"($1) 333-$3")

Wscript.Echo strNewString
看明白这段脚本的含义了吗？我们仅删除了替换文本中旧的前缀（反向引用 $2）；并在其位置换用硬编码且标准的前缀值 333。在运行该修改后的脚本之后，电话号码 555-123-4567 将变成什么样子呢？完成后应类似如下：
(555) 333-4567
反向引用还有另一种常见的用法。假设我们有如下所示的字符串值：
Myer, Ken
有没有方法可以调换值的顺序，并使其像如下方式显示姓名：
Ken Myer
噢，要是连这都做不到，那我们岂不是太蠢了吗？以下正是可以执行此类事情的脚本：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "(\S+), (\S+)"

strSearchString = "Myer, Ken"
strNewString = objRegEx.Replace _

strSearchString,"$2 $1")

Wscript.Echo strNewString
在该特殊脚本中，我们将搜索后接逗号的一个词（即 \S+），然后是一个空格，再接着是另一个词。（在本例中，我们使用 \S+ 来代表一个“词”。）结构 \S+ 表示任意连续的非空格字符组。换句话说，可使用字母、数字、符号；事实上，应该说是除空格、制表符或回车换行符之外的所有字符。正如您所看到的那样，我们希望搜索以下两个子匹配：一个代表姓氏 ($1)，另一个代表名字 ($2)。因此，可通过使用以下语法将用户名显示为“FirstName LastName”格式：
"$2 $1"
逗号去哪里了？噢，很明显，我们不再需要它了，因此只需把它丢掉即可。
备注：非常有趣，由于某些原因，我们也开始考虑使用脚本编辑器。嗯......
在结束今天的讨论之前，让我们再向您展示一个示例。（哦，好的，不是结束今天的讨论，而是在结束本月的讨论之前。）虽然并非绝对的万无一失；但毕竟，我们不希望像本文这样的入门文章太过于复杂。（而正则表达式确实可能演变成非常复杂的内容。）尽管如此，我们还是介绍一下以下脚本，在大多数情况下，此脚本可删除一个值（如 0000.34500044）前面的零：
Set objRegEx = CreateObject("VBScript.RegExp")

objRegEx.Global = True
objRegEx.Pattern = "\b0{1,}\."

strSearchString = _
"The final value was 0000.34500044."
strNewString = objRegEx.Replace _
strSearchString,".")

script.Echo strNewString
与往常一样，该脚本起作用的唯一原因在于模式：“\b0{1,}\.”首先查找词边界 (\b)；从而确保我们不会删除值（如 100.546）中的零。然后，搜索后跟小数点 (\.) 的一个或多个零“0{1,}”。如果找到匹配的模式，我们将使用一个小数点“.”替换所有这些零（和小数点）。如果一些按计划执行，则可将字符串转换成以下格式：
The final value was .34500044.
本月我们要讲的就是这些内容。在结束之前，需要强调的是，甚至在油漆尚未完全干透之前，蒙娜丽莎就已经是相当具有争议性的话题。这位神秘的妇女是谁？她为什么要这样微笑？她为什么没有眉毛？许多艺术历史学家认为蒙娜丽莎甚至并非女性，该画像描绘的其实是莱昂纳多·达芬奇自己。（如果真是这样，那他也太别出心裁了。）更有甚者，Unarius Educational Foundation 宣称该画像实际上是莱昂纳多在“更高世界”中的“灵魂写照”，并且正是该“灵魂写照”指引莱昂纳多成为举世闻名的大画家。非常巧合的是，它与本月的“您好，脚本专家！”撰写方式不符而合。
即表示请将您的所有投诉都发送到 the-twin-soul-of-the-scripting-guy-who-writes-that-column@the-other-microsoft.com。谢谢。

Scripto 博士的脚本谜题
每月一次的挑战！不仅测试您的解谜技能，还测试您的脚本编写技能。

2008 年 5 月：脚本数独
本月，我们将要玩的游戏是数独，但有一点点难度。不是在格子中使用数字 1 至 9，而是使用组成一个 Windows PowerShell™ cmdlet 的字母和符号。在最终解决方案中，其中一行将拼写出这个 cmdlet 的名称。
备注：如果不知道数独的玩法，Internet 上提供此游戏说明的网站多达数千个，我们就不在这里罗嗦啦，抱歉。

Scripto博士的脚本谜题
答案：脚本数独，2008 年 5 月

The Microsoft Scripting Guys 为 Microsoft 工作，也就是受雇于 Microsoft。在玩、教或看棒球（以及各种其他活动）的闲暇之余，他们还负责维护 TechNet 脚本中心。要查看相关信息，请登录 www.scriptingguys.com。


 安全观察: 量子安全性原理
安全观察
量子安全性原理
Jesper M. Johansson

闲聊一些新奇但颇有价值的内容非常有趣。目前为止，我使用海森堡不确定性原理来解释安全性概念已有一段时间。（听过我的独角兽故事的人都知道我喜欢使用其他原理的基本理论来阐述观点。）虽说
有些奇怪，但确实存在与其他科学分支的一些基本概念相关的信息安全推论。
量子物理学中海森堡不确定性原理的基础是图 1 中所示的等式。这一原理指出粒子的位置 (p) 和动量 (x) 存在如下关系：因此如果增加测量位置的精度，就会降低测量动量的精度。两个因子的精度范围为普朗克常数与一个微小系数的乘积。说得更清楚点，该原理说明在同一时刻一个粒子不可能所有因子都达到最好的精度。
Figure 1 Heisenberg Uncertainty Principle
Figure 1 Heisenberg Uncertainty Principle
它与预测不确定范围直接相关，主要预测对粒子多个事实状态的不确定程度。尽管（尚）无法预测范围，但必须认识到：无法使用确定性预测单个计算机网络上的两个变量将如何影响该网络的安全性。
您还必须进行权衡。尽管您在信息安全方面可能并不受普朗克常数的限制，但是仍存在其他限制。必须进行的最显而易见的权衡发生在安全性和可用性（或有效性）之间。.如果暂时不考虑可用性——并且，非常坦白地说，除了面临拒绝服务攻击，我认为安全人员不应对其他可用性方面的问题负责——保护某项内容的最轻松方法是将其关闭。这样，它就不会再遭到黑客攻击。尽管有效性会一落千丈。
同样地，尽管成本显著增多，但与每年向所有员工发送一封电子邮件来提醒他们工作中不要使用即时消息相比，昂贵的预防数据丢失产品产生的效果也要大得多。但是，您的组织愿意支付这笔费用吗？现在来看看量子物理学与安全性在哪里有着超乎想象的紧密联系。

薛定谔猫
在“薛定谔猫”寓言中介绍了一个相关但却不同的量子物理学概念。该故事说到 20 世纪著名的物理学家艾尔文·薛定谔与您可能已听过的另一位 20 世纪著名的物理学家阿尔伯特·爱因斯坦就叠加概念有一场旷日持久的辩论。薛定谔发现存在有两种状态叠加的元素的量子力学领域非常荒谬。
为支持其观点，薛定谔设想了一个试验，即将猫放在一个密封的盒子中。盒子中的另一件东西是毒药容器，通过一些（假想的）亚原子放射性粒子来控制毒药的释放。如果放射性颗粒发生衰变，毒药会被释放出来，并且猫会因此而死。
遵从量子力学规律的亚原子粒子存在于叠加的状态中。由于小猫的状态完全取决于亚原子粒子的状态，因此它也处于这种叠加的状态中。只有通过实际观察猫的状态，我们才能最终确定它具体是死是活。
当然，薛定谔的目的旨在说明：当应用于原子系统时，量子力学的某些规律有多么地荒谬。不过，他的示例经常被认为可能产生门外汉所说的“观察者效应”。尽管观察者效应并不适用于量子力学中所关注的亚原子系统，但它对于我们安全专业人员而言却非常有趣。简而言之，它说明通过观察改变了某个事物。
观察者效应
为更详细地解释它，请看看一杯茶的示例。为了解茶的热度，您将温度计放入杯中。假设温度计放入时茶为 80 摄氏度，而温度计自身为 22 度（室温）。在将温度计放入茶中后，它开始从茶中吸收热量，而茶也释放一些热量来加热温度计。最终，温度计和茶具有相同的温度。然而，该温度既不会是 80 度，也不会是 22 度——它会是两者之间的某个温度。因此，通过测量茶的温度，您改变了它。
观察者效应与信息安全也有关联。每次执行操作来解决某个安全问题时，您可能会由于修改系统而修改了安全状况。我将把它称为安全状况流动性效应 (SPFE)，这是我能想到的最好的术语了。
另一个更简单的示例是服务帐户依赖关系。在有关保护 Windows 网络的第 8 章中 (protectyourwindowsnetwork.com)，我介绍了在系统中安装入侵检测服务 (IDS) 来检测攻击。然而，IDS 将登录到中央系统并且需要很高的权限来访问受监控的系统。大多数情况下，即意味着服务会使用权限很高的服务帐户。
如果任何一个这样的系统遭到入侵，除了能禁用 IDS，攻击者还可访问服务帐户凭据并访问其他所有系统。它是一个很好的 SPFE 例子。如果通过在环境中安装某个功能来提供安全性，即会随之产生新的潜在安全问题。
SPFE 的示例还有许多。Steve Riley 对于 802.1x 在有线网络上存在的某些问题的介绍 (microsoft.com/technet/community/columns/secmgmt/sm0805.mspx) 也是一个不错的示例。许多环境都非常希望使用基于主机的防火墙，这种情况屡见不鲜。但是，如果与 802.1x 结合使用，此组合可能带来之前并不存在的一个特殊攻击。同样，安全技术修改了环境的安全状况并产生了本来并不存在的攻击。
并不是说这些方法天生就没用，应该束之高阁。它的意思是需考虑所执行的操作对总体安全性的影响。如果执行风险管理，您必须考虑您的操作和预防措施在风险方面的实际意义。在缓解问题影响时，不能在实施对策之后就止步不前。实际上，安全是一个过程。需使用深层防御策略，但是需考虑防御将如何改变安全状况以及您将如何应对由于该策略所产生的新威胁。

成熟的强化策略
我研究强化指南已有 10 多年了。回头看看最初的几个指南，我发现它们仅是我和同事认定您应该打开的设置列表。那时，支持安全性的基本策略还不成熟——如果某项功能旨在提供安全性，一般逻辑就是必须将其打开。 而未多加考虑以下事实：即有许多合理的理由可以一开始就将这些功能关闭。
最后，我领悟到要有效地执行强化，必须在强化方面做出全方位思考并且考虑系统将面临的威胁。这一启示塑造出了《Windows 2000 Security Hardening Guide》(go.microsoft.com/fwlink/?LinkID=22380) 中的一系列案例。接下来，自然就是将指南拆分成不同的威胁级别（如《Windows Server 2003 Security Guide》(go.microsoft.com/fwlink/?linkid=14846) 中所示）。
当时，我一直烦恼于即使已打开并使用了所有指导设置，仍可能进入系统。其原因可能是：漏掉了修补程序，因此某些运行方法使我得以进入，或者安装了一些不安全的第三方软件。
事实证明这两个指南中的强化措施在总体安全状态方面的帮助并不太大。它仅归结出几个关键事项。实际上，我曾构建过的最安全系统 (msdn2.microsoft.com/library/aa302370) 仅使用了这些安全指南中的四个或五个调整工具，并且它们中没有一个能真正按预想停止任何攻击。遗憾地是，人们希望只按一下蓝色的“Secure Me Now”（立即保护我）大按钮就可以自动强化系统，但是安全性要比那种情形复杂得多。

如何处理风险
要受到良好保护（而不是有限的保护），必须采取一个合理的方法来处理风险。您必须了解面临着哪些风险，决定要降低哪些风险，然后还必须了解如何降低风险，这一切都不是启动一下开关就可以实现的。
一般而言，这些安全开关是为特定情形设计的，并不一定最适合您的具体配置。它们的作用是创建一个不错的基线起点，并迎合许多市场对这些快速强化调整工具的需要。在现代软件中，大部分开关已默认打开，而没有打开的开关可能具有严重的副作用。
并且，启动大量开关可能产生一个无法支持且不稳定的系统，该系统可能不会执行您需要它执行的任务——而这所有的一切就是为了预防您尚未弄清的威胁。SPFE 和量子物理学告诉我们应在实施保护后进行重新分析，但是太多组织都没有做到这一点。实际上，他们并未做到第一时间分析威胁。如果首先实际分析威胁，您会发现真正产生影响的事物并不是列出帐户名的匿名限制，也不是大规模的访问控制列表更改。
相反，实际产生影响的是确定系统是否应提供某项特殊服务；如果是，提供给谁；然后再执行该策略。重要的是确保只有那些绝对需要与您通信的系统和用户才有权执行此操作。另一要旨是确保所有应用程序和用户都使用尽可能低的权限。简而言之，要牢记采取明智的安全方法并且下功夫进行分析，从而使每个系统都可以负责自己的安全。
它就是目前的安全方法使用服务器和域隔离 (microsoft.com/sdisolation)、Windows Server® 产品中的安全配置向导 (SCW) 以及“服务器管理器”工具（在 Windows Server 2008 中管理角色）的原因。这些工具将一步步引导您理解必须支持的情形，然后帮助您恰当地锁定系统。当然，这些工具不会提供适合每个人的万能药，但是它们能提供可支持配置，实际执行您购买该软件要完成的任务。

在适当的位置应用安全设置
它的核心是不能依赖外部因素或简单的调整工具来保证安全。每项资产都必须能够保护自己，“外围防护”和“内部网络”之类的概念现在已毫无意义。
对于绝大多数组织网络而言，至多处于半防御状态。您需了解到这一点并采取适当的措施，而不是仅依赖于机械的强化指南。首先，必须了解自身需求。还要从其他了解您需求的人那里借鉴经验。
网络广播上的一个客人最近建议小型企业用户转到美国国土安全局网站并下载用于 Internet Explorer® 的强化指南。那是一个负责保护军事和国家安全设施的政府机构，为什么您要指望它提供保护小型企业中 Web 浏览器的合适指南？这个例子形象地说明了为什么某些糟糕的逻辑仍在计算机安全性领域中流行。由于指南是由三个字母的政府机构所发布的，人们会认为它肯定非常安全。
选择通常表现为二元决策：具有“高安全性”或“低安全性”。此选项更好的表述是介于“高安全性”或“适当安全性”之间。安全性并非一刀切的过程。
实际上，高安全性不适合于所有人——并且，它通常并不适合大多数人！它并非您应为之而努力的终极目标。它是一种特殊的系统配置，如果系统遭到破坏，人们也会遭灾。如果这种情形符合您的风险情况和威胁模型，则使用高安全性。
如果您的风险情况和威胁模型并非如此，则应使用更适合的安全性。在默认情况下，可配置的调整工具很可能都已针对中等风险做了适当设定。现在大部分 Microsoft 产品都采用这种默认状态，在安全性和可用性（有用性）以及性能之间提供了一个合理的平衡。目前强化一般都能做到这一点。
现在，需要考虑其他安全步骤。最好先从 TechNet 安全中心 (microsoft.com/technet/security) 着手，当然还有《Windows Server 2008 安全资源工具包》这类书籍。

风险管理是核心
现在，您可能已意识到我规划的未来方向：风险管理。海森堡不确定性原理中的关键信息是您需要进行权衡。这部分原理并非深奥难懂。
然而，“薛定谔猫”所传递的信息是许多人都没有考虑到的。不仅需要分析问题的所有层面并制定平衡决策，而且还必须考虑解决方案所带来的更改。一个合理的风险管理策略将考虑这些更改如何影响系统，以及是出于风险缓解策略还是其他原因而实施这些更改。

年度损失期望
量化风险的常见方法（也是在许多安全认证课程中学到的方法）是年度损失期望 (ALE) 等式（如图 2 所示）。标准的 ALE 非常简单。确定事件的概率以及每次出现的成本，然后将两个值相乘。根据结果您可预计每年为安全事件所支付的费用。如果风险成本太高，可执行缓解之策。
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
Figure 2 ALE is the probability of a loss, multiplied by the cost of the loss per incident
它的问题是标准 ALE 无法适当处置缓解成本。缓解不仅本身存在成本，并且许多缓解还具有副作用，也会产生相关成本。
以其中一个最标准的安全调整工具为例：帐户锁定。许多组织部署了帐户锁定，表面上可防止攻击者猜出密码。可通过算术方法计算出攻击者猜出任何单一密码的概率。要是您进一步挖掘，还可算出攻击者成功猜出某个密码而产生的破坏的平均成本。根据这两个数字，许多组织觉得 ALE 并不令人满意，因此实施了帐户锁定。
但是，这一特殊缓解措施有一个您可能并未考虑到的成本。即，实施缓解本身存在的成本，当然，在这个例子中虽然非常小。为准确起见，计算还应包括缓解所产生的副作用的成本。
首先，存在技术支持人员为用户解锁帐户产生的成本。如果帐户仅锁定一小段时间（比如 15 分钟），在该时段内还因失去生产力导致额外的成本。这一因素视为每个事件的成本，再乘以在指定时段内发生该事件的概率。在本例中，要将成本与预期的锁定事件数（您的日志可能已能提供该数字）相乘。
还必须考虑用户加重系数。如果可能被锁定帐户，用户会使用复杂度较低的密码，因为这能减少输入错误几率。因此，在实施缓解措施后，我们希望避免的事件的概率并不会完全降至零。
最后，可能存在由于缓解而引入的漏洞，而在使用缓解之前系统中并不存在这些漏洞。对于帐户锁定，攻击者只需重复输入错误的帐户密码，就可以利用该功能来禁用网络中的所有帐户。也存在发生此情况的概率以及每个事件的相关成本。
如果将所有这些因素考虑在内，显然必须修改损失期望等式。首先，必须修改事件概率。尽管概率不可能完全降至零，但是根据前面的说明，现在该事件的发生概率应该比之前要低。每个事件的成本也可能已发生变化。您需要加入缓解自身产生的成本。该成本包括实施成本加上所有副作用的年度成本之和。每个此类年度成本为所发生副作用的概率与该副作用每个事件成本的乘积。将等式略微简化一点，现在可得到更加准确的风险分析等式（如图 3 所示）。
图 3 中的改良等式提供了一个更加准确的方法来分析特定问题的风险。许多组织已使用此方法来分析风险。但是，太多组织仍使用简化的风险视图，它无法充分体现出分析缓解影响的必要性。如使用修改后的 ALE 等式，则会对这一需求予以足够的重视。
Figure 3 Considering the additional costs of mitigation
Figure 3 Considering the additional costs of mitigation

这一切意味着什么
如果本文只给您一项启迪，那么应该是质疑安全策略背后的常规思路。在信息安全领域，我们所做的太多工作都是基于纯粹刻板的世界观。许多假设现在都已过时。
攻击已发生变化。攻击者现在都是专业人员，发动攻击的原因包括金钱、民族至上以及意识形态等。如果仍在无效的安全调整工具上浪费时间和金钱，后果是相当严重的。它还意味着必须采取更先进的风险管理方法。
首先，必须意识到所做的每件事都需要进行权衡。您无法非常确定地了解每件事。
其次，必须清楚您是在一个相互依赖的系统中执行操作。通过在该系统中引入安全更改，即修改了系统本身，它意味着之后必须重新分析系统。
最好是在实际实施这些更改之前进行分析，因为频繁变动对系统会产生极大的影响，以致于弊大于益。通过使用更好的分析工具提醒您分析此类更改，可大大提高对它的重视程度。
最后，切勿忘记人为因素。在信息安全方面所做的一切努力均旨在使企业和组织中的用户可尽可能安全地操作。
在最近的一次演示中，我指出了现在不可能有哪个用户购买计算机是为运行防病毒程序。 安全是您的主要目标，但并非公司的主要目标。组织之所以采用这一模式是因为这样做可以取得最大的收益。切勿忘记有为企业提供服务的信息安全组，不能各行其事。如果忽略了这一事实，用户会不惜一切代价地完成其工作，甚至会避开其并不理解或认同的安全控制。

Jesper M. Johansson是研究安全软件的软件架构师，还是《TechNet 杂志》的特约编辑。他拥有管理信息系统博士学位，具有 20 多年安全方面的经验，并且是企业安全性领域的 Microsoft 最有价值专家 (MVP)。他的最新著作是《Windows Server 2008 安全资源工具包》。


 桌面文件: 让管理员退居幕后
桌面文件
让管理员退居幕后
Wes Miller

在三年多以前，我开始将我的主 Windows 系统上的用户帐户从本地管理员帐户转换成了本地用户帐户。我已在 Microsoft 工作了七年多的时间，始终都是以完全权限的 Administrator 身份运行。毋庸置疑，这样做很方便——但是却缺乏安全保障，
我和其他许多人所处的这种状况并非只限 Windows 系统，其他系统也屡见不鲜。
我经常希望有一种方法能够对此进行准确的统计，但我其实很清楚而且业内人士也曾告诉过我，现在有太多的组织甚至 IT 专业人员本人都以本地 Administrator 身份运行。在 Winternals，我切换到以 User 身份运行的前提是了解这样做的困难程度（作为“专业消费者”），并且在一定程度上了解我们的产品 (Winternals Protection Manager) 在一般组织中能提供什么样的帮助。假设大多数组织中的大部分用户至今仍在以 Administrator 身份运行，我们的目标是使管理员能以 User 身份运行，并最大程度减少转换工作（或至少是所带来的麻烦）。无论使用何种技术，将组织中的用户从 Administrator 身份转换为 User 身份并非易事，但这却是减少组织攻击面的最有效方法。它可以被视为系统内的防火墙，因为这也的确是其真正的作用。

应该如何实现呢？
您面临的挑战：感到痛苦
如果您尚未开始考虑将 Administrator 身份转换成 User 身份，那现在是开始考虑的时候了。建议您首先亲自感受一下。不要在备用计算机上——那样不真实。请在您的主系统（即您天天使用的计算机）上进行尝试。如果运行的是 Windows Vista®，还建议在不使用“用户帐户控制”(UAC) 的情况下进行尝试。如果想在组织内宣传进行某些变革，在大张旗鼓进行宣传之前首先自行体会一下是个不错的主意。相信您会发现以非管理员身份运行并非像您想象的那样困难——而且在引入了这样的安全措施后，将会切实改变组织的攻击面。

大多数用户都以 Administrator 身份运行的根源在于 Windows® 的历史。从第一个版本的 Windows 开始，到 Windows NT® 3.1 之前，每个交互式用户的权限都与下一个用户相同——从功能上讲，没有任何安全性可言。在家用环境下，这并不算是个大问题；它意味着所有软件都以相同的方式进行安装。这样做是假定此用户拥有该计算机，并且安装的所有软件都允许该计算机的所有用户使用。
当 Windows NT 首次面市时，它肯定不能立即占领企业（更不用说消费者）市场。并且由于 32 位 Windows 和 Windows NT 之间存在着的 Win32® 兼容性问题，大多数应用程序供应商并没有仅仅为了 Windows NT 的安全性基础结构而重建其应用程序。实际上，直到 Windows 2000，许多面向消费者的“独立软件供应商”(ISV) 才开始注意到 Windows NT。当然，是 Windows XP 强制解决了此问题，因为它终结了 Windows 的 9x 系列。
但是，应用程序仍假定系统中的每个用户均有权写入到 Program Files、注册表中的 HKEY_LOCAL_MACHINE (HKLM) 以及 HKEY_CLASSES_ROOT，而事实却不是如此。在这些假定访问的情形中，游戏常常是最令人头痛的一个方面，请参阅 Matt Clapham 有关此主题的文章，网址为：technetmagazine.com/issues/2007/02/Gaming。
这的确是个问题，因为大多数跨系统应用程序都将其文件和注册表设置存储在这些位置，您需要能够读取和写入这些位置才能安装它们。不幸地是，一些应用程序仍坚持在安装后写入这些注册表项。例如，我女儿有个基于 Flash 的游戏。每次运行时它都会尝试安装一个自定义播放程序——这意味着当我女儿以 User 身份而非 Administrator 身份运行时，应用程序将无法启动，并会出现一个致命错误。尽管这是个极端案例，并且它是一个消费者应用程序，但实际上许多非消费者应用程序在非管理用户方面做的也不够好。事实上，如果您深入探寻我的挑战（请参阅侧栏“您面临的挑战：感到痛苦”），您就会发现 Windows 对以 User 身份运行的支持程度是多么糟糕。
如果看一看图 1，您会了解到在 Windows XP 上以 User 身份运行 IPConfig /release 后产生的效果。如果与图 2 进行比较，您会发现在 Windows Vista 下运行这个命令的效果也好不到哪儿去，但至少可以了解到命令失败的原因。请注意，联网工具整体都得到了改进，可以允许用户刷新其 IP 地址。同样，在任意版本下尝试以 User 身份运行 Computer Management (compmgmt.msc) 都只能执行有限数量的任务——而且通常会产生令人沮丧的结果（如图 3 所示）。尽管 Windows Vista 最初并未启用 Computer Management 中的许多工具，但却比较清楚地给出了访问被拒绝的消息。
Figure 1 Running as a user under Windows XP
Figure 1 Running as a user under Windows XP
Figure 2 Running as a user under Windows Vista
Figure 2 Running as a user under Windows Vista
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP
Figure 3 Misleading message after running compmgmt.msc as a user on Windows XP

为什么重要
那么为什么我们要给予关注？因为作为 IT 专业人员，我们应该开始强制应用程序调整到最低权限用户，而非让应用程序假定交互式用户拥有系统。
遗憾地是，对于那些允许管理员写入注册表项的策略，它们也授予了在用户上下文中运行的恶意软件对那些未通过“访问控制列表”(ACL) 明确拒绝的所有内容的完全访问权限。在 UNIX 领域，人们普遍都不以 root（在功能上等同于 Windows 的管理员帐户）身份运行，这主要是因为推动安全模型边界的软件体系几乎已不再存在。
尽管如此，您最好采取同样的做法，仅在明确要求时才以 Administrator 身份运行——或者更进一步，仅以 Administrator 身份运行单个应用程序。这样做之后，即可建立起我之前提到过的系统内防火墙。从而，当恶意软件或间谍软件试图执行其不应执行的操作时将会失败——因为它无法写入注册表或文件系统位置，而不写入这些位置就不能真正感染系统（如安装服务或驱动程序，或者为所有用户安装）。此外，这还可以使反恶意软件程序能够抑制它所识别出的恶意软件，使其不致首先危及整个系统。
但是要注意，这并不能保证用户不受攻击。很可能有一些恶意软件能够成功感染单个用户的上下文或破坏其数据（尽管此类恶意软件目前尚未广泛传播）。但此类软件所针对的攻击目标比较有限。因此，采用 Linux 或 Macintosh 上所采用的恶意软件防御方法（潜在的受害者如果比较少的话，恶意软件作者根本就不屑于去关注）有助于确保您的最终用户以及您自身的安全。

Power User 退出历史舞台？
在开发 Protection Manager 时，我们从客户那里听到过这样一番话：“我们的所有用户都以 Power user 身份而非 Administrator 身份来运行 Windows XP，因此我们是安全的。”可是，实际上 Power user 与 Administrator 之间的差别并不大。Windows XP 中存在很多潜在的漏洞，只需略施小计就可以使 Power user 变为 Administrator。事实上，在 Windows Vista 和 Windows Server® 2008 中已删除了 Power user 组；只有从之前版本的 Windows 升级而来的系统还保留着 Power user 组。总而言之，应尽可能避免使用 Power user 组，即使您使用的是 Windows XP。

权限损耗
如果您读过我在三月份撰写的有关 Windows 瘦客户端的专栏 (technetmagazine.com/issues/2008/03/DesktopFiles)，则应该记得我曾说过使 Windows XP 通过瘦身的方式来节约空间。同样，在将 Administrator 转换成 User 时可以考虑采用一种常见的做法，但执行起来必须要当心。这种做法就是调整注册表和文件系统的 ACL，使用户可写入其通常不能写入的位置——从而允许那些存在此类问题的应用程序访问。
显然，最佳选择是获取更新的应用程序以避免进行这种改动，但有时这是不可能的。如果必须更改权限（即降低它们），操作时要非常谨慎。要记住，User 和 Administrator 之间的防火墙主要是通过注册表和文件系统权限来定义的。打开它会降低保护程度，并可能拓宽呈现给恶意软件的攻击面——因此执行前务必要三思。

UAC 又是怎样的情形呢？
说到将用户从 Administrator 身份转换成 User 身份，就不能不提到 Windows Vista 中的“用户帐户控制”(UAC)。UAC 与 Mac OS X 中的类似功能一样，可以使您在以 Administrator 身份运行时不必面临如此大的风险。
这是如何实现的呢？看一看图 4 中 Process Explorer 显示的有关 cmd.exe 的内容。右侧的 cmd.exe 实例是在未提升的情况下启动的，而且我是以 Administrator 身份运行的。结果，即使右侧的用户与左侧的用户完全相同（左侧的 cmd.exe 是在提升的情况下启动的），应用程序本身并未包含它（以及运行该实例的用户）在执行需要管理权限的任务时所需的权限和令牌。UAC 是通过降低用户交互式上下文中的攻击面来工作的。唯一的问题是必须告诉 Windows：即执行此任务需要管理权限，用户有资格获得完成此任务所需的提升。
Figure 4 Two instances of cmd.exe with different privileges
Figure 4 Two instances of cmd.exe with different privileges
Windows Vista 中的小盾牌显示了哪些任务需要提升（请参见图 5）。这些任务在每次运行时都需要提升——而这也是大家特别关注的 Windows Vista 的弱点之一。替代方法是使凭据更具“粘性”，而这可能会带来潜在的安全威胁，使系统更容易被利用。
Figure 5 Shields in Windows Vista indicate the need for elevation
Figure 5 Shields in Windows Vista indicate the need for elevation
如果启用了 UAC 且用户仅以 User 身份运行，则当应用程序需要管理权限时，系统会提示其提供一组管理凭据。请注意，在此示例中，就像是使用 runas 或 psexec 时一样，应用程序实际是在您启动它时使用的 User 身份的上下文中运行（与在 UAC 下作为管理员不同）。在这种情况下，这些任务以提升的权限在您的上下文中运行。

以 User 身份运行 Windows Vista？
在运行 Windows Vista 时，我个人倾向于使用 User 身份而非 UAC 下的 Administrator 身份，因为我认为在一般的企业中，这仍是最好的想法。毕竟，这样做不但用户可以完全控制其系统，而且您也可以减少受到恶意软件攻击的机会。
此外，如果您打算管理用户（使用组策略）、防病毒软件、反恶意软件程序或其他软件，并希望集中控制这些任务是否实际执行或完成，必须确保最终用户不是管理员。如果用户是管理员，他们可能会停止服务、添加或删除驱动程序等。当然，以 User 身份运行的别有用心的最终用户可以使用 Windows PE 来绕过某些安全屏障。BitLocker® 可增加其难度，但我要重申，只要有充足的时间和丰富的知识，在经过深入钻研后，具有物理访问权限的最终用户将可以对其计算机执行他所希望的任何操作。
以 User 身份运行 Windows Vista 与以 User 身份运行 Windows XP 的差异并不仅限这些。需要时，可以使用相同的工具（PSExec、RunAs 和现在的 UAC）以 Administrator 身份来运行任务。让人高兴的是，许多在 Windows XP 中需要管理权限的任务现在都已不再需要。例如，Windows Vista 用户可以安装本地打印机。（在 Windows XP 中，用户可安装网络打印机，但安装本地打印机需要有管理权限。）在 Windows Vista 中，只要用户实际进入了计算机并且打印机驱动程序位于驱动程序库中，用户就可以安装打印机并管理其中的打印作业（更多信息，请参阅 go.microsoft.com/fwlink/?LinkId=111534）。请注意，在 Windows Server 2008 中此功能被禁用。
当人们以 User 身份运行 Windows XP 时，经常取笑它的时钟功能（或者没有此功能）——尝试以 User 身份双击时钟（人们经常用这种方式来查看日期，无论它的设计本意是否如此）——您会看到图 6 所示的错误。这不是很友好。在 Windows XP 中，通过修改策略可使用户能够执行此操作，但在 Windows Vista 中，已经改为以这种方式运行。总而言之，以 User 身份运行时，无论是使用 UAC 还是以正式 User 身份运行并提升为另一用户，在 Windows Vista 中通常都要比在 Windows XP 中更人性化。
Figure 6 In Windows XP, non-admins couldn't change the time
Figure 6 In Windows XP, non-admins couldn't change the time

记住限制
请记住，将用户转换成非管理用户并非是万能灵药。对于那些实际上掌管着自己的计算机的最终用户而言，他们可以千方百计地寻找其系统的漏洞，尤其是当策略或 User 权限使其感到不便或令其无法完成工作时。
如果用户以 Administrator 身份运行，则无需费力就可以绕过已有的任何组策略。当然，再多费一点事，用户可以引导到 Windows PE 并修改一些通常情况下他并不具有的权限（尽管在使用 BitLocker 或其他驱动器/卷加密时，可以使其无法实现此操作，或者至少会困难一些）。
如果您的组织尚未开始将最终用户转换成以 User 身份运行，您现在需要做的最重要的事情就是了解您和您的组织为什么要花费时间、金钱和精力来改变用户以 Administrator 身份运行的现状。
的确，有一些旧应用程序可能无法再使用，但是如果为了迁就某个无法以 User 身份运行的应用程序而损害组织的安全则有些得不偿失。可以考虑虚拟化该应用程序——将其移到用户能真正作为管理员运行的虚拟机中。这不但使您可以在需要时继续使用该应用程序，而且还可以通过将 Administrator 身份转换成 User 身份来保护系统剩余部分的安全。
请注意，在整个专栏中，我没有使用“锁定”或类似的衍生词。许多人都把将 Administrator 转换成 User 看作是常常使用该词描述的任务的一部分。也许是由于我的心理学背景的原因或与我目前所处的市场营销领域有关，我认为千万不要使用会使最终用户感觉其权限被剥夺的词汇（即使只是语义上的）。
相反，应该关注组织的安全利益，并确保针对一些边缘情况（特定用户根本无法以 User 身份运行的任务或需要管理权限才能执行的特定任务）制定出合理的计划。无论是使用某些手动方法（如 Run.vbs 脚本，可在 technetmagazine.com/issues/2007/03/DesktopFiles 上找到）还是通过商业解决方案来帮助您实现转换（它可以向最终用户隐藏转换细节，使工作一步到位），都必须尽快开始执行到非管理员身份的转换。《TechNet 杂志》的撰稿人 Aaron Margosis 是以非管理员身份运行的倡导者。如果您还不熟悉他的博客，则应该仔细研究一下——它是深入了解此主题的最佳去处（请参阅 blogs.msdn.com/aaron_margosis）。

Wes Miller 目前是位于德克萨斯州奥斯汀市的 CoreTrace 公司 (www.CoreTrace.com) 的高级技术产品经理。在此之前，他在 Winternals Software 公司任职，并曾在 Microsoft 担任项目经理。您可以通过电子邮件 technet@getwired.com 与 Wes 联系。


 领域备注: 一台 PC，多个鼠标
领域备注
一台 PC，多个鼠标
Kentaro Toyama

现在的印度 是一个差距悬殊的国家。一方面，它是一个 IT 强国，拥有众多受过良好教育的人才开发满足全世界计算需求的技术。而另一方面，全国 70% 的人们每天的收入仍不足 2 美元。这些截然相反的境况有时会出现在贫困地区政府学校的计算机课堂中，在这里您最多只能看到几台 PC。由于学校自身缺乏购买计算机的经费，因此仅有的几台计算机通常都来自于捐赠。
在此类学校中，学生人数几乎总是超过计算机的数量。10 来个孩子围坐在 1 台 PC 旁的情况十分常见，而且通常是由其中最强壮的孩子负责操作。当然，“个人计算机”这一词汇中的“个人”二字表明 PC 是设计来供单个用户使用的。作为 Microsoft 印度研究中心的一员，我们都希望能为让更多的孩子接触到计算机而做些事情。
最后想出来的解决方案非常简单：MultiPointTM 允许将多个 USB 鼠标插入到一台计算机中，并且每个鼠标对应于屏幕上不同颜色的一个光标 (research.microsoft.com/users/udaip/multipoint.htm)。实际上，这种解决方案创建了一个多人环境（就像游戏控制台一样），这样针对多鼠标模式编写的教育软件就可以使多个孩子同时使用一台 PC。
尽管大人们担心整个屏幕会搞得一团糟，但这些学生们却很快适应了这种模式。我们曾针对 7 年级学生进行过多次严格的研究，通过将五人 MultiPoint-PC 配置与一个学生一台 PC 配置相对比，研究人员发现：首先，当每个孩子都能控制鼠标时，也许由于这样更加有趣，他们与 PC 以及其他孩子交互的时间比使用另一种配置情况时要长得多。其次，必须设计鼓励协作而不全是竞争的软件应用程序，否则某些孩子（尤其是男孩子们）会将其变成缺乏教育价值的“分组对抗”竞赛。最后，如果建立了协作关系，那学生们在 MultiPoint 应用程序中学到的知识将与每人拥有一台 PC 时所学到的一样多，至少对于简单的词汇记忆任务来说是如此。在之前提供的 MultiPoint 链接上包含有关此次研究的更多信息。
如果批量购买的话，每只鼠标的价格仅为几美元，这意味着通过向学校提供 MultiPoint 教学应用程序，每个孩子的计算机成本将显著降低。例如，五名学生共享一台价值 500 美元的 PC，再加上每人一只 5 美元的鼠标，这样平均下来每个孩子只需 105 美元 — 任何能够降低每个学生教育成本的方案都会受到预算决策者的欢迎。
Microsoft 的“无限潜能”(microsoft.com/unlimitedpotential) 和“教育”(microsoft.com/education) 项目组已认可 MultiPoint 对于资源匮乏学校的价值。为促进快速广泛地使用此解决方案，他们发布了一个软件开发工具包，该工具包可以帮助教育内容开发人员方便地在 C# 应用程序中应用这种多鼠标模式。可免费下载和使用该 SDK ，并且任何基于 Windows® 的计算机都可以运行 MultiPoint 应用程序 (microsoft.com/downloads)。
作为“无限潜能”计划之下的项目之一，MultiPoint SDK 的目标是将 PC 的价值扩展到尽可能多的学生。为此，我们需要您的帮助。如果尝试使用 MultiPoint 来编写教学应用程序，欢迎您告知我们。我们将在 MultiPoint 网站上提供优秀示例程序的链接。
接下来，Microsoft 印度研究中心和终端服务产品团队将考虑另一种共享 PC 的方式：“分割屏幕”，即两名操作者、两个键盘以及两个鼠标共享一台 PC 和一台显示器。显示器将从中间分成两半，这样即可在每一边屏幕中运行单独的操作系统会话。

Kentaro Toyama 是 Microsoft 印度研究中心 (research.microsoft.com/india) 的副主管以及新兴市场技术小组 (research.microsoft.com/research/tem) 的首席研究员，该小组旨在为全球经济相对落后的地区开发技术。


 Windows 机密: 16 位图标已经过时了
Windows 机密
16 位图标已经过时了
Raymond Chen

我 在 2008 年 2 月的 Windows 机密专栏中提到，某些功能确实已经从 Windows® 中消失了。它们通常消失得非常缓慢而且基本上察觉不出，只有产品团队的人们会在每一次功能消失时安静地举行庆祝。另一个在 Windows Vista® 中消失的功能是使用 32 位代码访问存储在 16 位模块（主要是 16 位 EXE 和 16 位 DLL）中的图标。
在开始介绍该功能之前，您需要了解 16 位代码可以正常访问存储在 16 位模块中的图标；而该过程发生在 16 位仿真层内部。消失的功能是从 32 位代码访问这些图标的能力，或者更确切地说，是类似 ExtractIcon 之类的 32 位图标提取函数从 16 位 DLL 中加载这些图标的能力。
从 16 位模块中提取图标的 32 位代码无法使用 FindResource 这样的内核函数在文件中找到图标。它们必须执行其自身的微型装入程序（用于解析 16 位模块头），找到并解析资源表以搜索所需的图标资源。只有完成所有步骤，32 位代码才能最终将像素转换为图标。
如您所想，完成这些工作的代码非常古老而且脆弱。错误或恶意行为都会导致二进制文件破坏，解析时也很容易出错。性能团队将会要求改变打开文件的方式，以便提高通过网络执行这些操作的性能，因为不同的打开和共享模式会对网络缓存的效果产生不同的影响。而可靠性团队可能要求重新编写解析代码，以避免使用内存映射文件。最终，维护此类代码的成本开始超过其所能提供的价值。实际上，我的意思是几乎没有人会再去编写 16 位程序了，不是吗？
现在，只要还存在 16 位仿真层，那您的 16 位程序仍可继续运行。（没错，64 位 Windows Vista 不包含 16 位仿真层，但这并不表示它比 Windows XP 落后；64 位 Windows XP 同样也不包含 16 位仿真层。虽然这样不会比原来更好，但同样也不会比以前更糟糕。）
在 Windows Vista 中，您损失的功能是不能在 32 位程序中使用 ExtractIcon 函数，也不能从 16 位 DLL 中获得图标。如果“开始”菜单上有 16 位程序的快捷方式，那么该快捷方式的图标现在将变成通用程序图标，因为 Windows 资源管理器无法再从其主 EXE 中提取 16 位程序图标。损失并不大。但如果这确实给您带来了麻烦，那您可以编辑该快捷方式的属性，并为其添加来自 32 位模块中的图标。
据我所知，损失该功能后唯一的问题出现在由一种特殊图表编辑工具生成的图标库内。由于某种原因，该程序默认将其图标另存为 16 位 DLL 中的资源，这意味着您将无法从 32 位代码中访问这些图标。当然，最简单的解决方法是将这些图标库重新另存为 32 位 DLL 中的资源。
我确信最终（说不定已经有人完成了）某人会编写一个小程序从 16 位 DLL 中提取所有图标，然后使用这些图标创建仅包含 32 位资源的 DLL，这样，那些使用 DLL 中 16 位旧图标的人们可以继续在“开始”菜单的快捷方式中使用它们。但我敢说，如果您编写此程序，那您很可能发现实际上谁也不会用到该程序。到 Windows 用户界面团队那里请求此程序的次数是：零。

Raymond Chen 的网站“The Old New Thing”及同名著作讲述了 Windows 的发展历程和 Win32 编程。他非常了解很多即将退出历史舞台的技术。