7 月 2008 7 月 2008
IIS: 开始使用 IIS 7.0
Internet 信息服务 7.0 的发布设置了新的标准、提供了根本性的改进，并引进了新功能来巩固 Web 环境。探究最重要的增强功能，并获取有关测试、逐步实施和将 Web 应用程序迁移到 IIS 7.0 的深入指南。 Fergus Strachan
沟通与协作: 规划向统一消息的迁移
如果计划得当，可以非常轻松地从传统语音邮件系统迁移到统一消息平台，最终用户几乎不会受到影响。本文介绍了在规划迁移、测试新系统和在组织中实施统一消息所需了解的内容。 Jeff Goodwin
沟通与协作: OCS 2007 如何利用语音功能
Microsoft Office Communication Server 为企业电话技术带来了重大变革。逐层剖析如何进行语音呼叫，了解将呼叫路由到各个端点的方法，并领会 OCS 通信中会话的重要性。 Rajesh Ramanathan
沟通与协作: 使用 Groove 和 SharePoint 创建强大的连接
Microsoft Office Groove 和 SharePoint Server 均提供了强大的协作功能。比较两者的区别及互补方式，并揭示如何通过集成 Groove 和 SharePoint 创建灵活便捷的解决方案，为不同地点的用户提供支持。 Alan Maddison
Windows 管理: Windows Server 2008 故障转移群集简介
多年来用户一直抱怨 Windows Server 中的群集太过复杂。随着 Windows Server 2008 的发布，群集功能得到了完全的改观。探究新“故障转移群集”中的一些最为重要的增强功能，并了解这一新版本如何使得群集更易于安装和维护。 Chuck Timon
Columns
编辑寄语: 印刷品退位: | 读者来信: 读者心声: | 工具箱: 面向 IT 专业人员的新产品:
Exchange 问答: 负载平衡、边缘传输及更多内容: 您是否想询问有关 Exchange 的问题？在本期内容中，我们回答了有关将 Exchange 与 SharePoint 一起使用、使用备用连续复制、在 Windows Server 2008 上安装 Exchange 2007 邮箱服务器等的问题。Henrik Walther | 实用工具特别推荐: Microsoft SharedView: 您是否正在寻找一种可用于与另一城市的人员迅速交流的方法？了解免费的实用工具 Microsoft SharedView 可如何帮助您和小组成员轻松跨地域共享文档和屏幕。Greg Steen | 深入剖析 SharePoint: 集成 Office 应用程序: 了解 Microsoft Office 应用程序如何与 SharePoint 进行集成和通信，并探究使用同样的原理实现非 Microsoft 应用程序与 SharePoint 之间的集成的方法。Pav Cherny
Windows PowerShell: 投球框: Don Jones 介绍筛选函数、管道、自定义对象，以及如何借助乒乓球理解 Windows PowerShell。Don Jones | 您好，脚本专家！: 肾上腺素刺激: 脚本专家介绍了令肾上腺素四溢的脚本，并向您展示了如何使用脚本来访问 Windows Vista 和 Windows Server 2008 中的新引导配置数据存储。Microsoft 脚本专家 | 桌面文件: 网络引导 Windows: 介绍远程安装服务 (RIS) 和 Microsoft 使用的其他 PXE 相关技术的历史。Wes Miller
安全观察: 密码和信用卡，第 1 部分: 本系列由三部分构成，在第一部分中介绍了常见的安全相关建议和常见措施过时的原因，以及它对实际安全成果的阻碍。Jesper M. Johansson | 领域备注: 确保选举的准确性: 分析了当今美国选举系统的缺陷并介绍了如何利用加密产生完全可审核的选举结果。Josh Benaloh | Windows 机密: 空间占用回顾: Microsoft Bob 比您想象的更为流行。Raymond Chen 解释了 Microsoft Bob 如何走进千家万户。Raymond Chen


IIS
开始使用 IIS 7.0
Fergus Strachan
概览：
  • 在 Web 场环境中部署 IIS 7.0
  • 安全性和性能增强
  • 将 ASP.NET Web 应用程序从 IIS 6.0 迁移到 IIS 7.0
  • 将 PHP Web 应用程序迁移到 IIS 7.0

目录
准备、设置、测试
我的测试安装
IT 管理员获得的重要增强功能
IIS 体系结构
集成和经典模式
模块和功能
Web 应用程序迁移
总结
Microsoft 的 IIS 团队宣称 Internet 信息服务 (IIS) 7.0 是 IIS 史上最大的一个版本。此版本设置了新的标准、做出了根本性的改进并
引进了新功能来巩固 Web 环境。IIS 7.0（包含在 Windows Server® 2008 和 Windows Vista® SP1 中）已应用于 Microsoft.com，并且多家 Web 托管公司已开始向希望将现有的 Web 应用程序转到新 Web 服务器平台的 Web 设计人员和开发人员提供 IIS 7.0 托管服务。
在本文中，我将探讨对于 IT 专业人员而言最为重要的关键 IIS 7.0 增强功能，然后将详细介绍迁移 ASP.NET 和 PHP Web 应用程序。但首先，我想要简要介绍一下模拟基本生产环境的测试实验室。
这是一个重要的任务。在将 IIS 7.0 部署到生产服务器之前，您需要花费一些时间来在实验室环境中执行全面测试，从而确保 Web 应用程序能在新 Web 服务器上顺利运行。

准备、设置、测试
测试实验室包括运行 Windows Server 2003 和 IIS 6.0 的系统（用于托管 ASP.NET 应用程序），以及运行 Ubuntu 7.10 Linux 分发版和 Apache HTTP Server 2.2 的服务器（用于托管基于 PHP 的 Web 应用程序）。我的最终目标是在临时和生产系统上部署 Windows Server 2008，然后转换复杂的 Web 应用程序以将 IIS 6.0 和 Apache 实例替换成 IIS 7.0。
我有两个主要 Web 应用程序：DotNetNuke 4.7 和 osCommerce 3.0a4。DotNetNuke 是基于 ASP.NET 2.0 和 Microsoft® SQL Server® 的一个 Web 应用程序框架。另一应用程序 osCommerce 是构建于 PHP 和 MySQL 之上且功能完备的电子商务解决方案的最新 alpha 版本。现在，让我们将这些高级应用程序放入 IIS 7.0 中！
需要说明的是，比较软件版本、产品或平台并非我的目的所在。但是，在 Windows Server 2008 和 IIS 7.0 中包含了许多我应当指出的标准化优点。比如，管理复杂程度有所降低，并且可以最大限度减少运行的 Web 服务器总数。
图 1 提供了本文将用到的测试实验室的概述。如果要在自己的测试环境中遵循我的说明，随附材料中有所需软件组件以及详细的分步安装说明的链接（可从《TechNet 杂志》网站的“代码下载”获取该随附材料）。
图 1 用于部署 IIS 7.0 的测试环境（单击此图像可查看大图）
请注意，在我结束本文的撰写时，Microsoft 发布了一个命令行工具 (MSDeploy.exe) 来支持客户部署、同步以及将 Web 应用程序迁移到 IIS 6.0 和 7.0。建议您了解一下该工具。可在 go.microsoft.com/fwlink/?LinkId=118272 处的 Microsoft Web 部署团队博客上找到相关的详细信息。

我的测试安装
在撰写本文时，Windows Server 2008 仍为预发布版，因此我并未替换域控制器或数据库服务器上的 Windows Server 2003。如果使用 Windows Server 2008 的官方发布版本，您可能还希望考虑迁移您的 Active Directory® 基础结构。将 SQL Server® 2005 和 MySQL 数据库迁移到 SQL Server 2008 同样超出了本文的讨论范围。
我在阶段服务器上部署 SQL Server 2008 的主要原因是它比安装带有 Service Pack 2 的 SQL Server 2005 更方便。DotNetNuke 完全可与 SQL Server 2008 数据库一同运行。在 Windows Server 2008 上安装 MySQL 5.0 也非常直观明了，并无复杂之处。
虽然 Server Core 上提供有 IIS 7.0，但由于测试有一些特定要求，我并未使用 Server Core 安装。阶段服务器需要完整的安装，因为它是我的主要测试系统。此外，Server Core 上并无 Microsoft .NET Framework。
PHP 可在 Server Core 上正常运行，但由于我的目标是整合 ASP.NET 和 PHP 应用程序，因此不会选择使用 Server Core。在 Server Core 支持 .NET Framework 之前，您需要执行完整安装来支持 ASP.NET 应用程序。如需安装测试环境的详细分步指南，请阅读随附材料中的 01_install_testlab.htm 文件。
我选择全新安装 Windows Server 2008（而不是升级现有的服务器）。此外，全新安装更易于实施如图 2 所示的逐步迁移方案。基本策略是继续运行现有的 Web 场，直到所有相关的 Web 应用程序组件已在阶段服务器上测试成功并迁移到新的 IIS 7.0 Web 场中。
图 2 逐步切换到 IIS 7.0（单击此图像可查看大图）
可选择一次性或逐步迁移所有现有的 Web 应用程序，具体取决于环境的复杂程度。对于每个 Web 应用程序或站点，在新的 Web 场上执行最终验收测试后，即可通过更改相关 DNS 记录将浏览器指向新 IIS 7.0 Web 场来实现切换。这种方式可将停机时间和服务中断降到最低。

IT 管理员获得的重要增强功能
《MSDN® 杂志》刊登了一篇由 Mike Volodarsky 撰写的题为“探索用于 Windows Vista 的 Web 服务器和更多内容”的优秀文章（网址为 msdn2.microsoft.com/magazine/cc163453.aspx），可通过该文章快速了解 IIS 7.0 中的改进。
另一不错的文章是 Microsoft.com 团队发表的名为“狗粮中的美味”的博客帖子（网址为 go.microsoft.com/fwlink/?LinkId=117436）。该帖子概述了团队成员最初的 IIS 7.0 体验。简单地说，他们评出了以下主要改进：
  1. 简洁安装。
  2. 更好的兼容性。
  3. 不再存在元数据库。
  4. 通过 UNC 共享中的 applicationHost.config 文件实现集中式配置。
  5. 通过应用程序目录中的 web.config 文件进行委派配置
  6. 改进了管理工具。
  7. 失败请求跟踪。
  8. 无需 URLScan 即可实现请求过滤。
  9. 通过 UNC 共享简化了内容同步可用性。
  10. 动态内容的输出缓存功能。
“简洁安装”毫无疑问是让人心动的。在博客上的帖子中，Microsoft.com 团队演示了如何利用单个命令行来部署 IIS 7.0 的所有功能（当然，或者仅是您需要的功能）。我非常希望通过使用图 3 中所示的命令行将这种方法合并到我的测试实验室安装指令中。
无可否认，该命令相当地长。（如果想要复制该命令，建议从《TechNet 杂志》网站进行复制和粘贴，而不要手动重新键入。）尽管该命令将所有可用的模块都部署到 IIS 7.0 计算机上，但却不包括 PHP。IIS 7.0 并不包括 PHP，而且通过 Internet 下载和安装 Debian 数据包这一概念对于 Windows® 包管理程序 (pkgmgr.exe) 来说非常陌生。添加 Windows 自动安装工具包 (AIK)。
图 3 通过单个命令行部署 IIS 7.0 功能
start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).
通过使用 AIK，可针对 Windows Server 2008 创建包含 IIS 7.0 和 PHP 5 的自定义安装 DVD。还可包含 MySQL、Web 应用程序文件以及部署中需要的所有其他组件。所有组件都可作为 Windows Server 2008 安装的一部分，从而可在所有 Web 服务器上统一应用自定义设置。此过程不需要使用命令行或编辑配置文件。
甚至可创建一个自定义 DVD 来执行完全无人参与安装。AIK 中包括用于创建 AutoUnattend.xml 文件的文档和工具，并且随后应将该文件放到 DVD 的根文件夹中。随附材料中的 Custom Image Deployment.htm 文件提供了分步说明。
许多管理员都认为兼容性也是一项重要的改进。在随后的操作过程中，我预计会遇到许多与 DotNetNuke 和 osCommerce 有关的兼容性问题，但转换到 IIS 7.0 的过程却相当轻松，尽管这两个 Web 应用程序都包括许多高级功能（如表单身份验证和搜索引擎友好的 URL）。
对于 DotNetNuke，向复杂 Web 场方案（在 64 位平台上共享 UNC 内容）的迁移完成得很顺利。几乎没遇到什么大问题。由于兼容性有所改进，大为节省了将 Web 应用程序转换为在 IIS 7.0 上运行所需的时间。
如果碰巧遇到与 Web 应用程序有关的兼容性问题，则内置诊断和跟踪支持这一新功能将迅速发挥功效。详细的诊断信息非常有意义，并且建议的解决方案非常有用并能实际奏效。
图 4 显示了以集成模式在 IIS 7.0 上运行 DotNetNuke 4. 7 时得到的诊断信息。在此示例中，共有三个选项（如“可尝试的方法”部分所示）。更改应用程序来支持集成模式可能是 DotNetNuke 开发人员的最佳选择。而忽略错误并不是个好主意。我喜欢第三种选择，即通过将 Web 应用程序切换到 Classic .NET AppPool 来启用经典模式，因为我希望不用修改 DotNetNuke 4.7 即可在 IIS 7.0 上运行它。
图 4 以集成模式运行 DotNetNuke 时的诊断信息（单击此图像可查看大图）

IIS 体系结构
您可能很想知道什么是集成模式和经典模式，以及它们为什么会影响 ASP.NET 应用程序 (DotNetNuke) 而不影响 PHP 应用程序 (osCommerce)。要更好地理解这一点，您必须首先了解一下 IIS 7.0 的体系结构。以前的版本主要通过 ISAPI 扩展 (aspnet_isapi.dll) 将 ASP.NET 运行时集成到核心 Web 服务器当中。而 IIS 7.0 允许 ASP.NET 模块通过一个名为 ManagedEngine 的全局 HTTP 模块（它将 ASP.NET Support DLL (webengine.dll) 加载到 IIS 7.0 请求处理管道中）直接插入到核心 Web 服务器中。
本机模块使用 IIS Web 服务器核心 API 来在管道中注册特定事件，如 BeginRequest、AuthenticateRequest、AuthorizeRequest 和 ExecuteRequestHandler。ManagedEngine 还提供必要的支持来将 ASP.NET 模块集成到请求管道中。通过使用该新体系结构，IIS 7.0 可以在处理请求的过程中随时调用本机和 ASP.NET 模块，而不用考虑所请求的内容类型。
例如，让我们来看看 ASP.NET 用户身份验证。在 IIS 6.0 中，基于 ASP.NET 的 HTTP 模块可以注册 OnAuthenticate 事件（如 FormsAuthentication.OnAuthenticate 和 WindowsAuthentication.OnAuthenticate）以设置当前 HttpContext 中用户的身份。这种方法在 ASP.NET 运行时内部非常奏效，但您无法使用该 ASP.NET 代码来保护通过基于 PHP 的 Web 应用程序公开的资源。
根据其 scriptmap 配置，IIS 6.0 将 ASP.NET 内容类型的请求转发到 aspnet_isapi.dll，但它不会将 PHP 内容类型的请求转发到 ASP.NET 的 ISAPI 扩展。毕竟，ASP.NET 无法处理 PHP 代码，但它同样也意味着如果请求的是 PHP 页面，那 ASP.NET 身份验证代码将无法运行。因此，使用 IIS 6.0 时需复制身份验证逻辑，因为 PHP 应用程序必须实施自己的身份验证机制。
IIS 7.0 使用事件驱动型处理模型，该模型支持在请求管道中混合和匹配各个模块。IIS 7.0 还另行附带了受管 WindowsAuthentication 和 FormsAuthentication 模块，当请求管道触发 AuthenticateRequest 事件时，这些模块会启动 OnAuthenticate 事件。现在，可使用本机模块（如 RequestFilteringModule 或 IpRestrictionModule）处理 BeginRequest 事件以尽早地拒绝关键请求，然后运行 AuthenticateRequest 事件中的自定义 ASP.NET 身份验证代码并让 FastCgiModule 运行 ExecuteRequestHandler 事件中的 PHP 脚本引擎 (php-cgi.exe) 来处理 PHP 页面。
这种集成体系结构使得 Web 开发人员不必复制代码来实现常见的业务逻辑。可使用自定义 ASP.NET 身份验证代码保护包括 PHP 应用程序在内的所有 IIS 资源。还可通过 ASP.NET 模块执行其他处理前和处理后任务，如 URL 重写、自定义跟踪和错误日志记录。

集成模式和经典模式
此新体系结构的副作用是可能需要应用程序开发人员更改现有 ASP.NET 应用程序的代码和配置，以确保该更改不会导致请求管道中发生模块冲突。但如果无法立即更改某个现有 Web 应用程序，则可在工作进程运行 Web 应用程序所用的应用程序池中启用经典模式。IIS 7.0 不会将 ManagedEngine 加载到经典模式的工作进程中，即，此时请求管道无法解析或调用 ASP.NET 模块。IIS 7.0 会激活大量基于 IsapiModule (aspnet_isapi.dll) 的 ISAPI 处理程序来按照类似 IIS 6.0 的方式处理 ASP.NET 内容类型。如果分析 applicationHost.config 文件（默认位于 %WinDir%\System32\InetSrv\Config 文件夹中）system.webServer 下的处理程序部分，您就会明白这种处理方式。
以搜索字符串 aspx 为例，您将找到一个指向 PageHandlerFactory-Integrated 的条目（根据设置 preCondition="integratedMode" 加载到集成模式的应用程序池工作进程中）以及指向 PageHandlerFactory-ISAPI-2.0 和 PageHandlerFactory-ISAPI-2.0-64 的其他条目（根据设置 preCondition="classicMode" 加载到经典模式的应用程序池工作进程中）。
由于管道模式是在应用程序池级别设置的，因此 IIS 7.0 可同时以集成模式和经典模式运行 Web 应用程序。并且，工作进程仅需在不同应用程序池中运行，但可托管在同一台服务器上。
请记住，集成模式和经典模式仅影响 IIS 7.0 将 ASP.NET 集成到请求管道的方式。这些管道模式不会直接影响 PHP 应用程序。无论使用的是集成模式还是经典模式，加载 FastCgiModule 和所有其他本机模块都不需要管道模式预处理。FastCGI 是在 IIS 7.0 上运行 PHP 脚本引擎的首选接口。如果不使用 FastCGI，也可通过 CGI 为 PHP 脚本引擎创建一个处理程序映射，或者可将 IsapiModule 与 PHP-ISAPI (php4isapi.dll) 结合使用。
但是，我认为这些 IIS 6.0 式的配置备用方法现已过时，因为 FastCGI 在性能和稳定性方面均提供了实质性改善。IIS 必须为每个 HTTP 请求初始化新的 CGI 进程，而 FastCGI 则针对多个请求重用 CGI 进程，因此 CGI 相对较慢。ISAPI 需要线程安全的 PHP，而这比运行非线程安全的 PHP 开销更大。
或许更为重要的一点是：线程安全版本中并未提供所有的 PHP 扩展，而使用 ISAPI 运行非线程安全的扩展并不是个好主意，因为它可能导致服务器出现稳定性问题。而 FastCGI 是一个与 CGI 类似的单并发环境。FastCGI 用于运行非线程安全的 PHP 时既稳定又快速，因此它显然是在 IIS 7.0 上运行 PHP 5 的最好方法。如果尚未准备好转换到 IIS 7.0，也可在 IIS 6.0 上使用它。

模块和功能
IIS 7.0 以高度模块化的体系结构（或者按照 IIS 开发人员的话来说，组件化的功能集）而著称。这对于希望使 IIS 7.0 的内存占用量和攻击面尽可能小的 Web 管理员来说是一个好消息。通过启用不同的模块甚至将标准模块替换成自定义模块，就可以完全控制 Web 服务器上的 IIS 7.0 功能。
要以集成模式或经典模式运行 ASP.NET 以及同一台服务器上的 PHP 应用程序，必须至少安装 Web 服务器角色和核心模块以支持请求处理、服务器配置、ASP.NET、ISAPI 和 CGI（它包括了 FastCGI 模块）。通过以下命令行即可实现：
start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI
我通常更喜欢在阶段服务器上安装 IIS 7.0 及所有的可用选项，以确保所有组件和管理工具均可用于快速启动并运行 Web 应用程序。我的策略是先确保一切运转正常，然后通过卸载角色服务和禁用模块来缩小配置。当 Web 应用程序开始工作不正常时，我就把刚才卸载的角色服务或模块添加回去。
也可选择使用包管理器 (pkgmgr.exe) 或 IIS 7.0 命令行工具 (appcmd.exe)，或者直接编辑 applicationHost.config 文件的 globalModules 部分，但我发现图形工具更为方便。请记住，有些模块（如 RequestFilteringModule 和 StaticCompressionModule）非常有用，尽管严格来说它们并非运行 Web 应用程序所必需的模块。如果卸载了应用程序池需要的模块，那么在访问 Web 应用程序时，您会收到一个 HTTP 错误（如图 5 所示）。
图 5 由于缺少 IsapiModule，ASP.NET 应用程序无法在经典模式下运行（单击此图像可查看大图）
备注：最佳做法是，确保在所有 IIS 7.0 服务器上都安装和启用了相同的模块组。要确认已安装的组件，请转到 HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\ 并检查注册表项。如果注册表项（如 NetFxEnvironment 或 CGI）的 REG_DWORD 值为 0000 0001，则表示已安装对应的组件。

Web 应用程序迁移
鉴于已掌握足够多的理论知识，现在就可以着手将一些 Web 应用程序迁移到 IIS 7.0了。如前所述，我的阶段服务器运行 IIS 7.0 的所有可用组件以及使用 FastCGI 注册的非线程安全 PHP 5。在开始之前，我需要询问以下几个基本问题：
  • Web 应用程序是否需要数据库管理系统（如 SQL Server 或 MySQL）？
  • 是否需要安装或配置其他组件（如 ODBC 连接、COM 对象或 SSL 证书）？
  • Web 应用程序是否需要特殊的服务帐户以及提升对文件共享和其他资源的本地或远程访问权限？
  • 某个平台专用功能的依赖关系是否在 IIS 7.0 上变得无法使用（例如依赖 Apache 模块来执行 URL 重写 (mod_rewrite)）？
询问此类问题可有助于更快地将 Web 应用程序迁移到 IIS 7.0 上。例如，如果尝试从使用 mod_rewrite 的 Apache 2.2 迁移某个 PHP 应用程序（比如为了得到友好的搜索引擎或预防通过内联图像发起的带宽攻击），那么必须在 IIS 7.0 上部署兼容的自定义 URL 重写解决方案，才能避免出现问题。幸运地是，osCommerce 在 IIS 7.0 上不需要使用 mod_rewrite 功能，但某些搜索引擎优化数据包却可能会使用该功能。
既然已确定并在阶段服务器上安装了所需的其他组件，那么我已准备好启动并运行 Web 应用程序。同样，我还想问自己几个问题：
  • 可使用哪些最简单的配置来支持 Web 应用程序？
  • 生产环境中目前使用的是些什么配置？
  • 我能否在新平台上优化 Web 应用程序配置？
  • 能够使 Web 应用程序在理想配置下正常运行的最小角色服务和模块集合是什么？
以最简单的配置运行 Web 应用程序是验证其是否有效的一种快速方法。如果一切正常，就可以将类似配置应用到现有生产环境并将生产数据导入到测试数据库中。当然，某些问题可能仅会在高级配置时才会浮现出来。
在测试实验室中镜像生产配置时，也可能找到改进的机会。将 applicationHost.config 文件放在 UNC 共享中很适合集中多台 Web 服务器的配置。要通过冗余和内容同步来提高容错能力，可考虑实施分布式文件系统 (DFS) 复制（它是一种 Windows Server 2003 R2 和 Windows Server 2008 中提供的基于状态的多主机复制引擎）。还可通过将 Web 应用程序的内容文件放在 UNC 共享上来最小化 Web 前端的存储需求。
其他优化方法可能会涉及到安全性或动态缓存。我并未在测试实验室中考虑安全性和性能方面的优化，因为它超出了本文的讨论范畴。我也没有配置 DFS 来避免安装更多服务器。随附材料中的分步说明简要示范了如何在 UNC 共享上托管 applicationHost.config 文件和 Web 内容。图 6 说明了如何使用 DFS 实现基于 UNC 的 Web 场。
图 6 将 applicationHost.config 文件和 Web 内容放在 UNC 共享上的 Web 场部署（单击此图像可查看大图）

结束语
IIS 7.0 是一个令人印象深刻的 Web 服务器平台。它的特色是重新设计了核心体系结构，同时几乎 100% 地向后兼容 IIS 6.0。它应该能够做到无需修改即可运行大部分现有的 ASP.NET Web 应用程序。但由于体系结构的更改较大，因此很可能会遇到兼容性问题。
无论是将 ASP.NET 还是 PHP Web 应用程序迁移到 IIS 7.0，最好都采用分步式方法，并且注重正确的规划、准备、测试以及记录代码和配置更改。
IIS 7.0 会令工作物有所值。它在安全性、性能、可配置性和灵活性等方面都进行了许多改进。要讨论完所有这些内容可能需要编写一本书。基于 UNC 共享的集中式配置和内容共享、通过应用程序目录中的 web.config 文件实现委派配置、改进的管理工具、详细的诊断信息和失败请求跟踪以及动态输出缓存都是赢得 Web 管理员欢心的出色方法。
在请求处理管道中混合本机和托管模块的功能可使 ASP.NET 开发人员受益颇多。并且，IIS 7.0 上的 FastCGI 在性能和稳定性方面的改进令 PHP 应用程序开发人员倍感欣慰。
而且，还有一项能够帮助 IT 专业人员成功应用 IIS 7.0 的重要工具：那就是 Microsoft IIS 社区门户网站 (www.iis.net）。它包含您需要的所有信息，包括有关新体系结构的详细说明文章、向 C++ 和 ASP.NET 开发人员展示如何创建 IIS 7.0 模块的源代码以及用于启动并运行 PHP 应用程序的分步说明。您肯定会用到该网站。它是为您回答 IIS 问题的首选途径。

Fergus Strachan 是 Maestra Ltd London 的创始人和董事，该公司是一家专门从事 IT 基础结构设计和项目管理支持的咨询公司，向英国的国际银行和教育机构提供服务。他撰写过多篇有关 Microsoft 服务器技术的文章，并且是《Integrating ISA Server 2006 with Microsoft Exchange 2007》一书的作者。还是《Microsoft Exchange Server 2003 Resource Kit》的合著者。

© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利；未经允许不得复制本文的部分或全部内容。


沟通与协作
规划向统一消息的迁移
Jeff Goodwin
概览：
  • 语音邮件简介
  • 规划迁移时的注意事项
  • 迁移策略
  • 多站点的难题

目录
语音邮件简介
规划迁移
实用的迁移策略
迁移演练
遵循规划的重要性
从传统的语音邮件系统迁移到统一消息平台是一个极具挑战性的项目。但通过一些正确的规划，就可以非常轻松地完成该迁移，尽可能减少最终用户可能遇到的中断。事实上，
将服务中断降至最低可能是您在执行此类迁移项目时的首要目标。
要明确迁移过程中需要规划哪些内容，必须首先了解公司将语音邮件视为关键任务应用程序的原因。这一基本信息将有助于您了解在迁移到“统一消息”时需要实现哪些功能以及这些功能对于管理员来说十分重要的原因。

语音邮件简介
不知起点，就不知所终，因此我先简要回顾一下语音邮件系统的起源以及构建方式。谁是第一个发明语音邮件系统的人至今仍存有争议。但是，第一款商用语音邮件系统是 VMX，表示“语音消息交换”(Voice Message Exchange)。
VMX 最初设计用于提供一种通过语音与公司内的其他人员进行交流的方法，就像现在使用的电子邮件一样。该系统包含用于发送消息、转发消息以及回复消息的命令。如果有留言，系统会通知用户。通知的方法有很多种，包括外部呼叫（使用特定电话号码致电用户）和留言灯（用户电话上的指示灯）。
随着 VMX 的逐渐普及，许多组织开始着手实现语音邮件系统的联网。这样就形成了一个企业范围的语音邮件解决方案，员工可通过它向公司通讯组列表发送广播消息。
为了能与语音邮件系统进行交互，按键式用户界面 (TUI) 随即应运而生。这些 TUI 随着时代的变迁而不断变化，但遗憾的是，至今仍没有标准的语音邮件界面。如果手机上有语音邮件，您可能对听到诸如“收取语音邮件请按 1”之类的提示习以为常了。但随着使用语音用户界面 (VUI) 的话音驱动语音邮件系统的逐渐普及，TUI 本身的重要性已不比从前。可是，不应低估用户可能对某个特定界面产生的依恋。
现在使用的企业语音邮件系统依赖于两种截然不同的体系结构：分布式和集中式。在图 1 中，西雅图、纽约和奥斯汀的办事处都使用分布式语音邮件体系结构，即每个站点都有语音邮件系统。相反地，伦敦、巴黎和格拉斯哥的办事处使用的是集中式模式，即 PBX 基础结构是联网在一起的，并且所有呼叫都会路由回位于伦敦的中心位置。两种模式都各有优缺点。但请注意，即使在分布式模式中，语音邮件系统也可联网在一起以实现站点之间的消息传递。
图 1 两种常见的语音邮件体系结构模式（单击此图像可查看大图）
组织选择使用分布式模式可能主要有以下三个原因：本地使用需要、各种不同的 PBX 系统无法联网、以及统一拨号计划限制。
一些组织对语音邮件系统的要求是：网络出现故障时，本地 PBX 和语音邮件系统仍可正常运行，确保站点保持完整的系统功能。交互式语音响应 (IVR) 系统仍可正常运行，同时外部的呼叫者仍可留言。最终用户实际不受任何影响，工作可照常进行。听起来可能有些耳熟 – 许多组织选择本地运行 Microsoft® Exchange Server 执行服务器也是出于相同的原因。组织可能希望通过风险评估来确定这种策略的必要性。
当组织由于收购而逐渐壮大时，远程站点的一些 PBX 平台常常无法与基础结构的其余部分联网。此时，组织可更换掉该 PBX，但这样成本极高；或保持这些站点不动并联网语音邮件系统以提供无缝的语音消息交换。第三方服务器也可帮助您联网完全不同的语音邮件系统。
要联网多个 PBX，需要一个统一拨号计划（即 UDP）。UDP 规定电话和语音邮件分机不能重叠。在图 1 中，您会发现西雅图、纽约和奥斯汀有重叠的分机号。这是因为美国的站点没有启用 UDP。可通过将分机范围扩大到 7 或 10 位来创建 UDP，但此操作会带来其他问题。
您可能必须更改每部电话上的拨号模板、更改 PBX 上的所有用户分机以及更改与该系统集成的所有应用程序。并且，它可能致使员工产生用户挫折感，因为他们现在必须记住并拨打 7 或 10 位的电话号码才能与楼下的某人通话。
尽管多年来一直在改进这些基本功能和体系结构难题，但语音邮件的本质依旧未变。消息交换、联网、通知方法、用户界面和体系结构都是您在规划迁移时必须牢记的重要因素。

规划迁移
“统一消息”更改了组织的方方面面 – 从用户与语音邮件的交互方式，到体系结构的设计方法，再到管理员的管理方式。在向统一消息系统迁移时，必须消除所有这些差异。下面这个检查表列出了在规划迁移时需考虑的事项。
消息联网 从传统语音邮件平台转换到“Exchange 统一消息”的所有组织都必须有一个共存期。如果组织已部署消息联网（一个互操作不同语音邮件系统的系统），只需将“统一消息”系统添加到现有系统列表即可。对于在多个位置使用单独的语音邮件或 PBX 系统的组织，强烈建议部署消息联网。
基础结构 设计“统一消息”的基础结构需要您决定联网要求、电话集成、服务器安置等问题。如果还不了解基本的部署策略，请阅读本人先前撰写的文章“使用 Exchange Server 2007 部署统一消息”（网址为 technet.microsoft.com/magazine/cc137737）。
自动助理 许多系统都包含多个自动助理，不同的助理适用于白天、夜间以及不同的部门。您需要与组织的电信小组协同工作以镜像传统语音邮件系统上的自动助理。
消息等待指示 您可能希望解决方案不需要消息等候指示器，但您的用户可能需要该功能。因此，千万不要低估用户对该红色指示灯通知的依赖程度。幸运地是，许多公司都开发了适用于 Exchange Server 的消息指示器应用程序。
传真支持 很多传统语音邮件平台都支持入站传真。Exchange 统一消息也支持入站传真功能，因此您可能希望在新部署中规划支持该功能。
交互式语音响应 某些传统语音邮件平台支持 Exchange 统一消息无法复制的交互式语音响应 (IVR) 应用程序。您可能希望在找到合适的替代方案之前先保留这些系统。
管理 Exchange 统一消息依赖于 Active Directory® 和 Exchange 邮箱服务器角色。您需要规划统一消息部署对管理、系统要求等的影响。
用户界面 在实施新 UI 时，必须对用户进行培训。Exchange 统一消息使用的界面与大多数手机界面极为相似，因此对于大多数用户而言它非常直观。它还使用语音识别，因此用户无需再使用按键。在 Exchange Server 中，此功能称为 Outlook® Voice Access。
培训 统一消息带来了用户沟通和使用语音邮件方式方面的模式转变。除 UI 外，还必须向用户提供培训，以教授最佳实践并展示更加有效的新沟通方法。例如，用户可能并不了解如何与收件箱中的语音邮件交互或者如何配置某些高级的统一消息设置。

实用的迁移策略
在将大型组织迁移到统一消息解决方案的过程中会遇到很多难题，这一点毋庸置疑。然而，在 10 年的统一通信从业过程中，我曾遇到过具有极为特殊要求的最复杂组织成功实现迁移的案例。
无论是单站点或是多站点组织，只要围绕以下五个基本步骤构建迁移策略，都会有所帮助。
  1. 规划和设计解决方案。
  2. 安装和配置统一消息服务器角色。
  3. 迁移试验组。
  4. 根据试验组的反馈修订设计。
  5. 迁移用户。
当然，多站点组织确实会面对在单站点情形中通常不会遇到的一些难题。我将在“多站点的难题”侧栏中单独介绍这些难题。
在迁移过程中，规划和设计解决方案是最为重要的步骤。建议为此项目分配一个“统一消息”团队。此团队应包括来自组织的各个部门且具有电信、Active Directory、Exchange、联网、安全、培训和项目管理专业知识的代表。然后，绘制一张公司现有的 PBX、语音邮件和电子邮件基础结构的详细体系结构图。
完成设计后即可安装和配置统一消息服务器角色。统一消息服务器可与现有的传统语音邮件系统并行安装。只需确保遵循所记录的最佳实践即可。
此时，您已准备好试用统一消息服务器。指定一个小型试验用户组，并将其迁移到新系统。组中包含 25 到 50 名用户即可。慎重地选择这些用户，从而创建一个由各种用户（IT 和电信员工、部门经理和销售人员）构成的试验组。通过包括如此众多的人员，可更好地确定设计是否切合目标、需考虑哪些特殊要求以及必须向用户提供哪些培训等。
收到试验组的反馈后，需修改设计以解决在测试过程中发现的所有问题。更具体地讲，重新审查我在“注意事项”中介绍的各个项目，并确保已针对您的组织适当地解决了这些要点。请注意，这里所做的最常见更改通常是为了培训。
最后一步是迁移用户。将系统迁移到整个生产环境中有多种方法和策略。其中两种主要方法是逐步迁移和快速切换。
如果选择在数周或数月时间内逐步迁移用户社区，需在原有用户和统一消息用户之间创建语音邮件岛。从而阻止用户通过语音邮件彼此转发消息。如果设计并不包括消息联网解决方案，则某些业务通信会中断。如果打算使用此方法，建议务必在初始设计中包括一个消息联网解决方案。
快速切换迁移是一次性移走所有用户。通常，组织会在周末执行此类迁移，这样他们就有足够的时间测试系统、进行配置更改并在遇到严重阻碍时撤销迁移。
无论您选择哪种方法，都务必要针对常见问题和从实验组中收集的答案对技术支持人员进行培训。还应确保技术支持人员精通于执行关键任务，包括启用用户、验证某个用户是否已启用以及更改密码。

迁移演练
在执行示例迁移的过程中，应牢记成功迁移到统一消息的主要目标是将用户的语音邮件箱从传统的语音邮件平台移到统一消息中，并且尽可能少地中断内外部用户。
图 2 详细说明了一家组织的体系结构。它不想更改这一混合 Exchange 体系结构。位于美国的多家办事处使用西雅图的主数据中心。奥斯汀的所有 IT 应用程序均由西雅图提供服务，而纽约办事处则保证本地的 Exchange 服务。美国区域内的语音邮件都利用完全不同的 PBX 基础结构进行分发。从技术上讲，无法联网 PBX 基础结构以提供集中式语音邮件。与之相反的是，欧洲的办事处则使用位于伦敦的集中式数据中心。欧洲的所有 IT 和电信应用程序都由该中心数据中心提供服务。
图 2 迁移前的示例体系结构（单击此图像可查看大图）
整个语音邮件的基础结构基于 Octel（现在称为 Avaya）平台。使用 Octel 模拟联网 (OAN) 实现所有语音邮件系统的联网，Octel 模拟联网 (OAN) 是一种专有联网协议，利用模拟电话线和长途电话来发送联网的语音邮件消息。该体系结构允许在站点之间传递公司内的语音消息。
多站点的难题
多站点组织在部署统一消息时会面对多种难题。幸运地是，可从其他组织已遇到的难题中了解到一些有用的信息。我无法在本文中罗列出所有的难题，但我可以将自己在与各种组织打交道时遇到的最常见问题介绍给您。
“我使用的是集中式 Exchange Server 体系结构和混合式电话环境。”
分布式环境比较容易设计。将统一消息服务器放在每个站点上，并将其与本地 PBX 集成。但如果使用集中式甚至是混合式环境时呢？您需要确定是否要在站点上本地留存统一消息。如在本地留存统一消息，该区域可能无法与集中式 Exchange 服务器相连，但仍提供自动助理功能且允许外部呼叫者（极有可能是客户）留言。具体方法取决于该区域中任务的重要性以及解决方案的可管理程度。
如果需要站点具备本地留存特性，在站点上安装远程统一消息服务器将是一个不错的选择。如果不需要，则可在本地站点上安装一个 SIP 网关。Exchange 统一消息非常灵活，因而并不需要联网 PBX 基础结构，也不需要统一拨号计划。
“我正在升级 Exchange 体系结构。”
许多客户正在升级 Exchange 体系结构，因而非常犹豫是否应开始“统一消息”迁移。我的建议是如果您已决定使用统一消息，那么应在升级 Exchange 服务器的同时执行迁移。只需履行您的升级计划即可，它应该不会增加此项目的复杂程度。
“我有很多不到 10 个人的小型站点，并且其中有些站点没有 PBX。”
对于现场有 PBX 的小型站点，只需在本地站点上安装 SIP 网关即可。对于现场没有 PBX 的站点，可使用电话技术将电话转发给中央 PBX 以将呼叫路由给统一消息系统。简而言之，可以用相当低的成本将统一消息服务部署到组织的小型远程站点中。
值得注意的一点是，这些小型站点实际上提供了一个极好的迁移测试平台。一个常用的迁移策略是从网络的边缘开始迁移，然后转移到核心。首先迁移小型站点，然后与统一消息团队进行总结以了解哪些方面进展顺利，同时遇到了哪些难题。然后在迁移下一个站点时吸取这些学到的经验。
统一消息团队决定从网络的边缘开始迁移到核心。对于所有区域，统一消息服务器的放置都将遵循以下 Exchange 服务器体系结构。团队为每个站点构建自己的规划文档，并且牢记在“注意事项”部分中介绍过的事项。在安装和配置服务器的过程中、用户培训过程中以及规划迁移策略时都会用到该文档。
对于每个站点，团队计划将用户快速切换到统一消息系统，同时保留传统平台以支持在找到替代解决方案之前仍会使用的 IVR 应用程序。团队决定在迁移后先等待 30 天再继续迁移下一位置。这一等待期旨在确保在移动更多用户和添加更多技术支持电话之前每个站点都已适应新平台。
组织决定首先迁移奥斯汀办事处。由于奥斯汀是由西雅图提供电子邮件服务，团队在西雅图安装统一消息服务器角色，并通过在奥斯汀安装 SIP 网关来提供 PBX 集成。由于传统语音邮件平台是联网的，团队必须通过安装消息联网服务器来解决统一消息平台的联网需求。 用户已接受新系统培训并且迁移非常顺利，因此团队决定接下来迁移纽约。
纽约办事处拥有自己的邮箱服务器和集线器传输服务器。因此，最佳实践应该是将统一消息服务器安装在纽约。团队遵循迁移规划文档安装该服务器。把该服务器添加到消息联网服务器内的节点列表内，该服务器位于语音邮件网络中。用户已接受培训且顺利地迁移到统一消息。
西雅图办事处已拥有在奥斯汀迁移阶段中所部署的统一消息服务器。团队确定该服务器的语音邮件端口足以支持西雅图和奥斯汀办事处。西雅图的用户已接受培训且迁移到统一消息。
欧洲的体系结构设计起来则要简单得多。PBX 基础结构已联网且 Exchange 为集中式。在伦敦部署统一消息服务器，然后从最小的站点开始迁移各个站点。图 3 说明了最终的体系结构。
图 3 迁移后的示例体系结构（单击此图像可查看大图）

遵循规划的重要性
我应邀解决了很多失败的统一消息迁移。许多组织都违反了一个或多个关键规则。
首先，应始终牢记它并不仅仅是一个语音邮件系统。它是一个关键任务应用程序，具备对应的特点。用户们依靠语音邮件技术来交换信息。请记住它是一个业务应用程序，迁移规划要考虑到我在本文中介绍过的所有注意事项。
向统一消息执行任何迁移均必须有电信团队的参与。电信团队最了解集成到公司基础结构中的电话应用程序。
在向统一消息迁移时，请制定企业解决方案规划。一开始可能只完成了单个站点迁移，但应始终在头脑中保持一个整体概念。例如，完成单个站点迁移却不向其他站点提供消息联网将会影响用户之间的通信。当然，它可能是一项艰巨的任务，所以请尽量向专家咨询，这样才能设计出考虑了所有 IT 应用程序的体系结构。
最后，切勿低估培训的重要性。统一消息转变了用户与语音邮件沟通和交互的模式。某些您看起来很明显的东西，对其他人却不一定显而易见。良好的培训是实现最顺利转换的关键所在。

Jeff Goodwin 是 VIA 组的高级技术专家，擅长 Exchange 和统一消息设计和部署。您可以通过 jgoodwin@theviagroup.com 与他联系。


沟通与协作
OCS 2007 如何利用语音功能
Rajesh Ramanathan
概览：
  • 在 OCS 2007 中进行呼叫
  • 如何保证呼叫的安全
  • OCS 中执行多模会话
  • 与 Exchange UM 集成以发送语言邮件

目录
基本语音呼叫
使用电话号码
保护呼叫
穿越 NAT 和防火墙
根据电话号码路由
入站路由
质量报告和故障排除
组合
多模行为和会话
语音邮件
结束语
Microsoft Office Communication Server (OCS) 2007 系列文章的第一部分讲述了如何博采 Live Communication Server (OCS) 2005 之长构建 OCS，
以提供更强大的企业级即时消息 (IM) 和状态显示功能，以及高级媒体和电话功能（请参阅 2008 年 2 月刊的《TechNet 杂志》，网址为：technet.microsoft.com/magazine/cc194409）。本文将继续深入探讨 IP 语音 (VoIP) 方面的内容。我将解释在 OCS 系统中进行语音呼叫有多么简单，并分层介绍技术，以便随同对应的功能展示每个组件。
如之前文章提到的，可通过以下多种配置设置 OCS 向用户提供电话功能：
企业语音 它是一个使用 OCS 和 Microsoft® 中介服务器的完整统一通信解决方案，无需 PBX。Exchange 统一消息 (UM) 在此系统中提供语音邮件功能。从现在起，我将具有此服务的用户称为“UC 用户”。我还将使用术语“UC 端点”来指代此配置中的客户端。
集成了 PBX 的企业语音 此配置使用户在保留桌上现有 PBX 电话的同时从统一通信中受益。它允许并行设置 OCS 和 PBX，这样传入呼叫可同时对 Office Communicator 和 PBX 端点振铃。PBX 仍拥有呼叫路由且仍提供语音邮件服务。
远程呼叫控制 此功能将 PBX 电话用作主电话，并且允许通过 Office Communicator 客户端控制电话。

基本语音呼叫
在此我将重点介绍企业语音用户的工作机制。如 RFC 3261 所述，利用 SIP INVITE 机制在 OCS 系统中设置简单语音呼叫。OCS 服务器承担类似邮局主管的代理角色，在客户端（或端点）之间转播消息。只要创建实时会话（如呼叫或即时消息会话），客户端就会生成新的 SIP INVITE。如果通过应答（即，远程端点发送一个 200 OK 响应）确认 INVITE，即建立起呼叫（请参阅图 1）。
图 1 INVITE 格式和 200 OK
INVITE sip:bob@example.com SIP/2.0
To: <sip:bob@example.com>
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:alice@xyz.example.com
Content-Type: application/sdp
Content-Length: 156

**Note: Alice Audio SDP payload not shown**

SIP/2.0 200 OK
To: <sip:bob@example.com>;tag=f5c728454a;epid=e73443245
From: <sip:alice@example.com>;tag=5c5ffe5428;epid=d793aff63a
Call-ID: 3522acd5acd349b4855871e3100a5f4f
CSeq: 2 INVITE
Contact: sip:bob@xyz.example.com
Content-Type: application/sdp
Content-Length: 160

**Note: Bob Audio SDP payload not shown**
在图 2 中，Alice 通过在 Office Communicator (OC) 2007 中选择 Communicator Call 来呼叫 Bob，OC 2007 产生一个发往 Bob 的 SIP 统一资源标识符或 URI (sip:bob@example.com) 的 INVITE。INVITE 带有媒体端点（Alice 用于接收音频）的音频会话描述符（称为 SDP，代表 Session Description Protocol）。OCS 将 INVITE 插入 Bob 注册的 SIP 端点（例如，Communicator Phone Edition 和 Communicator 桌面）。INVITE 包含“发件人”标头 sip:alice@example.com；Bob 的客户端端点在反向名称查找 (RNL) 中使用它来查找名称 (Alice)，将其显示在传入呼叫通知中。
图 2 将呼叫路由到多个端点（单击此图像查看大图）
每个端点均显示有可全局路由用户代理 URI (GRUU)。GRUU 是 SIP 端点的唯一标识，它是在从 OCS 服务器注册的过程中获取的。GRUU 地址有助于路由 SIP 消息，因此一旦端点回答呼叫，就可直接使用 GRUU 地址在端点之间传送其他转换操作的后续 SIP 信号。
图 3 是后续过程，Bob 通过 Communicator 桌面进行应答。Bob 的 OC 发送一个 200 OK 消息来说明他接收音频的位置。一旦 OCS 代理检测到有端点做出了应答，它将取消对其他 Communicator Phone Edition 端点的呼叫。200 OK 响应到达 Alice 的 Communicator 端点后，两个 Communicator 端点均拥有充足的信息（IP 端口、加密参数等）来启动媒体。
图 3 从一个端点做出应答（单击此图像查看大图）

使用电话号码
到目前为止，我们看到了用户单击 Communicator Call 创建邀请。该过程与用户选择或键入电话号码时的情形有所不同：
  • 客户端首先规范化电话号码并将其显示为 TEL URI（它根据 RFC 3966 的指示描述了电话号码所标识的资源）。
  • 由于 OCS 服务器仅识别 SIP URI，因此客户端通过添加域后缀和 user=phone 标记来将 TEL URI 转换成对应的 SIP URI。
  • 如果号码对应于内部用户，OCS 将直接路由邀请。如果为外部号码，邀请将路由到最近的 SIP-PSTN 网关。
对公共交换电话网络 (PSTN) 号码的某些呼叫要求在应答呼叫前建立媒体路径，这样才可播放远程通知或收集其他数字以完成呼叫。在此类情形下，PSTN 网关发送一个 183 会话进度指示符和一个音频 SDP。Communicator 使用此信息来在远程用户应答呼叫之前与一个目标端点建立双向媒体路径。
一旦之前的所有媒体路径均建立完毕，Communicator 将启用双音多频或 DTMF（电话信号音）键盘，这样用户可输入远程系统需要的任意其他数字。输入的所有 DTMF 数字均在媒体路径中作为 RFC 2833 数据包发送。PSTN 网关负责在 PSTN 端生成适当的 DTMF 语音信号。
请注意，如果 Bob 启用了对手机的同时振铃，OCS 代理将把呼叫路由到网关，并同时振铃 Bob 的其他 Communicator 端点。在此类情形中，OCS 代理指出插入在 183 会话进度响应中为活动状态，这使 Communicator 与 PSTN 网关建立一个仅执行接收的媒体通道。

保护呼叫
OC 建立的语音呼叫的一项关键功能是默认根据 RFC3711 中的定义使用安全实时传输协议 (SRTP) 来加密媒体。SRTP 提供机密性、消息身份验证和对 RTP 通信的重播保护。在建立呼叫的过程中，客户端自身之间协商安全功能，并根据 INVITE 机制交换加密密钥。
OC 的默认加密设置为“可选”，它允许两个 OC 端点建立加密的媒体通道。管理员可调整此设置以保证组织遵章守法。例如，可将其设置得更加严厉以强制对所有呼叫进行加密，或者全部关闭。

穿越 NAT 和防火墙
OCS 系统中的客户端使用交互式连接建立 (ICE) 技术来向网络地址转换 (NAT) 设备和防火墙后面的用户提供媒体连接性能，无需更改现有 NAT 组件。ICE 技术目前正由 Internet 工程任务组 (IETF) 进行标准化。每个客户端均了解通过区内置备机制为其提供服务的音频/视频 (A/V) 边缘服务器，并且在登录过程中维持到 A/V 边缘的验证链接。
在进行呼叫之前，客户端会在 A/V 边缘服务器（对于媒体中继）、NAT 或主机客户端本身的可能连接性位置（地址和端口，也称为候选对象）上分配资源。在发出会话初始协议 (SIP) INVITE 时，它会将此连接性信息包含在内。200 OK 应答携带对等方的类似候选对象信息。一旦每个端点都拥有一个对等候选对象列表，随后，完善的排名和检查机制就会选择两个对等方之间的最优路径，从而保证媒体的成功。

根据电话号码路由
由于以下因素，根据电话号码路由比基本呼叫机制更复杂：
  • 组织可能有各种拨号计划，它们部署在内部，用于快速拨号。
  • 号码可能以非标准格式存储（例如，用户可能在 Microsoft Office Outlook® 中保存七位字符串）。
  • 存在多种映射到不同外部号码的策略。例如，可能阻止某些用户拨打国际长途。
OCS 系统要求电话号码为 RFC 3966 TEL URI 格式，这样才能正确路由它们。不是这种格式的号码需先进行转换，然后客户端才发送 INVITE。图 4 中的图表显示了 OCS 系统中的具体操作细节。
图 4 路由电话号码（单击此图像可查看较大视图）
客户端可用的号码可能来自各种来源。预规范化号码来自通讯簿服务 (ABS)（此服务使用管理员定义的规范化规则将号码转换成规范化的 E.164 格式）。一旦客户端向规范化号码发送 SIP INVITE，OCS 即应用转换过程来将号码映射成内部用户。
  • 第 1 步显示输入系统的号码或是唯一（规范化，遵循 E.164 编号规划），或具有标识位置的电话上下文。这些号码将包含在 SIP INVITE 之内，发送给服务器。OCS 将 INVITE 路由到一个转换过程。
  • 转换过程（第 2 步）尝试利用服务器侧的 RNL 将电话号码映射到 UC 端点。转换可将该号码的路由确定为某个出站路由或某个 UC 用户，如果无法正确转换号码，呼叫将失败且代码为 4xx。
  • 如果号码转换成非 UC 或外部号码，在针对与呼叫方相关的号码应用策略（第 3A 步）后，它将发送到出站路由组件，此组件将 INVITE 重定向到适当的 SIP-PSTN 网关以便执行进一步处理。出站路由负责均衡网关间的呼叫负荷，或在必要时故障转移到备用网关。如果禁止对某个号码的访问，出站路由过程可能失败、拒绝呼叫并返回一个 SIP 403 响应代码。请注意，出站路由仅适用于呼叫方为 UC 用户的情形。如果不是这样，OCS 会尝试使用对该 URI 所设置网关的静态路由。
  • 如果号码转换成 UC 用户的号码，INVITE 将路由到该用户的 SIP URI（第 3B 步）。入站路由是 OCS 的一项功能，仅适用于 UC 用户和目标为 SIP URI 的所有呼叫。正如您将看到的，入站路由将针对 UC 用户应用振铃超时、呼叫转发和语音邮件转发规则。
请注意，从规范化过程产生的号码可能由于客户端位置不同而有所不同。管理员可设定位置配置文件并分配特定于某个位置的号码转换规则（如四位拨号在该位置中的工作原理）。每个 UC 用户分配一个位置配置文件，系统中的所用客户端都使用区内置备来下载特定于自身位置配置文件的规则。接下来我将详细介绍入站路由。

入站路由
入站路由规则指定当系统中存在或不存在注册客户端时应如何路由到某个用户的呼叫。传入路由组件还负责根据显示状态向传入呼叫应用规则；例如，如果用户已将状态显示设为“请勿打扰”，则它可将传入呼叫发送到语音邮件。传入路由了解显示状态容器级别，并且自动拒绝来自阻止容器中用户的呼叫。图 5 显示了 OCS 入站路由组件支持选项的摘要。
图 5 入站路由功能
功能 | 注释
振铃持续时间 | 默认为 20 秒。用户最多可将其更改为 60 秒。达到此限值后呼叫将转到无人应答呼叫目的地。
将无人应答呼叫路由到语音邮件 | 如果对用户启用了语音邮件，则默认执行此操作。根据入站路由规则路由呼叫。
如呼叫方在呼叫到达语音邮箱之前挂机，生成“未接呼叫通知” | 通知 Exchange UM 此类未接呼叫。
呼叫阻隔 | 拒绝来自受阻止呼叫方的呼叫（仅阻止具有 SIP 标识的用户发出的呼叫）。
请勿打扰 | 将呼叫路由到语音邮件。如果用户处于此模式，同时振铃目的地将不会振铃。
允许打断列表 | 如果呼叫方处于“团队”容器中，将允许呼叫，即使用户已设成“请勿打扰”。
同时振铃 | 将传入呼叫配置成对 PSTN 电话号码以及 Communicator 和 Communicator Phone Edition 客户端振铃。
立即转发呼叫 | 立即向另一用户、PSTN 电话号码或语音邮件转发传入呼叫。
转发无人应答呼叫 | 将无人应答呼叫转给另一用户、PSTN 电话号码或语音邮件。
工作时间 | 使用在 Outlook 日历上配置的工作时间来激活用户的呼叫转发设置。
入站路由规则将包含在用户自置备信息之内，上载到服务器作为 XML 架构。图 6 展示了入站路由的工作原理。OCS 系统中某个用户的传入呼叫默认振铃此用户（显示为 "Me"）。如果未在振铃持续时间内应答呼叫，将默认向语音邮件发送无人应答呼叫。用户可选择立即转发到某个号码、另一个人或直接发到语音邮件来修改默认配置。
图 6 路由呼叫（在工作时间）（单击此图像可查看大图）
立即转发到另一个人或号码的任何呼叫均将导致该人员或号码的入站路由规则生效。用户也可设置到另一号码或人员的无人应答呼叫转发。
如果用户在转发规则内选中选项“仅在 Outlook 工作时间应用”，则将在工作时间应用图 6 中所示的规则，在其余时间默认振铃已注册端点。请注意，此行为要求组织部署了 Microsoft Exchange Server 2007 和 Outlook 2007 客户端，因为 Communicator 要使用来自 Exchange 2007 可用性 Web 服务的工作时间信息，并且利用 Outlook 2007 自动发现支持来获取服务器位置。

质量报告和故障排除
OCS 2007 系统中的客户端使用 RTAudio，尽管这种新一代的音频编码解码器可容忍不完美的网络状况，如抖动、数据包丢失等，但监视仍必不可少，这样管理员可找出并修复潜在的热点。OCS 2007 系统中的客户端在每次呼叫结束时向中央体验质量 (QoE) 服务器报告每个呼叫的质量，并提供详细的统计数据，包括带宽、丢失、抖动、平均意见分数（一种用户感受的度量方式）、使用的设备等等。其实现方式是将 SIP SERVICE 请求中的负载发送给 QoE 服务器（它的地址是利用区内置备机制编程确定的）。
请注意，所有客户端端点都是独立地向 QoE 服务器报告呼叫质量。如果由于信号中存在错误而导致呼叫失败，客户端也会向 OCS 报告同样的内容，提供一个存储库来存放客户端出现的所有错误。﻿

组合
既然已了解建立呼叫的各个方面（包括输入号码、入站和出站路由以及连接性检查），让我们来总体看一看这个过程。图 7 总结了从用户开始呼叫起所发生的情况。OCS 系统中的客户端在建立呼叫过程中起着至关重要的作用，它们管理整个呼叫建立过程。OCS 参与了呼叫的初始路由，边缘服务器帮助客户端查找最优的媒体路由。现在让我们来看看接下来发生的情况 — 会话。
图 7 端对端呼叫流（单击图像可查看大图）

多模行为和会话
会话概念是 OCS 系统的核心。会话是两个或多个人之间的多模会话，可同时包括语音、视频和 IM，还有各种项目（如会话时的文件传输、Outlook 中的电子邮件或存储在 Microsoft Office OneNote® 中的笔记）。
以下几个会话因素可能对 OCS 客户端系统的设计产生影响：
  • 会话中涉及的所有情态使用相同的窗口。如果将即时消息添加到音频会话中，它亦会在同一窗口内起作用。
  • 可跨设备进行会话。用户可选择在 Communicator Phone Edition 上实现音频，但在 Communicator 桌面上使用 IM。
  • 所有模式一起升级为会议：如果出现升级3，则必须一起升级会话的所有情态（无论情态当前位于哪个设备）。例如，如果音频模式位于 Communicator Phone Edition，而相同会话的 IM 模式位于 Communicator 桌面，则升级为会议可确保该会话的音频和 IM 有同一组参与者。
  • 记录总体会话，但不记录个人会话。呼叫日志包含完整的会话信息，包括会话期间笔记、即时消息对答以及音频持续时间等详细信息。从而使用户在 Outlook 中打开呼叫日志时可方便地全面了解整个会话。
  • 可从会话日志继续会话。OCS 客户端使用会话 ID（唯一标识设备和应用程序间会话的一个号码）归纳会话。当从旧会话的历史记录日志开始新会话时，将使用一个完善的机制来计算会话的增量。相同的会话 ID 还作为电子邮件 ID 存储在 Outlook 中。
会话 ID 包含在 SIP INVITE 中，作为自定义属性 Ms-Conversation-Id 传递。图 8 显示的事务首先添加语音，然后添加 IM。请注意，在多模会话结束时，存储在 Outlook 中的历史记录日志具有相同的会话 ID。
图 8 多模会话和会话 ID（单击此图像查看大图）

Exchange UM 是用于 OCS 2007 的语音邮件系统。OCS 仅将启用了 UC 的用户的呼叫路由到 Exchange UM。OCS 提供了多种用于与 Exchange UM 集成的功能：
  • Communicator 电话 UI中的“呼叫语音邮件”（请参阅图 9）允许用户不必输入 PIN 即可管理 UM 邮箱、更改问候等，因为他已通过身份验证。
  • Communicator UI 中的消息等待指示（请参阅图 10）允许用户在 Outlook 中打开语音邮件文件夹，而 Communicator Phone Edition 中的消息等待指示则允许用户直接通过电话播放语音消息。
  • 可使用 Communicator 的 UI 将呼叫转发到语音邮件。
  • 拒绝呼叫将自动路由到语音邮件。
  • 从 Outlook 中的语音邮件项“在电话上播放”可直接振铃 Office Communicator 客户端。
图 9 Communicator 中的呼叫语音邮件选项
图 10 Communicator 中的消息等待指示
OC 用于接收语音邮件通知的机制与 Communicator Phone Edition 有所不同。OC 在 Outlook 的语音邮件搜索文件夹中注册新邮件通知并在此文件夹中报告新消息。Communicator 还使用“错过的对话”和“呼叫日志”。

结束语
我在此展示了语音呼叫在 OCS 2007 中的工作原理，该系统的构建基础是利用多个 RFC 的 SIP。在 OCS 中，客户端端点在管理呼叫方面起着重要的作用。默认情况下，会加密所有语音呼叫。OCS 具备灵活的组件，用于操控号码并管理其在系统中的流动。
会话是 OCS 中的中心概念，包括语音、IM 和视频。OCS 与 Exchange UM 相集成，并允许 Communicator 端点接收语音邮件通知，通过 Outlook 或直接从服务器访问语音邮件。

Rajesh Ramanathan 已经在通信行业工作了 14 年，他为 Office Communicator 2007 设计了语音协议、用户体验以及语音和会议。他目前是 Microsoft Office Communicator 团队的首席项目经理。可通过 rajeshra@microsoft.com 与 Rajesh 联系。


沟通与协作
使用 Groove 和 SharePoint 创建强大的连接
Alan Maddison
概览：
  • 创建 SharePoint 文档库
  • 创建 Groove 工作区
  • 同步 Groove 和 SharePoint
  • 允许访问工作区

目录
Groove 和 SharePoint 一起
入门
设置审批控制
创建 Groove 工作区
同步 Groove 和 SharePoint
允许访问工作区
总结
Microsoft Office Groove 2007 (Groove) 和 Microsoft Office SharePoint Server 2007 (SharePoint) 表现出的相似性经常令 IT 专业人员感到疑惑不解，他们对具体的使用环境
不甚明了。乍一看，两个产品似乎确实非常类似，因为它们均提供协作功能。但是，一旦深入了解体系结构，两者的区别便会浮出水面。
SharePoint® 提供了一个可靠且缩放自如的内容管理框架和协作工具集，并且支持结构化工作流。相比之下，Groove™ 是一个协作工具集，可快速部署在工作区内，IT 开销极少甚至无需开销。由于支持文档协作、线程化讨论和日历功能，Groove 为实现安全可靠的动态临时协作提供了一个理想框架。简而言之，大多数用户最终都会以不同方式使用这些产品。
Groove 2007 版本还通过 SharePoint Files 工具增加了对 SharePoint 集成的内置支持。该工具允许 Groove 工作区与 SharePoint 文档库同步，并且正如我们将看到的，内置集成意味着可轻松地充分利用这两个产品。事实上，Groove 的灵活性和动态特性与 SharePoint 完善强大的功能一旦联手，会产生极大的益处。
Groove 牵手 SharePoint
如今的 IT 领域对组织与其合作伙伴和供应商之间的协作要求日益增长。然而，对于那些使用各种产品（如 SharePoint）实现的强大协作解决方案，它们的侧重点是内部团队和满足在整个组织内共享信息的需求。在这种情形下，从管理和安全角度来看，很难向组织外部的用户提供访问权限。这就需要让用户能临时访问外部合作伙伴。
Groove 和 SharePoint 组合提供的就是这种解决方案。SharePoint 提供组织之内的协作、内容搜索和工作流框架；添加 Groove 后，公司可扩大这些功能，让其包含组织之间的轻松协作。通过 Groove，用户可快速在公司之间建立协作工作区。并且，由于支持 192 位高级加密标准 (AES) 对称密钥，协作的安全性得以确保。实际上，Groove 安全功能是内置的，并且始终处于启用状态，因此用户不必担心它的配置。
Groove 的安全体系结构为这些工作区及其内容提供了高级别的保护（无论是本地存储时还是在网络传输过程中都是如此）。SharePoint Files 工具允许此信息与 SharePoint 文档库进行双向同步，从而可确保从内部访问汇集的信息。让我们通过具体的示例来了解此过程的工作原理。
入门
在日常业务活动过程中，组织通常会与多个公司相互协作。其中不仅涉及外部组织，还包括不经常一起工作的部门（如财务、公司联络和法律部门）中的个人。因此，这些组织不仅需要创建一个将相互协作的临时内部团队，而且需要使协作的成果可供并未参与此协作过程但必须能访问最终可交付项的人员使用。通过使用 SharePoint 和 Groove，即可轻松地实现这些目标。
如果还没有要与 Groove 工作区同步的 SharePoint 文档库，首先应创建一个这样的文档库。为此，连接 SharePoint，然后选择“查看所有内容”链接。加载完此页面后，选择“Create”（创建），然后如图 1 所示，从“Libraries”（库）列中选择“Document Library”（文档库）。
图 1 创建 SharePoint 文档库（单击此图像查看大图）
在新文档库页面上，有许多要配置的设置 — 库的名称和说明，是否将库纳入“快速链接”，是否启用版本管理，以及在库中直接创建的新文档的默认格式。默认禁用“文档版本历史记录”选项，但是，如果版本管理适用于您的环境，应启用此功能。还应考虑 SharePoint 提供且可用作 Groove 和 SharePoint 实现内容的一些高级功能。这些增强功能包括：
  • 版本历史记录
  • 审批控制
  • 签出程序
  • 工作流控制
  • 文档保留政策
  • 审核
  • 真正简易聚合 (RSS)
与 Groove 一起使用时，通过 SharePoint 提供的这些附加功能可提供极大价值。在我的示例中，这些附加功能（尤其是审批控制）将非常有用。例如，假设团队成员在 Groove 中协作草拟一个文档。当最终稿做好审核准备时，可将它与 SharePoint 同步，然后成为审批流程的对象。

设置审批控制
若要配置此功能，从文档库选择“设置”菜单，然后选择设置选项。这样可以查看所有配置和自定义选项。要配置审批，选择“权限和管理”中的“工作流设置”链接以显示“添加工作流”页面。选择工作流模板（在我们的示例中为审批模板），然后输入工作流的名称。接下来必须决定是使用现有任务列表还是创建一个新的任务列表。新的任务列表提供更好的机密性，但由于在我们的示例中不存在此问题，因此选择默认项即可。
选择任务列表之后，必须决定审批流程的启动方式。让我们将其设成一个手动流程，即允许具有正确权限的所有授权用户启动此流程。如使用其他选项，可根据版本管理、在文档库上启动后，或者添加新文档或更改现有文档时来自动化此流程。
按“下一步”接受这些配置选项后，需输入一些最终配置信息。第一个配置选项是分配任务的方式。由于审批流程中可能有多个人，因此可连续（即一个人批准项目后，移向下一个人）或并行（即任何人可在任何时间执行审批）分配审批者。然后，必须决定是否允许审批者向他人分配任务以及在任务完成之前他们能否请求执行更改。
下一步是选择实际审批者，然后决定其完成此任务的时间。最后，决定完成工作流的时间。默认选项是完成所有任务后工作流即完成。在最后的配置选项中，指定是否一旦工作流完成就更新审批状态。按“确定”按钮后，即创建了审批流程，可以开始审批文档。

创建 Groove 工作区
创建 SharePoint 文档库后，下一步是创建 Groove 工作区。为此，首先确保您拥有一个 Groove 帐户和至少一个身份。身份是在 Groove 中显示状态和进行沟通的基础。每个 Groove 帐户均可与多个身份相关联，每个身份只能与一个唯一的联系人文件相关联，这样您可以针对使用的每个身份自定义联系人信息。还可导出 Groove 帐户和相关身份以便在多台计算机上使用它们。
创建帐户和身份后，通过双击系统任务栏中的 Groove 图标打开 Groove 启动栏。单击“新建工作区”选项，输入适当的工作区名称，并选择“标准”类型的工作区。Groove 标准工作区适合工作区成员执行状态显示、警告和角色分配。单击“确定”后，Groove 将创建工作区并将其打开。图 2 显示了一个新的工作区，并且有些文件已添加到“文件”工具。此时，工作区可正常使用，可通过配置警告或通过添加需要的任何工具来完成设置。
图 2 新的 Groove 工作区（单击此图像查看大图）
可在工具、工作区或单个文件上配置警告。警告分为四个级别：无、中、高和自动。中等设置会突出显示新内容，而高级别或自动设置会播放音频文件。还可配置警告，在用户进入某个特定工作区时通知您。若要配置警告，选择“选项”菜单中的“设置警告”。在文件自身的属性中设置针对单个文件的警告；右键单击工作区中的某个文件并选择“属性”。
除默认标准工作区中的“文件”工具（用于文档协作）和“讨论”工具（用于线程化讨论）外，还有许多其他工具，包括“日历”、“表单”、“问题跟踪”、“会议”、“画板”，当然还有 SharePoint Files 工具。每个工具都提供了非常有价值的附加协作功能。若要添加工具，选择工作区右下方的“Add a tool to this workspace”（向此工作区中添加工具）按钮，然后选择要添加的工具（如图 3 所示）。还可随时轻松删除某个工具。
图 3 向 Groove 工作区添加一个工具（单击此图像查看大图）

同步 Groove 和 SharePoint
添加 SharePoint Files 工具后，需设置 SharePoint 站点的 URL，该站点包含要与其同步的文档库。为此，选择工作区屏幕下方的 SharePoint Files 选项卡后，只需按 Groove 工作区中的“Setup”（设置）按钮即可（如图 4 所示）。
图 4 设置 SharePoint Files 工具（单击此图像查看大图）
输入 URL 后，您会看到该 SharePoint 站点上可用的所有库。如图 5 所示，然后选择要使用的库。Groove 会连接并开始自动同步。它意味着 SharePoint 库中目前的所有文档都会下载到 Groove 工作区以供使用。图 6 显示了一个示例。
图 5 设置 URL 后，SharePoint 库将出现在 Groove 中（单击此图像查看大图）
图 6 同步 Groove 和 SharePoint（单击此图像查看大图）
文档在 Groove 工作区中显示为未读，因此它们是刚下载下来的。请注意，与 SharePoint 同步的所有文件均可利用 SharePoint 的签入/签出功能。并且，签出某个文件时，您将确保在您编辑文档时，其他用户均不能执行更改。
还必须注意，SharePoint Files 工具提供双向同步，因此如果通过 Groove 向 SharePoint Files 工具添加文件，它们会同步到 SharePoint 文档库。尽管默认同步设为自动执行，可通过按“立即同步”按钮来手动启动同步。如果这样操作，您会看到需同步的所有文件的更改摘要以及相关操作：get（从 SharePoint）或 send（到 SharePoint）（如图 7 所示）。
图 7 手动同步后，您会看到更改摘要（单击此图像查看大图）
要特别注意的一点是，作为 Groove 标准工作区组成部分部署的“文件”工具不同于 SharePoint Files 工具。Groove 文件工具并不与 SharePoint 同步，如需要，可将其删除。但是，由于它不与 SharePoint 同步，因此实际可用此工具存储团队在项目过程中需访问的临时文件。此处存储的文件仍将在工作区成员之间同步。

允许访问工作区
部署完基本的协作基础结构后，可以开始授权用户访问工作区。但首先需要通过电子邮件或 Groove 即时消息来邀请他们。或者，使用 Groove 将邀请导出成文件。此文件默认与 Groove 应用程序相关，扩展名为 .grv，可使用其他方式传送，如放在网站上并允许收件人下载邀请。
Groove 即时消息包括安全检查，以确保邀请仅可被收件人阅读。通过电子邮件或使用邀请文件邀请时，确保选中“要求确认接收”，这样可复查加入工作区的人员是否正在您打算邀请的人。它为工作区提供了另一层防护。您还应指出可以取消无回应的邀请。
将用户邀请到工作区时，需为每个收件人选择一个角色。角色包括“经理”、“参与者”和“来宾”，默认分配为“参与者”。每个角色在工作区中都有具体的权限，通常应仅将“经理”角色分配给在工作区中真正需要所有权限（如删除工具）的人员。工作区创建者默认获取“经理”角色，分配的角色则可随时更改。
鉴于本文中项目的临时特性，完成所有操作后，最后应删除 Groove 工作区。在确保已将工作区与 SharePoint 库同步后，打开工作区，转到“文件”菜单并选择“删除工作区”。然后，选择“从此计算机删除”或“为所有成员删除”。（每个用户的机器上都有一个工作区副本，它会持续存在，直到针对所有成员执行了删除。）
项目的完成点为利用 Groove 和 SharePoint 的互补特性提供了又一个良机。文档最终同步后，最适合您利用 SharePoint 中的信息管理策略设置。特别是可启用数据过期来自动管理归档数据。
通过启用过期，可指定数据的保存期。保存期结束时，SharePoint 可自动删除数据或启动一个工作流程。此功能最适合将 Groove 数据合并到公司的信息生命周期管理策略中。您可随时配置数据保存策略。实际上，如果在初始配置库时没有这么做，现在正是恰当的时机。
要启用过期功能，在文档库中选择“设置”菜单，然后选择文档库设置菜单项。然后，可在页面的“权限和管理”中查看“信息管理策略设置”菜单选项。单击这个链接后，可指定您定义的新自定义策略，也可选择启用文档库以使用在站点级别定义的策略。
请注意，如果定义自定义策略，需输入一些配置信息。因此，在我的示例中，您应启用过期功能，然后选择保存期以及此保存期过期后执行的操作。
Groove 是功能丰富的协作客户端，旨在为临时协作提供一个动态、直观且安全的框架。通过其丰富的工具集，Groove 提供了适应性很强的轻量级协作平台，可在组织中或不同组织间轻松使用。
如果 SharePoint 已为贵公司提供一个可靠且功能强大的内容管理框架和协作工具集，相信您会发现将其与 Groove 合并将是个有吸引力的解决方案。这两个产品互补性极强，将它们配合使用时可显著提高协作团队的工作效率。﻿

Alan Maddison 是 Brocade 战略业务系统部门的高级顾问。


Windows 管理
Windows Server 2008 故障转移群集简介
Chuck Timon
概览：
  • “故障转移群集管理”管理单元
  • 新功能和增强功能
  • 备份和还原功能
  • 从 Windows Server 2003 进行迁移

目录
新的管理界面
改进了配置过程
嵌入了验证过程
新的仲裁模型
增强了安全功能
扩展了网络功能
增强了与存储交互时的可靠性
内置恢复过程
新的备份和还原功能
从 Windows Server 2003 服务器群集进行迁移
自从在 Windows NT 4.0 Enterprise Edition 中首次引入群集以来，用户就一直在抱怨它太难于设置，维护则更是难上加难。管理群集
要求管理员不仅要了解群集本身，还需要精通存储技术以及群集服务与各种存储解决方案交互的方式。许多组织都难以获取用于启动和运行高可用性解决方案以及之后对其进行维护所需的所有技能。
多年来群集一直在不断改进，但直到 Microsoft 开始研究 Windows Server® 2008 时，仍有许多地方有待改进。明确这一点后，团队以简单为主要目标开始着手重新设计群集。在 Windows Server 2008 中，Microsoft® 群集服务 (MSCS) 得到了完全的改观，并且现在改称为“故障转移群集”。
这并不是说简单是新的“故障转移群集”带来的唯一改进。这些年来，由于许多组织都提供了有关他们希望在群集解决方案中看到哪些功能的有价值反馈，因此 Microsoft 积累了大量经验教训。新的“故障转移群集”功能可解决用户报告的许多首要问题，并且还加入了一些使其更具吸引力的激动人心的新功能。因此在本文中，我将向您介绍 Windows Server 2008 故障转移群集中包含的一些非常酷的新功能。

新的管理界面
安装“故障转移群集”之后，可在“管理工具”中或通过运行 Cluadmin.msc 访问“故障转移群集管理”界面。“故障转移群集管理”管理单元（类似于 Windows Server 2008 中的其他管理界面）是一个 Microsoft 管理控制台 (MMC) 3.0。对于群集老手来说，首次打开“故障转移群集管理”管理单元的感觉就像来到国外却没有带地图一样。
新界面分为三个不同的窗格，如图 1 所示。左侧窗格列出了组织中的所有 Windows Server 2008 故障转移群集。中间的窗格提供了有关在左侧窗格中选择的群集配置部分的详细信息，而右侧窗格显示可执行的操作。
图 1“故障转移群集管理”管理单元（单击此图像可查看大图）
例如，在左侧窗格中选择 Storage。中间的窗格将随后显示群集中提供了哪些存储以及哪些存储（如果有）当前可用的详细信息。如图 1 所示，该群集包含支持见证磁盘的一块存储区、已为 File Server 置备的存储以及一些可用存储。右侧窗格列出了相关的操作，如添加更多存储。请注意，“故障转移群集管理”管理单元不能用于管理之前版本的“Microsoft 群集服务”。

改进了配置过程
配置“故障转移群集”变得非常简单。许多配置、重新配置和维护群集的操作都有向导。有了这些向导的帮助，管理员不必再担心资源是否已配置正确或者它们是否会以正确的顺序联机。
图 2 显示了“高可用性向导”。在该特定示例中配置了一个 File Server。左侧显示了向导已指引管理员完成的步骤列表。此过程一旦完成，就会显示摘要页面并可查看报告。
图 2 高可用性向导（单击此图像可查看大图）

嵌入了验证过程
在之前版本的 Windows Server 中，要成为受支持的群集解决方案，必须在“Windows Server 目录”中将硬件配置列为“群集解决方案”。它包括在“地理位置分散型”类别下单独列出的多站点群集。要列在该目录中，硬件供应商必须运行一组 Windows 硬件质量实验室 (WHQL) 测试并将结果提交给 Microsoft。这对于供应商来说成本很高，并且难以维护“Windows Server 目录”数据库。
在 Windows Server 2008 中，“故障转移群集”包含一个内置的验证过程。该过程由分为四个大类别的一系列测试组成，如图 3 所示。
图 3 故障转移群集验证测试类别（单击此图像可查看大图）
您可以看到 Network 类别已展开以显示运行的测试；每个类别都包含一系列测试。Storage 类别也许是四个类别中最关键的一个类别，它包括用于确保存储解决方案符合 Windows Server 2008 故障转移群集提出的新要求的测试。
具体地说，硬件供应商现在必须使用基于 Microsoft Storport 驱动程序的驱动程序，并且它们必须支持 SCSI-3 持久保留。此外，在使用多路径软件“设备专用模块”时，必须遵循“Microsoft 多路径输入\输出”标准。
由于并入了验证过程，支持模型发生了更改。所有硬件必须具备 Windows Server 2008 徽标，并且必须通过所有的验证测试。唯一例外的是包含两个单独且完全不同的储存柜（每个站点一个）的多站点群集，以及并未使用任何共享存储的 Exchange Server 2007 群集连续复制实现。

新的仲裁模型
Windows Server 2008 故障转移群集中的仲裁模型也发生了更改。在较老的系统中，当管理员听到“仲裁”这个词时，他可能想到的是包含群集配置和一些复制文件的某个共享磁盘。它是群集中的一个单点故障。如果仲裁磁盘出现故障，群集服务将终止并失去高可用性。
Windows Server 2003 服务器群集提供了另一种仲裁类型，即“多数节点集”仲裁。此类仲裁类型通常是在多站点群集中实现，并且不需要共享存储。“多数节点集”仲裁由驻留在每个群集节点上的系统驱动器上的文件共享组成。通过服务器消息块 (SMB) 连接来连接到该仲裁类型。同样，为使群集能正常运行，必须有大多数节点的参与。
引入 Exchange Server 2007 群集连续复制 (CCR) 之后，文件共享见证 (FSW) 功能也添加到了 Windows Server 2003 服务器群集中。它允许单个 Exchange 2007 CCR 群集节点（或任意多站点群集）继续提供服务，只要能够实现到大多数 FSW 的连接即可。
在 Windows Server 2008 故障转移群集中，仲裁的概念现在才真正意味着达成共识。现在实现仲裁（或达成共识）的方式是拥有足够的投票才能开始使用群集。可通过多种方法获取足够的投票，具体取决于仲裁配置。在 Windows Server 2008 故障转移群集中共有四种仲裁模式，如图 4 所示。在列出的四种模式中，只有前两种（“多数节点”和“节点和磁盘多数”）可在创建群集过程中自动选择。应使用以下逻辑：
  • 如果在群集中配置的节点数目为奇数，则选择“多数节点”模式。
  • 如果在群集中配置的节点数目为偶数且共享存储已连接并可访问，则选择“节点和磁盘多数”。
图 4 配置群集仲裁向导中的仲裁模式（单击此图像可查看大图）
要从可用存储选择一个见证磁盘，可选择大小至少 500 MB 且配置了 NTFS 分区的首个磁盘。其余仲裁模式仅可通过运行“配置群集仲裁向导”来手动选择。“节点和文件共享多数”选项通常用在多站点群集配置或 Exchange 2007 CCR 群集中。最后一个选项“非多数:仅磁盘”模式等同于传统群集中的共享仲裁模式。它是一个单点故障，通常不应使用此选项。
在群集中仅有两种见证资源（物理磁盘和文件共享）经过配置后能帮助达成共识。
见证磁盘是群集服务可将其联机的一块存储区。该磁盘与群集“网络名称”及相关 IP 地址资源一同位于“群集核心资源组”中。配置了见证磁盘后，该磁盘上将出现一个 Cluster 文件夹并放置一个完整的群集配置副本（群集配置单元或副本）。
FSW 是一个网络共享，在理想情况下位于不属于群集的网络服务器上。为 FSW 建立 SMB 连接，由 FSW 维护见证日志文件（它包含了群集配置的版本信息）的副本。
一个群集中仅可配置一种见证资源。在群集实现仲裁时需要该资源提供一张额外的投票。换句话说，如果群集仅差一张选票（即一个节点）即可达成共识，那见证资源将联机以便实现仲裁。如果群集还差多张选票才可实现仲裁，则见证资源不会联机，且群集将继续保持休眠状态并等候其他群集结点的加入。

增强了安全功能
故障转移群集包含多个新的安全增强功能。其中最重要的也许是不再需要群集服务帐户 (CSA)。在之前版本的 Microsoft 群集服务中，在配置过程中需要用到域用户帐户。该帐户的目的是用于启动群集服务，因此需将它添加到每个群集节点上的本地管理员组中，并且向其提供必要的本地用户权限以便群集服务能正常运行。作为域用户帐户，CSA 需要遵守许多可应用到群集节点的域级别策略。这些策略可能会导致群集服务失败，对高可用性产生负面影响。
现在，群集服务是以一个本地系统帐户的名义运行，该帐户对本地群集节点具备一组特定权限，能够正常运行。群集的安全上下文已转换成“群集名称对象”(CNO)，该对象是首次创建群集时在 Active Directory® 的“计算机”容器中默认创建的计算机对象。一旦成功创建群集且 Active Directory 中存在 CNO，就不再需要用于安装和配置群集的用户帐户。
在 Active Directory 的“计算机”容器中创建的其他计算机对象与“故障转移群集”相关联。这些对象称为“虚拟计算机对象”(VCO)，等同于在群集中作为客户端访问点 (CAP) 的一部分创建的群集“网络名称”资源。CNO 负责创建群集中的所有 VCO，它会被添加到 Active Directory 中对象的系统访问控制列表 (SACL) 中（请参阅图 5）。
图 5 Active Directory 中 VCO 的安全性（单击此图像可查看大图）
CNO 还负责同步它创建的所有 VCO 的域密码。将根据配置的密码轮换域策略完成此过程。此外，由于 CNO 负责创建与群集中的 VCO 相关联的所有计算机对象，因此 CNO（计算机帐户）必须具有域级别权限以便能够在创建 VCO 的容器（默认情况下为“计算机”容器）中创建计算机对象。
另一项更改是 Kerberos 现在已成为默认的身份验证方法。由于 Active Directory 中存在计算机帐户，因而使得此项增强的安全功能成为可能。但是，如果某个应用程序虽然无法使用 Kerberos 来执行身份验证却需要访问群集资源，则群集可以使用 NT LAN Manager (NTLM) 身份验证。
直接处理群集过程的群集节点间的通信也更加安全。所有群集内部的通信都会默认进行签名。可通过使用 cluster.exe 通用语言接口 (CLI) 来更改此群集属性，这样可加密节点之间的所有通信以提供更高级别的安全性。

扩展了网络功能
“故障转移群集”中的新网络功能使得高可用性和灾难恢复解决方案的设计更加灵活。同时，这些网络增强功能在群集中的节点间提供了更加可靠的连接。
在单个网络中找到群集节点可能是客户最迫切需要的功能。现在已实现这项功能。群集网络驱动程序已彻底重新编写，因此只要每个节点都连接至少两个分别路由的单独网络，它就可以在群集中的节点间提供高度可靠且容错的通信。
群集网络驱动程序根据群集启动过程中提供的连接信息构造自己的内部路由表。这包括本地连接信息以及在群集配置数据库（群集注册配置单元）中提供的信息。
群集验证过程的一项内容是网络连接发现过程。在不同路由网络中找到群集节点的功能减轻了多站点群集的网络需求。因而使得组织部署它们时更加轻松且成本更低。它还使在“故障转移群集”中使用 iSCSI 存储成为更具吸引力的存储解决方案。
群集节点还可通过 DHCP（动态主机配置协议）获取 IP 地址信息。如果网络管理员允许其环境中的服务器使用动态地址，则此功能可以减轻他们的负担。
群集节点网络接口的配置决定了哪些网络使用静态或动态 IP 地址。尽管群集中的 IP 地址资源是从 DHCP 服务器获得的，也可以在“故障转移群集管理”管理单元中将其更改为静态 IP 地址。
在过去，所有的群集通信都使用用户数据报协议 (UDP) 广播，或者有时使用多播。现在已停止使用多播功能，且群集通信转为使用 UDP 单播。（端口 3343 仍是 Microsoft 群集使用的公共端口。）许多网络管理员对于不再使用广播都感到非常高兴。但是，群集中真正的回报在于群集服务内部的新消息传递过程。（不过，该内容超出了本文的介绍范围。）即使将 UDP 用作传输机制，群集内部的通信现在也是更加可靠的 TCP 通信。

增强了与存储交互时的可靠性
“故障转移群集”与存储交互的方式发生了翻天覆地的变化。群集磁盘驱动程序 (clusdisk.sys) 已彻底重新编写，现在它才是真正的即插即用 (PnP) 驱动程序。而且它与存储交互的方式也已发生改变。
在 Windows Server 2003 中，群集磁盘驱动程序位于一个直接存储路径中。但在 Windows Server 2008 中，群集磁盘驱动程序需要与分区管理器 (partmgr.sys) 驱动程序进行通信才能与存储实现交互。图 6 中展示了这两种方法。
图 6 存储堆栈在 Windows Server 2008 中的变化（单击此图像可查看大图）
分区管理器主要负责保护群集磁盘资源。首次映射到群集节点时，共享存储总线上的所有磁盘都会自动处于脱机状态。因此，即使是在创建群集之前，也可将存储同时映射到群集中的所有节点。不再需要一次一个地引导节点，在一个节点上准备磁盘然后关闭节点，再引导另一节点，检验磁盘配置等等。
但仍然需要执行存储测试，该测试是群集验证过程的一个部分并且需要初始化磁盘。可在执行验证过程之前在群集的一个节点上完成该操作。一旦存储被添加到群集，磁盘将在“磁盘管理”界面中显示“保留”状态，并且会一直处于受保护状态。
另一项更改与 SCSI 命令有关。在 Windows Server 2003 中，SCSI-2 Reserve\Release 命令与写入磁盘自身扇区中的群集磁盘驱动程序搭配使用。在 Windows Server 2008 中，必需使用 SCSI-3 PR (Persistent Reservation) 命令。群集节点必须先注册然后才能保留存储，并且群集节点需定期使用“注册保护协议”来保护其保留。
验证过程中的其中一项存储测试将验证此功能。如果某个存储解决方案并不支持 SCSI-3 (PR) 命令，则“故障转移群集”也将不支持它。
在连接到存储时，许多组织使用多路径软件来实现冗余。这种方法不但受到支持，甚至还推荐做为最佳实践。但是，必须使用“Microsoft 多路径输入\输出”标准来重新编写第三方多路径软件解决方案（即设备专用模块），以便得到“故障转移群集”的支持。从而确保所有的 SCSI-3 PR 命令都同时沿所有路径发送到存储，无论路径是否处于活动状态。验证过程也会确认此功能。
其他存储改进包括有所改进的检查磁盘 (chkdsk.exe) 过程、之前“群集服务器恢复实用程序”中的内置磁盘修复功能以及自修复磁盘。在“故障转移群集”中，确定群集磁盘资源时将同时用到磁盘签名和 LUN ID。如果任意一项发生更改，群集配置都会更新。正是由于物理磁盘资源上的属性更改提供了更好的高可用性，因而减少了错误。

内置恢复过程
之前提到的磁盘修复显然是一项内置恢复功能。还有一个是 Active Directory 修复功能。如果删除了代表 CNO 的计算机对象，您将无法再创建与群集 CAP 相关联的计算机对象。但是，您会遇到的第一个问题可能是高度可用的应用程序或用户由于无法获得安全令牌而无法访问群集外部的资源。
从已删除的 CNO 恢复包括以下两个步骤。首先，必须让域管理员从 Active Directory 的 DeletedObjects 容器恢复已删除的计算机对象。然后，在还原并重新启用该对象之后，执行“故障转移群集管理”管理单元中的“修复 Active Directory 对象”过程。
在 Windows Server 2003 服务器群集中，位于 %systemroot%\cluster 子目录中的群集配置文件可能会损坏因而必须进行替换。在“故障转移群集”中，自修复功能可帮助解决这一问题。如果群集服务在某个节点上启动且配置数据库发生损坏，将使用 HKLM\System\CCS\Services\ClusSvc\Parameters 注册表项中包含的信息加载最小的配置模板。该节点将尝试加入一个已成形的群集，如果该尝试成功，该群集注册表配置单元的一个全新副本将被推送到该节点。如果节点无法加入群集，群集服务将终止。

新的备份和还原功能
“故障转移群集”自带了“卷影复制服务”编写器。它在备份和还原群集数据库以及物理磁盘资源上保存的数据过程中起着非常关键的作用。备份群集配置非常简单。只要系统状态为备份的一部分，就可以还原群集配置。但请注意，仅应备份具有仲裁的群集。从而确保备份的是最新的群集配置。
有两种完全不同的群集还原类型：权威还原和非权威还原。非权威还原使用 Windows Server Backup 或第三方备份应用程序来从选定的备份执行还原。而群集结点的权威还原仅可使用 Windows Server Backup CLI (wbadmin.exe) 执行还原。
权威还原实质上是将群集配置“带回”执行备份时的状态。要完成权威还原，必须停止除正在执行还原的节点以外的所有其他节点上的群集服务。当还原完成且在已还原节点上启动群集服务后，群集的还原配置将变成权威性的新群集配置。然后，在群集中的其他节点上重新启动群集服务时，还原配置将在加入过程中向外推送到这些节点。
在某些情况下，它可以节省大量的时间和资金。假设您有一个包含多个打印后台处理程序资源的打印群集且每个资源都支持 1,500 台打印机，而您无意间删除了其中一个打印后台处理程序资源。现在，大量用户无法正常打印。与其手动将这些打印机都重新添加回群集配置，更快的方法是执行群集配置的权威还原。当然，这需要您具备良好的备份和还原策略。

从 Windows Server 2003 服务器群集进行迁移
由于 Windows Server 2008 故障转移群集包含这些体系结构更改，因此并不支持从 Windows Server 2003 执行就地或周期性升级。从 Windows Server 2000 群集升级到 Windows Server 2003 时，许多组织都系统地删除了群集中的所有节点，全新安装操作系统，然后再将节点重新添加到群集中。这种方法无法用于迁移到 Windows Server 2008 的情形，因为 Windows Server 2003 和 Windows Server 2008 群集节点不能处于同一群集当中。
幸运地是，系统提供了一个基于向导的迁移过程来帮助执行迁移。但是迁移到 Windows Server 2008 故障群集需要执行一些规划。有以下三种基本的迁移方案：
  • 使用相同的服务器和存储。
  • 使用相同的服务器，但使用新的存储。
  • 使用新的服务器和新的存储。
所有方案都需要确保硬件已通过 Windows Server 2008 徽标计划的认证，并且已运行故障转移群集验证过程且通过了所有的测试。完成这些步骤后，就可继续执行迁移过程。
并非 Windows Server 2003 服务器群集中的所有资源都可以迁移。可迁移网络名称、IP 地址、物理磁盘、文件共享、分布式文件共享 (DFS) 根、DHCP 和 WINS。也可（有限地）迁移通用服务、通用应用程序和通用脚本资源。
同时，Microsoft Exchange 和 SQL Server® 之类的应用程序都拥有自己的程序来迁移到“故障转移群集”。打印机可使用“打印管理”管理单元（与“打印服务器角色”一起安装）迁移到 Windows Server 2008，从而先将打印机导出然后再将其导入新配置的高度可用的打印服务器。无法迁移第三方资源类型。
迁移过程不会迁移任何数据。它会将群集配置设置从 Windows Server 2003 迁移到 Windows Server 2008。
迁移过程完成时，所有的迁移资源最初都处于脱机状态。原因是可能存在其他必要的步骤。因此，在开始使用群集之前，必须查看迁移后报告以了解还需要执行哪些步骤（如果迁移到新存储则还需要执行数据迁移）。例如，如果迁移 DHCP 服务器，必须在群集中的所有节点上安装“DHCP 服务器角色”。如果迁移 WINS 服务器，必须在群集中的所有节点上安装“WINS 服务器”功能。

Chuck Timon 是 Microsoft 支持群集和安装技术的一名支持升级工程师。他撰写过 Windows Server 2008 故障转移群集培训课程，目前正从事 Hyper-V 培训工作。


编辑寄语 印刷品退位
Joshua Hoffman

印刷品该退位了。 大约你们都会这么想。在无限信息时代中，无数的精巧设备可随时随地以各种格式提供信息，那些用胶水粘在一起的纸张还能发挥什么作用呢？它是不是已经过时了？杂志和报纸是不是应该陈列到 Smithsonian 博物馆的大厅里去，这样某天我们还能够怀旧地想象一下随身携带纸墨的感觉？
有点夸大其辞了？可能是吧。但我敢肯定您已经猜到我完全不同意这种说法（这不仅出于我的职位能否保住的考虑；我在 Microsoft 可做的事情还是很多的）。我坚信印刷出来的文字能够提供更深刻且更丰富的体验，无论它多么地简单（或者正是由于它的简单才达到了这种效果）。当我坐下来阅读一篇长长的文章时，我始终更喜欢手拿印刷稿而不是在计算机屏幕上阅读。对我来说，打印稿能让我更加融入其中。我的观点是不是有点陈旧过时了？也许吧，但根据我们最新的读者调查来看，90% 的人都与我持有相同的观点。
我现在可不是在建议大家掩耳盗铃。实际上我跟大家一样热爱技术。但类似我们这样的出版物能够 — 并且应该 — 具有全面的体验，即采用各种形式 — 联机、脱机和现场阅读材料。当然，如果要阅读 Mark Russinovich 撰写的长篇且深刻的技术文章，那我还是希望阅读打印稿。但同时，我也希望能够聆听 Mark 的讲座并观看他演示所介绍的技术。
这种观念已成为《TechNet 杂志》的指导原则。我们仍为每月印刷的出版物感到骄傲，而与此同时，所有曾经印刷出版过的内容也将在网站上提供。并且在不久的将来会有更多的内容利用 Internet 上的这一独特平台。例如，在最新一期的杂志中，我们通过 Don Jones 的 Windows PowerShell 专栏启动了屏幕广播系列。现在，您可以在 Don 向您介绍当月专栏的主题的同时观看到他的视频。在我们的网站上，还有一个新的“可持续计算”专栏，该专栏用于介绍 IT 的环境影响以及作为 IT 专业人员的我们可做些什么以便成为负责任的全球公民。
与往常一样，您的反馈意见对于我们而言至关重要，我们将根据您的意见继续使《TechNet 杂志》拥有更加丰富的媒体体验。请发送电子邮件至 tnmag@microsoft.com 与我们联系。
—Joshua Hoffman

衷心感谢以下 Microsoft 技术专家： Ed Banti、Avronil Bhattacharjee、Nino Bilic、Mai-lan Tomsen Bukovec、Eric Charran、Elden Christensen、Trina Gorman、Scott Landry、Michael Murgolo、Sanjeev Nair、Hugh Pyle、Amritansh Raghav、Jez Sadler 和 Jim Truher。


读者来信 读者心声

Active Directory 域服务
我非常喜欢 2008 年 3 月刊的《TechNet 杂志》。我想到现在为止我已读过 12 遍了！我尤其喜欢 Gil Kirkpatrick 撰写的文章“Active Directory 域服务中的新增功能”。在这篇文章中，Gil 提到一个名为 Microsoft® 审核收集服务的产品。现在市面上有这个产品吗，它是不是一个独立的应用程序？
— Erasmo M.

Microsoft 审核收集服务 (ACS) 是 System Center Operations Manager (SCOM)（此管理软件之前称为 Microsoft Operations Manager (MOM)）的一个组成部分。它只是 SCOM 的一个组件，不是独立的产品。
—Gil Kirkpatrick，NetPro CTO 和《TechNet 杂志》作者

签名
在 2008 年 4 月刊的《TechNet 杂志》中的 Windows PowerShell 专栏（“请在此处签名”，technet.microsoft.com/magazine/cc434702）的第二段中，作者 Don Jones 说到：“签名”一词相对于我要论述的内容而言是一个恰当的技术术语，尽管这个单词本身并没有真正透彻说明将要发生的情况。这里所说的签名脚本并不意味着您对其进行批准或授权，就像在合同或信用卡上签名那样。”
我认为在合同或信用卡上签名也不一定就表示对它们进行批准或授权。必须在全面考量环境因素后才能确定操作是否有效。例如，当我还很小的时候，我在父亲的加油站中玩耍信用卡 — 没有人会尝试催收我在这些交易中产生的债务。
在配置得当的 Active Directory® 网络实施氛围中，签名的确意味着授权脚本执行操作。出现签名表示签名人员将接受签名事情的责任，签名随后可能触发进一步的活动 — 信用卡公司开具帐单或网络将代码视为可信资源。
请继续努力吧 — 《TechNet 杂志》让人受益匪浅。
—Jeremy P.

感谢您的反馈，Jeremy。读者对《TechNet 杂志》的内容给予如此之高的重视，让我们倍感欣慰。

SharePoint Services
在运行 Windows® SharePoint® Services (WSS)（不是 Microsoft Office SharePoint Server）时，如果用户想通过网站接口/URL 访问它时，是否还需要其他 CAL 许可证？
—Douglas M.

网上有许多有关此主题的文档。以下是一些有用的链接：msmvps.com/blogs/cgross/archive/2005/04/02/40723、microsoft.com/windowsserver2003/howtobuy/licensing/extconnector.mspx 和 windowsserver/sharepoint/bb684457。
—Pav Cherny，《TechNet 杂志》“深入剖析 SharePoint”的专栏作家

对深入剖析 SharePoint 的建议
我最近阅读了《TechNet 杂志》2008 年 5 月刊的 SharePoint 专栏 (technet.microsoft.com/magazine/cc462809)。您希望读者提供一些主题方面的建议。如果能有 SharePoint 与 Project/Project Server 集成方面的文章，那就太好了。
—Phil H.

Project/Project Server 是个不错的建议！我们肯定会在将来的专栏中考虑这一主题。多谢您的反馈。

对深入剖析 SharePoint 的其他建议
总体说来，Web 上存在大量有关使用标准 SharePoint UI 或 SharePoint Designer 定制站点的文档，但很少有关于站点定义的文档（现有的少量文章也非常初级，对实际问题几乎毫无用处）。许多人已经开始探索站点定义，而使用方法仅对采用 SharePoint 有所帮助。具体说来，在我的公司中，我们正在为以下主题绞尽脑汁：
  1. 在站点定义中设置列表的自定义权限。
  2. 站点定义中的自定义列表项表单。
  3. 站点定义内的 Web 部件连接。
  4. 如何以增量方式提供站点定义。
—Adam C.

感谢您的建议。我们继续扩充此内容时正要考虑这类读者反馈。


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

自动化管理任务
Automise 2
automise.com/automise.aspx
单调的重复性任务令人厌烦、费力且容易出错。自动化此类任务是管理成功的关键所在，并且可提高工作满意度。除使用枯燥的批处理文件和自定义 VBScript 来自动执行任务外，还有许多类似于宏的 Windows® 实用程序，以及一些甚至需要您了解某种自定义脚本语言的实用程序。但还有另外一个选择。VSoft Technologies 公司出品的 Automise 2 可让您通过拖放和自定义样式 GUI 来生成自动执行的日常任务。
此应用程序的界面非常类似简单的编程 IDE，并提供类似的选项。您将获得一个工具箱，可从中将项目拖到设计器表面、允许单步调试代码的调试控件、不同项目的视图、输出运行日志、历史记录以及属性窗口。使用 Automise 时，“代码”实际是自动化任务工作流的可视表示形式。
Automise 的工具箱包含多个操作，每个操作执行自动化过程中的一个步骤。此应用程序包括 380 个操作，涉及从创建 .zip 文件到重启 IIS 的所有可能操作。
在设计任务时，可分层构建这些操作的结构以涵盖定期执行的多个管理流程。此外，可通过流控制操作来连接操作，如尝试/捕获块、异常引发、if-then-else 语句、循环、开关、延迟和异步操作组。
每个自动化项目也可包括其他项目，这样就可将主要流控制与子任务分隔开来。还有操作字符串和 XML 数据、设置变量、等待进程和命令等操作。通过所有这些流控制选项，即使再复杂的操作也可实现自动化。
可利用 Automise 创建、运行、编辑和删除计划任务。这意味着也可使用 Automise 来管理现有进程。我无法列出所有操作，但主要操作包括：在全局程序集缓存 (GAC) 中注册 DLL、重新生成 SQL Server® 索引、运行 chkdsk、编辑注册表、备份事件日志、编辑 Active Directory® 用户、安装卷、创建还原点以及创建虚拟目录等。并且，如果内置操作无法实现您的目标，Automise 还有自定义脚本、命令以及即时 SQL 执行操作。
总之，它是一个方便的工具。如果您实际只希望自动化自己的 Windows 工作站而无需自动化网络基础结构，则可了解一下 Automise Lite。它省去了许多功能，但仍可满足超级用户的大多数需求。
价格：单用户许可证起价 195 美元（直销价）。
使用 Automise 2 直观地自动执行任务（单击此图像可查看大图）

实时监控日志
BareTailPro
baremetalsoft.com/baretailpro
到处都是日志文件！但使用它们却非常不容易。让应用程序显示事务日志是个不错的方法。但要想真正实时了解正在发生的事件，又该如何呢？Bare Metal Software 提供的可靠软件 BareTailPro 就是一种解决方案。尽管自 2006 年起就未再更新，但这一简单的实用程序仍是对旧控制台 *nix 命令 'tail -f' 的增强 Windows 模拟。
通过其直观的 GUI，可以同时监视多个任意大小的日志文件，从而实时透明地了解写入日志的内容。要在文件间切换，只需单击选项卡即可。另外一个非常不错的功能是：每个选项卡都用一个图标来表示每个日志文件的状态，指明是正在对文件执行写入操作还是“tail”已停止。
尽管对于大多数应用程序日志而言，其日志记录方式通常存在很大不同。幸运地是，BareTailPro 可读取 Unicode、UTF-8、ANSI 和 ASCII 文件，并且可处理以 CR/LF 对、单个 LF 和空白结束的行。可轻松地配置换行和选项卡展开，以让您以最佳方式查看特定类型的日志文件。此外，可通过配置字体大小、类型、间距和行高来增强日志文件的可读性。
另一不错的功能是应用程序中可应用于日志视图的可配置突出显示。可根据文本字符串设置任意数量的前景/背景颜色编码规则。例如，可用红色突出显示所有错误、用黄色突出显示警告，或者可选择突出显示具有特定 IP 地址或主机参照的所有行。可指定行为粗体或斜体，并且可选择忽略文本字符串的大小写。
即便使用文本突出显示，一个增长迅速的日志文件仍可能掩盖尾部视图，从而难以确定您要寻找的事件。BareTailPro 提供了另一种有用的功能。正则表达式和文本搜索功能可让您快速裁减日志视图，从而将所需的行实例隔离到可管理的子集中。BareTailPro 使用的正则表达式语法由 Java、Perl 和 PHP 使用的标准表示法的子集组成。如果您并不熟悉该用法，产品网站提供了快速参考。
此实用程序以表格格式显示过滤结果，并添加了一些非常有用的列，如时间戳、行号以及随同原始行资源定义的任意捕获组的结果。在过滤视图中，还可对这些行进行分类。
对于那些为我找到所需结果的“神奇”正则表达式，我永远记不住它们的语法。这就是我非常喜欢此工具的模式保存功能的原因。可利用它来命名、编辑和保存模式以便反复使用。一旦过滤视图中确实存在重要的行，BareTailPro 还允许将这些结果导出到某个文件或具有定制格式的剪贴板，这样您就可以进行各种设置（如每个结果列的宽度、对齐、前缀和后缀）。
令人印象深刻的是，这个小巧的实用程序包含在单个小型可执行文件中，便于携带且对环境影响很小。请注意，如果仅需监视日志文件而不需要正则表达式过滤、保存搜索模式以及导出搜索和过滤结果，则使用免费 BareTail 即能满足这个要求。
价格：单个许可证起步价为 35 美元。
使用 BareTailPro 监视网络（单击此图像可查看大图）

编制系统清单
Total Network Inventory
softinventive.com
快速访问整个环境中所有机器的详细信息是成功实现系统管理的关键部分。此信息的电子表格和供应商列表不容易跟踪、难以保持完整并且很快就会过期。
使用“根据需要”显示信息的动态工具非常有用，这样可收集必要信息，了解谁安装了什么以及他们正在运行哪种硬件。此类工具还提供一个不错的方法来监视特殊用户可能在其机器上安装了什么。（当然，前提是组策略并未限制安装权限，或可根据特定软件包的安装位置来快速计算您应具有多少个许可证。）Softinventive Lab 的 Total Network Inventory 就是这样一个工具。
安装 Total Network Inventory 后，可使用 Scan 向导来启动清单编制流程，该向导将引导您查找网络中的节点。可选择立即扫描、通过指定的 IP 地址范围或网上邻居计算机浏览进行扫描，也可使用登录脚本扫描（它允许在机器登录域时收集信息）。
Total Network Inventory 依赖 Windows 管理规范 (WMI)（IPC$\ADMIN$ 或 RPC/DCOM）和本地帐户的典型共享来执行扫描。因此，需以管理员身份运行它。
扫描完成后，即可浏览机器或搜索特定计算机以盘存其资产。Total Network Inventory 将收集的清单信息分成以下三类：硬件、软件和其他信息。硬件部分包括有关处理器、主板和芯片集、内存、视频子系统、存储（包括物理和逻辑设备）、网卡类型和配置、外围设备和系统中安装的所有其他设备的详细信息。
软件部分提供 OS 信息，包括产品密钥、序列号、系统目录以及已安装的服务包。还包括有关修补程序（以及各自的知识库文章编号）和已安装的所有防病毒和数据库应用程序的详细信息。并且，您会得到一个已安装程序列表（以及 Program Files 目录视图，这样您可以看到可能在标准“添加/删除程序”列表中隐藏的应用程序）以及所有自动运行的应用程序列表。
最后，“其他信息”部分总结了有关系统环境的详细信息，如用户和系统变量、共享资源、正在运行的进程、已安装的服务和本地用户帐户。
Total Network Inventory 实际向您提供了执行资产审核、许可检查、升级计算和性能计算所需的信息。Report Builder 组件是其中的上品。此功能可通过快速参考审核档案记录向您提供多个条理清晰的详细报告，内容包罗万象。报告可以合计或用于单个机器。我觉得特别有用的一个功能是“软件和许可证计数”选项卡视图。它显示了整个环境中安装的每种软件的总数，以确保您遵守供应商协议。
价格：25 节点许可证起价 95 美元。
Scan 向导引导用户查找网络节点（单击此图像可查看大图）

书讯
《Mastering Microsoft Exchange Server 2007》
sybex.com
无论您喜欢与否，电子邮件均是运行平稳的组织的一个核心组件。（尽管，我必须得承认：有时我确实希望用户必须先参加一个有关有效书面通信的课程，然后再允许他们使用电子邮件。）多年来，将语音通信、日历、资源计划、统一客户端访问和邮件过滤（用于垃圾邮件、病毒以及类似事物）集成起来的愿望愈发明显。这就是 Microsoft® Exchange Server 2007 的用武之地。
最新版本的 Exchange 顺利地将所有此类组件集成到一个可扩展的强大解决方案中。但鉴于特性和功能众多，管理员、架构师和支持人员均需要一些不错的参考书籍，以帮助他们计划、部署、管理和维护此类动态电子消息解决方案。
在上一期的“工具箱”专栏中，我介绍了《Microsoft Exchange Server 2007 Administrator's Companion》。另一值得考虑的有用资源是 Barry Gerber 和 Jim McBee 联合撰写的《Mastering Microsoft Exchange Server 2007》（Sybex，2007 年）。它是可引导您完成 Exchange Server 生命周期的一个清晰书面指导。
此书的前三个章节（理解和计划方面的内容）介绍了 Exchange Server 2007 的基本组件和实施要求。熟悉之前版本 Exchange 的人会喜欢精简功能方面的章节。而对组成 Exchange Server 2007 部署的不同服务器角色和组件的描述总是能吸引所有人的目光。要部署一个这么复杂的服务器，肯定需要大量深思熟虑，您需要重点关注有关计划增长、磁盘空间要求和 Active Directory 集成的章节。
下一节介绍实际安装，包括全新安装和从 Exchange Server 2000 或 Exchange Server 2003 的升级（无法直接从 Exchange Server 5.5 执行升级）。此处还详细介绍了每个 Exchange 服务器可扮演的各种角色，包括边缘传输、客户端访问、集线器传输、邮箱、统一消息和管理工具。
然后此书接着介绍可扩展性，向您展示如何监视性能、添加更多邮箱存储容量等等。您会在此发现一个非常酷的新“本地连续复制”功能，它允许保存邮件存储的最新本地备份。如果主数据库发生变化，可快速地转换到备份，而不必从其他不好用且陈旧的备份执行恢复。
接下来该书详细阐述可使用 Exchange Server 2007 部署获得的各种管理任务和工具。这些工具包括 Exchange 命令行管理程序（基于 Windows PowerShell™）和 Exchange 管理控制台 GUI（它也依赖于 Windows PowerShell 引擎）。在这一章中，您将了解如何管理邮箱、地址列表和用户帐户。还有消息记录管理以及管理消息分类、日记和传输规则。
第四部分更加深入地介绍可用性和可靠性。既然企业越来越依赖于电子消息，这部分内容理所应当予以高度重视。
它将介绍负载平衡、服务器冗余、存储冗余、网络冗余和群集的基础知识。您将简要了解有关定期维护、运行备份以及灾难恢复情形的最佳实践，它们有助于保持公司电子消息系统的正常运转，应对出现的问题。
接下来的两章介绍客户端访问，包括 Microsoft Office Outlook® 2007、Outlook Web Access、IMAP 和 POP3。最后一部分对 Exchange 管理员再重要不过了，它介绍了安全性和审计，展示了基本的安全实践和预防措施以及可用的各种审计工具。总之，这一精深的参考资料可使您加快 Exchange 部署并使其步入正轨。
价格：49.99 美元（直销价）。

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


实用工具特别推荐 Microsoft SharedView
Greg Steen

我经常与身在远方的同事共事，经验告诉我，如果每个人都可以查看并使用相同的桌面交互，阐述并交流各自观点的效果要好得多。
假设销售团队正在出差时，需要迅速聚到一起共享信息、确认报价并减少重复性工作。如果使用电子邮件传递“活动文档”，它很快就会失去同步特性；如果团队中的每个成员都可以几乎同时查看并编辑相同的 Microsoft® Office Excel® 电子表格或 Word 文档，那将是何种效率。现在，有一款轻量级协作工具就可实现该功能 — 它就是 Microsoft SharedView 1.0。
Microsoft SharedView 允许最多聚集 15 个人，并且同时共享会议主持人的桌面，就像你们正在查看同一桌面一样。您的第一反应可能是，如果 15 个人同时控制相同的桌面，结果只会是一片混乱，但实际上可将对桌面的控制从一个成员传递到另一成员。
尽管您是控制者，但您可以看到协作者的鼠标移动（每人获得一个个性化光标），因此他们可以指出文档或应用程序中的项目。稍感遗憾的是，SharedView 并未集成音频功能，但在共享桌面的同时，可使用 Windows Live™ Messenger 的音频客户端或喜欢的 IP 语音 (VoIP) 客户端来召开会议。
Microsoft SharedView 允许同时共享会议主持人的桌面（单击此图像查看大图）
SharedView 的安装很简单，客户端非常直观，即使是没有太多技术常识的用户也能迅速掌握并运行该工具。使用 Windows Live 帐户登录后，即可通过一系列单击操作启动 SharedView 会话。加入会话同样很简单；只需键入要连接的会话名称（通常是主持人的 Live ID）以及密码即可。通过电子邮件或向 IM 客户端传输邀请文本即可发送邀请。
SharedView 中的其他选项包括：启用或禁用远程复制和粘贴（这样会话用户可从本地工作站向主持人的机器添加文本）；直接启用 Word 中的更改跟踪，这样您就可以看到人们如何更改共享文档；以及利用显式阻止列表来阻止某些 Windows Live ID 参加此会议。此应用程序还有一个很酷的讲义功能，您可以利用它来制作可供会话参与者使用的补充文件；每个会话最多可有 25 个文件或总计 200MB 的文件。
此外，可键入向参与者发送的广播消息，它们将显示在其连接会话的顶部。如果愿意，可共享所有内容；如果更希望在会议进行过程中保持某些内容的私密性，可从主持人的机器便捷地启动和停止共享窗口。总而言之，如果您正在寻找一个方便易用的协作工具，Microsoft SharedView 正好可满足要求。
要想试试这个工具，请从《TechNet 杂志》网站的代码下载区下载 Microsoft SharedView，网址为 technetmagazine.com。

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


深入剖析 SharePoint 集成 Office 应用程序
Pav Cherny

目录
Office 应用程序集成
扩展 SharePoint UI
使用 Office OpenDocuments 控件
与 SharePoint 进行通信
实现自定义 OpenControl 解决方案
总结
Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 能够与 2007 Microsoft Office 系统中的桌面应用程序实现无缝集成，从而简化了文档、电子表格、日历、联系信息等的协作。实际上，这种集成非常天衣无缝，以至于
可以说 2007 Office 系统是一个统一的办公解决方案平台。
这对于那些注重使用 Microsoft® Office 技术来提高信息工作者生产效率的组织来说非常理想。但是，采用不同 Office 应用程序的组织无法享受同样的现成互操作优势。虽然 2007 Office 系统提供了必要的集成功能，但接口和组件的文档记录非常少，并且无法用于所有情形。因而使得第三方供应商难以将 SharePoint® 技术集成到其应用程序当中，而他们的客户要向信息工作者提供统一的体验则更是难上加难。
在本专栏中，我将介绍 Office 应用程序如何与 SharePoint 进行集成和通信，以及可如何根据相同的原理实现非 Microsoft 应用程序与 SharePoint 之间的集成。不过，我将首先简要介绍用于实现无缝集成的服务器配置设置、客户端组件和通信协议。
了解这些细节之后，我将进一步介绍如何与不具备内置 SharePoint 支持的应用程序进行集成。一般来说，这方面的内容侧重于实现 IFilter 组件，以便扩展搜索功能并在 SharePoint 服务器上添加自定义图标，但我的介绍不仅限于此。扩展搜索并返回带有适当图标的结果并不表示实现了完整的应用程序集成；用户可能还希望直接在 SharePoint 用户界面中打开这些文档。
而这正是复杂之处。如果尚未在工作站上部署 Office，那您需要临时安装一个客户端组件。但即使已部署 Office，您仍可能发现该组件无法可靠地运行，具体取决于您的 SharePoint 站点拓扑和配置。
为解决这一问题，我创建了一个自定义解决方案，以让您在无需部署 Office 的情况下就可集成任意应用程序（如记事本、Adobe Reader 或 Autodesk AutoCAD）。该自定义解决方案还将说明基于标准 Office 组件的应用程序集成在某些情况下失败的原因。您可以在本专栏的随附材料（可通过网站的“代码下载”获取）中找到该解决方案以及分步部署和配置说明。

Office 应用程序集成
从用户角度来看，SharePoint 的菜单类似于 Windows®“开始”菜单。在文档库中创建一个新文档非常简单：单击“New”（新建），然后单击“New Document”（新建文档），Microsoft Office Word 2007 即启动。编辑现有的文档同样非常简单。将鼠标置于文档上方，打开“Edit Control Box (ECB)”（编辑控件箱）下拉菜单，然后单击“Edit in Word”（在 Word 中编辑）。很少有人会想到当通过 JavaScript 从网页启动 Word 2007 时，虽然您是在本地运行此应用程序，但文档却位于远程 SQL Server® 数据库中，并且 Web 服务器存在于数据访问路径当中（如图 1 所示）。
图 1 在 SharePoint 中处理 Word 文档（单击该图像可查看大图）
尽管比较复杂，但在安装了 2007 Office 系统的 Windows 工作站上可以得到无缝的用户体验。在 SharePoint 库中处理文档与处理本地文件或网络共享中的文件非常类似。
然而，如果没有安装 Office 2003 或 2007 Office 系统，Windows 工作站上的 UI 则有所不同。单击“New Document”（新建文档）或“Edit in Word”（在 Word 中编辑）仅出现一个对话框，提示您没有兼容 Windows SharePoint Services 的应用程序。
这也并不奇怪。要提供 Office 用户所中意的统一体验，必须多种元素协同工作才能实现。SharePoint 必须了解文档库中维护的内容类型才能在“New”（新建）和 ECB 菜单中呈现出所需的命令。为响应这些命令的鼠标单击事件，必须运行 JavaScript 代码以启动相关的应用程序，并沿文档路径传递。这部分工作与工作站配置有关，因为 JavaScript 代码是在本地运行。此外，相关的应用程序必须与 SharePoint 进行通信，以便读取并可能写入文件。如果希望将应用程序与 SharePoint 集成，则必须将这些元素组合在一起。
另一方面，SharePoint 与数据库服务器之间的通信对应用程序是透明的，并且 Web 服务器上的索引过程也对应用程序透明以便于搜索。因此，虽然我不会在本文中详细介绍这些方面的内容，但我建议您阅读 Microsoft 知识库文章“如何使用 Windows SharePoint Services 3.0 注册 Microsoft 筛选器包”（网址为 support.microsoft.com/kb/946338）以了解 Microsoft 筛选器包。现在，我们的重点是添加命令、实现必要的客户端组件和促进应用程序通信。

扩展 SharePoint UI
扩展 SharePoint 用户界面和功能的方法非常多。可更改站点的设计、自定义 ASP.NET 页面、开发 Web 部件，或更改 WSS 和 MOSS 中包含的 JavaScript 代码以便直接启动应用程序。
还可以在文本编辑器中打开 Ows.js 文件（该文件位于 SharePoint 前端服务器上的 COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 文件夹中），并更改 createNewDocumentWithProgIDCore、editDocumentWithProgIDNoUI 和 DispDocItem 函数的工作方式。但还有更好的方法，不需要您以不支持的方式更改 WSS 代码库：使用内容类型和文档类型映射。
在文章“使用自定义内容类型对数据管理进行标准化”（请参阅 2008 年 2 月刊的《TechNet 杂志》，网址为 technet.microsoft.com/magazine/cc194408.aspx）中，我解释了如何创建全局和特定于站点的内容类型以便管理文档以及 SharePoint 文档库和列表中的其他内容。也可以阅读该文章随附材料中的工作表 Text Content Type.pdf，它解释了如何为 .text 文件创建一个新的内容类型并将该内容类型与文档库进行关联。这样就可从“New”（新建）菜单选择“Text Content”（文本内容）命令，正如可针对 Word 文档选择“Document”（文档）命令一样（请参阅图 2）。
图 2 SharePoint UI 中的自定义内容类型（单击该图像可查看大图）
ECB 菜单同样可以进行扩展。您可能希望 ECB 菜单可以感知内容类型，但在当前的 WSS 版本中并非按照这种方式实现该菜单。必须在 Docicon.xml 中注册您的文档类型，该文件位于每台 SharePoint 前端服务器上的 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml 文件夹中。
例如，通过将以下文档类型映射添加到 Docicon.xml 的 <ByExtension> 段落中，就可使 SharePoint 显示“Edit in Notepad”（在记事本中编辑）命令（请参阅 Text Content Type.pdf 文件了解更多详细说明）：
<Mapping Key="text" Value="ictxt.gif"
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>
Key 参数标识文件扩展名、Value 参数定义显示在用户界面中的文档图标、EditText 参数定义 SharePoint 附加到“Edit in”（在…中编辑）命令中的字符串，而 OpenControl 参数指定客户端 COM 组件的 ProgID。SharePoint JavaScript 函数将该 ProgID 传递给 ActiveXObject 调用（请参阅 Ows.js 了解详细信息）以实例化 COM 对象（此对象可以是应用程序本身，也可以是基于相关文件类型启动应用程序的帮助程序控件）。
SharePoint 产品和技术网站

  • SharePoint 产品和技术网站
  • Windows SharePoint Services 技术中心
  • Windows SharePoint Services 开发人员中心
  • Microsoft SharePoint 产品和技术团队博客
请注意：名为 SharePoint.OpenDocuments 的 OpenControl 是指最新版本的 Office 随附的一个 ActiveX® 控件 (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll)。如果工作站中存在该文件且 SharePoint 服务器上的 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images 文件夹中存在指定的文档图标（Value 参数），则表示您可能已完成大部分必要的集成工作。
Windows SharePoint Services 3.0 SDK 中包含一些有关 2007 Office 系统随附的客户端 API（包括 OpenDocuments 控件）的信息。请参阅 msdn2.microsoft.com/ms440037 上有关客户端 API 参考的部分。

使用 Office OpenDocuments 控件
OpenDocuments 控件满足了最重要的应用程序集成需求，但它需要 Office 2003 或 2007 Office 系统，并且功能比较有限。“New”（新建）菜单中的命令可能并不总是有效，而且有时它们还会显示可能会误导用户的通知。
如图 3 所示，OpenDocuments 控件通知用户未正确安装所需应用程序或无法打开模板文件，但实际上并不存在这两种问题。“Edit”（编辑）菜单的功能也有问题。用户经常会看到显示在图 3 前面的第二条错误消息。我对这条消息记忆深刻，因为它甚至可以误导 SharePoint 专家，稍后我将向您详细介绍该消息。
图 3 OpenDocuments 控件令人误解的错误消息（单击此图像可查看大图）
尽管如此，对于所有工作站都已安装最新版本的 Office 的环境而言，OpenDocuments 控件非常有用。除此之外，可在“New”（新建）菜单中隐藏内容类型（显示“Document Library Settings”（文档库设置），单击“Change New Button Order And Default Content Type”（更改“新建”按钮的顺序和默认内容类型），然后取消选中所有内容类型的“Visible”（可见）复选框），这样用户就不会遇到第一条错误消息。还可使站点拓扑尽量简单，以避免基于 Web 的分布式创作和版本控制 (WebDAV) 通信问题，从而消除第二条错误消息。

与 SharePoint 进行通信
到目前为止，我已成功地扩展了 SharePoint UI，并可通过 OpenDocuments 控件启动应用程序，但我的应用程序仍需要一种方法来与 SharePoint 进行通信以访问数据。通常，SharePoint 支持多种方法来实现此目的，如 Microsoft Office FrontPage® Server Extensions、WSS 远程过程调用 (RPC)、WebDAV 和 Web 服务。实际上，Office 应用程序（如 Word 2007）可使用这些通信方法中的任意一种或全部，具体取决于访问文档的方法（如通过 Web 文件夹、映射网络驱动器或 SharePoint UI）。
每种 SharePoint 客户端/服务器通信方法都依赖 HTTP 作为底层协议。例如，FrontPage 和 WSS RPC 均使用 HTTP POST 和 HTTP GET 请求定向到 SharePoint 服务器上 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI 文件夹及其所有子文件夹中的 ISAPI 扩展。
ISAPI 最重要的一项扩展是 Owssvr.dll，它能处理列表和文档库。图 4 显示了在 Word 2007 中打开 SharePoint 的“Save”（保存）对话框（左侧），以及通过 URL 请求 http://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx 直接在浏览器中打开该对话框（右侧）的示例。两个屏幕快照之间的相似之处非常明显。
图 4 Word 2007 和 Internet Explorer 中的 SharePoint“Save”（保存）对话框（单击此图像可查看大图）
其他重要的 ISAPI 扩展包括 Author.dll，它运行 FrontPage 和 WSS RPC 以执行客户端编辑操作，如上载、重命名和删除文档）；Admin.dll 可用于管理站点并执行多个其他管理任务；Shtml.dll 可用于支持 HTML 表单提交。
通常，如果不访问源代码，则不会将 FrontPage 和 WSS RPC 支持添加到现有的应用程序中（如记事本或 Adobe Reader）。但是可通过 Windows 中包含的 Web 客户端功能来提供必要的通信工具。
SharePoint 还通过 Httpext.dll 支持 WebDAV（位于 %WINDIR%\System32\Inetsrv\ 文件夹中），但我们仅讨论在客户端的实现。运行 Windows Server® 2008 或 Windows Vista® 的计算机默认安装 Web 客户端功能。可在“控制面板”的“管理工具”中的“服务”小程序中找到对应的 WebClient 服务。在 Windows XP 和 Windows Server 2003 上，必须单独安装 Web 客户端。无论使用什么系统，均需确保已启动 WebClient 服务，并将“启动类型”设为“自动”。
图 5 显示了 Web 客户端的体系结构。WebClient 服务是在一个用户模式 DLL (Webclnt.dll) 中实现的，“服务控制管理器”将这个 DLL 加载到 Svchost.exe 宿主进程中。Webclnt.dll 提供“网络提供程序”接口来执行非 I/O 操作（如对访问 WebDAV 的用户执行身份验证；将 SharePoint 站点安装为网络驱动器；将 SharePoint 站点、列表和文档库枚举为网络资源；以及断开已安装的驱动器）。
图 5 WebDAV 客户端重定向程序体系结构（单击此图像可查看大图）
为此，Webclnt.dll 需要与提供实际重定向程序功能的内核模式文件系统驱动程序进行通信。WebDAV 客户端重定向程序驱动程序 (Mrxdav.sys) 以重定向驱动器缓冲子系统 (RDBSS) 为基础，该子系统与 I/O 管理器和其他内核组件集成以提供远程文件系统服务。Mrxdav.sys 运行 WebDAV 通信工具以支持对 SharePoint 站点和文档库进行文件系统级别的访问。
如果通过网络重定向程序访问 SharePoint 站点和文档库，则用户应用程序中将不再需要提供 FrontPage 和 WSS RPC 支持。可将网络驱动器映射到文档库（如 net use x:http://wss/doclib/Shared%20Documents），并且还可通过 UNC 路径访问 SharePoint 资源。
URL http://wss/doclib/Shared%20Documents 映射到 \\wss\doclib\Shared%20Documents。因此，可采用多种方式来在应用程序中打开文档。例如，可使用 HTTP 路径 http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt 或 UNC 路径 \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt 在记事本中打开文档。
遗憾地是，Web 客户端的功能存在一些限制。无法访问自定义属性或使用自定义 TCP 端口的 Web 应用程序。如果用户无权访问层次结构中的父站点，那么 Windows Vista 随附的 Web 客户端也会失败，如 WebDAV Access.pdf 中所述（请参阅随附材料）。
路径 http://sharepoint/HR/Administration/Shared%20Documents/ 包括一个不存在的根站点（即 http://sharepoint），而如果不访问根，Web 客户端将无法确定 Web 服务器的功能。Web 服务器拒绝 Web 客户端的 OPTIONS 请求且状态代码为 401，它表示访问并未通过身份验证，并且 Web 客户端将继续提示用户输入凭据，即使用户拥有站点集合 sharepoint/HR 及其中所有站点的管理访问权限（如图 6 所示）。
图 6 失败的 WebDAV 访问 （单击此图像可查看大图）
在使用 OpenDocuments 控件时，如果 Web 客户端无法打开文档，您将收到如图 3 所示的错误消息。应用程序运行正常且文档类型映射正确。原因在于无法通过 WebDAV 重定向程序访问该文档。

实施自定义 OpenControl 解决方案
通常，可通过以下两种方法来解决 Web 客户端的不足之处。可以等到 Microsoft 提供更新后的 Web 客户端版本，也可以实施能够解决当前状况的自定义 OpenControl 解决方案。实施自定义 OpenControl 并非易事，但它可以免去在工作站上安装 Office 的需要，使您能够以更有意义的方式处理“新建”（New）命令和“Edit in”（在…中编辑）命令，并且它还使您能够从 Web 客户端失败的境况中解脱出来。
如果这些问题中有您感兴趣的内容，请参阅随附材料中包含的 AppStart 源代码。它显示了如何在 Microsoft .NET Framework 程序集中公开 SharePoint JavaScript 代码可以调用的 OpenControl COM 接口。AppStart 源代码还展示了一种可行方法，如果无法使用 WebDAV 进行直接访问，该方法能通过 HTTP 检查能否访问文件并将文件下载到本地计算机。最后，AppStart 源代码通过将与内容类型相关的模板下载到本地计算机来响应“New”（新建）命令，从而使用户可以开始处理文档。Text Content Type.pdf 和 Adobe Reader Support.pdf 工作表介绍了部署此 OpenControl 解决方案的方法。
图 7 中所示的图表显示了 AppStart 的体系结构。我的自定义 OpenControl 组件（称为 Biblioso.dll）公开了两个等同的 COM 接口，SharePoint JavaScript 可以调用这两个接口来创建新文档或打开现有文档进行编辑（Biblioso.AppStart.2 和 Biblioso.AppStart.3）。
图 7 AppStart 的体系结构 （单击此图像可查看较大视图）
如果已打开文档进行编辑，Biblioso.dll 将确认文件是否存在，并且如果可直接通过 WebDAV 访问该文件，则启动相关的应用程序以及文档路径。如果无法访问该文件，Biblioso.dll 将启动进程外 COM 服务器，此服务器将加载 OpenDocsUtility.dll 以通过 HTTP 下载文件并启动应用程序以及已下载文档的路径。
进程外 COM 服务器使此解决方案可以摆脱 Internet Explorer® 进程（此进程要求必须在保护模式下将文件下载到 Temporary Internet 文件夹）。用户必须能够在不受保护模式限制的情况下下载文件，而作为应用程序代理运行的进程外 COM 服务器可以提供这一功能。
由于不支持使用 .NET 来开发进程外 COM 服务器，因此我转而使用 C/C++ 编写该可执行程序。我仅使用 C++ 实现最基本的“Save As”（另存为）对话框。为使解决方案尽可能地直观简单且减少开发工作量，我把实际的下载代码放在一个 .NET 程序集 (OpenDocsUtility.dll) 中，然后通过另一 COM 接口来进行调用。
为简化部署，我为该解决方案添加了一个“安装”项目。除此之外，安装例程注册了所有 COM 组件，并将应用程序特定的设置写入 HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart。最重要的两个参数是 AllowedApps 和 AllowedFileTypes。AppStart 解决方案仅适用于必须显式指定这些参数的应用程序和文件类型。
安装例程还为进程外 COM 服务器创建了一个提升策略，以便 Internet Explorer 进程中的 Biblioso.dll 可在不触发安全警报的情况下启动 AppBrokerEngine.exe。如果希望了解有关 Internet Explorer 保护模式和如何在应用程序开发中处理它的更多信息，强烈推荐阅读 Marc Silbey 和 Peter Brundrett 撰写的“了解并运行 Internet Explorer 保护模式”，网址为 msdn2.microsoft.com/bb250462。
在查看 AppStart 组件时，请记住开发此解决方案的目的只是为了说明能够实现哪些功能；它并不适用于生产环境。我们没有足够的时间去优化代码和全面测试该解决方案，并且除源代码注释外，并未编写功能文档。
使用该解决方案所带来的风险应由您自己承担。如果有兴趣研究源代码以创建自己的解决方案，可从 Biblioso 代码项目中的 AppStart.cs 着手。该文件实现了 OpenControl COM 接口和来自 Ows.js 的 JavaScript 调用的入口点。
总结
在处理文档以及 SharePoint 文档库和列表中的其他项目时，WSS 3.0 和 MOSS 2007 提供了大量应用程序集成功能以实现无缝的用户体验。2007 Office 系统中的桌面应用程序非常生动地展示了这一点，并且还有可能与非 Office 应用程序实现相同级别的集成和可用性。
应用程序集成体系结构的核心是 SharePoint JavaScript 函数所使用的 COM 组件，以及用于启动应用程序的文档路径。2007 Office 系统提供了多个针对特定 Office 应用程序需求优化的 COM 组件，并且还可重用 Office OpenDocuments 控件来集成非 Microsoft 应用程序。OpenDocuments 控件满足了最基本的需求。对于更高级的应用程序集成需求，可创建一个自定义控件。
要实现应用程序与 SharePoint 的完全集成，不仅需要安装 IFilter 组件和文档图标以扩展搜索和显示功能，还需在 SharePoint 服务器上创建自定义内容类型和文档类型映射以便在 SharePoint 用户界面中提供适当的“New”（新建）和“Edit in”（在…中编辑）命令。这些命令调用 JavaScript 函数，而这些函数又调用通过 OpenControl 组件公开的方法。工作站上还必须有 OpenControl 组件。
另一重要组件是 Windows Vista 上默认包含并安装的 Web 客户端。Web 客户端实现了 WebDAV 重定向程序和远程文件系统驱动程序，这样所有应用程序都可以通过类似于在网络中共享文件的方式访问 SharePoint 列表和文档库中的资源。尽管 Windows Vista 随附的 Web 客户端具有一些缺陷，但它仍是应用程序集成过程中的一个极其重要的部分。
WebDAV 支持还弥合了在非 Windows 工作站上运行的应用程序与 SharePoint 之间的沟壑。在这些操作系统中，COM 和 ActiveX 控件技术通常均不可用，因此无法使用 OpenControl 组件来自动启动应用程序，但大多数操作系统都包含 WebDAV 重定向程序，因此用户至少可以直接访问文档库，而不必将文件下载到本地工作站。
WSS 3.0 和 MOSS 2007 是 2007 Office 系统成功的基础，并且使用第三方基于 Office 的应用程序的用户可以采用同样的方法来从 SharePoint 中获益。集成功能远远超过了 Office。通过充分利用 SharePoint，可构建一个统一的办公解决方案平台，该平台提供 Office 和第三方软件所具有的相同用户体验，从而提高信息工作者的生产效率。

Pav Cherny 是一位 IT 专家兼撰稿人，专门研究 Microsoft 协作与统一通信技术。他的作品包括白皮书、产品手册和书籍，其内容主要介绍 IT 运营和系统管理。Pav 是 Biblioso Corporation 的总裁，该公司主要经营托管文档和本地化服务。

© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利；未经允许不得复制本文的部分或全部内容


Windows PowerShell 投球框
Don Jones

目录
扮演 Cmdlet
筛选函数
从物理对象角度思考
实际应用
游戏时间
在我最近讲授的一堂 Windows PowerShell 课中，一些学生难以想象出外壳管道的具体含义。我承认管道从概念上讲不十分直观，因此对于习惯于视觉教学的初学者来说，要弄清楚它的含义有些困难。当我讲到
直接在管道中工作的筛选函数的概念时，事情真地棘手起来，从他们的表情我可以看出有些学生没有听懂。
为了解决他们的困惑，第二天我带来了一个球框、一些名称标记贴纸和一些乒乓球（嘿，谁说 Windows PowerShell® 不能变得饶有趣味）。我决定使用以下命令行做个展示：
Get-Process | Where { $_.VM –gt 1000 } | Sort VM
–descending | Export-CSV C:\Procs.csv

扮演 Cmdlet
通过使用名称标记贴纸，就是您经常在同学会或类似活动中佩戴的“你好，我是……”贴纸，我给每个学生分配一个 cmdlet 名称。我解释说乒乓球代表 Windows® 进程对象（更具体地说，是 System.Diagnostics.Process 类型对象），然后我要求学生告诉我哪个 cmdlet 名称听起来最可能生成进程对象。
看过彼此的标记后，他们认为是最明显的选项 Get-Process。这也是我非常喜欢 Windows PowerShell 中使用的 cmdlet 名称的一个主要原因：它们表述得十分清楚。
因此，饰演 Get-Process 的学生抓起所有乒乓球并将它们投入纸板框中。这个框代表外壳的管道，学生的动作几乎就是 cmdlet 的功能。cmdlet 生成一个或多个对象，然后将它们倒入管道中。
然后管道中的下一 cmdlet 取得执行权。在此示例中，代表 Where-Object cmdlet 的学生捡起所有乒乓球，并一个一个地检查，查看是否某个球的 VM 属性大于 1,000。在外壳中，“VM”代表虚拟内存，在本练习中，我在每个乒乓球的标签上写下了不同数量的虚拟内存。
VM 大于或等于 1,000 的每个球（或称为进程）会返回球框（有时称为管道）中，其他的球弃之不用。（实际并非如此，我将它们解救了出来以便在将来的课程中使用。）
接下来，假扮 Sort-Object 的学生仔细检查乒乓球框，并根据 VM 属性将它们依次排序。我必须承认这里有点儿考虑不周 — 球总是滚来滚去的！看来下次课我得找一些方形的乒乓球，或者准备一些鸡蛋箱。
最后，扮演 Export-CSV 的学生捡起球并将信息写到一个 CSV 文件中。在真实世界中，是将进程的属性写到我们假设为 CSV 文件的活动挂图中。

筛选函数
了解过简单的管道后，我们决定看看筛选函数（它要复杂一些）。我推荐图 1 中所示的筛选函数和命令行。
图 1 示例筛选函数和命令行
Function Do-Something {
 BEGIN { }
 PROCESS {
  $obj = New-Object PSObject
  $obj | Add-Member NoteProperty "TimeStamp" (Get-Date)
  $obj | Add-Member NoteProperty "ProcessName" ($_.Name)
  Write-Output $obj
 }
 END {}
}
Get-Process | Do-Something | Format-Table *
首先，我想简要回顾一下筛选函数的功能。此函数包含三个脚本块：BEGIN、PROCESS 和 END。
在管道中使用此函数时，首先执行 BEGIN 脚本块。此脚本可能执行一些设置任务，如打开数据库连接。
然后，PROCESS 脚本块对通过管道传递给函数的每个对象执行一次。在 PROCESS 脚本块中，自动使用当前管道对象填充 $_ 变量。因此，如果传入 10 个对象，PROCESS 脚本块将执行 10 次。
最后，在执行完所有传入对象后，运行 END 脚本块并执行所有必要的清理任务（如关闭数据库连接）。
在这些脚本块中，使用 Write-Output 编写的所有内容将存储在下一 cmdlet 的管道中。其他内容则会被丢弃。
由于命令始于 Get-Process，之前的学生将所有乒乓球归拢在一起（我们休息了一会，有人就恶做剧一样将球扔得到处都是 — 想想看吧）并将它们投入管道框中。这项工作完成后，扮演“Do-Something”筛选函数的学生接过执行权。
他首先执行自己的 BEGIN 脚本块。它是空的，因此并不费事。接下来，他拾起所有管道对象（乒乓球）并开始一个一个地查看。这挺有趣的，因为一共大约有一打球，他正尽力在膝盖上摆放所有的球 — 哦，也许正需要您的帮助。
总之，他一次挑选一个进程对象并执行 PROCESS 脚本块。该脚本块让他创建一个全新的自定义对象（我使用特殊的黄色乒乓球来代表它，在当地体育用品店中找到这些球可不是件容易事）。在这些新乒乓球上，他记下了当前日期和时间以及当前查看的进程对象的名称。
这个新自定义对象随后被写入管道，即他将黄色乒乓球放入球框中，丢弃原来的进程对象乒乓球。他对框中的每个进程对象乒乓球执行此操作，总计约 12 个。完成后，每个白色乒乓球都被替换成黄色的自定义对象乒乓球。最后，他执行 END 脚本块（它没有内容，不耗费任何时间）。
为了有始有终，扮演 Format-Table 学生现在登场。她捡起框中的所有球（此时全是黄色的“自定义”对象）并开始使用每个球上写的属性构建一个表。最终会生成写在活动挂图上的一个表，共有两列（TimeStamp 和 ProcessName），大约十二行。

从物理对象角度思考
此练习使管道和筛选函数真正触动了班级中的每个人。乒乓球出色地表达出了对象的含义，如果只说外壳很容易让人感觉抽象。
每个人都可以看到 cmdlet 如何处理这些对象，结果如何被放入管道中以及下一 cmdlet 如何选取这些结果并进一步处理对象。筛选函数中的事件顺序更加明显，因为 PROCESS 脚本块技术一次处理一个输入对象。
它还显示了创建新自定义对象并将其放入管道的方式。并且，它有助于展示生成自定义对象的好处，与简单文本相比，其他 cmdlet（如 Format-Table）可使用新的自定义对象，随后可以很灵活地选择使用和代表数据的方式。

实际应用
学生中一个普遍的问题是如何在实际应用中使用我们刚才展示的管道和筛选函数。对于我来讲，答案很简单，因为我刚为最近的一个会议制作了一些示例（可从 scriptinganswers.com/essentials/index.php/2008/03/25/techmentor-2008-san-francisco-auditing-examples 自行下载示例）。
其中一个示例是要列出 Win32_UserAccount 类的多个属性，它来自多个计算机的 Windows 管理规范 (WMI)。假定计算机名称列在 C:\Computers.txt 中，以下简单命令即可完成此工作：
Gwmi win32_useraccount –comp (gc c:\computers.txt)
问题在于 Win32_UserAccount 类并不包括告诉您每个实例来自哪个计算机的属性，因此结果列表将是一个无用的大杂烩，其中包含许多计算机的帐户。我的解决办法是创建一个包括源计算机名称的新自定义对象并选择所需的类属性。此自定义对象的代码如图 2 所示。
图 2 使用自定义对象来收集计算机名称并选择属性
function Get-UserInventory {
  PROCESS {
    # $_ is a computer name
    $users = gwmi win32_useraccount -ComputerName $_
    foreach ($user in $users) {
      $obj = New-Object
      $obj | Add-Member NoteProperty Computer $_
      $obj | Add-Member NotePropertyPasswordExpires ($user.PasswordExpires)
      $obj | Add-Member NoteProperty Disabled ($user.Disabled)
      $obj | Add-Member NotePropertyFullName ($user.FullName)
      $obj | Add-Member NoteProperty Lockout ($user.Lockout)
      $obj | Add-Member NoteProperty Name ($user.Name)
      $obj | Add-Member NotePropertyPasswordRequired ($user.PasswordRequired)
      $obj | Add-Member NotePropertyPasswordChangeable ($user.PasswordChangeable)
    }
  }
}

Get-Content c:\computers.txt |
  Get-UserInventory |
  where { $_.PasswordRequired -eq $False } |
  selectComputer,Name |
  Export-Csv c:\BasUsersBad.csv
最后的命令行将所有计算机名称传递给筛选函数（它会生成自定义对象）。接下来，我筛选掉所有其他用户，只保留其 PasswordRequired 属性为 False 的用户（此想法旨在生成问题帐户的审核报告）。然后我仅保留 Computer 和 Name 属性，这样最终报告是一份计算机名称和帐户名称的列表，由于它们的密码永不过期，因此需要加以注意。 筛选函数能生成这份多计算机报告，因为它向输出添加了源计算机名称，同时仅留下了我所感兴趣的属性。
尽管有其他类似方法可完成此任务，但此方法可能最直接。它还可用于阐述重要概念和技术。

游戏时间
即使已经对管道运用自如，仍有许多内容需要学习。从物理对象角度思考有助于弄清楚您正在尝试做什么。
因此下次遇到 Windows PowerShell 概念问题时，试着跳出计算机的束缚，以日常物品为例来模仿任务。我的愚见是在手边放一小袋乒乓球（或立方体，如果找得到）备用。
本月 Cmdlet：Out-File
您有多少次使用 > 符号将 cmdlet 的输出导出到某个文件？它类似于 Get-Process > Processes.txt。您是否知道您实际只是使用伪装的 Out-File cmdlet？以下是执行完全相同功能的命令：Get-Process | Out-File Processes.txt。
当然，它需要的键入操作要多一点，那么为什么要麻烦地键出完整的 Out-File cmdlet？一个原因是 Out-File 在阅读时要更加清楚些。比如，某人六个月后可能看到您的一个脚本，并且想知道 > 代表什么（毕竟，它是一种旧事物）。
相反，Out-File 非常清楚地表示将创建一个文件并将其写出。并且，Out-File 提供了 -append 参数（非常类似于 >>）以及 -force 和 -noClobber 参数，从而使您可以控制是否覆盖现有文件。最后，键出 Out-File 还可以让您访问 -whatif 参数。这个便捷的参数将向您展示 Out-File 将执行的操作，但并不会实际执行！它是测试复杂命令行的一个不错方法，几乎没有风险。
视频
观看 Don Jones 如何运用这些 cmdlet。

Don Jones 是《Windows PowerShell:TFM》一书的合著者并且教授 Windows PowerShell 课程 (www.ScriptingTraining.com)。


您好，脚本专家！ 肾上腺素刺激
Microsoft 脚本专家

毫无疑问，在我们看来为《TechNet 杂志》撰稿是一份最受尊敬、最有价值的工作了。（当然，如果实际得到了报酬，那它的价值还会更高，但那是另外一回事了）。这份工作究竟有多么受人尊敬？让我们这样来解释一下：现在，在全世界，孩子们在被塞进被窝时都会看着他们的母亲并对她们说：“妈妈，等我长大了，我要为《TechNet 杂志》撰写每月的脚本专栏。”
注释 当然，现在全世界有很多人都相信本专栏已由孩子们撰写了。但那同样是另一码事。
众所周知，脚本专家们非常享受为《TechNet 杂志》撰写文章得到的盛誉；我们甚至学会了忍受狂热追星族和狗仔队。但实情是，我们从事这份工作不是为了荣耀和崇拜；而是为了从编写系统管理脚本获得纯粹的肾上腺素刺激。
无可否认，您很少会看到“纯粹的肾上腺素刺激”和“系统管理脚本”出现在同一句话中。（当然，“纯粹的肾上腺素刺激”前面的形容词是“完全没有”是个例外。)
一般人会认为系统管理脚本非常有用，但并不会让人感到非常激动；实际上，他或她很可能觉得脚本编写有些单调。原因如下：他们当中还没有一个人尝试过在 Windows Vista® 或 Windows Server® 2008 中编写引导配置数据脚本。
这个消息让您心动了，是吗？读到这里您可能就知道了，在 Windows Vista 和 Windows Server 2008 中，旧的 boot.ini 文件已被废弃，改为使用新的引导配置数据存储（在管理引导过程方面，它会提供更好的灵活性和功能）。
太酷了。但真正酷的是：托新的 Windows® 管理规范 (WMI) 提供程序的福，现在可以使用脚本来轻松地访问并完全管理引导配置数据 (BCD) 存储了。
不要担心脊柱中有种上下乱窜的奇怪感觉；它就是纯粹的肾上腺素刺激的感觉。开始和 BCD 脚本打交道后，您就会开始习惯这种感觉了。
在深入介绍之前，应声明我们无法一开始就涵盖可利用 BCD 提供程序完成的所有功能，至少在这一个专栏中是不可能的。（我们向杂志的编辑发了封电子邮件，询问是否能专门为编写引导配置数据脚本做一期合刊，但目前尚未收到他们的答复。）
要了解更多完整的信息，请参阅 go.microsoft.com/fwlink/?LinkId=116953 上的 BCD WMI 提供程序文档。与此同时，我们将向您展示一些设计用于多引导计算机（即安装了多个操作系统的计算机）的示例代码。
对了，这些脚本仅适用于 Windows Vista 和 Windows Server 2008。这是因为目前只有这两个操作系统支持 BCD，我们之前已提到这一点。
首先来看一个可以告诉我们计算机上当前正在使用哪个 OS 的脚本。当然，它并非 BCD 提供程序最令人激动的用途；毕竟，我们已可以使用 WMI 类 Win32_OperatingSystem 来确定计算机上当前正在使用哪个 OS。但是，它是一个相当简单的脚本（就 BCD 脚本而言至少是这样），并且提供了一种不错的方法来说明使用 BCD 时所需要的基本技术（至少可以说是有些不同寻常的技术）。
此外，我们不能在专栏中包含过多令人兴奋的内容：《TechNet 杂志》已告诉我们，如过份激动和热情的“您好，脚本专家！”粉丝有不当行为，罪名会落到我们头上。考虑到我们的专栏定期出版后会在全球引发故意伤害罪，我们不能再次为兴奋买单了。
注释 记不记得甲壳虫乐队被粉丝骚扰的那些视频以及女孩子们看到 John、Paul、George 和 Ringo 时昏厥和尖叫的那些照片？这与我们每次出版新专栏的情形何其相似。
好吧，打住，这么说是有些夸张了。但毫无疑问，许多人（无论男女）在阅读了我们的某期专栏后会情绪激动。
无论如何，来看一看图 1 中的脚本，它使用 BCD 提供程序来判断计算机当前正在使用那个 OS。在尝试运行该脚本之前，您应该知道必须以管理员身份运行，否则该脚本会失败。
图 1 获取当前的操作系统
Const BcdLibraryString_Description = &h12000004
Const Current = "{fa926493-6f1c-4193-a414-58f0b2456d1e}"

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.OpenObject Current, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
Wscript.Echo "Current operating system: " & objElement.String
这当然并不表示只需以管理员权限登录某个帐户即可。您需要通过右键单击“开始”菜单中的“命令提示符”并以管理员身份选择“运行”，来打开一个命令提示符窗口。然后，可通过命令提示符运行该脚本。
那么，此脚本的工作原理是什么？您知道，我们很担心您会继续问下去。不过没关系，我们会尽我们所能地进行解释（即，至少保证一小段时间内不扩大兴奋）。
首先，我们定义两个常量：BcdLibraryString_Description 和 Current。BcdLibraryString_Description 指我们要检索的对象；在本例中，该对象包含当前操作系统的“说明”（名称）。
顺便提一下，它是使用 BCD 提供程序时的一个既可爱又奇怪的地方。通常，无法仅检索某个属性的值；而是使用其中一个常量（以及 GetElement 方法）来检索另一个对象，然后回显属于该对象的某个属性的值。当然，这有点滑稽可笑，但您知道人们常说的那句话吗：过程与目标同等重要。
注释 这让您对他们的目标感到困惑，是吗？
至于常量 Current，它只是用于代表当前正在使用的操作系统的一个 GUID。值
{fa926493-6f1c-4193-a414-58f0b-2456d1e}
被视为是一个“众所周知”的 GUID（它又一次证明 Microsoft 人实际非常具有幽默感）。
虽然这个 GUID 众所周知，我们还是执意把它包括进来，以防诸位中有人记不得以下两个值中哪一个是正确的：
{fa926493-6f1c-4193-a414-58f0b2456d1e}
{fa926493-6f1c-4193-a414-58f0b2456d1f}
注释 如果您想知道 GUID 应发音成“gwid”还是“goo-id”，我们可以告诉您更多内情，比如前述的 GUID 必须为 V1 GUID，就像第三组数字如何以 4 开头一样。但我们已保证过将兴奋感保持在最低程度。我们将信守承诺。
正如您可能已猜到的，在使用 BCD 提供程序时，随时都需要使用常量、十六进制值和 GUID。我们无法在本月专栏中介绍到所有内容，但您可以通过访问先前提到的 MSDN® 上的 BCD 页面 (go.microsoft.com/fwlink/?LinkId=116953) 来了解更多信息。前提是您能经受得住所有兴奋带来的震撼。
定义完两个常量后，接下来连接本地计算机上的 WMI 服务。能使用此脚本来检索远程计算机的引导配置数据吗？当然可以。
坦白地讲，如果这都做不到的话，这些 BCD 也太没价值了。为检索远程计算机（再次强调一下，远程计算机必须运行 Windows Vista 或 Windows Server 2008）的引导配置数据，只需将该计算机的名称指定给变量 strComputer 即可：
strComputer = "atl-fs-001"
还应指出 WMI 连接字符串中的一对关键字项。首先，您可能已注意到连接字符串中同时包含了“备份”和“恢复”权限，这也是 {(Backup,Restore)} 结构的作用。这重要吗？如果希望脚本有效，那它就非常重要：如果未明确包括这两个权限，脚本将失败。
其次，请注意我们并未连接到系统管理脚本中最常用的 root\cimv2 命名空间。我们是连接到 root\WMI 命名空间并直接绑定到 BCDStore 类。下面这些代码就用来解决这个问题：
"\root\wmi:BcdStore"
它还不是令人兴奋的部分。好戏还是后面呢。
除了少数例外，对于大多数人来说，编写的所有 BCD 脚本都包括相同的三个步骤：定义常量、连接到 WMI 服务然后打开 BCD 存储。我们已完成步骤 1 和步骤 2，下列代码行将执行步骤 3：
objStoreClass.OpenStore "", objStore
正如我们所说到的，我们将打开 BCD 存储（即存储所有引导配置信息的操作系统实体）。要打开该存储，只需调用 OpenStore 方法并向该方法传递两个参数：
  • 空字符串 ("")。这是告诉脚本我们想要打开默认存储。
  • objStore。它位于我们向该脚本提供的一个“输出”参数中。我们向该方法提供变量的名称，作为回报，该方法会返回一个对象，它将该变量名用作对象引用（在本例中，即代表 BCD 存储的对象）。
一旦打开存储，就可使用 OpenObject 方法来检索另一对象（存储在输出参数 objDefault 中）：
objStore.OpenObject Current, objDefault
这个新对象是什么？没错：它就是当前正在使用的操作系统。这是因为我们向 OpenObject 传递了常量 Current（即代表当前操作系统的众所周知的 GUID）。
好了，现在我们知道计算机上当前正在使用哪个操作系统了，对吧？差不多是这样。要获取该信息，我们还需要使用 GetElement 来检索代表该操作系统的“说明”的一个对象：
objDefault.GetElement _
  BcdLibraryString_Description, objElement
现在，您能保证自己不会过于兴奋，也不会犯下故意伤害罪吗？很好。如果是那样的话，可以告诉您：现在可回显 String 属性的值，并最终确定计算机当前正在使用的操作系统：
Wscript.Echo "Current operating system: " _
  & objElement.String
请保持冷静。要记得您的承诺：不要犯故意伤害罪。我们知道这确实很难。但请尽力而为。试着深呼吸，在我们编写 BCD 脚本时这一招始终非常管用。
正如我们所讲到的，仅仅是确定计算机正在使用哪个操作系统就充满了这么多艰难险阻；其实上有更轻松的方法可完成该项任务。但从积极的一面来看，您现在已了解 BCD 脚本的工作原理，即意味着您可以做一些脚本编写者还没做过的事情。（冷静，再冷静。）例如，在多引导计算机上，始终有一个操作系统已标记为“默认”；如果计算机重新启动而周围没有人告诉它其他指示，则计算机将自动加载默认操作系统。在 Windows Vista（以及 BCD 提供程序）之前，脚本编写者是无法确定计算机上的默认操作系统的。但现在，只需运行一个像图 2 中那样的脚本就可以轻松做到这一点了。
图 2 确定默认操作系统
Const BcdLibraryString_Description = &h12000004
Const BootMgrId = "{9dea862c-5cdd-4e70-acc1-f32b344d4795}"
Const DefaultType = &h23000003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
    strComputer & "\root\wmi:BcdStore")
objStoreClass.OpenStore "", objStore

objStore.OpenObject BootMgrId, objBootMgr

objBootMgr.GetElement DefaultType, objDefaultOSIdentifier
objStore.OpenObject objDefaultOSIdentifier.Id, objDefault

objDefault.GetElement BcdLibraryString_Description, objElement
WScript.Echo "Default operating system: " & objElement.String
你们说对了：它确实会让过度兴奋，不是吗？但必竟很少，是吧？我们将不再详细解释该脚本；假如您并未错过前面的 10 或 12 个段落的话，您应当能够自行遵循该逻辑。但您可能注意到了，为了获取默认操作系统，我们不得不使用一个中间步骤：使用 OpenObject 方法打开一个“引导管理器”对象的实例。打开“引导管理器”后，可使用常量 DefaultType 来检索代表默认操作系统的一个对象。
不可否认，现在已相当地激动人心了：可确定当前的操作系统，同时可确定默认的操作系统。但您知道什么才是真正的酷吗？那就是检索在计算机上安装的所有操作系统的列表。那才是真正的激动人心！先稳定住自己的情绪，然后看一看图 3。
我们做了些什么？首先定义了两个新常量：WindowsImages，可用于检索支持 BCD 的所有 OS 实例（即 Windows Vista 和 Windows Server 2008）；LegacyImages，可用于检索计算机上的所有“传统”操作系统的实例。连接到 BCD 存储后，使用 EnumerateObjects 方法来检索计算机上安装的所有支持 BCD 的操作系统的实例：
objStore.EnumerateObjects _
  WindowsImages, colObjects
图 3 查找计算机上的所有操作系统
Const BcdLibraryString_Description = &h12000004
Const WindowsImages = &h10200003
Const LegacyImages = &h10300006

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore

objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
Wscript.Echo

objStore.EnumerateObjects LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
EnumerateObjects 完成任务后，建立一个 For Each 循环来遍历该集合中的所有操作系统。在该循环中，使用以下两行代码来检索并显示操作系统“说明”：
objObject.GetElement _
  BcdLibraryString_Description, objElement
Wscript.Echo objElement.String
然后针对计算机上安装的所有传统操作系统重复该过程。
objStore.EnumerateObjects _
  LegacyImages, colObjects

For Each objObject in colObjects
 objObject.GetElement _
  BcdLibraryString_Description, objElement
 Wscript.Echo objElement.String
Next
注释 我们能理解其中的陶醉感觉，但请小心谨慎地运行 BCD 脚本；很可能人体所能承受的肾上腺素刺激数量是有限度的。未经医生的事先检查，孕妇、可能成为孕妇、永远不会成为孕妇或曾经是孕妇的女性，以及纯正的男性公民均不应运行 BCD 脚本。
好吧，您无需事先经过医生的检查。但是，如果向医生询问他对于运行 BCD 脚本的看法，听听他的回答可能会相当有趣，不是吗？
现在，让我们来尝试点真正疯狂的东西吧 — 看看是否可以更改默认操作系统。例如，假设我们有一台同时运行 Windows Vista 和 Windows Server 2008 的双引导计算机。再假设我们希望将 Windows Vista 设为默认操作系统。我们将如何做呢？好的，看一看图 4。它展示了完成此项任务的一种方法。
图 4 更改默认操作系统
Const BootMgrId = "{9dea862c-5cdd-4e70-accl-f32b344d4795}"
Const BcdLibraryString_Description = &h12000004
Const DefaultType = &h23000003
Const WindowsImages = &h10200003

strComputer = "."

Set objStoreClass = GetObject("winmgmts:{(Backup,Restore)}\\" & _
 strComputer & "\root\wmi:BcdStore")

objStoreClass.OpenStore "", objStore
objStore.EnumerateObjects WindowsImages, colObjects

For Each objObject in colObjects
 objObject.GetElement BcdLibraryString_Description, objElement
 If Instr(objElement.String, "Vista") Then
  objStore.OpenObject BootMgrId, objBootMgr
  objBootMgr.SetObjectElement DefaultType, objObject.ID
 End If
Next
通过此脚本，再次打开 BCD 存储，然后使用 EnumerateObjects 来检索计算机上安装的所有支持 BCD 的操作系统的集合。在此我们设置一个 For Each 循环来遍历集合中的所有项，使用下行代码（到现在应该很熟悉了吧）检索每个操作系统的“说明”：
objObject.GetElement _
  BcdLibraryString_Description, objElement
获取给定操作系统的“说明”后，使用 InStr 函数来查看该值中是否包含词语 Vista：
If Instr(objElement.String, "Vista") Then
您说得对，这样看上去有点笨，对吧？比较酷的方法是使用 Windows Vista 的 GUID，然后直接打开该操作系统，这样就不必枚举并遍历计算机上的所有操作系统。
遗憾的是，我们必须知道 Windows Vista 的 GUID 才能使用这种很酷的方法。使用我们的方法不必知道任何事情（这对于脚本专家们倒是好事）；我们需要做的就是不断地搜索直至找到标题中包含词语 Vista 的操作系统。
注释 如果计算机上安装了多个 Windows Vista 实例呢？这时您可能需要查找一下 Vista Ultimate 或 Vista Enterprise 之类的字符串。
一旦找到 Windows Vista，就使用以下两行代码来打开 Windows 引导管理器，然后将默认操作系统设为 Windows Vista：
objStore.OpenObject BootMgrId, objBootMgr
objBootMgr.SetObjectElement _
  DefaultType, objObject.ID
我们这个月的内容就到这里了；毕竟，即使是脚本专家，我们也无法应付随时随地无休无止的激动。但不用担心；下个月我们还会带来另一期激动人心的“您好，脚本专家！”。希望您届时已恢复过来。
Scripto 博士的脚本谜题
每月挑战不仅测试您解决谜题的能力，还测试您的脚本编写技能。

2008 年 7 月：VBScript 方块
它们可能是矩形而非方块，但那是题外话了。要解出这个谜题，需将右侧的每个方块放入左侧的空方块中，从而构成 VBScript 函数的名称。每个方块只能使用一次。下面是一个示例：
要正确地解出这个示例，需要将 OU 方块（矩形）移到第一个词语的空方块中，然后将 MS 和 OX 移动到第二个词语的空方块中。这样就构成了 VBScript 函数 UBound 和 MsgBox，如下所示：
现在您来试一试：

答案：
Scripto 博士的脚本谜题
答案：VBScript 方块，2008 年 7 月

脚本专家为 Microsoft 工作，也就是受雇于 Microsoft。在不玩、不教或不看棒球（以及各种其他活动）的时候，他们负责管理 TechNet 脚本中心。要查看相关信息，请访问 www.scriptingguys.com。


桌面文件 网络引导 Windows
Wes Miller

目录
PXE 的工作原理
深入探究 RIS
WDS — 起点
其他参与方
结束语
在接下来的几个月中，我打算介绍 Windows 部署服务 (WDS)，Windows Server 2003 中包含这项服务，它还内置到了 Windows Server 2008 中。WDS 可能是部署基础结构中一个非常重要的组件，因此我希望确保您有良好的基础进行讨论。第一篇
专栏将深入介绍预引导执行环境（PXE；发音为 pixie）的体系结构、远程安装服务 (RIS) 的历史以及 Microsoft 使用的其他与 PXE 相关的技术。
在 2001 年调到 Windows 核心操作系统组时，RIS 是我接手的一项技术（由于其复杂性和对 BIOS 实现及硬件的依赖性，当时感觉有些忐忑不安）。但是，除 Windows® PE 外，它是我作为项目经理最喜欢的技术之一。
我还记得首次安装 Windows 3.0 时的情形，当时使用的是一组 3.5" 磁盘。后来，可引导 CD（包括在某些版本的 Windows 98 中）的出现让安装变得更加轻松。但实际上，安装始终需要某些类型的本地媒体以及本地硬盘。
客户对通过网络引导 Windows 的需求与日俱增 — 即，无需硬盘，完全通过网络进行引导。尽管 Windows 的某些早期版本具有该功能，但 Windows NT® 却没有。而且，尽管可通过 iSCSI 启动程序引导当前版本的 Windows Server® 2003 和 Windows Server 2008，但此过程与真正的网络引导有很大区别 — 它始终需要依赖一个远程驱动器作为引导驱动器。
预先设置客户端
  • 评估 RIS 客户端预先设置过程
  • 使用预先设置的客户端计划网络安全增强功能
  • 预先设置客户端计算机
  • 远程操作系统安装
自 Windows 2000 起，Microsoft 开始开发最终称为 RIS 且允许基于网络进行安装的一种技术。RIS 的目标比较简单 — 使用 PXE 将操作系统映像放在目标计算机的本地硬盘上。

PXE 的工作原理
图 1 显示了 PXE 引导序列。PXE 是一个相对简单的协议，由 Intel 和其他供应商制定，属于“有线管理”计划的一部分。PXE 派生自动态主机配置协议 (DHCP)（它又派生自 BootP），通常在网络接口卡 (NIC) 中实现。简而言之，以下是具体的步骤：
图 1 PXE 引导序列（单击此图像查看大图）
第 1 步系统 BIOS 启动并确定引导顺序。
第 2 步如果引导顺序将 PXE 放在硬盘、闪存驱动器、或 CD-ROM 之前，或者不存在这些设备，将从 NIC 加载通用网络驱动程序接口 (UNDI)。NIC 具有一个极小的网络设备驱动程序和普通文件传输协议 (TFTP) 实现。（某些 BIOS 实现需要最终用户按 F12 键才能执行 PXE 引导。这并非标准做法，我建议禁用这一功能。）
第 3 步系统执行一个简单的用户数据报协议 (UDP) 广播，以查找 DHCP 服务器。它实际是 PXE 引导序列的第一步，称为“发现”。请注意，协议是 UDP — 意味着首先需要花费一些时间来处理路由器和交换机，以确保所有 PXE 通信均可顺利通过。
第 4 步如果 DHCP 服务器听到广播，它将使用 IP 地址来做出相应的响应。此步骤称为“提供”。在此要特别注意的一点是：PXE 没有状态，此时客户端必须提供的系统独有状态信息的数量非常有限（MAC 地址，还可能有系统管理 BIOS GUID，也称为 SMBIOS GUID）。
第 5 步在接收包含 IP 地址的数据包后，客户端表示它实际需要更多信息 — 即 PXE 服务器的地址。再次进行广播，其中包括最初响应 DHCP 服务器的信息。此时客户端告诉 DHCP 服务器：“我需要更多信息 — 尤其需要网络引导程序 (NBP) 的位置。”此步骤称为“请求”。
第 6 步PXE 服务器使用 PXE 服务器地址和 NBP（一个极小的引导可执行文件，小于 32KB）的位置做出响应。此步骤称为“确认”。如果在同时操作，您可能已注意到首字母缩写词 DORA（Discover-发现、Offer-提供、Request-请求、Acknowledge-确认），一个记住序列的好方法。
请注意，如果已安装 Microsoft DHCP 和 WDS（或使用某些其他供应商的技术），则不会出现请求步骤，并且实际上，来自 DHCP 服务器的原始“提供”数据包已包括 PXE 服务器和 NBP 程序的位置（因而省去了两个步骤以及一些时间）。
第 7 步客户端（具有之前提及的小 TFTP 协议堆栈）将从 PXE 服务器指定的网络位置下载 NBP。TFTP 是一个标有日期且无状态的超微型协议。它在安全性或性能上并不出众 — 因此许多路由器管理员均默认禁用它。必须启用它 PBX 才能正常运行。
许多 PXE 实现（包括 RIS）都可以要求用户此时按 F12 键继续操作，但 PXE 服务器的管理员通常会将其禁用。下个月研讨 WDS 时，我将介绍一些增强功能，Microsoft 将其引入 TFTPD (TFTP Daemon)（Windows Server 2008 的 WDS 中）以改善性能。
第 8 步初始化 NBP。对于 RIS，它将启动 Windows 引导加载程序，此程序将开始执行部署的流程。PXE（至少是实际的引导级协议）不再是此流程中的一个组件。
请注意：PXE（RIS、WDS 或任何其他基础结构）在以下情形下无法正常工作：链路速度慢（它可能要传输大量数据）或高延时链路（如卫星）（通信无法正常执行且甚至可能无法保持）。
在 PXE 引导过程中，您可能已注意到：当客户端发送请求时，并无明确的提问：“您是我母亲吗？”这是因为 PXE 服务器不需了解多少状态信息。通常发生的是争用 — 首先响应客户端请求的服务器将取得胜利。有许多方法能帮助减少此类问题：
  • 调整一个 PXE 服务器或其他服务器的响应速度。网络延迟和服务器动力将影响服务器的响应速度。实际上，在 Microsoft，Microsoft IT 过去使用的服务器都非常好，甚至于即使 PXE 服务器位于办公室中，公司服务器有时仍可胜出。在这种情况下，只需针对预先设置的客户端，将本地 PXE 服务器设为根本无超时即可。
  • 预先设置客户端。如果想要使 PXE 服务器先于其他公司 IT 服务器做出响应，这一点非常重要。通过预先设置客户端，从而允许 Active Directory® 告诉 WDS 或 RIS：是的，实际上，“我是你的母亲”。请注意，在 Active Directory 中，SMBIOS GUID 更适合作为系统的唯一标识符 — 但如果系统中没有实现 SMBIOS GUID（很可能出现在相对较旧的硬件中），您可以（而且必须）根据 MAC 地址使用 GUID。如需更多信息，请参阅“预先设置客户端”侧栏。
  • 切勿允许 PXE 通信跨交换机或路由器；每侧放置一台 PXE 服务器。此方法的缺点是实现和维护都很昂贵（每个服务器都必须维护自己的映像）。
RIS 和现在的 WDS 服务器（如 Microsoft 的 DHCP 服务器）必须依据相关的 Active Directory 实现进行身份验证。目的是通过让 Active Directory 了解所有服务器来减少未授权 PXE 服务器可能导致的问题（如 PXE 广播风暴）。
请注意，此方法仅依靠 Active Directory 识别出的服务器实施保护。如果设置自己的域或非 Microsoft PXE 服务器，情况就不是这样了。
在 Microsoft，有个过分热心的员工曾配置过一个“零接触”部署非 RIS PXE 服务器。它完全删除硬盘并记下一个新映像。如果是在一个封闭（不联网）的实验室中进行部署，此方法确实可行，遗憾的是真实环境并非如此 — 设想如果 Microsoft 的总经理在引导顺序中将 PXE 放在硬盘之前，会导致删除硬盘的内容。
这不是个问题，因为 Microsoft IT 始终要求按 F12 键来实现 PXE 引导，但此 PXE 服务器没有延迟、F12 提示或任意类型的通知。这等于总经理丢失了计算机以及未受漫游用户配置文件保护的所有数据。
如果准备实现“零接触”或极少要求按 F12 键，您可从此故事中知晓隔离 PXE 服务器的必要性。

深入探究 RIS
在 Windows 2000 发布后我接手了 RIS。就 RIS 而言，Windows 2000 经历的是一段艰难的时期 — 测试、性能和其他限制导致 Windows Server 2000 的 RIS 仅可用于部署 Windows 2000 Professional。无法通过 RIS 部署服务器产品。Windows 2000 仅可用于 x86 机器，因此它是一个不错的 RIS 测试平台，因为它在一种体系结构中涉及一个产品。RIS 包括（且需要）与 Active Directory 的完全集成、妥善地集成到 Microsoft 的 DHCP 服务器中，并且包括自己的 TFTPD。
RIS 使用 NBP 来继续下载 TFTP — 并且使用充足的 Windows 内核来开始安装过程。（某些特定时刻，一旦 Windows 从 TFTPD 切换至为基于 SMB 的服务器连接，实际上就与传统软盘启动的 Windows 2000 或 Windows XP 安装共享文字代码路径。）初始化本机模式 Windows 后，Windows 安装会启动 RIS OS Chooser (OSC) 向导。
OSC 屏幕可进行某种程度的配置（类似 HTML 2.0 的页面）。它们有严格的限制，无法包含图像或类似内容，并且实际上无法包含非 ANSI 字符（因而使 Windows 的某些区域设置部署变得非常复杂）。
RIS 的最终产品是位于 RIS 服务器中的一个 txtsetup.sif 文件。执行完 OSChooser 向导后，将“软重启”客户端，但 RIS 服务器和 txtsetup.sif 文件的位置将保持不变，且会在软重启后重新加载。此 txtsetup.sif 文件实质上与 unattend.txt 文件相同，包括多个附加字段来帮助 RIS 完成安装过程。
RIS 还可执行非常类似于传统无人参与安装的一种安装 (RISetup)，它有一个基于克隆的基础结构 (RIPrep)，类似于 Sysprep，实际上是与其共享代码。但 RIPrep 还可将自身的映像上载到 RIS 服务器。
但是，RIS 有一些愈发明显的基本限制。首先是缺少服务器部署支持。由于存在红色代码和震荡波这类攻击，并且许多大客户在从 2001 年 9 月 11 日那场灾难中执行直接恢复时，都遇到了复杂的 IT 问题，使得我们必须迅速为现有 Windows 2000 RIS 服务器找到一个解决方案，以实现 Windows Server 部署。我们曾针对 Windows Server 2003 做过此类研究，但尚未正式发布。
有关 PXE 相关技术的更多信息
  • PXE 客户端、DHCP 和 RIS 服务器之间的 PXE 交互过程说明
  • 计划 PXE 启动的操作系统部署
  • PXE 体系结构
  • 远程安装服务
  • 远程操作系统安装
  • 远程操作系统安装的分步指南
  • WDS PXE 提供程序
  • 什么是远程安装服务？
  • Windows Server 2003 自动部署服务
其次，RIS 缺少完全自动执行 OSChooser 向导的能力（后来是通过 Windows Server 2003 中的 <META ACTION="AUTOENTER"> 元素启用此向导）。最后，OSChooser 无法使用非 ANSI 字符正常运行 — 它是美国以外的许多客户指出的一个主要弱点。
这就出现了无法使用法语键盘来完成 RIS 安装这类情形。在全球各地使非 ANSI 字符在 PC 的 BIOS 级别安全工作极其复杂且难以实现。
随着 Windows Server 2003 的发布，我们正式添加了对 Intel Itanium 体系结构和所有版本 Windows 2000 和 Windows Server 2003 的支持。Windows Server 2003 由于支持 x64 体系结构而更进了一步。
RIS 的 TFTPD 有了大幅改动，提高了性能。Windows Server 2003 支持同时引导最多 75 个客户端；请记住，当 SMB 管道中充满到客户端的网络流量时，即达到上限。

WDS — 起点
当我们开始研究用于“Longhorn”（Windows Server 2008 的代码名称）的 RIS 时，需要先做个回顾。正如我之前在专栏中提到的，我们曾对通过 Windows PE 实现的基于映像 (WIM) 安装下过很大的赌注。它为 WDS 建立了一项关键原则：通过 Windows PE 的 PXE 引导实例实现基于映像的部署。
我们还知道 Windows Server 2003 将成为 Windows Vista® 部署的常见平台，我们需要一个用于 WDS 下层的“带外”解决方案。因此，WDS 可在 Windows Server 2003 SP1 上运行且已内置到 Windows Server 2003 SP2 中。
由于可作为 RIS 服务器（旧式模式）、混合服务器（混合模式）或仅 WDS 服务器（本机模式）运行，WDS 允许迁移到正式的 WDS 形式部署。我听过客户询问有没有方法在 Windows Server 2003 SP2 系统上安装 RIS。是的，有 — 安装 WDS 并在旧式模式下运行。图 2 显示了所支持的操作系统。
图 2 支持部署的平台
操作系统 | RIS (Windows 2000) | RIS (Windows Server 2003)** | WDS (Windows Server 2003)**** | WDS (Windows Server 2008)
Windows 2000 Pro | X | X | X | X
Windows 2000 Server | * | X | X | X
Windows XP Pro |  | X（x86 和 IA64）*** | X | X
Windows Server 2003 |  | X（x86 和 IA64）*** | X | X
Windows Vista |  |  | X | X
Windows Server 2008 |  |  | X | X
* support.microsoft.com/kb/308508 和 support.microsoft.com/kb/313069 添加了 Windows 2000 Server 与 RIS 配用方面的支持说明。 ** WDS 旧式模式和混合模式支持同一组旧式安装。 *** Windows Server 2003 SP1 添加了对 x64 系统的支持。IA64 系统仅支持基于 RISetup 的安装。 **** 支持本机模式。
Windows Server 2003 SP1 和 SP2 中的 WDS 是向 WDS 迁移的起点。正如我之前提到的，WDS 在 Windows Server 2008 中添加的主要功能是经过改进的 TFTPD、可扩展固件接口 (EFI) 引导支持，当然还有基于多播的部署。

其他参与方
Microsoft 的另一团队构建了自动部署服务 (ADS)，主要用于快速置备服务器。ADS 具有基于扇区的正式映像、自己的引导代理（比 Windows PE 小巧，但功能不够完整）、自己的 TFTPD 以及非常先进的多播。在 System Center Configuration Manager (SCCM) 中，ADS 中的内置功能在一定程度上得以体现，尽管功能并非 100% 相同。﻿
Windows XP Embedded 通过将其 TFTPD 放入 RAMDisk 可实现完全 PXE 引导，但无法以这种方式进行远程部署。此技术旨在支持通过 PXE 同时使用相同磁盘映像引导多个系统。

结束语
简而言之，以上讲述的是发展过程。要了解更多信息，请参阅“有关 PXE 相关技术的更多信息”侧栏。下个月，我将深入探究 WDS 基础知识，然后是有关 WDS 高级功能（多播等）的专栏，最后是 WDS 的全新使用方法，即超越现有 WDS/安装体验应用您自己的部署技术。

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


安全观察 密码和信用卡，第 1 部分
Jesper M. Johansson

目录
不可行的安全建议
不可行且不正确
不能理解的建议
基于映像的站点身份验证的缺陷
最近，我应邀接受了明尼苏达大学旗下杂志的访谈。很显然，他们想在某些成功的校友身上印证某种特征，不过没有找到 – 因此他们不得不找到我顶数。采访者询问我的职业，我就试着解释了安全
基础结构软件。“这听起来太复杂了！我认为安全涉及的基本就是密码和信用卡。”她大叫道。
我对此略加思考，结论是她确实切中了要害。安全确实差不多就是密码和信用卡。至少，对最终用户是这样。而我们这些行内人的看法是：安全涉及加密算法、Kerberos 是否就比 TLS 或 NTLMv2 更好？WS* 的优点，是否应向密码哈希中加入其他元素？以及所有其他我们乐于讨论的诀窍。当然，我们自己的视角比最终用户更深入，但我们却都忽略了一件基本的事情：对于我们的客户而言，安全的内涵差不多就是密码和信用卡。
当然，我们如此热衷于讨论的秘诀和如此乐此不疲地开发的新技术都是为了保护最终用户的数据。但我仍然认为我们偏离了轨道。我们这些 IT 世界中的亚文化群之所以存在，就是为了满足委托人的特定需要，即保证数据安全的需要。其中自然包括确保 IT 资产的安全使用。这就是它的本质。
在前几期专栏中，我提到没有人会出去买一台计算机专门用来运行防病毒软件的。用户购买计算机是为了使用网上银行、玩计算机游戏、写电子邮件、做家庭作业或履行其他基本功能。同样地，没有哪个公司成立 IT 安全组而仅仅是为了让他们实现 NTLMv2。它是为了保护公司资产，使公司最大程度地安全使用其 IT 资源并实现业务目标。
为大众服务就是我们存在的意义。
因此，我必须问问我们现在是否真正地做好了“服务”。或者说，我们这些安全亚文化群实际上是不是带来了负面效果？立法者和执法者是不是在帮助我们发挥负面影响？我们实施的所有这类新技术对最终用户真正有所帮助吗？我对此心存疑虑。因此，我想研究一下全球 IT 提供商实际过大于功的几个领域。
在某些时候，总感觉我们授以用户的大部分安全建议和安全技术都是不可行的、不正确的、不能理解的或（在许多情况下）这三种情况的某种组合。在这个由三部分组成的系列中，我将研究一些我们给用户带来困惑的事例，具体而言，就是给出的建议或部署的技术包括上述的一种或几种情况。

不可行的安全建议
迷惑人们的一个最佳途径就是提供不可行的安全建议。甚至是给出个不正确的建议。图 1 说明了一则屡试不爽的、理论可行却毫无价值的建议。
图 1 不可行的安全建议（单击此图像查看大图）
看看是在什么样的环境中要求您为所拥有的每个在线帐户使用不同的密码的？三十年前这种建议还有些意义。那时联网的人数不过数百，他们都是非常聪明的人，对密码没有苛求。遗憾的是，这则建议一直被保留下来，并一次又一次的重复，但已不符合当今计算机的实际使用情况。
您有多少个在线帐户？抛开那些没记住的不算，我自己就有 115 个。图 1 中的建议不仅建议我应使用 115 个不同的密码，还应每 30 到 60 天更换这 115 个密码。换句话讲，我每天应更改我的其中 2 到 4 个。（算算看：这同时意味着我一年中将使用 690 到 1380 个密码。）
或许提供该建议某些站点的技术人员能够每天提出 4 个不错的密码并短时记住 115 个当前密码，但可以确信的是，99.99 % 普通的 Web 冲浪公众都无法做到这一点。
从纯粹的理论角度来看，在不同的场合使用不同的密码实际上是正确而有意义的，每 30 到 60 天更改一次您所有的密码的建议也是如此。但此建议同时也是不可行的。考虑到用户目前使用的密码数，如果不借助任何帮助（如纸张或软件），他们完全无法执行该建议。进入下一个示例。

不可行且不正确
图 2 中所示的这则建议来自于一家全球最大银行的 Web 站点，它既不可行，又不正确。标题 "Read our password advice"（请阅读我们的密码建议）下的同样推荐 "different passwords everywhere"（不同的场合使用不同的密码）。同时还建议您 "never write them down"（切勿将其记在纸上）。
图 2 不可行且不正确的建议（单击此图像查看大图）
这样看来，我现在有 115 个不同的密码，我还得每天创建 4 个新密码，还不能用笔将它们记下来。有那么一阵子我认为自己头脑不灵光，因为我记不住自己所有的密码。然后我发现实际上每个人都是这样子的。人类根本记不住 115 个密码。我们能记住并处理大约七大块信息 – 这是我们与生俱来的特性。如果按照 Internet 上找到大多数密码建议所述，它实际连一个密码的要求都无法满足（请参阅musanim.com/miller1956 上 George A. Miller 的文章“神奇的数字七加减二：我们信息处理量的一些限制”）。
令人遗憾的事实是在涉及到密码建议时，我们的行业却在时时误导用户。如果安全亚文化群打算告诉用户他们应在不同的场合使用不同的密码，然后我们还需要告诉他们该如何做 – 即将这些密码记录并存储在安全的地方。将它们写在纸上、使用安全的文档或使用专用工具，如 PasswordSafe (sourceforge.net/projects/passwordsafe)。面对现实吧，我们或是记下过自己的密码，或是在不同的场合使用相同的密码。实际上，最近的一项调查表明 88 % 的用户在所有需要身份验证的系统中都使用相同的密码（请参阅 msnbc.msn.com/id/24162478）。
反对记下密码的建议的确是这种趋势的一个推动因素。我们需要做的是向用户讲解如何有效地管理密码（及其他敏感数据），而不是对此信息放任自流。这样他们凭据的安全性就会提高。

不能理解的建议
在 20 世纪 60、70 和 80 年代，没有大量用户在线并使用基于 Web 的服务，前两种情况是很有效的古老建议。到目前为止还没有人十分抱怨这种建议，因为它们已是广为接受的意见。
这种建议迷惑了用户，使他们对存储其密码心存不安。如果安全专家仅对用户给出建议，而不是帮助他们完成必要的工作，那是安全专家的失误。毕竟，找出管理安全性的方法不是用户的职责。只有安全专家才胜任此工作。我们必须为我们的用户找出管理其所有在线帐户的可行方法。但由于大多数指导都只是在重复相同的过时建议，用户只好借助记事贴和电子表格记住他们的密码。
作为一种身份验证机制，密码发挥着巨大的作用。但密码的主要问题在于人们很难记住它们。IT 世界一直在发明各种新机制来替换密码或扩充密码，而不是尝试解决人性本身的问题，结果自然不尽人意。使得用户们感到更加困惑。
我上次访问某个金融服务站点时，所显示的登录屏幕上只有一个用户名文本框（请参阅图 3），让我感到非常吃惊。
图 3 我在哪里键入我的密码？
我起初以为自己访问的是恶意 Web 站点。我随后迅速地验证了该站点，这一步还比较容易，因为该站点提供了证书，结果是该站点没有问题。问题在于人们已习惯于在登录某个站点同时看到两个文本字段 - 用户名和密码。这一切来源于多年来所遇到的相同常用工作流。因此当您猛然间发现某个网站仅要求您输入用户名时，事情就有了波折。此示例的缘由是提供商实施了一项使用图片识别访问站点的用户以防止仿冒攻击的技术。按照其设想，当您填完用户名后，站点会弹出一个包含可识别图片的屏幕，如图 4 所示。
图 4 某些站点现在使用图片来为用户验证站点（单击此图像查看大图）
其原理为您知道每个网站会弹出什么样的图像。如果未显示正确的图像，则您可认为该站点被仿冒了。就其本质而言，这是个不错的概念。假定用户知道每个网站会弹出什么样的图像，这种策略还是颇有些意义的。
敏锐的读者会注意到图 4 中的绿色地址栏。这代表该网站使用 SSL 和扩展验证 (EV) 证书，这也是为什么地址栏是绿色的原因。同时意味着整个利用图像识别站点的假设没有任何附加价值。至少一部分最终用户还让这些图像搞得昏头涨脑了。该站点已向用户验证了自己 – 它已提供了包含公司名称、Web 站点地址和信任发行商名称的证书。而地址栏为绿色的事实又告诉我该公司还花费了三倍于 EV 证书的开销。
当然，这样的图片也是可以伪造的。如果用户可提交她自己的图片，攻击者就有多种办法大概地推断出当前所使用的图像。如果用户在每个站点都使用相同的图片，攻击者就有了一个好机会，他只需创建一个包含用户喜爱内容的站点（我将让您提出自己的示例），并要求用户提供站点验证使用的图片即可。如果用户在所有站点都使用相同的图片，这个新站点将得到用户在其他站点使用的图像，例如，她的网上银行站点。
某些站点会让您选择自己的图像，而有些则会使用照片存储库。例如，图 4 中的站点有 318 张库存照片可供选择。之前的诡计对于那些不允许用户提交自己照片的网站无法奏效。但如果用户不能选择她自己的图像，则对于那些用户不常访问的站点，用户将不大可能记住哪些图片用于哪些站点。我确实不知道自己在图 4 所示的站点上使用什么图片，但可以向您保证不是截图上所显示的那张图片。
这种基于图像的方法的问题在于攻击者可以显示 318 张图片中的任何一张或随机地选择 Flickr 中的一张照片，而许多用户都会认为该图像是正确的。如果大部分人能记得诸如哪张照片能访问哪些站点之类的事情，我们就不会发生目前仿冒和安全相关的问题了。
那么，为什么站点在已使用证书验证自身的情况下还要让用户用图片验证站点呢？为什么不只使用该证书并帮助用户了解如何验证它们呢？证书已证明了站点对用户的身份。
获得证书的过程当然要比获得用户的站点身份验证图像安全得多。如果是 EV 证书，并且您使用的是 Internet Explorer® 7 或 Firefox 3，浏览器还会在地址栏中突出显示相关的证书信息。遗憾的是，这种突出显示仅对极为昂贵的 EV 证书有效。

基于映像的站点身份验证的缺陷
图片身份验证技术存在诸多问题。首先，它使得从某个站点获取用户名变得极为容易。实际上，如果您输入错误的用户名，图 4 中所示的站点将会显示一个对话框，如图 5 所示。如果您为某个已选择了一张秘密图像的用户键入了正确的用户名，您会看到这个人的秘密图像。很显然，这种发现对于尝试获取有关某个用户信息的攻击者而言极具价值。
图 5 可方便获取用户名的图像身份验证的站点
此处所示的实现类型事实上没有任何安全价值。攻击者可简单地在伪造的站点上复制该登录工作流。该伪造站点会要求输入用户名，然后将其传递给真正的站点。您甚至可在客户端上使用 AJAX 实时更新表单，产生更逼真的效果。此外，如果合法站点尚未缓解登录表单上的跨站点请求伪造攻击，AJAX 代码甚至可将请求直接提交给真正的站点，除非浏览器可缓解跨站点 XML-HTTP 请求。
现在，在结果返回后，攻击者可分析数据、提取图片并将其向最终用户显示。换句话讲，任何能向用户提供伪造登录站点的攻击者也能显示该用户的秘密图片。最终的结果就是使用基于图像的站点身份验证是完全没有任何附加价值的。图片会在向站点验证用户身份之前显示，因此，如果攻击者具有或可获取用户名称，则同样能使用该图片。
假定从未提醒用户要在提交表单前查找证书，这是一种安全的假设，因为使用基于图像的站点身份验证本身是基于相同的假设 – 从用户那里获取用户名是不困难的。另外，由于很多基于图像的站点身份验证方案对于有效用户名与无效用户名的响应是不同的，也使得获取用户名变得轻而易举。攻击者甚至可在攻击真正开始前顺便做到这一点。
最后，我们使用户产生了两种感觉：更安全或更困惑。我们花费了相当数量的股东权益实现基于图像的站点身份验证，却根本没有进一步地阻止恶意用户诱导最终用户将其凭据提交给伪造的 Web 站点。
以上就是我在本期安全观察中要与大家交流的全部内容。请在下月查看本系列的第 2 部分，我将讨论更多误导性安全措施以及不良身份验证的示例

Jesper M. Johansson 是研究安全软件的软件架构师，还是《TechNet 杂志》的特约编辑。他拥有 MIS 博士学历，具有 20 多年安全方面的工作经验，同时还是企业安全方面的 Microsoft MVP。他的最新著作是《Windows Server 2008 安全资源工具包》。


领域备注 确保选举的准确性
Josh Benaloh

在本次美国总统选举年中，公众注意力集中在投票技术上。在我们进行艰难抉择时，人工记票报告之间的钟摆来回摆动着，这种方式繁琐而极易违规操作；打孔机由了解其基理的内部人士操控着；穿孔卡片上带着其炙手可热的悬挂式孔芯；光学扫描选票极易被蹩脚的校准扫描器误读；触摸屏系统会被潮湿或恶意软件损坏；还有综合产物，它们所产生的问题远比解决的问题要多。
而这只是这些系统缺陷的冰山一角。此外，世界各地广泛使用的各项技术均依赖于技艺熟练且公正诚实的选举管理员来维护选举的公正性。
但有更好的办法可使选举的公正性不依赖于管理员或设备。这种选举可由官员、选民甚至感兴趣的观察员全程核实其公正性。
为此，假定向符合条件的选民提供代码，允许他们在某个可公开读取数据的 Web 站点上在其姓名旁张贴其选票。选民可检查该 Web 站点以查看他们自己的选票是否被准确地记录下来，任何人都能通过独立审核来检查是否所有的选民都合法、计数与宣布的得票数是否吻合。
但是，请等一下 – 这种“坦诚”的选举还缺乏一个要素，那就是隐私。没错，但可利用加密来弥补这个不足 – 从而能在选举中秘密投票并全程加以核实。与张贴原始选票不同，这里张贴的选票是经过公钥加密的，其加密密钥由选举官员们共享，这样解密就需要合作。投票结束后，选举官员进入合作流程以产生选举得票数，以及得票数与张贴的加密选票组准确对应的加密证明。
每个选民都可检查加密选票是否合乎其本意，并且任何人都能检查该加密证明以确认正确计入了这些加密选票。通过这种方法即可全程审核选举得票数。
真的有这么简单吗？不是。这只是对大致情况的真实描述，还必须谨慎地管理其中的许多细节，才能使其尽善尽美。例如，我们仍然必须依赖传统的方法来确保选举设备能充分地保护选民隐私。那么是如何确定选民们已在加密选票反映了其意图呢？选民们必须确信在其姓名旁张贴的加密值确实与其意图对应，而不需要向第三方出示这种对应关系（以免他们受到强迫或收买选票的影响）。我们必须达到这些目标，且不能让选民的选举复杂性超出传统的投票系统。
全程可审核的选举流程已在加密文献中研究了至少四分之一个世纪，现在，我们已经有可靠可行的办法来提供准确得票数的加密证明。研究社区内近来的注意力集中在面向选民的前端，同时也在此方面取得了很大进展。
选举技术的商业需求很大，但并不很惊人。在这个市场中，有着广泛利益的大型联合企业会被投以猜疑的目光，因为他们的一些利益可能会从某些选举结果中获益。因此，这个市场最好由很多微型企业组成，其整个业务都依赖于获取选举权。有关全程可审核选举方法的详细信息及链接，请访问 research.microsoft.com/crypto/voting。

Josh Benaloh 是 Microsoft 研究中心的高级加密专家。他在国际密码学研究学会的董事会工作八年，发表了大量文章，包括 1987 年的博士论文《Verifiable Secret-Ballot Elections》。


Windows 机密 空间占用回顾
Raymond Chen

还记得 Microsoft Bob 吗？ 它最初的设计意图是成为 Windows® 3.1 上友好的用户界面，但最终却声名狼藉（甚至还背上恶名，成为《PC World》评出的有史以来最差技术产品之一）。在 Bob 退出历史舞台之后的几年里，该产品已经沦落一提起就让人发笑的地步。
巧合的是，Microsoft® Bob 的内部代号为“Utopia”（乌托邦）— 名称虽略显张狂，但至少显出一份冲劲和活力。当得知营销同事们为此产品定下 Bob 这个名字时，我们全都摇头表示怀疑。
但是，接下来我将介绍您可能并不知道的 Bob 来龙去脉。 Bob 的失败反倒是一件好事。
如果打算通过 CD 来发布软件，您一定会担心单独的一张 CD 是否能够实际放下您的产品。幸运地是，尽管将翻译、支持工具和必须放到 Windows XP CD 中的其他内容所需的磁盘空间计算在内，仍然会剩余约 30 MB 的存储空间。担心这些事的人们指出，既然我们买下了 CD 上的所有存储空间，那就应该把它都用起来，不是吗？
Microsoft Bob 的内部代号为“Utopia”（乌托邦）— 名称虽略显张狂，但至少显出一份冲劲和活力。（单击该图像可查看大图）
这样做的另一目的是减少喜欢制作 Windows 非法副本的人数，但却收效甚微。有人决定使用虚拟数据填充 CD 上的该剩余空间，然后通过 Windows 安装程序来确认虚拟数据是否仍然存在。依此逻辑，下载 CD 映像副本的人们将不得不额外下载三十或更多兆的数据。请注意，当时“宽带”尚未普及到每个家庭，主流用户使用的是拨号连接。强迫用户通过 56Kb 调制解调器额外传输三十兆数据会产生一些负面影响 — 尽管按照今天的标准来看影响并不大。
要想通过虚拟数据检查，还需要虚拟数据源。现在，他只需调用 CryptGenRandom 函数即可生成 30 MB 加密随机字节，但这种方法还真没有吸引力。通过挖掘存档可找出一个 Microsoft Bob 的副本。 他取得了所有软盘映像，并将它们组合成一个大文件。Microsoft Bob 软盘映像的内容随机性并不强，所以他决定通过加密来打乱这些数据。当需要输入加密密钥时，他只需用手在键盘上随意划过，就能得到一份加密的 Microsoft Bob 副本。它就是用来占据 Windows XP CD 上未使用空间的承载数据。
最终，Windows XP 成了有史以来所开发的最有效 Microsoft Bob 部署工具。如果回头翻查储物柜，找出您的 Windows XP 副本，精确按照上述说明操作，加密程序就会生成一份 Microsoft Bob 的副本。

Raymond Chen 的网站“The Old New Thing”及同名著作均讲述了 Windows 的发展发展情况及 Win32 编程。他很想知道自己是否能看到重大的技术改变。

© 2008 Microsoft Corporation 和 CMP Media, LLC。保留所有权利；未经允许不得复制本文的部分或全部内容