| 离之前写SID在VDI场景下的介绍已经很久远了。在那之后我们共同经历了疫情的挑战，也越发显示出支持远程工作的重要性。这场至今仍未平复的灾难，彻底地改变了很多事情，包括我们今后的工作方式。 |
|---|
| 很荣幸参与到不同此类项目中，也想把一些经验记录下来，让这些工作更有价值。才发现博客现在可以加封面了。考虑到克隆这个词，也出于对《人潮汹涌》和华仔的喜爱，挑了一张海报。图片版权和肖像权归权利方所有，如有侵权，请通知删除。 |
尽管我们在 聊聊VDI虚拟桌面的重复SID问题（上）和聊聊VDI虚拟桌面的重复SID问题（下）中探讨了重新生成SID在链接克隆和即时克隆、流式制备中不再重要，但我在很多VDI项目中发现，仍有很多用户由于技术储备、管理认知等原因，不得不使用全克隆方式、按照传统PC的管理方式去管理VDI桌面的情况。
容我偷偷地告诉你，VDI项目里，全克隆其实也不需要进行SID的处理。
但在这些场景中，用户仍会延续之前需要刷新SID的认知和习惯。尽管不建议延续使用PCLM方式（例如SCCM等）管理VDI的桌面系统，但如果VDI架构中存在遗留的管理体系，那么还是需要考虑SID的问题的。
在一些项目里，最近也出现了不少由于自定义过程失败导致桌面池无法完成制备的问题。所以我产生了小结一下系统自定义工作的想法。既然这个步骤看上去历史久远了，不妨就叫前传吧。
克隆人的进攻
既然我们需要快速复制大量的Windows系统提供给用户使用，那么按照Windows的规范进行这一过程就非常必要。从一个安装镜像到最终批量部署，会经历如图的流程。
整个系统自定义过程其实分为两部分，第一部分是“通用化”，这部分最复杂，也最容易出问题。第二步是“定制化”，相对简单。接下来就分别逐个环节开聊。
通用化（Generalize）
自定义过程实际是为了解决批量化、标准化部署Windows系统的问题。毕竟没有人愿意一台一台安装Windows系统、安装软件和配置。为了实现这个目标，就需要完成上述安装配置之后，对Windows系统进行捕获（Captrue）。捕获其实是使用工具对系统进行复制和保存，可以使用推荐的自带工具DISM，有时也会用历史悠久的方式例如Ghost。为了让捕获的镜像能够在其他不同硬件配置的设备上运行，也为了抹除安装导致的系统特征信息，需要在捕获之前，对系统做“通用化”处理。而在Windows系统上完成这一工作的，就是Sysprep（系统准备）工具。
标准的Sysprep工作流程是：使用Sysprep将PC配置为审核模式（Audit Mode），重启后进行软件的安装和配置以及系统的更改和更新，但应用商店应用除外。完成后，运行Sysprep勾选“通用化”之后关机，也可使用命令行。如果打算以“全新系统”的形式提供给用户，可以勾选开箱即用体验（OOBE）。
审核模式（Audit Mode）
审核模式会将安装配置阶段登录的本地管理账户及其配置文件自动删除，因此特别适合工厂出厂前准备“干净”的系统给客户，当然比较有经验的IT部门也可以照此办理。工程师们经常跳过审核模式进行系统的准备，看上去常常也没有什么问题，但出现问题时不妨按照微软建议的流程操作。
审核模式和OOBE有三种方式进入：使用安装应答文件、在OOBE或Audit Mode屏幕按Ctrl+Shift+F3和使用Sysprep工具。有关介绍详见：https://v.gd/M838zM
Sysprep过程
了解Sysprep的功能对理解系统通用化及定制化流程非常重要，毕竟这个过程发生的变化对于管理员是不可见的。Sysprep主要提供以下功能：
-
从 Windows 映像删除PC特定的信息，包括PC的安全标识符 (SID) 。 这允许捕获映像并将其应用于其他PC。 这称为 "通用化电脑"。
-
从 Windows 映像中卸载PC特定驱动程序。（包括虚拟驱动程序）
-
通过将电脑设置为启动到 OOBE，使电脑准备好交付给客户。
-
允许你向现有安装添加应答文件 (无人参与的) 设置。完成“定制化”。
Sysprep运行历经如下过程：
-
验证执行。会检测是否具备运行条件，例如是否为本地管理员，是否存在未完成的标志（这在后面将排错时很重要）。Sysprep必须对应Windows版本且一次只能运行一个实例。
-
日志初始化。查看日志是重要的排错手段，不同Sysprep操作会产生不同的日志。
-
分析命令行参数。GUI方式逐步退出，命令行是推荐的做法。
-
执行操作。通过日志可以看到这个阶段会调用需要的DLL和EXE完成操作。
-
验证操作。确认所有步骤完成并最终关闭或重启系统。
即使需要通过通用化去除硬件清单，在目标计算机上部署Sysprep之后的镜像依然需要添加所有可能用到的驱动程序。对于虚拟化场景，虽然我暂时没有找到确切的文档，但猜测需要额外的步骤来完成支持虚拟化的准备过程。
我在很多年前还做终端管理项目，例如System Center的OSD/MDT的时候，积累了一个记忆，就是Sysprep在同一个Widnows安装上只能执行3次。所以当年不得不精心规划维护一个镜像树，以使得枝桠不超过三层。但现在这个数字已经被改到了1001。所以大部分情况底下，放心大胆的运行吧。
| 操作系统版本 | Sysprep 计数限制 |
|---|---|
| Windows 8.1 和 Windows Server 2012 或更高版本 | 1001 |
| Windows 7 和 Windows Server 2008 R2 | 3 |
| Windows Server 2008 | 3 |
与时代变迁有关的另一个点在于Microsoft Store应用。比较奇怪的一个逻辑就是，在通用化之前如果安装或更新了Microsoft Store应用，Sysprep会失败。
应答文件（Anwser Files）
我们需要跳过让用户输入本地管理员账户和密码，以及实现自动加入域的操作。因此，要使用应答文件来实现Sysprep之后自动化的配置工作。
如果没有缓存应答文件，需要在Sysprep命令行中指定/unattend: *<file_name >* 选项指定单独的 Unattend.xml 文件。
应答文件是一个有结构和格式规范的XML文件。在后续会结合例子来介绍。
以上对Sysprep做了简短的小结，更多有关介绍详见：https://v.gd/T32VkK
服务器角色的Sysprep支持
尽管写这几篇的初衷是探讨VDI架构的Windows系统，也顺手给Windows Server系统带上几句吧。由于服务器运行是很多角色是有状态的（即，配置或数据在不同时刻是不同的，并且无法通过简单的复制进行服务的恢复），因此当服务器运行一些角色，例如：活动目录AD的服务角色、WSUS服务角色、WDS服务角色等等。
限于篇幅，Sysprep就先聊到这里，打算在下一篇介绍vSphere是如何去做自定义过程的。
