企业官网建设流程全解析

1. tiny11builder 不是“魔改工具”，而是 Windows 镜像工程的标准化流水线

你在网上搜“tiny11builder”，十有八九会看到一堆“一键精简”“秒变轻量”“告别卡顿”的标题。但我要先泼一盆冷水：tiny11builder 本身不删任何系统文件，也不绕过微软签名验证，更不是什么破解补丁或注入式修改器。它本质上是一套高度封装、可复现、可审计的 PowerShell 自动化脚本集合，其核心逻辑完全建立在微软官方支持的 DISM（Deployment Image Servicing and Management）和 ADK（Assessment and Deployment Kit）技术栈之上。换句话说，它干的活，你用管理员权限打开 PowerShell，手动敲几十行 DISM 命令也能完成——只是没人愿意这么干。

我第一次接触 tiny11builder 是在给一家做工业边缘计算设备的客户部署系统时。他们要求 Windows 11 IoT Enterprise LTSC 镜像必须控制在 8GB 以内，且所有预装应用、后台服务、遥测组件必须彻底剥离，同时保留 .NET Framework 3.5、Windows Subsystem for Linux（WSL）、Hyper-V 平台虚拟化能力——这三者在默认镜像里是互斥的：启用 WSL 就得开 Hyper-V，开了 Hyper-V 就得留一堆驱动和服务，留了服务体积就上去了。当时我们试过手动 DISM 操作，光是清理“Windows Defender Antivirus”这个功能包，就因为依赖关系错综复杂，反复失败了 7 次，最后一次还导致镜像无法启动。直到发现 tiny11builder 的--no-defender参数背后，其实是先用DISM /Image:C:\mount /Get-Features列出所有可卸载功能，再逐个分析Parent和Dependents字段，最后按拓扑排序生成卸载序列——这才是它真正值钱的地方：把微软文档里零散、晦涩、极易踩坑的 DISM 依赖规则，变成了一个可预测、可回滚、可日志追踪的执行流。

所以，别把它当成“绿色软件”去双击运行。它是一条微型的 Windows 部署产线：输入是微软原版 ISO（比如en-us_windows_11_iot_enterprise_ltsc_2024_x64_dvd.iso），输出是符合你定制策略的 WIM/ESD 文件。中间每一步——挂载、清理、精简、注入、提交、导出——都调用的是DISM.exe这个微软亲儿子，所有操作日志默认写入logs\目录，你可以随时用DISM /Get-WimInfo /WimFile:output.wim验证结果。它不黑箱，它只是把黑箱般的 DISM 手动操作，变成了白盒化的配置驱动流程。

这也是为什么它能稳居 GitHub Trending 前列：不是因为它多神秘，而是因为它把一件极其专业、极易出错、文档极不友好的底层部署工作，降维成了“改几个 JSON 参数 + 点一次 Start-Build.ps1”的事。你不需要背熟DISM /Image:C:\mount /Disable-Feature /FeatureName:NetFx3 /Remove的全部语法，只需要在config.json里把"netfx3": false设为true，脚本就会自动判断该用/Enable-Feature还是/Disable-Feature，并处理好前置依赖。这种“语义化封装”，才是 tiny11builder 的真实定位——它是 Windows 部署工程师的 CLI 工具链，不是小白用户的“一键加速器”。

提示：tiny11builder 的 GitHub 仓库里，src\目录下全是.ps1脚本，functions\子目录里每个.ps1文件都对应一个 DISM 操作模块（如Remove-AppxProvisionedPackage.ps1、Disable-Telemetry.ps1）。建议初学者先通读Start-Build.ps1主流程，再对照DISM官方文档看每个函数的参数映射——这比直接跑脚本更能理解它到底在干什么。

2. 精简不是“删删删”，而是基于 Windows 功能层级的精准外科手术

很多人以为“精简 Windows”就是删掉C:\Windows\SystemApps里的 Metro 应用，或者用第三方工具禁用一堆服务。tiny11builder 完全不走这条路。它的精简逻辑，严格遵循 Windows 的四层功能架构模型：

关键点在于：L1 和 L2 层的操作是“禁用”，L3 和 L4 层的操作是“移除”。禁用（Disable）只是让功能不可用，但文件仍保留在镜像中，占用空间；移除（Remove）则是物理删除文件，释放空间。tiny11builder 默认对 L1/L2 采用禁用（因部分功能存在硬依赖），对 L3/L4 则直接移除——这是它体积压缩效果显著的核心原因。

举个具体例子：--no-apps参数。它不只是删掉开始菜单里的图标，而是执行以下完整链路：

1. 挂载 WIM 镜像到C:\mount\windows
2. 运行DISM /Image:C:\mount\windows /Get-ProvisionedAppxPackages获取所有预配包列表
3. 过滤掉Microsoft.DesktopAppInstaller（winget 依赖）、Microsoft.VCLibs.140.00.UWPDesktop（桌面应用依赖）等关键包
4. 对剩余包逐个执行DISM /Image:C:\mount\windows /Remove-ProvisionedAppxPackage /PackageName:xxx
5. 清理注册表残留（通过注入cleanup-apps.reg）

这个过程之所以可靠，是因为它不靠文件名匹配（易误删），而是严格依据DISM /Get-ProvisionedAppxPackages返回的PackageName字段——这是微软定义的唯一标识符。我曾见过有人用批处理遍历SystemApps目录删*Mail*，结果把Microsoft.Windows.CloudExperienceHost（登录界面核心）也删了，导致系统无法进入桌面。tiny11builder 绝对避免这种野蛮操作。

再看一个高频需求：关闭遥测。网上流传的“组策略禁用”或“注册表修改”只能作用于已安装系统，对离线镜像无效。tiny11builder 的--no-telemetry实际做了三件事：

• 禁用 L1 层的DiagTrack服务（DISM /Disable-Feature /FeatureName:DiagnosticPolicyService）
• 移除 L4 层的遥测更新包（DISM /Remove-Package /PackageName:Package_for_KB4074588~...）
• 注入预设的telemetry-off.reg到镜像HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\DataCollection路径

这三重保险，确保镜像部署后，从开机第一秒起就不再发送任何遥测数据——不是“关不掉”，而是“根本没机会开”。

注意：--no-defender是最常被误解的参数。它并非彻底删除 Windows Defender，而是禁用Windows-Defender-Default-Definitions功能包，并移除所有预装的病毒定义更新包（.cab文件）。镜像里仍保留MpCmdRun.exe和基础扫描引擎，但无定义库则无法查杀。若你需要保留 Defender，应使用--defender-minimal，它只移除 UI 组件和实时防护服务，保留命令行扫描能力。

3. 构建环境不是“装个 PowerShell 就行”，ADK 版本与 Windows 版本必须精确对齐

很多人跑 tiny11builder 失败，90% 的原因出在环境准备阶段。它不像普通 PowerShell 脚本，对运行环境有硬性依赖：必须安装与目标 Windows 版本匹配的 Windows ADK（Assessment and Deployment Kit），且 ADK 版本不能低于目标系统版本。这不是建议，是 DISM 引擎的底层限制。

以构建Windows 11 26H2（内部代号“Cobalt”）镜像为例：

• 你必须安装ADK for Windows 11, version 26H2（Build 26000+）
• 不能用 ADK 24H2（Build 24660），即使它能启动，但在处理26H2新增的CloudExperienceHost组件时会报错0x80070002（找不到指定文件）
• 更不能用 ADK 22H2（Build 22621），它根本不认识26H2的新功能包命名规则

我在实际项目中遇到过一个经典案例：客户提供的 ISO 是Windows 11 Enterprise LTSC 2024 (Build 26100)，但运维同事图省事，直接装了最新版 ADK 26H2 Preview。结果脚本在Mount-WimImage.ps1步骤卡死，日志显示DISM failed with error 0x80070057。排查了 3 小时才发现，Preview 版 ADK 的DISM.exe对26100的WinPE驱动包解析有 Bug，必须降级到ADK 26H2 RTM (Build 26000.1)才能正常挂载。

ADK 的安装也不是全选就行。tiny11builder 只需要其中三个组件：

• Deployment Tools（必选）：提供DISM.exe、Oscdimg.exe、MakeWinPEMedia.exe
• Windows Preinstallation Environment (WinPE)（必选）：提供WinPE驱动和工具，用于创建可启动介质
• User State Migration Tool (USMT)（可选）：仅在需要迁移用户数据时用，tiny11builder 默认不用

其他如Windows Assessment Tools、Application Compatibility Toolkit完全不用装，它们不仅不参与构建，还会拖慢安装速度、增加系统负担。

PowerShell 版本同样关键。tiny11builder 要求PowerShell 5.1 或更高版本（Windows 10/11 自带），但严禁使用 PowerShell Core（7.x+）。因为：

• DISM的 PowerShell 模块（Dism）是 .NET Framework 依赖的，而 PowerShell Core 基于 .NET Core，无法加载
• 脚本中大量使用的Get-WmiObject、Set-ItemProperty等 cmdlet 在 PowerShell Core 中已被弃用或行为不同
• Start-Build.ps1开头的#requires -Version 5.1就是硬性检查

如果你在 Windows Server 上运行，务必确认ExecutionPolicy设置。常见错误是Set-ExecutionPolicy RemoteSigned -Scope CurrentUser只对当前用户生效，而 tiny11builder 需要以管理员身份运行，所以必须执行：

Set-ExecutionPolicy RemoteSigned -Scope LocalMachine -Force

否则会在Import-Module Dism步骤报错File xxx.ps1 cannot be loaded because running scripts is disabled on this system。

最后是磁盘空间。构建一个 8GB 的精简镜像，临时空间需求远超想象：

• 挂载 WIM 需要 2 倍镜像大小（ISO 5.2GB → 挂载后占用 10.4GB）
• DISM 清理过程会产生大量临时文件（C:\$WINDOWS.~BT\Sources\）
• 最终导出 WIM 时，DISM /Export-Image会先解压再压缩，峰值占用可达 15GB+

因此，系统盘（通常是 C:\）必须预留至少 30GB 空闲空间。我见过太多人因空间不足，在Export-WimImage.ps1步骤失败，错误码0x80070070（磁盘空间不足）看似简单，但日志里埋得很深，新手往往花半天才定位到。

4. 配置文件 config.json 是你的“精简宪法”，每个字段都决定最终镜像的基因

tiny11builder 的灵魂不在 PowerShell 脚本里，而在config.json这个配置文件中。它不是简单的开关列表，而是一个结构化的镜像策略声明。理解每个字段的含义和取值逻辑，是定制出符合你需求镜像的前提。

一个典型的config.json结构如下：

{ "sourceIso": "D:\\ISO\\win11_iot_ltsc_2024_x64.iso", "outputDir": "D:\\tiny11_output", "wimIndex": 1, "architecture": "amd64", "edition": "IoTEnterprise", "features": { "netfx3": true, "telnet": false, "iis-webserver": false }, "optionalFeatures": { "wsl": true, "openssh": false, "hyperv": true }, "apps": { "removeAll": true, "keepList": ["Microsoft.DesktopAppInstaller", "Microsoft.VCLibs.140.00.UWPDesktop"] }, "telemetry": "off", "defender": "minimal", "language": "zh-CN", "drivers": [] }

关键字段深度解析：

wimIndex：指定 ISO 中哪个 WIM 文件作为源。一个 Windows ISO 通常包含多个索引：

• Index 1：Windows 11 Home
• Index 2：Windows 11 Pro
• Index 3：Windows 11 Enterprise
• Index 4：Windows 11 IoT Enterprise LTSC

你不能凭名字猜，必须用DISM /Get-WimInfo /WimFile:D:\sources\install.wim查看。wimIndex错了，构建出来的就是错误版本——比如你想要 LTSC，却用了 Index 1 的 Home 版，后续所有精简都白费。

edition：这个字段直接影响脚本加载的精简策略。tiny11builder 内置了针对不同版本的优化规则：

• IoTEnterprise：默认禁用Windows Update Medic Service（UsoSvc），因为 IoT 场景不允许自动更新
• Enterprise：保留Group Policy相关组件，但禁用Work Folders（企业云同步）
• Education：移除所有Microsoft Teams预配包，但保留OneDrive教育版

如果你把edition设为Pro却想构建LTSC，脚本会警告但不会阻止，结果就是镜像缺少 LTSC 特有的Windows Defender Application Guard组件，导致部署后某些安全策略失效。

features和optionalFeatures：这两组布尔值看似简单，但背后有强约束。例如wsl和hyperv必须同时为true或同时为false。因为 WSL2 依赖 Hyper-V 平台，如果只开wsl:true而hyperv:false，脚本会在Validate-Features.ps1步骤直接退出，报错WSL2 requires Hyper-V to be enabled。这不是 bug，是设计上的强制校验。

apps.keepList：这是最易出错的字段。keepList里的包名必须与DISM /Get-ProvisionedAppxPackages返回的PackageName完全一致，包括大小写和版本号。例如Microsoft.Windows.Photos是正确的，microsoft.windows.photos或Photos都会失败。tiny11builder 提供了一个辅助脚本Get-AppxList.ps1，你可以先挂载 ISO，运行它获取所有可用包名，再复制粘贴到keepList中，避免手输错误。

telemetry：取值不仅是on/off，还有basic和enhanced。basic会保留Diagnostic Data Viewer（诊断数据查看器）UI，但禁用所有上传；enhanced则只禁用Activity History和Advertising ID，保留核心遥测——这是为合规审计场景设计的灰度选项。

实操心得：我习惯在首次构建时，先用--dry-run参数运行脚本（.\Start-Build.ps1 --dry-run）。它不会真正挂载镜像，而是模拟整个流程，输出将要执行的 DISM 命令列表。你可以仔细检查每一条命令是否符合预期，比如确认DISM /Remove-ProvisionedAppxPackage是否真的避开了你keepList里的包。这比盲目构建后再修复快得多，尤其当你在批量定制多个客户镜像时，--dry-run是必备的安全阀。

5. 构建失败不是“脚本坏了”，而是 DISM 日志里藏着完整的故障地图

当 tiny11builder 报错时，第一反应不该是重装、重启或换电脑，而是立刻去看logs\目录下的日志文件。tiny11builder 的日志设计非常专业：每个主要步骤都有独立日志（Mount.log、RemoveApps.log、Export.log），且每条 DISM 命令的输入参数、返回码、标准输出/错误都会被完整记录。DISM 的错误码不是随机数字，而是微软定义的 HRESULT 值，每个都有明确含义。

最常见的错误码及应对方案：

我遇到过一个特别隐蔽的故障：脚本在Remove-Telemetry.ps1步骤失败，日志显示0x80073701。按常规思路，我以为是 ISO 损坏，重下了三次 ISO 都不行。最后发现，问题出在C:\mount\目录的 NTFS 权限上——之前一次失败的构建残留了C:\mount\windows目录，其所有权被设置为某个已删除的域账户，导致当前管理员无法写入。解决方案不是删目录，而是用icacls C:\mount /reset /T重置所有子目录权限。

另一个高频陷阱是DISM 安装输入法报错740。这其实不是 tiny11builder 的问题，而是 Windows 输入法框架的权限缺陷。当脚本尝试注入自定义输入法时（通过DISM /Add-Package），会触发 UAC 提权，但自动化脚本无法交互。解决方案是在config.json中禁用--no-inputmethod，改用部署后通过Set-WinDefaultInputMethodOverridePowerShell 命令设置，绕过 DISM 的提权环节。

最后强调一个黄金法则：永远不要跳过Validate-Image.ps1步骤。这个脚本在导出前会执行：

• DISM /Check-Health：检查镜像完整性
• DISM /Cleanup-Image /StartComponentCleanup：清理组件存储
• DISM /Get-WimInfo /WimFile:output.wim：验证导出镜像的索引和大小

如果这一步失败，说明镜像已损坏，强行使用会导致部署后蓝屏或功能缺失。我曾帮一个客户修复过一个“构建成功但部署后无法联网”的问题，根源就是Validate-Image.ps1被跳过，DISM /Cleanup-Image未执行，导致网络堆栈组件损坏。重新运行验证脚本后，问题自然消失。

踩坑实录：某次为客户构建Windows 11 26H2镜像，所有步骤都显示 success，但部署后发现Windows Terminal无法启动，报错0x80004005。排查日志发现，Remove-Apps.ps1在移除Microsoft.WindowsTerminal时，因--no-apps参数过于激进，连带删除了Microsoft.VCLibs.140.00.UWPDesktop（终端依赖的运行库）。解决方案是在config.json的apps.keepList中显式加入该包名。这个教训让我养成了一个习惯：每次新增keepList，都用DISM /Get-AppxPackage -AllUsers | findstr "VCLibs"在干净系统上验证其存在性，确保包名准确无误。

6. 镜像交付不是“拷个 ISO 就完事”，启动介质与部署策略决定最终体验

构建出output.wim只是完成了 70% 的工作。剩下的 30%，是让这个精简镜像真正落地到物理设备或虚拟机上。tiny11builder 本身不生成可启动 USB，但它提供了完整的WinPE集成方案，这才是工业部署的关键。

标准交付流程分三步：

第一步：创建 WinPE 启动介质tiny11builder 的Create-Media.ps1脚本会：

• 从 ADK 安装目录复制WinPE基础镜像（winpe.wim）
• 注入DISM、BCDEDIT、Notepad.exe等必要工具
• 添加tiny11-deploy.ps1脚本，实现“一键部署”逻辑：

  # tiny11-deploy.ps1 核心逻辑 $targetDisk = Get-Disk | Where-Object {$_.Size -gt 30GB} | Select-Object -First 1 Initialize-Disk -Number $targetDisk.Number -PartitionStyle GPT New-Partition -DiskNumber $targetDisk.Number -UseMaximumSize -AssignDriveLetter | Format-Volume -FileSystem NTFS -NewFileSystemLabel "Windows" Expand-WindowsImage -ImagePath "X:\sources\install.wim" -Index 1 -ApplyPath "D:\" -Compact

  这段脚本自动识别大于 30GB 的磁盘，初始化为 GPT，创建 NTFS 分区，并将output.wim解压到D:\。你无需手动分区，也无需记住diskpart命令。

第二步：注入驱动与定制化脚本工业设备往往需要特定网卡、串口、GPU 驱动。tiny11builder 支持在config.json的drivers字段指定驱动路径：

"drivers": [ "D:\\drivers\\realtek\\rtl8168.inf", "D:\\drivers\\intel\\igfx.inf" ]

脚本会在 WinPE 启动时，自动运行pnputil /add-driver加载这些驱动，确保部署过程能识别硬件。更进一步，你可以在scripts\目录下放置post-install.ps1，它会在 Windows 首次启动时自动执行，完成：

• 激活（slmgr /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX）
• 网络配置（New-NetIPAddress -IPAddress 192.168.1.100 -PrefixLength 24 -InterfaceAlias "Ethernet"）
• 应用安装（Start-Process "D:\\apps\\docker-desktop.exe" -ArgumentList "/S" -Wait）

第三步：验证与签名精简后的镜像必须通过微软的signtool签名，否则在 Secure Boot 启用的设备上无法启动。tiny11builder 不内置签名功能，但提供了Sign-Image.ps1模板：

# Sign-Image.ps1 $cert = Get-ChildItem Cert:\LocalMachine\My | Where-Object {$_.Subject -match "YourCompany"} Set-AuthenticodeSignature -FilePath "D:\tiny11_output\install.wim" -Certificate $cert

你需要提前在本地证书存储中导入有效的 EV 代码签名证书。没有签名的镜像，在 Dell、HP 等品牌商用机上会直接黑屏报错Secure Boot Violation。

最后提醒一个实战细节：不要用 Rufus 或 BalenaEtcher 直接写入 tiny11builder 生成的 ISO。因为 tiny11builder 输出的是install.wim文件，而非标准 ISO 结构。正确做法是：

1. 用Create-Media.ps1生成WinPEUSB
2. 将output.wim复制到 USB 的\sources\目录，覆盖原install.wim
3. 用oscdimg.exe重新生成 ISO（如果需要）：

   oscdimg -n -bD:\winpe\efi\microsoft\boot\efisys.bin D:\winpe D:\tiny11.iso

这个流程确保了启动介质的兼容性和可靠性。我经手的 200+ 台工业设备部署，从未因启动介质问题失败过——因为每一步都源于 tiny11builder 的标准化设计，而不是靠运气。

个人体会：tiny11builder 的最大价值，不是帮你省了多少时间，而是消除了部署结果的不确定性。以前我们交付一个定制镜像，客户总要问“这个版本确定能跑 Docker 吗？”“那个串口驱动肯定包含了吧？”。现在，我把config.json、drivers\目录、scripts\目录打包发过去，客户自己运行Start-Build.ps1，得到的镜像和我本地构建的一模一样。这种可复现性，才是企业级部署的基石。它把“经验”变成了“代码”，把“人”变成了“流程”。