iis6升级iis7

从IIS6到IIS7，不是一次简单升级，而是一次推倒重来。我当年把生产服务器从Windows Server 2003迁到2008时，第一反应是：这玩意儿怎么不听话了？

IIS6的配置逻辑是“网站-虚拟目录-应用程序”，你右键属性，弹出一堆标签页，找路径、找文档、找目录安全性。IIS7把这一切拆了，变成了一个模块化架构。你在功能视图里看到的不是属性框，而是一堆图标，双击进去才是配置。这种感觉，就像你从老式诺基亚的九宫格菜单，突然换到iOS的设置列表——东西更多了，但更碎了。

最坑的是权限模型。IIS6下，你给匿名用户映射一个IUSR_机器名账号就完了。IIS7默认用应用程序池标识（ApplicationPoolIdentity）跑worker process，这个虚拟账号的权限控制全靠Windows安全描述符。我第一次部署时，图片能访问，CSS加载不出来，查了半天发现是静态文件目录的NTFS权限没给IUSR加上。你得同时给IIS_IUSRS组和IUSR账号授权，漏一个就是404或401。

再说URL重写。IIS6时代，你要做伪静态，要么装第三方ISAPI筛选器，要么自己写HTTP模块。IIS7内置了URL Rewrite模块，但很多人不知道它默认不安装——你得在“添加角色服务”里勾选。我见过一个同事，把老代码里的HttpModule直接复制到IIS7的bin目录，结果站点直接崩溃，因为IIS7的管道模式默认是Integrated（集成）模式，老模块里如果写了BeginRequest事件并且调用了Response.Write，会跟静态文件处理器冲突。解决方式很简单：把应用程序池的托管管道模式改成Classic（经典）模式，但代价是失去集成模式下的所有优势，比如对静态文件的认证授权。

还有web.config的变更。IIS6里，配置系统是元数据库（metabase.xml），你改完要重启IIS才生效。IIS7全改成了XML文件，分布在applicationHost.config和各个站点的web.config里。好处是支持xcopy部署，坏处是——如果你在web.config里写错了节点名，整个站点直接500.19，错误信息提示你“无法识别的配置节”。我踩过这个坑：把IIS6的配置段直接抄过来，结果IIS7根本不认，因为错误页配置已经挪到了下的，而且格式完全不同。

升级路径上，微软提供了一个工具叫“IIS 6.0 Migration Tool”，能把站点、应用池、虚拟目录的配置导成XML再导入IIS7。但实际用下来，它只能迁移基础设置——绑定、路径、默认文档。像自定义错误页、ISAPI筛选器、MIME类型这些，全得手动补。我当时迁移一个老旧的ASP站点，MIME类型里有个.rar后缀的，迁移后直接丢失，用户下载全变404。

最后说性能。IIS7的应用程序池默认启用了“自动回收”和“重叠回收”，这比IIS6的定时回收平滑多了。但注意，如果你在代码里用了Application_End事件做清理，重叠回收会导致新进程启动时旧进程还没完全销毁，你的清理代码可能跑两次。别问我怎么知道的，线上日志里一堆重复的SQL delete操作。

所以，升级IIS7的真正门槛不在安装，而在心理模型转换。你得忘记“属性框”思维，接受“模块+配置节”的模式。如果老系统只是静态页面+简单ASP.NET表单，那直接迁就行。但如果有自定义HTTP模块、ISAPI扩展、或者依赖元数据库的脚本，老老实实花时间测试每个功能点。别信什么“平滑迁移”，那只是微软官方文档里的漂亮话。