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 也会与大家分享设备准备策略的上手。
HOWTO: 通过 Intune 配置 Windows 客户端拒绝向移动存储写入数据
HOWTO: 通过 Intune 配置 Windows 客户端拒绝向移动存储写入数据
在企业环境下一些 Windows 客户端将受到严格的管控，尤其是在一些涉及敏感数据的场景中，通常需要禁止将本机数据写入到 USB 等移动存储设备中，以避免数据泄露。如果企业正在使用 Intune 管理这些客户端和策略，那将很轻松的能够实现这些需求，并且提供了更为灵活全面的管控方案。今天就跟随 gOxiA 来做这个配置实践，首先登录 Microsoft Intune 管理中心，进入“设备 – Windows - 配置文件”，然后“创建”配置文件，“平台”这里选择“Windows 10 和更高版本”，“配置文件类型”选择“设置目录”。
进入“创建配置文件”向导页面，先为配置文件填入一个名称，本例为“Deny Removable Storage Write Access”。
然后，找到“Storage”类别（也可以通过搜索找到），然后选中“Remove Disk Deny Write Access”，之后将左侧内容窗格中的配置启用 - “Enabled”即可。
OK！到这里主要配置完成，是不是非常轻松便捷！但是我们从备注中可以了解到，一旦启用该配置，将拒绝所有移动存储的写入。对于那些希望允许将数据写入移动存储已启用 Bitlocker To Go 的组织，则建议改用“Computer Configuration\Administrative Templates\Windows Components\Bitlocker Drive Encryption\Removable Data Drivers”进行配置，如果希望改用则继续关注后面的截图。
我们可以搜索“Bitlocker”分类，找到“Administrative Templates\Windows Components\Bitlocker Drive Encryption\Removable Data Drives”，勾选“Deny write access to removable drives not protected by Bitlocker”，这里我们应当留意它的子选项“Do not allow write access to devices configured in another organization”，这将禁止写入到非授权的设备，即使它已经使用 Bitlocker。此外，我们还要注意，这个分类配置会被前面的“Remove Disk Deny Write Access”覆盖，所以不能同时配置。
OK，一旦决定采用的限制方案即可完成配置进入配置文件分配的页面，最后宣告完成。
如果您希望创建更为复杂的限制策略，可以搜索“Removable”，在“Removable Storage Access”分类中提供了多达38个策略，其中我们可以使用“Custom Classes”为特定设备配置禁止访问的权限。通过“Device Installation Restrictions”还可以允许安装特定的设备进行更为复杂全面的管控，多管齐下的方案总有能够适配组织安全需求的。
最后，如果我们推送了“Remove Disk Deny Write Access”策略，并希望在客户端上验证是否应用了该策略，可以通过事件日志查看器找到“Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider”，并查阅事件ID813的日志，其中能够看到相关的记录。
