October 2008 October 2008
虚拟化: Windows Server 2008 中的 Hyper-V 简介
Hyper-V 的引入使虚拟化成为对 IT 环境更加有吸引力的解决方案。了解如今的虚拟化市场并掌握 Hyper-V 如何提高虚拟化的可管理性、可靠性和安全性。 Rajiv Arunkundram
虚拟化: 使用 VMM 2008 管理您的虚拟环境
System Center Virtual Machine Manager 提供了一个综合界面来管理虚拟基础结构。最新版本添加了对 Windows Server 2008 Hyper-V 以及 VMware 虚拟机的支持。探索新功能并学习使用 VMM 来集中处理您的管理任务。 Edwin Yuen
虚拟化: Microsoft Application Virtualization 入门
Microsoft Application Virtualization (App-V) 允许您通过您的组织将虚拟化桌面交付给客户端系统。这大大简化了系统管理并使员工从其办公桌解放出来。仔细研究一下 App-V 的工作方式，会发现应如何在组织中对其进行部署。 Anthony Kinney
虚拟化: 实现 Hyper-V 的高可用性
将服务器合并到更少的物理机器中具有很多优势，但务必要对系统进行高可用性规划。本文介绍了使用 Windows Server 2008 故障转移群集为您的 Hyper-V 虚拟机提供高可用性。 Steven Ekren
虚拟化: 服务器虚拟化备份和灾难恢复
虚拟化为灾难恢复带来了重大改变。本文介绍了如何在您的灾难恢复计划中考虑 Microsoft 虚拟化平台因素，并深入探讨了 Windows Server 2008 Hyper-V 备份和恢复选项及注意事项。 Adam Fazio
虚拟化: 用于规划虚拟基础结构的基本工具
您的基础结构是否已做好虚拟化准备？针对整个网络的基础结构评估工具 Microsoft Assessment and Planning Toolkit 可帮您更好地了解您的 IT 基础结构，并可帮您确定系统是否已经做好升级或迁移至各种技术（包括虚拟化）的准备。 Jay Sauls and Baldwin Ng
Columns
编辑寄语: 遨游虚拟世界: | 读者来信: 读者心声: | 工具箱: 面向 IT 专业人员的新产品:
SQL 问题与解答: 大型事务日志、何时使用修复功能以及更多其他内容: 在本期内容中，Paul Randal 解答了一些有关备份和还原的问题，简单介绍了日志传送和数据库镜像之间的差异，并说明了为什么不要轻易使用“修复”功能。Paul S. Randal | 实用程序特别推荐: Offline Virtual Machine Servicing Tool: 脱机存储的虚拟机不能自动接收必需的更新，导致无法保证其安全性和兼容性。这会给整个 IT 环境带来风险。了解免费的 Offline Virtual Machine Servicing Tool 如何帮助您自动化更新虚拟机的流程。Peter Skjøtt Larsen and Suveen Kumar Reddy Vuppala | Windows PowerShell: 配置文件的力量: 是否希望 Windows PowerShell 在启动时显示根据您的需求定制的工作环境？Don Jones 将展示如何使用配置文件来自定义 Windows PowerShell 外壳。Don Jones
您好，脚本专家！: 临别感言: 脚本专家讨论苏格拉底并再次讨论有关查询 XML 文件的主题。但是，这次是结构化的 XML 文件，因此没有使用子节点，而是将附加属性值配置为属性。The Microsoft Scripting Guys | 桌面文件: 自定义 Windows 部署服务: Wes Miller 深入探讨了 Windows 部署服务，向我们展示了如何自定义和配置 WDS 以满足组织需求。Wes Miller | 安全观察: 再探安全性的十个永恒定律，第 1 部分: 从“安全性的十个永恒定律”首次发布迄今已有 8 年多的时间，自那以来安全领域发生了诸多变化。本月，Jesper Johansson 着手撰写了一篇由三部分组成的系列文章，站在现在的角度分析这些定律是否仍然成立。Jesper M. Johansson
领域备注: 高容量彩色条形码: Gavin Jancke 利用颜色和三角形开发出了新型的条形码，其数据容量要远远超出传统的黑白条形码。让我们密切关注这些高容量彩色条形码。Gavin Jancke | Windows 机密: 苦干，非巧干: Raymond Chen 研究了程序故障与错误之间的非正比关系，并解释了程序员通过苦干出成果的重要性Raymond Chen


虚拟化
Windows Server 2008 中的 Hyper-V 简介
Rajiv Arunkundram
概览：
  • 什么是虚拟化？
  • 三种虚拟化体系结构
  • 微内核化与整体化管理程序
  • Hyper-V 的作用

目录
服务器虚拟化市场
服务器虚拟化的工作原理
虚拟化解决方案的类型
Windows 管理程序
父分区
设备共享体系结构
集成组件
Hyper-V 功能集
可伸缩性
高可用性
安全性
可管理性
结束语
最近关于虚拟化的论述很多，大部分探讨的是服务器虚拟化。这是业界最令人兴奋的趋势之一，有可能在今后几年内转变 IT 系统的部署模式。服务器虚拟化不仅会改变 IT 管理员和架构师对服务器和系统利用率的考虑方式，对于那些必将成为动态环境的因素，它还会影响其管理过程和工具。
实际上虚拟化出现已有一段时间了，但此项技术仍在发展中。事实上，不同的人对这个单词本身有不同的理解。但是广义上说，虚拟化目的在于从下一个层抽象一个技术堆栈层，就像从服务器中抽象存储或从应用程序抽象 OS 一样。这样就可以实现合并，并获得更好的可管理性。
作为一个概念，虚拟化适用于存储、网络、服务器、应用程序和访问。当您查看存储和网络时，虚拟化的目标是聚合一组不同的设备，这样总资源池看起来以及操作起来就像单个实体。例如，您可以配置一个 40TB 存储解决方案来代替一个包含 20 个 2TB 存储设备的设备组。但对于其他组件，虚拟化的行为恰恰相反，它会帮助让单个系统发挥多个系统的作用。此方面的一个最常见示例是服务器虚拟化，您在单个服务器上托管多个 OS 实例和环境。
Microsoft 已经在多个不同的级别上实现了虚拟化，从桌面扩展到数据中心，其解决方案覆盖服务器虚拟化、应用程序虚拟化、演示虚拟化和桌面虚拟化。Microsoft System Center 的管理部件是贯穿其中的连接器。在本文中，我将集中讨论服务器虚拟化组件，特别是 Hyper-V（Windows Server 2008 的重要功能）如何适应动态数据中心。

服务器虚拟化市场
首先，我认为有必要了解当今的具体环境以及整个市场的发展趋势。据研究显示，一些分析人员估计目前售出的所有物理服务器中有 5–9% 被用作虚拟化主机。您可能认为这是很大的数量，因为市场上每年要发运九百多万台物理服务器。但有一件事情可以肯定：随着更多的客户对虚拟化非常熟悉而逐渐采用它，仍然存在着巨大的商机。
虚拟化的使用场合需要引起重视。大型企业客户无疑肩负着测试的职责，它们是早期的采用者。但是，一些中小型企业也在部署虚拟化。虚拟化已经在不同的工作负荷中得到普及，从业务应用程序和管理到 Web 和电子邮件皆是如此。
那么，为什么虚拟化现在如此时兴呢？这其中有几个因素，主要是时机。几个重要的行业因素同时聚合在一起，虚拟化因此得以更加广泛的采用。这些行业因素包括向 64 位计算的转换、多核处理器以及提高系统利用率所需的可持续计算。
系统持续增长，它们需要利用像虚拟化这样的技术来充分利用系统的功效。虽然核心技术（和摩尔定律）在提高系统处理能力方面已经稳步领先，但我们现在更为关心的是环境影响、功效要求和冷却成本。
因为有这些因素，再加上虚拟化能带来显而易见的投资回报率 (ROI)，使其迅速扩大了在大型和小型企业中的市场。作为 IT 专业人员，我们可以预计所有主要参与方在接下来的几年中会继续在这一技术领域进行投资，并改进特性和功能。

服务器虚拟化的工作原理
服务器虚拟化通常可以让您在单个物理设备上安装（并同时运行）两个或多个身份、应用程序堆栈等各不相同的 OS 环境。Hyper-V 是下一代基于 64 位管理程序的虚拟化技术，它提供了可伸缩的可靠平台功能。通过与 System Center 结合使用，它为物理和虚拟资源提供了一组集成的管理工具。
所有这些都可以减少成本、提高利用率、优化基础结构并使各企业能迅速置备新服务器。为了帮助您更好地了解 Hyper-V 的构建方式，我想先看看不同类型的虚拟化解决方案。

虚拟化解决方案的类型
从本质上讲，有三个常见的体系结构可用于服务器虚拟化，如图 1 所示。虚拟化层和物理硬件之间的关系处理决定着它们的根本差异。虚拟化层就是称为虚拟机监控器（VMM，不要与 Virtual Machine Manager 混淆）的软件层。该层可以创建多个共享同一底层硬件资源的独立实例。
图 1 三个虚拟化体系结构（单击图像可查看大图）
Type-2 VMM 体系结构的应用实例就是 Java 虚拟机。在该实例中，虚拟化的目标是创建一个运行时环境，进程可以在此环境中执行一组指令，而无需依赖主机系统。此时，隔离的是不同的进程，它允许单个应用程序在不同的 OS 上运行，而无需担心 OS 依赖关系。服务器虚拟化不属于这一类别。
Type-1 VMM 和 Hybrid VMM 是现今广泛使用的两种方法。VMM 利用 Hybrid VMM 在主机 OS 上运行并帮助创建上层虚拟机。Hybrid VMM 的示例是 Microsoft Virtual Server、Microsoft Virtual PC、VMware Workstation 和 VMware Player。请注意，虽然这些类型的解决方案非常适用于客户端方案（即，您只在部分时间运行虚拟机），但 VMM 会极大地增加开销，因而不适合资源密集的工作负载。
在 Type-1 VMM 体系结构中，VMM 层直接在硬件上方运行。这通常称为管理程序层。该体系结构最初由 IBM 于 20 世纪 60 年代针对大型机系统而设计，最近连同各种解决方案（包括 Windows Server 2008 Hyper-V）在 x86/x64 平台上提供。
在可用的解决方案中，管理程序是作为固件的嵌入式部件提供的。但这只是一个打包选项，并不会实际改变基础技术。
Type-1 VMM 实质上使用两种主要方法构建管理程序解决方案： 微内核化和整体化。这两种方法（如图 2 所示）是真正的 Type-1 VMM，它们将管理程序直接安装在物理硬件上。
图 2 构建管理程序解决方案的两种方法（单击图像可查看大图）
整体化管理程序方法在单层内托管管理程序/VMM，这一层还包括大部分必需组件（例如内核、设备驱动程序和 I/O 堆栈）。这一方法为 VMware ESX 和传统大型机系统之类的解决方案采用。
微内核化方法使用非常瘦的专用管理程序，它仅执行核心任务以确保分区隔离和内存管理。该层不包括 I/O 堆栈或设备驱动程序。Hyper-V 采用此方法。在此体系结构中，虚拟化堆栈和特定于硬件的设备驱动程序位于称为父分区的专用分区中。

Windows 管理程序
通过创建虚拟处理器、内存、定时器和中断控制器确保明确分隔多个 OS。OS 使用这些虚拟资源就像它们使用其相应的物理资源一样。
Windows 管理程序（Hyper-V 的部件）执行下列任务：
  • 创建逻辑分区。
  • 管理来宾 OS 的内存和处理器计划。
  • 提供虚拟化输入/输出以及在各分区之间进行通信的机制。
  • 强制实施内存访问规则。
  • 强制实施 CPU 使用率策略。
  • 提供称为 hypercall 的简单编程接口。
由于 Windows 管理程序使用微内核化方法，因此它非常小（不到 1MB）。这种最低的空间占用率可以帮助提高系统的整体安全性。
对于正在运行的 Hyper-V，需安装使用 Intel VT 或 AMD-V 技术的 x64 系统。通过 x64 技术可以访问更大的地址空间并支持内存更大的系统，从而可以在单个主机系统中安装多个虚拟机。Intel VT 和 AMD-V 是有硬件辅助的虚拟化解决方案，在环形体系结构中提供超级权限层，以帮助将管理程序的执行环境与系统其余部分隔离开来。它们还允许 Hyper-V 运行原装来宾 OS，不会产生大量的仿真性能损失。

父分区
Hyper-V 包括一个父分区，它实质上是一个具有特殊或特权级访问权限的虚拟机。这是唯一可以直接访问硬件资源的虚拟机。所有其他虚拟机（称为来宾分区）均通过父分区访问其设备。
父分区的存在是相当透明的。开始安装 Hyper-V 时，首先必须在物理系统上安装 Windows Server 2008 x64 Edition。然后需要转到 Server Manager、启用 Hyper-V 角色并重新启动系统。系统重新启动后，将首先加载 Windows 管理程序，然后将堆栈其余部分转换成父分区。
父分区有键盘、鼠标、视频显示器以及其他与主机服务器连接的设备的所有权。它并不直接控制管理程序使用的定时器和中断控制器。
父分区包含一个 Windows 管理规范 (WMI) 提供程序（便于管理虚拟化环境的方方面面），以及一个虚拟化堆栈（代表子分区执行与硬件相关的任务）。另外，父分区中还包含主机系统硬件所需的所有独立硬件供应商 (IHV) 驱动程序，针对 Windows Server 2008 x64 版本创建的所有驱动程序也将在父分区中运行。

设备共享体系结构
Hyper-V 中具有创新性的体系结构组件之一是新设备共享体系结构，它支持各个来宾 OS 中的模拟设备及合成设备。设备模拟对于支持带有上一代硬件设备驱动程序的旧式 OS 非常有用。例如，Hyper-V 包括 Intel 21140 网络适配器的模拟，在许多旧式 OS 刚刚面世时它称为 DEC 21140 网络适配器。
设备模拟速度通常很慢，不易扩展，也不能很好地调节。但模拟仍很重要，因为通过它您可以在 Hyper-V 上运行大多数 x86 OS。由于虚拟化现在已从主要针对测试和开发的小型技术转向生产环境所必需的技术，因此用户需要更好的性能才能运行更大的工作负载。模拟设备不再能满足这些日益增加的要求。
一个替代解决方案是使用 Hyper-V 合成设备。合成设备是可直接映射为物理设备的虚拟设备。与模拟设备不同，合成设备不会模拟原有硬件。通过 Hyper-V 硬件共享模型，受支持的来宾 OS 可直接与可能没有物理设备的合成设备交互。这些 OS 使用虚拟服务客户端 (VSC)，它在来宾 OS 中充当设备驱动程序。
VSC 使用 VMBus（即内存中的高速总线）来访问父分区中的虚拟服务提供程序 (VSP)，而不是直接访问物理硬件。然后父分区 VSP 会管理对底层物理硬件的访问，如图 3 所示。合成设备的主要优势在于其在 VMBus 上的性能更接近于非虚拟化硬件设备的性能。
图 3 VSC 使用 VMBus 访问 VSP，VSP 随后管理对底层物理硬件的访问（单击图像可查看大图）

集成组件
Hyper-V 的目标是为在同一计算机上运行的各种实例之间提供强边界。为在来宾 OS 与主机 OS 之间产生交互并为受支持的来宾 OS 提供附加功能，Hyper-V 提供了集成组件。
Hyper-V 集成组件支持以下功能：
  • 时间同步
  • 卷影复制服务 (VSS)
  • 检测信号功能
  • 来宾关闭
  • 项值对交换（用于访问来宾 OS 的注册表）
  • OS 识别
Hyper-V 功能集
毫无疑问，虚拟化平台的行为与物理服务器越接近，各个组织部署并依赖虚拟工作负载就更为容易。在我看来，您可以从四个重要领域来审视虚拟化平台的不同功能。
如今大多数基于管理程序的虚拟化解决方案在特性和功能方面彼此非常接近。随着我们的不断深入，总体拥有成本 (TCO) 和易于使用之类的内容将成为重要的区分标志。管理解决方案将预见后续投资和开发，使我们更接近动态 IT 环境的愿景，即，基础结构可以非常灵活地根据企业需求进行调整，而且模型和策略可帮助改进自动化和管理。

可伸缩性
使用微内核化管理程序体系结构，Hyper-V 中的 CPU 开销非常低，为虚拟化工作负载留出了大量的空间。通过让虚拟机利用强大的功能和硬件（例如，多核技术、改进的磁盘访问和更大的内存），Hyper-V 提高了虚拟化平台的可伸缩性和性能。
通过与 Windows Server 2008 的其余功能结合使用，Hyper-V 允许您在一个系统上合并大多数工作负载（包括 32 位和 64 位工作负载）。它还继续支持已在整个环境中使用的 32 位工作负载，帮助您平衡所采用的 64 位技术。
由于 Hyper-V 需要带有硬件辅助虚拟化的 64 位主机系统，因此可帮助确保主机系统有权访问大型内存资源池。Hyper-V 主机可以支持多达 1TB 的内存，其中每个虚拟机最多包含 64GB 内存。对于计划虚拟化非常耗费内存的工作负载（如 Exchange Server 和 SQL Server）的人员来说，这是非常关键的。
Hyper-V 在主机系统上还支持多达 16 个逻辑处理器，使 Hyper-V 可用于大部分商用多核双座和四座系统。您还可以创建最多包含四个虚拟处理器的虚拟机，以支持需要或利用多处理器功能的工作负载。
通过 Hyper-V 合并服务器还能使这些服务器利用强大的联网支持，包括 VLAN、网络地址转换 (NAT) 和网络访问保护 (NAP) 策略（隔离）。作为 Windows Server 2008 的一项功能，Hyper-V 可与其他 Windows Server 功能（如 BitLocker 和 Windows PowerShell）良好配合。

高可用性
高可用性是指 Hyper-V 和主机群集功能联手帮助解决业务连续性和灾难恢复需求。业务连续性能够尽可能缩短计划和非计划停机时间。这包括在例程功能上耗费的时间，如维护与备份以及意外停电。
灾难恢复是业务连续性的一个重要组成部分。自然灾难、恶意攻击甚至软件冲突等简单的配置问题都有可能导致服务和应用程序瘫痪，直到管理员解决问题并恢复数据后才能恢复正常。可靠的业务和灾难恢复策略必须将数据丢失降至最低并提供强大的远程管理功能。
考察高可用性时，应考虑三个不同的类别，即计划停机时间、非计划停机时间和备份。通常需要对计划停机时间加以保护，以帮助从主机系统移开虚拟机，这样您就可以执行硬件维护，或者对主机系统或虚拟化平台（可能需要重新启动）应用补丁程序。
大多数组织都对维护时间制订了计划，你真正需要的是最大程度减少或消除主机系统因维护关闭时虚拟机不可用的时间。通过快速迁移功能，您在数秒钟时间内便可迅速将正在运行的虚拟机从一个物理节点移到另一个物理节点。因而，当您对原始主机执行维护时仍能在生产中使用虚拟机。完成维护后，您便可以使用快速迁移将虚拟机重新送回原始主机系统。
非计划停机时间是指无法预见的停机时间。它本质上可能是灾难性的，可能就像某人意外拔出电源线而使服务器关闭一样。虽然这听起来不大可能，但这些年来我在 Tech•Ed、Vmworld 和其他会议上遇到了几个管理员，他们都向我讲述了一些服务器如何被某个同事意外关闭的情况。
通过 Hyper-V，您可以针对不同的主机系统设置主机群集并将所有虚拟机配置为群集资源，然后可以在其中某个主机发生故障的情况下故障转移到其他系统同时，Windows Server 2008 的多站点群集功能将使您能够设置一个分散于各地的群集，这样，如果您的主数据中心发生了故障，您可以将各个虚拟机恢复到远程数据中心。
这还为保护所有分支机构提供的便利。Hyper-V 中非计划停机时间支持的一大优势对来宾 OS 无限制，这意味着您可以将其高可用性优势扩展到 Linux 虚拟机以及旧版本的 Windows Server，从而以类似的方式保护并恢复这些系统。
考虑非计划停机时间时，请切记恢复相当于关闭系统并重新启动，这意味着您将丢失所有状态信息。这可能（也可能不）是问题，具体视您在虚拟机中运行的工作负载而定。这就是在高可用性上下文中要考虑备份的重要原因。
Hyper-V 允许您对每个虚拟机进行备份，或使用 VSS 对所有仍在运行且 VSS 可识别的虚拟机生成一致的备份。通过 VSS，您可以将备份设置为在设定的间隔进行，而不会影响生产工作负载的可用性，同时确保有连续的备份计划，以便帮助您在出现非计划停机时能轻松恢复状态。有关 Hyper-V 提供的高可用性解决方案的详细信息，请参阅本期 TechNet 杂志中由 Steven Ekren 撰写的文章“实现 Hyper-V 的高可用性”(technet.microsoft.com/magazine/cc837977)。

微内核化管理程序体系结构旨在最大程度地减少攻击面并增强安全性，尤其是在 Hyper-V 作为 Server Core 角色实施时更是如此。Server Core 是 Windows Server 2008 的一个安装选项。管理程序不包含任何设备驱动程序或第三方代码，为运行虚拟机提供了更加稳定、简洁且安全的基础。Hyper-V 还通过与 Active Directory 集成提供了基于角色的强大安全性。Hyper-V 可使虚拟机从硬件级别的安全功能（如执行禁用 (NX) 位）中受益，从而进一步帮助提高虚拟机的安全性。
像其他 Windows Server 组件一样，Hyper-V 已经渡过了安全开发生命周期 (SDL)，而且为确保 Hyper-V 是一个高度安全的虚拟化平台，已进行了大量威胁建模和分析。在部署 Hyper-V 时，一定要遵循部署 Windows Server 2008 以及 Hyper-V 的最佳实践。在您的计划中要将 Active Directory 以及防病毒和反恶意软件解决方案包含在内。并使用委派管理功能来确保您对 Hyper-V 主机使用适当的管理员访问权限。

可管理性
微小的服务器散乱分布问题很容易转变为严重的虚拟机散漫分布问题。这种风险要归因于部署虚拟机的低难度。随着虚拟机移动性的增加，您还需要承担了解不同虚拟机运行的准确位置、跟踪其安全上下文等等职责。
幸运的是，有了 Hyper-V，您就不必再为虚拟环境创建单独的管理基础结构。它与 Microsoft 管理工具、System Center Virtual Machine Manager 和 Microsoft System Center Operations Manager 以及第三方管理工具相集成。它让您可以从一个控制台管理您的所有物理和虚拟资源。有关 System Center Virtual Machine Manager 2008 的详细信息，请参阅本期 TechNet 杂志中由 Edwin Yuen 撰写的文章“使用 VMM 2008 管理您的虚拟环境”(technet.microsoft.com/magazine/cc836456)。同时，对 Windows PowerShell 的支持还使任务自动化变得更加容易。
Hyper-V 还让虚拟机能使用可用硬件，这是史无前例的。由于所有 Windows 硬件质量实验室 (WHQL) 认证的驱动程序都能够在父分区中运行，因此 Hyper-V 为驱动程序和设备带来了广泛的兼容性，从而使管理在您的环境中运行的各种驱动程序变得更加容易。

结束语
如我之前所述，管理将成为开发和区分的重要内容。在未来几年内您必将会看到这一领域内活动倍出。总的来说，当虚拟化担当更加主流的角色时，这确实是一个令人兴奋的时刻。如果您还没有试用过 Hyper-V 或者您只是想了解更多的详细信息，请转到 microsoft.com/Hyper-V。
Rajiv Arunkundram 是 Microsoft 的高级产品经理，主要负责 Windows Server 营销部门的服务器虚拟化。从技术和业务角度来看，Rajiv 的主要职责是与客户和合作伙伴合作，帮助他们了解 Microsoft 的虚拟化策略和解决方案。


虚拟化
使用 VMM 2008 管理您的虚拟环境
Edwin Yuen

本文基于 Virtual Machine Manager 2008 的预发布版。文中的所有信息均有可能发生变更。
概览：
  • 支持 VMware VM
  • 基于 Windows PowerShell 的脚本编写和自动化
  • 综合集中式管理
  • 安装过程

目录
Virtual Machine Manager 2008 简介
与 System Center 集成
Virtual Machine Manager 2008 安装
添加 VMware ESX 主机
VMotion 迁移
结束语
去年，Microsoft 推出了 System Center Virtual Machine Manager 2007，它为管理运行 Microsoft Virtual Server 2005 的虚拟基础结构提供了综合界面。现在，为配合新 Windows Server 2008 Hyper-V 管理程序的发行，发布了新版本的 Virtual Machine Manager (VMM)。System Center Virtual Machine Manager 2008 不仅管理 Microsoft Virtual Server 2005 和 Windows Server 2008 Hyper-V 的安装，还支持 VMware Infrastructure 3 (ESX/ESXi) 服务器。通过 VMM，您现在可获得一个适用于整个虚拟基础结构（包括 Microsoft 和 VMware 系统）的集成管理界面。
VMM 支持所有传统虚拟化任务，例如，源自模板和预配置 VM 的快速虚拟机 (VM) 部署、物理到虚拟 (P2V) 转换、集中式虚拟基础结构对象库，甚至 VMware 虚拟机（VMX 配置文件和 VMDK 虚拟磁盘）到 Hyper-V VM 的虚拟到虚拟 (V2V) 转换。此外，VMM 与 System Center 系列其余部分的集成将物理系统和虚拟系统的管理引入到了单一管理平台中。
在本文中，我将介绍 VMM 2008 及其为 IT 管理员带来的新功能。然后，我将介绍 VMM 安装所涉及的要求和步骤。最后，我将进一步探讨如何使用 VMM 2008 中的某些新功能。

Virtual Machine Manager 2008 简介
System Center Virtual Machine Manager 2008 是一个独立的应用程序，它为在 Microsoft Virtual Server 2005 R2 SP1、Windows Server 2008 Hyper-V、Microsoft Hyper-V Server 2008 和 VMware Infrastructure 3 (ESX/ESXi) 服务器下运行的虚拟机提供了企业级集中式管理。与其他 System Center 产品结合使用时，VMM 可提供端到端物理和虚拟基础结构管理。图 1 显示了 Virtual Machine Manager 的体系结构布局。
图 1 System Center Virtual Machine Manager 2008 体系结构（单击图像可查看大图）
熟悉 VMM 2007 的人应该发现，VMM 2008 中进入 VMM 系统的界面要多得多（请参见图 1）。左上角的方框表示 VMM 2008；右上角的方框表示 System Center Operations Manager 2007，下方显示的是托管系统和界面。红色方框指示管理服务器，蓝色方框显示系统输入，绿色方框是托管主机系统，其托管对象以黄色显示。
左上角的红色方框代表 Virtual Machine Manager 2008 服务器服务。它的上面是进入服务的三个不同界面；管理员控制台、Windows PowerShell 界面以及具有委派用户访问权限的自助 Web 门户。Windows PowerShell 是所有对 VMM 服务器访问的基础。VMM 管理员控制台完全基于 Windows PowerShell 构建而成，因此您只需创建 VMM 服务器服务运行的 Windows PowerShell 脚本即可。因而，VMM 2008 的公共 API 是 Windows PowerShell，任何程序都可以通过 Windows PowerShell 利用 VMM。一个不错的示例就是 Citrix 的 XenDesktop Desktop Delivery Controller 与 Virtual Machine Manager 的集成，它是完全通过 Windows PowerShell 实现的。
起支持作用的 VMM 是一个 SQL Server 2005 或 SQL Server 2008 数据库（如果没有其他数据库可用，可使用完全安装的 SQL Server 或 SQL Server Express Edition）。虽然图表显示 Operations Manager 和 Virtual Machine Manager 均指向 SQL Server，但这两个程序不是共享一个数据库。它们只是在同一版本的 SQL Server 上运行。Virtual Machine Manager 与 Operations Manager 之间的实际集成是通过一个连接器（通过 VMM 提供）实现的。此连接器允许 VMM 和 OpsMgr 共享数据，从而将虚拟化信息带入 OpsMgr 并将 OpsMgr 数据带入 VMM 以进行操作。
图表下半部分显示的是托管主机。VMM 2008 仍管理 Virtual Server 2005 R2 SP1 虚拟机主机和集中式库共享，与 VMM 2007 中一样。应当注意，在 VMM 中，库共享并不是特殊的文件存储或服务器。它只是一个 VMM 管理的 Windows 文件共享。您可以通过 VMM 管理库，也可以轻松地从文件共享复制和删除文件并让 VMM 发现变化。您还可以拥有多个库，这对于委派的服务器组和远程办公室的服务器非常有用。
VMM 2008 新增了管理 Hyper-V 和 ESX 管理程序的功能。Hyper-V 主机的管理是通过 Windows 远程管理 (WinRM) 和 Windows 管理规范 (WMI) 界面完成的。实际上，添加可能存在的 Hyper-V 主机时，如果 Hyper-V 角色未在 Windows Server 2008 中启用，那么 VMM 可以自动为管理员启用该角色。此功能也可用于 Windows Server 2003 系统的潜在 Virtual Server 主机。
VMware VI3 ESX 主机的管理实际上是通过 VMware VirtualCenter 服务器完成的。VMM 2008 通过 VirtualCenter Web 服务 API 与 VirtualCenter 衔接。因而，VMware 管理需要 VirtualCenter 服务器，大多数企业安装的 VMware 都至少有一个 VirtualCenter 服务器。VMM 2008 的独特功能是可以管理多个 VirtualCenter 服务器。VMM 可以添加多个 VirtualCenter 服务器，允许管理员聚合整个 VMware 基础结构并提供单一企业视图，之前无法做到这一点。
作为 System Center 系列产品的一部分，VMM 在管理员控制台中使用 System Center 或 Outlook 样式的界面。VMM 管理员控制台并不是 MMC 管理单元；它是一个全新的应用程序，采用 Microsoft .NET Framework 并以 Windows PowerShell 1.0 为基础构建而成。事实上，正如之前提到的，管理员控制台中的任何操作均将调用关联的 Windows PowerShell 命令，因此 UI 实际上是使用 Windows PowerShell。在管理员控制台中执行的任何命令或函数也可通过 Windows PowerShell 中的命令行来执行。
管理员控制台中的每个向导都包含一个“View Script”（查看脚本）按钮，用于显示要运行命令的相关 Windows PowerShell 脚本，从而为学习 Windows PowerShell 提供一个不错的起点，因为它与 VMM 相关。“查看脚本”操作（VMM 2008 中的新增功能）现在可在记事本中打开这些脚本，因此您可以轻松地直接从 VMM 对其进行编辑。您也可以轻松地保存编辑过的脚本，然后可以直接从 VMM 库（VMM 2008 中的另一新增功能）重新使用它。VMM 2007 中的 cmdlet 已在 VMM 2008 中进行了更新，包括对 VMware 服务器的支持。同一 cmdlet 可跨多种虚拟化平台工作，这样，cmdlet（如 New-VM）就可在 Microsoft 和 VMware 系统中发挥功效。因而，IT 管理员可以使用一组 cmdlet 来管理 Virtual Server、Hyper-V 和 VMware ESX 主机。
Virtual Machine Manager 2008 旨在向 IT 管理员提供以下三个重要优点：
  • 最大限度地利用资源
  • 具备更好的灵活性
  • 充分利用现有技能
多种特性和功能共同铸就了这些优点。首先，VMM 通过将整个虚拟基础结构的管理进行集成（有无管理程序皆可）帮助您最大限度地利用资源。通过将 Microsoft 和 VMware 系统集成，VMM 2008 提供了包含所有主机和虚拟机的单一视图（如图 2 所示），并允许管理员按参数（如主机、操作系统、所有者、添加日期等）筛选和查看其系统。
图 2 VMM 控制台显示集成式 Microsoft 和 VMware 管理（单击图像可查看大图）
VMM 也可通过便利的服务器合并与转换（如 P2V 和 V2V）帮助您最大限度地利用系统资源。P2V 允许您将现有物理机合并为虚拟机，而无需重新安装这些机器。在转换硬件利用率较低的计算机时，这一点尤为有用，这样您可通过将多台低利用率计算机一起放置在单个物理硬件上而最大限度地利用资源。P2V 是 VMM 的一个集成功能，不需要另行增加软件或服务器。在 VMM 2008 中，支持更多物理系统，包括 Windows Vista、Windows Server 2008 和 x64 主机。VMM 的 P2V 功能是计划工具（如 Microsoft 评估规划 (MAP) 工具）的出色助手（本期《TechNet 杂志》中由 Baldwin Ng 和 Jay Sauls 撰写的文章中对此工具做了介绍），可帮助确定服务器合并的候选对象。
如果虚拟机是 Vmware 的 VMDK 格式，VMM 允许您使用 V2V 将现有 VMDK 转换成 VHD 格式。这是一个离线进程，即当 V2V 进程将实际 VMDK 文件转换成 VHD 时，VMware VM 必须关闭。也可以使用 P2V 功能转换正在运行的 VMware VM。这可能听起来有点乱，但请切记虚拟机是机器在先，虚拟在后。其他所有系统将 VM 视为正在运行的机器，VMM 的 P2V 功能也是如此，它允许您将任何虚拟化软件上正在运行的 VM 转换为 Microsoft VHD。
VMM 通过多项功能为 IT 管理员提供了更大的灵活性。其中一个重要功能是将 VM 从一个主机迁移到另一个主机，从而保证高可用性并优化服务器。VMM 2008 通过 Hyper-V 主机支持快速迁移，这样只需停机几秒便可在 Hyper-V 主机之间移动 VM。这需要 Windows Server 2008 群集和共享存储，但 VMM 可帮助简化管理和配置。
通过 VMware ESX 主机，VMM 2008 还支持 VMware Vmotion，即不需要明显中断便可移动 VM 的 VMware 功能。它需要有启用 Vmotion 的 VMware ESX 主机，就像群集和 SAN 后端垂青快速迁移一样。在下文后面的内容中，我将使用 VMM 2008 向您介绍 Vmotion。
最后，VMM 2008 可以将现有 Virtual Server 2005 VM 迁移到 Hyper-V 主机上，从而自动执行迁移所需的所有升级和转换。
无论是转换还是新部署，在任意 VM 部署（包括前面介绍的迁移）中，VMM 均使用名为“智能定位”的进程将 VM 部署到主机。它还使用“智能定位”查询所管理的所有虚拟机主机、检索这些主机资源可用性的多个参数，然后返回可将 VM 部署到其中的推荐主机加权列表。正如图 3 所示，“智能定位”支持 Microsoft 和 VMware 主机及其存储配置。VMM 2008 中的“智能定位”既可识别平台又可识别配置。因此，它仅推荐适合正确主机平台的主机；如果需要高可用性则只推荐群集主机，对于 x64 VM 只推荐使用 x64 的主机。
图 3 智能定位分析所有可用的主机（单击图像可查看大图）

与 System Center 集成
VMM 2008 的关键功能之一是与 System Center Operations Manager 2007 的集成。虽然 VMM 2007 可与 Operations Manager 进行某种集成，但 VMM 2008 包括一个 Operations Manager 产品连接器，极大地增强了这一集成功能。通过与 Operations Manager 的集成，VMM 提供了管理员控制台出具的综合操作管理器报告，以及一项称为性能和资源优化 (PRO) 的全新功能。
PRO 使 VMM 2008 可以创建称为“PRO 提示”的警报，甚至可以根据 Operations Manager 的监视参数执行自动补救操作。图 4 显示了一些 PRO 提示的示例。使用启用 PRO 的管理包（PRO 包）时，VMM 2008 可以执行自动操作，例如，根据基于主机、管理程序、硬件乃至工作负载的性能参数迁移 VM 和新建 VM。
图 4 PRO 提示为虚拟基础结构中所存在的问题提供了警报和补救措施（单击图像可查看大图）

Virtual Machine Manager 2008 安装
要安装 System Center VMM 2008，需要满足几个先决条件和新系统要求。首先，VMM 2008 服务器要求有 Windows Server 2008 x64。该服务器不能安装在 Windows Server 2003 或 Windows Server 2008 的 x86 版本中。管理员控制台和其他组件仍可安装在 Windows Server 2003、Windows XP 或 Windows Vista（对于控制台）中，要求和安装过程与 VMM 2007 一样。
其次，VMM 2008 要求其安全模型安装在 Active Directory 域中。VMM 2008 支持外围网络（未加入域的）主机的管理，包括非域系统的 P2V（此为 VMM 2008 的新增功能）。使用 Windows Server 2008 作为安装平台的优势之一就是 VMM 的许多先决条件（如 .NET Framework 3.0、WinRM 和 Windows PowerShell 1.0）已经内置。最后，VMM 2008 需要 Windows 自动安装工具包 (WAIK) 3.0，虽然 VMM 2008 安装程序已包括安装文件。
尽管我建议在生产环境中的生产服务器上分别安装每个 VMM 组件，但我将介绍的是单服务器安装。安装 VMM 服务器的建议硬件是基于 x64 的服务器、至少 2GB RAM 且主频为 2.8GHz 或更高。由于它是具有本地 SQL 数据库的单服务器安装，因此需要 7GB 的硬盘空间。请注意，如果使用远程数据库，则 VMM 安装本身仅需 1GB。本地库安装另外需要 80GB 的硬盘空间。
如前所述，VMM 在 Windows Server 2008 x64 安装中运行。需要的其他软件包括 .NET Framework 3.0、Windows PowerShell 1.0、WinRM 和 IIS 6.0 或更新版本（用于自助门户）。还需要有 Microsoft MSXML 6.0 Parser，但它是 .NET Framework 3.0 的一部分。
在开始 VMM 安装时，提供有五个选项：Virtual Machine Manager Server、管理员控制台、自助门户、本地代理以及配置 Operations Manager 管理包的选项。如前所述，我将在单个计算机上安装全部组件，从 VMM Server 开始。安装开始后，第一个屏幕将检查系统先决条件。
除了之前提到的要求之外，计算机必须处于域中。VMM 服务器安装将自动为您启用内置功能，因而无需手动启用它们。
启动安装程序后，我建议使用 Windows Update 选项确保 VMM 2008 是最新的。然后安装程序会检查主要与 SQL 数据库安装有关的选项。在此示例中，我将使用 SQL Server 2005 Express Edition。
接下来，向导会要求您确定集中式库的位置。该位置可以是 VMM 服务器上的本地目录（会针对该目录创建共享），也可使用现有文件共享。默认位置为 C:\ProgramData\Virtual Machine Manager Library Files。
下一步是分配端口。在此步骤中，我需配置核心 VMM 服务器服务与管理员控制台连接所用的端口（默认端口为 8100）、WinRM 用于执行管理功能的端口（默认端口为 80）以及后台智能传输服务 (BITS) 用于将文件移动到虚拟机主机的端口（默认端口为 443）。输入完此类信息后，将显示摘要屏幕，服务器安装到此结束。
接着，我将安装管理员控制台，其系统先决条件与 VMM 服务器相似。除了安装目录之外，唯一可用的配置选项是确认用于连接 VMM 服务器服务的通信端口。该端口应为 8100（在 VMM 服务器安装中所配置的）。
安装结束时，会让您选择创建管理员控制台的桌面快捷方式以及在结束安装后打开控制台。最好是两者皆选。首次打开管理员控制台时，系统会提示您连接服务器。在单服务器安装环境中，应连接端口 8100 上的 localhost，这样只需按 Enter 便可启动控制台。
最后，我将安装自助门户。安装此功能的前提条件是必须具备 IIS 6.0 或 7.0、.NET Framework 3.0 和 Windows PowerShell 1.0。（因为自助门户正是核心 VMM 服务的另一个界面，它要使用 Windows PowerShell，所以需要有 Windows PowerShell。）对于 Windows Server 2008，您需要在开始安装 VMM 2008 之前启用 IIS 角色。执行此操作时，请确保下列 IIS 角色服务已被启用：
  • 常用 HTTP 功能（静态内容、默认文档、目录浏览、HTTP 错误）
  • 应用程序开发（ASP.NET、.NET 可扩展性、ISAPI 扩展、ISAPI 筛选器）
  • 安全性（请求筛选）
  • IIS 6.0 管理兼容性
如果已启用这些角色服务，安装将通过先决条件检查并继续进行。在安装过程中，配置选项仅处理自助门户使用的端口。第一个端口是连接核心 VMM 服务的 8100 端口，与管理员控制台相同。第二个端口是用于运行门户的端口。默认端口为 80，但是，在许多配置中，该端口可能已占用，如果是这样，VMM 安装程序会发出警告。必要时，将此端口更改为另一打开的端口（如 8080）。安装程序会创建一个名为“Microsoft System Center Virtual Machine Manager 2008 Home 自助门户”的网站。可在 Server Manager 中更改此配置。
完成 IIS 安装后，只需转到 Internet Explorer 中的 localhost:8080 便可打开此网站。如果在打开网站的过程中系统提示您进行身份验证，那是 Internet Explorer 安全设置所导致的。应在 Internet Explorer 的 Intranet 环境中运行自助门户；您可能需将 VMM 服务器添加到 Internet Explorer 中的 Intranet 站点列表中。完成此类配置后，您将随时可以在 VMM 2008 中创建和使用启用自助的 VM。

添加 VMware ESX 主机
虽然 VMM 2008 中有许多新增功能，但最让人心动的无疑是添加了对 VMware ESX 主机管理的支持。有了这个支持，VMM 现在可以管理绝大多数企业 IT 部门的虚拟基础结构。
将 ESX 主机添加到 Virtual Machine Manager 2008 相当简单。如前所述，VMM 2008 通过 VirtualCenter 服务器（它必须是 2.0.1 或 2.5 版本）管理 Vmware 主机。要将 VMware ESX 服务器添加到管理控制台，只需使用位于“操作”窗格右上角的“添加 VMware VirtualCenter 服务器”操作来添加 VirtualCenter 服务器。
启动向导后，键入 VirtualCenter 服务器的计算机名称以及 VirtualCenter 服务器的管理帐户。VMM 便会将 ESX 主机（包括 VirtualCenter 中的现有“主机组”结构）添加到 VMM 界面中。此任务执行需要几分钟时间，但您可从“VMM 作业”菜单监视进度。
导入所有服务器后，您应该可以在 VMM 中看到与 VirtualCenter 中相同的 VMware ESX 主机服务器结构。要添加另一 VirtualCenter 服务器，只需重复此过程即可。将主机结构添加到 VMM 中后，可以将非 VMware 服务器添加到同一组结构中。当然，非 VMware 服务器不会显示在 VirtualCenter 中。
VMM 2008 使用 VirtualCenter 管理 ESX 主机时，它必须能够直接访问 ESX 主机本身以使用某些功能，例如，V2V、保存状态以及从 ESX 主机克隆 VM。因此，将 VirtualCenter 服务器添加到 VMM 后，主机将显示为“确定（受限）”。要启用完全管理，请转到 VMM 中各个 ESX 主机的“属性”页，并提供适当的主机凭据以直接管理服务器。

VMotion 迁移
每当讨论 Virtual Machine Manager 2008 中的 VMware 管理时，总是会问到这样一个问题，即 VMM 是否可以执行 VMotion 和其他 VirtualCenter 功能。由于 VMM 使用 VirtualCenter 进行 VMware 管理，因此此问题的答案是肯定的！
从功能上讲，VMM 给予 VMotion 和其他任何迁移一样的待遇。要启动 Vmotion，首先选择要移动的 VM，然后从 VMM 右侧的“操作”窗格中选择“迁移虚拟机”选项。完成后，VMM 将调出该 VM 的“智能定位”窗口并显示潜在的目标主机（迁移类型为 Live），如图 5 所示。智能定位可以帮助您为您的 VM 选择正确的目标主机。请注意，此过程与使用 Hyper-V 主机执行快速迁移相同。
图 5 使用智能定位的 VMotion（单击图像可查看大图）
为 VM 选择目标主机（在本例中，选择名为 cqaesxi003.contoso.com 的服务器，然后单击“Next”（下一步））。最终摘要窗口（如图 6 所示）将显示请求的操作。
图 6 VMotion 摘要窗口（单击图像可查看大图）
如前所述，VMM 中的每个向导都有一个“查看脚本”按钮，可在记事本中显示作业的 Windows PowerShell 脚本。这样，我们就可以看到 VMM 2008 中的 Windows PowerShell 如何与 Vmware 协同工作。以下是此操作的脚本：
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
该系统通过三个简单的命令执行 Vmotion。在我的示例中，我将 VM MyVM 从 VMware 服务器 cqaesxi003.contoso.com 移到服务器 cqaesxi001.contoso.com。第一个命令用于确定要通过 VMotion 迁移的虚拟机。正如您所看到的，在此命令行中，我将虚拟机值分配给变量 $VM：
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
第二个命令用于确定 VM 的目标 ESX 主机系统。在此行中，我将变量 $VMHost 分配给 ESX 主机 cqaesxi003.contoso.com：
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
最后，我使用 Move-VM 命令来实际移动 VM。以下是用于 Move-VM 的完整命令行和参数：
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
按照 Virtual Machine Manager 中的异类管理哲学，您可以看到此命令并不是特定于供应商或软件的。要完成 Vmotion，请发出以下命令：
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
这将告诉 VMM 针对 $VM 中的 VM 运行 Move-VM，从而移到 $VMHost 中的主机系统，并异步运行作业。作业开始后，可以从 VMM 中的“作业”窗口监视整个过程。同样，可以使用这一相同的基本命令对 Hyper-V 群集乃至非群集主机（使用基于 LAN 的迁移）执行快速迁移。
您可以看到，通过引入新的管理平台和新功能，System Center Virtual Machine Manager 2008 进一步提升了 Virtual Machine Manager 2007 的出色特性和功能。通过查看安装过程和几个功能，我希望我已经展示了在 VMM 2008 中管理多个管理程序有多简单。
VMM 2008 旨在成为管理虚拟化的综合软件，它将 Microsoft 和 Vmware 的物理和虚拟系统集于一体。通过这一新版本的 Virtual Machine Manager，VMware 管理员、Microsoft Virtual Server 2005 管理员以及新 Hyper-V 管理员均可以在其虚拟基础结构中利用单一工具、单一脚本界面以及单一管理过程（这一点最为重要）。

Edwin Yuen 是 System Center Virtual Machine Manager 的 Windows 企业管理部门的技术产品经理。Edwin 是在 2006 年 7 月 Microsoft 收购 Softricity 后加入 Microsoft 的。Edwin 还具有 13 年在商业和联邦部门担任技术顾问的经验。他拥有约翰-霍普金斯大学的电气工程学士学位。


虚拟化
Microsoft Application Virtualization 入门
Anthony Kinney

本文基于 App-V 的预发布版本。文中的所有信息均有可能发生变更。
概览：
  • App-V 体系结构
  • 管理虚拟应用程序
  • 使用 App-V 排序器
  • 将 App-V 与 Configuration Manager 集成

目录
App-V 体系结构
App-V 完整基础结构的工作原理
更新虚拟应用程序
排序
版本 4.5
Microsoft Application Virtualization（或 App-V）现在与我是心心相印了。App-V 过去称为 SoftGrid，我是在 Microsoft 收购创建 SoftGrid 的公司 Softricity 之后加入 Microsoft 的。现在，我为有机会为《TechNet 杂志》撰写本文倍感兴奋，因为在收购之后发生了很多变化。
要了解 App-V，最好先探讨一下 IT 专业人员在企业管理方面面临的挑战。如今的商用台式机遭到了应用程序的冲击。在安装某个应用程序之前，它必须要经过一个漫长的回归测试，以确保它能与系统中安装的其他应用程序共存，且不会影响它们正常运行的能力。然后应用程序必须在其投入生产之前完成一系列的部署流程。由于应用程序基本上只能在安装位置使用，因此您的用户将被限制到特定的计算机。这使复杂而又关键的项目（例如，OS 和应用程序迁移、安全刷新和灾难恢复计划）更为复杂。
App-V 彻底改变了这一局面。有了 App-V，台式机管理变成了一个自动化的便捷流程，而不是一系列复杂、耗时而又占用资源的步骤。您可以更加轻松地部署、修补、更新和终止应用程序，同时获得更好的结果。
通过 App-V，用户可以坐在任何台式机前访问其应用程序。应用程序会按需交付，但运行起来与实际在本地安装并无二致。因此，没有必要安装应用程序组件或改变主机设备。
这种虚拟化的使用使 IT 专业人员对台式机的管理方式发生了巨大变化。不用改变主机设备，代之以运行虚拟化应用程序，这会带来诸多益处，包括：
  • 减少了应用程序的冲突
  • 应用程序更新更快、更方便
  • 可以并行运行同一应用程序的多个版本
  • 应用程序能灵活适应在线和离线用户
  • 减少了应用程序到应用程序的回归测试

App-V 体系结构
现在让我们来看一下在 App-V 平台的后台实际上发生了什么。此平台由几个主要组件组成：排序器、数据库、客户端、管理服务器、流式服务器和管理控制台（请参见图 1）。
图 1 App-V 环境的布局（单击图像可查看大图）
App-V 系统的核心是 App-V 客户端。可以使用两种类型的客户端，即终端服务器客户端和桌面客户端。无论哪种情况，您计划在其上部署虚拟应用程序的每个桌面和终端服务器上均应安装客户端。此客户端占用的磁盘空间很少。它将安装一个驱动程序和可见的用户运行时组件（显示为任务栏指示器）。
此客户端将从 App-V 管理服务器收集虚拟应用程序的列表并显示可用的虚拟应用程序。它负责启动这些应用程序（由用户启动时）并管理客户端缓存。客户端还负责管理虚拟运行时环境的创建并确保各个环境在其自己的虚拟设备中运行。这种虚拟环境有多个组件，包括虚拟注册表、虚拟文件系统和虚拟服务管理器。
App-V 4.5 中提供了三个基础结构部署选项：完整基础结构、轻型基础结构和独立模式。部署完整基础结构时，后端包括 App-V Management Server 和 App-V Streaming Server（这是一个新组件，我稍后会加以介绍）。App-V Management Server 将托管和交付集中式虚拟应用程序，并会在应用更新或修补程序时更新虚拟应用程序。
此管理服务器依靠 SQL Server 来托管 App-V 数据库，该数据库包含虚拟应用程序的配置和设置。您应使用 Active Directory 组作为中央管理工具来置备和控制虚拟应用程序的权限。
为管理设置和配置，App-V 平台提供了一项 Microsoft .NET Framework Web 服务，只要安装了 IIS，便可在同一服务器上加载此服务。此 Web 服务充当 App-V 管理控制台（Microsoft 管理控制台 (MMC) 管理单元）与 App-V 数据库之间的联系人。管理员可以使用此控制台来发布和管理虚拟应用程序、分配 Active Directory 组、控制服务器设置以及运行虚拟化应用程序使用情况报告（请参见图 2）。
图 2 管理控制台（单击图像可查看大图）
轻型基础结构包括 App-V 流式服务器，它可执行活动/软件包升级等流功能。此选项不需要 Active Directory 或 SQL Server，它没有桌面配置服务，而且不具备许可和计量功能。不过，轻型基础结构允许将流功能添加到 System Center Configuration Manager (SCCM) 和其他第三方企业软件部署 (ESD) 解决方案。
在独立模式下，App-V 排序器可以创建 MSI 文件，用它自动添加虚拟应用程序（请参见图 3）。MSI 文件包含元数据，任何 ESD 系统都可以识别该数据并控制虚拟化应用程序。此模式要求客户端处于独立模式，这样只允许虚拟应用程序有基于 MSI 的更新，不允许出现流。此模式允许组织利用 App-V 隔离功能。
图 3 App-V 排序器（单击图像可查看大图）
MSI 文件非常灵活，只要有 App-V 客户端，它们就可以完全独立运行，而不需要任何服务器组件。这意味着它们可以手动部署（使用磁盘），也可以通过任何传统部署工具部署。
在 App-V 4.5 中，HTTP 和 HTTPS 是当前支持流的协议。这样就可以获得更好的流性能，采用更广泛的协议，尤其对于跨安全广域网 (WAN) 和跨 Internet 的流更是如此。

App-V 完整基础结构的工作原理
用户登录到装有客户端（App-V 终端服务或桌面客户端）的设备，客户端会向服务器请求分配给当前用户的应用程序列表。服务器将与 Active Directory 进行通信，以确定此用户所属的组，然后将应用程序的列表重新返回给客户端。客户端便开始针对已分配给该特定用户的虚拟应用程序构建公告。
在此发布过程中，要执行多个操作：
  • 复制配置文件
  • 创建桌面图标
  • 创建“发送到”链接
  • 创建开始菜单文件夹
  • 配置文件类型
此过程非常快速，最重要的是，它可确保环境看起来与用户预期的一样，没有什么直观变化。虚拟应用程序会像它们在本地安装那样运行，当然，它们不会改变主机。图标指向 App-V 客户端（它依赖于启动程序文件 (OSD 文件) 进行配置），而不是指向驻留在程序文件目录中的可执行文件。
特别要注意，此过程对网络的影响非常小，因为与传统软件部署不同，不需要安装任何东西。这有极大的好处，尤其是在漫游用户环境中，因为应用程序可供用户使用，但在应用程序启动之前不会实际交付任何内容。这种公告方法还提供了 App-V 的按需和漫游应用程序功能。
当用户启动虚拟应用程序时，客户端会读取 OSD 配置文件，此文件存储在本地计算机中。这将告诉客户端与 App-V 管理服务器进行通信时使用哪个协议以及该应用程序驻留在哪台服务器上。
相应的服务器会向下传送初始启动阈值（通常为完整应用程序的 20–40%）以响应客户端。整个启动阈值传送完成后（再次重申，只是应用程序的 20–40%），虚拟应用程序便可以运行了。
这种流实际上是随 App-V 引入的模式转变的关键元素之一。它只发送足量的应用程序，以使应用程序在运行时不会浪费宝贵的网络宽带。发送给客户端的所有数据均驻留在设备上的本地缓存文件中，可从本地缓存启动此应用程序的所有后续启动，从而消除额外的网络流量。
虚拟应用程序完成流操作后，客户端会构建一个隔离环境，以防止此应用程序改变本地计算机（也就是说，应用程序不占用客户端空间）。但是保存和编辑文件时，客户端允许虚拟应用程序访问本地文件系统，只要用户在本地系统中具有相应的权限，它还允许应用程序与本地服务（如打印）进行交互。但虚拟应用程序对本地系统的文件和注册表所做的任何更改都将被重定向到虚拟化环境，以便主机设备保持不变。
当应用程序运行时，之前没有使用的所有功能都将根据需要交付并缓存以备后续使用。这样做的好处是初始启动时只会加载用户需要的组件，不需要的功能不会消耗网络资源。（新版本提供了一些客户端缓存方面的改进，使缓存使用率和后台流更加智能化。）
以 Microsoft Office Word 为例。几乎所有用户都使用拼写检查器（没有它我根本无法撰写本文！）；因此，它是初始启动的一部分。但 Word 中的“帮助”功能又是怎么样呢？没有那么多的用户使用此功能，因此，不需要在初始启动中交付。它会在某个用户对其进行首次访问时被发送给该用户。
当用户完成操作后关闭应用程序时，客户端会消除虚拟环境并将所有用户设置存储在用户特定的位置，以保留该环境并在下一次启动时重新构建。虚拟应用程序已被传送的部分（百分比）均保留在本地缓存中，可供下一次启动使用。如果其他用户登录到同一主机系统并启动同一虚拟应用程序，则此新用户将从已存储在缓存中的应用程序受益。
要删除虚拟应用程序公告，只需将此用户从相应的 Active Directory 组中删除即可。要将虚拟应用程序从台式机中完全卸载，只需清除缓存即可。由于应用程序永远不会真正安装在本地，因此不会出现询问您“您是否要删除此共享组件？”这样烦人的提示。
请注意，即使虚拟应用程序存储在缓存中，也并不意味着所有用户都有权访问它。与本地安装的应用程序不同（用户只需搜索或浏览他们无权访问的可执行文件），虚拟应用程序的存在没有直观或物理表示，除非 Active Directory 组向此用户授予了相应的显式权限。

更新虚拟应用程序
更新是使用排序器来完成的。应用程序经过修订包括更新后，便可将其置于下一版本的 App-V 管理服务器上。该服务器随后会在下一次启动时通知客户端发生了更改。如果仍使用前一版本，则用户依旧可以访问该版本，直到虚拟应用程序关闭。下一次启动时，构成更新的变化量将被向下传送到客户端并载入缓存，从而形成了应用程序的更新版本。
假设您有 1,000 名用户在运行 Word 2000。管理员需要将 Word 2000 (word2K.sft) 更新为 Word 2000 SP3，因此她将 word2K.sft 文件复制到排序站并在排序器中选择“Open for Package Upgrade”（打开软件包升级）。选择该选项后，管理员便可从上一软件包状态开始工作。然后她可以复制 DLL，运行更新，或在虚拟应用程序内执行修补程序以将其更新为 Word 2000 SP3。之后，管理员将保存这个已更新的软件包。
排序器会自动分配一个新文件名 (word2K_2.sft)，以防止文件重名并指示排序的版本。将此新软件包与旧软件包置于 App-V 管理服务器的同一目录中，以使 Word 2000 (word2K.sft) 和 Word 2000 SP3 (word2K_2.sft) 最终驻留在相同目录中。管理员之后会使用 App-V 管理控制台将这两个 SFT 文件连接在一起。
在客户端，打开 Word 2000（不带 SP3）的活动会话的用户将继续正常工作。在管理员完成上述链接操作之后启动应用程序新会话的用户将会收到一条消息，指示已检测到更改。然后客户端开始仅向下传送 word2K.sft 与 word2K_2.sft 之间的变化量，并将应用程序自动更新为 Word 2000 SP3。
由于虚拟应用程序具备动态特性，因此回滚操作也是非常容易的。只需返回到 App-V 管理控制台并删除新添加的版本。这会使客户端在重新启动时回滚到上一版本。为确保软件包数据无交叉，客户端会自动清除缓存并重新传送正确的 SFT 文件。当您考虑必须要执行哪些操作才能回滚使用更加传统的软件部署工具实际安装的应用程序更新时，这是一个值得考虑的权衡。

要发挥 App-V 的优势，您必须创建虚拟应用程序包。App-V 排序器在这里就派上用场了。您为传统软件部署工具编写脚本和创建软件包时获得的任何知识和体验都会帮您轻松向排序过渡。（应该指出的是，要阐述排序需要用一整篇文章。）
大多数软件部署解决方案依靠脚本捕获应用程序自行安装的方式，然后在其他计算机上重复此过程，无需再访问每台计算机来安装或更新应用程序。应用程序安装完成后，常规软件部署工具会彻底擦除软件包。然后您必须安装该应用程序可能依赖的所有依赖关系、运行其他脚本或执行手动步骤以根据需要配置应用程序。
App-V 中的根本改变是排序过程生成了一个已安装应用程序的映像，包含它的所有依赖关系和配置。App-V 客户端可“完成”这一任务，而无需改变该映像的处理设备。
排序器会生成多种多样的文件，其中最重要的是 SFT 文件，它包含所有应用程序资产、依赖关系和配置信息。在某些情况下，它还可能包含多个应用程序。毫无疑问，此文件可能会非常大。可以对其应用一些压缩选项，但对您网络和设备性能的充分了解是必不可少的。排序器创建的图标文件 (.ico) 用于通告虚拟应用程序，以使其像在本地安装一样运行。
OSD 文件也非常重要，其选项是无穷尽的。默认情况下，这是一个基于 XML 的文件，用于告知 App-V 客户端如何启动虚拟应用程序。也可以对 OSD 文件进行修改，以配置和控制虚拟应用程序的启动和运行方式。我强烈建议您阅读“排序管理指南”和“排序最佳方法”文档，以熟悉通过 OSD 文件提供的属性和值。
最后，新的 manifest.xml 文件包含基于软件包的配置信息，可用于与第三方 ESD 解决方案和 MSI 部署集成。排序器还可以为虚拟应用程序包生成一个 MSI 文件。可使用此文件将虚拟应用程序加载到独立（无服务器）客户端或 ESD 系统。
排序器本身是一个基于向导的工具，可引导您完成应用程序安装并将其转换成虚拟应用程序（请参见图 4）。第一步是配置软件包的默认属性。这些属性存储在 OSD 文件中，包括软件包名称和注释。一些高级设置允许您指定从中进行传送的服务器、内容目录和软件包应支持的操作系统。
图 4 排序向导（单击图像可查看大图）
第二步是安装、配置和测试应用程序。在安装期间，排序器会捕获对本地系统所做的全部更改，包括文件系统、注册表和系统。此向导中还有几个实用工具，可用于完成 Windows Update 集成等操作。
下一步是配置文件类型关联并指定应将快捷方式放置在什么位置。标准位置包括“开始”菜单、桌面和快速启动栏，但也可以创建自定义位置。
然后您需要启动此应用程序并配置初始启动阈值。App-V 在此步骤中确定需要交付给客户端以使应用程序开始运行的应用程序初始部分。
要配置这一初始代码（通常称为 Feature Block 1 或 FB1），只需启动应用程序并使用用户所需的最常见功能。例如，启动 Word，然后启动拼写检查器。应用程序在此阶段调用的任何 DLL、文件或注册表项会被自动指定为 FB1 的一部分。此时未使用的所有文件、设置或组件均被添加到 FB2 中。之后使用此应用程序时，客户端将会收到一个 SFT 文件的映射，指示 FB1 开始和停止位置以及 FB2 中存在的其他文件的位置，以便客户端可以在应用程序需要时检索这些文件。
排序过程的最后一步是确保所有内容正确配置。排序器显示的对话框如图 5 所示，它表示 SFT 并允许您对软件包做出任何最后添加或更改。
图 5 确认和调整最终软件包（单击图像可查看大图）

版本 4.5
经过两年的准备，App-V 4.5 计划在今年晚些时候发布。这是 Microsoft 这一产品首次面世，它通过引入几项重要的增强功能（例如，动态虚拟应用程序交互、扩展可伸缩性和更为符合 Microsoft 国际化与安全的要求）推动了应用程序虚拟化。
动态虚拟应用程序交互允许虚拟化应用程序彼此进行交互。这种交互称为动态套件合成 (DSC)。 DSC 不是为取代将多个应用程序添加到同一软件包的功能。而是提供了一种新方法来集成在各虚拟应用程序之间共享的依赖关系、中间件和插件。
管理员可以指定哪些虚拟化应用程序可彼此交互。例如，假设您有五个 Web 应用程序，它们需要同一 Java 版本。在 App-V 4.1 中，您必须将此相同的 Java 版本添加到五个单独软件包中的每一个。假设 Java 版本需要一个补丁。管理员稍后必须为五个不同的软件包提供补丁。如使用 DSC，Java 只需打包一次，即可配置为能供所有五个 Web 应用程序使用的软件包。因此，修补 Java 只需要管理员为 Java 软件包提供一次补丁。
对于中间件和插件也是如此。随着 Microsoft 发布的临近以及最终确定所有最新添加的内容，我打算在博客中写一篇有关其他使用案例方案的文章。
可伸缩性的增强功能包括流式基础结构和后端基础结构。后端组件已进行了修改，它可以更好地支持群集和故障转移方案，而且更适合 WAN 和 LAN。增强功能源自几个关键的添加项。
第一个是全新的流式服务器组件，它允许进行流化，而无需 Active Directory 和 SQL Server 后端基础结构。您仍然会得到按需交付和集中更新软件包的所有巨大益处，而没有苛刻的后端要求。它可广泛用于分支机构方案和与第三方 ESD 解决方案的集成。
App-V 客户端也进行了一些改进。例如，客户端现在将所有使用情况信息存储在本地，以便可以跟踪此信息，无论客户端信息与网络是连接的还是断开的。客户端缓存也进行了扩展和改善，可以在有限的磁盘空间中提供更好的性能。现在还支持排序非英语应用程序、在非英语操作系统中运行 App-V 以及本地化为其他多种语言。

将 App-V 与 Configuration Manager 集成
App-V 4.5 中的许多增强功能和新功能都是针对将 App-V 集成到 SCCM 2007 R2 而设计的。正像我之前所探讨的，虚拟化和流化可交付传统软件部署工具未提供的应用程序。我并不是说 App-V 将取代这些工具，而是说 App-V 可以对其进行补充和扩展。
通过这种集成，您可以获取 SCCM 的所有可伸缩性、报告、设备识别和 WAN 功能以及 App-V 的所有流化和隔离功能。下面列出了会从这两项技术集成中受益的领域：
应用程序发布，SCCM R2 集成支持按需交付、漫游应用程序、初始启动阈值和应用程序部署的所有功能，无需改变客户端 PC。
更新 SCCM，分发点 (DP) 可以在软件包更新时仅部署虚拟应用程序的变化量。它引入了集中式功能，只需单击一次便可将虚拟化应用程序还原为以前版本。
管理，版本 R2 引入了一项全新的虚拟应用程序公告向导，允许管理员从单个控制台部署虚拟化应用程序以及传统软件包和公告。
打包，将 App-V 与 SCCM 集成后不需要将应用程序重新打包。必须从 SCCM 外部使用 App-V 序列完成应用程序的初始排序，但管理员可以使用 SCCM 更新现有软件包。
授权许可，可以使用 SCCM 中的现有工具跟踪虚拟应用程序的授权许可和计量。
BITS，SCCM 提供了一种全新的方法来使用行业标准的 BITS 协议将虚拟化应用程序部署到 App-V。虽然 SCCM DP 可以流化，但有些时候流化并不是部署虚拟化应用程序的理想方法。通过 SCCM 进行部署时，有两个选项可以使用。您可以使用标准流，也可以使用 BITS 的服务质量 (QoS) 功能来以更加可控的方式进行部署。如果您想在用户启动虚拟应用程序之前预加载缓存，这也是非常有用的。
计算机部署，SCCM 可以将虚拟化应用程序部署到指定计算机并继续支持基于用户的 App-V 目标平台方法。当您将虚拟应用程序部署到便携式计算机、网亭和实验室计算机时，这会很有用。如果软件由设备授权（而非指定用户），这还为协助实施许可证控制提供了方便。
可伸缩性，需要部署两个具有大量重叠的单独工具是一个常见问题。通过将 SCCM 的可伸缩性、WAN 优势与 APP-V 的隔离和流化优势相集成，您可以使用现有的 SCCM 处理管理和部署，从而简化处理过程。

Anthony Kinney 是一位技术销售专业人员，负责 Microsoft 桌面优化包。Anthony 是在 2006 年 Microsoft 收购 Softricity 后加入 Microsoft 的。在 Softricity 工作时，Anthony 编写并设计了 SoftGrid（现在为 App-V）的第一个培训程序。可通过 Anthony.kinney@microsoft.com 与他联系。


虚拟化
实现 Hyper-V 的高可用性
Steven Ekren
概览：
  • 使用 Hyper-V 合并服务器
  • 确保虚拟机的高可用性
  • 设置 Windows Server 2008 故障转移

目录
高可用性
主机和来宾
来宾可用性
确保 VM 高可用性
前提条件
高可用性演练
注意事项
服务器虚拟化无疑将对企业中的 IT 部门产生重大影响，而 Hyper-V 与 Windows Server 2008 则可将这种影响变为现实。将服务器合并到更少的物理机器上将在资源和成本节省方面取得巨大优势，但在规划过程中需要考虑两个关键因素。用户对其软件（包括业务线 (LOB) 应用程序，以及类似消息和协作平台之类的工具）可用性的期望不断提高。而且，服务器问题或故障对运营的影响也越来越大。Windows Server 2008 和 Hyper-V 可以让虚拟机 (VM) 及其内部所托管的工作负载发挥出高可用性 (HA)。

高可用性
可用性是指用户能够访问系统以完成其工作。在高可用性环境中，需要确保用户始终能够访问系统，因为其设计和实现的目标即是确保运营的连续性。
Hyper-V 的高可用性通过使用 Windows Server 2008 故障转移群集功能实现。高可用性会受到计划和非计划停机时间的双重影响，在这两种情况中，故障转移群集均可以显著提高虚拟机的可用性。
虚拟机可以通过故障转移群集进行管理，并且可以在虚拟机内部使用故障转移群集以监控并转移 VM 中托管的工作负载。我将更加详细地说明这两种配置方案，但本文侧重于在使用前管理虚拟机。当然，您可以查看“Hyper-V 常用术语”侧栏。

主机和来宾
因为 Hyper-V 系统上运行着多个操作系统，所以准确把握所讨论的层或 OS 非常具有挑战性。我使用术语“来宾”指代 Hyper-V VM 内部运行在子分区中的 OS 和环境。而术语“主机”则表示物理机器，它由 Hyper-V 父分区上的 OS 负责管理。
主机可用性解决了服务器合并可能导致的“将所有鸡蛋放入同一个篮子里”的问题。Windows Server 2008 故障转移群集可以在 Hyper-V 父分区（主机）上配置，以便能够监控 Hyper-V 子分区（虚拟机或来宾）的运行状况并在群集节点间移动。这种配置具备以下主要优点：
  • 如果正在运行 Hyper-V 和 VM 的物理机器需要进行更新、更改或重新启动，则可以将 VM 移动到群集中的其他节点上。当物理机器恢复服务后再将 VM 移回原来的机器。
  • 如果运行 Hyper-V 和 VM 的物理机器发生故障（比如主板故障）或性能严重下降，则 Windows 故障转移群集中的其他成员将接收该 VM 的所有权并自动将其恢复到在线状态。
  • 如果 VM 出现故障，可以在同一台 Hyper-V 服务器重新启动，或者移动到另一台 Hyper-V 服务器。由于 Windows Server 故障转移群集可以检测到这些故障，所以它将根据 VM 资源属性中的设置自动采取恢复措施。凭借检测和恢复自动化，停机时间得以降至最低。
图 1 表示在这种情况下可能发生的事件。最初，VM2 位于主机 A 上，然后将 VM2 移动到主机 B。请注意在此移动过程中，配备 SAN 存储的 LUN 2 从主机 A 更改到主机 B。为确保高可用性解决方案能够满足您的可用性需求，需要仔细斟酌安放 VM 的位置。同时考虑容量和性能。
图 1 虚拟机及其存储移动到新的主机（单击图像可查看大图）
节点的容量应该足够容纳所有的 VM，并且能够应对 x 个节点发生故障或脱离活动群集分区。（X 代表您希望群集能够承受的节点丢失数量，在丢失这些节点时仍能容纳所有的 VM。当决定容量时，您可以选择某些通常不托管 VM 的节点作为保留节点。或者，您也可以将 VM 传播到所有节点，以便确保每个节点都有足够的剩余空间在任意 x 个节点出现故障时能够成功地接收所有权并启动 VM。
出于日常性能原因考虑，将 VM 传播到群集的所有节点可能比较理想。如果将某些节点作为保留节点且不托管任何 VM，则托管 VM 的节点将使用更多资源，而且可能降低 VM 和管理分区的性能。在各节点中传播 VM 可以减少各节点承载的工作，并为 VM 和管理分区提供更好的性能。但是，规划容量也因此新增了挑战。类似 System Center Virtual Machine Manager 2008 之类的管理软件可以为节点故障和 VM 定位提供容量计算，以此提供帮助。

来宾可用性
来宾可用性侧重于使正在 VM 内部运行的工作负载高度可用。常见的工作负载包括文件和打印服务器、IIS 和 LOB 应用程序。分析 VM 内部工作负载的高可用性需求和解决方案与分析独立服务器上的工作负载非常相似。解决方案视具体的工作负载而定。
某些工作负载可以通过 Windows 网络负载平衡 (NLB) 获得高可用性，它允许将多台服务器作为使用通用网络名称的服务器池的一部分。客户端使用该虚拟网络名称发起连接请求，并连接 NLB 群集中的节点。使用 NLB 群集的典型方案是利用 IIS 构建 Web 场，其中每个单独的系统都包含有相同网页的 IIS，并可访问相同的数据。NLB 提供负载平衡，并可在维护或服务器发生故障期间删除成员关系服务器，以此实现高可用性。如果 Hyper-V VM 运行 Windows Server 2008（或包含 NLB 的早期 Windows Server 版本），则来宾可以与相同或不同 Hyper-V 主机的来宾一同成为 NLB 群集的成员。
运行 Windows Server 2008 的来宾可以使用 Windows 故障转移群集功能为其工作负载提供高可用性。在来宾内部（来宾群集）使用 Windows 故障转移群集有许多优点：
工作负载运行状况监控Windows 故障转移群集包含一个资源监控器，它可以调用与群集相关联的资源 DLL。每种资源都具有运行状况监控，它们通过测试由该资源所管理的应用程序或服务确保其工作正常。这些检查就是通常所说的 isAlive/looksAlive 检查。如果其中某个资源调用失败，则该资源本身可能出现故障。根据其属性配置，该资源可能会重新启动服务或应用程序，或者移动到 Windows 故障转移集群中的另一个节点。
虚拟机维护如果需要更改 VM 的配置，或者需要更新或更改 OS 或软件，则可以将工作负载移动到群集中的另一个节点，VM 关机或更新，这样对最终用户的干扰最小。
主机维护如果托管 Hyper-V VM 的物理机器需要进行维护或软件升级，并且 Windows 故障转移群集中的其他成员位于不同的 Hyper-V 主机之上，则该 VM 中的工作负载将移动到群集中的另一个节点，这样就可以关闭该 VM 以适应物理服务器的更改或重新启动。
虚拟机或主机故障如果物理 Hyper-V 主机或虚拟机来宾发生故障，Windows 故障转移群集中的其他节点将检测到该群集成员无响应或无法再加入群集，而工作正常的节点成员将把运行在发生故障的 VM 上的应用程序或服务恢复联机。

Hyper-V 常用术语
以下是帮助定义高可用 Hyper-V 系统（主机群集）组件或功能的术语列表。
父分区所有运行在管理程序服务器上的操作系统都已分配硬件资源，包括 RAM、CPU 和其他系统组件。在 Hyper-V 中，负责管理系统资源和管理程序配置的分区通常称作父分区。当配置 Hyper-V 角色且服务器重新启动时，充当系统本机操作系统的 Windows Server 2008 将成为 Hyper-V 服务器父分区中的操作系统。
子分区Hyper-V 服务器上的隔离环境，配置子分区是为了承载来宾操作系统，并为该操作系统提供硬件资源。
Hyper-V 主机托管 Hyper-V 和在父分区内运行的操作系统的物理服务器。
Hyper-V 虚拟机Hyper-V 配置信息及用于引导和运行 Hyper-V 子分区的数据。其中包括创建子分区的配置信息、VHD 文件或包含数据的传递磁盘。
传递磁盘磁盘管理程序中显示为物理磁盘的存储设备，它分配给 Hyper-V 来宾专用。Hyper-V 来宾可以装载该磁盘，并将其作为本地连接的存储设备使用。
虚拟硬盘 (VHD)由 Hyper-V 子分区连接的文件，操作系统可将其视为存储设备（磁盘）。.vhd 文件可以位于父分区装载的存储设备上，也可以是直接连接的存储设备，或者连接 SAN、NAS 或 SMB 的存储。
确保 VM 高可用性
要配置虚拟机的高可用性，只需完成“故障转移群集管理”中的“HA 角色向导”即可。当 Hyper-V 虚拟机具备高可用性时需要考虑几个重要组件。首先，让我们看一些重要概念和一般性的前提条件。
故障转移群集节点故障转移群集中的各个物理服务器称为节点。对于主机群集，故障转移群集服务在 Hyper-V 系统父分区上的 Windows Server 2008 中运行。这使得在同一物理服务器子分区中运行的 VM 能够配置为高可用虚拟机。配置高可用性的虚拟机在故障转移群集管理控制台中将作为资源显示。
HA 存储高可用虚拟机可以配置为使用虚拟硬盘 (VHD)、传递磁盘和差异磁盘。为了使虚拟机能够在故障转移群集节点间移动，需要能够被任何 VM 托管节点访问且由故障转移群集服务管理的存储（在“磁盘管理”中显示为磁盘）。传递磁盘应该作为磁盘资源添加到故障转移群集，而 VHD 文件必须位于作为磁盘资源添加到故障转移群集的磁盘上。
虚拟机资源一种用于代表虚拟机的故障转移群集资源类型。当虚拟机资源在线后，Hyper-V 将创建子分区并启动虚拟机内的操作系统。虚拟机资源的离线功能可以从托管节点的 Hyper-V 中删除 VM，并从 Hyper-V 主机中删除子分区。如果虚拟机关闭、停止或置于保存状态，则其资源将处于离线状态。
虚拟机配置资源一种用于管理 VM 配置信息的故障转移群集资源类型。每台虚拟机都具有一个虚拟机配置资源。该资源的属性包括配置文件的路径，配置文件包含将虚拟机添加到 Hyper-V 主机所需的所有信息。启动虚拟机资源需要访问该配置文件。因为配置由单独的资源管理，所以即使在 VM 离线时也可修改 VM 资源的配置。
虚拟机服务和应用程序组对于需要通过故障转移群集获得高可用性的服务或应用程序，必须在同一故障转移群集节点中托管多种资源。为确保这些资源始终处于同一节点且能够正确互操作，将它们放入 Windows Server 2008 故障转移群集称为“服务或应用程序”的组中。VM 的虚拟机资源与虚拟机配置资源始终位于相同的“服务或应用程序”组中。也可能会有一个或多个物理磁盘（或其他存储类型）资源包含“服务或应用程序”组中的 VHD、配置文件或传递磁盘。
资源依赖关系确保在虚拟机资源在线（启动）之前使虚拟机配置资源在线，并在虚拟机资源离线（停止）之后使虚拟机配置资源离线非常重要。通过设置虚拟机资源的属性，使其依赖于虚拟机配置资源可以确保实现这种在线/离线秩序。如果某个存储资源包含用于虚拟机配置资源或虚拟机资源的文件，则应该将这些资源设置为依赖该存储资源。例如，如果虚拟机使用磁盘 G:和磁盘 H: 上的 VHD 文件，则虚拟机资源应该依赖配置文件资源、磁盘 G: 资源和磁盘 H: 资源。

前提条件
以下是通过 Windows Server 2008 故障转移群集功能获得 Hyper-V 虚拟机高可用性的三个前提条件：
  1. 必须为群集中每个节点配置 Windows Server 2008 故障转移群集功能。有关配置和管理故障转移群集的详细信息，请参阅“Hyper-V 资源”侧栏。
  2. 必须安装 Hyper-V 角色。应该安装 Hyper-V 更新并为故障转移群集中的每个节点配置角色（同样请参阅“Hyper-V 资源”侧栏）。Hyper-V 包含一个安装 Hyper-V 服务器组件的更新软件包和一个安装 Hyper-V 管理控制台的更新软件包。安装 Hyper-V 服务器组件更新后，可以通过 Server Manager 或 ServerManagerCMD 添加角色。
  3. 需要为虚拟机提供共享存储。存储可由故障转移群集作为内置物理磁盘资源进行管理，也可以使用第三方解决方案管理共享存储。当然，第三方解决方案必须支持 Windows Server 2008 故障转移群集。

高可用性演练
现在让我们看看高可用性解决方案的创建步骤。第一步是建立虚拟机。在某个已经安装 Hyper-V 角色的故障转移群集节点上使用“Hyper-V Manager”配置一个虚拟机（请参阅图 2）。该虚拟机既可以是手动配置的新 VM，也可以导入预先存在的 VM。VHD 应该位于由 Windows Server 2008 故障转移群集管理的磁盘上，并且当前在将要配置 VM 的节点上处于在线状态。
图 2 配置虚拟机（单击图像可查看大图）
现在，通过关机、关闭或保存状态将虚拟机置于停止状态。只有处于停止状态的虚拟机才可配置由故障转移群集进行管理。
在任何运行 Windows Server 2008 故障转移群集角色的服务器，或运行远程服务器管理工具 (RSAT) 的 Windows Vista 客户端上打开“故障转移群集管理”控制台（如图 3 所示）。通过选择“管理群集…”操作并选择节点或群集名称，或者选择连接运行控制台的节点上的群集，来连接故障转移群集。
图 3 “故障转移群集管理”中的虚拟机（单击图像可查看大图）
从“故障转移群集管理”控制台，选择“配置服务或应用程序…”操作。该操作将打开“高可用性向导”，它将引导您完成配置服务、应用程序或将由故障转移群集管理的虚拟机。在向导中的“选择服务或应用程序”页面，请选择“虚拟机”，然后选择“下一步”。
“选择虚拟机”页面将显示故障转移群集中任意节点上配置的所有虚拟机。选择虚拟机，然后选择“下一步”。向导的“确认”页面将显示任何警告或错误。在这一步中将检查虚拟机配置以确认它是否可以配置为 HA 资源，以及节点是否能够托管它。此时选择“下一步”会将虚拟机作为高可用性资源添加到故障转移群集。
“摘要”页面提供有关添加虚拟机作为高可用性资源的结果信息，包括所有警告。“查看报告…”按钮可以显示配置高可用虚拟机任务的详细信息，以及任何警告或错误。最后，选择“完成”会关闭“高可用性向导”。
如图 3 中窗口所示，“故障转移群集管理”控制台将在群集名称和“服务或应用程序”下方左侧窗格中列出带有虚拟机默认名称的对象。从该树形结构中选择虚拟机，“服务或应用程序”组中的资源将显示在控制台的中央窗格中。如果任何其他虚拟机在所选的存储中也存放了文件，它也将添加到该组中。还将显示置于该组中的每台虚拟机和虚拟机配置资源。
“服务或应用程序”组的信息窗格将显示该组的“状态”、“警报”、“首选所有者”和“当前所有者”信息。“所有者”节点是当前配置或运行虚拟机的节点。选择“将虚拟机移动到另一个节点”操作可以使虚拟机先离线，然后在另一个节点上在线。通常最佳做法是将 VM 移动到故障转移群集中可能托管它的每个节点，以便验证移动成功且 VM 能够启动和运行。

Hyper-V 资源
  • Windows Server 2008 专用 Hyper-V 技术发布版本更新说明
  • Hyper-V 分步指南：测试 Hyper-V 和故障转移群集
  • Windows Server 2008 故障转移群集简介（作者 Chuck Timon，《TechNet 杂志》2008 年 7 月）
  • NLB 主机在 Windows Server 2008 Hyper-V 虚拟机未按照预期聚合
  • Win2008 群集网络广播
  • Microsoft 针对 Windows Server 2008 故障转移群集的支持策略
注意事项
以下是一些设置高可用性虚拟机时需要记住的要点：
存储如果虚拟机在相同共享磁盘上有 VHD 文件，即使它们位于相同磁盘的不同卷，仍需要置于相同的“服务或应用程序”组中。共享磁盘的优势之一在于它能够更好地利用可用存储空间。
但是，不利之处在于当移动虚拟机时（无论因虚拟机故障自动恢复，还是因为管理员的选择），该组中所有的虚拟机都将移动。
驱动器盘符和 GUID可以创建不分配驱动器盘符的卷。虚拟机可以使用这些卷，且这些卷可由故障转移群集进行管理。如果某个磁盘资源包含使用 GUID 而不是驱动器盘符的卷，则将在“群集管理”中显示该 GUID。当创建虚拟机并为 VHD 指定路径时，确保路径中的 GUID 与该卷“群集管理”中显示的 GUID 相匹配非常重要。如果不匹配，则虚拟机可能无法在故障转移群集中的其他节点上成功启动（在线）。
以下几种情况可能导致 GUID 不匹配。如果某卷先于节点上在线，然后才成为故障转移群集管理的磁盘资源，则该卷在每个节点上可能具有不同的 GUID。卷还可能在单个节点上具有多个 GUID。当磁盘作为物理磁盘资源添加到故障转移群集时，节点（包含在线磁盘）中使用的卷 GUID 将在该磁盘资源的属性中注明。
当磁盘资源在线时，卷 GUID 将添加到节点。这确保故障转移群集为该卷记录的特定 GUID 在任意使该磁盘在线的节点上均为有效路径。该节点可能包含关联相同磁盘的其他 GUID。因此，用户可以找出节点上对该卷有效的 GUID，但故障转移群集并不能保证它与其他节点上卷所用的 GUID 相同。它产生的症状是虚拟机资源（通常是“配置”资源）无法在线，并显示错误消息，指示路径无效。错误消息中的路径显示该 GUID 不是该卷的群集管理 GUID。
装入点装入另一个卷的文件夹中的卷，未分配驱动器盘符或使用 GUID，是 Hyper-V 和故障转移群集可以使用的有效卷。由于被装入的卷和托管该装入点的卷必须位于相同的故障转移群集节点上，所以必须将装入点中的所有磁盘放入相同的“故障转移群集服务或应用程序”组。
如果这些卷位于相同的磁盘上，那显然不存在问题。但如果这些卷位于不同的磁盘上，那肯定会出现问题。同样明显但仍值得一提的是：被装入的卷和装入点主机必须是共享存储，且配置为由故障转移群集节点管理。
差异磁盘 差异磁盘所含的所有 VHD 文件需要位于共享存储上，而该存储与使用差异磁盘的 VM 属于相同的“服务或应用程序”组。在最简单的配置中，差异磁盘包含两个 VHD。一个是父 VHD，其中包含发挥基础作用的数据集。另一个 VHD 是与父项关联的子项。
第一次使用时，差异磁盘的表现类似父项。如果数据位于父项，则从该 VHD 读取数据。所有的写操作在子 VHD 上执行。如果数据位于子项上，则读取该数据时将引用子 VHD。
如果 VM 采用某种方式配置，使得子 VHD 位于共享存储中，而父 VHD 或者不位于相同组中的共享存储上，或者位于本地连接的存储设备中，则该 VM 移动到另一个节点时将无法启动（在线）。“高可用性向导”应该通过检查确保该设置在 VM 中配置正确，并在检测到该错误时提供错误消息，但如 VM 配置发生更改，最好注明要求。

Steven Ekren 是 Windows Server 故障转移群集和高可用性团队的高级产品经理。Steven 在 Microsoft 支持部门工作长达 12 年，期间他曾协助企业客户实施和排除 Windows Server 故障转移群集和虚拟化技术故障，包括 Windows Hyper-V、System Center Virtual Machine Manager、Microsoft Virtual Server 和 Microsoft Virtual PC。


虚拟化
服务器虚拟化备份和灾难恢复
Adam Fazio
概览：
  • 灾难恢复计划注意事项
  • 灾难恢复高可用性解决方案
  • 使用 Windows Server Backup 备份和恢复

目录
灾难恢复计划 101
灾难恢复和虚拟化
物理到虚拟转换
虚拟机快照
备份 Hyper-V
Windows Server Backup
使用 WSB 备份 VM
注意事项
使用 WSB 恢复 VM
Data Protection Manager
脚本化备份
DiskShadow
总结
随着服务器虚拟化技术的发展和在行业中愈发广泛地普及，许多组织逐渐意识到它还有着超常的优势：降低基础结构成本并提高 IT 灵活性。下一项前沿技术将使用虚拟化平台作为启用或加强灾难恢复 (DR) 战略的方法。
为什么 DR 准备始终是 IT 行业所面临的最热门话题之一呢？研究表明：公司每停机一小时将平均损失 $80,000 到 $90,000，并且几乎没有任何公司能够在出现灾难性数据丢失后仍能长期生存。本文将介绍使用 Microsoft 虚拟化平台的 DR，并深入探讨了 Windows Server 2008 Hyper-V 备份和恢复选项及注意事项。

灾难恢复计划 101
DR 是在出现停用时恢复关键服务的过程，它应该是每个公司业务连续计划的一部分，该计划定义公司在此类灾难期间或之后将如何继续履行其职能。这些计划是所有 DR 活动的基础。
有些供应商宣称其 DR 自动化技术足够好，需要历经演练的详细计划的机率很小，甚至不需要这类计划。虽然可以说自动化能够改善恢复时间并减轻对人工干预的依赖，但我们还是要郑重指出：您不可能仅凭技术成功减轻灾难。人员和流程的重要性与技术相比始终不相上下。
事实上，您会发现如果没有事先从 DR 计划流程中了解所有限制和目标，几乎不可能选择正确的技术。虽然本文不讨论定义整个 DR 计划，但我想强调这些元素是选择正确的技术和实施方案时所必需的。所以我们先大致看一下 DR 计划中一些关键的技术推动因素。
服务定义和优先级您所尝试保护的整个服务具体由什么定义，它对公司的重要性有多高？图 1 显示可能包含在任何 DR 计划中的公司服务示例。
图 1 服务定义和优先级示例
服务 | 主要组件 | 依赖关系 | 业务使用情况 | SLA
公共网站 | 网络负载平衡器、三台 Web 服务器、两台数据库服务器 | DNS、网络、防火墙、目录、存储区域网络 (SAN) 存储 | 产品购买和订单跟踪；电子商务；客户支持门户；公司信息 | 99.99%
财务系统 | 两台数据库服务器、一台应用程序服务器 | DNS、网络 | 按照法律和法规的要求记录公司收入 | 99.99%
电子邮件系统 | 三台电子邮件服务器、一台 Web 服务器 | DNS、网络、防火墙、目录 | 公司通信；客户支持 | 99.5%
定义好服务后，您可以开始确定系统和依赖关系，以及所需的 DR 策略类型。很可能在查看整个服务和依赖关系集合之后，您发现需要考虑建立几个不同级别的 DR，原因是为所有关键任务服务制定单个 DR 解决方案可能会非常昂贵且复杂。
服务级别协议 (SLA) SLA 是服务提供商 (IT) 与客户（组织）之间的协议，用于为给定服务定义可用性目标。该协议可能非常冗长，也可能非常简短有效；例如，“在正常业务时间期间，电子邮件系统的可用性达到 99.95%，非正常业务时间可用性达到 98%，不含计划维护时间段，以月为单位计量”。通常，SLA 可分解为多个层次，IT 服务可以分配到这些层次中，在预定义的时间段进行测量。
操作级别协议 (OLA) OLA 主要说明不同 IT 组（合作支持 SLA ）之间的协议，包括服务交付的流程和响应时间。假设您有一个 SLA 目标为 99.99% 的关键任务网站，但它赖以提供内容的数据库的可用性目标仅为 95%。OLA 有助于识别这些不匹配的情况，并协调 IT 团队以便达到相同的目标。
恢复点和恢复时间目标 (RPO/RTO) RTO 定义出现连续性中断之前服务不可用的时间长度，而 RPO 定义组织认为可以接受的数据损失级别。因此，如果某服务每月测量的 SLA 为 99%，则它的 RTO 为 7 小时 18 分钟。如果与 RPO（比如 24 小时）组合起来，则您现在可以准确定义所需的备份技术和时间计划。
数据保留策略组织的数据保留策略精确指定保留备份的时间和存储位置。它们通常由法律和法规要求决定。
数据分类您还应该考虑数据的特性。如果将数据分类，那您可以很快发现并不是所有的数据都需要相同级别的 DR 考量。例如，单独数据库的可用性要求可能与有多个域控制器（每个域控制器都包含目录的副本）的 Active Directory 的可用性要求不同。同理，文件服务器的数据可能与 CRM 数据的恢复过程大不相同。
灾难方案定义所有希望计划的方案非常重要，因为每种方案都将有不同的恢复过程、业务影响和相关成本。查看所有可能的方案，然后决定为环境制定 DR 计划时的目标非常有用：
  • 损失整个站点
  • 损失单个数据中心
  • 损失一台系统（操作系统或硬件故障）
  • 损失数据（数据删除或损坏）
  • 损失关键依赖关系
很明显，恢复整个站点损失与恢复单个系统损失的注意事项有天壤之别。您还须根据 SLA 定义恢复阈值。例如，假设整个站点离线的原因是主要 ISP 网络断开。如果受影响服务的 SLA 对于服务恢复是 8 小时，对于数据恢复是 48 小时，那您可能更希望对备份站点执行服务故障转移程序，而不是实际完成数据恢复过程，因为预计生产站点会很快再次出现问题。
看！到现在为止我们还没有谈到技术呢！计划的重要性不可低估。没有成文计划的 DR 实现只能是“DR 愿望”。

灾难恢复和虚拟化
好的，现在我们已经掌握了 DR 计划的基础，那么，虚拟化在其中有何作用呢？许多公司报告的虚拟服务器恢复时间都以分钟为单位，而物理服务器的恢复时间则以天或周为单位。因为整个服务器的操作系统现在只是一组文件，它已从底层物理硬件中抽象出来，所以为考虑可恢复性开辟了新的空间。
当今流行的理论是可以通过高可用性 (HA) 解决方案实现部分或所有 DR 目标。言下之意是：如果在彼此分离的物理位置配备群集节点并使用站点间数据同步的话，那么在发生故障时，被动节点可以恢复运作且能够在近乎实时的情况下恢复。
确实如此，但如果回忆前面定义过的灾难方案，很明显这种解决方案并不能保治百病。您还需要技术组合以便为所有方案作好准备，这通常包括一些常规类型的备份。HA 并不能防止所有可能的停机，而且它并不能完全替代某些备份策略。
使用 Hyper-V 和 HA 需要您仔细规划存储层，因为这是实现可恢复性的关键因素。例如，即使使用共享存储的 2 节点 Hyper-V 群集位于不同的数据中心，但仍有存储子系统和数据这一单独的故障点。
然而，您应该知道不使用共享存储的相同 2 节点 Hyper-V 群集能够承受其中一个节点上的存储或数据损失。这确实需要复制技术确保存储同步，使得复杂性加大（请参阅图 2）。
图 2多站点 Hyper-V 群集（单击图像可查看大图）
在数据复制和同步领域有一些非常有趣的发展，但 Microsoft 目前尚不能提供这些技术。在 Windows Server 2008 多站点群集页面（microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx）上，其中介绍的合作伙伴值得一看。另一项资源是 Windows Server 目录（请参阅 windowsservercatalog.com），它列出了获得 Windows Server 2008 认证复制技术的存储供应商。
如您所见，可供考虑的 HA 和存储配置为数众多。这再次说明为什么需要先定义业务需求，然后使其能够推动技术需求，而不是采用相反方式。

物理到虚拟转换
虚拟化显然可以提供某些独特的恢复灵活性，但对于并不非常适合虚拟化的物理系统又将如何呢？System Center 虚拟机管理器 (SCVMM) 中包含对正在运行的 Windows 服务器执行物理到虚拟 (P2V) 转换的功能，它可以产生与物理源服务器完全一致的可引导 Hyper-V 虚拟机 (VM)。这样您便可以在校园或整个国家内像复制虚拟副本一样复制 VM，同时还可获得相似的恢复时间。
这种方法与在恢复位置进行裸机恢复这一传统方式不同，它不再需要配置与生产位置数量或类型相同的物理系统。这样您可以充分利用恢复硬件，并根据灾难的影响按需进行扩展。
尽管 SCVMM 不包括用于 P2V 转换的调度程序，但由于 GUI 完全在 Windows PowerShell 之上运行，所以可以使用 New-P2V cmdlet 轻松地进行脚本化。实际上，SCVMM 中的所有向导都会显示它们用于执行任务的代码，您可以从环境的测试 P2V 中复制这些代码并进行修改，供今后自动执行之用。图 3 显示了一些示例代码；您可以在您的环境中运行 SCVMM P2V 向导获得可自定义的独特 Windows PowerShell 脚本。
图 3 由 SCVMM P2V 向导生成的代码
$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

虚拟机快照
尽管从技术上讲并不是备份，但 VM 快照提供了可以使用差异磁盘还原的时间点和 VM 配置文件的副本。如果灾难涉及 VM 内部数据的意外删除，则可以考虑采用这种 DR 功能，因为 VM 可以还原到快照位置，去除数据损失。（我们将稍后讨论卷影复制服务快照，或称 VSS。）

备份 Hyper-V
基于主机的备份服务器虚拟化一项让人心动的优势是可以不再需要单独备份虚拟化系统。既然这些系统仅仅是位于主机文件系统中的文件，那您只需备份这些文件即可，不是吗？并不完全是这样。因为这些系统是由内存数据、磁盘数据、系统配置和打开文件组成的活动计算机，所以还需要考虑几件事。那我们如何确保所有这些变化部件的数据一致性呢？
Windows Server 备份功能的重大改进来自 Windows Server 2003 和 VSS 的出现，它提供一组标准的扩展 API，VSS 编写器（应用程序和服务中用于帮助提供一致卷影副本的小程序）使用它来创建打开文件和应用程序的备份。凭借 VSS 服务、提供程序和编写器的帮助，备份应用程序可以快速生成时间点的卷副本，应用程序可以知晓该副本并给予正确处理。
Hyper-V 有其自身的 VSS 编写器，它允许软件制作者创建极具吸引力的备份解决方案。编写器使备份应用程序能够获得运行中 VM 的基于主机 VSS 备份。如果 VM 中运行的操作系统已安装 Hyper-V 集成组件和 VSS 服务（Windows XP SP1 和 Windows Server 2003 及更高版本中提供），则基于主机的备份将以类似于在来宾内运行的方式进行；备份将在 VM 运行时执行且保持数据的一致性（请参阅图 4）。
图 4 VSS 备份（单击图像查看大图）
但是，如果来宾操作系统不支持“集成组件”或 VSS，那么备份进程需要将来宾机器置于已保存状态，并且为 VM 数据文件生成基于主机的 VSS 快照，以供时间点恢复使用。处于保存状态的 VSS 快照将导致 VM 暂时停机（通常为 5-10 分钟），以便将 VSS 数据副本完整备份到磁带。
基于来宾的备份在物理环境中，服务器和应用程序需要分别进行备份，并且此类备份应该可以在虚拟数据中心内继续。在这种情况下，备份 VM 时也需要做此考虑，例如，基于网络的备份需要考虑网络容量需求，以及备份过程中对系统的性能影响。使用基于来宾的备份，您可以选择在主机中设立专用物理 NIC，它绑定到所有来宾均可使用的虚拟网络。

Windows Server Backup
Windows Server 2008 包含支持 VSS 的 Windows Server Backup (WSB)，它可以用于执行 Hyper-V 基于主机和基于来宾的 VM 备份。因为完全支持 VSS，所以它可以针对正在运行的 VM 执行基于主机的备份，这无疑是十分理想的。
但如果您的 VM 未安装“集成组件”，那将无法使用 VSS。在这种情况下，您有以下两种选择。您仍然可以使用 WSB 备份没有安装“集成组件”的 VM，这意味着需要保存 VM 的状态，并且备份将获取 VM 的虚拟磁盘和配置文件。
但是，这对类似 Exchange 之类的应用程序可能不够理想，因为这类应用程序将无法识别已经运行过备份，且不会修改应用程序日志。此外还需要使 VM 停机，停机时间将视备份所需的时间而定。
或者，可以在 VM 内部运行备份，就像物理机器使用 NTBackup 或 WSB 一样（具体取决于 VM 的操作系统）。让我们看看如何对已安装“集成组件”的受支持来宾使用 WSB。

使用 WSB 备份 VM
Hyper-V 不会为使用 WSB 而自动注册其 VSS 编写器。您必须按照图 5 中所示的方式手动添加注册表项和值才能使 WSB 支持 Hyper-V。可以通过在命令行中键入以下命令来完成此操作：
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v
图 5 用于注册 Hyper-V VSS 编写器的项和值
路径 | 注册表项和值 | 类型
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | 项 | n\a
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | 值 | REG_SZ（例如 Hyper-V）
此操作不需要重新启动，因为 WSB 将在备份运行时搜索此项/值。可以使用以下命令显示是否已设置该条目：
reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
以下是安装 WSB 的方法。单击“开始”|“服务器管理器”。在左侧窗格中，单击“功能”，然后单击右侧窗格中的“添加功能”。在“选择功能”页面上，展开“Windows Server Backup 功能”并选中“Windows Server Backup 和命令行工具”复选框。现在请按以下步骤配置您的备份：
  1. 转到“开始”|“管理工具”|Windows Server Backup。
  2. 如果备份远程主机，则选择“连接到另一台计算机”并键入 Hyper-V 主机。
  3. 选择“立即备份”或“备份计划”。
  4. 选择备份配置 — “完整服务器”或“自定义”。如果选择“自定义”，则需要确保取得所有卷（其中包含与要备份 VM 相关的数据），包括 VM 配置数据、虚拟磁盘和快照。
  5. 选择保存备份的位置。
  6. 选择“VSS 完整备份”或“副本备份”。对于当前没有其他 VM 备份的基于主机备份，可以选择 VSS 完整备份。
  7. 配置好详细信息后，选择“备份”。
注意事项
  • 您必须备份与 VM 相关的所有卷，包括虚拟硬盘 (VHD)、VM 配置文件和快照。
  • 如果创建“备份计划”，您必须使用专用的本地卷，它由 WSB 格式化并独占使用。与之相反，如果准备执行“立即备份”作业，您可以将备份保存在非专用的本地卷、可移动设备或网络共享。
  • 如果要备份的 VM 中未安装“集成组件”，WSB 将保存运行中 VM 的状态以便确保备份数据的一致性。
  • 完成后，备份集可以便携移动且用于任何 Hyper-V 主机。
使用 WSB 恢复 VM
尽管 WSB 确实具备恢复单个文件的能力，但该功能并不使用 VSS，因此如果在备份时 VM 正在运行，则有可能导致产生不一致的恢复。要恢复运行中的 VM，您需要恢复整个卷。
要完成此操作，您必须转到“开始”|“管理工具”|Windows Server Backup，并在“操作窗格”中选择“恢复”。选择要恢复数据的服务器（WSB 备份数据所在的服务器），然后选择恢复数据的日期。接下来选择恢复类型。
此时您必须做出决定。如果需要恢复整个 VM，包括其配置、快照和虚拟磁盘（例如整个主机出现故障），选择“应用程序恢复”，然后选择 Hyper-V，如图 6 所示。在这种情况下，您没有恢复单个文件的选项。您必须恢复备份集中的所有内容。请注意：这不会覆盖自上次备份起发生过变化的现有 Hyper-V 和 VM 配置数据。
图 6 恢复 Hyper-V 备份（单击图像可查看大图）
如果仅需要恢复 VHD 自身，而 VM 的配置数据和快照正常，那您可以选择文件和文件夹，并选择所需的单个 VHD 文件。请注意，该过程不会使用 VSS 编写器；需要谨记在 VM 备份开始前应该先保存其状态。
如果出现整个系统和数据全部损失并希望恢复 Hyper-V 主机自身，包括 Windows Server 2008 操作系统和其中运行的所有 VM，那您必须引导至 Windows 恢复环境并从该环境中执行恢复。可以通过 Windows Server 2008 安装盘或预配置磁盘分区完成此操作。

Data Protection Manager
我们已经介绍了备份和恢复步骤，以及使用免费的可靠内置 WSB 备份 Hyper-V 主机和来宾的注意事项，但 WSB 并不是企业级的数据保护解决方案。Data Protection Manager (DPM) 2007 SP1 才是企业级的数据保护解决方案。该程序当前计划在 2008 年底发布，DPM SP1 将支持 Hyper-V 并提供某些极具吸引力的功能：
  • 用于所有 Hyper-V 主机和来宾的单一管理控制台。
  • 持续数据保护，以最多 15 分钟的间隔拍下基于 VSS 的快照，仅获取进程中的更改。
  • 允许备份跟随 VM 在群集节点间移动的 Hyper-V 群集识别功能。
  • DPM 服务器到 DPM 服务器复制。
  • 支持磁盘和磁带介质（磁盘到磁盘、磁盘到磁带或磁盘到磁盘再到磁带）。
  • 在整个数据范围内备份和恢复，包括 Hyper-V 主机和来宾；运行中来宾的无代理 VSS 备份；支持恢复单个 VM；故障转移群集数据；及用于 SQL Server、Exchange、SharePoint、Hyper-V 和 Virtual Server 的业界一流应用程序专用功能。
  • 备份前和备份后脚本。
如果您当前正在使用第三方备份解决方案，那么请密切关注该应用程序的更新；大多数供应商正努力将基于 Hyper-V 主机的解决方案推向市场。

脚本化备份
WSB 包含命令行界面 (WBadmin.exe)，以及一组用于编写脚本的 Windows PowerShell cmdlet。当使用这些工具时，将应用与前面所述相同的备份规则，并且需要通过注册表手动注册 Hyper-V VSS 编写器。
图 7 显示了一些 WBAdmin 命令。有关 WBAdmin 的完整文档，请参阅 go.microsoft.com/fwlink/?LinkId=124380。如您所见，WBAdmin 中没有能够配置备份策略自身的命令，但有一个 Windows PowerShell 管理单元可以管理这些设置。您可以使用以下命令查看是否已注册该管理单元：
Get-PSSnapin -Registered
图 7 WBAdmin 命令
WBAdmin 命令 | 说明
ENABLE BACKUP | 启用或修改每日计划备份。
DISABLE BACKUP | 禁止运行每日计划备份。
START BACKUP | 运行备份。
STOP JOB | 停止当前运行的备份或恢复。
GET VERSIONS | 列出可从具体位置恢复的备份的详细信息。
GET ITEMS | 列出备份中包含的项目。
START RECOVERY | 运行恢复。
GET STATUS | 报告当前运行作业的状态。
GET DISKS | 列出当前在线的磁盘。
START SYSTEMSTATERECOVERY | 运行系统状态恢复。
START SYSTEMSTATEBACKUP | 运行系统状态备份。
DELETE SYSTEMSTATEBACKUP | 删除系统状态备份。
而且您可以使用以下命令加载名为 Windows.ServerBackup 的管理单元：
Add-PSSnapin windows.serverBackup
加载后，您可以访问用于 WSB 的 Windows PowerShell cmdlet，如图 8 所示。有关每个 cmdlet 的详细说明，请运行此命令：
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
图 8 Windows Server Backup cmdlet
Cmdlet | 说明
Add-WBBackupTarget | 将备份目标添加到备份策略。
Add-WBVolume | 将卷添加到备份策略。
Get-WBBackupTarget | 从策略中获取备份目标。
Get-WBDisk | 获取所有磁盘。
Get-WBPolicy | 获取当前备份策略。
Get-WBSchedule | 获取策略中的备份计划。
Get-WBSummary | 获取备份历史记录和摘要。
Get-WBVolume | 获取所有卷。
New-WBBackupTarget | 新建备份目标。
New-WBPolicy | 新建空策略。
Remove-WBBackupTarget | 从策略中删除备份目标。
Remove-WBPolicy | 删除备份策略。
Remove-WBVolume | 从策略中删除卷。
Set-WBPolicy | 保存 WBPolicy 对象以创建计划备份。
Set-WBSchedule | 为备份策略设置计划。

Windows Server 2008 中还内置了另一个实用程序，它也可以利用 Hyper-V VSS 编写器并提高了脚本编写的灵活性。DiskShadow.exe 允许进行卷影复制并将其作为驱动器装载，这使得管理员能够完成比使用 WSB 更具选择性的备份。切记 DiskShadow 不接受 Windows PowerShell 管道输入；它要求通过脚本传递命令，类似如下所示：
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
此脚本首先删除 C 盘的全部现有卷影副本，然后确保在 DiskShadow 运行之后保留卷影副本。接着它创建事务块 — 如果任何步骤失败，则整个过程失败。在该块中，DiskShadow 验证已加载 Hyper-V 编写器并将 C 盘添加到待备份的驱动器列表。
C 盘将获取 GUID 以便进行标识，并且该 GUID 将保存在名为“MyShadow”的环境变量中。完成后，将创建卷影副本。
备份将使用环境变量以 X 盘的形式出现。可以对其中的数据进行各种操作，然后 DiskShadow 可以再次运行，使用命令 Unexpose X:删除该驱动器。
注意：恢复通过 DiskShadow 备份的 Hyper-V VM 现在是手动过程（必须重新创建 VM，不保留快照等）。虽然这样存在明显的缺点，但却可以保护数据。
总结
DR 是看似永无休止的艰辛旅程。但服务器虚拟化的技术和低成本特性带来了新的亮点。Microsoft 不仅提供虚拟化，而且还提供整个体系。与此同时，服务器虚拟化平台和 System Center 系列还提供了更加全面的解决方案，以应对组织面临的不断加剧的复杂性挑战，包括 DR。
非常感谢 James O'Neill 对完成本文予以的大力支持。

Adam Fazio 在 2 年以前开始加入 Microsoft 咨询服务，目前参与美国公众部门的工作。他在 IT 行业打拼了 10 余年，曾经为财富 100 强创建过各种基础结构项目和数据中心运作，使它们加入了 Internet 这一大家庭。他现在担任 Microsoft 全球虚拟化快速开发项目的技术升级负责人。


虚拟化
用于规划虚拟基础结构的基本工具
Jay Sauls 和 Baldwin Ng
概览：
  • 降低成本
  • 编制计算机清单
  • 确定 CPU、磁盘 I/O 和网络利用率

目录
工具重点推荐
了解您的收获
确定当前利用率
服务器布置建议
虚拟机配置
布置限制
考虑您的选择
要求
总结
虚拟化并不是新技术，但现在正迅速风靡于许多新领域，远远超过 IBM 最初在 20 世纪 60 年代开发的平台虚拟化范畴。此技术得到迅猛发展的主要原因是虚拟化技术的潜能有助于降低数据中心和整个 IT 运营的成本。随着能源消耗与日俱增，组织中不同部门对 IT 服务的需求也日益增大，您可能需要在抑制运营成本的同时努力追赶服务器发展的步伐。虚拟化可以助您一臂之力。并且，Microsoft 和其他软件制造商一直在致力于开发可以使虚拟资源得到更广泛应用的新技术，包括服务器、桌面和应用程序虚拟化等。
在本文中，我们将介绍一个有助于虚拟化项目的工具集 — Microsoft Assessment and Planning Toolkit 3.1 (MAP)，它是 Microsoft 解决方案加速器家族的成员。什么是解决方案加速器？简而言之，它们是几乎所有 IT 项目都会用到的自动化工具和指南。解决方案加速器是免费的权威资源，可帮您前瞻性地规划、提供和操作您的 IT 基础结构（从桌面到服务器，从实体到虚拟）。
经过与行业专家协同设计并在实际客户环境中进行测试，解决方案加速器为提高性能和构建跨产品的 IT 基础结构提供了适当的规范性指南和自动化操作，而不必一切都从头开始。这些资源主要针对各种规模的公司都非常关注的关键问题，如基础结构评估和规划、虚拟化、沟通和协作以及安全性和遵从性。

工具重点推荐
新发布的 MAP Toolkit 3.1（参见图 1）是一款针对整个网络的基础结构评估工具，其设计目的旨在帮助您快速了解您的服务器和桌面，包括它们是否已准备好升级或迁移到诸如 Hyper-V、Microsoft Application Virtualization、Windows Server 2008、Windows Vista、Office 2007 以及 SQL Server 等技术。
图 1 Microsoft Assessment and Planning Toolkit 3.1 （单击图像可查看大图）
如图 2 所示，MAP 会自动生成有关准备情况的评估报告和建议，从而省去您手动操作所需的大量工作。MAP Toolkit 3.1 对服务器和桌面方案都提供支持，还可以评估台式计算机是否适合升级为 Windows Vista 以及规划 Microsoft Application Virtualization 的实施等。
图 2 自动生成的迁移建议示例（单击图像可查看大图）
对于服务器虚拟化规划，此工具包含以下三个重要功能，可帮您确定哪些物理机器是首选机器：服务器清单、性能指标收集和虚拟化布置建议。让我们先来看一种方案，它将向您展示如何使用这些功能来构建详细的当前环境一览表以及如何着手规划虚拟化转换。

了解您的收获
许多大型企业都采用了某种形式的服务器管理基础结构，如 System Center Operations Manager。其中有些环境缺乏有效的管理。对于当前工作环境，如果您不确定采用的是哪些服务器或服务器正在运行哪些程序，则可使用“服务器清单”功能快速勾勒出一幅条理清晰的画面。“服务器清单”功能可利用 Active Directory、IP 地址范围扫描甚至只需从平面文件导入一个机器列表就可查找您所在环境中的计算机。如图 3 所示，您还可以使用多种方法（例如，Active Directory 和 IP 地址扫描）来查找本应在 Active Directory 中但实际却不在的计算机。
图 3 选择计算机查找方法（单击图像可查看大图）
找到计算机后，MAP Toolkit 3.1 会尝试与每一台相连接，并通过 Windows Management Instrumentation (WMI) 检索 50 多类数据。根据这些数据会生成多种不同的报告。对于服务器与虚拟化合并，我们最感兴趣的是当您选择向 Windows Server 2008 迁移特定角色和服务时所创建的报告。
即使不立即迁移到 Windows Server 2008，此方案创建的两份报告也有助于确定您所在环境的硬件种类（包括处理器类型和速度、磁盘大小和安装的内存）以及您为每个服务器所分配的软件角色（DNS 服务器、域控制器和终端服务）。
这些报告以 Microsoft Excel 工作簿的形式提供，因此您可以方便地使用 Excel 的排序和筛选工具来准确判断您所在环境中最适合用于虚拟化的计算机。
服务器清单报告将提供选择要虚拟化的服务器时需要考虑的一些属性的数据。例如，您可能希望确保要虚拟化的计算机所运行的操作系统受到 Hyper-V 虚拟化平台的支持。在通过服务器清单流程创建的 WS2008HardwareAssessment Excel 工作簿中，您可以在“Server Inventory”（服务器清单）选项卡下检查“Current Operating System”（当前操作系统）和“Service Pack”（服务包）列，以查找可能需要升级的所有系统。

确定当前利用率
查找虚拟化候选对象的下一个步骤是测定物理机器的利用率。MAP Toolkit 3.1中的“性能指标向导”（参见图 4）会根据您标记为虚拟化候选对象的机器列表来记录性能计数器。CPU 利用率、磁盘 I/O 利用率以及网络利用率均可以被捕获以供日后查阅。
图 4 性能指标向导（单击图像可查看大图）
此工具的这一部分被设计为可对机器进行较长时间（一个月）的监视，这有助于您灵活选择使用方式。如果您已清楚了解所处环境出现最高利用率的时间（例如，可能是每周出现一次的批处理窗口），则可将此向导设置为仅在该段时间前后的几小时内运行。但是，如果您不确定最高利用率出现的时间或想观测大量具有不同最高利用率时间的机器，则需要将此向导设置为运行数天或数周，以记录计算机数据。这可以使此工具能够根据大量数据自动确定最高利用率。
使用以前的清单信息，通过 Excel 中的排序和筛选功能创建要监视的机器的列表。“性能指标向导”可接受平面文件格式的列表，其中每行显示一个机器名称。先将 Excel 中的机器名称列表复制到记事本中的新空白文本文件中，然后再保存。当出现提示时，将此文件导入向导，并设置性能指标收集时段的结束时间。此向导将进入数据收集模式，并每五分钟一次从指定计算机收集性能计数器。
“性能指标向导”结束工作时，会创建一个详细的 Excel 报告，列出观测到的所有机器和以下不同类别利用率的所有性能指标：CPU、物理磁盘、逻辑磁盘和网络。利用此信息，您可以进一步优化考虑实施虚拟化的候选对象列表。
您既可以选择利用率极低的机器，尝试在一台主机上合并多个此类机器作为虚拟机 (VM)，也可以将此信息与清单数据进行组合，以查找具有任务关键型服务且需要高可用性的机器。虚拟化可用于为高可用性环境提供增强的灾难恢复功能。分析完成后，即可继续最后一步：生成虚拟机布置建议。

服务器布置建议
“服务器虚拟化和合并向导”可用于指定假定的虚拟化主机在 CPU、网络、磁盘子系统和内存等方面的配置情况。利用通过“性能指标向导”收集到的性能数据，“服务器虚拟化和合并向导”可计算出 VM 来宾至 VM 主机的有效映射，从而确保每台主机都得到合理利用，而不会在出现最高利用率时面临使用过度的风险。
“服务器虚拟化和合并向导”结束工作时，将生成一个详细的 Excel 电子表格，其中会显示建议的来宾 VM 至物理主机的映射。对于每个 VM 和主机，此报告都会显示预计的磁盘 I/O、网络 I/O 和 CPU 利用率。在配合过程中将来宾 VM 添加到物理主机时，如果以前的主机达到了容量限制，则会分配新的主机。每次分配新主机时，系统都会显示一则消息指出分配新主机的原因。
如果多台主机均收到同样的消息，则可能需要考虑使用不同的主机配置重新运行“布置向导”，以尝试增加分配给每个主机的来宾数量。例如，如果多台主机均显示消息声称达到了内存极限，则可以尝试重新运行该向导，为主机配置指定更大的内存。这将会增加可以分配给每个主机的来宾数量。

虚拟机配置
在“服务器虚拟化和合并向导”中的每个页面都可以配置假定计算机配置的主要组件，它们将被用于构建 VM 主机容量模型。这些模型既可用于 Virtual Server 2005 R2，也可用于 Hyper-V，在向导的第一页，会要求您提供要使用的虚拟化技术（参见图 5）。
图 5 为布置建议选择要使用的虚拟化技术（单击图像可查看大图）
在 CPU 配置页面，会提供 AMD 和 Intel 的多个系列的 CPU 型号。如果其中未包括您的 CPU 型号，请选择一个最接近的。您可以在此页面中配置实际的处理器、内核和每核超线程的数量。请注意，如果选择 Hyper-V 作为虚拟化平台，则只有 64 位 CPU 可供选择（参见图 6）。
图 6 主机 CPU 配置（单击图像可查看大图）
在向导的第三页，可配置磁盘子系统的磁盘驱动器数和 RAID 技术，以计算主机的可用磁盘空间和磁盘子系统的吞吐量值。吞吐量值可根据所选的接口技术以及磁盘可靠性和性能监视器 (RPM) 速度自动给出。
在 MAP Toolkit 3.1 中，不提供对构建存储区域网络 (SAN) 模型和网络附加存储 (NAS) 磁盘解决方案的直接支持。为了获得近似值，需要选择 SCSI 磁盘技术并配置与 SAN 配置类似的 RAID 级别，而且磁盘速度也要相近。该近似值应足够接近实际值，这样才有助于进行初始规划。

布置限制
将虚拟化来宾计算机映射至物理主机时，必须先考虑六个因素才能评估某个来宾是否与主机的剩余容量相适应：
  • CPU 利用率
  • 网络 I/O 利用率
  • 磁盘子系统 I/O 利用率
  • 内存
  • 磁盘空间
  • 对指定的虚拟化技术的来宾操作系统支持
CPU、网络和磁盘子系统利用率情况相当直观。测定的实际虚拟化来宾候选对象利用率可转换为等效的虚拟化主机利用率，并可随后添加到主机的现有利用率中。如果为了该资源而分配给该主机的所有来宾其总利用率小于阈值限制，则可将来宾分配给该主机。否则，将不会安置此来宾，并会尝试从其他来宾中查找是否有合适的。
例如，假设您收集了一台计算机的性能指标，其 CPU 为 1.2 GHz Pentium 4 并且显示 CPU 利用率为 32%。如果您配置的是具有四核 Intel 至强 5300 系列 CPU 的虚拟化主机，则可根据从可能存在的来宾计算机测得的初始 CPU 利用率来推算出等效的预计主机利用率。此新利用率会因较新的 CPU 体系结构、更快的 CPU 时钟速度和新增的更多内核而低于测得的初始值。
相反，如果您配置的主机其 CPU 性能不如来宾 CPU，则在经过推算后预计的利用率会高于测得的初始值。在任何一种情况下，当来宾被分配给主机时，都会在计算主机的总利用率时使用新推算出的 CPU 利用率。
有关内存和磁盘空间利用率的确定方法问题是一个值得简要讨论的问题。安装在每个潜在的虚拟化来宾中的物理内存总数会保留在主机计数中。此外，主机本身还保留少量内存 (512 MB)。当主机的总内存因来宾分配和主机消耗而被完全占用时，将无法继续在该主机上安置其他虚拟化来宾。
磁盘空间的处理方式也类似：安装在每个潜在的虚拟化来宾中的物理磁盘空间总数会保留在主机计数中。此外，它还保留了 50 GB 的磁盘空间供虚拟化主机使用。当分配给主机的所有来宾所占用的磁盘空间加上主机自身保留的空间达到主机配置中指定的值后，将无法再分配更多来宾。
系统将会针对所选的虚拟化平台进行检查，以确保来宾计算机中运行的操作系统受虚拟化平台的支持。例如，在 Virtual Server 2005 R2 中不支持 64 位操作系统作为来宾，因此，如果选择这些操作系统作为虚拟化技术，则无法安置这些来宾。

考虑您的选择
通过多次运行“服务器虚拟化和合并向导”，即可轻松对比不同硬件情况下的虚拟化主机所得到的结果。每次运行该向导时，都可选择不同的 CPU、磁盘和内存选项，从而找到最适合您的环境的解决方案。
请注意服务器合并 Excel 工作簿中“Consolidation Recommendations”（合并建议）选项卡上的“Last Placement Failed Reason”（上次布置失败原因）列。这些原因可帮您了解无法将更多来宾机器安置在特定主机中的原因。如果数台主机显示的原因均相同（例如，来宾的内存占用量超过了主机的可用内存量），则增加主机配置的内存可能会减少必需的主机数。

要求
MAP Toolkit 3.1 的其中一个优势在于它不必在所清点的计算机中安装任何软件。所有操作均采用远程方式执行。但是，必须先考虑一些因素才能使各项功能正常发挥作用。
为使“清点向导”和“性能指标向导”能顺利完成其工作，必须开启目标计算机上的几个 TCP 端口，并且必须能够从安装有 MAP Toolkit 的计算机访问这些端口。《入门指南》详细介绍了这些要求；简而言之，必须开启待清点计算机中的身份验证、DCOM 和 WMI 端口。如果在运行 MAP Toolkit 3.1 的计算机和清点目标之间的网络中安装了防火墙，必须将这些防火墙配置为允许此流量通过。
MAP Toolkit 3.1 设计用于一次性清点多达 100,000 台计算机的环境，以及收集多达 3,000 台计算机的性能指标。默认情况下，此工具将安装 SQL Server 2005 Express Edition 的私有实例。SQL Server Express 存在 4GB 的数据库文件大小限制，在达到 SQL Server Express 强制要求的文件大小限制之前，此配置大约可以清点 20,000 台计算机。要在清点期间处理更多计算机，必须修改某些默认值。
要处理较大规模的环境，必须使用 SQL Server 完整版，如 SQL Server 2005 Standard Edition。在安装 MAP Toolkit 之前，需要安装 SQL Server 2005 的新实例，并将此实例命名为 "MAPS"。然后，在同一计算机上正常运行 MAP Toolkit 安装程序。MAP Toolkit 要求使用 SQL Server 的本地实例，因此安装程序会自动检测数据库服务器的本地 "MAPS" 实例并安装到其中，而不会安装到 SQL Server Express Edition 中。
对于更大规模的环境，可使用扩容功能，此功能允许在安装有 MAP Toolkit 的多台辅助计算机的协助下执行大规模清点工作，并将收集到的所有数据存储到一个中心数据库中。此配置还要求使用 SQL Server Standard Edition，以避免遇到 4 GB 文件大小的限制。
有关如何在此配置中安装此工具以及如何编辑适用于此模式的数据库连接字符串的详细信息，请参见《入门指南》。此外，扩容功能还可用于将 SQL Server 安置在未安装 MAP Toolkit 的机器中。

所有的解决方案加速器（如 Microsoft Assessment and Planning Toolkit）都是为了能够把您从繁重的 IT 项目任务中解脱出来。MAP Toolkit 已经为许多用户在进行 Hyper-V 部署时节省了数百小时的 IT 规划时间。您是否打算试一试？
如果您想尝试 Microsoft Assessment and Planning Toolkit，可从网站免费下载，网址为 microsoft.com/map，您还可以下载其他虚拟化解决方案加速器，网址为 microsoft.com/vsa。此外，我们还强烈建议您访问 MAP Toolkit 团队博客（网址为 blogs.technet.com/mapblog）以获取更多技巧和观看演示视频。

Jay Sauls 是 Microsoft 解决方案加速器团队的高级项目经理，他一直在从事 Windows Vista Hardware Assessment 和 Microsoft Assessment and Planning Toolkit 等工具的设计和实现工作。之前，Jay 曾在其他 Microsoft 产品团队工作过，包括 Microsoft Commerce Server、Microsoft BizTalk 以及 System Center Capacity Planner。

Baldwin Ng 是 Microsoft 解决方案加速器核心工程团队的高级项目经理。他目前负责的项目包括 Microsoft Assessment and Planning Toolkit 和虚拟化解决方案加速器。Baldwin 在 IT、电子商务和无线 Internet 服务方面拥有超过 16 年的产品管理和开发经验，他曾效力于 Microsoft、Corbis 和 Alltel 等公司。他的博客地址是 blogs.technet.com/MAPBLOG。


编辑寄语 遨游虚拟世界
Joshua Hoffman

虚拟化已经不再是什么新鲜事物了。本月再以它做开场白可能无法再激起大家的热情，但惯而为之吧。虚拟化的概念是 1967 年左右最先在 IBM CP/CMS 操作系统中引入的，并从此将操作系统与底层硬件资源分离开来。虽然此概念在建立之初即相当完善，但在过去 40 多年的时间里也经历了许多变化。
2008 年，对计算机虚拟化的研究又攀上了一个新的高峰。随着降低成本、简化管理以及建立可持续计算实践等需求越来越依赖更强大的多核处理器和最新的管理技术，虚拟化占据主导地位的时代已经悄然来临。这正是本期《TechNet 杂志》所要介绍的内容。本期文章将详细介绍 Windows Server 2008 中激动人心的 Hyper-V 平台、用于管理虚拟环境的工具以及用于部署虚拟应用程序的技术等内容。
就我个人而言，我希望代表整个《TechNet 杂志》的全体同仁向 Microsoft 脚本专家专栏的两位特约编辑 Greg Stemp 和 Jean Ross 表示由衷的感谢。我想当你们得知 Microsoft 脚本专家实际上并不是一群头脑异常发达、一手拿着试管一手拿着脚本在 Microsoft 的大厅里转来转去的小老头时可能会大吃一惊。在过去的三年时间里，一直是 Greg 和 Jean 在《TechNet 杂志》中主持编写“您好，脚本专家！”专栏，并且取得了有目共睹的成就。您好，脚本专家！不但成为我们出版栏目中的最流行专栏，而且一直以来它所获得的赞誉和读者电子邮件也都远远超出我们的预期。
正是由于所有这些原因以及其它更多原因（不仅仅是因为我们对他们的热爱），所以当听到 Greg 和 Jean 将要告别《TechNet 杂志》时，我们都非常难过。Greg 和 Jean 将离开这里去开辟一片新的天地，这一切已成定局。但幸运的是，他们还会在雷蒙德待上一段时间，继续为 Microsoft 的客户奉献他们的才智。让我们祝福他们一切顺利，希望有一天能够在我们的刊物上再次看到他们的文章。
与此同时，令人尊敬的脚本专家 Dean Tsaltas 欣然接受了我们的邀请，将在我们找到下一任脚本专家之前暂时担负起撰写“您好，脚本专家！”的重任。Dean 将在下个月带领我们深入探讨 Windows 管理规范。千万不要错过良机！—Joshua Hoffman

衷心感谢以下 Microsoft 技术专家： Karri Alexion-Tiernan、Carmen Asher、Scott Culp、Steve Ekren、Trina Gorman、Michael Michael、Mike Mitchell、Michael Murgolo、Rob Polly、Dan Reger、Jez Sadler、Bill Scheidel、Bryon Surace 和 Jim Truher。


读者来信 读者心声

SQL 数据库管理
非常感谢2008 年 8 月刊的“SQL Server：高效维护数据库的关键技巧”一文（网址为 technet.microsoft.com/magazine/cc671165）。终于看到了为我们 —非自愿 DBA，一群只需要确保某些被称为 SQL Server 的应用程序仍在运行和备份就万事大吉的数据库管理员 — 撰写的 SQL 文章。
在随后的一页中，您又介绍了“Windows 管理：为服务器把脉”（technet.microsoft.com/magazine/cc718984）。它们真是太棒了。我把这两篇文章都已从杂志中剪下收藏起来 — 因为我们没法处理数字电子杂志。我肯定会时不时重温这两篇文章的。希望你们能继续努力。
得知您对这两篇文章很感兴趣，我们也很高兴。我们一直希望我们提供的内容能对读者有所助益。当然，对于那些热情洋溢的赞美我们也是来者不拒，并且多多益善！如果您希望我们在以后的专栏中包括任何其他主题，请发送邮件告知我们。我们随时期待来自读者的需求反馈。
—Joshua Hoffman，主编

Image X 和 Windows PE
感谢你们提供的有关使用 ImageX 和 Windows PE 部署旧操作系统的专栏（2008 年 2 月刊的“Windows XP 和 Windows PE 2.0 的双引导”，网址为 technet.microsoft.com/magazine/cc194422）。我是在去年发现这些工具的，并随后开始尝试使用它们来替换我的公司一直使用的映像工具 (Acronis Snap Deploy)。大约六个月以前，我可以得心应手地使用它来进行工作了，现在它是我们使用的唯一映像工具。
后来我阅读了你们的文章，并注意到你们提出的有关添加 bootsect.exe /n52 选项的建议。以前我从未听说过这个选项。在应用映像之前我们执行的唯一操作是使用 DiskPart 及其包括的脚本 (commands.txt) 擦除硬盘驱动器。到目前为止我们还未遇到过任何问题，但以后是否会出现问题呢？
在早期是需要使用该命令的。但在该篇文章发表后，一个团队成员告诉我没有必要再使用它，因为现在引导代码中包含逻辑，可以尝试搜索新式启动管理器代码，如果未找到，它会在失败前尝试使用 NTLDR。因此您完全可以忽略这一点，不必担心任何问题。
—Wes Mille，专栏作家，桌面文件

测试映像环境
我阅读了你们的“桌面文件”专栏中有关使用 ImageX 工具实施映像以及通过 Windows 部署服务 (WDS) 启用多播的文章（Windows XP 和 Windows PE 2.0 的双引导）。我想安装一个测试环境，现在想确切知道都需要哪些工具。我是否必须安装 Windows Server 2008 才能实施多播？此外，在镜像映像时，是否必须使用 ImageX 才能安装 Deployment 4 或 Windows 自动安装工具包 (WAIK) 和 WDS？
要通过 WDS 使用多播，必须安装 Windows Server 2008。在 Windows Server 2003 环境下，多播组件现在和将来都不可用。
Deployment 4 不是使用多播的必需工具。要使用它，需要获取 Windows Server 2008 以及适用于 Windows Server 2008 的 WAIK 发行版本。该版本的 WAIK 是包含适用于 Windows PE 多播的必需片段的第一个版本。
—Wes Miller

WDS 多播
我尝试使用 ImageX 在计算机和映像之间执行克隆操作。很快我发现了一个问题：ImageX 不支持多播传输。我想使用 WDS 服务器进行相同的多播传输。这能否实现？Wdsmcast 命令似乎可以达到此目的。如果是这样，WDS 客户端该如何通知 WDS 服务器要下载哪个映像？
确实，ImageX 不能处理多播。您必须使用 Wdsmcast（在 Windows Server 2008 WAIK 中）指定要连接到哪个传输（在服务器上启动了它们之后）。白皮书“使用传输服务器”中提供了有关如何使用 Wdsmcast 进行连接的相关信息 (technet.microsoft.com/library/cc725964)。请阅读章节“如何使用 Wdsmcast.exe 将客户端服务器连接到命名空间”。
—Wes Miller

联系我们 您有问题要问吗？可以向 tnmag@microsoft.com 发送电子邮件与我们联系，或访问我们的博客论坛：blogs.technet.com/tnmag。


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

让应用程序与您形影相随
PortableApps.com
PortableApps.com
作为一名 IT 专业人员，您可能会经常需要从一台计算机移到另一台计算机。当您这样做时，您可能会希望能拥有一组随时可用的标准应用程序、工具和文档。满足这些需求的一种方法就是使用类似 PortableApps.com 所提供的启动程序平台。在其站点上，您可以找到免费的开源 PortableApps.com 平台，以及大量可独立运行于 USB 闪存驱动器、内存卡、便携式硬盘驱动器或数字音乐播放器中的便携式应用程序。
此外还有 PortableApps.com 套件。此套件下载方便，其中包括大量可供选用的便携式应用程序以及基础平台，所有这些只需一个安装程序。共有两个套件版本。套件简装版包括 Mozilla Firefox、Thunderbird、Sunbird 以及 ClamWin 防病毒软件、用于即时消息传递的 Pidgin、Sumatra PDF 阅读器、KeePass 密码管理器、AbiWord 字处理器、音频播放器和一些简单的游戏。套件标准版除包括上述全部应用程序外，还包括 OpenOffice.org 办公套件，其中包含 Writer、Calc、Impress、Base 和 Draw。
此外，该站点还有许多其他开源应用程序被制作成“便携式”版本，包括用于 FTP 的 FileZilla、用于 telnet 和 SSH 的 PuTTY、用于 SFTP 和 SCP 的 WinSCP、用于快速列表的 PNotes 和 Task Coach、用于压缩的 7-Zip、命令提示符、用于清除文件的 Eraser、用于 CD/DVD 刻录的 InfraRecorder、用于磁盘内容可视化的 WinDirStat、用于校验文件的 winMd5Sum 以及用于文件和目录比较的 WinMerge。（经常阅读我的“工具箱”专栏的读者可能会注意到我在前几期的内容中已介绍过许多此类应用程序。）
此外还有一个非常活跃的用户社区，他们会制作一些网络实用工具（如 WinPCap 和 Wireshark）的便携式版本。（这两种工具确实非常有助于执行管理和故障排除任务。）此论坛甚至还专门开辟了一个区域，供大家推荐需要制作便携版本的应用程序。
这些应用程序在您使用的存储设备中是完全独立的。如果它们需要写入注册表或需要任何“离盘”访问权，则它们会在退出时将一切都恢复到运行前的状态。您也可以脱离 PortableApps.com 平台运行这些应用程序 — 为方便使用它们已被打包到单独的安装程序中。但您极有可能会用到此平台的功能，而此套件则提供了一个可以随身携带的自定义环境。
PortableApps.com 平台已设置为自动运行。因此，当您将 USB 闪存或便携式驱动器插入 Windows 主机后，您即可看到所提示的运行平台应用程序的选项。当您启动该平台后，将会出现一个系统任务栏图标。单击此图标将弹出一个菜单，它非常类似于 Windows 的“开始”菜单。此应用程序启动器提供了到所有便携式应用程序的快速链接以及到便携式驱动器文档文件夹的链接，此外还可以显示驱动器剩余空间指示器、用于备份驱动器中的文档的实用工具、搜索工具以及用于安装新便携新应用程序的链接。您可以自定义此界面，从 30 多种界面语言中选择一种适用语言。
使用一段时间后，您可能会对如何修改应用程序使其成为便携式工具发生兴趣。此网站还有一个活跃的“便携式应用程序开发”论坛，可帮您顺利入门。总体看来，这是一组可以放在便携包中的超酷工具。

价格：免费。
PortableApps 让您的工具与您形影相随

排除远程系统的故障
TeamViewer
teamviewer.com
当您排除应用程序出现的故障时，要么提供产品演示和教程，要么费尽口舌搞清用户的问题，但最好还是坐在发生故障的计算机旁来排除故障。不过通常这是不可能的。退而求其次的方法就是借助工具使您“亲临现场”，而不必真的到达现场。TeamViewer GmbH 推出的 TeamViewer 就能使您如愿。
此实用工具的安装过程非常简单，可使您快速与远程计算机建立起连接。TeamViewer 支持的基本操作模式有四种。首先是“远程支持”，此模式允许您控制远程计算机，以便能够排除故障、协助操作和维护以及指导用户完成某个动作。然后是“演示”，此模式允许您在远程用户的系统中显示您的桌面，以便您能够进行动作演示。另一模式是“文件传输”，此模式允许您在两台计算机之间传输文件而无需共享桌面。最后一种是“VPN”，此模式允许您在您的计算机和主机之间建立即时的虚拟专用网络（使用 TeamViewer VPN 适配器安装选项）。
在安全保护方面，此应用程序使用了 RSA 密钥交换和 256 位 AES 会话编码。密钥交换可确保没有“中间人”（包括 TeamViewer 路由服务器）嗅探数据流。此外，当您连接到 Supporter 会话时（Supporter 是用于指代会话主持人的术语），系统会自动生成会话 ID 和密码，远程用户必须输入这些信息才能建立连接。如果您想连接到无人值守的计算机执行一些操作（例如，管理您的服务器），TeamViewer 还提供了安装为系统服务的选项，使您不但可以轻松传输文件、使用远程控制功能、创建 VPN，甚至可以重新启动远程计算机。
在您打算使用应用程序提供支持或进行演示时，另一个超酷功能就是 TeamViewer QuickSupport 模块（或称为 Customer 模块）。这是一个很小的可执行文件，它不需要进行软件安装，也不需要具有对远程计算机的软件安装权限即可运行。最终用户只需双击此执行文件，然后输入会话 ID 和密码，即可将您的会话与计算机建立起连接。
TeamViewer 有一些非常有用的配置选项。您可以优化显示器共享的颜色数量、删除远程显示器的墙纸或选择使 Windows Vista Aero Glass 始终处于启用状态。并且您可以调整会话的常规质量/速度设置。此外，您还可以控制是否启用一些功能，如远程控制、文件传输、VPN 连接、远程键盘和鼠标输入、在本地和远程主机之间切换控制以及查看远程屏幕等。
您可以录制会话供以后重播和审核时使用。如果您不希望通过 TeamViewer 服务器路由（或许出于安全配置方面的考虑），您也可以选择让 TeamViewer 仅使用 LAN 连接进行路由。
Premium 版本支持无限的 Supporter 安装，它还包括一个便携版本，可将其放入 CD 或 USB 闪存驱动器中，从而使此工具与您形影相随。Premium 版本还包括 TeamViewer Manager，它可以记录会话详情并允许您存储合作伙伴详情，这两项功能都非常有用，不但可以追踪客户，还可以向客户提供报告和开具发票。TeamViewer 还可用于 Mac OS X，它支持不同平台之间的访问，使您在 Windows 计算机环境中即可连接到 Mac。

价格：非商业性使用免费。Business 版本 699 美元起，提供一个 Supporter 安装。Premium 版本 1,399 美元，允许无限 Supporter 安装。
使用 TeamViewer 连接到远程系统

书讯
End-to-End Network Security:Defense-in-Depth
如今，网络安全防护引入了多层前瞻性技术来降低发生事故的风险以及限制网络基础结构内外潜在漏洞的出现。《End-to-End Network Security:Defense-in-Depth 》(Cisco Press, 2007) 一书由 Omar Santos 编写，可帮您了解日益复杂的网络防御问题。
尽管出于众所周知的原因，本书属于 Cisco 丛书的一部分，但它仍提供了大量通用的安全信息，从而使其成为网络专业人员或对基础结构安全感兴趣的系统管理员不可多得的一本参考资料。
本书首先概述了网络安全技术，从防火墙和 VPN 一直到入侵检测/防御系统和身份管理。然后，又分以下六个步骤详细介绍了处理安全事故的方法：准备、识别（安全威胁）、分类（安全威胁）、回溯、反馈和总结。
接下来本书讨论了使用各种设备和工具的前瞻性安全框架，包括 IDS/IPS、NAC、AAA、SNMP、Syslog 和 VLAN 等。然后又介绍了主要与 Cisco 网络安全领域解决方案相关的 Cisco 纵深防御方法，内容涵盖无线网络、IP 电话、数据中心安全和 IPv6 安全。本书最后提供了三个案例研究，分别讨论了大中小型企业所采用的一些实际安全解决方案。

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

调查设备 ID
PCIDatabase.com
PCIDatabase.com
您是否曾遇到过这种情况：尝试升级系统但却遇到几个未知设备，其说明中除了标明“PCI 设备”外未提供任何其他信息，您不知道该如何获得驱动程序，或如何在不撕下计算机包装并借助手电筒的光亮在机箱中四处寻找的情况下确定设备型号？或者，您也可能一直在尝试确定已知设备上的基本芯片集究竟是什么型号。如果是这样，那么请访问 PCIDatabase.com，它可以为您提供免费的服务。
这一由用户提供支持的数据库可帮助您根据供应商和设备名称及 ID 进行搜索，以找出更多信息。您只需打开“Device Manager”（设备管理器）、右键单击要查询的设备并选择“Properties”（属性）、选择“Details”（详细信息）选项卡，然后再选择“Hardware IDs property”（硬件 ID 属性）即可。此时将显示一组字符串，其中包含一些十六进制值，带有 "VEN_"（用于供应商）和 "DEV_"（用于设备）等字样。
此站点提供了许多连接至有用资源的链接，可帮您查找是否有适用于您查询设备的驱动程序（当然，也不要忘记查看生产商的网站）。
您还可在 PCIDatabase.com 发现另一种超酷功能：如果您查询某特定供应商，您会看到一个相关页面，其中列出了该供应商的总部地址、电话号码、可用网站、联系人、PCI 设备的供应商十六进制 ID 以及该站点知道的所有该供应商设备的列表。由于此站点是由用户提供支持的站点，因此也鼓励您将您的信息添加到其中。

价格：免费。
在 PCIDatabase.com 获取供应商和设备信息（单击图像可查看大图）

审核和清点资产
CCS Network Inventory
crowcanyon.com
如果不用离开办公桌就能发现任何一台客户端计算机中安装的软件将会为您节省大量时间。我们假设在一段时间内跟踪这些资产是您的工作。Crow Canyon System 可通过其 CCS Network Inventory 解决方案帮您完成这些工作。
此应用程序是一种无代理的清点和审核工具，它可以扫描 LAN 的工作站，收集硬件、软件、服务和用户信息。由于 CCS Network Inventory 不使用远程代理，因此执行环境需要待清点的计算机提供 RPC、计算机浏览器服务、远程注册表服务、文件和打印机共享以及 ADMIN$ 共享访问权（正如大多数其他无代理清点产品一样）。
此应用程序允许您使用替代凭据进行查询，这在扫描范围跨多个域时非常有用。安装完此应用程序后，即可扫描 IP 地址范围、使用 Windows 网络搜索功能、导入计算机列表或手动指定要清点的 Windows 工作站列表。
在 CCS Network Inventory 审核内容方面，它可以收集软件的详细信息，包括：安装了哪些应用程序、应用了哪些修补程序、该计算机安装的是哪种操作系统以及安装了哪些服务包，甚至还可以收集安装的字体信息。在计算机配置方面，您可以了解到正在运行的服务和程序、共享的文件夹、驱动器映射、环境变量、用户帐户、计划任务、启动命令以及正在运行的网络协议。对于硬件，您可以了解到连接的显示器、打印机、硬盘（及其大小和分区）、CD 和 DVD 驱动器、处理器、内存等详细信息。此外，您还可以设置自定义扫描来获取注册表值、文件计数（例如，谁拥有最多的 mp3）以及驱动器的可用空间。
所有信息都存储在应用程序的自定义数据库中，随后可使用此数据来创建报告。CCS Network Inventory 提供了大量内置报告，可将数据进行可视化转换和传送以供审核和报告之用。如果内置报告和查询信息未完全包含您需要的内容，您可以使用内置的 SQL Query Builder 工具来编写和运行更详细的或特定的数据查询内容。
通常，拍摄某段时间内的环境快照以查看变化情况是一种不错的方法。CCS Network Inventory 通过比较两个信息数据库实例，可帮您了解其间的变化。例如，通过比较当前的扫描和一年前的扫描，您可以了解改用 Windows Vista 的工作站的数量、在过去一年中硬件组件进行过更新的工作站数量，或是在您发出警告后仍继续运行不支持的软件的用户。
在撰写本文时，CCS Network Inventory 仍不完全支持 Windows 2008 Server，但可支持其他类型的 Windows 环境，包括 Windows Vista。

价格：25 节点起价 235 美元。
使用 CCS Network Inventory 管理远程资产

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

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


SQL 问题与解答 大型事务日志、何时使用修复功能以及更多其他内容
Paul S. Randal

问：我在备份时注意到一些异常现象，希望您能解释一下。我们需要经常备份 62GB 的生产数据库，以刷新应用程序开发人员所使用的数据。我们总是先删除旧副本然后再还原新副本。还原的副本与生产数据库大小相同，而且数据看起来也一样，但是与备份过程相比，还原过程所需的时间要长很多。这是怎么回事？为什么还原比备份需要更长的时间？
答：其实这不属于异常现象。根据您所处的环境，这种现象通常是预料之中的。备份和还原所需的时间之所以不同，是由于每个流程必须执行的步骤不同。
备份数据库包含两个步骤。主要就是对数据库执行 IO 读取操作以及对备份设备执行 IO 写入操作：
备份步骤 1 读取数据文件中所有分配的数据，然后将其写入备份设备。
备份步骤 2 读取某些事务日志，然后将其写入备份设备。
所需的事务日志数量可能会差异很大，但其数量一定能将还原的数据库恢复到相同的时间点。（我曾在一篇博客文章中深入地说明了此问题，其网址为 sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx。）
而还原数据库最多可能包含四个步骤。涉及的工作要比读写 IO 复杂得多：
还原步骤 1 如果数据库文件不存在，则创建它们。
还原步骤 2 从备份中读取所有数据和事务日志，然后将其写入相关的数据库文件。
还原步骤 3 对事务日志运行恢复过程的“重做”阶段。
还原步骤 4 对事务日志运行恢复过程的“撤消”阶段。
两个备份步骤所需时间与还原步骤 2 所需时间大致相同（假定硬件配置类似并且服务器上没有用户活动）。如果数据文件较大并且需要进行零初始化（这在 SQL Server 2000 中是需要执行的操作，在 SQL Server 2005 中是默认操作），则还原步骤 1 可能需要较长时间。
为避免花费较长时间，请不要在开始还原之前删除现有文件。或者，也可以启用即时初始化，以便快速创建这些文件（有关详细信息，请访问 msdn.microsoft.com/library/ms175935.aspx）。
还原步骤 3 和 4 是对还原的数据库进行恢复，以便确保事务一致性；此流程与崩溃恢复期间对数据库执行的操作流程相同。恢复操作所需时间取决于需要处理的事务日志量。例如，如果在进行备份时恰好有一个长时间运行的事务处于活动状态，则该事务的所有事务日志都会被备份进来，因此届时不得不进行回滚。

问：我打算在日志传送和数据库镜像之间选择一种提供生产数据库冗余副本的方法。我很担心需要在两个服务器之间传送的事务日志数量，尤其是对于我们每晚都需要执行的索引重建操作。听说镜像功能发送的是实际的重建命令而非事务日志，而重建是在镜像中完成的。真的是这样吗？如果是这样，那么对于 BULK_LOGGED 恢复模式，镜像解决方案要优于日志传送，对吗？
答：您听说的观点是错误的。数据库镜像过程是通过将实际的事务日志记录从主体数据库发送到镜像服务器来完成的，这些记录在镜像数据库中将被“重播”。对于镜像的数据库，既不存在任何类型的转换或筛选，也不存在任何类型的 T-SQL 命令拦截。
数据库镜像仅支持 FULL 恢复模式，这意味着始终会完全记录索引重建操作。根据涉及的索引大小的不同，这可能意味着会生成大量事务日志，从而导致主体数据库的日志文件很大，在将日志记录发送到镜像时需要占用大量的网络带宽。
您可以将数据库镜像视为实时日志传送（实际上，这正是早期在 SQL Server 2005 开发期间该功能所使用的名称）。在日志传送过程中，主数据库的事务日志备份会定期传送到辅助服务器上，并在辅助数据库中进行还原。
日志传送功能支持 FULL 和 BULK_LOGGED 恢复模式。对于使用 FULL 恢复模式在日志传送数据库中所执行的索引重建操作，生成的事务日志量将与镜像数据库中生成的数量完全相同。但是，在日志传送数据库方案中，数据是以日志备份（或系列日志备份）而非连续流的形式发送到冗余数据库的。
如果在索引重建完毕后在日志传送数据库中使用 BULK_LOGGED 恢复模式，则只会生成少量的事务日志。但是在下次事务日志备份时，还将会包含被所记录的最低限度索引重建操作改变的全部数据文件范围。这意味着无论是纳入在 BULK_LOGGED 恢复模式下重建的索引的日志备份还是纳入在 FULL 恢复模式下重建的索引的日志备份，其大小都几乎完全相同。
因此，对于镜像数据库与日志传送数据库中的索引重建而言，需要发送到冗余数据库的信息量几乎完全相同。实际的差别仅在于发送信息的方式 — 是连续发送还是成批发送。
在这两种方法之间进行选择时需要考虑许多其他因素（因素太多，仅在一次 SQL 问题解答中无法全部讨论）。您应该先了解所有这些因素与您的需求的关联程度（例如，可接受的数据丢失限制和允许的停机时间），然后再做决定。

问：我正在运行 SQL Server 2005，我发现其中一个数据库的事务日志一直在不断增大。该数据库处于完全恢复模式，我正在进行事务日志备份。我认为这本应该防止事务日志不断增大。这其中究竟发生了什么问题？
答：在完全恢复模式下进行事务日志备份很重要，在这一点上您是对的。但是，还有其他一些因素可导致事务日志增大。这完全取决于究竟是什么在要求事务日志成为被使用的日志（或活动日志）。除了缺乏事务日志备份以外，可能会导致此现象发生的其他常见因素还包括复制、数据库镜像和活动事务等。
复制过程是通过异步读取事务日志记录，然后加载这些事务并将其复制到单独的分布数据库来完成的。尚未被复制日志读取器任务读取的任何事务日志记录都无法被释放。如果您的工作负载生成了大量事务日志记录，而您又为复制日志读取器的运行频率设置了较长的时间间隔，则会累积大量记录，导致事务日志增大。
如果您运行的是异步数据库镜像，则可能会存在尚未从主体数据库发送到镜像服务器的事务日志记录储备（称为数据库镜像 SEND 队列）。这些事务日志记录在成功发出之前无法被释放。如果生成了大量事务日志记录，而网络带宽又受到限制（或出现其他硬件问题），则储备可能会变得很大，导致事务日志不断增大。
最后，如果用户启动了一个显式事务（如使用 BEGIN TRAN 语句），然后进行了某些形式的修改（如 DDL 语句或插入/更新/删除操作），则所生成的事务日志记录在用户提交或回滚该事务前都需要进行保留。这意味着由其他事务生成的任何后继事务日志记录也无法被释放，因为事务日志无法选择性地进行释放。如果假设该用户当天没有结束该事务就下班回家了，则随着越来越多的事务日志记录被不断生成而又无法释放，事务日志就会越来越大。
要了解事务日志无法释放的原因，可以查询 sys.databases 系统目录视图并查看 log_reuse_wait_desc 列，类似于下面所示：
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
如果证明是由于某个活动事务所导致的，可使用 DBCC OPENTRAN 语句获取有关该事务的更多信息：
DBCC OPENTRAN ('dbname')

问：我听说在从损坏进行恢复时，不到万不得已不要使用 REPAIR_ALLOW_DATA_LOSS；而应先使用备份进行还原。您是否能解释一下为什么不应使用 SQL Server 2005 的修复功能，以及为什么在使用时要考虑“危险”程度？
答：首先，我确实编写过有关 SQL Server 2005 修复的文章。REPAIR_ALLOW_DATA_LOSS（以下简称为“修复”）的问题在于其工作方式不是很清晰。之所以这样命名此“修复”正是为了说明运行它可能会导致数据库中的数据丢失。此功能修复损坏的数据库结构的方式通常是先删除损坏的结构，然后修复数据库中的其他所有内容（引用已删除结构的或被已删除结构引用的）。在保持数据库结构一致性方面，“修复”的确是不到万不得已不推荐使用的方法，因为它的着眼点不是挽救用户数据。“修复”不会故意去删除用户数据，但它也不会主动去挽救用户数据。
这样一来您可能会认为“修复”是一种不可靠的方式，但是当不得不进行修复时，它可以提供一种最快捷最可靠的方法来修复损坏数据。在进行灾难恢复时，速度极为重要，并且要求绝对准确。设计出经过验证能在各种情况下迅速准确地完成修复操作的复杂修复算法几乎是不可能的。例如，在修复代码中有一些复杂算法可解决为两个索引分配同一页面或范围的问题，但通常此算法都是采用此“修复”功能再加上一些修补。
此外，还有其他一些需要了解的有关“修复”的问题：
  • 在删除损坏的结构时，“修复”不会考虑外键约束，因此，可能会删除与其他表格有外键关系的表格中的记录。如果在运行“修复”后不运行 DBCC CHECKCONSTRAINTS，则无法确定是否发生了这种情况。
  • “修复”不会（也无法）考虑在应用程序级定义的、可能会被要删除的某些数据破坏的任何内在业务逻辑或数据关系。同样，如果不运行应用程序中构建的任何一种自定义的一致性检查，则无法确定是否有关系遭到破坏。
  • 某些修复操作无法被复制。在对等拓扑中对发布服务器或节点运行“修复”可能会在拓扑中引入不一致问题，必须手动进行纠正。
鉴于以上原因，通过采用备份而非运行“修复”来从损坏中进行恢复始终是个不错的办法。但是产品中也提供了“修复”，因为一旦出现数据库受损而又没有备份的情况，最起码要有一种方法能使数据库迅速恢复联机状态。

问：我刚以一名 DBA 的身份加入一家新公司，现在需要负责管理多种应用程序及其后端数据库。其中一种应用程序的更新性能非常差。在经过调查后，我发现该应用程序使用的每个表都包含大量索引。经过多方询问后，才知道似乎是以前的 DBA 喜欢对各个表列及某些组合添加索引。我认为并非所有索引都是必要的，但我该如何找出可以安全删除的索引呢？我们运行的是 SQL Server 2005。
答：正如您所猜测的那样，大量索引极有可能是造成性能不佳的主要因素。每次在表中插入、更新或删除行时，都需要在每个非群集索引中执行相应的操作。这将在 I/O、CPU 利用率和事务日志生成等方面增加大量的管理开销。
在 SQL Server 2000 中，判断正在使用哪些索引的唯一途径是使用配置文件和检查查询计划。在 SQL Server 2005 中，则可使用新的动态管理视图 (DMV) -sys.dm_db_index_usage_stats，它可以跟踪索引使用情况。
此 DMV 会跟踪数据库启动以来的每一次索引使用及使用方式。SQL Server 关闭后所有数据库的统计信息均会丢失，某个数据库关闭或拆分后，该数据库的统计信息会丢失。其想法是如果某个索引未出现在输出中，则它肯定在数据库启动后就未被使用过。
随着时间的推移来跟踪索引使用情况的简单方法是定期拍摄 DMV 输出的快照，然后对这些快照加以比较。许多人都忽略的一点是必须跟踪索引在整个业务周期内的使用情况。如果您只是拍摄一天的快照，则可能会发现多个未使用过的索引。但是，如果这些索引是具有其他用途，比如用于帮助月底报表更快速地运行，则可能不应该删除这些索引。如果某索引确实在整个业务周期内都未被使用过，则很可能能够将其删除并回收空间以提高性能。
有关用于定期拍摄 DMV 快照的一些简单代码，请参见我的博客文章，网址为 sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx。

Paul S. Randal 是 SQLskills.com 的总裁，也是 SQL Server 的 MVP。Paul 曾编写过 DBCC CHECKDB/repair for SQL Server 2005，并在 SQL Server 2008 的开发过程中负责核心存储引擎部分的工作。Paul 是灾难恢复、高可用性和数据库维护方面的专家，经常出席一些会议。他的博客地址是 SQLskills.com/blogs/paul。


实用工具特别推荐 Offline Virtual Machine Servicing Tool
Peter Skjøtt Larsen 和 Suveen Kumar Reddy Vuppala

内容
安全梦魇
揭秘
维护基础结构
使用工具
即将推出
虚拟化计算机工作负载就是意味着使用虚拟机 (VM) 来从底层硬件分担工作负载。现代 IT 部门发现 VM 在许多情况下非常有用，包括：
转移工作负载您可以根据使用需求的变化通过 VM 方便地增减多种方案的工作负载带宽，而无需相应对硬件进行改动。
开发和测试应用程序可以创建多个 VM，分别代表应用程序需要支持的每种配置，而无需使用专用的硬件。
软件升级您可以通过 VM 来使新版软件包联机工作，而将旧版置于脱机状态 — 两个版本同时存在于相同的硬件中。
软件分发可使用 VM 作为业务线应用程序的分发单位，它在预测试软件包中拥有一致的软件组合。

安全梦魇
使用 VM 的其中一个好处是您可以在脱机状态下将其存储为 VM 映像。然后在需要时可以随时“唤醒”这些 VM，而且部署它们的速度要比部署等效硬件的速度快很多。
但是，使越来越多的计算环境处于等待脱机状态会带来一个维护问题。许多软件更新机制都必须依赖于系统联机状态，这样才能检查更新情况或自动接收更新。
如果 VM 不是处于联机状态，则它只是计算机中的一个文件，无法与任何更新机制进行交互。因此，脱机几个月后再联机的 VM 可能会威胁到网络安全，或者网络会威胁到它的安全。
这并不只是错过操作系统更新这样简单。过期的应用程序或病毒配置文件可能会使 VM 易受攻击或与公司标准不相符合。
为了帮助客户解决脱机 VM 的更新问题，Microsoft Solution Accelerator 团队开发了 Offline Virtual Machine Servicing Tool。此工具使用 System Center Configuration Manager (SCCM) 2007、Windows Server Update Services (WSUS) 3.0 和 System Center Virtual Machine Manager (VMM) 2007 来协调所存储的 VM 的更新。图 1 显示了此工具的概念性说明以及它如何与各种外部组件相连。
图 1 Offline Virtual Machine Servicing Tool 的工作原理（单击图像可查看大图）
为使 VM 能够进行更新，此工具使用 VMM 来暂时将其部署到维护主机。由于维护主机配置通常都具有同时运行多个 VM 所必需的 CPU 性能和内存容量，所以此工具可以成批处理 VM。
VM 在维护主机上处于活动状态后，SCCM 或 WSUS 马上就可以向其提供必要的更新。更新完毕后，此工具使用 VMM 使 VM 重新回到脱机状态。（请注意，此工具仅支持由 VMM 管理的 VM。）

揭秘
Offline Virtual Machine Servicing Tool 使用 Windows Workflow Foundation (WF) 来协调 VM 的更新流程。从选择适当的更新管理系统开始，到挑选适用于 VM 的下一可用维护主机、确保更新操作启动，再到最后的处理异常事件，更新程序包含了许多决策点。
使用基于 Windows WF 的解决方案赋予了开发团队极大的灵活性，他们可以方便地对流程进行更改并推动其向前发展。此外，它还为用户提供了一个稳定可靠的解决方案，此方案可根据用户需要量身定制以满足其特定需求；在此流程的关键衔接点，工作流前后的内置步骤提供了各种自定义机会。
此工具使用 Windows PowerShell 来执行工作流级别以下的单个任务，可与 VMM 提供的 Windows PowerShell API 完美结合。此外，基于 Microsoft .NET Framework 的 UI 看上去非常类似于系统中心产品，因此新用户使用起来会感到很熟悉。

维护基础结构
维护基础结构的一个基本原则是配置网络安全，以防 VM 在更新过程中受损。在此工具的 1.0 版中，这是通过 VMM 和相应更新系统（WSUS 或 SCCM）所连接的虚拟专用网络 (VPN) 实现的。大多数用于 VMM 库的相应基础结构采用的都是光纤通道连接的存储区域网络 (SAN)，它可以快速将 VM 映像传送到维护主机。
所有 VM 都必须是使用 Active Directory 和 DNS 的同一域的成员。各单独的服务器可专用于 VMM、WSUS、SCCM 和 VMM 库，但虚拟服务器的组合也可用于更小的环境。不用说，维护主机必须是物理服务器。

使用工具
建立了维护基础结构后，需要先检查某些设置是否正确，然后才能启动此工具。确保 VMM 正在管理所有相应的 VM、各 VM 均安装了相应的更新客户端并且在 WSUS 或 SCCM 中已配置了必需的更新包。确保在 VMM 中配置维护主机组是可选项。
准备就绪后，即可启动 Offline Virtual Machine Servicing Tool，其中包含大量的配置步骤。您必须指定 VMM 服务器和相应的 WSUS 或 SCCM 服务器，然后指定要使用的维护主机组（如果维护主机已分组）以及该主机组中要使用的维护主机（参见图 2）。您可能会希望配置要管理的 VM 组，但这是可选项。
图 2 配置 Offline Virtual Machine Servicing Tool（单击图像可查看大图）
配置完此工具后，即可创建维护作业。维护作业包含此工具用来管理特定 VM 的所有信息，包括是使用 WSUS 还是使用 SCCM 进行更新、VMM 服务器和 WSUS 或 SCCM 服务器的位置、待管理的 VM 的身份、要用于此流程的网络类型（以及身份，如果适用）、要使用的维护主机的身份、访问 VM、VMM 服务器和 WSUS 或 SCCM 服务器所需的帐户凭据，最后还包括运行维护作业的时间计划（立即运行还是在指定日期和时间运行）。
如果为运行维护作业指定了日期和时间，则 Windows 任务计划程序会自动确定启动时间。当维护作业运行时，Offline Virtual Machine Servicing Tool 对每个 VM 均沿用下列程序：
  • 从 VMM 库选择下一个 VM。
  • 在 VMM 中查询最合适的维护主机。
  • 将 VM 部署到维护主机。
  • 确保 VM 连接到正确的网络。
  • 启动 VM。
  • 确保在 VM 上安装了相应的更新客户端。
  • 触发更新流程。
  • 等待更新流程完成。
  • 关闭 VM。
  • 将 VM 重新存储回 VMM 库。
更新不同 VM 库所需的时间也各不相同，具体取决于维护主机的数量和性能、对 VMM 库存储内容的访问速度以及更新性质。
即将推出
请注意，Offline Virtual Machine Servicing Tool 的当前版本 (1.0) 不支持网络访问保护 (NAP)，它是一种极具吸引力的限制 VM 访问网络的方法。除此之外，它还不支持 Windows Server 2008 的 Hyper-V 技术，也不支持使用 Windows Server 2008 作为客户端操作系统。
新版本的 SCCM、WSUS 和 VMM 即将推出，而 Offline Virtual Machine Servicing Tool 2.0 版将会提供对这些新版本的支持，同时还会支持 Hyper-V 和在客户端使用 Windows Server 2008。此工具还将会提供对 NAP 的支持，以便进行网络隔离。您可以从 technet.microsoft.com/cc501231 下载 Offline Virtual Machine Servicing Tool。

Peter SkjØtt Larsen 是 Microsoft 的高级产品经理。在加入 Microsoft 之前，Peter 曾参与过电信运营软件系统的架构设计和开发以及无线服务标准化的制定和开发。
Suveen Kumar Reddy Vuppala 是 Microsoft 的高级软件开发工程师。他在过去的七年间曾设计和开发过 Microsoft 的实时监视工具和部署解决方案。


Windows PowerShell 配置文件的力量
Don Jones

目录
外壳、主机和配置文件
使用配置文件？
创建自定义控制台
更多配置文件技巧
配置文件须知！
如果您定期阅读本专栏，那么至此您应该已经知道 Windows PowerShell 支持配置文件体系。它们实质是外壳在运行时自动执行的外壳脚本，具有 .ps1 文件扩展名。例如，它们提供了一种不错的方法来定义自定义别名。有了自定义别名后，在每次运行外壳时，配置文件都会自动定义您的别名，从而使它们在您使用外壳时随时可用。
外壳可以定义以下四种不同的配置文件：
  • 应用到所有外壳和计算机的所有用户的配置文件。
  • 应用到所有用户但仅应用到 Microsoft PowerShell 外壳的配置文件。
  • 应用到当前用户和所有外壳的配置文件。
  • 应用到当前用户且仅应用到 Microsoft PowerShell 外壳的配置文件。
“所有外壳”这一概念可能有点令人困惑。此术语源于 Windows PowerShell 的一些早期开发概念，它们并未真正应用到最终产品中。现在，术语“所有主机”可能会更准确一些。

视频
观看 Don Jones 演示如何创建配置文件以自定义 Windows PowerShell 外壳。

外壳、主机和配置文件
其实，Windows PowerShell 本身就是一组 Microsoft .NET Framework 程序集。我喜欢将这一部分外壳称为 Windows PowerShell 引擎，因为它包含通常被视为属于 Windows PowerShell 的功能。但是，没有内置的方法可供人们与此引擎交互。如果确实想要使用此外壳，必须通过宿主应用程序（或主机）加载此引擎。
您过去经常运行的 powershell.exe 应用程序就是一个此类主机。Windows PowerShell 2.0 社区技术预览版 (CTP) 随附的 gpowershell.exe 应用程序也是一个主机。主机和外壳之间的关系并不像我在这里说的这样简单，但这一简化的解释也完全涵盖了您所看到的行为。
必须要了解的是，如果通过基于文本的命令行界面与外壳进行交互，则您很可能使用的是 powershell.exe 主机。但即使您使用由其他应用程序（如 Exchange 管理外壳）所安装的快捷方式来启动外壳，这也同样适用。Exchange 管理外壳并不属于另一种外壳或宿主应用程序。实际上，它只是使用快捷方式启动的常规 powershell.exe 主机，此快捷方式可指定一组要预加载的管理单元和脚本。这些管理单元可在外壳中启用 Exchange 管理功能。但您使用的仍是相同的外壳。
powershell.exe 主机配置文件（在 Windows Vista 中）的位置如下所示：
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 用于计算机的所有用户和所有外壳。
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 用于计算机的所有用户，但仅用于 Microsoft.PowerShell 外壳。
  • %UserProfile%\Documents\WindowsPowerShell\profile.ps1 仅用于当前用户和所有外壳。
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 仅用于当前用户和 Microsoft.PowerShell 外壳。
这些配置文件并不是在默认情况下创建的。必须在您手动创建后，它们才会出现。
每个宿主应用程序负责加载和执行正确的配置文件。如果某个特定宿主应用程序“决定”不加载任何配置文件，它实际上真可以这样做。配置文件的执行并非是由 Windows PowerShell 引擎自动实施的。
跟踪这一切的最简单方法是打开外壳，键入 $profile，然后按下 Enter 键。它将向您提供一个完整路径，外壳会试图使用它来作为被我称为“主”配置文件（它是针对每个用户且特定于外壳的配置文件）的路径。然后您可以创建或修改该脚本，而此脚本在每次外壳启动时都会执行。

使用配置文件
正如我之前建议的，配置文件的其中一个常见用途是定义自定义别名。或者，您可添加自定义 PSDrive（它们实质上是完全存在于 Windows PowerShell 中的映射驱动器）。不太常见的一种用途是根据您在环境中所使用的软件产品创建一种超外壳，它可以根据您的需求执行任何管理任务。要真正解释超外壳概念，首先需要了解一些背景信息。
Microsoft 中创建 Windows PowerShell 的产品组也负责许多其他核心管理技术，包括 Microsoft 管理控制台 (MMC)。MMC 具有与 Windows PowerShell 非常类似的工作原理。运行 mmc.exe 时，首先出现的是一个空白控制台，这对许多人来说都没什么用。您需要添加 MMC 管理单元才能创建一个能正常运行的控制台。
根据需要配置了控制台后，可将控制台保存在一个扩展名为 .msc 的文件中。利用这一保存的控制台文件，您可以随时快速重新加载自定义控制台。
许多管理员并不创建自定义 MMC 控制台，而是依赖于随所管理的产品一同安装的控制台。例如，Exchange Server 创建的控制台仅包含 Exchange Server 管理单元。“Active Directory 用户和计算机”是另一个包含单个管理单元的预创建控制台。
Windows PowerShell 的工作原理非常类似。随 Exchange Server 2007 管理工具一同安装的 Exchange 管理外壳图标实际上是指向 powershell.exe 的快捷方式，其中包含加载控制台文件的指令。外壳控制台文件的扩展名为 .psc1，内含要预加载的管理单元的列表（非常类似于 .msc 文件，其中包含 MMC 为您预加载的管理单元的列表）。但是，您并非一定要使用这些预创建的外壳控制台。您可以创建自定义控制台（就像在使用 MMC 时一样）并使用它来完成所有管理任务。配置文件在这一实现过程中起着关键作用。

创建自定义控制台
要创建自定义控制台，首先应查找要处理的每个管理单元的全名。确保所有必需的管理工具都已安装在计算机中。然后，在 Windows PowerShell 中运行 Get-PSSnapin –registered。这将列出所有已注册但却未加载的可用管理单元。然后创建或编辑相应的 Windows PowerShell 配置文件。添加 Add-PSSnapin 命令，加载希望始终可用的每个管理单元。这可能包括用于 Exchange Server、System Center 产品以及第三方管理单元（如 PowerShell Community Extensions）的管理单元。然后保存配置文件（请记住，如果 Windows PowerShell 执行策略需要，则对配置文件进行数字签名）并关闭外壳。重新打开外壳，它会自动加载配置文件中列出的所有管理单元。
另一种技术是将所有管理单元加载到外壳中（使用 Add-PSSnapin 和管理单元的名称），然后运行 Export-Console 创建一个 .psc1 控制台文件，其中包含当前正在使用的所有管理单元。然后，可使用这一 .psc1 控制台文件创建一个新的 Windows PowerShell 快捷方式，以指定 PSConsoleFile 参数和自定义的 .psc1 文件。该快捷方式随后会使用您的控制台，并自动加载所有指定的管理单元。

更多配置文件技巧
我使用我的 Windows PowerShell 配置文件在每次外壳启动时执行许多其他有用的任务。以下是在我的系统上启动外壳时发生的一些情况：
  1. 我使用我的域管理员帐户运行 Get-Credential，并将结果存储在名为 $cred 的变量中。这将使 $cred 在整个外壳中都可用。然后可将其传递到各种 cmdlet（如 Get-WmiObject cmdlet）的 –credential 参数。由于 $cred 存储有密码，因此我可以直接使用这些 cmdlet 而不会被提示输入密码。
  2. 我运行 Cd C:\ 以便外壳在我计算机的 C:驱动器的根目录启动。
  3. 我运行 New-Alias of Out-File 以创建一个名为 "of" 的别名。这样，我可以使用 "of" 而不是使用 "Out-File"。我需要经常使用它，因此定义简短的别名非常方便。
我尝试在外壳的 HKLM:驱动器中创建一个测试密钥，HKLM 代表注册表的 HKEY_LOCAL_MACHINE 部分。如果出现错误，则我知道外壳是在没有提升权限的情况下启动的。通常我所做的工作需要提升权限，这只是我在执行重要工作之前预先了解自己是否具有提升权限的一种快速方法。
我定义一个名为 Ping-Address 的自定义函数，用于接收计算机名称或 IP 地址并根据计算机是否可 ping 返回 True 或 False 值。在我的工作中需要经常使用此函数，因此我在配置文件中对其进行了定义，以使其在我的外壳中全局可用。

本月 Cmdlet：Get-WmiObject
细心的读者可能已猜出我要介绍先前提过的 cmdlet，但我希望首先谈一谈它提供的一个很酷的变化功能。我常常看到有一些管理员试图通过使用以下技术从多台计算机（其名称列在一个文本文件中）来检索 Windows 管理规范 (WMI) 信息：
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
尽管此技术非常有效，但实际您并不需要它，因为 Get-WmiObject 可接受 –computerName 参数的计算机名称数组。要实现相同的效果，您只需使用：
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
将 Get-Content 命令放在括号中可强制外壳执行命令并将结果（计算机名称的数组）放入 –computerName 参数中。
配置文件须知！
请注意，powershell.exe 并不是加载 Microsoft.PowerShell 配置文件或所有外壳配置文件的唯一应用程序。许多提供 Windows PowerShell 支持（包括来自 SAPIEN Technologies 的 PrimalScript、来自 Quest Software 的 PowerGUI 以及来自 ShellTools 的 PowerShell Plus）的集成开发环境 (IDE) 也加载这些相同的配置文件，以提供与 powershell.exe 主机类似的体验。
加载大量管理单元的大型配置文件可能会导致这些应用程序的启动速度变慢，因为在准备就绪并且可以用于宿主应用程序之前，Windows PowerShell 引擎需要执行大量的指令。实际上，如果执行一个非常大的配置文件，即使是 powershell.exe 也需要经过一段时间才能启动起来。
使用相同名称来定义 cmdlet 的管理单元也可能会导致冲突。例如，如果两个管理单元都分别定义一个名为 Get-User 的 cmdlet，则 Windows PowerShell 不会执行任何一个 cmdlet，必须使用 cmdlet 的完全限定名来指定需要处理的具体目标。该完全限定名可能比较难看，因为管理单元名称可能会非常长。如果遇到此问题，我通常只是放弃同时加载这两个管理单元的想法。相反，我会仅加载在配置文件中最常用的管理单元，然后在需要加载并使用其他管理单元时使用单独的“全新”外壳。
Windows PowerShell 配置文件可为外壳提供大量附加的便利。但请记住，如果被某段恶意软件进行了恶意编辑，则配置文件也可能会造成大范围的破坏。要保护配置文件，您可以对它进行数字签名并对 Windows PowerShell 进行配置以使用它的 AllSigned 执行策略，或者修改配置文件（所有）的 NTFS 文件权限以使常规用户帐户无法修改它们。

Don Jones 是《Windows PowerShell:TFM》和《VBScript, WMI, and ADSI Unleashed》的作者。您可以通过 PowerShellCommunity.org 网站与他联系。


您好，脚本专家！ 临别感言
Microsoft 脚本专家

著名的希腊哲学家苏格拉底（死于公元前 399 年，在“脚本编辑器”问世之前不久）很可能是因为说过“浑浑噩噩的生活不值得过”而出名的。很多人也都知道这句名言。但值得一提的是，脚本专家们最近发现苏格拉底根本就没有说过“浑浑噩噩的生活不值得过”这句话。事实证明，这句名言只是数百年前某位中世纪抄写员的误译。苏格拉底的原话其实是：“未经检验的 XML 文件根本不值得存在”。
现在看来，这句哲学名言确实很有道理！XML 最近变得越来越流行；快速搜索一下某位脚本专家的测试计算机，最少也能马上找出由各种系统或应用程序使用的 500 个 XML 文件。
另外，现在很多非常重要的数据也都以 XML 的格式存储。这样做很正确。当然，如果这些数据未经检验则不属正确之列。但让人沮丧的是，这种情况时有发生，如果没有其他原因，那只能说明：许多人对如何检验 XML 文件一无所知。特别是他们不了解如何查询和搜索 XML 文件。
注意可能您对希腊哲学家不太熟悉，苏格拉底非常喜欢四处高谈阔论，但却不愿意做一些实事，事实上，他的妻子赞西佩就把他称为“无聊的闲人”。现在您应该知道为什么脚本专家会在内心对苏格拉底充满好感了吧。
当然，你们当中肯定有人会想，“等一下：脚本专家不是已经在以前的专栏（technet.microsoft.com/magazine/cc162506“追汽车……和 XML”）中讨论过如何搜索 XML 文件了吗？既然如此，为什么他们现在还要再讨论这个话题呢，是不是脚本专家们已经懒惰到一遍又一遍地重复撰写相同专栏的地步啦？”
不管您是不是相信，我们实际上比您想象的还要懒。但这并不是我们重新讨论这个话题的主要原因。在以前的专栏中，我们讨论过结构类似于图 1 中所示代码的 XML 文件，其中每个属性值都代表文件中的单个节点。
图 1 仅包含节点的 XML 文件
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
这个文件很不错，但除了便于写入和指示外，它并不是 XML 文件的唯一组织方式。在前面的示例中，文件中的每个计算机都有其自身的节点；而其中的每个节点又包含许多子节点（os、department 和 name）。但是，也可以构造一个各节点都不包含子节点的 XML 文件；附加属性值将被配置为属性。类似于图 2 中的文件所示。
图 2 包含属性的 XML 文件
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
这有什么问题吗？事实上，确实有问题。我们在很久以前在一个很久远的问题中为您展示的脚本就无法使用图 2 所示的 XML 文件的结构。那是因为当时没有发生这种情况。但这确实是一个不容回避的问题，因为你们当中的许多人都需要读取这种类型的 XML 文件。
有问题请尽管提问。不过在我们最终回过头来解决这个问题之前可能还得等上一年半载。
在继续讨论之前，让我们仔细看一看我们的 XML 文件。在本例中，文件的主要节点名为 HARDWARE；每个单独的计算机都作为 HARDWARE 的子节点存在。除此以外，其中的每个节点还都包含一对属性：os（用于存储计算机中所安装的操作系统的名称）和 department（用于存储拥有该计算机的部门的名称）。
例如，假设我们希望获得所有运行 Windows XP 的计算机的列表。使用脚本能做到这一点吗？当然可以：
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
让我们看一下这个脚本。首先我们创建一个 Microsoft.XMLDOM 对象实例；顾名思义，这个对象可使我们能够对 XML 文件进行处理。创建完对象后，我们将 Async 属性设置为 False；这可以告诉脚本我们希望同步加载文档而不是异步加载。为什么脚本会关心这一点呢？说句实话，可能它根本就不关心；毕竟脚本（像脚本专家一样）都是没有生命死气沉沉的。
但您却必须关心这一点。如果异步加载文档，即使文档未完全加载，脚本也会继续运行下去。这就有点糟糕了：想象一下如果试图对并不存在的文档执行任务可能会出现什么情况。同步加载 XML 文件可确保在脚本继续执行前文件已完全加载。
真是太巧了，我们现在刚好到了加载 XML 文件的步骤。我们通过调用 Load 方法并打开文件 C:\Scripts\HARDWARE.xml 进行加载，代码如下所示：
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
在这里我们采用了 SelectNodes 方法来查询 XML 文件，并告诉脚本我们希望检索哪些 XML 节点。请注意这种确实有点不同寻常的语法。
首先，我们需要指定在 XML 文件中的路径。我们的 XML 文件有一个名为 HARDWARE 的顶级节点，后跟一系列名为 COMPUTER 的二级节点。其中每个二级节点都代表 XML 数据文件中的一条单独记录。这正是 selectNodes 查询以如下方式开始执行的原因：
//HARDWARE/COMPUTER
在这里，我们遇到了这种结构：
[@os='Windows XP']
这部分查询与标准 SQL 查询中的 WHERE 子句类似。在 SQL 中，我们可能会使用类似如下所示的数据库查询来检索运行 Windows XP 操作系统的所有计算机的列表：
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
使用 SelectNodes 方法时也与此类似：我们希望获取所有 os 属性 (@os) 等于 Windows XP 的计算机的列表。并且为了表明这是一个 WHERE 子句，我们将整个子句都括在方括号内。
注意这种类型的查询被称为 XPath 查询。有关 XPath 的更多信息，请查看 msdn.microsoft.com/library/ms256115.aspx。
如前所述，这虽然有点怪异，但确实有效。如果希望得到属于财务部门的所有计算机的列表应该怎样做呢？小菜一碟；我们可以按照如下方式调用 selectNodes：
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
同样，WHERE 子句包含在方括号中，我们在属性名称 (department) 前面加上符号 (@)，然后指明我们要获取的值。
简单吧？
调用了 selectNodes 方法后，我们只需通过循环返回值的集合并回显 Text 属性即可回显计算机名称，如下所示：
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
我们能够得到哪类信息呢？实际上，我们希望得到类似如下所示的信息：
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
换句话说，它将返回当前运行 Windows XP 的所有计算机的名称。
顺便说一下，这可以并不局限于仅返回计算机名称；因为计算机名称是每个节点的“默认”值，所以这只是我们引用 Text 属性得到的结果。
我们也可以明确指出需要返回哪个属性。例如，看一看修改后的 For Each 循环：
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
如您所见，在此循环中我们仍回显 Text 属性的值；但我们还追加了下面这行代码：
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
在这种情况下，我们使用 getNamedItem 方法来检索 department 属性的值；然后回显该属性的 Text 属性。这就是我们如何指定希望（以及不希望）回显到屏幕上的属性值的方法。（还要注意，我们还加入了 Wscript.Echo 命令，以便在两条记录之间插入一个空行。）当运行此脚本时，我们会得到如下所示的结果：
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
毫无疑问，如果需要，您还可以编写更为复杂的查询。例如，假设您希望获取所有运行 Windows XP 或 Windows Vista 的计算机的列表。在 SQL 中，您可以通过编写 OR 查询来实现。猜到了吗？在查询 XML 文件时，您可以使用完全相同的方法：
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
看明白这段脚本的含义了吗？在一对方括号中，我们提供了两个条件：@os='Windows XP' or @os='Windows Vista'。这样就可以返回类似图 3 所示的报告。
图 3 OR 查询的结果
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
如果仔细检查该 XML 文件，您会发现输出结果中包含运行 Windows XP 或 Windows Vista 的计算机；而运行 Windows Server 2003 或 Windows Server 2008 的计算机却未包含在其中。确实不应该包含它们。
有什么问题吗？您是否希望编写更为严格的查询，比如仅返回属于财务部门且运行 Windows XP 的计算机？正如您猜想的那样，这非常简单；您只需编写类似下面所示的 AND 查询即可：
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
执行后将会返回以下数据集：
atl-ws-002
Finance
为什么报告中只有一个结果？没错：因为财务部门的确只有一台运行 Windows XP 的计算机。
我们希望这些能够帮助大家处理这种特殊类型的 XML 文件。如果还有其他类型的 XML 文件让您给遇上了，那就只能祝您好运了。
因为我们是以一句名言作为本月专栏开场白的，所以我们想引用类似的警句作为本专栏的结束语。我们脚本专家都非常喜欢德皇威廉二世的一句名言，就把它作为结束语吧：“我由此永远放弃对普鲁士王位以及与之伴随而来的德意志帝国王位的主张。”
Scripto 博士的脚本谜题
每月挑战不仅测试您解决谜题的能力，还测试您的脚本编写技能。

2008 年 10 月：VBScript 填充
要解开此谜题，只需在每行填入一个 VBScript 函数名称即可。完成后，通过组合蓝色方框中的字母还会得出另一个函数名称。

答案：
Scripto 博士的脚本谜题
答案：2008 年 10 月：VBScript 填充

脚本专家—Greg Stemp 和 Jean Ross—为 Microsoft 工作。


桌面文件 自定义 Windows 部署服务
Wes Miller

目录
取代现有部署技术
研究堆栈
网络引导程序
WDS PXE 提供程序
TFTP Daemon
引导配置数据存储
Windows PE
传输服务器
自定义多播
结束语
近三个月以来，我一直在讲述 Windows 部署服务 (WDS) — 首先是它的起源，然后是概述，接下来又进一步介绍了它的一些高级主题（如 WDSUtil 和多播）。在本系列的最后一期中，我们将了解在哪里以及如何自定义 WDS 并加以配置以满足组织的需求。大多数 Microsoft 工具都提供了一定程度的可配置性。但是只有当一切都最终敲定后，您才能够真正确定该工具是否满足您的需求，或者还是像通常情形那样，必须根据您的应用场合对其进行一些调整。

取代现有部署技术
最近，我经常被读者问及的一个问题是：“我现在使用的是 x（某种现有部署技术）— WDS 是否适合我，它是否具有与 x 相当的功能？”。对于反对自动部署服务 (ADS) 的用户，他们特别感兴趣的其中一个问题是：“如何才能对服务器快速地执行大规模部署或重新配置操作 — WDS 能做到这一点吗？”
尽管 WDS 的设计目的并非想完全取代 ADS，而且实际上它也缺少成为真正替代品所需的一些关键组件，但通过执行少量操作即可使 WDS 代替 ADS。类似地，如果按原样提供的 WDS 在某些方面不适合您，您可以将它的许多组件替换掉 — 但涉及的复杂程度和工程量则有所不同。让我们看一看如何通过 WDS 进行部署并审视一下可能希望自定义的部分以及如何实现此目的。

研究堆栈
图 1 显示了 WDS 部署过程中的组件。其中的每个步骤都可以进行一定程度的自定义。我对每个步骤都做了彩色编码处理，以反映我所认为的在替换或自定义时的复杂程度（通常指开发技能）。颜色越深，自定义该步骤时可能就越难。
图 1 自定义 WDS 时的复杂性
自定义每个步骤时的困难程度实际上同时取决于团队的技能（开发或脚本编写）和对各种技术的掌握程度，例如 WDS、Windows 映像格式 (WIM)、Active Directory，或者想要集成的任何其他技术（如 SQL 或 ADSI）。让我们审视其中的每个步骤；考虑一下您可能希望用于自定义它们的方式以及将要使用的方法。

网络引导程序
尽管是否有必要创建自定义网络引导程序 (NBP) 来取代 WDS 附带的此类程序还很值得商榷，但确实可以做到这一点。WDS 所包括的 NBP 可用于无头系统（通常为服务器），也可用于那些提示（或不提示）按 F12 的系统。既可以使用 WDSUtil 将这些 NBP 预先设置到 Active Directory 中，也可以在没有预先进行设置的系统中将 Startrom.com 替换为要使用的 NBP（例如，如果所有系统都是无头系统，或者在任何时候您都不希望提示 F12）。
遗憾的是，有关创建自己的 NBP 的文档并不太多（如需更多信息，请参阅 msdn.microsoft.com/library/bb870970.aspx）。NBP 是一个非常小的 16 位可执行文件，它具有严格的限制，且需要特殊的编程技巧。通常都建议使用 WDS 提供的现成 NBP，除非您打算满足一个非常特殊的需求并且开发团队具有相应的技能。

WDS PXE 提供程序
对于远程安装服务 (RIS)，我们从客户处收到的常见反馈是希望使用 Active Directory 以外的其他数据存储来存放客户端系统信息 — 通常是 SQL Server。对于 WDS，其设计包括了一个可插入的基础结构，被用在预引导执行环境 (Pre-Boot eXecution Environment, PXE) 提供程序中。这意味着在经过开发后，可使用 Active Directory 以外的其他后备存储来存放 PXE 信息。
WDS 有的自己的提供程序，它使用 Active Directory；System Center Configuration Manager (SCCM) 现在也可挂接到 WDS 并实现自己的提供程序。有关编写自己的提供程序的文档非常少，而且可用示例代码也不多（尽管 Windows SDK 提供了一些文档和示例），因此任务并不轻松。除非遇到对引导过程有非常特殊的需求的场合，否则我还是建议您不要尝试编写自定义 PXE 提供程序。

TFTP Daemon
有时，在引入 WDS 之前，客户已经投资建立了自己的“普通文件传输协议 Daemon”(TFTPD)。由于 PXE 服务器之间无法有效整合，这通常都意味着最终只会有一个服务器。
根据我的经验，这通常意味着需要利用现有的、通常基于 Linux 的 TFTPD 并借助它来实现对其他操作系统的引导。无法通过 RIS 所使用的原始基础结构来实现这一目标。但是在 RAMDisk 引导成为标准后已可以做到这一点，另外也可以使用基于 WDS 的引导映像来实现。
有一件事必须要清楚，那就是您现在所进入的这个领域已经超出了 Microsoft 提供技术支持的范围，因此您很可能会遇到难以解决的问题。此外，利用 WDS 中增强的 TFTPD，可能会在性能方面受到影响。理想情况下，建议使用现有的 WDS TFTPD 并尝试使用 PXE 超时、预先设置和/或网络边缘来定义哪个客户端从哪个 PXE 服务器进行引导，而不是试图调整现有服务器来适应它。

引导配置数据存储
使用 RIS 时，根本不可能在引导级指定引导目标 — 您必须遍历 OS Chooser 并选择一个选项，例如是否加以设置、Windows PE（Windows 预安装环境）或完全不相关的其他内容。由于 WDS 使用完整加载程序实现网络引导，因此它也支持为客户端提供的自定义引导配置数据 (BCD) 存储。每个体系结构的默认 BCD 都位于 RemoteInstall\Boot\<arch>\Default.bcd 下，其中 <arch> 是所引导系统的特定体系结构。
可针对每个客户端自定义此 BCD，客户端将使用它来进行引导。例如，您可建立一个 BCD 条目用来启动安装，建立另一个用来运行 Windows 恢复环境 (WinRE)，还可以建立第三个用来运行内存测试 — 或者也可以建立一个完全自动化的安装条目作为默认选项，此外再建立一个手动条目（或自定义安装体验）作为用户可选的选项。（如需更多信息，请参阅 "How to Modify the BCD Store Using Bcdedit"，网址为 go.microsoft.com/fwlink/?LinkId=115267）。

当然，WDS 的绝大多数繁重工作都发生在 Windows PE 中 — 因此，调整 Windows PE 以满足您的需求可能是自定义体验需要关注的一个关键领域。默认情况下，WDS 会提供一个非常标准的模板用于安装，其中包括完整的安装体验。有时，这可能并不适合您的部署需求。在这种情况下，您可以创建自己的 Windows PE 引导映像。让我们从头开始。
除了使用 BCD 指出要使用哪个映像外，还可以通过在 Active Directory 中自定义计算机的“机器帐户对象”(MAO) 来指定映像。在 RIS 中，会通过一个特定的 MAO 属性来存储每一项（要使用哪个 Startrom 和 Unattend—SIF—文件）。在 WDS 中，它们以名称-值的形式成对存储在条目 netBootMirrorDataFile 下。例如，给定计算机所使用的引导映像和 Unattend 文件都存储在此条目中。条目的格式是以分号分隔的名称-值形式的列表。用于修改引导映像和 Unattend 文件的条目分别是 BootImage 和 UnattendFilePath。
当然，您也可能会希望彻底舍弃现有的安装体验而构建自己的体验。也许您会需要可配置性和自动化程度更高的版本，或经过 SQL Server 进行自动化处理的版本。您可能希望能像某些客户在早期使用 RIS 和 Windows PE 那样来进行处理，并构建自己的安装前端。无论编写的安装体验具体内容如何，您需要完成的关键任务都包括：
  • 找出所有针对每个机器或每个用户的信息。此信息可从多种渠道获取，例如，从用户输入、SQL Server 或文本文件。
  • 将安装映像复制到客户端系统并加以应用。此任务可通过以下方式完成：直接使用安装、使用 ImageX 应用来自网络共享的映像，或者通过多播（只需通过 ImageX 复制映像并应用即可）。
  • 提供完成安装所需的 Unattend 文件（如 Unattend.xml 或 sysprep.inf，具体取决于要部署的 Windows 版本）。
  • 自动化想要执行的所有安装后迁移步骤（或在部署 Windows Server 2008 时需要应用角色的所有步骤）。
ADS 引入了任务序列的概念，可允许向一台或多台计算机分配可重复的步骤。由于 ADS 并非设计用于或支持 Windows XP，因此无法使用它来部署操作系统。但 ADS 任务序列实际只是结构化的脚本，因此可使用自定义安装过程来执行相同的步骤。
我痴迷于 Microsoft SQL Server 已有很长一段时间了（从 SQL Server 6.5 发布起），因此我本能地想到使用 SQL 来构建此类结构。当然，您需要为此将 SQL 功能添加到 Windows PE 版本中。此外，您还可以编写自己的 GUI — 一个 HTML 应用程序 (HTA) 或经过编译的可执行文件 — 或使用 Windows Script Host (WSH) 来执行非常简洁的仅包含命令行的安装体验。要利用 HTA 或 WSH，也必须将其添加到 Windows PE 中。
在设计自己的安装体验时，其复杂性完全取决于您自身的技能和想象力。我曾看到过仅使用 SQL 和 WSH 或 HTA 定义的相当不错的系统 — 对于某些人来说，这些都是易于获取且较为简单的技能。但是，必须牢记我在之前的专栏中介绍的以下限制：
  • Windows PE 的特点是没有 Windows on Windows (WOW) 子系统，因此必须针对需要支持的每个体系结构分别编译一次。
  • 如果需要通过 x64 或 IA64 Windows PE 进行部署，则无法使用 Visual Basic 6.0。
  • 可使用 Visual Studio 2005 或 2008 构建应用程序，但必须同时构建一个非托管 Visual C++ 应用程序，因为 Windows PE 不支持 Microsoft .NET Framework（所有版本）。
  • 没有 .NET Framework，也无法使用 Windows PowerShell 实现自动化。
如果愿意编写自己的安装体验，您当然也可以通过 WDS 使用第三方映像实用程序。尽管我认为 WIM 格式和 ImageX 已经可以满足绝大多数部署情形，但也可能存在一些现有映像工具更适合您的特定需求。
同样，在某些特定情形下可能需要自定义分区 — 例如使用 BitLocker 部署 Windows Vista，或在另一个卷上构建 Windows XP 系统并存储配置文件数据，也可能是部署 Windows Server 系统并希望在同一磁盘上创建一个单独的卷来记录日志。这些都要求对 DiskPart 进行自动化处理，在之前的版本中，实现方式是将一个脚本（任意文件格式）提供给 DiskPart，其中包含想要执行的命令并以退出命令结束（以退出 DiskPart）。
创建自己的安装体验并非重点所在，因为您基本上重新构建了安装可执行文件（或者至少镜像了它的功能），并且设计和构建工作量相当庞大。但是，它可以确定默认情况下要构建到其中的功能数量以及要在哪里（HTA、WSH 或任何已编译的编程语言）构建它。

传输服务器
如果您不打算使用 WDS 默认提供的大多数功能（如 Active Directory），或您准备自行构建完全自定义的解决方案，传输服务器可以满足您的需求而且不会引入您不需要的需求。图 2 中的表格（摘自 "Using Transport Server"，网址为 go.microsoft.com/fwlink/?LinkID=115298）描述了作为 WDS 传输服务器角色的一部分所包括的内容。
图 2 部署服务器与传输服务器的对比
 | 部署服务器 | 传输服务器
服务器要求 | 环境中需要 Active Directory 域服务 (ADDS)、动态主机配置协议 (DHCP) 和域名系统 (DNS)。 | 环境中不需要其他服务器。
PXE | 支持具有默认 PXE 提供程序的 PXE 引导。 | 未安装 PXE 提供程序，因此必须创建一个自定义 PXE 提供程序。
映像服务器 | 包括 Windows 部署服务映像服务器。 | 不包括 Windows 部署服务映像服务器。
传输方法 | 单播和多播均可。 | 仅允许多播。
管理工具 | 使用 Windows 部署服务 MMC 管理单元或 WDSUTIL 命令行工具进行管理。 | 仅通过 WDSUTIL 命令行工具进行管理。
客户端计算机上的应用程序 | 使用 Windows 部署服务客户端（基本上是 Setup.exe 和支持文件）、Wdsmcast.exe（已包括在 Windows AIK 中）或自定义的多播应用程序。 | 仅使用 Wdsmcast.exe 或自定义的应用程序。
我所说的传输服务器的实现比较复杂，并非是指角色本身难于实现；实际上，它非常容易部署（参见图 3）。需要大量工作的是围绕传输服务器展开的自定义安装实现。大量使用传输服务器角色会导致失去作为角色构建到 WDS 中的大部分易用性。
图 3 传输服务器对自定义部署方案可能非常有用（单击图像可查看大图）

自定义多播
无论是否使用传输服务器角色 — 但主要针对您需要使用时 — 如果要执行多系统部署，使用多播可实现相当不错的效果。ADS 具有非常强大的多播功能，使用具有多播功能的 WDS 也可得到同样的结果。WDS 具有自己的多播方式，但如果您要构建自己的自定义解决方案，可按照我上月所讲述的使用 WDSMCast 来执行多播（参见图 4）。请记住，您需要传输要部署的映像文件，然后还必须应用它们。这通常意味着需要充足的本地磁盘空间来存储和应用映像。
图 4 运行 WDSMCast（单击图像可查看大图）

结束语
WDS 本身已提供了相当多的功能 — 很可能已经足以满足许多组织的需求。但如果您希望构建自己的超越 WDS 界限的自定义解决方案，您也完全可以做到 — 这仅取决于您的想象力、时间安排以及技能。

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


安全观察 再探安全性的十个永恒定律，第 1 部分
Jesper M. Johansson

早在 2000 年，Scott Culp 曾发表了一篇题为“安全性的十个永恒定律”的文章。它是我读过的有关安全性问题的最佳文章之一。他所介绍的信息到现在仍然是所有信息安全工作的基础，如果尚未读过这篇文章，建议您阅读一下（甚至将其打印出来）。在 microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx 可找到它。
人们对该文褒贬不一。有人指摘说，它是 Microsoft 为避免修复那些被视为严重问题的一些漏洞所采取的花招。但也有人认为它是有关安全问题的一篇最基本的文章，并且由于其公认的重要性而被大肆抄袭。但是我却比较推崇那些能够提出自己观点的评价，例如在以下网址发表的见解：edgeblog.net/2006/10-new-immutable-laws-of-it-security。
在这篇文章发表后的八年时间里，安全领域发生了巨大的变化。实际上，在每种主要的蠕虫病毒爆发前用户都会被提请注意。我们已经已经在打一场信息战（对手是有组织的犯罪、政治实体等）。常见语汇表中新增了各种新名词和术语，例如网页仿冒、网址嫁接、僵尸网络、间谍软件和跨站点请求伪造等。我们有运行于 Windows 中的有史以来最为复杂的 rootkit。我们拥有在很大程度上专为解决安全问题而开发的新操作系统，也有对安全问题仍未引起足够重视的其他一些操作系统。
社会工程学已发展成为一个主要威胁。数据侵犯（例如，一家大型零售商泄露了 9400 万个信用卡号码）已成为常见的新闻故事（但人们仍继续在此类商店购物）。美国和英国政府合伙滥用绝大多数西方世界居民的私人信息（可人们仍将私人信息在此类政府中存档）。并且，大量的安全剧场（security theater，意指在没有明显改善安全措施的情况下让用户感到安全的方法）已进入我们的生活，机场的安检就是一例。
我认为现在是需要再来探究一下这些定律的时候了。如果我们看到的所有这些变化都发生在本世纪的最早阶段，我们是否还会宣称这些定律是永恒不变的呢？如果的确是这样 — 如果它们经受住了过去 8 年的考验 — 那么很可能它们也能经受住接下来 10 年的考验。
在这一由三部分内容组成的系列文章中，我将以批判的眼光来审视每条定律。本月我将介绍定律 1 到 3。在下个月的内容中，我将剖析定律 4 到 7。最后一期我将研究定律 8 到 10，并根据自从 2000 年这些定律最初面世以来我们周围所发生的变化，针对看上去合理的想法和观点提供一些佐证。
定律 1：如果攻击者能够设法使您在自己计算机上运行他的程序，那么这台计算机就不再属于您了。
此定律有力地说明了，在计算机上执行的任何软件都可能会控制该计算机。在这条永恒定律第一次出现时，Microsoft 提供的操作系统包括 Windows 98、Windows Me 和 Windows NT 4.0。现在我们有了 Windows Vista 和 Windows Server 2008。
在 Windows 98 和 Windows Me 中，您所执行的任何软件都可以完全控制计算机。Windows NT 4.0 有一个非常可靠的底层安全模型，但如果以“管理员”身份运行它，则在效果上会将其隔离模型降级为 Windows 98 和 Windows Me 的模型。当然您也可以使用非管理员身份运行 Windows NT 4.0，但这样做会非常痛苦，极少有组织会这样做（即使有也是屈指可数的几个）。
假设您就是以非管理员身份运行 Windows NT 4.0 的。那么，在撰写定律 1 时它是否适用？回答是肯定的。首先，Windows NT 4.0 有大量不容忽视的漏洞。例如，存在着一些不够严密的权限，尤其是针对内核对象以及在注册表中。还有许多尚未被发现但专家预期可能会发生的攻击类型。例如，在 1999 年，人们尚未意识到以提升权限的用户身份在交互式桌面上运行进程可能会危及计算机的安全。直到 2002 年，Chris Paget 发表了有关粉碎攻击的白皮书 "Exploiting the Win32 API"，这时大家才意识到这一点 (seclists.org/bugtraq/2002/Aug/0102.html)。
难道在拟定定律 1 时 Microsoft 就预见到了粉碎攻击？不，实际上并非如此。Microsoft 只是意识到一个简单的事实：极少有真正的安全边界可以阻止在计算机上执行的应用程序接管该计算机。
Windows Vista 和 Windows Server 2008 是从 Windows NT 4.0 迁移而来的两代操作系统。它们是否可使定律 1 无效？是否存在具有同样问题的其他操作系统？这要视情况而定。在新操作系统中的确存在更为可靠的安全边界，实际上早在 2000 年出现的一些试验性操作系统中就已经具有了适当的安全边界。然而，此类边界仍为数不多。例如，Microsoft .NET Framework 中的“代码访问安全”就是一个安全边界。它专门设计用于使在沙盒中执行的代码不会影响底层操作系统。
Internet Explorer 中的 Iframes 提供了另一个安全边界。但 Iframes 不会影响对操作系统本身的访问，它只影响网页上不同部分的内容之间的访问。Internet Explorer 中的“保护模式”（如图 1 所示）是操作系统级别的安全边界。它的目的是防止在浏览器中执行的代码影响底层操作系统 — 在没有用户操作的情况下。还有一些其他安全边界（如标准用户帐户），用于防止用户帐户影响底层操作系统或任何其他用户。
图 1 Internet Explorer 7 使用名为“保护模式”的安全边界（单击图像可查看大图）
了解术语“安全边界”的含义极为重要。它并不意味着存在着一个不可侵犯的隔离墙，可以保证提供坚不可摧的、全面的隔离。此术语实际是指软件供应商（例如 Microsoft）要负责提供安全补丁以修复任何违背该边界的行为。软件始终会存在错误，毫无疑问，我们会继续发现更多的违背行为，而软件供应商则需要继续提供补丁。随着时间的推移，他们应改进其软件以在第一时间修复这些漏洞。这可能会被视为定律 1 仍然成立的佐证。
但是，还有另外一个需要考虑的至关重要的内容。您之前可能已经注意到了短语“没有用户操作”。定律 1 实际并非真的与软件的缺陷或漏洞有关。它实际是与人为因素中的漏洞有关！关键短语是“设法使您”。如果攻击者能够设法使您运行他的程序，则他很可能也能设法通过一些伎俩使您在赋予程序提升权限的上下文中这样做。
即使您不具有管理权限也没有关系。作为标准用户，您仍有权访问大量有趣的信息：银行文件、情书、图片、视频以及公司机密数据。所有此类数据都有可能令攻击者感兴趣，并且他们均无需任何提升权限即可读取。对于您所管理的计算机中的信息而言，执行某个恶意程序就相当于将您所有操作权限都移交给了攻击者。因此，如果将“您的计算机”定义为“您所管理的计算机中的数据”，则大可忽略有关权限的任何讨论而直接得出“定律 1 成立”的结论。
即使不对计算机的定义做过细的划分，定律 1 似乎仍然可以经受住时间的考验。定律 1 的目的是为了指出以下事实：作为计算机的操作员，您必须对您在该计算机中运行的软件负责。如果您安装了恶意驱动程序或恶意视频编解码器，则相当于将该计算机的完全控制权转交给了罪犯！
尽管软件供应商可以采取各种措施来避免发生意外的危害（这实际是安全边界的真正意义所在），但有意执行的恶意软件通常会摧毁所有此类保护性措施。这就是除了确保用户无权执行管理任务外，对其进行相关培训也至关重要的原因。因此，可以肯定地说，定律 1 在今天仍然成立，只是计算机的定义可能需要稍做修改。
定律 2：如果攻击者能够更改计算机上的操作系统，那么这台计算机就不再属于您了。
此条定律看似极其简单。很显然，如果攻击者能够更改计算机上的操作系统，那么您将无法再信任这台计算机。但是，随着计算需求的发展演变，操作系统的含义也已发生了变化。许多年前，我为 The Blackwell Encyclopedia of Management 撰写了关于术语“操作系统”的定义 (managementencyclopedia.com)。在定义中描述了操作系统对输入输出设备、硬件及类似设备访问的管理。现在，我手头并没有百科全书，而且原始记载也已不知所终，但我可以肯定的是，我并未提到过操作系统包括纸牌游戏、笔触输入法以及视频代码转换器等内容。
随着计算变得日益复杂，操作系统也需要支持更多的功能。更重要的是，OEM 厂商常常会在其中加入他们自己的附加软件 — 这种附加软件有的还稍微有点作用，但通常都是有百害而无一利。而且，其中有些附加软件会重复已内置到核心操作系统中的功能。
例如，Windows Server 2008 Enterprise Edition 在默认安装时所占磁盘空间超过 5 GB。Windows Vista Ultimate Edition 包括 58,000 多个文件，占用空间超过 10 GB。而且组成操作系统的不仅仅是文件。还有数千个配置设置以及后台程序或服务。
它们都只是操作系统的一部分。它是一个整体术语，包括所有文件、所有配置设置、所有服务，也包括由文件和配置设置创建的所有运行时对象 — 信号、命名管道、RPC 端点等。甚至高度抽象的构造（如系统时间）和特定类型的数据（如事件日志内容）也应被视为操作系统的一部分。
鉴于操作系统的发展演变方式，修改任何此类文件结构是否真的会使计算机不再值得信赖？直接的回答是否定的。例如，Windows Vista 随附了来自 MS-DOS 的旧式行编辑器 edlin.exe。我无法肯定但我愿意以一杯三倍量的摩卡咖啡作为赌注：自 Windows Vista 发布之日起，在所有安装的副本中，edlin.exe 只被调用过两次。这两次都发生在大约三分钟之前我尝试记住其语法的时候。如果有人修改了 edlin.exe 或其他从来没有人使用过的文件，是否真的意味着它不再是您的计算机了？
Edlin.exe 毫无疑问是操作系统的一部分，但如果没人曾经执行过此文件，那么对它的修改会导致计算机受到破坏吗？答案当然是不会。修改并未使用过的操作系统部分并不会使计算机受到破坏。而从未使用过的操作系统部分还有很多。
但是，间接的答案是肯定的。我们不能只通过查看是否有人执行某个文件来判断对它的修改是否可能会导致计算机受到破坏。问题要比这复杂得多。看一下 edlin.exe 的访问控制列表 (ACL)，如图 2 所示。
图 2 edlin.exe 的 ACL 限制非常严格（单击图像可查看大图）
edlin.exe 的 ACL 限制非常严格。只有 TrustedInstaller 服务有权修改这一可执行文件。这一点非常重要：它意味着当攻击者修改计算机上的该文件时，会导致出现间接的影响。修改 edlin.exe 这一行为的确意味着此计算机不再属于您了。恶意用户可以修改 edlin.exe 这一事实是此处的关键所在。如果攻击者可以修改该文件，则他就可以修改任意文件，这意味着您将无法再信任计算机上的任何内容了。
操作系统会保护自己。服务会受到保护以避免遭到未经授权的修改。配置设置会受到保护以避免遭到未经授权的修改。磁盘上的文件会受到保护以避免遭到未经授权的修改。甚至操作系统所使用的信号和 RPC 端点也会受到保护以避免遭到未经授权的修改。如果攻击者可以修改任何此类受保护的对象，则他也就可以修改所有此类对象，并且极有可能他已经这样做了。
这一点至关重要。通过几条永恒定律可知，并非执行某种操作这一行为意味着计算机遭到了破坏。真正重要的只是有人有能力执行某种操作。这是一个需要注意的地方。在涉及计算机安全的每个方面，您都必须始终牢记：真正重要的并不是实际执行了什么操作，而是他能够执行什么操作。
如果计算机向 Internet 敞开大门且数月未打补丁，它是否仍值得信赖？答案是否定的。必须将该计算机视为已遭到破坏。您无法再信任可能已遭到破坏的系统上的任何内容。（五年前，我在文章 "Help!I Got Hacked.Now What Do I Do?" 中说过同样的话，文章的地址为 technet.microsoft.com/library/cc512587）。如果遇到老练的攻击者，受到破坏的系统甚至可能不会显示出任何遭到破坏的迹象。系统可能看起来非常正常。
毫无疑问，定律 2 仍然成立。如果攻击者可以修改计算机上任意受保护的对象，则该计算机将不再属于您了。只需记住，重要的是修改此类对象的能力，而并不是受到实际的攻击。
定律 3：如果攻击者对您的计算机具有无限制物理访问权限，那么这台计算机就不再属于您了。
在 2000 年，此条定律极为重要。许多人并未完全了解对系统具有物理访问权限时都可以做些什么。实际上，即使是应该对此有深刻了解的一些政府机构也并未认识到这一基本要点。当时，在安全指南中建议将“Allow shut down without logon option”（允许在不登录的情况下关机）设为“disabled”（禁用）。这将导致登录屏幕上的“Shut down…”（关机…）按钮变灰。其理论依据是：要关闭计算机，用户必须首先登录以便留下系统关闭人员的审核记录。
其实此观点存在瑕疵。要对登录屏幕上的“Shut down…”（关机…）按钮具有访问权限，您必须实际就坐在控制台旁边。在您坐在控制台旁边的情况下，如果您真的想要关闭计算机，通常可以使用计算机前面的圆形大按钮 — 甚至电源线。系统肯定会关闭。而且没有审核记录。
Windows 2000 包括一个名为“Allow undock without logon”（允许在不登录的情况下移除）的安全设置，此选项在 Windows Vista 中仍可用，如图 3 所示。其原理是相同的。要从基座移除便捷式计算机，必须先登录系统。
图 3 为什么不把计算机和基座一起盗走？（单击图像可查看大图）
此设置的实际安全价值很值得怀疑。我的想法是如果有人可以走近该便捷式计算机并移除它，那么肯定也有人可以轻松地盗走它。现在，虽然我并非曾经盗取过便捷式计算机，但如果我想这样做的话，这一预防措施根本无法阻止我。我可能会将便捷式计算机和基座作为一个整体一起拿走。哎呦，我还盗走了网线和电源线。真是一个毫无意义的安全调整工具！
直到 Petter Nordahl-Hagen 创建了他的 Offline NT Password & Registry Editor，才真正触及有关物理访问的要害。他的作品只是一张 Linux 引导盘，其中包括一个试验性的 NTFS 文件系统驱动程序，可实现对 NTFS 卷的读取和写入访问权限。引导盘上的软件会将注册表安装到本地计算机中，并将管理员帐户的新密码写入 SAM（软件资产管理）配置单元。您需要的只是能够物理访问系统以及一、两分钟的时间。
类似它的这种工具就是最初撰写定律 3 的原因所在。实际上，在许多演示中都使用了 Nordahl-Hagen 的工具。不幸的是，它并未在绝大多数受众中间传播开来。我曾在一些演示中亲自使用过此工具，但由于厌倦了被不断问及“我们如何确保没有用户知道类似工具？”以及“Microsoft 采取了哪些措施来修复这个问题？”，后来就再也没有使用过它。IT 业界的绝大部分人只是不想接受或不想了解物理访问的危险程度要压过所有其他途径这一事实。
在这种环境中，定律 3 非常重要。但是它却遭到批评家们的无情攻击。它被认为是 Microsoft 的伎俩，企图避免修复可能（即使只有一点点）与物理访问相关的所有问题。定律 3 在很多情况下被用来驳回漏洞报告，包括 Offline NT Password & Registry Editor。但是，要阻止对系统具有物理访问权限的攻击者，实际只有一种可能的方法：确保他们无法接触到任何数据。
这是破解定律 3 的可能途径。从定律成文之初，完全磁盘加密技术就已成为一种可行的解决方案。通过使用完全磁盘加密（更准确的说法是“整卷加密”），整个卷（在其他操作系统中被称为分区）均可被加密。因此，如果整个引导卷（换句话说，其中安装有操作系统的卷）被加密，我们想知道的是定律 3 是否仍然成立？
回答是非常有可能。首先，解密密钥必须存储在某个位置。放置密钥（BitLocker 中的默认选项）的最简单位置是计算机中的“受信任的平台模块”芯片。这样做的话，计算机将可以通过无人参与的方式引导。计算机引导完成后，对计算机拥有永久物理控制权限的一些老谋深算且心怀叵测的攻击者可通过多种方式对其实施攻击。由于计算机现在可以连接到任意网络，因此可能会使用与网络相关的方式来攻击系统。
例如，攻击者可能会通过直接内存访问 (DMA) 设备（如 USB 闪存驱动器）来读取或写入内存。计算机开始运行后，如果攻击者对该计算机具有物理访问权限，则后果将不堪设想。
如果密钥未存储在该计算机中，则攻击将取决于攻击者能否获取或猜出密钥。如果使用 PIN 码来引导计算机，则攻击者可能会比较轻松地猜出此代码。如果密钥存储在单独的硬件设备中（如 USB 闪存驱动器或一次性密码链）或由其派生而成，则攻击者必须对该独立设备具有访问权限。肯定有方法可以获取这些密钥，或使那些对密钥具有访问权限的人感到非常不便，尽管可能要颇费一番周折。
您也可以通过一种略微不同的方式来解释定律 3：“如果攻击者对您的计算机具有物理访问权限，可能此计算机已经被盗，因此不太可能再将其拿回来。”从这个角度看，这台计算机实际上已不再属于您了。而且，从这个角度来看，对于攻击者而言，能否访问计算机上的数据也无关紧要。但是这实际并非定律 3 的实质所在。它意味着攻击者可以访问计算机中的数据，而非得到计算机本身。
综上所述，定律 3 的确仍然成立。毋庸讳言，当今的一些技术在阻止具有物理访问权限的攻击者方面已经取得了明显的成效，并因而最大程度降低了能够访问采用了安全措施的计算机上的数据的攻击者数量。也就是说，攻击者所具有的能力始终决定着攻击者实际可以攻击的程度，最新的技术解决了 10 个永恒定律中的多个定律所提出的问题（在一定程度上）。但是，物理访问仍提供了进入系统的方法（尽管较为复杂）。
就目前而言，安全性永恒定律被证明非常具有适应性，无论是对于技术进步还是对于时间考验而言。在前 3 个定律中，定律 3 最不稳定，不过即使这样它在许多情况下也仍然成立。但是，它是具有最易获取且最可靠的缓解方案的定律。在接下来的两期《TechNet 杂志》中，我将继续本次讨论，看一看定律 4 到 10 是否仍然成立。

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


领域备注 高容量彩色条形码
Gavin Jancke

我们都非常熟悉条形码，虽然它们一点也不引人注目，但在日常生活中却无处不在，从食品包装到发货标签，到处都能看到条形码的身影。条形码最初是在 1974 年出现在零售业中，当时是由宽度可变的一维竖直条组成，其中可存储 12 位数字。八十年代后期，条形码逐渐发展成为计算能力得到大幅提高的二维黑白条形码（矩阵码），其数据密度从只有几位数字增加到数百个字节。
2003 年，我开始着手 Microsoft Research 的生物防伪身份证项目。我不但需要存储加密文本（如姓名和年龄），还需要存储指纹或虹膜扫描样板。对于现有的黑白条形码而言，要存储所有这些必要数据，其尺寸将会比身份证本身还要大，因此显然需要采用一种新方法。
我必须决定如何在每个符号中存储多位信息，以符合二维黑白条形码的标准。通过采用彩色而非黑白，即可增加存储的数据位数，四种颜色可增加两位，而八种可增加三位。
此外，我还对符号形状进行了试验，以查看在扫描时不影响注册效果的情况下，其排列是否还能更紧凑一些。最初使用的六边形看起来非常不错，但这种形状混合在一起后，计算机将无法清晰识别。
最终我决定使用三角形，因为在紧凑空间中巧妙交织的同时，它们仍然可以保持其特有的形状。通过使用多行多种颜色的三角形，可将密度容量增加到三维。
另外，还有许多不确定因素需要解决。在处理颜色时面临的其中一个最大问题是打印规格和光照条件的变化。虽然肉眼可以轻松地分辨各种颜色（至少对那些非色盲的人来说），但对计算机而言却并非如此。
我采用了数种不同的方法来确保软件能准确读取颜色。我在条形码中创建了一个小到几乎无法发现的调色板，其中包含了存在于实际条形码中的基准色。这将提供一种定标机制，可准确指定构成某种特殊颜色（例如红色）的信息。我还尝试了一些更高级的技术，如自定义简化颜色分类算法，它可以利用颜色空间理论将颜色分为不同的集合。这两种方法都很有效，而且可以互为补充。
此项目的目标之一是编写一段用手机读取条形码的程序。说到手机，人们首先会想到光照不足、聚焦不准、焦距镜头不可变等特点。一个更为严峻的挑战是如何使用基于整数的、运行速度相对缓慢的手机 CPU 来处理本该通过计算机视觉完成的工作，为此团队需要提出某种可靠的理论，以解决如何利用尽可能少的像素来检测图像中的条形码的问题。扫描过程需要在某一读取质量范围内都能工作，如从清晰明亮的 LCD 面板到亮度较低、聚焦不准的实际印刷品。
最终算法在解码条形码图像时，实时照相机视频帧要快于实际帧速率 — 使用 200Mhz 的 CPU 时大约快 10 毫秒。在条形码图像中，可以被检测到的最小数据负载是单位面积像素数至少为 45 个。
在各种不同情况下对此工作进行测试验证花费了两年多的时间。此技术现已授权给第三方，今年晚些时候，利用此技术开发的一些激动人心的应用程序将会面世。
Gavin Jancke 是 Microsoft Research 的工程主管，负责运营高级开发小组和 Web 体验团队。以前他曾是 SQL Server 的产品支持工程师、软件工程师，并且曾担任过比尔·盖茨的执行技术咨询人员。


Windows 机密 苦干，非巧干
Raymond Chen

对于软件开发人员，Windows 错误报告的最大优势之一是它能提供有关其程序故障根源的实际信息。任何已在 winqual.microsoft.com 在线注册的软件供应商都可以使用这些错误报告。当然，您可以在实验室运行所有类型的测试，但实验室情况与实际情况之间始终存在着鸿沟。这可能会导致一些错误在您的测试中始终没有出现，但会把您的客户搞得焦头烂额。
几年前有一位程序员向我讲述了这样一个故事，其产品的可靠性团队为其分配了一项任务。团队想解决某个特定组件中导致崩溃和挂起的主要原因。经过一些协商后，双方同意力图将此类故障数量减少为原来的一半。他们想修复至少对该组件 50% 的崩溃和挂起负责的错误（通过 Windows 错误报告测度）。
我们都知道故障并不是均匀分布的。有一些故障非常罕见，一些则很常见，还有一些非常猖獗（相对而言）。工程就是一场权衡游戏；如果资源（时间、金钱和技术力量）有限，您必须将您的资源用在它们能发挥出最大作用的地方。由于现在的目标是减少崩溃和挂起的次数，因此明智的方法是研究 Windows 错误报告所报告的最常见故障，了解根源，然后尝试修复这些常见故障。
Windows 错误报告提供有关程序故障的实际信息（单击图像可查看大图）
当程序员研究故障数据时，发现在所报告的错误中，有五个特定的崩溃和挂起占总数的 60% 以上。如果程序员可以修复导致这五个故障的错误，他便可将崩溃和挂起次数减少到原来的五分之二（优于我们的目标值二分之一）。
Microsoft 自身的 Windows 错误报告数据的分析显示：帕拉图原理是解决 Windows 崩溃和挂起的一个绝好经验法则；约有 20% 的错误导致 80% 的故障。这一研究还揭示了一个更令人惊讶的结果：仅 1% 的错误便导致了 50% 的故障。并不是所有错误都是均等的，但了解这种分布的不均匀程度会非常令人大开眼界。
在更加仔细地对这五个故障进行研究之后，程序员发现这些故障都来自同一个根源。崩溃和挂起只是同一基本错误的不同表现。因此他与一些质量保证人员共同开发并测试了修复程序，并在下一个补丁中加入了这一修复程序。有了这一错误修复，该组件的理论失败率立刻减少为原来的五分之二。通过这一相当简单的代码他成功完成了修复。
当我听到这个故事时，我对该组件的错误分布曲线比 Windows 的更加突兀倍感惊讶。几乎一半以上的崩溃和挂起是由一个错误导致的。如果没有诸如 Windows 错误报告这类工具所收集的数据，您是无法在代码中获知这些信息的。
您可能会认为这么快便达到了其目标会令可靠性团队非常兴奋。仅在两周之内通过一次修复便超出了约定的目标。但是他们却非常生气。
“这真让人无法接受，我们预计这要用两个月的时间。这太简单了！”很明显，他们想让程序员埋头苦干，而不是巧干。
Raymond Chen 的网站“The Old New Thing”及同名著作均讲述了 Windows 的发展史及 Win32 编程。他衣服中的 20% 为洗衣房带去了 80% 的工作量。