 TechNet Magazine December 2006

TechNet Magazine December 2006

Exchange Server 2007: 将基础结构升级到 Exchange 2007

无论贵组织是大型组织还是小型组织，要平稳转换到 Exchange Server 2007，都需要预先做好规划。有了合适的转换规划，就可以避免任何服务中断。让我们来看一看您在执行升级时需要遵循的步骤。

Kate Follis Exchange Server 2007: 轻松驾驭 Exchange 管理外壳

Exchange 管理外壳为管理员提供了一个强大的接口来从各个方面管理 Exchange Server 2007。在这里，您将大致了解如何从命令行开始编写脚本、集成应用程序以及执行其他强大的管理任务。

David Strome Exchange Server 2007: Exchange 和 Outlook：一起使用更理想

Exchange Server 2007 和 Microsoft Office Outlook 2007 共同实现了通信和协作领域的巨大突破。了解我们如何钻研更简单的配置、改进的搜索功能、统一消息及更多内容。

Michael Khalili Exchange Server 2007: 与 Exchange 2007 永远的亲密接触

通信的作用从未像现在这般强大。让我们看看 Exchange Server 2007 中内置的统一消息和 Outlook Web Access 功能如何帮助您从任何地方通过一个位置访问到所有消息。

Joshua Trupin Exchange Server 2007: Exchange 2007 中更强大的日志功能

Exchange Server 2007 提供了更为灵活的日志功能，从而使得在大型组织内监控特定用户帐户和满足遵从性要求变得更加容易。

David Strome Exchange Server 2007: 通过发件人 ID 抵御垃圾邮件和网页仿冒欺诈

以发件人 ID 框架 (SIDF) 为基础而构建的电子邮件身份验证在抵御垃圾邮件和网页仿冒欺诈邮件方面实现了重大的改进，得到了广泛采纳。实际上，全世界三分之一以上的电子邮件已经过身份验证并遵从 SIDF。以下是它的工作原理。

Craig Spiezle and Alexander Nikolayev 编辑视角: 实现目标

TECHNET MAGAZINE IS MORE than just this fabulous publication you hold in your hands today. Our team has been working furiously to create an innovative new Web site that will make our content accessible to more than a billion people around the world.

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

Greg Steen Windows PowerShell: 简单命令。强大的管理能力

Don Jones Post Mortem: 从 Exchange 5.5 迁移

Whitney Roberts SQL 问题与解答: 防止重新启动、安装多个更新及其他内容

Edited by Nancy Michell 您好，脚本专家！: 杯托在哪？

The Microsoft Scripting Guys 安全观察: 部署全球信任的 PKI

John Morello 桌面文件: 了解 Windows 映像格式

Wes Miller Windows 机密: 等待 RunOnce

CONSIDER AN installation that needs to restart the system in the midst of the process. For example, the program might wish to upgrade a system DLL that is currently in use. You would need to trigger an intervening reboot to get the new DLL file installed, and then after the DLL has been upgraded, you could use it in the next stage of the installation.

Raymond Chen


 Exchange Server 2007: 将基础结构升级到 Exchange 2007
Exchange Server 2007 Kate Follis

将基础结构升级到 Exchange 2007
概览:
  • Exchange 2007 中的新功能
  • 准备升级
  • 基于角色的部署
  • 邮件路由拓扑

我过去经常讲授有关从 Exchange Server 5.5 迁移到 Exchange 2000 Server 的课程。课程从早上 8:30 开始，下午 6:00 左右结束。我每次离开教室时都会感到
筋疲力尽。仅仅为了转移目录资源，以及有关 NTDSNoMatch 的各种混淆和偶尔会拒绝信任的 Windows NT® 4.0 信任，就需要大量的准备工作。由于时间的限制，我们几乎不能涉及 Exchange 2000 Server 管理，但总是有几个迫不及待的学生打算在星期五夜间离开教室，在周末完成迁移过程。我警告过不要这样做，并建议多花一些时间做计划，但我不能确定他们是否留意这样的警告。
从 Exchange 2000 Server 或 Exchange Server 2003 转换到 Exchange Server 2007 与您花时间进行计划一样需要谨慎进行。实际的转换过程将因组织和当前部署的复杂性而异，但转换过程仍需要若干个阶段。小型组织可以一个单独项目的方式来执行这些阶段，而大型组织可以决定逐步引入服务器角色并支持 Exchange 在一段时间内处于共存模式。端到端过程专用于在整个转换期间维护邮件功能和稳定性。在本文中，我将侧重于在升级到 Exchange Server 2007 时维护通过整个组织的邮件流所需的基本步骤。

注意事项
第一点需要注意的是，Exchange Server 2007 必须部署于 64 位硬件中，而且它不支持从任何以前版本的 Exchange 进行原位升级。必须使用摆动升级法将现有的邮件服务移至 Exchange 2007。而且，Exchange 组织必须在本机模式下运作以支持添加 Exchange 2007 服务器。因此，如果贵组织当前正在使用 Exchange 5.5，则您必须先执行到 Exchange Server 2003 的过渡升级，然后才能转换至 Exchange 2007。
规划转换时，必须考虑 Exchange 2007 中的一些重要变化。例如，Exchange 2007 引入了基于角色的部署，它允许您选择要提供的邮件服务，并部署特定于这些服务的服务器角色。可以分别在专用的硬件中部署服务器角色，也可以在同一台物理服务器中安装多个角色，作为独立的实体进行管理。有关各个方法的说明，请参见侧栏“Exchange 2007 服务器角色”。
Exchange Server 2007 服务器角色
邮箱服务器 邮箱服务器角色为组织提供邮件存储区。Exchange 2007 可支持每个服务器拥有多达 50 个存储区。这些存储区可以作为 50 个单独的存储组进行部署，也可以在一个存储组中创建多达 50 个存储区。邮箱服务器角色是能作为群集部署的唯一角色，因此，如果您要使用群集化，将需要在专用硬件上安装邮箱服务器。
客户端访问服务器 客户端访问服务器角色可替换前端服务器所提供的功能。利用它可以对使用 POP3、IMAP4、Outlook® Web Access (OWA)、RPC over HTTPS（现在称为 Outlook Anywhere）和 Exchange ActiveSync® 访问 Exchange 的客户端执行邮箱访问。
中心传输服务器 此角色为 Exchange 组织提供了 SMTP 和 MAPI 邮件传输服务。组织中用户所发送或接收的每个邮件都由中心传输服务器进行处理。这很重要。因为这确保了任何邮件都不能回避基于服务器的规则或日志策略，这些策略由针对传输管道中各点的代理所提供。
统一邮件服务器 此角色提供了对邮箱的语音访问。它通过与 IP/VoIP 网关或 IP-PBX 进行集成提供了对邮件和日历项的电话访问，同时允许您对回复进行录制。此角色对于 Exchange 来说是一项新增功能，不能与任何以前版本的 Exchange 进行交互。
边缘传输服务器 边缘传输服务器通常部署在外围网络中。它在 Exchange 组织和 Internet 之间提供了 SMTP 邮件传输，还通过使用传输代理提供了反垃圾邮件和防病毒处理。您现在可以按组织和外围网络服务器共同使用的一项技术进行标准化。这种无缝交互模式简化了管理过程，并允许外围服务器的简单集成。

检查拓扑
那么从哪里开始呢？嗯，除非您知道自己身在何处，否则很难指出您进行到了哪里。花一些时间来评估当前环境并记录拓扑（不仅是 Exchange，还有 Active Directory®环境）。您可能会高兴地知道 Exchange 2007 已经摆脱了链接状态路由以及基于路由组和连接器的拓扑。而 Exchange 2007 则利用了贵组织在设计 Active Directory 拓扑时已经做出的投入。结果，所有 Exchange 收件人和配置数据都存储在 Active Directory 中，路由拓扑从 Active Directory 站点配置派生而来，而且所有服务器角色都将使用站点感知来发现在其他服务器角色上运行的服务。
确保当前的 Active Directory 站点拓扑真正利用底层物理网络，并且所有 Active Directory 站点都具有关联的子网，然后记录现有 Active Directory 站点和 IP 站点链接。还要记录所有 Exchange 2003 服务器所在的物理位置，以及路由组和路由组连接器结构。
下面是转换过程中最棘手的部分：从基于路由组的 Exchange 路由基础结构转换为基于 Active Directory 站点的路由基础结构。对于小型组织，这通常是一个简单的过程。但对于具有许多路由组的大型组织来说，如果 Exchange 2003 和 Exchange 2007 同时存在，则需要对过渡阶段进行仔细规划。需要做的最后一件事情是，最终通过由低带宽连接的某些远程路由组路由的通道，使邮件从 Exchange 2007 用户发送到您的 Exchange 2003 邮箱。
让我们首先针对当前的拓扑做出一些假设：
  • Exchange 2003 组织在本机模式下运行。
  • 拥有多个路由组。
  • 拥有多个 Active Directory 站点。
图 1 展示了一个 Exchange 和 Active Directory 拓扑。请记住，初步规划中包含的信息越详细，设计结果越好。
图 1 Exchange 和 Active Directory 拓扑
图 1 Exchange 和 Active Directory 拓扑

Exchange 2007 如何使用 Active Directory
Exchange 2007 服务器启动时，会被加上一个站点属性戳记，可帮助其他 Exchange 2007 服务器查找该服务器所提供的服务。只有中心传输服务器可以使用 SMTP 在组织内传输邮件。每个含有邮箱服务器的 Active Directory 站点还必须有一个中心传输服务器，而且，如果邮箱用户使用任何非 MAPI 方法访问其邮箱，那么各站点还必须有一个客户端访问服务器。无论何时需要处理邮件进行发送，邮件都将经过中心传输服务器，该服务器将决定如何对该邮件进行路由。如果邮件发往邮箱服务器，且该服务器与中心传输服务器位于同一 Active Directory 站点，则此中心传输服务器会将邮件发送到邮箱。如果邮件发往其他站点中的邮箱服务器，则此中心传输服务器会将邮件直接中继到远程站点的中心传输服务器。
中心传输服务器使用 Active Directory IP 站点链接成本信息来计算通往收件人邮箱所在的 Active Directory 站点的成本最低的路由。此路由选择算法与 Exchange 2003 非常相似，但它是基于 IP 站点链接成本，而不是路由组连接器成本。而且，邮件不会在途中停止于各中心传输服务器。它会直接从源位置传输到目标位置。既然依赖于 IP 网络传输邮件，那为什么还要劳神费力地去计算成本最低的路由呢？有几方面的原因。一个是为了延缓邮件出现分支。发送给多个收件人的邮件可能需要被发送给多个 Active Directory 站点中的邮箱服务器。Exchange 2007 在邮件达到路由路径中的岔口时才会将其拆分，而不是在第一个中心传输服务器中产生邮件分支或拆分邮件。因此，邮件将直接中继到 Active Directory 站点中代表分岔点的中心传输服务器。这种行为被称为延迟扇出。
成本最低的路由还用于确定在无法到达目标位置时邮件在何处排队。如果无法到达目标 Active Directory 站点中的中心传输服务器，发送端中心传输服务器随后将尝试发送给路由路径中下一个最近的 Active Directory 站点中的中心传输服务器。邮件将沿成本最低的路由继续进行传送，直至到达可使用中心传输服务器的 Active Directory 站点。最后，如果通往收件人 Active Directory 站点的路由中没有可用的中心传输服务器，则邮件将在本地队列中等待。此方法使邮件在尽可能接近传送点的位置排队等待，这样有助于使网络故障诊断更具确定性。这种行为称为出现故障时排队。
Exchange 2003 的工作方式完全不同。它基于分配给路由组连接器的成本计算从一个路由组到另一个路由组的成本最低的路由。路由路径中各路由组的桥头服务器将接收邮件然后将其转发。如果路径中的下一个连接器不可用，则会尝试计算替代路由。还会在整个 Exchange 组织内传达链接状态更新邮件，以通知其他 Exchange 服务器连接已断开。桥头服务器将尝试在断开的连接器周围进行路由，直到收到指示连接已建立的链接状态通知。
大型组织进行转换的难点在于在共存期间维护邮件流。为了在将 Exchange 2007 引入环境中时实现这种连续性，所有 Exchange 2007 服务器都应成为一个路由组的成员。这意味着，无论 Exchange 2007 服务器属于哪个 Active Directory 站点，Exchange 2003 都将认为它属于该路由组。这允许您在此路由组和 Exchange 2003 路由组之间建立一个路由组连接器，以使 Exchange 2003 可以指出如何将邮件路由至 Exchange 2007。Exchange 2007 还将使用此路由组连接器确定如何将邮件发送至 Exchange 2003。但是，Exchange 2007 始终都希望通过其他 Exchange 2007 服务器路由邮件，并且始终都不会通过 Exchange 2003 路由组中的主干直接到达其他 Exchange 2007 服务器。

引入第一个 Exchange 2007 服务器
当您在 Exchange 2003 组织内安装第一个 Exchange 2007 服务器时，将需要选择 Exchange 2003 桥头服务器，用来建立第一个路由组连接器。
图 2 显示引入的第一个 Exchange 2007 服务器是如何影响组织拓扑的。
图 2 安装第一个 Exchange 2007 服务器
图 2 安装第一个 Exchange 2007 服务器
至此不会有什么问题。请注意，由 Exchange 2007 创建的路由组连接器的默认成本只为 1。邮件将和往常一样继续流过 Exchange 2003 服务器。如果邮件从任何 Exchange 2003 服务器发送给 Exchange 2007 服务器用户，则该邮件将流过阿卡普尔科路由组。创建路由组连接器后，您选择的 Exchange 2003 桥头服务器便自动成为 ExchangeLegacyInterop 通用安全组的成员，并被授予正确的权限以从 Exchange 2007 收发电子邮件。只要 Exchange 2007 服务器被指定为连接器的源服务器或目标服务器，就必须始终使用 Exchange 管理外壳中的 New-RoutingGroupConnector 来创建路由组连接器。还可以使用 Set-RoutingGroupConnector cmdlet 来修改路由组连接器的配置。例如，您可能想将源和目标服务器添加到初始路由组连接器，以提供冗余。（有关详细信息，请参阅 David Strome 在本期的 TechNet 杂志中关于 Exchange 管理外壳的文章。）

准备移动某些邮箱
下一步是将 Exchange 2003 服务器中的某些邮箱移至 Exchange 2007 服务器。使用 Move-Mailbox cmdlet 实现此目的。但是，在您可以停止 Exchange 2003 服务器的使用之前，您会希望在 Exchange 2007 服务器上创建发送和接收连接器，来替代在 Exchange 2003 服务器中定义的 SMTP 连接器，以处理通往外部 SMTP 地址空间的路由。
在下图中，来自阿卡普尔科路由组的资源已被移至 Exchange 2007。可以停止使用阿卡普尔科路由组，但这意味着您必须立即建立连接其他路由组的路由组连接器。在图 3 中，我将路由组连接器配置成了连接迈阿密北部路由组的桥头服务器。
图 3 配置路由组连接器
图 3 配置路由组连接器
让我们继续将洛杉矶东部路由组转换至 Exchange 2007。这种情况下维护路由有一点棘手。在图 4 中，Exchange 2007 已安装在洛杉矶站点中，第二个路由组也已经停止使用，但没有创建其他任何路由组连接器。
图 4 安装在洛杉矶站点的 Exchange 2007
图 4 安装在洛杉矶站点的 Exchange 2007
现在，如果邮件从洛杉矶站点中的 Exchange 2007 服务器发送到洛杉矶西部路由组中的 Exchange 2003 服务器，该邮件将首先被转发到阿卡普尔科，然后分别经过迈阿密北部和迈阿密南部，最后到达洛杉矶西部。如果邮件从洛杉矶西部路由组中 Exchange 2003 服务器发送到洛杉矶站点中的 Exchange 2007 服务器，该邮件将首先被转发到迈阿密南部，然后分别经过迈阿密北部和阿卡普尔科，最后到达洛杉矶。哎，真是麻烦。
为避免出现这种情况，我们将需要再添加一个路由组连接器。图 5 显示在洛杉矶站点添加连接洛杉矶西部和 Exchange 2007 服务器的路由组连接器。注意：如果要避免存在过多的路由组连接器，请确保您的第一个路由组连接器已在连接良好的中心 Active Directory 站点中进行配置。
图 5 更有效的路由
图 5 更有效的路由
这会引发可能不是很明显的问题。现在有多种流入和流出 Exchange 2007 路由组的方法。由于 Exchange 2007 路由组并不使用链接状态，所以目前可能存在路由环路。Exchange 2003 服务器可能会选择一个替代路由以在断开的连接器周围进行路由，而 Exchange 2007 将始终选择成本最低的路由。解决这个问题的方法是禁止出现不重要的链接状态更新邮件，这将防止出现传达连接器为断开状态的链接状态邮件，但不会防止出现传达配置更改的链接状态邮件。这一点非常重要，因为我们希望 Exchange 2003 服务器了解新的路由组连接器，但不希望它们尝试计算替代路由。最终结果是 Exchange 2003 服务器将出现与 Exchange 2007 服务器相同的出现故障时排队的行为。
在图 6 中，我们已将更多的 Exchange 2003 资源转换到 Exchange 2007。链接状态更新已被禁止，我们也非常小心地创建了维护逻辑路由路径的路由组连接器。
图 6 更多的 Exchange 2003 资源转移至 Exchange 2007
图 6 更多的 Exchange 2003 资源转移至 Exchange 2007
但有一个问题。我们已在雷德蒙和温哥华建立了链接状态岛。邮件可以正常传送，虽然经过迈阿密，但不会经过雷德蒙和迈阿密传达链接状态配置更改。要维护当前路由表，您将需要在雷德蒙和温哥华之间配置其他路由组连接器。您可以调整该路由组连接器的成本，使其足以防止 Exchange 2003 在该连接上进行路由，同时允许传达链接状态配置更改。
通过仔细规划，您可以避开维护两个单独的 Exchange 路由拓扑可能会带来的一些问题。您将会得到最无缝的结果，方法是一次转换一个路由组，然后再移至下一个路由组，直到只有 Exchange 2007 服务器在运行为止。
至此，我重点介绍了 Exchange 2007 中的路由更改及其对您的转换所产生的影响。规划到 Exchange 2007 的转移时还需要记住其他几个注意事项。
Exchange 2003 前端服务器无法访问 Exchange 2007 邮箱。不过，Exchange 2007 客户端访问服务器可将您与 Exchange 2003 邮箱连接而不会产生任何问题。使用 Exchange 2007 客户端访问服务器时，您只会看到与存储您邮箱的邮箱服务器相同的 OWA 版本。如果在单独的硬件上部署 Exchange 2007，则客户端访问服务器应是在 Active Directory 站点中引入的第一个角色。在任何邮箱移至 Exchange 2007 之前，任何提供对邮箱的公共 Internet 访问的 Exchange 2003 前端服务器都应替换为 Exchange 2007 客户端访问服务器。
我先前曾提到过，每个具有邮箱服务器角色的站点还需要具有客户端访问服务器角色（如果您具有非 MAPI 客户端以及 OWA - 现在谁能在没有 OWA 的日子里活着？）和中心传输服务器。所以，如果打算使服务器角色共享硬件，务必要将客户端访问服务器作为一个角色选择。典型安装将包含中心传输服务器角色、客户端访问服务器角色及邮箱服务器角色，即实现完整功能的 Exchange 环境所需的所有角色。
转换过程的另一注意事项就是何时升级客户端应用程序 (Outlook)。在客户端升级到 Outlook 2007 之前，您将无法充分利用所有 Exchange 2007 服务器功能。这包括增强的外出邮件设置和托管邮箱文件夹功能。
您还需要决定何时部署边缘传输服务器角色。从技术角度上讲，在引入其他任何 Exchange 2007 服务器角色之前或之后，可以将外围网络的 SMTP 中继和智能主机替代为边缘传输服务器。不过，如果首先部署边缘传输服务器，整体功能将会受到限制，原因是 Exchange 2003 无法将边缘传输服务器所需的收件人和配置数据从 Active Directory 复制到 ADAM（Active Directory 应用程序模式）。
安装至少一个中心传输服务器后，可以在外围网络中部署边缘传输服务器，然后再从中心传输服务器所驻留的 Active Directory 站点订阅边缘传输服务器。中心传输服务器上的 EdgeSync 服务会将 Active Directory 中的收件人数据子集复制到 ADAM。
通过该数据边缘传输服务器可以执行收件人查找和安全列表聚合，这样您就可以充分利用边缘传输服务器上运行的反垃圾邮件代理。另外，EdgeSync 将创建端到端邮件流经 Exchange 组织和 Internet 所需的发送连接器。这可以使提供通往外部地址空间的路由的 Exchange 2003 SMTP 连接器的替换过程得以简化。
因此，花点时间规划到 Exchange 2007 的转换，您将发现路由非常简单省力。

Kate Follis 是 Exchange 2007 技术编写团队的高级内容发布人。其所在小组专门研究边缘传输和中心传输服务器角色。在加入 Microsoft 之前，Kate 多年担任 Microsoft 认证培训师，讲授 Exchange 和 Active Directory。
© 2007 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.


 Exchange Server 2007: 轻松驾驭 Exchange 管理外壳
Exchange Server 2007 David Strome

轻松驾驭 Exchange 管理外壳
概览:
  • Exchange 管理外壳工作原理
  • Cmdlet 使用方法
  • Cmdlet 与命令

如果您是 Exchange 环境的管理人员，那么您现在一定已经听说了即将发布的 Exchange Server 2007 包含一个全新的命令行接口，称为 Exchange 管理外壳。Exchange 管理外壳构建于 Microsoft Windows PowerShell 技术之上，
是一个强大的管理接口，可用来通过命令行从各个方面管理 Exchange Server 2007。通过命令行，您可以与 Exchange 管理外壳直接进行交互，为实现自动化编写脚本，或将应用程序与底层引擎相集成。图 1 显示了作用中的外壳。
图 1 Exchange 管理外壳
图 1 Exchange 管理外壳
Exchange Management Console 不只是使用 Exchange 管理外壳来执行操作；其中的各种向导还会告诉您它们正在执行哪些命令。可复制向导所创建的命令并直接将它们粘贴在命令行或脚本中。根据需要修改参数后，可使用 WhatIf 参数对脚本或命令进行测试，以便在对环境做出任何实际的更改之前查看其结果。
Exchange 管理外壳提供了一个强大而灵活的脚本编写平台，用以与当前的脚本编写解决方案相集成，它还允许您直接与 COM 和 Windows Management Instrumentation (WMI) 等数据源进行通信。Exchange 管理外壳以 .NET Framework 为基础，它使用 cmdlet（Exchange 管理外壳中的最小功能单元）来接受和返回结构化的数据而非纯文本。稍后我们将深入探讨 cmdlet。

Windows PowerShell 管理单元
了解 Exchange 管理外壳要从它与 Windows PowerShell™ 的关系入手，后者是一个基于 .NET Framework 的、强大而又灵活的全新命令行接口。它结合了许多其他外壳的最佳功能，同时也加入了许多新功能。Windows PowerShell 专门用于托管其他应用程序，这在很大程度上与 Microsoft 管理控制台 (MMC) 负责托管应用程序所提供的各种管理单元相类似。Exchange 管理外壳是第一个发布的 Windows PowerShell 管理单元。
管理单元是用于管理应用程序或主要组件的 cmdlet 的集合。它们如果不先加载，就无法使用。幸运的是，启动 Exchange 管理外壳管理单元的过程非常简单。不过，在探讨这一点之前，我应该首先解释一下您在阅读本文及使用 Exchange 管理外壳时需要了解的一些主要概念。
Cmdlet：Cmdlet 类似于其他外壳中的内置命令，例如 cmd.exe 中的 dir 命令。与这些为人所熟知的命令一样，cmdlet 可以从 Exchange 管理外壳的命令行中直接进行调用并在该外壳的上下文中运行，而不能用作单独的进程。但与其他外壳中的命令不同的是，cmdlet 带有“动词-名词”形式的描述性名称。动词说明 cmdlet 所执行的操作，而名词则说明将接受该操作的组件或功能。
您不必猜测 cmdlet 具体做些什么。当看到 Move-Mailbox cmdlet 后，一切不言自明。
要了解 cmdlet 与普通的命令有何不同，请参阅侧栏“Cmdlet 与命令”，它摘录自 Windows® SDK 的 .NET Framework 3.0 部分，可以通过 windowssdk.msdn.microsoft.com/en-us/library/ms714395.aspx 找到它。
身份和位置参数：Identity 参数可以用于大多数与 Exchange 相关的 cmdlet 中。它允许您访问用于引用 Exchange Server 2007 中特定对象的唯一标识符，以便使用对您最有意义的唯一值对特定 Exchange 对象执行操作。
Identity 参数是来自其他参数的数值的集合。这些值对于该组对象一定是唯一的。这些其他参数（如 Name 和 DistinguishedName）的值可以由您指定，也可以由系统生成（例如 GUID）。所使用的其他参数（如果存在）及其填充方式取决于所引用的对象。
Identity 参数也可视为位置参数，对于这种参数，您可以指定其值而不必指定其名称。Parameter Position 属性为整数的参数即为位置参数。该整数表示命令行上 cmdlet 可找到参数值的位置。因为 Identity 是位于位置 0（第一个位置）的位置参数，所以在此位置输入的任何不具有参数名的值均被视为 Identity 参数的值。这减少了键入命令时的击键次数。例如
Get-Mailbox –Identity "Kim Akers"
所执行的操作与下面的命令相同：
Get-Mailbox "Kim Akers"
管道操作：Exchange 管理外壳中的管道操作是指一个 cmdlet 在执行操作时使用另一个 cmdlet 的输出。管道操作是使用管道符号“|”来完成的。同一名词 cmdlet 集中的所有动词都可以使用通过管道操作从另一个命令获得的信息。某些名词 cmdlet 集还允许通过管道向另一个名词 cmdlet 集传递数据。
通过将两个或更多 cmdlet 的操作一起通过管道传递给字符串的方式，可以在增强组件功能的同时，减小组件的规模。例如，可以使用一个 cmdlet 来收集数据，再将该数据传递给第二个 cmdlet 以将该数据筛选为一个子集，然后将该数据传递给第三个 cmdlet 以便只对该子集执行操作。

启动 Exchange 管理外壳
此外壳最为简便的加载方式是：单击“开始”、“程序”、“Microsoft Exchange Server 2007”，然后单击“Exchange 管理外壳”。
Exchange 管理外壳管理单元的另一种加载方式是从 Windows PowerShell 会话手动进行。单击“开始”、“程序”，然后单击“Windows PowerShell”。在其启动后，运行如下命令来加载 Exchange 管理外壳：
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin
在加载 Exchange 管理外壳管理单元时，使用“程序”菜单项和使用 Add-PSSnapin cmdlet 手动启动这两种方式之间存在一些区别。使用“程序”菜单项时，不仅会加载 Exchange 管理外壳管理单元，还会运行 Windows PowerShell 脚本以建立自定义的 Exchange 管理环境。如果要在手动加载 Exchange 管理外壳后建立类似的管理环境，请进入 Exchange 安装目录下的 bin 目录，例如 C:\Program Files\Microsoft\Exchange Server\Bin。然后，运行如下命令：
.\Exchange.ps1
看看 Exchange.ps1 脚本可以了解如何根据需要定制 Windows PowerShell 环境。加载 Exchange 管理外壳时，会出现类似图 2 的欢迎信息。
图 2 Exchange 管理外壳欢迎标语
图 2 Exchange 管理外壳欢迎标语

从何处入手？
此外壳包含内容广泛的 cmdlet 集合，因此 Get-Help cmdlet 和 Exchange Server 2007 帮助文件将是非常宝贵的资源。Exchange Server 2007 帮助文件的“操作”部分针对大多数管理任务提供了丰富而详尽的操作步骤。
键入不带参数的 Get-Help 后，会出现有关如何获得帮助的一般性帮助信息。要获得某个具体 cmdlet 的帮助，请键入后跟所要了解的 cmdlet 的 Get-Help 命令。使用 Detailed、Full 和 Example 参数可以控制所显示的信息。只需将它们加到命令结尾即可。例如，Get-Help cmdlet name –Full 可返回某个 cmdlet 所有可用的帮助部分。
如果要检索某个 cmdlet 的某个特定参数或多个参数的信息，可以在 Get-Help 中使用 Parameters 参数。例如，如果要查看 Set-Mailbox cmdlet 所有包含“quota”一词的参数及其说明，应使用如下命令：
Get-Help Set-Mailbox –Parameter *quota*
有时，您可能想列出所有管理特定服务器角色或组件功能、或在某特定功能作用域内影响对象的 cmdlet。为此，Get-Help cmdlet 允许您使用如下三个参数：Role、Component 和 Functionality。在 Get-Help cmdlet 中使用这些参数时，必须用通配符符号“*”将通过这些参数所指定的值括起。下面的示例说明了如何以每个参数调用 Get-Help：
Get-Help -Role *Mailbox*
Get-Help -Component *Recipient*
Get-Help -Functionality *Server*
要了解详细信息，Exchange Server 2007 帮助文件中的“获取帮助”主题列出了可供使用的所有角色、组件和功能值。

设置命令输出格式
默认情况下，Exchange 管理外壳在屏幕上显示输出时，只显示每个对象可用属性的子集。不过，将命令输出通过管道传递给下列三个格式化 cmdlet 后，即可轻松访问到所有属性：Format-List、Format-Table 和 Format-Wide。您或许会定期使用 Format-List 和 Format-Table，因此我将加以一一讨论。
Format-List cmdlet 从管道接收输入并输出由每个对象的所有指定属性组成的竖向分栏列表。使用 Property 参数可以指定所要显示的属性（尽管 Property 参数是一个位置参数，也就是说您只需指定值而无需指定参数名）。如果调用未指定任何参数的 Format-List cmdlet，则会输出所有属性。此 cmdlet 会将输出内容自动折行而不会将其截断。Format-List 的一个最佳用途是覆盖 cmdlet 的默认输出，使您可以检索额外的信息或更为切题的信息。例如，
Get-DistributionGroup | Format-List Name, *OnlyFrom,
PrimarySmtpAddress, *Size*
图 3 显示了此命令的输出。
图 3 Format-List 输出示例
图 3 Format-List 输出示例
Format-Table cmdlet 可以按由属性数据的列和标签标题组成的表格形式来显示各项内容。默认情况下，Get-Mailbox 和 Get-JournalRule 等许多 cmdlet 都使用表格格式输出内容。Format-Table cmdlet 的参数包括 Properties 和 GroupBy。这些参数的工作原理与 Format-List cmdlet 中的完全一样。要完全显示较长的属性信息行而不是在行末将其截断，可使用 Wrap 参数，用法如下：
Get-Mailbox –Database Research | Format-Table Name,
ProhibitSendQuota, Database –Wrap
请参阅图 4 查看输出内容。
图 4 Format-Table 输出示例
图 4 Format-Table 输出示例
如果加入通配符，您可以无需分别键入各属性名即可匹配多个属性。例如，下面的代码会返回所有以“E-mail”开头的属性。
Get-Mailbox | Format-List Email*

练习时间
既然您已经掌握了一些基本的命令，为什么不练习一下下面的例子。它们将进一步证明 Exchange 管理外壳的强大功能和灵活性，并让您亲自示范。
您将尝试的第一个命令会创建 10 个用户，其名称从 User1 到 User10：
1..10 | ForEach { Net User "User$_" MyPassword=01 /ADD
/Domain; Enable-Mailbox "User$_" -Database "Mailbox
Database" }
让我们来逐一加以剖析。命令 1.0 会输出整数 1 到 10 并通过管道传递给 ForEach cmdlet。ForEach cmdlet 会在收到每个对象时作用于其上，并对每个对象运行 { } 括号内的命令。Net User 命令会创建一个新的域用户，Enable-Mailbox cmdlet 则会在本地服务器上的“Mailbox Database”中创建一个新邮箱。这两个命令以分号分隔，从而能够处于同一命令行中。$_ 变量是包含管道中当前对象值的特殊变量。对本示例而言，$_ 变量包含当前管道中的整数。
下面的示例将会显示服务器 MBX 上的邮箱，并返回每个邮箱的 Name、mailbox database 和 quota 属性。
Get-Mailbox –Server MBX | Format-Table
Name,Database,*quota*
Get-Mailbox cmdlet 会返回由 Server 参数所指定的每个邮箱，然后将每个邮箱对象的输出通过管道传递给 Format-Table cmdlet。默认情况下，如果未指定所要显示的属性，Format-Table cmdlet 会显示由 cmdlet 返回的所有属性。这里只请求了 Name 和 Database 属性，以及所有包含字符串“quota”的属性。图 5 显示了可能的输出形式。
图 5 Get-Mailbox 命令输出
图 5 Get-Mailbox 命令输出
在下面的示例中，针对组织内职务为“经理”一级的所有启用了邮件功能的用户，将发送配额限制设置为 600MB。
Get-User –Filter { Title –Like "*Manager*"}
–RecipientTypeDetails UserMailbox | Set-Mailbox
–ProhibitSendQuota 600MB
如果只运行 Get-User cmdlet 本身，将会返回 Active Directory 中的所有用户对象，其中包括未启用邮箱功能的用户。要检索一组可由 Set-Mailbox cmdlet 使用的用户对象，需要指示 Get-User cmdlet 仅返回启用了邮箱功能的用户的 Active Directory 用户对象。RecipientTypeDetails 参数用于指定 Active Directory 收件人类型（本例中为 UserMailbox）。接下来，需要检索一组职务为“经理”一级且启用了邮箱功能的用户。在本例中，每个 Active Directory 用户对象的 Title 属性都已填写完毕。可以通过 Filter 参数（用于指示服务器仅返回符合标准的 Active Directory 对象）利用此属性值来确定哪些用户是经理。这称为服务器端筛选。拥有一组对象后，它们会被传递给 Set-Mailbox cmdlet，该命令随后会将每个邮箱的 ProhibitSendQuota 属性设置为 600MB。
接下来，我们再来测试一个命令的结果，看其是否能删除某个通讯组内的所有邮箱。该命令如下：
Get-DistributionGroupMember "Fourth Year Students" |
 Where { $_.RecipientType –Eq "UserMailbox" } | Remove-
 Mailbox -WhatIf
第一个 cmdlet 会检索作为“Fourth Year Students”通讯组成员的收件人对象。然后，只将符合 RecipientType 为“UserMailbox”的收件人对象传递给 Remove-Mailbox cmdlet。Remove-Mailbox cmdlet 将显示其执行的操作及要被执行操作的对象，而并不删除这些邮箱。Get-DistributionGroupMember cmdlet 会检索作为“Fourth Year Students”通讯组成员的所有收件人对象的列表。但由于 Remove-Mailbox cmdlet 只能处理启用了邮箱功能的用户，因而您需要筛选掉除“UserMailbox”之外的所有收件人类型。与一些其他 cmdlet 不同，Get-DistributionGroupMember cmdlet 并没有 Filter cmdlet，这意味着它无法执行服务器端筛选。对于不能执行服务器端筛选的 cmdlet（因为它们没有任何性能优势），可以使用 Where cmdlet 来执行客户端筛选，该命令可以检索所有对象并在本地客户机上执行筛选。Where cmdlet 只允许那些符合所指定标准的对象通过。RecipientType 为“UserMailbox”的对象被发送给 Remove-Mailbox cmdlet。此 cmdlet 会删除 Active Directory 用户对象并将邮箱标记为“删除”。如果使用 WhatIf 参数，Remove-Mailbox cmdlet 会显示如下的文本：
What if: Removing the Mailbox "contoso.com/Users
/user10" will remove the Windows user object and mark
the mailbox in the database for removal.
如果您对该命令将执行所需的操作感到满意，请不带 WhatIf 参数再次运行该命令。对于某些 cmdlet，例如带有 Remove 动词的 cmdlet，此外壳将在进行任何更改之前自动要求确认。您可以选择单步调试每个更改、指示外壳不再提示确认，或者取消进一步处理。对于不能自动实现确认的 cmdlet，可使用 Confirm 参数进行强制确认。

结束语
既然已经领略了 cmdlet 的强大功能，想必您已准备去亲自体验，感受 Exchange 管理外壳和 Microsoft Windows PowerShell 将给您未来的系统管理任务提供怎样的帮助。如果想要阅读这两方面主题的更多内容，请查看下列资源。有关管理外壳的相关信息，请参阅 Exchange Server 2007 帮助文件 (go.microsoft.com/fwlink/?LinkId=69434)、Windows Powershell 脚本编写中心 (go.microsoft.com/fwlink/?LinkId=71134) 以及 Exchange 团队博客 (msexchangeteam.com)。

David Strome 担任 Microsoft“Exchange 用户培养”团队的技术撰稿人已有一年时间。在加入位于华盛顿雷德蒙的 Microsoft 之前，David 有大约 10 年时间供职于加拿大大不列颠哥伦比亚省的多家公司，从事 Exchange Server 设备的设计、实现和管理工作。可通过 dstrome@microsoft.com 与他联系。


 Exchange Server 2007: Exchange 和 Outlook：一起使用更理想
Exchange Server 2007 Michael Khalili

Exchange 和 Outlook：一起使用更理想
概览:
  • 安装简化
  • 集成语音、传真和电子邮件
  • 为符合规章遵从性而使用了托管文件夹

多年来，Microsoft Exchange Server 和 Outlook 为数百万用户提供了可靠的电子邮件，帮助人们协调和管理日历，并使联系人的组织安排变得轻而易举。一些人可能想知道再一次的组合有何新意。是这样，Exchange Server 2007
和 Microsoft Office Outlook 2007 很快即将发布，它们将共同在通信和协作领域实现一次重大突破。
Exchange Server 2007 和 Office Outlook® 2007 所提供的改进在您启动 Outlook 客户端那一刻起就会有明显感觉。在之前的版本中，Outlook 要求您知道 Exchange 邮箱服务器的名称，一些阻碍大量用户的信息。结果造成了支持人员呼叫过于频繁或初始化脚本复杂化，而这两者都增加了运行有效消息环境的成本和复杂性。目前，通过 Exchange Autodiscover Web 服务，只要将客户端加入到域中，Outlook 就能自动配置帐户。如果客户端没有加入域，用户只需输入名称、电子邮件地址和密码。Outlook 和 Exchange 会解决其余的问题（请参见图 1）。
图 1 帐户设置
图 1 帐户设置
同样，在过去，用户不仅要在初次使用时设置 Outlook，而且还要在它们移动到不同的邮箱服务器时，对其进行重新配置。即使发送了电子邮件提醒用户邮箱将要迁移，繁忙的工作者也几乎注意不到与临近的迁移有关的事项，直到一天早上他们要进来，才发现自己被锁在了 Outlook 之外。此时，接踵而来的就是又一个支持人员呼叫。Autodiscover Web 服务也能解决这个问题。当用户从一个邮箱服务器移到另一个邮箱服务器时，Outlook 会识别出原有配置不再有效，并会再次查询 Autodiscover Web 服务，然后重新配置新邮箱的客户端。整个过程对最终用户完全透明。

重新设置日历
过去，多数日历逻辑驻留在 Outlook 中。每个会议更新都被视为一次单独的会议邀请，这意味着可不按顺序接受通知。如果连续发出两个会议更新，并且接收方先收到的是第二个会议更新，则他的日历上会有过时的信息。此外，如果从 Smartphone 或 PDA 访问 Outlook 信息，将导致不同的闲/忙信息（取决于用户查看数据的方法）。
解决方法是将全部日历逻辑从 Outlook 客户端移到 Exchange Server 2007。当该服务器收到会议请求时，会议将会被临时自动置于日历中，直到用户选择接受或拒接约会。如果收到有关会议时间和地点的更改，会议将自动得到更新，旧的邀请将会被标记为过时，这样用户便不会意外接受它。该逻辑在所有客户端（Office Outlook、Outlook Web Access、Outlook Mobile 或其他第三方客户端）中都一致，因而只会显示正确、最新的会议。
有了准确性如此可靠的日历，就能够提供一套可提高用户工作效率的新工具。过去，为众多繁忙的员工安排会议非常不易。用户必须手动查找适合会议的空闲时间，这就要滚动浏览很多天的信息查找适合全部与会者的时间。现在 Outlook 2007 计划助理（如图 2 所示）将寻找适合每一个人的最佳时间。在输入必需和非必需与会者以及所需的场所和资源后，“计划助理”将显示最佳会议日期的彩色编码视图。一旦选定了日期，便会使用同一方案来查找那一天的最佳时间。
图 2 计划助理
图 2 计划助理
“计划助理”按照必需与会者、非必需与会者、场所和资源这样的顺序来确定开会的最佳时间。使用“计划助理”还能够轻松地处理弹性工作时间和不同时区等问题。用户能够设置自己的工作时间，确定早上到达时间和晚上离开时间。因此，那些习惯晚睡，直到上午 9、10 点钟才会工作的人，可以设置在这个时间开始工作。当其他人需要安排会议时，就不会建议较早的时间（如上午 8 点）。如果处在不同时区的两个小组（如一个在伦敦一个在洛杉矶）需要开会，会议的时间只会安排在双方都上班的时间。伦敦方面的人将会在下午稍晚的一些时候开会，洛杉矶方面的人将会在一大早就开会，而不会是开会的时候其中一方是凌晨 2 点。

大海捞针
近几年来，到达一般用户收件箱内的电子邮件的数量正以惊人的速度增长。然而从前一个普通的办公邮箱仅能容纳几百封邮件，现在有些人一天就能收到那么多邮件。在这些雪片般飞来的邮件之下，掩藏着对任何企业的运作都至关重要的信息财富。在需要时能够找到合适的信息是一个真正的挑战。
Office Outlook 2007 和 Exchange Server 2007 的搜索功能与之前版本相比有了很大提高。无论用户处于缓存模式还是在线模式，都将对邮件使用相同的搜索算法。处于在线模式下时，搜索查询被发送到 Exchange 服务器，在那里搜索得以执行。Exchange Content Indexer（比 Exchange Server 2003 中的索引程序快达 35 倍）用于保证快速查找和检索信息。处在缓存模式下时，Outlook 使用“即时搜索”（基于 Windows® Desktop Search 3.0），能够合并搜索引擎并减少 CPU 时间。可以对出现在主题、正文、收件人和发件人字段甚至是附件中的文本进行搜索，如图 3 所示。
图 3 搜索重要电子邮件的新方法
图 3 搜索重要电子邮件的新方法

通过统一消息访问任意位置
Exchange 统一消息是 Exchange Server 2007 的一个内置组件，它将所有类型的业务通信（包括电子邮件、语音邮件和传真）都汇集到一个单独的收件箱中。在传统的系统中，语音邮件是通过电话获得的，电子邮件是通过计算机获得的，而传真则是通过专用的传真机获得。Exchange 统一消息可以使用户选择最佳客户端来满足他们在特定时间和地点的需求。在 Outlook 中，语音和传真消息出现在紧临电子邮件消息的收件箱中。语音邮件消息一经选中，将包含一个嵌入式播放器，以便能够直接从阅读窗格播放消息（请参见图 4）。
图 4 通过 Outlook 播放语音消息
图 4 通过 Outlook 播放语音消息
Outlook 还允许在上下文中处理消息。通常，当您收听语音邮件时，会在纸上草草做一些记录。这些记录与消息不相关，还可能被丢失，很难成为有效通信的模型。使用 Exchange 统一消息可直接在 Outlook 中进行记录。它们与消息紧密相关，并以可搜索文本形式建立索引，从而确保记录始终出现在语音邮件消息的上下文中。这样一来，就可使用 Exchange Server 2007 和 Office Outlook 2007 的改进搜索功能快速找到它们。
Outlook 还能够管理大量的语音邮件选项（请参见图 5），包括允许用户在客户端更改语音信箱的个人识别码 (PIN)（申请 PIN 重置是语音邮件系统支持人员呼叫的一个主要方面）。利用 Outlook 中的选项，用户可以生成一个新的 PIN 并通过电子邮件发送给他们。该 PIN 使他们能够一次性访问 Exchange 统一消息电话界面、Outlook Voice Access，之后会要求他们更改 PIN。
图 5 统一消息包含 Pin 重置选项
图 5 统一消息包含 Pin 重置选项

保障和保护
当今组织的消息环境面临着许多威胁。Outlook 和 Exchange 将联手对抗这些威胁。垃圾邮件只是其中的一个威胁，Office Outlook 2007 增加了对 Outlook 电子邮件邮戳（对抗垃圾邮件的一种新方法）的支持。Outlook 对待发邮件执行一个小计算谜题，并将谜题答案附加到该邮件。之后 Exchange 会检查结果。在每次只发送一封的基础上执行计算谜题（合法邮件通常是这种情况）时，几乎不占用 CPU 时间，如果垃圾邮件发送者的计算机必须为大量电子邮件创建谜题，他们计算机的负担将会变得非常沉重。因此，带有 Outlook 电子邮件邮戳的邮件与没有邮戳的相比显然更加合法，在确定每封电子邮件合法性的时候，Exchange 会考虑这个因素。
除了垃圾邮件等旧有威胁，新的监管体制正在改变消息系统的要求。Sarbanes-Oxley、HIPPA 和 Basel II 等法规就记录的保留或破坏制定了严格的规则。为了满足这一新需求，Exchange 和 Outlook 引入了“托管文件夹”。这些文件夹由管理员针对特殊类型的消息而建立。在 Outlook 中，最终用户可以看到这些文件夹以及应在文件夹中储存的内容的描述（请参见图 6）。使用 Exchange 传输规则也可将消息自动发送到特定的文件夹中。一旦消息位于一个指定的“托管文件夹”中，就会保留该文件夹的存档、保留和过期策略，并将以与组织策略一致的方式自动进行处理。
图 6 托管文件夹强制执行电子邮件规章遵从规则
图 6 托管文件夹强制执行电子邮件规章遵从规则
尽管做出了最大努力，但偶尔也会有违背规章遵从的情况。在这些实例中，快速标识和修复是必要的。Exchange 提供的快速搜索功能成为一种关键工具，可供合规专员查找能成为确定违背规章遵从的线索的消息。为了找出并纠正此类违规情况，可跨邮箱执行搜索。

更易于管理的环境
Exchange Server 2007 和 Office Outlook 2007 一起，使消息系统与先前版本相比有了很大提高。它们将所有重要业务邮件都汇集在一个位置，使这些邮件易于查找、创建，并使它们的安全性和遵从性更高。它们共同将协作和通信提高到新的水平。

Michael Khalili是 Exchange Server 的产品经理，负责“客户端访问”和“统一消息”。除此之外，他还负责 Outlook 和 Exchange 的集成。


 Exchange Server 2007: 与 Exchange 2007 永远的亲密接触
Exchange Server 2007 Joshua Trupin

与 Exchange 2007 永远的亲密接触
概览:
  • Outlook Web Access 的改进
  • Exchange Server 2007 中的统一消息功能
  • 通过 ISA Server 2006 实现安全性

几年前，在线通信是最基本的通信方式。人们通过 POP3 和 SMTP 发送电子邮件。一切都那么简单。当然，一切也需要改变。今天，组织需要为员工提供
足够的灵活性，使他们可以自由选择工作的时间和方式，同时这一切也必须是安全的。Microsoft® Exchange Server 2007 有几项针对这些需求的内置功能，其中包括 Microsoft Office Outlook® Web Access (OWA) 和统一消息功能。让我们来一起研究 Exchange Server 2007 的这两个关键组件，了解它们如何超越了先前的版本来为今天的企业创建功能更为强大的通信平台。
OWA 从 5.5 版本开始成为 Exchange 的一部分。坦白地说，它最初的几版有些笨拙。它们解决了通过 Web 浏览器访问 Exchange 邮箱的问题，但这都是在没有充分利用 Outlook 所提供的各种功能的情况下实现的。
随着 Exchange Server 2003 所附带 OWA 的改进，事情对于最终用户而言开始有所好转。基于浏览器的体验比以往要自然得多，基本就像是在使用客户端程序。Exchange Server 2007 中的 OWA 又更进了一步，它是抛开以前版本完全重新编写出来的，从而充分利用了其他最新的技术创新，例如 RPC over HTTP 和 ASP.NET 2.0。
举个例子，我们来看一下 OWA 是如何完成呈现的。先前版本的 OWA 在存储过程中通过邮箱服务器呈现。这样会给邮箱服务器增加额外的负担，可能造成系统速度下降。相比之下，Outlook Web Access 2007 则通过 ASP.NET 在客户端访问服务器 (CAS) 上呈现数据。这样就使邮箱服务器从页面处理工作中解脱出来，从而提高了性能。
此外，前端所执行的工作也发生了改变。在先前版本的 Exchange 中，OWA HTTP 请求会通过代理转到相应的邮箱服务器。而 Exchange Server 2007 通过 RPC 直接从相应的邮箱服务器提取数据，从而减少了与 OWA 相关的通信量。在某种程度上说，也正因为有了这个过程，您才可以在位于企业虚拟专用网络 (VPN) 连接之外的客户端上使用 Outlook。然后通过 OWA 呈现邮箱信息。Exchange Server 2007 也可以代理 OWA 请求，但它并不是将其直接发送到邮箱服务器，而是转发给其他 CAS 服务器。
图 1 显示了 Exchange Server 2007 上 OWA 的体系结构。
图 1 OWA 如何访问 Exchange Server 资源
图 1 OWA 如何访问 Exchange Server 资源

管理
重建后的 Exchange Server 2007 体系结构中包含一些用于管理 OWA 的扩展选项。您可以使用 Exchange 管理控制台或使用 Exchange 管理外壳。配置设置存储在几个位置。
通过 Exchange 管理控制台可以访问大多数可能的配置设置，例如使用分段实现的启用或禁用功能、附件拦截、身份验证、以及日历、任务列表和拼写检查等访问功能。在 Exchange 管理控制台中能完成的工作也都可以通过 Exchange 管理外壳任务来完成。
此外，通过 Exchange 管理外壳还可以创建和删除 OWA 的新虚拟目录。您还可以对基于用户的分段设置进行更好的控制以及更改默认语言设置等等。
Windows 注册表是表单式身份验证超时值的默认存储位置（这些设置无法通过 Exchange 管理控制台或 Exchange 管理外壳获得）。通过 Active Directory® 可以访问特定于 OWA 的设置，例如附件拦截和分段。IIS 元数据库中包含可影响 IIS 行为的所有设置（身份验证、GZIP）。web.config 用于保存 ASP.NET 设置，例如控制 OWA 附件上传的“maxuploadsize”。

身份验证
OWA 提供了几种服务器端身份验证选项。安装后，安全功能默认采用基于表单的身份验证。但您可以根据组织需求在必要时通过几种方法进行改进。IIS 将根据 Active Directory 执行身份验证，以确保通过验证的用户拥有相应的域权限。您还可以使用基本身份验证、数字身份验证、RSA SecurID 甚至智能卡登录等方式来访问电子邮件。
OWA 最强的安全性级别是 Windows 集成身份验证，它将 Kerberos 和 NTLM 完美结合。事实上，Outlook Web Access 2007 Web 部件访问和 Active Directory 站点之间的 CAS 代理都要求采用 Windows 集成身份验证方式。它还为用户通过 Intranet 访问 OWA 提供了一点额外的好处，即实现了 Windows 客户端身份验证的单点登录。这样，如果您已经是受信用户，就无需再登录 OWA。
如果您使用默认的表单式身份验证，OWA 会在一段时间的不活动状态后自动超时。根据用户在登录期间出现相应提示时所选择的机器类型（公用或专用），超时时间会有所不同，可能是 15 分钟（公用机器），也可能达到 8 小时（专用计算机）。用户对于公用或专用机器所做的选择非常重要，因为其他安全性设置也可以因此项设置而异。例如，您可以在公共机器上拦截附件，也可以更改身份验证超时值。基于表单的身份验证过程基本分为四个步骤（如图 2 所示）。
图 2 身份验证过程
  1. 客户端将未加密的请求发送给服务器。
  2. 服务器将加密的 cookie 发送回客户端。
  3. 服务器不断丢弃和创建新的加密密钥，并将三个最新的密钥保存在内存中。
  4. 如果客户端在发送请求时所使用的加密密钥已经过时但仍在内存中，则会收到以最新密钥加密的新 cookie。
    —或者—
    如果客户端在发送请求时所使用的过时加密密钥已被丢弃并且已经超时，则必须重新登录。

msExchQueryBaseDN 是用来限制某些用户只能看到 OWA 一小部分地址簿的一种机制。msExchQueryBaseDN 会在 Active Directory 用户对象上被加以标记，指向某个“地址列表”(AL) 或“组织单位”(OU)。此 AL 将用作用户的“全局地址列表”(GAL)，用户所看见的 GAL 仅包括此 OU 中的用户帐户。可使用 LDAP 设置 msExchQueryBaseDN。

向后兼容性
Exchange Server 2007 中 Outlook Web Access 的核心是 CAS，而该 CAS 模型已经有了进一步的发展，最大程度地提供了与运行早期版本 Exchange 的服务器的互操作性。为了确保这种互操作性，务必首先部署或升级 CAS 服务器，然后再升级其相关的邮箱服务器。
可以使用 CAS 角色的 Exchange 2007 服务器连接到 Exchange 2000 和 Exchange 2003 服务器上的邮箱。站点部分升级后，RPC over HTTP 和 Exchange ActiveSync® 都会继续工作。如果通过 /exchange、/public 或 /exchweb 虚拟目录进行访问，OWA 和 WebDAV 也会有效地工作。您还可以在 Exchange Server 2007 上为这些早期版本创建自定义的 OWA 虚拟目录。

ISA Server 2006 是您的朋友
Exchange Server 2007 中的 Outlook Web Access 比之从前已经有了长足的进步，但如果与 Internet Security 和 Acceleration (ISA) Server 2006 配合使用，则无异于锦上添花。
ISA Server 2006 是集成的边缘安全网关。它既能帮助您保护站点免受来自 Internet 的威胁，同时也提供对应用程序和数据的安全远程访问。这也是 OWA 的目标，因此这两个功能的配合使用将实现所有计算思想中最为神奇的一个：协同（有关 ISA Server 的背景信息，请参阅 microsoft.com/isaserver/2006）。
ISA Server 2006 为饱受折磨的 Exchange 管理员带来几点好处。举个例子，“Web 发布负载平衡”(WPLB) 功能允许您使用 HTTP cookie 来平衡负载。即使客户端 IP 发生改变，也可以确保客户机/服务器关系。ISA Server 2006 还提供 GZIP 压缩和解压缩功能，允许您分析通信量或从 Web 服务器卸载压缩任务。使用 ISA Server 2004 时，您必须进行以下选择：将 HTTP 压缩与 OWA 配合使用，或者将基于表单的身份验证与 ISA Server 配合使用。幸运的是，ISA Server 2006 同时支持这两种选择。
此外，还可以通过 ISA Server 执行 OWA 链接转换。如果有人在 OWA 电子邮件中放入了一个 Intranet 链接，ISA Server 可以将其转换为正确的 Internet 链接。这项功能是相当有用的，但必须记住要将 Intranet 链接发布到正在发布 OWA 的 ISA 阵列。
或许最重要的是，ISA Server 2006 执行预身份验证，来帮助在外围保护网络的安全。预身份验证旨在确保恶意的 HTTP 通信流不会到达服务器。如果被引向 CAS 的通信流事实上是有效的，ISA Server 会允许其从外围网络进入域中（外围服务器在 Intranet 域之外，负责拦截不应进入域中的通信流。CAS 不应部署在外围域中，而需要部署在 Intranet 域中，这样才能访问 Active Directory 用户帐户）。

Outlook Web Access 故障排除
Outlook Web Access 2007 提供了一些用于改进监视和故障排除工作的新工具。监视任务会自动运行于 CAS 服务器上，用于测试每个邮箱服务器的连通性以及 OWA 登录。Exchange Server 2007 还提供了更为详细的“事件日志”消息和“性能计数器”。
Exchange 最佳实践分析工具（请参阅 microsoft.com/technet/technetmag/issues/2006/01/TuneUpExchange 中的内容）有了进一步的改进，它可以在 OWA 配置不当的情况下发送相关警告和错误消息来提醒管理员。您还可以通过 LogParser 工具从 IIS 生成 OWA 使用情况报告（microsoft.com/technet/technetmag/issues/2006/10/LogParser 上 2006 年 10 月刊中有这方面的介绍）。

统一消息功能
OWA 解决的是移动业务需求，而统一消息功能将不同形式的消息合并到一个统一的位置（因此而得名）。现在，电子邮件业务依赖于 Exchange Server。而语音业务（电话呼叫、语音邮件）则通过电话服务器来提供。收电子邮件要在桌面上，接听语音邮件则要通过电话。我甚至还没用过传真消息呢！
通过 Exchange Server 2007 的统一消息功能，组织可以将电子邮件、语音和传真数据传送到一个收件箱中，用户则通过 Outlook 和 OWA 访问这里的所有信息。统一消息功能也会将消息传递到另一个方向：用户可以通过 Outlook Voice Access 来以电话方式访问语音邮件、电子邮件、联系人和日历。
对系统管理员而言，统一消息功能将 Exchange 和电话基础结构结合起来，提供了一个存储解决方案、一个目录和一个传输，从而简化了消息的处理工作。而且由于每个人只需要一个邮箱，总体复杂性程度有所下降。
最好的一点是什么呢？这可以通过现有服务器来实现。了解了 Exchange Server 2007 和电话技术后，您的学习曲线就会相当平坦。统一消息的各项功能与 Exchange 相集成，您将使用相同的安全模型和相同的收件箱。您甚至可以通过 OWA 访问语音邮件和传真。
图 3 显示在安装了统一消息服务器角色后 Exchange Server 2007 中统一消息的体系结构。仔细看一下（以后可能会有测验），然后我们来详细探讨统一消息体系结构。
图 3 统一消息功能将语音、传真和电子邮件通信整合在一起
图 3 统一消息功能将语音、传真和电子邮件通信整合在一起
在企业中设置统一消息功能时，需要了解许多基本的要素。Exchange Server 中包含代表电话硬件的对象。随后可以在 Exchange Server 环境中定义这些对象的关系。Exchange Server 统一消息系统对象包括“UM 服务器”、“UM 拨号计划”、“UM IP 网关”和“UM 查寻组”，此外还有“UM 邮箱策略”和“UM 自动助理”。下面让我们看一看每个对象如何来证明其存在的价值。
“UM 服务器”对象创建于装有 UM 服务器角色的 Active Directory 中。通过它，管理员可以控制 Exchange Server 2007 统一消息部署的设置和属性。“UM 拨号计划”是统一消息功能中的基本管理单元，表示分机号的内部使用方法。“拨号计划”中的所有用户只需拔打分机号即可与所有其他人联系。如果要与其他位置结合在一起，双方通常都要有自己的“拨号计划”。
“UM IP 网关”对象代表物理的 IP 电话 (VoIP) 网关或启用了“会话初始协议”(SIP) 的 IP 专用分组交换机 (PBX)。统一消息服务器可以从 IP/VoIP 网关设备接收呼叫。“UM 查寻组”将“IP 网关”与“UM 拨号计划”链接在一起。在 PBX 配置一个“查寻组”后，就会在 Active Directory 中创建一个“UM 查寻组”来代表它。可以配置“查寻组”来提供跨 IP 网关的负载平衡。这些网关进而又可以通过将一个“UM 查寻组”与多个网关相关联来提供负载平衡。“UM 邮箱策略”类似于语音邮件分级服务，其中包括一个“拨号计划”和若干用来为用户和组设置运行策略的属性。
“UM 自动助理”可以与一个“UM 拨号计划”相关联。它可以通过定制来执行多种任务，例如针对不同日期和时间定制的提示记录和定义任务。“自动助理”的作用范围可以通过地址列表来划定。
图 4 显示了这六个统一消息对象是如何相互配合工作的。
图 4 统一消息电话对象的交互作用
图 4 统一消息电话对象的交互作用

设置
用户有了 Exchange Server 2007 邮箱后，管理员必须针对统一消息功能来启用它。为此，管理员必须在“拨号计划”中将邮箱与一个“UM 邮箱策略”和一个分机号相关联。此外，还必须将 PBX 配置为在出现 RNA（响铃，无应答）时将呼叫路由到统一消息服务。PBX 首先会将呼叫路由到用户的分机。如果发生 RNA 情况，则再将呼叫路由到 VoIP 网关，然后路由到统一消息服务器。
统一消息具有可伸缩性。您可以根据业务需要添加任意多个电路交换式 PBX 通道和 UM 服务器。使用 VoIP 网关时，基于 IP 的呼叫会被传送给 Exchange 统一消息服务。由于这对于许多企业来说是全新的功能，因此您应当进行全面的网络分析，以确保 IP 网络有足够的带宽来同时处理数据和语音。
通常，Exchange Server 2007 统一消息服务器可以处理 50 到 200 个并发 IP 呼叫，以及最多 200 个传入的语音和传真呼叫（默认情况下设置为 100）。如果您需要更大的处理能力，或者想要提高容错能力，可以扩建额外的统一消息服务器。

结束语
至此您已经找到了答案！Exchange Server 2007 提供两个功能：Outlook Web Access 和统一消息，这两个功能共同为组织带来了巨大的利益。Outlook Web Access 可以让您从任何地方安全地访问电子邮件，而统一消息功能允许用户访问最终都将进入 Exchange 2007 邮箱的电子邮件、语音邮件、传真消息和其他邮箱数据。

Joshua Trupin 是 MSDN 杂志和 TechNet 杂志的执行编辑。他为 MSJ、MIND、MSDN 杂志和 TechNet 杂志撰写了许多文章。另外他还编写了《Hoop Stats:The Basketball Abstract》一书。


 Exchange Server 2007: Exchange 2007 中更强大的日志功能
Exchange Server 2007 David Strome

Exchange 2007 中更强大的日志功能
概览:
  • Exchange Server 2007 日志规则
  • 新日志向导
  • 日志报告中包括的内容

您是否曾经不得不记录您与某位特定用户之间往来的电子邮件，而结果是您要连同驻留在该邮箱存储中的其他 300 个邮箱中的邮件
一起来查找这些特定的电子邮件？Microsoft Exchange Server 2007 解决了这个问题，为您提供了您所需要的精确控制。
企业“客户端访问许可证”(CAL) 提供了按收件人的日志功能，允许您将目标指向要记录的人。通过使用日志规则，现在您可以将目标仅指向您想要记录的收件人和发件人。可将焦点缩小为单个的邮箱，也可扩大到包括销售部门的全体人员（举例来说）。而且，他们的邮箱不必在同一个服务器上、同一个 Active Directory® 站点上，甚至是同一个 Exchange 组织中。通过 Active Directory 复制，您的变更会自动应用于贵组织中运行中心传输服务器角色的所有计算机。

日志原理
在 Exchange Server 2003 中，日志功能是针对每个物理服务器上的每个邮箱存储来实现的。如果想要记录组织中的所有邮箱，您需要对每个邮箱存储配置日志功能。而如果想要记录单个收件人的邮件，您必须在该用户的邮箱存储中记录每一个人或者是专门为该用户创建一个新的邮箱存储。
Exchange Server 2007 中的日志功能利用了 Exchange 中新增的基于角色的拓扑功能。如图 1 中所示，当所有邮件发送至/自邮箱和统一消息服务器、其他 Exchange 系统、第三方应用程序和 Internet 时，它们均由中心传输服务器进行处理。所有中心传输服务器都包含一个称为日志代理的传输代理，它负责将日志规则应用于邮件。由于日志代理位于中心传输服务器上，所以它会在邮件到达其收件人之前遇到每个邮件并对其进行评估。日志代理会在分类之后进行邮件操作 — 这能够确保访问邮件的所有收件人和发件人属性，并允许代理决定该邮件是直接发送给收件人的还是通过通讯组扩展接收到的。它还会指出收件人是否存在于源于 Exchange Server 2007 组织之内的邮件的“收件人”、“抄送”或“密件抄送”行上。
图 1 中心传输服务器邮件流程
图 1 中心传输服务器邮件流程
当邮件通过中心传输服务器时，日志代理会对其应用管理员配置的日志规则。这些规则用于决定代理是否要捕捉关于某邮件的信息，从而将该信息与原始邮件一起转发到日志邮箱。该数据将以称为日志报告的邮件形式进行发送。
对于早期版本的 Exchange，您必须将配置应用于多个服务器。而当您在 Exchange Server 2007 中创建了日志规则后，该变更将通过 Active Directory 应用于贵组织中的所有中心传输服务器。所有中心传输服务器，进而所有日志代理都将从 Active Directory 读取该同一配置。因此，这一切确保了所有日志代理均应用相同的日志配置。
当您创建或修改日志规则时请牢记 Active Directory 复制时间，因为配置变更需要在您的整个组织范围内进行复制并由中心传输服务器读取。这可能会花费几个小时的时间。为帮助您确定日志配置的更新时间，Exchange 在每个服务器的安全事件日志中都记录了一个事件。
Exchange Server 2007 可确保日志报告绝不会由于日志邮箱不可用、已满、配置错误或脱机这些原因而丢失（这尤其有利于帮助您遵守各种法律法规要求，因为丢失的邮件可能导致违约）。如果日志报告无法传送到日志邮箱，则该报告将保留在中心传输服务器的队列中，直到日志邮箱可用。由于这样可导致队列迅速膨胀，因此，您应监控日志邮箱的可用性以确保其运行正确。如果日志邮箱在很长一段时间内仍不可用，您可以配置一个替代邮箱来接收队列中的报告。

确定记录内容
开始创建日志规则之前，您需要清楚地知道您想要面向的对象以及想要记录的数据类型。您可通过在日志规则中指定用户来选择要记录的特定用户。举例来说，这些用户可能受到了监管要求的制约，也可能是牵涉到了要求收集电子邮件和其他通信信息以作为证据的法律程序中。
除指定要记录的收件人之外，您还可以确定要记录的邮件范围，有“内部”、“外部”和“全局”三种选择。“内部”仅面向组织内部的邮件，“外部”面向发件人或其中一位收件人在外部的邮件，“全局”同时面向内部和外部邮件（请注意，“全局”选项将记录通过中心传输服务器的所有邮件，甚至包括那些可能已按照“内部”和“外部”范围由规则处理过的邮件）。
Exchange Server 2007 支持统一消息，因此您可将 Exchange 配置为收集用户收件箱中的所有电子邮件、语音邮件和传真。这还意味着您可以记录所有这些数据，或选择排除某些数据。
如果您运行的是具有标准 CAL 的 Exchange Server 2007，则您仍然可以使用按邮箱存储日志功能。然而，如果想要使用新增的按收件人日志功能，则必须升级到 Exchange Server 2007 Enterprise CAL。

日志邮箱的存放位置
确定了要记录的内容后，您还需要决定要将日志报告发送到何处。如果您拥有多个站点，则在决定日志邮箱的存放位置时，需要考虑您当前或计划的网络拓扑。日志可能产生大量的重复报告，这取决于贵组织的规模和邮箱的数量。
不过，您不必总是使用 Exchange 上的邮箱。您可将日志报告发送到任何有效的 SMTP 地址。该地址可以指向 Exchange Hosted Services、第三方存档解决方案或使用通讯组的这两者的任意组合。然而，请注意，可能会存在与日志报告发送到的位置相关的某些安全隐患。
不管您决定将日志邮箱存放于何处，都要必须在 Active Directory 中为其创建一个收件人对象。这可以是 Exchange Server 2007 邮箱、用于将邮件重定向到 Exchange Hosted Services 或第三方存档解决方案的启用了邮件功能的联系人，或者是同时包含邮箱和联系人的通讯列表。

日志报告中的内容
当日志代理记录邮件时，它会尽可能多地将有关原始邮件的详细信息捕获到日志报告中。然后，将该报告发送到日志邮箱。该信息在帮助您确定邮件意图、其收件人和发件人方面非常重要。例如，在何处标识收件人（是将其地址直接填写到“收件人”字段中、包括在“抄送”字段中，还是仅作为通讯列表的一部分）可帮助确定收件人在邮件讨论中的参与方式。原始邮件作为一个附件随附在其中。图 2 中的屏幕快照显示了两个日志报告，其中一个日志报告指示发送到 david@contoso.com 的邮件已转发给 christine@contoso.com，另一个日志报告指示发送到 Sales_Group@contoso.com 通讯组的邮件已被扩展，收件人 lukas@contoso.com（“销售组”通讯组的一名成员）已收到该邮件。两个报告均将原始邮件作为附件包含在内，显示原始发件人为 brian@contoso.com，主题为“Sales forecast”。
图 2 显示转发的收件人和扩展的通讯组收件人的日志报告
图 2 显示转发的收件人和扩展的通讯组收件人的日志报告
Exchange 仅对其已知为正确的信息进行分类。无法自动确定的信息将被放到日志报告的适当字段中。图 2 对日志报告正文部分包含的字段进行了说明。

所有安全性问题
默认情况下，同一 Exchange 组织中运行 Exchange Server 2007 的计算机之间的所有通信都会被加密。此加密包括日志报告。Exchange Server 会采取一系列措施以降低日志报告被篡改的风险：
  • 在 Exchange 2007 组织的中心传输服务器和邮箱服务器之间使用安全链接。
  • 以“Microsoft Exchange”代表原始邮件的发件人发送日志报告。
  • 中心传输服务器与邮箱服务器之间的会话需要通过验证。
  • 在同一 Exchange 2007 组织的中心传输服务器和邮箱服务器之间发送日志报告时，仅接受通过验证的连接。
创建日志邮箱时，您必须确保其安全性，因为该邮箱包含发送至/自贵组织中收件人的那些邮件。某些邮件可能是法律程序的一部分或是受到监管要求的制约，且很多法律都要求邮件在被提交给侦查机构之前保持免篡改状态。为增强日志邮箱的安全性，您应将日志邮箱配置为仅接受来自 Microsoft Exchange 发件人的邮件并要求发送到日志邮箱的所有邮件均由通过身份验证的发件人来发送。图 3 显示了日志邮箱上所配置的邮件传送限制。您也可以使用以下“Exchange 管理外壳”命令来配置这些邮件传送限制：
Set-Mailbox <Journal Mailbox Name>
-AcceptMessagesOnlyFrom "Microsoft Exchange" -RequireSenderAuthenticationEnabled $True
图 3 邮件传送限制
图 3 邮件传送限制
如果要将日志报告发送到 Exchange Server 2007 组织之外的日志邮箱，则必须对 Exchange Server 2007 计算机与接收服务器之间的连接进行手动加密并确保其安全。您可以通过以下方法来实现：要求在两个系统之间使用传输层安全性 (TLS)、要求在接收系统上进行验证、在接收系统上仅接受来自 Microsoft Exchange 收件人 SMTP 地址的邮件（该 SMTP 地址类似于 Exchange_UMUnique GUID@contoso.com）、将用于转发邮件的 Active Directory 联系人配置为仅接受来自 Microsoft Exchange 收件人的邮件。

实现日志规则
我们已经谈论得足够多了，还是来实现一些规则吧！日志代理中的日志规则可以在“Exchange 管理外壳”或“Exchange 管理控制台”中进行配置。每种方式都可用于配置收件人、范围和日志邮箱设置。默认情况下，日志规则会在创建后即启用。您指定的日志电子邮件地址值必须是 Exchange Server 2007 组织中的现有收件人对象。该收件人对象可以是邮箱、通讯组、动态通讯组或用于将邮件发送到某个 SMTP 地址的联系人。
使用“Exchange 管理控制台”时，“新建日志规则”向导将引导您完成新日志规则的创建过程。在“组织配置”部分，选择“中心传输服务器角色”。然后，在“操作”窗格中，单击“新建日志规则”。其中，您必须提供规则名称、日志电子邮件地址和范围的值。如果想要日志规则记录组织中所有收件人的邮件，则不必指定“收件人”字段的值。您还可以选择是否希望日志规则在创建后被禁用。图 4 显示了将记录发送自/至 brian@contoso.com 的所有邮件的示例配置。已记录的邮件将发送到名为 Compliance Mailbox 的日志邮箱中。
图 4 新建日志规则向导
图 4 新建日志规则向导
在“Exchange 管理外壳”中，您可以使用以下六个 cmdlet 来管理日志代理。
  • New-JournalRule
  • Set-JournalRule
  • Get-JournalRule
  • Remove-JournalRule
  • Enable-JournalRule
  • Disable-JournalRule
New-JournalRule cmdlet 用于新建日志规则。以这种方式新建日志规则的基本条件与使用向导时相同。您必须指定 Name、Scope 和 JournalEmailAddress 参数的值。同样，如果想要日志规则记录组织中所有收件人的邮件，则不必指定 Recipient 参数的值。如果想要在创建日志规则后将其禁用，您必须为 Enabled 参数指定值 $False。要创建配置与图 4 中所示配置相同的日志规则，请使用以下命令：
New-JournalRule
-Name "Brian Smith Journal Rule"
-Recipient brian@contoso.com
-JournalEmailAddress "Compliance Mailbox"
-Scope Global
使用 Get-JournalRule cmdlet 可查看您已经创建的所有日志规则的列表。独立运行该 cmdlet 将显示贵组织中配置的所有日志规则及其配置设置的汇总列表。如果想要查看有关日志规则的所有可用信息，您可以在 Get-JournalRule cmdlet 与 Format-List cmdlet 之间建立管道。管道会将一个 cmdlet 的输出发送到下一个 cmdlet，因此第二个 cmdlet 可以对该输出进行其他处理。例如，Format-List cmdlet 将显示其接收到的所有输出。要查看可用于先前创建的日志规则的所有信息，请使用以下命令：
Get-JournalRule -Identity "Brian Smith Journal Rule" | Format-List
要启用或禁用日志规则，可使用 Enable-JournalRule 和 Disable-JournalRule cmdlet。使用这两个 cmdlet 时，需要在 Identity 参数中指定日志规则名称。例如，要禁用我们刚刚创建的日志规则，请使用以下命令：
Disable-JournalRule -Identity "Brian Smith Journal Rule"
Set-JournalRule cmdlet 用于修改现有日志规则。日志规则的名称与 Identity 参数结合使用，以将您要修改的规则通知给日志代理。然后，指定 Recipient、JournalEmailAddress、Scope 或这些参数的任意组合以及新值。例如，要修改存储在我们所创建的规则的 JournalEmailAddress 参数中的值，请使用以下命令：
Set-JournalRule -Identity "Brian Smith Journal Rule" -JournalEmailAddress "Seattle Users Compliance Mailbox"
最后，可使用 Remove-JournalRule cmdlet 来删除现有日志规则。使用 Identity 参数来指定日志规则的名称。要删除我们的示例日志规则，请使用以下命令：
Remove-JournalRule "Brian Smith Journal Rule"
当您执行此操作时，“Exchange 管理外壳”会询问您是否确实要删除该日志规则。下面是最后一个提示：几乎对于所有的 cmdlet，您都可以省略 Identity 参数标签，而仅指定参数值即可。

David Strome担任 Microsoft“Exchange 用户培训”小组的技术撰稿人刚刚一年多的时间。在加入位于华盛顿雷德蒙的 Microsoft 之前，David 有大约 10 年时间供职于加拿大大不列颠哥伦比亚省的多家公司，从事 Exchange Server 安装的设计、实现和管理工作。可通过 dstrome@microsoft.com 与其联系。


 Exchange Server 2007: 通过发件人 ID 抵御垃圾邮件和网页仿冒欺诈
Exchange Server 2007 Craig Spiezle and Alexander Nikolayev

通过发件人 ID 抵御垃圾邮件和网页仿冒欺诈
概览:
  • 发件人 ID 基础
  • 在 Exchange Server 中配置发件人 ID
  • 身份验证的优点

为了应对日益加剧的垃圾邮件的威胁，已经开发了许多身份识别和筛选技术。这些技术主要依靠询问一些有关每封电子邮件的问题来有效发挥作用，例如
发件人是谁。遗憾的是，发件人是谁这样的基本问题并非总是那么容易回答。电子邮件通常是通过 Internet 发送，而不会对发件人或代表发件人的计算机进行任何身份验证。事实上，假冒他人身份发送电子邮件是一件非常容易的事情，而且也没有任何对欺骗邮件进行自动检测的方法。
简单邮件传输协议 (SMTP) 用于发送和接收电子邮件，其设计初衷不包括验证电子邮件的发件人。由于存在这一技术漏洞，任何名称和地址都可以作为发件人插入。因此，内容筛选或反垃圾邮件措施不能只依赖标头信息来确保邮件确实来自邮件中描述的位置。
电子邮件身份验证专门解决这一漏洞。有了身份验证，电子邮件发送和接收系统都会验证邮件是否来自发件人所声称的域。这使组织可以更加容易地有效筛选垃圾邮件，还可确保合法电子邮件到达目标收件人。
如今，有两种免费提供的方法可用于电子邮件身份验证：发件人 ID 框架 (SIDF) 和域名密钥身份识别邮件 (DKIM)。SIDF 是一种基于 Internet 协议 (IP) 的解决方案，通过将“发件人策略框架”(SPF) 和“Microsoft 电子邮件呼叫方 ID”合并而产生。2006 年 4 月，“因特网工程工作组”(IETF) 发布了发件人 ID 规范 RFC 4405-4408。行业和利益相关者（包括 Microsoft）联合建议基于以下因素部署 SIDF：业务和技术数据、稳定性、完备性、部署灵活性、对入站或出站性能的影响最小，以及与 ISP 和企业环境的电子邮件系统的互操作性。
DKIM 综合了 Yahoo! 的域名密钥和 Cisco Systems Inc. 的互联网邮件标识 (IIM) 规范。2006 年 1 月，IETF 批准创建 DKIM 工作组，该规范目前正由 IETF 进行审查。
虽然没有一个完美的解决方案可以抵御垃圾邮件，但是 SIDF 代表了业界抵御域名欺骗的重要开端。因此，它是在线减少垃圾邮件和网页仿冒欺诈攻击并增加信任和可信度的关键组件。全世界采用 SIDF 的组织数目正急剧上升。如今，五百五十万以上的公司和域持有者都已发布了 SPF 记录，有六亿多用户得到 SIDF 的保护。目前，全世界三分之一的电子邮件每天要经过身份验证并遵从 SIDF。
如果没有众多组织和公司的贡献和支持，就无法开发出 SIDF 并在世界范围内进行推广，这些组织和公司包括 AOL、Authentication and Online Trust Alliance (AOTA)、Bell Canada、E-Mail Senders Provider Coalition (ESPC)、CipherTrust、Cisco Systems、IronPort Systems、MarkMonitor、Port25 Solutions Inc、Sendmail、Symantec、TRUSTe、VeriSign 等。

了解发件人 ID
一些行业调查表明，95% 以上的网页仿冒欺诈垃圾邮件来自欺骗域，并具有欺骗性的发件人电子邮件地址。就是这一点使 SIDF 与反垃圾邮件处理有巨大差异。就其本身而言，SIDF 不会解决垃圾邮件的问题，但其为使垃圾邮件和网页仿冒欺诈攻击的后果降至最低做出了巨大的贡献。SIDF 不会防止发送垃圾邮件。但它确实使垃圾邮件更易于检测。此框架可帮助电子邮件发件人保护其域名、名声及其品牌。它为做出根据发件人名声和电子邮件行为进行筛选的决定打下了坚实的基础。
发件人 ID 会设法验证每个电子邮件是否源自其本身所声称的 Internet 域。其实现方法为，对照域所有者已授权发送电子邮件的服务器的注册列表，检查发送此电子邮件的服务器的地址。Internet 服务提供商 (ISP) 或收件人的邮件服务器会在邮件发送到用户的收件箱之前自动执行验证。
请注意，发件人 ID 或其他任何身份验证机制都不会取代内容筛选系统。SIDF 和 DKIM 都不扫描实际邮件内容。相反，身份验证会通知入站邮件系统是否可以证明该邮件来自声明的发件人。由于大多数垃圾邮件和网页仿冒欺诈的出现实际上并不是来自呈现的域，所以这种方法可以帮助自动识别这些邮件，并将其从传入邮件流中分离出来。
在 SIDF 内，SPF 记录提供与某个域关联的所有出站邮件服务器的简单文本记录，以及其相应的 IP 地址。组织会将 SPF 记录发布到其 DNS 服务器区域文件，随后由收件人邮件服务器进行检查。设置 SPF 记录是一个快速、简单而且免费的过程。发件人 ID 框架 SPF 记录向导提供了检查域邮件服务器和创建要准备发布的自定义记录的分步过程。（有关发布 SPF 记录的详细信息，可从 microsoft.com/senderid 获得。此向导可通过 microsoft.com/senderid/wizard 直接访问。）
接收 SMTP 邮件服务器通过对 DNS 中域的区域文件执行 ping 操作来检查是否存在 SPF 记录。找到后，会对照所列的 IP 地址检查发送服务器的 IP 地址。如果两者相符，则确认此邮件为可信邮件。另一方面，如果发件人域中的 SPF 记录与发送此邮件的 IP 地址不符，则此验证失败，并导致出现负的分值，该邮件可能会被放入垃圾邮件文件夹中。图 1 显示了这一过程。
图 1 检查 SPF 记录中是否有传入邮件
图 1 检查 SPF 记录中是否有传入邮件
SIDF 会使收件人邮件服务器根据发件人过去的行为、名声、邮件内容及其他可根据需要定义的条件对邮件进行分析。这一功能提供了额外的安全措施。例如，垃圾邮件发送者会通过记录相似的域和发布的 SPF 记录来蒙骗用户和接收网络，使其认为该邮件来自合法的发件人。即使这种电子邮件可能会通过身份验证检查，但发件人为垃圾邮件发送者的名声也足以阻止、废弃或删除该邮件。

发件人 ID 部署选项
通过 SIDF 的出站电子邮件身份验证并不需要变更任何基础结构或更新软件，并且不是客户端或服务器软件特有的功能。不过，如果组织想要合并入站身份验证以保护其公司和员工，则将需要更新其入站系统和“邮件传送代理”(MTA)，并部署支持 SIDF 的软件或工具。绝大多数主导商业开源 MTA 及反垃圾邮件供应商（包括 Microsoft® Exchange Server 和 Exchange Hosted Filtering）提供了集成的解决方案。
Microsoft 已将 SIDF 集成到了其所有邮件产品中，包括 Microsoft Exchange Server 2003 Service Pack 2 (SP2)、Exchange Server 2007、Microsoft Exchange Hosted Filtering、Microsoft Windows Live™ Mail、MSN® Hotmail®、Outlook® Express 和 Office Outlook 邮件和协作客户端。
但即使是 Microsoft 也同样会接收到垃圾邮件。Microsoft 日平均传入通信量大约为一千五百万封邮件，而在最近的垃圾邮件攻击期间，我们发现邮件量已达到上述数量的二到四倍之多。在这样的环境下，成功防御垃圾邮件的方法关键在于警惕地执行可行技术。
Microsoft 目前正运行基于发件人 ID 筛选（在 Exchange Server 2003 中）和发件人 ID 代理（在 Exchange Server 2007 中）的内部 Exchange Server 反垃圾邮件解决方案。在这两个版本的 Exchange Server 中，发件人 ID 状态基于对位于相应 DNS 服务器中发件人 ID 记录的评估。将按以下优先级检查 RFC 2822 邮件头确定实际域：
  1. Resent-Sender
  2. Resent-From
  3. Sender
  4. From
发件人域（或最近负责将某个邮件注入邮件流的实体，因为电子邮件系统可以合法地代表其他邮件服务器转发邮件）通过按定义的顺序查找刚刚提到的标头的第一个定义来确定。如果未找到其中的任何标头，则 SIDF 将使用 SMTP RFC 2821 MAIL FROM 值。

配置发件人 ID
在 Exchange Server 2007 中，发件人 ID 代理可在安装了边缘传输角色的服务器中启用。如果启用了发件人 ID 代理，则它将对通过接收连接器传入的邮件进行筛选 - 所有传入（从外部源）且未经过身份验证的通信流都需要经过发件人 ID 处理。在 Exchange Server 2003 中，发件人 ID 状态在 EXCH50 blob 服务器之间得以持久保持；在 Exchange Server 2007 中，此状态也已被添加到邮件元数据中。在最终目标位置时，两个状态均被转换为 MAPI 属性，以供客户端将来使用。
Exchange Server 2003 中的发件人 ID 筛选配置（在“邮件发送属性”下提供）只指定 Exchange Server 如何处理失败的验证。
要启用 Exchange Server 2007 中的“发件人 ID”，只需打开已配置了边缘传输角色的服务器的“Exchange 管理控制台”，选择“反垃圾邮件”选项卡，再选择“发件人 ID”，并在“操作”窗格中单击“启用”或“禁用”以切换“发件人 ID”代理，如图 2 所示。另外，可以使用 Exchange 管理外壳启用或禁用“发件人 ID”，如图 3 所示。
图 2 用于 Exchange Server 2007 中发件人 ID 代理的 Exchange 管理控制台控件
图 2 用于 Exchange Server 2007 中发件人 ID 代理的 Exchange 管理控制台控件
图 3 使用 Exchange 管理外壳启用发件人 ID
图 3 使用 Exchange 管理外壳启用发件人 ID
“发件人 ID 属性”对话框将反映代理的状态，即启用还是禁用。“操作”选项卡提供的选项与 Exchange Server 2003 中提供的选项极为相似（请参见图 4）。
图 4 Exhange Server 2007 中的发件人 ID 代理操作属性
图 4 Exhange Server 2007 中的发件人 ID 代理操作属性
就发件人 ID 实现和功能方面，Exchange Server 2003 与 Exchange Server 2007 之间没有什么重大的差异，而且发件人 ID 筛选（在 Exchange Server 2003 中）和发件人 ID 代理（在 Exchange Server 2007 中）使用同一种基本算法进行提取和验证。可能操作的范围也是相同的：删除邮件（无提示删除）、拒绝邮件（500 级 SMTP 协议响应）以及用发件人 ID 结果标记邮件并继续处理。后一个选项在两个版本的 Exchange Server 中都是默认操作。
在 Exchange Server 2007 中，FAIL 和 TempError 状态码均可触发“拒绝邮件”操作（在 Exchange Server 2003 中，只有 FAIL 状态码可以触发此操作）。需要对发件人 ID 代理进行显式配置，以通过 TempError 状态码触发对邮件进行“拒绝邮件”操作，因为在默认情况下会允许这些邮件进入系统，用发件人 ID 结果作标记，然后再进行处理。
用于此用途的配置选项不会通过图形用户界面显示，所以您必须使用 Exchange 管理外壳配置与 TempError 状态码对应的发件人 ID 操作。例如，要强制发件人 ID 代理通过 TempError 状态码拒绝邮件，请运行以下发件人 ID 代理 cmdlet：
Set-SenderIDConfig -TempErrorAction Reject
Exchange Server 2007 中发件人 ID 状态结果和可能操作的范围与 Exchange Server 2003 发件人 ID 筛选相类似，如图 5 所示。
Figure 5 Exchange Server 2007 中的发件人 ID 状态和操作 (Close Figure 5)

发件人 ID 状态 | 说明 | 操作
Neutral | 已发布的发件人 ID 数据没有明确做出定论 | StampStatus
Pass | IP 地址属于允许集 | StampStatus
Fail | IP 地址属于非允许集 | StampStatus、Delete 或 Reject
SoftFail | IP 地址可能属于非允许集 | StampStatus
None | 无发布数据 | StampStatus
TempError | DNS 服务器不可用之类的临时性错误 | StampStatus 或 Reject
PermError | 无法恢复的错误，例如记录格式错误 | StampStatus
Exchange（如果配置为执行此操作）将只删除发件人 ID 验证失败的邮件。其他任何结果都不会触发邮件删除。结果状态为 Neutral、None、SoftFail、TempError 或 PermError 的传入邮件将相应加以标记并传递下去，以进行进一步的反垃圾邮件验证。在某些情况下，当邮件完全异常并且 FROM IP 地址丢失时，便无法在邮件中对发件人 ID 状态加以标记。此时，邮件不会被丢弃或拒绝。而是会继续传递，以在未设置发件人 ID 状态的情况下进一步处理，并将记录相应的事件以引起关注。
在 Exchange Server 2007 中，很容易定义可以不进行发件人 ID 验证的发件人域和 Exchange Server 收件人。同样，此配置选项只在 Exchange 管理外壳中提供。例如，要从发件人 ID 筛选中排除域 contoso.com，请运行以下命令：
Set-SenderIDConfig -BypassedSenderDomains contoso.com
同样，要从发件人 ID 筛选中排除发送给指定 Exchange Server 收件人的邮件，请运行以下命令：
Set-SenderIDConfig -BypassedRecipients user@contoso.com
在 Exchange Server 2007 中，发件人 ID 的各个配置项（通过 Exchange 管理外壳 cmdlet 设置，但不能通过图形用户界面进行设置）可通过在 Exchange 管理外壳中运行 Get-SenderIDConfig 命令轻松获得，如图 6 所示。
图 6 发件人 ID 配置 cmdlet
图 6 发件人 ID 配置 cmdlet
Exchange 管理外壳可用于快速手动验证 IP 地址和相应的域名。要检查“发件人 ID”状态，请运行以下命令：
Test-SenderID -IPAddress <IPAddress>-PurportedResponsibleDomain <SMTPDomain>
如果该域不存在，您将会看到一个类似于图 7 的结果。
图 7 验证某个地址的发件人 ID 状态
图 7 验证某个地址的发件人 ID 状态

发件人 ID 的优点
除了在对电子邮件进行身份验证和减少用户接收的垃圾邮件数量方面的明显优点外，作为一种协议，SIDF 还具有其他优势。在其开发期间，Microsoft 重点关注几个主要目标，包括性能、成本、部署和可伸缩性及可互操作性。
SIDF 会首先对电子邮件发件人进行身份验证，并会考虑到使用发件人的名声分值。因此，它可能会使垃圾邮件和欺骗性的电子邮件明显减少，并提高来自已知发件人和受信任发件人的合法电子邮件的传输能力。SPF 记录的创建是免费的，所以任何想要遵从 SIDF 的组织都可以轻易实现此操作。希望遵从新标准中的规定的组织应该可以实现此操作。有了 SIDF，实现遵从性就像发布 SPF 记录一样简单。
SIDF 已开发成尽可能在现有软件中运行。它可与大范围的电子邮件体系结构及客户端和服务器软件配合使用。为使其发挥作用，任何身份验证服务在满足最大的 ISP 需求时，都必须能够像满足最小的家用邮件服务器的需求那样容易。SIDF 可以支持一到数千个电子邮件服务器，以及那些将其电子邮件服务器外包给其他组织的邮件服务器。
2007 年 4 月 18 日和 19 日，Microsoft 和包括 30 多个组织和合作伙伴的行业协会将在马萨诸塞州的波士顿举办“身份验证和在线身份提交”。这一活动为期两天，期间将回顾案例研究和发件人 ID 技术，同时详细说明电子邮件身份验证的商业价值。有关详细信息，请访问 aotalliance.org/summit2007。此外，可访问 microsoft.com/senderid 和 microsoft.com/exchange 站点获取有关工具和资源的信息。

Craig Spiezle 是 Microsoft Windows Live Safety 技术策略和规划方面的主管。作为电子邮件身份验证的产品经理，Craig 已成为将发件人 ID 引入该行业的驱动力。Craig 于 1992 年加盟 Microsoft，曾担任过多种管理职务，包括国际市场推广、产品支持策略、OEM 和新市场开发。
Alexander Nikolayev 是 Microsoft 的程序经理，主要负责 Exchange Server 和 Windows Server 的服务器端协议、传输核心和反垃圾邮件组件。他拥有玛莉大学的 MBA 学位。请阅读 Alexander 在 Exchange 团队博客上发表的文章，网址为 blogs.technet.com/exchange。


 编辑视角: 实现目标
编辑视角
实现目标

TECHNET 杂志不只是 现在您手中拥有的这份神奇出版物。我们的团队一直在孜孜不倦地工作着，希望创建一个创新的网站，以使全球能够访问得到我们网站内容的人数超过十亿。从 11 月份的期刊开始，每篇文章将分别以下列七种语言在线提供：英语、西班牙语、法语、德语、俄语、简体中文和巴西葡萄牙语。通过增加六个其他语种（您知道，我们已经提供了英语的在线版本），我们将能够以本国语言阅读我们内容的人数增加了 16 亿之多。真是令人难以置信！
好像这还不够好，我们又增加了一组功能以使站点可用性更强。我们新增的可定制 RSS 源允许您按日期、栏目、作者或主题来选择内容。您甚至可以混合搭配。请立即访问 technetmagazine.com/rss 以开始创建您自己的源。
我们还引入了新的主题页。如果您要阅读有关 IT 专业人员需要完成哪些内容才能做好 Windows Vista 的准备工作的所有文章，只需转到 technetmagazine.com/vista。如果您是邮局主管，一定要查看 technetmagazine.com/exchange。我们已经在 technetmagazine.com/topics 上提供了 32 篇相关文章，陆续还会提供更多（从 11 月份开始，我们已提供了 43 篇有关安全性的文章，以供您查看）。
还远不止这些。现在您甚至可以深入洞察本杂志以及 IT 专业人士的所在领域。Joshua Hoffman 是 TechNet 杂志的技术和组稿编辑，在 blogs.technet.com/tnmag 上主持本杂志博客。而我则负责站点上的每月博客，网址为 www.technetmagazine.com/podcasts。在每期内容中，我将与您所阅读的文章的作者交谈，透过字面解释文章背后的原因。您将非常愿意听到我们的一流作者就各自的文章及其所做工作而作的讨论。
我们正全力以赴，准备将 TechNet 杂志打造成适用于 IT 专业人士的全球最有用资源。虽然我们在 2006 年取得了不错的成绩，但我们非常想知道我们还能为您做些什么。如有任何意见，请发送邮件！我们的编辑热线是 tnmag@microsoft.com。意见邮箱将保持常开状态。
— JOSHUA TRUPIN

向以下 Microsoft 技术专家致以衷心感谢：Kevin Allison、Jessica Arnold、Sebastian Bengochea、Naveen Chand、Li Chen、Alpa Dave、Jill Frank、Mihai Jalobeanu、Darcy Jayne、Harry Katz、Kerry Landen、Todd Luttinen、Brett Muzzey、Bruce Payette、Tony Smith、Shawn Thomas、Jim Truher 和 Scot Vidican。


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

Web 应用程序的压力测试
WAPT Web 应用程序压力测试工具
www.loadtestingtool.com
了解您的最新版本 Web 应用程序执行状况，这对于正确调整基础结构大小，避免出现 CEO 质问您为什么她在查看站点时会得到“服务器太忙”的回应这样令人高度紧张的时刻而言，是至关重要的。而且，如果您在寻找一个相对费用较低、易于使用的 Web 应用程序压力和性能测试工具，则您可能想要查看 SoftLogica LLC 的 WAPT 4.0。
该应用程序运行在大多数版本的 Windows® 上，但是由于在早期版本上存在套接字限制，故您会希望使用 Windows 2000、Windows XP 或 Windows Server® 2003 来获得其全部潜能。与大多数使用虚拟用户的性能测试应用程序一样，拥有的内存越多，处理器速度越快，并且网络连接越丰富，您能够使用 WAPT 模拟的虚拟用户就越多。
文档中规定，对于具有 512MB RAM 和一个 gig-e 接口的 PIV 2.4，其虚拟用户限制在 2,000 个左右，但这取决于所要测试的应用程序类型以及测试配置文件的设置。可改变测试的另一个因素是请求之间的延迟，WAPT 可以让您在虚拟用户配置文件中将其设置为用户所需时间。
一旦您完成了对虚拟用户配置文件的设置（您可以拥有许多按测试实行的方案），便可为该配置文件创建测试计划。WAPT 将测试顺序分为三个部分：初始、主要和最终操作。这更多是逻辑上而不是功能上的划分，举例来说，他们的确建议将登录或注册功能划分到初始部分中，而将注销操作划分到最终部分。WAPT 允许您手动输入请求，或使用集成浏览器记录器跟踪您希望此配置文件的用户如何在您的站点上冲浪。接下来，您可以转到常规设置，以确定用于此测试的负载以及您是希望将其固定还是在指定时间段内逐渐增加其负载量。在测试期间，通过 WAPT 您可以实时查看测试方案的性能统计。完成此操作后，您可以将结果保存为 HTML 或 CSV 以供将来查看。
价格：每台机器 350 美元。
了解您的最新版本 Web 应用程序执行状况，这对于正确调整基础结构大小，避免出现 CEO 质问您为什么她在查看站点时会得到“服务器太忙”的回应这样令人高度紧张的时刻而言，是至关重要的。而且，如果您在寻找一个相对费用较低、易于使用的 Web 应用程序压力和性能测试工具，则您可能想要查看 SoftLogica LLC 的 WAPT 4.0。
该应用程序运行在大多数版本的 Windows® 上，但是由于在早期版本上存在套接字限制，故您会希望使用 Windows 2000、Windows XP 或 Windows Server® 2003 来获得其全部潜能。与大多数使用虚拟用户的性能测试应用程序一样，拥有的内存越多，处理器速度越快，并且网络连接越丰富，您能够使用 WAPT 模拟的虚拟用户就越多。
WAPT Web 应用程序压力测试工具
WAPT Web 应用程序压力测试工具
文档中规定，对于具有 512MB RAM 和一个 gig-e 接口的 PIV 2.4，其虚拟用户限制在 2,000 个左右，但这取决于所要测试的应用程序类型以及测试配置文件的设置。可改变测试的另一个因素是请求之间的延迟，WAPT 可以让您在虚拟用户配置文件中将其设置为用户所需时间。
一旦您完成了对虚拟用户配置文件的设置（您可以拥有许多按测试实行的方案），便可为该配置文件创建测试计划。WAPT 将测试顺序分为三个部分：初始、主要和最终操作。这更多是逻辑上而不是功能上的划分，举例来说，他们的确建议将登录或注册功能划分到初始部分中，而将注销操作划分到最终部分。WAPT 允许您手动输入请求，或使用集成浏览器记录器跟踪您希望此配置文件的用户如何在您的站点上冲浪。接下来，您可以转到常规设置，以确定用于此测试的负载以及您是希望将其固定还是在指定时间段内逐渐增加其负载量。在测试期间，通过 WAPT 您可以实时查看测试方案的性能统计。完成此操作后，您可以将结果保存为 HTML 或 CSV 以供将来查看。
价格：每台机器 350 美元。

书评
《Content Networking Fundamentals》（内容联网基础知识）
www.ciscopress.com
内容为王，Silvano Da Ros 所著的《Content Networking Fundamentals》（内容联网基础知识）（Cisco Press，2006）可帮助您在增强内容传送基础结构的快速跟踪方面有所提高。该书标称自身为“对内容网络理论和实际应用的全面介绍”，事实上也的确如此。虽然该书明显偏爱 Cisco 的网络设备，但还是能够让您很好地了解内容网络的不同组件，以及实现内容网络的原则的实践指导（无论您的基础结构中内容网络为何类型，这些实践指导都适用）。
该书首先对内容网络的不同元素进行了高度概述（真正提高了 OSI 模型第 4 层到第 7 层通信中的性能和传送内容）。然后深入研究主要内容表示格式（例如 XML、HTML、WAP）的具体细节和通过 XSLT 在网络边缘进行内容转换以及流媒体传送部分。最后，转入可扩展性和可用性，讨论有关服务器负载平衡（全局以及局部）、防火墙负载平衡和内容缓存设备（例如 Cisco 的内容服务交换机）的使用。
如果您在基础结构中使用 Cisco 的内容服务交换机，您会发现关于交换安全内容一章比较吸引人。这一章将向您介绍配置安全套接字层内容服务模块以及配置 URL 和标题重写的详细内容。通常，任何忠于品牌的网络专业人员都会发现 QoS 一章有助于理解不同的排队机制和阻塞管理。
总之，虽然 Cisco 硬件的实施确实非常困难（毕竟，它是由 Cisco Press 发布的），但这本书将帮助您将术语“内容网络”转化成实际并可应用的方法，以用于内容传送基础结构。
价格：55.00 美元。

监视服务
WebWatchBot
www.exclamationsoft.com/webwatchbot/default.asp
有一件事情既能树立也能破坏 IT 专业人员的形象，那就是能否在组织的终端用户之前先检测到问题（并有可能进行修复）。因此，IT 专业人员可拥有的一个最重要的工具就是一个有效的监视系统，该系统可深入研究您所提供的不同服务，以便检验它们是否能正常运行。ExclamationSoft 的 WebWatchBot 可帮助您达到此目的。
此应用程序可以监视您能想到的每一项普通服务。WebWatchBot 并非只验证服务是否运行，它还将此过程加深一步。实际上，它将对服务进行测试以确保服务能正常发挥作用。例如，FTP 验证确实可以上载和下载文件，DNS 监视可以执行 40 个不同查询命令中的任何一个，并在响应中搜索字符串，而且 POP3 和 SMTP 测试确实登录并报告邮件性能。
WebWatchBot
此外，WebWatchBot 允许您链接事务中的一系列步骤，并将报告整个事务的任何错误或不可接受的延迟（根据您设置的阈值）。此应用程序还将监视 HTTP 和 HTTPS URL，并且可以检查指定内容。您甚至可以设置数据库监视，使之执行查询并对照标准响应来检查数据。
价格：每个单用户许可证 495.95 美元。

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


 Windows PowerShell: 简单命令。强大的管理能力
Windows PowerShell
简单命令。强大的管理能力
Don Jones
此专栏基于 Windows PowerShell 的预发布版本。文中的所有信息均可能会发生变更。

在经历了漫长的等待之后，Windows PowerShell 终于已蓄势待发。这意味着该是 Windows 管理员提起注意的时候了。Windows PowerShell 提供了也许是最简单且最灵活的方法来自动执行各种各样的管理任务，从而您的工作效率和效力都得到提高。
但更为重要的是，Microsoft 正在 Windows PowerShell™ 之上构建 Exchange Server 2007 和 System Center 2007 之类产品的图形管理控制台。这意味着您将能够从 Windows PowerShell 内部执行几乎所有的管理任务。随着时间的推移，Microsoft 计划提高越来越多产品的管理能力。因此，Windows PowerShell 最终会成为用于管理几乎任何 Microsoft 服务器产品的第一个全能型工具。为了帮助您尽快入门，我将在此新设的专栏中定期探讨 Windows PowerShell。请务必要下载一份软件。

强大而又简便的功能
顾名思义，Windows PowerShell 是一个外壳，但与从 Windows NT® 3.1 起就出现的命令提示符 (Cmd.exe) 不同。Cmd.exe 不会消失，但随着 Windows PowerShell 的到来，几乎没有什么理由再继续使用 Cmd.exe。
Windows PowerShell 在使用方面与 Cmd.exe 并无多大不同，只是 Windows PowerShell 的功能更为强大。与 Cmd.exe 一样，Windows PowerShell 具有内置的脚本编写语言，不过它比 Cmd.exe 原始的批处理语言更为灵活。灵活性是如何体现的呢？有了 Windows PowerShell，您可以使用仅包括大约半打内置关键字的语言自动执行极其复杂的任务。
既然我已提到了脚本编写，那么现在我可能就应该简单提一下安全性。Windows PowerShell 得益于 Microsoft 过去十多年在安全性方面所取得的研究成果。默认情况下，Windows PowerShell 不会运行脚本，只能交互式地用它来运行单个命令。如果您确实启用了脚本编写，则可令 Windows PowerShell 仅运行经过数字签名的脚本。这些均有助于确保 Windows PowerShell 不会成为下一个 VBScript — 一种伟大的语言，但它常被滥用来创建恶意脚本。VBScript 也不会退出历史舞台，但您可能会发现 Windows PowerShell 对于许多不同的任务来说更易于使用。
Cmd.exe 做到的事情，Windows PowerShell 几乎都能做到。例如，您可以运行 ipconfig 并且会获得同样熟悉的输出。但是 Windows PowerShell 会引入一整套新的命令，它们不是外部可执行文件。这些 cmdlet（发音为“command-let”）就内置于 Windows PowerShell 之中（要了解对 Windows PowerShell 使用入门最有用的 cmdlet，请参见侧栏的“快速使用入门十大 Cmdlet”）。
快速使用入门十大 Cmdlet
  • Get-Command 用于检索所有可用 cmdlet 的列表。
  • Get-Help 用于显示有关 cmdlet 和概念的帮助信息。
  • Get-WMIObject 用于通过 WMI 来检索管理信息。
  • Get-EventLog 用于检索 Windows 事件日志。
  • Get-Process 用于检索单个活动进程或活动进程的列表。
  • Get-Service 用于检索 Windows 服务。
  • Get-Content 用于读入文本文件，将每行视为一个子对象。
  • Add-Content 用于将内容附加到文本文件。
  • Copy-Item 用于复制文件、文件夹和其他对象。
  • Get-Acl 用于检索访问控制列表 (ACL)。
要获得 Windows PowerShell 自带的完整 cmdlet 列表，请访问 windowssdk.msdn.microsoft.com/en-us/library/ms714408.aspx。
所有 cmdlet 都以标准的“动词-名词”格式命名，这使其易于理解和记忆。例如，运行 Get-Command cmdlet 将会列出所有可用的 cmdlet。对于管理员来说最有用的 cmdlet 也许就是 Get-WMIObject。若您想要查明 Server2 正在运行哪个服务包，只需运行：
Get-WMIObject Win32_OperatingSystem –Property ServicePackMajorVersion
 –Computer Server2
要使用 VBScript 来发现同一信息，就得编写几行代码。利用 cmdlet 可以处理服务（Start-Service、Stop-Service 等）、进程（Stop-Process 等）、文件（例如，Rename-Item、Copy-Item、Remove-Item、Move-Item）等等。其中许多 cmdlet 甚至还有快捷名称，称为别名。对于 Get-WMIObject 而言，您可以只键入 gwmi。运行 Get-Alias 将为您提供这些快捷名称的列表。

为什么面向对象很重要
Windows PowerShell 在 Microsoft® .NET Framework 上构建，所以它完全是面向对象的。通常，只有软件开发人员才会对此感到兴奋，但是就本处的情况而言，面向对象可以为管理员节省大量的时间。这是因为管理员现在只需在基于文本的外壳内就能直接处理丰富的对象。请看以下示例：
Get-Process | Sort-Object pm –desc | Select-Object –first 10
这里只有一行，其中含有以管道分隔的三个不同的 cmdlet（稍后会对此进行详述）。第一个 cmdlet 检索所有正在运行的进程，然后将那些对象传递给或通过管道输送到 Sort-Object。第二个 cmdlet 基于每个进程对象的 pm（即物理内存）属性按降序对其进行排序。然后将进程对象的有序集合通过管道输送到 Select-Object，它将选取前十个对象进行显示。结果呢？此行简单命令会显示机器上的十大物理内存使用者，如图 1 所示。这是一种极其有效的方法，借此可在执行某些故障排除时进行快速浏览。
图 1 使用简单的 Cmdlet 进行故障排除
图 1 使用简单的 Cmdlet 进行故障排除
管道（在美式键盘上，该竖线字符通常位于反斜线按键上）的使用是 Windows PowerShell 具有如此能力不可或缺的组成部分。使用此字符，可以将对象从一个 cmdlet 传递（或通过管道输送）给另一个，从而使每个 cmdlet 可以进一步提炼结果、设置结果的显示格式，等等。之所以能够采用这种机制，是因为每个 cmdlet 均会返回一个或多个对象，而非纯文本，这就使得后续 cmdlet 可以处理完整的对象。
Windows PowerShell 中的对象使用非常普遍，这全都仰仗于它的变量。而且，您不必预先声明变量，只需在变量名称前放置一个美元符号 ($) 就可以开始使用它们了。尽管不是必需的，但您也可以将所要放入变量的数据类型告知 Windows PowerShell。这使得 Windows PowerShell 可以将变量映射到某一种极其强大的 .NET Framework 类型，从而为您提供诸多附加的内置功能。例如，假设您想要提示输入计算机名称并从该计算机中检索服务包版本，但是您不知道键入的计算机名称是否会包括两个反斜线（如 \\Server2）。由于您知道 Get-WMIObject cmdlet 不需要反斜线，因此您可以将计算机名称保存到一个字符串变量中，然后使用 Replace 方法以空字符串替换反斜线，如下所示：
[string]$c = Read-Host "Enter computer name"
$c = $c.Replace("\","")
    Get-WMIObject Win32_OperatingSystem
    –Property  ServicePackMajorVersion
    –Computer $c
已在 $c 变量中提供了 –Computer 参数的值。该变量最初是作为字符串而创建的，因此它具有 .NET Framework 字符串类型的所有功能，包括 Replace 方法。当然，要了解所有这些功能需要花费一些时间，但是通过示例您应该很容易就能掌握这些功能。Windows PowerShell 本身也有助于简化学习过程。例如，如果您键入 $c = $c.（不要忘了句号）并按 Tab，Windows PowerShell 将显示 Clone()，这是字符串类型的第一个方法。如果您一直按 Tab，Windows PowerShell 将会循环列出所有可用的方法。实质上，当您这样做时，Windows PowerShell 是在向您展示它所知道的字符串处理方法。
在此给出一项更难的任务。从文件中读取计算机名称的列表（每行一个名称）并显示每台计算机的服务包号。在 VBScript 中，此项任务将需要一打或更多行的代码。在 Cmd.exe 中，您就得使用复杂的批处理文件。在 Windows PowerShell 中，此项任务仅需一行：
Get-Content "c:\computers.txt" | foreach
{ $_; gwmi Win32_OperatingSystem -prop
ServicePackMajorVersion -comp $_ }
Get-Content cmdlet 读取 C:\Computers.txt 的内容。文件的每一行均自成一个对象。此对象集合（即，计算机名称）通过管道输送到 foreach 命令（它其实就是 ForEach-Object cmdlet 的别名）。花括号内的命令会对通过管道送入的每个对象重复一次（在本例中就意味着它们对每个计算机名称都要运行一次）。特殊的 $_ 变量将包含当前对象（即，当前的计算机名称）。
花括号内实际是两个命令：第一个只是通过输出 $_ 的内容来显示当前的计算机名称。第二个是现已熟悉的 gwmi。结果将显示文件中所列出的每台计算机的服务包版本列表。所有这些都是用相对简单的一行命令完成的。
请注意，–Property 和 –Computer 参数名已被缩写。Windows PowerShell 仅需有足够的信息即可唯一地区分参数名。

可读性与复用
然而，编写一行命令和参数无助于可读性。Windows PowerShell 允许您将其拆分成更具可读性的形式，您甚至不用编写脚本就能将其直接键入外壳。这就是它可能的形式：
PS C:\> $names = get-content "c:\computers.txt"
PS C:\> foreach ($name in $names) {
>> $name
>> gwmi Win32_OperatingSystem -prop ServicePackMajorVersion -comp $name
>> }
>>
这一次，文件的内容存储在变量 $names 中。本例仍使用了 foreach，但它不是通过管道进行输入的，因此必须告知它需要循环处理哪个对象集合以及将每个对象存储在哪个变量中，即 ($name in $names) 所指明的那一部分。其他方面大体相同，只要您一按 Enter，就会执行代码并显示结果。
如果要重复使用此同一代码，只需将其制成函数即可。再次将以下内容直接键入到外壳中：
PS C:\> function Get-ServicePacks ($file) {
>> $names = get-content $file
>> foreach ($name in $names) {
>> $name
>> gwmi win32_operatingsystem -prop servicepackmajorversion -comp $name
>> }
>> }
>>
如您所见，实际上并未做太多更改。只需将上一示例封入一个名为 Get-ServicePacks（与 Windows PowerShell 的“动词-名词”命名惯例保持一致）的函数即可。该函数现在具有一个名为 $file 的输入参数，该参数在 Get-Content cmdlet 中已被取代，这样便可在运行函数时指定另一不同的文件。至此已定义了函数，运行它很简单，方法几乎与 cmdlet 一样，只需调用其名称并传递输入参数即可：
PS C:\> Get-ServicePacks c:\computers.txt
图 2 显示了结果。
其缺点在于此函数仅在该 Windows PowerShell 实例运行期间才存在。一旦关闭外壳，该函数即会消失。您可以将该函数复制到您的 Windows PowerShell 配置文件中，该配置文件是一种自动运行的脚本，它会在 Windows PowerShell 每次启动时执行。这样做就使该函数在打开的每个 Windows PowerShell 窗口中均可用。或者，如果需要，也可将该函数做成独立的脚本，然后只需键入其路径和文件名即可执行该脚本。
图 2 运行 Get-ServicePacks 函数的结果
图 2 运行 Get-ServicePacks 函数的结果

一切尽在于文件（或文件夹）
Windows PowerShell 决不只有函数和 cmdlet。让我们以文件管理为例来快速了解一下其中还蕴藏着什么别的内容。您可能对 Cmd.exe 中的驱动器和文件夹导航再熟悉不过了 — 键入 C: 可切换到 C 驱动器，键入 cd \test 可转入 C:\Test 文件夹。Windows PowerShell 的工作方式完全相同，不过 cd 只是 Set-Location cmdlet 的别名。
尝试运行 Get-PSDrive，该 cmdlet 会列出所有可用的驱动器。除了常用的 C:、D:（也许还有 A:）驱动器之外，您还会发现一个名为 Cert 的驱动器、另一个名为 Env 的驱动器以及其他名为 HKCU 和 HKLM 的驱动器。实际上，Windows PowerShell 将许多不同类型的存储资源均以“驱动器”形式公开，从而使得诸如本地证书存储区、环境变量和注册表等资源均可通过一个象文件那样为大家所熟悉的导航界面来获得。
键入 Set-Location HKLM:（或 cd hklm:，如果您喜欢使用快捷方式）而后按 Enter，可转到 HKEY_LOCAL_MACHINE 注册表配置单元。如果要删除某个表项，可使用 del 将其删除，就像该表项是文件或文件夹一样（不过一定要非常小心，如果删除了必需的表项或是对注册表进行了不正确地修改，可能会发生严重问题）。
这一切灵活性均来自于提供程序，它们将资源（如注册表和证书存储区）映射成类似于文件系统那样的格式。Microsoft 计划通过另外的提供程序来扩展 Windows PowerShell，例如，使您能够导航 Exchange Server 存储区，就像它是文件系统一样。这是一项非常重要的技术，重要性就在于它吸纳了 Windows 所使用的林林总总的存储库并使它们看起来全都相同，而且还使得它们都可以通过您已熟悉的命令和技术系统来进行管理。

安全性设计
我已提到过 Windows PowerShell 在设计时很注重安全保护。Windows PowerShell 中主要的安全功能是它的执行策略。默认情况下，此策略设置为“Restricted”，您可以通过运行 Get-ExecutionPolicy cmdlet 来进行验证。在 Restricted 模式下，不能运行脚本。就这么简单。由于这是默认模式，因此刚出盒的 Windows PowerShell 不能用来运行脚本。
您可以使用 Set-ExecutionPolicy cmdlet 指定其他模式。我个人更偏爱 RemoteSigned 模式。在此模式下，可以运行未经数字签名的本地脚本（而非远程脚本），同时能够以最简单的方法开发和测试脚本。除非已使用受信任发布方所颁发的证书对脚本进行了数字签名，否则 AllSigned 模式不会运行任何脚本。最后，采用 Unrestricted 策略可运行任何脚本。我建议切莫采用此策略，因为以此方式打开的 Windows PowerShell 会运行可能伺机找上您计算机的恶意脚本。请注意，执行策略也可能受组策略支配，它会替代所有本地设置（如果组策略设置正要替代您的本地设置，Set-ExecutionPolicy 会向您发出警告）。
另外，Windows PowerShell 不会从当前目录运行脚本，除非您指定了该路径。这样设计是为了防止命令攻击。比如，某人创建了一个名为 IPConfig.ps1 的脚本（PS1 是 Windows PowerShell 脚本文件的文件扩展名）。如果文件可在当前文件夹之外运行，则您可能会键入 ipconfig 而运行此用户所创建的脚本，可当时您其实是希望运行 Windows 程序 Ipconfig.exe，这样就带来了风险。由于 Windows PowerShell 不会在当前文件夹之外运行脚本，所以这种错误不可能发生。如果您的确想在当前文件夹之外运行脚本，只需指定路径即可：例如 .\myscript。对当前文件夹的显式引用确保您知道自己正在运行脚本，而非外壳命令。
Windows PowerShell 还具有使实验变得更加安全的功能。例如，请考虑（但请勿尝试）这个令人害怕的组合：
Get-Process | Stop-Process
Get-Process cmdlet 会创建进程对象的集合并通过管道将其输送到 Stop-Process cmdlet，而后者真的会将它们停止！这会导致在大约 5 秒钟后出现蓝屏 STOP 错误，原因是终止了关键的 Windows 进程。但是，您可以通过添加非常方便的 –Whatif 参数来看看将会发生什么情况，而不会令其真的发生：
Get-process | Stop-Process -Whatif
在 Windows PowerShell 中运行此命令会产生一组语句，它们会告诉您 cmdlet 将会做什么，而不会真的让它们这样做。Windows PowerShell 中的在线帮助系统（可通过 help 别名访问）尚未记载 –Whatif 参数，但请记住它。它是一个很好的工具，用于测试脚本和 cmdlet 以检验其结果，而不会实际做出任何具有潜在危害性和破坏性的事情。

总结
在没有加入此 Windows PowerShell 版本的功能中，最重要的也许就是对 Active Directory® 服务接口 (ADSI) 的支持。尽管 Windows PowerShell 可以利用与 Active Directory 和其他目录服务配合工作的功能非常强大的 .NET 类，但它尚没有一个方便的 Get-ADSIObject cmdlet。这就给处理目录对象带来一点困难。
此外，Windows PowerShell 通常提供了多种不同的方法来执行同一任务。这样很好，但可能会令人在学习 Windows PowerShell 时变得更加迷惑，因为对于任何给定的任务，您可能都会看到半打不同的处理方法示例。
随着时间的推移，一切都会得到解决，Windows PowerShell 团队将会继续为产品增添更多的特色和功能。要想一直成为圈内人，请访问该团队的博客。

Don Jones 是 ScriptingAnswers.com 的创始人，《Windows PowerShell:TFM》（SAPIEN Press，2006）的合著者。请通过 don@scriptinganswers.com 与他联系。


 Post Mortem: 从 Exchange 5.5 迁移
Post Mortem
从 Exchange 5.5 迁移
Whitney Roberts

项目
肯塔基州教育局需要将其现有的 Microsoft® Exchange Server 5.5 实现迁移到 Exchange Server 2003。其系统在每个学年大约要为 600,000 名教职员工和学生提供支持。
参与方
此项目由肯塔基州教育局的“教育技术办公室”(OET) 负责，KiZAN Technologies 的顾问给予协助。OET 工作人员一直在对现有 Exchange 5.5 实现进行管理监督。Exchange 服务器的日常运行则由该学区的本地工作人员负责。
面临的难题
该教育局为肯塔基州全部 178 个学区提供技术指导。这些学区彼此通过 WAN 相连接，但每个学区都托管其自己的本地受管 Exchange 5.5 服务器，这些服务器需要分别升级。经过这次升级，系统应支持 Outlook® 2003 缓存模式客户机、改进的 Outlook Web Access (OWA) 体验、标准化的电子邮件寻址方案等等。
除了部署新的电子邮件服务器和客户机基础结构外，许多学区要增加对学生电子邮件的支持功能。州和联邦都有政策要求对学生信息加以保护，不允许将这些信息提供给各自学区外的其他学区。
计划
由于不能使用 Active Directory® Connector (ADC)，我们创建了一个新的 Exchange 组织并迁移到其中。实现电子邮件地址标准化就意味着要为各学区创建新的标识子域以及 400 多个新的收件人策略。要保护学生地址，需要构建由“全局地址列表”(GAL) 和各学区自定义地址列表组成的体系。
实际的迁移过程包括搭建新硬件、根据学区成员身份和用户类型创建并配置邮箱，以及根据学区成员身份和用户类型设置扩展属性，使用户出现在相应的地址列表中。
我们创建了一个基于 Visual Basic® 的应用程序，用以检测和更正配置不当的帐户属性或组成员身份，并正确置备新邮箱以确保维持可见性需求。此应用程序已部署到全部 178 个学区并正在学区的服务器上定期运行。

背景
表面上看，这似乎并不是一项很复杂或技术难度很高的工作。但有人曾善意地提醒过我，业务需求决定一切，而这个项目的业务需求真的是令人瞠目结舌。
多年来，分散式的管理和纷繁混杂的各种标准造成了众多的支持“真空区”，这些“真空区”常常需要由 OET 来进行管理。此外，OET 还必须确保 Exchange 5.5 实现能同时满足学区和教育局的需求。也就是说，对于引入了学生电子邮件的学区，要按州和联邦指导方针（请参见 ed.gov/policy/gen/guid/fpco/ferpa/index.html）的规定来保护学生信息，不允许将这些信息提供给各自学区外的其他学区。
在 Exchange 5.5 中，这些指导方针意味着学区内的学生信息不能复制到共享 GAL 数据的其他学区或其他州管理机构。具体来说，这就需要全部 178 个 Exchange 5.5 站点都经历一个手动的导出/导入过程：即隐藏学生，复制列表，取消隐藏学生，最后导回地址列表。通过这种方式，其他学区只能看到教工数据。本学区可以看到自己的所有数据，但只能看到其他学区的教工数据。
考虑到现有系统的优缺点，消息基础结构的升级必须满足一些具体的条件。首先，肯塔基州教育局需要在一个可读的公用 SMTP 命名方案基础上、在整个企业范围内实现标准化。这一方案需要为教工和学生提供独立的 SMTP 地址空间。
新系统还需要提供一种集中管理的服务，使学区从消息管理与可用性职责中解脱出来。也就是说，灾难恢复、邮件流和支持人员呼叫解决方案都将采用集中式的管理。这样一来，新系统就必须提供一种集中式的方法来跨所有学区实现用户配置的标准化，而无论给定用户的地理位置或学区关系如何。
此外，新系统还必须跨一个公用的统一命名空间针对所有学区提供基于 Web 和移动设备的安全电子邮件访问。
鉴于这些需求（其中许多需求在现有的 Exchange 5.5 系统中尚未实现），Exchange 2003 的升级工作真的令人望而却步。

解决方案组块
为了满足这些业务需求，我们确定了几种专门针对 Exchange 的部署方案。
由于缺乏标准化以及 Exchange 5.5 环境容量巨大，因而不能使用 ADC。因此，我们转而创建了一个新的 Exchange 组织并迁移到其中。
为了清理各学区教工和学生的电子邮件地址并实现标准化，我们创建了 400 多个新的收件人策略。此外，还根据需求为各学区建立了一个唯一的标识子域，其中包括学生的标识学区标志。例如，就 Shelby 县而言，主要子域为 shelby.kyschools.us。各学区的学生都有一个 stu. 子域标志，因此 Shelby 县学生的电子邮件地址为 stu.shelby.kyschools.us。
另一个限制条件是学生地址只能供其所在学区使用，而教工地址可跨学区使用。这意味着要构建由 GAL 和自定义地址列表组成的一套完善体系，如图 1 和图 2 中所示。迁移到 Exchange 2003 的一个好处是可以通过权限来保证地址列表的安全，通过组成员身份来控制对各地址列表的访问。我们很好地利用了这一特点，创建了两个学区级安全组（一个用于教工，一个用于学生），并为学区教工和学生 GAL 及地址列表制定了相应的安全措施，只允许特定学区内的用户帐户访问某些地址列表。删除默认 GAL 和地址列表并确保“每个人”和“通过身份验证的用户”组不在各地址列表的访问控制列表 (ACL) 中出现后，我们可以预先选择特定学区中特定用户类型能够查看的地址列表。
图 1 基于角色的自定义地址列表
图 1 基于角色的自定义地址列表
然而，权限只是部分地解决了可见性问题。我们必须提供一种方法来控制在不同地址列表中哪些内容是可见的。为此，我们创建了一个基本“轻量目录访问协议”(LDAP) 查询，用以查询教工和学生的可见性；然后针对各地址列表和 GAL 对该查询稍加定制。例如，针对 Shelby 教工 GAL 的 LDAP 查询将只显示 Shelby 学区相应的教工和学生以及本州各其他学区的所有教工（但不包括学生）。而针对 Shelby 学生 GAL 的 LDAP 查询将只显示 Shelby 学区的教工和学生，并不显示本州任何其他学区的其他教工和学生。我们为该组织中的所有学区重复使用这一查询。图 3 显示了在这次复杂的迁移中所使用的一些 LDAP 查询示例。
Figure 3 地址列表 LDAP 查询 (Close Figure 3)

教工 GAL LDAP 查询
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
学区地址列表 LDAP 查询
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=15)))))
学区学生地址列表 LDAP 查询
(&(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(&(extensionattribute14=<districtNumber>)(extensionattribute15=20)))))
学区教工脱机地址列表 LDAP 查询
(&(&(objectCategory=*)(mailnickname=*)
(!objectCategory=ExchangeAdminService)(!objectCategory=msExchPublicMDB)
(|(extensionattribute15=15)(&(extensionattribute14=<districtNumber>)
(extensionattribute15=20))(&(extensionattribute14=<districtNumber>)
(extensionattribute15=14)))))
图 2 将教工与学生相隔离的全局地址列表
图 2 将教工与学生相隔离的全局地址列表
Exchange 用户属性 extensionAttribute14（自定义属性 14）和 extensionAttribute15（自定义属性 15）的自定义值是 LDAP 查询背后的区分机制。对于全州的所有教工和学生而言，其 extensionAttribute14 属性包含用于指定用户类型的特定值，extensionAttribute15 属性包含用于显示学区关系的唯一值。各学区都有唯一的学区标识值，每个用户类型又对应相同的值，这样，地址列表就可以准确地显示各学区各用户类型的所需信息。
当用户通过非缓存模式下的 Outlook 或通过 OWA 访问电子邮件时，这些地址列表的效果非常好。（我们使用 msExchQueryBaseDN 属性将各用户引向 OWA 中的正确地址列表。）但在缓存模式下运行 Outlook 的用户却面临着另外一个问题。由于 Outlook 不会将自定义的 GAL 视为指定的“脱机通讯簿”(OAB)，我们不得不创建了与 GAL 一样的附加地址列表。然后对各学区邮箱存储进行配置，使缓存模式用户使用相应的 OAB 地址列表。总而言之，这一解决方案创建了 1,500 多个地址列表，来为全部 178 个学区各种类型的用户提供完整的功能。

确保遵从性
为确保已经实现的结构能够正常工作，首要的一点是遵从新建立的各项标准。对于组织中每个启用了 Exchange 的用户，必须执行一些高级别的任务。这是因为必须要跨所有学区的 Exchange 服务器对每个用户正确定位，每个用户的信息也必须出现在正确的地址列表中。
用户必须是学区域内适当安全组的成员，因为安全组负责授予权限来打开相应地址列表。此外，还必须根据学区和组织单位 (OU) 成员身份正确设置用户的 msExchQuerybaseDN 属性。用户的 OU 决定了用户类型。
下一步是根据学区成员身份和用户类型在适当服务器上的正确存储库中建立用户邮箱。这一工作影响着服务级别、邮箱大小限制及脱机通讯簿地址列表，这样一来 Outlook 缓存模式就能够正常工作了。扩展属性基于学区成员身份和用户类型而设置，这样用户可以显示在适当的地址列表中，而在其他列表中则不出现。
最后，我们需要提供一种更正方法。如果有任何帐户的属性或组成员身份被误配置（或更改）为不适当值，这一方法可以自动进行更正。如果用户在学区的域内从一个 OU 转移到另一个，这意味着用户分类发生了变化，必须更新邮箱位置、GAL 选择及地址列表可见性。
我们需要一种置备系统，用来完成这些任务并确保 Active Directory 的一致性和精确性。于是，我们基于 Visual Basic 创建了一个基于控制台的应用程序，可以从学区 Exchange 2003 服务器上定期运行该应用程序，来检查对策略和标准的遵从性并处理新对象的创建和置备，我们将该程序部署到全部 178 个学区。
我们觉得当前的任务过于复杂，很难通过一系列脚本快速可靠地执行。因此，鉴于该基于 Visual Basic 的应用程序效率较高，具有结构化的错误和异常处理支持，而且其内部代码只需最小量的重新编写工作即可轻松适应于将来的 Microsoft Identity Integration Server (MIIS) 扩展代码，因此可视为适合于上述问题的解决方案。
我们要迁移到新组织，所以必须找到一些共存方法。新环境要支持超过 178 个遗留 SMTP 域（有些学区先前有学生电子邮件域，有些则没有），但我们奢侈地逐个迁移每个学区并将其遗留邮件和地址传递到新系统中，而不影响其他学区。然而，我们需要避免学区在从 Exchange 5.5 迁移到 Exchange 2003 时出现电子邮件流中断。这意味着要在 Exchange 2003 Active Directory 和遗留 Exchange 5.5 目录之间实现某种类型的目录同步。Microsoft 在迁移期间只授予肯塔基州教育局有限的 MIIS 使用权限，于是我们开发出了自定义的扩展代码，用来在迁移前、迁移期间和迁移后通过 MIIS 实现两个 Exchange 组织的同步。
移动到新的 Exchange 组织自然就会影响 MAPI 客户机配置。教育局面临这样一个事实：迁移期间在学区级差不多有上万个 MAPI 配置文件必须重新配置。幸运的是，Microsoft 发布了 Exchange Profile Tool (ExProfRe.exe)，学区一级配置文件的迁移就是通过这个工具实现的。我们创建了一个打包的安装程序，它以预加载的值运行 ExProfRe.exe，使学区级配置文件的迁移可以自动执行。该程序通过“组策略”调用。我们这项组织间配置文件自动迁移工作的成功率接近百分之百。

硬件升级
由于新的 Exchange 2003 服务器将取代分散在各地的 Exchange 5.5 服务器，所以从硬件方面来说，此解决方案必须与 Exchange 5.5 部署支持相同数目的用户，再加上新增的学生帐户。服务器必须由学区当地托管，因为根据 WAN 拓扑结构的设计，所有学区间流量（Internet 和内部）都通过一条专用 T1 线路（某些学区中为多条 T1 线路）流过。
由于在预算、管理及设备托管等方面的限制，Exchange 服务器不能有通过存储区域网络 (SAN) 附加的存储器，因此所有存储器必须是内部存储器或直接附加的存储器。因为多数学区没有带机架存储器和中央冷却设备的数据中心，所以服务器必须尽可能自给自足。幸而对于多数学区而言，其用户数少于 5,000，因此可以实现单服务器部署。用户较多的学区使用了更为强大的服务器（或多个服务器）及额外的存储器，有的还配有单独的前端服务器，进一步将学生与教工的流量相隔离。
在大多数学区中，我们部署了装备精良的双处理器服务器，这些服务器配置了最大数目的 15,000 RPM Ultra320 SCSI 驱动器、多个 RAID 控制器及 4GB RAM。更大的学区部署了一个或多个四处理器服务器，根据需要使用了更小的前端服务器。部署前的基准和性能测试结果表示系统不存在使用率或负载问题。而不同程度的本地使用模式将是服务器整体性能的真正决定因素。

概念证明测试
尽管此生产环境包括一个由 178 个域组成的 Active Directory 林，但概念证明 (POC) 实验室将这一环境缩减到 13 个学区域和一个空的根域。所有测试域都由从生产域导出的数据填充。虚拟 Exchange 5.5 服务器基于所选学区数据库的副本进行构建和配置，以便我们能够在计划环境之外测试迁移过程并进行构建。整个 POC 测试实验室由虚拟机构建，所以环境可以基线化、冻结，也可以根据需要重新部署。
我们设计、编码、测试并最终确定了各种脚本（使用 VBScript）、Systems Management Server (SMS) 安装程序包和控制台应用程序。最后，我们确定了执行初始 Exchange 2003 安装和配置（包括收件人策略、GAL 和自定义地址列表及权限）的脚本。此外，还通过脚本来处理迁移中所涉及的管理组配置、学区域配置（安全组创建和权限委派）及部署后配置。
Exchange 2003 服务器的搭建工作遇到了一些重大的难题。我们需要在所有 178 个域中成功地安装全部 Exchange 服务器，而且在安装时不能危及迁移工作的其他部分。Exchange 2003 不同于 Exchange 2000 的一点是，直到域中安装第一个 Exchange 2003 服务器后，特定于域的 Exchange Domain Servers 组才会添加到组织的 ACL 中。（而在 Exchange 2000 中，该组是在运行 DomainPrep 进程时添加的。）为确保 Active Directory 的组织对象中能列出所有必要的安全组，我们不得不先在一个给定域中安装，然后手动将 Active Directory 从该域复制到 Active Directory 复制中心站点，再将该复制拖动到要安装的下一学区。只有在确认组织对象上的 ACL 拥有来自前一学区的 Exchange Domain Servers 组后，才能安全地开始下一学区的安装工作。即使这一过程只在一个域中没有按正常顺序完成，该学区也都至少必须进行重新安装，否则其他学区将不能进行学区间通信，这是因为组织对象 ACL 不能正确列出所有其他学区。
我们对整个部署、配置、服务器搭建和迁移进行了多次测试，直至我们确信这一过程在 POC 环境中运行良好。

迁移与不断出现的难题
项目团队批准了这些 POC 过程和结果后，即准备开始进行迁移。OET 选择首先进行自身的迁移，这样他们可以亲身体验这一过程及之后的效果。迁移时，所有服务器均已搭建，初始环境已经验证完毕。所有前端协议服务器和邮箱服务器均已就绪，准备投入生产供用户使用。
我们的这一迁移计划执行得相当顺利，经过 21 小时服务器间的内容传输后，OET 在 Exchange 2003 上启动并正常运行。很幸运，Outlook 配置文件在从 Exchange 5.5 迁移到 Exchange 2003 时没有出现重大的问题。我们加入了一个批处理文件，它根据一些简单的逻辑来以不同的配置调用 ExProfRe.exe。然后，我们将该批处理文件和 ExProfRe.exe 发布到各学区中域控制器 (DC) 的 Netlogon 共享区，并使用“组策略”在迁移结束时针对所有客户机运行该批处理文件。这一过程在 OET 运行良好，我们确信在后面的迁移过程中也会成功实现。
此时，相关人员又根据 OET 部署的体验对迁移计划重新进行了审核和批准。在接下来的迁移中，我们选择六个学区作为首批生产站点。在各学区进行迁移前，MIIS 从 Exchange 5.5 中读取有关学区邮箱的最新信息并更新学区域中的相应用户。我们使用“Exchange 迁移向导”(Mailmig.exe) 来实际地在组织之间转移邮箱数据。在向导转移邮箱数据时，所有代理地址会从 MIIS 最初所导出的部分移动并更新到 Active Directory 中。在迁移期间，邮件在前端 SMTP 服务器上排队，然后在迁移、迁移后服务器配置和用户测试完成后发布给学区；学区准备使用 ExProfRe.exe 来执行大规模的客户端迁移。

赢得 RUS
为使 Outlook 客户端正常工作，我们需要确保置备解决方案在设置属性值方面具有绝对的权威性。我们也需要“收件人更新服务”(RUS) 来完成帐户设置工作；但 RUS 只应在置备完成后运行。为此，学区（所有 178 个学区）的 RUS 实例设置为“永不”根据其时间表运行，而置备解决方案使用了用于在置备完成后触发 RUS 的代码。
对于大多数学区而言，其用户数少于 5,000，而日常的更新量更是少之又少，再加上置备系统会在日常运行结束后触发更新工作（而不是重建），因此 RUS 很快就完成了。但有些学区的用户数超过了 10,000。在这样的环境中进行更新要费时得多，如果需要在这些大型的域中完全重建 RUS，可能要花费一周甚至更长的时间。由于 RUS 在运行时会评估所有对象类型，因此在这类大型域中进行重建将是一个极其漫长的过程。
虽然我们无法提出一个迁移策略（我们曾与 Exchange 产品小组的成员一起研究，试图提出一个解决方案），但我们增强了置备代码，使它可以处理许多通常由 RUS 执行的工作。一旦初始置备结束，就会填充用户的 showInAddressBook 和 proxyAddresses 属性，使用户无需等待 RUS 完成其工作即可立即登录。我们还创建了在其中一个前端 Exchange 2003 协议服务器上运行的手动任务。它定期执行 LDIFDE 导入并清除 RUS 网关代理地址，这样一来，如果某个收件人策略在环境中只是偶然被应用，它就不会被放入企业每个 RUS 的任务列表中。

分类程序问题
就避免学生数据泄露到学区外而言，一个令人关注的方面是通过实施控制来防止学生向本学区外的用户或者本系统外的 Internet 地址发送电子邮件。我们没有采用由连接器和相关项组成的完善系统，而是决定实现 Exchange 2003 一个鲜为人知的功能，并对学区与前端协议服务器所在中央集线器之间的现有“路由组连接器”施以连接器限制。在每个域中创建两个安全组（一个用于教工，一个用于学生），并将这些组添加到连接器限制中。
在注册表中启用连接器限制检查功能后，我们开始注意到一些显著的性能下降问题。各种邮件会在分类程序和本地传送队列中阻塞数小时，即使是要发送给同一服务器上收件人的邮件也是如此。随着时间的推移，当越来越多的学区完成迁移时，这些问题越来越严重。作为一个短期的解决方案，我们关闭了连接器限制检查功能，结果邮件传送的性能有所提高。进一步的检查表明，分类程序不仅会在邮件提交后检查自身域中两个组的组成员身份，而且还会检查其他 177 个域中相同两个组的组成员身份。对于进出服务器的每封邮件都是如此。
我们随后与 Microsoft 启动了一个支持案例。Microsoft 在进行评估后，目前正在生成一个修补程序，希望通过允许分类程序在拓扑结构复杂性更低的模式下工作，来缓解这一问题。直至发稿时，我们尚未得到有关修补程序的进一步信息，但这一程序的宗旨是提供一种设置，来允许分类程序对路由拓扑结构进行某些假设，从而不会跨所有连接器来检查组成员身份。

经验教训
如果说通过这个项目我学到一些经验教训的话，那就是对我们这些技术顾问而言，业务需求决定一切。很多时候，我们必须在业务需求的可行性和解决方案的复杂性之间进行权衡。我在本栏目中介绍的各种决策和选择都是我们认为最适合于我们的特定环境（包括我没来得及在此讨论的要素）、资源及业务需求的决策和选择。对于您而言，可能有不同的决策，但希望本栏目能给您一些启示。幸而对于我们，Exchange 2003 和 Active Directory 提供了足够的灵活性来满足这次复杂的迁移工作的所有需求。一旦解决了肯塔基州教育局部署项目最为棘手的规模问题，实际的解决方案就相当简单了，它基于 Active Directory 和 Exchange 2003 中我认为未被充分利用的功能而构建。
第二个宝贵的经验教训是，采用一种平稳的方法来实施故障排除和风险/问题管理。有时候应当在本地实施故障排除，而有时候则需要求助于 Microsoft 产品支持服务的高级资源。

展望未来
肯塔基州教育局的环境的确是独一无二的。在这次的部署过程中，我们几乎利用或定制了 Exchange 中的每项功能来满足其需求。目前整个环境已部署和迁移成功，进入实现附加功能的阶段。教育局已经看到 Windows Mobile® 平台对于学区所能带来的益处，并希望继续发展移动设备。
通过服务器合并可以获得巨大的价值。肯塔基州教育局当前正在考虑将 Active Directory 环境的某些方面虚拟化。随着 Exchange 2007 的即将推出，教育局已经开始考虑其消息系统的升级需求。
肯塔基州教育局也在考虑引入 Live Communication Server、Live Meeting Server 等工具中其他的协作功能。Microsoft Operations Manager 2005 当前也正在部署之中，准备用它来管理并监控 Exchange 和 Active Directory 服务器。

结果
这次实现的质量和普及率将影响肯塔基州公立学校体系中的每个孩子，包括我自己的孩子和这个项目中我同事的孩子。这次实现通过各种技术使肯塔基州教育局以前所未有的速度、以安全和标准化的方式获得了长足的发展。能参与这次的项目，我深感荣幸。

Whitney Roberts 是 KiZAN Technologies (www.kizan.com) 的首席顾问，从 Exchange 4.0 版起就一直在致力于 Exchange 方面的工作。


 SQL 问题与解答: 防止重新启动、安装多个更新及其他内容
SQL 问题与解答
防止重新启动、安装多个更新及其他内容
编辑：Nancy Michell

防止重新启动

问：将修补程序和类似程序应用到 SQL Server 甚至是更普遍意义的服务器操作系统时，如何限制重新启动的次数？

答：首先，您可能有兴趣知道大部分安装后的重新启动并没有硬编码到安装程序中。它们通常是锁定文件导致的结果。也就是说，安装程序会试图更新一些当前被其他应用程序或操作系统在使用的（锁定的）文件。有一种直接的办法可消除这些重新启动，就是确保没有进程正在使用上述的文件。怎么办呢？
首先是确定安装期间被使用或锁定的具体文件。最简单的方法就是在注册表 HKLM\system\currentcontrolset\control\sessionmanager\pendingfilerenameoperations 中查找它们。查看该注册表项有两个目的：通过它可确认重新启动请求确实是由锁定文件引起的，并且它会告知您哪些文件被锁定。如果您在安装后、重新启动之前查找这些文件，您就可能找出导致重新启动的原因，并在将来的安装过程中采取措施来消除重新启动。
您可能会发现两种类型的条目。如果某个文件被读锁定，您将看见每文件一行形式的条目，表示更新的文件已存在于磁盘上，不过您需要清除仍在使用的临时副本。如果文件被写锁定，您将看见每文件两行形式的条目，表示更新尚未发生，应用程序处于未知状态，尚不可以使用。应用程序就像是停留在安装过程中。若是如此，一行代表实际文件，另一行指向临时文件（将在重新启动后变成实际文件）。
下一步骤取决于多种因素，不过中心就是确定当前在使用锁定文件的软件。请使用依赖关系检查程序（如果条件许可）或者 MSDN® 上的 DLL HELP 数据库（参阅 support.microsoft.com/kb/815065）。
如果您识别的软件有一项服务，请手动停止该服务后再进行测试。如果是应用程序，则将其关闭，然后再试。有时会是多个应用程序在同时使用同一个文件，则需要停止所有的这些程序。
这些测试（在您的测试环境中）的结果就是安装前要在生产环境中停止的应用程序以及服务的列表。从而生产环境将不会要求重新启动，因为没有什么软件将会锁定安装程序正在安装的文件。当然，别忘了在安装完成后重新启动那些应用程序与服务。
让人高兴的是这些锁定通常不会有多大变化。因此，您只要对您的系统成功进行过一次这样的操作，就可能能够在系统的整个生存期内避免许多次的重新启动。
还有一个技巧值得一提。您可能同时安装了多个版本的 SQL Server™ 或其他的产品，且它们可能甚至属于不同的版本级别。您应总是首先更新最新版本。大多数情况下，更新将用最新版本替换一切，从而所有其他实例将不用关心是否有锁定。例如，如果您有三个 SQL Server 2000 SP3 实例，您升级到 SP4 的第一个实例将会升级 MSXML3.dll 文件且需要重新启动。假定您执行了重新启动。然后，您就可以将后两个实例升级到 SP4 而无需重新启动，因为更新的 MSXML3.dll 文件已经存在。对于在升级 SQL Server 2000 实例之前升级任何 SQL Server 2005 实例以及在升级 SQL Server 7.0 实例之前升级 SQL Server 2000 来说同样如此。这是个确实行之有效的常规最少次数重新启动策略。
总体来说，Microsoft 开发团队做了许多的工作来停止或限制许多情况下的重新启动次数。既然本文是 SQL 问题与解答专栏，就让我们以 SQL Server 为例。
在 SQL Server 2005 中，SQL Server 团队将 SQL Server 必需的 Microsoft® 数据访问组件 (MDAC) 代码分离到 SQLNCLI（新文件）中以取代更新 MDAC 本身，并将 MDAC 移回与操作系统结合。这有什么用呢？Windows® 操作系统本身将使用 MDAC 并锁定这些文件。这就是大多数 SQL Server 服务包和其他包总是需要您重新启动的原因。现在，SQL Server 可以不触及操作系统使用中的 MDAC 文件来更新其 MDAC 版本，因此就不需要重新启动。
此外，现在还在 SQL Server 2005 SP1 安装程序中内置了一个依赖关系检查程序和中断。这可以向您显示被锁定的对象以及可能锁定该对象的程序或服务，从而您有机会当时就停止执行锁定的对象并继续安装，而无需重新启动。它意味着您可以实时解决该问题而不需要进行更多的测试。当然，如果您选择无人参与模式或者正在此模式下运行，则您总是可以选择继续并重新启动。只是您将注意到该功能对于找出锁定您的文件的对象是如此的简单！
此外，Microsoft Installer 技术还能够更有效地处理现有的 PendingFileRenameOperations (PFR)。您可能会想起，只要有文件出现在我们先前讨论过的注册表项中，SQL Server 2000 安装就将受阻。SQL Server 2005 安装很智能，只有在这些文件是属于 SQL Server 时（表示可能会有冲突）它才会受阻，甚至出现如是情况，它也经常能找到 PFR 项并直接进行更新而无需重新启动。MSI 和 update.exe 都不同程度的包含了该技术，它们是用于执行所有更新的现行标准的 Microsoft 安装程序。
哪些是已知会导致重新启动的因素呢？MSXML3.dll 是最主要的原因之一。该文件总是被 Windows SVCHost 服务锁定，因此任何包括该服务的程序都必须要重新启动。此外，该文件还存在于大部分的 MDAC 堆栈 (mdac_typ.exe) 中。幸好，MDAC“集成到”了 Windows Server® 2003 和 Windows XP SP2 及后续版本中。SQL Server 开发团队做了许多杰出的工作来分离 msxmlsql.dll，使得 SQL Server 更新不会导致重新启动，不过您暂时偶尔还是能看到这种情况发生。对于它，您无能为力 - 您不能关闭 SVCHost 而继续运行更新。
同样，update.exe 软件包的卸载过程有点古怪。如果卸载该程序，它将会锁定（当然，在 PFR 项外部）安装程序的预备文件。从而阻止其他 update.exe 软件包运行，直到您重新启动将锁定解除为止。实际上，您能做的就是要明白这一点并计划在卸载任何修补程序之后重新启动系统。
另一个问题是间断性。并非所有程序都会一直使用某一个文件。事实上，大部分共享 DLL 的使用都是以时间点的方式，也就是说其他程序会根据自身的工作负荷和代码路径只在需要时进行调用。这表示您有可能测试了 10 次都没发现被锁定的文件，而后在生产部署时却发现一个被锁定的文件。遗憾的是，我们没有什么神丹妙术。您只能尽可能地将测试环境构建得与您的生产环境一样，包括负载（无论如何是个不错的目标），并进行足够多次测试以发现这些因素。
操作系统服务包和升级将引起重新启动。请注意，对于低级版本（Windows 2000、Windows XP 和任何更早期的版本），必须在完成重新启动之后安装才算结束 — 即使 pendingfilerenameoperations 注册表项为空时也如此。在重新启动期间，系统可能会运行例外的软件包注册操作来安装代码。它们甚至不是服务包安装的一部分，而是嵌入在您的当前操作系统中的命令，它们受升级的触发，目的是允许您运行要用来保留它们的代码段。
最后，PFR 项不会执行文件版本检查，也不通过顺序化来强制排序。这意味着它将按文件的列出顺序开始文件替换。但是在硬盘上替换文件的顺序已被证实是到最后一个文件才完成（而不是从第一个文件开始的）。这一点毫无疑问，不过这意味着如果在同一路径中存在同一个文件的两个副本，而每个都指向不同的版本，则这将在重新启动后产生一个随机结果。如果您遇到这种情况，则必须将其修复。如果您不能确定，只需在重新启动后再次运行相关的两个安装程序。如果您取得了正确的文件，则二者均不会执行任何操作。如果您取得的是错误的文件，则具有正确文件的那个软件包就会将其修复。老实说，比起找出所需的结果到底是什么来说，这是更快更安全的方法。

多个服务包安装

问：我在 4 节点群集上有八个 SQL Server 2000 群集实例，并且只想以最少次数的重新启动来安装 SP4。我可以将 SP4 逐一安装到这 8 个实例上并在最后重新启动全部节点吗？

答：一旦您在给定的 Windows 服务器上（群集或非群集）完成了 SQL Server SP4 单个实例的安装 — 可能需要重新启动，则在该机器的任何其他 SQL Server 实例上安装 SQL Server SP4 时便不会再进行重新启动。原因是，所有共享文件（工具、MDAC 和 MSXML 等）均已是正确的版本，从而无论被锁定与否，均不需要再进一步更新。所有非共享文件只会由第一个实例使用，该实例将被安装程序关闭。值得注意的是，如果您有多个版本的多个实例，您应当首先更新最新的 SQL Server 实例。

作为 Network Service 运行

问：究竟什么是 NT AUTHORITY\NETWORK SERVICE 帐户，其主要用途是什么？此外，该帐户有什么安全含义，尤其是为其赋予系统管理员 (sa) 权限时？

答：Network Service 帐户与网络上的 System 具有相同的标识（计算机标识），但是它在本地机器上的权限更小。因此，如果某个服务要求访问网络资源，也许是使用域控制器解析帐户名称，则该服务必须作为 System、域帐户或 Network Service 运行。通常，Network Service 是最安全的选择，因为它的作用范围仅限于本地机器，而且即使在本地机器上的权限也受到进一步限制。
在 SQL Server 中让 Network Service 成为系统管理员意味着在本地机上作为 Network Service 运行的任何其他服务都拥有对整个服务器的完全控制。例如，当 SQL Server 服务帐户被配置为作为 Network Service 运行时，就会发生这种情况。使 SQL Server 服务帐户成为系统管理员的一员需要服务器功能（例如，允许环回连接）。尽管在 SQL Server 上使 Network Service 作为管理员运行并不是个很好的安全实践，但也许会（或也许不会）好于将域帐户用于该目的，而它要比将 SQL Server 作为 LocalSystem 运行安全得多。
如果您不想让 Network Service 具有系统管理员权限，下一个要探讨的选择就是将域帐户专门用于在 Windows NT® 的一个或多个安装上运行 SQL Server。
以下文章可提供一些帮助：msdn.microsoft.com/library/en-us/dnpag2/html/paght000009.asp 和 microsoft.com/technet/security/topics/serversecurity/serviceaccount。

创建多个数据库

问：我想要将数据划分到单独的数据库中，一次可能会多达 250 个在线数据库。我估计在任何给定时间将只有 20% 的数据库要用于主动查询。数据库是多点比少点好吗？

答：数据库服务器实例中的数据库数量应由业务需要和管理因素决定。在单个服务器实例中创建多个数据库并不需要多少开销，不过更多的数据库意味着执行维护任务（如备份和还原、镜像、用户帐户以及用户角色）方面的管理开销会更多。随之增加的管理复杂性可能会超出增加数据库所带来的益处。
通常的规则是在一个数据库中保存与某个应用有关的所有数据，从而从故障中恢复会更容易。如果某个应用的数据遍布多个数据库，则在故障转移期间必须恢复所有这些数据库。这会延迟恢复，而如果其中某个数据库不能恢复时，甚至会导致整个恢复失败。
也就是说，将数据分到多个数据库中有以下原因：
  • 数据子集与其他数据的备份要求不同。
  • 某些数据需要一个单独的安全环境，即一个不同的数据库所有者。
  • 有时，数据的存在是用于历史目的并且需要在只读模式下保存。

衷心感谢以下 Microsoft IT 专家为我们提供技术专业知识支持：Ramon Arjona、Frank De Waelle、Robert Djabarov、Herman Learmond-Criqui、Maxwell Myrick、Ruslan Ovechkin、Uttam Parui、Shashi Ramaka、Gary Roos、Gavin Sharpe、Vijay Sirohi、Jimmie Thompson 和 Madhusudhanan Vadlamaani。

编辑：Nancy Michell


 您好，脚本专家！: 杯托在哪？
您好，脚本专家！
杯托在哪？
Microsoft 脚本专家
本专栏基于 Windows PowerShell 的一款预发布版本。文中的所有信息均可能会发生变更。

每当引入新技术时，人们通常都得需要一段时间才能真正将新技术与原有技术区分开来。让我们以第一辆汽车为例吧。之所以会在最初将这些装置认为是不用马拉的马车，那是因为这些装置本身几乎就是这么回事。当您审视它时，第一辆汽车与马拉的马车的区别就在于，一个使用马而另一个不使用马。除了这一点外，很难将它们区分开。
当然，现在几乎不会有人会将汽车误认为是马拉的马车。这是因为，随着时间的推移，汽车制造者们已经设法做了许多改造，这样，汽车就完全不同于马车了。例如，当今的汽车出厂时就带有 CD 播放器、空调和卫星导航系统；而马车怎么会涉及到这些东西。同样，假设您在 19 世纪 80 年代赶着一辆马车，途中需要放下一会儿您的法布奇诺咖啡；哎呦，您真是不走运。相比之下，有些休闲越野车则推出了多达 17 个杯托，而至少有一种型号的汽车为司机一个人就提供了三个杯托。一些较新款式的汽车甚至具有能够根据您的需要而加热或冷却饮料的杯托。
注 过去，人们在驾驶时竟然无法喝到三种不同的饮料，真难以想像他们是如何挣扎度日的。换作您，要是在驾驶时只能喝到一两种饮料，您同意吗？
在一项新技术得到人们的真正认可之前，要想让人们支持新兴的未知技术而不要支持那些原有的可靠技术，需要给他们一个理由。当 DVD 最先问世的时候，它们能够像录像机那样，让您在家中观看电影。从另一方面来说，DVD 比录像带更贵，而且您不能用 DVD 播放机来录下您自己的秀。不用说，DVD 并没有在世界各地引起轰动。事实上，直到 DVD 制造商开始在光盘内加入您甚至不知道会出现在电影中的删掉的场景、演员的解说词，以及其他无法从录像带上获得的东西时，DVD 才开始代替与其功能相同的 VHS。能够在家观看电影还不够；DVD 制造商们所提供的功能必须要更加先进，并超越人们已熟知的那些功能。
注 是否有人真正观看任何的附加项目则不是谈论的重点：人性就是这样，如果提供了某些东西，就会必须将其拿来，而不管对您是否有用。巧合的是，脚本专家正考虑推出这样一个 DVD 光盘：其内容主要由从 TechNet 杂志专栏中删除的文本以及系统管理脚本的备选结尾组成。

使用 Windows PowerShell
Windows PowerShell™ 是 Microsoft 发布的一项新增命令外壳/脚本编写技术，它是证明这一点的另一个示例。当人们第一次听说 Windows PowerShell 时，他们通常会听到这样的说法：
  • “Windows PowerShell 允许您管理进程和服务。”
  • “Windows PowerShell 可以使您从事件日志中检索事件。”
  • “Windows PowerShell 能够让您使用 WMI 来管理计算机。”
当然，听起来是没什么不对的，都是一些非常有用且重要的任务。但唯一的问题在于，您早就能用 VBScript 和 Windows Script Host 来执行那些任务了。保持向后兼容性非常重要，如果 Windows PowerShell 甚至都不能做与 VBScript 相同的工作，那它的创新意义就不大（设想一下连电影都不能播放的 DVD 播放机。实际上，您根本不必设想：有一位脚本专家的家里就有一台这样的机器）。
尽管如此，但如果 Windows PowerShell 只能做与 VBScript 相同的工作，那我们为什么要一开始就关注这项新技术呢？不可否认，VBScript 没有随附任何杯托，Windows PowerShell 也是如此。那我们使用哪种脚本编写技术会有什么不同吗？
老实说，不会有任何不同。另一方面，撇开缺乏杯托这一点不谈，Windows PowerShell 确实具有 VBScript 所没有的一部分功能。如果您需要做的只是管理进程和服务，那可能就没有必要去了解 Windows PowerShell 了；有句话说得好，东西还没坏，就别急着去修它。（当谈到脚本专家时，这句谚语应该改为“你们不试着修补它吗，因为它一会儿就坏了。”）Windows PowerShell 真正有吸引力的地方在于您能用它做一些 VBScript 所不能做的事情。如，更改文件的上次编写时间。

更改上次编写时间
您没听错：更改文件的上次编写时间。出于各种原因（如版本控制的快捷形式），脚本编写者一直梦想有一天他们能够更改一个文件或一组文件的上次编写时间（或创建时间）。令人沮丧的是，Windows Management Instrumentation (WMI) 和 FileSystemObject 中居然都没有这个功能；在这两项技术中，文件日期和时间是只读的。
但有了 Windows PowerShell，如果要将文件的上次编写时间更改为当前日期和时间，则只需运行以下命令：
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
在解释这个命令是如何起作用之前，让我们先回答一个几乎人人都在想的问题：如果 WMI 不能修改文件的上次编写时间，那 Windows PowerShell 是如何做到的呢？我们认为应该先解决这个问题然后再干别的事情。原因很简单，因为它代表了对 Windows PowerShell 的常见误解。人们可能会认为 Windows PowerShell 只是使用 WMI 的一种新方式。当然，您确实能够使用 Windows PowerShell 访问 WMI 数据；在我们等待构建其他 cmdlet（本机 Windows PowerShell 命令）的同时，大多数系统管理脚本仍然主要依靠 WMI，这也是实情。但是，在本质上，Windows PowerShell 是基于 .NET Framework 构建的，Windows PowerShell cmdlet 通常处理的是 .NET 对象，而不是 WMI 对象。这是很重要的，因为通过 .NET Framework 获得的属性并非一定与通过 WMI 获得的属性相同。
例如，当我们使用 Get-Item cmdlet 绑定到文件时，我们不会得到 WMI CIM_Datafile 类的实例；相反，我们得到的是 .NET 对象。这真有什么大不了的吗？的确如此 — .NET 对象提供的用于文件管理的属性和方法集与 WMI 所提供的略有不同。但是，就像我们刚刚看到的那样，这些细微的差别是非常重要的，如只读属性与读/写属性之间的差别。
接下来的问题：我们如何知道 Get-Item cmdlet 返回了 .NET 对象？在这种情况下以及在大多数情况下，查明我们正在处理的是哪种对象的最简单途径（以及确定可供我们使用的属性和方法的最简单途径）是绑定到文件，然后将该对象传递至 Get-Member cmdlet：
Get-Item c:\scripts\test.txt | Get-Member
该命令的结果如图 1 中所示。如您所见，这确实是一个 .NET 对象（脚本专家怎么会将类似内容弄错呢！）
Figure 1 由 Get-Item 返回的对象的成员 (Close Figure 1)

TypeName: System.IO.FileInfo

Name                      MemberType     Definition
----                      ----------     ----------
AppendText                Method         System.IO.StreamWriter AppendText()
CopyTo                    Method         System.IO.FileInfo CopyTo(String destFileName),
                                         System.IO.FileInfo CopyTo(S...
Create                    Method         System.IO.FileStream Create()
CreateObjRef              Method         System.Runtime.Remoting.ObjRef CreateObjRef(
                                         Type requestedType)
CreateText                Method         System.IO.StreamWriter CreateText()
顺便说一下，这个简单的小命令说明了 Windows PowerShell 的两个更加有趣（和有用）的功能：管道操作和元信息。我们今天不会涉及技术细节，但管道操作背后的基本理念是能够使用 cmdlet 来获得某个对象然后再将该对象移交给其他 cmdlet。在这个命令中，我们使用 Get-Item cmdlet 来获得一个代表文件 C:\Scripts\Test.txt 的对象，然后通过管道将该对象（作为一个对象）移交给 Get-Member cmdlet（符号 | 在 Windows PowerShell 命令中代表管道）。
Get-Member 随后开始工作，恰巧是检索被检索对象的属性和方法。这是 Windows PowerShell 有用功能中的一个：便于您访问元信息，即关于信息的信息。通过使用 cmdlet（如 Get-Member 和 Get-Command），您能够向 Windows PowerShell 询问您需要的所有信息，其方式与编写 WMI 脚本来检索有关可用的 WMI 类、属性和方法的信息大体上相同。
注意，Get-Member 实际上比 WMI 提供的功能更进一步。虽然您能够使用 WMI 获得关于 WMI 对象的信息，但您不能使用 WMI 获得关于其他 COM 对象（如，FileSystemObject）的信息。对于 Windows PowerShell 则不然。Get-Member 适用于您能够绑定到或创建的任何对象。不记得使用 FileSystemObject 时可用的方法了吗？然后运行以下命令：
New-Object -comobject "Scripting.     FileSystemObject" | Get-Member
这真是一个非常有用，也是远没有被充分利用的功能。
很好，是吧？如果我们在使用文件 C:\Scripts\Test.txt 时滚动可用属性和方法的列表，我们将会最终看到下面这一行：
LastWriteTime             Property       System.DateTime LastWriteTime {get;set;}
有意思。显然，LastWriteTime 是一个同时支持 get（读取）和 set（写入）的属性。这意味着我们能够使用 Windows PowerShell 来更改文件上次编写时间的值吗？嗯......
Windows PowerShell 术语表
别名 代表现有 cmdlet 的可自定义名称。Windows PowerShell 提供了大量默认别名，用于将常见外壳命令映射到各自的等价 cmdlet。
Cmdlet Windows PowerShell 中的最小功能单位，与其他外壳中的内置命令相似。
命令 Windows PowerShell 中的执行单位。命令可包括多种管道操作，通过使用 ; 字符，命令还可以跨行。
法布奇诺 星巴克出售的一种混合冰咖啡饮料。
Monad/MSH/Microsoft 命令外壳 Windows PowerShell 先前的代码名称。
对象 从系统或命令检索到的结构化数据。Windows PowerShell 将数据作为 .NET 对象处理，从而您能够通过名称来处理对象属性，而不必一定对基于文本的命令输出进行分析。
参数 命令行 cmdlet 中设置的选项。Windows PowerShell 在开头使用连字符 (-) 来指定一个参数。
管道 能够将一个命令的输出发送到另一个命令的输入。英文中也称为 pipe；在命令中由 | 字符表示。
配置文件 Windows PowerShell 启动时加载的设置，能够使您配置外壳的运行方式。
脚本 保存为文件并通过文件执行的一个或多个命令。对于脚本文件，Windows PowerShell 使用的是扩展名 .ps1。
Shell 可在其中同时运行命令和 cmdlet 的命令行环境。
变量 在命令执行期间能够设置、更改或检索其值的对象或参数。

现在让我们回过头来讨论一下用于将 Test.txt 的上次编写时间设置为当前日期和时间的命令吧。该命令如下所示：
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = Date
正如您所看到的那样，这个命令真的没有太多的内容。首先，我们声明一个名为 $a 的变量。然后我们使用 Get-Item cmdlet 连接到文件 C:\Scripts\Test.txt。反过来，我们将该对象储存到变量 $a 中。在输入一个分号（它能够使我们在一行上执行多个命令）后，我们将 LastWriteTime 属性的值设置为当前日期和时间。您知道，这几乎弥补了杯托的不足，不是吗？

展开想像的翅膀
当然，您并非只能将上次编写时间设置为当前日期和时间。例如，考虑以下命令：
$b = Get-Date "5/22/2006 8:15 PM";
$a = Get-Item c:\scripts\test.txt; $a.LastWriteTime = $b
这次我们将三个命令放在了一起。首先，我们使用 Get-Date cmdlet 来创建一个日期和时间分别为 5/22/2006、8:15 PM 的日期时间对象。为什么我们没有在第一个脚本（该脚本用于将上次编写时间设置为当前日期和时间）中使用 Get-Date 来创建日期时间对象呢？道理很简单：Date 命令将自动返回一个日期时间对象（要亲自验证这一点，将下列命令输入到 Windows PowerShell 控制台中：Date | Get-Member）。
在创建了与所需日期时间相等的日期时间对象后，接下来我们使用熟悉的 Get-Item 命令来获得代表文件 Test.txt 的对象（即我们储存在变量 $a 中的对象）。最后，我们将 LastWriteTime 属性设置为由变量 $b 代表的值：
$a.LastWriteTime = $b
不管您是否相信，您还没有完成任务的一半呢。看一看以下这个不吸引人的命令吧：
$b = Get-Date "5/22/2006 8:15 PM";
Get-ChildItem c:\scripts | ForEach-Object {$_.LastWriteTime = $b}
这个命令有什么特别有趣的地方吗？那么，让我们来看一下它的用途。第一部分非常简单：我们再次创建一个日期为 5/22/2006，时间为 8:15 PM 的日期时间对象。但是，注意在第二部分中我们使用的不是 Get-Item cmdlet，而是以下这个命令：
Get-ChildItem c:\scripts
这样做的目的是什么？嗯，无论何时将 Get-ChildItem cmdlet 应用于某个文件夹，您都会得到该文件夹中全部文件的集合。我们将获取该集合，然后将集合中的所有项目通过管道（即 | 符号）移交给 ForEach-Object cmdlet。
ForEach-Object 将会如何处理全部这些文件？嗯，它当然是更改每个文件的 LastWriteTime 属性的值了：
ForEach-Object {$_.LastWriteTime = $b}
注 尽管本月专栏并不是 Windows PowerShell 初学者指南，我们还是应该指出：$_ 是一个特殊的变量，用于代表 For Each 循环中的当前项。它等同于以下 VBScript 循环中的 objItem：
For Each objItem in colItems
    Wscript.Echo objItem.Name
Next
当 Windows PowerShell 命令运行结束时，文件夹 C:\Scripts 中的所有文件将具有相同的上次编写时间。我们想要由这些新发明的无需用马驾驶的马车之一来做这个工作！
我们可能要整晚运行该命令的各种形式。例如，也许您只想更改文件夹 C:\Scripts 中 .txt 文件的上次编写时间？好的；您需要做的一切就是提问：
$b = Get-Date "5/22/2006 8:15 PM"; Get-ChildItem c:\scripts\*.txt | ForEach-Object {$_.LastWriteTime = $b}

激发您的兴趣
很酷吧。但是，我们应该指出的是本专栏的目的不是向您“兜售”Windows PowerShell，也不是鼓励您抛开所有的 VBScript 脚本然后将它们全部转换为 Windows PowerShell。如果这些脚本能够完成您想要和需要它们做的事情，那么您就不要去改变它；对于批处理文件、命令行工具、魔术拼写和其他任何用于管理计算机的工具也是如此。记住，如果东西还没坏......
其关键并不在于 Windows PowerShell 能够让您做曾经能够做到的事；而是在于，由于 Windows PowerShell 在某种程度上提供了对 .NET Framework 的访问，从而能够让您做先前做不到的事。修改一个文件（或一组文件）的上次访问时间就是这样一个例子。是否还有其他示例取决于您需要做的事情是什么。正是这些功能使得 Windows PowerShell 值得人们仔细研究。
对于许多人来说，这次对于 Windows PowerShell 的介绍可能是不同寻常的：毕竟，与用简单的“Hello, world”之类的示例开头不同，我们引入了一个由多部分组成的 Windows PowerShell 命令，并且抛开了管道和 cmdlet 等术语，即使每个人都了解它们是什么含义。这是有意的。毕竟，我们知道你们当中的许多人还没有尝试过 Windows PowerShell；我们担心，如果我们向您展示如何在计算机上检索服务列表，您只会耸耸肩然后接着做您要做的事。
注意，我们希望您要做的事不是驾驶。对许多人来说，开车时喝三种饮料、观看 DVD 和打手机，而不把“阅读 TechNet 杂志”加进来是一件很困难的事。
嗨，继续往下看：我们是在对大多数人说，而不是针对所有人。

Microsoft 脚本专家为 Microsoft 工作，也就是说受雇于 Microsoft。在没有棒球等各种娱乐活动时，他们偶尔也会经营一下 TechNet 脚本中心。请访问 www.scriptingguys.com 进行查看。


 安全观察: 部署全球信任的 PKI
安全观察
部署全球信任的 PKI
John Morello
本专栏包括预发布信息，这些信息可能会发生变更。

公钥基础结构（或 PKI）是在不同应用程序、操作系统以及身份识别领域间建立信任的基础元素。它建立于层次信任模型之上，在该模型中，最终实体信任最高根级别的公共密钥，因而隐含信任由该根签名的其他任何密钥。
鉴于此结构，通过添加附加的证书颁发机构 (CA)，很容易就能对设计周全的 PKI 加以扩展，而不用将更改引入最终实体。
PKI 的实现方式通常有两种。最为常见的方法是根据需要从某一个隐含信任的全球根提供商（如 Cybertrust 或 VeriSign）那里购买证书。这些证书通常用于保护网站上的通信，但它们也可用于虚拟专用网络 (VPN) 加密、电子邮件签名以及类似的任务。由于这些全球根已内置到现今的每一种 Web 浏览器和操作系统中，所以采用此方法很容易就能跨越组织界限拓展信任关系。但是，由于这些证书是按需购买的，所以此方法对于在大型组织内进行广泛部署的情况可能代价高昂。
内部 PKI 模型最近比较盛行。顾名思义，内部 PKI 只在组织自身的网络中受信任。如果组织要使用证书在其网络上置备每一位用户和每一台计算设备，则采用此模型会更加便宜。此方法常常用于为诸如智能卡登录、加密文件系统 (EFS) 以及安全无线联网等技术提供便利。其缺点是，由于这些证书不是全球受信任的，所以它们不是很适合于外向型应用程序。因此，大多数部署了内部 PKI 的组织通常会采用一种混合方法，从某一个全球信任的根那里为公共应用程序购买证书。
但如果您能从两种方法中都得到很大好处，该如何呢？如果贵组织可以利用颁发内部证书所节省的费用来运行自身的 PKI，同时置备公共信任的证书（所有证书全部来自您自己的本地系统），又该如何？这样的解决方案不仅具有内部 PKI（如 Active Directory® 集成、自动注册和本地化 IT 支持）的好处，而且还具备全球信任根的主要优点。路易斯安那州立大学 (LSU) 就拥有这样一个系统。在本期的安全观察中，我将密切注视我们在 LSU 实现的解决方案，讨论其技术设计并着重指出在部署相似系统时应采用的最佳实践。应当注意，我将要介绍的解决方案只满足我们特定环境、资源和业务需求的特殊需要。您应当事先评估贵企业的所有这些方面，以便确定正适合于您的解决方案类型。

LSU 的 PKI 做法
LSU 是一所以研究为主的大学，其学生和教职员工总数超过 40,000 人。它拥有许多面向公众的网站，其中的许多网站都要求传输层安全性（针对安全套接字层 (SSL) 证书的专用术语）。LSU 每年都会花费数千美元从全球信任的根提供商那里购买证书。
同时，LSU 还有其他 IT 安全目标，为此可以大加利用设计周全的内部 PKI。根据 LSU 的目标和需求，您可能会以为我们选择了混合模型。但情况恰好相反，我们决定采取一种自己觉得更具创新性的方法。
我们与其中一个全球信任的根 Cybertrust 合作，在 LSU 校区部署了一个 CA，它从属于 Cybertrust 根 CA（参见图 1）。Cybertrust 在其 OmniRoot 计划中提供了此项服务。在此方案中，LSU 建立并运作了一个在 LSU 自有设备上本地运行的 CA。然而，与先前讨论的内部模型不同，LSU 的 CA 不是自签名的，并且其密钥（及其签名的任何密钥）在现今的几乎所有操作系统和浏览器上都是隐含受信任的。从技术上讲，此设计是 x.509 标准开放性的逻辑扩展。由于 PKI 建立在这些标准上，所以可以将不同供应商创建的系统插入到同一总体层次结构中。这就是说，OmniRoot 解决方案特别引人注意的地方是服务的使用条款。
图 1 Cybertrust 全球根证书
图 1 Cybertrust 全球根证书
OmniRoot 服务专为我们在 LSU 实现的那种 PKI 部署而设计。在 OmniRoot 计划中，加入该计划的组织每年要向 Cybertrust 支付一笔固定费用，然后只需为那些针对公共用途而创建的证书按每个证书支付费用。换言之，LSU 可以根据需要颁发任意数目的证书以供内部使用，而不必担心每证书费用的增加。同时，面向公众证书的费用现在也大大低于该大学按需购买证书时所支付的费用。
清楚点讲，内部证书和公共证书从技术观点来看别无二致。它们从同一 CA 链颁发，具有相同的密码强度，而且是通过同一注册授权系统置备的。二者的唯一不同之处就是许可条款。
最终，我们已能够以较低的费用来扩展和增强 LSU IT 安全性平台。此成就为 LSU 的这种 PKI 解决方案树立了一个大型商业典范。现在，让我们看一下部署的更多技术细节。

PKI 层次结构
LSU 的 PKI 层次结构采用双层设计而构建，根层由 Cybertrust 和在 LSU 运行的在线颁发 CA 进行管理（参见图 2）。根层构成了层次结构中的信任锚。换言之，由层次结构中的任何 CA 颁发的所有证书的信任关系均归入 CA（参见图 3）。因此，根 CA 形成了层次结构中所有 CA、证书和最终实体之间的共同纽带。由于 Cybertrust 全球根已内置到 Windows® 以及现今的几乎每一个其他计算系统中，因此这个共同纽带会自动延伸到 LSU 的网络范围之外。
Figure 2 双层 PKI 层次结构 (Close Figure 2)

根层 (Cybertrust) | 颁发层 (LSU)
由 Cybertrust 管理 | 由 LSU 管理
位于 Cybertrust 的安全数据中心 | 位于 LSU 的 Baton Rouge 校园
包含在几乎所有现今计算系统的默认根证书内 | 向 LSU 系统组织内的最终实体颁发证书
 | 由 LSU 颁发的证书归于 Cybertrust 根下，因而受到全球信任
图 3 LSU 的颁发 CA 所颁发的证书
图 3 LSU 的颁发 CA 所颁发的证书
Cybertrust 在其某一个安全托管设施中管理根 CA。托管设施使用了强大的物理安全控制，包括陷阱、生物特征锁和全铜外壳的储存库。Cybertrust 只将证书颁发给已证明符合其安全及证书策略的组织的颁发 CA。
LSU 的颁发 CA 是一个面向最终实体的系统，负责向 LSU 的用户和机器群体提供证书。其证书由层次结构中位居其上的 Cybertrust CA 签名，并且它所颁发的证书通过其自身链接到 Cybertrust 根 CA（参见图 3）。

颁发 OS 和硬件
LSU 对其颁发 CA 使用了带有 Service Pack 1 的 Windows Server® 2003 Enterprise Edition。Windows Server 2003 证书颁发机构服务提供了许多新功能，包括密钥存档、增量证书吊销列表 (CRL) 和“版本 2”模板。用作颁发 CA 的 Windows 实例依据标准 LSU Windows Server 构建策略构建。它在更新过程中进行了所有相关安全性的更新，并使用标准的 LSU 变更管理措施以及软件清单和更新工具进行管理。简言之，尽管管理 CA 服务本身有一些独特之处，但基础服务器硬件和操作系统很容易集成到组织的现有 IT 操作中。
除了遵循标准的 LSU 服务器安装最佳实践之外，我们还利用了 Windows Server 2003 Service Pack 1 中提供的安全配置向导 (SCW)。SCW 使用了一个数据库，其中包含可在 Windows Server 上运行的各种工作负荷的依赖矩阵以及这些工作负荷所需的安全性设置。此数据库包括将由 CA 提供的两个主要角色 — CA 服务本身和 IIS（它提供了 PKI 自服务网站）。
我们使用 SCW 很容易就创建了一个安全模板，除了运行这些工作负荷所需的服务以及强化服务器网络堆栈的服务之外，该模板禁用了其他所有的服务。然后，我们使用 scwcmd.exe 将此模板转换成组策略对象 (GPO)，以便能将其应用于组织单位级别的服务器。由于 LSU CA 基于角色的安全配置现存储在 Active Directory 内而与特定的机器无关，因而此方法简化了扩展和灾难恢复。
LSU 的颁发 CA 建立在一台 IBM xSeries 346 服务器上，该服务器具有双 3.2GHz Intel Xeon 处理器、4GB 的 RAM 和五个 146GB 的 SCSI 硬盘。根据 CA 服务的性能要求以及 LSU 利用硬件安全模块的事实，此平台应具备显著的生命力和成长空间。
按照标准最佳实践，我们通过创建两个 RAID 1 阵列将数据库和日志文件分割到单独的物理心轴上。第五个硬盘保留作为热备件且对这两个阵列均可用。我们将第一个阵列作为系统卷进行安装，其上存放着 CA 数据库。第二个阵列用于日志文件和其他各种数据文件，如 CRL。CA 数据库基于其他 Windows 部件（如 Active Directory）中已有的相同 Jet 技术而建立，所以其他基于 Jet 的存储解决方案的维护和磁盘配置最佳实践在此同样适用。
硬件安全模块 (HSM) 是专用的硬件设备，与操作系统分开进行管理。HSM 通常以 PCI 适配器形式出现，但也可作为基于网络的装置提供。这些模块不仅为 CA 密钥提供了一个安全的硬件存储区，而且还提供了一个专用的密码处理器来加速签名和加密操作。Windows 通过 CryptoAPI 接口利用 HSM — HSM 被视为一台密码服务提供商 (CSP) 设备。OmniRoot 计划要求每个 CA 至少使用一个经过 FIPS 140-2 级别 3（级别 4 的设备相当罕见）认证的 HSM 进行密钥生成和存储。作为独特而又高度安全的设备，HSM 需要一笔可观的财物投资；基于 PCI 的 HSM 的定价一般在 10,000-15,000 美元之间。
在 LSU 设计中，使用了一台 nCipher nShield 500 TPS（“每秒 500 个事务”的型号）作为直连式 HSM。（“直连式”表示它属于服务器内部并且只能供该服务器使用，与之相反，基于网络的 HSM 可以为多台主机所共享。）该 HSM 是一台 FIPS 140-2 级别 3 设备，它为钥控材料提供了 N 的 K 重保护。HSM 提供了强力保护以防私钥泄漏 — 攻击者需要拥有 HSM 存储器以及规定数目的访问令牌及其 PIN，才能访问密钥。
关键要注意一点，HSM 是为了防止其内容遭到恶意方的篡改而设计的。因此，HSM 对连续登录尝试失败次数施加了严格的限制。在 LSU 的设计中，连续 10 次登录尝试失败后，存储器将被擦除且无法挽回。
在我们的设置中只有一个 CA，所以没有理由享受基于网络的 HSM 的价格优惠。然而，如果组织计划要实现两个或多个 CA，便能以大大便宜的价格购买单台基于网络的 HSM，并在各 CA 之间共享它。此方法也使令牌的管理变得更加容易，因为所有密钥存储均可以由同一组令牌加以保护。

Active Directory 和注册
基于 Windows 的 PKI 解决方案的主要好处之一是，无需在加入 PKI 的实体上安装附加软件即可完成证书置备。相反，通过自动注册和组策略相结合，大多数证书置备都可以进行自主管理，且对最终用户不可见。LSU 使用此技术将机器证书自动分发给从属于其 Active Directory 的计算机。而且，我们使用一个自定义网站为非 Windows 主机提供了自服务证书请求功能。
正如前面提到的那样，OmniRoot 计划区分公共使用的证书和内部使用的证书。如果证书由不属于 LSU 组织的系统和用户使用（例如，当某位预期学生通过 SSL 安全网站提交入学申请时），它们将被视为公共证书。在 LSU 组织内部使用的证书（例如用于在 LSU 的服务器上加密数据的证书）被视为内部证书。
由于 OmniRoot 计划的费用取决于面向公共证书的数量，因此我们需要能够跟踪颁发了多少公共证书以及颁发给了哪些人。这样，对于任何公共用途的证书，模板的可辨别名称以“PublicCertificate”开头，显示名称以“Public Certificate”开头。例如，面向公共的 LSU TLS 证书模板基于默认的 Windows Web Server 模板，且被称为 Public Certificate LSU Web Server。对于内部使用的 Web 服务器，我们还有另一个模板，称为 Internal Certificate LSU Web Server。从技术上讲，这两个模板是完全一样的，命名上的区别只是为了简化记帐工作。
对于批量注册需求（例如为用于 IPSec 的证书注册整个部门），我们依靠自动注册。这是 Windows 中内置的一个简单而又高效的工具。从 PKI 管理员的观点来看，唯一需要的操作就是在模板上更改访问控制列表，同时授予任何一组需要证书的用户或计算机进行自动注册的权限。这些实体随后会自动检查 Active Directory，列举其具有自动注册访问权限的模板，找到具有这些模板的 CA，然后自动进行证书注册。另外，如果模板已被取代且在过期之前自动进行了续期，则自动注册功能还可确保证书被替换。
对于非批量用途，例如为 Web 服务器置备证书，我们使用了一个自服务网站，借此用户可以通过 Web 浏览器请求证书。此站点是 Windows Server 2003 随带的 Web 注册页面（/certsrv 虚拟目录）的自定义版本；我们的实现包括加上 LSU 标准的 Web 标记以及预先填写请求页面上正确的默认条目。而且，我们使用 Windows CA 服务中的默认退出模块，在通过此站点发送的请求需要批准时自动向我们的 PKI 管理团队发送电子邮件。

吊销设计
每个证书都有一个有效的生存期。有时，LSU 需要使未到有效期限的某些证书无效（例如，如果发给某位员工的证书在 2007 年 5 月有效期满，而该员工在 2007 年 1 月就离开了 LSU）。此类吊销是通过 CRL（它们是包含由 CA 签名的证书序列号列表的文件）来完成的。CRL 上所含的序列号是指那些有效生存期未满但 LSU 不再认为其值得信任的证书。客户端随后可以下载此 CRL 并对照检查以确定证书的有效性。
任何 x.509 v3 证书（除了根 CA 证书本身）均应有一个指向有效 CRL 的指针。此指针称为 CRL 分发点，简称 CDP。CRL 分发点包含于证书本身（参见图 4），并且不能在颁发证书后进行修改。CRL 是一个基本部件，用于保证来自 CA 的证书是有效的。同样，我们要确保 LSU CRL 具有物理冗余性和高可用性且可被外部各方访问。
图 4 LSU 的 CRL 分发点
图 4 LSU 的 CRL 分发点
与 Active Directory 集成在一起的基于 Windows Server 的 CA（如 LSU 那样）会自动将其 CRL 发布到 Active Directory，这样便可通过轻量目录访问协议 (LDAP) 对其进行访问。默认的发布位置是林中公钥服务容器内的 CDP 容器（参见图 5）。此发布位置是一个绝佳选择，因为它提供了自动复制、容错以及 CDP 局部查找功能。
图 5 CDP 容器
图 5 CDP 容器
然而，在 LSU 设计中存在许多利用 PKI 的非 Windows 和非 Active Directory 计算机。而且，尽管 LSU 是一个大型组织，但其绝大多数用户都位于同一校园网络（具有一条 10Gbps 的主干线），这就使得基于 Active Directory 的 CDP 发布的优点只能得到最低限度的发挥。
因此，我们只将 CRL 发布到某个 HTTP 路径，从而使构建冗余托管平台变得更加容易（我们主要的网站已建立了镜像站点）。这样也就消除了与启用客户端 LDAP 查找有关的潜在复杂性。我们每日发布一次 CRL，每小时进行一次增量式 CRL 发布。

展望
尽管我们当前的 PKI 为大学社区提供了强大的安全解决方案，但我们计划继续增强其功能。Windows Vista™ 和下一个版本的 Windows Server（代号为“Longhorn”）将会提供大量新的密钥管理功能，我们计划对这些功能进行研究。我们特别感兴趣的地方有已计划的在线证书状态协议 (OCSP) 客户端和响应器功能、对椭圆曲线密码术和 SHA-256 算法的支持以及大为改进的自动注册界面。此外，Windows XP Service Pack 3 计划加入一项称为凭据漫游的功能，它将在不带来漫游配置文件所涉及的系统开销的情况下提供密钥对安全漫游。最后，我们将对证书生命周期管理器（当前提供有测试版）的使用进行研究，以便提高我们的报告和管理能力。
总之，LSU 的 PKI 为大学提供了一项基本的安全服务，该服务在许多关键的 IT 功能中得到了应用。使用 Cybertrust 的 OmniRoot 服务，我们可以运行与 LSU 的其他 IT 系统完好集成的 PKI，但全球都可以得到它的信任。并且，通过在 Windows CA 服务上构建该解决方案，我们获得了高效的证书置备和管理能力以及与现有目录和身份识别管理系统的完美集成。简言之，想象中的具有强大安全性和无缝信任的 PKI 已在 LSU 变成现实。

John Morello以最优异的学业成绩毕业于路易斯安那州立大学，并在 Microsoft 的 Microsoft Consulting Services 当过六年的高级顾问。他使用 MCS 为战略性客户（如 Deloitte、GE 以及各种联邦组织）构建了 PKI。他现任 LSU 的副首席信息安全官。


 桌面文件: 了解 Windows 映像格式
桌面文件
了解 Windows 映像格式
Wes Miller
本专栏基于 Windows 部署工具的预发布版。文中的所有信息均可能会发生变更。

随着 Windows Vista 的发布，Windows 安装和部署的方式出现重大改变。安装引擎和 Windows Vista 部署工具的完整套件（以及 Windows Server 的预发行版本，其代码为“Longhorn”）已经重新编写。我在最新的 TechNet 杂志文章中曾讨论过这些更改
以及 Windows® 部署团队为进行这些更改而付出的努力。但关于这一主题有许多要讨论的内容，因此我将在这一新的定期专栏中介绍 Windows PE、Windows 安装和部署以及其他 Windows 管理和安全主题。
在此第一部分中，我将讨论全新的 Windows 映像格式 (WIM)。如果您尚不熟悉映像的细节，请务必阅读侧栏“典型映像过程”加以了解。在下一专栏中，我将讨论 Windows 自动安装工具包 — 它是新的工具套件，其中包括 ImageX（用来创建和处理 WIM 映像的命令行工具）和 Windows 部署服务 (WDS)（将替换远程安装服务 (RIS)）— 看看这些工具如何能使 OS 部署更容易。

转折点
Windows 部署团队年复一年地从 OEM 和企业客户那里听到相同的反馈。他们需要对映像更好的支持，还需要 Microsoft 提供统一的映像工具。这些用户不想选择第三方供应商，也不想了解其复杂的产品。而且，我们常常听到这样的抱怨，即 OEM 和企业客户认为他们不应该对使用映像工具部署 Windows 付费，而是想让 Microsoft 提供这些工具。
在 Windows Vista™ 开发初期，Windows 部署团队下了一个非常大的赌注。我们决定彻底放弃整个安装引擎 — 其许多组件已存在近十年之久。安装一直是薄弱环节，而且步骤太多。我们打算加速这个过程，删除不必要的步骤，提高 Windows 安装的整体可靠性。为此，我们将一改过去一段时间以来使用的手动接合引擎的整个安装过程，用完全基于映像的安装过程来替换。

设计全新的映像格式
在重新设计安装过程之初，我们就开始定义应使用的映像的类型了。争论的焦点一直是扇区与文件。也就是说，应使用以逐个扇区复制的方式来存储卷副本的映像格式，还是使用以单个文件为基础存储每个文件的映像格式。大多数人期望从速度（使用扇区的方式）与压缩（使用基于文件的方式）上获益。最后，我们用了一种格式，我感觉这一格式最大程度折衷了这两个益处。它不但具有非常好的性能，而且还提供了很大程度的压缩。
为了设定满足 OEM 和企业用户需求的映像格式，我们首先定义了几个必须实现的主要目标。我们列出的目标很大程度地倾向于基于文件的体系结构。我想我们全都看到了这一方式的优势，因此我们首先沿此方向开始。不久即诞生了 WIM 文件。（您可能会感到奇怪，WIM 中的“M”并不代表什么。我们根据接近交付里程碑时重复的 Windows 团队活动将其命名为 WIM — *.WI 这种缩写看上去怪怪的。）那么，我们来了解一下针对新映像格式提出的一组目标。
Windows 文件系统中性格式 该映像格式必须跨 Windows 支持的两个文件系统体系结构发挥作用。虽然几乎所有系统在运行时都使用 NTFS，但是许多 OEM 和企业都使用 FAT 文件系统作为暂时替代，以便能使用 MS-DOS® 部署 Windows。然后它们会转换为 NTFS。在 Windows Vista 中我们必须继续提供这一支持。
卷几何中性 我们必须解决捕获大卷并将它应用于较小的卷这一历史问题。即便映像工具能通过分区处理手段解决此问题，它也不可靠。在基于文件的体系结构中，映像占用的空间大小仅为组成该映像的多个文件的大小。由于文件系统独立还原，因此卷的大小不可靠。
典型映像过程
当 OEM 复制大量系统或大型组织需要将 Windows 部署到众多计算机中时，他们通常使用映像技术。前提是采用主机系统，严格按需要进行构建，然后将其复制到目标系统上。如果您不熟悉映像过程，以下是大概介绍。
  1. 管理员将 Windows 安装在系统上并按需要配置它。这涉及添加和删除组件、安装常用应用程序以及调整 UI 及其他设置。我们称之为主机系统。
  2. 然后管理员运行 Sysprep（由 Microsoft 以 Windows 部署工具形式提供），它会执行整理属性这一重要工作，这些属性可使 Windows 安装具有唯一性（例如，计算机名称、Windows 安全标识符 (SID) 及其他跨系统的唯一标识符）。当 Sysprep 的第二部分运行时，这些属性会被重置。
  3. 接着，管理员关闭计算机并重新启动进入 Windows PE、MS-DOS 或允许管理员运行映像应用程序的其他 OS。
  4. 现在，管理员运行映像工具，创建参考系统的映像。此映像是一个包含参考磁盘或分区的精确副本的文件（或文件集合）。
  5. 系统关闭，然后管理员将映像存档，映像可以根据需要进行更新（添加应用程序、修补程序和服务包）。
  6. 该映像被复制到一台或多台计算机上，至此 Sysprep 完成其工作，运行一次安装程序的简化版（称为“最小化安装”或“欢迎使用 Windows”，这取决于运行 Sysprep 时所用的 Windows 版本和配置 Sysprep 的方式）。此阶段依赖于一个名为 setupcl.exe 的极小的本机模式可执行文件。

系统体系结构中性 该映像体系结构必须使用 Windows 可以支持的任何体系结构。当时，这意味着支持截然不同的 x86 和 IA64 (Intel Itanium) 体系结构。现在，这也包括 x64（AMD64 和 EM64T）体系结构。
必须快速捕获并应用。如果是压缩形式，必须相当快地捕获映像。而更为关键的是，在应用映像时必须非常快速。
支持非破坏性映像应用程序 由于我们替换了升级选项（该选项会替换 Windows，而不会损坏用户数据或应用程序），并派生出能用于系统恢复的工具，我们希望该工具能够映像系统，但不会破坏卷上的任何现有内容。如果不做出相当多的工作，基于扇区的格式不会让用户实现上述目的 — 通常您只能还原一个整卷，甚至什么也做不了。
支持大量压缩 在 Windows Vista 开发初期，我们仍侧重于以 CD 形式交付。但鉴于 Windows XP 的映像大小接近 1GB，我们确定，尽可能紧密压缩映像很重要。对于基于扇区的映像而言，有很多手段可以实现此目的，但是我们关心是的这种实现中的移动部分。许多基于扇区的格式省略了磁盘上的空白区域以节省空间。（这就是即便映像大小始终为 0，也记录 0 的原因。）但是，由于使用基于文件的方式，我们对此进行了本质上的处理，因为我们不占用空白区域。
支持文件的单一实例 这个问题与前述问题相同。众所周知，Windows 可以在几个不同位置存储同一文件的多个副本。基于文件的方式使得只存储每个文件的一个实例并根据需要使用该文件很容易办到。
支持多介质（光盘）方式 甚至在 WIM 的初期，当我们刚好能在单张 CD 中容纳一个映像时，我们就已知道我们必须支持多个介质。即使我们在一张 CD 上交付 Windows，一旦用户添加应用程序、服务包等，他们的映像很可能会超出单张 CD 或 DVD 所能容纳的大小。因此我们必须允许它们跨越多个介质，以用于其自身的安装和恢复解决方案。
支持一个文件 Blob 上存在多个卷映像 很少有一个映像能够用于一切的情况。我们设计“单一实例”时，还加入了获取多个卷的功能 — 相同压缩和单一实例相互作用。因此，如果获得 Windows XP Professional 的映像，然后附加了 Windows XP Tablet PC Edition（它是 Windows XP Professional 的扩展集）的新映像，则该映像将只会依据两种版本之间明显不同的文件而增加大小。
这样，OEM 或企业用户可以附加许多彼此之间派生的映像，而其大小不会呈指数增加。这一功能很难通过基于扇区的格式实现。

WIM 的工作方式
WIM 格式的设计目标是尽可能简单，同时满足我们的指导原则。基于文件的方式可以满足上述目标。但它是如何精确工作的呢？
简单地说，您可以将 WIM 文件看作是 CAB 文件（它与 ZIP 格式很相似，但由 Microsoft 设计并认可 CAB 格式）。实际上，我曾听说 WIM 被称为“CAB 的子项”。WIM 文件和 CAB 文件之间的主要区别在于，除了捕获和压缩文件本身外，WIM 映像还存储应用于文件的元数据和组成在给定卷映像中捕获的卷的目录。因此，它有点像一种存档文件，其中包括将卷还原为创建映像时的样式所需的所有元信息 — 访问控制列表 (ACL)、短/长文件名、属性等等。
请注意，捕获过程的任何一点都不是所收集的分区信息（大小或类型）。应用过程也不对系统进行分区。ImageX 与多数映像工具不同，它具有分区中性的特点，需要在应用之前就创建分区并进行格式化。要在应用映像之前自动执行该过程，您应使用 diskpart 以及格式化命令行工具。
在卷映像中存储哪些内容不受任何限制。映像可包含两个卷（分别在星期二和星期四捕获的相同卷），一个具有服务包的映像和一个不具有服务包的映像，或者满足您需要的其他内容。要理解的主要一点是同样的文件只会捕获一次。两个卷映像具有的共同之处越少，占用的空间就越多。
我还应指出，WIM 格式的设计中，没有任何使其无法与 Windows 早期版本共用的内容。它在 Windows Vista 中的使用情况与在 Windows 2000 中的使用情况一样良好。现在让我们详细了解捕获并应用映像时刚好发生的情况。

捕获映像
捕获卷映像时，将有以下步骤执行：
捕获卷的元数据 ImageX 收集有关文件名、NTFS ACL 以及卷上其他文件系统属性的数据。（您可以选择使用一个脚本文件排除某些文件。）
捕获文件数据 文件由 ImageX 加载。每个文件都加载到卷上并准备收集有关该文件的某些数据。
生成文件哈希 生成基于文件本身的文件加密哈希。此哈希成为映像中文件的唯一标识符。
检查副本并将其删除 如果映像中已经存在另一个具有相同哈希的文件，则认为这是相同的文件，并且新文件通过指向已经存在的文件加以引用。
压缩唯一的文件数据 与采用 CAB 或许多其他存档格式不同，采用 WIM 格式的每个文件都是单独压缩的，而不是以组成一个数据流的文件集合的形式进行压缩。您也可以选择根本不进行压缩，这样将跳过此步骤。
压缩并存储卷的元数据 所有文件存档后，就会创建卷的元数据项。这将列出每个添加到卷映像中的文件。
生成并存储映像 XML 数据 这是对所捕获的每个卷映像的引用。例如，如果您运行 ImageX/info，此 XML 数据就是您将看到的数据。
编写缓存的 WIM 数据索引 最后，将编写主数据索引（以及缓存的数据）。这是适用于整个 WIM 的主文件表；其中每个哈希包含一项。
正如您所看到的，WIM 是按逐个文件的基准创建的。而且，不管为映像附加多少卷，您都只有一个 WIM 文件。

映像超载
在我们开始着手进行 WIM 的工作时，有许多团队在开发类似的解决方案。那时，自动化部署服务团队正在为不同的客户群开发映像解决方案。他们的方式有一些非常有趣的低级别实现细节，但是像当时大多数映像引擎一样，他们的映像引擎是基于扇区的。Windows XP Embedded 团队也构建了基于扇区的映像引擎，允许嵌入的独立硬件供应商 (IHV) 在系统制造时部署其自己的映像。而且，当 Microsoft 在 2003 年拥有了虚拟 PC 团队时，该团队引入了适用于虚拟硬盘 (VHD) 文件另一种文件格式。
所有这些格式的核心都是基于扇区的。它们符合每个客户群的需求，但是这些解决方案不符合我们对 WIM 的指导原则。因此，我们继续构建了新的 WIM 格式和用来捕获映像的 ImageX 命令行工具。最终，在我们的格式作为 Windows Vista 测试版的一部分公之于众之前，许多其他团队适当地加以了采用。例如，SMS 团队在其“操作系统部署功能包”中就提供了 WIM 的早期实现。

应用映像
现在让我们看看计数器过程：应用映像。
加载缓存的 WIM 数据索引。这一部分涉及前面过程中的最后一步。由于这是主索引，因此在指定了要应用的卷映像后，第一件事情就是从 WIM 中加载它。
检索并加载映像元数据 ImageX 加载每个卷映像特定的元数据。
创建目录结构 要确保每个文件都有一个被还原到的位置，需创建该卷的完整目录树。
提取文件数据 从 WIM 中以文件存档时的顺序提取文件。
应用文件数据 在此步骤中，文件被加载、解压缩（如果卷映像以 WIM 压缩），并复制到每个被引用位置。最后，应用每个文件的所有元数据。
应用所有目录元数据 由于目录中的 ACL 可能会阻碍映像的正确应用，因此这最后的步骤很重要。

灵活的压缩
我们使用 WIM 映像格式的主要目标之一就是提供灵活的压缩选项。因此，我们提供了必要时捕获压缩卷映像的功能，同时还允许捕获未压缩的映像。如果映像不需要极度压缩，或者高速捕获很重要，则最好选择后者。
进行压缩时，要记住一些关键原则。压缩用的时间始终比解压缩长。压缩算法越精密，压缩给定数据集所用的时间就越长。而且提供给压缩算法的数据越多，压缩效果就越好。
使用 XPress 或 LZX 压缩可以压缩 WIM 映像 — 当然，也可以选择不压缩。如果需要进行一些压缩，但不希望捕获过程占用更多时间，则 XPress 可以对这种情况很好地折衷。LZX 会提供最佳的压缩比 — 但是，正如您能推测到的，此方法会占用相当长的时间。
虽然不进行压缩会使映像捕获的速度最快，但是它也会产生最大的映像。压缩类型是按 WIM 提供的选项。一旦将卷映像捕获为 WIM，所有将来的卷映像都必须以相同的压缩设置进行捕获。
请注意，因为 WIM 映像是在逐个文件的基础上压缩的，所以压缩可能会不完整。这是有意做出的决定 — 我们这样做的目的就是使映像更易于编辑。捕获后编辑映像的功能是一个重要的选项。对于在捕获映像后要编辑的文件而言，必须替换文件数据及其元数据。如果我们同时压缩了整个 WIM，那么对我们进行设计（如果完全有可能）来说，对编辑文件提供支持就会复杂到令人难以置信的程度，并且替换映像中的文件将占用相当多的时间。通过我们进行的折衷，我们提出了一种既可有效压缩，又仍能使用我们的工具进行编辑的格式。
我希望本文能让您很好地了解我们为 Windows Vista 设计的各种映像功能的工作方式。在我的下一篇专栏中，我将介绍一些可用来管理和部署 WIM 映像的工具，侧重于 ImageX 和 Windows 部署服务。

Wes Miller是德克萨斯州奥斯汀市 Pluck 公司 (www.pluck.com) 的一位开发经理。在这之前，Wes 在奥斯汀市的 Winternals Software 公司任职，并曾在 Microsoft 担任 Windows 程序经理和产品经理。可通过 technet@getwired.com 与 Wes 联系。Wes 对 John Macintyre（现任 Microsoft 的 WIM/ImageX 程序经理）给予本专栏的帮助表示感谢。


 Windows 机密: 等待 RunOnce
Windows 机密
等待 RunOnce
Raymond Chen

假设 存在一个需要在进程当中重新启动系统的安装。例如，程序可能想要升级当前正在使用的系统 DLL。您可能需要触发一个干预重新引导以安装新的 DLL 文件，然后，在 DLL 升级完毕后，您可以将其用于安装的下一阶段中。
RunOnce 项便是针对此类场景而开发，在干预重新启动后，安装程序利用它来完成各自的安装（这是过去认为程序不会将事情弄糟的那段日子）。
Windows® Explorer 会在创建桌面和任务栏之前等待 RunOnce 程序的运行，直至完成。这是因为 RunOnce 在支持安装程序的原则下运行。由于 RunOnce 程序可能会更改系统配置数据，所以您不希望用户在重新配置系统期间使用该系统。
例如，RunOnce 程序正在对其刚刚安装的文件执行重定位基址和绑定，其中有些是外壳扩展的一部分。您当然不希望用户在程序或扩展的可执行文件仍在更新的同时尝试运行该程序或激活该扩展吧。
“支持安装程序”原则的另一个缺陷是仅当具有管理员权限的用户登录时，才会对 RunOnce 项进行处理。因此，不是管理员的用户无法完成安装。除此之外，如果对非管理员执行 RunOnce 项，则它将不再“运行一次”。事实上，这会造成一个进退两难的局面。这时您会怎么说呢，“好吧，我们不再运行它了，我们去运行另外一个”？要改变这一系统全局状态，您需要拥有管理权限。另外，很明显，非管理用户没有管理权限！程序再也不会是“运行一次”，相反地，它会“一次又一次地运行，直到管理员登录为止”。
RunOnce 主要用于结束程序安装，它显示在 Windows 安装程序中。当您试图安装服务包或升级为更新版本的 Windows 系统时，安装向导会检查 RunOnce 项。如果该项非空，您将收到一条错误消息，“程序安装仍在进行中，请先完成安装，然后再尝试升级操作系统。”这是合理的，因为您并不想恰好在程序安装过程当中来更改操作系统。
RunOnce 的整个设计都透露着它的过去。Windows 95，一个未对管理员和非管理员做出区分的操作系统中就有它的印记。实质上，由于每个人都是 Windows 95 的管理员，所以使用 RunOnce 的安装程序会依赖于下次重新启动时所执行的 RunOnce 活动。
对于最新的 Windows 操作系统，具有管理员权限的用户的一次登录时间不得长达数月这个设想将成为可能，对于 Windows Vista™ 尤其是这样。因此，需要运行 RunOnce 的程序可能会在经历过漫长的等待之后才能找到自身。
作为旁观者，我曾经见过一个永久的 RunOnce。每当它运行时，都会将自己重新添加到 RunOnce 项中。这明显违反了 RunOnce 项的初衷，因为它不再是程序安装的一部分，而是程序常规操作的一部分。而且，这种行为会导致 Windows 安装程序将始终报告说，有一个安装正在进行中。
因此，该用户再也不能升级操作系统了，因为这个惹人厌的程序总是在说：“我还需要做一些小事情，马上就可做完”。程序今天不会完成安装，“但是明天一定可以”。这非常类似于等待 Godot，但希望不会有生存危机。

Raymond Chen的网站 The Old New Thing 用于处理 Windows 历史和 Win32 编程。他当前正在编写一本书，恰巧书名也叫《The Old New Thing》（Addison-Wesley，2007）。