HOWTO: 解决因禁用防火墙服务引发的 Outlook 附件预览故障
HOWTO: 解决因禁用防火墙服务引发的 Outlook 附件预览故障
MPSSvc is a core service! MPSSvc is a core service! MPSSvc is a core service! [ 重要的事情说三遍！！！]
MPSSvc是什么服务？干什么用的？
为了获取 MPSSvc 服务的相关信息，使用命令行 “sc qc mpssvc” 进行查看，可得知 MPSSvc 就是 Windows Defender Firewall，即 Windows 防火墙服务，启动方式为自启动。从遥远的 XP 时代开始，这个服务就存在，而且随着 Windows 系统的发展，已经成为必要的核心级服务。
而一些 “聪明” 的 IT 人员为了避免客户端计算机的 Windows 防火墙功能影响正常使用和管理，使用了自认为最有效的方法来禁用它！即，通过域 GPO 直接禁用 Windows Firewall（MPSSvc）服务。下发策略后，确实像 XP、Win7这样的客户端运行照旧，貌似没什么不良的影响，也满足了 IT 管理员的 “目标”，因为那些防火墙问题的报修有效减少了。
但是在后续的发展阶段，随着 Win8、Win8.1 的发布，到现在 Win10 的发布，企业中运行 Win10 的客户端计算机也越来越多，而微软也一直在致力于改善 Windows 的安全功能以提高安全性。那么问题来了，一些用户开始抱怨自己的 Outlook 无法正常预览 Office 附件，且在双击打开这些附件后会报错。
在预览附件时的报错提示为“不能预览此文件，因为以下预览程序发生了错误：...”；如果双击打开这个 Office 附件，则会提示“内存或磁盘空间不足，Microsoft ... 无法再次打开或保存任何文档。”在故障发生的起初，进行排错时一直都没有想到是防火墙导致的故障。（PS：谁会想到 “聪明” 的 IT 会如此禁用 WFW）
在无奈之际，使用 Procmon 对执行 trace 进行了捕获，进行具体的分析。在密密麻麻的记录中，终于找到了线索。当用户执行预览时，会触发一个对防火墙动态链接库的查询操作，由于 GPO 禁用了防火墙服务的启动，所以未能找到相关的资源。
当时为了验证，立刻检查了防火墙服务，果然被禁用导致无法正常启动。恢复设置后，故障解除。（PS：就此问题与 IT 理论的结果就是之前怎么没问题，现在怎么就出问题，压根就不是禁用防护墙服务的问题嘛！）
所以呢，要其变更下发的 GPO 是没戏了，为此想了一个 Workaround，即通过计划任务在每次启动系统后使用 sc 命令将 mpssvc 改为自启动，并启动它。具体的命令如下：
在编写上段命令前，曾尝试调整 Office 的安全设置，将打开有异常的 Office 文档的程序保护试图功能关闭，如下图所示。但是在 Outlook 中预览还是无法解决。
就 Windows 防火墙 与 Office 的问题，微软也发布了知识库进行了说明和解释。当同时满足以下条件时，则会发生上述描述的故障问题。
- Windows防火墙服务没有运行
- Windows 10、Windows 8.1、Windows 8 或基于 Windows Server 2012 的计算机上使用 Outlook 2016 或 Outlook 2013
具体是因为 Outlook 中的预览功能使用受保护的试图功能（也成为沙盒）。在 Microsoft Office 2010 引入了此功能。在 Windows 10、 Windows 8.1、Windows 8 和 Windows Server 2012，受保护的试图功能改进了 AppContainer 功能的结合。这提供了更强的进程隔离，并且它还会阻止从沙盒的网络访问。
参考资料：KB2912722
HOWTO：禁用 Windows 10 更新
HOWTO: 禁用 Windows 更新
Windows as a Service 是大势所趋，满足了大多数用户的需求。在过去用户总是抱怨 Windows 更新周期过慢，现在 Windows 10 每半年就会推出一个功能更新，但也并不是所有的用户都感到满意，真是众口难调！之前抱怨 Windows 更新过慢的一些企业用户，反而现在又抱怨更新过快！gOxiA 倒认为，其实他们的抱怨不是因为更新过快，而是因为每半年一次的功能更新常会发生更新失败的问题，这就增加了 IT 维护成本。导致更新失败的原因确实很多，在企业中常见的是因为一些第三方安全软件导致的，所以 In-Place Upgrade 就极易失败。最终，IT 希望能禁用或推迟 Windows 10 的功能更新，但在实际操作中发现并不能彻底禁用功能更新补丁的推送，这主要是因为 Waas 策略导致的，要求客户端要获得持续的支持就必须更新到最新版本，所以在到达推迟更新的最后期限后 Windows 10 仍旧会接收功能更新。
有不少 IT 人员来咨询是否有什么方案能解决这一问题？！网上也提供了很多种禁用更新的方法，但多少都有些瑕疵，其实我们完全可以借助微软 GPO 来实现禁用功能更新的需求。
首先在企业内部部署 WSUS，使客户端接入到 WSUS 上接受企业的统一更新管理，这样企业 IT 可以利用 WSUS 的审批功能只允许每月的安全更新。
虽然 Windows 客户端连接到 WSUS 上接受管理，但仍旧可以从微软官方获取更新，这就导致功能更新最终会被推送到系统上，尤其是“微软 Windows 10 易升”这样的工具。
所以我们还需要阻断到微软更新服务器的连接，为此我们使用 GPO 来实现。在“计算机配置 /管理模板/Windows 组件/Windows 更新”中找到“不要连接任何 Windows 更新 Internet 位置”，将其设置为“已启用”。
gOxiA 专门写了一个脚本，可通过 Github 获取。
https://github.com/goxia/ITSM/blob/master/W10_DisableOSUpgrade.bat
Windows Defender Application Guard 快速体验
Windows Defender Application Guard 快速体验
为了阻止以前出现过的以及新涌现的攻击，微软为 Windows 10 v1709 新增了一个安全功能，利用独特的硬件隔离方法来化解来自互联网的攻击。这项安全功能称之为“Windows Defender Application Guard”（以下简称：WDAG），专为 Windows 10 和 Microsoft Edge 设计，WDAG可有效隔离用户或企业不受信任的站点，从而在浏览 Internet 时提供保护。应用的隔离容器技术基于Hyper-V，简单理解就是当用户触发访问不受信任的站点时，Microsoft Edge 将在 Hyper-V 的隔离容器中打开这些网站，这样就可以将网站与主机操作系统隔离开来，使主机系统得到保护，有效阻止攻击者。
在 Windows 10 v1709 版时，要启用 WDAG 需要企业版，但自 Windows 10 v1803 开始专业版（Pro）也可直接开启 WDAG，但一些管理、数据和打印支持特性仍需要企业版。
要安装和启用 WDAG 只需要通过 Windows 程序和功能 添加即可，如下图所示。当然我们也可以通过 PowerShell 命令行安装。
虽然 WDAG 基于 Hyper-V，但是在安装“Windows Defender 应用程序防护”时，并不需要事先安装和配置 Hyper-V Role，而且与其也并不冲突，但是如果你要在虚拟机中体验 WDAG 是不受支持的。
要使用 WDAG 只需要运行 Microsoft Edge，在菜单中点击“New Application Guard window”（新应用程序窗口，PS：由于当时测试使用的是英文系统，所以截图为英文界面。）即可启动。
在首次启动 WDAG 时会进行初始化，gOxiA 使用的是固态硬盘，所以并没有等待太久，初始化完毕后会打开一个新的 Microsoft Edge，其窗口边缘为醒目的橙色，且左上角也有醒目的“Application Guard”图标，便于用户识别。
前面已经讲过，WDAG采用了隔离技术，默认配置下是不能在 WDAG 和主机系统间交互数据的，而且在 WDAG 中下载的一些资源也无法执行，但是就目前测试看处理流程上还有待完善，例如 gOxiA 在 WDAG 中点击了一个 PDF 链接并打开，是可以在 WDAG 中阅读这个 PDF 文件的，但是如果关闭后从下载列表中再次打开时则会被拒绝，当然也无法通过右键点击复制，将其从 WDAG 环境下复制到主机系统。
另一个有意思的发现是 WDAG 呈现出来的 Edge 是基于 RDP 的，可以在任务管理器中看到这个进程“hvsirdpclient.exe”，那么 WDAG 应该还用到了 RemoteApp。继续深挖，当然是想看看 WDAG 的系统环境，因为在主机系统环境下还能看到“vmmem”这个进程，占用了 1GB 的内存，它应该就是 WDAG 实例。
要想一探 WDAG 实例环境，只能从当前打开的 WDAG Microsoft Edge 入手，如下图所示 gOxiA 成功打开了 WDAG 的资源管理器，WDAG 的磁盘大小约40GB，查看占用的容量显示为 2.34GB（PS：有意思，占用了这么少的空间，怪不得启动速度有所保障。），但是其系统盘根目录下有个名为WDAG的子目录，存放这一个目录重定向文件，占用了4GB左右，而这个文件貌似是直接映射的 WDAG 主机系统下的目录文件，从命名看应该是供用户读写的区域。
之所以会有前面的说法，是因为通过对进程的监视发现 WDAG 这个虚拟机相关的资源文件相当复杂，除了常见的虚机 VHDX 外，还在其基础上生成了多个差异磁盘，而这些虚拟磁盘文件都只有几百兆的容量，要想单独拷贝出来 Mount 查看其内部结构或加载到 Hyper-V 跑一跑是不可能的。而且 WDAG 的资源目录中还有一个名为 Base 的目录，包含了完整的 Windows 目录结构，而这个目录应该就是前面提到的目录重定向的源文件。
有兴趣的朋友可以在深入挖掘，貌似微软针对 WDAG 的安全性问题还有奖励活动。最后概览一下 WDAG 这个系统环境，当前版本是 10.0.17134 即 1803 版 Windows 10，而且是个专业版，但这个专业版貌似又运行在 S Mode 下，因为无法在 WDAG 下执行传统 EXE 程序，当然 UWP 应用也被禁用了（PS：也许还应用了 AppLocker 技术进行了限制）。此外，要想在 WDAG 与主机环境交换数据或应用打印，是需要企业版支持的，且需要配合组策略（GPO）进行配置，此外通过组策略还可以为企业提供 WDAG 的统一管理特性，如果您所在的企业对 WDAG 感兴趣可联系 gOxiA 获得咨询服务。
小贴士：
- 重置容器环境，并放弃用户在WDAG中生成的所有数据
C:\Windows\System32\wdagtool.exe cleanup RESET_PERSISTENCE_LAYER
