IIS：實地操作 IIS 7.0

IIS

實地操作 IIS 7.0

Fergus Strachan

綜覽：

在 Web 伺服陣列環境內部署 IIS 7.0
安全性和效能提升
將 ASP.NET Web 應用程式從 IIS 6.0 移轉至 IIS 7.0
將 PHP Web 應用程式移轉至 IIS 7.0

預備，起，測試
我的測試設定
對 IT 系統管理員的重要改進
IIS 架構
整合和傳統模式
模組與功能
Web 應用程式移轉
總結

Microsoft 的 IIS 小組說 Internet Information Services (IIS) 7.0 是 IIS 有史以來最重大的發行。這個版本不僅立下新標準，提供意義重大的改進，

所帶來的新功能更整合了 Web 環境。內含在 Windows Server® 2008 和 Windows Vista® SP1 中的 IIS 7.0，讓 Microsoft.com 發揮強大威力，而且好幾家虛擬主機公司也已開始提供 IIS 7.0 主機給想要將現有的 Web 應用程式移植到新網頁伺服器平台的網頁設計者和開發人員。

在本文中，我將探索對 IT 專業人員來說最重大的 IIS 7.0 增強功能，接著我會深入探討移轉 ASP.NET 和 PHP Web 應用程式。不過首先，我想要簡述一下構成基本生產環境的測試實驗室。

這項工作很重要，在將 IIS 7.0 部署到實際執行伺服器之前，您必須花時間在實驗室的環境內進行充分測試，以確保您的 Web 應用程式能夠在新網頁伺服器上正常執行。

預備，起，測試

我的測試實驗室包括了執行 Windows Server 2003 和 IIS 6.0 的系統，上面主控著 ASP.NET 應用程式，另外也包括了執行 Ubuntu 7.10 Linux 發佈和 Apache HTTP Server 2.2 的伺服器，上面則主控以 PHP 為主的 Web 應用程式。我最終的目標是要將 Windows Server 2008 部署在開發用和生產系統上，然後轉移複雜的 Web 應用程式，將 IIS 6.0 和 Apache 執行個體取代為 IIS 7.0。

我有兩個重要的 Web 應用程式：DotNetNuke 4.7 和 osCommerce 3.0a4。DotNetNuke 是以 ASP.NET 2.0 和 Microsoft® SQL Server® 為基礎的 Web 應用程式架構。另外一個應用程式 osCommerce 是以 PHP 和 MySQL 為基礎建置而成，它是全功能電子商務解決方案的最新 Alpha 版本。現在就讓我們把這些進階應用程式放到 IIS 7.0 上吧！

我想要先釐清我的用意並不是要比較軟體版本、產品或平台。不過，我想指明 Windows Server 2008 和 IIS 7.0 的標準化確實有不少優點。換句話說，這麼做不但可降低系統管理的複雜度，而且還可以將執行網頁伺服器的總數減至最少。

[圖 1] 提供我用於本文的測試實驗室概觀。如果您想要在自己的測試環境內遵循我講解的步驟，可以到 TechNet Magazine 網站的「程式碼下載」區段，從附隨的資料中找到必要的軟體元件，以及詳盡的逐步安裝指示。

[圖 1] 首展 IIS 7.0 的測試環境 (按一下以放大影像)

請注意，大約在我快寫完本文的同時，Microsoft 也發行了一項命令列工具 (MSDeploy.exe) 支援客戶部署、同步處理和移轉 Web 應用程式至 IIS 6.0 和 7.0。我建議您試試這項工具。詳細資料可在 Microsoft Web 程式開發小組部落格上找到，網址是 go.microsoft.com/fwlink/?LinkId=118272。

我的測試設定

在撰寫本文的同時，Windows Server 2008 仍舊處於搶鮮版階段，因此我並沒有置換網域控制站或資料庫伺服器上的 Windows Server 2003。隨著 Windows Server 2008 的正式發行，您應該考慮一併移轉 Active Directory® 基礎結構。而將 SQL Server® 2005 和 MySQL 資料庫移轉到 SQL Server 2008 同樣超出了本文討論的範圍。

我主要是把 SQL Server 2008 部署在開發用伺服器上，因為跟安裝 SQL Server 2005 含 Service Pack 2 比起來，這比較不費力。DotNetNuke 可搭配 SQL Server 2008 資料庫順利執行。在 Windows Server 2008 上安裝 MySQL 5.0 也很直接了當，沒什麼複雜性可言。

雖然 Server Core 上可用 IIS 7.0，但基於測試的特定需求，我並沒有使用 Server Core 安裝。因為我的開發用伺服器是主要的測試系統，因此需要完整安裝。再說，Server Core 上也不能使用 Microsoft .NET Framework。

PHP 在 Server Core 上可順利執行，但是我的目標是要整合 ASP.NET 和 PHP 應用程式，因此我完全不考慮 Server Core。除非 Server Core 支援 .NET Framework，否則您必須得執行完整安裝才能支援 ASP.NET 應用程式。如需安裝測試環境的詳細逐步指南，請參閱附隨資料中的 01_install_testlab.htm 檔案。

我選擇執行 Windows Server 2008 的全新安裝 (而不是升級現有伺服器)。另外，透過全新安裝，實作開發用移轉案例也比較容易，像 [圖 2] 就是這樣的一個案例。基本的策略是要讓現有的 Web 伺服陣列繼續執行，直到所有相關 Web 應用程式元件在開發用伺服器上都成功通過測試且順利移到新 IIS 7.0 Web 伺服陣列為止。

[圖 2] 分階段切換到 IIS 7.0 (按一下以放大影像)

您可以根據環境的複雜程度，全部一次或採漸進方式移動所有現有的 Web 應用程式。對於每個 Web 應用程式或網站，在新 Web 伺服陣列上執行最後的接受度測試後，您就可以變更相關的 DNS 記錄，將瀏覽器導向新 IIS 7.0 Web 伺服陣列來進行切換。這可盡量減少停機時間和服務中斷。

對 IT 系統管理員的重大改進

《MSDN® Magazine》中有一篇 Mike Volodarsky 所著的精闢文章，名為＜深入探索 Windows Vista 的 Web 伺服器＞(網址是 msdn2.microsoft.com/magazine/cc163453.aspx)，可讓您快速了解 IIS 7.0 中所提供的各種改進。

另外一項不錯的參考來源是 Microsoft.com 小組的部落格文章，標題為＜狗食裡面美味的一小口＞ (網址是 go.microsoft.com/fwlink/?LinkId=117436)。這篇文章概述了小組成員的 IIS 7.0 的初體驗。簡單的說，他們把最重要的改進排名如下：

簡化的安裝。
極佳的相容性。
擺脫 Metabase。
透過在 UNC 共用上放置 applicationHost.config 檔案進行集中化設定。
透過應用程式目錄中的 web.config 檔案進行委派設定。
改進的管理工具。
失敗要求追蹤。
無需 URLScan 即可篩選要求。
透過 UNC 共用簡化內容同步處理可用性。
動態內容的輸出快取。

簡化的安裝肯定也在我的名單上。在 Microsoft.com 小組的部落格文章裡面，他們會示範如何以單行的命令列部署 IIS 7.0 的所有功能 (或者，只部署您要的功能)。我很興奮地以 [圖 3] 所示的命令列，將這套方法也併入我的測試實驗室設定指示。

不可否認地，這行命令的確很長 (如果您想要複製這行命令，我建議您從 TechNet Magazine 網站複製然後貼上，而不要手動輸入)。雖然這個命令把所有可用的模組都放到 IIS 7.0 電腦上，卻不包括 PHP。IIS 7.0 並沒有包含 PHP，而 Windows® 封裝管理員 (pkgmgr.exe) 其實對於透過網際網路下載和安裝 Debian 套件的概念很陌生。所以請輸入 Windows 自動化安裝套件 (AIK)。

[圖 3] 以單行命令列部署 IIS 7.0 功能

start /w pkgmgr.exe /iu:IIS-WebServerRole;IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;IIS-HttpRedirect;IIS-ApplicationDevelopment;IIS-ASPNET;IIS-NetFxExtensibility;IIS-ASP;IIS-CGI;IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-ServerSideIncludes;IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;IIS-RequestMonitor;IIS-HttpTracing;IIS-CustomLogging;IIS-ODBCLogging;IIS-Security;IIS-BasicAuthentication;IIS-WindowsAuthentication;IIS-DigestAuthentication;IIS-ClientCertificateMappingAuthentication;IIS-IISCertificateMappingAuthentication;IIS-URLAuthorization;IIS-RequestFiltering;IIS-IPSecurity;IIS-Performance;IIS-HttpCompressionStatic;IIS-HttpCompressionDynamic;IIS-WebServerManagementTools;IIS-ManagementConsole;IIS-ManagementScriptingTools;IIS-ManagementService;IIS-IIS6ManagementCompatibility;IIS-Metabase;IIS-WMICompatibility;IIS-LegacyScripts;IIS-LegacySnapIn;IIS-FTPPublishingService;IIS-FTPServer;IIS-FTPManagement;WAS-WindowsActivationService;WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI

# Command provided by the Microsoft.com team (blogs.technet.com/mscom).

透過 AIK，您可以建立一張內含 IIS 7.0 和 PHP 5 的 Windows Server 2008 自訂安裝 DVD。您還可以包括 MySQL、Web 應用程式檔案，還有部署所需的其他任何元件。所有元件都可以作為 Windows Server 2008 安裝程式的一部分，讓您在所有網頁伺服器上套用一致的自訂內容，完全不用命令列或編輯設定檔。

您甚至可以建立自訂 DVD 進行完全自動化安裝。AIK 包括了建立 AutoUnattend.xml 檔案的說明文件和工具，您可以把它們放到 DVD 的根資料夾中。附隨資料中的 Custom Image Deployment.htm 檔案有提供相關逐步指示。

許多系統管理員也同意相容性是一項重大的改進。其實我預期 DotNetNuke 和 osCommerce 會碰到一些相容性問題，但轉移至 IIS 7.0 卻是相當輕鬆，儘管這兩種 Web 應用程式都包含進階功能，例如表單驗證和搜尋引擎式 URL。

對於 DotNetNuke，我是一直等到在 64 位元平台上透過 UNC 內容共用移到複雜的 Web 伺服陣列案例後才開始遇到問題。不過，問題不大。終歸一句，改進的相容性表示要讓 Web 應用程式在 IIS 7.0 上執行，所需的時間更短。

如果您的 Web 應用程式剛好遇到相容性問題，內建的診斷和追蹤支援很快會成為您愛不釋手的新功能之一。詳細的診斷資訊深具意義，而建議的解決方案路徑也非常有用，而且頗具成效。

[圖 4] 顯示您以整合模式在 IIS 7.0 上執行 DotNetNuke 4.7 時取得的診斷資訊。在本例中有三個選項 (顯示在「您可以試的事」一節)。對 DotNetNuke 開發人員來說，最佳選擇可能是變更應用程式來支援整合模式。而忽略錯誤可能不是什麼好主意。我喜歡第三個選擇，將 Web 應用程式切換到傳統 .NET AppPool 來啟用傳統模式，因為我想在 IIS 7.0 中執行未修改的 DotNetNuke 4.7。

[圖 4] 執行在整合模式中的 DotNetNuke 的診斷資訊 (按一下以放大影像)

IIS 架構

您可能會好奇這些整合和傳統模式到底是什麼，還有它們為什麼會左右 ASP.NET 應用程式 (DotNetNuke)，卻對 PHP 應用程式 (osCommerce) 一點影響也沒有。為了更清楚瞭解這一點，您必須先看看 IIS 7.0 的架構。之前的版本把 ASP.NET 執行階段整合至核心網頁伺服器，主要是透過 ISAPI 擴充程式 (aspnet_isapi.dll)。而另一方面，IIS 7.0 則容許 ASP.NET 模組直接透過一個稱為 ManageEngine 的全域層級 HTTP 模組插入核心網頁伺服器，這個模組會將 ASP.NET 支援 DLL (webengine.dll) 載入 IIS 7.0 要求處理管線內。

原生模組使用 IIS 網頁伺服器核心 API 來註冊管線內特定的事件，例如 BeginRequest、AuthenticateRequest、AuthorizeRequest 和 ExecuteRequestHandler。ManagedEngine 也提供將 ASP.NET 模組整合至要求管線所需的支援。藉著這個新架構，IIS 7.0 可以在要求處理期間的任何階段叫用原生和 ASP.NET 模組，而不管要求的內容類型為何。

讓我們舉 ASP.NET 使用者驗證為例。在 IIS 6.0 中，以 ASP.NET 為主的 HTTP 模組可以註冊 OnAuthenticate 事件 (例如 FormsAuthentication.OnAuthenticate 和 WindowsAuthentication.OnAuthenticate)，在目前 HttpContext 中設定使用者的識別。這在 ASP.NET 執行階段中頗具成效，但是您無法使用這段 ASP.NET 程式碼來保護透過以 PHP 為主的 Web 應用程式公開的資源。

根據 IIS 6.0 的指令碼對應設定，它會將 ASP.NET 內容類型的要求轉寄到 aspnet_isapi.dll，但是它並不會將 PHP 內容類型的要求轉寄到 ASP.NET 的 ISAPI 擴充程式。畢竟，ASP.NET 並不會處理 PHP 程式碼，但是這也表示如果要求 PHP 頁面的話，ASP.NET 驗證程式碼也不會執行。因此，對於 IIS 6.0，您必須複製驗證邏輯，因為 PHP 應用程式必須實作它們自己的驗證機制。

IIS 7.0 採用一種事件導向的處理模型，這種模型支援在要求管線中混用個別的模組。除了其他元件之外，IIS 7.0 還附隨了 Managed WindowsAuthentication 和 FormsAuthentication 模組，這些模組在要求管線引發 AuthenticateRequest 事件時會發出 OnAuthenticate 事件。您現在可以讓原生模組，例如 RequestFilteringModule 或 IpRestrictionModule，來處理 BeginRequest 事件，藉此儘早拒絕重要的要求，然後在發生 AuthenticateRequest 事件時執行自訂 ASP.NET 驗證程式碼，並在發生 ExecuteRequestHandler 事件時讓 FastCgiModule 執行 PHP 指令碼引擎 (php-cgi.exe) 來處理 PHP 頁面。

有了這樣的整合架構，網頁開發人員就不必再複製程式碼來實作一般的商務邏輯。您可以使用自訂 ASP.NET 驗證程式碼來保護所有的 IIS 資源，包括 PHP 應用程式在內。而且您可以透過 ASP.NET 模組執行其他前置和後置處理工作，諸如重寫 URL、自訂追蹤和記錄錯誤等。

整合和傳統模式

這套新架構所引起的副作用是，現有的 ASP.NET 應用程式可能需要變更程式碼和設定，這應該由應用程式開發人員執行，以確保這些變更不會導致模組在要求管線內產生衝突。但是如果您無法馬上移植現有的 Web 應用程式，您可以在工作者處理序用來執行 Web 應用程式的應用程式集區內啟用傳統模式。IIS 7.0 並不會將 ManagedEngine 載入傳統模式的工作者處理序中，這也暗示了在這種情況下，要求管理無法解析或叫用 ASP.NET 模組。IIS 7.0 反而會啟動幾個以 IsapiModule (aspnet_isapi.dll) 為基礎的 ISAPI 處理常式，來處理類似於 IIS 6.0 的 ASP.NET 內容類型。若您在 applicationHost.config 檔案 (預設可以在 %WinDir%\System32\InetSrv\Config 資料夾中找到) 中分析一下 system.webServer 中的處理常式區段，就不難看出這點。

以 string aspx 為例進行搜尋，就會發現有個指向 PageHandlerFactory-Integrated (根據 preCondition="integratedMode" 設定載入整合模式的應用程式集區工作者處理序) 的項目，以及其他指向 PageHandlerFactory-ISAPI-2.0 和 PageHandlerFactory-ISAPI-2.0-64 (根據 preCondition="classicMode" 設定載入傳統模式的應用程式集區工作者處理序) 的項目。

因為管線模式是在應用程式集區層級設定的，所以 IIS 7.0 可同時在整合和傳統模式內執行 Web 應用程式。而且工作者處理序其實只需在不同的應用程式集區中執行，它們還是可以裝載在同部伺服器上。

請記住，整合模式和傳統模式只會左右 IIS 7.0 將 ASP.NET 整合至要求管線的方式。這些管線模式並不會直接影響 PHP 應用程式。FastCgiModule 和所有其他原生模組在整合模式和傳統模式中，不需具備管線模式的先決條件，就可以載入。FastCGI 是在 IIS 7.0 上執行 PHP 指令碼引擎所偏用的介面。若不想使用 FastCGI，您也可以透過 CGL 建立 PHP 指令碼引擎的處理常式對應，或者您可以使用 IsapiModule 搭配 PHP-ISAPI (php4isapi.dll)。

不過，我個人認為現在 FastCGI 既然提供大幅改進的效能和穩定性，這些 IIS 6.0 式的設定替代方案其實很過時。CGI 的速度較緩慢的原因是因為 IIS 必須為每項 HTTP 要求初始化一個新的 CGI 處理序，而 FastCGI 則是重複使用 CGI 處理序來處理多項要求。ISAPI 需要有執行緒安全的 PHP 組建，表示負荷會比只執行非執行緒安裝的 PHP 還要高。

或許更為重要的是，並非所有 PHP 延伸模組在執行緒安全版本都可用，而且搭配 ISAPI 執行非執行緒安全延伸模組並不是個好主意，因為它可能會在伺服器上導致穩定性問題。另一方面，FastCGI 則是像 CGI 一樣的單一並行環境。用來執行非執行緒安全 PHP 的 FastCGI 是既穩定又快速，而且很顯然是在 IIS 7.0 上與 PHP 5 搭配使用的上上策。如果您還沒準備好轉移至 IIS 7.0 的話，它也可以在 IIS 6.0 上使用。

模組與功能

IIS 7.0 功能是高度模組化的架構 — 或者，套句 IIS 開發人員的用語，是元件化的功能集。這對於想要盡可能縮減記憶體使用量和 IIS 7.0 攻擊面的 Web 管理員，真是一大福音。透過啟用不同的模組，甚或是以自訂模組取代標準模組，您便能在網頁伺服器上全權掌控 IIS 7.0 功能。

若要在整合或傳統模式中執行 ASP.NET，以及在相同的伺服器上執行 PHP 應用程式，您必須至少安裝網頁伺服器角色和核心模組，藉以支援要求處理、伺服器設定、ASP.NET、ISAPI 和 CGI (內含在 FastCGI 模組中)。這可透過下列命令列來完成：

start /w pkgmgr /iu:IIS-WebServerRole;
WAS-WindowsActivationService;WAS-ProcessModel;
WAS-ConfigurationAPI;IIS-ASPNET;
IIS-NetFxExtensibility;WAS-NetFxEnvironment;
IIS-ISAPIExtensions;IIS-ISAPIFilter;IIS-CGI

我一般偏好在開發用伺服器上以所有可用的選項安裝 IIS 7.0，以確保所有元件和系統管理工具都可以使用，藉此讓我的 Web 應用程式能迅速地順利執行。我的策略是確定事情一切 OK 後，藉著解除安裝角色服務和停用模組來縮小設定的範圍。當 Web 應用程式開始行為不軌時，我就把剛剛移除的角色服務或模組新增回去。

您也可以選擇使用封裝管理員 (pkgmgr.exe) 或是 IIS 7.0 命令列工具 (appcmd.exe)，或者直接編輯 applicationHost.config 檔案中的 globalModules 區段，但是我發現圖形化工具其實非常方便。請記住，有些模組 (像是 RequestFilteringModule 和 StaticCompressionModule) 即使不是執行 Web 應用程式必備的項目 (嚴格說起來)，它們還是相當管用。如果您解除安裝某應用程式集區所需的模組，您會在存取 Web 應用程式時收到 HTTP 錯誤，如 [圖 5] 所示。

[圖 5] ASP.NET 應用程式因為遺漏 IsapiModule 而不能在傳統模式中執行 (按一下以放大影像)

備註：最佳的作法是，確定所有 IIS 7.0 伺服器上安裝和啟用的是同一組模組。若要確認已安裝的元件，請前往 HKEY_LOCAL_MACHINE\Software\Microsoft\InetStp\Components\，然後檢查登錄機碼。若 NetFxEnvironment 或 CGI 的登錄機碼的 REG_DWORD 值為 0000 0001，表示相對應的元件已安裝。

Web 應用程式移轉

理論講得天花亂墜，該是捲起袖子動手把一些 Web 應用程式移到 IIS 7.0 的時候了。前面有提到，我的開發用伺服器會執行 IIS 7.0 與所有可用的元件，還有以 FastCGI 註冊的非執行緒安全 PHP 5。開始前，我需要先問幾個基本問題：

Web 應用程式需要有資料庫管理系統，例如 SQL Server 或 MySQL 嗎？
我需要安裝或設定其他元件，例如 ODBC 連線、COM 物件或 SSL 憑證嗎？
Web 應用程式需要有特殊的服務帳戶，以及對檔案共用和其他資源須提升本機或遠端存取權限嗎？
對於 IIS 7.0 上沒有提供的平台特定功能有任何依存性，例如需要依存 Apache 模組來重寫 URL (mod_rewrite) 嗎？

問這些問題可幫助您讓 Web 應用程式更快在 IIS 7.0 上順利執行。舉例來說，如果您試著從使用 mod_rewrite 的 Apache 2.2 移轉 PHP 應用程式 (假設是為了方便使用搜尋引擎，或避免頻寬透過內嵌連結影像被劫奪)，除非在 IIS 7.0 上實作相容的自訂 URL 重寫解決方案，否則將會問題連連。所幸，osCommerce 在 IIS 7.0 上並不需要 mod_rewrite 功能，但是有些搜尋引擎最佳化套件可能需要這項功能。

既然在開發用伺服器上已決定並安裝了必要的附加元件，我也準備好讓 Web 應用程式正常執行。同樣地，我還有幾個想要自問的問題：

我有什麼最簡單的設定可用來支援 Web 應用程式？
目前生產環境內採用的是什麼設定？
我可以最佳化新平台上的 Web 應用程式設定嗎？
要 Web 應用程式在預期的設定內正常運作至少要有哪些角色服務和模組？

要確定 Web 應用程式能正常運作，最快的方法就是以最簡單的設定進行。如果一切看起來都很順利，就可以開始套用類似現有生產環境的設定，並將生產資料匯入到測試資料庫中。不用說，有些問題可能只會在進階設定下浮現。

您可能也會注意到在測試實驗室中鏡像生產設定時，有機會可以做些改進。把 applicationHost.config 檔案放在 UNC 共用上，是集中設定多部網頁伺服器的好作法。若要透過備援和內容同步處理來提高容錯，可考慮實作分散式檔案系統 (DFS) 複寫，這是 Windows Server 2003 R2 和 Windows Server 2008 上提供的一種以狀態為主的多重主機複寫引擎。您也可以把 Web 應用程式的內容檔案放到 UNC 共用上，盡可能降低 Web 前端的儲存需求。

其他可能的最佳化還包括安全性或動態快取。我沒有在測試實驗室裡面處理安全性和效能最佳化，因為這已經超出本文討論範圍。為了避免安裝其他伺服器，我也沒有設定 DFS。隨附資料裡面的逐步指示提供了一個簡化的範例，說明如何在 UNC 共用上主控 applicationHost.config 檔案和網頁內容。而 [圖 6] 則圖解了如何使用 DFS 來實作 UNC 架構的 Web 伺服陣列。

[圖 6] 使用 applicationHost.config 檔案和 UNC 共用上的網頁內容部署的 Web 伺服陣列 (按一下以放大影像)

總結

IIS 7.0 是令人刮目相看的網頁伺服器平台。它在重新設計核心架構的同時，也與 IIS 6.0 保持近百分之百的回溯相容性。它應該不用修改就能執行大部分現有的 ASP.NET Web 應用程式。但是架構化變更的範圍之廣，您無法假定不會遇到相容性問題。

無論您是將 ASP.NET 或 PHP Web 應用程式移轉至 IIS 7.0，最好是採取分階段方式，並把重點放在妥善規劃、準備、測試，以及記錄程式碼和設定變更上。

IIS 7.0 值得您投入這樣的心力。它在安全性、效能、設定性和彈性各方面都有許多改進。若要一一討論可能要寫上一整本書才行。以 UNC 共用為基礎的集中化設定和內容共用，透過應用程式目錄裡面的 web.config 檔案進行委派設定，改進的管理工具，詳盡的診斷資訊和失敗要求追蹤，以及動態輸出快取，在在都是贏得 Web 管理員芳心的必勝之道。

能夠在要求處理管線內混和原生與 Managed 模組，使 ASP.NET 開發人員受益匪淺。而透過 IIS 7.0 上的 FastCGI 所帶來的效能和穩定性提升，對 PHP 應用程式開發人員來說，更是一大福音。

另外還有一個重要的東西可幫助 IT 專業人員成功使用 IIS 7.0：Microsoft IIS 社群入口網站 (www.iis.net)。它包含了您所需的全部資訊，包括關於新架構的詳實文章，給 C++ 和 ASP.NET 開發人員的原始程式碼，示範如何建立 IIS 7.0 模組，以及讓 PHP 應用程式順利執行的逐步指示。您肯定會想要瞧瞧這個網站。這是解答您 IIS 相關問題的好地方。