IIS 7.0 支持兩種管道模式：一種是IIS 7.0最新提供的集成管道模式，另一種是經典管道模式，經典管道模式是由先前版本的IIS提供的。
我們可以通過應用程序池設置管道模式，這項功能對IIS管理員尤其有用，因為這樣既可以令一台服務器僅運行一種模式，也可以令兩種模式同時運行於一台服務器上。
上述兩種管道模式使用的web.config文件存在重大的區別，許多在經典管道模式下能夠正常工作的web.config文件都無法在集成管道模式下正常工作。利用AppCmd.exe，我們可以將經典管道模式下的配置文件格式自動轉換為集成管道模式下的配置文件格式。
我們有必要首先看看各種模式的結構，並且研究兩種模式之間的區別。
1. 經典模式
在IIS 6.0中的經典模式中，ASP.NET是一個添加到IIS中的ISAPI。IIS 7.0之所以支持這種模式，是為了做到向后兼容。但是，經典模式缺少許多集成模式才能提供的特性。在經典模式中，IIS擁有自身的管道，這些管道可以通過創建一個ISAPI擴展進行擴充，而ISAPI擴展是以難以開發而著稱的。ASP.NET作為一個ISAPI擴展運行，只是IIS管道中的一項組成部分。
下圖很好地解釋了上述情況。注意，在這種情況下，ASP.NET似乎是一種類似於馬后炮的成果，僅當IIS處理ISAPI擴展時才能夠發揮作用。
利 用文件擴展名，可以判斷使用哪個ISAPI處理程序。例如，可以將擴展名為.aspx 和.ascx的文件映射到aspnet_isapi.dll；並且將擴展名為.asp的文件映射到asp.dll，這樣就可以處理傳統的ASP頁面；此 外，將擴展名為.php的文件映射到php.dll，這樣就可以處理PHP頁面，前提是已經安裝了php.dll。
此外，在IIS 6.0和IIS 7.0的經典模式中，某些特性是重復的。例如，錯誤處理就是一種重復的特性，因為IIS可以處理非ASP.NET頁面，而ASP.NET可以處理所有將處理程序映射為aspnet_isapi.dll的頁面。
在IIS 6.0中，我們可以將所有文件類型都映射到ASP.NET，但是這樣做存在一些限制。最大的限制就是如何處理默認文檔：一個默認文檔僅當在 global.asax中或者在一個HTTP模塊中被指定為默認文檔時，這個默認文檔才能夠得到處理。某些自定義的配置需要使用 aspnet_isapi.dll處理所有的文件類型。IIS 7.0可以輕易地解決這個問題。
經 典模式可以在無須修改web.config的前提下運行現有的Web網站，因此，如果使用的Web farm中既包括IIS 6.0服務器，也包括IIS 7.0服務器，或者因為某些原因無法將web.config文件轉換為遵循新語法的web.config文件，那么就可以使用經典模式。
2. 集成模式
利用集成模式，可以將ASP.NET作為IIS的有機組成部分。現 在，IIS服務器的功能被划分為40多個模塊，因此也就將IIS和ASP.NET的功能划分為不同的組成部分。諸如StaticFileModule、 BasicAuthenticationModule、FormsAuthentication、Session、Profile，以及RoleManager等模塊都是IIS管道的組成部分。注意，FormsAuthentication、Session、Profile，以及RoleManager原本就是ASP.NET的組成部分，與IIS並無關系。
下圖使用模塊解釋了IIS管道。這些模塊原本是ASP.NET的組成部分，現在已經是IIS管道的有機組成部分。
IIS 管道提供了二十多種事件，開發人員可以利用這些事件來擴展Web服務器的功能。實際上，通過創建定制模塊，同時更新 applicationHost.config，可以僅使用自定義模塊，而無須再使用微軟公司提供的內置模塊，我們可以將IIS 7.0中的模塊替換為自定義的模塊。
3. 兩種模式之間配置的區別
IIS 7.0對配置文件進行了一些修改，Web開發人員可以使用這些修改內容。例如，<system.webServer>節就是這樣一項修改，無 論是經典模式還是集成模式都可以識別<system.webServer>節，同時，<system.webServer>節既 可以在applicationHost.config文件中設置，也可以在web.config文件中設 置。<system.webServer>節既可以控制靜態頁面，也可以控制動態頁面。即使在經典模式 中，<system.webServer>節也具有重要作用，它可以幫助Web開發人員在web.config文件中設置不同的IIS配置。
在集成模式中，HTTP模塊和HTTP處理程序不再定義於<system.web>中，而是定義於<system.webServer>中。如果在集成模式中運行一個包括了HTTP模塊或HTTP處理程序的web.config文件，那么將會發生失效。幸運的是，微軟公司已經詳細規定了一個編號為500.22的錯誤信息，這個錯誤信息說明了如何一步步地遷移web.config文件。
IIS 7.5 中配置 <system.webServer> 節點
問題
在 IIS7.5 中配置 <customError><error> 節點的404頁面不起作用
分析
<system.web> 節點是iis7.0之前版本的主要配置節點，在II7.0以后IIS管道處理與ASP.NET管道處理進行了集成，提高了ASP.NET的處理性能。由於 程序運行在IIS7.5集成模式下，需要在<system.webServer>節點中配置，新增加 的<system.webServer>節點中需要進行哪些修改以程序在IIS7的集成模式下能完全生效呢，主要包含以下幾個方面：
（1） <modules> ----- 相當於<system.web>中的<httpModules>
（2） <handlers> ----- 相當於<system.web>中的<httpHandlers>
（3） <customError>下的<error> ----- 相當於<system.web>中的<httpErrors>
以上三點中，如果你的程序中有自定義的httpModules或者httpHandlers的話，那么第一點和第二點非常重要，具體資料請MSDN。
配置
<httpErrors errorMode="DetailedLocalOnly">
<remove statusCode="404" />
<error statusCode="404" path="/404.htm" responseMode="ExecuteURL" />
</httpErrors>
補充
errorMode有三個值，分別為Custom、DetailedLocalOnly、Detailed，意思為對用戶與服務器端始終顯示自定義頁面、只能服務器端顯示詳細出錯信息、對用戶與服務器端始終顯示詳細出錯信息。
responseMode有File、ExecuteUrl、Redirect三個層，分別表示使用服務器端靜態文件、可執行的URL、URL轉向。
注意：<httpErrors>與<customErrors>是不同的，前者主要用於處理http相關的錯誤信息，而后者主要是處理應用程序級的錯誤頁轉向。
<customErrors>
同 樣，如果Application_Error和<customerErrors>同時存在，也存在執行順序的問題。因為優先級 Application_Error事件> <customErrors>配置項，所以發生應用程序級錯誤時，優先執行Application_Error事件中的代碼，如果 Application_Error事件中調用了Server.ClearError()函數，<customerErrors>配置節中的 defaultRedirect不起作用，因為Exception已經被清除；如果Application_Error事件中沒用調用了 Server.ClearError()函數，錯誤頁會重新定位到defaultRedict指定的URL頁面，為用戶顯示友好出錯信息。
通過對.NET提供的以上四種錯誤處理機制的分析，我們可以把它們從不同的角度分類，便於我們理解和使用。
1、 從功能上分類：用於異常處理（Handling exceptions）是Page_Error事件和Application_Error事件；用戶錯誤頁面重定向（Redirecting the user to an error page）的是 ErrorPage屬性 和 <customErrors>配置項。
2、 從錯誤處理的范圍分類：用於頁面級（Page level）錯誤處理的是Page_Error事件 和 ErrorPage屬性；用於應用程序級（Application level）錯誤處理的是Application_Error事件 和 <customErrors>配置項。