 TechNet Magazine July 2007

TechNet Magazine July 2007

通信: Exchange Server 2007 数据保护与灾难恢复

Exchange Server 2007 包含一系列支持高可用性和灾难恢复功能的选项。探索 Exchange 提供的替代解决方案并为您的组织制定理想的灾难恢复方案。

Lee Benjamin 通信: 提高 Windows Mobile 6 的安全性

当 Smartphone 和 PDA 从办公室之外访问网络时，它们可能会使网络暴露于新的漏洞。下面为您提供 Windows Mobile 6 和 Exchange Server 可以如何帮助保护贵公司移动设备和基础结构的指南。

Matt Fontaine 通信: 公用文件夹的强大替代方法

MOSS 2007 提供了比 Exchange 公用文件夹强大得多的共享数据解决方案，为用户带来了许多增强功能和更轻松的管理。让我们看看如何使用 SharePoint 来共享日历、联系人和文档。

Alan Maddison 通信: 使用智能卡登录 Outlook Web Access

安全链中最为薄弱的一个环节与脆弱、易被破坏的密码有关。了解如何通过为您的移动用户实施智能卡双重身份验证来增强电子邮件的安全性。

Victor Akinnagbe, Ted Dressel, and Jason Opdycke Windows 管理: Windows Vista 中的 ActiveX 安装程序服务

在不限制应用程序兼容性的情况下，您如何保护台式计算机免遭恶意 ActiveX 控件的破坏？我们将向您介绍 Windows Vista 中的 ActiveX 安装程序服务 (AxIS)，该服务采用一种新方法来管理 ActiveX 控件，从而解决了这个问题。

Rob Campbell and Joel Yoker 编辑视角: 六度间隔

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

Greg Steen SQL 技术问答: 内部群集、神秘的挂起、SA 帐户及其他

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

Jeff Tondt IT 运作方式: 排除 RPC 错误

Zubair Alexander 网络专家: 通过 VPN 连接进行 IPv6 通信

Joseph Davies Windows PowerShell: 重新考虑管道

Don Jones 您好，脚本专家！: 脚本就像生活，给人的观感非常重要

The Microsoft Scripting Guys Exchange Queue & A: 边缘和集线器传输角色、虚拟机及其他

KC Lemson and Nino Bilic 安全观察: 管理 ACL 的工具

Jesper M. Johansson 桌面文件: Microsoft 桌面优化包

Wes Miller Windows 机密: 安全模式的修复功能

Raymond Chen


 通信: Exchange Server 2007 数据保护与灾难恢复
通信 Lee Benjamin

Exchange Server 2007 数据保护与灾难恢复
概览:
  • 基本备份和恢复
  • 数据连续性
  • 复制技术
  • 替代解决方案

Microsoft Exchange Server 的设计考虑了备份因素。组织需要备份其邮件数据，同时还必须能够恢复这些信息。为满足这些要求，Microsoft 构建了一整套数据保护选项，从传统的
备份和低端的恢复到操作连续性，直至可提供最高水平的可用性和灾难恢复功能的真正业务连续性解决方案。在本文中，我将介绍这些选项并帮助您决定如何为您的组织实施最佳 Exchange 恢复解决方案。

级别 1：基本备份和恢复
您可以在数据库脱机后备份 Exchange 文件，也可以在数据库正在运行时进行备份。实际上，更多情况下建议采用后一种方式来备份 Exchange。但 Exchange 不仅仅是一组文件。它是包含大型数据库文件和事务日志的信息存储区。发送给 Exchange 的邮件消息会立即记录在事务日志中，当系统进入某些空闲周期时（通常在若干毫秒之后），这些消息将复制到数据库中。Exchange 通过将信息尽快存储到磁盘，来提供高水平的恢复功能。恢复 Exchange 最根本的是这两组信息的可用性。一旦系统出现故障，则需要结合使用上一次备份以及该备份点之后发生的所有事务，将 Exchange 恢复为最近的信息。注意，Exchange 会根据需要自动将事务重新播放到恢复的数据库中。
备份程序访问 Exchange 数据库信息的方式是通过可扩展存储引擎 (ESE) 备份 API 或更新的 VSS 解决方案（稍后我将介绍这些新的解决方案）。只要启动 ESE 备份，Exchange 就会暂时挂起向其数据库进行的所有写入。在 ESE 暂时将数据库设置为只读模式以便能够在完整备份过程中对其进行复制的同时，它还会使用一个临时数据库来保存在备份过程中发生的新事务。当备份完成后，ESE 会将数据库返回正常的读/写模式，并应用累积在临时数据库中的事务。成功完成备份后，最后还会清除掉旧的事务日志。
即使对于在半夜时分备份正在进行时登录的用户，此备份过程也是直接和透明的；虽然如此，ESE 仍然需要很长时间才能完成，特别是因为 Exchange 数据库的规模跨度很大，可以从几千兆字节到可管理的 30 到 50GB，甚至高达 100GB——如果使用标准技术，几乎一整夜也无法完成备份。要初步了解使用 NTBackup.exe 时的可用选项，请看一下图 1。
图 1 使用 NTBackup 实用工具
图 1 使用 NTBackup 实用工具

Exchange 最佳实践
如果希望能够迅速从常见硬件和系统故障中恢复，应在夜间运行完整的 Exchange 备份。为改进 Exchange 服务器使用本地磁盘时的性能和恢复能力，应使用单独的 RAID 阵列来存储 Exchange 数据库和 Exchange 事务日志，这一点很重要。这样，如果 RAID 阵列控制器出现故障，或者如果阵列中的多个磁盘出现故障，使得剩余磁盘无法再重新构造条块化的数据时，您仍然能够进行恢复。如果丢失了事务日志，您仍然可以在其他驱动器上获得最新的 Exchange 数据库，从而能够继续使用新事务日志进行正常操作。如果丢失了数据库驱动器，此时的恢复策略应是返回到前一夜的 Exchange 数据库的完整备份，然后应用当前日期的事务日志使之保持最新状态。
限制 Exchange 数据库的大小非常重要，以便能够以合理的用时备份每个数据库——更重要的是，能够进行恢复。对多数组织来说，这意味着需要使数据库的大小保持在 30 到 50GB 之间。如果数据库超出该大小，则建议将其拆分成多个小数据库，以便能够对恢复进行管理。

备份和恢复连续性
数据库和事务日志的放置位置非常重要——不仅仅是对于备份性能，还事关恢复速度。今天，所有服务器都支持各种级别的磁盘驱动器冗余（称为 RAID）。从基本上讲，RAID 使得磁盘驱动器出现故障时不会导致系统崩溃，但在更换和重建磁盘之前系统性能会降低。在此期间，为响应每个磁盘的访问请求，阵列控制器必须动态地使用剩余磁盘重新构建数据。有关邮箱服务器存储设计的详细信息，请参阅 Microsoft IT Showcase 文章“Exchange Server 2007 的 64 位应用”。
Exchange 的核心功能是其单实例数据库设计。这意味着在一个 Exchange 数据库中，只会存储一个特定邮件消息副本以及一个附件（如果有）。如果该邮件是发送给同一信息存储区中的多个收件人，则会创建指向相应对象（邮件、附件）的附加指针，但不会复制对象。这不仅对提高传送效率很有好处，还可以为 Exchange 节省磁盘和磁带空间。
由于 Exchange 只擅长恢复整个数据库，因而单个邮箱、文件夹或邮件的恢复会要求先恢复整个磁带。毫无疑问，用户会希望具备更小单位的恢复能力。磁带的这种单实例特性使之非常难以实现。针对此需求，备份服务供应商采用了“程序块级备份”(Brick-Level Backup) 技术（本人并不建议采用此技术）。使用认可的 ESE 备份 API 完成 Exchange 的完整备份后，备份产品会将每个邮箱添加到备份磁带上。因为该备份 API 并未提供一种从单个邮箱中提取数据的方式，所以使用了 MAPI。结果，备份磁带由于复制了所有邮件和附件而变得非常长。
Microsoft 提供了一些增强功能，可部分解决这一问题。例如，管理废纸篓（或转储程序）会在用户将某些数据删除后，将其保留一段时间，以防再次需要。此外，不再需要保留一个备用服务器作为 Exchange 恢复林；恢复存储组允许管理员部分装载从磁带上取回的已恢复数据库，并将数据复制或合并至邮箱级别。

熟能生巧
许多组织都曾领教过一项艰巨的任务，即不管决定在哪个级别上进行备份和恢复，都必须定期对备份媒体和恢复过程进行测试。许许多多管理员都是在灾难发生后才知道其备份技术和恢复过程是否能够正常工作。最佳的测试时间是在建立和配置了崭新的服务器之后，当它已经开始作为 Exchange 组织的一部分运行，但上面只有很少的用户时即开始。此时，您应当执行一次 Exchange 完整备份，并定期备份您的驱动器，此外还要捕获系统的状态，其中包括系统磁盘上的重要文件和 IIS 元数据库（其中存储了 Exchange 的路由配置）。然后，小心地重新格式化该新服务器并重新启动，更新最初构建服务器时获取的注释。您应当能够从系统状态中恢复设置，同时还要具有足够的文档来手动重新实施系统配置的设置。
在这种“消防演习”上花些时间可显著减少将来的恢复操作所需的时间。您应当定期重复此过程。执行此任务时，可记下从离站位置获取磁带所需的时间。那些在此期间不得不耐心等待的用户经常会开始认真考虑磁盘到磁盘备份在其备份和恢复策略中所能起到的重要作用——即使离站磁带存储仍然为灾难恢复提供了最终支撑。

磁带备份面临的挑战
从磁带中恢复需要很长时间。现在，Exchange 对于组织来说是如此重要，以致于用户和管理者希望它能够始终处于可用状态。当出现严重问题时，大多数组织都感到措手不及。没有人会想到从磁带中恢复 75GB 的数据库居然需要八个小时——而这甚至还未包括从离站存储设施中获取磁带或重新安装操作系统所需的时间。
此外，从磁带中检索正确的数据库也是一项严峻的挑战。自从 Exchange 首次面世以来的 10 年时间里，磁盘存储和广域网的成本已经有了大幅下降。这使得许多组织能够支付更快的备份和恢复方法的成本。这些组织可以利用相关技术，为其 Exchange 基础结构实现操作的连续性和灾难恢复功能。

级别 2：操作连续性
操作连续性是一组旨在使恢复过程尽可能迅速完成，同时尽量缩短意外停机时间的过程和技术。操作连续性针对通过磁带进行的本地恢复提供了改进的恢复时间目标 (RTO) 和恢复点目标 (RPO)。它力争消除（只要有可能）使磁带重新入站所需的时间。请参见图 2 以比较备份和恢复的操作连续性与灾难恢复。
图 2 恢复连续性
图 2 恢复连续性
该图显示了恢复和可用性的连续性，左下角的技术速度慢、成本低；右上角的技术速度快、成本高；同时在操作连续性与灾难恢复解决方案之间有意进行了一下模糊过渡。
该图揭示了这些方法在成本、恢复时间和可用性之间的取舍状况。在本文中，我会刻意将本地连续性处理与灾难恢复明确区分开来。灾难恢复始终被视为一种远程操作，并以使数据离站为主要目标。距离带来了额外难度，并且通常成本更高，但灾难恢复是有关严重灾难性事件后的业务继续的措施。稍后我将深入探讨这一问题。

一些历史
随着 Exchange 在基础结构中的地位越来越重要及其数据库中存储的信息越来越多，显然有必要减少备份和恢复所需的时间。某些大型组织与 Microsoft 协同工作，开发出一种方法，大大改进部分操作的恢复。如果某个组织可以从外界接收或向其发送新电子邮件，则表面上看起来好像什么也没有发生。毕竟，表面现象是很重要的。
为实施 Exchange 的这种“拨号音”式恢复，一个新的空数据库取代了被破坏的数据库。然后，Exchange 和 Active Directory® 使用适当的权限创建新邮箱，使得用户能够发送和接收邮件。当检索了备份磁带并恢复了数据后，可使用管理权限进行装载。然后，Exchange 管理员可以将恢复的邮箱合并到拨号音邮箱中。可根据需要划分邮箱的优先级。虽然这是一项改进，但该过程很耗时，也比较复杂；它最初使用了 EXMERGE，后来应用到了恢复存储组中。不过应当注意，拨号音恢复方案之后的完整数据恢复会是一项非常艰巨、复杂的任务（尤其是在 Exchange 2007 中，存储组可多达 50 个）。如果考虑实施拨号音恢复方案，请注意确保益处大于付出。

卷影复制服务
为利用低廉的磁盘并从生产 Exchange 服务器中消除处理器开销，针对 Microsoft® Windows Server® 2003 和 Exchange 开发了一个新备份 API。所创建的卷影复制服务 (VSS) 旨在提供一致的数据时点副本。这些快照是可迅速生成的 Exchange 数据的只读副本，其中只连续包含发生更改的数据。这些副本通常指向另一个具有可用磁盘空间的服务器，或者指向存储区域网络 (SAN)。可以保留多个快照，并在磁带上制作备份。这样一来，生产 Exchange 服务器将不再受到备份软件和磁带副本开销的性能影响。
使用 VSS 进行 Exchange 数据保护具有多个优点。首先，可以从 Exchange 服务器中消除磁带备份操作的性能负载。虽然仍然需要备份到磁带，但它可以使用 Exchange 数据的副本，而不影响用户性能。其次，每晚多次获取快照成为可能。随之而来的另一个好处是您可以在辅助服务器上或其他本地存储中保留多个快照。
市场上有许多第三方产品利用了 VSS 快照功能。有些产品只是减少了备份和恢复 Exchange 数据库所需的时间，另一些产品还添加了某些功能，例如比本机 Exchange 所能提供的单位更小的恢复能力，使您能够恢复至邮箱级别。虽然没有人喜欢如此零碎的备份，但人们确实希望能够恢复特定的文件夹，甚至单个邮件消息。

复制技术
以软件为媒介的 Exchange 故障转移是某些复制供应商提供的一个选项。它将激活一个备用 Exchange 服务器，然后通知 Active Directory 所有用户的邮箱已经移走。有两种方式来完成此任务，并且它们都要求对 Exchange 和 Windows 环境进行某些自定义。一种需要对 DNS 用一些小技巧，使得备用服务器能够获取故障服务器的名称和 IP 地址。这种方法的优点是客户端工作站方面会比较简单，因为 Outlook® 会认为它仍在使用相同的服务器。
第二种方法使用一台运行 Exchange 的备用服务器，其上存储了数据库的副本，但并未进行任何装载。出现故障时，该备用服务器将通知 Active Directory 所有用户的邮箱已移到它那里。然后将运行一个脚本或发布一个组策略，告知客户端它们位于不同的邮件服务器上。Outlook 2007 能够识别 Active Directory，这使得该过程变得更简单，因为它自己就会自动识别出这些映射。

使用 MSCS 的本地群集
可用性连续性的高端是 Microsoft 群集服务 (MSCS)；Exchange 是能够识别群集的应用程序。群集可在两台或更多台计算机之间共享信息，这样如果其中一台出现故障，其他计算机可接管其工作。今天，大多数 Exchange 群集都有两个或四个节点，最多可以使用八个节点。始终会指定一个节点作为被动节点——可在 Windows Server 正在运行且安装了 Exchange Server 的情况下操作，但没有活动的邮箱。Exchange 2003 提供了一种两节点的主动/主动群集，但是由于性能负载的原因，现在不建议使用它，Exchange 2007 将不再对其提供支持。
针对 Exchange 2003 的群集方式，包含一个被动节点的 Exchange 2007 群集仍然可以使用一个单一的共享存储阵列。虽然群集品质的存储阵列通常具有许多冗余功能来防范多种类型的故障，但它们仍然只提供一个数据副本，这留下了一个隐患。这就是为什么这些群集被称为单副本群集 (SCC) 的原因，以区别于 Exchange 2007 中的多副本群集 (MCC) 所带来的下一代数据保护手段。我们将在说明灾难恢复时进一步讨论 MCC。

本地连续复制
本地连续复制 (LCR) 是 Exchange 2007 的一项新功能，它提供了一种改进方式来维护同一服务器内 Exchange 数据库和事务日志的第二份副本。这为使 Exchange 数据库和事务日志分别位于不同 RAID 阵列中的最佳实践添加了一个冗余层：利用 LCR 可以在存储数据库主副本的阵列中存储一份日志的辅助副本，然后在存储日志主副本的阵列中存储一份数据库的辅助副本（参见图 3）。如果其中任何一个 RAID 控制器或阵列本身出现故障，您仍然可以使用另一个阵列中的数据库和事务日志。通过这种方式，您可以继续操作——虽然这会令人感到有些紧张，并且性能会有所降低——直至能够将出现故障的阵列重新建立起来。
图 3 配置 LCR
图 3 配置 LCR
LCR 是一种本地操作连续性解决方案，而不是一种备份方案，因此您仍然需要一个完整备份策略。使用 LCR 还有一个性能损失，因为您的服务器现在要制作数据库和事务日志的两份副本。此外，在 Exchange 2007 的实现中存在一些限制，使得 LCR 只适用于较小的组织，因为 LCR 只支持某个存储组中的一个数据库，以及某个组织中的一个公用文件夹数据库。
使用 LCR 恢复功能实现的故障转移不是瞬间即可完成的——必须要由一位有经验的 IT 专业人士通过运行脚本来备份 Exchange。该过程要求执行在 Exchange 管理控制台之外运行的 Exchange 命令行管理程序命令。
Exchange Server 2003 Enterprise Edition 使组织最多能够运行 20 个 Exchange 数据库（四个存储组，每组最多五个数据库），而 Exchange 2007 Enterprise Edition 允许使用多达 50 个存储组，每组都有自己的数据库。事务日志也从 Exchange 2003 中的 5MB 文件减少为 Exchange 2007 中的 1MB 文件。这两项变化都是设计来支持 LCR 的——外加群集连续复制 (CCR)，它在某种程度上也与此相关。
中小型组织将使用 LCR 以便为其 Exchange 操作提供改进的数据保护。LCR 易于实现，但仍然需要手动干预。作为一种“同一服务器/本地磁盘”解决方案，LCR 只是迈向改进的操作连续性的第一步。虽然它确实能够针对 RAID 阵列和 RAID 控制器的故障起到保护作用，但多个磁盘或 RAID 控制器同时发生故障的可能性是很低的。多数情况下，故障方案涉及整个服务器的崩溃，这将我们引向了 Exchange 保护中的下一步。

第三方本地非主机复制
为进一步提升 Exchange 的恢复能力，第三方供应商开发了一些利用“非主机”复制方式的产品，使用 Exchange 日志文件在另一台计算机上保留一份 Exchange 数据库的备用副本。在这种情况下，数据保护或归档解决方案将执行一个 Exchange 的 ESE 完整备份，将其备份到另一台计算机上，然后在 Exchange 关闭事务日志时立即将其取出。它会将这些事务日志插入到其 Exchange 数据库副本中，以使其始终保持最新状态。如前所述，这些日志很小（在 Exchange 2003 中为 5MB，在 Exchange 2007 中为 1MB），因此当完整备份完成后，将这些日志文件复制到非主机服务器上几乎不会给 Exchange 服务器带来任何系统开销。

级别 3：灾难恢复和高可用性
灾难恢复是指在主要数据中心不可用时将它重新建立起来并恢复运行的能力。Exchange 需要具备有效的灾难恢复能力，因为电子邮件和日历功能在今天已经成了许多组织的命脉。
有些公司将其传统的离站存储磁带备份作为某种形式的灾难恢复措施，但是如果您唯一的数据中心遭到火灾或水灾破坏，那么即使用车拉来成卷的磁带也毫无意义。灾难恢复实际上不仅仅是将数据移到另一处位置，还涉及恢复应用程序并使之运行的技术和过程。要实现有效的灾难恢复，需要让主系统和辅助系统相隔一定距离。地点相隔距离的远近取决于考虑要克服的灾难的量级。如果您担心失火，那么或许园区内的另一栋建筑已足够远。但是，涉及火车或飞机失事的基础设施灾难可能会影响 1 英里或 1 英里以上的半径范围。许多灾难是区域性的：洪水、冰雹、地震甚至停电等。通信也可由于自身的灾难而陷入困境——从切断与您的 ISP 之间的链接的反铲问题到拒绝服务攻击，直至针对一般商务的 Internet DoS 攻击。
在实践中，如果您的组织已经在多个地点配备了 IT 员工，那么针对您要防范的灾难类型，其中一处位置可能会符合您的远程操作连续性标准。与求助于灾难恢复服务提供商或在新位置租用空间相比，使用自己的设施和员工要更经济。
灾难恢复的终极目的是给人一种感觉：使客户确信您的业务仍在运行中。当灾难袭击某个城市或地区时，人们对此可以理解；但是如果您的公司在几天到一个星期之内没有恢复正常，那么很有可能客户和供应商会做出最坏的猜想；许多公司都因此而落败下去。对于客户来说，您的运营必须看上去已经恢复正常，以使他们确信您的业务仍在继续。客户对恢复的及时性存在不同认识：与办公家具供应商的暂停运营相比，他们对金融服务公司的暂停运营更易失去耐心，这很容易理解。

灾难恢复要求
如果希望能够在灾难后使 Exchange 重新在线，需要将其数据复制到一个辅助地点，并使用适当复制技术将数据提供给一个已准备好运行这些数据的预热 Exchange 服务器，然后通知 Outlook 客户端它们的邮箱已经移走。
Exchange 在复制方面的要求较高，尤其是在距离较远时。对于真实的事务数据库，每个写入的顺序极为重要。使问题变得更加复杂的是，Exchange 使用 SMTP 传输协议在服务器之间传输所有事务和系统信息，而这是一种非常占用带宽的协议。此外，对于 Exchange 群集，必须每隔 500 毫秒在系统之间传递一个检测信号。如果辅助节点没有收到该信号，则可能会触发故障转移。
解决这些问题的复杂性或许是 Microsoft 直到今天才在 Exchange 2007 中涉足这一领域的原因。在 Microsoft 尚未涉足之前，若干第三方解决方案已经开发出来，它们使用基于主机或基于阵列的复制功能来复制 Exchange 数据。
供应商意识到他们可以通过将节点分散到不同位置来扩展一个群集，这称为扩展群集。今天，要实现扩展群集，最常见的方式是使用通用的第三方数据复制产品或那些专门为扩展 Exchange 节点而开发的产品。您可以使用 MSCS 完成此任务，但 WAN 上的子网要求是个难点。向远程数据中心提供可靠的高带宽连接是很复杂的，再加上群集，无疑会增加建立、维护和定期测试灾难恢复系统的成本，并会提出更高的人员要求。

群集连续复制
Microsoft 通过 Exchange 2007 中的群集连续复制功能扩展了它对群集的支持。CCR 扩展了 LCR 的功能，现在能够维护两个 Exchange 数据库和事务日志副本，在两个群集节点上实现同一设想。灾难恢复意味着需要使主系统与辅助系统在地理上彼此分离，在 Windows Server 2008（原代号为“Longhorn”）使得扩展群集成为可能之前，Microsoft 多副本群集 (MCC) 无法跨越很远的距离。
使 MCC 节点能够具有单独的数据副本的技术称为多数节点集 (MNS)，它是指一个选举过程，其中两个或多个节点决定由谁来保存数据的活动副本。当出现故障时，其余节点将进行一次新选举以确定由谁接管作为新的主处理/数据服务器。支持这种技术民主行为的是 CCR，它将确保每个节点都具有最新的数据库。使用 CCR 的 Exchange 2007 群集被限制为只有两个节点。
在大型组织中，Exchange 服务器通常在服务器上配置本地系统磁盘，然后通过 SAN 连接到 Exchange 数据库（使用 SCSI、光纤或 iSCSI 磁盘阵列）。对于 MCC/MNS 群集，一个有趣的问题是高端的 Exchange 存储是否会退化到为每个节点使用本地 RAID 阵列。如果 MNS 群集的目的是使每个节点具有自己的独立存储，那么将每个节点指向旨在提供公共存储的 SAN 是否仍然有意义呢？
在一个中规中矩的 MCC/MNS 群集方案中，主节点会将存储放在 SAN 上，而辅助群集节点会使用本地磁盘或成本较低的 iSCSI SAN。该辅助节点可远离主数据中心，位于一个不具有 SAN 基础结构的远程位置。
不管其如何展开，使用 MNS 和 CCR 的 MCC 都是在冗余和增强的可用性方面取得的另一项进步，因为此时有多台计算机能够进行故障转移，并且数据在单独的存储元素上进行复制。不过，在 Windows Server 2008 出现之前，这仍然完全局限在一个数据中心内。Windows Server 2008 将提供扩展群集的本机支持，使 MNS 群集中的节点能够在地理位置上相隔任意远的距离——前提是节点之间的网络延迟能够稳定地低于 500 毫秒。直到这时（以及从此以后），第三方群集技术才能基于 Microsoft MNS 和 CCR 提供扩展群集所需的地理分隔，以便获得有效的灾难恢复解决方案。
群集属于灾难恢复连续性的高端领域，而 CCR 可恰当地定位为 Exchange 的高可用性功能。即使这种结合具有较高的成本和人员要求，但对于希望获得一个同构的 Microsoft 环境的用户来说，这将是一种令人兴奋而先进的解决方案。

第三方远程操作连续性
一旦面世，Microsoft 解决方案和第三方扩展产品就将占据灾难恢复连续性的绝对高端，这一点勿庸置疑。数秒内即可自动完成故障转移——几乎尽善尽美。不过，并非所有公司都需要如此级别的可用性和业务连续性，有些也无力为此支付数十万美元的费用。对许多公司来说，能够在几分钟内完整恢复 Exchange 的可靠解决方案已经足以提供他们所需的所有操作连续性。
例如，Mimosa Systems, Inc. 将一个数据中心内的操作连续性扩展到远程连续性。在远程位置，Mimosa DR 维护了一个 Exchange 副本，使用来自主 Exchange 服务器的事务日志使其保持最新状态，并时刻准备着将此有效副本提供给您的备用 Exchange 服务器。远程 Exchange 服务器使用标准服务器硬件，并且就像单数据中心实现一样，您可以使其保持预热状态，时刻准备着在出现灾难时激活。一旦发生灾难，远程位置的操作员可以启动故障转移并执行故障转移，包括装载备用数据库文件以及重新映射邮箱和 Outlook 配置文件。但是需要注意，这种第三方解决方案存在一定的支持局限，知识库文章“Microsoft 针对修改或提取 Exchange 数据库内容的第三方产品的支持策略”对此进行了定义。

总结
Exchange 数据保护提供了一系列技术和过程，根据成本和功能性可将其分组为三个级别。开始考虑 Exchange 数据保护的要求时，您应当考虑利益相关者所能接受的停机时间。优异的性能和快速的恢复要求付出更高成本，高端选项都将超过六位数。更经济的解决方案旨在努力提供更高水平的可用性，但无法达到最高水平。您应根据自己组织的需要进行选择。
Service Pack 1 for Exchange 2007
Service Pack 1 (SP1) for Exchange 2007 当前正在进行测试版测试，已经确定其中将包含管理员所欠缺的许多功能，包括对 OWA 的增强、控制台中的附加 GUI 功等。
对负责制定恢复解决方案的管理员来说，尤为有用的是 Exchange 2007 SP1 还包含第三种可用性解决方案，作为对 LCR 和 CCR 的补充：辅助连续复制 (SCR)。这是一种折中方案，Microsoft 旨在借此获得优秀的可恢复性，同时避开完全“高可用性”的复杂性。
SCR 允许将 Exchange 数据库和事务日志复制到与邮箱通常所驻留的服务器不同的 Exchange 服务器上。该 SCR 目标可以是本地的，也可以是远程的，并且可以是一个备用 Exchange 服务器，或是一个群集。但是，SCR 并不要求在任一位置上存在群集；它与 CCR 的不同之处在于其目标是一个备用环境，并且故障转移是一个手动过程。注意，您仍然需要通过连线获得第一个大型副本——实质上是一个完整备份。您可能需要经常进行这种大型复制，并且必须清楚这对您网络的影响，就像使用 CCR 和第三方解决方案一样。我预期 SCR 和 CCR 以及各种能够提供类似、有时甚至更好功能的附加产品将能得到广泛应用。

Lee Benjamin管理着 ExchangeGuy 咨询服务，直接面对客户并为 Microsoft 合作伙伴提供建议。Lee 也是世界上最大的 Exchange 用户组 ExchangeServerBoston 的主席，以及 BostonUserGroups 的主管。Lee 还是 Exchange 的 MVP 和 Microsoft 认证培训师，并经常在行业会议上发表演讲。
© 2007 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.


 通信: 提高 Windows Mobile 6 的安全性
通信 Matt Fontaine

提高 Windows Mobile 6 的安全性
概览:
  • 设备上的安全
  • Exchange Server 安全
  • 网络安全

移动设备可以提高世界各地工作人员的工作效率，让他们可以访问公司信息，并让他们甚至在离开物理办公室时
也能保持联系。这样确实能提高工作效率：只要打开移动设备，开始工作即可。
但是移动设备存在另一问题，即 IT 专业人员面临着保持虚拟办公室的安全和稳定这一艰难任务的挑战。从他们的角度来看，每个移动设备都是一个容易被侵入的潜在网络安全漏洞，都有可能导致数据被窃取。构建更安全的移动设备部署非常关键，但同时必须通过提供无缝、直观的用户体验来取得平衡。
Microsoft® Windows Mobile® 6 及其前身，含消息传送和安全功能包 (MSFP) 的 Windows Mobile 5.0 包含了很多功能，帮助您轻松即可保护公司基础架构，而且不会给您的用户带来多大的不便。使用 Microsoft Exchange Server 作为消息平台可进一步增加可用的安全选项。在本文中，我将阐述如何使用 Windows Mobile、Exchange Server 和一些网络安全最佳实践作为保护贵公司移动设备的基础。

移动通信体系结构
在计划或升级移动部署时要考虑三个层：设备、邮件服务器和网络（参见图 1）。在设备级别，主要的挑战包括只允许授权访问设备以及防止设备上未经授权的应用程序。Windows Mobile 可以通过 PIN 验证和密码保护、设备超时锁定，以及在设备的记忆丢失或被盗时本地或远程“擦掉”或擦除设备内存等功能，来帮助阻止对设备本身的未经授权的访问。支持通信通道和可移动存储的数据加密。阻止未经授权的应用程序（例如病毒或间谍软件）安装到或访问设备的关键部分也很重要。将管理角色定义、应用程序访问层、代码签名设置、安全设置和安全证书结合起来，也可帮助获得设备级保护。
图 1 移动通信的层次
图 1 移动通信的层次
接下来一个安全层是邮件服务器，例如含 Service Pack 2 (SP2) 的 Exchange Server 2003 或 Exchange Server 2007。这一层包括邮件安全——使邮件安全传出和传入设备的技术，以及通过 Exchange ActiveSync® 实现的邮件服务器和移动设备之间的交互。不要求 Exchange Server 使用 Windows Mobile 设备，但是使用 Exchange 可以带来成本、可伸缩性、性能和管理方面的优势。
优异的设备级和邮件服务器安全实践固然重要，但是保护网络层也很关键。根据最佳实践配置贵公司的网络并实施强大的安全协议，可以帮助防止对网络的破坏，即使有一个或更多移动设备遭到破坏也不怕。

设备上的安全策略
防御安全隐患的第一道防线是基于 Windows Mobile 的设备本身。Windows Mobile 操作系统提供各种支持身份验证、存储卡加密、虚拟专用网络 (VPN)、Wi-Fi 加密的设备级安全服务和安全套接字层 (SSL) 服务。设备级安全包括管理谁有权访问设备及其数据、控制哪些应用程序可以在设备上运行，以及创建数据传入和传出设备的方式。总之，管理员在含 MSFP 的 Windows Mobile 5.0 和 Windows Mobile 6 上设置和实施安全策略时有很大的灵活性。
用户访问通过 PIN 或密码身份验证来管理。设备可设置为在一段时间的非活动状态后或在关闭后自动锁定，用户需要再次解除对设备的锁定后才能使用（参见图 2）。用户访问控制的细节由安全策略设置，它可根据管理员的安全角色进行更改。
图 2 设置密码策略
图 2 设置密码策略
安全策略定义移动设备安全的所有级别（参见图 3）。谁有权设置和更改这些安全策略由安全角色决定。“管理员”角色通常预留给移动操作员，他/她可以完全控制安全策略的设置。“企业”角色为 Exchange 所用，以管理一些设备策略，这些策略由 Exchange 管理员配置。根据与设备提供商的协议，您可能可以自定义贵公司的安全策略。
Figure 3 移动设备的安全策略 (Close Figure 3)

策略 移动设备
阻止对设备的未经授权的渗透

含有 MSFP 的 Windows Mobile 5.0

指定用户必须始终验证设备以解除其锁定，或者允许用户在桌面输入 PIN。
默认角色：管理员、企业。

Windows Mobile 6

允许或拒绝用户更改可移动存储媒体移动加密设置的权限。
默认角色：管理员、企业。
指定用户在设备锁定处于活动状态下进行连接时是否必须验证设备。默认角色：管理员、企业。
在设备被盗或丢失的情况下保护敏感数据

含有 MSFP 的 Windows Mobile 5.0

指定用户必须始终验证设备以解除其锁定，或者允许用户在桌面输入 PIN。
默认角色：管理员、企业。

含有 MSFP 的 Windows Mobile 5.0 和 Windows Mobile 6

指定设备是否必须配置密码。配置本地和远程设备擦除设置。
默认角色：管理员、企业。
Windows Mobile 所使用的可自定义的身份验证方法受本地身份验证插件 (LAP) 控制，它可以与本地身份验证子系统 (LASS) 交互。这个技术使 Exchange Server 可以精确地控制设备配置，例如通过强制执行密码长度和强度要求或启用简单的 PIN 身份验证。
Windows Mobile 6 有一组扩展的 LAP 功能，它们可以通过使用 Exchange Server 2007 来进行配置。您可以启用 PIN 模式识别（例如，拒绝使用简单的模式，如“1111”或“1234”），配置密码或 PIN 过期时段，允许用户请求基于某个条件重设 PIN，或保留 PIN/密码历史记录，以阻止用户在被要求创建新 PIN 或密码时重新使用这些旧的 PIN 或密码。

保护设备上的数据
当不正确的 PIN 或密码的输入次数超过管理员设置的限制后，本地设备擦除功能会硬重置这些设备，从而擦除它的记忆，包括用户身份验证凭据。该限制会被设置成 Exchange Server 安全策略的一部分。每发生两次不正确的输入后，设备会提示用户输入结构化的密钥字符串继续（参见图 4）。这可以保护设备不会由于不小心按错键而被意外擦除。在使用 Windows Mobile 6 和 Exchange Server 2007 时，远程擦除存储卡也是有可能发生的。
图 4 强制使用 PIN 和密码
图 4 强制使用 PIN 和密码
如果有人将内含敏感公司数据的 2GB 的存储卡落在了出租车上，锁定设备并无多大用处。幸运的是，您可以使用 Windows Mobile 6 来解决这个问题。它可对存储卡数据加密，这样只有曾经对该存储卡进行过写入操作的设备才能读取它。正如 Windows Mobile 6 的许多其他增强的安全功能一样，Exchange Server 2007 可用来以无线方式提供这个安全功能。存储卡加密对用户而言，在很大程度上是透明。Exchange Server 2007 会让管理员选择用户是否可以更改其存储卡加密设置。
应用程序是否可以在 Windows Mobile 设备上运行是根据三个权限级别来确定的：特权、普通和阻止。特权级别的应用程序（由特权证书存储区中的证书签名）可写入注册表和系统文件，还可以安装证书。同台式计算机或服务器一样，可以更改操作系统环境的应用程序越多，破坏这个环境的可能性就越大。减少具有“特权”级权限的应用程序的数量通常是一个比较好的做法。大多数应用程序只需要在“普通”级别运行（由 Unpriv 证书存储中证书签名的应用程序或用户已同意运行的未签名应用程序），该权限允许它们执行（但阻止访问）系统文件。阻止的应用程序是指被阻止，并且由于签名或用户操作不正确而无法运行的应用程序。
设备可以有一层或两层安全访问配置。使用一层访问配置，未签名的应用程序要么以“特权”权限运行，要么被阻止而无法运行。如果策略检查成功或如果用户允许应用程序运行，则两层访问配置会在“普通”级别运行未签名的应用程序。根据设备设置，可以提示用户是否执行未签名的应用程序。
电子证书，最常用的个人、设备和应用程序身份验证的形式之一，是设备、服务器和网络级别的 Windows Mobile 安全的重要组成部分。Windows Mobile 操作系统在设备上的不同证书存储中存储了好几种类型的证书。对于应用程序，证书会确定哪些是可以安装和运行的。对于要在不提示用户的情况下在基于 Windows Mobile 的设备上运行的应用程序，它必须要经过证书的签名，证明它已被 Microsoft Mobile2Mobile 程序接受。应用程序根据与它们相关的证书被授予各种权限级别。
对于网络身份验证，每个移动设备都带有很多由证书颁发机构 (CA)（如图 5 所示）颁发的受信任商业根证书。邮件服务器（例如 Exchange Server）会在与设备建立 SSL 连接之前验证设备根证书的真实性。如果贵公司使用自定义证书，也许可以将它们安装在所购买的基于 Windows Mobile 的设备上，或者可能需要创建一个新的证书。有关这一点，我会在本文的“网络安全”部分做进一步的讨论。
图 5 管理电子证书
图 5 管理电子证书
ActiveSync 和 Internet Explorer® Mobile 可使用 SSL 来帮助保护设备与公司 Web 服务器之间的数据传输。无论可同步化 Microsoft Exchange 数据，可配置设备或下载应用程序的连接是否存在，都是这样。SSL 会对带有 128 位 RC4 或 3DES 密码器的通信通道加密，因此数据无法被外部各方读取。Windows Mobile 还支持 VPN，用户可以在通过 Internet 访问服务器时使用数据包加密来提供与专用线路类似的安全性。

Exchange Server 安全
基于 Windows Mobile 的设备并不要求运行 Exchange Server，但是这两个系统已设计为一起紧密配合运行，提供了一个强大的端到端移动消息传送和工作效率解决方案。自含有 MSFP 的 Windows Mobile 5.0 发布以来，ActiveSync 已得到增强，可允许远程管理 Windows Mobile 设备的设置。它提供一种简单、有效的方法，让您可以在大多数 Windows Mobile 设备中传播和强制实施全局安全设置。
ActiveSync 在 Microsoft Windows Server 2003 的应用程序/Web 服务器组件 IIS 上运行。IIS 提供的内置安全可帮助保护 ActiveSync 本身不受来自网络的攻击。因为 Microsoft Office Outlook® Web Access (OWA) 也是基于 IIS 的，所以您可以对 ActiveSync 和 OWA 使用同一个安全证书。
当 ActiveSync 用于传播 Enterprise 策略时，这个策略会被发送到下一次与 Exchange Server 同步的设备。用户必须接受更改，否则不允许连接到服务器。很多网络会处理各种设备，包括不能接受复杂安全策略的过时硬件。如果必要，您可以从安全策略需求中排除某些设备（例如过时硬件），这样它们就可以继续连接。
Exchange Server 2003 SP2 和 Exchange Server 2007 有一些不同的安全策略控制功能。Exchange Server 2003 SP2 可用来指定最小密码长度（4 到 18 个字符），要求密码必须包含数字和字母，并设置设备锁定之前可处于非活动状态的时间长度。此版本的 Exchange Server 还可以设置安全设置被推送到设备的频率，并允许按照上述情况排除过时设备。
随着 Exchange Server 2007 版本的发布，ActiveSync 移动设备管理功能已得到了增强，包含所有的 Exchange Server 2003 SP2 功能，以及下列功能：
  • 允许或不允许简单密码（如“1234”或“1111”）
  • 启用或不启用附件下载
  • 要求存储卡加密
  • 设置最大附件大小
  • 允许用户通过 OWA 恢复设备密码
  • 启用对通用命名约定 (UNC) 和 Microsoft Windows SharePoint® Services (WSS) 文件的访问
使用 Exchange Server 2007，IT 专业人员可灵活地量身定制针对每个用户和设备的策略，以便管理用户组的策略，并可以从安全策略中彻底排除某个用户。

远程访问擦除
除了前面详细介绍的本地设备擦除之外，您还可以通过 Exchange Server 2003 SP2、Exchange Server 2007 或 OWA 远程擦除基于 Windows Mobile 的设备。远程擦除在进行同步化时执行，即使您没有使用 ActiveSync 安全策略也无妨。设备无法停止远程擦除硬重置。数据、设置和安全密钥都会被重复的零覆盖，这对恢复不是核心操作系统组成部分的数据造成了极大的困难。

网络安全
网络安全同设备和邮件服务器组件一样，对移动安全同等重要。它也是最容易受您控制的移动基础结构组成部分。即使一个或多个移动设备碰巧都遭到了破坏，根据最佳实践来配置贵公司的网络并实施相应的安全协议有利于阻止对网络的破坏。
Windows Mobile 可用于各种网络类型。使用标准的 Internet 安全协议和防火墙，可以设计出一个适合您性能、可伸缩性和安全需要的解决方案。
当邮件服务器被保留在公司网络中时，它们可能会得到作为 Internet 和公司网络之间缓冲的边缘防火墙的保护。Microsoft Internet Security and Acceleration (ISA) Server 2004 或 ISA Server 2006 都具有专门设计用于特殊用途的功能，它会在将传入数据包传递给 Exchange 服务器之前，检查所有的传入数据包以确定它们的身份，然后通过 Internet 将出站信息发回客户端。
配置 ISA Server 要求您启用 SSL 加密，并指定端口 443 作为 Exchange Server 通信的 SSL Web 侦听端口。这通过将其限制为单个端口最小化了来自 Internet 的风险。同时，应要求所有的客户端在通过 ActiveSync 连接之前建立 SSL 链接。
ISA Server 可以预先验证 Web 应用程序（如 OWA）用户，以帮助阻止未经验证的用户访问应用程序服务器。ISA Server 2006 通过充当基于 Windows Mobile 的设备的 SSL 终止点，改善了 ISA Server 2004 的 SSL 桥接模式。这允许基于 Windows Mobile 的设备验证 Exchange 服务器，可在不与其直接连接的情况下，依靠 ISA Server 2006 来回传递通信。由于建议的 ISA Server 2006 位置在外围网络，这样公共 Internet 空间与 Exchange Server 前端之间就有了一个额外的安全层。

身份验证
有两种基本的身份验证类型可供选择：基本类型和基于证书的类型。基本身份验证是指 Windows Mobile 客户端和 Exchange 前端服务器之间是标准的、启用名称和密码的、基于 SSL 的连接。它仍要求证书，因为 Exchange Server 会在验证之前寻找设备上匹配的根证书。Windows Mobile 和 IIS 允许您使用大量与 SSL 相关的加密方法。
基于证书的身份验证在含有 MSFP 的 Windows Mobile 5.0 和 Windows Mobile 6 中都有提供，它使用的是传输层安全性 (TLS) 而不是 SSL 基本身份验证。除了根证书以外，TLS 还要求每个用户具有一个含公用和专用密钥的证书。因为 TLS 使用的是加密密钥（最多 2,048 位），而不是密码，因此该协议提供了更严格的身份验证。
在 Windows Mobile 6 中，要使用“桌面注册”注册一个用户证书，要求将设备插接到与证书注册服务器同一域中的台式计算机。用户使用密码、智能卡或其他方式验证注册，然后将设备连接到台式计算机。然后用户可以通过台式计算机访问证书系统，按顺序将证书安装到移动设备上。桌面注册可以用于各种 Windows Mobile 安全性用途，包括证书续订，以及 ActiveSync 身份验证证书、SSL/TLS 身份验证证书、802.1x Wi-Fi 证书或 S/MIME 电子签名证书的分发。
SSL 等安全协议可以保护传输时的邮件数据，但是一旦它们位于 Windows Mobile 设备或 Exchange 服务器上就不会对它们加密。S/MIME 是一种熟悉的支持电子签名和/或加密电子邮件的 MIME 电子邮件标准的安全形式。它提供位于和高于 SSL 传输层加密的额外层的保护。

总结
我们需要注意组成创建足够安全的基础结构的解决方案的每一个层次。Windows Mobile、Exchange Server 和 Microsoft 网络安全产品（如 ISA Server）联手解决了管理移动基础结构的难题。这有利于减轻 IT 部门的一些压力，从而可以将重点从应付移动设备带来的安全挑战，转移到它们实现的工作效率提高方面来。

特别感谢 Kathy Esser、Katharine Holdsworth、Sarah Norton 和 Chip Vollers 对撰写本文给予的帮助。

Matt Fontaine是 BuzzBee 公司的一位技术撰稿人。


 通信: 公用文件夹的强大替代方法
通信 Alan Maddison

公用文件夹的强大替代方法
概览:
  • 共享日历和联系人
  • 使用博客和 Wiki 进行通信
  • 共享和管理文档

自从第一版 Microsoft Exchange 起，公用文件夹就已经出现了，它最初的目标是提供一个可以共享文档、通讯组列表和自定义应用程序开发的基本平台。然而几乎从一开始，
管理和使用已成为许多 Exchange 环境日益复杂的部分一直是管理员的一个难题。尽管 Exchange Server 2007 在管理公用文件夹方面已实现了一些重要改进，但是挑战依然存在。公用文件夹就是没有提供现在企业所需要的强大的协作和文档管理平台。
Microsoft 曾宣布 Exchange Server 2007 可能是支持公用文件夹的产品的最后一个版本。但是公用文件夹还是得到了全面的支持，并且随着 Exchange Server 2007 的发布这种支持还会持续 10 年，这是检验另一个方法的好时机。
幸运的是，Microsoft 在发布 Microsoft® Office SharePoint® Server (MOSS) 2007 时提供了一个引人注目的选项。MOSS 2007 提供了一个 IT 管理员和企业更换和超越公用文件夹所能提供的功能所需要的平台。在本文中，我将阐述 MOSS 如何提供一个稳健而强大的框架，为您带来比 Exchange 公用文件夹多得多的功能。另外，我会重点阐述如何针对共享日历、联系人和文档共享等通常使用公用文件夹的任务使用 SharePoint。
请不要忘记您将仍然需要公用文件夹，直到您至少更新了您的客户端为止。出于种种原因，从 Outlook 97 到 Outlook 2003 的 Microsoft Outlook® 客户端都需要公用文件夹，包括脱机通讯簿、企业窗体库和闲/忙查询。转移到 Outlook 2007 和 Exchange Server 2007 后，就完全可以在您做好准备的情况下再摆脱使用公用文件夹。

SharePoint 日历
共享日历是公用文件夹的一种常见用途，SharePoint 可以非常轻松地用 SharePoint 日历替换公用文件夹日历。SharePoint 网站的默认安装已包括一个日历，不过您可能需要创建多个日历来满足贵公司的需要。为了阐述这一点，我将逐步向您介绍为人力资源团队创建共享日历的方法。第一步是选择“查看所有网站内容”，它通常显示在 SharePoint 网站的左上角（参见图 1）。
图 1 创建新网站内容
图 1 创建新网站内容
选择“查看所有网站内容”后，单击“创建”按钮（如图 1 所示）。“创建”页面加载后，您就会看到默认内容类型选项（如图 2 所示）。为了创建日历，必须选择“跟踪”栏中的“日历”。然后必须填写名称和说明字段，并选择是否要将日历纳入“快速链接”部分。
图 2 “创建”页面显示很多默认选项
图 2 “创建”页面显示很多默认选项
至此，日历已创建成功。用户可以选择是通过 SharePoint 网站还是直接从 Outlook 查看共享的日历。若选择执行后一个操作，用户只需要使用 Web 浏览器连接到该日历，然后打开“操作”菜单，选择“连接到 Outlook”选项。
当第一次连接成功后，Outlook 会显示一个安全警告，提醒用户应该只连接到已知、可信的来源。一旦选择了“是”，该日历就会连接到 Outlook。图 3 显示了默认视图，即 SharePoint 日历和 Outlook 日历并排显示。
图 3 并排显示 SharePoint 日历 和 Outlook 日历
图 3 并排显示 SharePoint 日历 和 Outlook 日历
日历连接到 Outlook 后，就会执行双向同步。任何通过 Outlook 输入的事件都会与 SharePoint 同步，并且所有查看日历的用户都会看到更新的条目。此外，如果您已启用 SharePoint 中的 SMTP 支持，则事件可以以电子邮件的形式直接发送到日历，然后 SharePoint 会添加这些条目。

SharePoint 联系人
许多公司都使用同样依赖于公用文件夹的共享联系人的功能。相应的，SharePoint 提供了另一种更稳定可靠的方法，使创建和管理联系人列表变得非常简单。继续以相同的示例为例，现在我向您介绍如何为该示例中的人力资源部创建共享的联系人列表。
再一次选择“查看所有网站内容”，然后单击“创建”按钮。现在选择“通信”栏中的“联系人”链接。您会看到一个屏幕，在这里您可以提供“姓名”、“说明”和“快速链接”配置的信息（参见图 4）。填完这些信息后，只要单击“创建”按钮，便可创建新的联系人列表。
图 4 填入姓名、说明和快速链接配置
图 4 填入姓名、说明和快速链接配置

用户通信
您还可以使用 SharePoint 创建讨论板（也称为讨论列表）。与“日历”和“联系人”一样，创建过程非常简单——选择“查看所有网站内容”，单击“创建”按钮，然后选择“通信”栏中的“讨论板”链接。正如您前面所执行的那样，输入“姓名”、“说明”和“快速链接”配置的相应信息，然后单击“创建”按钮。图 5 显示了包含一些示例文章的讨论板。
图 5 包含几篇文章的讨论板示例
图 5 包含几篇文章的讨论板示例
除了讨论板之外，现在 SharePoint Server 还支持两个很流行的通信工具——博客和 Wiki。博客和 Wiki 不能使用公用文件夹，它们是 SharePoint Server 2007 的新功能，这两个工具为功能集提供了让人兴奋和有用的协作功能。
博客提供了一个交互式论坛，在这里博客作者可以轻松地将自己的想法和观点张贴到网站上，与他人分享。通常这些文章是分类的，以便让读者更容易找到感兴趣的文章。同时，读者还可以对博客作者的意见给出回应。例如，公司可以让行政管理层的成员来维护博客。它可以成为与员工沟通的有效工具，让员工分享想法的途径，并可保持各个级别的交流通畅。
在 SharePoint 上创建博客非常简单。第一步是选择“查看所有网站内容”，单击“创建”按钮，然后单击“网页”栏下的“网站”和“工作区”。将显示“新建 SharePoint 网站”页面，在这里您必须提供该网站的“标题”、“名称”和 URL。然后您可以为该网站选择一个模板，在本例中请选择“博客”模板。最后三个配置选项是针对权限、导航和网站目录列表的。完成所有要求的选项后，请按一下“创建”按钮。实际上这会在您的顶级网站中创建一个子网站，子网站内是提供博客功能的库和列表。此过程完成后，您就可以进入新博客了。
Wiki 是另一个为实现更具协作性的编写而设计的出色工具。用户可以添加、删除和编辑网站上的内容，以及将很多页面链接在一起。创建 Wiki 最简单的方法就是选择“查看所有网站内容”，单击“创建”链接，然后选择“库”栏中列出的“Wiki 网页库”。在您填妥要求的“名称”、“说明”和“导航”配置字段后，按一下“创建”按钮，便完成了。有关使用 SharePoint 中 Wiki 的更多信息，请参阅《TechNet 杂志》2007 年一月期中的文章“在工作时使用 WIKI”。

SharePoint 库
公用文件夹实际上成了文档存储库，成了一个用户可以轻松地访问和共享文件的中心位置。多年以来，Exchange 管理员已经发现，这是让公用文件夹变得如此不实用的主要用途之一。这不仅导致公用文件夹数据库的 Exchange I/O 增多，也影响了整个 Exchange 基础结构内的复制。SharePoint 库提供了另一种绝佳的方法，可卸载 Exchange 及其资源的需求。
SharePoint 库是 SharePoint 网站内的一个位置，允许您存储和管理文档。该库有好几种类型，包括图片、Wiki 网页、表单和文档。在考虑替换公用文件夹时，文档库是最合适的选择。文档库支持在 SharePoint 网站中存储、管理和创建（在某些情况下）文档。
许多不同类型的文件可以存储在文档库中，除了某些文件类型（如可执行文件和脚本）之外，由于安全原因它们都受默认值限制。然而这些限制可通过 SharePoint 中心管理网站的“操作”部分来配置。
MOSS 的默认安装包括可以进行自定义的文档库。大多数公司会想要创建多个库来支持公司中的不同业务单位。这通过使用 SharePoint 提供的工具很容易做到。例如，要为人力资源部署文档库，请选择“查看所有网站内容”，单击“创建”链接，然后选择“库”栏中列出的“文档库”。然后您会看到您需要配置的一些设置——提供库的名称和说明，指定是否将库纳入“快速链接”部分，选择是否应启用版本管理，以及选择在库中直接创建的新文档的默认格式。
请特别注意“文档版本历史记录”选项。它的默认选择是“禁用”。然而，版本管理很有用，并且适合于很多环境。除了存储文档的历史副本之外，此功能还会跟踪何时进行更改、谁进行更改，并提供查看和恢复以前版本的功能。
图 6 显示了新创建的具有一些已上传文档的文档库。创建文档库后，就可以通过 Microsoft Outlook 和 Windows® Explorer 使这些存储库可用。Outlook 允许您脱机访问文档库的内容，并将只读副本提供给不能访问该网络的用户。提供 Windows Explorer 的访问权限利用了“网上邻居”的优点。通过输入文档库的 URL，您可以访问您的用户。在更大的环境中，您可能需要考虑使用“组策略”来部署这些“网上邻居”。
图 6 包含一些已上传文档的文档库
图 6 包含一些已上传文档的文档库

深入介绍
SharePoint 提供了明显超越公用文件夹功能的功能集。除了可以为您提供某些使用公用文件夹也能获得的常用功能之外，SharePoint Server 还提供了更多可扩展这些常用用途的功能的强大功能。这些增强的功能包括：
  • 版本历史记录
  • 审批控制
  • 签出程序
  • 工作流控制
  • 文档保留政策
  • 审核
  • RSS
这些功能对很多企业内容管理平台非常重要，SharePoint 提供了管理员可轻松使用的稳健框架。这个增强的功能可用于许多 SharePoint 功能，包括日历、任务、讨论板和文档库。
若要配置此功能，请选择“设置”菜单，然后选择设置选项——例如图 7 中显示的“文档库设置”选项。然后会显示“设置”页面，在这里您可以查看所有可用的配置和自定义选项。例如，“常规设置”栏下的“版本管理”设置链接允许您配置历史记录。
图 7 选择设置选项配置增强的功能
图 7 选择设置选项配置增强的功能
正如我前面提到的那样，该功能提供文档更改的记录，包括谁进行了更改、何时进行的更改，并在必要的时候允许用户查看和恢复之前的版本。还有可能会控制 SharePoint 存储的版本的数量。一旦达到限制，项目就会被直接删除，而不是送到 SharePoint 回收站。
“版本管理”部分还允许您配置您需要的“内容审批”和“签出”设置。启用“内容审批”时，任何提交的项目都必须经过审核才能将它们用于其他用户。未经过批准的项目保留为待定状态。“签出”过程通过禁止多个用户在同一时间使用文件，来提供内容控制功能。
工作流是 SharePoint 提供的另一个有用功能，公用文件则没有这个功能。本质上，工作流提供业务流程结构化的方法来帮助简化贵公司的运作。如同在 SharePoint 内实施的那样，工作流是一系列通过指定的流程来自动化文档移动的预定义任务。此过程可能是迭代的，它要求每个步骤都在移至下一个步骤之前完成；这个过程也有可能是并行的，允许指定的任务可以在任何时候完成。包含在 SharePoint 中的默认工作流有：
  • 审批
  • 收集反馈
  • 收集签名
  • 处置审批
信息管理策略是用来强制遵守法规和业务需求的。策略由一系列与文档管理和控制相关的规则组成。SharePoint Server 支持自定义规则，但也包含便捷的默认规则，包括：
  • 审核
  • 过期
  • 标签
  • 条码
审核可以根据一系列您在网站设置中定义的操作来记录事件。您可以跟踪打开文档、下载或查看项目或其属性、编辑文档、签入或签出文档、移动或复制项目以及删除或恢复项目等操作。
内容过期允许您删除内容，以便符合贵公司的数据保留策略。数据过期可能会发生在某一个特殊的日子，或发生在某个事件发生之后（例如文档创建）的某个固定的期间。
标签与打印以及将文本添加到打印输出结合使用。实际上，该策略可以有很多用途。例如，您可以要求来自人力资源共享文档库的所有文档都包含一个保密通知，以符合您的法律部门的法规。
条码提供在线文档和打印文档的正式跟踪方法。SharePoint 将为每个文档创建唯一标识符，然后用户就可以将条码的图像插入它们的文档。
另一个重大改进是 SharePoint 与 RSS 源的集成。日历、联系人、文档库和讨论板都提供用户可以订阅的 RSS 源。您的用户可以接受自动的更新，以帮助跟踪其日常职责，所有这一切只需要一个 RSS 读取器（如 Outlook 2007）即可。

总结
Microsoft Office SharePoint Server 2007 提供了企业级功能，并提供了一种可替代 Exchange 公用文件夹的强有力方法。稳健的管理框架使实施共享日历、联系人和文档的解决方案变得更加容易。同时，还可以创建各种通信方式，包括论坛、博客和 Wiki。

Alan Maddison 是 MTI Technology Corporation 的 Microsoft 技术实践高级顾问。他重点研究 Active Directory、Exchange Server 和虚拟化。


 通信: 使用智能卡登录 Outlook Web Access
通信 Victor Akinnagbe and Ted Dressel and Jason Opdycke

使用智能卡登录 Outlook Web Access
概览:
  • 双重身份验证
  • Kerberos 约束委派
  • ISA Server 和 Exchange 配置

移动员工是 IT 组织面临的最为独特的安全挑战。远程用户需要对数据和服务（如电子邮件）进行安全访问。然而遗憾的是，现实中
安全链最为薄弱的环节往往与脆弱的密码、恶意软件（如击键记录器），以及访问您所在组织内部资源的远程计算机上的病毒有关。
提高这种移动环境安全性的其中一种方法是去掉这其中的某一个薄弱环节：密码（虽然允许在访问某个帐户时不使用密码进行身份验证可能会带来麻烦）。用于解决密码相关问题的主要技术便是双重身份验证（或有时为多重身份验证）。双重身份验证在启用访问时不是依赖一种单一的方法（密码），而会使用额外的身份验证方法，包括用户名/密码的组合、物理设备（如智能卡），或生物特征识别码（如指纹）。
如果您有远程用户，通常会稍稍开启您的防火墙以便允许远程用户访问公司网络。标准的防火墙通过提供内部网络和外部网络间网络级的隔离来提供基本的风险缓解（参见图 1）。为增强安全性，只能关闭端口，如若需要与内部网络中的设备进行通信，就将端口映射到正确的位置。这些技术确实提供了足够的网络级保护，但由于攻击技术不断发展成熟，多层网络安全性就变得非常必要了。
图 1 端口被阻止或被映射的标准防火墙
图 1 端口被阻止或被映射的标准防火墙
既然移动员工最常使用的公司服务是电子邮件和消息传送，因此将您的 Exchange 基础结构进行安全配置就变得比任何时候都重要了。让您的用户通过 Outlook® Web Access (OWA) 访问电子邮件是为移动员工提供安全服务的一种方法。通过智能卡为 OWA 提供更为安全的双重身份验证是另一个关键步骤。在本文中，我们将进一步说明您在启用自己的使用智能卡的 OWA 部署中应当注意的问题。

优于防火墙
在您的网络中使用 Microsoft® Internet Security and Acceleration (ISA) Server 2006 可以简化向远程用户开放网络这一任务，而且更为安全。ISA Server 2006 包含一些安全增强功能，如启用智能卡的虚拟专用网络 (VPN)、到 Active Directory® 的轻型目录访问协议 (LDAP) 身份验证，以及 Kerberos 约束委派。ISA Server 与您想象的传统防火墙稍有不同。它不仅通过在网络层提供多层安全性——这可以代替或与标准的防火墙硬件结合使用——而且还提供传统防火墙通常不支持的一些其他安全功能，如应用程序筛选器。不想让某个人在特定托管网站上使用 HTTP POST 方法？想要在 SMTP 消息接触您的 Exchange 服务器之前在其上强制实行 RFC 遵从性？想要在加密的安全套接字层 (SSL) HTTP 数据包进入网络前对其进行检查？ISA Server 可以管理所有这些以及更多的任务，从而确保只有干净的、经筛选的通信可以被转发到您的 DMZ 或内部网络中。
对于标准防火墙来说，SSL 会话是一个大问题。当数据包通过防火墙时，它们会保持加密状态（这意味着 SSL 正常工作）。因此，如果一个应用程序（如 OWA）通过使用 SSL 的硬件或软件防火墙进行发布，那么除了状态数据包检查外，标准防火墙便不能执行其他真正有效的检查了。这种仅仅是打开和映射端口会极大地增加受攻击的机会。由于在边缘处没有进行真正的检查，未经检查和身份验证的数据包便可传送到您的内部网络中。
ISA Server 2006 可以作为 HTTP 客户端的 SSL 终结点，确保只有经过身份验证的通信可以到达已发布的 Exchange 服务器。ISA Server 支持一个名为 SSL 桥接的有用功能。通常数据包是由通过一个标准的 SSL 会话与 ISA Server 进行通信的客户端进行加密的。有了 SSL 桥接功能，ISA Server 就可以本地终止 SSL 加密，检查当前未加密的数据包，对 Active Directory 的用户进行身份验证（如果需要），使用 SSL 对数据包重新进行加密，然后将加密后的数据包传送到相应的 Exchange 服务器上（参见图 2）。使用这种技术，SSL 桥接可以缓解 SSL 会话中隐藏的攻击，而这些攻击对于那些应用程序不敏感的防火墙来说只不过是一些加密的数据 Blob。
图 2 ISA Server 从应用程序层的角度来看待通信
图 2 ISA Server 从应用程序层的角度来看待通信
提到 Kerberos 约束委派，到达服务器的经过预先身份验证的通信是十分值得注意的一点。在标准的防火墙中，端口只是简单地映射到 Exchange 服务器，并且由前端服务器自身来执行身份验证任务以防止恶意用户。当需要进行身份验证时，ISA Server 可以直接联系 Active Directory，并代表用户请求获得凭据。如果用户成功通过身份验证，ISA Server 会将消息转发至 Exchange 前端服务器。前端服务器则不再需要对随机的未知用户请求进行身份验证，并可单独用于代理到后端服务器的请求。ISA Server 2006 还可以使用 Kerberos 约束委派来启用到 Windows SharePoint Services 和 Exchange ActiveSync 等技术的基于证书的访问。
Exchange Server 2003 包含对 OWA 登录的前后端服务器之间基于 Kerberos 的身份验证支持。（您是否使用 IPsec 来保护该客户端通信？）Exchange Server 还支持到群集邮箱服务器的 Kerberos 身份验证。

启用智能卡身份验证
为 OWA 实施基于智能卡的身份验证一直以来都是一项挑战。不过现在 ISA Server 2006 中已有了一个根据 Kerberos 约束委派功能开发的解决方案。该解决方案允许用户通过证书来提交凭据，以便成功通过 OWA 的身份验证。Kerberos 约束委派深受广大用户的欢迎，它是对使用无约束委派、受 Windows® 2000 支持的 Kerberos 委派的一次改进。Kerberos 的约束功能可以提高安全性，并且限制了使用假冒身份这种更为复杂的攻击的潜在风险。
在启用智能卡的情况下，由于用户无法从外部网络对密钥发行中心 (KDC) 进行可路由的访问，因此 ISA Server 2006 会联系 Active Directory 来对用户进行身份验证。ISA Server 会根据 Active Directory 证书-用户映射来对用户进行身份验证，然后根据用户主体名称 (UPN) 来分别获取相应的 Kerberos 票证。在这种情况下，ISA Server 会通过应用程序级别的筛选和反向代理服务向 Exchange 前端服务器提供 Kerberos 约束委派功能。如果尝试不使用反向代理进行委派，则会增加漏洞攻击的风险，从而影响网络或 Active Directory 域的完整性。
Exchange Server 2003 和 Exchange Server 2007 均允许基本身份验证和集成身份验证。但是您需要对 Exchange Server 2003 进行软件更新，以便启用 OWA 的基于智能卡的身份验证。（有关详细信息，请参阅文章“对 Exchange Server 2003 中支持 Outlook Web Access 智能卡身份验证的新功能的说明”。）您必须拥有一个处于 Windows Server® 2003 本机功能模式的域，涉及的所有 Exchange Server 2003 服务器必须应用 SP2 或更新的版本，并且必须有一个 ISA Server 2006 服务器作为 OWA 站点的反向代理。
安装软件更新并对 ISA 和 Exchange 服务器进行配置后，便可以使用智能卡对 OWA 会话进行身份验证了。图 3 显示了智能卡验证过程中需要进行的一系列事件。用户先在 Internet Explorer® 中打开 OWA 站点 (1)。事实上，在启动 OWA 会话时，用户会实际连接到 ISA Server，并且服务器会提示您输入证书而不是用户名和密码。正确的证书存储在智能卡中，用户需要有一个 PIN 才能获取证书。
图 3 使用智能卡对 OWA 进行身份验证
图 3 使用智能卡对 OWA 进行身份验证
证书验证 (2) 由证书吊销列表 (CRL) 或在线证书状态协议 (OCSP) 请求来处理，这根据 ISA Server 的配置和安装的其他软件而定。ISA Server 会向域控制器 (DC) 发送一个验证用户凭据的请求。如果请求失败，ISA Server 会向用户提供一个错误页面，并且没有请求会到达 Exchange 前端服务器。
凭据经验证后，会生成 Kerberos 票证并会将请求传送至使用集成身份验证的 Exchange 前端服务器 (3)。Exchange 前端服务器收到请求后，会对 Kerberos 票证进行验证并会找到用户的后端邮箱服务器 (4)。
前端服务器会通过 Kerberos 约束委派为相应的后端服务器请求一个 Kerberos 票证，并会将邮箱请求代理到使用集成身份验证的后端服务器 (5)。后端服务器会处理请求 (6)，并会将邮箱数据返回给 Exchange 前端服务器 (7)。OWA 页的 HTML 数据将被传送至 ISA Server (8)，然后数据会返回至客户端机器 (9)。

配置 Exchange 环境
先前提到的知识库文章对 Exchange Server 2003 软件更新进行了说明，并包含指导您完成使用 ISA Server 2006 和 Exchange Server 2003 启用 Kerberos 约束委派这个过程的信息。
软件更新后启用的主要操作是使从 Exchange 前端服务器到各自的后端服务器的 Kerberos 约束委派过程自动化。由于 ISA Server 不是 Exchange 组织的一部分，因此该项更新不会将从 ISA Server 到前端服务器的 Kerberos 约束委派过程自动化。这种 ISA Server 实例到 Exchange 前端服务器之间的委派需一一手动启用。
软件更新会在 Exchange 系统管理器 (ESM) 中添加一个新的选项卡，该选项卡可让您将某个 Exchange 前端服务器指定为 KCD-FE（参见图 4），这样便可以让该服务器在每个 Exchange 后端服务器的委派选项卡上进行填充。
图 4 启用 Kerberos 约束委派
图 4 启用 Kerberos 约束委派
这个新的 UI 还可让您在管理组属性中指定用哪个凭据来填充 msDS-AllowedToDelegateTo (A2D2) 属性，如图 5 所示。该属性用于进行 Kerberos 约束委派。
图 5 设置控制委派的帐户
图 5 设置控制委派的帐户
根据最低权限原则，您可以使用一个标准的用户帐户，并授予它通过组策略对象 (GPO) 来委派用户和计算机的能力。为帐户授予这个提升的权限后，该帐户便可作为一个服务帐户，使每个管理组的 Kerberos 约束委派过程自动化。
请务必采用正确的步骤，以确保恶意用户无法破坏 Kerberos 约束委派服务帐户。即使帐户不是一个域管理员，利用 Kerberos 委派对其进行访问也可导致受到复杂的攻击。由于帐户具有建立新的 Kerberos 关联的功能，因此使用时应非常小心。为确保帐户的安全性和完整性，应采取必要的措施，如长而复杂的密码、增强审核、帐户停用技术等。
Exchange 软件更新还使 ESM 接口有关集成身份验证方面发生了重大变化。先前在 Exchange Server 2003 中，当某个服务器被指定为前端服务器后，用于启用 HTTP 虚拟目录（HTTP 虚拟服务器下）的集成 Windows 身份验证的选项就会变灰（参见图 6）。
图 6a 更新使得可以使用集成身份验证
图 6a 更新使得可以使用集成身份验证
图 6b 更新使得可以使用集成身份验证
图 6b 更新使得可以使用集成身份验证
发生这种情况的原因是，由于技术方面的问题（如代理服务器会中断 NTLM 会话、使用 Kerberos 身份验证的用户需要连接到 Active Directory，以及 Internet 用户通常不属于该域），Exchange 前端服务器不支持集成身份验证。上面提到的知识库文章中所描述的更新取消了这些限制。安装了更新后，您只需转到虚拟目录，然后选中“集成 Windows 身份验证”复选框，将其作为验证用户凭据的机制。选中该复选框后，它会在 Active Directory 中的虚拟目录对象上设置一个名为 msexchAuthenticationFlags 的属性（使用 Microsoft 管理控制台的 Adsiedit.msc 插件可以看到该属性）。
通过 OWA 来检查邮件的用户可能知道他们的 Exchange 后端服务器的名称，并且当他们位于公司内部网络时可以使用集成身份验证连接到这些后端服务器。使用集成身份验证的用户体验的不同之处在于，由于您已经登录到网络中，系统便不会提示您输入用户名和密码了，因为 Internet Explorer 会自动对您进行身份验证并登录到网站中。这一点对于位于公司网络的用户来说是非常棒的，但外部用户（OWA 用户更常见的是外部用户）通常在从网络外部访问 Exchange 前端服务器时不会登录到某个域中。（知识库文章“IIS 如何验证浏览器客户端”中对这个过程进行了详细的说明。）
在 Exchange Server 中，更新会对“委派”选项卡进行填充，以便使用 Active Directory 中的 A2D2 属性，而不是服务主体名称 (SPN)。如果您使用 Adsiedit.msc 来查看 Exchange 计算机对象，您就会注意到两个截然不同的属性：A2D2 属性，它是 Kerberos 约束委派列表；SPN 属性，它是 Kerberos 定位器和帐户规范点。虽然确实是这两个属性同时促成了 Kerberos 约束委派，但您只需通过图形界面修改 A2D2 属性即可。
Windows 可以使用内置的 HOST SPN 作为别名来寻找其他服务。这意味着 Kerberos 约束委派无需使用 setspn.exe 来进行 Exchange 前端到后端的委派。（虽然使用这个解决方案可以在 SPN 属性列表中明确指定 HTTP/Servername，但这会引起更多由管理员造成的错误，并且这也不是 Kerberos 约束委派运行所必需的。）Kerberos 约束委派会在 Active Directory 中查找 A2D2 属性。当未对该属性进行填充（或填充的 SPN 值出错）时，Kerberos 约束委派将不会在各自的服务器间进行。但是在一个 Exchange 群集中，只需将来自前端的 A2D2 属性指向群集节点计算机帐户便可让委派顺利进行。
正如前面提到的，Windows Server 2003 域包含的 Exchange 2003 服务器必须处于 Windows Server 2003 本机功能模式。在未达到这一级别的域功能前，Kerberos 约束委派将不能使用。如果您的域仍处于混合模式，但您安装了前面提到的软件更新，那么委派看似是可以进行的，但 SPN 注册实际上是失败的。Kerberos 约束委派还是一项域功能，而不是林级功能。这意味着，对于 Exchange Server 2003 来说，ISA Server 以及 Exchange 前端和后端服务器必须是同一域中的成员（虽然不同域中的用户仍然可以通过 Kerberos 约束委派的身份验证）。非域成员的 ISA Server 实例，或是其他域中的 ISA Server 实例将不作为该解决方案的一部分运行。

配置 OWA 站点
IIS Admin 不可用于针对 OWA 的任何类型的身份验证更改。即使 OWA 是在 IIS 下运行，并且会像任何其他网站一样响应元数据库中的变化，但 Exchange 和目录服务到元数据库 (DS2MB) 进程使事情变得有点复杂。DS2MB 进程会将 Active Directory 中的更改复制到 IIS 元数据库中，这种复制是单向的，它会覆盖先前直接对 IIS 进行的所有更改。该进程造成的影响是，如果管理员直接对 IIS 元数据库进行更改（如设置集成身份验证），该解决方案看似可以正常运行，但是一旦下一次 DS2MB 复制循环开始，解决方案就将被破坏。
ESM 中为 HTTP 虚拟目录启用集成 Windows 身份验证的选项是可用的，因为 ESM 可以直接对 Active Directory 进行编辑，然后将所做的更改复制到 IIS 元数据库中。请记住，虽然停止系统助理服务会停止 DS2MB 进程，以便让您对 IIS 元数据库进行更改而不被覆盖，但我们不建议采用这种方法。系统助理下次启动时，会轮询 Active Directory 中的更改，然后解决方案将自动被停用。
“委派”选项卡显示了“仅使用 Kerberos”选项和“使用任意的身份验证协议”选项。既然我们讨论的解决方案是使用 Kerberos 约束委派的，那么我们就不难知道应该选择“仅使用 Kerberos”，但是许多 IT 组织的情况是不适用这种一般逻辑的。因此，我们应选择“使用任意的身份验证协议”这个选项（如图 7 所示），因为请求并不是作为 Kerberos 请求，而是作为 HTTP 请求进入的，它有一个与之相对应的证书映射到 Active Directory 帐户。
图 7 更正智能卡的身份验证设置
图 7 更正智能卡的身份验证设置
在此例中，ISA Server 是通过 SSL 来请求用户 PKI 证书的。传入的请求不是 Kerberos 票证，因此为了让 Kerberos 约束委派顺利进行，就必须进行转换。因此，指定“仅使用 Kerberos”这种设置将会破坏 ISA Server 上的通信链。但是请注意，“仅使用 Kerberos”选项在 Exchange 前端到后端服务器的委派中是适用的，因为前端服务器只会接收来自 ISA Server 的 Kerberos 票证。
\Exchange 和 \Public 虚拟目录是唯一包含专用用户和公共文件夹信息的位置。Exchange 中的 SSL 配置对于 Kerberos 约束委派或双重身份验证来说都不是新的事物，它是对采用基本身份验证凭据的 OWA 的标准 SSL 启用的一次继承。您应按照文中描述的方法在 OWA 上启用 SSL，因为错误地强制启用 SSL 会破坏 OWA，同时也会使 ESM 出现问题。

其他配置详细信息
实施该解决方案时，先以标准方式部署 ISA Server 和 Exchange 可以让工作变得更加简单。请不要实施整个 Kerberos 约束委派解决方案并配置所有设置（特别是在部署中还没有 ISA Server 时）。这样会使得当处理过程中的某个组件或步骤出现故障时的故障排除过程变得更为复杂。而以标准方式（使用用户名和密码，但不使用基于表单的身份验证）部署 ISA Server 和 Exchange 可以让工作变得更加简单，可确保安装可以正常工作，然后转换为 Kerberos 约束委派和证书身份验证。
一般来说，基于表单的身份验证不能与启用智能卡的 OWA 一同使用。基于表单的身份验证需要用户通过标准的 Outlook 表单提交用户名和密码。但是使用基于智能卡的双重身份验证，用户将只拥有一个智能卡而没有密码。因此基于表单的身份验证就不具有任何通过仅接受或提交证书来进行身份验证的方法。在通信链中的任何一处（例如在 ISA Server 后的某个前端服务器上）使用基于表单的身份验证都将破坏启用智能卡的 OWA 配置。如果您启用基于表单的身份验证，Exchange 虚拟目录将被强制设置为“基本”身份验证，同时 IIS 元数据库也将被设置为“基本”身份验证。
如果您的用户既有用户名/密码又有智能卡，则您可以在 ISA Web 侦听器上启用回退身份验证，当用户在收到提示输入基于证书的凭据的信息后点击 ESC 按钮时，系统将提示输入标准的用户名/密码凭据，即使在 Exchange 服务器上的 ISA Server 后启用了集成身份验证也如此。此外，ISA Server 可让 SSL 会话超时，该功能与基于表单的身份验证类似。

结束语
支持用智能卡来为 OWA 进行身份验证是 Exchange Server 2003 和 Exchange Server 2007 中的一项深受广大用户欢迎的新增功能。有了这种使用证书登录 OWA 的能力，用户就不再需要为记住那些又长又复杂的密码而担心，而管理员现在也有了有效的工具来防止击键记录器和其他形式的恶意软件，避免了它们从受感染的系统中找到用户凭据的风险。有关详细信息，请参见侧栏上的“资源”。
为使用智能卡的双重身份验证正确配置 ISA Server，通过在已发布的 OWA 应用程序上实施应用程序级的筛选，可以进一步增强总体的安全性。此外，ISA Server 2006 内置了对通过简单的发布向导来发布 Exchange Server 2003 和 Exchange Server 2007 的支持，因此对于正在转为使用 Exchange Server 2007 的组织来说，先前对 ISA Server 所做的投资依然有效。
资源
  • 如何共享由 Outlook Web Access for Exchange Server 2003 中的“安全 HTML”筛选功能删除的文件
  • Kerberos 委派故障诊断
  • 元数据库更新服务
  • ISA Server 2006 中的身份验证
  • Kerberos 协议转换和约束委派
  • TechNet 网络广播：实施使用智能卡的多重身份验证

Victor Akinnagbe是 Microsoft 的一位高级现场工程师，在华盛顿特区工作。他重点研究安全性、基础结构和消息传送。
Ted Dressel是 Microsoft 的一位顾问，在华盛顿特区工作。他重点研究安全性和基础结构。
Jason Opdycke是 Microsoft 的一位高级现场工程师，在夏洛特地区工作。他重点研究安全性和基础结构。


 Windows 管理: Windows Vista 中的 ActiveX 安装程序服务
Windows 管理 Rob Campbell and Joel Yoker

Windows Vista 中的 ActiveX 安装程序服务
概览:
  • ActiveX 控件的常见难题
  • 如何安装 ActiveX 控件
  • 危险的权限
  • Windows Vista 中更安全的处理

道理总是相同的。要想大幅度增强安全性，就必须放弃某些自由度或灵活性。如果您的环境与多数组织机构类似，就会有努力强化桌面操作系统的强烈愿望，以便
为您的最终用户提供更加安全的计算环境。IT 管理员执行保护台式计算机的任务通常依靠综合运用安全策略设置、用户权限、文件和注册表访问控制列表 (ACL) 以及系统服务限制。
部署安全台式机环境的一个常见障碍是，如何缓解恶意 ActiveX® 控件相关的威胁，同时仍在您的环境中提供适当级别的应用程序兼容性。这是一个困扰桌面操作系统多年的难题。幸运的是，Windows Vista™ 中新的 ActiveX 控件安装程序服务 (AxIS) 消除了公司环境中管理 ActiveX 控件的顾虑。AxIS 为标准用户提供了一种简单可控的方式，从经许可的网站安装 ActiveX 控件，通常情况下这些用户是不允许安装 ActiveX 控件的。AxIS 上的组策略控制允许 IT 管理员决定用户可安装哪些控件，而不管用户具有哪些权限。
在本文中，我们将了解围绕 ActiveX 控件的管理难题、这些难题在以前版本的 Windows® 中是如何解决的，以及 Windows Vista 中的 AxIS 如何提供独特而有效的方式来管理 ActiveX 控件的安装。

什么是 ActiveX 控件？
ActiveX 控件是用户通过 Internet Explorer® 安装和调用的一小段可执行代码（通常是打包在压缩文件内的 OCX 文件）。Web 开发人员创建 ActiveX 控件是为了向他们的 Web 应用程序中添加功能，而这些功能用标准的 HTML 或简单的脚本是无法轻易实现的。
ActiveX 控件的一个主要特性是其简单的“下载并执行”部署模型。ActiveX 控件通过 HTML object 标记完成安装和调用，该标记有一个名为 CODEBASE 的属性，如果用户的计算机上尚未安装此控件，该属性会通知 Internet Explorer（用 URL）到哪里获得此控件。在这种情况下，Internet Explorer 下载相关的安装程序包，执行对象的信任验证，并通过 Internet Explorer 信息栏提示用户所需的安装权限（如图 1 所示）。安装过程中，控件通过呈现页面进行注册和调用。安装后，任何标准用户都可调用此控件。这种简单的分发和执行机制意味着开发人员可以用一种便捷的方式向他们的 Web 应用程序用户分发其组件。这种分发方法的问题是标准用户不能直接安装 ActiveX 控件，因为必须具有管理权限才能完成安装。
图 1 ActiveX 控件安装信息栏
图 1 ActiveX 控件安装信息栏
当 ActiveX 控件在 Internet Explorer 4.0 中首次引入时，Internet 似乎还是一个非常友好的环境。如今，通过 Web 分发的可执行代码可能代表严重的威胁，所以 Windows 只允许具有本地管理员权限的用户安装 ActiveX 控件，而且安装还必须按照策略设置获得批准。在管理员安装了 ActiveX 控件后，系统中任何用户都可以调用此控件。这种行为通过 Windows 中的一组文件和注册表 ACL 来协助实现。虽然这种方法可阻止标准用户安装 ActiveX 控件，但并没有减轻安装这些控件的本地管理员和标准用户（具有已修改的默认权限）的风险。
Windows 中的默认保护只允许具有管理权限的用户执行安装，在个人层面上解决了 ActiveX 控件问题，但它没有解决如何在整个大型组织机构内管理这些控件的问题。公司环境中的一个常见难题是如何准许使用 IT 机构信任的 ActiveX 控件，同时缓解外部不受信任的控件所带来的潜在威胁。最后，安装某个特定 ActiveX 控件的决定权通常留给了个人用户，这取决于用户的权限，而与控件的好坏无关。为了消除威胁，一些组织机构阻止所有的 ActiveX 控件，另一些组织机构虽允许最终用户安装，但试图控制任何安装的恶意软件。
阻止安装不良控件的另一种方法是对标准用户实施受限制的权限，让 IT 管理员在台式机平台上预先安装所有必需的控件。如果当前所用的 ActiveX 控件具有相对静态的特性，使用与台式机更新相结合的预定发布过程进行修改，或者使用系统管理服务器等软件分发机制，那么这种方法会十分有效。然而，持续管理、内部应用程序开发人员随时更改需求和对外部控件的依赖将继续成为这些方法的障碍。
在用户具有管理权限的情况下，问题就不同了；它涉及阻止这些用户安装未经许可的控件。在这种情况下，因为用户具有管理权限，因此假定最终用户具有安装 ActiveX 控件的权限。（注意，让最终用户担当本地管理员对组织机构意味着高风险，对于多数公司环境来说，不推荐这种做法。）
一个解决方案是，让一台内部 Internet 组件下载服务器承载经批准的控件。该解决方案需要修改客户端注册表中的 CodeBaseSearchPath 字符串。正常情况下，当请求的 HTML 页面中发现含有 CODEBASE 属性的对象标记时，Windows 客户端会指向 CodeBaseSearchPath 数据中指定的位置。默认情况下，该注册表字符串包含 CODEBASE 关键字和 ActiveX 控件库的 Internet URL。要实施 Internet 组件下载服务器，您需要将 CodeBaseSearchPath 中的默认数据替换为内部服务器的 URL，您的组织机构批准的控件将驻留在这台内部服务器上。与前面的方法相似，该解决方案需要持续管理，并需承担 ActiveX 控件的内部服务器的承载成本和复杂性。
还有其他的解决方案，比如修改 Internet Explorer 的 URLActions 区域、通过组策略指定管理员批准的控件，以及通过防火墙规则在外围阻止安装所有控件。但是，正如您看到的那样，所有这些方法都存在自身的问题，许多方法由于缺乏灵活性而最终被放弃。更糟的是，这些解决方案中有些依然要求用户具有管理权限。最后，这些修改试图解决部分问题，如控制（或阻止）ActiveX 控件的来源位置、调用位置等；但是，这些解决方案并未缓解没有管理员权限的用户不能安装 ActiveX 控件的基本问题。

AxIS 能为您做什么？
Windows Vista 中的 AxIS 允许公司管理员采用默认的文件系统设置让用户担当标准用户，在维持强健的安全状态的同时对 ActiveX 控件进行管理。AxIS 提供配置 ActiveX 控件受信任来源的组策略选项，以及代表标准用户从那些受信任来源安装控件的代理进程。主要好处是，您可以在用户工作站上保持一种非管理的安全状态，并且享有集中的管理控制。AxIS 依靠 IT 管理员确定 ActiveX 控件的受信任来源（通常为 Internet 或 intranet URL）。当一个对象标记指示 Internet Explorer 调用一个控件时，AxIS 采取下列步骤：
  1. 检查控件是否已安装。如果未安装，则必须先安装后才能使用。
  2. 检查 AxIS 策略设置，验证控件是否来自受信任的来源。这项特定的检查用策略中指定的受信任位置与对象标记的 CODEBASE 属性中指定的 URL 的主机名进行比照。
  3. 代表用户下载和安装控件。
如果源 URL 的主机名未在 AxIS 策略设置中列出，就会激活常规用户帐户控制 (UAC) 提示，要求管理权限才能完成安装。此外，AxIS 还会在应用程序事件日志中用 ID 4097 记录一个来源 AxInstallService 的事件，描述未成功的 ActiveX 控件安装，以及控件特定的下载路径。4097 事件的一个示例如图 2 所示。公司管理员可使用该事件日志条目中的数据修改组策略，允许此后访问该网站时 AxIS 安装该控件。
图 2 4097 AxInstallService 事件
图 2 4097 AxInstallService 事件
AxIS 是 Windows Vista Business、Enterprise 和 Ultimate SKU 附带的可选组件，可通过无人参与选项或通过“控制面板”对话框（“程序”|“程序和功能”|“打开或关闭 Windows 功能”）启用，如图 3 所示。一旦启用，AxIS 就会在每次 Internet Explorer 请求控件时执行上述步骤。
图 3 在控制面板中启用 AxIS
图 3 在控制面板中启用 AxIS
Windows Vista 中向事件附加任务的功能为管理员提供了一种从 AxIS 服务接收通知的简便方式，比如，当安装某一 ActiveX 控件被阻止时。特别要注意的是，不能假定安装 ActiveX 控件的 URL 主机名永远与最终用户从其网站访问的主机名相同。因此，AxInstallService 4097（未遂安装）事件提供的信息对于确定试图安装的控件所来自的主机显得极为有用。
使用从该事件中获得的信息，您可以在组策略中配置受信任的位置。本地或组策略中的 AxIS 设置位于“计算机配置”设置中（如图 4 所示）。您可以在“ActiveX 控件的批准安装站点”策略设置中指定受信任位置的主机 URL（参见图 5）。已批准站点设置需要两项信息，即安装 ActiveX 控件的来源位置和安装行为。
图 4 “组策略对象编辑器”中的设置
图 4 “组策略对象编辑器”中的设置
图 5 AxIS 批准的安装站点
图 5 AxIS 批准的安装站点
首先，如前面所述，需要一个主机 URL 来表明控件的受信任位置。与前面解决方案不同的是，前面的办法需要知道控件的 CLSID（当开发人员修订控件时常常发生变化），而 AxIS 允许从受信任的位置安装任何控件，从而减少总体管理负担。第二项信息是一串用逗号分隔的四个值，分别规定了 ActiveX 控件下载过程中的行为。这些值指定了四个属性：TPSSignedControl、SignedControl、UnsignedControl 和 ServerCertificatePolicy。前两个属性（TPSSignedControl 和 SignedControl）可从以下三个值中任取其一：0、1 或 2。这些值类似于 URLAction 设置中的值。值 0 阻止安装控件，值 1 的作用是提示用户安装所需的权限，值 2 的作用是以静默方式代表用户安装控件。未签名的控件不能以静默方式安装，因此 UnsignedControl 的值只能为 0 或 1。注意：如果未指定策略，将使用默认值 2、1 和 0。
最后一个属性根据已签名设置控件的证书设置来指定安装行为。与多数 SSL 站点类似，证书必须通过一系列安全测试才能确认其有效性。无效的证书属性在实际实施已签名 ActiveX 控件的过程中有时确实存在。通过其配置，AxIS 允许管理员根据具体的 URL 忽略证书中有时出现的无效信息。最后一个属性表示为位掩码的值组合形式，如图 6 所示。
Figure 6 ServerCertificatePolicy (Close Figure 6)

值 | 定义
0x00001000 | 忽略证书中无效的规范名称 (CN)。
0x00000100 | 忽略未知的证书颁发机构。
0x00002000 | 忽略无效的证书日期。
0x00000200 | 忽略错误的证书用法。
默认设置为 0，表示 AxIS 完成安装前必须通过所有的安全检查。主机设置和这四个值的组合均在策略设置中指定，如图 7 所示。
图 7 经批准的 AxIS 主机 URL
图 7 经批准的 AxIS 主机 URL

结束语
AxIS 允许您配置组策略，以控制用户能够安装的 ActiveX 控件，而无需管理权限或复杂的配置。在早期版本的 Windows 中，此级别的控制颇具挑战性，以前采取的解决方案通常具有严格的限制或增加了管理开销。AxIS 为各组织机构提供了另一类工具，采取一种台式机系统上最终用户权限的最小权限法，从而实现了最终用户不需要管理权限的标准用户模型。Windows Vista 使 IT 管理员可以选择公司环境中受信任的 ActiveX 控件，这种选择是由组织机构而非最终用户决定的，从而把控制权重新交回 IT 管理员手中。

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


 编辑视角: 六度间隔
编辑视角
六度间隔
Joshua Trupin

您是否曾经感到有些离群索居？ 是否曾经独坐空室，凝视虚空，想知道智慧生命是否存在？确切地说，到底是否有人存在？或许您未曾产生过这种感觉——特别是如果您的收件箱永远都塞得满满的，就像我的一样。
不过，我最近确实经历过那种痛苦，并由此决定我需要与外界建立联系。我在一家商业性社交网站上进行了注册并开始添加联系人，包括所有我曾经与之一起工作过、收到过他/她的文章或者在会议上与之说过话的人。在一个星期之内，我的列表中就有了 58 个联系人。感觉很棒！
但这还只是第一级。到了第二级（熟人的熟人），我就有了 3,500 多位高朋。由于这 3,500 多人每人又有自己的联系人，须臾之间我的第三级联系人就暴涨到 277,000 人。我用 Excel 电子表格做了一个简单计算：假设每个人平均有 50 个联系人，等到了第六级，我认识的人将超过 340 亿。Kevin Bacon，您可以让位了！我认识的人比地球上生活的人还多。突然之间，原来的虚空一下子热闹起来。
不过，这又带来一个新问题。我怎样才能应对所有这些关系呢？我需要广纳良言。您现在是否在使用某个社交/商业关系网站？您如何将想与之对话的人与想要回避的人区分开？敬请光临《TechNet 杂志》博客，并将您就这一棘手问题的想法告诉我们。
如果您对所有这些 Web 2.0 联网技术不很擅长，那么也不必担心。本月的《TechNet 杂志》将帮助您更好地使用 Exchange Server，改善您的通信和交流。我们准备了五篇文章，提供了扩大您组织消息传送范围所需的知识。
将智能卡身份验证用于 Outlook Web Access 是本月的一个精选专题。在允许访问您公司的资源之前，要求提供某种形式的实体身份验证始终是一个好主意，而智能卡在任何情况下都能使之成为可能。我们还将探讨 Exchange Server 的灾难恢复，如何使用 Exchange Server 2007 中的 SharePoint 来替代公共文件夹，以及如何使用 Windows Mobile 6 改善移动安全性。当然，我们还有 Exchange Queue & A；如果您的工作涉及消息传送，那么您应该会喜欢这期专栏。噢不，又有三个人刚刚蹦到我的网络上。我最好去看看是否应当打声招呼，或者假装在睡觉。
—Joshua Trupin

向以下 Microsoft 技术专家致以衷心感谢：Kristian Andaker、Chris Corio、Jim Harrison、Chad Jones、Michael Lee、Shawn McGrath、Michael Murgolo、Eric Perlin、Michelle Rutzer、Gavriella Schuster 和 Jim Truher。


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

监视远程连接
RecordTS
www.tsfactory.com
您是否曾想要监视您的终端服务器或远程桌面会话？如果您的远程桌面会话似乎导致您的网站出了问题，也许您想知道在这之前发生了什么。也许您的终端服务器出现某一问题，而您又无法复制这一过程。也许您在担心知识产权的安全。或许您需要对如何在测试环境下配置 SharePoint® 服务器进行快速记录或演示。如果您对上述任一情形有些耳熟，就应该仔细阅读 TSFactory 中的 RecordTS。（TSFactory 是由 Cláudio Rodrigues 创立的，他是一名终端服务领域的 Microsoft MVP。）
RecordTS 有两个版本：终端服务器和远程桌面。选用哪个版本取决于您想要监视什么类型的连接。正如该产品的网站所宣称的那样，RecordTS 充当终端服务器或远程桌面会话中的“安全摄像机”。该软件主要在终端服务和最终用户会话之间起到代理作用，它能够记录会话中发生的每项活动和操作。
安装过程采用的是简单而直观的向导，从中您为应用程序指定数据目录，作为保存会话的存储位置。应用程序将安装一个 MMC 管理单元（您用它来配置服务）、RecordTS 服务，以及用于查看会话记录的会话播放实用工具。在打开 MMC 管理单元后，右键单击服务文件夹，打开属性屏幕，在此您可以配置一些设置，比如，您想让服务运行于哪个端口。（如果您已将终端服务会话转移到一个非标准端口，这一特定设置非常有用）。在“Storage”（存储）选项卡中，可将“Default Storage Folder”（默认存储文件夹）设置为本地文件夹或 UNC 路径。
您还可以配置已存储会话的目录结构。例如，您可以使用域、用户以及日期和时间来组织即将保存的数据。而且，您可以设置服务在磁盘空间不足时采取的操作，如果您在本地磁盘存储会话，这也许是最重要的设置。您可以选择不允许新连接并中断当前会话（该选项侧重于高安全性），也可以选择关闭会话记录（如果您不想打断正常工作，可采用该选项）。
在“Security”（安全性）选项卡中，通过选择一个现有的证书或创建一个自签名证书，可以指定是否要对所有的会话记录进行数字签名。如果您打算使用该工具达到审计或追查责任目的，则这一选项值得考虑。在“Users”（用户）选项卡中，您可以指定那些应该或者不应该记录其会话的用户。
总而言之，RecordTS 是一个极具价值的安全和审计工具，其用途可以更广泛，比如，您可以用它来记录一个用法演示。我知道它是我的工具箱中的便捷工具。

价格：RecordTS Remote Desktop Edition 起步价 495 美元，RecordTS Terminal Services Edition 起步价 995 美元。

主机监视
高级主机监视器
www.ks-soft.net
如果您曾亲自为一个任务关键基础结构提供运营支持，就会发现要想睡得安稳就不能缺少：一个卓越、可靠的主机监视器。即使您拥有坚如磐石的硬件集和稳定可靠的应用程序堆栈，绝对没有一点故障，您也会想要一个功能完善的主机监视器，以便在冗余系统必须介入时通知您。
来自 KS-Soft 的高级主机监视器号称有 58 种不同的测试方法和 30 种警报方式。您可以检查进程信息、用户会话、平均负载、内存等项目。该应用程序提供特定于 Windows® 的测试、Linux/UNIX 测试和平台独立的检查。与 Windows 测试不同，Linux/UNIX 测试需要在客户端安装远程监视代理。
还有一项 Windows Management Instrumentation (WMI) 监视测试。您可以使用嵌入的 WMI Explorer 查找正确的查询，这样便可以轻松地导航到合适的项目并进行选择，还可以执行查询，以验证它能够得到您需要的数据。
高级主机监视器还有一些与数据库相关的测试，如 ODBC 查询测试，它可验证 ODBC 数据源的可用性，运行查询，并用一个已知值来验证结果。您还可以检查主机接受 SQL Server™、MySQL、Oracle、Postgres、Sybase 和 Interbase 数据库服务器的入站会话的能力。
还有许多与磁盘和文件相关的测试，可帮助您检查可用空间、配额、文件夹或文件的可用性以及 UNC 共享的可用性。此外，您还获得标准的网络相关测试：常规 TCP/UDP 检查、邮件测试（针对 SMTP、POP3 和 IMAP）、邮件中继检查、HTTP 内容和计时测试等。您还可以创建用于级联检查项目的监视器测试依赖性，这是一个十分有用的选项。测试还可以按定期和不定期计划进行安排，您可以非常精细地调节测试模式。
其中的警报方式包括将消息发送到 SMS、ICQ、电子邮件、事件日志或弹出式窗口。同时也可以触发其他事件，如启动或停止服务、重新启动计算机或执行一个外部程序。
高级主机监视器的专业版和企业版均附带 KS-Soft IP 工具，即由 19 个 TCP/IP 相关的网络实用工具组成的工具集，其中包括端口/协议扫描程序和 SNMP 陷阱观察程序，通过后者可以接收和处理 SNMP 陷阱消息。另外，这两个版本都有一个日志分析程序和报告组件，使您可以利用历史监视数据的趋势形成正常运行报告和性能分析评审。
界面本身提供了一个极佳的方式，可同时获取众多测试的简要概况。通过该界面，可以很方便地扫描您所监视的主机并发现问题。
价格：企业版 599 美元，专业版 275 美元。

磁盘清理
WinDirStat
www.windirstat.info
与您的住宅或公寓十分相似，一段时间过后，文件存储位置也会有凌乱的趋势，有些东西在某一时间有用，但现在只是占据着宝贵的空间而已。稍稍进行一些清理可能很管用，但与您的住宅不同，目录的树状结构不能向您提供显而易见的场景，要想清理混乱的局面您往往无从下手。幸运的是，有一个非常棒的可视化工具可帮助您查看哪些文件占用了您的环境空间。
GPL 程序 WinDirStat 是一个基于 Windows 的工具，它受到 Linux KDE kdirstat 的启发，可将选定驱动器上的文件显示为一系列不同颜色的方块。方块的大小代表文件的大小，您由此可以轻松识别那些没有用的庞然大物，如陈旧的 ISO 或 ZIP 文件。
在您选择了本地驱动器（或一组本地驱动器）后，该程序即扫描目录树，创建文件在内存中的映射。然后，会在图形用户界面的底部窗格中直观地显示出结果。单击底部窗格中的有色方块，就会在类似于 Windows 资源管理器的顶部窗格中导航到该文件的位置。顶部窗格向您提供有用的统计信息，如文件大小、文件最后更改日期及其他属性。此外，您还可以看到该文件所占用的子树的百分比。
一种非常酷的设计，即各种颜色都特定于文件类型，单击右上方检测到的文件类型，就会在底部窗格中突出显示该类型的所有文件。这种方法十分便捷，例如，当可能需要找出您的用户保存在文件服务器上的所有隐藏的 MP3 文件的情况下。您还可以看到这些文件总计的字节数占用所在分区的百分比。
价格：免费下载。

书评
“Enemy at the Water Cooler”（潜在的敌人）
syngress.oreilly.com
几乎所有的公司都需要连接到 Internet，多数公司意识到来自外部几乎持续不断的攻击企图带来的危险，这些攻击试图突破其信息基础结构分隔“外部”的“内部”的连接点。然而，许多公司忽视了一个可能危害更大的威胁，这个威胁就存在于组织机构的内部。Brian Contos 著作的“Enemy at the Water Cooler: Real-Life Stories of Insider Threats and Enterprise Security Management Countermeasures by Brian Contos”（潜在的敌人：现实生活中内部人员威胁的案例和企业安全管理对策）(Syngress, 2006)。生动地阐明了所谓内部人员威胁的强大威力。
Contos 描述了现实世界中过去发生的攻击事件以及对所涉及公司的影响。他声称，安全性是一个持续的过程，它的构成“综合了人、过程和技术”。他试图用这本书阐明企业安全性管理 (ESM) 软件解决方案对降低内部人员威胁的潜在力量。
作为 ArcSight 公司的首席安全官，Contos 在很大程度上依赖于推行公司自己的 ESM 软件解决方案，但那并没有降低总体价值。该书缺少深度的技术细节，但通过观看其他组织机构的问题所在，通过了解如何有效实施 ESM 解决方案来减少内部攻击的发生，就会对在您组织机构中的哪些地方加强自身安全程序有一个很好的设想。
在背景一章中，即“Cyber Crime and Cyber Criminals 101”（计算机犯罪与计算机罪犯 101），Contos 概括了一些需要引起注意的不同类型的攻击者及其动机。您还能简要了解一些他们的攻击技术，比如缓冲区溢出、代码打包和“Warhol 威胁”。
随后的章节深入研究了内部人员威胁的细节，包括内部人员危害公司的方式、管理风险的概念和从技术角度消除威胁的方法。技术展望提供了关于最低权限、强验证、访问控制以及异常事件检测与管理的简要概述。这就为讨论 ESM 软件解决方案作了铺垫。再次重申，该书倾向于仅推荐 ArcSight 的产品，但主要功能的解说适用于任何系统。
该书提供了许多横跨多个行业和环境的案例情节，详细介绍了不同类型的内部人员威胁及检测方法（有些还包括缓解方法）。这些案例研究对您自己的某些业务实践可能具有借鉴意义，也许还提供了降低您的环境中内部人员攻击风险的解决方案。
价格：49.95 美元。

与工具箱专栏联系
如果您希望在本期专栏中介绍某个自己非常喜欢的工具或实用工具，请发送电子邮件给专栏作者，地址为 tntools@microsoft.com。

Greg Steen是一位技术专家和企业家，他酷爱钻研技术。他总是在寻找各种新工具和新方法，以帮助 IT 专业人员更为轻松地进行操作和开发。


 SQL 技术问答: 内部群集、神秘的挂起、SA 帐户及其他
SQL 技术问答
内部群集、神秘的挂起、SA 帐户及其他
编辑：Nancy Michell

问：我需要更好地了解群集是如何工作的。我们的环境将由以下几个部分组成：一个运行 SQL Server™ 2005 的 64 位 Windows Server® 2003、一个 SQL Server Reporting Services (SSRS) Web 场（一种报表服务器扩容部署）、一个 SSRS TempDB 编录服务器，以及通过链接服务器从第三方数据库中抽取数据，并为 SSRS 存储该数据的 SQL Server。
我们想要一个三节点的主动/主动/被动群集。节点 1 为主动节点，用于存储从第三方数据库中抽取的数据。节点 2 为主动节点，用于存储 SSRS 目录。节点 3 为被动节点，作为节点 1 或节点 2 的故障转移之用。您能否帮我们实现这样的群集？

答：很遗憾，许多人都对 SQL Server 群集的主动/主动和主动/被动这些术语存在误解。他们认为 SQL 群集可以支持跨多个服务器对一个数据库或 SQL 实例进行“扩容”。但事实并非如此。SQL Server 上并没有一种类似主动/主动数据库或实例的组件。“实例”是指安装了 SQL Server 及其相应的数据库。我们这种按 SQL Server 实例进行的群集始终为主动 (1)/被动 (n) 模式（请注意，n 的值介于 1-7 之间，依您的 SQL Server 的版本而定）。这就是为什么称之为故障转移群集的原因。
了解这一点之后，您就可以开始考虑在一组节点上安装多个故障转移群集实例了。例如，使用共享磁盘的三个物理服务器可以在节点 1 和节点 2 上分别有一个默认为主动模式的实例，而节点 3 则作为这两者的故障转移节点。这些实例是完全独立的，不共享数据，也非主动/主动模式。它们皆为主动/被动模式，并共享同一个故障转移实例。如果两个实例在发生故障时都转移至节点 3，那么就可以知道随着时间的推移，节点是否存在因负荷过重而崩溃的危险。根据设计，每个故障转移的处理能力是相等的。如果最大负荷在正常操作过程中需要两个节点来进行处理，那么节点 3 将不可能在最大负荷下被正常指派给两个节点。
尽管如此，因为能够运行一个群集的硬件的成本十分巨大，我们理解人们会如何衡量两个主要节点同时发生故障，并将整个负荷全部转移到一个节点上这种情况的可能性。出于这样的考虑，他们也许会决定承担这种风险，而不是购买全部的故障转移容量。
幸好，我们带来了一些好消息：SQL Server 2005 为获得高可用性 (HA) 提供了多种方案，包括一些替代方案，在发生故障时，它们可以比群集更快地进行故障转移，甚至能够均衡数据的重复备份（群集依赖的是单个 SAN）。这些选项包括镜像、对等复制等。有了那些新的替代方案，我们可以提供更多的选择以满足各种需求，包括一些组合了多种 HA 功能的方案。
Microsoft® 群集配置验证向导 (ClusPrep) 现已可下载，它代替了原先的“硬件认证列表 (HCL)”测试，可以用几个月的时间对整个配置进行验证，从而确认其在群集下是“受支持的”。这就将硬件验证工具交到了 DBA 手中，进一步降低了获得经认证的硬件的成本（金钱和时间）。它甚至使在一个群集节点集中验证和部署异构硬件成为可能。

问：在我的机器上进行的删除操作在 12 个小时后显示为挂起。它并没有被阻止。查看最慢的查询计划后，我发现有一个触发器的运行需要 87,327 秒，因此我怀疑该操作在这个触发器中被挂起了。如何才能确切地查看是哪个语句被挂起了？

答：很可能是触发器中的某个循环没有退出，其中原因有很多。如果挂起的时间较长，并且您想要查看正在执行哪个语句，则可运行图 1 中的代码。它将告诉您当前正在运行哪个语句，而这个语句应该就是导致您机器挂起的原因。
Figure 1 查找当前正在执行的语句 (Close Figure 1)
-- Look at the current statement being run:
-- Put results to text (Ctrl + T)
DECLARE @Handle binary(20),
        @start int,
        @end int,
        @SPID int

SET    @SPID = spid

SELECT @Handle = sql_handle,
        @start = stmt_start,
        @end = stmt_end
FROM Master..sysProcesses(NOLOCK)
WHERE SPID = @SPID

IF NOT EXISTS (SELECT * FROM ::fn_get_sql(@Handle))PRINT ‘Handle not found in cache’
ELSE
   SELECT ‘Current Statement’= substring(text, (@start + 2)/2, CASE @end WHEN -1 THEN (datalength(text))
       ELSE (@end -@start + 2)/2 END)
       FROM ::fn_get_sql(@Handle)

问：我需要支持通过防火墙的事务复制。发布服务器和分发服务器位于防火墙外，而订阅服务器则位于防火墙内。订阅服务器被设置为在 1433 上侦听，以下是我机器的名称：发布服务器：PUBMACHINE，分发服务器：DISTMACHINE，订阅服务器：SUBMACHINE。我需要打开哪些端口才能成功推送初始快照和发布？

答：如果您使用推送订阅，则只需打开 SQL Server 端口（即您的 1433 端口），因为分发代理将在分发机器上（防火墙外部）运行，并且也许可以对由快照代理生成的快照文件进行本地访问。但如果您使用请求订阅，则在订阅机器上运行的分发代理将需要穿过防火墙对快照文件进行访问。以下是一些您可以考虑使用的选项。
假设快照文件现已可从防火墙外的一个共享文件访问，则您可以打开 Windows® 穿过防火墙的文件共享端口，以便让在防火墙内部运行的分发代理可以访问位于防火墙外部的快照文件（注意，这可能会给基础结构的其他部分带来安全隐患）。请注意，如果您已将一个本地路径配置为默认的快照位置（SSMS 默认值），则可能需要使用分发代理的 /AltSnapshotFolder 选项来覆盖快照文件的拾取位置。
您也可以对复制进行配置，以使用 FTP 来传送快照文件（这时需要打开端口 21）。

问：我想知道停用 SQL Server 2005 中的 SA 帐户会带来哪些问题，以及停用 SA 是否真的可以增强安全性。是否有关于这个问题的白皮书？

答：在新的 SQL Server 2005 中，当未启用混合模式时，默认会停用 SA 帐户并会为其随机生成一个密码。您也可以手动将其停用。没有关于这个问题的白皮书，但最佳实践白皮书中对停用和重命名登录进行了讨论。
如果要防止 SA 帐户被破坏，可以对其进行重命名。只需记住，如果停用一个帐户，就需要为其设置一个新密码。
要回答您关于这是否提供了真正的安全性这个问题，请记住，停用帐户之所以能够增强安全性是因为当帐户停用时，对密码进行猜测是徒劳的。无论黑客或病毒有多长的时间，对一个被锁定的帐户进行强制攻击都不会成功。重命名或停用 SA 会破坏依靠此 SA 帐户进行连接的应用程序。因此首先应找出这些应用程序并对它们进行修复或清除。正如前面提到的，只有重新启用该帐户后，才可使用该帐户连接到数据库。此外，因为先前的身份验证过程失败，失败的尝试对受攻击系统产生的影响较小。

问：我的一个大型在线事务处理 (OLTP) 数据库的日志文件是数据文件的两倍大小。我已经尝试使用下面的命令将该日志文件缩小到合理的大小，但我需要进一步缩小该文件：
backup database syslogs to backupfile
DBCC SHRINKFILE (syslogs_log)

答：您应将您的备份数据库更改为一个备份日志语句。这样，就可以将该数据库置于简单恢复模式并执行 shrinkfile 语句。日志缩减完毕后，请将数据库设回其先前的恢复模式并对数据库进行备份。如果日志文件仍未缩减，请检查并确保没有打开的事务（使用 dbcc opentran 命令）。知识库文章“support.microsoft.com/kb/907511”提供了更多信息。

问：如果在执行计划的 SQL Server Agent 作业时发生故障转移，故障转移后会对该作业产生怎样的影响？是否需要手动重新启动该作业？

答：是的，如果没有其他处理程序，则需要手动启动该作业。如果不想手动重新启动作业，也可以编写一个脚本，在作业完成时更新表格。如果值为 1，则表示作业已经执行；其他值则表示作业尚未完成，另一个作业稍后将进入并发出启动命令。因此，当作业执行过程中因发生故障转移而需要重新运行时，通过编写一个脚本，可以减少对那些在午夜执行，且又必须在下一个工作日之前完成的重要作业所产生的担心。
提示：升级和 DBCC UPDATEUSAGE
要从 SQL Server 2000 升级到 SQL Server 2005 吗？
如果是，请务必在数据库完成升级后运行 DBCC UPDATEUSAGE。
DBCC UPDATEUSAGE 会报告并更正目录视图中错误的页数和行数。这些错误的数据需要进行更正，因为它们可能会导致 sp_spaceused 系统存储的程序返回错误的空间使用情况报告。在 SQL Server 2005 中，这些值始终能够被正确地维护，因此这些数据库从来不会出现错误的计数。但是，将数据库升级到 SQL Server 2005 可能会包含无效的计数，因此您需要在升级后运行 DBCC UPDATEUSAGE。
接下来将说明 DBCC UPDATEUSAGE 是如何工作的。它会更正表格或索引中每个分区的行、使用的页面、保留的页面、叶页面以及数据页面的计数。如果系统表格中的数据都正确，则 DBCC UPDATEUSAGE 不返回数据。如果发现并更正了错误的数据，并且您未使用 WITH NO_INFOMSGS，则 DBCC UPDATEUSAGE 会返回系统表格中被更新的行和列。
DBCC UPDATEUSAGE 也可用于同步空间使用计数。由于在大型表格或数据库上运行 DBCC UPDATEUSAGE 可能需要一些时间，因此它通常是在您怀疑 sp_spaceused 返回的值不正确时才使用。请注意，在返回表格或索引的空间信息前，sp_spaceused 在运行 DBCC UPDATEUSAGE 时可以接受一个可选的参数。
SQL Server 2005 中的 DBCC CHECKDB 已经得到了增强，它可以检测页数和行数何时变为负值。当检测到负值时，DBCC CHECKDB 会发出一条警告，并建议您通过运行 DBCC UPDATEUSAGE 来解决这个问题。虽然这个问题看似由数据库升级到 SQL Server 2005 引起，但实际上无效的计数在升级操作之前已经存在。
这里有一个如何更新当前数据库中所有对象的页数/或行数的示例。下面的命令将 0 指定为数据库的名称，DBCC UPDATEUSAGE 会报告当前数据库的更新信息：
DBCC UPDATEUSAGE (0);
GO
要更新页数和/或行数，如 AdventureWorks 的页数和/或行数，并且不显示信息性消息，您可以运行类似下面这个命令，该命令指定 AdventureWorks 为数据库的名称，然后不显示所有的信息性消息：
USE AdventureWorks;
GO
DBCC UPDATEUSAGE (‘AdventureWorks’) WITH NO_INFOMSGS; GO
更多信息，请在 SQL Server 联机丛书中查阅“DBCC UpdateUsage”。

Thanks to the following Microsoft IT pros for their technical expertise: Ken Adamson, Sunil Agarwal, Siggi Bjarnason, Shaun Cox, Laurentiu Cristofor, Ernie DeVore, Michael Epprecht, Lucien Kleijkers, Raymond Mak, Chat Mishra (MSLI), Niraj Nagrani, Rick Salkind, Jacco Schalkwijk, Vijay Sirohi, Vijay Tandra Sistla, Matthew Stephen, and Buck Woody. Thanks to Saleem Hakani for this month's tip.


 实用工具特别推荐: SMSMap
实用工具特别推荐
SMSMap
Jeff Tondt
下载这篇文章的代码: UtilitySpotlight2007_07.exe (2477KB)

一幅图画胜过千言万语。这句著名的谚语表达的意思是，错综复杂的事情使用一张图像即可说明，或者说一张图像比大量的文字更有说服力。这句话也恰当地形容了可视化的目标，即必须迅速汲取大量的数据。
对于像我这样的系统管理服务器 (SMS) 痴迷者来说，把整个 SMS 层次结构看作一幅图画可以帮助我理解基础结构是如何部署的。或许您可以使用这样的图画，来展示管理一个 SMS 迁移计划的前后景象。在某些故障诊断案例中，这样的图表对于找出解决办法或至少获得他人的帮助是十分有益的。当然，作为一名负责任的 SMS 管理员，出于其他种种原因，您需要用文档记录系统的层次结构。

绘制图画
您完全可以靠自己绘制这样的图表。您完全可以卷起袖子，手动绘制 SMS 层次结构，亲手记录站点的设置。如果您使用 Microsoft® Operations Manager (MOM) 来监视 SMS 服务器，那么它也可以用来绘制层次结构的图表，不过我必须说明，MOM 并不是完全适用的图表工具，当然它也不会记录您的站点设置。也许还有其他方法或便捷的工具，但我还没有遇到过足以创建完美的图画和帮助记录站点设置的东西，或者至少没有达到我满意的程度。
所以，我决定自已动手。于是，SMSMap 1.0 诞生了。SMSMap 是一个 Visual Basic® .NET 应用程序，它使用 SMS SDK 中 SMS 管理的库，并通过 COM 自动执行 Microsoft Visio®。该实用工具查询目标 SMS 站点服务器，然后创建一个形象生动的 Visio 图表，并将站点设置导出到一个 XML 文件中。选择 XML 是因为它是记录站点设置的最恰当的方式。我还决定显示 SMS 角色，而不仅仅是与其他 SMS 服务器相关的物理服务器。这样可以通过 Visio 的层对图表进行补充，以便从多个视角查看 SMS 的层次结构。
图 1 放射格式
图 1 放射格式
目前在该程序中可选择六种不同格式的 Visio 图表。例如，图 1 采用放射格式显示非常简单的 SMS 层次结构，图 2 则采用流程图格式显示相同的层次结构。对于大得多的层次结构来说，该实用工具也表现非常出色，但在这里我想让事情简单些。
图 2 流程图格式
图 2 流程图格式
某些情况下，SMSMap 可能会发展为记录所有的站点设置。目前，它只记录 SMS 站点角色和所有的边界。稍加努力，便可将更多的站点设置导出到 XML 文件中。

使用 SMSMap
SMSMap 的源代码和安装文件可从《TechNet 杂志》网站获得。要安装该程序，只需执行 SMSMapSetup.msi，即可帮助您完成安装过程。请记住，SMSMap 使用 Visio，所以您还必须事先安装 Visio。安装后，请执行 C:\Program Files\Microsoft\smsmap\smsmap.exe（除非您将它安装到默认位置以外的其他位置）。
您可以在任意计算机上运行 SMSMap，而无需在站点服务器上运行它（而且许多 SMS 站点服务器不太可能安装 Visio）。输入您希望发起查询的 SMS 站点服务器的名称。如果您希望查询整个层次结构，此服务器可为中心站点，否则，它可以是任意子级主站点服务器，但在这种情况下，您只能获得该子级主站点以下的层次结构。接下来，使用 domain\username 格式输入有权查询 SMS 的帐户，然后输入该帐户的密码。（密码不会显示出来，所以您可以在别人面前输入。）
有六个单选按钮可用来选择布局，您可以选择在绘图中允许或者阻止 SMS 角色的出现。这些复选框位于“Options”（选项）选项卡下。按下“Draw”（绘制）按钮即可启动该实用工具。它首先检查 Visio 是否可用，然后查询指定的 SMS 主站点服务器，并将对象添加到 Visio 图表中。当 SMSMap 正在转储对象时，Visio 图表看起来可能不太美观，但实用工具最后会将它们组织成您一开始指定的格式。
深入探讨
现在您已了解使用 SMSMap 记录您的 SMS 层次结构的原因和方法。对于那些想展示其开发实力的人士，我们来进一步了解该实用工具的工作原理。
SMSMap 使用 Managed SMS Site Server Interfaces 收集 SMS 信息，使用 Visio Primary Interop Assemblies 生成具有所有必需形状的 Visio 图表。SMS 2003 SDK Version 3.1 包含了最新发布的 Managed SMS Site Server Interfaces。您可以使用这组托管接口，通过任何支持 Microsoft .NET Framework 的语言或应用程序连接和配置 SMS 站点服务器。
这些接口使用 System.Management 命名空间，通过 Windows® Management Instrumentation (WMI) 与 SMS 提供者交互。要想使用这些接口，您必须使用与 .NET 兼容的语言（如 C#、Visual Basic .NET 等）并引用 SMS SDK 随附的 .NET 程序集 Microsoft.SystemsManagementServer.Automation.dll 来开发应用程序。
.NET Management 类清除了许多 WMI 对象模型的特性，从而提供面向对象的统一模型。WMI 连接、对象枚举、方法执行、对象删除、对象检索和事件捕获等基本任务可通过 .NET Management 类实现。

Visio 主互操作程序集
您可以通过主互操作程序集使用托管代码以编程方式控制 Visio 等 COM 应用程序。Visio 主互操作程序集使您能够将 Visio 的功能集成和扩展到托管应用程序中。
如果您的计算机上已安装了 .NET Framework，当您随后安装 Visio 时，安装程序就会将 Visio 主互操作程序集添加到您计算机上的全局程序集缓存 (GAC) 中。您可以从您的托管应用程序中添加 Visio 主互操作程序集的引用。
在项目中添加该引用后，您就可以开始在您的托管应用程序中使用 Visio 对象了。Visio 有非常丰富的对象模型，提供一组类、接口和枚举，从而使您能够以编程方式创建图表。

程序流程
刚才我已说明了 Visio 和 SMS 的主要组件接口，下面我来解释一下实用工具自身的流程。
使用托管接口的第一步是连接到 SMS 提供者。这可以通过创建一个 SMSProvider 类的新实例来实现。该类会在内部查找指定站点服务器的 SMS 提供者，并使用一组给定的凭据连接到该提供者。如果提供者在本地计算机上，则连接到提供者时将使用当前登录的凭据，而不是提供的凭据。虽然可以在 SMS 服务器上运行 SMSMap，但我建议您在装有 Visio 的独立工作站上运行它。大多数 SMS 站点服务器出于显而易见的原因并未安装 Visio。
当您通过 SMSProvider 类访问 SMS 站点上的数据时，从安全权限的角度来说，就如同使用 SMS 管理员控制台一样。举例来说，如果您试图通过一个 SMSProvider 配置某站点服务器的设置，那么，您连接到提供者所用的帐户必须具有如同使用管理员控制台一样的同一组权限。
SMSProvider 类提供了一个 GetSiteSettings 方法，通过该方法可获得当前站点（提供者所属站点）或具有特定站点代码的任意站点的站点设置。图 3 中的代码片断说明 SMSMap 如何连接到目标站点服务器的提供者。用户凭据预期以 Domain\User 格式传递。您还可以指定“.”来表示当前计算机。图 3 中还含有帮助在用户界面中显示结果及用于日志记录的代码。
Figure 3 GetSiteSettings 代码段 (Close Figure 3)
Imports System.Management
Imports Microsoft.SystemsManagementServer.Automation

 oProvider = New SMSProvider(txtServer.Text, txtUser.Text, txtPassword.Text)
 oSite = oProvider.GetSiteSettings()
 Trace.WriteLine(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Connected to “ & txtServer.Text & “: “ & My.Computer.Clock.LocalTime)
 Application.DoEvents()
...
下一步是建立用于收集和记录目标站点服务器 SMS 信息的 XML 文件，如图 4 所示。
Figure 4 创建 XML 文件 (Close Figure 4)
‘ First, Create the XML File
 oWriter = New XmlTextWriter(m_sXmlFile, System.Text.Encoding.UTF8)
 oWriter.WriteStartDocument()
 oWriter.WriteStartElement(“Hierarchy”)

 ‘ Export Target Site to XML
 oWriter.WriteStartElement(“Site”)
 oWriter.WriteAttributeString(“Code”, oSite.SiteCode.ToString.ToUpper)
 oWriter.WriteStartElement(“SiteServer”)
 oWriter.WriteAttributeString(“Name”, oSite.SiteServer.ToString.ToUpper)
 oWriter.WriteEndElement()
 oWriter.WriteStartElement(“ParentSiteCode”)
 oWriter.WriteAttributeString(“SiteCode”, “THIS_IS_THE_TOP”)
 oWriter.WriteEndElement()

...
接下来，目标站点需要在 Visio 图表中绘制，并在用户界面和日志中更新，如同在图 5 所看到的那样。
Figure 5 在 Visio 中绘制站点 (Close Figure 5)
 ‘Draw Central Site
 dblXLocation = 4.25
 dblYLocation = 8.5
 vApp = New Visio.Application()
 vDoc = vApp.Documents.Add(“”)
 vStencil = vApp.Documents.OpenEx(TEMPLATEPATH, 4)
 ‘ Add Layers
 vExistingLayers = CType(vDoc.Pages(1).Layers, Visio.Layers)
 vLayer = CType(vExistingLayers.Add(“Site”), Microsoft.Office.Interop.Visio.Layer)

...

 If oSite.SiteType = SiteTypes.PrimarySite Then
 vFlowChartMaster = vStencil.Masters(“Primary Site”)
 ElseIf oSite.SiteType = SiteTypes.SecondarySite Then
 vFlowChartMaster = vStencil.Masters(“Secondary Site”)
 End If
 vToShape = vApp.ActivePage.Drop(vFlowChartMaster, dblXLocation, dblYLocation)
 vLayer.Add(vToShape, preserveMembers)

...
为了遍历目标站点下的整个层次结构，须执行与上述相同的基本代码（查询 SMS 和在 Visio 中绘图）。无论层次结构有多大，通过递归调用一个名为 Level 的函数，可确保对所有的子站点都进行查询。对于目标站点下的每个子站点，Level 收集 SMS 站点信息，并在 XML、用户界面和日志中记录这些信息。最后，图 6 显示如何使用实用工具开始时所选择的格式对 Visio 图表进行格式处理。然后，XML 和日志文件关闭。
Figure 6 最后完成 (Close Figure 6)
 vDoc.Pages(1).Layout()
 vDoc.Pages(1).ResizeToFitContents()

 ‘Calculate the page width and height with a 5% boundary
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageHeight”)
 dHeight = visCell.Result(“in”)
 visCell = vDoc.Pages(1).PageSheet.Cells(“PageWidth”)
 dWidth = visCell.Result(“in”)
 dHeight = dHeight + 1
 dWidth = dWidth + 1
 vDoc.Pages(1).PageSheet.Cells(“PageHeight”).Result(“in”) = dHeight
 vDoc.Pages(1).PageSheet.Cells(“PageWidth”).Result(“in”) = dWidth
 vDoc.Pages(1).CenterDrawing()
 Trace.WriteLine(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 ListBox1.Items.Add(“Arranged Sites “ & oSite.SiteServer & “: “ & My.Computer.Clock.LocalTime)
 vFlowChartMaster = vStencil.Masters(“Background world”)
 vApp.ActivePage.Drop(vFlowChartMaster, 0, 0)

 ‘Finish up
 vDoc.SaveAs(SAVENEWFILE)
 vDoc.Close()
 vApp.Quit()
 vDoc = Nothing
 vApp = Nothing
 GC.Collect()

...

只是一个开始
当然，这只是一个开始，还有很多改进的可能。设备管理点需要进行检查，我在 SDK 中还没有看到它们。为了完整记录一个站点，还可添加另外一些站点设置。也许在添加更多种类的 Visio 布局设置方面还有一些更多的工作要做，从而让小型和大型层次结构看起来更美观。每一布局类型在试图产生有效的显示效果时都存在其自身的问题。当然，添加对 System Center Configuration Manager 2007 的支持是非常重要的下一个步骤。但即便如此，SMSMap 第一版还是能帮助 SMS 管理员通过 Visio 的层和透明度来显示全貌，并尝试一些“假设分析”方案。
如果您下载源代码，便可以扩展该实用工具，以满足自己的需要。我分别在 Windows XP SP2 和 Visio 2003 以及 Windows Vista™ Enterprise 和 Visio 2007 上对 SMSMap 进行了测试。如果您有关于如何改进该实用工具的建议，请给我发电子邮件：jeff.tondt@microsoft.com。

Jeff Tondt是 Microsoft Consulting Services 的一名 II 级资深顾问。他关注的领域包括系统管理、自动化和修补程序管理。他是一名 SMS 主题事项专家，他的联系方式如下：jeff.tondt@microsoft.com。


 IT 运作方式: 排除 RPC 错误
IT 运作方式
排除 RPC 错误
Zubair Alexander

如果您多年来使用的都是 Windows 服务器平台，那么可能曾经看到过远程过程调用 (RPC) 错误。它们提示您 RPC 服务器无法使用，或者没有更多的可用终结点，或提供某个其他难懂的警告。如果您对这些消息感到困惑，请继续阅读。我会
谈到一些比较常见的错误，以及可用来识别所遇到的 RPC 错误的各种技术，并会讨论一些可以解决某些特定问题的解决方案。但是在我讨论 RPC 错误和解决方案之前，先让我们大致了解一下 RPC 技术。

什么是 RPC？
RPC 是一种进程间通信 (IPC) 方法，客户端和服务器可使用这种方法来进行相互之间的通信。简单地说，RPC 可被程序（通常是客户端计算机上的程序）用来执行服务器计算机上的程序。例如，Microsoft® Outlook® 客户端可通过使用 RPC 与 Microsoft Exchange Server 通信。客户端计算机会使用某些参数将消息发送到服务器计算机。而服务器则会以一条包含执行程序的结果的消息响应客户端。
此过程的组成部分是终结点，即计算机上的名称、端口或端口组，由服务器监视经过其传入的客户端请求。更具体地讲，它是用于 RPC 的服务器进程特定于网络的地址。
终结点映射程序 (Endpoint Mapper) 是 RPC 子系统的一个组成部分，负责响应客户端要解析动态终结点的请求。在某些情况下，终结点映射程序还负责动态地将终结点分配给服务器。
另一个重要的 RPC 组件就是 Locator 服务。它维护网络上的 RPC 服务和服务器列表。Windows® 客户端会连接到服务器消息块 (SMB) 端口（TCP 139 和 445）上的域控制器，并通过 Locator 服务搜索 RPC 服务或服务器。
大多数内置的 Windows 服务都通过 RPC 相互通信。例如，证书服务、DCOM、FRS、MSMQ、MAPI 和 Active Directory® 复制服务都使用 RPC 来进行通信。因此，如果 RPC 服务不能网络上正常运行，则您可能就会遇到很多通信问题。

RPC 错误
现在让我们看一些 RPC 服务失败时您可能会遇到的错误。（这并不是完整的列表。）
当文件复制服务 (FRS) 失败时，运行时可能会出现可怕的“RPC 无法使用”错误。当您试图映射一个驱动器时，可能会遇到“拒绝访问”错误。当使用 Active Directory 用户和计算机时，可能会看到错误消息“指定的域不存在或无法联系。”登录域时，可能会看到一条错误消息，指明“缺少该系统主域的计算机帐户或该帐户的密码不正确，无法让您登录此域。”
当 Microsoft Outlook 客户端试图与 Exchange Server 通信时，RPC 失败可能会导致客户端遇到“您的登录信息不正确”或“Outlook 无法登录”等令人误解的错误。
除了这些错误外，当 RPC 服务不可用时，您可能还会遇到其他问题。例如，可能会无法浏览“网上邻居”中的域，或者可能无法打开“组策略”管理单元。
这些只是一部分示例而已，在这些示例中您可能没想到 RPC 会引起问题。在更多示例中，以及在涉及远程过程的任何时候，RPC 问题都有可能是造成您困境的根本原因。那么您要如何确定，以及更重要的是，如何跟踪到精确的错误呢？让我们来了解一下。

故障排除
如果您怀疑您的 RPC 服务遇到了问题，您可以使用好几个工具来诊断这些问题。
一个是 Repadmin 工具。这个程序通常是用来监视和排除 Active Directory 复制问题，但是它也可以用来排除 RPC 终结点映射程序的问题。要运行该工具，可在命令提示符下键入 repadmin /bind。如果您遇到了 RPC 问题，会看到类似下面这样的消息：“终结点映射程序没有更多可用的终结点。”这是与 RPC 相关的问题的第一个提示。
另一个选择是使用“域控制器”诊断工具 (DCDiag)，这是一个通过域控制器诊断问题的命令行程序。如果您看到错误“状态为 1722：RPC 服务器无法使用”，您就知道遇到了“域控制器”诊断工具恰巧发现的 RPC 问题。
很多时候，您都在使用 Ntdsutil（用来管理 Active Directory 和执行大量维护任务的命令行工具），这个时候如果您试图连接到服务器，就可能会遇到 RPC 错误。最有可能的就是您会看到更常见的错误之一，例如“终结点映射程序没有提供更多的终结点”。同样，这是 RPC 可能存在问题的一个提示。如果真是 PRC 存在问题，检查域控制器上“组策略”对象一致性的 Gpotool 工具也会报出同样的错误。
使用 Dcpromo 工具将 Windows 2000 Server 或 Windows Server® 2003 服务器提升为域控制器时产生的 Dcpromo.log 也可以显示 RPC 的问题。例如，如果提升失败，可以查看一下该日志。它位于 %windir%\debug 文件夹。列出的错误大意是目录服务无法复制分区，或无法创建对象。在此消息结束的地方会有一个错误代码。下面是您可以在 Dcpromo.log 中看到的错误消息类型的一个示例：

08/14 10:35:04 [INFO] Error - The Directory Service failed to replicate
 the partition CN=Schema,CN=Configuration,DC=.. (1722) 08/14 10:35:04 [INFO]
  NtdsInstall for dc.contoso.com. returned 1722 08/14 10:35:04 [INFO]
   DsRolepInstallDs returned 1722 08/14 10:35:04 [ERROR] Failed to install
    the directory service (1722)
注意错误代码 1722，在这条消息中出现了四次，这指明 RPC 服务器无法使用。图 1 列出了部分错误代码及其说明，更多的错误代码及其说明可以在 msdn2.microsoft.com/ms681386 中找到。
Figure 1 错误代码及其说明 (Close Figure 1)

错误代码 | 说明
58 | 指定的服务器不能执行请求的操作。
1721 | 没有足够的资源可用于完成此操作。
1722 | RPC 服务器不可用。
1723 | RPC 服务器太忙，无法完成此操作。
1727 | 远程过程调用失败，尚未执行。
1753 | 终结点映射程序没有提供更多的终结点。

解决 RPC 错误
既然您已掌握了检测某些 RPC 错误的方法，接下来就让我们看一下部分解决方案。
Microsoft 客户端会连接到端口 135 上的 RPC 终结点映射程序。然后终结点映射程序会告诉该客户端请求的服务在侦听哪一个端口。系统会动态分配这些端口号，可以是 1024 和 65,535 之间的任何端口号。当您遇到错误时，例如 1753，就表示终结点映射程序没有提供更多的终结点，这意味着 RPC 终结点映射程序无法对服务使用大于 1024 的端口。我们稍后再进一步讨论这个主题。
您需要做的第一件事是检查服务器上 RPC 服务的状态。根据服务器角色的类型，RPC 和 RPC Locator 服务应具有图 2 中所列的状态。如果两个服务都没有像图中显示的那样配置，请尝试调整状态，重新启动服务器，然后进行测试，看它是否解决了您的问题。
Figure 2 RPC 服务的状态 (Close Figure 2)

服务器角色 | RPC 服务 | RPC Locator 服务
Windows Server 2003—域控制器 | 已启动，自动 | 已停止，手动
Windows Server 2003—成员服务器 | 已启动，自动 | 已停止，手动
Windows Server 2003—独立服务器 | 已启动，自动 | 已停止，手动
Windows 2000 Server—域控制器 | 已启动，自动 | 已停止，自动
Windows 2000 Server—成员服务器 | 已启动，自动 | 已启动，手动
Windows 2000 Server—独立服务器 | 已启动，自动 | 已停止，手动
请验证您的客户端是否可以成功地 Ping 存在连接问题的服务器。例如，如果您在与 IP 地址为 192.168.1.200，名为 DC1 的服务器通信时遇到了问题，则在命令提示符下使用下面的命令来验证 DNS 是否在正确地解析主机 DC1：
Ping –a 192.168.1.200
请确保是将 –a 开关与 IP 地址（而不是主机名）搭配使用。
如果一切顺利，您应该会得到 DC1 的响应，如图 3 中所示的 Ping 响应。注意 Ping 不只是解析 IP 地址 192.168.1.200，还解析主机名 dc1.contoso.com。这确定了 DNS 名称解析在正常运行，并且如期望的那样正确地解析到主机 dc1.contoso.com。
Figure 3 Ping 响应 (Close Figure 3)
C:\WINDOWS>ping -a 192.168.1.200

Pinging dc1.contoso.com [192.168.1.200] with 32 bytes of data:

Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128
Reply from 192.168.1.200: bytes=32 time<1ms TTL=128

Ping statistics for 192.168.1.200:
  Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
  Minimum = 0ms, Maximum = 0ms, Average = 0ms
您还应确保 Windows XP 或 Windows 2000 客户端上的注册表至少包含图 4 右窗格中列出的四个 ClientProtocols。
图 4 列入注册表的 RPC ClientProtocols
图 4 列入注册表的 RPC ClientProtocols
如果缺少任一项，则添加一个图 4 中所示名称和数据类型的新字符串值。在默认情况下，还有一个名为 ncacn_nb_tcp 的第五项，它可用来识别基于 TCP 的 NetBIOS，将其作为终结点的协议家族。根据您的配置，您的 ClientProtocols 下可能没有列出这一项，这时您可以手动添加此项以查看它是否解决了 RPC 错误。
注意列在图中左窗格中的 Rpc 文件夹下的项，即 ClientProtocols、NameService、NetBios 和 SecurityService。如果您恰巧看到名为 Internet 但没有值的项，请尝试删除该项，然后重新启动您的计算机。这可能会帮助您解决问题。但是在您修改 Windows 注册表时始终要非常小心。
如前面所述，RPC 可以使用 1024 到 65,535 之间的端口，因此您需要确保这些端口没有被防火墙封锁。要确保端口开放的最简单的方法就是使用“端口查询”工具。这个工具有两种类型：命令行版本 (PortQry) 和 GUI 版本 (PortQueryUI)。
PortQry 可在 Microsoft 下载中心下载。有关其他信息，请查看文章“有关 Portqry.exe 命令行实用工具的说明”。在那里您可以找到 PortQry 状态报告的简要说明以及用来解决问题的命令示例。请不要忘记您还可以使用 GUI 版本，它更加简单，可以在 go.microsoft.com/fwlink/?LinkId=73740 下载。
使用“端口查询”时，您应该确保在没发生过 RPC 错误的计算机上运行它，并且是针对发生了 RPC 问题的计算机来运行它。例如，如果您想验证端口 135（它被 RPC 终结点映射程序占用）是否开放，可以在命令提示符下使用 PortQry，如下所示：
portqry -n [servername] -e 135
无论您使用的是 PortQuery 还是 PortQueryUI，您都会获得结果，如下所示：
Starting portqry.exe -n 192.168.1.200 -e 135 -p TCP ...
Querying target system called:
 192.168.1.200
Attempting to resolve IP address to a name...
IP address resolved to dc1.contoso.com
querying...

TCP port 135 (epmap service): LISTENING
最后一行显示端口 135 是开放的。否则，最后一行会指明“未侦听”。
要查看端口的范围，请输入以英文逗号隔开的端口号范围，例如“135,1024-5000”。

其他解决方案
如果尝试了目前列出的所有办法还是没有解决您的问题，这里还有一些其他方法供您选择。根据您环境中的具体问题，您可能想要尝试对注册表进行下列其中一项修改。（等等！在修改注册表前，请确定您已备份您的系统，尤其是注册表，这很重要；这样如果真的发生错误，您可以将您的计算机恢复到之前的状态。)
一个方法是调整 MaxUserPort，以指定当应用程序请求系统的可用用户端口时 TCP 可分配的最大端口号。在默认情况下，Windows Server 2003 会将 MaxUserPort 的值设置为 5000，这表示它以 5000 作为最大端口号，即使此项不存在。根据您的配置，您的注册表中可能没有此项，这时您可以将此项添加到图 5 所示的位置。
图 5 注册表中的 MaxUserPort 设置
图 5 注册表中的 MaxUserPort 设置
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Port range = 5000 – 65534
Default = 5000
在修改注册表时，您需要注意任何其他潜在的负面影响，它并不总是那么容易。如果将这个值设置为 50,000，则修改此项可能会对 Microsoft Exchange Server 有影响。如果 Exchange Server 最佳实践分析工具 (BPA) 发现 MaxUserPort 注册表项的值小于 50,000，它会显示一个警告。Microsoft 建议您将值设置为 60,000；否则您可能会引发命名服务提供程序接口 (NSPI) 代理警告，例如事件 9040。有关详细信息，请参阅 Microsoft 的文档“MaxUserPort 值太小”。
您还可以调整 TcpMaxDataRetransmissions。TCP 数据包期望能收到接收端的确认。如果在计时器到时之前还没有确认，则会重传数据包，最多 TcpMaxDataRetransmissions 次。此参数的默认值是 5，但是您可能想尝试 4 或 3 这些值。请不要使用小于 3 的值。
如果 TcpMaxDataRetransmissions 注册表项不存在，您可以将它添加到注册表的下列位置，如下所示：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Valid range = 0 - 0xFFFFFFFF (hexadecimal)
Default = 5
有关 TcpMaxDataRetransmissions 的详细信息，请参阅 Microsoft 知识库文章 170359“如何修改 TCP/IP 最大重传超时时间”。
另一个您可能想实验的注册表项是 TcpTimedWaitDelay。如果用户端使用了过多的端口，很可能它会在 TCP/IP 释放关闭的连接之前用尽端口。这是因为 TCP/IP 直到经过段最大生存时间 (MSL) 的两倍时间后才会释放连接（这称为时间等待状态）。此外，因为每个 MSL 都被定义为 120 秒，而 TCP/IP 直到经过 2 个 MSL 后才会释放连接，因此需要长达 240 秒（4 分钟）的时间才能让 TCP/IP 释放一个关闭的连接。注意，这是一个使用 Service Pack 进行改正后的 Windows NT® 中已知的问题；因此目前您不太可能会遇到这个问题。但是，Microsoft 建议调整这个设置，使之成为一个可以解决 RPC 终结点映射程序错误的可能解决方案，正如知识库文章“如何排除 RPC 终结点映射器错误”中所说明的一样。
可将 TcpTimedWaitDelay 添加到注册表的下列位置：
HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Data type = REG_DWORD
Range: 30 - 300 (decimal)
Default: 0xF0 (240 decimal)
有关 TcpTimedWaitDelay 的详细信息，请参阅知识库文章“Windows NT 客户端用尽端口”。尽管该文章没有建议任何特定的数字，但是您可能会想将 TcpTimedWaitDelay 降到以十进制表示的 60（秒），而以十六进制表示则为 3c。

结束语
RPC 错误可能是您的网络出现各种通信错误的根本原因。幸运的是，您现在有好几种创新方法，可以帮助排除这些难以捕捉的问题。我在这里推荐的工具有些是内置的，有些是 Windows Server Resource Kit 中提供的。很多都已在图 6 中列出。您可以使用这些工具来检测 RPC 错误的原因和位置，然后使用本文列出的其中一项技术来解决这些错误。
Figure 6 RPC 故障排除工具 (Close Figure 6)

工具 | 说明
DCDiag | 分析域控制器的状态。
事件查看器 | 显示记录的事件。
Gpotool | 确定策略是否有效、一致。
NetDiag | 用于测试网络连接。
Network Monitor | 监视和捕获网络通信。
Ntdsutil | 为 Active Directory 提供管理工具。
PortQry，PortQueryUI | 用于 TCP/IP 连接测试。
Repadmin | 诊断 Windows DC 之间的复制问题。
RPCDump | 通常与 Network Monitor 一起使用。
RPCPing | 用于确认 RPC 连接。

Zubair Alexander 是 MCSE、MCT 和 Microsoft MVP，也是一家 IT 培训和咨询企业 SeattlePro Enterprises 的所有者。他的经验涉及 IT 培训领域的诸多方面：作家、大学教授、顾问、网络工程师、公开演讲人、安全架构师、系统管理员、技术编辑和培训师。您可以通过 alexander@techgalaxy.net 与 Zubair 联系。


 网络专家: 通过 VPN 连接进行 IPv6 通信
网络专家
通过 VPN 连接进行 IPv6 通信
Joseph Davies

当您开始评估 Intranet 上 Internet 协议版本 6 (IPv6) 的作用，并开始规划部署时，应了解如何在 Windows 中通过虚拟专用网络 (VPN) 连接来支持 IPv6 通信。使用 VPN 连接，可以扩展您的网络，它可通过公共网络（如 Internet）来建立与专用网络
的链接。VPN 连接拥有双层保护，一个是强大的身份验证协议，可验证连接用户的凭据，另一个是加密方法，可实现数据机密性。
Windows® XP 和 Windows Server® 2003 包含一个 IPv6 协议堆栈，但是有很多核心服务和网络组件并不支持 IPv6。Windows Vista™ 和 Windows Server 2008（以前代号为“Longhorn”）功能齐全，可支持 IPv6，在默认情况下便可安装和启用。实际上，几乎所有装有 Windows Vista 和 Windows Server 2008 的网络应用程序和服务都支持 IPv6。本月我将研究 Windows Vista、Windows Server 2008、Windows XP 和 Windows Server 2003 是否支持 VPN 连接发送的 IPv6 通信。这些 VPN 通信通过 Internet 协议版本 4 (IPv4) 和 IPv6 Internet 建立。

IPv4 Internet 上的 VPN 连接
现在大多数 Intranet 的 VPN 连接都通过 IPv4 Internet 创建。图 1 显示了这种类型的 VPN 连接基于 Windows 的组件。这些组件包括：
图 1 IPv4 Internet 上的 VPN 连接基于 Windows 的组件
图 1 IPv4 Internet 上的 VPN 连接基于 Windows 的组件
VPN 客户端 这是一台可以启动对 VPN 服务器远程访问的 VPN 连接，并可与 Intranet 资源进行通信的计算机。远程访问 VPN 连接使 VPN 客户端可以像直接连接到 Intranet 一样执行操作。VPN 客户端即可运行 Windows 的客户端版本，也可运行 Windows 的服务器版本。
VPN 服务器 这台计算机可以侦听远程 VPN 连接尝试，强制执行身份验证和连接要求，以及在 VPN 客户端与 Intranet 资源之间传送数据包。VPN 服务器通常会运行具有“路由和远程访问”服务的 Windows 的服务器版本。
VPN 路由器 VPN 路由器是一台可以启动或侦听 VPN 点对点连接尝试的计算机。VPN 点对点连接可以将 Intranet 的两个部分连接在一起。VPN 路由器运行 Windows 的服务器版本以及“路由和远程访问”服务。
VPN 连接 根据 VPN 协议的封装的定义，VPN 连接是 VPN 客户端和 VPN 服务器之间或 VPN 不同路由器之间的逻辑链接。
启用 IPv6 的 Intranet 此 Intranet 可以本机转发 IPv6 通信，也可以作为 IPv4 数据包以隧道的方式转发 IPv6 通信。
IPv6/IPv4 主机 这个 Intranet 节点可以本机收发 IPv6 通信，也可以作为 IPv4 数据包以隧道的方式收发 IPv6 通信。
基于 Windows 的 VPN 客户端、服务器和路由器可以使用下列 VPN 协议来封装通过 VPN 连接发送的数据包：点对点隧道协议 (PPTP)、基于 Internet 协议安全性的第二层隧道协议 (L2TP/IPsec) 以及安全套接字隧道协议 (SSTP)。只有包含 Service Pack 1（SP1 目前正处于测试阶段）的 Windows Vista 和 Windows Server 2008 才支持 SSTP。
对于 IPv4 Internet 上的 VPN 连接，可以使用两种方法来发送 IPv6：IPv6 数据包作为 IPv4 数据包以隧道的形式发送（下称“IPv6-over-IPv4 通信”）和本机 IPv6 通信。
在本期专栏中，根据 VPN 协议和 Windows 的版本，详细说明了对通过 VPN 连接进行的 IPv6 通信的支持情况。对于远程访问 VPN 连接，指定的 VPN 协议和 Windows 版本的组合意味着它可以获得 Windows 远程访问客户端和远程访问服务器组件的支持。

IPv6-over-IPv4 通信
使用这种方法，位于 Intranet 上的远程访问客户端或 IPv6/IPv4 主机使用 IPv4 报头来封装 IPv6 数据包，并将结果作为 IPv4 数据包发送。对于 Intranet，站内自动隧道寻址协议 (ISATAP) IPv6 转换技术 (RFC 4214) 使 IPv6/IPv4 节点可以在仅使用 IPv4 的 Intranet 上交换 IPv6 通信。使用 ISATAP，可以不必配置或升级您现有的路由器，就能在仅使用 IPv4 的 Intranet 上启用 IPv6 连接，从而支持本机 IPv6 寻址和转发。有关 ISATAP 的详细信息，请参阅位于 microsoft.com/technet/network/ipv6/ipv6coexist.mspx 的“IPv6 转换技术”。
图 2 显示了使用 IPv4 Internet 上的 VPN 连接发送 IPv4 数据包时用于 VPN 通信的通用数据包结构。IPv4 数据包由 VPN 协议封装，包含报头和报尾，报尾的有无依 VPN 协议而定。结果的封装含有允许在 IPv4 Internet 上转发的 IPv4 报头。
图 2 使用 IPv4 Internet 上的 VPN 连接的 IPv4 数据包
图 2 使用 IPv4 Internet 上的 VPN 连接的 IPv4 数据包
对于 IPv6-over-IPv4 通信，通过 VPN 连接发送的 IPv4 数据包的负载是 IPv6 数据包。图 3 显示了使用 IPv4 Internet 上的 VPN 连接发送 IPv6-over-IPv4 数据包时用于 VPN 通信的通用数据包结构。
图 3 使用 IPv4 Internet 上的 VPN 连接的 IPv6-over-IPv4 数据包
图 3 使用 IPv4 Internet 上的 VPN 连接的 IPv6-over-IPv4 数据包
对于远程访问 VPN 连接，IPv4 Internet 上的 IPv6-over-IPv4 通信由 Windows Vista、Windows Server 2008、Windows XP SP1 或更高版本及 Windows Server 2003 中的 PPTP 和 L2TP/IPsec，以及 Windows Vista SP1 和 Windows Server 2008 中的 SSTP 支持。而对于 VPN 点对点连接，IPv4 Internet 上的 IPv6-over-IPv4 通信则由 Windows Server 2008 和 Windows Server 2003 中的 PPTP 和 L2TP/IPsec 支持。

本机 IPv6 通信
对于本机 IPv6 通信，VPN 客户端、服务器或路由器可以在不启动 IPv4 封装的情况下通过 VPN 连接发送 IPv6 数据包。这项功能对具有本机 IPv6 连接的 Intranet 很有效，它要求 VPN 客户端、服务器和路由器支持 IPv6 控制协议 (IPV6CP)，即 RFC 2472，该协议定义了 IPv6 节点如何协商基于点对点协议 (PPP) 的连接的 IPv6 配置选项。Windows Vista 和 Windows Server 2008 都支持 IPV6CP，而 Windows XP 和 Windows Server 2003 则不支持。图 4 显示了使用 IPv4 Internet 上的 VPN 连接发送本机 IPv6 数据包时用于 VPN 通信的通用数据包结构。
图 4 使用 IPv4 Internet 上的 VPN 连接的本机 IPv6 数据包
图 4 使用 IPv4 Internet 上的 VPN 连接的本机 IPv6 数据包
对于远程访问 VPN 连接，IPv4 Internet 上的本机 IPv6 通信由 Windows Vista 和 Windows Server 2008 中的 PPTP 和 L2TP/IPsec，以及 Windows Vista SP1 和 Windows Server 2008 中的 SSTP 支持。对于 VPN 点对点连接，在 IPv4 Internet 上传送的本机 IPv6 通信由 Windows Server 2008 中的 PPTP 和 L2TP/IPsec 支持。

IPv6 Internet 上的 VPN 连接
您还可以在 IPv6 Internet 上创建 VPN 连接。这类 VPN 连接在目前还不常见，但是当更多的 Internet 服务提供商为其客户提供 IPv6，以及更多的公司将 IPv6 Internet 连接纳入其 Intranet 边界网络时，它们就会变得更加普遍。
为了支持 IPv6 Internet 上的 VPN 连接，使用的 VPN 协议必须支持通过 IPv6 的连接。在 Windows Vista 和 Windows Server 2008 中，L2TP/IPsec 和 SSTP VPN 协议支持通过 IPv6 的远程访问 VPN 连接。在 Windows Server 2008 中，L2TP/IPsec 支持通过 IPv6 的点对点连接。IPv6 Internet 上的 VPN 连接使用的组件与用于 IPv4 Internet 上的 VPN 连接的组件一样，都可用于远程访问和 VPN 点对点连接。
还有两种通过 IPv6 Internet 发送 IPv6 数据包的方法：IPv6-over-IPv4 通信和本机 IPv6 通信。图 5 显示了通过 IPv6 Internet 上的 VPN 连接发送数据包时 IPv6-over-IPv4 数据包的通用结构。
图 5 使用 IPv6 Internet 上的 VPN 连接的 IPv6-over-IPv4 数据包
图 5 使用 IPv6 Internet 上的 VPN 连接的 IPv6-over-IPv4 数据包
对于远程访问 VPN 连接，IPv6 Internet 上的 IPv6-over-IPv4 通信由 Windows Vista 和 Windows Server 2008 中的 L2TP/IPsec，以及 Windows Vista SP1 和 Windows Server 2008 中的 SSTP 支持。而对于 VPN 点对点连接，IPv6 Internet 上的 IPv6-over- IPv4 通信则由 Windows Server 2008 中的 L2TP/IPsec 支持。就像 IPv4 Internet 上的 IPv6-over-IPv4 通信一样，IPv6 Internet 上的 IPv6-over-IPv4 通信也要求部署 IPv6 转换技术，例如您 Intranet 上的 ISATAP。
图 6 显示了通过 IPv6 Internet 上的 VPN 连接发送数据包时本机 IPv6 数据包的通用结构。就像 IPv4 Internet 上的本机 IPv6 通信一样，IPv6 Internet 上的本机 IPv6 通信也需要 IPV6CP 支持，并要求在您的 Intranet 上部署本机 IPv6 连接。
图 6 使用 IPv6 Internet 上的 VPN 连接的本机 IPv6 数据包
图 6 使用 IPv6 Internet 上的 VPN 连接的本机 IPv6 数据包
对于远程访问 VPN 连接，IPv6 Internet 上的本机 IPv6 通信由 Windows Vista 和 Windows Server 2008 中的 L2TP/IPsec，以及 Windows Vista SP1 和 Windows Server 2008 中的 SSTP 支持。对于 VPN 点对点连接，IPv6 Internet 上的本机 IPv6 通信由 Windows Server 2008 中的 L2TP/IPsec 支持。

总结
图 7 显示了通过 VPN 连接发送 IPv6 通信的四种方法以及两种不同类型的 VPN 连接在 Windows 中受支持的情况。简单地说，如果使用 IPv6 转换技术（例如您 Intranet 上的 ISATAP），您就可以在 IPv4 和 IPv6 Internet 上通过 VPN 连接发送 IPv6-over-IPv4 通信。如果您的 Intranet 支持本机 IPv6 连接，就可以在使用 Windows Vista 和 Windows Server 2008 的 IPv4 和 IPv6 Internet 上通过 VPN 连接发送 IPv6 通信。
Figure 7 Windows 中对通过 VPN 连接进行 IPv6 通信的支持 (Close Figure 7)

发送 IPv6 通信的方法 | 远程访问 VPN 连接 | VPN 点对点连接
IPv4 Internet 上的 IPv6-over-IPv4 通信 | Windows Vista、Windows Server 2008、Windows XP SP1 和更高版本及 Windows Server 2003 中的 PPTP 和 L2TP/IPsec，以及 Windows Vista SP1 和 Windows Server 2008 中的 SSTP | Windows Server 2008 和 Windows Server 2003 中的 PPTP 和 L2TP/IPsec
IPv4 Internet 上的本机 IPv6 通信 | Windows Vista 和 Windows Server 2008 中的 PPTP 和 L2TP/IPsec 以及 Windows Vista SP1 和 Windows Server 2008 中的 SSTP | Windows Server 2008 中的 PPTP 和 L2TP/IPsec
IPv6 Internet 上的 IPv6-over-IPv4 通信 | Windows Vista 和 Windows Server 2008 中的 L2TP/IPsec 以及 Windows Vista SP1 和 Windows Server 2008 中的 SSTP | Windows Server 2008 中的 L2TP/IPsec
IPv6 Internet 上的本机 IPv6 通信 | Windows Vista 和 Windows Server 2008 中的 L2TP/IPsec 以及 Windows Vista SP1 和 Windows Server 2008 中的 SSTP | Windows Server 2008 中的 L2TP/IPsec

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


 Windows PowerShell: 重新考虑管道
Windows PowerShell
重新考虑管道
Don Jones

之前关于 Windows PowerShell 是多么得与众不同、多么得新颖、多么得令人兴奋已经谈了很多，尽管它是基于已存在多年的命令行界面概念，而且主要用在基于 UNIX 和 Linux 的操作系统中。但是这个 Windows PowerShell 与其先前版本共享的常见技术很容易
忽视 Windows PowerShell™ 真正的灵活性和独特性，及其卓越的 Windows® 环境适用性。
Windows PowerShell 中最常谈到的一个功能就是管道，不过很遗憾，它也是最容易被误解的功能之一。那是因为它依据的是 19 世纪 70 年代早期定义的术语，曾经代表完全不同且性能较弱的功能。

管道的起源
曾创建过的第一批 UNIX 外壳中，其中一个就是 Thompson 外壳，它非常原始，只具有最基本的脚本编写语言元素功能，没有变量。这个外壳有意设计得很普通，执行程序是其唯一的真实用途。但是，它引入了一种改进当时其他外壳的关键概念，即管道。通过使用 < and > 符号，可以指示该外壳将输入和输出重定向到不同命令，以及重定向来自不同的命令的输入和输出。例如用户现在可以将命令输出重定向到某个文件。
这个语法在后来得到了扩展，可以使一个命令的输出也能被输送到另一个命令的输入，从而使一长串连续的命令可以链接在一起，以完成更多复杂的任务。在外壳的版本 4 之前，都采用竖线字符“|”来进行输送，因此称为管道字符。甚至 MS-DOS® 最早的版本就已通过这些字符实施了基本管道，允许用户将 type 命令的输出输送到更多命令的输入，从而创建针对长文本文件的一次显示一页的方式。
尽管在 1975 年发布 UNIX 版本 6 之前，Thompson 外壳被广泛认为存在不足，但对外壳开发人员和用户来讲，管道的概念还是很深入人心，并且发展成了许多至今还在使用的技术。

管道文本
几乎所有外壳的限制都在于它们内在的基于文本的本质。在基于 UNIX 的操作系统中，这实际上不是限制，而是对操作系统本身如何运行的反映。UNIX 中几乎任何资源都可以以某种类型的文件表示，这意味着可以将文本从一个命令输送到另一个可以提供大量功能和灵活性的命令。
然而一提到管理信息，文本肯定是具有限制性的。例如，如果我要向您提供一个运行在 Windows 计算机上的服务列表，您肯定能明白这个意思。也许我最好是在第一栏输入服务名称，第二栏输入它的启动模式。您强大的大脑会进行透明而即时的分析或转换，文本会显示为您可以理解的有意义的信息。可是计算机没那么聪明：为了让计算机对这个列表执行一些有意义的操作，您必须告诉计算机第一栏由字符 1 到 20 组成，第二栏也许由字符 22 到 40 组成，等等。
多年来，这种文本文件分析一直是管理员必须将多个命令链接在一起的唯一方法。实际上，VBScript 和 Perl 这些脚本编写语言在字符串操作方面占优势，主要是因为它们需要能够接收一个程序或命令的文本输出，然后将该输出分析转换为某种可用于某些后续任务的有用数据。例如，我曾经写过这样一个 VBScript 作业，即接收 Dir 命令的文本输出，分析文件名称和日期的输出，然后将以前未使用的文件移到存档位置。字符串分析非常棘手，因为例外（输入数据中的各种变化）几乎一直发生，这要求您重做脚本中的逻辑以处理所有可能发生的改变。
作为 Windows 环境中管理脚本或自动化的形式，字符串分析并不是很有用。这是因为 Windows 本身不是以容易访问的文本格式存储很多信息。相反，它使用数据中心存储（例如 Active Directory®、Windows 注册表和证书存储），使得脚本专家们必须先使用一个工具来生成某些形式的文本输出，然后才是分析这个文本并使用它执行一些操作的脚本。

对象更简单
Windows 软件开发人员总是会想办法让一切变得更简单。最初，Microsoft 特意开发了 COM，想以更易于使用的方式来表示 Windows 复杂的内部工作机制。现在，Microsoft® .NET Framework 仍执行这个相同的任务——它以标准化的方式表示软件的内部工作机制。
通常，COM 和 .NET 将项目作为对象公开。（软件开发人员可能会反对这种简化，但是出于讨论目的，简单的术语就足够了。）这些对象都具有很多不同类型的成员。对于我们来说，对象的属性和方法是我们最感兴趣的地方。属性基本上在某些方面可以说明一个对象，或者它会修改对象或其行为。例如，服务对象可能会有一个包含服务名称的属性和另一个包含服务启动模式的属性。方法会导致对象执行某个操作。例如，服务对象可能会有名为 Stop、Start、Pause 和 Resume 的方法，表示可以和服务一起执行的不同操作。
从编程或脚本编写的角度来看，对象的成员是指使用点阵符号。对象会经常被分配给变量，从而为您提供物理操作该对象的方法。例如，如果我将一个服务分配给变量 $service，我可以使用语法 $service.Stop 停止该服务。或者我可以通过显示 $service.Name 来检索该服务的显示名称。

管道中的对象
因为 Windows 是一个庞大而复杂的操作系统，而且它不会以文本格式存储它的管理数据，所以较早的外壳技术根本不适合它。例如，假设我有一个名为 SvcList.exe 的命令行工具，它可以产生服务的格式化列表及其启动模式。在 Windows 命令行外壳（一种外壳，深深扎根于具有数十年历史的 MS-DOS 外壳）中，我可能会运行以下程序：
SvcList.exe | MyScript.vbs
此语句检索服务列表并将该列表输送到 VBScript÷ 文件。我必须编写 VBScript 文件来分析这个格式化列表，然后执行所有我想执行的操作——也许会输出任何启动模式为“禁用”的服务。这项任务可能比较耗时。最后，问题是该 SvcList.exe 有一个独特的输出，它不共享其他命令可以轻易用来分析利用其输出的通用格式。
然而对象可以提供这个通用格式，那就是 Windows PowerShell 管道与所有对象（而不仅是文本）一起工作的原因。当您运行 Get-WMIObject 之类的 cmdlet 时，用程序员术语来说，会产生对象组或对象集合。每个对象都包含允许您操作它的所有属性和方法。如果将对象输送到 Where-Object cmdlet，就可以筛选它们，从而只剩下我想要显示的对象。Where-Object 不需要分析任何文本，因为它没有检索任何文本，它在检索对象。例如：
Get-WMIObject Win32_Service | Where-Object {$_.StartMode -eq “Disabled” }
或者，如果您更喜欢通过别名提供的较短语法：
gwmi Win32_Service | where {$_.StartMode -eq “Disabled” }
有趣的是 Windows PowerShell 始终会将对象沿着管道传递。直到管道的末端才停止（当没有其他地方可以传递对象的时候），外壳会使用其内置格式规则生成对象的文本表示形式。例如，请看下面的情况：
Gwmi Win32_Service | where {$_.StartName –eq “LocalSystem” } | select Name,StartMode
这组三个 cmdlet 可以检索我本地计算机中的所有服务，筛选掉不使用 LocalSystem 帐号登录的所有服务，然后将其他服务传递给 Select-Object cmdlet，这样仅输出两个属性：Name 和 StartMode——它们是我之前要求要选择的两个属性。结果是一份以 LocalSystem（也许是出于安全审核目的）身份登录的服务的简单报告。
由于所有的 cmdlet 都共享一种通用数据格式——对象，所以它们可以与另一个不进行复杂字符串分析的 cmdlet 共享数据。同时由于 Windows PowerShell 本来就可以创建对象的文本表示形式，管道的末端就肯定是我，一个人，可以读取的文本输出。图 1 显示了产生的输出示例。
图 1 和对象一起传递的一系列输送的 cmdlet 所产生的文本输出
图 1 和对象一起传递的一系列输送的 cmdlet 所产生的文本输出

管道的亮点
在 Windows PowerShell 中输送的原因非常令人诧异，那就是 Windows PowerShell 中的每个项目都是对象，包括您可以使用的所有属性和方法。从技术角度上来说，甚至文本文件也是字符串对象的集合，文件中的每一行文本都可充当一种独立的独特字符串对象。例如，创建名为 C:\Computers.txt 的文本文件（使用“记事本”）。使用文本填充该文件，然后在 Windows PowerShell 中运行下列命令：
Get-Content C:\Computers.txt | Select-Object Length | Format-List
如果您不太喜欢要进行很多键入操作，也可以使用别名：
gc C:\Computers.txt | select Length | fl
该代码会提供一个列表，指定每个文本行的长度（以字符为单位）。Get-Content 会检索文件中的字符串对象，Select-Object 则会获取每个对象的 Length 属性，而 Format-List 则会为您创建好用的、可以读取的文本输出。虽然这可能不是一个可以使用的实用管理工具，但是它阐明，即使是与文本行一样简单的元素也是 Windows PowerShell 中的对象。
由于能够将对象从 cmdlet 输送到 cmdlet，或者从 cmdlet 输送到脚本，因此可以创建非常强大的“一行式命令”。它们是简单的 cmdlets 字符串，附加在一个较长的管道中，该管道进一步完善了对象集，可以提供您真正需要的一切。几乎不进行任何脚本编写或编程，Windows PowerShell cmdlet（在相应管道中排成一队）也可以实现显著的效果。

支持未来一代
未来的 Microsoft 服务器产品仍会建立在扩展了此功能的 Windows PowerShell 之上。例如，实施新的 Exchange Server 2007 机器时，您可以使用 Windows PowerShell 来检索所有的邮箱，筛选掉所有不在新邮件服务器所在办公室的邮箱，然后将这些邮箱移到新的服务器上——这一切操作都不需要编写脚本，只需单个文本行即可实现。Exchange Server 2007 团队已发布强大的一行式命令的冗长列表。它真正阐述了管道的功能及其能够完成的管理任务。
使用 Windows PowerShell 的技巧是要了解，虽然这个新工具建立在长期存在的原则和 UNIX 世界的原理之上，但它是适合 Windows 管理的唯一工具。不要让术语的通用性愚弄了您，让您误以为 Windows PowerShell 就是 Windows 的 UNIX 外壳翻版。Windows PowerShell 包含全新的概念，那就是利用 Windows 平台，将它与 Windows 执行任务的方式紧密结合起来。

Don Jones是一位 Windows PowerShell MVP 及 Windows PowerShell 101 (ScriptingTraining.com) 的作者。您可以通过 www.ScriptingAnswers.com 联系 Don。


 您好，脚本专家！: 脚本就像生活，给人的观感非常重要
您好，脚本专家！
脚本就像生活，给人的观感非常重要
Microsoft 脚本专家

几百年， 甚至几千年以来，哲学家和圣人们都一直在告诫我们，在判断人或事的时候，不要只看外表。（提醒您，我们不应该对别人妄下判断；毕竟，情人眼里出西施。）要知道俗话说得好：真正的美来自于内在，而不是外表，您的本质远比您的外貌重要。
对于这一点，脚本专家只能给出一个评价：那就是废话。
没错，就是废话。脚本专家首先承认在完美的世界中，外观并不重要。但是我们并不是生活在完美的世界中。如果我们是生活在完美的世界中，那么法式炸薯条和热巧克力酱圣代就可以构成两大主食了。无论您愿不愿意，外观真的很重要。这对于脚本和其他东西都是一样的道理。
脚本专家注意到很少有人会被在命令窗口中运行的 VBScript 脚本纯粹的美而感动得痛哭流涕。（也许脚本专家 Dean Tsaltas 算得上一位，但是他是我们所能想到的仅有一位。）
另一方面，在我们这个高科技世界里，脚本专家在编写在命令窗口中运行的脚本时已不受限制，这也是实情。幸亏有了 HTML 应用程序 (HTA)，脚本专家才能够访问 DHTML 的功能，从而可以为脚本创建 GUI。可以利用这些相同的 HTML 技巧来创建 Windows Vista™ 的小工具，正如我们知道的那样，这是一个有可能会彻底颠覆系统管理脚本编写的方法。不过猜猜看?一旦您开始讨论 GUI，所有关于美是肤浅的这种陈旧老观念立即就会被扫地出门。对于在图形环境中运行的脚本来说，外观和功能与性能同等重要。
这就是问题所在。毕竟，我们只是脚本专家；我们怎么知道如何创建图形用户界面呢？似乎我们不太走运，对吗？
也许是的。但也许又不是。我们不是刚刚才听到有人说过“多亏了脚本专家”这样的话吗？
没有，真的没有。我们刚刚没听到有人这么说吗？或许是他们在喃喃自语或有些问题......
好吧，这没关系。应该有人曾经这样说过的，因为有脚本专家在这里提供帮助（不管您是否需要我们的帮助）。
为了带您初步了解 GUI 的奇妙世界，让我们看一下简单的小 HTA 的开始部分。（如果您想了解有关创建 HTA 的详细信息，请参阅 HTA 开发人员中心。）
我们在图 1 看到的便是奇特的桌面信息系统的第一部分。正如您所看到的那样，我们首先是在 HTA 窗口的右上角放置一个漂亮的小图形。这个思路是想在 HTA 第一次加载时，它会检索登录用户的名称，然后在此图像的顶部显示用户名及计算机名称。稍后我们会将各种类型的其他非常酷的项目添加到 HTA，但是正如他们所说的，要事第一。
图 1 非常漂亮的 HTA 图形界面的初始
图 1 非常漂亮的 HTA 图形界面的初始
是的，我们确实不知道“他们”是谁。可能是其他哲学家中的某一位。可能是伏尔泰。因为这听起来像伏尔泰说的话。
当然，这是一个漂亮、简单的小应用程序，但是它的...美...也许还不能让脚本专家 Dean 感动得流泪。但是它称得上是一个很有用的演示工具，运用了适用于多种不同情况的基本概念。毕竟，很多这些夸张的 Windows Vista 小工具都是基于相同的原则运行的；它们只显示奇特的图形（即量表或刻度盘），然后在此图形的顶部写入一些文本。这使您看起来似乎拥有了一个非常酷的小量表，可以显示可用的磁盘空间，而实际上，您真正所拥有的是一个带有某个动态文本的通用图形结构。
嗯，坦白地说，这对我们没有什么意义。但是在我们深入研读这期专栏后，这些问题就会明朗化了。
关于我们能显示一个图形然后再于此图形的顶部写入文本的概念，还存在一个问题：就是它不起作用。可是，使用基本的 HTML 标记我们反而能获得一些类似图 2 中的效果。这可能并不是我们希望的情况。也许尼采说的“人类永远别指望能将文字放到图形的顶部，至少在 HTA 中就不行”是对的。
图 2 覆盖文本的首次尝试
图 2 覆盖文本的首次尝试
又或者也许是尼采错了：我们不是刚刚听到有人说——好吧，没关系？事实证明，我们不能使用传统的 HTML 做我们想做的事；它就是不起作用。当然，理论上我们可以将我们的图形创建成背景图形，然后使用表和不间断空格和各种其他小技巧来尝试让文本覆盖图片。之所以说“理论上”，我们有很好的理由，即除了最简单的情形之外，这个策略根本不起作用。
事实证明，还有一个更好的方法可以在 HTA 或 Windows Vista 小工具中创建奇特的布局：即级联样式表，说 CSS 可能更为人熟悉。
CSS 可用来定义文档的字体、边距和对齐方式、颜色和其他显示方面。（它特别适合网页。但是，由于 HTA 和小工具实质上就是网页，所以 CSS 同样适用于它们。)我们没法一一讨论所有您可以使用 CSS 进行的操作，因此如需详细信息，您可以非常方便地参阅 MSDN® 上详尽的 CSS 参考文档。一言以蔽之，现在我们可以使用 CSS 精密地控制 HTA 的布局，包括可以将一个项目（我们的文本）覆盖到另一个项目（我们的图形）上。
我们将阐述我们是如何处理所有情况的。但是在开始阐述之前，让我们先看一下图 3 中简单的 HTA 的代码。
Figure 3 最后，我们所获得的脚本...... (Close Figure 3)
<SCRIPT LANGUAGE=”VBScript”>

Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
 “<font style=’font-size:18pt;color:white’>” & _
 strUser & “<br>” & strComputer & “</font></p>”
End Sub

</SCRIPT>

<img src=“test2.jpg“ align=“right“>
<span id=UserData style=“position:absolute;left:770px;top:150px“></span>
正如您看到的那样，这个代码的内容并不多。我们有一个 Window_OnLoad 子例程，它可以（根据名称）在 HTA 每次启动或刷新时自动运行。我们将马上讨论这个子例程。此外，我们还有两个 HTML 元素：图形和范围。您肯定知道，我们会使用这些标记来插入图形，从而可以使用对齐属性来确保该图片显示在窗口的右边：
<img src=”test2.jpg” align=”right”>
它为我们提供了这个范围的 HTML 标记：
<span id=UserData style=”position:absolute;
left:770px;top:150px”></span>
好了，我们已在这里使用了范围标记。范围标记到底是什么呢？嗯，实际上，范围只是 HTA 的一个指定区域；它是 HTA 窗口的一个“已标记”部分，我们可以用编程方式进行标识（主要是因为我们已将 ID UserData 指定给范围）。一旦设置了范围，我们就可以编写为该范围指定文本或 HTML 代码的子例程。实际上，我们不但可以这样做，在我们的 HTA 中我们也已经这样做了。
但是，正如我们说过的，我们会在稍后加以讨论。在我们讨论之前，我们需要先看一下已添加到范围标记中的样式参数：
style=”position:absolute;left:770px;top:150px”
这个参数，如您所料，是将动态文本成功置于图形顶部的关键。实际上我们在这里指定了三个独立的样式属性。
Position 我们已告诉 HTA，我们希望范围的精确位置在什么地方。这从本质上意味着我们始终要范围处在相同的位置，即使这意味着（在本例中便是如此）该文本会被写入其他项目（例如图形）的顶部。
Left 它仅指定了范围相对于 HTA 窗口最左边的位置。本例中，我们想要范围在距左侧 770 像素 (770px) 的位置开始。
Top 这个设置和 Left 属性非常相似，只不过这次我们是指定范围相对于 HTA 窗口上边缘的位置。本例中，我们要在范围开始之前在距窗口顶部往下 150 像素 (150px) 的地方开始。
我们是如何知道要将我们的范围的左边设置成 770 像素，而将顶部设置成 150 像素的呢？好，实话告诉您，我们并不知道。相反，我们是靠猜的；我们将图形放在页面上，并为范围的 Left 和 Top 属性指定值。然后我们打开 HTA，查看效果。正如您所料，我们可能偏了一点点，因此我们调整这些值，再刷新 HTA，然后再查看效果。我们这样做了几次，就像 Goldilocks，直到我们认为效果刚好为止。
注意：您可能知道 Goldilocks 和三只小熊、它们的床和椅子、不是太烫就是太凉的麦片粥等等。但是我们并不确定是否可以将 Goldilocks 看作是一位伟大的哲学家。但是您可能会说，看看她如何闯入别人家里，喝别人的麦片粥，坐别人的椅子，睡别人的床而没发生任何问题，显然在她身上体现了独特的哲学见解。
不管怎样，图 4 显示了我们的 HTA 现在的外观。当然，它不可能是一件艺术作品，但是我们倒是想看看毕加索会如何以编程方式打印图形顶部的信息。
图 4 看看样式的强大功能
图 4 看看样式的强大功能
说到这儿，我们是如何以编程方式打印图形顶部的信息的呢？嗯，我们有好消息告诉您：终于到了要讨论 Window_OnLoad 子例程的时候了，如图 5 中所示。
Figure 5 Window_OnLoad 子例程 (Close Figure 5)
Sub Window_OnLoad
 Set objNetwork = CreateObject(“Wscript.Network”)

 strUser = objNetwork.UserDomain & “\” & objNetwork.UserName
 strComputer= objNetwork.ComputerName

 UserData.InnerHTML = “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>” & _
  strUser & “<br>” & strComputer & “</font></p>”
End Sub
您知道，当我们可以更仔细地查看这个子例程时，我们发现实际上没有什么可讨论的，不是吗？正如您所看到的那样，我们首先是创建 Wscript.Network 对象的示例。然后我们使用这些代码行来检索用户名和域以及计算机名称：
strUser = objNetwork.UserDomain & “\” & _
  objNetwork.UserName
strComputer= objNetwork.ComputerName
当然，那正好是我们想要写入 HTA 窗口的信息。我们需要做的就是将 strUser 和 strComputer 变量与小 HTML 标记结合起来，然后将产生的字符串分配给范围的 InnerHTML 属性：
UserData.InnerHTML = _
  “<p align = ‘center’> “ & _
  “<font style=’font-size:18pt;color:white’>”_
  & strUser & “<br>” & strComputer & _
  “</font></p>”
是的，我们知道那是一个看起来有点复杂的代码。但是它真得不是那么难弄。它只是看起来复杂而已，因为我们是将好几个项目结合到一个字符串中。我们以段落开始标记为开端，这个标记指定我们想使段落中的文字居中。
“<p align = ‘center’> “
接下来是字体开始标记，它指定我们应使用 18 号白色文本：
“<font style=’font-size:18pt;color:white’>”
strUser 是存放我们用户名的变量，格式为 Domain\UserName。“<br>”是插入一个换行符。我们插入它，以使用户名出现在一行中，而计算机名称出现在第二行中。strComputer 是存放计算机名称的变量。最后，我们添加字体结束标记和段落结束标记：
“</font></p>”
当您分别观察各个部分的时候，可以发现这个代码远没您想像得那么复杂。
顺便说一下，您可以放置差不多所有您想放入的 HTML 元素。例如，假设您想要一个按钮位于图形下面的居中位置。要达到这个效果，只要将它添加到您的 HTA 代码中：
<input type=”button” value=”Test Button” style=”position:absolute;left:820px;top:300px”>
结果产生的 HTA 如图 6 所示。
图 6 如此可爱的按钮
图 6 如此可爱的按钮
此外，您必须摆弄这个按钮，使其置于正好的位置，但是这个过程不能太长。实际上，如果您愿意做一道数学题，您可能可以提前确定正确的位置。您需要知道的就是每个对象的宽度和高度（有些您可以通过使用样式参数来指定）和 HTA 窗口的宽度和高度。在默认情况下，至少在脚本专家的测试计算机中，HTA 的宽度大约为 1020 像素宽，高度大约为 685 像素（当然，效果可能会有所不同）。如果没有别的问题，您可以开始从这些数字入手，然后调整它们直到符合您的要求为止。
很显然，这是一个全面但过于简单的 CSS 简介，但是它为您提供了美化脚本的入门知识。哲学家可能会鄙视这些尝试，并会告诉您脚本真正的美来自于内在，而非外观。但是让我们换个角度思考。谁是史上最伟大的哲学家呢？没错：是柏拉图、苏格拉底、亚里斯多德，等等。明确这一点后，我想提一个问题：您见过这些哲学家的照片吗？这些说美不重要的人都没有留下一张自己的照片，您不觉得很有意思吗？不觉得奇怪吗？好些问题值得我们思索。

Microsoft 脚本专家为 Microsoft 工作，也就是受雇于 Microsoft。在玩、教或看棒球（以及各种其他活动）的闲暇之余，他们还负责维护 TechNet 脚本中心。您可以光顾他们的网站 www.scriptingguys.com，看看他们都在干些什么。


 Exchange Queue &amp; A: 边缘和集线器传输角色、虚拟机及其他
Exchange Queue & A
边缘和集线器传输角色、虚拟机及其他
KC Lemson and Nino Bilic

在 2007 年 5 月份的 Exchange Queue & A 中，我们探讨了有关在网络共享中存储 .pst 文件的问题。Windows Server 性能团队最近开通了一个博客并全方位讨论了有关这一主题的
极度深入的技术细节。因此，我们希望将这个链接介绍给您。现在，我们来看看这些问题。

问：如果我想部署 Microsoft Exchange Server 2007，那么是否必须部署边缘服务器？

答：不需要为部署 Exchange Server 2007 而部署边缘服务器。您可以在一台承担各种核心服务器角色任务（如邮箱、客户端访问和集线器传输）的机器上为您的域接受 Internet 电子邮件并运行反垃圾邮件和防病毒程序。

问：边缘传输服务器角色与集线器传输服务器角色之间存在哪些差异？如果不部署边缘服务器会漏掉什么？

答：集线器角色的主要目的是在组织内路由邮件，并对这些邮件应用业务策略。使用集线器角色，传输规则将基于 Active Directory® 对象——用户、通讯组列表等。集线器角色还允许您在邮件或发送给用户组的日志消息中添加免责声明，因为您或许会希望基于 Active Directory 成员关系来建立这些规则。例如，您可以为发送给 DLOfUsersOnLitigationHold 的所有邮件建立日志，或者为由 DLOfMembersOfLegalTeam 发送的出站邮件添加免责声明。虽然在集线器服务器上运行反垃圾邮件代理是可能的，但默认情况下并未启用它们，因此您需要通过运行 install-antispamagents 脚本（位于服务器上的 \scripts 目录中）来手动安装它们。
边缘服务器角色的主要用途是传输组织的进入或发出邮件，并对这些邮件执行邮件清洁（反垃圾邮件、防病毒、内容或附件过滤等）。当您安装边缘服务器时，已经默认启用了反垃圾邮件功能。边缘服务器角色的一个独特的功能就是不要求它加入到 Windows® 域中，即它可以在不属于某个 Windows 域的独立 Windows Server® 安装中运行，但您仍可以将边缘服务器作为企业林结构中 Exchange 2007 组织的一部分进行管理。
这在外围网络中尤为有利，其中您可以将该服务器放在一个工作组中，或者外围网络中的机器可以有一个单独且明确的林。按这种情况部署的边缘服务器可以方便地为企业网络和 Internet 之间的邮件执行所有邮件清洁和传送操作，同时仍可以按照与其余 Exchange 2007 系统管理相一致的方式对这些边缘服务器进行管理。
在边缘服务器上，传输规则是基于 SMTP 地址，而不是 Active Directory 对象——不过当然，您可以使用 DL 的 SMTP 地址或 Active Directory 中的用户。边缘传输规则的大部分都是中心传输规则的一个子集，但隔离操作是个例外，它只存在于边缘服务器上。
边缘服务器还具有某些由中心传输服务器所没有的代理提供的功能：附件剥离和地址重写。附件剥离是指有选择地删除具有潜在危险的附件（带有 .exe 和 .com 等扩展名）的功能。地址重写代理允许您重写电子邮件的标头，这样，（比方说）虽然您的用户帐户的域和默认 SMTP 代理地址是 @contoso.com，但发送到 Internet 的出站邮件可显示为来自 @northwindtraders.com。此外，边缘服务器仅基于域或地址空间执行路由，因此，如果您在 Exchange 和另一个电子邮件系统之间共享相同的 SMTP 地址空间，则需要在集线器服务器上执行该路由，或者在边缘服务器上配合使用地址重写代理来执行路由。
另一个关注要点是 Exchange 2007 服务器是否直接面对 Internet（无论是集线器服务器角色还是边缘服务器角色）。换言之，对域 MX 记录的端口 25 的连接是否以某种方式连接到了 Exchange 2007？您可能已经在为您的域接受邮件并将其传递给企业网络内部的 Exchange 的 Internet 上，设置了 SMTP 网关、病毒防火墙或其他解决方案。如果您将边缘服务器或集线器服务器部署为面向 Internet，则可以利用 Exchange 2007 中最卓越的功能之一：安全列表聚合通过安全列表聚合，用户可以将发件人添加到其 Microsoft Outlook® 中的安全列表中（通常他们会为来自经销商的 Internet 新闻稿或电子邮件进行这样的处理），从而将这些列表安全传播给边缘服务器角色或集线器服务器角色，以使来自这些发件人的邮件能够绕过内容过滤。当然，对一个用户来说是垃圾邮件的信件，对另一个用户来说可能是有价值的新闻稿，因此安全列表聚合是因人而异的。您可以在 Exchange 2007 文档中找到有关其工作方式的更多信息。
如果您的最终部署是由一台承担集线器服务器角色的服务器为您的域接受 Internet 电子邮件，则需要注意一些事项。当然，首先要确保设置了强大的防火墙或端口过滤解决方案，以使您的服务器只接收必要端口（如端口 25）上的连接。此外还要注意，您需要安装反垃圾邮件代理，因为默认情况下并未安装或启用这些代理。由于集线器服务器的最常见部署方案是放在企业网络内，因此默认情况下并不允许匿名连接——您需要在端口 25 接收连接器上选中 AnonymousUsers 权限组。您还需要确保启用安全列表聚合并将其设置为定期运行，这样当用户更新其邮箱的安全列表后，从这些用户的安全发件人列表发送给他们的邮件才能绕过内容过滤。我们的博客提供了更多详细信息。
以下代码显示了一条 AT 命令，它使用一个名为 SafeList.bat 的批处理文件在每天晚上 11:00 点更新所有服务器上的所有邮箱：
at 23:00 /every:M,T,W,Th,F,S,Su cmd /c
“D:\SafeList.bat”
以下代码显示了 SafeList.bat 文件的内容：
“d:\Program Files\Microsoft Command Shell\v1.0\Powershell.exe”
-psconsolefile “d:\Program Files\Microsoft\Exchange Server\bin\exshell.psc1” -command
“get-mailbox | where {$_.RecipientType
-eq [Microsoft.Exchange.Data.Directory.Recipient.RecipientType]::UserMailbox } | update-safelist”
如果您需要验证自己的设置能够正确运行，请在 Exchange 2007 文档中查阅更多相关信息。

问：当我启动其中包含 Exchange 的 Virtual PC 镜像后，在与目录或 LDAP 服务器建立联系时总是会遇到问题。远程登录到 389 没有问题，并且所有服务也都在运行。这是为什么？

答：去年我在 Tech•Ed（微软技术大会）上也遇到过这种问题。我的便携式计算机中有一个 Virtual PC 副本，这是我从一台工作机器上复制的，本打算用它来为大会的成员做些演示，这些人为在随后一个月发布的 Exchange 2007 Beta 2 发表了许多专题文章。
我已经做过了上百万次产品演示，知道该产品是很可靠的，因此并未精心准备。但当我在星期一早晨启动我的 Virtual PC 时，就在首次会议前的一小时，发现它的每个部分都无法与域控制器建立联系，您可以想像得出我额头上的冷汗。幸亏有会务组的那些超级聪明的家伙，我们得以很快解决了问题。
我在 Tech•Ed 上遇到的这个问题是由于我在自己的超级缓慢的便携式计算机上运行 Virtual PC 造成的。问题的根源是 DNS 与 Active Directory 的争用问题。镜像中的 DNS 服务器被配置为与 Active Directory 相集成，但是由于镜像中加载的服务的序列（以及，或许我们应当说，由于我的便携式计算机的迟钝），当 DNS 服务器尝试与 Active Directory 联系时，尚未启动必要的目录服务。
在相同的机器（它并非一定是个虚拟的镜像）上安装了 DC 和 Exchange 的任何服务器都可能发生这种情况，但在速度奇慢的虚拟环境中发生这种情况的可能性非常大，尤其是使用一台像我这样的不够强劲的便携式计算机。
我还见过一个类似的问题，事关在两台机器之间复制的 Virtual PC 镜像，尤其是当其中一台机器位于不同的网络上时。如果您遇到这种问题，请检查镜像中的 OS 的 IP 地址，它可能使用了一个来自旧网络的过时的 IP 地址。将其刷新以获得来自新网络的 IP 地址，然后看看是否可以解决问题。
为避免将来出现这类问题，另一种方法是使来宾机器上的 DNS 服务器不与 Active Directory 相集成，并在主机和来宾机器上都安装 DNS。让来宾机器将未知记录转发给主机，同时让主机将未知记录转发给适当的 DNS 服务器。这样，当您的镜像启动并尝试更新 DNS 记录时，就不太可能失败了。

问：Exchange 2007 的安装过程似乎与早期版本的 Exchange 有很大差异。具体过程是怎样的呢？

答：的确如此。实际上，Exchange 2007 的安装过程分几个阶段。下面是整个过程的概要说明。

当您首次运行 setup.exe 时，将启动一个进程，其中提供了在开始实际安装服务器角色之前需要安装的多数前提项目的链接。安装了所有这些前提项目后，即可单击随之出现的“安装 Microsoft Exchange”链接（请参见图 1）。
图 1 满足一般前提条件后出现的安装链接
图 1 满足一般前提条件后出现的安装链接
如果您通过网络运行 setup.exe 并单击该安装链接，则核心安装文件将复制到本地机器上的 %TEMP%\ExchangeServerSetup\ 文件夹中。随后会启动安装向导。
安装向导将引导您完成各种选择，如许可协议、错误报告和安装类型（从中选择要安装的服务器角色）。根据当前存在的 Exchange 组织（如果有）及其状态，向导页会有所不同。
完成此步骤后，安装程序将执行就绪情况检查——它是一个非常好的 Microsoft Exchange Server 最佳实践分析工具 (BPA) 版本；默认情况下，它会连接到 Internet 以下载最新的必备 XML 文件。它提供了一个定期更新先决条件的机会，并可借此解决 Exchange 团队在产品发布后发现的任何问题。完成先决条件检查后，您有机会对结果进行检查并继续；否则，程序会显示任何相关问题，您必须解决后才能继续安装。如果您的服务器未能通过先决条件检查，多数情况下向导会让您再次尝试检查。
通过先决条件检查后，会显示“安装”按钮，这时便可以安装之前选定的任何角色。只有您选定的角色的文件才会得到复制和安装。
在安装过程的最后，您将有机会启动 Exchange 管理控制台并应用任何可能存在的 Exchange 2007 更新。

KC Lemson是 Exchange Server 的用户体验经理。她的网上银行帐户被暂时挂起了。
Nino Bilic是 Exchange Server 的可支持性项目经理。最近他为自己的信用卡增加了一个备用电子邮件地址。


 安全观察: 管理 ACL 的工具
安全观察
管理 ACL 的工具
Jesper M. Johansson

在 Windows 中，访问控制列表 (ACL) 能让您很好地控制用户的能力和使用类似文件和文件夹等资源的过程。管理 ACL 可能是更复杂的任务之一，它与保护您用户系统的安全性相关。幸运的是，有很多有用的实用工具
可以帮助自动化和简化关于权限和 ACL 的任务。
大多数读者都熟悉历史悠久的 cacls.exe 工具，它自面市以来就安装在每个版本的 Windows NT® 中。如果在 Windows Vista™ 中运行 cacls.exe，会看到下列消息：
Microsoft Windows [Version 6.0.5744]
Copyright (c) 2006 Microsoft Corporation. All rights reserved.

C:\Windows\system32>cacls

 NOTE: Cacls is now deprecated, please use Icacls.
除了对 Windows Vista 中 ACL 的更新之外（我已在《TechNet 杂志》2007 年六月期中进行了说明；请参阅 technetmagazine.com/issues/ 2007/06），Microsoft 还更新了一些可用来管理 ACL 的工具。有趣的是，在这些更新中最重要的是命令行工具。
Icacls.exe 是 Windows Vista 中新出现的（在 Windows Server® 2003 Service Pack 2 中的下层也是新出现的）。它将逐渐替代 cacls.exe，正如您可能知道的一样，它从未被完全更新过，无法支持更多由 Windows® 2000 引入的详细权限，从而使这个更新晚了大约七年之久。
令人惊讶的是，不管 cacls.exe 是否被弃用，它实际上还是包含了部分新功能。首先，它能识别交接点和符号链接，并且知道如何遍历它们。其次，它可以打印和设置 ACL，从而可以使用安全性描述定义语言 (SDDL) 字符串。
然而，尽管 cacls.exe 有更新，您都会真的需要 icacls.exe 中提供的功能。

保存和恢复 ACL
过去 10 年来一直有一个愿望（至少是我的愿望），就是希望能够保存 ACL，以便可以在后来恢复它。事实证明，它是您可以对 ACL 执行的最复杂的操作之一。除了在某些特殊情况下以外，ACL 一般不可能回到一开始未遭破坏的原始状态。不过，该功能可能非常有用。
在介绍如何保存或恢复 ACL 之前，让我们先探讨一下它为什么这么难。假设您有一个包含本地大学学生用户数据的层次结构。您在 2 月 1 日保存了 ACL。4 月 17 日，您发现 ACL 遭到了破坏，然后去从保存的副本进行恢复。这个操作有哪些复杂的地方？
首先，新季度是从 4 月 2 日开始。您的学生大约有 15％ 已毕业；因此，他们的目录不再保留。这样，您在无效的备份文件中会有 ACL。您还有一批新学生，也占 15％，在这个新季度入学。他们现在有主目录，但是在备份文件中没有 ACL。他们的 ACL 应该是什么？当然您有 70％ 的学生仍在那里，但是他们已创建了新文件和文件夹，并删除了其他文件和文件夹。您可以忽略删除的文件和文件夹，但是您如何配置他们创建的新文件夹呢？如果学生决定在 3 月 4 日将文件夹与他的朋友分享，那该怎么办呢？您会在恢复 ACL 时中断他们的共享吗?
保存和恢复 ACL 并不是许多人希望您相信的那么简单的一个操作。您在执行此操作时需要小心行事。很可能，甚至极有可能您会将一些未定义的行为作为结果。恢复 ACL 确实是最后一个手段；备份它的时间越长，恢复它时发生中断的可能性就越大。
不过如果您愿意尝试这个功能，可使用 /save 开关运行 icacls.exe：
icacls <target> /save acls.bin /t
这会将 ACL 保存到名为 acls.bin 的文件。在该文件中，具有 ACL 的每个对象会各占一行，后面接着的一行指定 SDDL 中的 ACL。通过使用 /t 开关，命令会对您指定对象及其下面的所有对象和容器执行操作。
保存功能是工具包中很受欢迎的一个新增功能，但是它仍有一些瑕疵。例如，它仅保存自由访问控制列表 (DACL)，而不是系统访问控制列表 (SACL)。实际上，如果有 SACL，它会保存代表这个 SACL 的虚拟值，但是不会实际保存 SACL 的任何部分。
此外，保存 ACL 的方法会引发一个有意思的问题。当您在最喜欢的文本编辑器中打开保存的 ACL 之前，请记住：
不要编辑您已保存的 ACL！
如果您在文本编辑器中打开了包含您保存的 ACL 的文件，您会发现它看起来像是 Unicode (UTF-16) 格式的文本文件。实际上，这就是它的具体格式。这也许会导致您考虑编辑它，并将其从本文编辑器中保存。千万别那么做！
如果您在文本编辑器中打开包含保存的 ACL 的文件，并进行了保存，您将无法从该文件恢复 ACL。事实证明，它实际上并不是 Unicode 文本文件。这种文件必须以 2 位字节的 0xfffe 开头。如果您使用文本编辑器（如记事本）保存文件，事实上它会将标记放入文件的第一个 2 字节中。但是此 icacls.exe 工具期望 ACL 数据会在文件中字节为 0 的地方开始。结果，工具将无法分析文件中的 ACL，因为它期望开始两个字节是指定操作对象的字符串的一部分。您的备份文件将不可用。
Microsoft 意识到了这个问题，但由于是在 Windows Vista 测试周期较晚的时候才报告，因此这个瑕疵在发布之前未被修复。目前，我们不知道它什么时候，甚至是否会被修复。因此现在最好的建议是不编辑已保存的 ACL。如果您需要这样做，请将文件保存为 .bin 文件，并使用十六进制编辑器，如您最喜欢的开发环境。
使用 /save 开关保存 ACL 后，就可以使用带 /restore 开关的 icacls.exe 来恢复它。形式最简单的恢复命令使用下面的语法：
icacls <directory> /restore acls.bin
恢复过程不会对文件进行任何操作。如需了解这一点，请看一下图 1 中显示的命令顺序。这里我通过指出文件中的 icacls.exe 创建了一个保存文件。然后我通过简单地用 /restore 替代 /save 来尝试恢复它。由于恢复命令仅对目录进行操作，所以无法进行上述操作。支持修改的文件已在 acls.bin 文件中指定。为了恢复 ACL，我会在目录中而不是在文件中指出它。这就是我在最后一个命令执行的操作，在这里我将“.”指定为需要操作的对象。
Figure 1 保存和恢复 ACL (Close Figure 1)
C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /restore acls.bin
test.txt\test.txt: The system cannot find the path specified
Successfully processed 0 files; Failed processing 1 files

C:\Users\Jesper>icacls . /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files
另请注意，恢复命令必须以提升的权限运行！只有当您有权读取 ACL 时，才能以低级别管理员甚至标准用户的身份运行命令提示符中的保存命令。然而要恢复 ACL，您需要有一个完整又纯粹的管理令牌。

替代 SID
icacls.exe 中另一个很有用的功能是可以用一个用户的权限替换另一个用户的权限。这通过使用 /substitute 开关在恢复期间完成。替代开关的文档中声称需要一个 SID，但是后来有说明实际上也可以是一个常规用户名。这样，图 2 中显示的顺序就能够工作了。
Figure 2 恢复期间替代 SID (Close Figure 2)
C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\foo:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt /save acls.bin
processed file: test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls. /substitute foo bar /restore acls.bin
processed file: .\test.txt
Successfully processed 1 files; Failed processing 0 files

C:\Users\Jesper>icacls test.txt
test.txt VistaRC2-Test\bar:(R,W)
    VistaRC2-Test\Jesper:(I)(F)
    NT AUTHORITY\SYSTEM:(I)(F)
    BUILTIN\Administrators:(I)(F)

Successfully processed 1 files; Failed processing 0 files
正如您看到的那样，我以之前就有的同一个 ACL 结束，但是用来指定 foo 权限的 ACE 现在用来指定 bar 的权限。

更改所有者
多年以来，这个 chown 工具已成为 UNIX 系统上的装订器。Windows 最初没有更改对象所有者的内置方法。后来在资源工具包中出现了 SetOwner 工具。再后来，Windows NT 4.0 中出现了 takeown.exe 工具，但是这个实用工具仅允许您获取所有权，不允许将它授予其他用户，除非您有他们的密码。现在 icacls.exe 提供一种内置功能，让您可以为您有权设置其所有者的对象设置所有者：
C:\>icacls c:\test /setowner foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files
遗憾的是，icacls.exe 不能为您显示对象的所有者。实际上没有办法从命令行看出对象的所有者是谁。而且，如果您保存对象的 ACL，就不会保存对象的所有者。
icacls.exe 还有一个 bug，即不能调用 SeTakeOwnershipPrivilege 来更改所有者。如果您有权根据 ACL 更改对象的所有者，那 icacls.exe 就会按照指定方式运行。然而，如果您是管理员，但无权根据对象的 ACL 更改该所有者，那么就会因为那个 bug 而无法使用 icacls.exe 执行此操作。在这种情况下，您需要使用 takeown.exe 工具，它可以调用 SeTakeOwnershipPrivilege，但是仅可以更改您帐户或管理员群组的所有者，而不是任意帐户的所有者：
C:\>takeown /f c:\test

SUCCESS: The file (or folder): “c:\test” now owned by user “JJ-VistaRTMTst\Jesper”.
当然，还应该注意 subinacl 工具，它可以从 Microsoft 下载中心下载，还有 setowner 开关。在很多情况下，Subinacl 的工作方式实际上比 icacls 更直观，但使用起来却也复杂得多。

查找特定用户的文件
Icacls 还有另一个有用的功能：可以找到有特定用户权限的文件。例如：
C:\windows\system32>icacls “c:\program files” /findsid jesper /t

SID Found: c:\program files\Passgen\
passgen.exe.
Successfully processed 1808 files; Failed processing 0 files
如果您想尝试找出特定用户可能有权执行的操作，这个功能将非常有用。

重置和更改 ACL
如果 ACL 已遭破坏或损坏，icacls.exe 有办法将其重置为从父项继承。这在 2006 年秋季爆发的零天安全性问题期间非常有用。用来缓解 Windows 组件中的这个问题的一种方法就是拒绝“每个人”访问对象的权限。这部分非常简单，但是使用 Windows XP 和 Windows Server 2003 中的内置工具来删除访问控制项 (ACE) 几乎是不可能的。不过在 Windows Vista 中，您只需要运行下面的命令：
C:\windows\system32>icacls “c:\program files\passgen\passgen.exe” /reset

processed file: c:\program files\passgen\passgen.exe
Successfully processed 1 files; Failed processing 0 files
当然，Icacls.exe 可以执行所有的标准授权/拒绝/删除操作。列表中真正新增的唯一项目是删除。使用这个开关，您可以删除所有允许 ACE 和所有拒绝 ACE，或者来自特定对象或层次结构的指定用户的允许 ACE 和拒绝 ACE。图 3 显示了一些不同的授权、删除和拒绝操作的示例。
Figure 3 授权、拒绝和删除操作 (Close Figure 3)
C:\>icacls c:\test /grant foo:(F)
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(F)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:g foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /deny foo:(F)
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test JJ-VistaRTMTst\foo:(N)
    BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test /remove:d foo
processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)

Successfully processed 1 files; Failed processing 0 files
如果您想将某一对象的访问权开放给特定组或用户，仅删除拒绝 ACE 的功能可能很有用。

设置完整性级别
Icacls.exe 还有显示和设置完整性级别的功能。Windows Vista 支持在对象上放置完整性标签。Icacls.exe 是可以用来执行该操作的命令行工具：
C:\>icacls c:\test /setintegritylevel high

processed file: c:\test
Successfully processed 1 files; Failed processing 0 files

C:\>icacls c:\test
c:\test BUILTIN\Administrators:(I)(F)
    BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
    Mandatory Label\High Mandatory Level:(NW)

Successfully processed 1 files; Failed processing 0 files
注意如果对象有一个显示设置，icacls.exe 仅显示完整性标签。大多数的文件都不会这样，因此您也很难看到这样的情况。
最后，icacls.exe 可以验证对象是否具有规范 ACL。如前面所述，大家都知道第三方工具会在 ACL 中以错误的顺序放置 ACE。Icacls.exe 可以验证和修复那些类型的问题，如下所示：
C:\>icacls c:\test /verify
processed file: c:\test

Successfully processed 1 files; Failed processing 0 files

ACL UI
ACL UI 或 ACL 用户界面已从 Windows XP 中的 ACL UI 进行了细微的修改。图 4 和图 5 分别显示了 Windows XP 和 Windows Vista 的 ACL UI 对话框。
图 4 Windows XP 中的 ACL UI 对话框
图 4 Windows XP 中的 ACL UI 对话框
图 5 Windows Vista 中的 ACL UI 对话框
图 5 Windows Vista 中的 ACL UI 对话框
正如您看到的那样，它们有一些不同。首先，对话框最终会清楚地显示您操作的对象，如果您同时对好几个对象进行操作，此对话框将非常有用。其次，底部还有一些帮助的超链接。但是，最值得注意的变化是删除了“添加”和“删除”按钮，替代它们的是大力支持 Windows Vista 中用户访问控制 (UAC) 的“编辑”按钮。正如您在该按钮上的盾牌旁边看到的那样，启动该对话框的用户无权编辑 ACL，因此在她可以编辑权限之前需要提升。注意，如果您在 C: 驱动器的根目录创建了文件夹并立即检查它的属性，它就可能不是默认值。作为文件夹的所有者，您将有编辑 ACL 的隐式权限，盾牌会消失。表示 COM Moniker 的盾牌是用来为一部分运行的进程启动提升提示的机制。如果单击“编辑”按钮，会看到一个熟悉的提升对话框，如果单击提升对话框中的“继续”，就会看到一个和您在 Windows XP 单击“添加”按钮后所看到的一样的对话框。ACL UI 在很多地方都遵循这个双对话框概念；您在提升之前都会看到对话框，提升后，就会看到 Windows 的先前版本中熟悉的老对话框。
如果先单击“高级”按钮，然后是“审核”选项卡，始终会有一个提升按钮，如图 6 所示。不可以在没有提升的情况下修改审核，即使您拥有对象的完全控制权限，或者您是所有者。那是因为，修改对象 SACL 的能力由 SE_SECURITY_NAME 特权掌握，在 GUI 工具中称为“管理审核和安全日志”。默认情况下，仅管理员具有该权限。但是，在管理员审批模式下（启用 UAC 时），会删除管理员的特权，即使您是管理员也需要提升。
图 6 修改 Windows Vista 中的审核设置始终需要提升
图 6 修改 Windows Vista 中的审核设置始终需要提升
最后要注意的是当您修改 ACL 时的提升要求：所有这些语句对于未禁用的 UAC 都是临时的。如果您禁用 UAC，所有的行为会转换为您在 Windows XP 进行的行为，除了对话框看起来不一样以外。但是，如果自从您的令牌具有 Administrators SID 以来您一直都是以管理员的身份登录，就不会要求提升。

其他工具
Icacls.exe 是一项很有用的工具，它在 cacls.exe 基础上进行了很多改进，但仍存在一些缺点。也许最值得注意的是它不能管理对象的访问权，而不是文件和目录的访问权。Windows Vista 相对于 Windows XP 而言，只对其他对象的 ACL 进行了细微的更改，但是需要管理服务、注册表项或 Active Directory® 对象的 ACL 的情况仍有发生。
如果您是命令行发烧友，就需要 subinacl.exe 来执行此操作。Subinacl.exe 是一种支持工具，也可在下载中下载。
尽管 subinacl.exe 比较容易使用，我还是必须给您一些警告。实际上，它有时候非常迟钝。但是，subinad.exe 是管理访问控制的强大工具。每个超级管理员都需要这个工具。

注册表 ACL
注册表 ACL 与文件系统 ACL 一样，曾发生过变化。尽管它变化的范围对比文件系统的变化要小得多。与以前版本的 Windows 最明显的不同在于，由于 Power Users 的排斥，几乎所有的 Power User ACE 都消失了。Power Users 并不比其他用户强大。尽管我们知道 ACL 真的是有些复杂，但是实际上不是所有的 Power Users 的 ACE 都消失了。只是不幸的是有一些丢失了。
当您查看注册表中的 ACL 时，在很多地方都会看到名为 RESTRICTED 的 SID 的 ACE。这对于 Windows Vista 并不新鲜，但它是一个很有趣又很难理解的 SID。RESTRICTED SID 表示提供受限令牌的任何进程。受限令牌可通过使用 CreateRestrictedToken API 的特殊功能来创建。这类令牌有一个或多个限制 SID——用于单独访问检查的 SID。假如我们有一个使用受限令牌运行的进程。如果该进程试图使用 RESTRICTED SID 的 ACE 访问对象，Windows 就会真正执行两项访问检查。第一项是普通访问检查。第二项的工作方式几乎与第一项一样，但是仅针对令牌中的限制 SID。两项访问检查都必须通过。
目前有好几个使用 RESTRICTED SID 的 ACL，特别是在注册表中。这个 ACL 的屏幕截图如图 7 所示。
图 7 几个地方的注册表 ACL 都包含 RESTRICTED 的 ACE
图 7 几个地方的注册表 ACL 都包含 RESTRICTED 的 ACE
此时，很少会有进程使用受限令牌功能，特别是涉及限制 SID 时。使用受限令牌功能的进程的示例是安装了 Windows 防火墙、基本筛选引擎和诊断策略服务的服务进程。它还使用限制写入的令牌。根据我的发现，Windows Vista 目前仅有九个服务使用 RESTRICTED 和限制写入的令牌。
正如最新先前版本的 Windows 一样，关于注册表权限的最佳实践是小心行事。除了在特殊和目的性较强的情况下之外，请不要修改注册表中的权限。考虑到复杂的继承模式以及对注册表执行的敏感操作，如果您不小心修改了注册表中的 ACL，就很可能会遇到无法接受的致命故障。

总结
和大多数的 Windows 版本一样，Windows Vista 中的访问控制做了一些细微的更改。但是，不像某些其他最新的版本，实际上还是有一些较小的更改，它们会添加到相当重要的行为更改中。特别是 UAC 要求的几个更改，例如完整性标签和对 ACL UI 的修改。此外，我们还对已记录的历史记录中的 ACL 进行了首次大清理。
在很多方法中，Windows 上的默认 ACL 实际上比 Windows Vista 中的要简单，因为之前有很多功能都没有。但是和先前的版本一样，您真的应该仔细研究访问控制，直到彻底了解它。特别是对于新版本的操作系统。希望通过使用本文介绍的工具，您可以轻松地了解 ACL。

Jesper M. Johansson 是解决软件安全问题的首席安全工程师，以及《TechNet 杂志》的特约编辑。他拥有 MIS 博士学历，具有 20 多年的计算机安全方面的经验。本专栏改编自 Roger Grimes 和 Jesper Johansson 的新书“Windows Vista Security: Securing Vista Against Malicious Attacks”（Windows Vista 安全性：保护 Vista 免遭恶意攻击）(Wiley, 2007)。


 桌面文件: Microsoft 桌面优化包
桌面文件
Microsoft 桌面优化包
Wes Miller
此专栏基于 Microsoft 桌面优化包的预发布内容。文中的所有信息均可能发生变更。

自从几年前开始实施软件保证 (SA) 许可计划以来，Microsoft 一直在寻求向 SA 中添加功能，以便随着时间的推移客户能够发现更多价值。除了提供包含在许可证中的 Microsoft 产品升级外，Microsoft 公司还致力于提供
可帮助组织改进其在 Windows、Office 和其他 Microsoft 软件等方面的体验的产品和技术（例如，Windows® PE 就是最先推出的这类产品之一）。
许多这类工具和程序都致力于使 Microsoft 提供更多附加功能，以降低包含在组织的 SA 范围内的 Windows、Office 和其他 Microsoft 应用程序的总体拥有成本。
Microsoft 在 2006 年收购了几家公司，它们都具有类似的计划：降低拥有成本，减少与管理和修复 Windows 以及基于 Windows 的应用程序相关联的复杂性。Microsoft 将许多这些新得到的技术组合到一个新的产品中，作为提供给具有 SA 的客户的增值服务。来自 Softricity、DesktopStandard、AssetMetrix 和 Winternals Software 的技术在未来的一年内将作为 Microsoft® 桌面优化包 (MDOP) 的组件提供给用户。此外，MDOP 还将包含一个 Microsoft 内部构建的组件，称为 Microsoft 系统中心桌面错误监控。
在节约成本方面，Microsoft 估计 MDOP 可帮助您的组织每年每个桌面节省 100 到 500 美元，具体取决于您在使用 MDOP 时所实施的最佳实践。有关 MDOP 的详细信息，可通过 windowsvista.com/optimizeddesktop 在线访问。

Microsoft 桌面优化包的目标
简而言之，MDOP 的主要目标是使 Microsoft 能够依据一个更加灵活的计划提供各种新管理技术，而不是将它们与新的操作系统版本绑在一起。显然，Microsoft 希望确保 Windows XP 与 Windows Vista™ 之间所存在的那种时间断层不会再次出现。通过在各个版本之间按照可预期的时间框架提供各种工具，MDOP 使 Microsoft 能够灵活地满足用户的各种需要，同时这也使企业客户能够从其软件投资中获得最大价值。
为帮助企业获得更大的灵活性，Microsoft 提出一种策略，可帮助客户获得一种更具动态的基础结构——这种动态是依据 Microsoft 在其动态系统计划 (DSI) 中所做的定义。有关 DSI 的详细信息，请参阅 microsoft.com/business/dsi 中提供的信息。
有关高层次上的策略就介绍这些。下面我们将分别介绍 MDOP 中所含的五项技术：
  • SoftGrid 应用程序虚拟化
  • 资产库存服务
  • 诊断和恢复工具集
  • 高级组策略管理
  • 系统中心桌面错误监控

SoftGrid 应用程序虚拟化
SoftGrid 应用程序虚拟化是从 Softricity 获得的技术，如其名称所示，它提供了应用程序虚拟化功能。当我第一次尝试使用 SoftGrid 时，我意识到它就是 Windows 2000 IntelliMirror® 本应具备的应用程序发布功能。为什么这样说呢？因为应用程序并未发布到客户端，而是完全虚拟化了。这样可以很容易地在客户端（或终端服务器）系统上提供应用程序。同样重要的是，此时可以对这些应用程序进行集中管理，并根据需要进行重新调用或更新。与 MSI 和转换的传统模型相比，SoftGrid 模型使应用程序的部署变得更容易，风险更低。
我们可以从虚拟映像的角度来认识 SoftGrid。您可能已经熟悉用于将 Windows（其中经常带有应用程序）部署到系统的磁盘映像的概念。实质上，SoftGrid 会获取应用程序并将其打包到一个应用程序映像中，而不是整个操作系统映像。
SoftGrid 应用程序虚拟化包含三个主要组件：应用程序虚拟化、应用程序发布和中心管理控制台。
应用程序虚拟化本身由以下各项的虚拟化表示组成：Windows 文件系统（包括系统文件）、Windows 注册表、字体、.ini 文件、COM/DCOM 对象、服务、内核对象（信号、mutex）、命名对象以及所有组件的命名空间。
请不要将 SoftGrid 虚拟化与 Windows Vista UAC 执行重定向的方式相混淆，这一点很重要。对于 UAC，当某个应用程序试图写入或修改注册表或文件系统的受保护区域时，它会被重定向到注册表和文件系统的用户特定视图。而 SoftGrid 则会使用将应用程序针对操作系统进行切实虚拟化的概念——包括其中所含的所有注册表和文件系统组件。不过，SoftGrid 的精妙之处在于它并不只是用来定义应用程序的单一功能。实际上，它包含以下各项：
  • 一个大小可达 4GB 的 SFT 文件；其中包含一个或多个应用程序及其所有依赖项，但 Windows 依赖项除外，它们一般位于目标系统上。
  • 一个大小约为 2KB 的 OSD 文件；其中包含有关如何请求和执行应用程序的定义。您可以将 OSD 文件视为一个 EXE 文件。
  • 一个大小约为 24KB 的 ICO 文件。这是启动该应用程序的一个有效快捷方式。
  • 一个大小约为 13KB 的 SPRJ 文件。排序器（SoftGrid 的核心）使用该文件来发布、打开、更新和修复现有程序包。
有关 SoftGrid 应用程序虚拟化工作方式的完整图示，请参见网站 softricity.com/ products/architecture.asp。
SoftGrid 解决方案的一大优点是可以使用一个中心管理控制台（参见图 1）来确定可提供给某个指定 Active Directory® 用户或一组用户的应用程序。然后，可以通过标准流协议并根据需要迅速将这些应用程序传递给用户。安装后，应用程序就可像是在本地安装的一样运作，它们支持用户自定义（甚至是通过漫游用户配置文件），并且即使客户端断开与网络的连接，也能正常工作。管理员甚至可以使应用程序变为不可用——以动态方式或自动进行（例如，在一个设定时间之后）。
图 1 SoftGrid 管理控制台
图 1 SoftGrid 管理控制台
最重要的是，鉴于应用程序的部署方式，您不必提供整个应用程序。实际上，可以只下载运行用户所使用的应用程序所需的部分。假设我们将整个 Microsoft Office 作为一个包来提供。如果用户只需要运行 Word，则只要下载运行 Word 所需的必要组件——而不必下载运行 Excel® 和 PowerPoint® 等所需的组件。如果用户要运行那些应用程序（例如 Excel），则可立即根据需要下载相关组件。
ERD 中包含的内容
  • 命令提示符
  • 资源管理器
  • 搜索
  • 记事本
  • 解决方案向导
  • 管理工具：Autoruns、Disk Management、Event Viewer、Registry Editor、Services and Drivers、System Information
  • 联网工具：File Sharing、Map Network Drive、TCP/IP Configuration
  • 系统工具：Crash Analyzer、Disk Commander、DiskWipe、FileRestore、Hotfix Uninstall、Locksmith、System File Repair、System Restore

SoftGrid 的另一个组件是其执行自动计数和许可检查的功能。这可帮助您遵守软件许可协议而无需额外的软件。
几乎任何应用程序都可以进行虚拟化。但也有一些例外，主要包括 Internet Explorer® 和其他 Windows 组件（包括修补程序和服务包）、防病毒软件和设备驱动程序。如果您希望深入了解 SoftGrid 的工作方式并探究其功能，建议您查阅位于 Softricity.com 的白皮书。

高级组策略管理
DesktopStandard 因其开发的弥补了组策略中薄弱环节的工具而为人所知。通过在 MDOP 中提供以前称为 GPOVault 的工具——现在称为高级组策略管理——Microsoft 为客户呈献了一款优秀的工具，能够将强大的（有时甚至是危险的）GPO 变成一个更加完善和可控制的过程。
如果您熟悉源控制软件的基本原理，那么可将高级组策略管理视为 Active Directory 组策略的源控件。（图 2 所示为高级组策略管理控制台的屏幕快照。）管理员签出现有策略修订，进行更改后再重新签入，使用类似组策略管理控制台的报告对结果进行审核。当管理员认为已经达到所需策略状态时，就可以提交更改并使之生效。与优秀的源控制软件一样，当确实存在错误时，可以迅速、安全地将更改回滚至较早的修订，而不会出现在这种过程中经常发生的任何臆断情况。
图 2 高级组策略管理控制台
图 2 高级组策略管理控制台
此过程的另一个重要方面是能够脱机编辑策略，而不要求对所有在线的活动系统进行更改。这样便可以在整个域或 OU 中进行更改之前先对更改进行隔离测试。
最后，通过基于角色的模型，高级组策略管理允许根据一个专门设计的工作流程来驱动更改。通过创建角色（如编辑者、检查者和审核者），管理员可以确保获得一个能够以受控制方式进行更改的过程。这样，当实施者认为可以提交更改时，他能够获得一个强有力的更改控制机制，确保在没有得到适当批准之前不会自动进行 GPO 更改。

资产库存服务
资产库存服务由 Microsoft 通过收购 AssetMetrix 获取的技术构成，它是一个强大的库存和资产管理解决方案。与 MDOP 的其他组件不同，AIS 采用了一种托管网站模型。AIS 使用一种对内存和带宽需求都很低的代理，它可以只运行一次，也可以定期运行；管理员可以使用该服务，通过搜索包含超过 400,000 个应用程序的超大型 Microsoft 托管数据库来寻找应用程序，以确定客户端系统上安装了哪些应用程序。然后，AIS 可以获取此累积数据并使其与您购买的许可证保持一致，以确保符合许可要求并减少因购买多余许可证所造成的浪费。
有些管理员最初可能对使用 AIS 有些犹豫不决，因为它是位于防火墙之外的托管模型，并且会在内部系统中清点安装的软件。但是，Microsoft 已经为确保组织隐私做了大量工作，首先是重新编写了构成 AIS 的应用程序的核心组件；了解这些很重要。这里不会将单个计算机的数据与任何组织数据重新捆绑在一起。Microsoft 还将认证一种由第三方提供的数据传输技术，以确保客户不会对 AIS 使用的模型感到不便。

诊断和恢复工具集
您可能知道（如果在过去几个月内您曾经阅读过我专栏上的生平介绍），当 Winternals 被 Microsoft 收购时，我是该公司的一员。在该公司供职期间，我是大部分 Winternals 产品的产品经理，其中包括 Winternals Administrator’s Pak。它就是 Microsoft 诊断和恢复工具集 (DaRT) 的前身。虽然以前存在于 Administrator’s Pak 中的某些工具已不再包含在 DaRT 中，但构成 ERD Commander 产品的关键组件仍然得以保留。
DaRT 的目标是提供一组能够帮助您诊断系统问题的工具——即使系统已经不能正常启动；并且您通常可以脱机修复这些问题。
ERD Commander 利用 Windows PE 来引导无法启动或无法正常启动的系统。在自定义的类似 Windows 资源管理器的界面下，提供了一组工具。其中的两款工具 Crash Analyzer 和 FileRestore 还可以在线使用。不过，如果您不是使用 ERD Commander 进行脱机诊断或恢复，那么必须在要运行它们的每个系统上都安装这些工具。
图 3 显示了 ERD Commander 的 DaRT 版本。在侧栏中可以找到 ERD Commander 组件中所含工具的列表。Explorer 工具是个例外，所列的前五个工具与您在常规 Windows 安装中使用的应用程序都相同。Explorer，连同从中启动它的 Start Menu 应用程序，是专门为在 Windows PE 下运行而开发的（小）版本。
图 3 ERD Commander
图 3 ERD Commander
Autoruns 工具源自一款同名的 Sysinternals 工具，利用它可以查看设置为在系统启动或用户登录时启动的所有应用程序。Disk Management、Event Viewer、Services and Drivers 和 System Information 工具位于通用用户界面中，它们的功能与 Windows 下名称类似的功能基本相似。Services and Drivers 工具尤为有用，因为它可以帮助您在系统出现故障时（由于设备驱动程序或无法正常工作的服务导致的）启动系统。最后还有一个 Windows Registry Editor，可用来处理脱机系统的注册表。
ERD Commander 还提供联网功能。虽然系统是通过 DHCP 自动配置的，但您可以使用 TCP/IP Configuration 小程序设置一个静态 IP 地址。不管是使用 DHCP 还是静态 IP 地址，都可以映射一个网络驱动器并向/从出现故障的系统复制文件，或者使用文件共享将系统变成一个文件服务器，以便能够使用一个正常工作的系统来复制故障系统中的文件。
最后还有一个杂项工具的集合。Crash Analyzer 使用 Debugging Tools for Windows（必须分别下载和安装它们——它们是免费的，但会经常更新）来诊断崩溃的原因。如果系统未启动，您可以在 ERD Commander 下脱机运行它；或者，您可以将一个 DMP 文件复制到安装了 DaRT 的正在运行的系统上，并在那里进行诊断。锁定故障原因后，如果是由一个新的服务或驱动程序引起的，则可以使用 Services and Drivers 工具将其禁用，并查看系统能否恢复正常。
Disk Commander 可帮助您恢复被意外删除或破坏的分区，以及恢复被删除的一组文件或一个目录。与之相反的是 DiskWipe，它可以用来完成一个 DoD 兼容的磁盘或卷擦除操作。FileRestore 用于恢复被意外删除的单个文件（在线或脱机恢复）。注意，不管使用哪种工具，文件类型和自删除后所过去的时间或磁盘活动都会影响恢复能力。
如果是 Windows 修补程序或服务包导致系统无法正常启动，可以使用 Hotfix Uninstall 工具有选择地卸载一个或多个修补程序或服务包。完成此过程需要重新启动，因为 Windows 并不支持完全脱机的应用程序删除操作。但这通常可以使您能够再次启动。
Locksmith 曾经是 Winternals 的 ERD Commander 工具集中所含的最受欢迎的工具之一。它可用来重置任何本地用户的密码。它不适用于域控制器，不能重置任何域用户的密码——通常，您可以使用该工具在忘记了密码或用户离开组织时重置本地管理员的密码。System File Repair 会检查所有受保护的系统文件，查看是否有任何损坏，并根据需要替换它们。System Restore 如其名称所示，用于在 Windows XP 系统上回滚或前滚至任何 Windows 系统恢复点。（要使用此功能，要求 Windows XP 具有预先存在的恢复点。）与很多用户一样，这一独特的功能曾经也挽救过我。
ERD Commander 和 DaRT 中的工具看似有些凌乱，但它们都是 Winternals 多年来开发出的强大实用工具的精选。我确信您会看到其价值所在，并发现它们对于您的恢复和故障排除任务所起到的帮助作用。

系统中心桌面错误监控
系统中心桌面错误监控 (DEM) 提供了一种迅速、便捷的方式，让任何组织都能将 Windows 崩溃和应用程序挂起问题集中起来并实施诊断。DEM 不会向 Microsoft 发送崩溃和挂起报告，而是使用组策略和内置 Windows 错误报告功能，将报告发送至您组织内指定用来进行诊断的服务器（其中并不要求具有一个附加软件代理）。所有 DEM 服务器数据都存储在一个 SQL Server 数据库中，因此您可以方便地查询收集的数据，用于您自己的内部应用程序和报告。这使您能够以一种更主动的方式来诊断组织内的问题。使用此信息，您可以要求生成此类事件的报告，发现最常见的崩溃和挂起原因，并确保为 Windows 补丁和应用程序补丁划分优先级以最小化或消除系统停机时间。
您还可以配置 DEM 服务器以便将结果上载至 Microsoft，以及使 DEM 自动下载 Microsoft 和第三方应用程序的最新故障排除数据。当出现崩溃或挂起时，可以从客户端获取更多数据。

获得 MDOP 许可
客户获得 MDOP 许可的第一项要求是具有现有的 Microsoft SA 协议。获得该协议后，每个桌面的许可费用的起步价为 7 到 10 美元。可以提供批量折扣和教学用价格优惠。
MDOP 在 SA 协议之外并不提供，但有一个例外情况：希望将 SoftGrid 技术用于其终端服务器（请参见 softricity.com/solutions/sbc.asp）或 SMS（请参见 softricity.com/products/softgrid-sms.asp）的客户可以这样做，并且将来的 SMS 和系统中心配置管理器版本还会提供 AssetMetrix 技术。

可用性和更新
今天，用户可以获得 MDOP 的初始组件。这些组件的提供情况如下：
  • Microsoft 已从 2007 年年初开始提供 SoftGrid。
  • Microsoft DaRT 自 2007 年 5 月开始提供。
  • GPOVault 技术应该于 2007 年 7 月提供。
  • 桌面错误监控应该于 2007 年 7 月在 MDOP 中提供。
  • AssetMetrix 技术应该于 2007 年 7 月发布 beta 版，并于 8 月发布正式版。
  • 对 DaRT 组件的更新计划于 2007 年下半年发布，其中的主要增强是 Windows Vista 兼容性。
MDOP 的将来版本计划是每年提供两次增强、升级和新功能发布。

MDOP 的发展方向
如前所述，AssetMetrix 技术的核心组件将集成到系统中心配置管理器的未来版本中。实际上，您可以预期，随着 Microsoft 对 MDOP 的不断推动，其中的某些功能会逐渐成为 Microsoft 部署、管理和配置技术的基线。随后，未来的 MDOP 版本还将提供一些新技术（有些由 Microsoft 开发，有些从其他公司获得）。从本质上讲，MDOP 将成为一个不断进步的先进管理和配置技术程序包。

Wes Miller是得克萨斯州奥斯汀市 Pluck 公司的一位开发经理。在这之前，他在奥斯汀的 Winternals Software 公司任职，并曾在 Microsoft 担任 Windows 项目经理和产品经理。您可以通过电子邮件 technet@getwired.com 与 Wes 联系。
对 Microsoft 桌面优化包产品经理 Chad Jones 和 Gavriella Schuster 为本期专栏所提供的帮助，在此致以深深的谢意。


 Windows 机密: 安全模式的修复功能
Windows 机密
安全模式的修复功能
Raymond Chen

当最初为 Windows® 95 开发 Windows 安全模式（也称作“哎呀糟透了请把它修好”模式）时，其目的是做更多事情，而不仅仅是禁用驱动程序。也就是说，它就是要修复那些能够自动修复的东西。
例如，当您在安全模式下启动时，Windows 资源管理器检查桌面上所有图标的位置，确保它们全部处于可见状态，因为制造一种某个图标位置偏离屏幕的状态也是可能的。
如果您想看看我谈的是什么，请在桌面上放置两个图标，一个在左边缘，一个在右边缘。使用“Ctrl+单击”选中这两个图标，然后抓取左图标并将它拖到屏幕的右侧。当您如此操作时，第二个图标也会随之移动，并与您拖动的图标保持不变的相对位置。第二个图标就这样向右移出了屏幕。
用户可使用安全模式排除 Windows 故障
用户可使用安全模式排除 Windows 故障
如果 Windows 资源管理器在安全模式下不能修复图标位置问题，那么，故障排除说明就可能令人困惑，而不是提供帮助：
  1. 以安全模式启动计算机。（好了。）
  2. 双击“我的电脑”图标。（嗯？我看不到“我的电脑”图标。）
  3. ...
啊！“我的电脑”图标在屏幕外或因其他原因不可用。您甚至无法通过故障排除的第二步。
有人曾经抱怨说：“你不应该自动修复图标。如果有用户就该问题寻求技术支持，支持工程师即可告诉他右键单击桌面，然后选择‘重新排列图标位置’选项。任务完成了，安全模式没有弄乱我的图标。”
首先，当您说“如果有用户就该问题寻求技术支持”的时候，您已经出局了。如果用户不得不拿起电话，你就失败了。
再说，这个提议也有悖于安全模式的心理作用。用户在事情不对劲时才开机进入安全模式，不过他们进入后也不一定知道该做些什么。他们真正要做的只是看一下会发生什么。“有些事情不对劲，让我们试试安全模式。”在 Windows 95 中，我们通过在安全模式中实施各种类型的自动修复操作，充分利用了这一心理。它的效果非常好。
此外，如果用户打电话来，您告诉他们：“开机进入安全模式；就会得到修复。”他们会自言自语地说：“好，太容易了。我本应该想到的。”
但是，如果您给他们一系列指示，说：“开机进入安全模式，右键单击这里，选择这个菜单项，然后单击那个框。”用户会遵循您的指示，问题也会得到解决，不过，这一点也不会让他们对使用计算机感到更轻松。他们反而会感到无力和泄气。用户不是充满信心，而是陷入一种认识上的无助状态。“我不可能搞清楚的。计算机用起来这么难。”

Raymond Chen的网站“The Old New Thing”和同名书 (Addison-Wesley, 2007) 讨论了 Windows 历史和 Win32 编程。作者喜欢在点燃导火索之前就逃之夭夭。