 TechNet Magazine February 2008

TechNet Magazine February 2008

Sharepoint: 在企业中收集数据的智能方法

信息是企业中最重要的资产之一。但是，管理通过电子邮件、基于 Web 的表单、调查以及其他机制收集的堆积如山的数据却是一大难题。下面我们来看一看 Microsoft Office system 可如何帮助您集成系统并使数据更具可访问性。

Keith Deshaies Sharepoint: 构建强大的调查基础结构

收集和分析数据是业务中必不可少的一个环节，但您需要使用一些工具，这样独立的团队才能根据需要收集所需数据。让我们了解一下如何利用 WSS 3.0、MOSS 2007 以及 InfoPath 2007 构建可在整个企业范围内使用的完善、灵活的调查解决方案。

Jim Bradley Sharepoint: 使用自定义内容类型对数据管理进行标准化

大量毫无关联的文档以及其他内容项目分散存储在大型组织中的不同位置，这使以集中、可重用的方式管理文档、文档的关联元数据以及文档行为变得十分困难。让我们了解一下如何使用 SharePoint 2007 中的内容类型来简化整个企业的内容管理。

Pav Cherny Office Communications Server: OCS 2007 如何利用状态显示功能

无论发送语音呼叫、视频会议、电子邮件还是 IM，Office Communications Server 2007 均可通过用户可用性的相关信息将通信路由至最合适的位置。我们来了解一下 OCS 2007 系统如何使用状态显示来连接端点。

Rajesh Ramanathan Office Communications Server: OCS 2007 语音部署规划

将 Office Communications Server 2007 与现有的 PBX 系统相集成是一项极具挑战性的任务。您需要选择集成方案、了解呼叫路由、清楚如何配置用户设置、着手号码规划以及执行其他一些工作。不过别担心。本概述将介绍您需要了解的信息。

Jochen Kunert and Rui Maximo 高性能计算: Windows Compute Cluster Server 简介

高性能计算依靠的不是大型专用系统，而是一组小型标准系统。通过以这种方式分配工作负荷，可以快速经济地解决复杂的问题。让我们了解一下 Windows Compute Cluster Server 2003 所提供的计算群集功能和支持。

John Kelbley and Doug Lindsey 在线增刊: 在终端服务中部署 2007 Office System

2007 Microsoft Office system 包括一些设计更改，在终端服务服务器场中部署它之前必须对此有所了解。本文概述了这些更改。

James D. Silliman 编辑寄语: 处理信息超载

Joshua Hoffman 读者来信: 读者心声

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

Greg Steen SQL 问题与解答: 非群集索引和保留权限

Saleem Hakani and Dan Carollo 实用工具特别推荐: ADMX Migrator

在 Windows Vista 中，组策略模板的格式已改为基于 XML 的结构。ADMX Migrator 实用工具可将原有的 ADM 文件转换为新的 ADMX 格式，还可以帮助您轻松创建自己的自定义 ADMX 文件。

Lance Whitney 网络专家: IEEE 802.1X 有线身份验证

IEEE 802.1X 身份验证为 Intranet 访问提供了一层额外的安全保障。让我们了解一下 Windows Vista 和 Windows Server 2008 如何为您的有线网络建立 IEEE 802.1X 身份验证。

Joseph Davies Windows PowerShell: Shell 权限

非常遗憾，Windows 的权限一直以来就非常复杂。但 Windows PowerShell 能提供一些帮助。让我们快速浏览一下 Windows 中权限的工作原理并找出如何能够简化与之相关的任务。

Don Jones 您好，脚本专家！: 比赛已经开始了！对了，还有一些 XML 也登场了。

Microsoft 脚本专家将继续关注 2008 脚本编写比赛，并且他们还会展示如何创建、添加和修改 XML 文档。顺便问一下，您听说过 2008 脚本编写比赛吗？

The Microsoft Scripting Guys 安全观察: 跳岛：减少不需要的依赖关系

不需要的安全依赖关系可能将您的整个网络暴露在攻击危险当中。理解安全依赖关系的工作原理将有助于分析您环境中的依赖关系并解决潜在问题。

Jesper M. Johansson 桌面文件: Windows XP 和 Windows PE 2.0 的双引导

从与 Windows 相同的分区引导 Windows PE 2.0 有许多优点。了解如何从同一个分区双引导 Windows XP 和 Windows PE 2.0，并探究执行此引导可以解决的问题。

Wes Miller 领域备注: 捐赠 PC

捐赠和重用旧硬件的同时，就不必填埋旧硬件，这样有助于保护我们的环境。以下提示可帮助您有效地删除旧计算机设备中的个人数据，以做好重用准备。

Jim Lynch Windows 机密: 废弃片段文件

下面讲一讲几个不太常用的功能的消失过程。

Raymond Chen


 Sharepoint: 在企业中收集数据的智能方法
Sharepoint Keith Deshaies

在企业中收集数据的智能方法
概览:
  • 收集和处理数据
  • 将表示逻辑从信息管理逻辑中分离出来
  • 利用 Microsoft Office 2007 技术构建数据收集解决方案
下载这篇文章的代码: DataGathering2008_02.exe (567KB)

企业利用各种方法来收集大量信息。数据的收集方式包括电子邮件、调查、Web 窗体及其他数据收集机制。通常情况下，数据会
发挥积极的作用。不过，管理大量数据收集工具和所有分散的信息却极其困难。可靠地集成和安全地共享数据一直是 IT 组织面临的挑战。随着各种标准和面向服务的体系结构的不断发展，IT 专业人员可以更加轻松地提高数据的可访问性和安全性。但是，尽管具有构建有效企业体系结构所需的各种工具和技术，其通用程度却远不能满足大量专有接口，因此产生了各自独立的解决方案。
以 Microsoft® Office system 中可用的技术为例。您可以基于 Windows® SharePoint® Services 3.0 快速创建一个部门调查，但是它是否为标准解决方案则取决于您的组织。如果您的公司将 ASP.NET 和 SharePoint 用作基于 Web 的协作和数据集成的平台，则此调查确实提供了标准的解决方案。但是，如果您的环境像我所在的公司那样采用了包括 SharePoint 在内的多个平台，情况就不同了。
当然，SharePoint 提供了多种用来与 IBM、HP、Siebel 等公司的各种系统集成的方法。对于希望创建专门的解决方案且仍使结果数据流入各种后端系统的高级用户而言，这是一个好消息。不过，如果您是一名解决方案架构师，还可以选择更好的方法 — InfoPath® 2007。
InfoPath 2007 是 2007 Office system 的一部分，您可以通过它将解决方案的表示逻辑从服务器上托管的信息管理逻辑中分离出来。利用基于 XML 的 InfoPath 技术，可构建适用于企业的数据收集解决方案。并且，在大多数情况下，InfoPath 窗体设计人员无需去详细了解 XML、Web 服务、解决方案体系结构、ASP.NET 或 SharePoint 对象模型。
在本文中，我将介绍如何使用 InfoPath 2007、Office SharePoint Server 2007 和窗体服务来构建灵活的数据收集解决方案。此外，还会展示如何利用 XML 在多层企业体系结构中将表示逻辑从业务逻辑中分离出来。
请注意，此处提及的“数据收集”指收集来自人类的信息的过程。当然，还有其他收集数据的方法（如爬网数据源），但是这些自动方法不在本文讨论范围之内。

采集和处理数据
数据采集要求可能非常复杂，但是它们具有一些共同点。通过在集中式模块中处理这些相似点，而在分散组件中处理独特要求，可有效地降低冗余工作、维护开销以及总体拥有成本。
例如，上市公司的符合性规定将产生业务要求，后者随之转换成适用于整个公司的信息管理策略。这些策略会影响跨部门的数据收集解决方案并且经常在各部门产生重复工作，例如，HR 部门（处理员工信息）和客户服务部门（处理客户信息）对个人身份信息的收集规则。甚至，类似但不相关的各部门之间的业务流程也可以采用统一的信息管理解决方案。
图 1 显示了典型业务流程的示例。当某个员工希望与同事交换任务时，他必须首先获得该同事的同意，然后是任务计划经理或协调员的批准，最后是主管的批准。例如，它可能涉及员工交换工作班次。尽管这些交换发生在不同的部门且可能采用不同的形式，但各种部门解决方案之间却可以共享相关工作流和信息管理逻辑。
图 1 可在部门之间共享的数据收集过程示例
图 1 可在部门之间共享的数据收集过程示例
当然，巩固冗余组件任务艰巨。推动整个公司的组织结构变化并非易事，但利用 Office system 技术可构建坚实的基础来促进这些变化。通过 InfoPath 2007，单个部门可创建与集中式标准信息管理系统相集成的窗体应用程序。同时，SharePoint 2007 使 IT 部门可将对站点集合、站点和文档库的管理控制委派给各个部门和团队。因此，各团队可在 IT 参与程度最低的情况下构建和部署自己的解决方案，而 IT 部门仍可控制所有共享服务和组件（如工作流、信息管理策略和备份过程）。

集中数据收集工作
企业通常向各团队提供部门应用程序服务器，以满足各自的信息管理需求。IT 部门仅负责保持硬件和操作系统正常运行，而各部门则需要管理其解决方案的所有方面。这些部门之间几乎很少协调，因此信息共享非常困难。
集中数据收集工作的技术难题主要涉及共享环境中自定义组件的安全性、性能、维护和支持。例如，如果在部门应用程序服务器上托管单个解决方案，则故障组件的影响会被隔离。但是，在共享环境中，故障组件则可能会更大规模地影响业务流程。这样，IT 部门就必须建立严格的策略来管理集中式系统上自定义组件的部署和维护。
如果在中心服务器场上托管部门的 SharePoint 解决方案，您需要在中心应用程序服务器上部署和维护这些部门解决方案的所有自定义组件。一种解决方案是依赖自定义字段类型，通过从后端 Web 服务填充的下拉列表来扩充解决方案的 UI。另一解决方案可依赖于 Web 部件来实现相同目的，它可以使用自定义工作流，所有工作流均使用托管代码编写且部署为 Microsoft .NET Framework 程序集。
即使将相对较少数量的 SharePoint 解决方案移动到中心应用程序服务器场，也可能产生棘手的配置和支持问题。如果必须在全局程序集缓存 (GAC) 中部署程序集，则安全性将成为问题，因为这些程序集将以完全信任方式运行。编程拙劣的组件可能使系统面临 SQL 注入、跨站点脚本或拒绝服务攻击。您需要确保组件可满足典型工作负载、峰值要求和长期运行操作，并保证它们不会阻止其他流程、可同步处理事件且组件执行可靠的输入验证。这样，用户就无法将 SQL 语句或脚本插入用于更新数据库或远程 Web 系统的列中。
简而言之，目的是要在标准产品功能的基础上加强安全且可扩展的服务器配置。通过依赖可重用且经过全面测试的解决方案，可避免创建大量自定义组件的麻烦。因此，可以保持前端分散而后端集中。关键是以松散耦合方式集成组件，以促进现有解决方案的重复使用。

拆分业务逻辑
那么，如何构建可在服务器上配置的灵活数据收集解决方案？最佳策略是将解决方案体系结构拆分成单个层，如图 2 所示：数据存储、业务逻辑和表示或 UI。现在，UI 通常基于浏览器，而业务逻辑则驻留在 Web 应用程序服务器上。它们分别需要访问数据库和非关系型数据存储库。
图 2 构建于三层体系结构上的典型企业解决方案
图 2 构建于三层体系结构上的典型企业解决方案
通常，业务逻辑包括事务逻辑来确保事务以原子级方式应用到各数据库管理系统。业务逻辑还可通过 HTTP、消息队列、RPC 等集成多个中间层服务。然而，整体解决方案体系结构本质上仍为三层模型。
图 2 中没有说明企业环境中业务逻辑的复杂性。此图中的应用程序服务器看起来似乎仅注重呈现基于浏览器的窗体和处理提交的数据，但该表示并未考虑工作流、符合性或信息管理需求。要解决这些需求，需将业务逻辑拆分成两个：表示逻辑和信息管理逻辑。这样，即可根据需要混合和匹配中间层组件，而不用针对每个解决方案从头重新构建组件。
图 3 显示了该体系结构，其核心是内容或数据，周围则是信息管理逻辑（它将在内容的整个生命周期中对其进行管理）。将表示逻辑与信息管理逻辑接合，即可通过用户界面访问数据。
图 3 将表示逻辑从信息管理逻辑中分离出来
图 3 将表示逻辑从信息管理逻辑中分离出来

XML 的收集和处理
在面向服务的应用程序 (SOA) 环境中，XML 是用于定义以及在各组件间共享数据和数据结构的主要标准。因此，XML 是在表示和信息管理组件之间实现接合的理想选择。
必须通过以下两种方式实现通信：需将 XML 转换成适于浏览器读取的文档和由窗体生成的 XML 文档。到目前为止，构建基于 XML 的窗体应用程序仍需要大量的编程技能。当结果 XML 数据必须遵守行业架构以促进组织内部的信息交换时尤其如此。
通过 InfoPath 2007，可以更加轻松地开发基于 XML 的窗体。掌握 XML 的具体细节当然非常有帮助，但窗体设计人员和高级用户已无需通过 XML 向导来构建基于 XML 的窗体应用程序。窗体设计人员只需将 XML 文档或 XML 架构导入 InfoPath，然后将各个属性和元素节点从数据源映射到窗体中的字段即可。窗体设计人员也可从 Web 服务、SQL Server® 数据库或者空白模板开始从头构建一个窗体，而 InfoPath 会在后台自动创建底层架构和数据绑定。
使用 InfoPath 和 XML 架构标准化窗体有多个好处。如果已有明确定义的 XML 架构，窗体设计人员以及工作流和信息管理组件的开发人员可根据相同的数据结构创建解决方案。如果窗体设计人员从头开始设计，则开发人员必须等到窗体完成后才能了解它对于底层数据结构的影响。定义完成数据结构后，只要现有的工作流和信息管理组件依赖于相同的数据结构，未来的解决方案（如新窗体模板）就可重复使用它们。并且，未来的工作流和信息管理组件可通过现有窗体和数据协同工作。如果基于已建立的行业架构来构建数据收集解决方案，结果会变得更加灵活。实际上，这些解决方案将与使用相同架构的其他公司所构建的解决方案相互兼容。
我创建了一个简单的 DirectReports 架构来将员工和经理关联起来。经理可使用结果窗体对其直接下属进行评估。可在本文所引用下载项的 Direct Reports 文件夹中找到架构、窗体以及说明如何重新创建窗体的 readme.htm，网址为 technetmagazine.com/code08.aspx。窗体只是基础，但却说明了基本概念。
下面这一点非常重要：我并未在 InfoPath 中创建任何验证逻辑，但是 InfoPath 仍会要求以特定的格式（domain\account 和 recipient@domain.tld）输入用户 ID 和电子邮件地址。否则，结果 XML 文档将无效。这是因为 XML 架构定义了这些格式。您可保存具有无效数据的窗体，但却无法提交它（如图 4 所示）。（我已向窗体添加了一个虚拟提交规则，因此您可以对此进行测试而不用实际向任何位置提交数据。）InfoPath 2007 验证会自动确保窗体已完全填写且无此类错误。
图 4a 验证出错阻止用户提交窗体
图 4a 验证出错阻止用户提交窗体
图 4b 生成的错误消息
图 4b 生成的错误消息
XML 架构将用作表示逻辑和信息管理逻辑之间的绑定约定。InfoPath 将锁定架构，这样窗体设计人员将无法刻意更改数据结构。这一点非常重要，因为更改已建立的 XML 架构可能会破坏现有的企业解决方案（如计划与新窗体模板结合使用的工作流模块）。
InfoPath 提供了大量功能，用来将高级的表示逻辑构建到窗体应用程序中。可使用 XML 文件、Web 服务、SharePoint 库和列表、数据库等中的数据来引入有意义的默认值。可通过规则（包括验证逻辑）根据用户选择更改字段值、添加托管代码以满足最高级的自定义需求，以及使用窗体服务使得可通过 Web 访问窗体模板。在任何情况下，窗体中的数据最后均会作为符合架构定义的 XML 文档到达信息管理逻辑。

使用 XML 或元数据
您可能想知道是应将信息管理逻辑直接应用到提交的 XML 文档还是使用分析器来将所需信息提取为元数据。SharePoint 可同时支持这两种方法。开发人员习惯于直接使用 XML 文档，但元数据更加灵活。
为了说明这一点，我创建了一个简单的 Web 服务，用于分析从图 4 所示的 Direct Reports 窗体传入的 XML 文档（可在随附下载项的 XMLParsingWebService 文件夹中找到源代码、安装文件以及具有分步说明的 readme.htm）。Web 服务可轻松地从 XML 文档中读取经理的用户 ID，将用户 ID 拆分成域和用户名两部分，根据这两部分创建消息，然后引发一个普通异常以返回处理后的信息，并在 InfoPath 窗体中以伪错误消息的形式显示。这是提交数据后在 InfoPath 中弹出对话框的一种简便方法。Web 服务非常有效，但是如果更改了底层数据源（例如，如果在 DirectReports.xsd 中将 OrgPerson 元素重命名为 Manager，并如 readme.htm 文件所述使用新架构更新了 InfoPath 窗体），Web 服务将失败。这一点也不奇怪。现在，XML 文档已发生变化，访问 User ID 元素的旧 XPath 表达式已无效。OrgPerson 和 Manager 架构几乎相同、InfoPath 窗体相同并且所需的处理结果也相同，尽管差异极小，但仍需部署和维护相同的 Web 服务。
如果希望将自定义代码在应用程序服务器上所占的空间降至最小，它并非一个好方法。与之相反，通过将 XML 节点映射到元数据字段并基于元数据执行处理，可针对类似数据结构使用相同的工作流和信息管理逻辑（即使 XML 架构并不相同）。只需确保子元素映射到正确的元数据字段并且数据格式符合处理要求，然后即可重复使用现有代码。
将 XML 节点映射到元数据字段与在 InfoPath 窗体中将 XML 节点绑定到 UI 控件（如图 5 所示）类似。在 SharePoint 中，元数据字段与在站点级别或列表级别定义且在内容类型定义中引用的列对应。内容类型定义了内容项目的特性（如元数据字段、工作流和窗体）。为使内容类型的元数据字段与相关 XML 文档中的对应节点保持同步，SharePoint 依赖于内置 XML 分析器执行属性升级和降级。在属性升级过程中，XML 分析器将 XML 文档中的节点值提取到文档库的对应列中。属性降级则指相反的过程，即从文档库中取出列值并写回文档。最重要的一点是 XML 分析器可使元数据字段和映射 XML 节点之间保持同步。
图 5 InfoPath 和 SharePoint 间的 XML 架构映射
图 5 InfoPath 和 SharePoint 间的 XML 架构映射
使用 SharePoint 对象模型时，Web 部件、工作流和信息管理逻辑可使用元数据字段以及底层 XML 文档。更改映射元数据字段的值会改变 XML 文档中的节点值，反之亦然。但是，直接使用 XML 文档可将业务逻辑和 XML 架构紧密结合起来。另一方面，映射元数据字段会提高代码的可重复使用性。显然，需确定哪种方法适合您的环境，但在大多数情况下，依赖元数据字段的 SharePoint 解决方案提供了更大的灵活性和更多的代码重用机会。
为说明 SharePoint 如何将 XML 节点与元数据字段关联起来，我在附属材料中包括了一个 SharePoint 功能以提供自定义文档库（请参阅随附下载项的 OrgPersonLib 文件夹中的 OrgPersonContentType.xml 文件）。OrgPerson 内容类型引用了以下四个字段：UserID、FullName、EMail 和 Direct_x0020_Reports。FullName 和 EMail 为内置字段。UserID 和 Direct_x0020_Reports 为 OrgPersonSiteColumns.xml 中定义的自定义字段。
字段定义非常通俗易懂。可在字段定义中直接将字段绑定到 XML 节点，也可在内容类型中覆盖此信息。我决定使用后一技术，因为它允许我在与 XML 文档不相关的内容类型以及依赖于不同 XML 结构的内容类型中使用自定义字段。OrgPerson 内容类型将元数据字段绑定到 XML 节点（其安排与我之前介绍的 OrgPerson 架构匹配）。此外，还有一个 AdditionalContentTypes.xml 文件，它定义了将相同元数据字段绑定到不同 XML 节点的更多内容类型。查看 Node 属性中的 XPath 表达式即可了解二者之间的差异。
OrgPersonLib 类型的文档库可存储不同类型的 XML 文档，而节点值通过相同的库列提供。此外，也可利用这个简单的映射技术来重用工作流和信息管理逻辑，因为四个内容类型（OrgPerson、Manager、Supervisor 和 User）引用一组共同的元数据字段。
图 6 显示了来自 Direct_x0020_Reports 的 OrgPerson 内容类型的 FieldRef 元素，它根据 XPath 表达式将字段映射到直接下属的 User ID 节点 (/OrgPerson/direct-report/user-id)。由于 XML 文档可包括多个直接下属条目，因此必须指定 Aggregation 属性。这便定义了 XML 分析器将如何处理返回的值集合。如果忽略此属性，XML 分析器将仅提取第一个节点值。支持的聚合值为 sum、count、average、min、max、merge、plain text、first 和 last。
图 6 映射到 XPath 表达式的元数据字段
图 6 映射到 XPath 表达式的元数据字段
所有示例内容类型均将标准 upload.aspx 页面用作 DocumentTemplate，因此单击 SharePoint UI 中的“新建”按钮时可将 XML 文件上载到文档库中。只要上载具有 .xml 文件扩展名的文件，SharePoint 就会自动调用内置 XML 分析器（一个例外情况是 WordProcessingML 文件，SharePoint 会为它调用 WordProcessingML 分析器）。XML 分析器会检查上载的 .xml 文件以确定相关的内容类型。这样，即可从字段定义中指定的位置中提取节点值并执行属性升级。（您可在上载 OrgPersonLib\XMLFiles 文件夹中包括的 OrgPerson.xml 文件时检验此过程。）此 XML 文档的结构与 OrgPerson 内容类型定义中指定的 XPath 表达式匹配。相应地，SharePoint 从 .xml 文件中提取数据、将数据写入对应的库列中并在 EditForm.aspx 页面中显示数据，因此可以确认并更新未标记为只读的文档属性。图 7 显示了包含从 OrgPerson.xml 中提取的数据的 EditForm.aspx 窗体。
图 7 包含提取数据的 EditForm.aspx 窗体
图 7 包含提取数据的 EditForm.aspx 窗体
如果更改 EditForm.aspx 中的 User ID、Full Name 或 E-Mail 值，SharePoint 会执行属性降级以更改底层 XML 文档中的节点值。不过，请注意，SharePoint 并不会强制施加 XML 架构限制，除非您亲自针对窗体执行所需逻辑。
此外，SharePoint 不会运行窗体应用程序的表示逻辑。例如，如果更改了 User ID，SharePoint 不会验证新值是否符合 NetBIOS 约定，也不会自动更新 Full Name 和 E-Mail 字段以匹配新选择。因此，如果更改单个字段可能产生不一致，应将内容类型定义中的对应列标记为只读，从而强制用户使用窗体应用程序（如 InfoPath）来更新数据。并且 XML 分析器会将 XML 文档中的所有更改提升到 SharePoint 中的对应元数据字段。
在 OrgPersonLib 示例中，可上载 OrgPersonLib\XMLFiles 文件夹中的任意 .xml 文件。.xml 文件使用完全不同的数据结构，但 SharePoint 会识别内容类型并将正确的节点值升级到站点列中。这是因为我在 XML 文件中使用了一个处理指令，来将 XML 文档与其对应的内容类型相关联。然而，OrgPerson.xml 文件并不包含此信息，但这不是问题。如果 SharePoint 无法通过处理指令或文档模板将 XML 文档与内容类型相关联，SharePoint 会使用默认的内容类型。对于 OrgPersonLib 的情况，它将恰好是 OrgPerson 内容类型，因此 XML 文档可被正确解析。
图 8 显示了如何明确地将 XML 文档与内容类型相关联。MicrosoftWindowsSharePointServices 处理指令将 ContentTypeID 定义为 0x010100668E393E4F0EFF4294DBD202D5D8321D。它恰好是 User 内容类型的 ID（如 AdditionalContentTypes.xml 中所定义）。
图 8 User.xml 示例文件的处理指令和 XML 数据
图 8 User.xml 示例文件的处理指令和 XML 数据
XML 分析器处理 MicrosoftWindowsSharePointServices 处理指令并将 ContentTypeID 值写入 ContentType 元数据字段。所有 SharePoint 内容类型都将共享此元数据字段，因为它是在 System 内容类型中的根级别定义的。如果打开 SharePoint 服务器上的 fieldswss.xml 文件（位于 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 文件夹中）并搜索 MicrosoftWindowsSharePointServices，即可了解 SharePoint 如何将处理指令与 ContentType 字段相关联。PITarget 属性指向 MicrosoftWindowsSharePointServices（它是处理指令），PIAttribute 指向 ContentTypeID（它包含 User 内容类型的 ID）。

InfoPath 中的内容类型关联
许多窗体设计人员都对 XML 分析和内容类型关联的技术细节感到非常头疼，但 InfoPath 2007 考虑到了所有的细枝末节。OrgPersonLib 示例随附的 readme.htm 文件包含了在 SharePoint 中发布 Direct Reports 窗体模板，以及创建仍然再次绑定到相同元数据字段（UserID、FullName、EMail 和 Direct_x0020_Reports）的内容类型的指令。您可以轻松地将新内容类型添加到 SharePoint UI 中的 OrgPersonLib 文档库。但是，新内容类型也指向作为文档模板的 InfoPath 窗体模板，以在更新现有 XML 文档时调用窗体应用程序。图 9 展示了 InfoPath 发布向导如何简化 XML 节点值与 SharePoint 站点列之间的属性映射。并且，如果再次将节点值与现有站点列相关联，可重复使用现有的 SharePoint 组件。
图 9 InfoPath 2007 中的属性映射
图 9 InfoPath 2007 中的属性映射

结束语
其他在线资源
  • InfoPath 2007 团队博客
  • W3C XML 架构规范和开发
  • XML 架构简介
  • Office SharePoint Server 2007 中的工作流
  • InfoPath 2007 窗体服务

通过利用 Office 中提供的技术，企业架构师可构建各种数据收集解决方案，它们具备改善代码重用和信息交换的功能。通过 InfoPath 2007，各部门可创建从各种来源提取信息的解决方案，然后将数据提交到各种系统（如 SharePoint）。SharePoint 还为开发人员提供了一整套 Web 服务和接口以构建工作流和信息管理组件。通过将这些组件托管在集中式 SharePoint 服务器上，各部门就拥有了构建其各自应用程序所需的基础结构。
同时，各部门可更快速地创建数据收集解决方案，可跨部门解决符合性规定和其他全球业务需求，并且随着应用程序服务器上自定义组件使用的减少，IT 环境的可维护性和可靠性将得以增强。

Keith Deshaies 是一位自由技术撰稿人和一家大型电信公司的 IT 分析师。他是 Microsoft Office 和 SharePoint 技术方面的专家，同时也是“技术交流协会”的一名会员。
© 2007 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.


 Sharepoint: 构建强大的调查基础结构
Sharepoint Jim Bradley

构建强大的调查基础结构
概览:
  • 规划和实施调查解决方案
  • 收集和处理 SharePoint 库中的调查结果
  • 管理性能和安全问题

没有充足的信息就无法做出正确的决策。仅凭预感是不能成事的，尤其是当您的决策会对业务产生影响的时候。无论您是要确定团队聚会的举办地点，
还是打算重新安排公司一半的资源来开发一种新产品，这一点都是毋庸置疑的。但是如何才能获得此类信息呢？
调查提供了一种用于收集反馈的经济有效的方法，从客户对您的产品的满意程度，到员工是否喜欢上次团队会议时吃的三明治，诸如此类的反馈。通过调查可以得到产品、系统或流程在日后改进和开发时所需的必要信息。问题在于，作为一名 IT 专业人员，您会如何建立可收集和存储数据的调查系统，以便有效地对这些信息加以利用？
您很可能已经有了一个或多个工具来收集、组织和分析此类数据。2007 Microsoft® Office system 也提供了这些工具，并且简化了这些工具的使用方法。实际上，可以通过多种方式来执行调查。但关键是要能够满足您的特定需求。例如，如果仅涉及少量受访者和非关键的数据，则对临时的实时数据收集而言，基于电子邮件的调查是一种不错的选择。有关详细信息，请参阅“使用电子邮件进行快速调查”下方的边栏。但是，如果受访者众多且属于关键任务数据，对这种相对复杂的方案而言，数据库驱动的调查会比较适合。有关此主题的详细信息，请参阅“构建数据库驱动的调查解决方案”下方的边栏。
在本文中，我将重点讲述另一种更加全面、更加灵活的解决方案：基于 SharePoint® 的在线调查。此方法对各种复杂程度的关键任务和非关键任务调查都适合。由于 SharePoint 调查基于 Web，所以任何人只要能够访问 Web 浏览器（甚至还包括移动设备）就能完成调查。在 SharePoint 调查中，可以自己的真实姓名进行答复，也可以匿名方式答复，您可以获得实时调查结果，甚至还可以使用一些分析工具。
要实施此调查类型，可使用带有 Forms Server 和 InfoPath® 的 Windows® SharePoint Services 3.0 (WSS) 或带有 Forms Services 和 InfoPath® 的 Microsoft Office SharePoint Server 2007 (MOSS)（有关其中各项技术的说明，请参见图 1）。由于这两种方案提供的功能本质上是相同的，因此在此次讨论中，我将重点讨论后者的组合。要全面了解 SharePoint 产品及其功能的比较情况，请参阅“Microsoft Office SharePoint Server 2007 产品比较下载”，网址为：office.microsoft.com/en-us/sharepointserver/HA101978031033.aspx。
Figure 1 支持 SharePoint 调查的 Microsoft 技术 (Close Figure 1)

技术 | 说明
Microsoft Office InfoPath 2007 | Microsoft Office InfoPath 2007 是一款用于创建表单和收集信息的工具。有关其他信息，请访问 office.microsoft.com/infopath。
Windows SharePoint Services 3.0 | Windows SharePoint Services 3.0（即原来的 SharePoint Team Services）是创建扩展 SharePoint 应用程序的基础。有关其他信息，请访问 microsoft.com/technet/windowsserver/sharepoint/techinfo/overview.mspx。
Microsoft Office SharePoint Server 2007 | Microsoft Office SharePoint Server 2007（即原来的 SharePoint Portal Server 2003）提供了一个服务器端的基础结构，使 Office 2007 客户变为 SharePoint 应用程序内容的创建者和使用者。有关其他信息，请访问 microsoft.com/sharepoint。
InfoPath Forms Services、Microsoft Office Forms Server 2007 | 利用 InfoPath Forms Services，用户无需安装 InfoPath 即可在 Web 浏览器中填写 InfoPath 表单，使调查成为跨平台、跨浏览器兼容的解决方案。Forms Services 需要使用 Windows SharePoint Services 3.0，尽管在名为 Microsoft Office Forms Server 2007 的独立产品中也提供了同样的功能。有关 Forms Services 的其他信息，请访问 microsoft.com/ms540731。有关 Forms Server 的详细信息，请访问 office.microsoft.com/en-us/formsserver/FX100490391033.aspx。

规划和实施
在设计调查时，需要事先考虑许多因素。这需要进行一些前期分析，因此务必要花时间制定一套考虑周全的调查计划。在初始规划阶段，需要定义想要获取的问题范围和数据种类、确定需要使用的技术以及建立预算和管理需求。之后即可转入实施阶段。常规的工作流包括设计调查表单、发布表单、收集和验证答复、汇集和分析数据以及报告结果。
调查实施工作流通常包括至少一名调查设计师、众多受访者以及一名分析师（如图 2 所示）。当然，调查工作流的复杂性可能会千差万别。例如，公司范围内的调查很可能要经过多轮的设计校订和审批。它很可能会利用自动执行的程序来提醒受访者、提供各种支持和故障排除表单、为管理者提供对结果的实时查看功能，并提供清晰的流程来确定和提交最终分析结果。此类调查的工作流较复杂，必须要使用支持工作流和报表功能的基于 Web 的系统。
图 2 调查工作流（从表单设计到数据分析）
图 2 调查工作流（从表单设计到数据分析）

完善的解决方案新看点
对于一个完善的调查解决方案而言，它必须满足许许多多的关键需求。该解决方案应允许单独的团队或业务部门自行创建、传播和收集调查结果，而尽可能不求助于 IT 部门，并且它应该不需要任何编程技能。表单创建工具应提供易用的“所见即所得”界面，以及能够充分发挥管道、分支和条件逻辑作用的丰富功能集。 显而易见，调查表单创建工具应适用于各种调查，而不论其规模大小和复杂程度如何。
此外，调查应在 Web 服务器上运行并与集中维护的 SQL Server® 数据库相集成，从而不必再由单独的部门来维护专用 SQL 数据库。任何受访者只要能访问 Internet 就能通过任意符合标准的浏览器填写调查。
调查流程可以方便地链接到工作流，并能够在不影响安全的情况下满足业务需求。此外，调查解决方案应能为许多组织提供多语言支持。
同时使用 MOSS 2007、WSS 3.0 和 InfoPath 2007，即可创建能够解决所有这些需求的集成解决方案。图 3 介绍了在 SharePoint 堆栈中各种组件是如何配合工作的。但是在讨论这一完整的调查解决方案之前，我想大概介绍一下单独使用 WSS 可以实现什么目标。然后，我将为您介绍添加 MOSS 和 InfoPath 后，协同使用这三者会为您带来的额外收益。
图 3 SharePoint 堆栈的组件
图 3 SharePoint 堆栈的组件

单独使用 WSS
即使没有其他组件，您也可以使用 WSS 来创建和实施调查。实际上，WSS 本身已包括了一个内置的调查模板，它可以使调查过程变得非常简单。要创建调查，请单击“开始”|“所有程序”|“管理工具”，然后选择“SharePoint 3.0 管理中心”。在下拉列表中，选择“网站操作”，然后单击“创建”。“创建”页面出现，其中会显示库、通信、跟踪、自定义列表以及网页的标题。在每个标题下方都有一些模板选项。在“跟踪”下方，单击“调查”。
WSS 会随后引导您逐步完成调查创建过程。您可以创建公开的或不公开的问题，并且能够指定是否可以对某个问题不做回答。您甚至还可以创建具有分支逻辑的调查，它能根据受访者的不同回答将其引入不同的路径。调查可以是匿名的，但如果需要，也可以标识受访者的身份。您还可以选择为调查分配一个工作流。
此调查基于浏览器，因此无需特殊的软件即可创建或接受调查。要填写调查，受访者只需登录 SharePoint 站点填写表单即可。访问权限是从父站点继承而来的，但也可以从 SharePoint 的“操作”菜单直接对其进行修改。调查答复被保存到 SharePoint 的调查站点，调查结果可以以列表形式或图形摘要形式查看，也可以导出到 Excel® 中。
重申一遍，此解决方案通过使用 WSS （再加上图 4 所示的流程）即可实现，无需任何其他软件。假设您已有了一个精心设计的 SharePoint 站点，单独的一个部门只需少量或者甚至根本不需要 IT 部门的协助就可以创建和实施调查。
图 4 基于 Windows SharePoint Service 的调查
图 4 基于 Windows SharePoint Service 的调查
如果需要对调查进行自定义，那么仅使用 WSS 流程所面临的一个限制就会凸显出来。WSS 使用各种默认的 ASPX 页（AllItems.aspx、DispForm.aspx、EditForm.aspx、NewForm.aspx、overview.aspx 以及 summary.aspx）来创建调查列表。虽然可以超越 WSS 中的固有参数对页面进行自定义，但大多数功能还是来自自定义起来不太容易的 Web 部件。而且，仅使用 WSS 的解决方案更适合于不需要集成外部数据源（如公司的 ERP 系统）的调查。
如果确实需要对调查解决方案加以扩展以包括自定义 UI 或集成其他数据源，则应认真考虑一下集 MOSS、WSS 和 InfoPath 于一身的解决方案。

完整的调查解决方案
MOSS 包括许多能够对 WSS 加以扩展的功能，但目前我想重点讲一讲 InfoPath Forms Services 这一组件。使用 InfoPath Forms Services 时，只有调查设计师一人需要在计算机中安装 InfoPath。其他人可通过 Web 浏览器访问调查。
在 InfoPath 中，设计师选中允许使用浏览器来填写表单的选项。InfoPath 随即创建一个表单，并且可在任何符合标准的 Web 浏览器中查看此表单。这一基于 Web 的表单与 InfoPath 表单的工作方式完全一样，只是在 InfoPath 的一些高级功能（如用户角色、垂直文本、对话框操作及高级控件等）方面存在例外。表单随后被发布到 SharePoint 库或列表。同时，InfoPath 的另一个功能（称为检查设计方案）可确保调查表单与 InfoPath Forms Services 兼容。
InfoPath 表单库与启用浏览器的表单库之间没有任何区别。在每种情况下，表单模板都是 .xsn 文件。可以使用 InfoPath Forms Services 在浏览器中显示表单，也可以将文件下载到客户端，然后直接在 InfoPath 中显示。如果调查设计师至少具有 SharePoint 站点的“参与者”权限，则他就可以使用 SharePoint 文档库来发布表单模板。
受访者只要具有符合标准的浏览器就可以填写 InfoPath Forms Services 调查，其答复随后将立即返回到 SharePoint 服务器。在 SharePoint 中，可以安全地存储、解析、共享和分析数据（使用 Excel、SQL 或可在网络中找到的其他工具）。所有这一切只需 IT 管理部门提供最低限度的协助即可实现。

回发和性能问题
不过，这可能会存在潜在的性能问题。例如，启用浏览器功能的表单是在 SharePoint 服务器的系统帐户环境中运行的，这意味着，如果表单包括代码或数据连接（如图 5 所示），则将在服务器上执行这些代码或数据连接，而不是在客户端中。复杂的表单可能需要频繁地将数据发回服务器，这就无疑增加了服务器的工作负荷。
图 5 具有其他数据连接的基于 InfoPath Forms Services 的调查解决方案
图 5 具有其他数据连接的基于 InfoPath Forms Services 的调查解决方案
调查使用的回发越多，前端 Web 服务器所承受的负荷就越大。但有时回发是不可避免的，如当实施分支响应时。为了最大程度地降低对系统的潜在不利影响，调查设计师必须意识到回发问题，并了解当回发不可避免时应如何最有效地实施调查。例如，设计师应采取类似于向导提示形式的调查，当用户单击“下一步”按钮时将数据发回服务器。这有助于减少回发的数量。
InfoPath Forms Services 必须维护服务器上当前所有活动表单的状态。默认的会话超时值为 60 分钟，也就是说，如果填写某个比较复杂的调查时所花费的时间超过 60 分钟，且在该时间内未回发任何数据，那么就会在服务器端关闭该会话。已输入但尚未提交的数据将丢失，受访者必须重新填写。
当有大量受访者同时填写调查表单且调查涉及大量数据源或包括文件附件时，此类问题会比较明显。有关详细信息，请参阅“改进 InfoPath 2007 表单的性能”，网址为：msdn2.microsoft.com/bb380251。

安全注意事项
虽然有关安全性的深入讨论不在了本文论述的范围之内，但强调几点安全注意事项还是非常有必要的。对于初学者，SharePoint 和 InfoPath 2007 都遵循 Microsoft 于 2002 年初采用的“可信赖计算计划”。InfoPath 表单有三个可能的安全级别：受限制、域和完全信任。默认情况下，InfoPath 会自动确定建议的安全级别并将其应用到表单。
数字签名功能可帮助确保表单是由特定用户创建或填写的并且它未被更改过。信息权限管理 (IRM) 可限制对模板和已完成表单的访问。为防止恶意用户上传包含有害代码的表单或使用 SharePoint 平台通过数据连接启动对其他系统的攻击，InfoPath 会对用户部署的表单和管理员部署的表单加以区分。用户只能上传不包含自定义代码的表单，并且只能使用“域”安全级别，这就限制了跨域的数据连接。这些参数将足以应对大部分调查解决方案。
当调查设计需要“完全信任”安全级别时，为了允许对资源的无限制访问，表单发布需要得到 IT 管理部门的批准。默认情况下，如果表单包含托管代码、在表单模板中定义了跨域的数据连接、表单使用了在集中管理的数据连接库中定义的数据连接或者启用了支持在移动设备上呈现的选项，则都需要 IT 管理部门进行批准。
对于“完全信任”安全级别，调查设计师将创建 InfoPath 表单并保存该表单模板。该模板或 .xsn 文件以电子邮件附件的形式发送给 SharePoint 管理员或通过网络共享进行传递。在将调查提供给产品系统之前，IT 管理员要对调查功能及其包含的所有代码进行检查。IT 管理员通过将调查模板上传到站点集合并激活调查模板来完成部署。这两个过程都是在“WSS 管理中心”控制台的“应用程序管理”页面上完成的。最终的结果是 IT 管理员可以将表单发布委派给单独的部门，然后继续对发布过程进行监督，确保这些表单行为不超出基本的数据收集活动。
对于一些常见情况来说，IT 管理员的监督是必不可少的，这些情况包括：表单必须使用默认数据进行填充以及调查结果要提交给多个数据源。默认情况下，“域信任”表单模板无法建立跨域的数据连接，但是可以通过采取一些措施来解决此限制，这些措施包括：
  • 授予表单“完全信任”权限。
  • 使用数据连接库中的数据连接创建“域信任”。
  • 搭配使用“域信任”和集中管理的连接库。
在表单发布期间，“完全信任”和集中管理的连接库选项需要管理员的批准。但是，使用在站点集合级别维护的数据连接库 (DCL)，用户发布的表单将可以跨越域边界。此 DCL 可以受单独部门的控制。但是，有一点必须要弄清楚，那就是允许单独的部门定义自己的基于服务器的数据连接可能会带来安全问题。
最安全的方法是在集中管理的连接库中定义数据连接，然后请 IT 管理员部署使用这些数据连接的高级调查表单。集中管理的连接库颇具优势，因为所有站点集合和整个服务器场都可以使用它。当访问不在本地 SharePoint 服务器上的数据源时，这将允许管理员定义中央身份验证设置。有关其他信息，请阅读在线文章“关于数据连接、身份验证和备选访问映射”，网址为：msdn2.microsoft.com/ms771995。

结束语
调查活动为各个级别的不同企业收集关键任务（及非关键任务）信息提供了一种强大有效的途径。但是，创建有效的调查需要合适的工具、合理的规划以及技巧和科学之间的巧妙搭配。事先进行全面的规划将有助于构建一个出色的解决方案，使组织中的各个部门都可以创建、发送、接收、存储以及分析调查数据。
如果调查能够获得及时、相关的信息，那么这个调查就是非常有效的调查了。为了能够在需要的时候收集到信息，您的解决方案必须能够简化在部门级创建和管理调查的过程，而且不会对安全产生影响。InfoPath 是信息工作者创建高质量调查的强大工具，它具有直观的界面，几乎无需培训即可使用。通过 InfoPath，您可以收集高质量的调查数据，而无需 IT 管理部门的过多介入。
InfoPath 2007 可与 WSS 和 MOSS 无缝配合，以便实施各种跨平台、跨浏览器兼容的复杂调查解决方案。这样，您的企业就能充分利用它的一项最重要的资产：信息。
使用电子邮件进行快速调查
要从一小组受访者中快速收集数据，临时调查是一种必不可少的手段。基于电子邮件的调查是此类实时调研的不二之选，这种调查创建迅速且不需要专门的服务器或 IT 部门的协助。在 Microsoft® Outlook® 邮件中嵌入投票按钮就属于其中一种最简便的方法，通过该方法，您可以发送、接收一维调查并使用表格列出结果。
开始投票按钮调查后，您的收件人会收到一封包含投票标记的电子邮件，其中会显示一个列出各种选项的下拉列表。收件人通过单击其中一个选项进行答复。然后会弹出一个窗口，显示消息“您已选择答复：<您的选择>”，并提供“发送”和“编辑”选项供您选择。
调查设计师或委派的代表收到电子邮件形式的个人答复，并手动将结果制成表格。如果调查包括大量的收件人，则应在 Outlook 中创建一条规则（使用规则向导），以自动将答复转到专用文件夹中，如图 A 所示。
图 A 自动将调查答复转到专用文件夹中
图 A 自动将调查答复转到专用文件夹中
不过，投票按钮的功能十分有限。插入到电子邮件的调查表单可以收集更多的数据，但手动检索数据并将这些数据制成表格可能会非常难以管理。对于基于电子邮件的调查，更为复杂之处在于它使用 VBScript 来自定义 Outlook 调查。自定义表单使收集和分析大量复杂数据的过程变得相对容易。要使用 Outlook 2007 中的开发人员功能，必须先显示“开发人员”选项卡，如图 B 所示。
图 B Outlook 2007 中的开发人员选项卡
图 B Outlook 2007 中的开发人员选项卡
创建自定义的 Outlook 窗体超出了一般 Outlook 用户掌握的知识范畴。但是，InfoPath® 2007 提供了一些新的功能，使实施自定义窗体变得非常容易。调查设计师无需专门的技术即可使用下列三种方式创建 InfoPath 表单和模板：
  • 导入现有的 Microsoft Word 文档或 Excel® 电子表格。
  • 下载经过初步设计的 InfoPath 模板并对其进行修改以满足特定需求。
  • 使用 InfoPath 的表单设计功能从头开始设计模板。
在这三种情况下，均可以将模板发布到 Outlook，然后通过电子邮件进行分发。利用 InfoPath 2007 和 Outlook 2007，只需少量或甚至根本不需要 IT 部门的协助，信息工作者就可以在数小时内创建一个包含二十个问题的调查，然后通过电子邮件将其发送到某个组、通过 Outlook 接收结果并使用 Excel 电子表格对数据进行分析。
此方案中唯一的实际要求就是所有参与者的计算机中都必须安装了 InfoPath 和 Outlook。由于 InfoPath 2007 实际上是扩展了 Outlook 2007 的功能，因此收件人直接在 Outlook 界面中就可以对调查进行答复。
但 InfoPath 远远不止是仅支持基于电子邮件的调查。您可以创建用于查询数据并将数据提交到 Web 服务和 SQL Server® 数据库的模板，也可以使用现有的 XML 文档或 XML 架构作为数据源。换句话说，只需极少的培训和加入少量（甚至根本无需加入）代码，用户就可以领略 XML 的强大功能和灵活性。
使用电子邮件作为调查解决方案有一些明显的弊端。例如，这些调查不能匿名，因为受访者的电子邮件地址是可见的。这可能会降低公正性并影响最终结果。此外，还有安全方面的问题（如仿冒攻击），因此使用基于电子邮件的调查所能收集到的信息类型和信息深度都有限制。

构建数据库驱动的调查解决方案
基于电子邮件的调查不适用于涉及大量受访者的较为复杂的调研 — 仅使用 Outlook® 中的一个文件夹管理和分析所有数据有些困难。更为可靠的解决方案是将对调查的答复导入数据库。数据库所具有的高级存储、编制索引、处理以及报表功能可能会对您非常有帮助。例如，Microsoft® SQL Server® 2005 就包括 SQL Server Reporting Services，它可以对调查结果自动进行处理。
要创建一个将答复提交到数据库的 InfoPath 表单模板，必须首先在网络中创建一个 Access® 或 SQL Server 数据库。接下来，在 InfoPath® 中，您可使用“设计表单模板”向导来启动模板创建过程。这将打开“数据连接向导”，它会逐步引导您将表单链接到数据库。InfoPath 使用数据库中的信息来构建数据源查询和数据字段。
只需极少量的培训或支持，大多数工作者所具有的知识就足以完成和提交调查。但是，在此方案中（数据直接传递到数据库），受访者必须安装 InfoPath 和 Outlook，并且他们必须位于公司防火墙后端或能使用 VPN 访问公司网络。
“InfoPath 数据连接向导”仅与 Microsoft SQL Server 2000 或更高版本以及本身使用 ADOXML 的 Access 数据库结合使用。对于其他数据库，不支持将数据直接提交到数据库。其他限制还包括 InfoPath 不允许将格式文本控件绑定到数据库字段以及不支持大型二进制数据类型等。
随着网络拓扑变得越来越大、越来越复杂，先将数据提交到中间的 Web 服务，然后再传递到数据库这一提交方法的优势日益明显。通过 Web 服务将调查表单前端从数据库后端分离还有利于在 Web 服务器上实施业务逻辑。由于 Web 服务是通过 HTTP 或 HTTPS 连接来执行的，所以参与者可以透过防火墙提交数据，如图 C 所示。但是要注意，受访者仍然必须安装 InfoPath 2003 或 2007。
此方案的不足之处在于实施过程需要 IT 部门参与。对此过程进行详细说明不属于本文的范畴，但我在此要告诫您的是从头开始构建数据库解决方案责任巨大。它需要事前规划、精心地进行调查设计、编写 Web 服务程序以及对数据库进行后端设计。InfoPath 2007 简化了流程的表单设计环节，但端到端解决方案还需要扎实的编程和数据库设计技能。添加高级功能（如工作流或多语言支持）会立即增加实施成本。
图 C 通过 Web 服务的 InfoPath 数据流
图 C 通过 Web 服务的 InfoPath 数据流

Jim Bradley 是 CoyoteTech LLC 的所有者。作为一家专业的通信公司，CoyoteTech LLC 专为 Microsoft 服务器产品开发用户协助文档。这些文档项目包括“Microsoft Exchange Server 2007 边缘传输和邮件保护”、“Microsoft Exchange Server 2007 的 64 位应用”以及“Microsoft Exchange 2003 技术参考指南”等。


 Sharepoint: 使用自定义内容类型对数据管理进行标准化
Sharepoint Pav Cherny

使用自定义内容类型对数据管理进行标准化
概览:
  • 使用 SharePoint 进行内容生命周期管理
  • 创建文档信息面板
  • 通过 InfoPath 来编辑 Office 和 SharePoint 文档
下载这篇文章的代码: ContentTypes2008_02.exe (779KB)

企业环境中存在大量文档及其他内容项目，企业要
以集中、可重用的方式管理文档、文档元数据和文档行为，面临着业务和技术方面的挑战。利用 Microsoft® Office SharePoint® Server 2007，组织内的各个团队可以共享网站上的工作区、文档库以及列表，有利于促进公司范围内的协作。
使用 SharePoint 2007，可以通过内容类型来标准化内容及生命周期特征的各个方面。站点内容类型是可以独立于任何特定站点集合、站点、列表或文档库而建立的元数据定义。这使您可以在公司范围内建立统一的属性、工作流、信息管理策略及其他元素，同时还允许各个部门或站点所有者自定义特定用途的内容类型。
在本文中，我将向您介绍如何使用在 Windows® SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 中引入的全新 SharePoint 内容模型来构建基于常规特征的企业内容层次结构。这些内容层次结构不但可以在全局级别统一应用元数据、工作流和信息管理策略，同时还具有一定的灵活性，可以在站点集合、站点、文档库和列表级别适应特有的内容管理需求。
为阐明 SharePoint 内容类型某些较低级别的情况，我在附属材料中提供了许多自定义工具，考虑到您可能会需要根据特定需求扩展这些工具，我还随附了源代码。不过请记住，这些工具尚未经过全面测试，因此不要用在生产系统中。您可以从《TechNet 杂志》网站下载代码，网址为 technetmagazine.com/code08.aspx。

内容生命周期和内容类型定义
SharePoint 资源
  • InfoPath 团队博客
  • Office SharePoint Server 2007 中的工作流
  • TechNet 网络广播：在 SharePoint Server 2007 中安装和配置搜索
  • InfoPath Forms Services

在组织中管理文档和其他内容时，有许多细节需要考虑。除此之外，还必须定义在创建、发布、存档和释放内容时，哪个人或哪个流程需要执行哪项操作。对组织而言，通常还需要开发用于内容创建的特定模板、定义角色以将责任和访问权限分配给用户、提供版本控制、监控兼容性、存储和存档、定义元数据等等。
无论某个特定内容生命周期多么复杂，SharePoint 内容模型均可找出某些常规特征和典型阶段，它们可以决定应该如何处理单个内容项目。例如，您可以通过模板和输入表单来组织内容创建，通过元数据来组织内容显示和搜索。您还可以使用编辑、批准或其他工作流需求、存档需求、过期时段以及适用的信息管理策略来区分单个内容片段。有些内容可能不需要任何特殊模板或者可能永远不需要存档，但即使这样它们也属于生命周期特征，会继续进入下一阶段以区分这些项目与其他项目。
SharePoint 内容模型允许您定义独立的内容类型并建立层次结构关系。在层次结构关系中，子项从父内容类型继承常规特征，并根据需要添加特定的特征。
要说明这一点，最佳方法就是检查 SharePoint 的内置内容类型。WSS 3.0 和 MOSS 2007 包括了许多典型项目的预定义内容类型，它们可存储在文档库或列表（包括文档和任务）中。您可以在 SharePoint 服务器上的 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Ctypes 文件夹中找到这些标准内容类型的定义。在那里您会发现一个名为 feature.xml 的指令清单文件。请看一下此文件，您会注意到 SharePoint 将标准内容类型定义作为具有站点集合范围 (Scope="Site") 的隐藏功能 (Hidden="TRUE") 实现，还可以注意到包含实际内容类型元素的 Element 指令清单文件为 ctypeswss.xml (<ElementManifest Location="ctypeswss.xml" />)。
如果您有兴趣了解有关 SharePoint 功能的更多信息，建议您阅读一下《MSDN® 杂志》中 Ted Pattison 的 Office Space 专栏，里面有一篇题为“SharePoint 的功能”的文章，网址为：msdnmagazine.com/issues/07/05/OfficeSpace。
现在，让我们在记事本中打开 ctypeswss.xml 文件来检查标准内容类型，忽略它们在 SharePoint 用户界面中的可见性。请勿修改 ctypeswss.xml。 如果您打算对 ctypeswss.xml 进行编辑以向标准内容类型中添加一些新字段或使隐藏的内容类型变为可见，以便 SharePoint 用户可以使用它们来派生新内容类型，那么请注意，这通常是没有必要的。而且这还会导致配置不受支持，甚至导致以后安装的 Service Pack 可能覆盖您的自定义内容并破坏内容管理解决方案。
较好的做法是将所需的内容复制到新的元素指令清单文件中、根据需要添加自定义内容，然后将自定义内容类型部署为具有站点集合范围的新功能，以便它们可供站点集合中的所有站点使用。
在 ctypeswss.xml 中指定的基于协作应用程序标记语言 (CAML) 的 System 内容类型定义如下所示：
<ContentType ID="0x"
    Name=$Resources:System
    Group="Hidden"
    Sealed="True"
    Version="0">
   <FieldRefs>
      <FieldRef ID="{c042a256-787d-4a6f-8a8a-cf6ab767f12d}" Name="ContentType"/>
   </FieldRefs>
</ContentType>
Group 和 Sealed 属性显示 System 内容类型已被隐藏和密封，因此不能在 SharePoint 用户界面中对其进行更改。System 内容类型只有一个 FieldRef 元素，它引用一个名为 ContentType 的内置站点列。这是最高级别的抽象。所有其他 SharePoint 内容类型都从 System 内容类型继承此属性。在此方法中，SharePoint 可确保存储在任何文档库或列表中的所有内容项目都共同拥有此属性。
图 1 显示了本文附属材料中提供的 ContentTypeHierarchy Web 部件，它以更加直观的方式对层次结构进行了说明。System 位于所有其他内容类型的根部，然后是 Item 等等。例如，Item 内容类型建立了下一级别的详细信息。如果检查 ctypeswss.xml，您会看到 Item 定义了一个单一的元数据字段，该字段引用了一个名为 Title 的站点列。通过这种方式，较低级别的所有内置内容类型都具有了 Title 属性。
图 1 WSS 3.0 内置内容类型层次结构
图 1 WSS 3.0 内置内容类型层次结构
继承的字段也可以删除，正如 ctypeswss.xml 中的 Document 内容类型定义所演示的那样。Document 内容类型包括多个对应的 RemoveFieldRef 元素，但是您可能希望 Title 字段按原样保留在您的自定义内容类型中，因为在 SharePoint 文档库和列表视图中可以通过 Title 列访问编辑控件箱 (ECB) 下拉菜单。
ctypeswss.xml 中的 Far East Contact 内容类型很好地说明了如何重命名继承的字段。搜索 0x0116（这是对应的内容类型 ID），然后检查 FieldRef 元素的属性 Name="Title"，以了解如何使用 DisplayName 属性来重命名用户界面中的字段。在这个特定的示例中，DisplayName 属性将用户界面中 Title 字段的名称更改为由 "$Resources:core,Last_Name;" 引用的本地化的数据值。
如果进一步查看图 1，您会看到 ContentType 元素的 ID 属性唯一标识了内容类型并建立了层次结构关系。所有 ID 均以父内容类型的 ID 开始，后面是附加的十六进制值。标准内容类型通常包含两个附加的十六进制值，以便为子内容类型创建新的唯一 ID。另一种方法是附带 "00" 和一个十六进制 GUID。举例来说，这就是 Office Data Connection File 和 Universal Data Connection File 内容类型从 Document 内容类型派生而来的过程。
用户需要记住的很重要一点是，ContentType 元素的 ID 属性的长度不能超过 1,024 个字符。如果所有内容类型均采用十六进制 GUID 寻址技术，这在大型层次结构关系中可能会是一个问题。但是，通过缩短长度的方法开始也不是可取之策，因为这些 ID 可能会不唯一。
为确保唯一性，请使用 GUID 技术为企业内容类型建立一个全局命名空间，然后在该命名空间中改用长度更短的方法。有关 ID 属性和其他内容类型定义元素的详细信息，请参阅 WSS 3.0 SDK 中的主题“内容类型定义架构”。

内容类型依赖关系
现在，让我们改为讨论如何使用 SharePoint 内容类型来组织对内容项目的管理。您需要考虑多个依赖关系，如文档库和列表、内容类型、站点列和字段类型之间的相互依赖关系。库和列表引用内容类型、内容类型引用站点列、站点列又引用字段类型（如标准 WSS 字段类型文本、注释、选择项、编号、货币等）、而字段类型又驻留在 Microsoft .NET Framework 程序集中（如 WSS 核心程序集 Microsoft.SharePoint.dll）。
举个例子，让我们返回到 System 内容类型，如先前在 System 内容类型指令清单文件条目的 CAML 定义中所阐述的那样。您将看到，此内容类型包含一个 FieldRef 元素，它引用一个名为 ContentType 的站点列。请注意，内容类型定义并不定义实际的 ContentType 站点列。ContentType 是在 Elements 指令清单 fieldswss.xml 中定义的 Text 字段，该指令清单位于 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 文件夹中。重申一下，Text 字段类型是在 fldtypes.xml 中定义的，您可在 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\XML 中找到该文件。对于此依赖关系树，尤其注意必须确保所有资源在 SharePoint 服务器上均可用。
您要使用的内容类型必须是在文档库和列表的站点级别或站点层次结构的较高级别创建的。同样，内容类型的元数据字段必须引用现有的站点列。您可以将基于标准或自定义字段类型的标准或自定义站点列添加到内容类型中，但必须确保这些站点列存在于本地站点内。此外，如果要使用自定义字段类型，则还需确保将基础 .NET 程序集部署到 SharePoint 服务器上。
对于引用文档模板、自定义事件接收器、工作流及其他组件的内容类型，也存在类似的依赖关系。例如，内容类型定义可包含一个指向与内容类型相关联的文档模板的 DocumentTemplate 元素。内容类型定义还可以包含具有一个或多个 XmlDocument 子元素的 XmlDocuments 元素，这些子元素定义内容类型的附加特征，如命名空间定义、文档信息面板定义或任何自定义的信息。

建立全局内容类型
具有编写权限的用户可以直接在 SharePoint 用户界面中创建新内容类型和站点列，但这些内容类型只能供本地站点和站点层次结构下层使用。自定义站点列只能在本地站点中使用。如果您希望建立全局内容类型，则这还不够充分。您需要确保全局内容类型在您的环境中可跨所有站点集合使用。此时，SharePoint 的功能就派上用场了。跨多个站点集合安装并激活 SharePoint 功能以在所有位置统一应用相应的站点列和内容类型定义是一件非常简单的事情。
本文的附属材料中提供了一个名为 AdventureWorks 的示例功能，它演示了如何建立全局内容类型。此功能将定义一个名为 Customer Documentation 的常规内容类型，该内容类型可用于创建任何类型的客户材料（如建议书和销售信函等）。我们可以根据常理来假设所有文档类型都与客户信息（如公司名称、联系人详细信息和地址等）相关联。我还专门为您的内容类型创建了一个名为 Customer Name 的自定义字段，并且还添加了一些内置字段，如 Department 和 Primary Phone。您可以通过编辑附属示例中的 ContentTypes.xml 文件来更改内容类型和字段，通过编辑 SiteColumns.xml 文件来更改字段引用。
如果您按照 readme.htm 文件所述来部署功能，则可跨多个站点集合统一激活该功能。然后，Customer Documentation 内容类型即可供全局使用。这样，各个部门便可通过与目标文档模板关联的派生内容类型来创建特定的客户文档。附属材料包括可用于销售和咨询的示例文档模板。图 2 显示了生成的内容类型。
图 2 客户文档的父内容类型和子内容类型
图 2 客户文档的父内容类型和子内容类型
在 WSS 3.0 和 MOSS 2007 中，您可以选择使用多种方法来创建自定义站点列和内容类型的功能。您可以研究 WSS 3.0 SDK 然后从头开始编写 XML 文件。您也可以选择使用 SharePoint Designer 将列表导出到个人 Web 包中、将生成的 .fwp 文件重命名为 .cab 文件、从 .cab 文件中提取 manifest.xml 文件，然后在 manifest.xml 文件中搜索 ContentType 定义。遗憾的是，这两种方法都不太方便而且容易出错。
相比之下，在 SharePoint 用户界面中创建自定义站点列和内容类型则非常容易。但是该界面并未提供编辑某个功能的 XML 文件的选项。“功能”是配置 SharePoint 资源的有效方式，但是一经配置之后，资源便仅存在于内容数据库中。或许在 WSS 的后续版本中会包括通过 SharePoint 用户界面将站点列和内容类型导出到 XML 文件中的功能（类似于导出到 Web 部件）。但目前，您需要自行处理此处的内容。
附属材料包括一个名为 ContentTypeSchema 的 Web 部件，它可以用作起始点。它使用 SharePoint 对象模型从所选内容类型中提取 SchemaXML 属性。通过基于可扩展的样式表语言转换 (XSLT) 的转换，Web 部件将派生出 Field 定义或 ContentType 定义，具体取决于您在单击显示按钮前在用户界面中选择的选项。
图 3 显示了这一使用中的 Web 部件。它显示了基于 Customer Documentation 内容类型的 Active Directory® Documentation 内容类型。Active Directory Documentation 内容类型与自定义的 Microsoft Word 模板 (Active Directory Template.dot) 相关联。请注意，此内容类型没有附加字段。所有字段均从父内容类型继承而来。
如果您打算在自己的环境中使用 ContentTypeSchema Web 部件，请记住，此 Web 部件尚未经过全面测试。我的 Web 部件使用了比较复杂的 XSL 转换过程在当前所选内容类型与其父内容类型的 SchemaXML 属性之间构建变化量。但是，XSLT 1.0 实际上并非针对高级 XML 文档转换而设计。不存在用于比较 XML 节点的内置功能。而且，XML 命名空间以及 CDATA 节都是 XSLT 1.0 无法有效进行处理的难题。
SharePoint 将使用 SharePoint 用户界面或 SharePoint 对象模型创建的站点列和站点内容类型的定义存储在内容数据库中名为 ContentTypes 的表内。在图 3 中，请看一下我的自定义内容类型的 ID。下面的 T-SQL 语句将提供相应的确切结果：SELECT Definition FROM ContentTypes WHERE ContentTypeId = <内容类型 ID>。
图 3 ContentTypeSchema 中的自定义内容类型定义 Web 部件
图 3 ContentTypeSchema 中的自定义内容类型定义 Web 部件
无论决定使用哪种方法，只要获取了站点列和内容类型定义，则为企业范围的内容类型创建功能将是一件轻而易举的事情。建议您对部门或公司的所有全局站点列和内容类型都使用单个功能。这样一来，就可以清楚添加新站点列和内容类型定义的位置。

对自定义元数据执行企业范围搜索
内容类型层次结构最直接的好处是，所有子内容类型均继承父内容类型的元数据字段。由于所有内容类型都共同拥有这些元数据字段，因此对用户而言，在文档库中创建自定义视图和过滤器相当容易。
AdventureWorks 示例功能非常直观地演示了这种情况。无论顾问或销售人员创建的是什么内容，在将生成的 Word 2007 文档保存到文档库时均需指定 Customer Name，因为 Customer Documentation 父内容类型根据需要定义了此元数据。通过根据 Customer Name 来分组或过滤文档库中的项目，顾问和销售团队成员可以方便、快捷地为客户找到所有现有的文档，如图 4 所示。
图 4 基于公共元数据对库中的各种文档进行分组
图 4 基于公共元数据对库中的各种文档进行分组
通过使用 WSS 3.0 和 MOSS 2007 的搜索功能，公共元数据还使跨多个文档库和站点查找内容变得非常简单。WSS 支持跨单个站点集合内的库、列表和站点进行搜索。MOSS 2007 允许您实施企业范围的搜索中心，并允许您在 SharePoint 3.0 管理中心用户界面中管理自定义元数据，这些都超出了基本功能的范畴。因此，下面将侧重于介绍 MOSS 2007。
当您在 MOSS 2007 中配置共享服务提供程序 (SSP) 并在 SharePoint 站点中爬网时，MOSS 2007 可自动发现在内容源中使用的公共元数据字段。相应地，您可在爬网属性列表中找到自定义的元数据字段。
在 SharePoint 功能中定义的元数据字段通常被归入 SharePoint 类别。要在 SharePoint 管理中心查找其位置，请在“共享服务管理”下的“快速启动”菜单上依次单击指向 SSP 的链接、“搜索”设置、“元数据”属性映射，接下来单击“快速启动”菜单中的“已爬网属性”，然后继续操作，打开 SharePoint 类别。
我将为您提供一个使用中的相关示例。名为 Customer Name 的元数据字段最终成为一个名为 ows_Customer_x0020_Name 的已爬网属性。SharePoint 为已爬网属性添加了前缀 "ows_"，"_x0020_" 是经过编码的单个空格。如果显示此爬网属性的详细信息，您会发现默认情况下它包括在搜索索引中，以使用户可以利用此爬网属性的值来执行内容搜索。但是，为了提高搜索精度，您可能不希望为使用户能够按客户名称来显式搜索内容而将已爬网属性映射到托管属性。
将已爬网属性映射到托管属性时，有两个选项可供您选择。您可以为每个已爬网属性自动生成新的托管属性，也可以手动将已爬网属性映射到托管属性。当您显示所需爬网属性类别的设置时（在类别（如 SharePoint 类别）中显示爬网属性时，单击“快速启动”链接上的“编辑类别”选项），第一个选项可用。在“批量爬网属性设置”下，必须选中“为此类别中发现的每个已爬网属性自动生成新的托管属性”复选框。但是，SharePoint 自动为创建的托管属性添加前缀 "ows_"，并使用 "_x0020_" 来转义空格。已爬网属性 ows_Customer_x0020_Name 的托管属性为 owsCustomerx0020Name。但这不是一个易于识别的属性名称。
或许较好的策略是在部署了企业范围的内容类型后，手动将已爬网属性映射到托管属性。您可以将一个已爬网属性映射到一个或多个托管属性。要在 SharePoint 管理中心创建新托管属性，请在“共享服务管理”下的“快速启动”菜单上依次单击指向 SSP 的链接、“搜索”设置、“元数据”属性映射，然后单击“新建托管属性”，以指定所需信息并将新托管属性与所需爬网属性相关联。
然后，用户可以使用托管属性来定位相关的内容项（可以使用“属性: 语法”的形式，也可以使用高级搜索）。例如，如果要将已爬网属性 ows_Customer_x0020_Name 映射到名为 Customer 的托管属性，用户只需在标准搜索框中指定 Customer: <客户名称>（如 Customer: Contoso），即可搜索该客户的所有文档。
将内容类型中最重要的元数据字段的托管属性包括在“高级搜索”页面上的属性列表中，这也是一个不错的想法。要实现此目的，请显示“高级搜索”页面，然后单击“现场操作”，并选择“编辑页面”命令。现在，您可以单击“高级搜索框”上的“编辑”来选择“修改共享 Web 部件”选项。当您展开“属性”类别并将光标置于相应的文本字段中时，可单击按钮以编辑属性 XML 文档。您需要向 <PropertyDefs> 元素添加一个属性定义，如 <PropertyDef Name="Customer" DataType="text" DisplayName="Customer Name"/>，还需要向 ResultType 元素（例如，元素 <ResultType DisplayName="All Results" Name="default">）下的此属性定义中添加一个引用，如 <PropertyRef Name="Customer" />。图 5a 显示了生成的“高级搜索”用户界面。图 5b 显示了搜索结果。
图 5a 基于客户名称搜索 IT 基础结构文档
图 5a 基于客户名称搜索 IT 基础结构文档
图 5b 客户名称搜索结果
图 5b 客户名称搜索结果

确保信息一致性
至此，我已成功地对最重要的元数据字段和内容类型进行了标准化，并基于 MOSS 2007 扩展了企业中跨站点集合的搜索功能。现在，当务之急是确保用户在元数据字段中输入的信息准确无误。
有两种方法可实现此目标。第一，您可以使用自定义的 InfoPath® 表单替换文档模板中的标准文档信息面板，该表单为用户提供了预定义的输入选项选择，如列表框中的选择项。第二，您可以将事件接收器绑定到内容类型，然后在用户创建、修改或删除相应的内容项时，检查元数据和其他信息的准确性。
这两个选项相互补充。InfoPath 表单主要提供编辑 SharePoint 内容类型的便利方法，而事件接收器可确保元数据的有效性（即使用户是在 InfoPath 表单外部编辑内容类型属性）。您可将事件处理程序绑定到特定内容类型，这将允许您在所有站点集合中指定与单个内容类型相关联的所有文档的事件及其响应，而不管文档库如何。您可在 msdn2.microsoft.com/ms453149 中找到有关如何开发和部署事件处理程序的详细信息。
将内容类型与自定义文档信息面板进行关联的最简单方法可能是在安装了 InfoPath 2007 的计算机中，在 SharePoint 用户界面上显示该内容类型的“文档信息面板”设置。然后，您可以单击“文档信息面板模板”下的“新建自定义模板”链接，在设计模式下启动 InfoPath 2007。但是，如果您的站点内容类型包括没有明确 SourceID 属性的站点列，则您可能会遇到 InfoPath 无法为“文档信息面板”表单创建有效 XSD 架构的情形。例如，先前引入的 Customer Documentation 内容类型包括多个可能会导致此问题的特定联系人列，如 Department、Office 以及电子邮件，如图 6 所示。
图 6 InfoPath 2007 中 XSD 架构的不兼容性
图 6 InfoPath 2007 中 XSD 架构的不兼容性
遇到这种问题时，您可以有两种选择。您可以从内容类型定义中删除对那些没有明确 SourceID 属性的站点列的引用，也可以使用与 InfoPath 2007 兼容的自定义站点列替换那些导致问题的内置站点列。请记住，在将基于 CAML 的内容类型的字段引用配置到内容数据库后，您不能再对其进行更改，尤其是在您已经创建了子内容类型的情况下。您再也不能仅更新一下基于 CAML 的内容类型定义文件，也不能只将更改向下推送到子内容类型，因为 Windows SharePoint Services 并不跟踪对父内容类型定义所做的更改。
要向下推送更改，您必须通过 SharePoint 用户界面或对象模型来更改父内容类型，或者必须定义从现有内容类型派生而来的新内容类型。利用后一种方法，您可以删除关键字段并添加新列。然后，您的用户即可从新内容类型派生以后的内容类型。为防止用户选择错误的内容类型，请将先前的内容类型添加到 _Hidden 内容类型组中。
我在之前曾说过，在部署并激活了基于 CAML 的内容类型后，将无法再更新它们。因此，在部署之前对全局内容类型进行测试显得非常重要。有关详细信息，请参阅 MSDN 文章“更新内容类型”，网址为：msdn2.microsoft.com/aa543504。
创建了具有正确字段引用的内容类型后，您便可以在 InfoPath 2007 中创建自定义文档信息面板。最佳策略是让站点所有者为其子内容类型创建自定义文档信息面板。InfoPath 2007 提供了将自定义文档信息面板直接发布到所选内容类型的选项，这将简化部署方案。它还可以在中心位置（如文档库）发布 InfoPath 表单，并将对文档信息面板的引用包括到内容类型中。如果您打算提供自定义文档信息面板以及 CAML 内容类型，这是最佳的选择。图 7 说明了实施体系结构。
图 7 MOSS 2007 中 XSN 文件在中心位置的实施
图 7 MOSS 2007 中 XSN 文件在中心位置的实施
本文的附属材料下载中包括一个名为 AdventureWorks_Update 的功能，它通过添加用于 InfoPath 2007 的附加站点列扩展了先前的 AdventureWorks 功能。AdventureWorks_Update 功能将原始的 Customer Documentation 内容类型标记为隐藏并派生出一个名为 Customer Docs 的新内容类型，它使用新站点列来替换继承的内置字段并将新内容类型与自定义文档信息面板相关联。
新的 Customer Docs 内容类型定义包括一个 XmlDocument 元素，它提供有关文档信息面板的信息。具体来说，xsnLocation 元素指向实施文档信息面板的 InfoPath 表单 http://companyresources/DIPs/customerDIP.xsn。有关如何应用 AdventureWorks_Update 功能的详细说明，请参阅 AdventureWorks_Update 文件夹下的 readme.htm 文件。

总结
您可以使用 SharePoint 内容类型来创建元数据策略，并在整个企业中将其统一用于内容管理。利用内容类型的层次结构，您可以标准化与整个企业环境相关的特征，并通过继承方式将其统一用于所有站点。
除此之外，它还可以扩展 MOSS 2007 的内置搜索功能，使用户可以更快速、更方便地查找到特定的内容。它也可以增强与元数据相关的信息一致性并建立集中的信息管理策略。最佳策略是基于最抽象的元数据特征来标准化全局内容类型，从而最大程度减少后续更改需求。SharePoint 内容类型以精心设计的内容模型为基础，可以提供众多新功能来标准化整个企业的内容生命周期管理。

Pav Cherny 是 Biblioso Corporation 的总裁，而且是一位 IT 专家和撰稿人，擅长协作和统一通信方面的 Microsoft 技术。他发表的作品主要侧重于 IT 操作和系统管理方面。


 Office Communications Server: OCS 2007 如何利用状态显示功能
Office Communications Server Rajesh Ramanathan

OCS 2007 如何利用状态显示功能
概览:
  • 授权和目录服务
  • OCS 2007 中的消息传送
  • 利用状态显示路由通信

Microsoft Office Communication Server (OCS) 2007 基于 Live Communication Server (LCS) 2005 版本的功能构建。LCS 2005 提供的是企业级的即时消息传送
(IM) 和状态显示。它还能通过远程呼叫控制 (RCC) 与现有 PBX 安装实现电话集成。
OCS 2007 进一步增强了 LCS 2005 中的状态显示和 IM 功能，并在 Office Communicator 2007 中增加了高级媒体和电话功能，使其成为羽翼丰满的 "softphone"。Microsoft 还针对媒体开发了会议服务器和边缘服务器。这样，您就可以利用现有 PBX 或单独制订完整的解决方案来满足组织的所有通信需求。
通过 Office Communicator 2007 的 "softphone" 功能，用户可以选择自己喜爱的 USB 设备并获得丰富的最终用户体验，使保持和转移这类常用的呼叫控制功能变得一目了然且便于使用。用户不必再记忆电话号码或使用拨号盘。只需轻松地单击鼠标从桌面应用程序进行呼叫，或通过将人员或通讯组列表拖放到对话中即可创建电话会议。
对于那些需要实物座机的用户，Office Communicator Phone Edition（或 Tanjay 电话）就像用户的另一个端点一样，Office Communicator 具有支持触摸屏的上下文菜单并提供熟悉的状态显示体验。
这些 OCS 系统功能以用户状态显示概念为核心构建。OCS 2007 可通过用户的可用性信息、通信端点和用户关系，使人们随时使用最适宜媒体进行联系。由于 OCS 集语音、电子邮件、IM 及其他通信方式于一体，所以它可帮助您以最有效的方式路由各种消息。
在本文中，将为您概述 OCS 2007 解决方案，并介绍如何将各部分组合到一起。此外，还将在文中描述如何将状态显示功能用作统一通信方案的重要组成部分，以及如何利用它来更有效地路由语音呼叫。

授权和目录服务
企业语音系统必须能够验证有权执行呼叫的人员的身份，还应具备对各个呼叫应用限制或策略的功能。在 IP 语音 (VoIP) 系统中，客户端需要经服务器验证才能发起呼叫。这类似于传统的 PBX 系统，在该系统中控制对实际线路的访问足以构成身份验证。
如图 1 所示，OCS 2007 系统使用 Active Directory® 进行验证并存储访问策略，OCS 通过针对 Active Directory 中的用户策略执行检查来授权呼叫。由于 OCS 与其他 Microsoft 应用程序（例如，Exchange Server 或 Microsoft® Outlook®）使用相同的 Active Directory 信息，您只需为 Active Directory 中的用户添加语音功能即可，方法是扩展用户的属性和策略（通过 Active Directory 架构扩展）并提供可供语音或 IM 等实时应用程序使用的统一目录。
图 1 OCS 统一通信组件
图 1 OCS 统一通信组件
在 Active Directory 中，与统一通信相关的最重要属性是会话初始协议 (SIP) 地址（也称为 SIP URI），在本质上它与用户的电子邮件地址非常相似。例如，Active Directory 中一位用户的电子邮件地址是 someone@contoso.com，那么为他分配的 SIP 地址将是 sip:someone@contoso.com。由于 SIP 地址与用户对象密切相关，因此您可以只使用一个身份，即用户登录其台式计算机或 Exchange 服务器所用的凭据也可用来登录 OCS 服务器。
另一个重要属性是用户的电话号码。OCS 服务器在内部会将发往电话号码的呼叫重新定向到能够路由呼叫的用户的 SIP URI。
OCS 2007 提供了通讯簿服务 (ABS) 界面，用于在组织内查找目录。它是脱机版本的通讯簿，使客户端端点不必每次在客户端执行搜索时都单击 Active Directory。
除 ABS 外，OCS 2007 还提供了通讯组列表扩展 (DLX) 服务，它使用户可在 Office Communicator 中看到与 Outlook 中相同的通讯组列表，并能在 Communicator 中扩充通讯组列表，从而更有效地发挥它的用途。用户可利用 Office Communicator 的这些通讯组列表内的成员直接设置电话会议，或启动群组 IM 聊天。

语音和消息传送服务
其他 OCS 资源
有关详细信息，请参阅下列资源：
  • 统一通信事件和网络广播
  • Office Communications Server 技术中心
  • TechNet 虚拟实验：启用用户和安装 Office Communicator 2007

企业语音解决方案必须提供用户最熟悉的呼叫控制功能。因此，OCS 2007 提供了常用的功能，如呼叫保持、呼叫转移和咨询转移、转发、同时震铃及 IM 等非语音模式。
OCS 2007 是语音呼叫路由的核心，提供入站和出站呼叫路由两种功能。出站呼叫路由包括转换号码、应用与用户相关的策略（例如国际呼叫限制）以及将呼叫路由到合适的端点或发送到公共交换电话网络 (PSTN)。入站呼叫路由功能处理用户选定的呼叫转发或时刻/状态显示首选项，并相应地路由传入呼叫。
OCS 本身不会中止传入呼叫。在 SIP 中，它的作用类似于 SIP 注册和 SIP 代理。系统中的客户端端点完全负责提供点到点信号和媒体。系统内的端点（如 Office Communicator 2007）提供了多频率音频编解码器（称为 RTAudio），它可以适应网络条件并具备恢复功能。
OCS 2007 借助可用于所有通信模式（如音频/视频、IM 和数据）的会议服务器角色，提供了内部部署 Web 会议。通过基于 OCS 的会议服务器，客户端端点可以从对等通信无缝转变为多参与者、多模通信，同时具备静音、排除参与者和锁定功能。预定会议可支持数百位参与者，临时讨论最多支持一百位参与者。您可通过 Outlook 加载项设定会议日程，或将来电升级为会议。此外，会议解决方案还提供诸如文件共享、白板和录音等工具。
当然，您必须能够连接到外部 PSTN 网络和电话号码，并能连通联盟企业或组织内现有的 PBX 安装。OCS 2007 与公用网关提供商提供的“SIP 转 PSTN”网关集成，从而允许连接到 PSTN 或现有的 PBX。可针对编解码器和信号转换配置“中介”服务器。中介服务器是可选的，针对不支持 Microsoft 编解码器的网关进行配置。
Exchange Server 2007 统一消息是面向 OCS 2007 的语音邮件解决方案。Exchange 统一消息为入站语音和传真呼叫提供呼叫应答，并会将收到的消息放入用户的 Exchange 邮箱内。此外，Exchange 统一消息还为公司提供了自动助理功能，以便为查找特定人员或部门的外部呼叫者提供帮助。
OCS 将实时 IM 作为使用音频的备用方案，它允许用户参加同时包含语言、视频和 IM 的多模会话。此外，Office Communicator 2007 还允许在 IM 中使用丰富的文本和格式，并且可随时将音频和视频加入 IM 会话，将 IM 对话无缝升级为音频对话。
计帐、日志记录和故障排除是另外附加的组件。“OCS 2007 呼叫细节记录”服务器可以执行计帐操作。对于在系统中发起的每个呼叫，均会创建一条记录，记下呼叫到达的时间、应答呼叫的目标以及其他各种参数，例如是否转移呼叫。OCS 还提供存档服务器，用来记录 IM 对话以满足符合性要求。体验质量 (QoE) 监视服务器可存储发起呼叫的相关质量信息，以用来排除网络中的语音质量问题。

注册和初始化
客户端初始化的第一步，OCS 系统中的每个客户端端点均需注册或登录 OCS。注册是与 OCS 服务器建立连接的过程，此步骤将通告存在客户。注册的过程涉及服务器对用户的身份验证，这也会在客户端实例和服务器之间建立安全关联。此安全关联将用于随后客户端通过服务器发起的呼叫，并由客户端通过重新注册定期刷新。重新注册的持续时间视服务器拓扑而定。例如，从企业外部通过 Microsoft AccessTM 边缘服务器注册的客户端端点刷新其注册的频率远远高于企业防火墙内部的客户端。
请注意，只有那些需要与 OCS 建立长期稳定的验证通道来接收语音呼叫或状态显示更改通知等此类传入通知的客户端端点才需要注册。Live Meeting 客户端端点仅在参加会议时才需要连接 OCS，因此无需向 OCS 注册。
为更好地理解 OCS 2007 中客户端交互的细节，让我们再深入了解一下作为客户端端点的 Office Communicator。（大部分与 Office Communicator 相关的信号流与用于其他客户端端点信号流相同，如 Office Communicator Phone Edition 或 Office Communicator Mobile。）注册完成后，Office Communicator 便会检索对客户端端点操作而言至关重要的配置信息。此类信息包括：
  • 自有信息，如联系卡、电子邮件地址、SIP URI、显示名称和电话号码
  • 针对客户端和策略启用的功能
  • 服务器地址，如 AV 边缘服务器 SIP 地址和语音邮件服务器地址
  • 存储在服务器上的联系人好友列表
  • 客户端位置的数字格式化规则
这种使用连接到服务器的现有 SIP 通道检索所有置备信息的机制称为区内置备。这样，只要客户端登录（即使是从网络或防火墙外部），客户端端点就能自动配置并刷新其配置信息。
注册时先要向服务器注册以进行初始化，然后获得并设置状态显示，最后输入就绪状态（请参见图 2）。请注意，OCS 允许为同一用户或 SIP URI 注册多个客户端端点。在注册期间，服务器向客户端返回唯一的 SIP 地址，以便能将所有传入的信号都发送给特定的客户端。此地址也称为可全局路由用户 URI (GRUU)。OCS 服务器会为每个向 OCS 注册的客户端端点分配一个单独的 GRUU 地址，作为其唯一标识。
图 2 注册步骤
图 2 注册步骤
为了控制注册，服务器限定每个用户最多可注册八次。如果为同一用户注册了多个客户端，则该配置称为多点登录 (MPOP)。如果只注册了一个客户端，则称为单点登录 (SPOP)。
OCS 系统的核心是 MPOP 概念。它使用户可以从任意端点接收传入呼叫或 IM 通知，从本质上而言，即允许用户使用多个电话或 IM 端点。这为应答 IM 甚至准确描述用户状态显示带来了有趣的动态效果。
例如，远程用户可能登录了一个无法接收 IM 的 Communicator Phone Edition IP 电话（SPOP 端点）。IP 电话会将端点的这一功能随同状态显示信息一并发布。用户的电话登录状态是联机。另一用户可以看到这一联机状态，并可能试图使用 Communicator 发送一个 IM。但是，由于状态显示已经发布了设备功能，因此会显示通知，指出远程用户所在的设备没有 IM 功能，所以无法接收消息。
另一个示例是自动接收 IM。无论何时启动 IM 对话，只要远程用户是单一 Communicator 实例（也就是 SPOP 端点），就会立即自动接收消息。但是，如果远程用户登录了两个 Communicator 实例（一台便携式计算机和一台台式机），则会有 10 秒的延迟，以便用户从一个设备接收即时消息。如果没有应答，则即时消息将由最活跃的 Communicator 实例自动接收。

状态显示
状态显示在统一通信中发挥着重要作用。它可使用户提前了解想通过给定模式通信的远程用户是否处于可用状态。因此，OCS 状态（例如“繁忙 — 正在通话”）所关联的是用户的忙碌状态，而非设备或线路繁忙。此外，OCS 2007 还提供了增强的状态显示基础结构，使用户能够共享位置、工作时间和会议时间等信息。
此外，用户还可通过 OCS 指定权限，使不同组的人员可根据其自己的权限级别访问不同组的状态显示信息。OCS 还能根据用户的状态显示（例如“请勿打扰”）和日历工作时间与呼叫方的权限级别做出路由决定，确定是为用户响铃，还是将呼叫发送到语音邮件。
在 Office Communicator 中单击呼叫显示的电话号码来源于三个位置，其中两个源自目录（全局地址列表/通讯簿服务器和 Outlook 联系人），第三个来自状态显示。通过状态显示，用户可以灵活发布要让其他人看到的电话号码。
此外，状态显示在许多语音路由的情况下也发挥着重要作用。例如，如果远程用户的状态显示指出“忙碌”并显示文字“会议中”，则用户接听语音呼叫的可能性很小。在这种情况下，呼叫方可能倾向于使用 IM 或电子邮件。同样，如果远程用户的状态显示为“请勿打扰”，这表明最好使用其他通信方式。
状态显示还带有用户当前会议主题和日历位置的相关信息，这些详细信息将发布给“团队”容器中的用户。它还具有某些特定功能的首选端点的相关信息，该信息可用来选取执行默认操作的端点。例如，仅从日历功能的首选端点发布日历数据（在所有端点基本都相同）。OCS 将按逻辑选择首选端点。
图 3 突出显示了状态显示带给 OCS 系统的不同功能。如前所述，状态显示是可用性和通信意愿的组合。“联机”状态表示用户非常愿意通信，“请勿打扰”则表示用户非常不愿意通信。除了需要对“请勿打扰”进行手动设置外，其他所有状态均由 Communicator 根据不同的条件自动捕捉，例如用户是否正在开会（忙碌）或不在计算机旁（非活动，然后离开），如图 4 所示。
Figure 3 如何设置状态显示信息 (Close Figure 3)

功能 | 来源
可用性和意愿（联机、脱机、离开、忙碌、请勿打扰） | 自动。根据会议状态、电话状态等等。也可手动设置。
日历状态（会议中，会议地点） | 自动。根据用户偏好。
设备功能（支持 IM） | 自动。根据 MPOP 设备。
电话号码 | 自动。根据用户偏好。
大部分活动端点 | 自动。根据用户活动。
注释 | 手动。由外出注释覆盖。
外出注释 | 自动。根据日历。
工作时间 | 自动。根据闲/忙数据。
位置 | 手动。根据用户选项。
图 4 状态显示是可用性和意愿的结合
图 4 状态显示是可用性和意愿的结合
请注意，可用性可由用户当前登录的多种不同设备来确定。由于同一用户有多个设备，每个设备都相应地发布设备的状态显示信息和用户数据，所以需要一种聚合逻辑以便为观察者呈现单一视图。OCS 就具有这样的聚合逻辑，可以根据状态显示系统所接收的各种参数、设备和输入计算状态显示。
在研究聚合前，有必要先了解一下如何向用户发布聚合信息。OCS 2007 引入了容器的概念，在某种程度上它类似于与社交圈相关的访问级别。每个容器提供不同数量的信息，加入特定容器的人员只能访问对该容器可用的信息。用户好友列表中的每个人都必须位于其中一个可用容器内。Office Communicator 允许用户向容器分配人员或根据关系级别将他们移入不同的容器。Office Communicator 使用智能试探法自动选择默认容器（图 5 中所列）。
Figure 5 状态显示容器 (Close Figure 5)

容器 | 用途
阻止 | 阻止状态显示信息。被阻止的用户不允许进行呼叫。但是，被阻止的用户可以看到姓名和电子邮件地址信息。
公共 | 提供姓名、标题、公司、电子邮件地址和有限的可用性。
公司 | 提供工作联系人信息、基本的计划和可用性。
团队 | 提供工作和移动电话号码、时间表、可用性，在“请勿打扰”状态时可打断用户。
个人 | 可以看到所有已发布的联系人信息，包括家庭和移动电话号码。
OCS 中的状态显示聚合根据设备报告给服务器的各种状态显示为用户确定正确的状态。图 6 展示了从不同来源聚合状态显示的方法。请注意，某些信息（如显示状态和用户活动）需通过 OCS 状态显示聚合机制发送才能在容器中使用，其他信息（如联系人详细信息）则由客户端端点添加到各自的容器内。不显示阻止的容器，因为除了成员关系信息，不向该容器发布其他信息。
图 6 状态显示聚合和发布
图 6 状态显示聚合和发布
在 OCS 系统中，当一个用户向联系人列表（好友列表）添加另一个用户时，会建立状态显示关系。但 OCS 系统还允许您查看公司目录中其他用户的状态显示，而无需将这些用户逐一加入自己的联系人列表中。
获得某人状态显示最简单的方法是在 Office Communicator 中进行搜索。这会在服务器上生成一个查询，并不会从服务器订阅有关远程用户状态显示更改的通知。但是，如果某个用户将其他用户加入其好友列表，则会订阅状态显示更改的通知，因此只要有变化，OCS 就会自动发送警报。

IM 和音频
IM 利用了注册和状态显示两方面的优势。在 OCS 系统中，消息在对等方之间传递，OCS 服务器则相当于一个代理，在 Office Communicator 客户端之间传送消息。
用户向其他用户发送的第一条消息十分重要。它会在 SIP 中建立会话。建立会话的一项内容是从注册的客户端中找出合适的 MPOP 客户端，在此过程中 OCS 将充当重要的代理角色。一旦用户接受传入的 IM 会话或用户的一个 MPOP 端点自动接受会话，后续消息就会顺利地进行端到端传递，而不再要求 OCS 查找合适的客户端。
用户可以在其桌面上将 IM 对话窗口保持打开状态，如果在 10 分钟的间隔内没有活动（即使 IM 窗口仍处于打开状态），Office Communicator 2007 将结束 SIP 会话。任何一方都可以终止 IM 会话。无论何时终止 IM 会话，Office Communicator 2007 都会自动创建对话历史记录项，在 Outlook 的“对话历史记录”文件夹中记录完整的对话。这是 Office Communicator 在 Outlook 中创建的特殊文件夹。客户端的日志记录功能是可选功能，默认情况下处于关闭状态。同一用户重新启动对话时，Office Communicator 会使用“对话历史记录”。因此，启用这一功能的用户在 IM 窗口关闭后仍可以更好的体验继续 IM 对话。
请注意，此处为振铃和 MPOP 展示的 IM 结构同样非常适用于语音。不过，邀请中包含的不是 IM 会话说明，而是指示音频功能的语音会话说明。OCS 会像应用于 IM 一样将对语音呼叫的振铃应用到所有端点。
语音信号大部分源自 IM 的概念，但它也可以满足处理媒体的需要。在后续文章中，我将详细讨论这一主题的相关内容。

Rajesh Ramanathan 已经在通信行业工作了 14 年，目前担任 Office Communicator 团队的首席项目经理。可通过 rajeshra@microsoft.com 与他联系。


 Office Communications Server: OCS 2007 语音部署规划
Office Communications Server Jochen Kunert and Rui Maximo

OCS 2007 语音部署规划
概览:
  • 电话服务集成方案
  • 配置 Office Communications Server
  • 用户、编号规划和路由

Microsoft Office Communications Server (OCS) 2007 是一款企业级产品，它实现了实时通信媒体与用户状态感知的集成，
其中包括 Web 会议（共享数据、音频和视频）、即时消息传递以及音频/视频会话。将 OCS 2007 与现有的 PBX 系统相集成非常具有挑战性。Office Communications Server 2007 并非为 PBX 设计，因为当今的信息工作者们在日常工作中使用的媒体通信方式多种多样（电子邮件、即时消息、电话以及语音邮件），但 PBX 系统却只能传送电话呼叫。
为了向管理员提供创建最优的个人或公司电话服务集成策略所需的灵活性，Office Communications Server 2007 提供了三种与现有电话服务环境相集成的配置方案。这些方案是：远程呼叫控制、企业语音以及集成了 PBX 的企业语音。
本文重点阐述有关 OCS 2007 电话服务部署（可能需要与现有的电话服务系统相集成）方面的规划注意事项。此信息对系统架构师、IT 管理员和电话服务管理员尤其有用。此外，我们还将提供有关其他方案的概述，但重点将是 Office Communications Server 2007 企业语音。

远程呼叫控制
其他 OCS 资源
  • Pro LCS:Live Communications Server 管理
  • 将电话服务与 Office Communications Server 2007 相集成
  • 企业语音规划与部署指南

在远程呼叫控制 (RCC) 方案中，用户已经具备 PBX、IP-PBX 或时分复用 (TDM) 桌面电话。利用 Office Communicator 2007 客户端，用户可以使用桌面电话拨打和接听电话而无需在话机拨号盘上拨号或拿起电话听筒。虽然用户可以使用 Office Communicator 2007 控制其桌面电话，但语音仍由 PBX 系统处理，而且不会转换为 IP 语音 (VoIP) 呼叫。尽管 Office Communicator 2007 能够控制桌面电话，但仍可以利用 PBX 电话拨打和接听呼叫，而无论 Office Communicator 2007 是否正在运行。
要在 Office Communicator 2007 和 OCS 2007 中启用 RCC，除了为 RCC 启用 Office Communications Server 2007 环境外，还必须部署会话初始协议 (SIP)/计算机支持的电话应用 (CSTA) 网关。SIP/CSTA 网关必须能够与您使用的 PBX 系统类型进行互操作，并且必须与 OCS 2007 兼容，因为它将作为这两个系统沟通的桥梁。为控制 PBX 电话，Office Communicator 2007 使用了 CSTA 协议。此协议定义了与电话交换机 (PBX) 进行交互时使用的 XML 架构，这在 ECMA（欧洲计算机厂家协会）269 标准中做了说明，此标准可在 www.ecma-international.org/publications/standards/Ecma-269.htm 找到。
Office Communicator 2007 通过发送 CSTA 命令来控制作为 SIP 负载的 PBX 电话，这些命令由 Office Communications Server 2007 路由到 SIP/CSTA 网关。Office Communications Server 2007 不需要了解 CSTA，只需知道如何路由即可。然后，SIP/CSTA 网关将命令转换为 PBX 所使用的本机协议。此过程如图 1 所示。
图 1 RCC 集成方案
图 1 RCC 集成方案
启用 RCC 需要五个步骤。第一步是配置 SIP/CSTA 网关以与 PBX 进行通信。第二步是配置 OCS 2007 将 CSTA 请求路由到 SIP/CSTA 网关。第三步是为 RCC 配置用户。第四步是配置 Office Communicator 2007。第五步是定义 OCS 2007 规范化规则，这些规则还适用于通讯簿电话号码规范化，这不同于与企业语音一起使用的电话号码规范化规则。

企业语音
为用户启用企业语音后，Office Communicator 2007 或 Office Communicator Phone Edition 将取代 PBX 电话成为该用户的主要电话。Office Communicator 2007 会为其分配一个唯一的电话号码。（为进行测试，可将现有的 PBX 电话转到 Office Communicator 2007 分配的新分机号。）Office Communicator 2007 与推荐的 USB 音频设备一起使用可同时处理呼叫控制（或信号）和媒体（音频和视频）。
在本方案中，Office Communications Server 2007 将在 IP 网络上的各 Office Communicator 2007 端点之间进行路由呼叫（IP-IP 呼叫），并将这些呼叫路由到公用电话交换网 (PSTN)/PBX（IP-PSTN 呼叫）。OCS 2007 对路由到 PSTN 的呼叫强制实施拨号限制。
要将 Office Communications Server 2007 环境连接到 PBX 或 PSTN，必须部署一个媒体网关，也称为 SIP/PSTN 或 IP/PSTN 网关。媒体网关必须与中介服务器（OCS 2007 的一种服务器角色）搭配使用才能连接到 Office Communications Server 2007 环境，如图 2 所示。中介服务器与关联的媒体网关应安装在相同的物理位置。
图 2 与 PSTN 或现有 PBX 集成的企业语音集成方案
图 2 与 PSTN 或现有 PBX 集成的企业语音集成方案
利用中介服务器，可将支持标准 SIP 实现（甚至不安全的 SIP 实现）的媒体网关与 Office Communications Server 2007 相连，因为 OCS 2007 只允许进行经过身份验证的加密的通信。中介服务器的另一项任务是处理标准编解码器（G.711、G.723 等）与 Microsoft 实时音频编解码器之间的编解码器转换。要获得 Office Communications Server 2007 支持的媒体网关列表，请参阅位于 technet.microsoft.com/bb735838 的 Strategic Hardware Partners。
您可以将媒体网关直接连接到 PSTN，也可以将其连接到现有 PBX 的主速率接口 (PRI) 中继连接。图 2 显示了可能存在的与 PSTN 和现有 PBX 集成的企业语音集成方案。对企业语音部署而言，控制器（通常是 Office Communications Server Standard Edition 服务器）并不是必需的。但建议使用它。
启用企业语音需要四个步骤。第一步是部署和配置媒体网关。由于它是 Microsoft 合作伙伴的产品，所以您应参考供应商文档，因为每种媒体网关的部署步骤都各不相同。
第二步是为各个媒体网关部署中介服务器。在此步骤中，必须配置中介服务器的一个网卡来发送和接收来自媒体网关的流量，配置中介服务器的另一个网卡来发送和接收来自 Office Communications Server 2007（通常是 Enterprise Edition 部署中的控制器）的流量。除非您的媒体网关是高级网关，否则它将需要 OCS 2007 中介服务器角色的协助才能与 OCS 2007 企业语音基础结构进行互操作。
第三步是定义编码规划。这包括定义语音策略、电话路由以及位置配置文件。
接下来要为企业语音配置用户。此外，必须为用户启用企业语音才能够向 PBX 或 PSTN 发出呼叫和接收来自 PBX 或 PSTN 的呼叫。这需要为每位用户分配唯一的电话号码。

集成了 PBX 的企业语音
此配置是企业语音配置的扩展。不同之处在于用户的 PBX 电话已被同步到该用户的 Office Communicator 客户端。此配置与通过 PBX 连接到 PSTN 的企业语音方案类似，如图 2 所示。但是，在此情况下，Office Communicator 2007 和现有的 PBX 电话将使用相同的电话号码，而不是使用 Office Communicator 2007 客户端来代替用户的 PBX 电话。
如果呼叫方使用另一部 PBX 电话或 PSTN 电话拨打用户分机，则 PBX 系统将通过 Office Communications Server 2007 将该呼叫分接到用户的 PBX 电话和用户的 Office Communicator 2007 客户端。当有传入呼叫时，用户的 Office Communicator 2007 客户端和 PBX 电话将同时响铃。相反，Office Communications Server 将通过媒体网关分接从 OCS 2007 到 PBX 的呼叫。使用 Office Communicator Phone Edition 时无法使用此方案。此配置要求使用 PBX 的语音邮件系统来处理语音邮件。对于此类用户，不能使用 Exchange Server 2007 统一消息作为语音邮件解决方案。
启用集成了 PBX 的企业语音所需的步骤与部署企业语音相同，此外还需要三个附加步骤。在第一个附加步骤中，必须将媒体网关直接连接到 PBX。然后，必须对 PBX 进行配置以支持此方案。（这可能需要升级 PBX 软件，具体取决于供应商。）最后，必须为用户启用 PBX 集成。
Microsoft 正致力于实现将中介服务器直接连接到 IP PBX 而无需媒体网关中继。请访问 technet.microsoft.com/bb735838 了解有关此主题的最新信息。

配置 Office Communications Server
企业语音功能由 Office Communications Server 2007 Enterprise Edition 和 Office Communications Server 2007 Standard Edition 中运行的服务进行处理。图 3 介绍了为企业语音提供路由入站和出站呼叫功能的服务
Figure 3 企业语音服务 (Close Figure 3)

服务 | 说明
转换服务 | 基于位置配置文件或电话内容应用规范化规则。
用户服务 | 对目标电话号码执行反向号码查询。
入站路由组件 | 应用目标用户的呼叫首选项。
Exchange 统一消息 | 根据需要将请求转发到语音邮件。
出站路由组件 | 根据 URI 和用户策略确定最优路由。
图 4 说明了当 OCS 2007 路由传入呼叫以执行 PC 到 PC 呼叫时，各个组件是如何对传入呼叫进行操作的。传入呼叫可以源自连接的端点（如 Office Communicator 2007 或 Office Communicator Phone Edition），也可以源自 PSTN/PBX 的中介服务器（PSTN-SIP 呼叫）。源自其中一个呼叫方的 Office Communications Server 2007 客户端端点（如 Office Communicator 2007）的传出呼叫将被发送到用户所在的 Standard Edition 服务器或 Enterprise 池。这个池称为用户的主池。
图 4 OCS 上企业语音相关服务的交互 前端服务器
图 4 OCS 上企业语音相关服务的交互 前端服务器
此时，Office Communications Server 2007 将对呼叫进行处理以确定路由目的地。下一跃点可以是被叫方的主池、中介服务器，也可以是 Microsoft® Exchange Server 2007 统一消息（请参阅图 5）。如果呼叫被路由到另一个主池，OCS 2007 会将该呼叫发送到被叫方的所有活动端点。被叫方的 Office Communicator 2007 或 Office Communicator Phone Edition 将响铃，并且设备上将出现一个弹出窗口通知。
图 5 呼叫路由
图 5 呼叫路由
如果呼叫被路由到中介服务器，该服务器将被配置为路由到特定的媒体网关。如果媒体网关直接连接到 PBX，则呼叫将由 PBX 路由到桌面电话或 PSTN。但是，如果媒体网关直接连接到 PSTN，则呼叫将直接到达 PSTN。
如果下一跃点是到 Exchange Server 2007 统一消息，则呼叫方可以留言。无论被叫方是否登录了 Office Communications Server 2007 都可以使用语音邮件。
当被叫方应答时，音频将以 IP 到 IP 呼叫的方式从呼叫方的 Office Communicator 2007 或 Office Communicator Phone Edition 直接发送到被叫方的 Office Communicator 2007 或 Office Communicator Phone Edition。如果呼叫方使用 PBX 或 PSTN 电话，则中介服务器将以 IP 到 PSTN 呼叫的方式将音频流量直接发送到被叫方的 Office Communicator 2007 或 Office Communicator Phone Edition。OCS 2007 仅处理呼叫信号，而这就是音频和视频在端点之间直接传输而不经 OCS 2007 路由的原因。

配置用户
必须为启用企业语音的用户分配在组织内部唯一的电话号码。此配置是在 Active Directory® 中完成的。这不同于为电话分配电话号码的大部分电话服务系统。这种设计的优点在于用户只要从客户端登录 OCS 2007，就可以将任意一台运行 Office Communicator 2007 的计算机用作自己的工作电话。这一方便的功能非常适合远程或现场办公的员工。
在 Active Directory 中，用户的电话号码以 E.164 格式指定。此格式定义了国际公共电信编号规划，这是唯一能够明确表示电话号码的编号方案。E.164 格式以如下格式指定电话号码：
+<country code><area code><phone number>
启用企业语音的用户有两种唯一表示形式：SIP URI 和 E.164 电话号码。当拨打某个电话号码时，Office Communications Server 将该电话号码的 E.164 表示 (+14255551212) 解析为用户的 SIP URI (joe@contoso.com)。然后，Office Communications Server 2007 根据被叫方的 SIP URI 路由该呼叫。如果无法将电话号码解析为 SIP URI，则 OCS 2007 会通过中介服务器将该呼叫路由到 PBX/PSTN。
规划企业语音部署时，如果必须要为每个 Office Communications Server 用户都分配一个唯一的电话号码，则需要考虑到现有的电话服务系统。如果通过媒体网关直接连接到 PSTN，则可能有一个全号段 2 或 3 位分机号及直拨 (DID) 号码可分配给 OCS 2007 用户。如果通过 PBX 连接到 PSTN，则可能会有一个由 PBX 提供的 DID 号段可分配给 OCS 2007 用户。

编码规划
虽然 E.164 格式的电话号码能够提供唯一的表示，但此方式对于拨号而言却不方便。而且，在 Office Communicator Phone Edition 或标准 PBX/PSTN 电话中无法输入此格式的号码。使用 10 个数字的拨号盘怎么能指定符号 + 呢？用户习惯于拨打较短的分机号，而此类分机号可能在特定位置是唯一的，但在整个公司范围内却不唯一。因此，有必要指定将此类分机号转换为 E.164 格式的转换规则。
管理员必须定义位置配置文件以指定执行这些号码转换的规范化规则。当电话号码被客户端（Office Communicator 2007 或 Communicator Phone Edition）或 Office Communications Server 2007 的转换服务扩展为 E.164 格式后，用户服务可执行反向号码查询并将 E.164 号码与对应的 SIP URI 相匹配。如果找到了匹配项，则在位置配置文件中定义的规范化规则将使用正则表达式来执行转换。例如，如果拨打 1234，则用来将任意四位数字模式转换为 +1425555{4 位数字} 格式的规范会将 1234 转换为 +1425551234。因此，利用位置配置文件，用户可以沿用熟悉的拨号习惯。
管理员可以通过以下三种方式为用户分配位置配置文件：
  • 通过组策略为使用 Office Communicator 2007 的用户定义位置配置文件。
  • 允许用户从 Office Communicator Phone Edition 选择位置配置文件。
  • 为主池分配位置配置文件。该配置文件将自动分配给位于该主池上的用户。
定义编号规划的过程包括创建语音策略、电话路由以及具有规范化规则的位置配置文件。语音策略定义了允许用户使用的呼叫接入类型。Office Communications Server 2007 通过电话路由确定如何将呼叫路由到 PBX/PSTN。由于可以通过多种方式来拨打电话号码，因此位置配置文件的规范化规则定义了如何将拨打的电话号码转换为能够随后进行路由的 E.164 格式。
启用企业语音的每位用户都由管理员关联到一个语音策略。语音策略定义了分配给用户的呼叫权限。呼叫权限将决定用户可以使用的路由，进而决定允许用户拨打的号码。每位用户都必须与单一的语音策略相关联。可用的策略数由管理员创建。
每个语音策略都包含一条允许或禁止用户启用并发响铃的设置以及一个按顺序排列的电话惯例列表。语音策略（与会议策略相似）是一个有关设置的逻辑容器，被定义为 XML 文档并存储在 Active Directory 中。这种设计的价值在于，无需扩展 Active Directory 方案，即可在未来版本的 OCS 2007 中进行扩展以支持其他策略设置。例如，如果某个语音策略未与任何电话惯例相关联，则会阻止分配了该策略的用户向 PBX/PSTN 拨打任何出站呼叫。此类用户只能拨打 IP-IP 电话。

电话惯例和路由
电话惯例定义了用户具有的电话路由权限。电话惯例是电话路由的集合。它必须是一个唯一的关键字字符串，即其他电话惯例不得与其同名。管理员可以根据需要创建任意多个惯例。
尽管语音策略可以直接与一个或一组路由（而不是电话惯例）相关联，但电话惯例的关键字却是维护策略与路由之间关联的一种抽象。如果策略直接与路由关联、彻底去除电话惯例的概念以及管理员修改了某个路由的名称，则需要更新与该路由关联的每个策略。通过使用电话惯例（这是策略和路由共有的用于在策略和路由之间创建关联的一个属性），即使路由名称发生了变化，策略和路由之间的关系仍然会保留。
路由包含电话号码模式以及连接到媒体网关的中介服务器的列表。必须为路由分配至少一个电话惯例。模式和网关之间的这种关联指定了如何路由匹配该特定模式的电话号码。
模式指定了它可以匹配的电话号码范围。它被定义为一个可以包括和排除一些电话号码的正则表达式。内置的“企业语音路由助手”工具有助于更加容易地构建这些正则表达式。因此，如果拨打的电话号码与路由的正则表达式模式匹配，则该呼叫将被路由到在路由中定义的其中一个网关。
单个路由中可以列出多个中介服务器（因此可有多个媒体网关）。Office Communications Server 2007 以轮询方式将呼叫路由到中介服务器，以此来平衡网关之间的流量负载。如果某个网关出现故障或停机维护，则相应的中介服务器将向 Office Communications Server 2007 返回一个响应，后者将立即尝试将该呼叫路由到路由列表中的其他中介服务器（因此会到达不同的媒体网关）。
如果向出现故障的媒体网关路由呼叫的尝试达到 10 次，Office Communications Server 2007 随后将按比例降低发往该媒体网关的流量，直到它再次响应为止。如果在附加的 10 次尝试后该媒体网关仍没有响应，则 Office Communications Server 2007 将停止向该媒体网关路由呼叫，直到它出现响应为止。
在电话路由中定义的媒体网关列表记录了网关的完全限定域名和端口号。如果电话号码与正则表达式模式不匹配，则检查与分配给该用户的电话惯例相关联的下一个路由，直到找到匹配模式为止。如果未找到匹配项，则无法路由该呼叫，因此也无法到达其目的地。用户将收到呼叫无法完成的通知。

后续步骤
Office Communications Server 2007 提供了三个级别的电话服务集成。在规划电话服务部署时，您需要确定哪个级别最适合您当前以及未来的电话业务需要。确定了这一点之后，您即可规划部署。规划的一个重要方面是为 Office Communications Server 企业语音部署定义编号规划。对此需要深思熟虑。
有关 Office Communications Server 2007 企业语音及相关技术的更多信息，请参阅“OCS 2007 附加资源”提要栏。

Jochen Kunert 具有 10 年的电信行业工作经验，目前在 Microsoft 担任 Office Communications 小组的高级项目经理。他是即将出版的新书《Microsoft Office Communications Server 2007 资源工具包》的合著者之一。可通过 jkunert@microsoft.com 与 Jochen 联系。
Rui Maximo 具有 14 年的 IT 行业工作经验，是《Pro LCS: Live Communications Server 管理》和《Microsoft Office Communications Server 2007 资源工具包》这两本书的合著者之一。可通过 ruim@ruimaximo.com 与 Rui 联系。


 高性能计算: Windows Compute Cluster Server 简介
高性能计算 John Kelbley and Doug Lindsey

Windows Compute Cluster Server 简介
概览:
  • 使用群集解决复杂问题
  • 计算群集的常规要求
  • 安装基于 Windows 的计算群集
  • 远程运行命令

高性能计算 (HPC) 是现在所使用的计算的一个分支，它主要用于解决计算量相当大的问题。许多年前，HPC（那时更常用的名称为“超级计算”）由
最初在研究中心出现的专用大型系统（非常昂贵）控制。然而，随着小型系统计算能力的提高，性价比的改变，计算工作负荷已经转向了 PC 级的系统。
许多计算量相当大的问题可通过并行完成计算来解决，也就是说，特殊计算或流程不用依赖其他计算结果就可独立完成。在这种情况下，大型问题就可以充分利用按计算群集分组的多个小型系统（节点）。以下给出了几个利用了计算群集的应用程序示例：
  • 金融模型 — 多次执行的算法或公式，每次的输入内容都不同。
  • 工程 — 模拟单个零件的效果，向模型应用表面质地特征。
  • 电脑动画 — 对影片中的每一帧应用表面质地特征和光照效果。
计算群集为解决复杂问题提供了一种经济快捷的途径。这里为您展示了 Windows® Compute Cluster Server 2003 所具备的主要计算群集功能和支持。
在此特别提醒：计算群集不同于可用性（故障转移）群集。您可能已经相当了解 Exchange、SQL Server® 或 Windows Server® 2003 中其他应用程序的可用性群集。它们通常利用共享存储来最大限度地保障应用程序的正常运行时间。计算群集的目的不是在出现中断时使另一个系统继续运行，而是使所有的节点以协作的方式运行。

计算群集的常规要求
HCP 资源
  • Windows HPC 社区
  • 使用 WCCS 2003 进行高性能计算
  • Microsoft 64 位计算概述
  • Microsoft Servers 主页
  • Compute Cluster Server 技术中心
  • 高性能计算群集部署安装、配置和调整分步指南

现代 HPC 系统具备一些相同的关键元素，用于协助处理工作负荷。首先，您需要多个系统。还需要制订计划程序，以协调各个节点的工作分配。这个计划程序在主管节点（头节点）上运行，确定可用的资源，指派并分配任务，同时跟踪作业的整体状态。它负责在系统群集和用户及管理员提交处理作业的位置点之间协调资源。
群集需要一种在节点间进行通信的方式。根据工作的具体类型，节点可能需要高速、低延迟的互联，以便相互传递信息来协调处理。每个计算节点和头节点至少必须连接到一个共用的网络。
若要大量互联系统协同工作以解决复杂问题，还需时刻关注并提供必要的条件。需要具备能置备、监控、管理和维护数十到成百上千系统的流程和工具，以确保提供协调稳定的环境。
最后也是最重要的，要有能开发出计算群集并行处理功能的应用程序。如果没有可以分解作业使其在多台计算机上进行处理的应用程序，或缺乏能支持“并行调试器”的开发工具，群集能发挥的作用就极为有限。

基于 Windows Server 的群集
2006 年，Microsoft 推出了 Windows Server 2003 Compute Cluster Edition (CCE) 和 Windows Compute Cluster Server 2003 (WCCS)，以满足各类 HPC 应用程序的需求。CCE 和 WCCS 的基础是您已经很熟悉的 Windows Server 2003。CCE 是许可与 HPC 应用程序搭配使用的 Windows Server 2003 版本。WCCS 相当于添加了 Microsoft® Compute Cluster Pack (CCP) 的 CCE。这意味着在部署、管理、监控和维护基于 Windows Server 的群集时，您使用的工具与管理现有 Windows Server 2003 系统所用的工具相同。
CCE 和 WCCS 仅有 x64 版，而没有 32 位 (x86) 版本，这一点请特别注意。附带 WCCS 的 CCE 的硬件要求与 Windows Server 2003 Standard x64 Edition 的硬件要求相同。除了支持高性能硬件（64 位架构），产品还为高性能互联（Gigabit 以太网、InfiniBand、Myrinet 等）提供远程直接内存访问 (RDMA) 支持。

Compute Cluster Pack
如前所述，计算群集的某些基本要求可通过安装 Compute Cluster Pack 得以满足。CCP 是独立的安装程序软件包，其中包括：
  • 集成的作业计划程序
  • 行业标准 MPICH2 的消息传递界面 (MPI) 支持
  • 群集资源管理和用户工具
CCE 和 WCCS 之间的主要区别是 CCP。您可能要问：如果计算群集需要这些组件，为什么只在 WCCS 中有，而在 CCE 中没有。答案是：某些 HPC 解决方案可以充分利用多种作业计划程序或专用 MPI（或者不需要 MPI 支持），并且仅需要一个出色的运行平台，即 Windows Server 2003。由于 CCP 是独立的软件包，您可以将其安装在 Windows Server 2003 的其他 x64 版本上（CCE、Standard、Standard R2、Enterprise 和 Enterprise R2）。

具体细节
WCCS 利用 Windows 的主要基础来简化基于 Windows 群集的管理和操作，包括 Active Directory® 和远程安装服务 (RIS)。Compute Cluster Server 使用 Active Directory 透明管理安全性。借助 Active Directory，用户可以使用一组能在数以百计的服务器节点间运行的凭据，向头节点提交作业。在一个或多个计算节点上执行作业时，它们在提交作业时所提供的用户凭据上下文中运行，之后安全缓存。WCCS 依靠 Active Directory 实现“单点登录”功能。在环境中呈现 Active Directory 的另一好处是：管理员可以使用组策略集中管理服务器和配置策略。
如果您的 IT 组织已经部署了 Active Directory，通过在现有域中构建群集，您可以节省大量时间和管理精力。我们推荐采用这种方法。
如果需要在没有 Active Directory 的环境中部署计算群集，我们建议您部署一个或多个专用域控制器来为群集承载 Active Directory。通常将头节点用作 Active Directory 域控制器，原因在于无论网络的拓扑结构如何，所有节点都已通过网络连接至系统。但是，如果群集数量相当大，建议不要将头节点用作域控制器，否则会加大头节点的负荷。实施时请遵循 Active Directory 的常规部署和管理原则（安装冗余域控制器、足量的备份、良好的安全规程等）

远程安装服务
WCCS 为“Microsoft 远程安装服务”映像部署平台提供了集成的前端。RIS 用于从头节点向每个计算节点部署操作系统映像，这意味着您可以使用 RIS 迅速安装新的群集节点。您不一定非要采用这种方法，在 WCCS 中集成 RIS 是为了方便起见。您还可以使用其他常用的 Windows Server 部署技术，例如，Windows Server 2003 自动部署服务 (ADS) 或手动安装 Windows Server 2003。
如果您想使用 RIS，在头节点上安装 CCP 前，请确保已至少定义了两个逻辑磁盘。RIS 需要一个与操作系统分开的磁盘来存储服务器映像。您的 RIS 分区应该有足够的可用磁盘空间，以容纳一个或多个 Windows Server 映像的完整副本。
对于最新出品的服务器硬件，特别是网络连接和存储设备，其所需的“即插即用”驱动程序可能没有包含在默认 Window Server 2003 映像内。如出现这种情况，您需要手动将这些驱动程序添加到映像内。support.microsoft.com/kb/254078 上有此操作的步骤记录。

安装自己的群集
第一步是配置您群集的大脑 — 头节点。先安装前面提到的 Windows Server 2003 的 x64 版本。在操作系统安装期间，可以选择是否将服务器加入现有的域（推荐）或在服务器上安装 Active Directory（如群集数量相当大，建议不要做此选择）。
操作系统安装完毕后，请确保您已经从 Microsoft Update 下载并安装了所有推荐的修补程序。如果您计划使用 RIS 进行计算机节点映像，您还需要使用“计算机管理”|“磁盘管理”这一管理工具来确保至少定义了两个逻辑磁盘。出于篇幅考虑，我们在本篇文章中不介绍基于 RIS 的安装。
成功登录并更新服务器后，您可以运行 CCP 安装程序。然后 CCP 安装程序会进行安装，或指导您下载并安装以下必备文件和更新项：
  • RIS 修补程序（请访问 go.microsoft.com/fwlink/?linkid=55167）
  • Microsoft 管理控制台 (MMC) 3.0（请访问 go.microsoft.com/fwlink/?linkid=62400）
  • SQL Server Desktop Edition（安装 Compute Cluster Server 2003 头节点时已随附安装此产品）
  • Microsoft .NET Framework 2.0
CCP 安装程序在评估您系统的安装准备状况方面有着出色的表现。它会让您了解执行过程中需要安装哪些组件，并自行安装这些组件，如图 1 所示。
图 1 安装 CCP 需要的组件
图 1 安装 CCP 需要的组件

任务列表
CCP 安装完成后，将启动管理员控制台，其侧重点是任务列表。如图 2 所示，任务列表包含几个窗格，每个窗格处理一个不同的领域并列出完成群集配置所需的关键任务。
图 2 任务列表列出了配置群集时您需要执行的任务
图 2 任务列表列出了配置群集时您需要执行的任务
您可以使用任务列表轻松实施您已建立的群集架构，包括选择并配置网络拓扑、节点安装流程和用户管理模型。每个窗格在右侧列出相应的任务，每项任务都会启动一个向导。为完整配置的头节点依次完成每项任务，该节点可以将 RIS 映像部署到一组已知的计算节点，并且可由一组已定义的用户管理和访问。
网络连接拓扑 WCCS 支持 HPC 中使用的五种最常用的网络拓扑。所有计算节点和头节点必须至少共享一个共用的网络。拓扑包括支持节点中多种类型的互联，并有单独的好处和成本。
您的网络拓扑取决于您群集的性能、安全性和部署要求。例如，您的应用程序可能需要高速互联进行信息传递，而您不想将其暴露给公司网络。您可能想利用基于 RIS 的集成自动部署功能。也许您所选择的硬件只适用单个 NIC，或者您希望头节点运行 Internet 连接共享 (ICS)，以便管理计算节点的名称解析和寻址。从任务列表调用“配置群集网络拓扑”向导后，您将获得常规 HPC 实施典型支持的五种拓扑，并帮助您配置网络连接，包括头节点和计算节点上的 Windows 防火墙配置。图 3 显示了一种支持的网络拓扑。
图 3 一种支持的 WCCS 网络拓扑
图 3 一种支持的 WCCS 网络拓扑
远程安装服务 如前所述，RIS 能够实现自动部署群集节点。
节点管理 您可以指定将在此群集中作为计算节点的服务器的计算机名。如果节点上执行 CCP，此时则需要指定节点所在群集的头节点。
用户管理 您可在此处指定将哪个 Active Directory 用户帐户或组作为系统管理员，还可以指定群集的用户。

节点安装
可以通过 RIS 管理实用程序或使用其他支持的部署方法自动部署计算节点。对于头节点，则必须在每个计算节点上安装 CCP。如图 4 所示，CCP 安装配置选项对于计算节点而言更为简单，它由以下项目组成：
图 4 Compute Cluster Pack 安装程序
图 4 Compute Cluster Pack 安装程序
  • 指定服务器应是计算节点（而非头节点）。
  • 指定应添加服务器的群集的头节点名称。
  • 指定是否在计算节点上安装管理工具和用户工具。

管理员控制台
节点与头节点实现通信后，便可以通过管理员控制台完成所有系统的大部分管理和监管任务，如图 5 所示。通过控制台可集中查看整个群集，包括所有相关节点的列表、对关键管理操作的访问权限和其他细节。最左侧窗格提供了可通过控制台实现的高级浏览，包括访问“群集管理员”，选中此选项后将出现一个摘要屏幕，其中显示群集状态和作业统计信息。在这里也可以查看对所有远程桌面和系统监视器会话的访问权限，但您大部分时间是使用“节点管理”来管理群集。
图 5 通过管理员控制台可集中查看整个群集
图 5 通过管理员控制台可集中查看整个群集
您应该自己熟悉了解管理员控制台，因为通过它可以访问集中管理 Windows 和群集节点所需的主要工具和功能。单击顶端中部窗格中的群集节点，会调出几个其他的窗口，您可以从中浏览各个节点对应的功能。
右键单击菜单所支持的功能使您可以通过“节点管理”轻松集中管理计算节点。您可以使用“节点管理”暂停或恢复节点；批准向群集中加入或从中删除节点；启动远程桌面、系统监视器或事件查看器；弹出 CD 托盘（如果您正试图在一个大型群集中找出一台计算机，此功能会很有用）。

酷炫 ClusRun
此列表中最酷的一项功能是“运行命令”，即远程运行任何命令，就像您就在目标计算机前面坐着并根据命令提示符进行操作一样。WCCS 包括命令行版本的“运行命令”功能，称为 Clusrun.exe，“ClusRun”用于说明 GUI 和命令行版本。
ClusRun 实用程序的好处超乎想象，尤其是在大型群集中。运行重复性的命令行任务时，它可节省大量的时间，有了它，还不必再编写相当复杂的管理脚本。
要使用此功能，突出显示希望使其运行命令的计算机的列表，然后右键单击，选择“运行命令”。随即将显示图 6 中的对话框。现在只需键入您所需的命令，然后单击“运行”，输出结果很快就会显示在“结果”窗口中。首次使用 ClusRun 时，系统会提示您输入凭据，但您可以选择缓存这些凭据以便随后反复使用。
图 6 可以在多个节点上运行命令
图 6 可以在多个节点上运行命令
为群集安装修补程序或安装包含自动安装例程的程序的常用方法是，将其置于文件共享，然后使用 ClusRun 强制所有计算节点调用该命令。通过一个命令就可以重新启动整个群集中的所有计算节点：
CLUSRUN SHUTDOWN –R –F –T 0

工具包
2007 年 5 月，HPC 团队发布了 Compute Cluster Pack 工具包（您可从 windowshpc.net/resources/Pages/default.aspx 在线获得该工具包）。此工具包内含 Windows PowerShellTM 支持、用于诊断连接状况的 MPIPingPong 工具和一个非常简单但很实用的图形化群集监视器。
如图 7 所示，“简单群集监视器”可在一个屏幕上显示群集中的每个节点、每个节点所具有的核心数量、每个 CPU 的利用率（亮绿）、内存利用率（黄色）、磁盘时间百分比（红色）和网络带宽利用率（橙色）。管理员可利用这个一目了然的工具了解群集的状况。
图 7 使用简单群集监视器监控多个节点
图 7 使用简单群集监视器监控多个节点
群集监视器还包括“远程”功能。您必须在头节点上运行群集监视器的第一个实例。但是，如果您在头节点上运行控制台会话中的群集监视器实例，您将有机会从工作站启动群集监视器的实例，将其指向头节点并获得相同的显示结果。

马上行动
现在您已了解了 HPC 和 Windows Server 2003 Compute Cluster Server。您了解到如何安装 CCP，并亲眼目睹了表现出色的综合控制台，并且您目前所拥有的酷炫新命令和图形化工具会使您的同事和用户感到眼花缭乱。在“HPC 资源”边栏中，您将会找到有关“高性能计算”的更多信息源。

John Kelbley 是 Microsoft 的技术产品经理，供职于基地位于美国东北部的“全球解决方案技术团队”。可通过 Johnkel@microsoft.com 与 John 联系。
Doug Lindsey 是 Microsoft HPC 团队的一名项目经理。他还是产品计算群集的管理员（包括 www.top500.org 上 2007 年 11 月排行榜的 #116）。可通过 Dougli@microsoft.com 与 Doug 联系。


 在线增刊: 在终端服务中部署 2007 Office System
在线增刊 James D. Silliman

在终端服务中部署 2007 Office System
概览:
  • 2007 Office system 的部署
  • 管理用户设置
  • 新的快速访问工具栏
  • 2007 Office system 的自定义工具

2007 Microsoft Office system 引入了一些重要的设计更改，在终端服务服务器场中进行部署或升级以前的版本之前必须对此有所了解。您需要熟悉全局模板、快速访问工具栏、
用于组策略的 .adm 文件管理单元以及 Office 自定义工具 (OCT)。如果您事先了解了所有这些工具，则部署过程会更加顺利。让我们从 Microsoft® Word 开始领略这些显著的变化吧。

部署 Word 2007
Word 一直以来使用的都是全局模板文件，在 2007 Office system 中，此文件名为 normal.dotm。在终端服务环境中，可采用三种不同的方法来部署 Word 和 normal.dotm 文件。您可以在所有安装了 Office 的终端服务服务器上保留该文件，这样用户将得到标准的 Word 默认视图。您可以在各终端服务器上打开该文件并自行修改、添加自定义设置，这样用户在 Word 中看到的将不是默认视图。您也可以彻底重命名此文件，这样用户可以得到自己的文件（当其在 Word 中更改设置和单击“默认”进行修改时）。
无论选用哪种方法，都最好在部署之前就决定下来。如果对原有设置不做任何改动，则用户将无法保存对全局模板所做的更改，因为终端服务服务器上的全局模板文件将覆盖其个人配置文件中的文件。如果不打开模板文件并进行调整，Word 2007 将只为用户显示其默认设置。
但是如果需要，您可以对终端服务场中每个服务器上的文件都进行调整。要采用这种途径并为每位用户维持相同的 Word 设置（如默认字体和字号、段落间距和布局），您需要将此全局模板文件保存在其默认路径位置。要修改希望对所有用户进行部署的任何设置，只需在每个终端服务计算机上打开此文件、在 Word 2007 布局中进行所需的更改（单击“默认”），然后保存这些更改并将更改写入默认的 normal.dotm 文件。
在进行任何更改之前都务必先备份默认文件，否则可能必须重新安装 Word 2007 才能取回原始文件。请注意，如果在修改 normal.dotm 文件的同时对快速访问工具栏进行更改，则这些更改将不会保存到此模板文件中。下面我将简要介绍一下快速访问工具栏及其行为。
如果想让用户能够管理其在 Word 中的全局设置，都需要做些什么？用户确实可以管理其全局设置，但需要您在场中的所有服务器上将 normal.dotm 文件重命名为 normal.dotm.old 形式的名称。建议最好使用这种方式，因为如果在其中挂接其他应用程序，则会在用户关闭 Word 时出现模板错误。
如果重命名此文件，Word 2007 会认为您希望允许用户管理其各自的首选项而不使用全局首选项，因此将允许用户修改并保存其设置。Word 2007 现在将自定义的 normal.dotm 文件保存到各个用户的配置文件路径下。如果您使用的是漫游配置文件（取决于设置路径的方式），则会将模板文件存储在各个用户的以下文件夹位置：\\domain\sharename\%username%\Application Data\Microsoft\Templates。
未存储在 normal.dotm 文件中的一个用户首选项设置就是对快速访问工具栏所做的所有更改。此工具栏是 2007 Office system 的新功能，它与主要的功能区工具栏（也是新功能）不同。快速访问工具栏是一个微型工具栏，默认位于 2007 Office system 屏幕的左上角。2007 Office system 的应用程序中包含此工具栏，如图 1 所示。请参阅 support.microsoft.com/kb/926805 了解更多信息。
Figure 1 快速访问工具栏文件 (Close Figure 1)

Office 应用程序 | 功能区 | 文件名
Access 2007 | 所有 | Access.qat
Excel 2007 | 所有 | Excel.qat
Outlook 2007 | 联系人 日历 通讯组列表 日记条目 邮件 公告 文件夹 任务 | Olkaddritem.qat Olkapptitem.qat Olkdistitem.qat Olklogitem.qat Olkmailitem.qat Olkpostitem.qat Olktaskitem.qat
PowerPoint 2007 | 所有 | PowerPoint.qat
Word 2007 | 所有 | Word.qat
如图 1 所示，快速访问工具栏使用扩展名为 .qat 的文件来存储个性化设置。这些文件保存在场内每个终端服务服务器上的以下默认文件路径位置，并且不漫游：C:\Documents and Settings\<用户名>\Local Setting\Application Data\Microsoft\Office（对于运行 Windows Vista® 的计算机，位置为 C:\Users\用户名\AppData\Local\Microsoft\Office）。
如果仔细观察该路径，您会注意到 .qat 文件位于终端服务用户的本地缓存配置文件的 Local Settings 子文件夹下。在注销时，该子文件夹不会与用户的漫游配置文件同步，因为在标准漫游配置文件路径结构中不存在 Local Settings。因此，遗憾的是，如果通过启用此组策略对象 (GPO) 设置来清除终端服务服务器上本地缓存的配置文件，则用户自定义的 .qat 文件将丢失（请参阅知识库文章 support.microsoft.com/kb/274152 了解更多信息）。
事实上，删除缓存的配置文件是终端服务管理员广为采用的一种方法，这样做是为了在用户注销时清理本地配置文件，所以 2007 Office system 中的这项更改至关重要，因为它涉及缓存的配置文件和快速访问工具栏。一种直观的解决方案是确保不设置我刚刚提到的知识库文章中讨论的 GPO 设置。如果不启用注销时删除缓存的配置文件且用户数量很多时，这些文件就会占用各终端服务服务器的本地 %systemroot% 驱动器上宝贵的硬盘空间，您还必须安装一些其他进程对此进行监视，因为服务器可能会耗尽硬盘空间。这种情况并不罕见，因为本地配置文件可能会变得非常大。
无论采用何种方法，都至少应在登录脚本中添加一个例程，定期备份用户的 .qat 文件，以便在丢失或意外删除的情况下能够进行恢复。通过保留这些自定义文件的备份，就不必频繁请求本地服务台来帮助恢复这些文件。
终端服务管理员很少备份这些本地缓存的配置文件，他们只备份网络漫游配置文件，正如我曾提到的，这种方式不会保存 .qat 文件的副本。另一种可选方案是考虑使用第三方产品为每位用户部署强制性配置文件，然后将每位用户的 Local Settings 更改映射到网络上的单独文件夹内。

组策略管理单元
近来，已为 Office 2003 提供了组策略 .adm 文件，利用它们可以更好地对 Office 策略和用户体验实施管理控制。同样，在 2007 Office system 中也提供了新的 .adm 文件来进行各种自定义设置，包括禁用“首次运行”对话框、修改“自动保存”设置及其他首选项。
如果已经部署了 Office 2003 组策略并决定改用 2007 Office system，则应首先从 GPO 中删除原有的 Office 2003 .adm 文件，然后才能添加 2007 Office system 的 .adm 文件。请记住要使用组策略管理控制台 (GPMC) 界面来备份 GPO，以便在添加新管理单元出现错误时可以进行恢复。据我所知，至少有一位终端服务管理员就曾因为删除 Office 2003 管理单元并随后向 GPO 中添加 2007 Office system 的 .adm 文件而不得不执行 ghost 策略项目。
我曾在 2007 年 5 月的文章“终端服务部署指南”(technetmagazine.com/issues/2007/05/TerminalServices) 中提到过，不应提示终端服务用户执行某些操作，如 Outlook® 自动存档或接受首次运行对话框屏幕等。要清楚，首次启动 Outlook 2007 时，默认情况下用户将看到两个首次运行屏幕：一个是“隐私选项”，另一个是“桌面搜索”。可通过以下几种方法禁用第一个屏幕（如图 2 所示）：修改 GPO 设置（使用新的 Outlook 2007 .adm 文件）、使用 Office 自定义工具或调整注册表。
图 2 2007 Office system 中的隐私选项对话框
图 2 2007 Office system 中的隐私选项对话框
“隐私选项”出现后（如果未禁用），会立即显示图 3 所示的屏幕，此屏幕还会出现在所有其他 2007 Office system 应用程序中。
图 3 2007 Office system 中的即时搜索功能对话框
图 3 2007 Office system 中的即时搜索功能对话框
要关闭 Office 应用程序的 Windows® 搜索提示，请从 go.microsoft.com/fwlink/?LinkId=78161 下载 2007 Office system ADM 模板，并将其加载到域控制器上的硬盘驱动器中。在组策略中，必须在计算机配置或用户配置、添加管理单元下加载 Office Outlook 2007 模板 (Outlk12.adm)。接下来，转到 User Configuration\Administrative Templates\Microsoft Office Outlook 2007\Tools | Options\Preferences\Search Options 并启用“禁止在 Windows 桌面搜索组件不存在时显示安装提示”设置。
2007 Office system 提供了许多组策略设置来控制用户体验，但需要在 GPO 中分别添加各自的 .adm 文件，例如各自的 Word (Word12.adm) 和 Excel® (Excel12.adm)。图 4 显示了 Outlook 2007 ADM 模板 (Outlook12.adm) 被添加到组策略后的外观示例。
图 4 组策略中的 Outlook 2007 ADM 模板
图 4 组策略中的 Outlook 2007 ADM 模板

其他更改
请注意，在 Office 2003 中，您还可以下载并使用“自定义安装向导”来创建自定义的转换。2007 Office system 中的新 OCT 不需要单独下载。在 Run 命令中使用“Setup /admin”即可启动它，它会指向您的 2007 Office system 媒体或安装源。对安装源文件执行此命令，然后根据喜好更改个人设置，从而创建一个 .msp 文件（相当于 Office 2003 中的 .mst 文件），而且您无需指定任何命令行选项即可将它包括在以后的部署中。只需将自定义的 .msp 文件放到网络安装点根目录下的 Updates 文件夹内，就可以自动按您的首选设置进行部署。
与以前版本相比，Outlook 2007 还有另一个优点，它能够自动定位 Exchange 2007 服务器，如果在 LAN 中启动，它会直接向 Active Directory® 发送服务连接点 (SCP) 查询。此查询使连接到已部署的 Exchange 2007 基础结构这一操作变得非常简单。有关详细信息，请参阅 go.microsoft.com/fwlink/?linkid=76177。
Microsoft 对 2007 Office system 在终端服务环境下的工作方式进行了一些重大的设计更改，包括简化部署工具、添加新的 .adm 文件管理单元以及简化界面等。在部署或升级 Office 应用程序之前了解本文所讨论的一些重要概念，有助于您更好地了解升级过程，还可以提前制定重要的设计决策。如果不打算现在升级，您可以考虑只加载 2007 Office system 兼容包，以便您的用户可以打开已升级用户发来的附件。您可以从 go.microsoft.com/fwlink?LinkID=77512 获得此兼容包。
掌握了此信息后，您就已经为成功部署 2007 Office system 做好了准备。请记住，在用户社区中进行部署之前，一定要先备份您的策略并在实验室环境下测试所有推荐设置。

James D. Silliman是一位 Microsoft 认证系统工程师，同时也是终端服务部署方面的 Microsoft 技术专家。他目前就职于 ASP，主要是为小型企业架构 IT 解决方案。可以通过 jsilliman@gmail.com 与他联系。


 编辑寄语: 处理信息超载
编辑寄语
处理信息超载
Joshua Hoffman

当我想到 本月的两大主题 — SharePoint 和 Office Communications Server 时，实际上对我们在彼此连接方面出现问题并不吃惊。您知道，当我撰写这篇短文时（可能在您阅读到它之前一个月左右），整个纽约市正处于休假氛围中。而此时，《TechNet 杂志》总部正位于纽约假期的中心位置：洛克菲勒中心。在许多方面它确实是个不错的城市，但是每年都有大约一个月的时间它会变成...让我们姑且将它称为挑战吧。来自全国各地以及世界各地的游客们使人口数量剧增（趋势甚至在加剧），他们去商店购物、观看展览或在宏伟的摩天大楼背景下滑冰。然而，许多纽约人却与之相反，他们匆忙撤退。
一些人争辩说这与那些游客有关，他们停在人行道中间拍照，因而跟在后面的本地人不得不停下来等侯或者会撞到他们。但其实并非如此（相反地，实际上，我们非常高兴大家的光临）。我认为问题在于超载。身处本身就已经很拥挤而繁忙的都市中，我们已经达到了临界点，而这只是由于人数过多而导致的。
明确这一点后，我发现我们的行业也存在极为相似的趋势。我们的组织规模在持续增长（可能这正是我们所希望的），因此每天产生的信息也越来越多。文件共享满了。数据库满了。电子邮件就更不用提了。就在不久前，GB 尚指很大的存储空间。但现在，TB 已很常见 — 甚至在家用 PC 中也是如此。目前，许多数据中心做规划时已使用 PB。我想我们可以认同；在这些存储场所确实有许多信息。但是，这些信息是确实有用还是仅仅让人目眩？它是否已结构化？是否易于分析？是否易于共享？
因此，在如此庞大的数据量之下，我们难以进行连接毫不奇怪。但是它可以变得轻松一些，这正是我们本月讨论的内容。在本期中，了解如何利用 SharePoint 的功能使得在企业中收集数据更加轻松且更具条理性。了解如何快速地构建调查以从用户（或客户）处收集该数据。了解如何定义自定义内容类型，以使所收集的信息更有意义。最后，了解如何利用 Office Communications Server 实现那些关键连接。毕竟，如果没有人共享，就算有所有数据又有什么好处呢？ —Joshua Hoffman

向以下 Microsoft 技术专家致以衷心的感谢：Ed Banti、Susan Bradley、Byron Hynes、Michael Murgolo、Ken Oien、Jim Truher 和 Kay Unkroth。


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

ActiveX 安装程序服务可用性
我刚刚拜读了您 2007 年 7 月发表的文章“Windows Vista 中的 ActiveX 安装程序服务”（网址为 technetmagazine.com/issues/2007/07/AxIS）。您能告诉我现在是否已经可以使用这项服务了？
—Eugene Y.

可以，现在就能使用 ActiveX® 安装程序服务了。通过 Windows Vista® 中“程序和功能”控制面板内的“打开或关闭 Windows 功能”，可以轻松启用这项服务。
“ActiveX 安装程序服务”仅是 Windows Vista Ultimate、Enterprise 和 Business 版中的一个可选组件。允许使用 ActiveX 安装程序服务安装 ActiveX 的站点列表由“组策略”控制。该列表存储在“组策略对象编辑器”的“计算机配置”|“管理模板”|“Windows 组件”|“ActiveX 安装程序服务”内。

Active Directory 工具
非常感谢“用于管理 Active Directory 的 11 个基本工具”这篇文章（2007 年 9 月）。我尝试使用文中介绍的 dsrm 这一实用工具从 Active Directory® 删除用户，我使用以下命令行：
          dsquery user -samid <samid> | dsrm
我收到了错误消息，指出 "dsrm" 的输入格式有误。但是，我分别执行各个命令时没有任何问题。您有何建议？
—Keith E.

我们将您的问题转给了该文章的作者 Laura Hunter。Laura 指出如果管道 dsquery 产生 dsrm，则 dsrm 需要 -noprompt 开关。在这种情况下，需要使用以下命令行：
dsquery user -samid <samid> | dsrm -noprompt
很抱歉在原文中忽略了此信息，我们将于在线版本中发布一项修正。

替代测验题可能性
我假定您切实认识到，或已有多人提醒您，Scripto 博士的“脚本谜题测验”（2007 年 11 月）实际上有两个同样有效的解决方案。如果在第一行和第二行出现的 4 字符变量是 nnde，以及如果在第三行和第五行出现的 5 字符变量是 iamex，谜题都可正确破译。（我同意区别是微不足道的，并且您解决方案中的名称使脚本具有更好的可读性。）
非常感谢对测验题所做的变换，我十分欣赏。
—Stan A.

衷心感谢您与我们共享您的替代解决方案，Stan！很高兴听到您说中意新的“脚本专家”测验题，我们为将其作为《TechNet 杂志》的固定专栏而备感兴奋。

Windows Vista 迁移论证
TechNet 杂志 2007 年 11 月刊的文章“Windows Vista 中脱机文件的更改”（转到 technetmagazine.com/issues/2007/11/Offline）有力地说明了 Windows Vista 在脱机文件方面的长处。它帮助我们做出了向 Windows Vista 迁移的决策，因为我们在使用 Windows® XP Professional 时遇到了许多脱机文件方面的问题。
—Daniel Z.

谢谢，Daniel！文章能对您的组织有所帮助让我们甚感欣慰。

缺页
您的杂志妙趣横生、内容丰富。但是，我手上的 2007 年 12 月刊杂志缺少 49-64 页。我对 Tom Cloward 和 Frank Simorjay 撰写的有关计算机取证的文章（“基本计算机取证指南”）十分感兴趣，它可能在第 60 页上。您负责印刷取证的团队能帮我找到缺失的页/数据吗？如果该文章有在线版本，并且您能发给我 URL，我将非常愿意在线阅读该文章。
—Dave S.

非常抱歉，我们在印刷 2007 年 12 月刊时确实出现了问题，使得邮寄给读者的少量杂志缺少第 49-64 页。在此代表我们的印刷商和 TechNet 杂志团队为由此带来的不便深表歉意。
现在，您所提到的文章及 12 月刊的其余部分可在线访问，网址为 technetmagazine.com/issues/2007/12。


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

解锁文件
Unlocker
ccollomb.free.fr/unlocker
我们都遇到过这种情况 — 某些自动化进程在操作中途挂起，并且文件写入被锁住，从而由于无法复制、移动、写入或删除文件导致另一个操作失败。有时您只是不知道谁是锁住文件的罪魁祸首，但您知道锁定的是哪个文件。您该如何处理这种情况呢？
有多种方法可供您使用，Cedrick Collomb 撰写的免费 Unlocker 工具就是其中一种，它提供的是快捷简便的 Windows® Explorer 集成解决方案，用于处理文件锁定问题。它与 Windows Explorer 集成，使您只需右键单击锁定的文件（或者是一组文件）即可从上下文菜单选择 Unlocker 来查找恶意程序。如果发现锁，您可以从多个选项中进行选择，如终止恶意进程、解锁文件（关闭句柄）、删除文件、移动文件或重命名文件。您还可以将当前状态的锁定文件复制到另一个位置。
Unlocker 有一个完整的应用程序安装程序，因此您无需手动注册或注销任何 DLL，亦无需重新启动系统即可启用该工具。它还支持自动更新通知（如果您不介意时时“接到提示”）以确保您具有最新版本。
Unlocker 甚至还支持命令行操作，这非常适用于自动操作。举例来说，这意味着如果在尝试移动日志时 .zip 文件出现锁定或者不想在凌晨起床手动解决问题，您可以轻松配置日志传送进程，让它自动关闭句柄并终止压缩进程。
实用工具还包含一个称为 Unlocker Assistant 的系统任务栏工具。这样，在您尝试移动、重命名或删除锁定文件时可自动启动 Unlocker 界面，无需单击操作即可查找文件并从右键单击出现的上下文菜单中选择 Unlocker。Unlocker 与 Windows 的大多数版本都兼容，其中包括 Windows Vista®。

价格：免费
借助 Unlocker，您可以快速找到锁定的文件并对其进行解锁。

分析网络流量
Wireshark
wireshark.org
良好的网络协议分析程序可使您掌握自身基础结构中网络流量的核心，从而了解互连应用程序的所有这些层的实际运行情况。可能大家最为熟悉的开源分析程序是 Wireshark，该程序利用开源 WinPcap 数据包捕获 Windows 库，并从 Ethereal（与 Gerald Combs 的努力密不可分）派生而来。
借助 Wireshark，您可以轻松捕获通过网络接口的流量，并在易于使用的图形界面中检查每个数据包的详细信息。只需选择界面并单击“开始”即可启动新的数据包捕获会话，就这么简单。GUI 以彩色编码帧的形式显示捕获的数据包，它会实时地详细说明事件的时间、源、目标、协议和预定描述。单击传输会突出显示详细信息，并将数据包数据解读为易于理解的详细信息窗格。在该窗格下方，您将看到以十六进制和 ASCII 编码表示的原始数据包数据。
一旦您获得执行分析所需的数据集，您自然可以保存或导出会话以供稍后分析之用。Wireshark 可以解码许多不同的协议，应该能满足大多数故障排除需求。
网络中的内容是纷繁多样的，为帮助您从所有这些数据中进行筛选，该应用程序具有基于表达式的强大筛选功能，可使您通过协议的每个参数缩小搜索范围。例如，您可以筛选出网络中除了与特定 IP 中的 BitTorrent 相关的通信之外的所有通信。或者，筛选器会使您通过阻隔大量虚假广播消息轻松找出造成网络严重破坏的计算机。
界面还使您可以轻松标记数据包以备审核，并根据捕获中的时间参考设置具体传输。Wireshark 让我着迷的一项功能是，右键单击 TCP 数据包后，在出现的上下文菜单上选择适当选项即可跟踪 TCP 流。此操作将调出一个窗口，其中包含 TCP 流内容的彩色编码格式化文本视图，它非常适用于检测 Web 应用程序错误、虚假 HTTP 标头或者您可能遇到的其他 TCP 通信问题。此时，您可以快速打印或保存会话以供稍后检查或演示之用。
我只是简要介绍了应用程序的功能。Wireshark 发布时带有 GPL 许可证，除了适用于 Windows 外，它还为大多数 Linux 和 FreeBSD 版本编译了二进制文件。

价格：免费
Wireshark 使您可以分析完整的网络协议

增强 Windows PowerShell
PowerShell Community Extensions
codeplex.com/PowerShellCX
如果曾经实际使用过 Windows PowerShellTM，您很可能已经注意到有几种执行循环模式在包含 cmdlet 或别名时效果最好。为此，一组来自开源社区的 Windows PowerShell 用户和倡导者创建了 PowerShell Community Extensions 项目，从而将通常请求的功能打包为一组可分发的 cmdlet、别名、提供程序、函数、筛选器和脚本。
数据包中包含的 cmdlet 有 Get-Clipboard 和 Write-Clipboard，通过这两个 cmdlet，您可以添加和检索剪贴板缓冲区中的数据。同时，Get-DomainController 可检索当前域中可用域控制器的列表，而 Write-GZip 和 Write-Zip 使您能够编写 GZIP 或 ZIP 文件。
您可以分别使用 New-Symlink 和 New-Junction 在 Windows Vista 或 Windows Server® 2008 中创建一个新的符号链接或接合点。DirectoryServices 是一个很有用的提供程序，该程序使您可以访问 LDAP 服务器（如 Active Directory® 和 AssemblyCache），从而允许您访问 Microsoft .NET Framework 全局程序集缓存及其内部的程序集。
此外还有许多很好的脚本。Set-Writable 和 Set-ReadOnly 脚本使您可以快速更改文件的只读状态。Get-Url 可生成 WebRequest 并将 WebResponse 作为一个字符串返回，Export-History 可将您的命令历史记录转储为一个 .clixml 文件以供稍后重用。您可以使用 Get-DiskUsage 脚本获得磁盘使用情况信息，甚至您还可以使用有趣的 Out-Speech 命令使计算机“开口说话”。数据包还包括大量其他很有用的函数，如 Quote-List 和 Add-PathVariable，前者可以减少命令行的键入，后者可以向指定的环境添加一组路径。
该项目可将一组非常有用的扩展功能添加到标准 Windows PowerShell 环境中。如果您恰巧是一位 Windows PowerShell 专家，我确信该项目将有助于您做出更大贡献。

价格：免费
PowerShell Community Extension 可提供通常请求的功能
PowerShell Community Extension 可提供通常请求的功能

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


 SQL 问题与解答: 非群集索引和保留权限
SQL 问题与解答
非群集索引和保留权限
Saleem Hakani and Dan Carollo

非群集索引及使用方法
问：什么是非群集索引？使用它们都有什么优缺点？
答：非群集索引与通常位于书籍最后部分的索引非常相似。书籍中包含的所有信息都在索引中以主题的形式表示，并以页码作为指针来指示该信息在书籍中的位置，可能多个地方都包含此信息。此外，书籍索引中的数据与书籍正文内容出现的顺序并不相同。这一点与非群集索引相同。如果为某个表建立了群集索引，则可以指定表中项目的顺序。否则，将无法确定其排列顺序。
此外，非群集索引有两方面的局限性：索引中只能包括 16 列且索引键最大字节数不得超过 900。这意味着什么？让我们以 MovieList 示例数据库中的 Movie 表为例，看看如果希望对以下各列创建索引会出现什么情况：MovieTitle NVarchar(50)、DirectorName NVarchar(50)、ShortStory NVarchar(400)。
假设提交以下语句创建该表：
Use MovieList;
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName, ShortStory);
这将会提示以下错误消息：“警告！最大键长度为 900 个字节。索引 'Movie_IDX' 的最大长度为 1000 个字节。对于某些较大值的组合，插入/更新操作将失败”。您之所以收到上面的错误消息，是因为“nvarchar”数据类型中每个字符占 2 个字节，包含前面所述三列的索引将超过 900 字节大小的限制。
使用 SQL Server® 2005 版，您现在可以通过将这些列添加到 INCLUDE 语句来解决这一问题。如果希望同时解决大小和列数限制，这将是一项非常有用的功能。可以通过执行以下语句来实现此目的：
CREATE INDEX Movie_IDX ON Movie(MovieTitle, DirectorName) INCLUDE (ShortStory);
必须注意，在创建索引过程中使用 INCLUDE 语句时，数据库引擎在计算索引键列数或索引键字符大小时不会考虑非键列。
要了解有关非群集索引的更多有用信息，请参阅 msdn2.microsoft.com/aa174537 中的“非群集索引”和 msdn2.microsoft.com/aa933130 中的“使用非群集索引”。要获得有关优化索引的提示，请参阅 sql-server-performance.com/optimizing_ indexes.asp。

保留权限数据
问：在重新初始化订阅时，如何才能避免丢失权限？我已多次遇到这一问题：在重新初始化快照时，所有已授予的权限都会丢失。
答：默认情况下，只要重新初始化订阅，订阅数据库中的所有对象都将被删除然后再重新创建。不过，有两种方法可解决此问题。
第一种方法是在重新初始化后重新应用所有权限。在手动设置好权限后，应使用脚本导出所有对象/语句级权限并将其单独保存，这样在重新初始化订阅后，您即可立即使用它们。
第二种方法是对订阅进行配置，使其在重新初始化订阅时不删除任何对象。为此您可以使用 SP_CHANGEARTICLE 系统存储过程来配置参数 @PROPERTY 的 PRE_CREATION_CMD 值，以及参数 @Value 的 NONE、DELETE 或 TRUNCATE 值。
同时，在目标对象部分的“项目属性”对话框中，选择“保持现有对象不变，删除数据”。“如果文章有行筛选器，则仅删除与筛选器匹配的内容”。“清空现有对象中的所有数据”。请务必先在测试环境下对此方法进行测试，如果需要更多帮助，请查看最新版的 SQL Server 联机丛书来了解最新信息。

Saleem Hakani 是一名高级数据库工程师、高级问题解决工程师和全球 Microsoft SQL Server 社区负责人，拥有 14 年的数据库系统经验。他负责外部 SQL Server 社区网站 sqlcommunity.com，您可以通过 Saleem@sqlcommunity.com 与他联系。
Dan Carollo 是一名运营工程师和 SQL Server DBA，他在 Microsoft 与 Windows 反恶意软件研究和响应团队合作。他拥有 SQL Server 的 MCT 证书。


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

对于那些 使用组策略的人而言，他们自然非常熟悉如何使用管理模板来配置操作系统和应用程序设置。随 Windows® 和一些关键软件（如 Microsoft® Office）提供的 ADM 文件涵盖了大部分常见的桌面配置。但是，有时您必须创建自己的 ADM 模板以合并自定义设置。从头开始设计 ADM 可能会很繁琐，因为它们有自身独特的语法，并需要使用文本编辑器进行构建。但是在经过一段时间并取得一些经验后，许多组策略专家都已非常擅长雕琢他们自己的 ADM 文件了。
在 Windows Vista® 中，Microsoft 已将组策略模板的格式改为基于 XML 的结构。这种新格式被称为 ADMX，与原有的 ADM 文件相比，新格式具有许多优点，如多语言支持、可在中心存储点管理所有模板等。
这的确是个好消息，但如果您想创建自己的 ADMX 文件却又不了解 XML，该怎么办呢？更为重要的是，该如何处理那些花费多年心血创建的自定义 ADM 呢？幸运的是，有 ADMX Migrator 实用工具前来解围。这是一款免费的工具，由 FullArmor Corporation 开发并授权给 Microsoft，它有两大优势：可以让您创建自己的自定义 ADMX 文件，还可以将原有的 ADM 文件转换为 ADMX。
ADMX Migrator 图形界面
ADMX Migrator 图形界面
为了使用新格式创建模板，ADMX Migrator 提供了 ADMX 编辑器，它具有图形用户界面，无需再使用其他文字编辑器。您可以在简洁明了的界面中使用下拉菜单和下拉列表构建自己的模板（参见图例）。要开始创建，请选择“New Template”（新建模板）命令，然后命名模板文件并输入一个类别作为文件分类依据。接下来通过输入策略要应用的注册表项、注册表值的名称以及它将影响的类别（用户、机器或两者）来创建实际的策略设置。您还可以对策略的作用加以说明。
完成后，将新模板保存为 ADMX 格式。它将同时存储为 ADMX 和 ADML 这两种文件类型。ADMX 文件包含实际的策略设置，ADML 文件为策略提供特定语言的信息。您现在即可将这两个文件复制到域中的适当目录下并将其合并到组策略中。
您很可能会希望将 ADM 文件转换为 ADMX 以利用新格式的优势。ADMX Migrator 提供两种转换方法：通过编辑器或通过命令行程序。在 ADMX Editor 中，选择从 ADM 生成 ADMX 的选项。浏览到您的 ADM 文件，此工具会马上自动进行转换。然后您可以在编辑器中打开转换后的文件，对它的值和属性进行检查并根据需要加以修改。ADMX Migrator 命令窗口稍微有些复杂；它需要您在命令提示符下键入一长串命令字符串才能执行转换。但是，它包括一些图形编辑器中所不具有的选项和灵活性。
ADMX Migrator 属于 Microsoft 管理控制台 (MMC) 管理单元，因此它需要 MMC 3.0 和 Microsoft .NET Framework 2.0。ADMX Migrator 可在 Windows XP SP2、Windows Server® 2003 SP1 以及 Windows Vista 环境下运行。您可以从 go.microsoft.com/fwlink/?LinkId=77409 下载此软件。

Lance Whitney 是一位 IT 顾问、培训师和技术撰稿人。他投入了很多的时间和精力来改进 Windows 工作站和服务器。15 年前，记者出身的 Lance 开始涉足 IT 世界。


 网络专家: IEEE 802.1X 有线身份验证
网络专家
IEEE 802.1X 有线身份验证
Joseph Davies
本文基于 Windows Server 2008 的预发布版。文中的详细信息均可能会有所变更。

随着 IEEE 802.11 无线网络 IEEE 802.1X 身份验证的普及，网络管理员也想将此标准用于其有线网络。就像无线客户端在允许向 Intranet 转发无线帧之前必须提交一系列凭据一样，
IEEE 802.1X 有线客户端在使用其交换机端口前也必须执行身份验证。IEEE 802.1X 为 Intranet 访问提供了一层额外的安全保障 — 您可以防止未通过身份验证的来宾、未授权或非管理的计算机连接到 Intranet。
可能您的有线交换机已经支持 IEEE 802.1X 身份验证，只需启用并配置即可。对于有线连接的身份验证和授权，启用 802.1X 的交换机通常使用远程身份验证拨号用户服务 (RADIUS) 协议向 RADIUS 服务器发送连接请求，如基于 Windows Server® 2008 的网络策略服务器 (NPS) 或 Windows Server 2003 Internet 身份验证服务 (IAS) 服务器。
在您针对 RADIUS 对交换机进行配置之后，若需要进行 802.1X 身份验证，还必须在您的有线计算机上启用并配置 802.1X 身份验证。自 Windows XP 后，Microsoft® Windows® 中就开始支持有线网络连接的 IEEE 802.1X 身份验证。但是，您必须在每台有线客户端的 Windows XP 和 Windows Server 2003 中手动配置 802.1X 身份验证设置（在 Network Connections 文件夹中网络连接属性的“身份验证”选项卡中）。遗憾的是，现在还不能集中为那些早期版本的操作系统配置有线 802.1X 设置或为其编写脚本。
幸运的是，Windows Vista® 和 Windows Server 2008 中的“组策略”支持有线设置，并且可使用 Netsh 工具编写脚本，这使 802.1X 有线设置的部署变得比以前更为简单。

组策略中的有线网络设置
使用有线自动配置服务
在 Windows XP 和 Windows Server 2003 中，有线连接的 802.1X 行为由“无线零配置”服务控制。在这些操作系统中，此服务默认为启用并将有线网络连接置于被动侦听模式，等候交换机启动身份验证。
反之，在 Windows Vista 和 Windows Server 2008 中，“有线自动配置”服务控制有线连接的 802.1X 行为，但默认处于禁用状态。因此，只有先启动“有线自动配置”服务，才会显示网络连接属性的“身份验证”选项卡。
对于运行 Windows Vista 或 Windows Server 2008 的单个有线客户端，您可使用“服务”管理单元启动“有线自动配置”服务并将其配置为自动启动。启动“有线自动配置”服务后，有线网络连接在活动侦听模式下运作，在此模式下，网络连接试图用交换机启动身份验证。
在 Active Directory 域中，您可使用“组策略”配置“有线自动配置”服务以实现自动启动。使用“组策略管理编辑器”管理单元，可配置“计算机配置”|“Windows 设置”|“安全设置”|“系统服务”|“有线自动配置”，从而设定自动启动模式。

为集中自动配置有线网络设置，Windows Server 2008 和 Windows Server 2003 Active Directory® 域服务支持组策略中的有线策略设置。您可以使用这些设置配置有线网络设置，使其成为基于域的组策略对象的计算机配置组策略内容。
通过这些有线策略设置，您可为运行 Windows Server 2008 或 Windows Vista 的有线客户端指定身份验证方法和其他 802.1X 设置。加入域后，这些操作系统会在启动时或在启动后定期自动下载并应用有线组策略设置。仅有一点需要注意，即必须扩展 Windows Server 2003 Active Directory 域来支持这些新策略。有关如何扩展 Windows Server 2003 Active Directory 域的信息，请访问 technet.microsoft.com/bb727029。
您可以在“组策略管理编辑器”管理单元的“计算机配置”|“Windows 设置”|“安全设置”|“有线网络 (IEEE 802.3) 策略”节点内配置有线策略。默认情况下并不存在有线网络 (IEEE 802.3) 策略。要创建新策略，请右键单击控制台树中的“有线网络 (IEEE 802.3) 策略”，然后单击“创建一个新 Windows Vista 策略”。
Windows Vista 有线策略的属性对话框包含“常规”和“安全”两个选项卡。图 1 显示了默认“常规”选项卡。在“常规”选项卡上，您可以配置策略的名称和说明，并指定是否使用有线自动配置服务，该服务控制有线连接的 802.1X 行为。有关详细信息，请参阅本专栏的“使用有线自动配置服务”边栏。
图 1 Windows Vista 有线策略的默认“常规”选项卡
图 1 Windows Vista 有线策略的默认“常规”选项卡
图 2 显示了 Windows Vista 有线策略的默认“安全”选项卡。在“安全”选项卡上，您可以启用或禁用 802.1X 身份验证、选择并配置“可扩展身份验证协议 (EAP)”身份验证方法、选择身份验证模式（用户重新身份验证、仅限计算机、用户身份验证或来宾身份验证）、配置在放弃身份验证前允许其尝试失败的次数，并配置是否为后续连接缓存用户信息。如禁用缓存，Windows 会在用户注销后从注册表删除用户凭据数据。这样，当下一个用户登录时，系统将提示他们出示其凭据（如用户名和密码）。
图 2 Windows Vista 有线策略的默认“安全”选项卡
图 2 Windows Vista 有线策略的默认“安全”选项卡
单击“安全”选项卡上的“高级”按钮，可为 802.1X 或单一登录配置高级设置。图 3 显示了 Windows Vista 有线策略的默认“高级”安全设置对话框。在该对话框中，您可以配置 802.1X 设置，如图 4 所示。
Figure 4 “高级”安全设置对话框中的 802.1X 设置 (Close Figure 4)

设置 | 说明
最大 EAPOL-Start 消息数 | 在没有收到对初始 EAPOL-Start 消息的响应时，连续发出的 EAP over LAN (EAPOL)-Start 消息的数量。
保持时间 | 在没有收到对先前发出的 EAPOL-Start 消息的响应时，重新传送 EAPOL-Start 消息的时间间隔。
启动时间 | 身份验证客户端在接收到来自身份验证方的失败指示后，不执行任何 802.1X 身份验证活动的时间。
身份验证时间 | 身份验证客户端在开始端到端 802.1X 身份验证之后重新传送任何 802.1X 请求之前所等待的时间。
EAPOL-Start 消息 | 有线客户端发送的 EAPOL-Start 消息。
图 3 Windows Vista 有线策略的默认“高级”安全设置对话框
图 3 Windows Vista 有线策略的默认“高级”安全设置对话框
运行 Windows Server 2008 的有线客户端支持有线连接的单一登录特性。Windows Vista Service Pack 1 即将发布的新版本也计划包含此功能，请在线查看 technetmagazine.com/issues/2007/11/CableGuy 了解详细信息。
“单一登录”设置可用于在用户登录前后执行用户级 802.1X 身份验证，并在开始用户登录前等候配置的秒数，直到用户级 802.1X 身份验证完成。您可以确定除了合并 Windows 登录屏幕的输入字段，是否还显示用户级身份验证对话框。例如，如果 EAP 类型希望用户确认在身份验证过程中从 RADIUS 服务器发送的证书，EAP 类型可显示该对话框。
此外，您还可以指定在执行用户级身份验证后，系统启动有线适配器 TCP/IP 配置的动态主机配置协议 (DHCP) 续订。如果计算机级和用户级身份验证的有线客户端使用不同的虚拟 LAN (VLAN)，并且这些 VLAN 属于不同的 IPv4 或 IPv6 子网，请选择此选项。

支持使用 Netsh 工具编写脚本
Windows Server 2008 和 Windows Vista 支持 Netsh 工具 netsh lan 上下文中的命令，以便配置有线设置或导出/导入有线配置文件（它是一组已命名的 XML 格式有线设置）。通过有线设置的命令行配置，您可在不使用组策略的情况下创建有线设置的自动脚本，从而更轻松地部署有线网络。“有线网络 (IEEE 802.3) 策略组策略”设置仅在 Active Directory 域内适用。对于没有组策略基础结构的环境，可以手动或自动运行用于自动化通过有线配置文件配置有线连接的过程的脚本（登录脚本的一部分）。
要对运行 Windows Vista 或 Windows Server 2008 的有线客户端执行命令行配置，请使用合适的参数运行 netsh lan 命令。例如，以下命令可为名为“本地连接”的网络连接启用“单一登录”，并对“单一登录”进行配置以在用户登录前执行用户身份验证：
netsh lan set profileparameter interface="Local Area Connection" ssomode=prelogon
有关 netsh lan 命令语法的详细信息，请访问 technet.microsoft.com/aa905084。
可从 Windows Server 2008 或 Windows Vista 有线客户端导出有线 XML 配置文件，然后使用 Netsh 工具将其导入 Windows Server 2008 或 Windows Vista 有线客户端。要导出有线配置文件，请使用 netsh lan 导出配置文件命令。如果想导入有线配置文件，请使用 netsh lan 添加配置文件命令。有关有线配置文件的有用示例，请访问 msdn2.microsoft.com/aa816372。
在命令行和 XML 配置文件的支持下，您可在组织的经 802.1X 验证的有线网络中启动有线客户端。如果有线客户端计算机不是域的成员，则无法使用计算机凭据连接有线网络。此外，计算机只有成功连接有线网络后才能加入域。不过，在命令行和 XML 配置文件的支持下，有线计算机可以使用用户凭据连接到组织的有线网络，然后将计算机加入域。有关详细信息，请访问 technet.microsoft.com/bb727031。

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


 Windows PowerShell: Shell 权限
Windows PowerShell
Shell 权限
Don Jones
下载这篇文章的代码: PowerShell2008_02.exe (151KB)

在讨论 Windows PowerShell 时，最常见的问题就是有关权限的问题，特别是外壳程序是否会自动更改权限以及如何更改。尽管目录和注册表权限也会经常出现，但文件权限可能是最常提及的问题。当涉及权限和几乎
所有命令行或脚本界面（包括 Windows PowerShellTM 和 VBScript）的问题时，我这里既有好消息，也有坏消息。
坏消息是在 Windows® 中，权限天生就很复杂，Windows PowerShell 在这方面的能力也非常有限。这个问题的根源在于在 Windows 操作系统中，出现权限问题时都会涉及多个对象，无论是在文件系统、Active Directory®、注册表还是任何其他位置，情况都是如此。
首先是资源本身，例如，目录对象、文件或文件夹。接下来是附加到资源的“访问控制列表”(ACL) 对象。ACL 由一个或多个“访问控制项”对象即 ACE 对象组成。ACE 本质上是将安全主体（用户或组，同时也是另一种对象）与权限（如读取或完全控制）和允许或拒绝状态联系在一起的一个对象。所以至少包括五种对象：资源、ACL、ACE、主体以及权限。
每种类型的资源对应的权限类型也各不相同，这就使得权限问题变得更为复杂。例如，目录对象包含管理访问单个对象属性的复杂权限。比较而言，文件权限要相对简单一些。
而且从技术来说，当涉及到审核时，复杂性将成倍增加。每个资源实际上有两个 ACL。第一个是“自由访问控制列表”(DACL)，它负责管理对资源的访问。第二个是“安全访问控制列表”(SACL)，它负责控制对资源的审核。操作这些权限意味着需要处理一大堆相当复杂的编程对象，而只有类似 Windows PowerShell 这样的外壳程序可以简化这个复杂的过程。

受限于 .NET Framework
尚未得到足够信息？
要获得更多 Windows PowerShell 资源，包括提供搜索功能的 cmdlet 库以及 Don Jones 和其他 Windows PowerShell 专家的联系方式，请访问 www.PowerShellCommunity.org。

Windows PowerShell 的特性使问题变得更为复杂。Windows PowerShell 是在 Microsoft® .NET Framework 的基础上构建的，它使用 .NET Framework 的基础类来表示和处理权限。这些 .NET Framework 基础类旨在为软件开发人员提供更加精细准确的权限控制。当然，“精细准确”含义甚广，而且通常意味着“非常复杂”。
此外，.NET Framework 并没有在每种 Windows 资源类型中都提供代表其权限的类。例如，虽然 .NET Framework 提供了操作文件安全性的类，但它却未提供操作共享文件夹安全性的类。由此可知，Windows PowerShell 并不能操作每种类型的 Windows 资源的权限。简单地说，Windows PowerShell 的功能受限于 .NET Framework 所提供的能力。

外壳程序中的权限
Windows PowerShell 中的权限管理由两个 cmdlet 派生而来：Get-ACL 和 Set-ACL。如您所料，Get-ACL 从资源中检索 ACL。然后您就可以根据需要修改 ACL 并使用 Set-ACL 将其写回到资源中。这两个 cmdlet 都是通用 cmdlet，而且都依赖于 PSDrive 提供程序的 Windows PowerShell 系统。因此从理论上说，只要 PSDrive 提供程序具备理解给定资源类型的能力和修改此类资源权限的能力，那么这两个 ACL cmdlet 就可以操作任何类型的资源。Windows PowerShell 中包含的 FileSystem 和 Registry PSDrive 提供程序支持通过这两个 ACL cmdlet 进行权限管理。（其他 PSDrive 提供程序可能不支持。）
图 1 所示的示例脚本能够指定开始目录、安全主体和权限。然后，脚本会将为该主体指定的权限应用到指定目录中的所有文件和文件夹。该脚本还将对子目录执行递归操作。
Figure 1 将主体权限应用到目录中的文件和文件夹 (Close Figure 1)
#ChangeACL.ps1
$Right="FullControl"

#The possible values for Rights are
# ListDirectory, ReadData, WriteData
# CreateFiles, CreateDirectories, AppendData
# ReadExtendedAttributes, WriteExtendedAttributes, Traverse
# ExecuteFile, DeleteSubdirectoriesAndFiles, ReadAttributes
# WriteAttributes, Write, Delete
# ReadPermissions, Read, ReadAndExecute
# Modify, ChangePermissions, TakeOwnership
# Synchronize, FullControl

$StartingDir=Read-Host "What directory do you want to start at?"
$Principal=Read-Host "What security principal do you want to grant" `
"$Right to? `n Use format domain\username or domain\group"

#define a new access rule.
#note that the $rule line has been artificially broken for print purposes.
#it needs to be one line. the online version of the script is properly
#formatted.
$rule=new-object System.Security.AccessControl.FileSystemAccessRule
($Principal,$Right,"Allow")

foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  $acl=get-acl $file.FullName

  #Add this access rule to the ACL
  $acl.SetAccessRule($rule)

  #Write the changes to the object
  set-acl $File.Fullname $acl
  }
该脚本的实质在于它在变量 $rule 中定义了新的访问规则。为此，我将使用一个“原始”的 .NET Framework 类，它可能是 Windows PowerShell 权限管理中最复杂的部分。该脚本随后使用 Get-ACL 依次检索每个文件和文件夹中的 ACL、使用 ACL 的 SetAccessRule 方法应用新规则，并使用 Set-ACL 将修改后的 ACL 写回到资源中。
实际上，尽管包含许多类似从 ACL 删除 ACE 这样相对复杂的操作，但脚本并不复杂。依我所见，使脚本看上去比较复杂的原因是它包含了太多的步骤：获取 ACL、定义规则、修改 ACL 及写入 ACL。单独一条命令无法一次完成所有任务。并且由于我希望修改多个文件中的 ACL，所以不得不将所有内容都放在一个 foreach 循环中，而使用 Get-ChildItem 来实际访问所有的文件和文件夹。

我将采用最简单的方式
本月 Cmdlet：Get-QADUser
如果您打算管理 Active Directory，那么这个 cmdlet 是必备工具。它没有内置在 Windows PowerShell 中，但它作为 Quest Software 软件中 ActiveRoles Management Shell for Active Directory (www.quest.com/activeroles-server/arms.aspx) 的一部分提供了免费下载。
安装了该管理单元后，您就可以使用 Get-QADUser 从目录中检索用户对象。当然，只要直接运行该 cmdlet 就可以返回所有用户，但这对大多数管理任务来说帮助并不大。但是 cmdlet 允许您指定筛选条件，在域控制器上应用这些条件就可以只将您所关注的用户返回给 Windows PowerShell。使用这种技术比先获得所有用户然后再使用 Where-Object cmdlet 进行筛选要快得多。例如，Get-QADUser -l Redmond 只返回属性“l”包含“Redmond”的用户。（顺便说一下，属性“l”代表位置，在 GUI 中是城市列表。）您可以通过管道将这些用户传入其他 cmdlet 以生成 HTML 报告、将其分配给某个组甚至可以直接将其删除。

我认为我举的这个例子并不复杂，但我知道许多管理员喜欢用更为简便的方法来处理权限。也许他们希望一次性从一组文件夹中删除特定的用户组，而不希望编写类似图 1 中所示的多步骤脚本。
幸运的是，Windows PowerShell 确实提供了一种处理权限的简单方法，而且您可能已经很熟悉这种方法了。
Windows PowerShell 不会让您放弃既有的可靠处理方法。您仍然可以使用为简化处理不同类型的权限而专门设计的各种命令行工具，如 Dsacls.exe、Cacls.exe 和 Xcacls.exe。虽然其语法与 Windows PowerShell cmdlet 所使用的标准化语法完全不同，但这些命令行实用工具不需要继续在命令行模式下使用与原来在 cmd.exe 解释器中类似的特定方法运行。您可以使用 Windows PowerShell 来自动化这些实用工具。
我曾遇到过一些人（我称其为“纯粹主义者”），他们坚持认为在 Windows PowerShell 中使用老式命令行实用工具是不合适的。我不太赞同他们的逻辑。我的目的就是完成工作，如果最简单的途径是使用一个 10 年前的命令行实用工具，那我肯定会使用。我可不会仅仅为了显得“更纯粹”而多花时间试图以特定的方法完成工作。Microsoft Windows PowerShell 团队也持有类似的观点。如果现有的工具能够完成工作，Windows PowerShell 就允许您在外壳程序中运行该工具。何必要从头开始呢？
图 2 显示了一小段摘自我写的《Windows PowerShell:TFM》(SAPIEN Press, 2006) 中的脚本，它使用 Windows PowerShell 来自动执行 Cacls.exe。此脚本只是一段演示代码，如果您希望使其成为真正的自动化工具，那还需要进行调整。但它确实演示了 Windows PowerShell 脚本收集信息并用其启动 Cacls.exe 的过程，就好像 Cacls.exe 是一个原生 Windows PowerShell 命令一样。（尽管此脚本通过提示用户输入来收集信息，但它也可以从文件或数据库中读取参数。）
Figure 2 自动执行 Cacls.exe (Close Figure 2)
#SetPermsWithCACLS.ps1
# CACLS rights are usually
# F = FullControl
# C = Change
# R = Readonly
# W = Write

$StartingDir=Read-Host "What directory do you want to start at?"
$Right=Read-Host "What CACLS right do you want to grant? Valid choices are F, C, R or W"
Switch ($Right) {
  "F" {$Null}
  "C" {$Null}
  "R" {$Null}
  "W" {$Null}
  default {
    Write-Host -foregroundcolor "Red" `
    `n $Right.ToUpper() " is an invalid choice. Please Try again."`n
    exit
  }
}

$Principal=Read-Host "What security principal do you want to grant?" `
"CACLS right"$Right.ToUpper()"to?" `n `
"Use format domain\username or domain\group"

$Verify=Read-Host `n "You are about to change permissions on all" `
"files starting at"$StartingDir.ToUpper() `n "for security"`
"principal"$Principal.ToUpper() `
"with new right of"$Right.ToUpper()"."`n `
"Do you want to continue? [Y,N]"

if ($Verify -eq "Y") {

 foreach ($file in $(Get-ChildItem $StartingDir -recurse)) {
  #display filename and old permissions
  write-Host -foregroundcolor Yellow $file.FullName
  #uncomment if you want to see old permissions
  #CACLS $file.FullName

  #ADD new permission with CACLS
  CACLS $file.FullName /E /P "${Principal}:${Right}" >$NULL

  #display new permissions
  Write-Host -foregroundcolor Green "New Permissions"
  CACLS $file.FullName
 }
}

已经了解了权限问题？
听说曾有人争论过 Windows PowerShell 在处理权限问题方面存在缺陷，因为它没有提供能够对权限进行简单、通用管理的原生 cmdlet。我不同意这种说法。首先，这种说法通常来自具有很深的 UNIX 背景的管理员，而且事实上 Windows 权限系统要远比 UNIX 使用的复杂。正是由于系统的复杂性使得 Windows PowerShell 也变得很复杂。但这并不是 Windows PowerShell 的问题。
另外，Windows PowerShell 实际上允许您利用已有的优秀命令行实用工具来使用一些简化的工具，正如我在文中展示的那样。确实，.NET Framework 需要加以扩展才可以对整个 Windows 平台进行更全面的权限管理。但总的说来，Windows PowerShell 能够为您提供两方面的便利：简化的权限管理和对精细而准确的管理工具的访问。

Don Jones 是《TechNet 杂志》的特约编辑，并且是《Windows PowerShell:TFM》(SAPIEN Press, 2007) 的合著者。他主要讲授 Windows PowerShell（请参阅 www.ScriptingTraining.com），可通过 www.ScriptingAnswers.com 网站与其联系。


 您好，脚本专家！: 比赛已经开始了！对了，还有一些 XML 也登场了。
您好，脚本专家！
比赛已经开始了！对了，还有一些 XML 也登场了。
The Microsoft Scripting Guys
下载这篇文章的代码: HeyScriptingGuy2008_02.exe (151KB)

您知道， 每当人们谈论体坛传奇人物时，肯定都会提到以下名字：Babe Ruth、Pele、Muhammad Ali、Walter Payton、ScooterK 和 MrRat、Johnny—
哈，太有趣了，您...哦，您是认真的？您真的不知道 ScooterK 和 MrRat 是谁？好吧，显然不关注冬季脚本编写比赛（2 月 15 日到 3 月 3 日在 TechNet 脚本中心举办，请访问 microsoft.com/technet/scriptcenter/funzone/games）的人们，ScooterK 和 MrRat 是真正的传奇人物，他们是 2007 冬季脚本编写比赛的参赛选手，并在至少一个小组夺得了完美分数。
并且非常酷的是：您是否真的期望成为像 Pele 那样的足坛传奇人物？可能不会。您是否曾经期望成为世界重量级拳击冠军？是的，一些脚本专家似乎已接近重量级，但距离拳击冠军的宝座还相去甚远。但是您 — 对，就是您 — 可以非常轻松地成为下一个 ScooterK 或下一个 MrRat。
注意：从理论上来讲，您也可能成为下一个 Babe Ruth。只需能在棒球连赛的两场比赛之间一口气吃下 24 支热狗即可。
请放宽心；我们将告诉您如何能成为下一个 ScooterK 或 MrRat（甚至可能是下一个 Bizzy 或 H2Data）。您所需要做的只是现身脚本中心并参加脚本编写比赛。在 2 月 15 日，我们将公布 10 个不同的比赛项目（10 项脚本编写挑战），并且要求您完成其中的任意或所有项目。编写脚本来解决我们所提出的问题，并通过电子邮件将它发送给脚本专家。（可在脚本编写比赛主页找到完整的说明。）我们将对您的脚本进行测试，如果它确实起作用，我们会奖励您积分。如果成功地完成所有 10 个比赛项目，您也将成为体坛传奇人物。或者至少是脚本编写领域中的传奇人物，这也差不多是一回事。
脚本编写比赛（从 2 月 15 日到 3 月 3 日）趣味横生且极具挑战性。其中最大的好处是，所有人都可以参加脚本编写比赛。您在某种程度上仍是系统管理脚本编写方面的新手吗？那么，请进入初学者组；我们将提供单独针对 VBScript、Windows PowerShellTM 和（本年度新增比赛项目）Perl 初学者竞赛题目。您认为初学者赛区的题目有些简单？那么就试试高级组，其中的竞赛题目同样涉及 VBScript、Windows PowerShell 和 Perl。
比赛（我们是否提到过举办时间是从 2 月 15 日到 3 月 3 日？）的中心内容是脚本编写，您肯定不想错过它们。现在，请访问脚本中心主页了解有关竞赛培训的提示和技巧，然后在 2 月 15 日我们正式开始比赛时再回来。
再重复一遍时间：2 月 15 日到 3 月 3 日。切勿错过。
那是什么？实际上，我们同意您的观点：还有整整一个月的时间，现在就推出新的“您好，脚本专家！”专栏来重点宣告脚本编写比赛可能有些气势过胜。然而，为了令 TechNet 杂志的忠诚读者高兴（我们从不动摇的主要目标），我们决定无论如何顶着风险推出新专栏。
正好在一年前（哇，真的有那么久了吗？），我们发布了一个专栏来说明如何使用脚本读取 XML 文件。该专栏并未告知您如何使用脚本来创建、编写和修改 XML 文件。本月，我们将补上这部分内容。您说希望了解如何编写可创建 XML 文件的脚本？只需提问即可。嗯，提问然后等一年，以便我们解决此问题。图 1 显示了该脚本。无可否认，它可能看起来比较复杂，但我们会解释其原理。
Figure 1 创建 XML 文件 (Close Figure 1)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName

Set objDate = _
  xmlDoc.createElement("AuditDate")
objDate.Text = Date
objRecord.appendChild objDate

Set objIntro = _
  xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)

xmlDoc.Save "C:\Scripts\Audits.xml"
首先，创建一个 Microsoft.XMLDOM 对象实例。您可能已经猜到，这就是使我们能够使用 XML 文件的对象。我们的目标是生成一个如图 2 所示的简单的 XML 文件。
图 2 我们的目标：一个简单的 XML 文件
图 2 我们的目标：一个简单的 XML 文件
要创建该 XML 文件，我们首先要做的就是创建根节点 (ITChecklist)。如何实现呢？如下所示：
Set objRoot = _
  xmlDoc.createElement("ITChecklist")
xmlDoc.appendChild objRoot
非常简单，不是吗？我们仅需调用 createElement 方法，将希望指定给根节点的名称传递给 createElement。然后，只需调用 appendChild 方法，将对新元素 (objRoot) 的对象引用作为唯一的方法参数进行传递。此时，我们已有了自己的根节点。
不过，请等一下，还有其他内容。接下来创建 ComputerAudit 节点，它是 ITChecklist 节点的子节点，代表单台计算机的信息。正如您所看到的，创建该节点的代码与创建根节点的代码类似：
Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord
唯一的区别在于：创建根节点时，是在 XML 文档自身上调用的 appendChild。（请注意对象引用 xmlDoc。）为向根添加新的子节点，我们要在根节点 (objRoot) 而非 XML 文档上调用 appendChild。就是这么简单。
将 ComputerName 和 AuditDate 节点添加为 ComputerAudit 的子节点同样简单。为此，我们将执行一个类似的过程：调用 createElement 创建新节点，然后调用 appendChild 将此新节点添加至文件。
（快速问答：这次，我们从哪里调用 appendChild？没错，是这样的：从 objRecord，我们刚花时间创建的父 (ComputerAudit) 节点。）
另外，由于 ComputerName 和 AuditDate 节点需包含值，因此还必须在将它们添加到文档前为其中每个节点的 Text 属性指定值。
只要浏览实际创建 ComputerName 节点的代码就会清楚：
Set objName = _
  xmlDoc.createElement("ComputerName")
objName.Text = "atl-ws-001"
objRecord.appendChild objName
正如您所料，创建 AuditDate 的代码几乎相同。我们只需在调用 createElement 时指定另一节点名称，并为 Text 属性指定另一个值即可。
老兄，此过程对于每个人而言都已经非常简单了，对吧？
创建完第一个（并且在本例中是唯一的）记录的节点后，我们来执行这一小段可爱的代码：
Set objIntro = _
 xmlDoc.createProcessingInstruction _
  ("xml","version='1.0'")
xmlDoc.insertBefore _
  objIntro,xmlDoc.childNodes(0)
它只是在文件开头处插入 <?xml version="1.0" ?> 标记，以确保得到格式标准的 XML 文档。
到此为止，剩下的工作就是调用 Save 方法并将新文件保存为 C:\Scripts\Audits.xml：
xmlDoc.Save "C:\Scripts\Audits.xml"
这样，我们就拥有了全新的 XML 文档。
现在，它实际上已经非常有用了：您已知晓了如何使用脚本创建全新的 XML 文件。当然，这只是特例，大部分时间都不需要实际创建全新的 XML 文件；而只需将新数据添加到现有文件即可。那么，脚本专家是否会为每个人展示如何操作呢？
您知道，我们最初决定对该问题回答不，我们不想为每个人展示如何将数据添加到现有的 XML 文件。随后，由于我们的仁慈和大方，因此决定与 TechNet 杂志的读者达成协议：如果阅读该杂志的所有人均同意参加 2008 年冬季脚本编写比赛，那么，作为回报，我们将向所有人展示如何使用脚本来将数据添加到 XML 文件。那么，是否所有人均同意参加脚本编写比赛呢？
嗯，我们正在等待您的参与。对，就是您 — 明尼苏达州罗切斯特的专家。
情况就象刚才我们介绍的那样。并且相信我们，脚本编写比赛过程会是一段美好的时光；每个人都会有这种感觉。我们保证。
现在，如之前说好的，我们将展示可将数据添加到现有 XML 文件的脚本。看一看图 3。
Figure 3 添加到 XML 文件 (Close Figure 3)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set objRoot = xmlDoc.documentElement

Set objRecord = _
  xmlDoc.createElement("ComputerAudit")
objRoot.appendChild objRecord

Set objFieldValue = _
  xmlDoc.createElement("ComputerName")
objFieldValue.Text = "atl-ws-100"
objRecord.appendChild objFieldValue

Set objFieldValue = _
  xmlDoc.createElement("AuditDate")
objFieldValue.Text = Date
objRecord.appendChild objFieldValue

xmlDoc.Save "C:\Scripts\Audits.xml"
您会看到，它与创建 XML 文件的脚本并没有太大差别。首先，创建一个 Microsoft.XMLDOM 对象实例，然后将 Async 属性设置为 False，即告知脚本我们希望同步而非异步加载文档。这中间有什么区别呢？是这样，如果异步加载文档，脚本会随心所欲地继续执行，即使文档并未完全加载也是一样。毫无疑问，如果尝试在尚不存在的文档上执行任务，会马上产生问题。通过确保同步加载 XML 文件，还可确保在完全加载文件后脚本才继续执行。
说到完全加载 — 没关系，不用管它。我们转而调用 Load 方法来打开文件 C:\Scripts\Audits.xml。打开文件后，我们立即使用此行代码来创建 documentElement 类的实例，其实际作用是将我们绑定到文档根。当然，在本示例中，是 ITChecklist 节点：
Set objRoot = xmlDoc.documentElement
之后的事情就轻而易举了。通过使用 appendChild 方法将该新节点添加到文件来创建 ComputerAudit 节点的新实例。然后，创建 ComputerName 和 AuditDate 节点的新实例，为每个新节点指定适当的值（分别是 atl-ws-100 和当前日期）。将这两个项目放入刚创建的新 ComputerAudit 节点中，调用 Save 方法保存文件，然后高兴地回来研究脚本以迎接即将开始的脚本编写比赛。
再次提醒，比赛计划于 2 月 15 日至 3 月 3 日在 TechNet 脚本中心举行。
到目前为止一切顺利。我们可以创建新的 XML 文件，并且可像该文件添加新记录。所有这些都很棒，但是我们仍有许多内容需要了解；例如，如何修改文件中的现有记录？嗯，至少有一种方法可以做到这一点（如图 4 所示）。
Figure 4 修改 XML (Close Figure 4)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
调用 selectNodes 方法（此方法用于确定查询将返回哪些记录）时会出现该脚本的重要部分。您会看到，在调用 selectNodes 时，我们谨慎地指定了两个标准：我们只需要 ComputerName 属性等于 atl-ws-100 的记录，并且我们仅希望得到 AuditDate 属性。
注意：您说无法明白其工作原理？那么，请参阅我们的第一篇有关使用 XML 文件的文章 (technetmagazine.com/issues/2007/02/HeyScriptingGuy)；此处更加详细地解释了 selectNodes 查询语法。
按照老习惯，selectNodes 会返回满足指定标准的所有 XML 记录的集合。这样，仅需通过设置 For Each 循环遍历集合中的所有项目，然后在该循环中为 AuditDate 指定新值，即可更新 AuditDate 属性（我们所需要的唯一属性）的值：
For Each objNode in colNodes
   objNode.Text = Date
Next
什么问题？您想知道我们能否一次修改多个属性？当然能。但遗憾的是，不是现在；在下一专栏中，还有一些必须解决的问题。
您说您还有一个问题：如何更新文件中所有计算机的审核日期？这很简单；使用图 5 中所示的脚本。
Figure 5 更改审核日期 (Close Figure 5)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit/AuditDate")

For Each objNode in colNodes
   objNode.Text = Date
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
此脚本与之前的 XML 修改脚本之间的唯一区别是什么？在此脚本中，我们并未指定我们仅希望查看 ComputerName 等于 atl-ws-100 的那些记录。省去该标准，我们默认会得到所有记录。
结束前，让我们再来看最后一个脚本。假设我们的老 atl-ws-100 已履行了最后的义务并且升入了计算机的天堂。
神学注释：那么，计算机寿命终结后会去何处？事实证明，它们通常被提供给某位脚本专家。例如，撰写本专栏的脚本专家就曾获赠一台笔记本电脑，原因是“您为 Microsoft 做出了很大的贡献，因此您确实应拥有一台笔记本电脑。”这件慷慨礼物的唯一缺点是什么？计算机已损坏并且实际上已无法开机。这可能还不算糟糕。事实证明，它还没有硬盘。
为结束硅元素生命的巨大循环，需从 XML 文件中删除 atl-ws-100。我们将如何做呢？请参见图 6。
Figure 6 从 XML 文件删除 (Close Figure 6)
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("C:\Scripts\Audits.xml")

Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")

For Each objNode in colNodes
  xmlDoc.documentElement.removeChild _
    (objNode)
Next

xmlDoc.Save "C:\Scripts\Audits.xml"
您会看到，它类似于之前修改 AuditDate 属性的那个脚本。实际上只有两点不同。首先，请注意我们并未麻烦地在 selectNodes 查询中指定任何属性值；在执行查询时，我们会得到 atl-ws-100 的所有 XML 记录：
Set colNodes=xmlDoc.selectNodes _
  ("/ITChecklist/ComputerAudit " & _
   "[ComputerName = 'atl-ws-100']")
接下来，在 For Each 循环中，只需调用 removeChild 方法来删除 ComputerName 等于 atl-ws-100 的所有记录即可：
xmlDoc.documentElement.removeChild _
  (objNode)
就是这样。再见，atl-ws-100；旧梦重温。
好的，有没有《TechNet 杂志》的编辑仍在阅读本月的专栏？您说他们都去参加每月脚本测试题了？非常好。我们现在就是权威了，我们可以告诉您：放下您手上的事情（比如阅读本杂志），赶快到脚本中心并开始准备参加脚本编写比赛。毕竟，您有很多时间来阅读《TechNet 杂志》。而脚本编写比赛一年才一次，并且时间有限（具体地说，从 2 月 15 日到 3 月 3 日，您知道只有这点时间）。切勿错失良机！
注意：您知道，既然您提到了，我们确实是等到您读完整个专栏后才告诉您停止阅读《TechNet 杂志》的，对吧？请想想原因是什么吧...

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

2008 年 2 月：神秘的符号
计算机键盘包含各种怪模怪样的字符；更怪的是其中的大部分字符在脚本编写语言 VBScript 或 Windows PowerShell 中均有特定用途。看看您能否将每个符号与其脚本编写用途相匹配。第一个已完成。

Scripto 博士的脚本谜题
答案：神秘的符号，2008 年 2 月

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


 安全观察: 跳岛：减少不需要的依赖关系
安全观察
跳岛：减少不需要的依赖关系
Jesper M. Johansson

在上个月安全观察的叙述中，我讲过使用 USB 闪存驱动器进行网络攻击的开始步骤。一旦已受感染的 USB 闪存驱动器插入计算机，攻击即开始。恶意代码将随后自动执行或在用户稍有不慎的帮助下（利用一些简单的社交
技巧）执行。虽然这种攻击仍然保持在对工作站的本地攻击层面，但需要清楚的是恶意软件有可能蔓延到网络的其他部分。我在即将出版的新书《Windows Server 2008 安全资源工具包》(Microsoft Press®, 2008) 中详细地讨论了这种网络攻击方式，目前我正在为本专栏修改其中的相关章节。
显而易见的一种保护方式就是禁用可移动驱动器。虽然这种方式很谨慎，但如果真的实行，用户们可能会很不高兴，他们的理由也很充分。除了最敏感的环境中，更好是尝试管理环境中包含的风险并抑制风险暴露。
而且，可移动驱动器并不是威胁客户计算机安全的唯一途径。不知您是否还记得“安全性的十个永恒定律”（可从 microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx 获得）？第 3 条定律依然适用：“如果攻击者对您的计算机具有无限制物理访问权限，那么这台计算机就不再属于您了。”在本讨论中，如果攻击者有权访问您的计算机，则必须认定该计算机已遭到破坏。如果攻击者能够设法使您在自己计算机上运行他的代码，甚至还能远程入侵。您可以将这种情况视为永恒定律的第 1 条：“如果攻击者能够设法使您在自己计算机上运行他的程序，那么这台计算机就不再属于您了。”
可以假定永恒定律仍然有效 — 它们已被证明具有相当普遍的适用性，在我们能够彻底改变计算机的工作方式之前，该定律不可能出现重大变化。因此，考虑一下这些定律如何应用于上述情形，削弱可移动驱动器的功能非常关键。只需要对注册表进行一些调整即可达到目的。
当然，您还必须使用其他保护层。您可以合理地假设许多客户端计算机已经遭到破坏，或者由一些并不总是关心组织最佳安全利益的用户使用。这表示您需要减轻他们对网络其余部分的影响，并提升理解、分析和减少安全依赖关系的重要性。

安全依赖关系的定义
当某台计算机的安全取决于另一台计算机的安全时将产生安全依赖关系。您可能曾经听人们说起如果域控制器 (DC) 已遭到黑客攻击，那您的整个网络都已陷入攻击之中。这种简化说法表明所有域成员的安全性都依赖于 DC。如果 DC 的安全都不能保证，那成员计算机的安全也就无从谈起。如果攻击者能够更改域的安全配置，那么他将可以通过在成员计算机的管理员组添加新帐户（以此为例）的方式接管域内的任何计算机。任何允许管理员对危害妥协的漏洞都不可小觑。因为管理员对所管辖的任何计算机都有完全访问权限。
在计算机系统中，依赖关系不可避免。事实上，它们是既常用又必要的；但是这并不代表所有的依赖关系都可以接受。在本专栏中，我将讨论哪些类型的依赖关系可以接受，而哪些则不可接受，然后我将分析依赖关系的类型及减少依赖关系的方法。在《Windows Server 2008 安全资源工具包》中，我将更加详细地讨论特定的依赖关系及如何对其进行管理。

可接受的依赖关系
通常，当敏感程度较低的系统在安全方面依赖更为敏感的系统时，这种依赖关系是可以接受的。一般来讲，计算机和系统可以根据敏感程度分为几类。（任何特殊环境中的特定类别与此处的一般讨论无关 — 它们的意义在于是固有类别。）为了方便讨论，假定现在有两个类别：工作站和 DC。此时，工作站在安全方面依赖 DC 是可以接受的。DC 比工作站的敏感程度高很多，所以很明显，它应该得到更好地保护。
对于用户帐户也可以得出相同的结论。管理员可以对用户的数据造成影响是可以接受的。这是因为管理员的责任更多，而且拥有对计算机及计算机中包含的所有信息的无限制访问权限（尽管并不总是直接或明显表现出来）。如果您理解这一点并适当管理自己的计算机，这种依赖关系并不会带来任何危害。
甚至软件也可以采用与此相同的方法进行分析。敏感程度较低的软件（如 Web 浏览器）使用并依赖敏感程度较高的软件（如操作系统）当然是可以接受的。如果操作系统有错误，那么 Web 浏览器因为一些新问题而易于受到攻击是意料之中的事，所以很可能处于亟待解决问题列表的较低位置 — 而操作系统和其他关键应用程序和数据将成为主要的焦点。该原理同样适用于错误如何修正或修补程序如何分发的问题 — 应该修正与问题关系最为紧密的错误。这样，修正的保护性影响将得到最大发挥。因此，应该首先修正操作系统自身的错误，而不是先解决 Web 浏览器的问题。
或者，可以通过更改设计去除依赖关系。例如，可以改写 Web 浏览器以减少对操作系统的依赖。安全性更高的组件（本例中为操作系统）实际上绝不会采用安全敏感程度较低的组件（Web 浏览器）所用的方式使用某项功能，在这种情况下，后一种方法更为恰当。

不可接受的依赖关系
根据上述我对可接受依赖关系的解释，不可接受依赖关系的定义现在应该很容易理解。基本上，敏感程度较高的系统应该从不依赖敏感程度较低的系统来保证其安全性。
如果某台工作站受到危害即表明 DC 的安全已遭到破坏，那您将面临严重的安全问题。如果一个网络的总体安全性依赖于网络中每台单独的计算机，那要保护这个网络将成为不可完成的任务。
让我们以统计学方法考虑这个问题。如果网络当中的每台计算机 99.999% 的时间是“安全”的，也许您觉得这个网络已经相当安全了。事实上，此百分比可能远远低于目前除最小型网络以外其他网络的实际情况。但现在假设您的网络当中有 40,000 台计算机，此时任何一台计算机都有 .001% 的可能遭到攻击。打趣点说，您整个网络此时就有 40% 的可能遭到攻击。
并且，即使只有 .001% 的可能，一台计算机还是可以通过不受管理的依赖关系对整个网络造成威胁。在这种情况下，网络到底有多安全？很显然，重点保护更为敏感的系统绝对至关重要。
毫无疑问，用户帐户和软件也是如此。例如，新的 Windows® 终端服务客户端允许您存储用于虚拟透明终端服务登录的用户名和密码。这些凭据使用凭据管理器 API 存储，通过用于主要登录会话的凭据提供保护。
这将产生安全依赖关系。请考虑以下示例：某个网络管理员登录到其个人工作站。她使用此工作站收发电子邮件、浏览 Web，并处理信息工作者的其他常规任务。很自然地，她将使用权限较低的域帐户完成这些工作。
某天的某时，该管理员连接到某台 DC 执行一些管理任务。她使用终端服务客户端执行此任务，并选择存储密码以便以后连接。这将导致至少一个（可能是两个）不可接受的安全依赖关系。第一个是她的域管理帐户凭据现在由其低权限的信息工作者凭据提供保护。如果该低权限的用户帐户遭到破坏，则域管理用户帐户也将遭到破坏，进而危及到整个域。
第二个依赖关系源自她在非域控制器上键入了域管理凭据。除非她的个人工作站与 DC 的受保护程度不相上下（很可能不是这样），否则就会出现 DC 的安全依赖于用户个人工作站安全的依赖关系。举例来说，如果同一办公室内某位心存不满的员工在网络管理员的工作站上安装了击键记录程序，现在就已经捕获了域管理凭据。只要您在非域控制器上键入域管理凭据，整个域就会暴露给非域控制器上的安全漏洞。
现在假设某个攻击者将可移动驱动器插入某台域管理员当前登录、曾经登录过或者将要登录的计算机中。该域管理员将受到影响，进而扩展到整个域都会遭到破坏。必须了解这种情况的危害性才能想办法避免。当然，如果某个安全应用程序依赖另一个安全程度较低的应用程序的功能来执行特定任务，该软件也会遭遇相同的问题。

一种攻击的分析
前面我已经说明了恶意可移动驱动器插入计算机会发生的情况。但是，可能只是清楚地说明了驱动器最初插入的计算机遇到的情况。假设出现问题的计算机已经加入域，如图 1 所示。
图 1 理想的域依赖关系
图 1 理想的域依赖关系
此处所示的情形展示了最理想的依赖关系。方向性箭头指示从何处继承依赖关系。例如，工作站的安全依赖 DC 的安全，而用户的安全依赖工作站的安全。攻击者也许能够破坏工作站，这可能导致保存在该工作站上的所有用户信息遭到破坏，但危害也仅限于此。
不过，假设登录该工作站的用户是服务器本地管理员组的成员，而且域管理员经常登录该服务器。此时将出现如图 2 中所示的依赖关系。
图 2 易受攻击的域依赖关系
图 2 易受攻击的域依赖关系
只要更改了登录问题计算机的用户这一假设条件，整个网络的安全性就已经受到影响。由于域管理员登录到该服务器，所以 DC 以及整个域的安全都将依赖该服务器的安全。
如果管理该服务器的安全性和 DC 一样，那这种依赖关系还可以接受。但在本例所示的环境中，登录到工作站的用户是该服务器上管理员组的成员。因此，该服务器的安全将依赖这台工作站的安全性。这意味着整个域的安全都将依赖这台工作站的安全性。那么，试想一下：假如这台工作站上的用户无意之中运行了攻击者的工具会出现什么情况。
当今信息安全领域可能很少有比安全依赖关系更重要的概念了。如果开始分析网络并尝试理解依赖关系，那您很可能会遇到不可接受的依赖关系。在最坏的情况中（这种情况远比您想象中更为常见），整个网络的安全依赖于整个网络 — 换句话说，网络中单台计算机的安全都在一定程度上依赖其他所有计算机的安全。因此，在这种环境下要创建既合理又现实的风险管理策略几乎是不可能的，因为无法控制依赖关系且过于复杂。对这一问题的解决方案是分析并管理依赖关系。
在本专栏中，我仅简要地概述了依赖关系及如何分析和减少依赖关系。您可以从我的新书《Windows Server 2008 安全资源工具包》中获得更多信息。该书用一整章讲述如何通过分析依赖关系，并使用先进的技术（如服务器和域隔离）和比较常见的技术（如管理型帐户管理）管理依赖关系，以便确保网络安全。
衷心感谢 David LeBlanc 为本专栏整理最初构思所提供的帮助。

Jesper M. Johansson 是解决软件安全问题的软件架构师，以及《TechNet 杂志》的特约编辑。他拥有 MIS 博士学历，并且具有 20 多年安全方面的经验。


 桌面文件: Windows XP 和 Windows PE 2.0 的双引导
桌面文件
Windows XP 和 Windows PE 2.0 的双引导
Wes Miller
下载这篇文章的代码: Desktop2008_02.exe (151KB)

在前几期的“桌面文件”中，我提到了 Windows PE 已成为一种恢复工具，还介绍了如何从另一个分区使用它。最近有人问了我一个问题，使我觉得有必要讨论一下此主题的最新发展趋势 — 同时使用 Windows PE 2.0 和 Windows XP，
毕竟许多用户可能使用 Windows® XP 一段时间了，而且 Windows PE 2.0 是 Microsoft 将继续提供支持的版本（请注意，对 Windows PE 1.x 将不再做进一步的更新）。
Windows PE 1.x 和 2.x 之间的一个重要区别在于 Windows PE 2.x 可以通过标准引导界面进行引导，而 Windows PE 1.x 必须使用特有的引导方法。尽管可以从另一个分区引导 Windows PE 1.x 或 2.x，但在操作系统所在的引导分区进行引导可能会有许多便利（我会在稍后加以介绍）。

Windows 的双引导
一直以来，Windows NT® 对双引导的支持都不太好。但是，由于基于可扩展固件接口 (EFI) 的计算机逐渐开始取代旧的 IBM PC AT BIOS，Microsoft 更改了 Windows 的引导机制，以便与 EFI 更好地协同工作并在所有体系结构中采用同一引导机制。从 Windows Vista® 开始，Windows 采用了称为引导配置数据库或 BCD 的新引导机制（请参阅 microsoft.com/whdc/system/platform/firmware/bcd.mspx）。但是，无论是使用原来的 boot.ini 还是新的 BCD 机制，Windows 通常都可以引导其他操作系统，虽然这样做就将引导过程转交给其他引导加载程序。
开始前必须先明确一点：Windows PE 2.0 只能在完全兼容高级配置与电源接口 (ACPI) 并且内存至少为 384MB（最好为 512MB）的系统上运行。我在五月份的专栏 (technetmagazine.com/issues/2007/05/DesktopFiles) 中提到，非 ACPI 系统将无法引导 Windows PE 2.0，并且由于必须将 Windows PE 2.0 引导到 RAMDisk，因此它需要配有足够的 RAM 来存放 RAMDisk、任意暂存空间以及所有 RAM 工作集。如果您的系统 RAM 少于 384MB，请趁早放弃这种途径而改用 Windows PE 1.6。即使是擅长给 Windows PE 瘦身的高手也无法在 256MB 内存的情况下流畅运行。

对了，别忘了要解决的问题
现在，让我们来了解一下通过从与 Windows XP 相同的分区引导 Windows PE 2.0 可以解决的问题。
完全系统恢复 这是通过从 Windows XP 所在分区引导 Windows PE 可以实现的其中一个任务。由于 Windows PE 2.0（与之前的 Windows PE 1.6 一样）可完全引导到 RAMDisk，因此您可以重新映像整个磁盘 — 或使用 ImageX 单独还原 Windows XP 文件，而不必重新映像整个分区。
由于允许用户在启动时引导到 Windows PE，因此现在甚至可以远程恢复系统。映像可以来自辅助分区、网络共享（如果用户不是移动用户）、恢复 DVD 或 USB 硬盘，如果使用的是 ImageX，甚至还可以将其存储在要恢复的分区上。这种磁盘恢复方法对许多问题（物理磁盘损坏除外）而言都是一种不错的解决方案。但是很明显，它不适合于还原用户数据，除非最初受到保护的数据作为恢复的一部分加以还原。请记住，应使用漫游配置文件并备份 PC 中的数据以防止此情况下的数据丢失。还应确保使用的任何恢复机制都考虑到用户的需要，减少任何潜在的数据丢失风险（包括由于重置 EFS 加密密钥而造成的丢失）。
文件恢复 Windows PE 还提供了启动和运行系统的机制（即使 Windows 的主安装不能引导）。在这种情况下，可将用户数据引导并恢复到其他系统（用户必须有热备份系统）或其他位置，以便用户能够很快重新开始工作。
系统修复 最后，在 Windows XP 分区上引导 Windows PE 后，可通过运行一组故障排除脚本或一个简单的、用户驱动的修复或恢复应用程序来修复系统。此过程类似于完全系统恢复，但它涉及的范围较小，并且不会危及用户数据。
现在我们了解了在 Windows XP 分区上引导 Windows PE 可实现的功能，接下来让我们看一看后台情况以便将此过程应用到所需的任何解决方案中。

在 Windows Vista 之前
在 Windows Vista 出现之前，对于基于 BIOS/主引导记录 (MBR) 的系统，其引导方式如下所述。BIOS 指向引导设备（对硬盘而言，它指向磁盘的 MBR）。MBR 执行可指定待引导分区的代码。注意，它是设置了活动标记的第一个分区。在最早版本的 diskpart 中，无法将分区设为不活动（即无法移除活动标记）。在 diskpart 中添加了开关来解决此问题 — 否则，它将是分区表顺序中具有活动标记的第一个分区。该分区包含引导扇区 — 它会指出接下来要执行的代码。从 Windows NT 到 Windows Server® 2003，要运行的代码都位于一个名为 ntldr 的没有扩展名的文件中。如果磁盘已格式化但未安装 Windows，则当您试图进行引导时，将看到错误消息“NTLDR not found”。
您可能有兴趣知道 ntldr 是完全向后兼容的，而不会向前兼容。这就表示 Windows XP 的 ntldr 可引导 Windows 2000，反之却不行。这就是实现双引导必须首先安装旧版本操作系统的原因。并且由于 ntldr 没有附带版本号，因此弄清这一点显得尤为重要。
Ntldr 是一个启动 NTDetect.com 的实模式（16 位）应用程序，它执行基本的设备检测然后启动内核 ntoskrnl.exe（这可能是多个文件中的其中一个文件 — 始终重命名为 ntoskrnl.exe）。内核是 Windows 引导过程中的关键组件。
此引导过程摘要显得有点简单，我省略了 Win32® 的整个初始化过程，因为它与本讨论并不相关。如果希望了解有关此引导过程的更多信息，建议您阅读 Mark Russinovich 和 David Solomon 合著的《Windows Internals, Fourth Edition》（Windows 内核，第四版）（Microsoft Press®，2004）。
另外，还要注意，从光盘引导时，Windows Setup 和 Windows PE 运行的是 setupldr.bin 而不是 ntldr。此文件实际包含的引导代码略有不同，目的是为了使其可以从光盘引导（ntldr 则不能）。这就是为什么引导 Windows PE 1.x 时，必须将 setupldr.bin 重命名为 ntldr 并放到磁盘上的原因所在。也是为什么该文件无法随后加载 boot.ini 文件的原因（因为 setupldr.bin 仅用于光盘引导，因此 boot.ini 并非是必需的文件）。

Windows Vista 及更高版本
Windows Vista 更改了此过程的许多方面。Windows Server 2008 对其做了进一步的更改，包括允许 IA32（支持 32 位）从 EFI 引导（到目前为止，除了基于 Itanium 的系统以外均无法实现此引导）。对于基于 BIOS 的系统，引导过程的初始步骤大部分都没变。关键区别在于 BOOTMGR 是引导加载程序，初始化后执行以下步骤。
它在引导目录中查找 BCD 文件（实际上是其自身的注册表配置单元）。BCD 包含要引导的引导条目（包括默认条目）。请参见图 1 了解映像类型（可执行文件类型），参见图 2 了解要启动的特定应用程序类型。ntldr 可以引用一个（或多个）此类条目。但其中仅有一个条目可实际引用众所周知的用于加载 ntldr 的 GUID（请参见图 3 中的第五行）。bootmgr 随后决定接下来要加载的条目，具体取决于是否正在引导系统、系统是否正在休眠或者是否要引导到 ntldr 或其他引导管理器（在这种情况下它会指向另一个引导扇区并启动该加载程序）。在使用非 Windows 操作系统进行双引导时，这种情况最常见。可在以下网站找到更多信息：microsoft.com/whdc/system/platform/firmware/bcd.mspx。
Figure 3 标准应用程序对象 (Close Figure 3)

说明 | BCDEdit ID | GUID
Windows 引导管理器 | {bootmgr} | 9dea862c-5cdd-4e70-acc1-f32b344d4795
固件引导管理器 | {fwbootmgr} | a5a30fa2-3d06-4e9f-b5f4-a01df9d1fcba
Windows 内存测试程序 | {memdiag} | b2721d73-1db4-4c62-bf78-c548a880142d
Windows 恢复应用程序 | 无别名 | 147aa509-0358-4473-b83b-d950dda00615
传统 Windows 加载程序 | {ntldr} | 466f5a88-0af2-4f76-9038-095b170dc21c
当前引导条目 | {current} | fa926493-6f1c-4193-a414-58f0b2456d1e
默认引导条目 | {default} | 无预定义的 GUID
Figure 2 应用程序类型 (Close Figure 2)

说明 | 值 | 说明
固件引导管理器 | 0x1 | 仅适用于 EFI 系统。
Windows 引导管理器 | 0x2 | 控制引导流。在双引导系统中，向用户显示引导选择菜单。
Windows 引导加载程序 | 0x3 | 加载特定的 Windows 版本或配置。
Windows 恢复应用程序 | 0x4 | 当计算机从休眠状态恢复时将 Windows 还原到其运行状态。
Windows 内存测试程序 | 0x5 | 内存诊断应用程序。
Ntldr | 0x6 | 仅适用于 PC/AT BIOS 系统。加载 Windows Vista 之前的 Windows 版本。
引导扇区 | 0x8 | 16 位实模式应用程序。仅适用于 PC/AT BIOS 系统。可用于重新启动引导过程并加载非 Windows 操作系统。
Figure 1 映像类型 (Close Figure 1)

说明 | 值
固件应用程序 | 0x1
引导应用程序 | 0x2
基于 Ntldr 的加载程序对象 | 0x3
实模式应用程序 | 0x4
您会注意到，改进后的 Windows Vista 引导基础架构与以前的版本相比更具条理性 — 除 bootmgr 外，所有引导代码均位于根级别 \boot 目录中，并且在 BCD 指定后，还可以转到 Windows 特定的二进制文件中。

引导 Windows XP 和 Windows PE 2.0
现在让我们来了解一下使用 Windows Vista 引导管理器，如何能够以 Windows PE 为中介，在继续引导 Windows XP 或 Windows 早期版本的同时，将 Windows PE 2.0 添加到集成的恢复工具组中。
当然，还要向引导过程中添加另一个 Microsoft 事先设计好的步骤。由于新的 bootmgr 基础架构需要向后兼容现有的 ntldr 和其他第三方引导管理器，因此专门构建了 bootmgr 来支持此类解决方案。
因此，在研究了 Windows 的启动方式以及新 BCD 的工作方式后，我们如何才能将二者联系起来并将 Windows PE 2.0 应用到现有的 Windows XP 安装呢？有两种方法可记下 Windows Vista 引导扇区（用来告知系统启动 bootmgr 的引导代码）。其中一种方法是使用 diskpart，通过 Windows PE 2.0 创建并格式化一个新分区。但在这里不能选择此方法，因为您已安装了 Windows XP 并且不希望损坏或移动它。因此改为使用以下过程：
  1. 确保 Windows PE 2.0 引导光盘上有 bootsect.exe 和 bcdedit.exe 的副本（都可以在 Windows Vista 安装 DVD 上找到）。
  2. 将 Windows XP 系统引导到 Windows PE 2.0 光盘。
  3. 引导后，运行以下命令：
    bootsect.exe /NT60 ALL
这会将引导扇区设置为 Windows Vista 兼容的引导扇区，它知道如何启动 bootmgr。
4. 将引导管理器复制到硬盘：
    xcopy BOOTMGR C:\BOOTMGR /I
5. 将 boot.SDI 文件复制到硬盘上的 \BOOT 目录中。必须在引导前制作一个副本，因为 Windows PE 运行时会锁定此文件，从而无法复制：
    xcopy BOOT.SDI C:\BOOT\
相应地更正源路径。
6. 将 boot.WIM 复制到硬盘。与 SDI 类似，应准备一份辅助副本，否则您将无法复制正在运行的文件：
    xcopy BOOT.WIM C:\BOOT\BOOT.WIM
相应地更正源路径。
7. 现在创建新的 BCD 存储：
    bcdedit /createstore
8. 接下来创建 BCD 条目以加载 Windows PE：
    bcdedit /create {ramdiskoptions} /d
    "Boot Windows PE"
    bcdedit /set {ramdiskoptions}
    ramdisksdidevice partition=c:
    bcdedit /set {ramdiskoptions}
    ramdisksdipath \boot\boot.sdi
    bcdedit /create /d "Windows PE" /
    application
    OSLOADER
9. 最后一行将返回 GUID。使用返回的实际 GUID 替换 {YOURGUID}。它们是 RAMDisk 的条目，用来从硬盘引导 Windows PE（如图 4 所示）。
Figure 4 RAMDisk 的条目，从硬盘引导 Windows PE (Close Figure 4)
bcdedit /set {YOURGUID} device ramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} path \windows\system32\winload.exe
bcdedit /{YOURGUID} osdeviceramdisk=[c:]\boot\boot.wim,{ramdiskoptions}
bcdedit /set{YOURGUID} systemroot \windows
bcdedit /set{YOURGUID} winpe yes
bcdedit /set {YOURGUID} detecthal yes
10. 现在，创建 bootmgr 条目以启动引导管理器：
    bcdedit /create {bootmgr} /d
    "Boot Manager"
    bcdedit /set {bootmgr} device boot
11. 最后，为现有的 Windows 安装设置 BCD 条目（将 Windows XP 中的显示文本更改为您希望在引导管理器引导菜单中显示的任意文本）。最后的命令还会将它设置为引导菜单中的第一个（默认）条目：
    bcdedit /create {ntldr} /d "Windows XP"
    bcdedit /set {ntldr} device partition=C:
    bcdedit /set {ntldr} path \ntldr
    bcdedit /displayorder {ntldr} /addfirst
12. 现在，通过选择适当的引导菜单条目，即可重新启动系统并使其启动先前安装的 Windows 或 Windows PE 2.0。图 5 显示了 bcdedit /enum all 的示例输出。此命令将在向 BCD 中添加完条目后列出所有条目（来自 Windows PE 1.6）。
示例输入
我一直在使用一个脚本来自动执行此任务。目前它只能将引导文件复制到硬盘并设置 BCD 条目。还无法在运行 Windows 的同时将引导扇区设置为新的 Windows Server 2008 的值 — 必须在 Windows PE 环境下脱机执行。您可在《TechNet 杂志》网站的代码下载部分找到此脚本，网址为 technetmagazine.com。要运行该脚本，运行 VBScript 的目录下必须具有下列项：
  1. BCDEdit
  2. BOOTMGR
  3. \BOOT\ 目录（来自 Windows Vista 或 Windows PE 2.0 媒体）
  4. \SOURCES\ 目录，包含有效的、可引导的 Windows PE 2.0 BOOT.WIM 文件
它会创建 BCD 并复制相应的引导文件。引导到 Windows PE 并运行 bootsect 后，即可进行双引导。

撤消双引导
撤消双引导要比实现双引导容易得多。只需运行以下命令将引导扇区还原到之前的 Windows Vista 引导扇区即可：
bootsect.exe /NT52 ALL
还原完毕后，即可删除 bootmgr 和 \boot 目录。下次重新启动时，引导扇区将改为强制启动 ntldr，而从引导流中彻底移除 Windows PE 2.0 和所有 Windows Vista 引导二进制文件。

Wes Miller 是位于德克萨斯州奥斯汀市的 Initiate Systems 公司 (InitiateSystems.com) 的技术产品经理。在此之前，他在 Winternals Software 公司任职，并曾在 Microsoft 担任项目经理。Wes 的联系方式如下：technet@getwired.com。


 领域备注: 捐赠 PC
领域备注
捐赠 PC
Jim Lynch

有关处理计算机的最经济有效的方法， 多年来的传统智慧已在 2003 年发布的一篇研究论文中进行了详尽阐述，此论文标题为“PC Disposal: TCO's Last Surprise”，作者是 Gartner Group 的 Frances O'Brien。论文中对 PC 处理方法进行了比较分析，并由此发现：捐赠设备是所有处理方法中（共六种）最昂贵的一种，因为找到愿意接受捐赠的合适慈善组织所需的时间太长。
捐赠提示
TechSoup.org 在 techsoup.org/recycle 提供了附加的捐赠提示，还可以在此位置接受捐赠。捐赠前需考虑以下事项：
  • 升级到新硬件后，不要舍不得放弃原 IT 设备。计算机设备五年后即会失去重用价值。类似地，手机通常三年后就会到达寿命终结。
  • 将不到五年的 IT 设备捐赠给回收机构胜过直接捐给非营利性组织或学校。
  • 将配件随设备一起包装（包括键盘、鼠标、打印机、调制解调器、软件磁盘以及设备随附的手册）。
  • 记录下所捐赠的物品并索要收据。如果捐赠给非营利性回收机构，则可能拥有减税资格。在美国，企业捐赠方可减少的税额为计算机的折旧前价值，而个人可减少的税额为计算机的现行市值。要确定计算机的合理市值，请转到加拿大的免费“已用计算机评估器”(servlets.edeal.com/servlets/PcEval)。

现在已与过去完全不同。事实上，美国国家环境保护局 (EPA) 最近发起了一项名为“Do the PC Thing”的活动，旨在教用户如何做好旧硬件重用准备并提供了一系列资源。此活动是 EPA 的电子设备回收和重用公众关注网站 Plug-In To eCycling (epa.gov/plugin/) 的一部分。单击“Reuse It!”链接可获取针对消费者或企业的文章。
在该网站上，您将了解到与捐赠或回收硬件相关的最重要问题是保护您自己。“Do the PC Thing”文献提供了有关硬盘驱动器擦除以及数据安全性和机密性法律要求的基本指导。无论是出于寿命终结回收的目的还是出于重用目的处理计算机，都必须删除敏感数据（如密码、文档、信用卡信息、电子邮件和网络日志）。
大多数电子设备废物利用机构、回收机构和资产管理公司均提供数据安全性服务，其方法是破坏硬盘或使用磁盘清理软件实用程序来覆盖数据使其无法恢复。请注意，如果计算机已指定要重用，最好保持计算机硬件完整无缺。
知名磁盘清理软件使用美国国防部 5220.22-M 规范。此类基于软件的数据清除会用一个字符系统地覆盖硬盘上的所有可寻址位置，确认覆盖，然后再次使用随机字符覆盖所有可寻址位置。2004 年，美国国家安全局 (NSA Advisory LAA-006-2004) 发现使用国防部标准软件的单次覆盖已足以使电子文件无法再恢复。
现在，相当轻松即可使数据保持安全。有一些知名的免费软件应用程序可供使用，如 Active@ Kill Disk Hard Drive Eraser (killdisk.com/eraser.htm) 或 Darik's Boot and Nuke (dban.sourceforge.net)。如果有多台计算机要执行数据清除，请考虑功能更强大的商用应用程序，如 Blancco Data Cleaner (blancco.com) 或 WipeDrive (whitecanyon.com)。
如果 IT 设备超过五年或严重损坏，则 Gartner 讨论到的六个处理选项之一是寿命终结电子设备回收。现在，美国有超过 900 家公司在开展此业务。要正确回收旧的 IT 设备，请参见美国电子产品回收联盟的可靠回收机构列表 (www.computertakeback.com/the_solutions/recyclers_map.cfm)。

Jim Lynch 是 TechSoup.org 的项目总监，负责计算机的回收和重用。TechSoup.org 是一个总部设在旧金山的高科技非营利性组织，其宗旨是向世界各地的慈善机构提供成本极低的硬件、软件和实用操作技术。


 Windows 机密: 废弃片段文件
Windows 机密
废弃片段文件
Raymond Chen

这种事不常发生 ，但偶尔也会有某个旧功能被删除的情况 — 产品团队不免要庆祝一番。例如，在 Windows® XP 中，用来设置桌面图案的界面已被去除。如果您设法编写一段程序来调用 SystemParametersInfo(SPI_SETDESKPATTERN)，就会发现底层功能仍在，但与之关联的内置界面已不存在。为什么要将桌面图案从桌面控制面板中去除呢？
我们的调查表明，现在几乎已经没有人使用桌面图案了。在内存非常昂贵、用户不想将四分之一的计算机内存浪费在 1MB 的壁纸位图上的时候，桌面图案非常流行。一张小小的 8×8 单色图案重复盖满屏幕，这样就以非常低的成本在 640×480 的屏幕上实现了某种程度的个性化。
但是，这些年情况的变化使桌面图案变得越来越没有吸引力。当然，首先是因为现在计算机的内存要远远超过 1983 年时的计算机内存。其次（也是当然）是因为现在监视器的分辨率要远远高于当时计算机的分辨率。一张精致的 8×8 大小的犬牙花纹图案在 1600×1200 的监视器上基本上只能显示成一个灰色污点。
它不是唯一被废弃的旧功能。另一个示例是片段文件。片段文件在 Windows 95 中引入，当时用作捕捉到文件中的文档碎片。这个文件碎片实际上是一个 OLE 对象。例如，片段文件基于的思想是：您可以在字处理程序中突出显示某些文本，然后将其拖动到桌面上，这时就在桌面上创建了一个片段文件。随后，您可以选取该片段文件并将其拖回字处理程序或其他程序中，这时用来创建片段文件的文本将插入到新文档中。在某种程度上它类似于复制和粘贴，不同之处在于它不是将数据临时存储到剪贴板上，而是存储在文件中。
现在，在创建这样一个片段文件后，您只能将其放入另一个文档中，就像只能将剪贴板中的内容粘贴到某处一样。在某些情况下，有人向片段文件添加了双击功能，双击片段文件后它会在最初创建它的应用程序中打开。（这和片段文件的内容无关，因此显示片段文件的唯一途径就是询问最初创建它的程序。）
我不清楚此功能是作为一种调试工具加入的，还是为了使用户无需创建用来放入片段文件的虚拟文档就可以看到片段文件的内容。无论哪种原因，病毒编写者都非常喜欢这种“打开最初创建该片段文件的应用程序”功能，因为这将允许他们创建一个片段文件并填充一段数据，声明“最初的应用程序是 cmd.exe，文档碎片就是这个批处理文件”。如果有人双击这个特殊的片段文件查看其内容，片段文件查看器就会传给命令处理器一个批处理文件并告诉它，“请打开这个文件让用户看一看文件内容。”
考虑到片段文件的历史，Shell 团队决定从 Windows Vista® 中删除此功能。为此，团队必须调查片段文件的实际使用率。Shell 团队于是请产品支持组调出了该组的记录，看一看究竟有多少人曾询问过有关片段文件的问题。从理论上来说，常用的功能会有相关的支持求助电话，而不常用的功能则没有（因为根本没人使用它们）。特别要指出的是，片段文件功能没有被归入“极其直观”这一功能分类，因此少量求助电话不能被解释为“呵呵，这个功能太浅显了，没人会打电话来寻求帮助！”
后来产品支持组给出了答案。在过去几年中，该组总共收到了四个相关电话。他们的问题都差不多，“我创建了这个奇怪的文件。它到底是什么？我该如何将其去除？”

Raymond Chen 的网站“The Old New Thing”及同名著作 (Addison-Wesley, 2007) 均讲述了 Windows 的发展历程及 Win32 编程。自从 Raymond 上次见到您至今已有数年，他很关心您家人的情况。