本站域名：http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问：http://goxia.maytide.net/m转载文章，请务必保留出处与作者信息，未经许可严禁用于商业用途！
HOWTO: 通过 Intune 解决 BitLocker 启用 PIN 支持时的 0x803100B5 问题
HOWTO: 通过 Intune 解决 BitLocker 启用 PIN 支持时的 0x803100B5 问题
早先 gOxiA 分享了"HOWTO: 解决 BitLocker 启用 PIN 时的 0x803100B5 问题"，如果你所在的组织已经开始基于 Intune 实施现代管理，并希望借助 Intune 下发策略来为客户端 BitLocker 启用 PIN 支持，那么暂时可能会有些小问题，你会发现找遍所有配置文件类型都没有提供“启用 BitLocker 身份验证需要在平板电脑上预启动键盘输入”（Enable use of Bitlocker auth requiring preboot keyboard - OSEnablePrebootInputProtectorsOnSlates）这个配置选项，不论是现有的配置文件模板，还是管理模板，即使是可自定义的 CSP。
借助 Intune 提供的“组策略分析”功能，可以了解 Intune 当前对组织在应用的 GPO 的支持情况和进度，如下图所示，可确认 Intune 目前尚未提供 OSEnablePrebootInputProtectorsOnSlates 的支持。
解决方案
既然现有配置策略没有提供 OSEnablePrebootInputProtectorsOnSlates 的支持，那就只能使用下发 PowerShell 脚本实现。我们知道 GPO 配置对应相关注册表键值，我们只需要借助 PowerShell 向注册表写入键值即可，以下脚本可作为参考：
PowerShell 脚本文件准备完毕后便可转向 Intune 管理后台 Microsoft Endpoint Manager admin center，在“设备”下找到“脚本”即可添加。
需要注意的是因为注册表键值位于 HKLM 下，所以无需启用“使用已登录的凭据运行此脚本”，后面跟随向导完成即可，至此 BitLocker 启用 PIN 支持的 Intune 策略添加完毕，当我们使用 Intune 进行策略下发时如果没有可用的配置文件或 CSP，则需要借助 PowerShell 以脚本方式变通实现。
HOWTO: 解决 BitLocker 启用 PIN 时的 0x803100B5 问题
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
HOWTO: 使用 Intune 为 Windows PC 部署 LOB 应用
HOWTO: 使用 Intune 为 Windows PC 部署 LOB 应用
趁热打铁，昨天 gOxiA 分享了“HOWTO: 使用 Intune 为 Windows PC 部署 Microsoft Store 应用”，今天我们继续 Intune 部署应用的话题，来聊聊使用 Intune 来部署 LOB 应用。LOB 即 业务线（Line-of-business）应用，它通常是一个单独的安装/应用包，如 .msi、.appx、.appxbundle，或是 .msix 和 .msixbundle。其中 MSI 大家都应该很熟悉了，是 Windows 标准的安装包格式，它通常是所谓的 Win32 应用，支持静默安装和高级安装选项，非常适合于企业部署使用；而 appx 和 appxbundle 即 Microsoft Store 中的应用包，属于 UWP 类型应用程序，利用这种应用包文件，可离线安装或脱离 Microsoft Store 来安装 UWP 应用；后者的 msix 和 msixbundle 是微软最新推出的安装包格式。
本例 gOxiA 将会介绍分发 UWP 应用包（.appx & .appxbundle）的方法。首先您需要从组织的软件供应商那里获取到 appx 或 appxbundle 格式的应用包，如果它们已经发布到了 Microsoft Store 中，已经具有 MSfB 的 IT 管理员便可以从中下载这些应用包。（你可能觉得此举有些多余，其实在某些场景下确实需要通过这个 Workaround 来获取和分发 UWP 应用，这里就不点透了！）
获取到应用包后，便可以前往 Microsoft Endpoint Manager admin center 进行添加，如果你在持续关注 gOxiA 的 Intune 主题文章，应该已经对添加应用不再陌生，这里就不再复述步骤只提重点。在应用类型中选择“业务线应用”，然后上传应用包文件，此时你会看到如下图类似的界面，会提示此应用包还需要其他依赖项应用文件，需要逐个添加后才能确保该应用包安装完毕后可以正常运行。
应用包添加完毕后，就会看到应用信息的必填项都会自动带入，我们仅需要额外的配置其他信息，并添加应用 Logo 图片文件即可。
重点来了，在分配选项中，现在就能看到 Required 和 Available for enrolled devices 选项。
到这里，使用 Intune 分发应用的“道路”上又前进了一步。参考文档：Add a Windows line-of-business app to Microsoft Intune | Microsoft Docs
HOWTO: 使用 Intune 为 Windows PC 部署 Microsoft Store 应用
HOWTO: 使用 Intune 为 Windows PC 部署 Microsoft Store 应用
如果之前你阅读过“HOWTO: 从 Microsoft Store for Business 删除应用”，应该会对 Intune 部署 Microsoft Store for Business（以下简称MSfB）应用有一定的了解，而今天要与大家分享的是通过 Intune 部署 Microsoft Store 应用。两者的区别在于 MSfB 除了可以通过 Company Portal（公司门户）和 Microsoft Store 来获取安装外，还支持强制部署（Required），这样应用就可以直接推送安装给设备或用户，无需用户再去选择安装；而后者 Microsoft Store 应用仅支持用户选择安装（Available for enrolled devices），即发布的应用必须由用户通过 Company Portal 去触发安装。很显然 MSfB 更适用于企业，但该服务目前并不是在所有区域可用，所以折中的选择只有 Microsoft Store，当然如果你的企业已经获得了 LOB App（.appx, .appxbundle, .msix, .msixbundle, .msi），也将会支持 Required 模式，gOxiA 将在以后分享这些内容。
言归正传，要使用 Intune 部署 Microsoft Store 应用（以下简称：MSStore App）十分简单，首先要获取到 MSStore App 的 URL，如果你已经在一台 Windows PC 上安装了这款应用，则可以通过鼠标右键单击应用，然后选择“更多”下的“共享”。
之后系统会自动打开 Microsoft Store 应用并定位到这款应用信息页面，还会弹出共享对话框，在对话框中单击“复制链接”，此时并没有结束，必须要打开浏览器粘贴并访问此 URL，并获取浏览器地址栏中的 URL 才可以添加到 Intune 中，根据需要可以将应用的 Logo 图片保存到本地以备后用。
现在访问 Microsoft Endpoint Manager admin center，定位至 应用 - Windows 应用下，添加应用选择 Microsoft Store 应用 类型，标星号的文本框为必填项，名称和发行者可以根据应用实际信息填写，说明部分由于支持 Markdown 格式，所以需要先点击“编辑说明”才能输入内容；应用商店 URL 便是我们前面获取到的最终的应用 URL，如果输入错误的格式会有提示信息；这里还建议直接将应用归类，并根据需要设定为特色应用，这样当用户打开 Company Portal 时就能在醒目的位置看到它；还记得前面让保存的 Logo 图片吗，可以将其上传这样用户就能更直观的获取到应用的信息。
在“分配”配置页面中，我们会看到当前只有一个选项，即：可用于已注册的设备（Available for enrolled devices），并支持分配个特定组或所有用户。所以你会留意到 MSStore App 存在诸多限制，其实并不适合企业用户部署。
MSStore App 添加完毕后可以在应用列表中看到，下图中可以看到 MSStore App 和 MSfB App 两种类型。
现在用户就可以启动 Company Portal 来选择安装应用，如果在前面我们将它设定为特色应用，则会看到如下图类似的排版。
深入探讨 Windows 10 BitLocker 自动设备加密
深入探讨 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 自动设备加密在几个场景下的表现/影响。
- 当使用 MSA 或 AAD 账户登录 Windows，会启用 BitLocker 自动设备加密，并激活 BitLocker 磁盘保护。
- 当使用本地账号登录 Windows，仅会启用 BitLocker 自动设备加密。
- 当使用 AD 账号登录 Windows，具体受组策略影响。
作为企业用户，如果认为 BitLocker 自动设备加密特性会对现有安全策略或 IT桌面运维流程有影响，则可以禁用 BitLocker 自动设备加密，请注意这一特性其实是 Windows 10 BitLocker 的安全特性。目前可参考的企业部署方式如下：
- Windows 应答文件 Unattend.xml，我们可以在 OfflineServing、Specialize、oobeSystem 阶段进行预配置。
Microsoft-Windows-SecureStartup-FilterDriver
PreventDeviceEncryption=True
- 通过注册表，可用阶段如上。
HKLM\SYSTEM\CurrentControlSetControl\Bitlocker
PreventDeviceEncryption REG_DWORD 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 保护的操作系统驱动器”。
参考资料：
HOWTO: 使用 Surface Deployment Accelerator 为 Surface 设备生成系统安装映像
HOWTO: 使用 Surface Deployment Accelerator 为 Surface 设备生成系统安装映像
Surface Deployment Accelerator（以下简称：SDA）是微软针对 Surface 设备提供的一款用于新生成系统安装映像的免费工具，基于 PowerShell 脚本编写，如果你正在维护 Surface 设备，它将会非常有帮助。大多数熟悉 Surface 的朋友应该知道，微软为 Surface 提供了用于恢复到出厂系统状态的 BMR 工具，但如果你希望使用最新版本的 Windows 10 操作系统并适配到 Surface 设备，那就可以利用 SDA 根据需要重新生成 Surface 特定型号的系统安装映像，在这份安装源中会默认包含该型号的最新驱动、系统的最新更新、Office 365，以及其他一些必要的附加应用组件，且支持生成 U盘或 ISO。
今天 gOxiA 将会跟大家分享如何使用 SDA 为 Surface 设备生成系统安装映像，首先访问 Github 下载 SDA 压缩包， 解压缩后将会看到一些脚本文件，然后准备一个容量 16GB 以上的 U盘，以及 Windows 10 的 ISO 文件（本次使用的是20H2），能够访问外部网络的连接是必不可少的，因为要下载驱动、更新以及应用组件。当然，也可以事先下载好特定型号的 Surface 驱动，但需要事先展开 MSI 驱动包。
要执行 SDA 则需要以管理员权限在 PowerShell 命令提示符下运行“CreateSurfaceWindowsImage.ps1”，这个 PS 脚本包含了一些参数，本文仅介绍常用的参数。
- -ISO：指定 Windows 10 ISO 文件的路径。
- -DestinationFolder：指定生成资源文件要保存的位置。
- -OSSKU：指定 Windows 10 的 SKU，有效值为：Pro，Enterprise
- -Device：指定了 Surface 的机型，有效的值为：SurfacePro4, SurfacePro5, SurfacePro6, SurfacePro7, SurfaceLaptop, SurfaceLaptop2, SurfaceLaptop3, SurfaceBook, SurfaceBook2, SurfaceBook3, SurfaceStudio, SurfaceStudio2, SurfaceGo, SurfaceGoLTE, SurfaceGo2, and SurfaceHub2
- -Office365：集成 Office 365，可以使用 True 或 False 进行控制。
- -CreateUSB：创建 U盘，可以使用 True 或 False 进行控制。
- -CreateISO：创建 ISO，同上。
- -UseLocalDriverPath：当为 True 时必须加载如下参数指定驱动路径。
- -LocalDriverPath：Surface 驱动所在路径，需已展开。
命令行参考：
SDA 目前已经支持简体中文版系统，可以留意版本号，当前为 v1.2.5.3，命令执行正确则只需要耐心等待，根据网络环境和当前系统性能的不同，生成所需的时间也不同，一定要有耐心，1-2小时是很平常的，大致的过程可参考下图：
微软发布基于 Windows 系统映像的 Microsoft Defender 更新
微软发布基于 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。
应用更新
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 请指定为一个临时工作目录。
[Intune] 使用 Get-WindowsAutopilotInfo 直接向 Windows Autopilot 注册设备
使用 Get-WindowsAutopilotInfo 直接向 Windows Autopilot 注册设备
如果你还记得这篇文章“HOWTO: 收集 DeviceID 用于测试 Windows Autopilot”，应该不会对 Get-WindowsAutopilotInfo 感到陌生。利用 Get-WindowsAutopilotInfo 可以收集设备的 DeviceID，然后参考“HOWTO: 将收集的 Windows Autopilot DeviceID 添加到 Intune”注册到 Windows Autopilot 执行部署。
将 DeviceID 添加到 Intune 的步骤还是比较繁琐的，现在 Get-WindowsAutopilotInfo 可以直接注册设备，这极大简化了测试过程。
让我们重温一下 Get-WindowsAutopilotInfo 的获取步骤：
1. 在 PowerShell 命令提示符下执行如下命令行，以安装 Get-WindowsAutopilotInfo。
备注：使用“-RequiredVersion X.X”可以指定要安装的版本，如果之前已经安装了旧版，请务必使用 –force 参数，更详细的参数介绍可参考官方文档“Install-Script”。
2. 为了能够执行该脚本，需要修改本地的安全策略。
Get-WindowsAutopilotInfo 准备完毕后，可以事先创建一个设备组并匹配到 Windows Autopilot 配置文件，本例中 gOxiA 创建了一个特定厂商设备的动态组，如下图所示，有关设备组的创建可参考“HOWTO: 在 Intune 中为 Windows Autopilot 部署创建设备组”。
现在我们可以执行以下命令行，来获取 DeviceID 并注册到 Windows Autopilot，也可同时分配到指定组，并等待配置文件分配。
HOWTO: 从 Microsoft Store for Business 删除应用
HOWTO: 从 Microsoft Store for Business 删除应用
如果您正在评估，甚至已经开始使用 Intune 来部署和管理 Windows 终端，会发现 Intune 部署应用的流程非常简单，尤其是通过 Microsoft Store for Business（MSfB） 部署 UWP 应用更加便捷。如果您还没有激活 MSfB 可以即可访问 Microsoft Endpoint Manager 管理中心，在“租户管理”中导航到“连接器和令牌”，之后就能看到“适用于企业的 Microsoft Store”，可以将其启用，并点击“打开企业应用商店”激活该服务，并与 Intune 绑定，成功后会看到如下图所示的界面。
点击“打开企业应用商店”可以访问 MSfB，或者也可以通过这个网址“https://businessstore.microsoft.com/”访问，通过“同步”按钮可以手动将 MSfB 购买的应用与 Intune 同步，否则需要等待15分钟。（PS：有关 MSfB 的性能指标可参考：https://docs.microsoft.com/zh-cn/microsoft-store/manage-private-store-settings）
在 MSfB 中企业 IT 人员可以获取免费或购买收费的应用程序，这些应用程序通常会提供 Online 或 Offline 的授权，前者我们可以通过 Microsoft Store 或 Company Portal 来分发，后者则可以下载 UWP 应用包实现侧加载。在获取到应用后，如果计划通过 Company Portal 分发以及强制部署，那么可以通过 Endpoint Manager 管理中心按需分配这些应用给特定用户和设备。此外您可以会注意到在 MSfB 管理界面中，也提供了分配应用的方法，这里的配置将作用到 Microsoft Store 中的专用商店。
到这里，gOxiA 大致描述了添加应用的过程，而本文的主题是从 Microsoft Store for Business 删除应用，在删除时我们会有以下几种场景。
第一种场景，我们希望从 Microsoft Store 下的专用商店中删除这些应用，避免用户自行从那里安装应用。这个场景下我们参考前面的截图，在“Private store availability”中将其改为“No one”。
第二种场景，即 IT 因为测试而获取了一些应用，现在希望从 MSfB 中整体清除它们，也就是从 Products & services 列表中清理掉。此时会发现我们根本找不到删除按钮。此时其实是一种概念的转换，我们实际上要清楚的是这份应用的购买订单，所以应当从“Order history”中退订，具体参考下图。
这样我们的列表就会显得干净许多，一些并不适用的应用也不再碍眼。对于Microsoft Account 类型的消费用户，目前还没有找到清理的办法，在我的列表中还能看到很多上古时代 Windows Phone 的应用。
HOWTO: 为 Intune 启用 Android 设备管理员 注册
HOWTO: 为 Intune 启用 Android 设备管理员 注册
要通过 Intune 管理 Android 设备，也需要将 Android 设备注册到 Intune，目前 Intune 为 Android 设备提供了两种注册管理方式：Android Enterprise 以及 Android 设备管理员。后者也被称为“旧版” Android 管理（随Android 2.2 发布），作为 Android 设备的管理方法，Google 在 Android 5.0 发布时推出了改进的管理功能 – Android Enterprise，用于替代过去的 Android 设备管理员，以实现更现代化、更丰富、更安全的设备管理，目前 Google 正逐渐减少新 Android 版本中对设备管理员的支持。
看到这里，也许你会对 Android Enterprise 产生浓厚的兴趣，但是当阅读完 Google 这篇文档 https://support.google.com/work/android/answer/6270910 热情立刻减半，是的在支持列表中缺少对本地的支持。如果你需要管理本地的 Android 设备则需要考虑继续使用 Android 设备管理员方式。
本文分享的内容也非常的简单，就是为 Intune 启用 Android 设备管理员注册。
首先，登录 Microsoft Endpoint Manager 管理中心，转到“设备 - Android - Android 注册”页面，点击位于页面底部“Android 设备管理员”下的“具有设备管理员特权的个人和公司自有设备”，如下图所示：
之后，在页面中勾选“使用设备管理员管理设备”这个选项。
到此步骤就告一段落，是不是很简单！接下来，就可以在客户端安装 Intune 公司门户了，成功登录后即通过 Android 设备管员 方式注册到 Intune 中。要在本地下载安装 Intune 公司门户应用，可通过如下渠道：
小米
https://go.microsoft.com/fwlink/?linkid=836947
Lenovo
https://go.microsoft.com/fwlink/?linkid=2125082
华为
https://go.microsoft.com/fwlink/?linkid=836948
百度
