最近在运维过程中，遇到了两个历史悠久而且截然不同的疑难问题。但巧合的是，两个问题殊途同归，最后居然使用了同样的解决方法。为了庆祝送别这两个问题，也为了和大家共同学习，共同进步，现在把解决问题的详细过程献出来和大家分享。
先对问题进行一下描述啊。第一个问题就是MSN无法登录！估计很多朋友看到这个题目就要暗自点头，大有一见如故的感觉。这个问题非常普遍，在我们公司更是由来已久。无论用户的级别高低，无论使用的MSN版本新旧，总有一部分不和谐的用户会跑来反映自己的MSN无法登录。按理说，即时通讯软件很不受网管待见，应该学会在夹缝里求生存，登录方式应该手段繁多，花样翻新。什么封装成HTTP，HTTPS，什么通过Web代理，Socks代理，加密代理登录等等，应该让网管觉得MSN登录真是防不胜防，堵不胜堵才好。可MSN倒好，我们还没想限制呢，它先自己顶不住了。
为了解决这个问题，劳动人民可是想了不少主意，大家上网搜了不少办法。什么导入证书法，什么在浏览器中勾选自动检测设置啊，这些方法倒也不是一无是处，可奇怪的是有些办法在张三的机器上行，在李四的机器上就不行，搞来搞去，也没有一个通用的解决办法。最可气的是有些用户第一天能登录，第二天就不能登录了，搞得大家每次登录MSN时心情都忐忑不安，充满了憧憬和期待。以前在MSN中配置代理服务器登录还是比较靠谱的一招，我们在TMG服务器上也配置了防火墙策略，希望用户通过HTTPS协议登录MSN服务器。可后来配置Web代理基本上就毫无作用了。很长一段时间以来，遇到用户无法登录MSN，大家都很头疼去进行技术支持。对比一下吃苦耐劳，从不挑肥拣瘦的QQ，这MSN跟别人的差距可真不是一星半点。
第二个问题也是一个老问题了，WPAD和WSUS之间有冲突。这个问题听起来挺匪夷所思的，WSUS是干嘛的，WSUS是用于给客户机自动更新微软补丁的；WPAD是干嘛的，WPAD是自动在客户机的Web代理或防火墙客户端上配置代理服务器的。咋一看这两者之间没什么关联，可奇怪的是只要一启用WPAD，客户机能自动发现代理服务器的同时会立即和WSUS服务器失去联系。为了解决这个奇怪的问题，我们在微软特意开了CASE，可微软抓了不少包进行分析，最后也没分析出什么结果。结果呢，这个CASE就一直挂在那了。问题没解决，我们只能在WPAD和WSUS之间选择Kill一个了，WSUS是负责更新补丁的，安全问题应该优先保证，所以只能委屈一下WPAD了。
介绍完现有的问题后，再来介绍一下是怎么解决问题的。我们先在MSN问题上找到了突破口，查询微软Technet三月份的安全博客时，忽然发现有篇文章介绍MSN登录原理，文章提到如何希望MSN通过代理服务器登录服务器，仅仅配置Web代理是不够的，MSN只是在完成登录的部分工作时使用到Web代理！注意，这也就意味着如果仅仅在MSN中配置下图所示的Web代理，是无法完成MSN登录的。
通过在客户机上抓包分析，发现MSN登录时要做很多工作，要联系一些*.microsoft.com的服务器，要联系一些*.hotmail.com的服务器，还要联系一些*.live.com和*.msn.com的服务器。当MSN访问这些服务器时，有部分工作可以由Web代理完成，但有些工作是不能通过Web代理的。那剩下的登录工作应该交给谁呢？答案是Winhttp代理！
Winhttp代理和Web代理是两套不同的代理机制，我们在浏览器中配置的代理服务器属于Web代理，那Winhttp代理应该如何配置呢？其实在Win7计算机中使用Netsh就可以轻松配置，如下图所示，我们在Win7客户机中以管理员身份运行一个命令提示符，然后输入：Netsh Winhttp Set Proxy proxy.chamc.com.cn:80。这条指令的目的就是把我们当前使用的代理服务器proxy.chamc.com.cn设置为Winhttp的代理服务器。
设置了Winhttp代理后，果然效果不凡，大家的MSN纷纷能够成功登录了！真是不容易啊，这个该死的微软，居然画蛇添足地设计什么Winhttp代理！群众中有几个人懂这个啊，都使用Web代理不就完事了嘛，这些程序员到底有木有脑子啊！大家正在义愤填膺地谴责微软，忽然有同事发现新问题了。只要在计算机上配置了Winhttp代理，就无法访问WSUS服务器了！
检查一下计算机c:\windows\windowsupdate.log文件，可以发现客户机访问WSUS服务器时的日志内容，日志中有这样的语句DownloadFileInternal failed for http://hq-sus/selfupdate/wuident.cab: error 0x801901f6。这种错误提示和配置WPAD后的错误提示完全相同，这种情况下我们就提高警惕了，为什么WSUS和Winhttp代理之间也有这种兼容性问题呢？
通过查阅资料，发现原来WSUS客户端在访问WSUS服务器时，也是要调用Winhttp代理进行通讯的。由于WSUS客户机和WSUS服务器同在TMG的内网，因此WSUS客户机应该直接访问WSUS服务器，根本不应该客户机先访问到TMG服务器，然后再通过TMG服务器访问WSUS服务器！找到问题之后，怎么解决呢？其实解决方法也很简单，在netsh Winhttp中设置旁路列表，告诉Winhttp代理，访问WSUS服务器不用经过Winhttp代理，这样就可以了。例如WSUS服务器是hq-sus，那么我们就可以在客户机上输入如下图所示命令：Netsh Winhttp set proxy proxy.chamc.com.cn:80 “hq-sus”。这条指令就是通知Winhttp代理，访问hq-sus服务器可以直接访问，不用经过Winhttp代理了。如果有内网其他的服务器要排除，可以用分号隔开，具体语法可以参考http://technet.microsoft.com/en-us/library/cc731131%28WS.10%29.aspx。
在客户机上配置完Netsh Winhttp后，问题解决了。用户可以登录MSN，也不会和WSUS有冲突了，问题貌似圆满解决啊！但是，但是，问题好像还留了一个小尾巴。为什么WSUS和WPAD当初会有冲突呢？难道也是类似原因导致的。在微软网站找资料！找啊找，找啊找，嘿嘿，功夫不负有心人啊，真的被俺找到了。原来Winhttp代理除了可以通过Netsh Winhttp进行配置，还可以通过WPAD进行自动配置。但是，当Winhttp代理通过WPAD下载wpad.dat文件进行自动配置时，由于wpad.dat文件中没有对wsus服务器进行排除，因此WSUS客户端通过Winhttp代理就不会直接访问WSUS服务器。而是需要通过TMG代理服务器去访问WSUS服务器，这样当然是不行的！
搞清楚道理，问题就好解决了。只要在配置WPAD时把内网的WSUS服务器排除之外就OK了。 在TMG服务器上打开管理控制台，找到“网络连接”－“内部”－“属性”中的“Web浏览器”标签，如下图所示，把WSUS服务器hq-sus添加到直接访问的列表中，这样WPAD就会通知使用Web代理或Winhttp代理不要通过代理服务器访问WSUS服务器，如果还有其他的服务器要排除，参考这种操作就可以。
排除的服务器可以通过TMG服务器上的wpad.dat文件体现出来，我们可以使用浏览器从TMG服务器上下载wpad.dat文件查看排除服务器列表。如下图所示，我们使用记事本打开TMG服务器上的wpad.dat，可以看到WSUS服务器hq-sus已经被排除使用代理服务器访问了。
现在，通过在WPAD中设置排除服务器，WPAD可以启用了。用户的Winhttp代理可以通过WPAD自动获取配置，不需要通过Netsh Winhttp进行配置。现在，用户登录MSN，访问WSUS服务器都没有问题了，非常和谐。从这个问题中，我们可以得出两个结论：第一是不要迷信微软，微软的产品之间也会有兼容性问题；第二是一定要相信微软，问题最终还是可以解决的。