桌面文件自定义 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 部署服务器与传输服务器的对比

我所说的传输服务器的实现比较复杂，并非是指角色本身难于实现；实际上，它非常容易部署（参见图 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 联系。