Win10到Win11组件化部署：用DISM与无人值守定制专属镜像

系统部署从 Windows 10 过渡到 Windows 11 之后，最容易踩的坑不是 ISO 下载不下来，而是每个人拿到手的系统都不一样：有人装完自带一堆游戏组件，有人一打开资源管理器就是 OneDrive 引导页，还有人升级之后右键菜单变成了两段式。真正要解决的问题不是在装机完成后反复卸载，而是把组件选择提前到部署阶段。所谓开源系统部署，并不是让 Windows 变成开源操作系统，而是让镜像定制、组件清单、无人值守安装和后续运维脚本形成一套可审计、可重复执行的自动化流程。下面围绕“Win10 到 Win11 组件自己选”这条主线，讲清楚如何用开源部署脚本配合微软官方 DISM、Windows PE 和无人值守应答文件，做出一份只保留自己需要的组件的部署镜像。

1. 先理清 Win10 到 Win11 后部署思路为什么必须改

在 Win10 时代，很多团队的部署模式还是“装一台母机，装完软件，清理垃圾，最后封装成镜像再复制”。这套流程可以跑，但到了 Win11 会明显变重：系统更新频率更高，预装应用更多，硬件检查更严，默认 UI 改动更大。与其继续维护一个越来越大的黄金镜像，不如把“组件选择”变成部署过程中的一个显式输入。

1.1 传统“封装完就拷”的模式在 Win11 上更难维护

传统封装流程有一个典型问题：母机上安装过的应用、用户配置、临时文件都会进入镜像。哪怕封装前做了清理，仍然可能在后续使用中暴露问题，比如某个驱动不兼容、某个预装应用在用户首次登录时自动启动、某个商店应用因为许可证问题反复报错。

Win11 的组件模型和 Win10 类似，但预装内容更多，系统自身的模块化程度也更高。纯粹靠“装完后卸载”来清理组件，很容易出现以下情况：

• 预装应用只为当前用户卸载了，新建用户时又自动安装回来。
• 组件之间存在依赖，卸载一个应用后，系统设置面板出现空白。
• Windows 更新推送新版本后，之前手动删掉的应用被重新补充。
• 镜像体积没有明显下降，因为组件数据还残留在 WinSxS 目录中。

这些问题的根源不是卸载操作本身，而是没有在部署阶段，也就是把镜像应用到磁盘之前，就完成组件筛选。

1.2 组件化部署的核心：清单驱动

组件化部署的思路是把“要安装什么、不要安装什么”写成一个清单，然后由脚本去读取清单并修改镜像。清单可以是一个 YAML 文件、JSON 文件，也可以是一系列 PowerShell 脚本。

一个常见的组件清单结构如下：

# components.yml apps_to_remove: - Microsoft.XboxGamingOverlay_8wekyb3d8bbwe - Microsoft.MicrosoftSolitaireCollection_8wekyb3d8bbwe - Microsoft.WindowsFeedbackHub_8wekyb3d8bbwe features_to_keep: - NetFx3 - Windows-Defender-ApplicationGuard oobe: hide_eula: true skip_machine_oobe: true

这份清单的价值在于可审计。团队成员可以 review 谁删了什么组件，可以回滚某一次调整，也可以在 Win10 镜像和 Win11 镜像之间复用同一套筛选逻辑。只要包名、功能名相同，脚本基本不用改。

1.3 Win11 比 Win10 多出来的部署约束

Win11 部署除了“组件选哪些”之外，还多了几个硬性前置条件。部署脚本如果不处理这些条件，镜像做得再干净也可能装不进去。

维度	Win10 传统部署	Win11 组件化部署
固件模式	Legacy BIOS 仍常见	推荐 UEFI，部分环境要求 UEFI
安全启动	可选	默认要求开启 Secure Boot
TPM	无强制要求	通常需要 TPM 2.0
硬件支持	老 CPU 仍能装	CPU 支持列表更严格
预装应用	较多但可控	更多且与系统模块耦合更深
右键菜单	传统菜单	默认紧凑菜单，可用注册表调整
部署工具	DISM、Ghost、第三方封装	DISM、Windows PE、自动应答为主

这里不建议为了绕过 Win11 硬件检查去强行修改安装镜像。测试机可以临时关闭检查，生产环境应该直接按 Win11 官方要求准备硬件，否则后续每月质量更新和驱动推送都可能出问题。

2. 准备好工作机、WinPE 和 ISO 源镜像

组件化部署需要在“干净”的环境中制作镜像。所谓干净，不是说必须在无网络的隔离电脑上操作，而是说工作机本身不要装一堆乱七八糟的软件，以免影响判断。更重要的是，源镜像必须来自官方渠道，不能拿来路不明的精简版再继续裁剪。

2.1 工作机需要准备的软件和硬件

制作 Windows 10 到 Win11 的自定义部署镜像，常见的环境要求如下表。

项目	要求	说明
操作系统	Windows 10 或 Windows 11 64 位	工作机用于运行 DISM 和部署脚本
管理员权限	必须	DISM 挂载镜像和修改组件都需要管理员命令行
官方 ISO	Win10 或 Win11 对应版本	从微软官网下载，记录文件哈希值
Windows ADK	最新版	提供部署工具和 Windows PE 生成能力
WinPE 加载项	与 ADK 版本一致	用于生成 WinPE 启动镜像
磁盘空间	至少 40 GB 空闲	挂载镜像、导出 WIM、生成 WinPE 都会占空间
测试虚拟机	VMware/VirtualBox/Hyper-V 均可	任何镜像修改都要先在小范围验证

需要注意，ADK 和 WinPE 加载项都是微软官方免费工具，版本要和目标系统版本匹配。如果工作机是 Win11，但目标镜像还要维护 Win10，建议保留两个版本的部署工具目录，避免环境变量冲突。

2.2 目录结构先约定好

制作镜像的目录结构不需要多复杂，但一定要稳定。推荐按下面这种方式组织：

D:\Deploy ├── Config │ └── components.yml ├── ISO │ └── 原版镜像文件.iso ├── WIM │ └── install.wim ├── Mount │ └── 挂载目录 ├── Drivers │ └── 按厂商分子目录存放驱动 ├── Logs │ └── 所有命令输出和错误日志 └── WinPE └── WinPE.iso

这样做的好处是：脚本里的路径是固定的，日志不会散落得到处都是，驱动目录可以按机型分批放入，不会污染源镜像。开源部署项目里的脚本也大多采用类似约定，你把它当成模板走即可。

2.3 从 ISO 中提取可挂载的 install.wim

官方 ISO 里的sources目录下通常有两个候选文件：install.wim或install.esd。DISM 可以读取 WIM 和 ESD，但通常只能挂载 WIM。如果源 ISO 中是 ESD，需要先导出成 WIM 再挂载。

先查看镜像信息：

dism /Get-WimInfo /WimFile:D:\ISO\sources\install.wim

如果这个文件不存在，说明 ISO 里可能只有install.esd，可以切换路径重新查看：

dism /Get-WimInfo /WimFile:D:\ISO\sources\install.esd

拿到索引号之后，把 ESD 导出为 WIM：

dism /Export-Image /SourceImageFile:D:\ISO\sources\install.esd /SourceIndex:1 /DestinationImageFile:D:\Deploy\WIM\install.wim /Compress:max /CheckIntegrity

导出完成后，再用dism /Get-WimInfo检查install.wim里的索引和版本信息。这一步不要省略，因为后续所有组件操作都要指定索引号，选错索引会改到错误的系统版本。

注意：源镜像的哈希值必须记录下来。Windows 11 镜像版本更新频繁，同一个版本号在不同渠道下载，内容也可能有差异。没有原始镜像作为基准，后续排查组件问题时很难定位到底是哪一步出了问题。

3. 用 DISM 挂载镜像并精确选择需要保留的组件

镜像定制的主战场是 DISM。DISM 能完成挂载、查看包、删除预装应用、卸载镜像等操作。所有修改都发生在“离线镜像”上，也就是还没有安装到硬盘的 WIM 文件，所以即使改坏了，重新挂载原始 WIM 就能恢复。

3.1 挂载镜像并确认源索引

以管理员身份打开命令行，创建挂载目录并挂载 WIM：

mkdir C:\Mount dism /Mount-Wim /WimFile:D:\Deploy\WIM\install.wim /Index:1 /MountDir:C:\Mount

挂载成功后会看到“正在操作”和“操作成功完成”的提示。此时不要直接关掉命令行，后续所有组件操作都要在这个挂载目录上进行。

在实际部署中，建议把命令输出同时保存到日志文件：

dism /Mount-Wim /WimFile:D:\Deploy\WIM\install.wim /Index:1 /MountDir:C:\Mount > D:\Deploy\Logs\mount.log 2>&1

日志文件看起来不起眼，但一旦镜像做出来之后出现奇怪问题，你可以靠它判断是挂载阶段失败还是组件删除阶段失败。

3.2 查看预装应用包和系统包

组合键Win + R打开“运行”，输入winver只能看到系统版本，看不到预装应用。要看镜像里面到底装了什么，需要分别导出两份清单。

查看预装 Appx 应用：

dism /Image:C:\Mount /Get-ProvisionedAppxPackages > D:\Deploy\Logs\appx.txt

查看系统包：

dism /Image:C:\Mount /Get-Packages > D:\Deploy\Logs\packages.txt

打开appx.txt，你会看到大量以Microsoft.开头的包名，例如 Xbox Game Bar、OneDrive、Windows 资讯、反馈中心等。这些包名看起来很长，但删除时要用完整PackageName，不能只写简写。

PackageName : Microsoft.XboxGamingOverlay_8wekyb3d8bbwe DisplayName : Xbox Game Bar

3.3 执行组件删除操作

对于不需要的预装应用，使用下面的命令从镜像中删除预置：

dism /Image:C:\Mount /Remove-ProvisionedAppxPackage /PackageName:"Microsoft.XboxGamingOverlay_8wekyb3d8bbwe"

一次只能传一个包名，因此更实用的做法是写一个 PowerShell 脚本，从apps_to_remove.txt中逐行读取包名并执行删除：

$apps = Get-Content "D:\Deploy\Config\apps_to_remove.txt" foreach ($app in $apps) { if ($app -and -not $app.StartsWith("#")) { dism /Image:C:\Mount /Remove-ProvisionedAppxPackage /PackageName:"$app" } }

这里要注意一个关键区别：

• /Remove-ProvisionedAppxPackage删除的是系统镜像中为“新用户预置”的应用。
• 如果只删当前用户的 Appx，新建用户后应用会重新出现。
• 如果只删预置包，已经存在的用户配置文件里可能还有残留。

在离线镜像阶段删除预置包，是相对干净的做法。它不会影响当前用户数据，因为当前用户数据还不存在。

系统包不建议随意删除。尤其是下面几类：

• Microsoft-Windows-*核心系统组件
• 语言包和字体包
• .NET 相关的NetFx*包
• Windows 恢复环境WinRE相关包
• 带有Foundation或Core字样的包

这些组件之间存在大量隐式依赖，删掉后不一定立刻报错，但系统更新、功能启用、故障转移恢复时往往会出问题。普通办公场景真正需要清理的通常只有预装应用和可选功能，而不是系统包。

3.4 清理并卸载镜像

组件删除之后，可以尝试清理 WinSxS 组件存储，减少镜像体积：

dism /Image:C:\Mount /Cleanup-Image /StartComponentCleanup

需要说明的是，离线清理能否执行取决于目标镜像版本和当前 DISM 版本。如果命令提示当前环境不支持，直接跳过并提交修改即可，不用在这个阶段死磕。

确认所有修改完成后卸载镜像并提交：

dism /Unmount-Wim /MountDir:C:\Mount /Commit

提交之后，install.wim已经变成了修改后的版本。建议把原始install.wim先备份一份，避免后续改坏后还要重新下载 ISO。

4. 让安装过程自己选择组件：无人值守应答文件

组件清理解决的是“不要什么”，无人值守应答文件解决的是“安装过程中每个步骤选什么”。Win10 和 Win11 的 Windows 安装程序都会读取名为unattend.xml或autounattend.xml的应答文件，通过它自动选择语言、分区、用户账户和隐私选项。

4.1 应答文件与组件选择的分工

组件选择发生在镜像离线修改阶段，应答文件发生在安装程序读取镜像后的配置阶段。两者不在同一时间生效：

工作内容	处理时机	使用工具
删除预装应用	启动 U 盘安装系统之前	DISM 离线镜像
保留可选功能	镜像挂载阶段	DISM / Get-WindowsOptionalFeature
自动选择语言	Windows PE 阶段	unattend.xml
跳过 OOBE 引导	specialize / oobeSystem 阶段	unattend.xml
创建本地账户	oobeSystem 阶段	unattend.xml
右键菜单样式	首次登录后	注册表命令或部署脚本

如果只做组件删除，可以把所有精力放在 DISM 上。但如果要形成完整部署方案，就必须把应答文件一起做掉。

4.2 最小 autounattend.xml 示例

下面是一份用于说明结构的autounattend.xml片段。它覆盖了 Windows PE 阶段的语言设置，以及 specialize 阶段的计算机名设置：

<?xml version="1.0" encoding="utf-8"?> <unattend xmlns="urn:schemas-microsoft-com:unattend"> <settings pass="windowsPE"> <component name="Microsoft-Windows-International-Core-WinPE" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SetupUILanguage> <UILanguage>zh-CN</UILanguage> </SetupUILanguage> <InputLocale>zh-CN</InputLocale> <SystemLocale>zh-CN</SystemLocale> <UILanguage>zh-CN</UILanguage> </component> </settings> <settings pass="specialize"> <component name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <ComputerName>DESKTOP-OPEN</ComputerName> <CopyProfile>true</CopyProfile> <RegisteredOwner>IT</RegisteredOwner> </component> </settings> </unattend>

把文件命名为autounattend.xml放到启动 U 盘根目录，Windows 安装程序会在启动后自动读取。这个文件里最容易被忽略的是processorArchitecture和publicKeyToken，它们必须与目标系统架构一致。如果你的目标系统是 arm64，就不能复用 amd64 的内容。

4.3 组件选择后的体验调整

Win11 安装完成后，很多人第一个想改的就是右键菜单。把 Win11 右键菜单改回 Win10 风格，本质上是注册表增加一个 CLSID 屏蔽项：

reg add "HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32" /ve /d "" /f taskkill /f /im explorer.exe start explorer.exe

但这属于个人偏好，不适合作为标准镜像里的强制配置。如果你负责维护企业镜像，更推荐把注册表调整放在首次登录的后置脚本中，并且通过组策略统一管理，不要直接写死在无人值守文件里。

5. 在 WinPE 里灌镜像并完成首次启动验证

镜像定制完成后，需要用 WinPE 启动到内存环境，然后执行分区、灌镜像、写引导三个动作。WinPE 的好处是它可以脱离系统盘运行，允许你对硬盘做完全清理，然后把自定义 WIM 完整部署到目标分区。

5.1 生成 WinPE 启动镜像

安装好 Windows ADK 和 WinPE 加载项后，在管理员命令行中进入部署工具目录：

cd "C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools"

执行环境初始化脚本，然后生成 WinPE 工作目录：

DandISetEnv.bat copype amd64 C:\WinPE

生成 WinPE ISO：

MakeWinPEMedia /ISO C:\WinPE C:\Deploy\WinPE.iso

如果你打算从 U 盘启动，也可以用MakeWinPEMedia /USB直接写入 U 盘。生产环境建议保留一份 WinPE ISO 存档，因为后续补充驱动、修复引导都需要用到。

5.2 分区、灌镜像、写引导

从 WinPE 启动后，打开命令提示符，先用diskpart把磁盘转成 GPT 并创建 UEFI 所需分区：

diskpart select disk 0 clean convert gpt create partition efi size=300 format quick fs=fat32 label="EFI" assign letter=S create partition msr size=16 create partition primary format quick fs=ntfs label="Windows" assign letter=C exit

这里解释了每个分区的用途：EFI 分区存放启动管理器，MSR 是微软保留分区，主分区安装系统。分区完成后，应用自定义 WIM：

dism /Apply-Image /ImageFile:D:\Deploy\WIM\install.wim /Index:1 /ApplyDir:C:\

应用完成后执行启动引导修复：

bcdboot C:\Windows /s S: /f UEFI

执行完bcdboot之后，检查一下S:\EFI\Boot和S:\EFI\Microsoft\Boot目录是否生成。如果只有磁盘分区，没有引导文件，重启后大概率会进入不了系统。

5.3 首次启动后要验证什么

系统装好进入桌面之后，不能只看“能开机”就结束。需要按下面这些维度逐项验证：

验证项	检查方式	预期结果
预装应用	Get-AppxPackage	不应出现清单里删除的应用
可选功能	Get-WindowsOptionalFeature -Online	保留的功能状态符合预期
系统版本	winver	与源镜像版本一致
更新服务	检查 Windows Update 设置	可正常查询更新，不报组件错误
系统日志	eventvwr.msc查看系统日志	无大量组件缺失相关错误
安全引导	msinfo32	TPM、Secure Boot 状态正常

在测试虚拟机里完成这一轮检查后，再在实体机上做小规模试点。不要一开始就在大量办公机器上批量部署。

6. 部署后常见故障：现象、原因、排查路径

组件化部署最容易出问题的阶段不是制作镜像，而是部署之后的第一周。下面梳理四条高频故障路径，每条都按“现象、可能原因、检查方式、处理建议”展开。

6.1 系统无法引导

现象：重启后黑屏，或提示找不到操作系统。

可能原因主要有三类：

• 分区表不是 GPT，而是 MBR。
• EFI 分区没有分配引导文件。
• 镜像应用目标分区和启动分区不对应。

排查方式：

diskpart list disk select disk 0 detail partition exit

通过detail partition查看 EFI 分区是否存在，再执行一次bcdboot重建引导：

bcdboot C:\Windows /s S: /f UEFI

如果仍然无法引导，查看 UEFI BIOS 里是否选择了正确启动项。很多情况下不是引导文件缺失，而是 BIOS 启动顺序里把 U 盘排到了硬盘前面，导致重启后再次进入 WinPE。

6.2 预装应用“删了又回来”

现象：系统首次登录时，Xbox Game Bar、OneDrive 等应用仍然出现。

可能原因：

• 删除的是当前用户的应用，而不是预置包。
• 删除预置包之后，没有提交 WIM 镜像。
• 系统安装过程中使用在线账户，商店应用被同步。

检查方式：

Get-AppxProvisionedPackage -Online | Select-Object PackageName

如果这里还能看到已删除应用，说明镜像里的预置包没有被移除干净。如果这里没有，但当前用户有该应用，可以在测试机新建一个本地账户检查是否复现。新建账户没有再出现，说明之前是旧账户缓存导致。

6.3 Win11 升级后被 TPM 和 Secure Boot 拦下

现象：镜像能部署，但在 Win11 升级检查时提示硬件不满足要求。

可能原因：

• 目标机器确实没有 TPM 2.0。
• BIOS 里 TPM 处于禁用状态。
• 镜像使用 Legacy BIOS 模式安装，Secure Boot 无法开启。

处理方式：

先在 BIOS 中开启 TPM 和 Secure Boot，再安装系统。不要为了绕过检查去修改安装源，因为后续功能更新和驱动签名验证都可能依赖这些特性。

6.4 组件删除导致系统设置或商店异常

现象：打开设置面板白屏，安装应用时报错 0x80073CF3，或应用商店里某些应用无法安装。

可能原因：

• 删除了与系统设置组件有依赖关系的 Appx。
• 删除了 Microsoft Store 或依赖 WebView2 的组件。
• 删除预置包时没有考虑依赖关系。

排查方式：

查看C:\Windows\Panther\setuperr.log和事件查看器中的 Application 日志，确认报错模块名称。如果是 Store 相关组件缺失，不要继续尝试逐个补装，建议直接基于原始安装源重新生成镜像，只保留高置信度可删组件。

问题现象	常见原因	检查方式	处理建议
无法引导	MBR 分区或 EFI 无引导文件	diskpart / bcdboot	转换 GPT 并重建引导
预装应用恢复	删的是当前用户数据	Get-AppxProvisionedPackage	在镜像阶段删除预置包
升级被拦	TPM/Secure Boot 未开启	msinfo32 / BIOS	开启后再部署
设置面板异常	删除了依赖组件	setuperr.log	回归原始镜像制作

7. Win10 到 Win11 组件化部署的工程化建议

组件化部署的意义不只是“做一次干净镜像”，而是让后续每一版系统都能按照同一套规则生成。要做到这一点，需要在脚本、清单、验证三个层面上都建立约束。

7.1 把组件清单变成配置文件，而不是记忆

不要靠“我记得这个包可以删”来维护镜像。把组件清单放入 Git 仓库，每次增删组件时提交说明，记录对应测试结果。推荐维护三份文件：

文件	作用
apps_to_remove.txt	需要删除的预置应用包名
features_to_keep.txt	必须保留的可选功能
features_to_disable.txt	可以关闭的可选功能

组件清单的改动要遵循“一次只改一项”的原则。如果同时删除十个应用，后续出现问题，很难确认是哪一项引起的。

7.2 生产环境发布检查清单

发布到生产之前，至少完成以下检查：

• 原始 ISO 的哈希值已记录，且能随时重新下载。
• 原始install.wim已备份，未直接覆盖。
• 所有组件删除命令的日志已保存。
• 在虚拟机中完成完整安装，并通过Get-AppxPackage验证结果。
• 在同一版本但不同架构的机器上做试点部署。
• 记录镜像的构建时间和构建脚本版本，便于回滚。

一个常见的错误是镜像做成功后直接把原始 WIM 覆盖掉。一旦后续需要添加某个驱动，或者发现误删组件，就只能重新下载 ISO。这个代价比多占用几十 GB 磁盘高得多。

7.3 扩展方向：从单机镜像到集中化部署

在单机镜像流程跑通之后，可以继续向两个方向扩展：

第一个方向是接入 PXE 网络启动，让机器开机后从网络获取 WinPE，再自动从共享目录加载自定义 WIM。这样不再需要逐台插 U 盘，适合大批量装机。

第二个方向是使用sysprep /generalize结合自动应答实现标准化装机。镜像应用完成后，系统以通用化状态首次启动，自动生成新的 SID 和计算机名，适合企业环境。

需要强调的是，无论使用哪种扩展方案，核心仍然是组件清单和构建脚本。只要这两样东西可控，Win10 和 Win11 的区别就只是源镜像和需求参数的不同，而不是每次都要重新走一遍手工清理流程。

对于刚开始接触这套流程的读者，建议不要一上来就追求删掉最多组件。先保留微软商店、计算器、截图工具和 Windows 安全中心这类与系统功能关联较深的应用，只删除那些确定无用的预置游戏和应用。等整条构建、部署、验证链路稳定之后，再逐步收紧组件清单。这样既能获得“组件自己选”的部署效果，也不会因为过度精简把系统改到不可维护。