一般 IIS 7.0 問題

這必須手動完成。

影響將取決於伺服器負載。 如果您要執行 10，000 個要求/秒，您將會遺漏核心快取;不過，如果您要執行 100 個要求/秒，您可能不會注意到。 它主要取決於所提供的內容，IIS 5.0 沒有核心模式元件，而且大部分的客戶都正常運作。

有基本的 Ruby 支援。 如需詳細資訊，請參閱下列連結：

http://mvolo.com/10-steps-to-get-ruby-on-rails-running-on-windows-with-iis-fastcgi/

如果您要透過 伺服器管理員 GUI 安裝， (「新增功能」) ，則安裝順序並不重要。 [新增功能] 精靈會檢查所有相依性，如果您遺漏任何必要的模組，將會發出警示。 此外，[新增功能精靈] 也知道模組的正確順序。

如果您要從命令列安裝或使用自動安裝，模組的順序不會再次 (，安裝程式會知道模組的正確順序) ，但您必須負責識別所有相依性。 如果您無法包含必要的相依性，則自動安裝/命令列安裝程式將會失敗。

僅提供已安裝所有功能的靜態檔案的應用程式集區，其使用量為 3 MB 私人位元組，5 MB 頁面檔案。 (這大於 IIS 6.0) 。 Windows Server 2008 會處理多個比 WS03 更好的應用程式集區。 當發出 ASP.NET 要求時，我們會在啟動期間預先載入少量 CLR， (~100 kb) 。 預先載入可由 ApplicationPool 上的 屬性設定。 它稱為 managedRuntimeVersion。 第一個 ASPX 要求會載入其餘 CLR (~8mb) 。

存取僅適用于 32 位的應用程式集區。 在 AppPool) 上載入使用者設定檔 (loadUserProfile 屬性是使用傳統 ASP 時發生問題，因為 Access 是使用不允許在載入使用者設定檔時存取匿名使用者的臨時目錄。

Windows Server 2008 Web 版本已大幅改善，而且我們著重在移除人工限制。 最終授權尚未完成，但我們打算移除所有硬體限制、允許 x64) 上的 4x 處理器和 32GB RAM (。 允許 SQL，且 SharePoint 可安裝在 SKU 上。

FPSE 不再是 Windows Server 的一部分。 我們正在與協力廠商合作，建立適用于 FPSE 的下載套件，以在 Windows Server 2008/IIS 7.0 上執行。 它沒有任何新功能或增強功能，只會修正以使其相容。

我們建議將 Windows Server 2008 安裝為全新，並移轉至;或者，只要在新伺服器上放置新客戶即可。 我們建議針對每部伺服器記載協力廠商元件和組態的妥善管理清單，讓目前的環境可以在新的伺服器上複寫。 請參閱網站和應用程式集區組態共用主檔案中的建議。 即將發行可協助移轉的工具。

下列案例支援就地升級：

• Windows Server 2003 可以升級至 WS2K8 Beta3、WS2K8 RC0、WS2K8 RC1 和 WS2K8 RT
• Windows Server 2008 Beta3 可以升級至 WS2K8 Beta3 和 WS2K8 RC0
• Windows Server 2008 RC0 可以升級至 WS2K8 RC0、WS2K8 RC1 和 WS2K8 RTM
• Windows Server 2008 RC1 可以升級至 WS2K8 RC1 和 WS2K8 RTM

如果伺服器處於共用組態模式，則必須在升級執行之前還原為獨立設定。 若要這樣做，請停用共用設定、將applicationhost.config和加密金鑰複製到本機電腦、在每個伺服器上執行升級，然後重新啟用共用設定。

安裝程式正在寫入的記錄檔和 iis7.log 一律開啟。 它不會更細微地瞭解所記錄的內容。

在安裝期間，我們不會提供任何方法來設定 Windows 模組以外的模組。 透過一般自動安裝，在安裝完成後，可能會有辦法執行某些專案，而且使用者可以執行一些程式碼。

追蹤 1000 個要求/秒的所有要求 < 應該是 < 5% CPU。 您可以為所有月臺設定全域追蹤規則。 您可以藉由變更 < siteDefaults > 區段來啟用所有網站的追蹤。

否，但有記憶體型回收，這會回收超過已設定記憶體限制的 AppPool。

在 sysprep 之後遺失 sysprep 之前所做的加密。 沒有因應措施。

您可以匯出電腦金鑰，並將其匯入所有伺服器，以便解密運作。 Server Beta 3 的 UI 包含稱為共用設定的功能，可讓您這麼做。 按一下 [匯出...而且它會加密機器金鑰、將它們連同applicationHost.config一起複製，並將administration.config複製到路徑。 之後，您可以從所有其他電腦選取 [匯入...]它會匯入電腦金鑰，並將設定指向共用組態。

不同的 AppPools 對此設定可以有不同的值。 應用程式可以指派給不同的 AppPools

處理此錯誤的預設檔案包含在 \inetpub\custerr\en-us 中。 錯誤的頁尾包含「伺服器版本資訊：Internet Information Services 7.0」，當然可以直接從.htm檔案中移除或編輯。

受管理的 API (Microsoft.Web.Administration) 可以存取原生 API 執行的所有設定，並使用 ServerManager.OpenRemote 靜態方法支援 DCOM 遠端處理。 您可以設定任何組態設定，但 Beta 3 不支援執行時間資訊，例如 AppPool 的狀態或要求或背景工作進程清單。

在舊版 IIS 中，您必須透過檔案系統 ACL 來控制存取。 這很繁瑣，而且沒有 Web 介面可以這麼做。 透過 URL 授權，您可以使用 IIS 使用者介面或使用直接web.config來控制 URL 的存取。 此外，您可以使用非 Windows 身分識別，例如表單驗證所提供的成員資格使用者和角色。

applicationPool 區段中與該應用程式集區相關的任何資料 (，因此在 applicationPoolDefaults 或該應用程式集區的特定資料) 會導致 WAS 回收應用程式集區。 背景工作進程可以要求 WAS 根據特定設定變更來回收應用程式集區，目前我們唯一執行的動作是 globalModules，但這不是關閉的清單 (，因為模組可以根據設定變更要求回收) 。

NLB 是 Windows Server 2008 的一部分。 它基本上與 Windows 2003 中的相同。 若要安裝 NLB，請移至 [新增功能] > 伺服器管理員功能 > ，然後從清單中選取 [網路負載平衡]。 若要設定 NLB，您必須開啟命令提示字元並執行 nlbmgr。 這是存在於 Windows 2003 中的 UI。

如果全系統 CPU 超過動態閾值，壓縮將會停止，並釋放它所使用的 CPU。 如果全系統 CPU 低於不同的限制，動態壓縮將會繼續，以節省頻寬。

不同的使用者對最佳 CPU 使用率有不同的意見。 有些認為 20% 的平均值很完美，有些則認為 75%。 如果您想要 X，而且一致地高於 X，您可能也會完全移除動態壓縮，因為它永遠不會使用。

它會在上一個樣本之後的 30 秒時間範圍中，以平均使用量來因素-因此，即使有異常尖峰，在尖峰之後最多 30 秒，而且如果您的尖峰是立即 (，因此不會影響平均 CPU 使用量超過 30 秒) ，它們不會影響動態壓縮。

在 applicationPoolDefaults 中設定 loadUserProfile=false 是共用裝載案例的好主意。 AppPool 的啟動時間會更快，而且您可以避免任何暫存的目錄許可權問題。

500.19 錯誤是由 IIS 7.0 功能委派模式所造成。 將功能委派給網站擁有者，而網站擁有者修改此功能時，其變更會保存在web.config中。如果伺服器管理撤銷該功能的委派管理，則網站擁有者必須負責清除web.config的功能詳細資料。否則，修改該委派功能的所有網站都會立即提供「Http 錯誤：500.19 - 內部伺服器錯誤」訊息。 為了避免這個問題，我們建議主機人員在發佈給終端客戶之後，不要撤銷委派的功能。

如果裝載的網站沒有web.config，IIS 7.0 將會建立一個。 如果網站有web.config，IIS 7.0 會修改它。 如果修改web.config，則網站擁有者必須負責合併變更，並確保手動合併和維護變更。

安裝管理服務完全不會修改AppHost.config或Administration.config。 您應該會看到的唯一變更是新的二進位檔 (wmsvc.exe) 。 將會建立自我簽署憑證，並新增一些登錄機碼。 這表示理論上，不應該中斷任何專案。

在大部分的情況下，其運作方式是現用的，因為我們使用redirection.config設定來讀取 apphost/admon.config。不過，如需詳細答案，這實際上取決於您將使用的案例：

• 使用本機內容共用設定：一般 Windows 或 IIS 使用者連線以修改其本機內容和其web.config - 沒有作用，所有專案都應該現用。
• 使用 Windows 使用者使用遠端內容的共用設定：它應該能夠運作，前提是 Windows 帳戶可以存取其內容。
• 使用 IIS 使用者使用遠端內容的共用設定：在此案例中，您必須將服務身分識別 (WMSVC) 變更為可存取遠端內容的帳戶，因為我們使用進程身分識別來存取內容。 請注意，apphost.config/admon.config將會運作，因為我們使用 redirection.config
• 管理伺服器連線的 Windows 系統管理員：它應該能夠運作，前提是您的 Windows 系統管理員具有共用設定的寫入權限。

如需在 IIS 7.0 中建立網站的相關資訊，請參閱下列連結。

應用程式集區，僅提供已安裝所有功能的靜態檔案，佔用 3 MB 私人位元組，5 MB 頁面檔案。 當發出 ASP.NET 要求時，我們會在啟動期間預先載入少量 CLR， (~100 kb) 。 預先載入可由 ApplicationPool 上的 屬性設定。 它稱為 managedRuntimeVersion。 第一個 ASPX 要求會載入其餘 CLR (~8mb) 。

如果這些資料夾不存在，Http.sys會自動建立這些資料夾。 如果您以其他內容覆寫許可權，它應該保留新的許可權。

我們已在內部進行測試，如果已安裝 ISAPI 和 Metabase，它似乎正常運作。 線上還有一些部落格，提供如何讓它運作的指示。 如需詳細資訊，請參閱下列連結：

https://blogs.iis.net/bills/archive/2007/03/06/coldfusion-on-iis7.aspx.

伺服器是在 AD 帳戶建立模式中設定。 AD 建立模式是仍受支援但將在 V4 中移除的已淘汰功能。 建議不要允許 WSS 在 AD 中自動建立使用者，而是在 WSS 外部進行使用者布建。

如需集中式全域設定的詳細資訊，請參閱： IIS 7.0 中的組態系統

目前沒有適用于 x64 的 FPSE。 我們的共用裝載建議架構是具有 32 位 AppPools 的 64 位 OS。 不幸的是，目前有一個錯誤可防止 FPSE 在此案例的 64 位上安裝。

您可以完成下列步驟，以重新整理系統三次：

若要執行 slmgr /rearm，請開啟regedit.exe並流覽至 HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SL。 確認 「skiprearm」 值已設定為 '0'。 如果此值不是零，則重新 arm 函式將不會重設系統啟用計時器。

確認 「skiprearm」 登錄值等於零 (0) 之後，請從提升許可權的命令提示字元執行 slmgr /rearm。 等候此程式已完成的通知。 這可能需要一或兩分鐘的時間。 完成後，請遵循提示來關閉電腦。 重新開機時，電腦將會在 OOB 寬限中執行，並有另 30 天的時間要啟用。 此程式不會對系統進行任何其他變更。

Iis。CertObj COM-object 仍在 IIS 7.0 中，我們認為它仍然是在多部網頁伺服器上部署憑證的最佳選項。 此元件行為維持不變，因此如果已啟用 ABOMapper) ，所有舊的腳本都應該 (運作。

set iiscertobj = CreateObject (「IIS。CertObj「)

iiscertobj。InstanceName = 「0.0.0.0：443」

iiscertobj。匯入 pfxfile、pfxfilepassword、true、true

因此，這類腳本不會取決於 ABOMapper。