IIS7报500.23错误的原因分析及解决方法

　　今天公司终端上有一个功能打开异常，报500错误，我用Fiddler找到链接，然后在IE里打开，报500.23错误：检测到在集成的托管管道模式下不适用的ASP.NET设置。后台是一个IIS7和tomcat7集成的环境，此处记录一下。

　　HTTP 错误 500.23 – Internal Server Error

　　检测到在集成的托管管道模式下不适用的 ASP.NET 设置。

　　为什么会出现以上错误？

　　在IIS7的应用程序池有两种模式，一种是“集成模式”，一种是“经典模式”。

　　经典模式则是我们以前习惯的IIS 6 的方式。

　　如果使用集成模式，那么对自定义的httpModules 和 httpHandlers 就要修改配置文件，需要将他们转移到和节里去。

　　两种解决方法：

　　第一种方法、配置应用程序池

　　在IIS7上配置应用程序池，并且将程序池的模式改为“经典”，之后一切正常。如图：

　　用了IIS7.x,但实际只发挥了6的功能，另外，在一些ASP.NET MVC程序中的效果也不好，所以，我们尝试以下解决方法：

　　第二种方法、修改web.config配置文件：

　　注： web.config路径C:\inetpub\wwwroot\web.config

　　例如原先设置(你的环境中可能没有httpModules，httpHandlers节点)

　　IIS Log的位置

　　IIS 6.0的Log日志存储在:

　　c:\windows\system32\logfiles\

　　IIS 7 Log存储在:

　　%SystemDrive%\inetpub\logs\LogFiles

　　经过我的测试, IIS日志是即时写入的, 不需要IIS reset.

　　IIS 6. 7的日志写入按不同站点写入不同的文件夹, 位置文件夹的格式都是”w3svc{siteId}”.

　　IIS6里, 查看站点ID的方式是通过IIS log的文件夹的名字来确定Site ID.

　　IIS7中, 在IIS管理器中的advanced settings中, General里的ID就是Site ID, 然后你需要通过这个ID来定位LogFiles文件夹中哪一个文件夹属于你要查看的站点.

　　Intergrated和Classic的区别

　　IIS7的Application Pools有两种mode，一种是Integrated，一种是classic。如果使用Integrated模式，那么对自定义的httpModules和httpHandlers就要修改配置文件了，需要将他们转移到和节里去。

　　IIS7的两种模式和IIS6有什么区别？

　　IIS7.0 Integrated mode：asp.net 的modules和handlers从下的 和里读取，以前的下的 和配置节会被忽略，如果设置禁止验证(disabledvalidation)，是不会产生错误的。

　　IIS7.0 Classic mode： 与 以上情况是相反的，和会被忽略。

　　经典模式是IIS6.0以及以下版本的唯一工作模式(只工作在ISAPI EXTENSION,ISAPI FILTERS下)。在此种模式下asp.net只是一个分别实现了ISAPIEXTENSION和ISAPI FILTER的插件(aspnet_isapi.dll,aspnet_filter.dll)，IIs的工作只是将特定的请求转发给Asp.net，与 PHP等等寄宿在IIS中的插件别无二致。

　　然而在集成模式里，IIS的管道与Asp.net的请求管道是紧密集成 的，Asp.net可以完全控制，访问整个请求管道。Asp.net不在作为一个外部插件，而是完全集成在IIS中。在此模式下，Asp.net HttpModules与ISAPI Filter拥有等同的控制权，Asp.net HttpHandlers与ISAPI Extension拥有等同控制权，换而言之Asp.net已经是IIS的一部分了。

　　如 果要兼顾IIS6及IIS7.可在web.config中同时保留httpHandlers(for IIS6)及handlers(for IIS7)里的相同定义，但记得要加上，不然IIS7会因为定义重覆出现而发生错误。