桌面文件自定义 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 联系。