gOxiA=苏繁=SuFan Blog

再谈 CompactOS

        距离上一次谈及 CompactOS 已经过去十年了，那还是在2015年的12月与大家分享了“HOWTO: 利用 CompactOS 减少 Windows 10 磁盘占用量”。感叹时间过得可真快，很多东西都已经变了……Windows 10 都已经发布10年之久了，说到这里提醒各位距离 Windows 10 生命周期结束还剩10个月左右（Windows 10 2025年10月14日终止服务），要抓紧向新的操作系统版本迁移！！！话题回到 CompactOS，再聊起它是因为最近在测试 Windows 11 IoT Enterprise LTSC 2024（以下简称W11IoTEntLTSC2024），先看下面两幅图。

        第一张图，是未启用 CompactOS 时空间占用情况，达到了 10.5GB，后者是启用了 CompactOS 的结果，仅占用了不到7GB的空间。对于结合了云端服务的现代计算设备而言，存储空间显得并不那么重要，先不说那些动辄 8~18TB 甚至更大海量存储的机械式硬盘，单固态硬盘 256GB ~ 1TB 也是常见，再高的还有 2TB ~ 4TB。既然不缺存储空间为什么还要谈 CompactOS 呢？对于 IoT 场景，通常设备存储不会太大，32GB ~ 64GB更为常见，按照 gOxiA 这个极端测试，仅配置了一个 16GB 的存储，此时操作系统的占用空间就显得尤为重要，越少的占用意味着可以留出更多空间给业务应用使用。所以，我们仍会用到 CompactOS，利用这个功能我们可以仅压缩运行操作系统所使用的文件，这些文件在运行读取操作时并不会在硬盘上进行解压缩，仅当需要进行写操作时才会从内存释放到硬盘。对于现代计算设备 CompactOS 所带来的影响是微乎其微的，甚至我们根本不会察觉到有什么变化，尤其是使用固态硬盘时！此外，根据微软官方的解释，由于压缩意味着减少读取，这将消除存储设备的负载，并提高 I/O 性能；但也意味着增加解压缩，此时 CPU 的负载将增加从而降低性能。这个特性也使 CompactOS 在具有快速 CPU 和 慢速存储 I/O 的系统上表现出可能更好的性能，当然这并不是绝对的！！！ 下面是对启动过程做的评估，两台设备都是执行的全新安装，左列的设备在安装时使用应答文件启用的 CompactOS，为了确保数据的准确性，各做了三次启动数据的收集。左列设备的数据展示了在启用 CompactOS 后确实会对设备性能造成一些小的影响，启动速度慢了2秒左右，感官上确实没什么感觉！

        之后对收集的 ETL 数据继续了对比，确实如官方文档所述，挺有意思！

        综上，如果我们要启用 CompactOS，建议使用更快的 CPU 和更大容量更快的内存，为了确保整体的运行性能，建议首选固态硬盘！对于启用 CompactOS，到目前 Windows 11 的 24H2 版本，Windows Setup 提供的 CompactOS 参数仍只支持升级模式，全新安装模式仍不受支持！要想在全新安装时启用 CompactOS 建议通过应答文件实现，参考如下：

        结束本次分享前，快速聊一下 CompactOS 所使用的压缩算法 - XPRESS4K，压缩率低但速度最快，与它一起提供的算法还有 XPRESS8K，XPRESS16K 以及 LZX。当我们要单独压缩某个程序时就可以根据实际需求执行，例如：compact /c /exe:lzx c:\program files\lobapp\lobapp.exe，对于 OEM 也可以对预装的那些只读程序文件进行压缩。

最后推荐两篇微软的官方文档供大家参考：

Compact OS, single-instancing, and image optimization | Microsoft Learn

Using Compact OS with Windows IoT Enterprise | Microsoft Learn

HOWTO: 修复 Windows 系统文件和组件存储

        Windows 运行一段时间可能因为意外关机、系统崩溃，或不兼容的软件或驱动更新，又或者是第三方优化工具的误操作，导致 Windows 系统文件和组件存储出现错误，那我们的系统环境就会出现一些莫名其妙的异常故障现象，或发生性能缓慢的问题，所以定期检查修复是非常有必要的运维措施，那么我们该如何检查修复 Windows 系统文件和组件存储呢？！

        gOxiA 今天要分享的话题相对轻松，也更容易理解和掌握！首先我们先了解一下什么是系统文件和组件存储。系统文件即 Windows 操作系统自身的一些关键文件，它们包含了动态链接库文件（DLL）；可执行文件（EXE）；驱动文件（SYS）；还有一些配置文件，如：注册表和启动相关文件；其他的还会有字体和主题文件这样的 Windows 应用资源文件，以及安全策略和网络组件文件。

        组件存储即 WinSxS 文件夹中的内容，它是系统文件的基石（备份库），包含了 Windows 所有核心组件的多个版本，用于支持系统文件的兼容性和回滚功能。每个组件都有对应的清单文件，记录了它们之间依赖关系和文件属性。文件中还包含文件的哈希值和数字签名，用于验证文件的完整性。

        系统文件和组件存储的关系是当进行系统文件扫描和修复时，都会从组件存储中进行提取。所以当我们执行系统文件修复失败时，就要先去执行和完整组件存储的修复。两者都会生成日志，并存储在“C:\Windows\Logs\DISM\dism.log”文件中，当需要进行相关排错时我们可以利用上这个日志文件。

        接下来，我们来了解如何修复系统文件和组件存储。对于系统文件，我们可以使用 SFC 命令，它内置于我们的系统中，需要管理员权限才能正常实行，具体的命令为：

        SFC 通过调用 Windows Resource Protection（WRP）技术来识别是否有核心文件被删除、损坏或修改。这个技术其实可以追溯到 Windows 98 时代的系统文件保护（System File Protection, SFP），再此之前 Windows 系统极易受到篡改……那会也是众多杀毒软件和专杀工具盛行的时期，再此之后 Windows 2000 和 XP 引入了 Windows 文件保护（Windows File Protection, WFP），到 Windows Vista 开始诞生了 WRP 并一路完善增强至今，使 Windows 越来越安全越来越稳定。

        OK，回归正题！如果执行后提示无法修复，那么我们就要使用 DISM 命令修复组件存储，首先我们可以先执行一次组件存储扫描，为此执行如下命令：

        扫描组件存储后一旦发现有异常，我们就要执行修复，为此我们可以使用 /restorehealth 参数，即：

        在执行 restorehealth 进行修复时会自动连接网络从微软官方 Update 及相关文件的资源网站下载正确的文件，如果出现网络问题则会影响修复，并提示失败。此时我们就需要手动指定稳定可靠的源，这个源可以是一个 Windows 实例，或者直接 Mount 一个 WIM 到目录进行引用，如果觉得麻烦，也可以直接引用一个 WIM。但需要确保引用的源与当前 Windows 实例的版本一致。

       下面 gOxiA 将引用一个 WIM 文件进行组件的修复，命令行如下：

        如果版本一致，并且源无损坏等异常，则能够修复成功，这样一来我们就不必通过重新安装操作系统来解决问题。

        最后，友情提示切勿使用第三方优化工具去执行清理 WinSxS 目录实现所谓的存储优化，它只会带来隐患！！！

使用 WDS 部署 Windows 11 24H2 Arm 的可行性研究

        今天继续分享与 Windows 自动部署相关的话题，前面介绍了“基于 Autounattend 应答文件的 Windows 11 24H2 Arm 自动化安装”，这次 gOxiA 要与大家分享一下最近在 WDS 上部署 Windows 11 24H2 Arm 的收获。如果你关注过之前的一篇日志“WDS 变更部署支持”，会了解到 WDS 很关键的信息，即便如此 gOxiA 还是希望通过实践做一下可行性研究。

        环境为一个工作组的Windows Server 2025（以下简称：WS2025），安装了 DHCP 和 WDS Role，并进行了配置目前属于可工作状态；客户端是一台 Arm 架构的设备，支持 PXE Boot 启动。首次尝试时，我先导入了 Windows 10 22H2 Arm 安装源中的 Boot.wim，在成功执行 PXE Boot 引导进入 Windows Setup 的 PE 环境后，报了一个错误，如下图所示，看起来是 DHCP 导致的一个问题。

        在导入网卡、USB等驱动后仍旧是报这个错误，看来应该是底层做了某些限制，指示给了一个完全无关的报错。之后又尝试导入 Windows 11 24H2 Arm 的 Boot.wim，启动后如下图所示，看起来是缺少相关驱动。

        但实际测试后发现即使导入了驱动也仍是这个提示，而且需要调用 CMD 执行网络初始化才能启动网络，但始终是提示需要驱动的界面，同上也只能放弃！

        最后的希望只能放在 Windows PE 上了，使用 Windows ADK 生成 Arm64 的 PE，并集成了网卡驱动，将其添加到 WS2025 WDS 的启动映像中，客户端引导成功，并且网络能够自动初始化。尝试做了 Ping 可连通 WS2025 服务器，并且还能够正常使用 Net use 命令。但当 gOxiA 尝试向该 PE 集成相关的 Setup 和 WDSTools 相关组件后，则该映像将启动失败。结论同上，应该是底层做了限制，就是要杜绝掉使用 WDS 执行 Windows Setup。

        OK，gOxiA 再换个思路，不在当前 PE 集成相关组件，使其成为一个可正常引导并访问访问网络的 PE 环境，之后从网络加载 Windows 11 24H2 Arm 的安装源，手动执行 Windows Setup，惊喜！！！竟然以 Legacy Setup 模式成功启动了 Windows Setup，但是呢……安装向导会提示当前设备不符合 Windows 11 最低需求。

        怎么可能！？该设备绝对是满足的，要了解真相只能排查日志 - Setupact.log，如下图所示，TPM没有被检测到。手动做了 TPM 的Bypass 检查跳过，这次可以了……

        既然因为检测不到 TPM 而终止，那就想办法为 PE 集成 TPM 驱动呗！想着简单，实现起来可是难上加难！首先查看 TPM 驱动发现它是一个系统级自带的驱动，与之相关的只有 TPM 固件驱动，检查 TPM 固件对应的 OEM.inf，再确认实际的 inf 名称，将其加载到 PE，谁想仍旧无法正常检测到 TPM，成为了难解之题，只能放到后续再研究。

        总结，通过本次测试研究，可使用基本版的 Windows 11 PE，通过手动加载 Windows 11 24H2 Arm 安装源的方式启动 Windows Setup，对于 TPM 问题可以通过 BypassCheck 的方法处理。那么 gOxiA 完全可以手动编制一个定制 PE 自动执行这些操作以完成 Windows 11 24H Arm 的自动部署。只是这样一来，WDS 仅仅是充当了一个 PXE Boot 的角色，而部署则完全依赖 WS2025 的 SMB。

        后面，会抽时间完成这个 PE 的定制，如有收获会继续与大家分享！