本站域名：http://goxia.maytide.net or http://sufan.maytide.net
移动设备请访问：http://goxia.maytide.net/m转载文章，请务必保留出处与作者信息，未经许可严禁用于商业用途！
通过 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 来取消重启的。
微软发布基于 Chromium 的正式版 Microsoft Edge 浏览器
微软发布基于 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 方式部署。
此外对于企业用户还需要了解以下信息：
- Microsoft Edge 稳定渠道的功能更新将按照6周周期进行发布。
- 为了确保 Microsoft Edge 可以无缝融入到 Windows 中，在安装后会对操作系统进行更改。
- Windows 当前版本的 Microsoft Edge 所涉及到的开始菜单Pin、磁贴、任务栏Pin和快捷方式都将迁移到安装的基于 Chromium 的 Microsoft Edge。
- 默认的大多数协议也将迁移到新版 Microsoft Edge。
- Windows 当前版本的 Microsoft Edge将会被隐藏，所有尝试启动都将被重定向到新版 Microsoft Edge。
备注：用户级别安装不会触发这些行为。
文末，gOxiA 建议企业用户使用该浏览器，除了广泛支持不同的 Windows 版本外，还支持跨平台，能够为用户带来一致的使用使用体验，并且支持微软账户或Office 365账户同步。至于兼容性问题，Chromium 内核深受用户喜爱和青睐，标准被广泛采用，这对于前端开发者也是福音。
Windows Autopilot 网络要求
Windows Autopilot 网络要求
在一些网络访问限制性更强的企业环境下，要确保 Windows Autopilot 能够正常的部署，需要为其创建网络访问白名单。由于 Windows Autopilot 依赖相关的 Internet 服务有很多，必须逐个对这些服务进行评估和配置，才能确保 Autopilot 正常工作。以下是 gOxiA 整理的主要服务相关信息：
- Windows Autopilot 部署服务，即 Windows Autopilot Deployment Service，当 Windows 10 设备网络连接就绪后将会连接到该服务。https://ztd.dds.microsoft.com https://cs.dds.microsoft.com
- Windows 激活：
https://go.microsoft.com/
http://go.microsoft.com/
https://login.live.com
https://activation.sls.microsoft.com/
http://crl.microsoft.com/pki/crl/products/MicProSecSerCA_2007-12-04.crl
https://validation.sls.microsoft.com/
https://activation-v2.sls.microsoft.com/
https://validation-v2.sls.microsoft.com/
https://displaycatalog.mp.microsoft.com/
https://licensing.mp.microsoft.com/
https://purchase.mp.microsoft.com/
https://displaycatalog.md.mp.microsoft.com/
https://licensing.md.mp.microsoft.com/
https://purchase.md.mp.microsoft.com/
- Azure Active Directory，由于涉及到身份验证所以必不可少的包含 AAD，具体可参考 https://docs.microsoft.com/zh-cn/office365/enterprise/office-365-ip-web-service
- Intune，在通过身份验证后，AAD 将在 Intune MDM 服务中出发设备注册，所以还要解决 Intune 的网络需求，具体可参考 https://docs.microsoft.com/zh-cn/intune/fundamentals/intune-endpoints
- 在 Autopilot 配置过程中，Windows 可以获取最新的更新补丁，为此建议确保 Windows Update 访问可用，但它不是必须的，因为在 Windows 更新无法访问时，Autopilot 仍将继续。
http://windowsupdate.microsoft.com
http://*.windowsupdate.microsoft.com
https://*.windowsupdate.microsoft.com
http://*.update.microsoft.com
https://*.update.microsoft.com
http://*.windowsupdate.com
http://download.windowsupdate.com
https://download.microsoft.com
http://*.download.windowsupdate.com
http://wustat.windows.com
http://ntservicepack.microsoft.com
- 在 Autopilot 部署过程中，会触发 Windows 更新， Store 应用和更新，Office更新和 Intune Win32 应用数据的下载，此过程将联系传递优化服务以启用对等共享内容，以便只有少数设备需要从 Internet 下载数据。如果传递优化服务不可访问，Autopilot 将继续从云中进行优化传递下载。除HTTP/HTTPS端口外，建议允许 TCP/IP 的 7680 和 3544 端口入站流量。
*.do.dsp.mp.microsoft.com
*.dl.delivery.mp.microsoft.com
*.emdl.ws.microsoft.com
- 时间同步也是 Autopilot 成功部署的关键因素之一，当 Windows 设备启动时，将会与网络时间服务器同步，以确保设备时间准确。为此，我们需要确保 time.windows.com 的 UDP 端口 123 能够访问。
- 域名服务（DNS）就不必过多介绍了，省略……
- 如果您在通过 Windows Analytics 收集部署信息，需确保 诊断数据 有效。具体可参考 https://docs.microsoft.com/zh-cn/windows/privacy/configure-windows-diagnostic-data-in-your-organization#manage-enterprise-diagnostic-data-level
- Windows 必须能够判断出设备可以访问 Internet，请确保能够通过 HTTP 访问 www.msftconnecttest.com，即 网络连接状态指示器（NCSI）
- Windows 推送通知服务（WNS），如果无法访问该服务，将不能接收来自应用和服务的通知，该服务不会阻止 Autopilot 部署，若要允许访问请配置通过 HTTPS 访问 *.wns.windows.com。
- 如果要部署 Store 应用，需确保能够访问如下 URL
login.live.com
login.windows.net
account.live.com
clientconfig.passport.net
windowsphone.com
* .wns.windows.com
* .microsoft.com
* .s-microsoft.com
www.msftncsi.com（Windows 10版本1607之前）
www.msftconnecttest.com/connecttest.txt（ 从Windows 10版本1607开始替换www.msftncsi.com）
- 如果您需要部署 Office 365 ，请参考 Office 365 URL 和 IP 地址范围
- 由于一些服务还需要检查证书吊销列表来确定服务中使用的证书，所以还需要参考 Office 365 URL 和 IP 地址范围，以及Office 365 证书链 继续访问配置。
- 如果在应用 Autopilot Self-Deploying Mode 或 Autopilot White Glove，还需确保能够访问如下 URL，这是因为带有 TPM 的设备在首次使用时需要从制造商哪里检索证书。
Intel- https://ekop.intel.com/ekcertservice
Qualcomm- https://ekcert.spserv.microsoft.com/EKCertificate/GetEKCertificate/v1
AMD- https://ftpm.amd.com/pki/aia
Infineon- https://pki.infineon.com
参考文档：
