HOWTO: 解决 FFU 执行 Split 后未生成分卷文件问题
HOWTO: 解决 FFU 执行 Split 后未生成分卷文件问题
当我们为 Windows 系统实例生成 FFU Image 后，可能因为容量大小的问题需要对 FFU 执行 Split，例如：要部署的设备使用 UEFI，则 UFlash 必须使用 FAT32 格式，但该格式的分区无法存储超过 4GB 大小的文件，此时的方案要么是将 FFU 单独存储在 NTFS 分区上，或者将映像进行分卷存储。
FFU 与 WIM 格式虽然有本质上的区别，但也都支持分卷存储，但是 FFU 在执行分卷时则会遇到一个问题（如果我们忽略了 FFU 的基础信息，则这会变成一个 Keng - 坑）！！！继续往下看……
通常我们会采用默认命令行和参数执行 Capture FFU，但当我们需要使用 /Split-FFU 来拆分 FFU 时会发现执行过程非常块，并且结果反馈已经完成，并没有任何报错，但当去找寻这些拆分后的文件时却发现它们并不存在。
原来 FFU 的 Split 必须使用未经压缩过的 FFU，而命令行参数会默认使用压缩选项，具体说明如下：
如此一来，作为映像部署人员，如果需要在未来拆分这些 FFU 文件，则在捕获时必须加上 /Compress:none 参数，但 FFU 的文件容量也将剧增。文末让我们再一次对 FFU 的特性增加深印象：
- 用途：在工厂车间实现最快速的 Windows 捕获和部署。
- 映像样式：基于扇区
- 压缩：模式使用 Xpress-Huffman
- 它捕获什么内容：捕获完整的驱动器信息集，包括分区。
- 应用映像时会发生什么情况：清理整个驱动器。
- 是否可以部署到不同大小的硬盘驱动器：是的，但新驱动器大小必须等于或大于原驱动器大小。
- 是否可以修改映像：是的，通过使用 DISM 可以装载，修改和卸载映像。
- 可靠性：包含目录和哈希表，用于在刷写到设备上之前验证签名。在捕获过程中生成哈希表，并在应用时进行验证。
HOWTO: 解决 Windows Server 2022 的 WDS PXE-E16 问题
HOWTO: 解决 WDS PXE-E16 问题
一台基于 Windows Server 2022 的 WDS 服务器已加入到 AD，并使用 AD 集成模式进行了初始化的配置，跟随向导同时导入了 WinSvr 2022 的 Boot.wim 和 Install.wim，但是在使用 Hyper-V Gen2 VM 执行首次网络引导时是正常的，但是在通过实体机进行 PXE 网络引导时，发生了 PXE-E16 故障；之后再用 VM 测试同样报错。
从报错信息可见 PXE-E16: No valid offer received. 在 Configuration Manager 中 PXE 启动问题的高级故障排除 | Microsoft Learn 文档中提供了一些排查的思路。尝试创建一个 Gen1 VM 引导发现是可以正常工作的，说明 WDS 服务和发现均没有问题，看来是有其他原因。
网上曾有文章介绍使用 WDS 的独立模式进行配置，但在本案中并不适合，回过头来分析客户端的特征，并结合 WDS 事件日志做了分析，才恍然大悟。
- 客户端使用 UEFI 模式启动
- 查阅 WDS 事件日志，可看到设备已从 PXE 启动，但并未执行后续启动步骤。在日志中可以看到一个重要的提示“客户端体系结构: 4”
- 如果使用 Gen1 VM 执行 PXE 启动，日志中记录其客户端体系结构为1，之后会创建 Non-Shared 缓冲区来读取文件“\boot\x86\wdsnbp.com”，之后当 gOxiA 按下 F12 确认从网络引导后，WDS 又为其过程创建了“\bootx64\pxeboot.n12”，随后 TFTP 获取到 x64 的 Boot.wim 成功引导加载 PE 环境。在 Configuration Manager 中的 PXE 启动 | Microsoft Learn 这篇文档中我们可以获取到很多有用的信息。
由于 WDS 初始提供 wdsnbp.com 来引导客户端启动，而其特性仅支持 x86 和 x64 BIOS，所以最终导致 Gen2 VM 和实体设备发生引导故障，因为两者均为 UEFI。
为了确保 UEFI 这类的 Modern PC 能够通过 WDS 提供的 PXE 进行网络引导，我们需要强制 WDS 为客户端提供 UEFI 支持，即使用 Bootmgfw.efi 或 Wdsmgfw.efi，为此我们需要配置 DHCP，添加 067 选项，强制默认使用 UEFI 引导。
最后再次执行启动验证，Gen2 VM 和 实体机均能够正常通过 PXE 引导。在 WDS 事件日志中，可跟踪到设备初始便会使用 067 指定的 efi 文件加载引导，之后会成功加载 x64uefi 下的 bcd 并顺利完成后续的 Boot.wim 加载任务。
需要注意，当通过 DHCP 强制支持 UEFI 后，在使用 Gen1 VM 执行 PXE 网络引导，则会发生 PXE-E79 故障。
如果在企业环境中同时存在 BIOS 和 UEFI 固件类型的设备，IT 管理员可以考虑配置 DHCP 服务器，定义供应商类别（DHCP Vendor Classes），添加 UEFI x86/x64 以及 BIOS x86&x64 的支持。
Windows 启动过程的保护技术
Windows 启动过程的保护技术
“安全”是这些年最热门的话题之一，Windows 操作系统也在不断完善和增强自己的安全性，我们看到了显著的成果。今天 gOxiA 来分享一些关于 Windows 启动过程的保护技术。
对于Windows启动过程所面临的威胁恐怕当属Rootkits，作为恶意软件的一部分，它可在内核模式下运行，将拥有与操作系统相同的权限，并且先于操作系统启动，可想而知它的威力、自身隐藏和防御机制有多强大。
Rootkits可以在启动过程的不同阶段加载不同类型的Rootkit：
- Firmware rootkits，可覆盖PC的I/O系统或其他硬件固件，从而可先于Windows启动。
- Bootkits，可取代操作系统的引导加载程序，也可实现在操作系统之前加载。
- Kernel rootkits，可取代操作系统内核的一部分，因此可随Windows加载时自启动。
- Driver rootkits，将伪装成Windows用于与硬件通信的受信任驱动程序的一部分。
Windows 目前支持四项功能，以帮助防止在启动过程中加载 Rootkit 和 Bootkit。
- Secure Boot，即“安全启动”通过将具有 UEFI 和 TPM 的电脑配置为仅加载受信任的操作系统启动加载程序。我们知道当 PC 启动时会首先寻找操作系统的引导加载程序，也就是我们常说的启动程序，没有安全启动的 PC 将无法判断它是受信任的操作系统还是 Rootkit，将会运行硬盘上的任何可引导加载程序。如果 PC 配备了 UEFI，当它启动时首先验证固件是否已进行数字签名，如果启用了安全启动，固件将检查启动加载程序的数字签名，确保其没有被篡改，如果引导加载程序完好无损，则仅当满足下列条件之一时，固件才会启动引导加载程序。
a. 引导加载程序是使用受信任的证书签名。对于经过 Windows 认证的电脑，Microsoft 证书是受信任的。
b. 用户已手动批准了引导加载程序的数字签名。此操作允许加载非 Microsoft 操作系统。 - Trusted Boot，即“受信任启动”Windows 在加载启动过程的每个组件之前进行完整性检查。在实际过程中，受信任启动将接管安全启动结束的位置。引导加载程序在加载之前验证 Windows 内核的数字签名。反过来，Windows 内核会验证其启动过程的所有其他组件，这包括了驱动程序、启动文件和 ELAM。如果文件被篡改，引导加载程序会检测到问题并拒绝加载损坏的组件。通常，Windows 可以自动修复损坏的组件，恢复 Windows 的完整性并允许 PC 正常启动。
- Early Launch Anti-Malware (ELAM)，即“提前启动反恶意软件”在加载驱动程序之前进行扫描测试，防止加载未经批准的驱动程序。前面讲到安全启动保护了引导加载程序，而受信任启动保护了 Windows 内核，那下一个被恶意软件盯上的机会便是感染那些非 Microsoft 启动驱动程序。传统的防病毒软件在加载启动驱动程序后才会启动，这为伪装成驱动程序的 Rootkit 提供了机会。而提前启动反恶意软件（ELAM）可在所有非 Microsoft 启动驱动程序和应用程序之前加载微软或非微软的防病毒驱动程序，从而形成安全启动和受信任启动后的信任链。由于操作系统还没有启动，并且 Windows 需要尽快启动，因此 ELAM 有一个简单的任务：检查每个启动驱动程序并确定它是否在受信任的驱动程序列表中。如果它不受信任，Windows 将不会加载。ELAM 驱动程序并不是一个功能齐全的防病毒软件解决方案，我们熟知的 Windows Defender 就支持 ELAM。
- Measured Boot，即“度量启动”将记录每一次的启动过程，与之前受信任的启动数据进行比对，客观评估电脑运行状况。该项技术旨在防范那些看起来很健康，但其实已经感染了 Rootkit 的 PC 。这些 PC 可能正在运行防病毒软件，但其实已经感染了恶意程序。度量启动技术可以用来验证 Windows 启动过程的完整性，它会使用如下过程：
1) PC 的 UEFI 固件在 TPM 中存储固件、引导加载程序、启动驱动程序的哈希值，以及将在防病毒软件应用之前加载的所有内容。
2) 在启动过程结束时，Windows 将启动非 Microsoft 远程证明客户端。受信任的证明服务器向客户端发送唯一密钥。
3) TPM 使用唯一密钥对 UEFI 记录的日志进行数字签名。
4) 客户端将日志发送到服务器，其中还会包含其他安全信息。
根据实际运行数据和配置数据，我们可以确定客户端是否在正常运行。
综上，Windows 现行提供的启动保护技术创建了一个从根本上抵御 Rootkit 的体系结构。确保了 Windows 安全。参考文档：Secure the Windows boot process | Microsoft Docs
