使用 21v Microsoft Intune 部署 Windows 设备
使用 21v Microsoft Intune 部署 Windows 设备
今天的分享不会涉及太多技术细节，之所以会聊到这个话题是因为有不少网友咨询“21v Intune 不支持 Autopilot，无法部署 Windows 设备”！！！gOxiA 认为这句话一半对，一半错。为什么会这么讲的？！首先我们先了解一下 21v Intune（由世纪互联运行的Intune）中的功能差异，官方的描述如下：
由于中国境内的服务由中国境内的合作伙伴运营，因此在 Intune 中存在一些功能差异。
- 由世纪互联运营的 Intune 仅支持独立部署。 客户可以使用共同管理将其现有 Configuration Manager 部署附加到 Microsoft Intune 云。
- 不支持从公有云迁移到主权云。 有兴趣迁移到由世纪互联运营的 Intune 的客户必须手动迁移。
- 目前不支持租户附加功能（无需注册即可将设备同步到 Intune 以支持云控制台方案）。
- 由世纪互联运营的 Intune 不支持派生凭据。
- 通过使用现代 MDM 渠道支持 Windows 10 的管理。
- 由世纪互联运营的 Intune 不支持本地 Exchange Connector。
- Windows Autopilot 和企业应用商店功能当前不可用。
- Microsoft Endpoint Manager 终结点分析和 Log Analytics 功能当前不可用。
- 由于 Google 移动服务在中国不可用，因此由世纪互联运营的 Intune 中的客户无法使用需要 Google 移动服务的功能。 这些功能包括：
- Google Play 保护机制功能（如 SafetyNet 设备证明）。
- 从 Google Play 商店管理应用。
- Android Enterprise 功能。 有关详细信息，请参阅此 Google 文档。
- 适用于 Android 的 Intune 公司门户 应用使用 Google 移动服务与Microsoft Intune服务进行通信。 由于 Google Play 服务在中国不可用，因此某些任务最长可能需要 8 小时才能完成。 有关详细信息，请参阅此文章。
- 为了遵守本地法规和提供改进的功能，Intune 客户端体验（公司门户应用）在中国可能有所不同。
- 隔离不可用。
- 移动应用管理 (MAM) 的可用性取决于这些应用在中华人民共和国的可用性。
- 由世纪互联运营的 Intune 不支持企业设备的 Android （AOSP） 管理。
- 由世纪互联运营的Intune不支持移动威胁防御 (MTD) 连接器，适用于 Android 和 iOS 设备的 MTD 供应商。
- 由世纪互联运营的Intune不支持合作伙伴设备管理与适用于 macOS 设备的 Jamf 集成。
原文来源：https://learn.microsoft.com/zh-cn/mem/intune/fundamentals/china | Microsoft Learn
gOxiA 特别对上文进行了标注，我们先来看 Windows Autopilot，这个功能其实理解起来还是比较难的，最终用户或企业IT会容易误解，甚至其内部人员恐怕也经常误解。从官方文档描述来看 Windows Autopilot 是一组用于设置和预配置新设备以让它们可供高效使用的技术，它为 IT 和最终用户简化了从初始部署到生命周期结束的 Windows 设备生命周期。其过程是最初部署新的 Windows 设备时，Windows Autopilot 使用 OEM 优化的 Windows 客户端版本。此版本预安装在设备上，因此无需为每个设备型号维护自定义映像和驱动程序。现有 Windows 安装可以转换为“业务就绪”状态，而不是重新映像设备，它可以：
- 应用设置和策略
- 安装应用
- 更改用于支持高级功能的 Windows 版本。例如，从 Windows Pro 到 Windows Enterprise。
部署后，可以使用以下方法管理 Windows 设备：
- Microsoft Intune
- 适用于企业的 Windows 更新
- Microsoft Endpoint Configuration Manager
- 其他类似工具
原文来源：https://learn.microsoft.com/zh-cn/mem/autopilot/windows-autopilot | Microsoft Learn
是否能理解 Windows Autopilot，比较抽象并且会先入为主出现一些误解！那再读读这篇 https://www.microsoft.com/zh-cn/microsoft-365/blog/2018/06/07/simplifying-it-with-the-latest-updates-from-windows-autopilot/
如果还是没能理解，好吧！我们从 IT 桌面交付这个维度来看，Windows Autopilot 解决了我们桌面标准化过程中的设备交付流程问题，引导设备和用户按照企业标准进行配置。
那回到我们的问题上来，21v Intune 没有 Windows Autopilot 是不是就无法做设备交付，或配置设备？不然，只是我们无法实现完整的，自动化的，引导式的交付流程。但对于我们的设备交付来讲，如果仅仅是为了满足能够基于 Internet 来推送 Windows 配置，安全策略，软件，甚至脚本……那么 21v Intune 完全可以支持，下面我们就用一张图来展示说明。
如果您有什么想法或问题，欢迎来询！
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 的支持。
