HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune

        在 6月份 gOxiA 分享了“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”，如果您已经学习了这篇日志，会发现收集硬件标识信息其实是非常简单的事情，但是需要注意它并不适用在生产环境，应仅用于评估和测试。

        今天要分享的是如何将收集的 Windows Autopilot DeviceID 添加到 Intune 中，因为后续我们将实践 Windows Autopliot 的用户驱动模式和自部署模式，所以需要将 DeivceID 事先添加到 Intune 的设备列表中，为此我们需要执行下述的操作步骤：

1. 首先访问 Azure Portal，使用拥有权限的账号密码登录。

2. 在左侧的导航列表中点击“Dashboard”，搜索 Intune，可以将其收藏到导航列表中便于后续访问。

3. 进入 Microsoft Intune 后，点击“Device enrollment”

4. 在“Deive enrollment”下点击“Windows enrollment”，并选择“Windows Autopilot Deployment Program”下的“Devices”，它便是我们要导入 DeviceID 的位置。

5. 进入“Deives”后，点击“Import”来导入我们之前拿到的硬件标识信息文件，它是一个 CSV 格式的文件，在上传后 Intune 会进行校验，如果格式无误便可以导入。

DevicesID 的 CSV 格式应该遵循如下格式内容：

<Serial NUmber>,<Windows Product ID>,<Hardware Hash>,(optional <Group Tag>)

        至此，DeviceID 便添加到了 Intune，在设备还没有注册到 Autopilot 上时设备使用序列号作为设备名称，我们可以在 “ Azure Active Driectory”中的“Devices - All devices”下找到它们。

        虽然我们在 Intune 中添加了设备的硬件标识信息，但是该设备还未受当前 Intune 的管控，也就是如果我们开机进入 OOBE 阶段，仍可以进行自定义的配置，或者使用其他组织的账号绑定设备。

HOWTO: 在 Intune 中为 Windows Autopilot 部署创建设备组

回顾：

“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”

"HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune"

        如果之前跟随 gOxiA 完成了上面的学习和动手操作，可以继续跟随 gOxiA 完成今天的内容，否则建议您从头开始了解。今天的内容将会非常轻松，会了解如何在 Intune 中创建“设备组”，这部分虽然很轻松，但它也是重点之一，因为在实施 Autopilot 部署时配置文件只能分配给组。

        我们可以创建两种类型的设备组，即：动态设备组 和 静态设备组，两者区别在于前者可通过定义规则自动将设备加入到组，或从组删除；而后者则需要由管理员进行分配。

        要为 Windows Autopilot 创建设备组，可登录 Auzre门户，定位到“Intune”，会看到“Group”，如下图所示：

进入 “Group” 后在 “All groups” 下点击 “New group”。

        在 “New Group” 中，会看到一些选项，带有 * 号的是必须填写的信息。其中“Group Type”表示组的类型，在预定义中包括了“Security” 和 “Office 365”。

• Security，它通常用于管理用户和设备的共享资源的访问权限，也可以为特定的策略创建安全组，这样一来我们就不用为每个成员单独设置权限。
• Office 365，主要是提供对共享邮箱，日历，文件以及SharePoint站点等的访问权限。

        本例中，我们要为 Windows Autopilot 创建设备组，所以这里的类型应该是“Security”。“Group name”很好理解，这里命名为了“UserDriven”。“Membership type”便是我们前面提到的静态和动态的组类型，包含了“Assigned”、“Dynanmic User” 和 “Dynamic Device”，是的动态组除了支持设备外，也适用于账户。

        当我们选择“Assigned”后，就可以手动添加账户或设备，这里我将添加之前导入的设备。

        我们也可以使用动态组，利用一些规则自动将设备添加到组中，这样就不需要手动添加那么麻烦。动态成员规则非常强大，提供了多种属性，可利用各种运算符，根据属性的值，创建具有多个表达式的规则。

        来看一个简单的例子“(device.accountEnabled -eq ture)”，还是很容易理解的，当设备账户启用状态是“真”时，那么便会设备便会自动加入到这个组，如果组中的设备账户启用状态为“假”时会将设备从组中删除。下图可看到当前动态设备组提供的可用属性。

        有关动态组的详细规则，强烈推荐学习官方文档：https://docs.microsoft.com/zh-cn/azure/active-directory/users-groups-roles/groups-dynamic-membership，随着准备工作的就绪，我们离正式实施 Windows Autopilot 也越来越近！

HOWTO: 在 Intune 中创建 Windows Autopilot 配置文件

回顾：

“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”

"HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune"

"HOWTO: 在 Intune 中为 Windows Autopilot 部署创建设备组"

        在之前我们已经了解了如何在 Intune 中 为 Windows Autopilot 部署创建设备组，当基本工作完成后，我们也将进入 Windows Autopilot 配置主要环节 —— 创建和分配 Deployment Profiles，当这一步完成后，我们便可以通过 Windows 10 客户端来体验 Windows Autopilot。

        首先，登录 Azure Portal，在 Intune 中找到 Device enrollment，进入后便能看到一系列的注册项，选择 Windows enrollment，就能看到位于"Windows Autopilot Deployment Program" 下方的 "Deployment Profiles"。

    点击"Create profile"，开始创建 Windows Autopilot 的配置文件。

        因为改版，配置文件的创建页面改为了引导式，对于用户来说虽然步骤显得繁琐，但更为清晰明了。首先我们需要输入配置文件的名称，本例命名为 UserDriven。

        目前 Windows Autopilot 提供了两种部署模式：User Driven（用户驱动）和 Self-Deploying（自助部署），简单理解后者的自动化程度更高，将会自动跳过"工作或家庭使用选项"，"OEM注册和OneDrive配置"，以及"OOBE 中的用户身份验证"，此外还可自动配置语言及键盘等设置。但是自助部署的需求也更高，从目前最新的文档看需要 Windows 10 的 1903，之前 gOxiA 在实际测试时发现 1809 对一些设备的 TPM 设备证明存在支持问题，并得到了产品组的证实。所以如果你打算测试自助部署还需要了解更多的先决条件，本例我们将使用“用户驱动”模式。

        在"User Driven"下我们可以隐藏软件许可条款，以及隐私设置等需要人工干预的界面，我们还可以指定登录到设备上的用户账户类型，例如将其分配为标准用户权限。

        在当前更新版本中还提供了"Allow White Glove OOBE"的选项，允许 IT 人员在不使用用户账号配置和登录的情况下对设备进行 Windows Autopilot 预配。只需要在配置阶段按下 5次 Windows 键即可激活该功能选项。

        此外，我们还可以配置设备名称模板，通过一系列变量生成有序的计算机名。

        配置文件的选项设置完毕后，就需要将其分配给指定组，还记得我们在之前创建的组吗，参考下图找到并选择这个 UserDriven 组。

        最后在 Review 界面可以对配置进行确认，无误后可点击“Create”确定创建。

        Windows Autopilot 配置文件创建后便可在之前已经添加到 Intune 中的设备上，使用 1903 的 Windows 10 进行测试。

End of Life

微软公布 Windows 7 Extended Security Updates

        Windows 7 的生命周期将于 2020年1月14日结束，Office 2010紧跟其后。在 Windows 7 生命周期结束后，系统仍能继续使用，但无法再从微软获得技术支持，安全更新以及软件更新。但在近日微软公布了一项付费服务 - Windows 7 Extended Security Updates，即 Windows 7 扩展安全更新，简称：ESU。

        它面向各种规模的企业用户，不论是 Windows 7 专业版还是 Windows 7 企业版都可以通过云解决方案提供商（CSP）购买 ESU。Windows 7 ESU 将按设备销售，且每年价格都会有所上浮，可用时间直至 2023年1月。

参考原文：https://www.microsoft.com/microsoft-365/partners/news/article/announcing-paid-windows-7-extended-security-updates

        以下是来自网文的 ESU 的价格参考：

Windows 7 企业版

• 第一年，25美金/台
• 第二年，50美金/台
• 第三年，100美金/台

Windows 7 专业版

• 第一年，50美金/台
• 第二年，100美金/台
• 第三年，200美金/台

        另外需要注意的是如果你计划从第三年开始购买 ESU，那么还需要支付前两年的费用，也就是说你要支付175美金/台/企业版。

        gOxiA 建议相关从业者应尽快推动 Windows 10 的升级工作。

Windows 处理器配置需求 - 201910更新含19H2

        微软近期更新了 Windows 处理器的最新需求列表，其中包含了 Windows 10 19H2（1909）的最新处理器需求，参考如下：

原文地址：Windows Processor Requirements

        从支持列表看与1903并无差别，毕竟1909更新与前一版本并未太大区别。Windows 10 1909 将支持当前市面上最新的主流处理器，包括 ARM 架构的 Qualcomm Snapdragon 850 and 8cx 处理器。

        此外，作为 IT 支持人员应当定期审阅该公告了解 Windows 各版本支持的 CPU，避免在交付的标准化映像版本与设备不兼容。举例来讲，当前企业在交付的 Windows 10 版本为 1607，那么该版本最高支持的 Intel 处理器仅为 Intel 7th，如果企业采购了基于 Intel 8th 的设备，那么就需要重新编制标准化映像，例如使用 Windows 10 1709，但由于 1709 的标准生命周期仅到 2019年4月9日，那么 IT 人员就需要考虑后续的迭代版本了，例如 1809 或 1903，但此时就需要额外验证企业内的业务应用或安全应用是否兼容最新版本的 Windows 。

        欢迎大家与 gOxiA 探讨现代桌面管理经验，尤其是如果您对交付 Surface 设备有任何问题，请与 gOxiA 联系。

微软公布 Microsoft Edge 新消息

        美当地时间11月5日，Microsoft Edge Insider 向用户公布了两则新的信息，受到了广泛关注。第一个则是 Microsoft Edge 发布了新的 Logo，新 Logo 增加了颜色过度，显得更加立体，给 gOxiA 的感觉像是一个新的生命。

        第二个消息则是正式公布将在2020年的1月15日发布基于 Chromium 的 Microsoft Edge 正式版。目前已经发布了正式预览版，基于 version 79 的 Beta 版本。

        从2019年4月公布 Edge Insider 以来，三个更新通道已经全部就绪，不论是你喜欢跟新的极客，或是开发人员，还是希望更稳定的测试用户都有不同的更新渠道，它们对应了 Can、Dev 和 Beta 。

        而且 Edge 已经全面支持跨平台运行，从 PC 到 服务器除了 Windows 10 以外还提供了 Windows 8.1/7/Server 2008R2/Server 2021 R2/Server 2016及以上版本的支持；而且还提供了 macOS 版本；即使你是移动用户也可想用这份美味，它支持 iOS 和 Android。

        此外，Microsoft Edge 还支持企业环境，提供了统一管理的特性，利用组策略可以为客户端设备提供统一定制化的配置。

        如果您正在评估浏览器，不要错过 Microsoft Edge，即刻访问 http://www.microsoftedgeinsider.com，gOxiA 从发布以来一直在用的是 Can 渠道更新，即每日更新，还是相当稳定的。

HOWTO: 使用组策略模板管理 Windows 10

       微软在 2015年8月首次发布了 Windows 10 的管理模板（ADMX），并且针对每个版本都有提供对应的 ADMX，如果企业正打算通过域组策略来管理 Windows 10 设备，那么这些管理模板不可或缺。根据微软提供的 ADMX 模板参考指南（Group Policy Settings Reference for Windows and Windows Server）中的数据，仅为 Windows 10 提供的新的管理选项就多达600多个（多个版本累计，可能含有重复项）。

        以下是 Windows 10 各版本的 ADMX 下载地址：

• Administrative Templates (.admx) for Windows 10 1511
  https://www.microsoft.com/en-US/download/details.aspx?id=48257

• Administrative Templates (.admx) for Windows 10 (1607) and Windows Server 2016
  https://www.microsoft.com/en-US/download/details.aspx?id=53430

• Administrative Templates (.admx) for Windows 10 1703
  https://www.microsoft.com/en-us/download/details.aspx?id=55080

• Administrative Templates (.admx) for Windows 10 1709
  https://www.microsoft.com/en-us/download/details.aspx?id=56121

• Administrative Templates (.admx) for Windows 10 1809
  https://www.microsoft.com/en-us/download/details.aspx?id=57576

• Administrative Templates (.admx) for Windows 10 1903
  https://www.microsoft.com/en-us/download/details.aspx?id=58495

• Administrative Templates (.admx) for Windows 10 1909
  https://www.microsoft.com/en-us/download/100591

        此外，微软还为 IT 人员提供了基于云的组策略搜索工具，允许管理员查看、过滤、复制所有的 GPO 设置。

http://gpsearch.azurewebsites.net/

        当 IT 人员下载并展开 ADMX 模板后，该如何应用到当前企业的域环境中呢？！方法很简单，我们可以基于中央存储的方式来创建和管理组策略管理模板，当然这一中央存储的特性一直存在。

        首先，我们需要在域共享中创建如下文件夹：
\contoso.comSYSVOLcontoso.compoliciesPolicyDefinitions

        然后，将下载的 ADMX 模板复制到上面的文件夹中，注意除了 ADMX 文件外，对应的语言目录也需要一并考入。

        建议在执行操作前，先阅读微软的知识文档，获取最佳的实践。https://support.microsoft.com/zh-cn/help/3087759/how-to-create-and-manage-the-central-store-for-group-policy-administra

微软发布基于 Chromium 的正式版 Microsoft Edge 浏览器

        本月15日微软向公众发布了基于 Chromium 的正式版 Microsoft Edge 浏览器，版本号为：79.0.309.65，现在可以访问新网站进行下载，https://www.microsoftedge.com。

        除了支持 Windows 平台，该浏览器还支持跨平台，目前已经能够安装在 MacOS、iOS 和 Android 平台上，访问官方网站或从下面的二维码扫描即可访问安装。

        如果您是企业用户，并希望在组织中部署这款浏览器，则可以访问 https://www.microsoft.com/en-us/edge/business/download 获取 MSI 格式的安装包，微软还提供了策略模板，供组织进行统一的管理。目前 Intune 也已经原生支持部署 Microsoft Edge，当然也可以继续使用 MSI 以 LOB 方式部署。

        此外对于企业用户还需要了解以下信息：

1. Microsoft Edge 稳定渠道的功能更新将按照6周周期进行发布。
2. 为了确保 Microsoft Edge 可以无缝融入到 Windows 中，在安装后会对操作系统进行更改。
3. Windows 当前版本的 Microsoft Edge 所涉及到的开始菜单Pin、磁贴、任务栏Pin和快捷方式都将迁移到安装的基于 Chromium 的 Microsoft Edge。
4. 默认的大多数协议也将迁移到新版 Microsoft Edge。
5. Windows 当前版本的 Microsoft Edge将会被隐藏，所有尝试启动都将被重定向到新版 Microsoft Edge。

备注：用户级别安装不会触发这些行为。

        文末，gOxiA 建议企业用户使用该浏览器，除了广泛支持不同的 Windows 版本外，还支持跨平台，能够为用户带来一致的使用使用体验，并且支持微软账户或Office 365账户同步。至于兼容性问题，Chromium 内核深受用户喜爱和青睐，标准被广泛采用，这对于前端开发者也是福音。

虚拟环境下在  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 的命令行很简单，如下参考：

        现在，我们就可以开始轻松的测试 PPKG 动态部署 Windows 10 了。文末，分享 PPKG 在 OOBE 阶段执行部署时的一些重点知识。

• 配置引擎会始终应用保留在 C:\Revovery\Customizations 目录下的 PPKG。
• PPKG 将会被复制到 %ProgramData%\Microsoft\Provisioning 目录下。
• 在 OOBE 阶段可以直接应用未签名信任的 PPKG。
• 当配置引擎在 OOBE 阶段应用 PPKG 时，仅将运行时设置从 PPKG 包中应用到设备。运行时设置可以是系统范围的配置设置，包括：安全策略、Windows应用程序安装和卸载，网络配置，引导 MDM 注册，账户和域配置，Windows 版本升级等。配置引擎还会检查设备上的配置设置（如：区域设置或 SIM 卡），并应用具有匹配条件的多变量设置。

官方参考：https://docs.microsoft.com/en-us/windows/configuration/provisioning-packages/provisioning-how-it-works

正确认识和理解 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”

引自微软官方文档：
https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/windows-hello-face-authentication

BitLocker 自动设备加密

        想必大家都知道 BitLocker，可以帮助我们对磁盘数据加密，确保其在系统脱机时不会被篡改或窃取。迄今为止 BitLocker 仍然是公认的最为安全的磁盘数据加密技术之一，受到不少企业用户的青睐。现在当我们采购来预装有Windows 10的设备后，完成OOBE就会发现当前磁盘已经是加密状态，十分的方便。

        那么这些 Windows 10 设备是如何确保 BitLocker 能够自动加密呢？！要实现自动设备加密硬件需要满足如下要求：

  
• 设备包含 TPM，包括 TPM 1.2或2.0。
    
• 基于 UEFI 启用。
    
• 已启用 Secure Boot。
    
• 已启用 DMA（直接内存访问）保护。

        在 Windows 10 启用自动加密前，会进行如下测试：

  
1. TPM 必须包括支持 PCR7 的 TPM
    
2. 启用了 UEFI 和 Secure Boot
    
3. 支持 Modern Standby 或 HSTI 验证
    
4. 启动分区有 250MB 的可用空间
    
5. 操作系统版本不应早于 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 加密。

体验新的 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 桌面交付过程，可以好好研读。

https://docs.microsoft.com/zh-cn/windows/package-manager/

微软发布 Windows File Recovery

        微软近日在其 Microsoft Store 发布了一款免费的数据恢复工具 – Windows File Recovery，利用该工具可以帮助用户从本地驱动器，甚至是 SSD 或外部可移动存储（SD卡或U盘）上恢复那些已经被删除的文件。

        满足 Windows File Recovery 的操作系统版本要求：Windows 10 19041 or 更高版本。Windows File Recovery 支持多种磁盘格式（FAT、exFAT、ReFS、NTFS），在非 NTFS 上进行数据恢复时需使用 Signature Mode 即参数 “/x”。

        是否已经心动？！要安装它只需要从 Microsoft Store 获取即可，可以通过这个链接直接访问安装。https://www.microsoft.com/store/r/9N26S50LN705

        当安装完毕后启动程序会自动进入 CMD 环境，假设我们要从一个目录恢复指定的文件，可参考如下命令行：

        对于前面提到的非 NTFS 场景，例如从 SD 卡恢复相片类型的文件，则可以参考如下命令行：

        Windows File Recovery 还支持高级选项，可通过 ”/!” 查看高级选项说明。

有关 Windows File Recovery 更详尽的帮助说明，强烈建议学习：https://support.microsoft.com/en-us/help/4538642/windows-10-restore-lost-files?WT.mc_id=thomasmaurer-blog-thmaure

Windows Insider 变更新版本发行方式

        微软 Windows Insider Program 在六月中下旬公布了项目的最新变更信息，将当前基于 Ring 的版本发布模式转换成了新的 Channel 模式。这一变化意味着 Windows Insider 版本发布的重心将由多频率转变为高质量。此外该模式也与现有的 Office 和 Edge 吻合，为用户带来一致的评估体验。

        新的 Channel 模式也非常便于理解，具体参考如下：

  
• Dev Channel，对应之前的 Fast ring，适用于一些高级用户或开发人员，可获得开发周期中最早的内部版本，体验到最新的更新，当然这也意味着不完善或存在不稳定的因素。
    
• Beta Channel，对应之前的 Slow ring，适用于那些喜欢尝鲜但又注重稳定性的用户。
    
• Release Preview Channel，对应之前的 Release Preview ring，该版本意味着无限接近正式版，已具备最终的关键功能，和可靠的质量更新。适用于组织内部大范围的验证和评估。

        需要注意的是，以上变更目前还未正式体现在 Windows 预览体验计划的功能设置中，您看到的仍是“慢、快、Release Preview”三个选项。

         更详尽的详细可阅览微软的官方网站：https://blogs.windows.com/windowsexperience/2020/06/15/introducing-windows-insider-channels/

巧妙利用 MSfB 在 Windows 10 LTSC 上部署 UWP 程序

        LTSC即长期服务通道，在过去被称为LTSB（长期服务分支），到目前位置微软一共发行了三个LTSC版本：

l Windows 10企业版 2015 LTSC，基于Windows 10 1507

l Windows 10企业版 2016 LTSC，基于Windows 10 1607

l Windows 10企业版 2019 LTSC，基于Windows 10 1809

        通过 LTSC 服务模型，可以帮助企业延迟接收 Windows 功能更新，默认情况下 Windows 10 会在一年中提供两次的功能更新。此外，LTSC 还提供了长达 10年的生命周期。还有一点吸引企业 IT 人员的是 LTSC 未包含 Windows 10 的新桌面体验功能（如：Cortana、Edge、Microsoft Store和所有内置的Windows应用程序）。

        不论怎样！LTSC 并非适用于大多数或所有电脑上部署，它仅适用在一些特定的应用场景或专用设备之上。这里有一篇文章介绍了 LTSC，强烈建议先行阅读。

https://techcommunity.microsoft.com/t5/windows-it-pro-blog/ltsc-what-is-it-and-when-should-it-be-used/ba-p/293181

        简单理解，如果您的电脑上安装了 Office 等生产力应用软件，或连接了一些打印机等外设，那么这款电脑就不应安装 LTSC，如果您安装了并在使用中发生了一些问题，也无法从微软那里得到有效的技术支持。

        即便如此，我们广大的企业IT人员还是非常青睐这个版本的操作系统。因为在 Windows 10 企业版 2019 LTSC 中又添加了很多的新功能，例如：

l 基于Windows 10 1809构建。

l 受Intune支持（注：WUfB目前不受支持），包括执行Autopilot部署。

l 安全性得以增强，提供了Windows Defender ATP、WIP、Windows Hello企业版，等安全功能和特性。

        要了解更详尽的信息，可访问：https://docs.microsoft.com/zh-cn/windows/whats-new/ltsc/whats-new-windows-10-2019

        回到正题，当我们在部署安装 LTSC 后可能需要使用常规版本下的 Windows 内置的应用程序，如 Windows Camera（相机）。由于缺少 Microsoft Store 我们将无法重新安装那些经典好用的 Windows 内置应用，此时正确的方案应该是从第三方获取独立的相机应用程序，他们可以是 Win32 或 UWP 类型的应用。

        但如果当前 LTSC 应用场景下又必须使用 Windows Camera 这类的内置应用，又该有什么办法呢？！

        经过研究，如果您所在的组织正好在使用 Intune，并开通了Microsoft Store for Business（简称：MSfB），那么这个问题就很容易解决了。我们可以从 MSfB 门户下载到 Windows Camera 的离线安装包。

        首先，利用搜索找到 Windows Camera，您会发现这个 UWP 提供了 Online 和 Offline 两种部署方式，而且授权模式是 Free！！！

        获取该应用后，便可以通过管理界面下载它的离线安装包，在下载时请务必正确选择相关的信息，如系统平台为 Windows 10 desktops，最小版本 17134 即不低于 1803 版的 Windows 10，架构是 x64，以及语言。之后，就可以下载这款应用的离线安装包。

        此外，根据需要下载应用程序的授权文件，对于 Windows Camera 由于是 Free 授权，这个倒是可以略过。由于 Windows Camera 还需用一些运行框架支持，所以一定要将“Required frameworks”下的三个包也一同下载安装。

        所有的应用包获取完毕后，便可以进入实质的安装阶段。首先，将这些文件拷贝到目标设备上的一个目录中，例如：C:\temp\camera。

        然后，使用 DISM 或 PowerShell 命令行即可完成安装，通过DISM安装应用包（Appx or AppxBundle）参考如下：

        安装完毕之后，在启动程序时请务必确保设备已经能够访问 Internet，否则应用将无法正常启动（会在日志中看到 COM ActivateExtension 相关的网络错误）。

        我们也可以通过 PowerShell 命令“Add-AppPackage“进行安装，参考命令如下：

        最后，分享两篇有关 LTSC 与 Surface 设备兼容性的指导文章。

https://docs.microsoft.com/en-us/surface/surface-device-compatibility-with-windows-10-ltsc

https://docs.microsoft.com/en-us/surface/ltsb-for-surface

微软发布基于 Windows 系统映像的 Microsoft Defender 更新

        在企业 IT 交付新安装的 Windows PC 的前几个小时可能会导致系统易受工具，这是因为操作系统安装映像可能未安装最新的系统更新，或包含过时了的反恶意软件。对于系统更新企业 IT 可以定期下载离线的系统更新包解决，而对于 Defender 早先可以通过下载“Defender 安全智能更新包”在部署阶段进行动态更新。而现在微软发布了基于 Windows 系统映像的 Microsoft Defender 更新工具，可以方便企业 IT 定期为操作系统安装映像提供 Defender 更新服务，最大程度地减少新部署中的此保护缺口。

        该工具可为 WIM 和 VHD 文件格式的系统映像执行反恶意软件更新包的安装任务，且只支持如下系统版本：

  
• Windows 10（企业版、专业版和家庭版）
    
• Windows Server 2019
    
• Windows Server 2016

        在执行安装更新后，反恶意软件客户端、反恶意软件引擎和签名版本将会更新到以下版本（本文：20201016）：

  
• 平台版本：4.18.2009.7
    
• 引擎版本：1.1.17500.4
    
• 签名版本：1.325.353.0

        程序包当前版本：1.1.2010.2（20201016），大小约为 110MB，要运行该工具的先决条件如下：

  
• 必须运行64位 Windows 10 或更高本本的操作系统环境，且包括 PowerShell 5.1 或更高版本。
    
• 必须安装 Microsoft PowerShell.Security 和 DISM 模式。
    
• 必须使用管理员权限再设备上启动 PowerShell。

下载地址：https://support.microsoft.com/en-us/help/4568292/defender-update-for-windows-operating-system-installation-images

应用更新

PS C:\> DefenderUpdateWinImage.ps1 - WorkingDirectory<path> -Action AddUpdate - ImagePath <path_to_Os_Image> -Package <path_to_package>

移除更新

PS C:\> DefenderUpdateWinImage.ps1 - WorkingDirectory<path> -Action RemoveUpdate - ImagePath <path_to_Os_Image>

显示当前更新信息

PS C:\> DefenderUpdateWinImage.ps1 - WorkingDirectory<path> -Action ShowUpdate - ImagePath <path_to_Os_Image>

注意：

请勿使用该工具更新实时映像，因为它可能会损坏在虚拟机内部运行的 Windows 安装。

WorkingDirectory 请指定为一个临时工作目录。

深入探讨 Windows 10 BitLocker 自动设备加密

        早先 gOxiA 分享了"BitLocker 自动设备加密"特性的一些细节，在这里可以先重温一遍。一些品牌笔记本，或 Windows 平板，或二合一的 Windows 设备，尤其是商用产品在使用时会发现磁盘自动激活了 BitLocker 加密保护，这一安全特性源于 Windows 10 BitLocker 的自动设备加密特性，但 BitLocker 自动设备加密特性详细划分是有两个状态的，其一是“启用状态”，其二便是“激活状态”，两者的区别在于前者启用状态下只是将硬盘 BitLocker 加密置于就绪状态，但并没有真正激活保护，所以在这一状态下，我们是可以通过 WinPE 或 WinRE 来访问磁盘内容的。而后者“激活状态”下等于 BitLocker 已开始保护磁盘。

        那么在什么硬件条件下才会启用 BitLocker 自动设备加密呢？！

        当一台 Windows 10 设备满足以下要求时，就会启用 BitLocker 自动设备加密特性。

  
• 设备包含TPM，包括 TPM 1.2或2.0
    
• 基于 UEFI 启动
    
• 已启用 Secure Boot
    
• 已启用 DMA Protection（直接内存访问保护）

        当设备具备以上要求时，启用自动加密前，Windows 10 还会在首次开机时执行如下测试：

  
• TPM 必须配置了 PCR7
    
• 启用了 UEFI 和 Secure Boot
    
• 支持 Modern Standby 或 HSTI 验证
    
• 具备不小于250MB 的启动分区
    
• 操作系统版本不早于 Windows 10 1703

        以上需求条件和测试都通过后，BitLocker自动设备加密特性/功能 便会启用，此时我们可以用命令“Manage-bde -status”查看状态。

        接下来我们再来了解激活 BitLocker 磁盘保护，或者说 BitLocker 自动设备加密在几个场景下的表现/影响。

  
1. 当使用 MSA 或 AAD 账户登录 Windows，会启用 BitLocker 自动设备加密，并激活 BitLocker 磁盘保护。
    
2. 当使用本地账号登录 Windows，仅会启用 BitLocker 自动设备加密。
    
3. 当使用 AD 账号登录 Windows，具体受组策略影响。

        作为企业用户，如果认为 BitLocker 自动设备加密特性会对现有安全策略或 IT桌面运维流程有影响，则可以禁用 BitLocker 自动设备加密，请注意这一特性其实是 Windows 10 BitLocker 的安全特性。目前可参考的企业部署方式如下：

  
1. Windows 应答文件 Unattend.xml，我们可以在 OfflineServing、Specialize、oobeSystem 阶段进行预配置。

Microsoft-Windows-SecureStartup-FilterDriver

PreventDeviceEncryption=True

  
1. 通过注册表，可用阶段如上。

HKLM\SYSTEM\CurrentControlSetControl\Bitlocker

PreventDeviceEncryption REG_DWORD 1

  
1. 命令行

Manage-bde -off [driverletter:]

        出于安全考虑还是强烈推荐使用 BitLocker 自动设备加密的，这样有助于我们快速实时 BitLocker 磁盘保护。另外还想与大家分享的是关于 BitLocker recovery 出现的原因以及获取恢复密钥的方法。

        首先，我们要正确认识开机出现的 BitLocker recovery，即“输入恢复密钥以进行恢复”，如下图所示：

        当电脑在启动时出现这个界面，除了在恢复系统，或用 WinPE 或 WinRE 引导时出现外（如果无需读取磁盘数据可以选择略过或继续以跳过），主要还是安全原因，可能的因素如下但不局限于：

  

•攻击者修改了您的计算机。这适用于具有受信任平台模块 （TPM）的计算机，因为 TPM 在启动期间检查启动组件的完整性。

    

•将受 BitLocker 保护的驱动器移动到新计算机中。

    

•使用新的 TPM 升级到新主板。

    

•关闭、禁用或清除 TPM。

    

•升级导致 TPM 验证失败的关键早期启动组件。

    

•启用 PIN 身份验证时忘记 PIN。

    

•启用启动密钥身份验证时，丢失包含启动密钥的可插拔 USB 闪存驱动器。

        最后 gOxiA 介绍几种场景下获取 BitLocker 恢复密钥的方法，首先如果是使用 MSA 登录，即使用 Microsoft Account（早先称为 Hotmail、MSN、LiveID……）的情况下，密钥会保存在 Microsoft 的个人账户信息中，我们可以通过网址 http://aka.ms/myrecoverykey 登录访问获取，或根据 BitLocker recovery 界面给出的 URL 获取，成功登录网站后可看到设备密钥 ID 对应的 恢复密钥，如下图所示：

        第二个场景是使用 AAD 账号登录，即使用 Microsoft 365 账号（原 Office 365 账号，也称为 Azure AD账号）登录的情况下，可以让 Azure 管理员从 AAD 门户的设备中找到对应的电脑，获取恢复密钥，如下图所示：

https://portal.azure.com/#blade/Microsoft_AAD_Devices/DevicesMenuBlade/Devices/menuId/

        也可以通过 Office 365 Portal 的账户信息中的设备页获取，如下图所示：

https://myaccount.microsoft.com/device-list

        第三个场景是使用本机账号登录，即在 OOBE 中创建了本地账号登录的情况下，在激活 BitLocker 磁盘保护时，必然会提示备份密钥。要备份密钥或管理 BitLocker 可通过“Windows 设置 - 更新和安全 - 设备加密 - BitLocker 设置”；也可以直接在任务栏搜索框键入 BitLocker 搜索。

        还有第四个场景，也是最典型的 AD 账号登录，如果 IT 管理员配置了将 BitLocker 信息保存到 AD 的策略，则可以通过 RSAT 的 BitLocker 驱动器加密管理实用程序 通过 ADUC 获取 BitLocker 恢复密码。

相关的组策略 (Windows Server 2019)请关注：计算机配置 - 策略 - 管理模板 - Windows 组件 - BitLocker 驱动器加密 - 操作系统驱动器（固定驱动器），配置“选择如何才能恢复 BitLocker 保护的操作系统驱动器”。

参考资料：

https://docs.microsoft.com/zh-cn/windows/security/information-protection/bitlocker/bitlocker-recovery-guide-plan

https://support.microsoft.com/en-us/windows/finding-your-bitlocker-recovery-key-in-windows-10-6b71ad27-0b89-ea08-f143-056f5ab347d6

https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/bitlocker-recovery-password-viewer-tool

HOWTO: 解决 BitLocker 启用 PIN 时的 0x803100B5 问题

        如果你所在的组织正在实施 BitLocker + TPM + PIN 的多验证方式来保护员工硬盘上的数据，可能会遇到如下图所展示的问题，在添加 PIN 时会发生一个错误，代码为：0x803100B5，即：“没有检测到预启动键盘。用户可能无法提供必要的输入来解锁卷。”

        出现该问题的设备通常是平板二合一类型的 Windows PC，由于键盘能够被拆卸，预启动环境又没有提供虚拟触摸键盘的支持，可能会导致在解锁时用户无法输入密钥。要解决这个问题也非常简单，我们只需要修改组策略（GPO）即可。使用 gpedit.msc 或 gpmc.msc 打开组策略编辑器，定位至“ 计算机配置 - 策略 - 管理模板 - Windows 组件 - BitLocker 驱动器加密 - 操作系统驱动器 ”，“启用 BitLocker 身份验证需要在平板电脑上预启动键盘输入”。如下图所示：

        如果需要通过注册表实现，可参考如下信息：

Key: HKLM\Software\Policies\Microsoft\FVE

Value: OSEnablePrebootInputProtectorsOnSlates

Type: DWORD

Enabled Value (decimal): 1

Windows 11 弃用或删除的功能

        微软在公布 Windows 11 后，用户可以通过 Windows Insider 获取到开发测试版以体验这个全新的操作系统。对于企业 IT 桌面的交付人员，他们更关注的是 Windows 11 带来了哪些改变？！因为需要确保在持续的交付过程中不会严重影响到最终用户。接下来快速了解一下在 Windows 11中哪些功能会被弃用或删除，以评估我们可能受影响的使用中的关键功能。

• Cortana 将不再包含在 OOBE 过程中，以及固定在任务栏中。
• 使用 MSA (Microsoft Account)登录时，桌面壁纸将不会再同步或从其他设备上同步回来。
• Internet Explorer 已禁用，默认推荐为 Microsoft Edge，如果网站需要 IE 访问可考虑使用 Edge 中的 IE Mode。
• 数学输入面板已删除。数学识别器可通过按需安装，包括数学输入控制和识别器。对于 OneNote 等应用中的数学模拟不会受到此更改影响。
• 新闻和兴趣已经演变为小组件，默认可在任务栏左侧找到该图标。
• 锁屏中的“快速状态”和相关设置已被删除。
• S Mode仅适用于 Windows 11 的家庭版。
• “开始”在 Windows 11 中显著更改，不再支持命名应用组和文件夹，布局当前无法重新部署。从Windows 10 升级时，固定的应用和站点不会迁移。实时磁贴特性不再可用。
• 平板电脑模式已删除。
• 任务栏功能已更改，不再包含人脉；某些图标不再出现在系统栏；任务栏只支持屏幕底部停靠；应用不能再自定义任务栏区域。
• 时间线 已被删除
• 以下应用在升级时不会删除，但将不再安装在新设备上，或在执行全新安装的 Windows 11 上，但可以从应用商店下载它们。
• 3D查看器
• OneNote for Windows 10
• 3D画图
• Skype

详情也可参考官方文档：https://www.microsoft.com/en-us/windows/windows-11-specifications#primaryR4

        如果您仍在继续关注 Windows 10，也可以从以下文档了解其不再开发的功能或删除的功能。

• Windows 10 不再开发的功能
• Windows 10 已删除的功能

HOWTO: 离线方式安装 WSL2 Ubuntu

        离线方式安装 WSL2 Ubuntu 只是一种比较极端的场景，使用的方案是从一台已安装了 WSL2 Ubuntu 的设备上使用 WSL 的导出功能将其导出为一个 tar 文件，然后再导入到目标设备上。当然，我们也可以先下载好 WSL 的 Linux 发行版，然后使用 Add-AppxPackage 安装。例如：

        以下是目前支持的 WSL 发行版：

  
• Ubuntu 20.04
    
• Ubuntu 20.04 ARM
    
• Ubuntu 18.04
    
• Ubuntu 18.04 ARM
    
• Ubuntu 16.04
    
• Debian GNU/Linux
    
• Kali Linux
    
• SUSE Linux Enterprise Server 12
    
• SUSE Linux Enterprise Server 15 SP2
    
• openSUSE Leap 15.2
    
• Fedora Remix for WSL

        要从设备上导出已安装的发行版，可以使用 WSL 的 --export 参数，例如：

        要将导出的发行版成功安装并运行在目标计算机上，还需要做一些额外的准备。首先，启用“适用于 Linux 的 Windows 子系统”，可使用命令行或图形界面。

        因为我们的目标是要运行 WSL2 模式，所以还需要启用“虚拟机平台”，也可以使用命令行。

        Windows 功能层面准备完毕后还没有完，因为目标设备不能联网，还需要手动下载和安装 Linux 内核更新包，以便能够支持 WSL2。

  
• 适用于 x64 计算机的 WSL2 Linux 内核更新包

         现在准备工作完毕，我们可以打开 CMD，将 WSL2 设置为默认版本。

        至此，我们可以开始导入 Linux 发行包，使用 --import 参数，需提供发行名称，要安装到的路径，导出的发行包所在路径，以及指定为 WSL2 版本。