gOxiA=苏繁=SuFan Blog

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 加密。

通过排错 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 设备

        在前段时间 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 阶段应用。