本站域名：http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问：http://goxia.maytide.net/m转载文章，请务必保留出处与作者信息，未经许可严禁用于商业用途！
体验新的 Windows 程序包管理器
体验新的 Windows 程序包管理器
微软在 Microsoft Build 2020 大会上公布了 Windows Package Manager （Windows 程序包管理器）预览版，它是一款工具，可以帮助我们自动化在计算机上获取软件的过程。对于企业 IT 人员来说，他的价值也非常巨大，现在只需一个简单的脚本命令即可通过互联网从软件库中获取到要安装软件的最新版本。
例如我们想安装 PowerToys，我们只需要输入“winget install powertoys”命令即可完成安装，而且整个安装过程将自动执行。
目前这个软件库构建在微软社区存储库中，我们可以使用“winget search”进行搜索可安装的软件，虽然目前类别和数量还较少，但相信更多的软件开发人员会加入进来，软件也就会更加丰富。除此之外，我们也可以构建一个本地清单，来部署软件。
此时，您可能会产生一个疑问，这个软件库直接信赖吗？！这是一个好问题，微软也考虑到了，所以会自动检查每一个清单，并利用 SmartScreen，静态分析，通过 SHA256 验证，以及其他一些过程来减少恶意软件进入存储库或计算机。
如果读到这里，您准备开始体验它，微软目前提供了三种方法。加入 Windows Insider 并安装最新版本的 Windows，该工具将内置在其中。或者加入 Windows Package Manager Insider，之后从微软应用商店安装“App Installer”。我们还可以直接从 Github 上获取到该工具的离线安装包，它是一个 appxbundle 格式的安装文件，可以从 https://www.github.com/microsoft/winget-cli 下载。
目前 Microsoft Docs 也提供了文档资料，如果您感兴趣将它应用在企业 IT 桌面交付过程，可以好好研读。
通过 Intune 为 Windows 10 设备自动配置邮件账户
通过 Intune 为 Windows 10 设备自动配置邮件账户
使用 Autopilot 我们实现了 OOBE 的自动化配置，为用户自动安装了应用程序，并下发了设备配置文件。当设备就绪，用户登录到 Windows 桌面，启动 Windows 10 内置的邮件程序，或 Outlook 后，将会提示使用当前登录账户配置这些邮件应用程序，虽然这样的设计已经非常便利，但对于一些用户来说，他们可能需要更人性化的配置方案，实现打开应用自动完成账户配置的过程。
利用 Intune 我们可以通过创建配置文件来实现这一需求，对于 Windows 10 内置的邮件应用可以创建单独类型的配置文件，为此访问 Microsoft Endpoint Manager 管理中心，定位到“设备 > 配置文件”，点击“创建配置文件”，然后选择“平台”为“Windows 10和更高版本”，“配置文件”选择“电子邮件”，然后点击窗格底部的“创建”。
在接下来的向导任务中，为这个配置文件起一个易于识别的名称，然后点击“下一页”。在“配置设置”页面下我们输入“电子邮件服务器”的地址，如：outlook.office365.com；“账户名”是显示在邮件应用中的配置名称；AAD用户名属性和电子邮件地址属性都可以使用“用户主体名称”，或者根据需要配置。此外我们还可以配置要同步的电子邮件数量，以及同步计划。如果您的组织允许使用Windows 10内置的联系人、日历和任务应用同步和管理 Office 365 Exchange Online的内容，则可以启用同步这些内容。具体参考如下图所示。
接下来要配置的就是将这个配置文件分配给谁，可以是指定的组或者是所有用户，或所有设备。
当配置文件下发后，用户打开 Windows 10 的邮件应用就会根据当前登录账号自动配置邮箱，如下图会遇到修复账户的提示，只需要点击修复即可。
Outlook via Exchange
对于 Outlook 我们可以创建管理模板配置文件（Administrative template profile）来实现基于 Exchange 服务的 Outlook 自动配置。仍然是创建一个配置文件，平台为“Windows 10 和更高版本”，配置文件选择为“管理模板”。接下来会发现这个管理模板就像经典的组策略一样，其实它就是沿用了 GPO 的概念和机制。我们只需要先选中“用户配置 > 所有设置”，然后搜索“smtp”就能看到两个配置项，这里我们选择“基于 Active Directory 主 SMTP 地址自动配置配置文件”，然后将其设置为“已启用”。
下发该配置文件后，当用户首次打开 Outlook 就会自动使用当前登录账户创建 Outlook 配置文件。
通过 Intune 配置文件的管理模板限制邮件拷贝到本地 PST
通过 Intune 配置文件的管理模板限制邮件拷贝到本地 PST
如果您是组织的 IT 管理员，正在使用 Office 365 和 Intune，且希望通过推送策略来限制用户客户端（Outlook）将邮件复制到本地的 PST 文件，那么现在可以通过 Intune “配置文件”下的“管理模板”来实现这一需求。
Intune 配置文件中的管理模板实现了之前 Windows GPO 的功能，除了可以配置 Windows 的计算机和用户配置，还可以使用已集成的应用策略对特定程序进行配置，例如：Microsoft Edge，Office 的 Word、Excel、Outlook 等程序。在过去 GPO 管理环境下，则需要先导入 Office ADMX 或 Edge ADMX。
今天 gOxiA 将演示如何配置管理模板来阻止用户在 Outlook 下将邮件复制或移动到本地 PST 文件。当用户复制邮件到本地 PST 时，粘贴（Ctrl + V）操作会失效；如果移动邮件到 PST 会提示错误，效果如下图。
具体的操作如下：
进入 Microsoft Endpoint Manager admin center (Microsoft 365 设备管理)，转到“设备” - “配置文件”，然后创建配置，“平台”选择 “Windows 10 and later”，“配置文件”选择“Administrative Templates”。
然后为配置文件起个易于识别的名称，如下图。
在配置设置下切换到“User Configuration”，展开至“Microsoft Outlook 2016 / 杂项 / PST 设置”，然后选中“禁止用户将新内容添加到现有 PST 文件”，将其配置为“已启用”。
之后将配置文件分配给特定的组，或所有用户。
最后审阅配置，并执行创建。
当应用到客户端上后，便会向客户端系统注册表写入相关键值，“HKCU\SOFTWARE\Policies\Microsoft\office\xx.0\outlook\pst”，增加名为“PSTDisableGrow”的键，“REG_DWORD”类型，值为“1”。
如果是 OCT 进行配置的，则该键值位于“HKCU\Software\Microsoft\Office\xx.0\Outlook\PST”。IT 管理员需要注意的是由于该键值位于“HKCU”下，会有潜在的安全影响。
参考文档：https://docs.microsoft.com/en-us/exchange/troubleshoot/outlook-policy/control-pst-use
BitLocker 自动设备加密
BitLocker 自动设备加密
想必大家都知道 BitLocker，可以帮助我们对磁盘数据加密，确保其在系统脱机时不会被篡改或窃取。迄今为止 BitLocker 仍然是公认的最为安全的磁盘数据加密技术之一，受到不少企业用户的青睐。现在当我们采购来预装有Windows 10的设备后，完成OOBE就会发现当前磁盘已经是加密状态，十分的方便。
那么这些 Windows 10 设备是如何确保 BitLocker 能够自动加密呢？！要实现自动设备加密硬件需要满足如下要求：
- 设备包含 TPM，包括 TPM 1.2或2.0。
- 基于 UEFI 启用。
- 已启用 Secure Boot。
- 已启用 DMA（直接内存访问）保护。
在 Windows 10 启用自动加密前，会进行如下测试：
- TPM 必须包括支持 PCR7 的 TPM
- 启用了 UEFI 和 Secure Boot
- 支持 Modern Standby 或 HSTI 验证
- 启动分区有 250MB 的可用空间
- 操作系统版本不应早于 Windows 10 1703
此外，需要注意的是仅当使用 MSA 或 AAD 账户登录，才会启用 BitLocker 自动设备加密特性。但这是否意味着如果我使用本地账号在符合 BitLocker 自动加密的设备上完成 OOBE 就会禁用自动加密呢？！
gOxiA 对此进行了研究和测试，实践表明在满足 BitLocker 自动加密的设备上，即使你在 OOBE 阶段用本地账号配置计算机，但之后系统还是会对磁盘进行加密，只是保护状态是未激活的。如果一些企业用户需要使用非 BitLocker 的磁盘加密保护，就需要考虑在标准化部署中禁用 BitLocker 自动设备加密。
为此，我们可以修改企业标准化映像的应答文件（Unattend.xml），添加 “Microsoft-Windows-SecureStartup-FilterDriver” 组件，并将 “PreventDeviceEncryption” 设置为 “true”。注意：该组件支持 offlineServing、specialize、auditSystem 和 oobeSystem 阶段。
我们也可以修改注册表来阻止 BitLocker 自动设备加密，同样是 “PreventDeviceEncryption”，REG_DWORD 类型，值为 1，其位于注册表 “HKLM\SYSTEM\CurrentControlSetControl\Bitlocker”，我们可以在 OOBE 阶段执行，即可停用自动加密。或者 IT 人员也可以编写脚本调用“Manage-bde –off [driverletter:]”命令关闭 BitLocker 加密。
通过排错 Intune for Education 80180014 了解 Intune 注册限制
通过排错 Intune 80180014 了解注册限制
今天 gOxiA 开通了一套教育版的 M365 测试环境，对其功能和特性进行简单和快速的体验。M365 for EDU 完全基于现有的 AAD、Intune 等云服务，在面向教育领域和其 IT 人员的操作页面等方面进行了优化，显得更为直观和友好。我们可以通过域名“https://intuneeducation.portal.azure.com”访问 Intune for Education 管理门户。当然也可以继续通过“Azure Portal”访问管理。
在 Intune for Education 门户，我们可以通过“启动快速配置”为教育场景完成了应用的分配和客户端系统的配置。对于国内一些学校，其 IT 人员通常都由计算机课老师担当，虽然有一定的 IT 基础，但由于行业不同在上手配置时可能还是会存在一些问题，所以 Intune for Education 提供了换一套非常便捷的配置向导，可以帮助学校 IT 人员快速继续配置。
接着 gOxiA 开启了一台安装有 Windows 10 Pro 1903 的虚拟机，在 Windows 10 的 OOBE 阶段通过“针对组织进行配置”进行了安装配置。这个过程非常简单。
但在开始进行配置时发生了错误，服务器错误代码给出的是 80180014，通过微软官方文档“MDM 注册错误值”查询到该错误代码是因为“不支持特定平台（例如Windows）或版本。此错误的一般解决方法是升级设备。”针对这一提示，gOxiA 首先想到的“难道是因为需要Windows 10 教育版才能注册到 Intune for Education？！”，但回过神一想，很明显这个“认为”是错误的！！！即使真的对 Windows SKU 有限制，也应该是后台某个设置中对其进行了配置，所以我们需要进入后台去找到它。
如果进入的是 Intune for Education 的管理门户，将无法找到这些设置，正如前面 gOxiA 所讲的教育版也同样基于 Intune，所以我们需要转到 Azure Portal 下的 “Microsoft Intune” 管理界面。如果你经常与 Intune 和 Autopilot 打交道，相信会了解到一项管理功能 - “注册限制”，利用该项功能 Intune 管理员可以创建和管理注册限制，例如限制用户的设备注册数量，或注册设备的操作系统和版本。这些系统可以是基于 Android 的，也可以是基于 iOS/iPadOS 或 macOS 的，当然也包括我们常用的 Windows，此外还可以针对这些平台的版本进行限制。除此之外，还可以对注册的设备类型进行限制，如：公司拥有的设备（COD），或 个人设备 即 自带设备办公（BYOD）。
针对出现的故障现象，对“注册限制”策略进行了检查，发现评估环境默认会阻止个人设备的注册，为此更改为“允许”，保存后生效速度很快，可以马上在客户端进行测试。
如果作为 Intune 管理员需要结合公司安规对注册设备继续限制，例如需要对注册的设备系统版本进行限制，则参考如下：
- Android 版本格式为：major.minor.rev.build
- iOS/iPadOS版本格式为：major.minor.rev
- Windows 仅对 Windows 10 支持 major.minor.build.rev（如：10.0.18363.657）
注：要按照厂商进行配置，则可以输入厂商名称并以逗号进行分隔。
引用参考：https://docs.microsoft.com/zh-cn/intune/enrollment/enrollment-restrictions-set
使用 Provisioning Packages 帮助企业 IT 人员快速交付 Windows 10 设备
使用 Provisioning Packages 帮助企业 IT 人员快速交付 Windows 10 设备
在前段时间 gOxiA 分享了一篇文章 - “虚拟环境下在 Windows 10 OOBE 阶段测试部署 PPKG”，详细介绍了如何在虚拟机环境下 OOBE 阶段测试 PPKG 的方法。并且还分享了一些重点知识。今天我们将介绍使用 Provisioning Packages（预配包）帮助企业 IT 人员快速交付 Windows 设备。
在过去的传统部署方案中，企业IT通常会根据组织的需求和规则策略重新定制标准化系统映像，在新设备到来后首先会进入 IT 桌面部门，通常会在 IT 服务台使用 WDS、MDT 或 SCCM OSD 等方案，重新为设备部署 Windows 操作系统。并且 IT 桌面部门还需要根据其他诸如业务或安全部门不断提出的新需求或变更重新生成映像。可以想象这是一件非常庞大且复杂的项目工作。
自 Windows 10 发布以来，提出了 WaaS – Windows 即服务的概念，随之为这一“现代桌面”提供了一系列的“现代部署”方案可满足不同场景的需求。在这些方案中，IT 人员可以利用“动态部署方案”轻松便捷地为企业交付新的 Windows 10 设备。
假设我们有一个场景，企业订购了一批新的 Surface 设备，其预装了 Windows 10 的专业版，随机搭载了 Office 应用程序，并且设备驱动也是内置的，由于随机系统非常干净，而且是最佳的运行状态，企业希望基于现有的系统进行定制和交付，由于 OEM 系统不支持映像的重新定制和生成，按照过去传统的做法企业IT桌面人员需要使用批量授权重新为 Surface 生成定制的企业标准化映像，这一过程所付出的工作量是相当繁重的，而且企业可能会重复使用专业版的授权。最后，企业IT桌面部门还需要不基于网络的部署。
在以上这种场景下，如何选择一种快速高效的部署方法呢？！
综合比较动态部署方案中的 Provisioning Packages（预配包）更容易满足这一部署场景的需求。利用预配包我们可以快速配置新的设备，而无需完成准备和安装新映像的过程；生成的预配包可以配置多个设备来节省时间；在准备和部署过程中不需要设备管理基础架构；预配包可以应用在没有网络连接的设备上。由于预配包是一个扩展名为 PPKG 的文件，我们可以多种形式进行预配包的分发，如：可移动磁盘，电子邮件，网络共享等。部署方式也随之灵活许多，除了可以双击预配包手动安装，也可以利用命令行编写脚本，尤为重要的是在 Windows 10 的 OOBE 阶段也可以应用预配包，这样一来我们就可以实现自动化的部署交付过程。
到这里，您可能希望知道预配包都能为我们做些什么？是否可以像以往的部署方案那样利用 Unattend 实现无应答安装和配置，加载一系列的脚本程序进行高级的自动化配置……等等？！
Provisioning Packages 为我们提供了丰富的预配设置选项，可以分配设备名称、输入产品密钥以升级 Windows，删除预安装的软件，连接到 WiFi，加入到 AD 或侦测到 AAD，当然也可以创建本地账号，还可以添加应用程序、证书……更多具体的细节可以参考微软官方文档。https://docs.microsoft.com/en-us/windows/configuration/wcd/wcd
那么我们如何生成预配包（Provisioning Packages - PPKG）呢？如果您是一位经验丰富的桌面标准化 IT 人员，应该知道 Windows ADK，其中的“配置设计器”（Windows Configuration Designer - ICD）便是 PPKG 的生成工具。我们也可以在“Microsoft Store”中安装它“Windows Configuration Designer”。
打开 ICD，默认会提供几个预配模板，如果是新手可以先从“预配桌面设备”开始，它提供了向导式的配置过程，可满足基本需求。通常 gOxiA 会使用“高级预配”来创建 PPKG 以满足不同的需求。
在“高级预配”模式下，通过左边提供的配置项来进行预配设置，如果您所需的需求未能满足，则需要考虑配合其他方法，如：命令行、脚本……或基于 AD 的组策略进行后续的配置管理。当预配包设计完毕后，就可以利用导出功能生成 PPKG 文件，在生成过程中我们可以为预配包起一个便于识别的名称，版本号会根据每次生成递增，利用“所有者”和“等级”我们可以为当前预配包设置优先级别。
创建好的PPKG就可以按照前文介绍的那样以不同形式分发给用户，或在 OOBE 阶段应用。
正确认识和理解 Windows Hello 的人脸验证
正确认识和理解 Windows Hello 的人脸验证
今天 gOxiA 来分享这个话题的起因是因为回到家中按照社区要求需要独自隔离14天，所以也就一直没有刮胡子，今天是最后一天于是一早在微信上发了一条关于 Windows Hello 的信息，说自己即使满脸长胡子也能够被 Windows Hello 识别出来，感觉非常惊喜。也正是因为这条信息，了解到圈里的一些朋友对微软的 Windows Hello 没有正确的理解，一直认为是与市面上其他识别技术一样采集“用户的图像”来进行比对认证，所以 gOxiA 认为非常有必要整理一下 Windows Hello 的知识，让广大用户正确认识 Windows Hello。
本文不会做与其他识别技术的对比和分析，只从 Windows Hello 和 Surface 设备角度来进行介绍。
相信大家有知道 Surface 的都会了解其出彩之一的功能特性就是带有支持 Windows Hello 人脸识别的红外摄像头（近红外传感器），通过 Windows 10 中的 Microsoft人脸身份验证（一种企业级身份验证机制）可以用来进行身份验证和解锁 Windows 设备，而且现在已经支持解锁 Microsoft Passport（在使用微软账号访问相关服务时可通过人脸识别进行登录验证）。
那么在使用 Surface 的近红外成像摄像头（IR Camera）通过 Windows Hello 进行人脸识别登录时是怎样的一种机制或者说过程呢？！其会有普通大众所担心的安全问题吗？因为从开篇曾提到 gOxiA 的一些朋友会认为“这是一种采集更多人脸图片来进行比对的一种功能”，恐会担心隐私问题。那么接下来我们先了解 Windows Hello 的运行方式。
首先，用户需要发起一个脸部识别的注册，如下图在 Windows 设置中找到 账户 设置，里面有个 登录选项，你就能看到 Windows Hello 人脸，它就是人脸识别注册入口。
接下来 Windows Hello 会通过 Surface 的 IR Camera 识别人脸，其算法将检测 IR Camera 中的用户面部，然后找到与眼睛，鼻子，嘴巴等相应的面部界标点（也称为对齐点）。为了确保算法有足够的面孔来做出认证决策，还会识别头部的方向。然后使用地标位置作为锚点，这种算法将从人脸的不同区域获取数千个样本来构建表示，其基本形式的表示即直方图，表示特点点周围的明暗差异。
可以理解，以上过程中通过人脸识别出来的只是一种“代表”，不是存储脸部的图像。通俗理解就是利用算法识别出当前脸部特征用作后续的验证，这一过程是生成自己的一个表示或一组表示的步骤（例如，如果我们有眼镜，则可能需要在不戴眼镜的情况下进行注册），这种表示形式的集合称为我们的注册资料，并存储在本地系统上以备将来比较。
所以呢，进一步的认识是：微软不会且永远不会存储实际的图像来用于对比验证。而且，这些注册数据也不会发送到网站或应用程序进行身份验证。当然，也不用想什么脸部注册漫游了，不要指望换台电脑登录账号就能直接启用脸部识别，需要在当前设备的 Windows 系统上重新注册以生成脸部特征表示。
接下来，当我们要通过 Windows Hello 进行人脸识别登录时，只需要面对 Surface 的 IR Camera，其会将获取的当前面部特征表示与当前设备系统上的已注册用户进行比较，该表示形式必须超过机器学习的阈值，然后算法才能将其接受为正确的匹配项。
前面，我们提过在过程中要生成自己的一个表示或一组表示步骤，其中的"一组"表示步骤会发生在以下几个情形中，此时我们可以通过“提高识别能力”再次进行识别，例如摘掉眼镜做一次识别。
- 偶尔戴某些类型的眼镜
- 面部形状或质地发生了重大变化
- 转移到周围环境光线较近的红外光下（例如：设备在室外阳光下）
转回 Surface 来说说它采用 IR Camera 的好处或优势，可以通过下面几张图来进行了解。
在以弱光为代表的如看电视或做PPT演示文稿情景下，使用普通摄像头和 Surface 近红外摄像头获取到的图像如下，可以看出 IR Camera 不会受到弱光和摄像头彩色成像系统的影响，能够生成清晰的图像。
（普通摄像头获取到的彩色图像） 
（IR Camera 获取到的红外图像）
下来，再看看如果在窗户或台灯前受到侧面照明时的情景，图像如下，IR Camera 仍能生成清晰完整的图像。
（普通摄像头获取到的彩色图像） 
（IR Camera 获取到的红外图像）
此外，由于使用了 IR Camera 还可以防止图像欺骗，因为红外采像时物体的波长会有所不同，也就是说你拿一张人像照片在 IR Camera 下是获取不到照片中的人像的，只能生成照片这个物体的外观，而其他材质下也是一样，例如手机的屏幕或者电脑屏幕。如下图所示：
在测量精度方面，微软的 Windows Hello 又是如何做的呢？！它使用了三种主要度量：错误肯定，正确肯定，错误否定。
- 错误肯定：有时也被计算为错误接受率，表示获得对你设备的物理访问权的随机用户被识别为你的可能性。该数字应尽可能的低。基线为小于0.001%或1/100000FAR。
- 正确肯定：即：真实肯定率，表示用户每次位于传感器前面时，将正确匹配其已注册个人资料的可能性。该数字应该尽可能的高。基线为单个注册用户大于95%。
- 错误否定：表示用户与他们的注册个人资料不匹配的可能性。该数字应尽可能的低。基线为单个注册用户不到5%。
考虑到测量误差非常重要，因此微软还通过两种方式对它们进行了分类：偏差误差（系统误差）和随机误差（采样）。
- 偏差误差：由于不使用 代表使用算法的环境和条件的数据，可能会导致偏差错误。此类错误可能是由于不同的环境条件（例如：照明，与传感器的角度，距离等）以及硬件导致的。
- 随机误差：随机错误是由于使用的数据与实际使用该功能的总体多样性不匹配而导致的。（例如：专注于少数没有眼镜，胡须或独特面部特征的脸部。）
通过以上内容的学习和理解，希望有助于大家正确认识 Windows Hello，排除误解。我们要知道 Windows Hello 的人脸识别技术不是靠存储图像来进行比对分析的！！！“Windows Hello 是科学、智能、严谨、合规，具备操守的。-- gOxiA”
虚拟环境下在 Windows 10 OOBE 阶段测试部署 PPKG
虚拟环境下在 Windows 10 OOBE 阶段测试部署 PPKG
当 IT 人员通过 PPKG (Provisioning Package - 预配包)来实现 Windows 10 的动态部署时，不免要对 PPKG 进行测试已验证是否达到预先设计的目标，通常我们会在管理员工作站上常见 PPKG，然后拷入到 U盘或网络共享中供目标设备测试或使用，但由于 PPKG 会对系统进行配置，虽然其提供了卸载功能，但一些特定的设置仍然会保留在系统中，如此反复会增加 IT 人员的成本。
利用虚拟环境，如虚拟机能够很好的帮助我们来进行测试验证，我们可以创建一个干净的环境状态下创建一个检查点，然后再应用 PPKG，当需要的时候还原检查点便可以从头开始。
但是，如果我们需要在 Windows 10 OOBE 阶段测试部署 PPKG 呢？常规的做法是将 PPKG 拷贝到可移动媒体，如 U盘上。（注意：PPKG必须存储在 U盘的根目录下），然后启动目标设备进入 OOBE，然后插入包含 PPKG 的 U盘，此时会自动开始应用 PPKG。当需要重复测试时，我们需要耗费大量的等待时间来重置 Windows 10 安装，使其恢复到最初的状态，重新开始 OOBE。
你可能会想到利用虚拟机（Hyper-V）来实现方便快捷的测试，但接下来会发现由于不能添加虚拟的 USB存储设备，将导致无法检索到 PPKG。也许你也跟 gOxiA 有一样的想法，将 PPKG 拷贝到一个虚拟磁盘根目录下，并加载到虚拟机中，然后在 OOBE 界面上连续按下五次 Windows 键来激活配置选项，但结果并不能如尝所愿，因为“安装预配包”向导无法检索到这个 PPKG。或者，你会考虑使用 DISM 或 PowerShell 命令来应用 PPKG，但由于处于 OOBE 这个特殊阶段，将会无法正常应用 PPKG。
难道，我们就没有办法了吗？？？！！！
其实，在 OOBE 阶段除了能够自动识别 U盘和 SD卡这类的可移动媒体外，还支持光盘驱动器。没错，我们可以利用虚拟机中的虚拟光驱来实现我们的需求，只需要为 PPKG 创建一个 ISO，加载到虚拟机中便可以在 OOBE 阶段检索到 PPKG。
为 PPKG 创建一个 ISO 有很多方法，除了第三方软件外，gOxiA 强烈建议你使用 Windows ADK 中自带的 Oscdimg.exe 工具，对于要跟桌面部署打交道的 IT 人员来说，相信每一位都会在管理员工作站上安装 Windows ADK。现在，我们只需要将 Oscdimg.exe 所在的目录位置添加到用户变量中即可在任意目录中执行该命令。
Oscdimg.exe 所在的目录位置是：
C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Deployment Tools\amd64\Oscdimg
为 PPKG 生成 ISO 的命令行很简单，如下参考：
在 OOBE 阶段，将生成的 ISO 加载到虚拟机中，然后连续按下五次 Windows 键，选择“安装预配包”，便会自动检索并应用这个 ISO 中的 PPKG。
现在，我们就可以开始轻松的测试 PPKG 动态部署 Windows 10 了。文末，分享 PPKG 在 OOBE 阶段执行部署时的一些重点知识。
- 配置引擎会始终应用保留在 C:\Revovery\Customizations 目录下的 PPKG。
- PPKG 将会被复制到 %ProgramData%\Microsoft\Provisioning 目录下。
- 在 OOBE 阶段可以直接应用未签名信任的 PPKG。
- 当配置引擎在 OOBE 阶段应用 PPKG 时，仅将运行时设置从 PPKG 包中应用到设备。运行时设置可以是系统范围的配置设置，包括：安全策略、Windows应用程序安装和卸载，网络配置，引导 MDM 注册，账户和域配置，Windows 版本升级等。配置引擎还会检查设备上的配置设置（如：区域设置或 SIM 卡），并应用具有匹配条件的多变量设置。
HOWTO: 使用 Intune 远程停用设备
HOWTO: 使用 Intune 远程停用设备
回顾：
"HOWTO: 为现有设备添加 Windows Autopilot 配置支持"
“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”
"HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune"
"HOWTO: 在 Intune 中为 Windows Autopilot 部署创建设备组"
"HOWTO: 在 Intune 中创建 Windows Autopilot 配置文件"
"HOWTO: 使用 Intune 部署 Microsoft Edge"
今天 gOxiA 将继续分享 Intune 中的设备管理功能 - 停用（Retire），使用“停用”可以删除托管设备上的应用数据、设置和电子邮件配置文件等内容，但是会将用户个人数据保留在设备上，整体的体验像是之前退域一样。当我们在 Intune 后台设备管理中点击“停用”后会显示停用设备的说明，其重点是此设备将不再由 Intune 托管，且不能再访问公司资源，由 Intune 部署的“现代应用”会被卸载，但不会卸载已经部署的 Win32 应用，Win32 应用包含的数据仍会保留在设备中，用户数据也不会被清理掉。
即使 AAD 账号已经登录，也可以使用“停用”，当停用执行完毕后会看到如下图的通知，当打开 Outlook 时会遇到修复提示，如果此时重启系统你会发现登录界面将会显示最后一次登录的 AAD 账号名称，但是您无法使用密码登录，因为该计算机上的 AAD 账号已经被移除，此时如果用户希望登录系统必须进入 Windows 的安全模式，在 Windows 安全模式下可以使用本地管理员 - Administrator 账号登录（密码为空），进入系统后可以创建一个新的本地管理员账号，用于从正常启动环境登录系统桌面。
登录系统后，你可以在 Users 目录中看到以往登录的用户账户目录，可以提取其中的用户数据。下表展示了“停用”后主要清理的内容：
Intune安装的公司应用和关联数据：卸载应用，删除bypass加载密钥，不会删除Office365专业版，不会卸载 Win32应用。
设置：不再强制实施 Intune 下发的策略。
WiFi和VPN配置文件设置：相关设置会被删除。
证书配置文件设置：删除并吊销证书。
电子邮件：删除已启用EFS的电子邮件及附件，并删除由 Intune 预配的邮件账户。
AzureAD脱离： 删除 AAD 记录。
前面 gOxiA 说过停用会保留用户数据，其中就包括 OneDrive for Business 中的数据，所以组织 IT 人员在使用“停用”时一定要进行谨慎的评估，这意味着 AAD 用户的数据会被保留在设备上，但设备将不再受到组织管控。在停用设备后，用户可以重新加入到 AAD 并托管到 Intune 中，此时用 AAD 账号登录会继续使用之前匹配的用户目录。
HOWTO: 使用 Intune 远程重启设备
HOWTO: 使用 Intune 远程重启设备
我们继续 Intune 的相关知识学习，开始前也可通过以下链接回顾之前的内容。
"HOWTO: 为现有设备添加 Windows Autopilot 配置支持"
“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”
"HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune"
"HOWTO: 在 Intune 中为 Windows Autopilot 部署创建设备组"
"HOWTO: 在 Intune 中创建 Windows Autopilot 配置文件"
"HOWTO: 使用 Intune 部署 Microsoft Edge"
今天 gOxiA 将介绍如何通过 Intune 远程重启设备。当组织的设备已经开始通过 Intune 管理，那么你会在设备概述中看到可管理的操作选项，如下图所示。
在顶部的选项中我们能看到支持的管理功能，其中“重启”功能很容易理解，当发起重启后客户端设备将会收到从 Intune 发来的重启指令，如果当前用户为锁定状态，那么当再次解锁登录到系统后会收到注销登录的提示，倒计时为2分钟，如下图所示。
如果当前用户为已登录状态，也会收到提示，如下图所示，大概3分钟后会收到如上一截图一样的通知，开始2分钟倒计时，之后强制重启。
如果当前设备未有用户登录，当发起重启后，设备并不会立刻重启，当用户再次登录系统，才会收到注销通知，如果点击关闭则会等待3分钟出现2分钟倒计时，最后强制重启。
但是……但是……重点提示来了！
如果当前设备未有用户登录，或为锁定状态，那么在发起重启指令5分钟后，便会执行强制重启。
以上这些测试结果与 Docs 上的介绍有所出入，在当前文档中介绍发出重启指令后设备端不会收到重启通知，且可能会导致当前工作内容丢失。也许正因为涉及数据的原因，重启机制才发生了变更，并未如文档描述的那样执行。
不过现在这个重启功能其实也失去了它的真正意义，因为在某些特定场景下确实需要管理员立刻！马上！强制重启客户端设备。PS：或许这里的重启应该换个名字叫“紧急重启”！
最后，再与大家分享的是由 Intune 发起重启指令后，是可以通过 shutdown /a 来取消重启的。
