基于 Autounattend 应答文件的 Windows 11 24H2 Arm 自动化安装
基于 Autounattend 应答文件的 Windows 11 24H2 Arm 自动化安装
已至 2024 年末，回顾 gOxiA 在7月中旬分享的日志“为企业部署 Arm Client 做准备”，现在一切都已经就绪！Windows 11 24H2 已经开始面向更多的用户推送，并且我们可以如愿以偿地从微软官方获取 Windows 11 24H2 ISO for Arm。接下来就可以完整地进行一次 Windows Arm 的定制化部署实践了。而今天要分享的是基于 Autounattend.xml 应答文件的 Windows 11 24H2 Arm 自动化安装。通过了解这一过程我们可以了解和掌握如何利用应答文件来实现 Windows Setup 的自动化。
Windows Setup 就是 Windows 安装源所运行的过程，通常 Windows 安装源是一个 ISO 文件，也就是我们常说的光盘镜像，ISO 可以直接加载到虚拟机的光驱中使用，也可以将其释放到 UFlash Disk 上，连接物理计算机的 USB-C/A 引导安装。这是一种最常见，最为简单，面向广大用户的安装方法。如果你阅读了“速览 Windows 11 Enterprise LTSC 2024 Setup 和 OOBE 体验”这篇日志，就可以了解到 Windows Setup 的安装过程。一旦成功启动 Windows Setup（Windows 安装程序）我们需要按照向导的指示完成一步步的安装动作，最终才能完成 Windows 从安装源到硬盘的安装过程。在前文中我们可以看到几个需要用户干预的步骤：
1. 选择语言设置
2. 选择键盘设置
3. 选择安装选项
4. 产品密钥
5. 选择映像
6. 接受适用的声明和许可条款
7. 选择安装 Windows 11 的位置
8. 确认准备就绪，可以安装
9. 安装 Windows 11
对于专业 IT，以上的步骤十分简单，可谓轻车熟路。对于普通用户通过友好易懂的向导也能轻松完成 Windows 全新安装。但如果希望将这一过程自动化，以应对自动化安装需求呢？！最常见的恐怕就是基于 WDS PXE 的传统安装场景了，或者位于设备应用现场的工程师需要就地执行全新安装时的场景，这些场景都会依赖 Windows 安装应答文件 - Unattend。（PS：当然我们也可以不使用基于 Windows Setup 的自动化安装方案，而是通过 PE 基于脚本来实现更复杂的适用于大规模批量自动化部署的方案，而这是我们以后的日子再聊的！！！）
Unattend.xml - Windows 安装应答文件，我们可以手动执行 Setup 程序来加载，或者将其加载到部署平台供系统映像使用，也可以直接加载到系统映像中。因为 Unattend 包含 Windows 安装的多个阶段的应答配置，可以实现 Windows 系统的自动安装、自动配置以及按需定制。（PS：这是一个并不轻松的工程，回顾过去标准化桌面的工作岁月，那些一遍又一遍耗时、耗力、耗费大量存储空间和硬件资源的测试验证过程！苦累心酸但又令人激动亢奋！在今天的高性能个人计算平台上，强劲的 CPU，充足的内存，海量的 SSD 存储，使得桌面标准化交付工程如鱼得水！现在真是幸福！！！）
Windows 11 24H2 Arm ISO 的发布实现了我们，尤其是企业对按需定制和标准化自动部署的期望，并且微软官方支持基于映像定制的传统部署方法，所以 Unattend 在 Windows 11 24H2 Arm 上是可行的。接下来就让我们体验以下这激动人心的时候！Windows Setup 自动化位于 Unattend 的 windowsPE 阶段，我们将逐一实现上述步骤的自动化。准备环境：
- 一台 Windows 工作站，建议 Windows 11 Pro/Ent 操作系统
- 安装 Windows ADK
- 一份 Windows 11 24H2 Arm ISO
- 为要安装的 Windows SKU 生成编录文件
- 使用 Windows 系统映像管理器创建应答文件，将其命名为 Autounattend.xml，在之后实际应用中只需要将 Autounattend.xml 拷贝到 Windows Setup 源的 UFlash Disk 根目录下，在从 USB 引导后就会自动加载这个应答文件来执行自动化安装。
1. 以简体中文 Windows 11 24H2 Arm 为例，要跳过“选择语言设置”和“选择键盘设置”。
为 windowsPE 阶段添加 Arm64 架构的 Microsoft-Windows-International-Core-WinPE 组件。中文输入法的代码为 0804:00000804，其他都为 zh-cn，可以根据需要配置 UILanguageFallBack 和 SetupUI 的语言，在本例中我们忽略，因为未集成其他语言。
2. “选择安装 Windows 11 的位置”，这一步主要是配置硬盘和分区。
通常设备上只有一块硬盘，ID 为 0。现代 PC 都采用 UEFI 方式，所以硬盘分区需要一个 FAT32 格式的 EFI 分区用作引导，大小建议 260MB（完美4K对齐）；一个 128MB 的 MSR（Microsoft Reserved Partition）分区，MSR 分区是 Windows 操作系统中用于管理磁盘的一种保留分区类型，主要功能是为系统管理操作保留空间；最后一个是操作系统分区，使用所有剩余容量 - Extend 设置为 true，NTFS 格式的 Primary 分区。对于 Windows RE 分区我们无需创建，系统在完成安装后的初始化阶段会自动准备。
大家会注意到配置中包含的两个设置：
- DisableEncrypteDiskProvisioning，设置为 true 表示不激活空白硬盘上的加密，即使这些硬盘支持基于硬件的加密。
- WillWipeDisk，设置为 true 表示擦除硬盘数据和分区，对于全新安装，建议擦除硬盘现有内容。
3. “选择安装选项”、“接受适用的声明和许可条款”、确认“准备就绪，可以安装”，这几个步骤其实只需要一个组件即可实现自动化。
我们只需要添加 UserData 组件下的 AcceptEula 即可实现自动化。此外，如果当前安装源包含多个 Windows SKU，我们还需要配置 Windows 安装密钥，以及选择 Windows SKU。这块其实只需要添加 UserData 组件下的 Product Key 即可。
UserData 的配置内容如下：
注意：对于 SKU 的部分，也可以通过 InstallFrom 下的 MetaData 为含多 SKU 的安装源进行配置；此外，还适用于那些内置 OA3 的 OEM 设备。MetaData 的 Key 支持多种方式：
1. /IMAGE/INDEX
2. /IMAGE/NAME
3. /IMAGE/DESCRIPTION
其中，INDEX 是 SKU 在 Image 中的索引号；NAME 是名称，简体中文安装源中的如 Windows 11 专业版；DESCRIPTION 即描述。可根据实际的部署场景来选择使用。
OK，到这里即将大功告成！最后我们添加最后一个组件的配置，即 Image Install 下 OSImage 的 InstallToAvailablePartition，将其设置为 true。如果不配置系统要安装的目标位置，将会在“选择安装 Windows 11 的位置”这个步骤暂停，要求用户确认。当然我们也可以通过 InstallTo 进行配置，但二者只能选一种方式。
现在所有的应答自动化配置均已完成，你没有看错就是这么精简。把这个 Autounattend.xml 拷贝到 U盘或集成到 ISO 中即可在物理机或虚拟机上实现自动化安装。
对于 Windows 11 24H2 Arm 的定制化部署我们才刚刚开始……
HOWTO: 解决 Windows 11 24H2 Hyper-V VM 中 Windows DHCP Server 无法分发 IP 的问题
HOWTO: 解决 Windows 11 24H2 Hyper-V VM 中 Windows DHCP Server 无法分发 IP 的问题
gOxiA 今天要分享的是近期遇到的一个 DHCP Server 和 Hyper-V VM 相关的棘手问题，环境其实很简单！宿主机系统为 Windows 11 24H2，安装了 Hyper-V 并创建了 Private Switch 用于 VM 之间通信，VM 分别是一个 Windows Server 2025（以下简称 WS2025）和一个 Windows 11 24H2（以下简称 Client），其中 WS2025 基于工作组环境，并安装了 DHCP 和 WDS Role，在 DHCP 上配置了一个作用域，WDS 主要提供 PXE Boot。检查各项服务和日志都没有异常，但是很奇怪！通过另一个 VM 执行 PXE Boot 时失败，没有任何服务器响应。之后进入这个 VM 的 Windows 11 24H2 系统，发现无法获取 IP，但是如果手动配置 IP，Client 即可以 Ping 通 WS2025。为了排除 WS2025 DHCP 问题，又导入了以前能够正常使用的 VM 模板，其 DHCP Server 基于 Windows Server 2016，但仍旧无法正常分发 IP，只能手动配置 IP 进行通信。为了进一步的测试验证，又安装了一个 Ubuntu Server 24.04.1，并配置了 DHCP 和 PXE，却能够正常工作。
到底是哪里出了问题呢？！
怀疑过 Hyper-V 自身配置，Hyper-V Virtual Switch 是基于软件的第二层以太网网络交换机，包括了以编程方式管理且可扩展的功能，还提供了安全、隔离和服务级别的策略。对应的 Virtual Network Adapter 也提供了丰富的功能选项，在检查并测试了它们的相关功能选项后，均没能解决。
也怀疑过是 Hyper-V 宿主 Windows 11 24H2 自身的问题，但苦于重装系统麻烦，所以最终选择用抓包的方式排查，抓包的方案是直接在 WS2025 中安装 Wireshark 并执行抓包。非常神奇！在进行抓包时 WS2025 竟然能够正常分发 IP 了，从截图可见 DHCP Offer 和 DHCP ACK，其中 DHCP Offer 表示 DHCP Server 正确接收到请求并发出响应，DHCP ACK 表示 DHCP Server 确认 IP 租用成功。
为什么 Wireshark 抓包时 DHCP 就能工作正常呢？！
1. Promiscuous Mode，抓包时 Wireshark 将网卡置于混杂模式，让它可以接收所有流经网卡的流量，包括目标不是本设备的数据包（如广播包）。
2. 绕过硬件的 Offload 功能，暂时禁用如 UDP/TCP Checksum Offload，可以让我们捕获到未处理过的原始数据包。
3. 调整网络堆栈行为，以强制网卡处理所有数据包。
如何做进一步的排错呢？！
前面提到开启 Wireshark 抓包时 DHCP 可正常分发 IP，说明当前 WS2025 的 DHCP Role 配置正确，且工作正常；Ubuntu Server 默认可正常执行 DHCP 分发，可排除 Hyper-V Virtual Switch 配置；那剩下的就是为 VM 配置的 Virtual Network Adapter 了，前面在 Hyper-V 控制台对 VM 的虚拟网卡进行过调整测试，均未能解决。剩下最后的就是 VM 系统环境中的 Microsoft Hyper-V Network Adapter 驱动部分的高级选项了。经检查包含以下可以的选项。
1. IPSec Offload
2. IPv4 checksum offload
3. Jumbo Packet
4. Large Send Offload Version 2 (IPv4)
5. Large Send offload version 2 (IPv6)
6. Network Direct (RDMA)
7. Packet Direct
8. Receive Side Scaling
9. Recv Segment Coalescing (IPv4)
10. Recv Segment Coalescing (IPv6)
11. RSS Profile
12. TCP Checksum offload (IPv4)
13. TCP Checksum offload (IPv6)
14. UDP Checksum offload (IPv4)
15. UDP Checksum offload (IPv6)
结合前面 Wireshark 抓包时的情况，重点锁定在以下三个方面：
1. Large Send Offload Version 2，将大数据包的分段操作卸载到网卡硬件上，提高性能。对于 DHCP 这类的广播流量，分段操作可能不适用，如果网卡在广播包处理上有问题，可能导致 DHCP Discover 丢失。
2. Recv Segment Coalescing，将接收的小数据包合并成更大的包以减少处理次数。广播包可能在合并过程中丢失或被延迟处理。
3. UDP Checksum Offload，将 UDP 数据包的校验和计算卸载到网卡硬件上。DHCP 使用 UDP 协议，如果校验和计算错误，可能导致 DHCP Discover 被识别为无效包。
在研读 Hyper-V Switch 技术文档时留意到不同操作系统版本中，其 NDIS 版本也有所不同，果然在“Introduction to NDIS 6.89”一文中了解到 Windows 11 24H2 使用的便是 NDIS 6.89，而在功能更新中提到了“UDP Receive Segment Coalescing Offload (URO)”，从 Windows 11 24H2 开始，UDP接收段合并卸载使网卡能够合并 UDP 接收段，即将来自同一流中匹配一组规则的 UDP 数据报组合到一个逻辑上连续的缓冲区中。然后，这些组合的数据报将作为单个大数据包指示给 Windows 网络栈。合并 UDP 数据报可降低在高带宽流中处理数据包的 CPU 成本，从而提高吞吐量并减少每个字节的周期数。看来非常适合游戏服务器、实时视频流传输和PXE Boot。
此外，在文中 Checksum validation and indication 部分的阐述，也给出了进一步的排错方向。OK！至此顿悟，一番折腾后问题也终于解决。
HOWTO: 统一配置管理 Copilot Key
HOWTO: 统一配置管理 Copilot Hardware Key
最近 Intune 新增功能公告中提到 Windows 设备目录提供了新的设置支持 - 即 Set Copilot Hardware Key，我们可以在 Windows 设置目录中找到。如果希望使用 CSP 直接进行配置，可以在 WindowsAI 部分找到 SetCopilotHardwareKey，当然也同样支持 GPO。之前 gOxiA 也有分享一篇相关的日志“HOWTO: 管理 Windows 上的 Copilot”，而今天 gOxiA 要分享的是如何自定义这个按键。
为什么要定义此按键的故事是这样的！
首先 Copilot Hardware key 是什么？如果最近了解过微软新发布的 Copilot+ PC（PS：在国内叫 Windows 11 AI+ PC），一定不会对它感到陌生，即键盘上的 Copilot 按键，就像我们一直在使用的 Win 按键一样，Copilot 按键也是一个功能键。目前大家已经能在很多设备的键盘上看到这个按键。
在允许使用的区域，当我们可以按下 Copilot 键便可快速启动 Microsoft Copilot 应用，如下图所示。否则（PS：例如在国内）此按键当前只能快速启动搜索功能。
如果我们已经安装了其他 AI 应用，或在组织内部署了自研的 AI 应用，则可以利用上这个按键来实现快速的程序调用，这样就能充分利用起这个按键。微软在最新发布的 Windows 11 版本中提供了这一支持，对于普通用户，可以打开 Windows 设置，点击左侧导航栏中的“个性化”，在右侧窗格中找到“文本输入”选项，进入即可看到“在键盘上自定义 Copilot 键”，在列表中我们可以通过自定义选择已经安装的应用，但目前我们仅能看到有效的应用程序允许在这里被使用。
对于那些需要标准化配置的组织，可以通过 Intune 或 GPO 进行集中配置。首先我们看一下 Intune 的配置方法，这也是前面 gOxiA 提到的 Intune 在 11月新增的功能之一。为设备创建配置文件，平台选择“Windows 10 and later”，配置文件类型选择“设置目录”。
之后，为该配置文件创建一个便于设别的名字。
下一步后，我们便可以在设置目录中搜索“Copilot”，在“Windows AI”类别下即可找到“Set Copilot Hardware Key”选项。在配置数据框中我们输入应用的 AUMID 即可，它允许我们添加所有设备上安装的应用。本例中 gOxiA 添加的是一个 PWA 类型的应用。要获取 AUMID 可参考“查找已安装应用的 AUMID”。最后跟随向导完成后续的配置文件创建步骤即可，至此 Intune 的配置过程也就完成了。
如果你使用的是其他 MDM 平台，可以参考 CSP - SetCopilotHardwareKey 进行配置。具体配置如下：
./User/Vendor/MSFT/Policy/Config/WindowsAI/SetCopilotHardwareKey
format: string
对于还在使用传统管理模式的组织，可以利用 GPO 进行配置，参考如下：
用户配置 - 管理模板 - Windows Copilot - 设置 Copilot 硬件键
最后也分享给大家注册表的位置：SOFTWARE\Policies\Microsoft\Windows\CopilotKey
通过自定义 Copilot 按键我们可以很轻易的利用起它，尤其是针对国内的用户。
