9 月 2008 9 月 2008
ISA Server: ISA Server 2006 安全保障指南
众多公司依靠 ISA Server 2006 (Internet Security and Acceleration Server 2006) 保障其环境的安全，却很少有公司采取重要措施保护 ISA Server 本身的安全。本文介绍了如何使用“安全配置向导”和管理角色减少其攻击面并保障 ISA Server 2006 的实施安全。 Alan Maddison
ISA Server: 使用 ISA Server 2006 增强 TS 网关的安全
使用新 TS 网关功能，Windows Server 2008 可使用户从任何位置访问其桌面，而无需使用 VPN。了解如何通过 ISA Server 2006 发布 TS 网关并将 ISA Server 2006 发布方案扩展到包含客户端运行状况强制措施。 Thomas W. Shinder 博士和 Yuri Diogenes
IIS 7.0: IIS 7.0 中的 10 大性能改进
最新版本的 IIS 引入了模块化且可扩展的平台，不但改进了对常见部署和管理方案的支持，还带来了明显的性能改善。本文介绍了 IIS 7.0 中带来这些改善的 10 大关键领域。 Mike Volodarsky
Mobility: 轻松移动您的业务线应用程序
如今许多移动专业人士都需要在其身处现场时能够通过移动设备访问他们在办公室里使用的业务线应用程序（CRM、ERP 等）。了解 Windows Mobile 和 Mobile Device Manager 如何让您为关键的业务线应用程序部署丰富的移动功能。 Matt Fontaine
安全性: 了解共享帐户密码的管理
共享和特权帐户密码十分常见，但绝大多数组织都未能充分地管理这些共享密码。这就导致了严重的安全问题。探究共享和特权帐户所带来的风险，并找出更好的方法来管理更加安全的密码。 Chris Stoneff
Columns
编辑寄语: 重返校园: | 读者来信: 读者心声: | 工具箱: 面向 IT 专业人员的新产品:
Exchange 问答: 对齐磁盘分区、规划 SCR 及其他: 在 2008 年 9 月份的 Exchange 问答中，我们解答了有关计算所需的全局编录服务器数、更改服务器站点成员身份等问题。Henrik Walther | 实用程序特别推荐: Windows Memory Diagnostic: 了解这一免费的实用工具可如何帮助您确定运行 Windows 时遇到的问题是否是由于内存故障所致。Lance Whitney | 深入剖析 SharePoint: SharePoint 目录集成: Pav Cherny 讨论了 SharePoint 中内置“目录管理服务”的限制，并解释了如何将此组件替换为自定义解决方案，以同步 SharePoint 与其他目录解决方案的收件人信息。Pav Cherny
Windows PowerShell: 字符串理论: Windows PowerShell 除了具有面向对象的性质，它还可以解析复杂的字符串。Don Jones 为您展示如何在 Windows PowerShell 中使用 Select-String 完成此操作。Don Jones | 您好，脚本专家！: 让您的用具随时候命: 了解如何使用未连接记录集（虚拟数据库表）解决与数据排序和使用大型数据集相关的 VBScript 限制。Microsoft 脚本专家 | 桌面文件: WDS 中的高级功能: Wes Miller 在有关 Windows 部署服务的第三部分中，探究了一些性能和可伸缩性增强、日志记录以及命令行自动化功能。Wes Miller
安全观察: 密码和信用卡，第 3 部分: 此系列文章共分三个部分，在最后一部分中，Jesper Johansson 将介绍软件供应商、安全套件以及营销措施如何阻碍真正的安全努力，并且还会警告我们这些做法将如何导致技术安全体系的崩溃。Jesper M. Johansson | 领域备注: 内部创新: Romi Mahajan 介绍了他的“内部创新”理论，此理论强调人类的创造力和资本应该并重，认为它们是实现持续不变的比较优势的关键所在。Romi Mahajan | Windows 机密: Windows 95 探秘: Raymond Chen 解释几行诊断代码如何突然让 Windows 95 运行变缓。Raymond Chen


ISA Server 2006 安全保障指南
Alan Maddison
概览：
  • 服务器安全保障最佳实践
  • 安装安全配置向导
  • 安全配置向导演练
  • 分配管理角色

目录
保障服务器的安全
安装安全配置向导
运行 SCW
管理角色
当前，众多 IT 专家正在依靠 ISA Server 2006 (Internet Security and Acceleration Server 2006) 保障其技术资产的安全，却很少有人采取专门措施保护 ISA Server 本身的安全。如果您
最近刚安装了 ISA Server 2006，您可能会回想起就在安装一结束时有这样一条提示。遗憾的是，很少有 IT 专家会花费时间（或有时间）执行这一重要的步骤，这导致其经常变为一纸空文。
如今的安全领域充满变数，ISA Server 本身的安全无法保障是不可容忍的。值得庆幸的是，用于保障 ISA Server 安全的工具已经有了长足的进步。ISA Server 2004 之前版本的“安全增强向导”中的诸多不适之处现在已得到解决。目前的工具和步骤均定义良好，如 Windows Server® 2003 随附的安全配置向导 (SCW)。
我将在本文中简述服务器安全保障的常用最佳实践。然后分步剖析 ISA Server 本身的增强策略，即使用“安全配置向导”减少对 ISA Server 的攻击面，并使用管理角色设定 ISA Server 的访问权限。

保障服务器的安全
无论服务器是位于数据中心还是就在您办公室的隔壁，要保障它们的安全均涉及很多因素和最佳实践。作为一名管理员，您的职责就是了解这些最佳实践，并尽可能以与公司实际情况相符的方式满足其要求。由于近年来对安全性的重视日益普及，我们中的大部分人对安全保障的核心任务已经非常熟悉，所以在这里就不必长篇大论了。
保障环境安全的第一步是确保服务器所处物理环境的安全。实际上，这意味着您必须限制对服务器的物理访问。如果环境空间不大，则需要为服务器所在的房间上锁，并限定只有极少数人才有权进入。如果空间很大，这一基本要求类似，但实施方式要更为复杂。例如，许多公司都使用电子监控。这样，它们就能审查对服务器所在位置的进入情况，甚至能够根据工作职责的层级限制对个人办公隔间的接触。
在处理 ISA Server 或 ISA 配置存储服务器的失窃或物理环境安全隐患时，需要考虑一些特殊的因素。失窃服务器存储的信息有可能危及您环境中所有 ISA Server 和通信（包括加密的通信）。
如果您怀疑某台服务器受到了攻击或失窃等，请立即转移受影响的服务器（如果它仍在现场），然后执行标准的取证程序。实施这些必要的措施后，您需要着手更改所有的机密信息—废除服务器上安装的所有证书并修改先前共享的密钥和保密信息。此外，如果您还持有备用配置存储服务器，请确保删除所有与受攻击服务器有关联的数据。
服务器物理环境的安全得到保证后，接下来就要确保能有条理地为所有软件安装补丁，包括虚拟化层、OS 和应用程序。应定期查看并应用补丁程序、升级程序和修补程序。但请务必先测试这些更新，然后再将其应用到生产系统中。要是补丁程序会对应用程序或数据的完整性有所不利，那它就毫无益处。
如果数据的完整性存在安全隐患，您就必须转而依赖备份。保障基础结构安全的另一重要因素就是由此而来。如果在需要时您无法迅速完整地恢复数据，停机时间会对您的操作产生重大影响，进而加大入侵成本。
监控和审计是两个需要考虑的因素。在任何良好的安全计划中，监控都是必不可少的要素。如果您没有花时间查看日志，特别是与安全相关的日志，您就很可能无法在出现损坏前找出入侵企图。
审计也是同等重要。在许多公司（尤其是大公司）中，这是一项制度甚至是法规要求。总之，对于任何公司，都需要定期查看用于保障资产安全的控制步骤和方法，以确保您的措施有效。
最后，由于您是在 Windows Server® 2003 上运行 ISA Server 2006，所以需要查看 Windows Server 2003 安全指南并执行必要的建议措施。该指南的路径为 microsoft.com/technet/security/prodtech/windowsserver2003/w2003hg/sgch00.mspx。
Microsoft 目前建议运行“基准安全性策略”模板，但您不应运行任何 Internet 协议安全性 (IPsec) 过滤器。

安装安全配置向导
那么，如何让 ISA Server 本身更为安全呢？SCW 是保障 ISA 安全的基本工具。它用于减少攻击面。它针对服务器的服务、网络安全和注册表创建安全策略和审计策略，从而为系统配置刚好需要的服务和功能。请切记仅配置您打算使用的 ISA Server 服务。例如，Web Proxy 服务默认启用，但如果您不会用到这一服务，应将其禁用。因此，您需密切注意 SCW 为您提供的配置选项。
Windows Server 2003 上默认未安装 SCW，因此您首先要自己使用“添加/删除程序”控制面板中的“添加/删除 Windows® 组件”小程序安装这一程序。（注意，Windows Server 2008 中默认安装有 SCW。）加载“Windows 组件”屏幕后，向下滚动并选中 SCW 的复选框。
安装一旦完成，该应用程序会出现在“管理工具”下。使用向导前必须先通过下载 ISA Server 2006 的更新来对 SCW 加以更新（地址为 go.microsoft.com/fwlink/?LinkId=122532）。此更新会为 ISA Server 2006 Standard Edition、ISA Server 2006 Enterprise Edition 和 ISA Server 配置存储服务器新增角色。
下载更新后，需要运行软件包并从中解压文件。解压这些文件后，将其中的两个 .xml 文件（isa.xml 和 isaloc.xml）复制到 SCW kbs 文件夹—在 Windows Server 的默认安装中，其路径为 c:\windows\security\msscw\kbs。
复制文件时，会提示您覆盖两个名称相同的现有文件。这两个文件要在 ISA Server 2004 中使用，所以覆盖前请进行备份。最后是将 isascwhlp.dll 文件复制到 bin 文件夹，通常它的路径是 c:\windows\security\msscw\bin。将 ISA 角色加入 SCW 后，即可开始安装。
Microsoft 通常建议您在配置完 ISA Server 后再运行 SCW。如果您运行的是 Enterprise Edition，这包括配置所有数组和数组成员。

运行 SCW
首先从管理工具启动 SCW—记住，您需要具有管理权限才能完成 SCW 进程。
图 1 显示了向导的第一个屏幕。如果您通读了此屏幕上的文字，尤其是“this wizard detects the inbound ports that are listened to by this server”（此向导检测由此服务器侦听的入站端口），您就会理解在启动这一进程前完全配置 ISA Server 和数组的重要性。
图 1 启动安全配置向导（单击图像可查看大图）
如果您尚未完全配置环境，您需要有一个好机会能在完成 ISA 配置后修改 SCW 配置。下一屏幕（如图 2 所示）会询问您想执行哪种操作。您应选择“Create a new security policy”（新建安全策略）。
图 2 新建安全策略（单击图像可查看大图）
随后通知您选择担任策略基线的服务器。由于您是新建策略，默认选项是使用您运行 SCW 的计算机。但是，此行为会随您在前一屏幕中所选的执行操作而变。总之，建议您最好在用作基线的服务器上安装 SCW。如果未在目标服务器上安装 SCW，则有可能丢失用于完成策略的信息。因此，为了方便起见，最好在将用做基线的服务器上安装 SCW。
按“Next”（下一步）后，SCW 将开始分析您的 ISA Server。此分析包括确定在服务器上安装的角色、可能在服务器上安装的角色、安装的服务以及基本联网信息。完成这一流程后，可通过选择“Configuration Database”（配置数据库）查看数据库。此配置数据库存有大量信息，包括所有支持的服务器角色、客户端功能和端口。
SCW 随后开始逐步引导您完成基于角色的服务配置。按“Next”（下一步）进入下一屏幕，它会提示您选择服务器角色，如图 3 所示。SCW 执行的初始扫描是可靠的，您应能发现已经标识出了正确的服务器角色。但是，您需要仔细检查并删除任何不需要的角色，这一点十分重要。如果服务器担当多个角色，确保选择了所有合适的角色。
图 3 指定服务器角色（单击图像可查看大图）
如果运行 ISA Server 2006 Enterprise Edition，务必要考虑配置存储服务器。如果配置存储服务器安装在充当 ISA Server 的服务器上（这一方式与建议的最佳实践不符，但在实际中经常出现），则需要确保还选择了“配置存储服务器”角色。如果实际服务器仅具备 ISA Server 2006 角色，则您不能对其使用托管两种角色的服务器基线扫描。
接下来会提示您选择服务器的客户端功能。换言之，您需指定服务器需要的服务。例如，几乎所有服务器都需要 DNS 客户端，如果服务器是域成员，则还需要域成员功能。
完成后为您显示“管理和其他选项”屏幕。在此指定使用服务或依赖网络连接的应用程序、管理和操作系统选项。任何没有在此选中的服务均被禁用。但在您完成选择并按“Next”（下一步）后，还允许您选择任何想要的其他服务。
接下来您可配置如何处理未指定的服务。您可定义在应用策略后，如发现未包括在主数据库中或未在基线服务器安装的服务，应进行何种处理。一般来讲，最好选择禁用未指定的服务，以防止任何未预见的攻击。遗憾的是，如果您的服务器有重大变化，这会带来负面影响。因此，若您将来要添加任何应用程序或网络服务，需要记住这一设置。
此向导的下一部分（如图 4 所示）允许您查看由 SCW 修改的服务。此配置屏幕为您提供比较视图，上面比较了当前状态和应用策略后修改的服务状态。
图 4 查看并确认服务更改（单击图像可查看大图）
确定要有更改的服务后，进入“网络安全”设置区。SCW 通常让您在此修改“Windows 防火墙和 Ipsec”设置。但由于您是在配置 ISA Server 2006，您只能略过这部分内容，如图 5 所示。
图 5 略过网络安全设置（单击图像可查看大图）
接下来是配置注册表设置，主要内容是网络验证和安全。这部分的第一个屏幕涉及服务器消息块 (SMB) 签名。SMB 协议是 Microsoft 核心联网协议，这些设置允许使用经过签名的通信，以减少中间人攻击的可能性。
默认设置（如图 6 所示）为 ISA Server SMB 通信提供了相当不错的安全防护。但您必须考虑到对所有通信签名所产生的影响。如果您没有多余的 CPU 时钟周期，不应选择第二个选项。并且要考虑应用此策略的所有服务器—如果您的服务器有多项工作负载，需要使用 CPU 利用率最高的服务器做为是否选取此选项的衡量标准。
图 6 指定是否要求签名的通信（单击图像可查看大图）
下一组屏幕处理 ISA Server 应使用的 LMCompatibility 级别。其中是第一个显示三个选项。除非您有旧版的 Windows 客户端（例如 Windows 95 或 Windows 98）或您使用本地帐户进行访问控制，否则应选中域帐户的默认选项。
在处理 LMCompatibility 级别的第二个屏幕上，您提供域控制器的相关信息。如果您未安装任何 Windows NT® 4.0 域，应选中默认选项（Windows NT 4.0 Service Pack 6a 或更新的操作系统）。在此对话框中，还应选中“Clocks be synchronized with the selected server's clock”（时钟与选定服务器的时钟同步）选项。选择“Next”（下一步）将显示入站 LAN Manager (LM) 通信的一些其他选项，如图 7 所示。
图 7 指示入站验证方式（单击图像可查看大图）
第三个屏幕与 LMCompatibility 级别有关，它确定是否要求 Windows NT LAN Manager (NTLM) 版本 2 以及是否存储 LM 哈希。如果您的环境将支持该配置，应确保这两个选项均未选中，因为这会大大提高安全性。随后为您显示“注册表设置摘要”。查看每个注册表项并确认策略设置正确。
接下来，向导将您带入最后一部分—审计。对于在此部分所选的任何配置选项，有一点需要特别注意：它们都不能回滚。但由于审计不会影响系统功能，您不应略过这一部分。
“Audit successful activities”（审计成功活动）这一默认选项不会为您提供登录失败的事件日志条目。但是，登录失败的相关信息会提供非常有用的入侵企图信息。因此，最好选中这一选项。
随后您可查看您的审计配置并按两次“Next”（下一步）以保存安全策略。如图 8 所示，此屏幕只需输入文件名；但您也可以提供简介。在多名管理员共享安全职责的大型环境中，此简介非常有用。
图 8 提供安全策略的名称和说明（单击图像可查看大图）
保存文件后，允许您选择是立即应用策略还是稍后应用。如果您选择稍后应用策略，此过程完成。如果您发现策略配置中有任何错误，可以回滚策略（但审计配置除外）。

管理角色
减少外部安全缺口时，减少 ISA Server 的攻击面是其中的关键步骤。但是，审查 ISA Server 内管理角色的分配也同样重要，这可减少内部安全隐患。图 9 和 10 中显示了管理角色和常用相关任务的部分列表。
图 9 Standard Edition 的相关角色和任务
任务 | 监控审计员 | 审计员 | 超级管理员
查看仪表板、警告、连接性、会话和服务 | 允许 | 允许 | 允许
确认警告 | 允许 | 允许 | 允许
查看日志信息 | – | 允许 | 允许
创建警告定义 | – | – | 允许
创建报告 | – | 允许 | 允许
中止和启动会话与服务 | – | 允许 | 允许
查看防火墙策略 | – | 允许 | 允许
配置防火墙策略 | – | – | 允许
配置缓存 | – | – | 允许
配置虚拟专用网络 (VPN) | – | – | 允许
图 10 Enterprise Edition 的相关角色和任务
活动 | 数组监控审计员 | 数组审计员 | 数组管理员
查看仪表板、警告、连接性和会话 | 允许 | 允许 | 允许
确认和重置警告 | 允许 | 允许 | 允许
查看日志信息 | – | 允许 | 允许
创建警告定义 | – | - | 允许
创建报告 | – | 允许 | 允许
中止和启动会话与服务 | – | 允许 | 允许
查看防火墙策略 | – | 允许 | 允许
配置防火墙策略 | – | – | 允许
配置缓存 | – | – | 允许
配置虚拟专用网络 (VPN) | – | – | 允许
执行 NLB 排放/中止 | – | 允许 | 允许
查看本地配置（在数组成员的注册表中） | – | 允许 | 允许
更改本地配置（在数组成员的注册表中） | – | – | –
正如您所见，与 ISA Server 相关的管理任务划分得很细。这就为您向公司中内的用户指定合适的角色提供了便利。
进一步讲，您需要牢记指定角色时最好应用最小权限的概念。任何已知用户只应具备完成工作所需的最低权限。
另外，还要注意 ISA Server 2006 Standard Edition 中本地 Administrators 组的成员与 ISA Server Full Administrator 的权限相同。在 Enterprise Edition 中,履行配置存储服务器角色的服务器所属本地 Administrators 组的成员对 Enterprise 配置有完全控制权。这意味着如果您的 ISA Server 是域成员，您需要仔细审查 Domain Admins 组的成员关系，以及隶属 ISA Server 本地 Administrators 组的任何其他组成员关系。

Alan Maddison 是博科 (Brocade) 战略业务系统部门的一名高级顾问，精通 Microsoft 技术。


ISA Server
使用 ISA Server 2006 增强 TS 网关的安全
Thomas W. Shinder 博士和 Yuri Diogenes
概览：
  • 两种搭配使用 TS 网关与 ISA Server 的方案
  • ISA Server 2006 配置
  • 测试和监视

目录
超越外围
第一个方案
配置 ISA Server 2006
测试和监视客户端访问
从 ISA Server 实施监视
第二个方案
客户端又将如何？
结束语
在 Exchange Server 2007 中成功实现了 Outlook Anywhere 之后，Windows Server 2008 又提供了以安全且可控制的方式从任意位置访问桌面的功能。
Windows Server® 2008 中的这一新终端服务器网关服务（TS 网关）提供了 Windows® 终端服务器服务的灵活性以及通过 HTTP 连接从任意位置连接终端服务器的能力。此项服务通过 HTTPS (SSL) 使用远程桌面协议 (RDP) 来增强安全性，同时提供了一个用于访问终端服务资源的客户端界面。
这一新型 TS 网关服务为那些需要从远程访问其计算机的用户提供了许多优势：
  • 在使用 RDP 连接内部资源之前无需建立虚拟专用网络 (VPN) 会话。
  • 通过使用网络访问保护 (NAP) 和 Windows 安全状况检查控制 RDP 连接增强了安全性。
  • 通过防火墙启用更安全的 Web 发布时，无需打开 TCP 端口 3389 入站。
您可以使用 Microsoft® Internet Security and Acceleration (ISA) Server 2006 来增强 TS 网关的安全性，同时允许从外部访问内部资源。您可以建立一个 SSL 到 SSL 桥接方案，其中 ISA Server 2006 仍使用 HTTPS 接收请求并将其传递给内部 TS 网关服务。桥接请求时，ISA 防火墙会解密 SSL 通信并执行应用程序层检查。
如果 HTTP 协议流通过了检查，那么通信将被重新加密并转发到终端服务代理。如果协议流未通过检查，则此连接将被丢弃。

超越外围
Microsoft 在安全性方面投入了大量的精力，将 Windows Server 2008 打造成了 Windows 最安全可靠的版本。同时，公司还关注用户将如何实现其产品以及用户是否依照最佳实践来保障其环境的安全。最佳实践需要有深层防御方法，能在多个访问点或层提供保护。我们在这里讨论的层包括策略、过程和识别、外围、内部网络和主机。
如果您允许外部用户通过 ISA Server 访问内部资源，您需要了解所涉及的各个产品的边界。ISA Server 2006 和 TS 网关将在“外围”层提供保护，但对于内部资源，您还需要准备一些策略，以根据需要允许或拒绝访问。Network Policy and Access Services (NPAS) 可使您实现这一点，它在策略、过程和识别层上发挥作用。对内部资源（驱动器、剪贴板、打印机等）的访问由处理内部网络层的终端服务资源授权策略定义。
在本文中，我们首先将说明如何通过 ISA Server 2006 发布终端服务网关。然后我们会将 ISA Server 2006 发布方案扩展到包含使用 NAP 的客户端运行状况强制措施。通过使用 NAP，我们可以创建客户端运行状况策略，以帮助我们控制主机层访问。

第一个方案
我们的目标是展示如何通过 ISA Server 2006 发布 TS 网关。图 1 汇总了此连接期间的计算机和数据流。在此方案中，我们将在 TS 网关本身实现网络策略服务器 (NPS) 角色；而在第二个方案中我们将改为使用中央 NPS 服务器。下面依次介绍了通信如何在 TS 网关发布解决方案的各组件之间工作：
图 1 通过 ISA Server 2006 发布 TS 网关（单击图像可查看大图）
  1. 外部 RDP 用户启动连接。客户端首先必须解析 TS 网关的外部名称（在本例中为 tsg.contoso.com）。外部 DNS 解析此名称（指向 ISA Server 的外部 IP 地址）。
  2. 在 RDP 客户端与 ISA Server 的外部接口之间建立 SSL 隧道。ISA Server 在端口 TCP 443 有一条 Web 发布规则，它使用签发给 tsg.contoso.com 的证书。
  3. 在评估此规则并检查允许的流量后，ISA Server 将向内部 DNS 服务器（位于域控制器上）发送一条 DNS 查询，以解析在 Web 发布规则中指定的服务器名称。
  4. ISA Server 之后会打开通向 TS 网关的 SSL 隧道并向其传递身份验证请求。
  5. TS 网关服务器验证用户的凭据并检验是否授权该用户建立连接。
  6. 在确定用户有权建立连接之后，TS 网关服务会在 TCP 端口 443 接收请求并通过 TCP 端口 3389（默认情况下）将 RDP 数据包转发到应用程序（如 CRM 应用程序）所驻留的内部终端服务器。
自此，RDP 客户端通过 ISA Server 发送给 TS 网关服务的任何数据包都将被转发到内部终端服务器，反之亦然。
请注意，RDP over HTTPS 就是 RDP/RPC/HTTPS。RDP 客户端将 RDP 通信封装在 RPC 标头中，该标头随后将与使用 SSL（或传输级安全性 TLS）保护的 HTTP 标头封装在一起。RPC over HTTPS 解决方案所需的所有组件都必须存在。这是因为当您安装 TS 网关角色服务时，它会自动安装 RPC over HTTP 代理。要了解更多该协议工作原理的信息，我们建议您阅读 ISA Server 团队博客的一篇文章 "Testing RPC over HTTP through ISA Server 2006 Part 1; Protocols, Authentication and Processing"（地址是 blogs.technet.com/isablog）。
这一实现需要安装有终端服务网关的 Windows Server 2008，而且此功能要依赖 RPC over HTTP 代理。要令 RDP over RPC over HTTP 代理发挥功能，必须安装并运行 Internet 信息服务 (IIS) 7.0。您还需要 Network Policy and Access Services，但是，如果您喜欢，也可以配置 TS 网关以使用 NPS 服务器（以前的 Internet 身份验证服务 (IAS)）集中存储、管理以及验证终端服务连接授权策略 (Terminal Services Connection Authorization Policies, TS CAP)。最后，您必须为 TS 网关服务器获取一个 SSL 证书（如果您还没有）。请特别注意，ISA Server 2006 必须信任发放该证书的证书颁发机构 (CA)。因此，请务必要将该证书导入受信任的根证书颁发机构存储区。
仅当您配置的 TS 网关授权策略要求用户是 Active Directory 安全组的成员才能连接 TS 网关服务器时，才需要 Active Directory® 域服务。对于此特定设置，我们将在运行 Windows Server 2003 SP2 的计算机上使用 Active Directory。
安装完终端服务网关服务后，将会出现图 2 中所示的屏幕，其中显示已安装的组件。若要连接 TS 网关，客户端必须运行以下一项内容：Windows Vista®；带 SP2 和 RDP 6.0（或更新版本）的 Windows XP；Windows Server 2008；带 SP1（或更新版本）和 RDP 6.0（或更新版本）的 Windows Server 2003。有关 TS 网关配置的详细信息，请参阅《Windows Server 2008 TS Gateway Server Step-By-Step Setup Guide》（go.microsoft.com/fwlink/?LinkId=122251）。现在让我们看一看如何配置 ISA Server 2006。
图 2 TS 网关安装汇总（单击图像可查看大图）

配置 ISA Server 2006
第一步创建一个 Web 侦听器，它将处理来自外部 RDP 客户端的请求。我们的 Web 侦听器具有下列参数：
  • 身份验证：基本
  • 身份验证检验：Windows (Active Directory)
  • 连接：在端口 443 上启用 SSL (HTTPS) 连接
  • 证书：向 tsg.contoso.com 签发的证书
  • 网络：外部
接下来创建 Web 发布规则。从 ISA Server 2006 角度看，RDP 客户端将使用 Outlook® Anywhere 所采用的协议，因此选择 Exchange Server 2007 向导。只需执行下列步骤即可：
  1. 右键单击“Firewall Policy”（防火墙策略），选择“New”（新建），然后单击“Exchange Web Client Access publishing rule”（Exchange Web 客户端访问发布规则）。
  2. 在“Welcome to the New Web Publishing Rule Wizard”（欢迎新建 Web 发布规则向导）页面中，键入规则的名称并单击“Next”（下一步）。
  3. 在“Select Rule Action”（选择规则操作）页面中，选择“Allow”（允许）选项并单击“Next”（下一步）。
  4. 在“New Exchange publishing rule”（新建 Exchange 发布规则）页面中，选择 Exchange 版本（在我们的示例中为 Exchange Server 2007）。选择 Outlook Anywhere (RPC/HTTP) 并单击“Next”（下一步）。（注意：请不要选择“Publish additional folders on the Exchange Server for Outlook 2007 client”（在 Exchange Server for Outlook 2007 客户端上发布其他文件夹）选项。）
  5. 在“Publishing Type”（发布类型）页面中，选择相应选项以发布单个网站或负载平衡器，然后单击“Next”（下一步）。
  6. 在“Server Connection Security”（服务器连接安全）页面中，选择“Use SSL”（使用 SSL）连接发布的 Web 服务器或服务器场，然后单击“Next”（下一步）。
  7. 在“Internal Publishing Details”（内部发布详细信息）页面中的内部站点名称框中，键入 TS 网关服务器的名称。选中“Use a computer name or IP address to connect to the published server”（使用计算机名称或 IP 地址连接发布的服务器）复选框，然后在“Computer name”（计算机名称）或“IP address”（IP 地址）框中键入服务器名称。如果您不知道 TS 网关服务器的名称，请单击“Browse”（浏览）导航到其位置。请注意，您在本页中使用的名称必须与 TS 网关网站绑定的网站证书上的常规名称或对象名称匹配。
  8. 在“Public Name Details”（公共名称详细信息）页面中，从下拉列表的“Accept”（接受）请求中选择该域名（在下方键入），然后在“Public name”（公共名称）框中，键入与向此 URL 颁发的证书的名称匹配的公共名称，在本例中，名称为 tsg.contoso.com。然后单击“Next”（下一步）。
  9. 在“Select Web Listener”（选择 Web 侦听器）页面中，单击下拉列表并选择先前创建的 Web 侦听器，然后单击“Next”（下一步）。
  10. 在“Authentication Delegation”（身份验证委派）页面中，选择“No delegation”（无委派）选项（但客户端可以直接进行身份验证），然后单击“Next”（下一步）。
  11. 在“User Set”（用户集）页面中，检验是否已选中默认选项“All Users”（所有用户），单击“Next”（下一步），然后单击“Finish”（完成）并加以应用。
如果您双击规则并转到“Path”（路径）选项卡，您将会看到我们拥有的唯一路径是 /rpc/*。这是由于我们使用的是 Exchange Server 2007 Outlook Anywhere 向导。

测试和监视客户端访问
如前所述，您需要 RDP 6.0 或更新版本的客户端来连接 TS 网关。要配置 RDP 客户端应用程序，请将其启动并在“Computer”（计算机）字段中键入要连接的终端服务器的名称。依次单击“Options”（选项）按钮、“Advanced”（高级）选项卡和“Settings”（设置），然后键入 TS 网关服务器的外部名称，如图 3 所示。在我们的示例中，它是 Web 侦听器所绑定的证书上的名称，我们的 Web 发布规则使用该侦听器接受传入请求。请注意，在本例中使用的是 Windows NT® LAN Manager 身份验证。完成后，依次单击“OK”（确定）和“Connect”（连接）。您将得到一个身份验证提示。键入有权访问终端服务器的用户的凭据，并单击“OK”（确定）。
图 3 配置 RDP 客户端（单击图像可查看大图）
请注意，RDP 6.0 客户端（用于 Windows XP 和 Windows Server 2003）将显示图 3 中所示的屏幕。系统将给您进行两次身份验证提示，第一次身份验证是针对 TS 网关计算机，第二次身份验证是针对要访问的终端服务器。这是很重要的一点，因为您可能认为这是由于 ISA Server 配置所致，实际上 ISA Server 根本不处理身份验证，因为 Web 发布规则适用于“所有用户”，这就允许通过 ISA 防火墙进行匿名连接。
Windows Server 2008 附带的 RDP 客户端有“Use my TS Gateway credentials for the remote computer”（将我的 TS 网关凭据用于远程计算机）选项，如图 4 所示。选中此选项后，您不必两次键入凭据，并且用户体验更好。在应用 SP1 之后，还可以在 Windows Vista 上使用此单一登录选项。
图 4 Windows Server 2008 RDP 客户端（单击图像可查看大图）
您可以使用“Monitoring”（监视）选项通过 TS 网关管理器监视连接。未经授权的用户尝试连接服务器时，TS 网关服务还能提供详细信息。在图 5 中，事件查看器显示了无权通过 TS 网关执行连接的用户的连接尝试。
图 5 登录 TS 网关服务的事件（单击图像可查看大图）
由于在 Web 发布规则中启用了“Requests appear to come from the ISA Server computer”（请求显示为来自 ISA Server 计算机）选项，因此对于此事件，会记录 ISA Server 2006 的内部 IP 地址。如果您要注册原始客户端 IP 地址，您将需要更改 ISA Server 2006 Web 发布规则并在“To”（目标）选项卡上选择“Requests appear to come from the original client”（请求显示为来自原始客户端）选项。

从 ISA Server 实施监视
使用 ISA Server 2006 可支持性更新包的新功能可以密切关注并了解内部网络的每个连接。图 6 显示了一个突出显示的连接，而且在 Request:行，RPC_IN_DATA 谓词指示 RPC over HTTP 代理的 URL。
图 6 使用可支持性更新的 ISA Server 2006 日志记录（单击图像可查看大图）
如果您继续查看日志记录，应看到其他 RPC over HTTP 谓词 (RPC_OUT_DATA)。有必要了解使用了哪些 HTTP 方法，哪些是 RDP/HTTP 的 RPC_IN_DATA 和 RPC_OUT_DATA，因为如果您配置了 HTTP 筛选来阻止这些方法，那么将在 ISA Server 上阻止流量。如果您希望锁定您的环境，则可以将 RDP/HTTP Web 发布规则配置为仅允许这两种方法。若要获取通常用于发布的 HTTP 方法的详细信息，请阅读文章 "HTTP Filtering in ISA Server 2004"（technet.microsoft.com/library/cc302627）。

第二个方案
在此方案中，TS 网关将使用位于另一台服务器上的 NPS 中央策略。我们将强制对从远程通过 TS 网关连接的客户端实施 NAP 策略。此处使用的组件与方案 1 中使用的组件相同，仅添加了 NPS 服务器。但是，由于 NAP 强制执行，因此将在客户端使用更多的组件，如图 7 所示。
图 7 方案 2 拓扑的主要组件（单击图像可查看大图）
下面介绍各个组件。在 Windows Vista 客户端上，系统运行状况代理 (SHA) 由负责监视并报告客户端运行状况的客户端组件组成。虽然 Windows Vista 附带了 Windows SHA，但也有其他一些供应商创建了自己的 SHA。
客户端上的 NAP 代理负责在客户端尝试访问网络时建立与 NAP 强制服务器的通信。NAP 代理会向该服务器发送客户端的“运行状况声明”(SoH)。
在 TS 网关上，TS 资源授权策略 (TS RAP) 组件允许您确定哪些计算机可用于接受传入的 RDP 请求。TS RAP 还会确定允许哪些用户与特定服务器建立 RDP 连接。
中央 NPS 负责控制用于规范内部计算机访问的条件、约束和设置。中央 NPS 上的系统运行状况验证器 (SHV) 负责评估客户端提交的 SoH 是否符合管理员设置的策略。
现在让我们将 TS 网关更改为指向 NPS 中央服务器。打开“TS Gateway Manager Console”（TS 网关管理器控制台），右键单击服务器的名称，并选择“Properties”（属性）选项。在服务器的属性窗口中，单击“TS CAP Store”（TS CAP 存储区）选项卡并选择“Central NPS server”（中央 NPS 服务器）。接下来，键入 NPS 服务器的名称或 IP 地址，然后单击“Add”（添加）按钮。您将会看到一个“Shared Secret”（共享密钥）弹出窗口。键入密钥并单击“OK”（确定），然后再次单击“OK”（确定）关闭窗口。您必须要记住这一密钥，因为它将用于 NPS 服务器。
假设 NPS 已安装在另一台服务器上，以下是您需要执行的步骤：
  1. 打开网络策略服务器控制台，并在左窗格中单击“NPS (Local)”（NPS（本地））。
  2. 在右窗格中单击“Configure NAP”（配置 NAP）。将显示“Select Network Connection Method for Use with NAP”（选择要与 NAP 配合使用的网络连接方法）页面。
  3. 在“Network Connection Method”（网络连接方法）下方，从下拉框中选择“Terminal Services Gateway (TS Gateway)”（终端服务网关（TS 网关）），然后单击“Next”（下一步）。
  4. 在“Specify NAP Enforcement Servers Running TS Gateway”（指定运行 TS 网关的 NAP 强制服务器）页面上，单击“Add”（添加）按钮。
  5. 在“New TS Gateway”（新建 TS 网关）窗口中，键入 TS 网关服务器的友好名称以及 IP 地址。然后在此窗口底部键入共享密钥（使用 TS 网关服务器配置中的密码）。然后，单击“OK”（确定）。
  6. 在“Configure Client Device Redirection and Authentication Methods”（配置客户端设备重定向和身份验证方法）页面中，可以指定将要重新定向的设备以及允许的身份验证方法（密码或智能卡）。对于本示例，保留默认选项并单击“Next”（下一步）。
  7. 在“Configure User Groups and Machine Groups”（配置用户组和计算机组）页面中，添加可以建立此连接的用户组。对于本示例，单击“User Groups(Required)”（用户组：（必需））下方的“Add Users”（添加用户）按钮并选择“Domain Admins”（域管理员）。依次单击“OK”（确定）和“Next”（下一步）。
  8. 在“Define NAP Health Policy”（定义 NAP 运行状况策略）页面中，您将会看到默认 SHV 已被选中。另请注意，在此页面底部，拒绝了对未兼容计算机的访问。保持选中默认选项并单击“Next”（下一步）。
  9. 在“Completing NAP Enforcement Policy and RADIUS Client Configuration”（完成 NAP 强制策略和 RADIUS 客户端配置）页面中，查看先前选择的选项。还可以单击“Configuration Details”（配置详细信息）超级链接，这将打开一个 HTML 页面，其中汇总了您的选择。完成后，单击“Finish”（完成）。
此向导可对众多重要策略（连接请求策略、网络策略和运行状况策略）的设置进行配置，因而显著减少了配置此方案 NAP 所需的工作。

客户端又将如何？
至此已对服务器进行了完全设置和配置，那么对客户端又必须做些什么呢？
要利用 NAP 强制策略，需要使用 Windows Server 2008 或 Windows Vista 作为客户端。对于 Windows XP，您需要安装 SP3（其包含 NAP 客户端）。
除了操作系统要求之外，还需要在客户端启用一些相关服务和设置。其中包括以下内容：
  • 将 TS 网关服务器名称添加到客户端上的“受信任服务器”列表中。
  • 启动 NAP 代理服务并将服务启动类型设置为“Automatic”（自动）。
  • 启用 TS 网关隔离强制客户端。
为了简化此解决方案的部署，Microsoft 已经创建了终端服务 NAP 客户端配置命令 (Tsgqecclientconfig.cmd)，可以从 go.microsoft.com/fwlink/?LinkId=122267 下载这一命令。运行此命令后，客户端将被配置为 TS 网关的 NAP 强制客户端。请注意，此命令必须使用提升的权限运行。
在整篇文章中，我们的主要目标不仅是介绍和说明 Windows Server 2008 上提供的新 TS 网关功能以及展示如何通过 ISA Server 2006 对其进行安全地发布，而且还要让您对两种产品的结合可为您公司带来的安全优势有全面的了解。
在当今世界，几乎所有成功的企业都要求能从任何位置进行连接。但是，这种连接性不能以牺牲用户的体验为代价。而且更为重要的是，所有这些操作都必须以安全可靠的方式完成。

Thomas W. Shinder 博士是 MCSE 和 ISA Server 方面的 MVP。自 1996 以来他曾担任过技术培训师、撰稿人和顾问。Shinder 博士编写了六本 ISA 防火墙方面的书籍。他还是 ISAserver.org（Internet 上 ISA 防火墙管理员和爱好者的最大社区）的创意先锋和始做俑者。

Yuri Diogenes 拥有 MCSE+S、MCTS、MCITP、Security+、Network+ 和 CCNP 认证，是 Microsoft ISA Server/IAG 团队的安全支持工程师。他为 Microsoft TechNet Library 和 ISA Server 团队博客撰写了多篇文章。从 1993 年起，Yuri 便在 Microsoft 从事技术工作。在加入 Microsoft 之前，他曾担任过 Microsoft 培训师、支持分析师和顾问。


IIS 7.0
IIS 7.0 中的 10 大性能改进
Mike Volodarsky
概览：
  • 最小化应用程序占用空间
  • 降低带宽成本
  • 使用增强的缓存功能

目录
进一步瘦化 Web 服务器
构建在瘦操作系统上
专用的应用程序拓扑
改进的应用程序支持
增加应用程序密度
通过压缩来降低带宽
媒体比特率限制
输出缓存
将 ISAPI 代码转换成 IIS 7.0 模块
服务器可扩展性
结束语
当我与计划采用 IIS 7.0 的公司会面交谈时，每次都要提到的一个问题就是迁移到 IIS 7.0 是否会改善服务器或应用程序的性能。答案
通常是肯定的，但如果在将应用程序刚刚迁移到 IIS 7.0 时并没有看到任何性能改善，也请不要感到惊讶。
要理解这一点，您需要了解最新版本自身的一些特点。IIS 6.0 是工程版本，旨在实现以下三个目标：更强的安全性、更高的可靠性以及改进的性能。相比之下，IIS 7.0 是一个平台版本。它的目的是将其前身所拥有的高质量基本 Web 服务器核心转换成支持重要最新部署和管理方案的模块化和可扩展平台。
体系结构的许多变更和新增功能实际上可能会对 Web 服务器的性能产生负面影响 — 例如，假定有一个关键变更，它将经过严格优化的 Web 服务器代码路径拆分成了多个独立模块，这会导致这些模块将不再受到 Web 服务器的特殊对待。但是 IIS 7.0 则不然，它不但保留了其前身的出色性能，在某些领域甚至有所突破，这一切都应归因于 IIS 团队在性能方面所做的大量卓有成效的工作。根据我在 Web 服务器核心和集成管道方面的工作经验，我可以负责任地说，要实现这一目标需要大量的独创性设计，还需要在实现产品时付出艰辛的劳动。
尽管如此，与之前的其他 IIS 版本相比，IIS 7.0 还是极有可能会提供显著的性能改进并减少服务器场的性能相关成本。
您大可不必只为了解这些优点而迁移到 IIS 7.0，您可以通过某些环境进行了解。例如，Microsoft.com 的 CPU 效率出现了 10% 的改进（可在 Microsoft.com 团队博客上找到完整的分析，网址为 go.microsoft.com/fwlink/?LinkId=122497）。您可能还会发现在某些特定领域也有显著的改进，例如安全套接字层 (SSL) 和 Windows® 身份验证（现在二者均在内核中执行），此外在多核和多处理器计算机中它也可以提供更出色的垂直可伸缩性。
但是，真正的 IIS 7.0 动力并不是来自于对现有功能的增量性能改进。相反，应该说这些改进源自于您会主动使用的新增功能。这些功能通常来源于平台的灵活性和可扩展特性以及一些新的性能特性。在本文中，我将向您展示通过迁移到 IIS 7.0 可以实现的 10 个最重要的性能改进。

进一步瘦化 Web 服务器
部署瘦 IIS 7.0 服务器的能力借用的是服务器的模块化体系结构。实际上，所有 Web 服务器功能都是以模块化组件的形式实现的，可以单独进行添加或删除。这样一来，您可以将那些对于应用程序的操作而言并非必需的所有服务器功能删除，这可以带来一些明显的益处，包括极大地减少受攻击的机会、减少操作内存占用量以及改善性能。
完整的 IIS 7.0 Web 服务器功能集由 44 个模块组成，包括为集成管道提供服务的本机 IIS 模块和 ASP.NET 模块。这些模块可以提供多种服务，如身份验证（Windows 身份验证和摘要身份验证模块）、应用程序框架支持（FastCGI 模块）、应用程序服务（会话状态模块）、安全性（请求过滤模块）和性能（输出缓存模块）。对于仅提供静态内容的最小 Web 服务器，它只需要 2 个模块就可以正常运行！
对于那些不必要的模块，其开销可能会相当显著 — 例如请求记录和失败请求跟踪模块。将此类模块从不需要它们的环境中移除可得到更高的总吞吐量和更快的响应，因为这可以减少服务器工作负载收到第一个字节的时间 (TTFB) 和收到最后一个字节的时间 (TTLB) 度量。
图 1 显示了在使用完整功能集时、使用工作负载的默认功能集时以及使用工作负载必需的最小功能集时，针对 HTML 文件（静态工作负载）和 hello world ASP.NET 页面（ASP.NET 工作负载）进行简单吞吐量测试所得到的结果。尽管大部分不必要的功能在“完整”配置中已被禁用，但在“最小”配置中完全移除它们仍可使静态工作负载和 ASP.NET 工作负载的吞吐量都得到大幅提升。
图 1 在具有 100 个并发客户端的三种不同配置情况下，静态工作负载和 ASP.NET 工作负载的吞吐率（单击图像可查看大图）
此外，您可能还会发现在内存占用量方面的改进和更高的站点密度，尤其是在共享托管环境或使用大量工作进程的情况下。这通常是由于向每个进程加载的 DLL 变少，同时还消除了在模块初始化和请求处理过程中所需的内存分配工作。图 2 显示了在相同的吞吐量测试中内存的使用量（IIS 工作进程专用字节）。尽管在此示例中改进并不明显，但增长是符合预期的，因为 ASP.NET appdomain 的开销相对要高于移除模块所带来的基线节约开销。
图 2 在具有 100 个并发客户端的三种不同配置情况下，静态工作负载和 ASP.NET 工作负载的内存使用量（专用字节）（单击图像可查看大图）
IIS 7.0 可以对在应用程序级别启用哪些模块提供额外的控制，还可以通过模块预处理来根据工作负载控制模块使用量。尽管这需要高级的配置，但在多站点环境中或对于支持多个不同工作负载的应用程序，它可以提供更多的益处。
需要注意的一点是：确定所需功能时可能会比较棘手。您不但必须要考虑支持应用程序框架所需的最少功能，还必须考虑应用程序可能间接依赖的其他功能。例如，您的应用程序可能取决于特定的身份验证方法或依赖于各种 IIS 功能所提供的授权语义，这时如果移除它们可能会对应用程序的安全性产生负面影响。同样，您的应用程序可能依赖于某些模块来实现功能或性能效果，在这种情况下移除它们可能会导致错误的行为或性能损失。

构建在瘦操作系统上
Windows Server® 2008 还提供了操作系统级别的组件化功能，可用于进一步减少 Web 服务器的外围应用。Server Core 是 Windows Server 2008 操作系统的最小安装选项，其中包含最小的核心操作系统子系统集。Server Core 是用于瘦 IIS 7.0 Web 服务器的理想环境。
但是，在评估 Server Core 时，要知道某些限制可能影响您的应用程序。Server Core 不提供对 Microsoft® .NET Framework 的支持，这也意味着它不支持 ASP.NET、IIS 的 .NET 可扩展性以及 IIS 管理器。此外，由于没有 Microsoft 管理控制台 (MMC) 可供使用，因此本地管理任务需要使用命令行工具。从性能角度来看，如果您已正确利用 IIS 组件化，则在运行 Server Core 和完整的 Windows Server 实现时，您可能不会觉察到应用程序工作负载的内存占用量或吞吐量的差异。这是因为 IIS 和您的应用程序所执行的工作在两个平台上都是相同的。但是有一个地方可以看到差异：服务器的总占用量（包括磁盘空间和内存使用量）。
例如，图 3 显示了针对完整的 Windows Server 2008 配置和 Server Core 执行静态工作负载测试后，内存占用量的差异。尽管在这两种情况下 IIS 的内存占用量实际完全相同，但 Server Core 的总操作系统内存占用量更低，因此相比而言只需更少的内存即可支持此工作负载。在实际当中，更低的内存占用量可允许在性能较差的硬件中部署应用程序工作负载，因为它关注的是应用程序的处理需求而非操作环境。当然，这也使得 Server Core 成为用于虚拟环境的首选。
图 3 执行静态工作负载测试后，完整的 Windows Server 2008 与 Server Core 的内存占用量（单击图像可查看大图）

专用的应用程序拓扑
优化应用程序工作负载时，可将工作负载分成多个不同的部分。例如，您可以在具有 10 个 Web 服务器、5 个应用程序服务器和 3 个代理服务器（用来执行缓存和压缩操作）的场中运行应用程序，而不是在具有 30 个相同 Web 服务器的场中运行它。
采纳特殊处理的原因有多种。首先，许多应用程序工作负载的性能在很大程度上都取决于应用程序的多个部分之间可以竞争得到的各种共享资源（如内存）。此类资源竞争可能产生瓶颈问题，导致各种资源无法充分利用每台服务器。通过分离应用程序的各个部分，可使其能够随时访问被竞争资源，从而使同样的硬件资源组发挥更高的效率。
其次，特殊处理可使应用程序获得更合适的缓存区域，从而改善其性能。这包括低级缓存（如虚拟内存转换旁路缓冲器 (TLB)）、文件系统缓存以及其他操作系统和应用程序缓存。另一种区域资源来自 CPU。通过仅关注应用程序的特定部分来减少所发生的并行活动数后，应用程序可减少上下文切换次数并将 CPU 的工作效率提高到最大。
第三，特殊处理可实现特定于工作负载的优化，从而使应用程序各个部分的工作效率更高。当在同一个服务器上支持整个应用程序时，由于应用程序的不同部分存在需求冲突，因此许多此类优化都无法实现。
一个经常发生此类情况的位置是 IIS 和 ASP.NET 线程配置，它会对并发性产生直接的影响，并会间接影响许多应用程序的内存使用量、延迟时间和吞吐量。IIS 静态文件工作负载严重不同步，需要施加高并发请求限制，但它只需极少量的可用线程即可正常工作。另一方面，许多 ASP.NET 功能是同步的，但长时间处于阻塞状态，因此需要较高的线程数，而同时仍有其他一些功能需要较低的并发限制以降低对内存的影响。通过分离静态工作负载，将部分请求处理管道划分到不同的进程或服务器，可优化每个单独工作负载的并发性。
最后，通过允许应用程序分别独立扩展离散的工作负载或应用程序部件，特殊处理可以实现更出色的总体可扩展性。这可以使应用程序拓扑在最需要的位置提供更高的容量和冗余性，而不是要求您将相同的模板应用到整个应用程序。在这一模型中，专用资源可能是物理服务器、虚拟服务器甚至是同一台计算机中的应用程序池。
要评估在应用程序拓扑中特殊化可能带来的好处，首先应找出应用程序中占用大量进程或资源的瓶颈。这些方面应作为特殊化的首要候选对象，因为在隔离后它们可能具有显著的优化潜力，并且它们将会需要最高级别的横向扩展。接下来评估在隔离它们之后，应用程序的剩余部分是否能更有效地利用资源。最后，还需要评估将隔离的应用程序组件组合在一起所需的连接机制的开销。

改进的应用程序支持
IIS 7.0 可以通过 FastCGI 实现对应用程序框架的扩展支持，FastCGI 是一种受到许多开源应用程序框架支持的开放式协议，如果不使用 FastCGI，这些应用程序框架可能不支持与 IIS 稳定的、高性能的原生集成。与 IIS 长期以来一直支持的 CGI（通用网关接口）协议不同的是，FastCGI 可以在 Windows 平台上提供明显改善的性能。这主要得益于 FastCGI 可重用的进程体系结构，它免去了针对每个请求创建进程的繁重开销，使客户端可以利用永久保持活动状态的连接。
如果您现在是使用 CGI 或其他机制来使 IIS 支持应用程序框架，则迁移到 FastCGI 协议可能会得到更好的性能（有时还可以得到更好的稳定性）。
利用此支持的第一个应用程序框架是 PHP。实际上，IIS 团队一直在与 Zend Technologies 进行直接的合作以确保 IIS FastCGI 实现能与 PHP 良好配合，并能够给 Windows 中的 PHP 框架带来性能的改进。（有关此项目的详细信息，请参阅我博客上的帖子，网址为 go.microsoft.com/fwlink/?LinkId=122509。）如果您使用的是混合 Web 服务器技术（例如运行在 IIS 上的 ASP 或 ASP.NET 应用程序，以及使用其他技术的 PHP 或与 FastCGI 兼容的其他应用程序框架），则可以在 IIS 7.0 平台上进一步巩固这些应用程序。
通过将 PHP 和其他应用程序框架迁移到 IIS 7.0 和 FastCGI，您可以充分利用 IIS 7.0 的各种功能，包括 ASP.NET 集成管道。利用它可以通过 ASP.NET 服务非常方便地增强应用程序框架，而不必再将其转换到 ASP.NET。并且它还可以使那些使用不同框架的应用程序协同工作。有关如何使用它在不改动任何代码的情况下来增强现有应用程序并改善应用程序性能的示例，请参阅我撰写的《MSDN® 杂志》文章“使用集成的 ASP.NET 管道增强应用程序”（网址为 msdn.microsoft.com/magazine/cc135973.aspx）。

增加应用程序密度
IIS 7.0 包括许多旨在增加可在单台服务器上托管的应用程序密度的增强功能。这些增强功能是 IIS 7.0 引入的用来改进共享托管质量的众多功能中的一部分，其中包括改进的站点置备和更好的应用程序隔离。
从性能角度看，这些改进主要关注在两个方面增加应用程序密度 — 增加可在单台 IIS 7.0 服务器上置备的应用程序数量，以及增加可在给定时间内处于活动状态的应用程序数量。
请注意，IIS 7.0 能够在每台服务器上置备的应用程序数量要大幅超出以前，在某些内部测试中，单台服务器上最多可置备 100,000 个站点。这就为其赋予了创建和配置大量站点和应用程序的能力。
需要注意的一点是：要实现高速置备，需要迁移到新的配置 API，因为较老的配置 API 无法实现这一点。此外，并非所有 IIS 配置 API 都提供相同的性能特性，因此必须仔细选择以确保实现高性能。如果有疑问，可使用直接利用最新 IIS 配置对象的配置选项，其中包括 Microsoft.Web.Administration 命名空间、AppCmd.exe 命令行工具以及 IIS COM 配置对象（可通过脚本、.NET 或 C++ 代码进行访问）。
在使用持久应用程序和工作进程来执行请求处理的 IIS 体系结构中，可置备的站点数和可处于活动状态的站点数之间的差别是一个非常重要的区别。在此模型中，活动的应用程序会消耗服务器上更多的资源，但同时它也会由于缓存和免去初始化成本等原因而提供更好的持续性能。
由于每个活动的应用程序都需要特定数量的内存和单独的工作进程（如果使用的是建议的应用程序隔离模型），所以活动应用程序的数量在很大程度上取决于应用程序的内存占用量。因此，对于仅提供静态内容的单个应用程序，其工作进程可能只需要 3MB 的内存（甚至还可以与其他静态内容应用程序共享同一个工作进程），但某些动态应用程序即使在低使用率情况下也可能需要 100MB 甚至更多的内存。这样一来，在定义最大的可能密度时，与应用程序的内存使用量相比，IIS 工作进程本身的内存开销就显得无关紧要了。
在典型的共享托管情形中，经常可以看到被称为 80/20 分布的现象，即 80% 的请求被转到 20% 的站点。这会导致少量站点始终处于活动状态。为允许更大数量的活动站点，IIS 7.0 提供了活动的生命周期管理。这可以帮助您从非活动应用程序回收内存以允许托管更多的活动应用程序。
IIS 7.0 引入了一种称为动态空闲的新算法，它可以根据服务器的可用内存主动调整工作进程的空闲超时时间。随着内存逐渐减少，删除空闲应用程序的速度会加快，因此允许托管更多的活动应用程序。但是，在有内存可用的情况下，此超时时间可维持一个比较大的数值，以提供更好的性能并维护应用程序状态。除了允许更多的应用程序处于活动状态外，动态空闲还有助于避免低内存状况出现，这种状况会由于超负荷而导致严重的性能降级。
要实现大量活动应用程序的托管，还应采用 64 位操作系统，因为它允许操作系统处理超过 4GB 的内存。此外，您还可以将 IIS 工作进程配置为在 32 位模式 (SysWoW64) 下运行，此时它们本身消耗的内存更少，同时还允许操作系统比在 32 位环境中寻址更多的内存。

通过压缩来降低带宽
带宽成本是运行面向 Internet 的数据中心的首要成本之一，这一点不足为奇。此外，提供请求内容所需的带宽是应用程序感知响应中的一个关键因素。
减少提供应用程序响应所需的带宽的其中一种最有效方法是使用 HTTP 压缩。它可以大幅减少响应的大小，对于容易压缩的文本内容（如 HTML），通常可减小到原来的 1/10。其最大优势在于所有桌面浏览器都支持它，并且与由于发送较少的数据而节省的延迟时间相比，桌面硬件的解压缩开销显得无关紧要。此外由于压缩是基于 HTTP 1.1 协议中所定义的内容编码协商，因此启用它对于不支持压缩的客户端而言是安全的 — 这些客户端仅接收未压缩版本的内容。
IIS 7.0 也包含其前身引入的以下两个压缩功能：静态压缩和动态压缩。静态压缩会预压缩静态内容并将其保存在磁盘上，因此允许未来的请求无需压缩开销即可直接提供压缩后的内容。动态压缩会实时压缩响应，因此可以压缩由应用程序生成的响应。IIS 7.0 上的任意应用程序框架都可以利用动态压缩 — 包括 ASP、ASP.NET 或 PHP。
动态压缩通常并没有令人望而却步的 CPU 开销，这一点让很多人感到疑惑。实际上，动态压缩一般只占用繁忙服务器上不到 5% 的总 CPU 使用率。动态压缩的部署不受限制，从而可以使应用程序工作负载节省尽可能多的带宽。
可通过配置压缩强度进一步优化压缩开销，从而实现所需的压缩量与 CPU 开销之比。但还不只这些 — 您还可以对应用程序进行配置以启用压缩内容缓存功能，这将可以通过提供已压缩的内容来避免出现对命中缓存的压缩开销。请注意，ASP.NET 和 IIS 输出缓存都进行了升级，现在既可以为支持压缩内容的客户端缓存压缩的内容，也可以处理来自需要未压缩内容的客户端的请求。

媒体比特率限制
随着越来越多的站点提供媒体内容，导致许多企业的带宽成本激增。更为糟糕的是，由于发送到客户端的媒体内容实际上根本没有被用到，因而浪费了大量的媒体带宽。为什么会发生这种情况？
想想上次浏览时您观看在线视频或视频广告的情形。您是否一直在观看视频直到结束？在浏览视频网站时，用户通常都是在观看视频的一部分后就转到了另一个视频或离开该页面。但是，对于使用渐进式下载方式来提供视频的 Web 服务器而言，它所发送的数据通常要远远多于这几秒播放时间所需的数据。大部分数据根本就没有使用到。
如果视频的观看时间平均只有 5 秒，但在这 5 秒钟内提供（缓存）了 30 秒钟的视频数据，则您可能浪费了超过 80% 的带宽！
一年前，为了帮助一位使用测试版 IIS 7.0 的客户解决这一问题，我编写了一个带宽限制模块，它可以自动检测视频比特率并确保服务器以大致相同的速率向客户端提供视频。IIS 媒体团队选择了这一称为“比特率限制模块”的模块（请参阅图 4），您可以在 iis.net 下载中心下载它 (iis.net/downloads/?tabid=34&g=6&i=1640)。有关详细信息，请参阅 Scott Guthrie 的博客（网址为 go.microsoft.com/fwlink/?LinkId=122514）。
图 4 比特率限制最小化带宽使用率（单击图像可查看大图）
“比特率限制模块”会自动检测最常见的视频类型的编码速率。您可以控制想要预发送到客户端以消除初始缓存延迟的数据量（快速启动）以及希望在提供内容时使用的编码率百分比。您还可以配置许多其他选项（如最大带宽和并发连接），并可以通过编程方式来控制模块。

输出缓存
一般而言，对于执行重复工作的应用程序而言，缓存是改善其性能的首选方法。与特定于应用程序的性能改善不同（它们通常需要花费大量的精力并不断耗用应用程序的处理开销），缓存可以免去重复请求相同内容的开销。
在 IIS 7.0 之前，IIS 和 ASP.NET 都以 IIS 内核缓存和 ASP.NET 输出缓存的形式提供缓存功能。IIS 内核缓存可提供最优的性能，但主要限于静态内容。ASP.NET 输出缓存是用于缓存动态内容的相当完善的解决方案，但其性能较低而且内存管理效率也不高。IIS 7.0 中新的输出缓存弥合了 IIS 内核缓存和 ASP.NET 输出缓存之间的沟壑。
IIS 7.0 输出缓存可缓存任意应用程序（包括 ASP、ASP.NET、PHP 以及与 IIS 7.0 兼容的任何其他应用程序框架）中的动态内容。通过提供对内容可变性和过期的基本支持，这一新功能可缓存 IIS 内核缓存无法缓存的内容。并且，它允许针对满足限制条件的内容使用内核缓存。
此外，对于不需要高级缓存功能（如缓存依赖关系或无效化）的 ASP.NET 内容，IIS 7.0 输出缓存还提供了比 ASP.NET 输出缓存性能更高的替代方案，但只能在 ASP.NET 输出缓存中使用。
说到输出缓存，最大的挑战通常在于如何定义正确的内容过期、无效化和可变性策略，从而在维持所需的缓存准确性和时效性的同时实现高效的响应缓存。大多数情况下，只需正确配置缓存规则即可做到这一点，但有时则需要一些取决于运行时信息的更加复杂的策略。为此，IIS 7.0 输出缓存提供了可用于确保所需的缓存行为的编程 API。这可以为本来不会从缓存受益的内容释放缓存性能潜力。此外，ASP.NET 集成管道可使非 ASP.NET 内容使用 ASP.NET 输出缓存。
部署动态内容的输出缓存可能会比较棘手，可能需要一个多层战略来利用 IIS 7.0 平台上各种缓存功能的效率和灵活性。这通常包括描述影响响应的多个参数，还包括首先定义过期和无效化战略以维持缓存的最新状态，然后再确定哪些缓存支持所需的语义。
尽管比较复杂，但还是值得为此付出的。通过实现 IIS 7.0 输出缓存，应用程序的总吞吐量可获得多个数量级的改进，并且数据库和业务层组件的负载也会相应减少。

将 ISAPI 代码转换成 IIS 7.0 模块
IIS 7.0 引入了一个新的服务器 API，所有 IIS 7.0 模块均以其作为基础。它取代了先前版本的 IIS 中使用的传统 ISAPI 过滤器和 ISAPI 扩展 API。对于不需要支持先前版本的新模块，新的 API 更易于使用、可帮助生成更可靠的服务器端代码并且功能会更强大。
但是，IIS 7.0 为此提供了一个选项，允许通过利用可选 IIS 7.0 模块实现的兼容性层来支持现有的 ISAPI 过滤器和扩展。这将允许现有 ISAPI 组件无需重写代码即可在 IIS 7.0 上运行。
尽管使用现有的 ISAPI 投资可降低 IIS 7.0 迁移的门槛，但必须要充分考虑如何将传统 ISAPI 代码导入到新的 IIS 7.0 API 中。这样做可免去 ISAPI 兼容性层的开销，并产生 ISAPI 组件不具备的一些性能优势。这些性能优势可能会十分显著，具体视 ISAPI 组件所执行工作的而定。例如，对于缓存配置元数据以及与站点、应用程序和 URL 相关联的任何其他数据，IIS 7.0 模块 API 都提供内置的支持，这可以明显加快组件的内部操作速度。
此外，IIS 模块 API 允许模块异步执行长时间运行的操作，例如接收请求实体数据或发送响应。通过异步执行这些任务，服务器可以支持大量的并发客户端（成千上万），而不会由于请求线程数量的限制而最多只能支持几十个或最多几百个并发客户端。异步处理还可以消除处理应用程序中其他的请求和活动时带来的影响、减少内存使用量以及得到更好的 CPU 利用率。
除了特定的性能影响模式外，原生 API 还可以使开发人员更加灵活地执行请求处理任务。它允许您改进服务器组件的设计，从而实现更高的效率。例如，对于一些在以前需要通配符 ISAPI 扩展和子请求执行的特定过滤任务，现在既可以在初始请求过程中在模块中执行，也可以针对响应启用 IIS 内核缓存。
这可能会需要一些原型设计和试验以确定可以实现迁移好处最大化的最优设计。由于 ISAPI 和 IIS 7.0 模块 API 之间存在基本体系结构的差异，因此直接移植路由不一定是正确的。要告诉大家的好消息是 IIS 7.0 模块 API 比 ISAPI 使用起来更简单，因此迁移难度会降低。

服务器可扩展性
IIS 7.0 提供端到端可的扩展性。它需要事先了解有关服务器操作的大量知识，尽管如此，它还是展示了改进特定于应用程序的性能的巨大潜力。在对服务器体系结构和请求处理有了一定的了解后，可利用此扩展性来设计自定义的性能解决方案，以适合您的应用程序、工作负载和硬件的需求。
这可以采用以自定义的实现来替换任意内置的 IIS 7.0 功能的形式。尽管 IIS 7.0 功能已经做了大量的优化和性能测试，但肯定无法针对每种可能的用途都进行优化。因此，您可以通过构建针对特定工作负载的优化来改善特定模块的性能。例如，您可能希望重新实现目录列表模块来缓存内存中的目录列表，而不是使用文件系统 API 来枚举文件。
此外，可扩展性也可用于构建新的性能特性。此类功能的内置示例包括输出缓存、压缩模块以及多种其他内部缓存。
要确定自定义性能特性的需求，您需要了解应用程序和工作负载的性能特性以及需要解决的瓶颈问题。IIS 7.0 为性能分析提供了充足的诊断支持，可使需求和所需的可能设计功能更加清晰。

结束语
尽管 IIS 7.0 版本主要是一个功能版本，但它通过模块化的体系结构、可配置性和新增的性能特性提供了显著的性能改善。这些改善通过服务器合并和减少的带宽成本为企业成本节约铺平了道路，并且可以提供更好的用户体验。
要正确利用这些改进，通常必须针对当前的应用程序平台执行全面的分析并对 IIS 7.0 体系结构有充分的了解。如需有关本文中提及的 IIS 7.0 体系结构和功能的详细信息，请访问 iis.net。在 mvolo.com 中，我将撰写更多的博客文章来介绍有关主动利用 IIS 7.0 来改进应用程序性能和降低运营成本的技术。
Mike Volodarsky 之前是 Microsoft IIS 团队的一名项目经理。在过去的五年时间里，他一直在推动 ASP.NET 2.0 和 IIS 7.0 核心功能的设计与开发。现在，他正在利用 IIS 7.0 和 Windows Server 2008 为高性能 Web 场构建高级 Web 服务器技术。Mike 是《IIS 7.0 Resource Kit》一书的主要作者，并且经常为《MSDN 杂志》和 IIS 7.0 博客 (mvolo.com) 撰写文章。


移动性
轻松移动您的业务线应用程序
Matt Fontaine
概览：
  • 移动 LOB 应用程序的业务需求
  • 适用于 mLOB 开发和部署的强大平台
  • 无线安全、管理和配置

目录
启用和管理远程工作人员
安全和设备管理
互操作性
IT 和用户生产率
开发和分发
底线
除了发挥传统的语音、消息传送和生产率功能之外，如今许多企业都希望移动专业人员可以通过移动 LOB (mLOB) 应用程序
访问他们在办公室里使用的同一业务线 (LOB) 系统。候选系统通常包括客户关系管理 (CRM)、企业资源计划 (ERP)、商业智能 (BI)、财务和会计应用程序。显然，有了 mLOB 功能，移动用户便能够访问和使用丰富的业务应用程序并能够与活动数据进行实时交互，从而缩短销售时间、改善客户满意度并提高生产率。以下是一些典型的业务方案：
  • 销售团队可以使用 Microsoft Dynamics™ CRM Mobile 从任何位置查看和更新客户数据。另一个 mLOB 应用程序可以让其访问实时价格和库存数据。此外，销售人员还可以现场使用专业设备收集销售文档，从填写订单到收集签名一应俱全。实际上，Windows Mobile® 设备还有销售点应用程序，这些应用程序可以扫描条形码并读取信用卡，然后连接后端 LOB 数据系统进行处理。
  • 可以使用 ERP 解决方案安排现场服务工作人员（该解决方案会根据其职位和位置安排相关人员），还可使用启用 GPS 的 Windows Mobile 设备对这些工作人员进行自动跟踪。现场服务员工只获取当天的第一项工作；完成工作后，会自动为他们安排下一工作（请参见图 1）。
  • 在制造企业中，带有射频识别 (RFID) 扫描功能的 Windows Mobile 设备可在启用 RFID 的仓库中管理库存，以无线方式将信息立即上传至数据库。而且，有一些 Windows Mobile 设备抗震性很好，或者具备“本质安全”，适合用于危险的工作环境，可以在需要时传送数据并同时满足重要的安全要求。
  • 每天在客户会议与董事会议之间往来奔波忙碌的高级管理人员（或许距离家庭办公室很远），可以在任何位置获得财务信息、费用报告或客户信息。
这些情况和其他许多业务现状推动着那些一流的公司采用 mLOB 应用程序。本文将向您展示 Windows Mobile 与 Mobile Device Manager 如何协同工作，从而使 IT 专家能够部署丰富的移动功能，满足当今在这一领域不断增加的业务需求。
图 1 显示了已完成的现场服务工作的 mLOB 应用程序

启用和管理远程工作人员
Windows Mobile 已被证明是一个功能强大的平台，由于它可与现有基于 Windows® 的 IT 资产很好地配合，因此能为不同行业的远程工作人员提供便利，其移动消息和统一通信 (UC) 可由 Exchange Server 和 Office Communications Server 提供，而且用户和 IT 专业人员之类的人士均可享受到熟悉的 Windows 体验，这种体验只需很少的培训便可使用和理解。
随着 Mobile Device Manager 的发布，Windows Mobile 已越来越成为在业务环境中部署移动设备的首选。Mobile Device Manager 能够利用 Active Directory® 和组策略以无线方式置备、管理和保护移动设备，就好像这些设备是联网的 PC 或文件共享一样。策略和软件可以自动推送到电话中，而安全性、软件和硬件策略可通过丰富的库存报告功能进行精细管理。
推动这些创新力的理念是：移动设备应该是 IT 系统的自然扩展，而不是充当一种中间设备。对于想要大大超越 Windows Mobile 设备的消息传送、通信和基本生产率功能的公司而言，使移动设备成为网络上的一等公民是关键所在。
假如您处于一个想要取得这一改进的组织中会怎样？让我们看看 Windows Mobile 和 Mobile Device Manager 的功能如何通过为 mLOB 应用程序提供强大的平台使其成为可能。

安全和设备管理
上述功能使 mLOB 应用程序可以随时随地访问客户、财务、库存等重要业务信息，让其更具吸引力，但同时也在安全方面带来了挑战。用户可以在各个位置通过公共网络从小型设备输入和访问此类信息。
许多公司已经允许通过带有虚拟专用网络 (VPN) 连接的笔记本电脑对 LOB 应用程序以及 Intranet 上的其他共享资源和工具进行移动访问。Mobile Device Manager 将此功能扩展到了带有移动 VPN 的 Windows Mobile 设备（请参见图 2）。Mobile Device Manager 网管服务器在 Windows Mobile 客户端与网络之间启用了 Ipsec 加密的隧道，因此能够通过公共连接（如 Internet 或无线数据包网络）安全访问企业防火墙后的信息。Windows Mobile 在此设置中支持多种类型的加密。
图 2 采用 Mobile Device Manager 的高级设备管理、安全和移动 VPN（单击图像可查看大图）

互操作性
可以针对设备和存储卡上的数据设置并强制实施加密策略。使用 mLOB 应用程序的工作人员可以将保密信息下载到其移动设备，与其他网络设备相比，这些移动设备更容易错放。值得庆幸的是，可以通过数据连接对任何启用移动 VPN 的设备执行远程设备擦除（请参见图 3）。例如，如果药品销售人员将客户文件从其公司的 CRM 系统下载到其移动设备上，然后粗心地将这台设备落在了实验室，那么可能会产生非常严重的后果。
图 3 如果移动设备丢失或被盗，可以远程删除其中的信息。（单击该图像可查看大图）
Mobile Device Manager 专门于处理此类问题。实际上，Mobile Device Manager 几乎可以让您管理 Windows Mobile 设备功能和用户策略的所有内容，从禁用特定的硬件功能、控制可安装的应用程序到限制对某些网络资源的访问。所有这些均可通过一个解决方案完成，而且全部都可以无线方式完成。如用户具备 mLOB 功能，这些功能会变得更为重要。例如，您可能想要防止用户使用蓝牙网络，因为它可能使数据下载到不受控制的设备。您可能希望只有某些用户可以安装移动会计软件客户端，那么您可以将其设置为仅对需要的用户自动上载并安装。
其他资源
  • Microsoft System Center Mobile Device Manager 2008
  • Microsoft System Center Mobile Device Manager 2008 简介
  • Microsoft System Center Mobile Device Manager 2008：技术白皮书
  • Microsoft System Center Mobile Device Manager 2008 针对业务目标群体的介绍
  • Windows Mobile Line of Business Solution Accelerator 2008
另外，Mobile Device Manager 并不要求公司数据通过第三方网络运营中心 (NOC)，而 NOC 有可能产生可用性断点或安全断点。实质上，您几乎可利用 Mobile Device Manager 完全控制任何规模的移动设备部署，使部署、管理和保护 mLOB 功能变得更为便利。
网络集成带来了另一个优势：所有精细控制均通过 Active Directory 和组策略完成，无需单独从其他网络客户端管理移动设备。这节省了资金和时间。但是，最重要的是，它允许您采用一致的安全和访问策略。组策略是控制移动访问 LOB 数据的极有效方式。可以轻松地为需要访问的用户提供组策略；也可以一起或分别限制不需要访问的用户。
管理 mLOB 部署（通常是移动设备）时需要考虑的另一个重要事项是与现有基础结构的互操作性。与 Windows Mobile 不同，一些移动设备操作系统与其他形式的 IT 是互不相关的，它们有自己的语言、服务器和工具。当您在移动设备上提供复杂的应用程序和关键数据访问时，这些因素变得越来越重要。
Windows Mobile 和 Mobile Device Manager 提供了这种互操作性。作为一种 Windows 操作系统，Windows Mobile 可与其他基于 Windows 的 IT 资产（如 Microsoft® Exchange Server、Microsoft Forefront™、SQL Server® 和 Microsoft Office Communications Server）很好地配合。这种产品族内部的互操作性使得设计和构建尖端 mLOB 功能变得更加容易。
例如，Windows Communication Foundation (WCF)（用于启用应用程序间通信的 Microsoft .NET Framework 技术）可以将 Exchange Server 用作消息传递实用工具，供使用面向服务的体系结构 (SOA) 实现 mLOB。有时，可以使用新的 Sync Framework 使互联的工作人员保持最新状态，Sync Framework 可以轻松地在使用 SQL Server Compact 3.5 的 Windows Mobile 设备与 SQL Server 2008 上的公司数据之间同步数据。如果没有可与如此多的即用式网络资源配合使用的移动基础结构，这些方案可能更难以实现。

IT 和用户生产率
提高生产率是 mLOB 部署的重要目标。但如果功能对于工作人员来说难于使用、对于 IT 专业人员难于管理的话，成本可能会超过收益，或者至少降低了投资回报率 (ROI)。开发 Windows Mobile 的目的就是尽可能使其接近 Windows 桌面体验；这种熟悉感可以为解决方案涉及的各方提高价值。
在 IT 一方，Windows Mobile（使用 Mobile Device Manager）旨在使 Windows Mobile 设备融入网络的主流。完成这一目标使用的是大家熟悉的技术，尤其是 Active Directory 和 Windows Server®。Mobile Device Manager 是 IT 管理解决方案的 System Center 系列的一部分，为世界各地众多的 IT 专业人员所采用。熟悉基于 Windows 环境的 IT 专业人员可以使用他们已经了解的 Microsoft 管理控制台管理单元，而不必学习整套新工具和实践操作。
对用户来说同样如此。使用 Windows Mobile 有着类似于桌面的体验，这可以帮助用户迅速掌握使用方法。他们可以使用 Office Mobile 套件（包括 Office Mobile Outlook®）完成工作，而无需学习新的应用程序。他们不必担心设备管理，因为它是集中进行处理的。设计 mLOB 应用程序的工作方式时，可以采取相同程序的桌面版本用户熟知的方式；可以将新工具的外观和行为构建为类似于典型 Windows 软件。用户的熟悉程度有助于减少技术求助并降低事故严重性，这对 IT 专业人员而言无异是一种恩赐。
Windows Mobile 与 Mobile Device Manager 平台的其他方面也能提高生产率。除了快速重新连接功能以外，Mobile VPN 还提供了持久的无缝跨网络连接，从而可以在需要时帮助用户进行连接，同时也封堵了产生问题的一个常见根源。Windows Mobile 支持多种设备尺寸规格，这使公司不必标准化许多设备，同时保证员工仍能选择满足其需求的设备。设备多样性还有利于实施生产率更高的 mLOB 方案，如基于条形码的库存管理或通过启用 GPS 设备进行路由。

开发和分发
定义 LOB 应用程序的属性（数据丰富性、效率和专业功能）往往在专门针对基于应用程序的生产率而设计的移动平台上最有作为。Windows Mobile 为移动工作人员提供了类似于桌面的体验，使开发、分发和管理 mLOB 应用程序变得更加容易。
首先，Windows Mobile 支持一种称为 .NET Compact Framework 的 .NET 版本。由于 .NET Framework 是全球广为使用的一种编程工具集，因此许多 IT 操作内部都有一些开发技能，用以针对 Windows Mobile 自定义和创建 mLOB 应用程序。如果 IT 操作没有这种开发技能，那么市场上会有现成的技能。
Windows Mobile 还支持大量商用 mLOB 应用程序。Microsoft 将 mLOB 解决方案作为其 Microsoft Dynamics 产品系列（包括 Microsoft Dynamics CRM Mobile 和 Microsoft Dynamics AX Mobile Sales）的一部分加以提供。此外，Microsoft Dynamics Mobile 开发工具还为开发人员提供了将软件扩展到移动环境的技术。Microsoft 已经许下承诺，随着 Microsoft Dynamics NAV 支持的到来，让其他 Microsoft Dynamics 解决方案也具备移动性。最主要的 LOB 解决方案（如 SAP、Siebel、PeopleSoft 和 SalesForce.com）提供了其应用程序套件的 Windows Mobile 兼容的版本。
一旦购买或开发了 mLOB 应用程序，便可使用 Mobile Device Manager 和 Windows Server Update Services 3.0 对其进行无线部署和管理。可使用组策略来设置接收应用程序的设备以及它们可以访问的功能。请注意，可用同样简单的方式执行应用程序更新。

底线
由于越来越多的公司为其员工和管理人员提供了 mLOB 应用程序，因此对于要完成部署和维护 IT 系统任务的人员来说，有更多的新事项需要加以考虑。Windows Mobile 和 Mobile Device Manager 体现了面向网络的移动设备的愿景，为 mLOB 开发和部署提供了易于管理的平台。此平台不但最大程度地提高了安全性和用户生产率，同时将 IT 部门的工作强度和基础结构投资降到了最低。此外，由于 Mobile Device Manager 允许您将 mLOB 部署扩展到更多的用户，因而减少了每位用户的 mLOB 开发和部署成本，同时增加了每位用户的 ROI。这样，可以轻松使用 Mobile Device Manager 管理 Windows Mobile，让您能够用创造性思维考虑如何能最有效地使用 mLOB 应用程序，而不是首先考虑如何让其工作起来。

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


安全性
了解共享帐户密码的管理
Chris Stoneff
概览：
  • 共享和特权帐户密码的风险
  • 密码的存储方式
  • 管理和保护共享密码
  • 符合性

目录
了解问题
越长越好
滥用域
借口，借口，借口
规章制定者的意图
自动化方法
思考
越来越多地需要管理员来处理的一个常见任务是定期更改共享和特权帐户（如内置
管理员或根帐户、应急帐户甚至进程帐户）的密码。从定义可知，内置管理员或根帐户是每个版本的 Windows®、Linux 和 UNIX 都会附带的帐户，它总是使用相同的安全标识符 (SID) 或用户标识符 (UID)。应急帐户是创建用来便于紧急访问安全系统的其他帐户。出现问题时，其他非特权用户有时会使用这些应急或管理员帐户来访问关键系统。最后一个，进程帐户是用于运行服务、任务、COM+ 应用程序和嵌入项目（如必须登录的脚本和其他二进制文件）的帐户。
现在，您一般会使用安装脚本或映像来部署系统。此外，所有工作站或服务器可能都使用相同的管理员帐户名和相同的 8 位字符密码，并且很可能在系统部署后就一直没有更改过。为此，对于密码一词，我使用的是单数 "password" 而非复数 "passwords"。
为了使用最佳实践或满足符合性要求（如萨班-奥西利 (SOX) 法案、支付卡行业 (PCI) 或健康保险可携性与责任法案 (HIPAA) 的规定），管理员可能不得不更改这些密码。有时，当知道这些密码的前任管理员或技术人员离开公司时，为避免安全漏洞被公开或无法处理信用卡，管理员需要主动更改密码。除去这些因素，管理员也有责任更改密码以保证公司以及公司需要保护的数据的安全性。

了解问题
在处理这些帐户和密码时，必须了解以下几个要素：
  1. 密码使用时间越长，其安全性就越差。
  2. 通常情况下，密码越长就越难破解。
  3. 计算机的身份验证方式不会由于所属域的不同而发生改变。每个域中都存在工作组的核心。
“密码使用时间越长，其安全性就越差”这一说法有误导之嫌。它真正的意思是指如果想要侵入某台计算机，需要的只是时间。如果有人问“多长时间可以破解密码？”，通常情况下，我认为并没有确切的答案，但对于某个给定系统，以下线索可以帮助确定答案：
  • 有多少人知道此密码？
  • 是否这些人仍在本公司工作？
  • 如果知道帐户密码的其中一些人离开了公司，他们是否是未怀不满离开的？
  • 是否禁止从软盘、CD、DVD 驱动器或者网络进行引导访问？
  • 计算机的用户是否也是本地管理员？
  • 是否所有系统的特权帐户都使用完全相同的密码？
让我们从这份列表的开头说起，可以这样说，知道一个秘密的人越多，该秘密变得人尽皆知的可能性就越大。我记得在许多公司工作时，管理员觉得将共享密码设为相同值并告诉 IT 员工和实习生密码内容会更加方便，而不是在需要的时候为他们键入密码。不可避免地，随着时间的推移，公司就会开始发现计算机有了各种未经批准的设置，并且普通网络用户也可以登录这些帐户了。
如果知道密码的所有人员都仍在公司工作而且都是忠实可靠的员工，则此类访问风险并不算太大。但您永远不会知道何时会遇到一个必须对付的恶意用户。如果有这样的用户由于关系不睦而离开公司，您就有了一个敌对方知道如何使用难以跟踪的帐户侵入您的网络。
如果没有禁止从硬盘以外的位置进行引导访问，则可能会使用户能够使用未经授权的映像（如 Windows PE 或各种 Linux 系统）进行引导，这些系统可以直接读取计算机的文件系统并获取对计算机保护存储的访问权限。（应当指出的是，许多漏洞实际来自于内部因素。即使所有员工和实习生都仍在公司工作，也无法保证密码和系统是安全的。）
我知道许多之前的员工之所以继续登录网络只是因为他们可以登录。他们只是在指出不更改系统密码是一种不好的做法，他们的举动让人觉得很有趣，但如果想到他们一旦具有恶意企图时可能造成的损失，也会让人感到非常恐惧。
如果允许从 DVD 或网络进行引导，则可能无法审核用户所执行的操作。也就是说，Linux 引导盘或网络映像经常可以获取直接访问文件系统的权限。如果系统的特权帐户全部使用相同的用户名和密码，则系统很容易受到重大攻击。对此会在稍后进行详细介绍。
密码的使用期限和长度是相关的，具体取决于用来破解密码的方法。如果使用暴力方法破解密码，时间实际上是所面临的核心问题。密码更改频率越低，破解者获取密码所需的时间就越长。
与此类似，密码越长，字符组合变化可能会呈指数级递增，因此需要更多的时间才能破解。所以必须考虑密码字符数是少于 7 个、8 到 14 个，还是 15 个甚至更多。如果密码少于 15 个字符且使用的是 Windows 系统，那么是通过系统配置还是组策略来禁用 LAN Manager (LM) 哈希呢？
密码的长度有哪些影响？对于 Windows，答案很简单。略去 Microsoft 哈希运算进程的历史不表，Microsoft 针对密码实施以下两种类型的哈希运算：LM 哈希和消息摘要 4 哈希 (MD4)。默认情况下，Microsoft 使用 LM 哈希，并且除非显式关闭这些哈希的存储，否则针对所有密码存储的值最多为 14 个字符。这些密码被分为两个各由 7 个字符组成的值 — 第一个值用于前 7 个字符，第二个值用于后 7 个字符，如图 1 所示。
图 1 示例哈希表
帐户名 | RID | LM 哈希 | NT 哈希 | 密码 | 注释
Administrator | 500 | aad3b435b51404ee:aad3b435b51404ee | 31d6cfe0d16ae931:b73c59d7e0c089c0 | Blank PW | 此 LM 哈希与 20 个字符的密码 LM 哈希完全相同。
Administrator | 500 | 0182bd0bd4444bf8:aad3b435b51404ee | 328727b81ca05805:a68ef26acb252039 | 7 Char PW = 1234567 | 代表前 7 个字符的第一部分与 8 个字符的密码完全相同。
Administrator | 500 | 0182bd0bd4444bf8:36077a718ccdf409 | 0182bd0bd4444bf8:36077a718ccdf409 | 8 Char PW = 12345678 | 代表前 7 个字符的第一部分与 8 个字符的密码完全相同，但第二部分并不相同。
Administrator | 500 | aad3b435b51404ee:aad3b435b51404ee | b79d07c2ecb3d565:033ece663f5a0b2e | 20 Char PW = 9876543210 9876543210 | 此 LM 哈希与空密码完全相同，因为无法针对长于 14 个字符的密码创建 LM 哈希。
Fred | 1221 | e52cac67419a9a:224a3b108f3fa6cb6d | 8846f7eaee8fb117:ad06bdd830b7586c | Identical | 在这三个示例中，看看 LM 和 NT 哈希为什么完全相同？这意味着对所有帐户而言，密码都完全相同。Microsoft 从未改变过哈希算法。
Monday | 1385 | e52cac67419a9a:224a3b108f3fa6cb6d | 8846f7eaee8fb117:ad06bdd830b7586c | Identical
SvcAcctX | 1314 | e52cac67419a9a:224a3b108f3fa6cb6d | 8846f7eaee8fb117:ad06bdd830b7586c | Identical
因此，如果密码只有 7 个字符长，它会包含在单个 LM 哈希中。多年来，Microsoft 一直建议密码至少使用 8 个字符。原因是第 8 个字符会强制将密码拆分成两个 LM 哈希值。
但必须注意，LM 哈希已广为人知，非常容易攻破。在目前的解决方案中使用它们的唯一目的是维护与旧版系统（如 Windows NT® 4.0）的向后兼容性。
现在，应使用至少为 15 个字符或者最好更长的密码，因为根据定义，它们不会生成 LM 哈希。如果强制使用 15 个字符的密码在您的环境中并不可行，应同时在映像创建过程（通过使用本地策略）和 Active Directory® 组策略中禁用 LM 哈希的存储。
此策略位于以下位置：计算机配置\Windows 设置\安全设置\本地策略\安全选项。只需将策略“网络安全:不要在下次更改密码时存储 LAN Manager 的 Hash 值”设为“已启用”即可。
必须注意，尽管一个良好的策略会规定大小写字母以及数字或特定字符的使用，但一个更好的策略还会规定长度为 15 个字符或更多。

越长越好
目前有一种被用于侵入计算机的方法是 Rainbow Tables，它利用的就是 LM 哈希。但如果增加密码长度即可使 Rainbow Tables 失效。
许多戴着安全帽的管理员似乎对 Rainbow Tables 知之甚少（甚至一无所知），我对此感到非常惊讶。有许多方法都可以创建 Rainbow Tables 以应对不同的算法。但它们仅是 0-14 个字符的所有 LM 哈希的预计算列表。
对于 Rainbow Tables，攻击者必须首先获取 LM 哈希。这就产生了之前的问题，即如何引导系统（引导到 CD 或 DVD）或用户是否为本地管理员。最终，可使用各种免费工具（如 pwdump）在几秒钟之内提取这些 LM 哈希。通过使用 Rainbow Tables，对这些哈希值进行搜索并最终确定密码。
为了满足自己的好奇心，我针对系统的内置管理员帐户设置了一个密码。它包含 14 字符，其中有各种大小写字母以及特殊字符和数字。然后我使用了从 Internet 免费下载的 Rainbow Tables，在不到两分钟的时间里，我就提取了系统上所有帐户的密码哈希并确定了管理员密码。
必须承认，看到第一个 LM 哈希被攻破时的感觉真的是相当酷，接下来第二个哈希又被攻破，把它们放到一起就得到了密码。在此重申，如果使用之前介绍的策略禁用了 LM 哈希，即使不能彻底阻拦这一特殊的攻击平台，也可以使其受到严格的限制。

滥用域
即使位于域中也并不能解决问题。域中的计算机仍使用相同的身份验证方式。而且正如我先前所说，每个域中都存在工作组的核心。这一简单的说法并非始终显而易见。我曾做过许多有关此主题的交流，我发现自己经常会提醒管理员究竟是使用什么来访问计算机 — 用户名和密码。然后，我必须深入探讨 Windows 在工作组中的工作原理。
如果尝试访问某个系统，将会需要向远程系统提供用户名和密码。通过使用集成的身份验证功能，Windows 会尝试为您完成此操作。这意味着如果您访问另一个 Windows 系统，Windows 会使用您当前登录的用户名和密码。因此，当您尝试访问另一个 Windows 系统时，如果远程系统已经有了相同的用户名和密码，则系统不会再提示您输入该用户名和密码。
这也称为“传递身份验证”。此过程在工作组中和跨域时同样起作用。系统最多要求您输入用户名和密码，这意味着您只需重新键入登录信息即可。
现在，即使将某个工作站或服务器加入域并且 Active Directory 成为中心帐户存储库，存储在这些系统中的所有本地安全帐户管理器 (SAM) 或本地帐户并不会魔术般地消失。针对这些本地 SAM 所发生的唯一事情是它们不再受到管理和保护，而这正是问题的根源所在。您最后一次更改系统的内置管理员或根帐户是什么时间？更好的做法是，下载一个报告实用程序，以显示所有帐户的密码使用期限并查看结果是否能通过审核。
如果仍不明白我的意思，可以选择其中一个域工作站，然后以具有管理员权限的域帐户登录。打开系统的计算机管理并创建一个名为 ToldYouSo 的本地用户。为此帐户设置一个密码并将其添加到系统的本地管理员组中。在另一个域系统中重复此过程。
现在，在其中任意一个系统中，以本地 ToldYouSo 帐户身份登录并尝试通过转到 \\systemName\c$ 来访问另一台计算机。您将能够访问管理共享，甚至不会提示您输入密码！我希望这一示例并不会令您感到惊讶。但如果的确如此，您应从中吸取教训并允许我重申一下：所有系统都像属于某个工作组一样运行，这一事实并不会仅仅因为系统属于某个域而改变。
问题的关键在于，如果从不或很少更改共享和特权帐户的密码，则共享和特权帐户会面临着风险。整个网络遭到破坏只是时间早晚的问题。

借口，借口，借口
在与管理员甚至是 CIO 交谈时，我经常听到以下有关不更改这些帐户密码的主要原因：
  • 我们有成千上万个系统，没有足够的时间或人力来更改这些帐户。
  • 我们没有必要的预算。
  • 我们完全禁用了管理员帐户。
  • 我们至今还没有受到过威胁，因此我们并不认为这是个问题。
  • 审核人员并没有注意到。
尽管我对前两个原因深感同情，但它们并不足以作为借口。每当想到在由于某种原因而未解决这一问题的公司中存储有我的个人信息时，我就会感到不寒而栗。
的确，并非网络中的所有系统都存有敏感信息，但这些计算机的用户的确可能访问到敏感信息，如社会保障号、医疗记录或财务数据等。作为系统管理员应该考虑到，用户可以安装击键记录器和屏幕捕获实用工具、停止组策略的应用、将外挂程序引入各种子系统以捕获和传输数据。当用户在单个计算机上执行此类操作时，很难找出这一恶意用户，因为他的用户名是 Administrator。
您是否知道在 Windows 中禁用内置管理员帐户并不能阻止以该帐户身份登录？请尝试：以安全模式重启系统并以内置管理员帐户身份登录。您可能会能够使用在原始映像中发布给帐户的密码并操作成功。有关此行为的详细信息，请参阅 Microsoft® 知识库文章“如何在禁用 Administrator 帐户后访问计算机”(support.microsoft.com/kb/814777)。

规章制定者的意图
处理 SOX、PCI、HIPAA 和其他规章可能会使您感到头晕。理解其需求可能会相当困难，因为它们的范围非常广而且定义不够明确。通常情况下，对于所有此类规章的目的可总结如下。
首先，需要保证有权访问所有特权帐户和信息的人员能够随时访问并提供一种证明方法。在任何情况下这都是一种良好的行为 — 特权帐户是有权对任何系统执行任何操作的帐户。它是内置的管理员。它是应急帐户。它们是所有技术支持人员和每个管理员都可能知道的帐户。
如果选择实施某个解决方案以管理这些共享的帐户密码，您需要针对内置管理员帐户创建一个当前并不存在的审核跟踪。您将获得一个不固定的密码。由于解决方案是自动化的，因此您不会由于更改这些密码而花费大量生产时间。最后，由于此解决方案可提供审核功能，因此您的公司通过审核的机率也会更大。

自动化方法
处理此类帐户的最有效方法是定期更改帐户以消除两个帐户共享相同密码的情形。如果使用共享密码，对一个系统的危害也意味着对另一个系统的危害。换句话说，不应存在公共的本地帐户或域帐户。
在处理可管理和随机化这些密码的自动化解决方案时，不要仅仅满足审核人员的最低要求。例如，如果无需多花任何精力即可使用包含 15、20 甚至 127 个字符的密码，为什么仅使用 8 个字符呢（请参阅图 2）？
图 2 使用自动化方法创建长密码（单击图像可查看大图）
此外还要考虑每天随机化特权帐户，如图 3 所示。如果可以每个月或每两个月甚至每天这样做，就没有理由 90 天才执行一次。毕竟，如果程序已自动化，就不会为您带来任何额外的工作量。此外，如果定期执行此操作，则会强制用户从工具的审核检索界面恢复密码，从而提供之前并不存在的另一种审核跟踪。（如果您现在将书写密码放入信封并将信封放在某人办公室的一个安全、隐蔽的角落，则不会有类似使用密码管理解决方案时的那种密码审核跟踪。）
图 3 每天随机化特权帐户（单击此图像查看大图）
最后，确保在密码恢复后，在经过固定时段后可以并且将会重新随机化它们。我不是指您创建的计划随机化工作，而是说创建仅在几个小时而非几个月内有效的一次性密码。同样，此方法会强制用户从工具的审核检索界面恢复密码，从而提供一个审核跟踪。

思考
共享帐户密码的管理问题必须加以解决。这意味着应采用一种可靠且定期变更密码的方法。解决方案必须可扩展而且足够灵活。它还必须提供对密码的安全访问，并且需要审核通过工具执行的每项操作以及由使用工具的每位用户执行的每项操作。此外，生成的密码在每个系统中必须唯一，以避免由于共享帐户信息而出现系统被侵入的情形。
许多供应商着手解决这一问题已有多年历史，更多的新供应商最近才涉足这一领域。购买前请务必研究并试验所有的新工具，以确保您决定购买的解决方案真正适合您的环境。

Chris Stoneff 是 Lieberman Software 公司 (liebsoft.com) 的产品经理，该公司致力于安全和系统管理软件的开发。他最大的动力在于不仅要了解事物的特定运作方式，而且要了解背后的原因。


在过去的几周，我很幸运地以 IT 专业人士的身份参加了一门进修课程。随着夏季即将过去以及重返校园这种念头的产生，这看起来顺理成章。但我必须承认，这同时还是一个震动。
您知道，Microsoft 的杂志团队（负责发布《MSDN 杂志》和《TechNet 杂志》的组织）正在审核和改进我们的流程。我们最终决定，从 2008 开始，我们不再使用纸笔，完全采用数字设计（我承认，我们就是这样的革新者！）。严肃地说，我们应当适时将那些大型软件公司所追求的某些高效率变为事实。
调整我们的新数字工作流时，很快就突显出一个问题，我们受到了文章状态跟踪工具的限制。虽然该工具已经“数字化”，但它是基于一些应淘汰的陈旧技术构建而成的，而且用打印在每个版面顶部的彩色小方框充当辅助手段。这就是高科技吗？于是我开始构建一个概念证明替代工具，并发现 SharePoint 最适合这一情形。
长话短说，我对你们当中的 SharePoint 管理员有了新的崇拜。这不是要批评 SharePoint，而是对此平台的强大功能和灵活性的认同，但在 SharePoint 中创建自定义工作流解决方案确实是非常困难的！（令人欣慰的是，我们有新的“深入剖析 SharePoint”专栏来提供帮助。）虽然离开一线工作数年后，面对这一挑战对我而言非常有吸引力，但我要重返课堂。
那里有许多相当不错的资源，不但可以帮助您重新钻研基础知识，而且还可能帮助您汲取新的知识：TechNet 新的“我如何”系列视频 (technet.microsoft.com/cc138021)、我们在杂志中采用的全屏动画演示 (.com/video)、TechNet Edge (edge.technet.com) 等。但我认为或许应该就在《TechNet 杂志》扩大我们“基础知识”的范围。不是自夸，我认为我们在提供深层技术资料（您已经了解，但愿能受到您的青睐）方面已经做的非常出色。我始终坚信温故而知新。让我们尽情享受一下暑期的剩余时光吧，因为很快我们全部都要重返校园。—Joshua Hoffman

衷心感谢以下 Microsoft 技术专家： Nathan Bigman、Nino Bilic、Mai-lan Tomsen Bukovec、Eric Charran、Trina Gorman、Gershon Levitz、Thomas Marquardt、Mandy Maxwell、Michael Murgolo、Sanjeev Nair、Michelle Rutzer、Jez Sadler、Jim Truher 和 Shimon Yannay。


读者来信 读者心声

SharePoint 容量规划工具
我公司的员工人数不到 600，其中的大部分人在使用 PC 或内联网方面不是十分活跃。但对促进公司沟通和协作的呼声却很普遍。我认为 Windows® SharePoint® Services (WSS) 3.0 最适合我们的工作环境，但我的上司只批准了一台服务器的预算。
我尝试使用 SharePoint 容量规划工具，但它不允许模拟单一服务器模型。您知道有针对单一服务器的模拟选项吗？
—Allen M.
我没听说有针对单一服务器的选项。但是，如果不考虑所有用户的行为会很难确定规模。我会用一个四核 CPU 并在开始时使用 8GB 的 RAM。基本上，中型服务器应该可以满足要求。
Joel Oleson 编译了大量设定规模方面的参考，您可在他的博客上找到这些资料，网址为 blogs.msdn.com/joelo/archive/2007/07/09/capacity-planning-key-links-and-info.aspx。它们会帮助您做出满足公司需要的最佳决策。
—Pav Cherny，专栏作家，
深入剖析 SharePoint

Microsoft Bob
我知道 Windows 机密专栏文章“空间占用回顾”（2008 年 7 月，technet.microsoft.com/magazine/cc565089）旨在揭示 Windows XP 光盘上藏有 Microsoft® Bob 程序，但是我的孩子却十分钟爱它的另一个特点并用它学习计算机文字处理基础。我家的第一台家用计算机就带有 Bob，即 Window 95 随附的 NEC Ready。随着它们的不断发展，我的孩子们都伴它渡过了一段有趣的时光。
Bob 在该专栏里被贬为一项不良技术。实际上它是一款出色的软件，只不过是目标市场定位有误。. . 它不适合成人。它更适合儿童。如果它以儿童市场为目标，那么可能一切都大不相同。如果它从一开始就是一款为儿童设计的程序，可能连我的孙儿都会从中获益。
—Jim S.

印刷品该退位了
您 2008 年 7 月撰写的编者按“印刷品该退位了”很有意思（网址为 technet.microsoft.com/magazine/cc595615）。我个人认为，信息技术方面的印刷版专家丛书很快将会退出历史舞台并为数字媒体所取代。但是，根据您的统计，在接受调查的读者中，有 90 倾向印刷品。这项调查是否具有代表性？是不是仅有那些接触印刷媒体的人参加了调查？这个群组中没有包含那些新生代吧，他们不再向您一样订阅报纸或杂志，一切信息均从网络获得，对您的调查一无所知。
印刷文字的读者无法通过漂浮文字启动视频或网播。也不能通过在印刷品的 Internet 链接上单击鼠标打开主页、新闻组或博客。更不能单击鼠标下载印刷文字中所提到的加载项或工具。
总之：印刷的书籍已是昨日黄花。读者将很快意识到，DVD 的优点远胜于印刷书籍。他可以将 DVD 的所有内容复制到笔记本电脑中随时随地进行访问。
—Ulrich S.
感谢您给出的反馈！您对 90% 的读者倾向印刷品有所疑问，这一调查是在我们的印刷订户和 Web 读者中开展的（两者大致各占一半），该调查是我们年度编辑调研的一部分，采用电子方式进行。我们对既阅读印刷品又阅读在线资料的读者提问，其中有 90% 青睐印刷品。
我完全同意您对在线发布内容优点的评说（媒体丰富、影响面广、可以单击链接等），但我仍坚持阅读印刷的文章更具吸引力。印刷品给人带来更多的舒适感，更贴近读者的心扉，许多人都有此同感。也就是因为两种媒体各有千秋，所以我们会继续用这两种方式发布《TechNet 杂志》。再次表示感谢！
—Joshua Hoffman，主编


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

监视服务器
Mastering SQL Server 2005 Reporting Services Infrastructure Design
sybex.com
基础结构越复杂，潮水般涌向管理员的信息就越多 — 其中的大部分信息都会被记录到文件或数据库中。但要弄清楚所有信息，您需要一个分析引擎和一个工具，能够将经过分析的数据以有意义的形式呈现出来。有一个工具可以很方便地做到这一点，它就是 Microsoft® SQL Server® 2005 Reporting Services。此工具可帮助您将所有数据聚合在一起，然后以人类可读的格式显示出来。并且，它可以自动或根据需要将信息放到不同的位置，从而有效地向企业用户提供所需的近乎实时的数据，使其能够做出更明智的决策。
要规划、部署和管理成功的 Reporting Services 基础结构（或任何新的服务器基础结构），使其不但能满足公司需求而且可以随着公司的成长而扩展，必须要做好充分的准备、掌握相应的知识并具有不屈不挠的精神。如果打算部署一个 Reporting Services 实例，Joseph L. Jorden 撰写的《Mastering SQL Server 2005 Reporting Services Infrastructure Design》(Sybex, 2007) 可帮您了解并逐步完成成功操作所需的关键步骤。
在深入探讨有关 Reporting Services 部署的技术细节之前，本书首先介绍了系统实施方面一些容易忽略的问题，这一点做的非常不错。这些基本内容包括确定实施系统的原因和企业的使用需求，以及定义如何实现最终用户的预期目标。其中有一章专门介绍了报告系统中的变更管理策略。其中涵盖了不同的变更管理方法，并提供了变更管理请求表单的模板和指导原则。我不是一个喜欢宣扬官僚作风好处的人，但这里少量采用结构化形式可确保环境更加稳定。
介绍了 Reporting Services 的企业终极目标后，本书又深入探讨了部署问题，详细介绍了有关安装、扩展、自动化以及配置的基本原理。它还提供了关于如何与 Microsoft Windows® SharePoint® Services (WSS) 相集成的技巧。这可以为创建部署检查表开一个好头，从而帮助您避免各种错误。
在 SQL Server 2005 Reporting Services 中，一个很酷的新功能是特别报告功能。利用此功能用户可以动态创建报告。本书介绍了如何启用此功能以及如何设置 Report Builder 工具。随后，本书又介绍了如何创建报告订阅，以便通过电子邮件、文件共享或集成的 SharePoint 交付功能来按计划生成和分发报告。
随着时间的推移，所有系统都需要进行维护，因此在接下来的章节中介绍了一些必要的任务，如备份实例、管理报告内容以及利用可用日志进行故障排除。还有一个有关安全性的章节也相当不错，它介绍了在部署时要用到的身份验证和授权选项。
对程序员而言，他们会非常喜欢其中有关扩展 Reporting Services 的章节以及通过基于 Microsoft .NET Framework 的应用程序来访问和操作报告的章节。报表定义语言 (RDL) 是 Reporting Services 的其中一个基本内容，本书使用了一个章节的篇幅来介绍可供使用的一些关键要素、RDL 文件的结构以及创建和部署这些文件的基本知识。
本书最后介绍了优化 Reporting Services 部署性能的一些技巧。您从中可以了解到有关评估性能、修改配置文件以及使用“性能控制台”的信息。本书的附录也相当不错，它介绍了如何将 Reporting Services 与 SharePoint 相集成。如果您打算在您的环境中部署 SQL Server 2005 Reporting Services，最好参考一下本书。它真的可以帮助您轻松入门。

价格：49.99 美元（直销价）。

审核环境
Alloy Discovery Professional Edition
alloy-software.com
要想开展工作、对问题进行故障排除以及确认系统是最新的而且符合安全性和软件策略，必须能够在您主管的领域快速检索特定系统的信息，这一点非常重要。使信息格式不但对企业用户非常友好而且还允许快速对基础结构进行评估，这也是一个很大的优势（当然还要能够充分发挥您的管理才能）。此外，还可以利用对信息的快速访问来帮助您确定正在使用软件的人员，以确保用户都经过了适当的授权。您可能会非常感兴趣的一个此类盘存和审核工具就是 Alloy Discovery Professional Edition，它是由 Alloy Software 开发的。
此应用程序的设置很简单，您可以非常快速地针对 LAN 中的一组计算机启动审核。通过用户界面可将计算机分组到一个经过组织的视图中，此视图与 Internet Explorer® 中的视图非常相似，在设置了一个或多个可审核的计算机组之后，只需一个简单的单击操作就可以完成对组的审核。它收集的信息量非常庞大，范围涉及硬件、软件、打印设备、共享甚至是事件。此外，您还可以查看资产标记、序列号、正常运行时间统计信息、环境变量、网络配置和本地用户帐户。基本上来说，任何您想要了解的有关环境的信息都可以收集到，甚至不用离开桌面（但出于对您个人健康的考虑，强烈建议您每次都出去散一会儿步）。
除了按需审核计算机外，您还可以制定审核计划。对于位于直连 LAN 以外的计算机以及对于无法利用足够的权限远程连接以执行审核任务的计算机，Alloy Discovery 提供了一种基于代理的方法来审核目标计算机。对于此类审核，可将其编写成脚本，然后制定定期运行或通过代理运行的计划，最后再通过电子邮件将其从代理发送到主 Alloy Discovery 存储库。另一种选择是将代理放在闪存驱动器上，然后在不同的计算机中启动审核。审核后，您可自动或手动同步信息，具体取决于用于主存储库的方法。
Alloy Discovery 还具有多种过滤器，您可将其应用到审核结果中以对整体库存进行分析。例如，您可以了解到有多少台计算机需要升级内存以支持某个应用程序，或者在您的环境中哪些计算机运行的是 Windows® XP Professional，哪些运行的是 Windows Vista® Business Edition。
有了这些数据后，您可能会希望将其创建成报表。此应用程序可以将报表发布到 HTML 页面，您可以从中对其进行深入的分析。您还可以设置定期任务以持续生成这些报表（此选项非常适合于“网络操作中心”）。此外，您可将所有审核信息导出到 XML、CSV 或 Microsoft Excel® 中用于各种用途，例如，向审核人员提供证据。

价格：基本产品 795 美元（直销价），每个节点另加 3 美元。﻿
利用 Alloy Discovery 监视环境（单击图像可查看大图）

管理密码
Password Corral
cygnusproductions.com
密码是当今互联世界不可缺少的一部分。（至少在所有信息都基于生物特征之前或实现某种形式的完全互信的乌托邦之前都会如此，但这两种情况都不会在短期内实现。）如果您和我一样，很可能会针对不同类型的环境使用不同类型的密码，并且针对不同的介质使用不同的密码。
除了常规的主流用途以外，还有用于管理员帐户、服务帐户和各种域帐户的系统密码。当然，不同的密码对应不同的用户名。诸如此类，不胜枚举。在这种情况下，应该如何安全、轻松地跟踪所有的密码？
其中一种方法是使用密码存储库将所有数据锁入超强加密的文件中，而可以实现此目的的一种不错的解决方案就是 Password Corral。此应用程序问世于 2001 年，它易于使用且能够超强加密，可利用 Diamond2 或 Blowfish 加密方法将所有密码加密到一个文件中。它一直在提供试用和测试版，并且仍对目前版本和未来版本提供支持并会继续进行开发。
安装了此程序后，要得到您的新密码文件，只需创建一个新用户，然后在系统（或网络驱动器）中选择一个存放密码文件的位置即可。现在，毫无疑问，如果准备将所有帐户的全部敏感密码信息都放在一个 Password Corral 文件中，那么 Password Corral 的密码应该超强并且需要经常变更。它是您真正需要记住和保护的一个密码，因此必须巧妙地处理它。
通过身份验证后，Password Corral 会提供一个与 Internet Explorer 类似的用户界面，左边是分层式文件夹结构，右边是详细信息窗格。可将密码组织到树状结构的文件夹中。每个密码都可以有一个说明、用户名、密码、参考 URL、参考电子邮件地址和有关帐户的注释。此外，还可以告知应用程序每个帐户的密码策略、指定过期周期的天数以及给定密码过期前的剩余天数。
其中一个视图选项包括按过期密码过滤，这样您就可以查看下次使用时哪些帐户需要重置。另一个很酷的功能是可以让此程序为您生成密码，从而使您省去为每个帐户创建强密码的麻烦。此密码生成器也可以自定义，允许您设置所需的长度、复杂性和构成字符。
另一个不错的功能是在输入完所有密码后，您可以按照曾在其中输入过数据的任何字段来轻松地搜索它们，此功能非常适合于在深层次文件夹结构中查找很少用到的帐户。您还可以设置此应用程序的超时时间，这样一来，即使您忘记了关闭 Password Corral，此应用程序也会自动锁定，从而保护您的敏感信息。此应用程序在退出时还会默认自动清理剪贴板，以免使用后在缓存中留下复制的密码。
如果需要频繁访问密码，可使用应用程序的系统任务栏图标选项，只需双击它即可从此处启动应用程序。如果希望使用 Password Corral 并用它来存储别处的帐户，应用程序也允许您从文件导入它们，避免进行额外的数据输入工作。如果愿意，您甚至可以导出并打印密码 — 只是在完成操作后必须要把印有密码的纸吞掉！总而言之，它是一个非常有用的免费工具。

价格：免费。
利用 Password Corral 跟踪所有密码（单击图像可查看大图）

审核文件使用情况
File System Auditor
scriptlogic.com
维护对共享文件系统的审核跟踪可省去许多令人头痛的问题。但更为重要的是，必须要满足特定的信息保存策略标准。为了找出某个操作的执行人员和执行时间，可试一下 ScriptLogic 出品的 File System Auditor。此应用程序是一个集中式管理系统，可近乎实时地审核目标系统中文件的使用并可在 SQL Server 数据库中存储信息以用于使用情况报告。
File System Auditor 支持 Microsoft SQL Server Desktop Engine (MSDE)、SQL Server 2000 和所有版本的 SQL Server 2005（包括免费的 SQL Server 2005 Express）。每个受监视系统都需要安装一个代理，其用途是监视文件使用情况并将其报告给 SQL Server。安装后，使用 Database Wizard 来创建数据库存储库，其中将记录所有审核信息。
作为系统管理员，您现在考虑的可能是频繁使用的系统的带宽和冗余；但据称此应用程序使用的是智能审核系统，可将不同的操作合并到单一审核条目中。对于带宽，File System Auditor 首次访问文件时仅使用 100 个字节的数据，之后的每次访问仅使用 10 到 20 个字节。
您可能很疑惑为什么不使用本机 Windows 审核，因为对于专用监控应用程序而言，其集中式管理、事件结合和报表功能的灵活性和可用性会更强一些。此外，将所有信息放在一个 SQL 数据库中可便于从其他系统中进行引用。
配置了数据库后，可通过 Agent Configuration Console 在目标服务器上设置代理。可键入服务器的名称或使用 Active Directory® 浏览找到它。File System Auditor 还支持群集文件服务器，因此可键入群集实例的名称。接下来，安装代理服务（如果帐户有远程访问权限，则通过单击一个按钮即可完成）并选择代理应使用哪个 Windows 或 SQL Server 帐户来连接到 File System Auditor 数据库。
对于每台服务器，可设置三种不同类型的监控排除：Path Filters、Process Exclusion Filters 和 User Exclusion Filters。Path Filters 允许选择路径并选择是包括还是排除所有文件或特定类型文件的特定文件夹和文件事件 — 如权限更改、创建和删除。Process Exclusions 和 User Exclusions 允许针对与目标服务器上的特定进程相关的文件和文件夹事件来执行相同的操作，但不支持文件类型过滤器。
设置并开始收集审核事件后，启动 Report Configuration Console 来放置要使用的审核数据。要设置报表，可针对数据设置多个过滤器，包括用户、特定文件或文件夹事件、路径、服务器、进程和日期范围。此外，您可以制定报表计划并让应用程序通过 SMTP 服务器用电子邮件发送发布的报表。最后，要实时查看针对系统中的文件执行的操作，可启动 File System Auditor 的 Real Time Viewer，像“跟踪”日志文件一样监视原始事件。

价格：此程序和一个服务器许可证的起步直销价约为 800 美元。
利用 File System Auditor 审核文件使用情况（单击图像可查看大图）

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


实用工具特别推荐 Windows Memory Diagnostic
Lance Whitney

代码下载位置： Utility2008_09.exe (640 KB)

目录
获取 Windows Memory Diagnostic
测试内存
您负责管理的其中一台计算机出现了故障 — 冻结、崩溃、蓝屏。是某些硬件出现故障了吗？还是新安装的应用程序导致的？会不会是内存出现了故障？可用来确定问题根源的一种方法是使用免费的 Microsoft® Windows® Memory Diagnostic 实用工具。此工具可针对计算机的 RAM 运行各项测试，以确定各个模块中是否存在缺陷。

获取 Windows Memory Diagnostic
要使用 Windows Memory Diagnostic，请从以下网址下载并执行程序文件 mtinst.exe：oca.microsoft.com/en/windiag.asp。请注意，不必安装 Windows Memory Diagnostic。此工具会显示以下两个选项，如屏幕快照所示：
图 1 用于创建可引导介质的 Windows Memory Diagnostic 选项（单击图像可查看大图）
  • Create Startup Disk（创建启动盘），通过它可创建一张包含此程序的启动软盘。
  • Save CD Image to Disk（将光盘映像保存到硬盘），通过它可将程序的 ISO 映像保存到硬盘上。然后可将该映像刻录到光盘，并使用光盘创建软件将其变为引导盘。创建可引导介质后，重新启动计算机并从软盘或光盘启动诊断程序。
测试内存
程序加载后，即会开始扫描 RAM。Windows Memory Diagnostic 工具启动时默认为“Standard”（标准）模式，此模式包括 6 项不同的连续内存测试，每项测试都使用一种独特的算法来扫描不同类型的错误。在程序运行时，屏幕会显示每个单独测试的结果，列出它的进度以及正在扫描的内存地址范围。这 6 项测试完成后，此工具将使用同样的测试运行下一轮测试，并将一直持续下去，直至退出软件为止。但是，通常情况下，一轮测试即足以确定内存是否存在故障。
如需更详尽的测试，可切换到“Extended”（扩展）模式，此模式将运行 11 项不同的内存测试。还有一种仅运行 2 项测试的“Basic”（基本）模式，但为全面起见，应使用“Standard”（标准）和“Extended”（扩展）模式。如果要运行扩展测试项目，建议在夜间运行 Windows Memory Diagnostic，因为它要运行很长时间。
所有测试都完成后，工具会显示“Succeeded”（成功）或“Failed”（失败）消息。“Failed”（失败）消息后跟相关故障的详细信息，通常会针对其中一个 RAM 模块指出错误。根据计算机环境的不同，诊断结果可能会将内存问题缩小到某个特定模块。
此时，菜单中将出现一个“View errors by memory module”（按内存模块查看错误）选项。此选项可帮助您确定因出现故障而需要更换的特定模块。
在“Advanced”（高级）选项屏幕中，可在“Basic”（基本）、“Standard”（标准）和“Extended”（扩展）模式之间切换。在此处，还可在扫描过程中关闭处理器缓存，从而强制工具直接从 RAM 访问数据，从而确保测试进行的更加彻底。System Information（系统信息）命令会列出每个插槽中安装的 RAM 的容量和类型。
Windows Memory Diagnostic 支持基于 x86 的平台，包括 Intel Pentium 和 Celeron 处理器以及 AMD K6、Athlon 和 Duron CPU。但是，此工具最多只能处理 4GB RAM，超过该范围后将不再执行扫描。
在 Windows Vista® 的“管理工具”下以及 Windows Vista 安装介质的“修复”选项下，均安装有此诊断工具的某个版本。但是，Windows Vista 版本提供的可视化反馈或选项并没有这么多。因此，您可能会希望保存一个独立版本，以便在下次计算机出现故障时可以使用它。
Lance Whitney 是一位 IT 顾问、培训师和技术撰稿人。他投入了大量的时间和精力来改进 Windows 工作站和服务器。15 年前，当他还是一名记者时，就开始涉足 IT 世界。


深入剖析 SharePoint SharePoint 目录集成
Pav Cherny

代码下载位置： SharePoint2008_09.exe (2,775 KB)

目录
SharePoint 目录管理服务
自定义目录管理服务
SharePoint 和 ILM
结束语
Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 包括“目录管理服务”形式的目录同步功能，可为 Active Directory 中的 SharePoint 资源来置备启用邮件功能的联系人和组对象。通过
为 SharePoint® 资源置备这些类型的收件人对象，用户可在发送文档和其他信息时，直接从 Microsoft® Outlook® 通讯簿中选择 SharePoint 库、列表和组。
SharePoint 收件人对象还提供一种方法来控制 Exchange Server 组织中的邮件传输和格式转换。此外，通过在 Active Directory® 中设置邮件发送限制，还可以防止未通过身份验证的发件人（如垃圾邮件发送者）将邮件提交到 SharePoint 库。
但是，SharePoint 的目录管理能力是有限的，并且在撰写本文时，我们假设的是使用 Exchange Server 2003 作为底层邮件传送系统。如果您目前使用的是 Exchange Server 2007 或第三方邮件传送系统，则需要通过自定义的解决方案来扩展或替换内置的目录管理功能，以获得所需级别的互操作性。
在本专栏中，我将简要介绍 SharePoint 的目录管理功能，然后讨论一种克服现有限制的方法。我的前提是内置的“目录管理服务”仅满足最基本的用户需求。包含各种邮件传送系统和目录平台的环境需要更出色的灵活性和功能。通过使用自定义的解决方案来替换内置组件，可将 SharePoint 收件人信息与提供 API 或导入功能的任意目录解决方案进行同步。
为证实这一点，我将向您展示如何通过与 Exchange Server 2007 兼容的方式来同步 SharePoint 的收件人信息。同样，您可以使用自定义的解决方案将收件人信息与 IBM Lotus Notes 或其他系统进行同步。
您还可以获得通过元目录服务（如 Microsoft Identity Lifecycle Manager (ILM) 2007 Feature Pack 1 (FP1) 中包括的 Identity Information Server）来集中化目录置备过程的能力。具体地来，我将向您展示如何将 SharePoint 与 ILM 2007 相集成，以协调 SharePoint 文档库的目录对象的置备。您可在本专栏的随附材料中找到用于构建此解决方案的工具、源代码和分步说明，该材料可从 technetmagazine.com 网站的“代码下载”部分获取。

SharePoint 目录管理服务
与 Exchange Server 不同（Exchange Server 针对几乎所有配置和收件人信息使用的都是 Active Directory），SharePoint 依赖于配置和内容数据库。因此，SharePoint 必须将启用邮件功能的库、列表和组的收件人信息从它的数据库传播到目录中。毕竟，邮件传送客户端更希望在通讯簿中查找收件人信息，而通讯簿通常是通过目录对象生成的。
SharePoint 预设包括一个用于此目的的“目录管理服务”，它是电子邮件集成 Web 服务 (SharepointEmailWS.asmx) 的一部分，在 SharePoint 3.0 管理中心中，可在“操作”页面的“传入电子邮件设置”下进行配置。图 1 展示了内置“目录管理服务”的工作原理。
图 1 SharePoint 目录管理服务体系结构（单击图像可查看大图）
当您启用一个 Web 场用于目录管理然后向库、列表或组分配一个电子邮件地址来接收邮件时（例如，通过使用 EmailSettings.aspx），会隐式调用电子邮件集成 Web 服务以在 Active Directory 中置备相应的收件人对象。首先，SharePoint 将电子邮件地址信息存储在内容数据库中。接下来，SharePoint 代表您以 Web 应用程序池帐户的身份将置备请求发送到电子邮件集成 Web 服务。如果置备请求失败，则最终在内容数据库中会出现电子邮件地址信息，但在 Active Directory 中却没有对应的收件人对象。
其他资源
  • SharePoint 产品和技术网站
  • Windows SharePoint Services 技术中心
  • Windows SharePoint Services 开发人员中心
  • Microsoft SharePoint 产品和技术团队博客
导致置备请求失败的原因有多种。最常见的原因是缺少 IIS 元数据库访问权限。由于 SharepointEmailWS.asmx 的设计目的是作为应用程序池帐户的 Web 服务，因此这一 Web 服务会检查 IIS 元数据库以查看调用者是否是应用程序池帐户，如果不是则拒绝其访问，而无论您的 SharePoint 站点和 Active Directory 权限级别如何。
然而，SharepointEmailWS.asmx 将以调用者的身份来执行此访问权限检查，因此调用应用程序池帐户需要访问元数据库以验证其自身的访问权限。这将强制您授予应用程序池帐户提升的权限以使操作能够成功。
当然，在 Web 服务器上提升的权限将成为导致安全问题的一个根源。要控制对 ASP.NET Web 服务的访问还有更好的方法。并且，SharePoint 期望在管理中心站点查找“目录管理服务”，但在被锁定以减少攻击面的 Web 场中，此站点并非永久可用。因此，如果希望在 SharePoint 生产环境中使用内置的“目录管理服务”，必须接受弱化的安全性配置。
内置“目录管理服务”基于紧密耦合的客户端/服务器体系结构这一事实带来了更大的限制。Microsoft.SharePoint.dll 直接使用 System.DirectoryServices.dll，因此无法通过实现您自己的逻辑来自定义置备过程。例如，内置的“目录管理服务”实现不会写入所有收件人属性以支持 Exchange Server 2007，并且没有选项可供自定义属性生成规则。
无法实现您自己的逻辑这一事实也意味着无法自定义置备过程以实现一些功能，例如实现自定义批准。SharePoint 支持组的批准过程，但此功能是以管理中心站点为基础的。只有 SharePoint 场管理员可以批准未决请求，但 SharePoint 管理员不必负责批准 Active Directory 置备过程。
也许更为重要的是，没有用于启用邮件功能的文档库和列表的批准过程。如果启用目录管理，则必须为 Web 场中的所有站点管理员授予权限，使其可在 Active Directory 中创建启用邮件功能的联系人和组。另外，它也无法基于组织单元 (OU) 来构建收件人管理，因为每个 Web 场的所有收件人对象都放在相同的 OU 中。
您无法将收件人对象移到另一个 OU 中，因为“目录管理服务”期望在 SharePoint OU 中查找收件人对象，因此必须在 Active Directory 中为 SharePoint 管理中心应用程序池帐户授予管理权限。此外，还无法在 SharePoint 和 Active Directory 之间实现双向同步。在 Active Directory 中更改对象属性不会将更改传播回 SharePoint 环境。

自定义目录管理服务
至此我们已经了解到内置“目录管理服务”还留有一些空间来构建额外的灵活性，接下来我们就讨论一些替代项。我要告诉大家的好消息是 SharePoint 允许您实现自己的目录管理服务。在 SharePoint 3.0 管理中心，您只需在“操作”页面的“传入电子邮件设置”下将 Web 服务注册为远程“目录管理服务”即可。
如需有关部署和注册自定义 Web 服务的详细分步说明，请参阅随附材料中的工作表 "Directory Integration Based on a Custom Directory Management Service.xps"。此外，我的自定义 Web 服务还展示了如何在不使用 cmdlet 或 Exchange 管理工具的情况下，在 Active Directory 中置备与 Exchange Server 2007 兼容的收件人对象。对应的源代码位于 EmailIntegrationService 文件夹中。图 2 显示了该解决方案的体系结构。
图 2 自定义目录管理服务体系结构（单击图像可查看大图）
自定义 Web 服务的界面必须遵从“目录管理服务”界面的要求，如 SharePoint SDK 中所述。只要在 MSDN® 网站 (msdn.microsoft.com) 中搜索 "SharepointEmailWS"，即可找到所需的全部详细信息。也可查阅随附材料内 EmailIntegrationService\App_Code 文件夹中的 Service.cs 文件。此文件可实现所需的 Web 服务界面，而置备 Active Directory 对象的实际代码位于 SPRecipient.cs 中。例如，SPRecipient.cs 中的 UpdateRecipientAttributes 函数可生成所需的 Exchange Server 2007 属性。如果希望开发自己的自定义目录管理服务，则必须替换代码文件 SPRecipient.cs。
自定义目录管理服务是一个不错的工具，可用来克服提升的权限需求，并可将 SharePoint 与第三方目录或邮件传送系统相集成。您不必通过检查 IIS 元数据库来限制 Web 服务对应用程序池帐户的访问。相反，您可以向 Web 服务的 web.config 文件添加一个 <authorization> 小节（请参阅随附材料示例）。
但是，即使这样也仍然存在许多问题，因为您无法控制 SharePoint 是否以及何时调用目录管理服务。此外，在删除启用邮件功能的文档库或列表时，SharePoint 不会调用“目录管理服务”，因此会在 Active Directory 中留下一个无效的收件人对象。无论使用的是内置“目录管理服务”还是自定义解决方案，均无法保证 Active Directory 中的收件人信息与 SharePoint 资源的一致。

SharePoint 和 ILM
要实现可靠的目录集成，应考虑部署专业的目录管理包（如 ILM）。此系统依赖于基于拉动的目录同步模型。管理代理从其连接的资源中拉出信息、将信息导入共用的元目录，然后再从元目录导出到其连接的系统。源系统通常不会将其信息推入元目录中。通过拉动信息，可确保与每个同步周期保持一致。
另一个好处是 ILM 包括许多现成的管理代理，可支持 Active Directory、Lotus Notes 和各种其他系统。您只需针对 SharePoint 实现一个自定义的管理代理，即可将 SharePoint 信息与环境中受到支持的其他目录平台进行同步。
您必须实现逻辑才能从 SharePoint 检索所需信息、保存导入文件中的信息，并将导入信息传输到元目录。但是，您无需实现该逻辑即可将该信息从元目录导出到 Active Directory 或其他目录平台。图 3 展示了如何使用 ILM 实现从 SharePoint 到 Active Directory 的同步。此外，也可以在其他方向实现同步来为目录对象置备 SharePoint 资源，但这种方法可能被认为是不必要的或可选的。
图 3 基于 Identity Lifecycle Manager 的目录集成（单击图像可查看大图）
开发 SharePoint 管理代理的一个不错起点是 Alex Tcherniakhovski 的文章 "Connecting ILM 2007 with SharePoint Services Lists"，其网址为 blogs.msdn.com/alextch/archive/2007/09/02/wsslistsandilm.aspx。Alex 介绍了如何构建基于 ILM 的目录管理解决方案（依靠提交到文档库的基于 InfoPath® 的置备请求）。Alex 的管理代理从文档库中检索所有经过批准的请求并创建对应的元目录对象，然后可将这些对象导出到连接的目录中。
但在默认情况下，当您针对某个列表或组启用邮件功能时，SharePoint 不会生成基于 InfoPath 的置备请求。可通过一个自定义的目录管理服务来实现此目的，但稍后您会遇到我们之前提到过的一致性问题，因为在任何情况下 SharePoint 都不会调用目录管理服务。因此，建议您的管理代理直接从站点集合的列表和组中检索所需的 SharePoint 收件人信息。如果需要批准过程，您可在随后针对管理代理中的新资源生成基于 InfoPath 的置备请求，然后再处理所有经过批准的请求。
检索 SharePoint 信息的方法有多种。可直接从内容数据库中读取信息、使用 SharePoint 对象模型或利用 SharePoint Web 服务。
建议不要直接访问内容数据库，因为在未来的版本中，数据库的结构可能会发生改变，致使您的目录管理解决方案无法正常运行。
直接在管理代理中使用 SharePoint 对象模型同样也比较麻烦，因为对象模型要求在本地运行代码，但在您的环境中，在各个 SharePoint 场的 Web 服务器上安装 ILM 可能会使目录管理基础结构变得更加复杂。
您可能会考虑使用 SharePoint Web 服务，但这会引发另一个难题，因为通过 SharePoint Web 服务无法轻松访问所需的信息（如 SharePoint 组的电子邮件地址信息或“传入电子邮件服务器显示地址”）。
最终看来，似乎最好的办法是实现一个自定义 SharePoint Web 服务，然后使用 SharePoint 对象模型来检索所需的信息，从而以 XML 文档的格式将其返回给调用者。现在，可通过自定义 SharePoint Web 服务的单个实例来集中化 ILM 的部署并集成任意数量的场和站点集合，如图 3 所示。
还有一个值得一提的方面，即基于 ILM 的目录集成并不会免去对自定义目录管理服务的需要。此自定义服务不需要执行任何操作，因为 ILM 会置备目录对象，但您必须提供一个自定义服务，以便能够在 SharePoint 3.0 管理中心启用目录管理。否则将无法实现一些功能，例如，您将无法首先向组分配电子邮件地址。图 4 显示了最终解决方案的体系结构。
图 4 基于 Web 服务的 SharePoint 目录集成（单击图像可查看大图）
通过在 web.config 文件中设置 OpMode 参数 (<add key="OpMode" value="dummy"/>)，可将随附材料中包括的自定义目录管理服务变成虚拟服务。在此配置中，对于没有执行任何操作的置备调用，自定义服务会始终返回 SUCCESS 作为响应。
此外，自定义服务会公开一个 ResolveUsers 方法，SharePoint 管理代理可调用此方法将基于 NetBIOS 的用户帐户名称解析为可分辨名称（在置备组时必须执行此步骤）。（SharePoint 以基于 NetBIOS 的用户帐户名称列表的形式返回组成员身份信息，但 Active Directory 需要的是可分辨名称。）就是这些！有关如何部署最终解决方案的详细信息，请参阅随附材料中的 "Configuring Directory Integration based on ILM 2007.xps"。
WSS 3.0 和 MOSS 2007 包括一个“目录管理服务”，可将 SharePoint 与 Exchange Server 2003 相集成，以实现基于邮件传送的跨平台协作。
但是这存在着诸多限制。用户必须将内置的“目录管理服务”更换为自定义解决方案。您也可以使用专业的目录管理解决方案（如 ILM）将 SharePoint 集成到目录管理基础结构中。这将提供最高级别的灵活性，并有助于确保在基于拉动的同步模型中信息的一致性。

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


Windows PowerShell 字符串理论
Don Jones

目录
一个真实的案例
复杂的匹配项
这是一个包含字符串的世界
每当我在 Tech•Ed 或 TechMentor 等会议上演讲时，我都习惯发出一些公告，通常它们会帮助用户记住一些事物（例如，Windows PowerShell）的关键点。我的最新公告是，“如果您在 Windows PowerShell 中解析字符串，那么您是在犯错误。”
它出自我对作为面向对象外壳的 Windows PowerShell™ 的观点。如果您是要将服务列表转储为文本文件，然后再对该文本文件进行解析以了解启动了哪些服务（或类似的工作），您的工作量一定非常大。对于基于文本的 OS（如 UNIX），这是一种有效的方法，但 Windows PowerShell（以及 Windows® 本身）可让您以一种更为有效的方式使用对象。
视频
观看 Don Jones 演示如何使用 Windows PowerShell 来解析复杂的字符串。

甚至您自己的脚本都应该生成对象（而非格式化文本），以便此外壳的各种格式、筛选、导出和其他命令可用来处理来自您脚本的输出。（在我 2008 年 7 月的 Windows PowerShell 专栏中，您可以阅读有关自定义对象作为脚本输出这一概念的更多信息。）
最近在奥兰多举办的 TechMentor 会议上，我的一名学生 Fla. 提醒我几乎所有规则（尤其是常用规则）都有一些例外。“在 IIS 日志文件中查找内容会怎样？在这种情况下您完全不必解析文本吗？”
嗯，是的。值得庆幸的是，Windows PowerShell 在解析文本的字符串方面也不示弱，类似它在对象友好方面的表现。既然您提到了这一方面，IIS 日志文件、防护墙日志文件及其他基于文本的日志可以充当完美的示例。

一个真实的案例
实际情况是，我需要为我服务的公司解析一组防火墙日志文件。一位员工被发现访问了一些不适宜的网站，在后续调查过程中，人力资源部门需要一个有关该员工所访问网站的完整列表。虽然提取一天的日志文件就已经不容易了，但 HR 人员却希望追溯到前几个星期，我可不想手动做这项工作。
公司的动态主机配置协议 (DHCP) 服务器指明数月来该员工的计算机一直都在使用相同的 IP 地址（我们在本例中假设是 192.168.17.54）。当然，这并没有什么异常，因为这是一部台式计算机，很少会关闭。但由于防火墙日志保留了源 IP 地址的记录，因此我意识到 Windows PowerShell 可能会有所帮助。
常被忽略的 Select-String 命令是其中的要点。您还将需要具备正则表达式的应用知识（我在 2007 年 11 月刊的 Windows PowerShell 中介绍了这些知识）。
Select-String 命令允许查找完全是文本文件的文件路径、正则表达式或简单字符串。然后它将输出匹配正则表达式或简单字符串的各个日志文件中的每一行。开始我只想获取包含该员工的台式计算机 IP 地址的所有行。每个日志文件行都含有一个日期和时间戳，这正是人力资源人员所寻找的全部内容。
该命令如下所示：
select-string -path c:\logs\*.txt -pattern "192.168.17.54"
-allmatches –simplematch
–simpleMatch 参数指定我提供的模式只是一个简单字符串，而非正则表达式。图 1 显示了一部分输出，它也可以输送到文件中。请切记，该输出包含发现匹配项的文件名和行号，如果您想要返回某些时间点并发掘更多信息，这会非常有用。
本月 Cmdlet：Start-Sleep
下面的 cmdlet 可以让您在漫长的工作日中小憩一下。也就是说，Start-Sleep 让您的 Windows PowerShell 脚本有短暂的休息。
脚本需要快速暂停并不稀罕。例如，假设您需要启动一项服务，等待数秒钟后该服务启动并运行，然后执行其他一些依赖于该服务的任务。Start-Sleep 正适合上述情况。例如，运行 Start-Sleep 10 将使外壳暂停 10 秒钟。如果您需要更精确的控制，可以运行 Start-Sleep -milli 100 暂停 100 毫秒。Start-Sleep 会将外壳（包括脚本、管道和其他所有内容）按指定的时间量完全挂起。现在只要某个人编写我所需的 Start-Nap cmdlet 就行了。
图 1 Select-String 命令的输出（单击图像可查看大图）

复杂的匹配项
在我向 HR 人员提供完全符合他们要求的内容之后，他们发现这仍然不是他们所需的。我的报告包含对大量 IP 地址（如 207.68.172.246（MSN® 网站））的访问。接下来，调查人员请我将报告削减为仅包含对特定 IP 地址（他们认为有问题的某一网站）的访问。在本专栏中，我不会透露调查中出现的实际 IP 地址。我将在本示例中使用 207.68.172.246（尽管 MSN 网站通常不会被视为不适宜）。
这一请求的难度稍大了一些。在我使用的日志文件中，源和目标 IP 地址恰好彼此相邻并由逗号分隔。因此我只需将我的搜索字符串更改为 "192.168.17.54,207.68.172.246" 并重复搜索。
但在更为复杂的日志文件中，两个 IP 地址之间可能存储有变量数据，这样简单的字符串匹配将不会起作用。在这种情况下，您必须采取正则表达式，对于较简单的日志格式它仍能正常工作，我将在此给出演示。
在正则表达式内，句点字符是适用于任何单个字符的通配符。我可以使用子表达式 (.)* 在我的两个 IP 地址之间搜索任意数量的字符。但是，我有必要使用反斜杠转译 IP 地址本身带有的文字句点。
产生的命令是：
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" –allmatches
我删除了 –simpleMatch 参数，因为这一次我使用的是正则表达式。得到的输出仅显示特定员工的计算机对视为不适宜特定网站的访问。输出还包含调查人员所需的日期和时间戳信息。图 2 显示当您运行此类命令时可能得到的部分输出。
图 2 仅显示对特定网站访问的精简搜索结果（单击图像可查看大图）
我还能将输出输送到 Format-Table 并使用其显示计算列的功能。我可以在表中加入日志文件的文件名以及发现匹配项的行号，甚至可以显示匹配行本身。但是，我可以让外壳用空字符串替换正则表达式匹配项，这样将仅显示此行的其余内容（在本例中为日期和时间戳）。这是一项高级技巧，它进一步显示了 Windows PowerShell 如何处理字符串数据并生成高度自定义的输出，全部都是在一个命令行中完成的：
select-string -path c:\logs\*.txt -pattern
"192\.168\.17\.54(.)*207\.68\.172\.246" -allmatches |
ft  filename,linenumber,@{"Label"="Time";
"Expression"={$_.line.replace
($_.matches[0],"")}} –auto
图 3 显示了最终结果的可能形式。
图 3 Select-String 命令的格式化输出（单击图像可查看大图）

这是一个包含字符串的世界
我即将宣布 Windows PowerShell 的面向对象特性是其最大的功效之一。但有些时候选择的目标并不是对象。
Windows PowerShell 可以在面向对象的领域中发挥作用。值得庆幸的是，Windows PowerShell 团队认识到了您处理的格式化字符串经常会包含一些外部数据，因此他们加入了 Select-String 命令。有了它和正则表达式的帮助，您便可以使用 Windows PowerShell 来编写单行指令，用它解析最复杂的字符串。

Don Jones 参与编写了《Windows PowerShell:TFM》，而且是其他许多 IT 书籍的作者。可通过其博客 www.concentratedtech.com 与其联系。


您好，脚本专家！ 让您的用具随时候命
Microsoft 脚本专家

代码下载位置： HeyScriptingGuy2008_09.exe (150 KB)

如果有什么可以概括我们这个现代社会的话，那就两个词：保持联系。幸亏有手机，您不必非要在家里等待别人给您电话；无论您身在何处，他们随时都可以联系到您。（噢，真是太好了。）幸亏有无线网络，您不必非要在办公室里完成工作；现在您可以在家，在海滩，几乎在您可以想到的任何地方工作。
真实的故事：脚本编辑的父母最近进行了一次野营旅游，但他们在连接野营地的无线网络时遇到了问题，出现了惊险的一幕（就像伟大的探险家 Lewis 和 Clark）。谢天谢地，卫星 TV 仍然能使用！
但这也仅是冰山一角。GPS 会让您精确了解您所在的位置，精度可达几英尺；依靠这一设备，其他人还可以准确了解您的位置（“您可以跑，但不可以藏”这句老话在今天尤其得到了验证）。如果他需要，编写此专栏的脚本专家可以让其支票帐户在每次结算时给他打电话；同样，他可以让他的汽车每月用电子邮件向其发送状态报告。更有甚者，只要他休假，家里的烤炉就能替他遛狗和浇园，这种服务够周到吧。
嗯，也许上一幕听起来有点玄。但如果需要，脚本专家可以购买启用了 Internet 的烤炉。这样，他可以在回家的路上给他的烤炉打电话，当他走进大门的时候，滚热的烤面包已经在等待着他了。老实说，我们不知道您为什么希望在走进大门时滚热的烤面包已等您享用。但我们可以做这个假设…
当然，如果每个人的目标都是保持连接，那么从不受潮流左右的脚本专家提倡您更多地保持断开，也就并不奇怪了。这意味着脚本专家建议您丢开手机或笔记本电脑吗？不是的；脚本专家要比那聪明得多。他们所提倡的是您将未连接记录集添加到您的脚本集中。但如果您想丢开手机或笔记本电脑，那是您的自由，我们不会干涉。
请注意：Harris Interactive 的调查显示，43% 的美国人在度假时使用笔记本电脑检查并发送与工作有关的电子邮件。50% 以上的美国人在度假时使用手机检查其电子邮件和/或语音邮件。这还不包括一年中没有休假的 40% 的美国人。
毫无疑问，许多人会高兴地将未连接记录集添加到其脚本集中，但有一个问题：他们不知道未连接记录集是什么。如果您不熟悉这一概念，让我来做个说明：未连接记录集是（或多或少）没有绑定到任何实际数据库的数据库表；它由脚本创建，仅存在于内存中，脚本结束时它便会消失。换言之，未连接记录集是一个仅存在几分钟之后便会消失的虚构数据结构，里面有您的数据。听起来确实很有用，脚本专家。非常感谢您的帮助！
我们承认：未连接记录集听起来并不令人十分兴奋。事实也是如此。但它们可能非常有用。经验丰富的 VBScript 编写者知识非常全面，但 VBScript 并没有世界上最好的数据排序功能。（当然，前提是您承认世上有最好的数据排序功能。）此外，VBScript 处理大型数据集的能力也十分有限。除了 Dictionary 对象（它会限制您使用最多含有两个属性的项目）或数组（它在很大程度上被限制为数据的单属性列表），就这两项算是例外。
未连接记录集会帮您解决这两个问题（及其他问题）。需要为您的数据（特别是多属性数据）排序吗？没问题；正如我们说过的，未连接记录集是数据库表的虚拟等效项，世界上没有比排序数据库表还要简单的事了。（如果您对这一结论吹毛求疵，那我们只能假设不排序数据库表比排序数据库表简单。）或者您可能需要跟踪一个很大的项目集（这些项目拥有多个属性）？没问题；我们提到过未连接记录集是数据库表的虚拟等效项吧？您需要以某种方式过滤该信息吗？还是要搜索该数据的特定值？只要能用某种方式使用数据库表的虚拟等效项，就万事大吉了…
这个时机不错：正好言归正传。（假设我们知道自己在谈论什么。）对于初学者，假设我们有图 1 显示的棒球统计数据，这些统计数据是从 MLB.com 网站收集的，存储在用制表符分隔值的文件中 (C:\Scripts\Test.txt)。
图 1 存储在用制表符分隔值的文件中的统计数据
球员 | 本垒打 | RBI | 平均分
D Pedroia | 4 | 28 | .276
K Kouzmanoff | 8 | 25 | .269
J Francouer | 7 | 35 | .254
C Guzman | 5 | 20 | .299
F Sanchez | 2 | 25 | .238
I Suzuki | 3 | 15 | .287
J Hamilton | 17 | 67 | .329
I Kinsler | 7 | 35 | .309
M Ramirez | 12 | 39 | .295
A Gonzalez | 17 | 55 | .299
这的确不错，但假设我们真正要做的是按球员击中的本垒打数排序显示此球员列表。对于类似于这样的事情未连接记录集可以为我们提供帮助吗？我们将马上找到答案；请看看图 2。这里有很多代码，是不是？不必担心；您一会儿将看到，它只是虚张声势而已。
图 2 未连接记录集
Const ForReading = 1
Const adVarChar = 200
Const MaxCharacters = 255
Const adDouble = 5

Set DataList = CreateObject("ADOR.Recordset")
DataList.Fields.Append "Player", _
  adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", adDouble
DataList.Open

Set objFSO = _
  CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile _
  ("C:\Scripts\Test.txt", ForReading)

objFile.SkipLine

Do Until objFile.AtEndOfStream
    strStats = objFile.ReadLine
    arrStats = Split(strStats, vbTab)

    DataList.AddNew
    DataList("Player") = arrStats(0)
    DataList("HomeRuns") = arrStats(1)
    DataList.Update
Loop

objFile.Close

DataList.MoveFirst

Do Until DataList.EOF
    Wscript.Echo _
        DataList.Fields.Item("Player") & _
        vbTab & _
        DataList.Fields.Item("HomeRuns")
    DataList.MoveNext
Loop
首先，我们定义四个常量：
  • ForReading。我们打开并读取文本文件时将使用此常量。
  • adVarChar。这是一个标准 ADO 常量，用于创建使用“变量”数据类型的字段。
  • MaxCharacters。这是一个标准 ADO 常量，用于指示“变量”字段可以容纳的最大字符数（在本例中为 255）。
  • adDouble。最后一个 ADO 常量，用于创建使用双精度（数字）数据类型的字段。
定义完这些常量之后，出现下面这段代码块：
Set DataList = CreateObject _
    ("ADOR.Recordset")
DataList.Fields.Append "Player", _
    adVarChar, MaxCharacters
DataList.Fields.Append "HomeRuns", _
    adDouble
DataList.Open
这是脚本的一部分，我们用它实际设置并配置我们的未连接记录集。为完成这项任务，我们首先创建 ADOR.Recordset 对象的实例；毫无疑问，这将创建我们的虚拟数据库表（即，我们的未连接记录集）。
然后我们使用下面这行代码（以及 Append 方法）将新字段添加到记录集中：
DataList.Fields.Append "Player", adVarChar, MaxCharacters
如您所见，这根本就没什么难懂的：我们只是调用了带有以下三个参数的 Append 方法：
  • 字段的名称 (Players)。
  • 字段的数据类型 (adVarChar)。
  • 字段中可以存储的最大字符数 (MaxCharacters)。
添加完 Players 字段后，我们可以添加第二个字段：HomeRuns，其数据类型为数字 (adDouble)。完成了这项任务后，我们随后调用 Open 方法声明我们的记录集已打开，可以进行工作了。
接下来，我们创建 Scripting.FileSystemObject 的实例并打开文件 C:\Scripts\Test.txt。脚本的这一部分实际与未连接记录集毫不相关；它的存在只是因为我们需要从文本文件检索数据。文本文件的第一行包含我们的标头信息：
Player     Home Runs     RBI        Average
我们的记录集并不需要这一信息，因此打开文件后我们首先要调用 SkipLine 方法跳过此第一行：
objFile.SkipLine
现在我们已经移到了包含实际数据的第一行，让我们设置 Do Until 循环来逐行读取文件的其余部分。每次我们从文件中读取一行时，我们将该值存储在名为 strLine 的变量中，然后使用 Split 函数将该行转换为值数组（通过每次遇到制表符时便拆分该行）：
arrStats = Split(strStats, vbTab)
不可否认，这只是一个简单的概述，但我们希望如此，因为大多数人现在都已非常擅长从文本文件检索信息。长话短说，第一次循环之后，数组 arrStats 将包含图 3 中所示的项目。
图 3 数组的内容
项目号 | 项目名称
0 | D Pedroia
1 | 4
2 | 28
3 | .276
现在，我们就可以感受其中的一些乐趣了：
DataList.AddNew
DataList("Player") = arrStats(0)
DataList("HomeRuns") = arrStats(1)
DataList.Update
这里我们要将球员 1 (D Pedroia) 的信息添加到未连接记录集中。为将记录添加到记录集中，我们首先调用 AddNew 方法；这将为我们创建一个能使用的新空记录。我们使用接下来的两行代码为两个记录集字段（Player 和 HomeRuns）赋值，然后我们调用 Update 方法正式将该记录写入记录集中。然后重新返回到循环开头处，对文本文件的下一行（下一个球员）重复此过程。看到了吗？这里可能有许多代码，但全部都非常简单明了。
那么，在所有球员都被添加到记录集之后会发生什么？在我们关闭文本文件之后，我们执行以下代码块：
DataList.MoveFirst

Do Until DataList.EOF
  Wscript.Echo _
    DataList.Fields.Item("Player") & _
    vbTab & _
    DataList.Fields.Item("HomeRuns")
  DataList.MoveNext
Loop
在第 1 行，我们使用 MoveFirst 方法将光标定位在记录集的开头；否则，可能仅显示记录集中的某些数据。然后我们设置一个 Do Until 循环，它将持续工作，直到我们用完所有数据（即，直到记录集的 EOF（文件结尾）属性为 True）。
在此循环内，我们要做的就是回显 Player 和 HomeRuns 字段的值（注意，用于指示特定字段的语法有点怪）：DataList.Fields.Item("Player")。然后我们只需调用 MoveNext 方法继续记录集的下一个记录。
毫无疑问，这确实非常简单。所有工作完成之后，我们应返回如下所示的结果：
D Pedroia       4
K Kouzmanoff    8
J Francouer     7
C Guzman        5
F Sanchez       2
I Suzuki        3
J Hamilton      17
I Kinsler       7
M Ramirez       12
A Gonzalez      17
您可以看到，细想起来，这个脚本真得不是那么好，是吗？当然，我们确实返回了球员的姓名和本垒打总数，但我们得到的这些本垒打总数并不是按顺序输出的。真是的；为什么未连接记录集没有将我们的数据排序呢？
这样做实际上有一个充分的理由：我们并没有告诉记录集我们想排序哪个字段。不过，该问题很容易解决：只需修改脚本，在调用 MoveFirst 方法之前添加排序信息即可。换句话说，将脚本的这部分内容改为如下形式：
DataList.Sort = "HomeRuns"
DataList.MoveFirst
很显然，这里并没有采用任何技巧，我们只是将字段 HomeRuns 分配给了 Sort 属性。现在看看我们运行此脚本后得到的输出：
F Sanchez       2
I Suzuki        3
D Pedroia       4
C Guzman        5
J Francouer     7
I Kinsler       7
K Kouzmanoff    8
M Ramirez       12
J Hamilton      17
A Gonzalez      17
看起来好多了。嗯，只有一件事例外：通常本垒打总数是按降序排列，本垒打数最高的球员位居第一。有没有办法将未连接记录集按降序排列？
当然有；只需添加有帮助的 DESC 参数，如下所示：
DataList.Sort = "HomeRuns DESC"
DESC 参数会为我们做些什么呢？答对了：
A Gonzalez      17
J Hamilton      17
M Ramirez       12
K Kouzmanoff    8
I Kinsler       7
J Francouer     7
C Guzman        5
D Pedroia       4
I Suzuki        3
F Sanchez       2
顺便说一下，对多个属性进行排序是完全允许的；您所要做的就是为其中的每个属性指定排序顺序。例如，假设您想先按本垒打排序，再按 RBI 进行排序。没问题；以下命令可以达到此目的：
DataList.Sort = "HomeRuns DESC, RBI DESC"
您自己试一试，看看结果如何。它不像在度假时检查您的电子邮件那样有趣，但也差不太多。
注意：请记住，您不能对尚未添加到记录集中的字段进行排序。这意味着什么？它表示在您将属性（如 RBI）添加到 Sort 语句之前，您需要将这些行添加到您脚本的相应位置：
DataList.Fields.Append "RBI", adDouble

DataList("RBI") = arrStats(2)
如果您想要查看输出，则还需要修改 Wscript.Echo 语句：
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI")
让我们看看，我们还能对未连接记录集做些什么？噢，还有其他有效的操作。假设我们检索所有球员的全部相关信息，然后按安打率对该数据进行排序。（这就意味着我们还需要修改原始脚本，创建名为 RBI 和 BattingAverage 的字段。）输出如下所示：
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
C Guzman        5       20      0.299
M Ramirez       12      39      0.295
I Suzuki        3       15      0.287
D Pedroia       4       28      0.276
K Kouzmanoff    8       25      0.269
J Francouer     7       35      0.254
F Sanchez       2       25      0.238
这没问题，但是如果我们只是需要击中率不低于 .300 的球员的列表该怎么办？如何将显示的数据限制为符合某种特定条件的球员？一种方法是将 Filter 分配给记录集：
DataList.Filter = "BattingAverage >= .300"
记录集过滤器的用途与数据库查询相同：它提供了将返回数据限制为记录集中所有记录的子集的机制。在本例中，我们只要求 Filter 除去所有其他记录，只保留 BattingAverage 字段的值大于或等于 .300 的记录。结果如何？Filter 将完全按我们要求操作：
J Hamilton      17      67      0.329
I Kinsler       7       35      0.309
A Gonzalez      17      55      0.304
要是我们的孩子能这样听话就好了，是吧？
顺便说一下，您可以在一个过滤器中使用多个条件。例如，此命令将返回的数据限制为 BattingAverage 字段大于或等于 .300 且 HomeRuns 字段大于 10 的记录：
DataList.Filter = _
  "BattingAverage >= .300 AND HomeRuns > 10"
而此过滤器将数据限制为 BattingAverage 字段大于或等于 .300 或者 HomeRuns 字段大于 10 的记录：
DataList.Filter = "BattingAverage >= .300 OR HomeRuns > 10"
试试这两个过滤器，您就会了解区别何在。目的是：为了增添些乐趣，您可以试试这里的另外一个过滤器：
DataList.Filter = "Player LIKE 'I*'"
事实证明，您还可以在过滤器中使用通配符。为此，请使用 LIKE 运算符（而非等号），然后按照您执行 MS-DOS® 命令（如 dir C:\Scripts\*.txt）时的方式使用星号。在上述示例中，我们应返回其名称以字母 I 开头的球员的列表；那是因为我们采用的语法声明“显示其中 Player 字段的值以 I 开头（之后可以跟任何内容）的所有记录的列表”。不再深说了；至此您应该知道相应的例程了。
顺便说一句，您也并非一定拘泥于安打率 0.309 这一式样。（通常安打率的表示中没有前导 0，例如 .309。）但这并没有问题；您只需使用 FormatNumber 函数便可用任何您想要的旧方式格式化安打率：
FormatNumber (DataList.Fields.Item("BattingAverage"), 3, 0)
在显示数字时，只需将此函数包含在您的 Wscript.Echo 语句中（或者，您可以将输出分配给一个变量并将该变量放在 Echo 语句中）：
Wscript.Echo _
  DataList.Fields.Item("Player") & _
  vbTab & _
  DataList.Fields.Item("HomeRuns") & _
  vbTab & DataList.Fields.Item("RBI") & _
  vbTab & _
  FormatNumber _
  (DataList.Fields.Item("BattingAverage"), _
   3, 0)
很有趣，是吧？
遗憾的是，看起来我们本月的只能说到这儿了。总之，我们只想说—很抱歉，电话响了。
不管怎样，我们要提醒的是—噢，天哪，现在手机响了。我们刚刚收到烤炉发来的电子邮件。重要消息：我们的热烤面包已经准备好了，需要黄油或果酱吗？我要走了，下个月见！
Scripto 博士的脚本谜题
每月挑战不仅测试您解决谜题的能力，还测试您的脚本编写技能。

2008 年 9 月：脚本搜索
下面是一个简单的（或许不那么简单）单词搜索。从列表中查找所有 VBScript 函数和语句。但是有个要求：剩余的字母将拼写成一个隐藏单词，它恰好是（猜对了）一个 Windows PowerShell™ cmdlet！
单词列表：Abs、Array、Atn、Ccur、CLng、Cint、DateValue、Day、Dim、Else、Exp、Fix、InStr、IsEmpty、IsObject、Join、Len、Log、Loop、LTrim、Mid、Month、MsgBox、Now、Oct、Replace、Set、Sin、Space、Split、Sqr、StrComp、String、Timer、TimeValue、WeekdayName。

答案：
Scripto 博士的脚本谜题
答案：2008 年 9 月：脚本搜索

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


桌面文件 WDS 中的高级功能
Wes Miller

目录
命令行管理
映像存储
多播
WDS 日志记录
其他问题
总结
在本专栏的最近两期中，我们研究了 Windows 部署服务 (WDS)。首先我介绍了 Microsoft 的基于预引导执行环境 (PXE) 的部署工具的历史，然后概述了 WDS。本月，我将深入探讨一些高级主题 —
WDSUtil（用于 WDS 的功能强大的命令行实用工具）、WDS 映像存储、WDS 日志记录以及针对 Windows Server® 2008 使用 WDS 的多播功能。
对于 Windows® 2000 和 Windows Server 2003 中提供的远程安装服务 (RIS)，它并没有像许多人期望的那样提供足够丰富的功能。尤其是在以下三个领域：
  • 性能（更具伸缩性的部署）
  • 日志记录/审核
  • 命令行自动化
随着我们逐步展开本月的专栏，您会看到在初始版本的 WDS（更具体地说，在 Windows Server 2008 的 WDS ）中，以上每个领域都得到了重大改进。

命令行管理
在上个月我曾提到过，WDS 提供了明显改进的管理控制台。但对大多数企业而言更为重要的是，WDS 提供了一个用于管理工作的新命令行实用工具 WDSUtil.exe（请参阅图 1）。WDSUtil 可随 Windows Server 2003（SP1+WDS 或 SP2）中的 WDS 可选组件以及 Windows Server 2008 中的 WDS Role 一同安装。
图 1 通过 WDSUtil 将体系结构发现选项设为 yes（单击图像可查看大图）
WDSUtil 是一个功能强大得令人惊讶的实用工具，但却比较复杂。可以通过 Microsoft® 管理控制台 (MMC) 实现的所有功能甚至更多其他功能都可以通过 WDSUtil 有效地完成。我们来实际看一看下面的示例（当您遇到问题时，也可以运行它来进行诊断）：
wdsutil /get-server /show:config
得到的结果与在 WDS MMC 中看到的几乎完全一样 — 只是 WDSUtil 可以通过更容易阅读的格式输出它，并可以在随后将其输出到文本文件中。
信息太少？尝试改为运行以下命令，它会返回更多信息：
wdsutil /get-server /show:all /detailed
可以通过运行以下命令来停止和重启 WDS 服务器：
wdsutil /stop-server
wdsutil /start-server
可在以下网址中找到 WDSUtil 的命令参考：go.microsoft.com/fwlink/?LinkId=112194。如果愿意，您还可以在以下网址下载它的 .chm 版本（以及所有 WDS 2008 文档）：go.microsoft.com/fwlink/?LinkId=89381。
使用 RIS 时，如果不是 Active Directory® 服务接口的权威人士，要想通过命令行来确定特定的 MAC 地址或 GUID 是否与 Active Directory 中的机器帐户对象 (MAO) 相关联，可能需要颇费一番周折。如使用 WDSUtil，则可利用二者中的任一个执行查询。
GUID 可能会很容易让人混淆，因为通过二进制字符串格式或 GUID 字符串格式都可以输入它们，唯一的不同之处是字节顺序和有无连字符。可使用以下任意一行代码输入带有或不带有连字符的 MAC 地址：
wdsutil /get-device /id:01-23-45-67-89-AB
wdsutil /get-device /id:0123456789AB
可使用以下命令通过二进制字符串获取设备信息：
wdsutil /get device /id:ACEFA3E81F20694E953EB2DAA1E8B1B6
或者，也可以使用以下命令通过 GUID 字符串获取设备信息：
wdsutil /get device /id:E8A3EFAC-201F-4E69-953-B2DAA1E8B1B6
许多计算机或许能够运行 64 位版本的 Windows，但遗憾的是，其中有些无法正确报告其体系结构。通过运行属于 WDS 中的一个小型网络启动程序，可让 WDS 尝试确定某个系统是否支持 x64。如图 1 所示，可使用以下命令实现此目的：
wdsutil /set-server /architecturediscovery:yes
事实上，WDSUtil /set-server 命令可用于配置大量的服务器设置。要查看可能情况，请运行以下命令：
wdsutil /set-server /?
如果已将 Windows Server 2003 WDS 服务器升级到 Windows Server 2008，可通过运行以下命令将全部 RIPrep 映像转换为 Windows 映像格式 (WIM) 的映像：
WDSUtil /convert-RIPrepImage
尽管 WDSUtil 可以转换 RIPrep 映像，但却无法转换其他 RISetup 映像（传统的 RIS/原有的 WDS 脚本安装）。
WDSUtil 的强大体现在能够自动执行重复的任务。通过图 2 中的命令可对 WDSUtil 的功能有大致的了解。无论是实施新 WDS 服务器、跨多服务器添加或修改映像、管理多播基础结构，还是指定何种网络启动程序用于特定的启动客户端，WDSUtil 均能提供之前的 RIS 所不具备的一些重要功能。
图 2 WDSUtil 命令
命令 | 说明
/add | 添加设备、映像或映像组。
/approve-AutoAddDevices | 批准未决的自动添加设备并允许为其设置配置信息。
/convert-RiprepImage | 将传统 RIPrep 映像转换成 WIM 映像。
/copy-Image | 复制映像存储中的某个映像。
/delete-AutoAddDevices | 删除所有或特定的未决自动添加设备。
/disable | 禁用 WDS 服务器或传输服务器。
/disconnect-Client | 从多播传输或命名空间断开某个客户端。
/enable | 启用 WDS 服务器或传输服务器。
/export-Image | 与 ImageX 中的 /export 一样，它会将现有映像从映像存储导出到 WIM 映像。
/get | 获取设备、映像、映像组、WDS 服务器或传输服务器的属性。
/initialize-Server | 配置 WDS 服务器以便在首次安装后使用。
/new | 创建捕获或发现映像、多播传输和命名空间。
/progress | 在执行指定命令时显示执行进度。
/reject-AutoAddDevices | 拒绝所有或特定的未决自动添加设备。
/remove | 删除映像、映像组、多播传输和命名空间。
/replace-Image | 使用新映像来替换（覆盖）某个映像。
/set | 设置设备、映像、映像组、WDS 服务器或传输服务器的属性。
/start | 启动 WDS 服务器或传输服务器。
/stop | 停止 WDS 服务器或传输服务器。
/uninitialize-Server | 还原服务器初始化期间对服务器所做的更改（还原成未配置状态）。
/update-ServerFiles | 使用服务器的 System32\RemInst 目录中的最新版本来更新服务器的 REMINST 共享中的文件。
/verbose | 在执行指定命令时显示详细输出。

映像存储
我在上个月曾提到过 RIS 使用单实例存储 (SIS) 在磁盘上更有效地存储文件，此方法在 WDS 中已被弃用。现在，所有的本机模式 (WIM) 映像（无论是何种操作系统）都保存在 WDS 映像存储中。正如我在之前的专栏中提到的，当卷映像有相关文件时，单实例功能可节省 .wim 文件中的空间。WDS 映像存储采用的是同样的工作原理。实际上，它使用 WIM 功能来存储映像。
要使用映像存储，需要至少有一个映像组；WDS 初始化通常会提示您创建一个映像组。您也可以在添加安装映像时创建一个新的映像组，而此映像将被添加到其中（请参阅图 3）。
图 3 创建新映像组（单击图像可查看大图）
那么，什么是映像存储？在 Images 目录中的 RemoteInstall 目录下，您会发现与创建的每个映像组所对应的目录。如图 4 所示，导入到映像组中的每个安装映像都有一个 .wim 文件，还有一个单独的 .rwm 文件（资源 WIM）。
图 4 映像组的内容（单击图像可查看大图）
仔细查看图 4 中的文件。此映像组包括：
  • install.wim（Windows Server 2008，Standard Edition）
  • install-(2).wim（Windows Server 2008，Enterprise Edition）
  • install-(3).wim（Windows Server 2008，Datacenter Edition）
  • install-(4).wim（Windows Server 2008，Standard Edition (Server Core)
  • install-(5).wim（Windows Server 2008，Enterprise Edition (Server Core)
  • install-(6).wim (Windows Server 2008，Datacenter Edition (Server Core)
现在，将这些文件的大小与 MMC 中的进行比较（如图 5 所示）。图 4 中每个 .wim 文件的大小与 Res.rwm 文件的大小相比只占很小的比例。为什么呢？嗯 — 为了节省空间，图中显示的 .wim 文件只是实际文件的存根。它们包括用来恢复 .wim 文件的元数据，但并不实际包含文件资源。映像组中所有文件资源都存储在该映像组的 .rwm 文件中。
图 5 服务器管理器中显示的映像（单击图像可查看大图）
要编辑映像存储中的安装映像，可导出映像、进行编辑，然后替换映像（或重新导入），也可以通过从 MMC 禁用相应的安装映像并通过安装和修改 .wim 文件进行编辑，以实现与它的交互。
RIS 始终存在的一个问题是映像复制。通过缆线复制经过 SIS 处理的文件时，SIS 会丢失，因为它是 NTFS 属性。这意味着如果有 40GB 的 RISetup 和 RIPrep 映像并要将它们复制到另一服务器，即使 SIS Groveler 已将其减少到 5GB，仍会通过缆线复制 40GB。对于 WDS 映像存储而言却并非如此。实际上，由于映像存储体系结构的原因，您可将其存储在分布式文件系统 (DFS) 服务器上，并使用 DFS 复制 (DFS-R) 在站点间复制它。
具体细节会随 WDS 版本的不同而异。对于 Windows Server 2003，请参阅 go.microsoft.com/fwlink/?LinkId=81031 中所提供文档的“使用图像”一章。对于 Windows Server 2008，请参阅位于 go.microsoft.com/fwlink/?LinkId=121960 中的“使用 DFS 存储和复制图像”。由于资源都存储在 .rwm 文件中，因此即使将映像组从一个服务器复制到另一个，通过缆线传输的数据量也只占需要传输的（或在旧的 RIS SIS 体系结构中）每个完整 .wim 文件数据量的一小部分。
那么，何时需要创建新映像组，何时需要使用旧映像组呢？这些规则通常与用于 .wim 文件的规则完全相同。尽管可以将 Windows XP Professional SP3 的映像放入主要由 Windows Server 2008 映像构成的映像组中，但这样做意义并不大，因为它不会节省很多空间。与 .wim 一样，您通常都会希望至少有针对以下软件的映像组：
  • 每个特定版本的 Windows — 同时包括版本 SKU (Windows XP Professional) 和 Service Pack 修订版 (SP3)。
  • Windows Server 2003 和更低版本：各个本地化语言版本（非多语言用户界面）。在 Windows Vista® 之前，本地化版本是完全不同的二进制文件，因此它们没有作为单实例存储在 .wim 文件中。
  • 各个版本的每个 Service Pack。尽管可以将 Windows Server 2008 和 Windows Vista SP1 映像存储在一起，但需要考虑该功能在组织中是否有意义。
映像存储即使多于之前的 SIS，也能很显著地节约空间 — 无论是在磁盘上还是通过缆线传输时，而且通常不需要什么操作即可使其顺畅运行。

RIS 的最大缺点之一是可伸缩性不足。多播部署是专门为改善这一问题而设计的。人们通常认为多播就是“更快”地部署，但实际上它与速度无关 — 它只是“更多”。可通过 RIS 部署多个系统。实际上，RIS 可同时处理约 75 个系统的部署。
但在远未达到此数量之前，性能就已受到影响，并且每个安装所需的时间也会越来越长。更糟糕的是，随着安装数量的增加，失败的可能性也在增加。同时，多个安装的服务器消息块 (SMB) 网络流量会使网络处于满负荷状态（因此在部署期间，员工可能会无法访问关键网络资源，如 Microsoft Exchange Server）。
多播的目的在于增加部署数量。无论是部署四个服务器还是部署具有 100 个系统的会议中心，多播都可以帮助您快速完成部署，并且不会使网络处于满负荷状态。尽管可以使用多播来部署单个系统，但是必须等到获得侦听传输的多个系统后，规模部署的好处才会得以实现。
要使用多播，必须具有支持多播的路由器。通常情况下，这意味着应启用 Internet 组管理协议 (IGMP) Snooping。此外还必须拥有 Windows PE 2.1（Windows Server 2008 RTM 或 Windows Vista SP1），因为 Windows Vista RTM 附带的版本 (2.0) 无法接收多播传输。
如果在同一个网络上有多个 WDS（或其他多播）服务器，还应指定一个自定义 IP 地址范围。可以通过 WDS MMC 来方便地更改它，方法是右键单击服务器、单击“属性”，然后单击“网络设置”选项卡。
在执行多播广播时，多播服务器既可以调整最慢客户端的接收速度，也可以将速度固定在较高水平而丢弃速度跟不上的客户端。出于可靠性考虑，WDS 会以最慢客户端接收传输时的速度运行。
如果发现传输性能低于您的预期，可运行 wdsutil /Get-MulticastTransmission/Show-clients。这可以找出限制传输速度的主客户端。然后可以断开该客户端，它会改为继续使用 SMB 而非多播。如需自动断开慢速客户端的示例脚本，请转到 go.microsoft.com/fwlink/?LinkId=121961。
要创建多播传输，可右键单击安装映像并选择“创建多播传输”，也可右键单击 WDS 控制台中的“多播传输”并选择“创建多播传输”。在创建多播传输时，既可创建 Auto-Cast，也可创建 Scheduled-Cast。如果有多个定期联机的客户端并且它们都需要完全相同的映像，则 Auto-Cast 会非常有用；新客户端会自动添加到正在进行的传输中，此传输是为最早请求安装映像的客户端启动的。Scheduled-Cast 允许您设置组大小，达到此值后即开始进行传输。
也可将传输设为在指定时间启动。客户端使用多播传输后，您可以通过单击映像名称来查看它们。在右侧窗格中，您会看到有关连接到传输的客户端的具体细节。
通常情况下，最终用户从“WDS 设置”客户端来使用多播。但是，Windows Server 2008 Windows 自动安装工具包 (WAIK) 随附了一个名为 WDSMCast 的命令行实用工具，利用它可通过多播传输从 WDS 请求 .wim 文件。.wim 文件必须完整地传输并应用到客户端 — 因此，您需要确保有足够的磁盘空间来存储和应用映像。下个月，我将介绍如何把 WDSMCast 集成到您自己的自定义部署过程中。

WDS 日志记录
WDS 可执行大量日志记录和跟踪，但为了节省空间默认禁用了其中的大部分功能。有两种类型的事件日志记录 — 当客户端写入 Windows 事件日志时以及写入用于 WDS 其他方面的跟踪日志时。
但是，在 Windows Server 2008 中，WDS 默认会执行大量日志记录。这些日志均位于“管理工具”|“事件查看器”下。WDS 日志显示在“应用程序和服务日志”| Microsoft | Windows |“部署服务诊断”下的“事件查看器”中。更为方便的是，这些日志与您在 MMC 中查看 WDS 角色时显示的是相同的日志（请参阅图 6）。
图 6 在服务器管理器中查看 WDS 事件（单击图像可查看大图）
通过使用以下参数来运行 WDSUtil 可启动 WDS 客户端日志记录（如图 6 中的事件日志所示）：
wdsutil /wdsclientlogging /enabled:yes /logginglevel:info
也可针对 WDS 的多个不同子组件启用跟踪日志记录。要配置跟踪，可在注册表项下设置相应的 DWORD 注册表值，如图 7 所示。所有跟踪日志都存储在 \Windows\tracing 下。然后，您需要重启相应的组件以便开始执行日志记录。
图 7 设置跟踪日志记录
WDS 组件 | 注册表项 | 注册表值 | 日志名称
服务器 | HKLM\SOFTWARE\Microsoft\Tracing\WDSServer\EnableFileTracing | 1 | wdsserver.log
多播功能 | HKLM\System\CurrentControlSet\Services\WDSServer\Providers\WDSMC\TraceDisabled | 0 | wdsserver.log
管理组件 | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMGMT\EnableFileTracing | 1 | wdsmgmt.log
MMC | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Tracing\WDSMMC\EnableFileTracing | 1 | wdsmmc.log
WDS 还具有性能计数器（如 go.microsoft.com/fwlink/?LinkId=121962 所述），您可以在系统性能出现问题时监视它们（或提前执行系统性能分析）。正如之前提到的，在遇到问题时，可使用 WDSUtil 的 /detailed、/verbose 或 /progress 开关来获取更详细的信息。
如果连接到 WDS 服务器的客户端或与之交互的 WDS 客户端存在问题，可使用 Microsoft Network Monitor (Netmon) 来进行调试，它是一个用于调试问题的极佳工具。Network Monitor 的下载地址为：go.microsoft.com/fwlink/?LinkId=121491。

其他问题
我发现有许多值得一提的问题。首先是内存 — 请记住，在核心部分 WDS 是基于 Windows PE 2.x 的。这意味着 WDS 客户端至少需要 384MB RAM — 实际上，应确保 512MB 以获得最优性能。还要记住，Windows PE 2.x 无法在非高级配置和电源接口 (ACPI) 系统上启动 — 这并不一定指旧的硬件。据报告，有些较新的系统也不支持 ACPI。
请注意，这些系统也不支持 Windows Vista 或 Windows Server 2008。对于不支持 ACPI 的系统，您可以预先在其中存放一份 Windows Server 2003 或更低版本的 WDS 或 RIS Server，也可以通过非 PXE 机制安装 Windows。
最后请牢记，如果希望从服务器引导 Windows PE 1.x，还需要使用 Windows Server 2003 或更低版本的 WDS 或 RIS Server，因为 Windows Server 2008 中的 WDS 无法引导 Windows PE 1.x 映像（RAMDisk 或 PXE）。
总结
到目前为止，我已深入探讨了 WDS 的历史、基础知识和一些高级主题。在下个月，我将介绍一些自定义的 WDS 方案 — 具体来说，包括如何与 WDS 交互以及如何对其进行调整以执行所需的任务，但通常不会用到现有的 WDS/安装体验。

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


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

目录
重载更新技术
有关安全的矛盾消息
归根结底为复选框
倡议
在前几期的《TechNet 杂志》中，我讨论了安全专业人员和 IT 行业如何令消费者感到困惑并干扰有效安全措施。在本系列文章的前两期中，我重点介绍了向消费者提供误导信息、重载登录工作流
以及唆使不良行为的解决方案这类的问题。到目前为止，我已向您介绍了许多示例，它们指出业界虽对消费者安全高度关注，但实际效果却极不尽人意。在本期和最后一期中，我将介绍为何消费者可以使用的一些最重要技术没有达到他们预期的效果。我的倡议便由所有这些问题展开。

重载更新技术
保持电子安全的主要原则（实际上就是不容置疑的要求）之一就是使您的所有软件始终保持最新状态。目前，几乎每个主要的软件提供商都提供某种形式的半自动机制，用以至少保持其某些软件的更新。但实际情况并非如此简单。
首先，您拥有的软件越多，必须更新的软件也就越多。同时，您购买其软件的供应商越多，就不得不接触到越多的更新机制。这便是造成混淆的因素。
例如，如果您正好在适当的位置保留了默认设置，Internet Explorer® 将更新其自身。但 Internet Explorer 实际上只是其他技术的一个容器。在 2008 年的 CanSecWest 会议上，当 Shane Macaulay 利用 Java 和 Adobe Flash 中存在的漏洞破解了 Mac 时便说明了此方面存在的潜在影响。（在作者编写此专栏时相关细节仍有些欠缺，因为该缺陷仍未公布。）但依我看来，这两项技术均不是内置组件，然而大多数计算机上都要安装它们，因为它们已广泛应用于 Internet。要保持这两款软件的更新都会有一些难度，因为它们均采用了自动更新机制，尽管这两种机制并非经常有效。
此外，大部分最终用户完全没有意识到这些技术的存在以及它们是需要更新的。大多数情况下，这些技术是在计算机上的 OEM 映像中提供的，对于消费者来说很难将它们与操作系统区分开来。就最终用户而言，当 Windows® Update 指示没有任何更新时，那就绝对没有更新。
第二个问题是更新机制通常都要比实际需要的机制更复杂。任何不具备完全自动模式的更新机制都不大可能得到广泛的使用，因为用户通常都没有意识到他们需要运行更新工具。而且，在大多数情况下，用户必须是管理员才能安装更新。甚至于用户必须是管理员才能获得可用更新的通知。
最后，供应商们利用软件更新技术来部署那些用户没有安装且完全不相关的软件（工具栏等）的现象越来越普遍。软件更新技术已从专用于部署软件更新过渡到一种分发附加软件的方式。
这方面有两个非常明显的例子，即 Microsoft® Windows Update 服务（如图 1 所示）和 Apple Software Update（如图 2 所示）。Apple 和 Microsoft 都选择了不仅利用各自的更新机制更新软件，还要部署那些用户最初并未安装的新软件。
图 1 利用 Windows Update 部署 Silverlight（单击该图像可查看大图）
图 2 利用 Apple Software Update 分发 Safari（单击该图像可查看大图）
在 Apple 案例中，即使您只安装了 QuickTime，也同时为您提供 iTunes 和 Safari。有趣的是，在默认情况下它们还全部被选中。
在 Windows Update 案例中，利用此更新服务部署的最新软件是 Silverlight™。Microsoft 在过去就使用过此项技术来分发新软件。值得称赞的是，至少 Microsoft 没有默认选中此框来安装新软件。
对于用户而言，此方法（通过更新机制分发新软件）会引发两个问题。首先，许多人后来在其计算机中留下的软件要比其开始使用时多。如您所知，无论做任何用途，所有软件都存在一些错误，而其中某些错误可能会导致潜在的安全漏洞。其中一些漏洞终将为某种形式的攻击所利用。结果是，许多用户将受到他们不需要甚至没有使用过的软件的攻击，而该软件是通过软件更新机制部署到其计算机上的。
另一个问题是用户可能会错误地理解软件更新机制的价值。如果用户们发现软件更新机制被用来部署新软件（而不是新的更新内容），他们可能会将更新机制视为一个麻烦，进而停止使用它们。设想一下，用户在受到来自其从未使用过而是通过软件更新机制接收到的某个程序的漏洞的攻击之后，他会有怎样的感受呢？
与用户对应保证其安全的技术失去信任相比，有几件事情可能会对技术体系的健康和安全造成更大的伤害。用户一旦失去了这种信任，他们将开始排斥这些技术，并最终放弃使用。如果对保护至关重要的技术（如更新技术）失去恩宠，则整个技术体系将处于危险的境地。保护这种体系是 Microsoft 甚至向明知道其运行盗版软件的计算机分发安全更新的原因所在。
相比之下，我十分欣赏整洁的特制 Mozilla Firefox 更新界面（如图 3 所示）。我当然希望 Mozilla 继续坚持杜绝通过其软件更新工具分发附加软件。
图 3 Firefox 的软件更新界面是业内最整洁的界面之一（单击该图像可查看大图）

有关安全的矛盾消息
如果整个行业针对消费者制定一致的消息将是件多么美妙的事情啊。虽然行业内的竞争是必不可少的，但消费者确实需要了解安全对其意味着什么。遗憾的是，如果整个行业继续发送彼此冲突的消息，消费者便无法做到这一点。坦白地讲，各家公司自己发布的消息能不相互矛盾就算不错了。
虽然这种通用消息在行业中恐怕永远不会出现，但至少要在消息传送过程中应保持一致性和实事求是。消费者对安全技术的继续信赖至关重要，这使整个行业任重而道远。
同样地，我们还需要询问是什么提供了目前的实际价值。 例如，我并不认为防病毒软件像行业内现在宣传的那样有效，甚至必不可少。就拿我七岁大的儿子使用的计算机和我家厨房的计算机来讲。两台计算机都安装了防病毒软件，但在安装后的三年里，没有一台在出现问题时报过警。现在，我并不是说我们应放弃防病毒软件，因为此时它仍是是技术体系的核心组件。显然，如果我们突然删除所有防病毒软件，那么攻击者很快就会利用这一点，而我们将会遇到更多的病毒感染案例。
其中的关键是整个行业需要考虑一下用户在其安全产品中真正需要的功能是什么，这些功能的有效性如何以及公司如何向消费者传达这些需求和价值。但目前的实际情况是用户收到了太多相互冲突、夸张且常常不真实的安全消息。

归根结底为复选框
举例来说，安全软件行业都是围绕套件做文章的。 今天，安全软件几乎是完全作为一组看起来毫不相关的功能进行分发的。几乎没有任何信息涉及到其中哪些功能是用户实际需要的。
这似乎导致了一场选取更多复选框的竞赛。虽然检查表为比较产品提供了一种很好的方式，但同时它们可能会引来不必要，甚至不值得要或没有意义的功能。图 4 至 7 显示了四个不同的安全软件供应商所提供的四种不同的复选标记列表。可以有把握地认为带有 17 个复选标记的产品比只有 10 个复选标记的产品的质量更胜一筹吗？
这些图确实非常有趣。在图 4 中，产品收到一个复选标记就成为了一个新版本。而在图 5 中，产品获得一个复选标记，是因为（根据公司的声明）它可以“阻止恶意网站的攻击”。图 6 中的产品受到更多青睐，因为它提供了“儿童上网保护”。显然，没有人会想要一款无法保护儿童的产品。但是，赢家将诸如注册表整理和硬盘碎片整理之类的功能包含在安全套件中也真有创意。前者即使有的话也是非常罕见的，而后者已经被置入 OS 中。事实上，Windows OS 的解决方案中已经包含图 7 中所示的 17 个复选标记中的 15 个。
图 4 只有 10 个复选标记的顶级产品（单击该图像可查看大图）
图 5 带有 11 个复选标记的产品必定更好（单击该图像可查看大图）
图 6 稍等一下，这款产品有 12 个复选标记（单击该图像可查看大图）
图 7 这款有 17 个复选标记的产品一定是最佳解决方案，不是吗？（单击该图像可查看大图）
其中有一些令人烦扰的头疼的流行趋势。这些产品不仅复制已经包含在操作系统中的功能（却忘了在营销文献中提及这一事实），还会发表完全错误的声明。例如，世界上没有任何安全软件能够真正地阻止来自任何位置的攻击，它们只能帮助防御攻击。任何产品也不能让您避开攻击者的视线。
问题在于软件安全的业务很大程度上是为保护用户不受其他供应商的产品带来的漏洞的伤害而构建的。但这些供应商不断致力于增强对其自己消费者的保护，结果使得安全软件行业发现其业务模式受到了威胁。虽然安全软件行业必定会发挥巨大作用，因为各种新的风险正在浮出水面，但供应商需要帮助消费者管理风险，而不只是抵御那些已不再是真正威胁的威胁。

倡议
如果我希望读者通过这个由三部分内容组成的系列文章领悟一点的话，那就是我们作为一个行业需要对我们的用户和消费者说实话。我们需要解释这些风险以及用户应如何解决它们。最后，我们需要开始装备人们以使他们能保护自己。
我对于所有这些“解决方案”最大的顾虑是，从长远来看，它们最终很可能会降低安全性。如果用户甚至 IT 经理真的相信这些产品将解决实际的安全风险（尤其是他们宣称有能力解决的所有风险），我们可能会失去传授人员如何真正保护自己的机会。
以密码身份验证系统为例。如果用户认为我在本系列的第一部分中讨论过的基于密码的身份验证系统的脆弱加载项能保护他们，那么他们可能会变得更加松懈，转而使用更薄弱的密码。我在本系列文章中重点介绍的最糟示例中，这项技术实际上是强制用户使用比以前更差的安全性（如果新技术还没有实现）。这意味着，当恶意用户发现如何攻克这些系统时（通常这并不很难），那么我们的处境比现在还要糟糕。这可能会导致严重的信任问题，致使用户放弃有真正价值的解决方案。
我们需要立即采取行动来保护支撑我们业务的技术体系。当然，必须要鼓励创新，但我们还必须要非常小心地避免为了创新而妨碍真正的风险分析。否则，我们所谓的安全壁垒将是十分脆弱的。
我讨论过的其他示例也是如此。以毫无意义的安全假象为例。它对用户绝对没有任何好处，它给用户带来一种安全错觉，使在线服务提供商可以逃避优化，而实际上对用户造成了间接的伤害。其间，只需花上几千美元（或许极个别情况是上万美元）的净成本便可向用户提供适当的信息。要求供应商花那么一点钱来保护其消费者及其业务真的很过分吗？
这有许多含义。首先，我们必须转变用户不能作出决定的认识，而且我们绝不能这样做。用户并非无法学会做出决定。毕竟，这些用户已经做出了许多决定，例如，决定购买计算机或者决定使用您的站点或者决定购买您的产品或服务之一。就像人们需要学习安全驾驶一样，他们也必须学习安全地使用计算机。目前，攻击者是以用户个人为目标，且不能依赖于技术进行决策。相反，安全技术必须是决策支持系统，在适当的时候提供适当的信息，使用户可以做出英明的决策。
世界上某些最糟糕的用户界面都来源于安全解决方案，因为应用程序要么被设计成对用户隐藏所有类型的决策，要么被设计成将所有可用数据（以非友好方式）转储给用户。两种方法都不起作用。前者将用户置于风险之中，因为不能根据该项技术做出正确的选择。如果技术被视为阻碍了用户的业务目标，那么在该项技术很快会被淘汰。而后一种方法也失败了，是因为人们不想受到 IP 地址、进程 ID 以及其他对于他们来说毫无意义的数据的打扰。他们只想知道计算机正在利用其密码和信用卡做什么。毕竟，这才是安全的真正含义。

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


领域备注 内部创新
Romi Mahajan

著名的管理权威和商务策划师 Gary Hamel 在他的《管理工作的未来》一书中认为，长期的比较优势源自创新文化的建立，而创新文化本身恰恰是管理方法演变的结果。尽管业界在多方面对自身进行了无数次的创新和彻底改造，但大部分公司仍处于层级制管理文化中。这会阻碍真正创新文化的出现，原因很简单，因为它在人类的创造力和资本方面无法产生合理的回报。
这些层级制度与创新是格格不入的；而人类的创造力一经释放，即会成为长期的创新性比较优势的核心要素。当人类的创造力受到制约时，80% 以上的工作人员都没有专注于其本职工作。Hamel 认为这不仅是经营层面的失败，也是道德层面的失败。
最起码这应当让业界对消除过多层级有所警觉。此论点的实质是反对官僚主义。决策制定者不应寄希望于高高在上的经理和臃肿冗余的管理人员。
Hamel 认为管理而非 IT 是创新的源头。毕竟，IT 可以商品化，这让它如何提供比较优势？如果 IT 不是创新的源头，并且如果生产率的提高、正常运行时间、可靠性、新应用程序的快速面市以及单一登录（和类似功能）无法提供比较优势，那么我们一直都在如此担心的究竟是什么呢？
您是否希望在总体上对 IT 组织和您公司的精髓进行深入的了解，以判断 Hamel 的观点是否有可能是正确的？如何确保 IT 没有被视为商品？
通过引入 Hamel 概念中的精华并使用它们来帮助 IT 组织确保其未来成为创新的中心，我创立了一种称为“内部创新”的理论。人类创造力和资本的最优使用是保证持续不变的比较优势的关键所在，并且优秀的组织必须使创新成为其职能所具有的内在品质。组织必须包容团体，而非官僚作风。并且，最为重要的是，管理常常会阻碍真正的创新 — 只有当管理得到发展时，才可能实现真正的创新。
让我们来看一看 IT 组织。IT 员工往往比较聪明、具有奉献精神且渴望有所作为。他们常常被号召使用尽可能少的资源创造尽可能多的价值，因此他们的大部分时间都在从事本职工作，几乎没有时间进行创新。
我的“内部创新”概念是将 Hamel 的理论应用到 IT 领域。核心原则是：
  • 假设 IT 员工具有与生俱来的创造力，我们最感兴趣的是如何确保 IT 管理模型能够充分利用此潜能。
  • 创新来自于系统的、挑剔的“思考-试验-错误-修正”过程，这是 IT 界无法回避的一个过程。
  • 当团体获得深入坦诚的包容时，技术解决方案即会出现。IT 此时可以将自身作为示范！
  • 在 IT 界，人是使比较优势得以体现的唯一来源。
  • IT 管理需要从关注项目和预算发展成为一种全新的、令人振奋的对创新管理的关注。
  • IT 不应与成本遏制相关，而应积极地创造产出。
您是否已经相信了这一理论？我们能否应用“内部创新”这一概念并论证 IT 组织是执行这一重要试验的不二之选？经理们是否已经准备好放下权力并包容自己的团体？管理层是否已经准备好放弃其权力并包容我们的集体荣耀？

Romi Mahajan 是 Ascentium Corporation 的首席营销官。在加入 Ascentium 之前，他在 Microsoft 工作了七年多，其最后的职务是“技术听众和平台市场营销”团队的主管。Romi 在技术、政治、经济和社会学领域均有著作问世。


Windows 机密 Windows 95 探秘
Raymond Chen

尽管 Windows® 95 的 32 位 程序可以使用您的常用 32 位编译器，16 位程序可以使用常用的 16 位编译器，但 Windows 95 本身需要一种特殊的编译器，它熟悉 32 位和 16 位两类程序，在其间搭建桥梁。Windows 95 还需要能将两类代码结合到一起的自定义链接器，以及用于 VxD（Windows 95 的驱动程序格式）的自定义链接器。
Windows 95 团队依靠语言和工具部门提供这些特殊用途的编译器和连接器。我想语言部门一定会认为这是个奇怪的请求：“你想让我编写一个能完成多项任务的编译器，将来让它一直只编译两种 DLL？”是的，就是这样。这是两种相当重要的 DLL。
尽管这一请求表面上看起来令人费解，语言和工具部门还是完成了这项任务，将这一极其特殊的编译器和链接器纳入 Windows 95 之内。当然，编译器不是一开始就完美无瑕。Windows 团队收到的是初始版本，随后以新优化的形式定期进行了更新并修复了错误。
某一天 Windows 95 突然变得奇慢无比。原来链接文件以秒计算，现在变成以分钟计算。文件仍能成功生成，但耗时甚巨。不仅在开发人员的机器上是如此—整个团队的所有成员都遇到了这一问题。是我们的代码突然击中链接器的软肋了吗？还是链接器错误在做怪？
一翻调试之后，我们找到了问题的根源。链接器的最新版本包含一些诊断代码，在将其交给 Windows 团队前，语言部的员工忘了删除这些代码。此诊断代码将其输出记入一个文件，该文件存储在编译器团队某位成员所在办公室的计算机上。这台计算机恰好关机了。（这让我们想起 Leslie Lamport，他对分布式系统的著名论述是：一旦一台你从不知晓的计算机停机，你就会一事无成。）
这一版本的链接器已正常运行了数周。构建 Windows 95 时，每次有人试图链接 VxD 时都会对开发人员计算机上的文件进行更新。只要计算机开机并连接网络，没人会注意这一点。但是一旦计算机关机，一切就变得奇慢无比。
找到问题后，负责编译器的员工没用多久就向 Windows 团队提供了一个补丁，用它删除了链接器中的诊断代码。
不同的人员讲述这个故事时，高潮各不相同。我讲述时的高潮是：“这位编译器开发人员后来调到了 Windows 团队并成为了我的老板。”我非常乐意将这个故事当成一个无伤大雅的笑话反复宣讲。
但是，我的老板对这件事的描述截然不同。“事实证明，我没写过那个诊断代码。是我的一个同事编的，并且他不把它放在自己的机器上，却占用了我的机器！”

Raymond Chen 的网站“The Old New Thing”及同名著作均讲述了 Windows 的发展史及 Win32 编程。他对无用代码所知甚深。