为企业部署 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 的消息，有机会要试试到时与大家分享。
微软发布 Windows 部署"四部曲"
微软发布 Windows 部署"四部曲"
今天这篇日志不是一篇纯技术分享，只是四个微软官方文档的推荐，非常适合那些计划部署 Windows 11、Windows 365 以及 Azure Virtual Desktop 的 ITPro，这仅是三部曲，那第四部其实是使用 Configuration Manager 执行 In-place upgrade（就地升级）。整个文档采用了带入式体验，提供了精心设计的学习内容，同时还与阅读者互动，甚至可生成用于部署的脚本，使大家能够更深入投入到文档学习和部署实践中。
下来让我们一睹芳容！
Windows 11 setup guide，其中还蕴藏了很多相关产品/服务的 setup guide，内容十分丰富，绝对是宝藏级手册！
Windows 365 Enterprise deployment checklist，根据不同的部署选项，对不同检查进行分类并根据优先级进行说明。
Azure Virtual Desktop setup guide
In-place upgrade with Configuration Manager，跟随向导学习相关的知识内容，并提供部署相关信息，便可在最后生成部署脚本导入到我们的CM中进行实践。
即可行动起来！！！
HOWTO: 为基于 Windows 10 的 ADK 提供 UFS 支持
HOWTO: 为基于 Windows 10 的 ADK 提供 UFS 支持
UFS - Universal Flash Storage（通用闪存存储），是我们常见的闪存存储设备的一个类型，虽然名字与 eMMC 和 SSD 相比有些陌生，但提到手机或平板电脑，相信大家就容易理解了，是的目前都广泛采用了 UFS 作为存储设备。UFS 在性能方面比 eMMC 要强很多，但低于最新的 SSD，但肯定强于早前的 SSD，相信在用手机做文件复制时一定有所感受，其性能还是非常强劲的。
UFS 目前也正广泛使用在 Windows 平板设备上，如果我们打开设备管理器查看磁盘驱动器可能并不会直观查阅到，但在存储控制器中可以清晰看到设备是否使用了 UFS 控制器（系统自带驱动）。如下图所示，该设备采用了 SAMSUNG 的 UFS 存储器。
查阅了三星官网了解到 KLUDG4UHGC-B0E1 是一款 UFS 3.1 制式的存储器，尺寸只有 11×13×0.8mm，1.2/2.5v，看来是相当轻巧和省电；性能也是不错的！
回到正题，如果买来的 Windows 设备预装的是 Windows 11，并且没有计划使用 Windows 10，那么可以划走这篇日志，否则跟随 gOxiA 往下走会有一些收获。
在企业环境下，IT 通常会使用 Windows ADK 作为桌面标准化的定制工具，有经验的 IT 会知道 Windows 10 的 ADK 是基于 Windows 10 2004版的，即 19041。如果我们使用该版本的 ADK 生成 PE 用于批量部署，会发现默认将无法识别 UFS 存储器，也就是说当我们用 PE 引导设备后将无法识别到硬盘！！！
那么我们该如何为基于 Windows 10 的 ADK 提供 UFS 支持呢？！前面讲过 UFS 控制器的驱动默认集成在 Windows 11 中，如果是缺少驱动支持，我们可以做旁加载，但实际测试发现在 Windows 10 ADK 的 PE 中是包含该驱动的，但为什么就不支持呢？！尝试将设备的驱动集成到 PE 也无济于事，看来应该与 Windows 10 操作系统本身有关。
查阅了网络文献了解到“自 Windows 10 2004（20H1 - 19041）开始就引入了对 UFS 驱动器的支持，在此版本之前的 Windows 10 版本中，对 UFS 驱动器的支持可能有限或不完全。”既然如此就印证了前面测试的结果，包含了驱动但可能不完全支持，那么既然当前设备支持 Windows 10 22H2 操作系统（OEM PE 的版本为 19041.2728），说明 Windows 10 理论上是可以支持 UFS 的，也许问题就出在了累计更新上。
由于 Windows 10 20H1 生命周期已经停止，所以可从 Windows Update Catalog 下载到的离线累计更新包（LCU）是有限的。查阅 19041.2728 发现其所对应的是 KB5023696，但该 KB 已经不再包含 19041 的相关说明和支持情况，仅支持 19042、19044和19045。但有提到如果脱机映像没有包含 KB5011543 (March 22, 2022)或更高版本的 LCU，则需要安装 KB5014032 (May 10, 2022 SSU)，经仔细复查发现其支持 2004 版 Windows 10，并提供了更新包。
万事俱备只欠东风 - 实践出成果！从 Windows Update Catalog 下载 KB5023696 和 KB5011543，然后使用 ADK 生成一个 PE 实例，Mount 这个 Boot.wim 文件到指定目录，然后使用 “Dism /add-package” 为 PE 集成更新；建议锁定更新“Dism /cleanup-image /image:c:\winpe_amd64\mount /startcomponentcleanup /resetbase /scratchdir:c:\temp”；最后 Unmount 确认写入修改。
使用已经集成更新的 PE 引导 UFS 设备，经测试已经可以识别 UFS 存储器，其 PE 系统版本为 19041.2728；Diskpart 的版本是 19041.964。
