一些值得关注的 Windows Autopilot 新增功能
一些值得关注的 Windows Autopilot 新增功能
在微软最近发布的一篇文档中“Windows Autopilot 新增功能 | Microsoft Learn”我们需要留意到一些重要的信息，它将有助于我们顺畅成功地实施 Windows Autopilot。
1. One step removal of Windows Autopilot registration
从 Intune 2307 版（可在 Intune 租户信息中确认当前版本），Windows Autopilot 过程中将添加删除设备注册的步骤，而无需事先通过 Intune Portal 进行操作。
这个功能看起来比较难以理解，其实主要用于解决已经执行了预预配和自部署的那些设备重新执行部署配置文件的问题。总之，在 gOxiA 看来，我们无需过度论证，它主要是改进了部署的成功率。
2. Device rename occurs during technician phase for pre-provisioning
从 Intune 2303 版开始，强制在 Pre-provisioning mode 的技术人员阶段进行设备重命名，以便为 AAD 联接设备进行预预配。这一改进，将设备重命名从用户阶段跳过。但需要 Windows 10 安装了 KB5023773，Windows 11 安装了 KB5023778 质量更新。
3. Install required apps during pre-provisioning
ESP（注册状态页）配置文件中新增加了一个选项，允许我们选择是否在Pre-provosioning阶段尝试安装所需的应用程序。理解其实还是比较困难的，在配置阶段我们可以设置在安装完所有应用和配置文件之前，避免用户使用设备。并且在发生错误后，可选重置或继续使用设备。此外，“如果已将所需应用分配给用户/设备，需要在安装完毕前阻止设备使用”，该选项默认是全部，但他们如果安装失败，则ESP将继续，并在用户登录时重试该应用。但现在，“如果已将所需应用分配给用户/设备，需要在安装完毕前阻止设备使用”，这个选项下多了一个“仅在技术人员阶段中失败的所选阻止应用”，如果选择“是”那些指定的应用必须被成功安装，否则部署失败。
4. New Microsoft Store apps now supported with the Enrollment Status Page
从2303开始ESP阶段将支持 Microsoft Store App(New)，这个比较容易理解，由于 Microsoft Store for Business 停用，阻止 IT 如果要部署应用商店内的应用都相继转至“Microsoft Store App(New)”，但之前在ESP阶段这些App并不会被安装比如进入到桌面后才会开始，而现在则完全不同。参考：“HOWTO: 在 Intune 中使用 Microsoft Store App(New) 添加应用”
5. Update to the Windows Autopilot sign-in experience
用户现在必须在注册期间初始登录时输入其凭据。将不再允许预先填充 AAD 的 UPN。这个更新到时有意思，记得早前很多用户喜欢减少 UPN 的输入，可能是现在考虑到安全隐私合规因素，又不再支持了。
6. Windows Autopilot diagnostics page
在使用 Windows Autopilot 部署 Windows 11 时，如果遇到错误，用户可以查看有关其详细故障排除信息。提供了新的诊断页面，非常友好的视图来方便我们排除故障，同时也可导出日志进行分析。
本次分享就到这里，其中主要包含了 gOxiA 关注的信息，若要了解详细的内容还请移步：“Windows Autopilot 新增功能 | Microsoft Learn”
加深对 Windows Autopilot 方案的认识
加深对 Windows Autopilot 方案的认识
Windows Autopilot 作为 Windows 现代部署方式逐渐受到各类企业 IT 的青睐。它不用再像传统部署方式那样要求IT为每个设备型号维护自定义映像和驱动程序。Autopilot 将使用 OEM 优化版本的 Windows，即设备首次开箱直接基于随机系统进行配置，使其达到企业所需要的交付标准。这一过程消除了IT执行这些后端过程的需要，从而节省了时间并可以更快更灵活地将设备交付给员工。
Windows Autopilot 不需要推送系统映像，它就是借助了 Intune 管理设备的强大功能和特性，将应用程序、策略设置、证书、VPN、Wi-Fi等常用的企业标准化配置通过 Internet 推送给设备端，而无需依赖企业内部的基础架构。Windows Autopilot 可以看作是 Intune 的一项功能或者子集，如同其名字一样 Autopilot 旨在 OOBE 阶段引导用户执行正确的配置流程。
一台已经注册到 Windows Autopilot 的全新 Windows 设备被寄送到了用户手中，用户拆箱打开设备加电将会进入 OOBE，即大家所说的欢迎界面，它将引导用户完成基本配置（区域、键盘和网络配置），然后提示用户输入公司账号和密码进行设备的配置，一旦验证成功将通过当前连接到互联网的网络从 Intune 中下载前面所讲的企业标准化配置直至结束，进入系统桌面后用户会发现系统已经被配置为企业的标准化桌面环境，甚至可以直接打开 Outlook 处理邮件，打开 OneDrive 访问自己的工作文件，使用 Teams 进行远程交流，连接 VPN 访问公司网络。而这一过程就是 Windows Autopilot 方案中的“用户驱动模式 - User Driven mode”，主要用于单个用户的设备部署，由用户运行部署。
在实际交付场景中，由于用户可能处于不同的网络环境下，当推送的应用程序容量较大的时候，也就意味着等待时间变长，可能会对用户体验有所影响，甚至会导致部署异常或失败。那么桌面交付决策人可能希望那些流转回 IT 服务台的设备，能够借助 IT 人员之手去执行标准化配置，或由OEM/经销商交付的设备去完成企业标准化配置。但这一过程又不要涉及到最终用户隐私（例如IT或OEM或经销商必须获取用户的权限即可完成配置），也避免了配置人员的账户信息及数据残留在用户设备上的可能。此时，IT/OEM/经销商人员在设备首次运行时，即 OOBE 阶段无需进行用户验证，只需要连续按下五次Win键，便可直接从 Intune 获取企业标准化配置。这一方案即 Windows Autopilot 中的 “预预配模式 - Pre-provisioning mode”。它相比较用户驱动模式的特殊之处在于无需用户身份验证，这就需要设备除了已经注册到 Windows Autopilot 外，还需要拥有 TPM 2.0 实现设备验证。预预配置模式也用于单个用户的设备，部署由IT/OEM/经销商发现，无需用户。
对于那些专用设备，如多用户使用的共享电脑或展台电脑，更希望能实现设备摆放到位后开机即可完全自动化地去执行部署。这一方案即 Windows Autopilot 中的“自部署模式 - Self-Deploying mode”。它将完全自动化 OOBE 阶段，包括那些区域、键盘和网络配置，并基于设备身份进行验证，所以自部署模式除了要求设备已经注册到 Windows Autopilot 和 TPM 2.0 外，还需要连接到有访问互联网的有线网络。这样当设备首次开机后便直接联网与Intune通讯进行设备验证，并根据自部署模式配置文件实施自动化操作和后续的标准化配置。
以上便是 Windows Autopilot 常用的三个方案：用户驱动模式、预预配模式、自部署模式。此外，Windows Autopilot 还有两个方案：面向现有设备的 Windows Autopilot（Windows Autopilot for existing devices），Windows Autopilot 重置（Windows Autopilot Reset）。
面向现有设备的 Windows Autopilot 方案本身在技术上不是 Autopilot 部署，它是在准备运行 Autopilot 部署的设备上完全重新安装 Windows 的方法。它不需要提前注册为 Autopilot 设备，并且可以使用自定义映像，可以像传统模式那样使用 MDT 或 ConfigMgr 任务序列，通过 JSON 文件将仅能使用 Autopilot 的用户驱动模式分配给设备，所以它与受支持的 Autopilot 标准方案一起使用。除非设备已经被分配了 Autopilot 配置文件，才能支持预预配模式和自部署模式。
Windows Autopilot Reset 也比较容易理解，允许远程发起设备重置的操作，即复位当前设备环境，重新执行标准化部署，这对那些设备再分配，或执行人员角色变更更为合适。当然也可用于修复那些系统环境有损坏的场景使其恢复至就绪状态，但如果 Windows 安装中存在严重损坏，这个方案将不起作用。
OK，至此相信你已经对 Windows Autopilot 有了进一步的深刻认识。记住 Autopilot 不会分发/推送操作系统映像，所以一个经过优化的、纯净的 OEM 随机系统显得至关重要！！！其三个标准方案：用户驱动模式、预预配模式、自部署模式，应用于不同交付场景，但对硬件和网络会有要求。
通过 Intune 控制 Windows 设备的位置服务
通过 Intune 控制 Windows 10 设备的位置服务
在 Windows 中提供了一个“查找我的设备”的功能，可以帮助我们找到这些设备的位置，并根据情况锁定它。注意：该功能仅适用于 MSA 类型的账号。我们可以访问 https://account.microsoft.com/devices 来使用这项功能。具体可参考：“查找并锁定丢失的 Windows 设备”。“查找我的设备”基于位置服务，当位置服务被启用后，其他应用程序也将有访问设备位置的权限，除非我们在隐私逐个对访问位置服务的应用进行配置。
对于使用 Intune 的组织如果希望禁用位置服务，则可以使用 Windows 设备配置文件，有两种方案：
1. 创建一个基于“设置目录”的配置文件，我们可以在“系统”下找到“允许位置”配置项。
允许位置有三个模式：
1）强制关闭位置。所有位置隐私设置将关闭并显示为灰色，用户无法更改。
2）允许使用位置服务。用户具有控制权，可以启用或禁用“位置隐私”设置。
3）强制打开位置。所有位置隐私设置都已切换并显示为灰色，用户无法更改。
当配置为强制关闭位置后，Windows 隐私中的位置将被禁用，将如下图所示。
我们也可以通过添加 CSP 策略来实现，具体为：
./Device/Vendor/MSFT/Policy/Config/System/AllowLocation
格式：Int
值：0 Force Location Off；1 default，Location service is allowed；2 Force Location On
参考：Policy-CSP-System#system-allowlocation
在 Intune 设备管理中也提供了“定位设备”的功能，并且它除了支持 Windows 平台外，还支持 Android Enterprise 以及 iOS/iPadOS，并且提供了更丰富的功能。如果你有兴趣可参阅：Intune 定位设备 | Microsoft Learn
最后，我们通过一篇官方KB了解一下 Windows 位置服务和隐私。
