IIS75补丁包

IIS 7.5的丁包最后一个官方补丁包，微软代号KB2672806，丁包发布于2013年10月。丁包说实话，丁包这玩意儿现在还在生产环境里跑着的丁包数量，比微软自己预想的丁包要多得多。我上个月还帮一家本地物流公司处理过他们那台Windows Server 2008 R2上的丁包IIS 7.5，补丁打到2013年就再没动过——不是丁包不想动，是丁包动不了，业务系统绑死了.NET 2.0的丁包老应用。

这个补丁包本身不解决什么惊天动地的丁包大问题。它修的丁包是几处远程代码执行漏洞，CVE-2013-1297那批，丁包还有几个FTP服务的丁包内存泄漏。真正有意思的丁包是补丁的安装方式——你得先装一个前置更新KB2533623，不然补丁直接报错退出。很多人卡在这一步，网上论坛里至今还能翻到当年的求助帖，有人把错误代码0x80070005贴出来问，底下回答五花八门，最后发现是权限不够，没以管理员身份运行。

我见过最典型的场景是这样的：一台跑了五年多的服务器，IIS 7.5上挂了几十个站点，其中一半是别人遗留下来的，没人知道具体是什么业务。你根本不敢随便打补丁重启，因为没人能保证IIS服务起来之后那些老站点还能正常响应。有个运维朋友跟我说过一句大实话——“IIS 7.5补丁包不是技术问题，是业务问题。”他所在的单位最后花了三个月时间，才把那些无主站点一个个确认、迁移、关停，最后才敢给那台服务器打上补丁。

补丁包里还有个细节容易被忽略——它同时更新了web.config的schema验证逻辑。这意味着打完补丁后，某些原本能过验证的配置项可能变得不合法。具体来说，<httpRuntime>里如果用了enableVersionHeader的旧写法，补丁后IIS会直接拒绝加载应用池。这事当年坑过不少人，因为很多老项目的配置文件是从2008年复制过来的，根本没人去检查那行设置。

另一个冷门但实际的情况是，这个补丁包对URL重写模块的兼容性有影响。如果你装了第三方的URL Rewrite 2.0，打完补丁后重写规则可能失效，日志里会频繁出现500.19错误。解决办法倒是简单——重新安装一次URL Rewrite模块就行，但问题在于很多人压根不知道两者之间存在关联，只会反复重启IIS，然后对着事件查看器里看不懂的错误码发呆。

现在回头看，IIS 7.5补丁包的寿命早就终结了。微软的主流支持在2015年结束，扩展支持到2020年1月也停了。但现实是，国内还有不少中小企业服务器跑在2008 R2上，IIS 7.5依然是他们最熟悉的东西。有人问为什么不升级，答案往往不是技术上的，而是预算和业务连续性考虑——换一台新服务器意味着要重做整个环境，要测试所有老应用的兼容性，要花时间培训运维人员。这些成本加起来，比买几台新机器高得多。

所以那个2013年的补丁包，到现在还被某些人当作宝贝一样存在硬盘里。我见过一个做IT外包的老哥，U盘里专门放了个文件夹叫“IIS75_补丁”，里面除了KB2672806，还有当年微软发布的几个hotfix，都是他这些年跑客户积累下来的。他说这玩意儿关键时刻能救命——有些客户服务器连外网都不通，更别提Windows Update了，只能靠他U盘里这点东西手动打补丁。

说到底，一个补丁包的价值不在于它修了多少漏洞，而在于它让一套老系统还能继续稳定跑下去。技术世界更新换代很快，但现实世界的系统迁移永远比技术迭代慢半拍。IIS 7.5补丁包就是个缩影——你明知道它已经过时了，但在某些角落，它还是一根实实在在的拐杖。