Windows Autopilot device preparation 快速上手
Windows Autopilot device preparation 快速上手
前面 gOxiA 与大家分享了 Windows Autopilot device preparation 与 Windows Autopilot 比较，以及相关的演示视频，今天将快速上手 Windows Autopilot device preparation（以下简称：Device preparation）。
Device preparation 被誉为“下一代 Windows Autopilot”，但目前仍与现有的 Windows Autopilot 共存，由于底层架构进行了重新的设计，所以在配置准备等方面都发生了重大的变化，其中还包含一个重要的变化是不再依赖硬件哈希来进行预注册，这相对来说将会灵活很多，但是也意味着暂时无法使用自部署模式和预配模式（白手套）。
既然发生了变化，我们就要从基本条件和基本准备入手。首先了解一下基本条件：
- 支持 Windows 11 23H2 的 KB5035942 及更高版本
- 支持 Windows 11 22H2 的 KB5035942 及更高版本
- 仅支持 Entra ID，不支持混合模式
- 已经注册为 Autopilot 的设备将不受支持，所以要被测试的客户端需要先从 Autopilot 解除注册
接下来，我们将要创建两类组：一个特用于 Device preparation的设备组，以及用户组。该设备组主要用于应用和脚本的分配，也就是说在 Device preparation 阶段指定的这些应用和脚本将会被分配给该组的设备。此外需要为其分配一个特定的所有者“Intune Provisioning Client (f1346770-5b25-470b-88bd-d5744ab7952c)”。
用户组主要用于指定哪些用户将应用 Device preparation，它不再像以前那样通过硬件哈希来进行识别。（PS：本次测试 gOxiA 使用了同一个组 - Device preparation。）
现在，我们将要创建 Device preparation（设备准备）策略。从下图可以看到之前已经创建好的策略，通过点击左上方的“创建”按钮我们将开始一个新的配置文件。
点击创建后将启动一个向导，在简介部分我们可以了解其相关资讯以及指导。
在“基本信息”页中为该策略命名。
在“设备组”页中我们搜索并添加之前为其创建的设备组。（PS：该组中的设备将在 OOBE 阶段安装指定的应用和脚本）
在“配置设置”页中，首先配置“部署设置”，其中部署模式当前仅支持“用户驱动”；部署类型“单个用户”；联接类型“已联接 Microsoft Entra”；用户账户类型“标准用户”。
接下来配置“现成体验设置”，如下图所示，与 ESP 功能相似，可配置超时时间，自定义错误信息，以及是否允许用户在多次尝试后跳过设置，并允许是否显示诊断链接。
应用和脚本部分，受 Device preparation 当前限制仅支持 10 个要部署的应用和脚本，所以即使前面我们为特定的设备组分配了超过其数量限制的应用，在这里也只能配置10个。
配置以上信息后，接下来可以跳过“范围标记”页，如果没有特殊的需求。之后会进入到“分配”页。即 Device preparation 策略为哪些用户有效。它实际替代了之前 Windows Autopilot 设备的预注册。
最后在“查看+创建”页复查我们的相关配置，如果没有错误点击“保存”即使策略生效。至此，我们的 Device preparation 策略创建完毕，我们可以准备一个客户端设备进行测试。具体的过程可以参考已经发布的视频 Demo。
Windows Autopilot device preparation 与 Windows Autopilot 比较
Windows Autopilot device preparation 与 Windows Autopilot 比较
微软在今年5月下旬公布了 Windows Autopilot device preparation - 设备准备（以下简称Device preparation），在“Windows deployment with the next generation of Windows Autopilot”这篇文章中可以了解到基本概况。gOxiA 也在近期发布了 Demo 视频，感兴趣的网友可以从常用的社交应用访问观看。
从现有资讯来看，大家对 Device preparation 都存在不同的认识和看法，好在官方团队在不断地更新 Q&A。对于Device preparation，gOxiA 一反常态不再先做基本介绍，有需要的可以移步上方官方文档先了解，今天主要跟大家分享的是 Device preparation 与 Windows Autopilot 的常用特性比较，可以更好帮助我们去认识和了解 Device preparation。
- Device preparation 适用于 GCCH 和 DoD 主权云。未来还将在 21v 提供。而 Windows Autopilot 则支持更多种类的设备，例如：Hololens 和 MTR；并且还提供了更多可自定义的选项用于预配体验。
- Device preparation 当前仅支持用户驱动模式。而 Windows Autopilot 包含：用户驱动、预配置、自部署和现有设备。
- Device preparation 不需要为设备进行预注册。而 Windows Autopilot 需要先收集设备信息并注册到 Autopilot。
- Device preparation 需要管理员创建设备准备策略和一个以 Intune 预配客户端 为所有者的设备安全组。而 Windows Autopilot 除了需要预先注册设备外，还需要创建 Windows Autopilot 部署配置文件，以及注册状态页（ESP）。
- Device preparation 仅在 OOBE 期间基于设备进行预配，目前支持部署最多10个应用（LOB、Win32、MSStore、M365），和10个 PowerShell 脚本。而 Windows Autopilot 在 ESP 期间提供基于设备和用户的预配，且支持任意数量的应用程序。
- Device preparation 仅从 Windows 11 的 23H2 和 22H2 的 KB5035942 开始提供支持。而 Windows Autopilot 对所有当前支持的 Windows 11 和 Windows 10 提供支持。
- Device preparation 仅支持 Microsoft Entra 加入。而 Windows Autopilot 提供了混合加入支持。
- Device preparation 不支持 Windows Autopilot 重置。
- Device preparation 不支持 DFCI。
更为详细的内容，可参考：https://learn.microsoft.com/en-us/autopilot/device-preparation/compare
了解以上众多不同，整体看下来还是 Windows Autopilot 提供了更丰富的功能特性，支持也更加广泛。正如官方所讲，仍旧会持续投资 Windows Autopilot，并希望将基于 Windows Autopilot 配置文件和设备准备策略的两个方案并存一段时间！此外，Device preparation 底层体系结构不同，可提供改进部署体验的功能，例如不需要为设备进行预注册。也正因此已在使用 Windows Autopilot 部署的设备将不能同时通过设备准备策略进行部署，需要先从 Autopilot 中取消注册。
后续，gOxiA 也会与大家分享设备准备策略的上手。
为企业部署 Arm Client 做准备
为企业部署 Arm Client 做准备
随着 AI 端侧运行的兴起，以及更多的基于 ARM 平台的品牌设备发布，预计在未来会有相当体量的 ARM Client 进入企业环境。对于需要进行 Windows 桌面标准化交付的组织，ITPro 需要了解基于 ARM 的 Windows 部署差异，提早准备部署测试环境，当商用 ARM 设备上市后可以及时有效的进行实践。
在过去基于 ARM 的 Windows 设备将仅支持 Intune 这样的现代部署，以及 PPKG 这样的动态部署方法，对于使用映像执行传统部署的方案并不支持。但现在 Windows 11 最新版本（24H2）将开始全面支持基于映像方式的部署以及定制方案。
在最新发布的 Windows ADK 10.1.26100.1 中，Windows PE 的 Arm 版本支持 PowerShell、.Net 和 Arm 上的 x64 仿真（Arm64EC）。对于 Windows PE Boot WIM，可以使用 CopyPE 指定 Arm64 生成启动文件，便可在 Arm 设备上引导启动。
从 Arm64 的 WIM 文件看并没有什么“特别”之处。
硬盘分区方面，UEFI 建议分区布局仍旧适用于 Arm。其中 System (Boot) 分区建议 260MB，MSR 16MB，Recovery 2GB。
对于需要使用无人参与应答文件的 ITPro，当要为 Arm 的 OS WIM 生成编录文件时（.clg）则要使用 32位版本的 Windows SIM。基于 Arm 的 Windows 包含与 AMD64 Windows 相同的恢复环境，但 Arm 恢复环境下使用的工具必须与 Arm 兼容，此外 Arm WinRE 环境下是不支持 PowerShell 和 .NET 的。
如果打算使用 PXE 服务器，如 WDS 进行 WIM 的部署，需要导入 Arm64 的 Boot WIM，这一过程还会自动导入 Arm64 的启动文件。
系统定制方面 Arm64 与 传统 AMD64 过程一般相同，我们仍旧可以通过 Windows Setup 或 DISM 执行映像的手工安装。也同样可以 Mount WIM 文件并执行修改，Sysprep 以及 Audit Mode 也同样适用于 Arm64。
语言包以及按需功能也都保持一致，但注意对应 Arm 版本。驱动程序方面，由于 Arm 的驱动要少于 x86 平台，所以需要确保拥有完整的 Arm 设备驱动程序，并且应当注入到 PE 和 脱机映像中 。
此外，需要注意的是 Arm 平台不支持 FFU 方式，仅支持 WIM。
虽然目前微软尚未公开提供 Arm 版的 Windows 安装源，但如果你已经拿到了基于 Arm 的 Windows 设备，其实是可以通过 PE 离线方式捕获 OSImage 或导出设备驱动的。这样一来，就可提前进行传统部署的测试环境！
最后，虽然我们已经可以利用传统的部署方法来为 Arm 平台准备 Windows，但 gOxiA 还是极力推荐使用 Intune 的 Windows Autopilot 这种更现代的部署方案。一些 OEM 设备预装的 Windows 环境已经非常出色，整体干净整洁没有多余的程序或驱动附加应用，开机即可通过 Windows Autopilot 执行标准化部署，整个过程让人感到舒适轻松！最近看到 next generation of Windows Autopilot 的消息，有机会要试试到时与大家分享。
