<?xml version="1.0" encoding="UTF-8" ?>
<rss version="2.0">
<channel>
<title><![CDATA[gOxiA=苏繁=SuFan Blog]]></title> 
<link>https://maytide.net/index.php</link> 
<description><![CDATA[gOxiA,苏繁,sufan,Microsoft MVP]]></description> 
<language>zh-cn</language> 
<copyright><![CDATA[gOxiA=苏繁=SuFan Blog]]></copyright>
<item>
<link>https://maytide.net/read.php/1861.htm</link>
<title><![CDATA[HOWTO: 解决Outlook邮件正文无法正确插入UNC类型快捷方式链接的问题]]></title> 
<author>gOxiA &lt;sufan_cn@msn.com&gt;</author>
<category><![CDATA[Windows Client]]></category>
<pubDate>Mon, 13 Nov 2017 06:29:27 +0000</pubDate> 
<guid>https://maytide.net/read.php/1861.htm</guid> 
<description>
<![CDATA[ 
	<p><a href="http://goxia.maytide.net/ftpup/2016/a2734efd2a17_D06F/troubleshooting.png"><img width="400" height="250" title="troubleshooting" alt="troubleshooting" src="http://goxia.maytide.net/ftpup/2016/a2734efd2a17_D06F/troubleshooting_thumb.png" border="0"></a></p><p><strong><font color="#fd3f0d" size="4">HOWTO: 解决 Outlook 邮件正文无法正确插入UNC类型快捷方式链接的问题</font></strong></p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;实在想不出更准确的题目，所以在分享前，<a href="http://goxia.maytide.net" target="_blank">gOxIA</a> 觉得很有必要详细描述一下这个故障现象。用户环境是 Windows 7 + Office 2010（经典组合），在其桌面上有一个文件夹快捷方式（.lnk），目标指向到的是一个 UNC 路径，结构基本就是“&#92;&#92;&#92;&#92;10.0.0.1&#92;&#92;aaa&#92;&#92;bbb&#92;&#92;ccc&#92;&#92;ddd&#92;&#92;eee”这个样子，当然示例路径中的字母在实际环境下是中文+符号。如下图所示：</p><p><a href="http://goxia.maytide.net/ftpup/2017/HOWTO-OutlookUNC_B89E/1.png"><img width="368" height="474" title="1" style="border: 0px currentcolor; border-image: none; display: inline; background-image: none;" alt="1" src="http://goxia.maytide.net/ftpup/2017/HOWTO-OutlookUNC_B89E/1_thumb.png" border="0"></a></p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;故障现象：用户在 Outlook 中撰写一封邮件，在正文部分使用“插入——超链接”功能，添加这个桌面快捷方式的地址。正常情况下，“插入超链接”窗口中的“地址”中显示的应该是这个快捷方式（lnk）的实际 UNC 路径，确定后邮件正文中添加的也应该是这个 UNC 路径。</p><p><a href="http://goxia.maytide.net/ftpup/2017/HOWTO-OutlookUNC_B89E/2.png"><img width="630" height="379" title="2" style="border: 0px currentcolor; border-image: none; display: inline; background-image: none;" alt="2" src="http://goxia.maytide.net/ftpup/2017/HOWTO-OutlookUNC_B89E/2_thumb.png" border="0"></a></p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;但是在用户故障环境下，显示和插入的结果却是这个快捷方式（lnk）的本地路径，如下图所示：</p><p><a href="http://goxia.maytide.net/ftpup/2017/HOWTO-OutlookUNC_B89E/3.png"><img width="630" height="293" title="3" style="border: 0px currentcolor; border-image: none; display: inline; background-image: none;" alt="3" src="http://goxia.maytide.net/ftpup/2017/HOWTO-OutlookUNC_B89E/3_thumb.png" border="0"></a></p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;问题虽小，但用户重视程度之高，在其他用户电脑上测试发现显示的确实为 UNC 路径，那么说明这个问题是一个故障。在打 Office 补丁，甚至重装了 Office 后，故障仍未解决。从故障看很可能是一直问题，所以决定寻求官方支持，但结果是 by design，或第三方插件干扰，实在无法接受这个解释！从经验来看这个问题很明显是一个故障，并且很可能是产品的已知问题。</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;看来必须要在自己的测试环境下重现故障，才能更好的寻找根因！随即开了一台虚拟机配置好了环境，但未重现故障，对比版本后得到如下信息：</p><p><font style="background-color: rgb(255, 255, 0);">用户环境：系统6.1.7601.17567&nbsp;&nbsp;&nbsp;&nbsp;Office14.0.7015.1000</font></p><p><font style="background-color: rgb(255, 255, 0);">测试环境：系统6.1.7601.23537&nbsp;&nbsp;&nbsp;&nbsp;Office14.0.7181.5000</font></p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;基本可以确认用户环境肯定是缺少了什么补丁所致，因为Office 2010也有安装 SP2，而后续的零星补丁又太琐碎，也尝试直接覆盖文件，但并未解决，可以判定该问题与 Office 补丁无关，那肯定就出在系统上面了。</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;随后，重新搭建了测试环境，为虚拟机安装 RTM 版操作系统和 Office，果然重现了故障。RTM 环境下的版本信息如下：</p><p><font style="background-color: rgb(255, 255, 0);">RTM环境：系统6.1.7601.17514&nbsp;&nbsp;&nbsp;&nbsp;Office14.0.7015.1000</font></p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;至此已经明确了故障问题，用户因缺少某个系统补丁，导致在插入一个 UNC 类型的快捷方式时，会出现未达预期的结果。通过测试，并不是所有的 UNC 快捷方式都会出现这个问题，难道是中文长路径所致？但长度并未超过 256，且字符也属常见类型，看来只能通过 Process Monitor 抓包进行分析。</p><p><a href="http://goxia.maytide.net/ftpup/2017/HOWTO-OutlookUNC_B89E/4.png"><img width="630" height="159" title="4" style="border: 0px currentcolor; border-image: none; display: inline; background-image: none;" alt="4" src="http://goxia.maytide.net/ftpup/2017/HOWTO-OutlookUNC_B89E/4_thumb.png" border="0"></a></p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;在抓包的数据中发现了问题！当添加超链接时，进程会遍历这个 lnk 所对应的 UNC 路径，但此时却出现了拒绝访问，如上图所示。根据分析的结果对这个 lnk 对应的 UNC 每一级目录进行了访问测试，果然如此！这个 UNC 路径“&#92;&#92;&#92;&#92;10.0.0.1&#92;&#92;aaa&#92;&#92;bbb&#92;&#92;ccc&#92;&#92;ddd&#92;&#92;eee”中，其中 DDD 和 EEE 是允许用户访问的，而上一级目录则禁止当前用户访问。</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;这也进一步验证了，该故障属于一个 Windows 的已知问题，接下来就是对更新补丁进行验证。将 RTM 测试环境接入内网 WSUS，拿到了 103 个补丁，这些补丁包含了安全和质量更新，还有汇总更新补丁。在一次打完所有补丁后进行测试发现故障消除! Great，可算有了里程碑式的进展，那么这 100 多个补丁中哪个才是修复当前故障问题的补丁呢？</p><p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;要对 103 个补丁进行测试真的是一个巨大、枯燥，令人抓狂的工作，最终锁定 <a href="https://support.microsoft.com/en-us/help/4022722/windows-7-update-kb4022722" target="_blank">KB4022722</a> 这个补丁！！！至此故障彻底解除，结尾要与大家分享一个重要的经验，在处理 Windows 故障，尤其涉及更新补丁时，在关键节点判断问题类型十分重要，如果分析归类为已知问题，应确认该问题是属于安全的还是质量的，这样才能有效减少工作量！！！（:-P）</p>
]]>
</description>
</item>
</channel>
</rss>