[Office]HOWTO: 解决 Outlook 无法打开正文嵌入的文件对象 故障
HOWTO: 解决 Outlook 无法打开正文嵌入的文件对象 故障
最近一段时间应该有不少用户遭遇到了Outlook无法打开正文嵌入的文件对象 故障，具体表现为会议约会正文中嵌入的文档对象无法正常打开，会提示“用于创建此对象的程序时Outlook。您的计算机尚未安装此程序或此程序无响应。若要编辑此对象，请安装Outlook或确保Outlook中的任何对话框已关闭。”如下图所示：
出现该问题是由于用户安装了微软于6月13日发布的 Office 安全补丁（KB3203467）所致，该补丁旨在修复用户打开经特殊设计的 Office 文件时可能允许执行代码的漏洞，但是该补丁存在已知问题会导致用户无法正常打开 Outlook 附件或正文中嵌入的文件对象。
在7月5日微软又发布了 KB4011042 用于解决 KB3203467 已知问题，但随后又撤掉了该更新补丁。可能该补丁存在一些问题，直至7月25日微软终于重新发布了用于修复 Office 文件可能允许远程执行代码的漏洞补丁——KB2956078，并且还修复了打开附件或嵌入的文件对象失败的已知问题。对于还在使用 Office 2007 的用户，请安装 KB3213643 解决此问题。
使用Hyper-V VLAN功能组建受隔离的网络环境
使用Hyper-V VLAN功能组建受隔离的网络环境
在开始今天的分享前，gOxiA 带着大家前先了解下面的截图，这样才能更好的理解所要分享的内容。在一个企业网络内（Corp LAN），已经部署了DC、DNS、DHCP、WDS等服务器，是一个完整的生产环境。在 10.1.50.x 的子网内 gOxiA 有三台 Hyper-V 主机（两台基于 Windows 10，一台基于 Windows Server 2016）进行工作相关的测试和评估。
默认情况下三台 Hyper-V 主机与 Corp LAN 是可以相互访问的，这个应该很容易理解吧；现在为这三台Hyper-V 主机分别创建了虚拟交换机 vNet-LAN50，那意味着其上的虚拟机将从 10.1.50.x 获取网络地址，并运行相互访问，到这里也很容易理解吧；由于一些测试需要进行隔离，通常会在Hyper-V 主机上创建 VMs Only LAN，仅供当前Hyper-V 主机上的虚拟机相互访问，或在当前 vNet-LAN50 上启用 VLAN 分配 ID 20 进行隔离，到这里相信也能理解；OK，我们继续，现在由于一个测试任务过于庞大所需的硬件资源很高，无法在一台Hyper-V主机上进行，需要现有的三台 Hyper-V 主机组网使用，且不变动现有的物理网络环境，同时实现与现有逻辑网络隔离。
如果为每台虚拟机创建单独的网络，如192.168.192.x，是可以实现相互通讯的，但是并未完全实现逻辑网络的隔离，假如虚机部署了 DHCP 服务，那么极有可能会对现有的 Corp LAN 产生影响。但是启用虚机 VLAN 后，怎么实现跨 Hyper-V 主机访问呢？！按理说 vNet-LAN50 这个虚拟交换机的物理接口是 Hyper-V 主机上与 10.1.50.x 相连的网卡，由于是透明通讯，虚拟机设置 VLAN20 后理应透过 vNet-LAN50 与其他 Hyper-V 主机上 VLAN20 的虚机通讯，但是现实很残酷并非如所想的那样！！！
经过测试需要通过 Hyper-V 的 Virtual Switch Manager（虚拟交换机管理器）为当前网络即 vNet-LAN50 也启用 VLAN ID 20，才能实现跨 Hyper-V 主机 的 VLAN 段虚机互访。
虽然该法实现了最终的需求，但也确实与现有逻辑网络完全隔离，这意味着原有 10.1.50.x 段中的其他设备将无法访问这三台 Hyper-V 主机，否则也必须修改 VLAN 为 20。（如果 Hyper-V 主机是多宿主，倒是很好解决！）
深入探讨 网站想要使用你计算机上的程序打开Web内容
深入探讨 网站想要使用你计算机上的程序打开Web内容
gOxiA 因为工作需要最近在做与桌面虚拟化相关的技术内容，期间就遇到了“网站想要使用你计算机上的程序打开 Web 内容”的问题。具体是在用户安装 VDA 客户端后，通过 IE 访问 VDI 门户时会弹出这个提示，如下图所示。其实问题是比较简单的，为了避免下次再弹出提示框，我们通常会复选“不再对此程序显示此警告”，然后点击“允许”。这样在访问 VDI 门户后就会直接启动 VDA 客户端正常访问。
之后 gOxiA 又用 Microsoft Edge 访问测试了一下，会直接提示下载一个扩展名为 ICA 的文件，而这个 ICA 在当前系统上被注册为使用一个特定的应用程序打开。
也就是说在整个访问过程中是浏览器下载了一个文件，然后由指定的应用程序打开它，当在 IE 浏览器环境下时可通过复选“不再对此程序显示此警告”然后“允许”来实现通过应用程序直接打开文件的操作，这样用户体验就会更顺畅。
那么问题来了，用户说如果我复选了“不再对此程序显示此警告”，然后点击了“不允许”，可发现是误操作了该怎么办呢？该如何恢复呢？为此，gOxiA 检查了 IE 设置还真的不像禁用弹出窗口、或兼容性视图设置那样会有明确的设置选项且支持修改操作。由于通常也都是习惯于正确的操作，确实会忽略掉如果复选不再显示警告并点击了不允许会有什么结果。
期间也有咨询过微软支持，但也没有准确的解答，无奈只能自己研究 。使用 Procmon 抓包来看看这一设置都做了什么操作？！
还挺轻松立刻就锁定了位置，当我们在弹出“网站想要使用你计算机上的程序打开Web内容”的警告窗体上，复选“不再对此程序显示次警告”，并点击“允许“后，iexplore 进程会在注册表的 “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy\” 下生成一个新的 GUID 项，并写入该程序的相关键值。其中 AppPath 和 AppName 是容易理解的，也没有什么特殊之处，而 Policy 则是非常关键，默认键值为”3“。如果我们修改了这个值，例如：2，那么再下次访问时又会重新弹出警告让用户选择，只有值为3时才会默认通过安装的应用打开下载的 ICA，而不再弹出任何提示。此外，在重新复选并允许后 iexplore 进程并不会修改之前已经添加的项和对应的键值，而是会重新生成一个新的项，很有意思！
接下来 gOxiA 又重新做了一次抓包，但这次操作是复选不再提示后不允许运行，但在抓包数据中分析发现，执行这一操作并不会写入任何设置。也就是说即使用户复选了不再提示，只要点击的是不允许，那么前面的复选设置是不会起到任何效果的。
至此，答案已经出来，我们也不必担心用户是否会进行误操作，如果出现 IE 访问 VDI 门户没有启动 VDA 客户端的故障问题，那么直接从 VDA 下手排错即可，无需再在 IE 身上徘徊！
后来微软支持也给找到了一篇文档，原来早在2009年时就有微软人士详细讲解过这个安全功能，具体可参考下面这篇 Blog ：
