透過遠端存放在 UNC 伺服器和 NAS 裝置上的內容部署和設定 Internet Information Services (IIS) 6.0

簡介
架構
存取遠端內容
Windows Server 2003 限制委派
設定伺服器進行委派
設定檔案伺服器上的權限
最佳化 IIS 的遠端內容快取
針對 UNC 內容調整伺服器
調整 SMB 的 IIS 和檔案伺服器設定案例
疑難排解 UNC 相關的問題
總結
相關連結
IIS 4.0 和 IIS 5.0 之 IIS UNC 相關的知識庫文件

像 IIS 這種網頁伺服器，常見的一個用途是，接受 Web 用戶端的檔案要求，然後取得檔案，將內容傳回給用戶端的方式，為要求提供服務。許多情況下，傳遞給用戶端的檔案都是存放在 IIS 本機伺服器上。這是為求速度的最佳化，同時也能確保當檔案進行更新時能立即傳送新內容。從簡單性和效能的觀點來看，如果只想要有幾個網站，能提供一組數量小又方便管理的檔案，則將內容裝載在 IIS 本機伺服器上無非是最佳的選擇。

不過，許多情況下，將檔案存放在 IIS 伺服器上既不實際，又不可行。有些系統要管理的檔案有很多，而將內容放在 IIS 伺服器上，等於是將管理內容和管理 IIS 的工作合併在同一個系統上。如果工作負載單一伺服器就可以處理，那麼將內容放在本機可能有好無壞，不過在需要向外擴充而加入網頁伺服器時，也可能會使系統管理複雜化，因為系統必須在伺服器間不斷進行複寫。複寫相當耗時，因而有可能導致傳送過時內容或其他同步處理的問題。除此之外，還需要管理多部伺服器檔案系統上的安全性，無謂是多添一層複雜度。最後，由於對檔案存放的需求日益增加，您還得擴展每部伺服器上的存放能力 (結果將產生額外的支出)，而擁有更多硬體，反而提高了因硬體失敗而停機的風險。

為了減緩這些問題所帶來的衝擊，可以使用 IIS 作為前端來傳送存放在遠端系統上的內容。本白皮書的重點放在設定和調整 IIS 6.0，以及一部用來作為集中式存放區的遠端伺服器，此遠端伺服器能使用 UNC (通用命名慣例) 路徑名稱，存放檔案、應用程式或其他 IIS 可用的網路資源。雖然書中內容只討論用做為檔案伺服器的 Microsoft 伺服器作業系統之存取事宜，但是如果存放解決方案是以 UNC 路徑名稱來存取遠端檔案共用，如 NAS 裝置，則書中大部分的資訊仍適用。

無論您的伺服器的需要是簡單且負載輕，或是複雜且負載重，對於 IIS 6.0 和 Windows Server 2003 中有什麼功能和方法可供您使用 UNC 路徑名稱來存取遠端內容有適當的了解，將有助實作您的設計。

就 IIS 提供遠端存放和散佈的情況，可假想一所教育機構，有 100 名教育者製作課程表和作業，以及公佈他們班級成績 (見 [圖 1]) 來作為範例。IIS 可用來對應每名教育者系統上個別的共用資料夾，允許他們迅速且輕易地發佈重要的內容給他們的學生。這種情況下，IIS 的工作是集中分散於遠端存放的資訊。

[圖 1] IIS 6.0 的工作是集中分散於遠端存放的資訊

利用分散式檔案系統 (DFS) 作為一種基礎的目錄結構，可使得這類的系統更為可靠，且更容易管理。比方說，假如 Anthro101 所對應的 UNC 路徑名稱是屬於 DFS 目錄一部分，則當導師變動下一學期的課程時，只需要在 DFS 中將 \\Instructor\Anthro101 的關聯變更為 \\NewInstructor\Anthro101 就行了，並不需要動到 IIS 設定。

IIS 為網際網路服務提供者 (ISP) 提供遠端內容的好處。例如，ISP 可在共用主機環境中的單一伺服器上擁有上千個網站。內容散至許多網站，但每個網站的流量都很低。透過將內容置離 IIS 伺服器，ISP 就可以將多部伺服器的內容存放在單一 RAID (Redundant Array of Independent Disks，獨立磁碟容錯陣列) 裝置上 (見 [圖 2])。藉著集中而不是分散許多網頁伺服器，ISP 在存放方面的投資得以有效運用。這不但能減少硬體失敗的影響，還能簡化修復策略。

[圖 2] IIS 從遠端存放設備發佈資訊

高容量網站通常使用的 Web 伺服陣列，具有多台設定一模一樣且能接收來自負載平衡者的流量的 IIS 伺服器。在這種案例下，Web 伺服陣列中的伺服器存取 Microsoft SQL™ 伺服器的叢集是很常見的事，通常是使用 Microsoft Cluster Server (MSCS) 作為共同的資料存放區。要注意的是，這種叢集案例在檔案伺服器之間並不是使用網路負載平衡 (NLB)，因為 Microsoft 網路中所使用的伺服器訊息區 (SMB) 通訊會依工作階段而不同。這種高可用性案例為 IIS 6.0 上執行的應用程式提供一個共同資料庫，能夠在其中一部伺服器遇到問題的情況下容錯移轉。同樣地，由 IIS 6.0 傳送的內容和應用程式也可裝載在叢集檔案伺服器或 NAS 裝置上，以便當其中一個遠端存放區失敗時，不致影響使用者 (見 [圖 3])。

[圖 3] 在高容量或 Web 伺服陣列案例中，多部 IIS 伺服器透過共同資料庫提供它們的應用程式和內容

集中化內容的好處是有代價的。雖說遠端存放給予系統管理員在 IIS 伺服器上有更多的選擇，但這種環境需要有額外的安全性。

當使用者在網頁瀏覽器輸入 URL 以存取 IIS 上的內容時，IIS 永遠會將該使用者與使用者帳戶關聯。若啟用匿名存取，並且網站和 NTFS 權限允許要求這類的存取，那麼就會將使用者指派到匿名帳戶，一般為 IUSR_ComputerName。如果沒有匿名帳戶，使用者則必須使用針對要求的資源所啟用的其中一種驗證方法來進行驗證。與使用者相關聯的使用者名稱和密碼為使用者的「憑證」。對本機 NTFS 權限的要求會比照使用者的安全性識別元 (SID) 進行檢查，以決定存取權限。由 IIS 代表使用者所啟動的應用程式會被告知要在使用者的「安全性內容」中執行。

當使用者向 IIS 要求的資訊是使用 UNC 路徑名稱對應到遠端檔案伺服器時，該檔案伺服器會先挑戰 IIS 進行驗證後才將存取權授與使用者。在 IIS 4.0 和 IIS 5.0 中，當於內容所在的 UNC 共用中建立新網站或虛擬目錄時，IIS 會提示系統管理員為網站建立使用者名稱和密碼憑證，如 [圖 4] 所示。該使用者名稱和密碼會存放在 Metabase 中，並且後續會用來向共用行驗證，以檢視網際網路服務管理員中的檔案。因此，[使用者名稱] 文字方塊中輸入的使用者必須是遠端檔案伺服器上有效的本機使用者，或者，若 IIS 伺服器和檔案伺服器兩者皆為網域成員的話，使用者必須是網域使用者。

[圖 4] 虛擬目錄建立精靈 (IIS 4.0 和 IIS 5.0)

當網路使用者存取網站或虛擬目錄時，IIS 會從 Metabase 擷取憑證，並將之用來向 UNC 共用進行驗證。

舉例來說，若有 100 名不同的使用者向 IIS 驗證，並要求存取遠端檔案伺服器，則 IIS 會使用每個使用者的憑證來授權存取存放在本機磁碟上的內容。對於存放在遠端的內容，IIS 並不會使用驗證過的使用者憑證，而是將系統管理員為網站建立的使用者名稱和密碼憑證提交給遠端檔案伺服器，以授權存取。使用單一使用者憑證來傳送內容，是一種確保遠端內容永遠可用的有效方法，不過，這種方法不但會降低使用 NTFS 權限來保障此類內容安全的效率，也會降低稽核的實用性。

在 IIS 6.0 中，IIS 管理員仍允許您像在 IIS 4.0 和 IIS 5.0 內一樣，設定一組固定的憑證，或者您可將使用者的憑證提交給檔案伺服器。這種傳遞憑證 (有時候稱為使用者委派) 是 IIS 6.0 中的預設設定，如 [圖 5] 所示。

[圖 5] 虛擬目錄建立精靈 (IIS 6.0)

在啟用使用者憑證的情況下， IIS 6.0 會將之提供給遠端系統，好讓系統管理員能夠以比前版 IIS 更細微得多的層級來保護和稽核遠端內容。此外，位在檔案伺服器上於採用傳遞驗證時啟動的應用程式也會在使用者的安全性內容中執行。

IIS 管理員內可見的變更反映了 Metabase 中的基本變更，也反映在 IIS 搭配使用驗證憑證與遠端檔案伺服器的方式上。首先，當將 UNCUsername 和 UNCPassword Metabase 屬性留白時，會將經過驗證的使用者憑證傳給遠端檔案伺服器，而不是傳遞存放在 Metabase 中的憑證。其次，若提交已驗證的使用者憑證以驗證使用者，但憑證是不正確的，則伺服器會傳回 401 錯誤 (未授權) 給網頁瀏覽器。假如為了驗證使用者所提交的 UNCUserName 和 UNCPassword 不正確，則會傳回 500 錯誤 (內部伺服器錯誤)。IIS 錯誤訊息中會提供足以通知合法的使用者，但又可阻撓駭客工具嘗試判斷如何攻陷 IIS 安全性的所需資料量。

[圖 6] 概述 IIS 處理之所有內容的驗證程序，包括像是 .gif 檔案和 HTML 網頁的靜態內容、指令碼對應的檔案、CGI 指令碼，以及 ISAPI 延伸 DLL (如 ASP 和 Microsoft ASP.NET)，全都在適當的使用者內容中執行。ISAPI 篩選器是在工作者處理序身分識別的內容下執行。依據預設，工作者處理序會以網路服務的身分執行，這是具備最低權限的內建服務帳戶。如需 IIS 架構和工作者處理序身分識別的詳細資訊，請參閱＜IIS 概觀＞。

[圖 6] IIS 執行或擷取之所有內容的驗證程序

在工作群組環境中，所有的使用者帳戶都是本機帳戶。使用基本驗證的傳遞驗證仍可運作，只要 IIS 和檔案伺服器同時擁有的使用者帳戶具備相同使用者名稱和密碼即可。不過這種設定很快就變成了系統管理的負擔，而未廣為實作。針對這些情況，指定專門用於 UNC 連線而設計的單一使用者帳戶也許是最佳的選擇。

在網域環境中設定傳遞驗證的方法有好幾種。每種方法都是假設檔案伺服器和執行 IIS 的伺服器是相同網域或信任網域的成員。每一個方法也是採用某種委派形式，也就是伺服器將使用者憑證傳遞給其他伺服器的能力。使用委派就不需要重新驗證使用者。

在 Windows 2000 和 Windows Server 2003 網域中，基本和 Kerberos 兩種驗證方法皆支援委派。然而，在 Windows Server 2003 原生網域中，您還可以為 NTLM、摘要式和用戶端認證等驗證方法設定委派。這些額外的驗證方法，加上 Kerberos，都可以使用 Windows Server 2003 原生網域一項稱為限制委派的新功能。這項功能可讓您以增強的安全性實作委派，並委派除了基本和 Kerberos 驗證方法所提供的該些登入憑證外的其他登入憑證。限制委派是在 IIS 6.0 工作者處理序隔離模式中運作。

如果您使用的是基本驗證 (這應該永遠使用安全通訊端層 [SSL] 來加密使用者名稱和密碼資料)，就不需要在網域控制站層級進行任何額外的設定。假如您是經由整合式 Windows 驗證使用 Kerberos 來進行傳遞驗證，請閱讀下文＜設定伺服器進行委派＞一節。對於 NTLM、摘要式和用戶端驗證設定，請閱讀下文＜設定伺服器進行委派＞與＜使用通訊協定轉送進行驗證＞兩節。

[表 1] 顯示各驗證方法的傳遞驗證設定需求。

[表 1] 傳遞驗證設定需求

本白皮書下一節將說明限制委派的運作方式。如需限制委派的詳細資訊，請參閱 Window Server 2003 的說明及支援中心。

Windows 2000 支援委派，但您不能將委派限制到某系統上特定一組的服務，這使得此項功能難以安全地實作。Windows Server 2003 原生網域採用限制委派 (有時稱為「Service4User2Proxy」)，交託 IIS 將委派的憑證給予遠端伺服器上指定的服務清單。能夠在網路上實作限制委派，便有機會可以設定執行 IIS 的 Windows Server 2003 檔案伺服器，將使用者的憑證傳遞給指定電腦上指定的服務。而這可讓您使用網域型使用者和群組，而不是單一指定的使用者，來保障遠端內容上的 NTFS 權限安全從 IIS 伺服器進行 UNC 存取。

當在 Windows Server 2003 檔案伺服器上啟用委派時，您可以將透過 NTLM、基本、摘要式、用戶端認證，以及 Kerberos 等驗證所取得的使用者憑證委派給遠端伺服器： 用戶端可使用當中任一種驗證通訊協定向 IIS 驗證，而 IIS 會使用 Kerberos 的功能來委派憑證。Windows Server 2003 的這項功能稱為通訊協定轉送，有時候也稱為「Service4User2Self」，因為 IIS (即「服務」) 能夠代表已驗證的使用者向自身取得服務。這再合理也不過了，因為 IIS 已經驗證使用者，並且正完成告知 Kerberos 它信任該使用者的身分識別用來操作自己。限制委派與通訊協定轉送相關，且允許 IIS (即「服務」) 在對 Kerberos 網域控制站 (KDC) 的要求中使用使用者的服務票證，以取得特定遠端伺服器 (即「Proxy」) 的票證。票證只能委派給由網域系統管理員所指定之遠端伺服器上的服務，這也是為什麼這類委派叫做限制委派的原因。這可給予您極大的彈性選擇要如何在 IIS 上驗證使用者，同時保有透過傳遞驗證安全地連線到網路資源的能力。

最後，遠端檔案伺服器會使用由 IIS 所傳送的服務票證來授權對所要求之共用、目錄和檔案的存取權，這都會受到 ACL 的保護。服務票證代表著網域使用者的身分識別，例如「MyWebSiteAnonymousUser」。[圖 7] 中顯示了驗證、通訊協定轉送、限制委派，以及授權的整個過程。

[圖 7] 在限制委派下授權

作為通訊協定轉送的範例，假設您的用戶端使用 NTLM 經由整合式 Windows 驗證向網頁伺服器驗證，使用者在 IIS 上的票證沒有足夠的權限存取其他伺服器 (例如檔案或 SQL 伺服器)。結果，經過 NTLM (或除基本或 Kerberos 驗證以外的任何方法) 驗證的使用者進行的傳遞驗證將會失敗。Windows Server 2003 可讓您設定 Microsoft Active Directory®，好讓使用 NTLM 的登入可以獲得授權以進行委派 (請參閱下文的指示)。一旦您啟用此項委派，網頁伺服器收到的票證現在會是 Kerberos 票證，這就有權限可以存取其他伺服器。NTLM 型的票證基本上被升級成了 Kerberos 型票證。

假如您已從 IIS 5.0 升級至 IIS 6.0，則 IIS 6.0 依預設會在 IIS 5.0 隔離模式中執行。在 IIS 5.0 隔離模式中，跨處理序應用程式是以本機 IWAM_ComputerName 帳戶的身分執行，這會使限制委派無法正確運作。以本機帳戶的身分執行的處理序並不能代表已驗證的使用者來取得 Kerberos 票證。不過倒是可以透過將 IIS 切換到工作者處理序隔離模式中執行的方式來啟用限制委派。在工作者處理序隔離模式中執行的工作者處理序將以網路服務使用者帳戶的身分執行，這個電腦帳戶在網域上具備足夠的權利可以委派憑證。

您如何在 Windows Server 2003 上設定委派全賴您是否支援同時具有 Windows 2000 和 Windows Server 2003 網域控制站的網路而定。當同時支援 Windows 2000 和 Windows Server 2003 網域控制站時，Windows Server 2003 就必須在混合模式中執行。這會限制您只能透過 Active Directory 樹系使用 Windows 2000 委派。

在您網頁伺服器所屬網域的網域控制站上：

1. 按一下 [開始]，指向 [系統管理工具]，再按一下 [Active Directory 使用者和電腦]。

2. 必要時展開網域 (例如，iishost.microsoft.com)，並展開 [電腦] 資料夾。

3. 在右窗格中，將出現您網域中的電腦清單。在網頁伺服器的電腦名稱上按一下右鍵，再按一下 [內容]。

4. 在 [一般] 索引標籤上，確定已選取 [信任電腦以便進行委派] 核取方塊，如 [圖 8] 所示。

5. 在告知您這個操作「不應該任意執行」的訊息方塊中，按 [確定]。

   

   [圖 8] 設定混合模式網域中的伺服器以進行委派

重點 請僅在需要的伺服器上啟用 [信任電腦以便進行委派]。網頁伺服器上必須設定此選項，但對遠端檔案伺服器並不是必要的。

在不支援 Windows 2000 網域控制站的 Windows Server 2003 網域中設定委派，允許您使用通訊協定轉送和限制委派。

確認您的網域是處於 Windows 2003 Server 模式中

1. 按一下 [開始]，指向 [系統管理工具]，再按一下 [Active Directory 使用者和電腦]。

2. 在左窗格中選取一個網域。

3. 按一下功能表上的 [執行]，然後選取 [提高網域功能等級]。

接著會出現 [提高網域功能等級]，如 [圖 9] 所示。假如您的網域是處於 Windows 2000 原生或 Windows 2000 混合模式，將需要將之升級為 Windows Server 2003 模式。

1. 繼續前個步驟，從 [提高網域功能等級] 對話方塊的下拉清單中選取 [Windows Server 2003]，再按一下 [升級]。

   重點： 此變更是無法還原的，且可能要花上 15 分鐘進行傳播。

   

   [圖 9] 提高網域功能等級

2. 在「這個變更會影響整個網域。升級網域功能之後，將無法還原。」的警告上，按一下 [確定]。

3. 在「已經成功地提高功能等級」訊息上，按一下 [確定]。

1. 按一下 [開始]，指向 [系統管理工具]，再按一下 [Active Directory 使用者和電腦]。

2. 必要時展開網域 (例如，iishost.microsoft.com)，並展開 [電腦] 資料夾。

3. [Active Directory 使用者和電腦] MMC 工具的右窗格會列出您網域中的電腦。在網頁伺服器的電腦名稱上按一下右鍵，選取 [內容]，再按一下 [委派] 索引標籤 ([圖 10])。

   

   [圖 10] 電腦內容 [委派] 索引標籤的預設設定

4. 委派依預設是處於停用狀態。若要啟用通訊協定轉送及限制委派，選取 [信任這台電腦所委派的特定服務]。

5. 除此之外，您還能指定是否要委派根據 Kerberos 或任一驗證通訊協定來運作。這可讓您將傳遞驗證與基本、NTLM、摘要式、Kerberos 或任何其他 IIS 驗證提供者搭配使用。

6. 按一下 [新增] 按鈕。

7. 在 [新增服務] 對話方塊中，按一下 [使用者或電腦]，然後搜尋或鍵入要從 IIS 接收使用者憑證的檔案伺服器名稱 ([圖 11])。

   

   [圖 11] 識別要接收委派之憑證的檔案伺服器

8. 完成時按一下 [確定]。

9. 在 [ComputerName 內容] 對話方塊中，按一下 [新增] 按鈕。接著會出現 [新增服務] 對話方塊。

10. 在 [新增服務] 對話方塊中，按一下 [使用者或電腦]，然後在 [選取使用者或電腦] 對話方塊中，搜尋或鍵入要從 IIS 接收使用者憑證的檔案伺服器名稱 ([圖 12])。

    

    [圖 12] 使用 Windows Server 2003 [選取使用者或電腦] 對話方塊來指定檔案伺服器

11. 完成時按一下 [確定]。顯示在 [圖 13] 中的 [新增服務] 對話方塊現在會列出針對選定電腦以 Kerberos 登錄為服務主要名稱 (SPN) 的服務。

    

    [圖 13] Windows Server 2003 [新增服務] 對話方塊顯示已登錄的服務

12. 從 [服務類型] 清單選取 HOST (即伺服器服務) 和 Common Internet File System (CIFS) 服務，再按一下 [確定]。

    重點 請只在您確定需要接收委派的憑證時新增服務。並確定使用檔案伺服器上，而不是網頁伺服器上的服務名稱。

    附註如果您打算使用限制委派存取遠端 SQL 伺服器，還需要新增該服務 (針對 SQL 伺服器機器)。這種情況的常見範例是，您有個會對 SQL 伺服器進行 ActiveX Data Object (ADO) 連線的 Active Server Page (ASP)。SQL Server SPN 為 MSSQLSvc。

    

    [圖 14] 設定 Active Directory 進行通訊協定轉送和限制委派的結果

13. 從 [ComputerName 內容] 對話方塊上的 [委派] 索引標籤，確認已加入新服務，如 [圖 14] 所示。按一下 [確定]。這就完成了設定 Active Directory 從 IIS 伺服器至檔案伺服器進行通訊協定轉送和限制委派的程序。

檔案伺服器權限必須審慎實作，以提供對內容適當的存取權。當中涵蓋將 IIS 驗證通訊協定與像是委派和傳遞驗證等功能相結合，或指定使用者帳戶供 IIS 在驗證遠端資源時使用。當然，您的伺服器始終都應該使用 NTFS 權限以便適當地強制安全性。

共用的預設共用權限是「任何人讀取」。如果您是將 IIS 用作為發行伺服器 (WebDAV、Microsoft FrontPage®、FTP 等)，並且檔案伺服器是後端，就需要將共用和 NTFS 的權限設定到足以允許寫入資源。共用權限應該是「變更」或「完全控制」，並且需要有「修改寫入」權限，讓這些應用程式能夠正確運作。所需的特定設定乃視您如何實作發行而定。

1. 在想要共用的資料夾上按一下右鍵。

2. 選取 [共用和安全性]。

3. 選取 [共用] 索引標籤 (適時設定共用名稱和註解)。

4. 按一下 [權限]。

5. 移除「任何人」群組 (若存在的話)，這可能會允許未預期的存取。

6. 新增應該對共用有存取權的適當使用者或群組 (「已驗證的使用者」是個不錯的選擇)。對於委派存取，這一般是「網域」群組或使用者。建議您使用群組來控制對本機資源的存取權。

7. 給予此使用者或群組存取內容所需的最低權限。「讀取」是所允許的最低共用權限。若此位置是要用於 FrontPage 發行，可能就需要「變更」或「完全控制」權限。

重點： 在編輯任何預設 NTFS ACL 設定時請小心，您需要確定系統管理員仍可控制檔案內容。

1. 在想要保護的資料夾或檔案上按一下右鍵。

2. 選取 [共用和安全性]。

3. 選取 [安全性] 索引標籤。

4. 按一下 [新增] 按鈕。

5. 鍵入您希望能存取此資源的網域使用者或群組的名稱，然後按一下 [確定]。預設 NTFS 設定僅適用於伺服器上的本機帳戶。您必須針對網域使用者明確允許適當的存取權。

6. 確認 [允許] 核取方塊是設為允許最低存取 (若要讓 IIS 擷取內容，只需要核取「讀取」存取權)。

附註： 取消核取允許列出資料夾內容的方塊並不會停用 IIS 管理員中的 IIS 目錄瀏覽功能。取消核取允許讀取和執行的方塊並不會停用 IIS 指令碼或 IIS 管理員中的執行權限。

在一些像是共用主機代管提供者的環境中，適當開放共用權限並仰賴 NTFS 權限來控制安全性是很常見的。要記得共用和 NTFS 權限會相結合以提供兩者所允許的最低權限。不管您選擇如何整合共用與 NTFS 權限，請確定它們的設定正確，因為這些權限是您網頁伺服器安全性的基石。

若要提高可用性，請考慮像對 SQL 伺服器進行叢集化一般來叢集檔案伺服器。此外 (或者)，您可以使用 DFS 來提供非機器特定的 UNC 命名慣例，並使用檔案複寫服務 (FRS) 來提供重複。這些技術都經過實證可提高 Windows 2000 Service Pack 3 (SP3) 和 Windows Server 2003 的可靠性。另外，也可使用網路負載平衡將流量分散給一組相同的檔案伺服器。下面列出幾篇有助於說明如何實踐此案例的知識庫 (KB) 文件，它們在使用 FrontPage Server Extensions 時效果特別顯著。

Windows Server 2003 中叢集網路名稱資源的內容說明 (英文)：

https://support.microsoft.com/default.aspx?scid=kb;en-us;Q302389

如何排解叢集服務帳戶修改電腦物件時所遇到的疑難：

https://support.microsoft.com/kb/307532/zh-tw

以 Windows 2000 為主的伺服器叢集的 Kerberos 支援：

https://support.microsoft.com/kb/235529/zh-tw

分散式檔案系統：

https://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/windows2000/techinfo/reskit/en-us/distrib/dsdb_dfs_kale.asp (英文)

當 IIS 傳送內容時，它會快取頁面以便在收到隨後的要求時快速傳送內容。這對遠端檔案伺服器來說尤為重要，因為網路子系統會介入 IIS 及其內容之間，因而增加延遲。當使用快取時，必須設置一些機制，以便讓 IIS 知道遠端伺服器上的內容比存放在 IIS 快取中的版本還要新。

IIS 6.0 支援兩種方法來判斷檔案快取是否需要以遠端檔案伺服器的新內容進行更新： 上次修改時間和檔案變更通知，前者是 IIS 6.0 的新功能，而後者就跟在 IIS 4.0 和 IIS 5.0 中實作的一樣。此外，也可針對靜態檔案和 ASP 個別設定要採用的快取方法。

自 Windows Server 2003 Service Pack 1 (SP1) 開始，UNC 內容會同時快取在工作者處理序檔案快取和 HTTP.sys 快取中。快取的行為乃視 DoDirMonitoringForUnc 登錄屬性的值而定，如下文＜上次修改時間＞和＜檔案變更通知＞中所討論般。

在預設情況下，IIS 6.0 只會詢問檔案伺服器上的檔案系統快取檔案上的上次修改時間。假如檔案上的上次修改時間有所變更，則會以新內容更新 IIS 上的檔案快取。若上次修改時間未變更，便會傳送 IIS 上的檔案的快取版本。在對應大量虛擬目錄到 UNC 共用時，使用上次修改時間來取代監視每個虛擬目錄是否有變更通知 (這可能會相當耗用檔案系統資源)，可提升延展性。檢查檔案上的上次修改時間是比檔案變更通知還要可靠的機制，因為有些 NAS 裝置並不會徹底實作變更通知。此外，由於取樣上次修改時間時會驗證共用和 NTFS 權限，安全性也能因此獲得增強。

上次修改時間快取方法最適合用於：

• 站台和虛擬目錄的數量多。

• 檔案很大 (大於 256K 的檔案將不會使用任何快取演算法進行快取，假如您要傳遞較大的檔案，沒有 HTTP.sys 快取和上次修改時間演算法的話，影響會比較低。在 Windows Server 2003 SP1 中，這項限制可透過登錄機碼來設定為大於 256K)。

• 快取點擊率低。

• 可靠性/可用性比效能重要。

• 您的 NAS 裝置不能可靠地支援變更通知。

• 您擔心在快取點擊期間需要遵守共用權限。

在繁忙的伺服器上，要在檔案每次被存取時檢查上次修改時間相當不切實際。因此，IIS 6.0 預設最多每五秒會檢查一次上次修改時間，否則它會假定檔案沒有變更。IIS 有五秒的窗口會從快取中傳遞出過時的檔案。

對於一些站台來說，五秒的時間太長，而對其他站台而言則太短。取樣間隔可使用下列登錄機碼來設定，這些機碼預設並不存在：

• 靜態頁面 設定登錄屬性 FileAttributeCheckThreshold，這是 DWORD 值，位於 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters。 另外也請注意伺服器端包含的檔案處理常式 (Ssinc.dll) 會利用使用者模式靜態檔案快取，因此您套用至使用者模式靜態檔案快取的設定也會套用至 .stm、.shtml，以及任何其他對應至 Ssinc.dll 的檔案。假如 DoDirMonitoringForUnc 登錄屬性 (位於 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters 的 DWORD 值) 是設為 False，則 IIS 會在經過一段為 FileAttributeCheckThreshold 登錄屬性設定的值相等的時間後，檢查快取項目是否有變更。自 Windows Server 2003 SP1 開始，IIS 會同時檢查工作者處理序檔案快取項目及 HTTP.sys 快取項目。

• ASP 指令碼 設定登錄屬性 FileMonitoringTimeoutSeconds，這是位於 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ASP\Parameters 的 DWORD 值。

使用上次修改快取更新機制，傳遞的內容將比較可靠且安全。另外在廣泛的應用程式結構上 (即您的網頁伺服器擁有眾多應用程式指向上千個不同的目錄)，它也能適當進行調整。不過倒是會有效能上的償失，可能在靜態內容上會很明顯。

在大多數情況下，以 UNC 為主的內容，效能在預設的快取設定下將稍微緩慢些 (與使用以變更通知為主的快取相較之下)。如果差異真的很大，應該是靜態檔案所造成的，ASP 檔案不會有這個問題。對於 ASP 要求，檢查上次修改時間與接聽變更通知之間的效能償失極微，因為不管是採用什麼方法進行快取更新，大半的延遲都是發生在重新編譯和執行 ASP 頁面上。

IIS 會在每個虛擬目錄的根層級監視變更通知事件。大量虛擬目錄可能會導致明顯的負荷，但是要是您使用的檔案伺服器能可靠地報告變更通知，並且您使用遠端內容的站台或虛擬目錄數量並不多，那麼採用變更通知是比較快的方法。舉例來說，假如您有一個使用幾個應用程式的網站，且所有的內容均存放在 Windows Server 2003 檔案伺服器上，那麼建議您使用變更通知的快取方法。

以變更通知為主的快取最適合用於：

• 使用 UNC 內容的站台和虛擬目錄的數量不多。

• 檔案小到可以快取 (256K 以下)。

• 要求是集中在幾個檔案間，也就是說，快取點擊率很高。

• 核心模式快取所提供的效能提升很重要。

您可以加入下列的登錄機碼來啟用以變更通知為主的快取，這些登錄機碼預設並不存在：

• 靜態頁面 將登錄屬性 DoDirMonitoringForUNC (位於 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Inetinfo\Parameters 的 DWORD 值) 設為 True。另外也請注意伺服器端包含的檔案處理常式 (Ssinc.dll) 會利用使用者模式靜態檔案快取，因此您套用至使用者模式靜態檔案快取的設定也會套用至 .stm、.shtml，以及任何其他對應至 Ssinc.dll 的檔案。自 Windows Server 2003 SP1 開始，IIS 會同時檢查工作者處理序檔案快取項目及 HTTP.sys 快取項目。

• ASP 指令碼 設定登錄屬性 EnableChangeNotificationForUNC，這是位於 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\ASP\Parameters 的 DWORD 值。

UNC 路徑上的高壓情況可能需要經過特殊調整，才能最佳化伺服器效能。在這種狀況下，瀏覽器、IIS 伺服器和遠端檔案伺服器上的事件日誌，以及 IIS 記錄檔的 Win32 錯誤訊息中，可能都會出現某些錯誤。下文將討論這些錯誤，並探討其解決方案。

在負載下使用 UNC 路徑，可能會看到下列的事件檢視器錯誤訊息：

「Windows 找不到網路路徑。請確認網路路徑正確，且目標電腦不是忙碌中或已關機。如果 Windows 仍舊找不到網路路徑，請連絡您的網路系統管理員。錯誤碼 0x80070033。」

「無法到達網路位置。有關網路疑難排解資訊，請參考 Windows 說明。錯誤碼 0x800704CF。」

當 IIS 伺服器在進行 UNC 連線時，若輸出 TCP 連接埠不足，可能就會傳回這些錯誤。在這些情況下，IIS 會對所有要求傳回 HTTP 500 錯誤，直到 TCP 連接埠再次可用為止。若要修正此問題，請使用 MaxUserPort 登錄設定 (在 IIS 伺服器上)，來增加可用的連接埠數目。如需 MaxUserPort 的詳細資訊，請參閱登錄機碼(英文)： https://www.microsoft.com/technet/prodtechnol/isa/2000/proddocs/isadocs/cmt_regkey.mspx(英文)。

例如，要是您有大量虛擬目錄，或是使用傳遞驗證並擁有大量已驗證的使用者，就有可能擁有許多驗證使用者同時使用 UNC 路徑上的資源。系統會為每名使用者開放不同的 SMB 連線，從 IIS 伺服器連至遠端檔案伺服器。每個 SMB 連線都會使用一個連接埠。預設情況下，對於輸出 TCP 連線，會限制您使用連接埠 1,024 至 5,000 (稍微少於 4,000 個連接埠可用)，因此您可能需要將此值增加為較大的值，例如 10,000 或 20,000，以允許額外的連接埠供每個 SMB 連線使用。請注意這可能會造成其他應用程式在這些數字較大的連接埠上建立通訊端時產生問題。詳細資訊，請參閱下列 MSDN 文件： https://www.microsoft.com/taiwan/technet/itsolutions/network/deploy/depovg/tcpip2k.aspx。

在某些情況下，由 IIS 報告與 UNC 路徑名稱相關的錯誤是因檔案伺服器上而非 IIS 上的問題而引起。如前所述，UNC 連線會產生 SMB 連線。而這會導致建立一或多個工作項目以供 SMB 連線使用。工作項目是 SMB 進行 I/O 作業而使用的資料結構物件，並且可以各種方法來取用不同的時間長短。比方說，對像是 CreateFile 或 GetFileAttributes 的檔案進行某項操作只需花一個 I/O 工作項目一段很短的時間。但是要求目錄結構上的變更通知則會花上一個工作項目整段連接至 IIS 伺服器的期間。因此，工作項目所執行的工作種類可能會影響工作項目服務 SMB 連線的整體可用性。

工作項目是建立在檔案伺服器的非分頁集區記憶體中，通常稱為非分頁集區。此記憶體之所以稱為非分頁是因為它不能動態地交換或分頁至系統分頁檔。因此，伺服器擁有充足可用的分頁集區以便正常運作是相當重要的。

檔案伺服器上有大量的工作項目可能會造成過度配置非分頁集區記憶體。在這些情況下，您可能會看到下列的事件檢視器錯誤訊息：

「沒有足夠可用的伺服器儲存空間以處理此命令。」

「伺服器無法透過系統未分頁共用區來進行配置，因為共用區目前是空的。」

「伺服器無法在最近的 60 秒內配置 <n> 次工作項目。」

您可以藉著開啟工作管理員，選取 [效能] 索引標籤並查看 [核心記憶體] 框架下的非分頁值，迅速地檢查檔案伺服器上的記憶體使用情形。要管理這類的問題有兩種方法： 減少工作項目的數量，或調整 IIS 和檔案伺服器來管理更多工作項目。

在決定什麼是最佳的辦法以繼續之前，您應該在模擬的工作負載下執行伺服器幾個小時的時間，並分析效能監視器計數器來查看檔案伺服器上下列的計數器：

• Server\Files Open 提供有助於評估適當 SMB 設定的資訊。

• Server\Files Sessions 提供有助於評估適當 SMB 設定的資訊。

• Server\Work Item Shortages 若此計數器增加，表示需要更多工作項目。

• Server\Pooled NonPaged Bytes 若此計數器過低，表示伺服器幾乎已經耗盡它可用的非分頁集區。可能有必要減少 SMB 工作項目。

當您調整伺服器時，監視這些設定將有助您評估調整的效率。

重點： 在 x86 平台上，非分頁集區記憶體的最大數量為 256 MB，不過您的系統可能擁有低於此值的非分頁集區記憶體，因為最大數量是動態決定而成。

檔案伺服器上的非分頁集區記憶體取用情形可藉由減少檔案伺服器上配置的工作項目數加以左右。這可以使用各種不同的方法來完成。

• 變更 IIS 的快取演算法，使用預設的上次修改時間方法來更新快取的結果，會建立較少的工作項目。

• 減少連線到檔案伺服器的已驗證使用者數目。系統會為每個唯一的使用者建立一個連線。如果您為連線指定使用者，而不是使用傳遞驗證，則可減少連線數。

• 減少使用遠端資源的虛擬目錄或網站數量。

對 IIS 伺服器所作的調整會影響檔案伺服器上的負載。因此，當調整這些參數時，檔案伺服器上的設定會由 IIS 伺服器上的設定決定。換句話說，您可以控制檔案伺服器上所需的工作項目數，方法是調整 IIS 伺服器上的登錄設定 MaxCmds，然後修改檔案伺服器上的 MaxMpxCt 和 MaxWorkItems 來配合 MaxCmds 設定。MaxCmds 會決定 IIS 伺服器允許連至檔案伺服器的同步 SMB 連線數，MaxMpxCt 是在檔案伺服器上設定，用來限制連至該伺服器的同步連線數，而 MaxWorkItems 則會指定檔案伺服器可配置的接收緩衝區最大數量。為 MaxCmds 決定適當的值很重要，如此才知道要為檔案伺服器上的 MaxMpxCt 和 MaxWorkItems 輸入什麼值。在確定 MaxCmds 後，檔案伺服器上 MaxMpxCt 的設定應該等於 IIS 伺服器上的 MaxCmds。另外，MaxWorkItems 的設定必須至少為 (MaxCmds * IIS 伺服器的數量)。

[表 2] 顯示 Windows Server 2003 上部分 SMB 設定的預設和最大登錄值 (與 Windows 2000 上相同)：

[表 2] SMB 登錄設定

為了協助決定這些設定的正確值，此處提供了一些工作項目設定的一般相關細節：

• 當使用傳遞驗證來存取遠端內容 (如 [圖 5] 所示) 時，每個唯一驗證的使用者都會建立一個 SMB 連線。當指定使用者存取遠端內容 (如 [圖 4] 所示) 時，只會使用一個 SMB 連線。

• 使用檔案變更通知作為快取更新演算法會增加取用很長一段時間的工作項目數目，因為每個變更通知例項都使用一個工作項目直到遺失連線為止。

• MaxWorkItems 是在遠端檔案伺服器上設定，登錄位置為 HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters。

• MaxCmds 和 MaxMpxCt 是在 IIS 伺服器上設定，登錄位置為 HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters。

• 原則是 MaxCmds 不得超過 12,000，因為在 RAM 超過 512 MB 的 x86 平台上有記憶體限制。

• 為了讓 MaxWorkItems、MaxCmds 和 MaxMpxCt 登錄值生效，您必須將遠端檔案伺服器上的伺服器服務，以及 IIS 伺服器上的工作站服務停止後再啟動。您可能還需要重新啟動相依的服務， 伺服器不需要重新啟動。

下列公式將協助您估計 MaxCmds 的開始值。為了釐清套用此項資訊的方式，這些公式會用在下節＜調整 SMB 的 IIS 和檔案伺服器設定案例＞中的一些案例中。

當使用變更通知進行快取時用於估計 MaxCmds 的公式顯示如下： (IIS 需要監視以查看是否有變更通知的個別實體目錄數) * (1 [若存在靜態檔案] + 1 [若存在 ASP 內容] + 1 [若存在 ASP.NET 內容]) + 50 (用於同時預設/一般檔案 I/O)。

此公式所提供的值假定 100% 的 IIS 伺服器連線在任何指定時間內都是處於作用中狀態 。一般來說，情況並非如此，所以 MaxCmds 可能會減少百分之 25 到 50，視活動的特性而定。

重點： 此項運算只是粗略的估計。使用效能監視器計數器的研究建議如上，您可以進行恰當的調整。

當使用上次修改時間進行快取時用於估計 MaxCmds 的公式顯示如下： (每秒的最大要求數 / 失效時間) / 2。失效時間 (Staleness Time) 指的是 IIS 檢查檔案變更的頻率，預設為五秒。此公式所提供的值假定隨時都在使用高百分比的 IIS 資源。若情況並非如此，您可減少 MaxCmds 百分之 50 到 75，視活動的特性而定。

重點： 此項運算只是粗略的估計。使用效能監視器計數器的研究建議如上，您可以進行恰當的調整。

在決定 MaxCmds 的值之後，您要將 MaxWorkItems 的值設定等於 (MaxCmds * [連線至檔案伺服器的 IIS 伺服器數目]) 的值。若只使用一部 IIS 伺服器，則 MaxWorkItems 應該是等於 MaxCmds。若有四部 IIS 伺服器，則 MaxWorkItems = 4 * MaxCmds。

在 RAM 超過 512 MB 的 Windows 2003 Server 上，所使用的每個工作項目會耗用 20K 的非分頁集區記憶體。若伺服器內的 RAM 低於 512 MB，則每個工作項目會使用 8K 的非分頁集區記憶體。為了確保有充足的非分頁集區記憶體可供其他伺服器資源使用，請試著將工作項目所使用的非分頁集區記憶體量減至最少。

重點 x86 平台上的非分頁集區最大大小為 256 MB。不過，您的伺服器可能會配置低於此數的大小，影響的因素包括實體記憶體大小。非分頁集區大小在設定之後可能會根據系統硬體設定 (包括實體記憶體大小及安裝的裝置) 而進行動態調整。您可以使用系統 PerfMon 工具透過查看兩個計數器，來監視非分頁集區使用量： Memory\Pool nonpaged Bytes 和 Memory\Pool nonpaged Alloc，兩者會指出目前使用了多少非分頁集區記憶體。有兩種方法可以間接判斷非分頁集區記憶體使用量何時超出最大大小。第一種是伺服器服務會在無法配置非分頁集區記憶體時記錄事件至系統事件日誌中。第二種是 PerfMon 計數器「Server\Pool Nonpaged Peak」，它會指出伺服器壽命期間任何時段所配置的最大非分頁集區記憶體量。若您相信伺服器取用的非分頁集區記憶體已達實際最大值，此值可粗略指出最大的可用非分頁集區記憶體量為何。

在某些情況下，您可能會發現您需要更多的工作項目數目，但每個工作項目要耗上 20K，您可能會取用過多的非分頁集區記憶體。假如您的伺服器擁有 512 MB 或以上的 RAM，則可將工作項目的大小設定為 8K，而非 20K。在檔案伺服器上，將登錄機碼 SizReqBuf (位於 HKLM\System\CurrentControlSet\Services\LanmanServer\Parameters 的 REG_DWORD) 設定為 0x1104 (4356d)。這允許在檔案伺服器上使用更多工作項目而無需取用同樣多的非分頁集區記憶體。此因應措施的代價是會減緩大型目錄的列舉，因而可能減緩網路效能。

附註 基於本白皮書的目的，我們假定伺服器擁有 512 MB 以上的 RAM，最大的非分頁集區記憶體大小為 256 MB，而一個工作項目耗用 20K。

為了為 IIS 和檔案伺服器決定適當的設定，讓我們來看看快取演算法 (上次修改時間和檔案變更通知) 如何影響前述的 MaxCmds、MaxMpxCt 和 MaxWorkItems 登錄設定。將這些考量因素與效能監視器研究相結合，可告訴您如何妥善地設定伺服器。基於此項討論的目的，將把每個應用程式視為 UNC 對應的網站或虛擬目錄。

在下列的案例中，假設每部伺服器都有超過 512 MB 的 RAM，並且有四部 IIS 伺服器連線檔案伺服器。

在此案例中，每部 IIS 伺服器都裝載多達 20,000 個應用程式。在這些 20,000 個應用程式當中，只有 1,000 個左右在任何指定時間內是處於作用中狀態。每個使用中的網站都會在自己的應用程式集區內執行，並且擁有兩名使用者：即發行使用者 (使用 FrontPage 或 WebDAV 發行) 和匿名使用者。內容主要是 ASP 和靜態檔案，加上少數的 ASP.NET 應用程式。

使用＜當使用檔案變更通知時估計 MaxCmds＞中所提供的公式，MaxCmds 的值估計如下：

20,000 * (1(靜態) + 1(ASP) + 1(ASP.NET)) + 50 = 60,000

接下來，會計算檔案伺服器上的最大工作項目數：

MaxWorkItems = (60,000 * 4 IIS 伺服器) = 240,000 個工作項目

最後會計算檔案伺服器上的非分頁集區記憶體需求：

非分頁集區 = (60,000 * 4) * 20K ≈ 4.6 GB

非分頁集區記憶體需求大於 256 MB 的限制。在此案例中，並沒有足夠的記憶體使用檔案變更通知。

使用上次修改時間方法進行快取更新，應該用不到變更通知的任何工作項目。這是預設設定，並且您可從此項分析看出，正是此案例所需的設定。

使用＜當使用檔案變更通知時估計 MaxCmds＞中所提供的公式：

MaxCmds = ([1,000 為最大要求量] / [5 秒為失效間隔]) / 2 = 100

接下來，計算 MaxWorkItems：

MaxWorkItems = (100 * 4 IIS 伺服器) = 400

最後，檔案伺服器上估計所需的非分頁集區記憶體計算如下：

非分頁集區 = 400 * 20K = 8 MB

非分頁集區記憶體需求介於 256 MB 的限制內。

視檔案 I/O 的作用流量，以及您對效能計數器的分析 (上述的 Server\Files Open、Server\Server Sessions 和 Server\Work Item Shortages) 而定，您可能還是需要從估計值增加 MaxCmds、MaxWorkItems 和 MaxMpxCt 的設定。

案例 1 的建議設定是使用預設的上次修改時間快取演算法：

此案例非常適合用在當大量網站意味著因為沒有足夠可用的非分頁及區記憶體，所以使用檔案變更通知演算法可防止設定被調整的情況。將 SMB 作為調整的限制移除後，除了考慮加入更多網站會如何影響系統管理負擔之外，您還應該確實考量網站的合計流量，以判斷您每部伺服器實際上可設定多少網站。

此案例將探討含大量執行數百個應用程式的大型網站，在此例中，假設有 300 個應用程式。另外也假設此網站包含靜態檔案、ASP 內容和 ASP.NET 內容，並且大多數使用者為匿名使用者。

使用＜當使用檔案變更通知時估計 MaxCmds＞中所提供的公式：

MaxCmds = 300 * (1(靜態) + 1(ASP) + 1(ASP.NET)) + 50 = 950

接下來，會計算檔案伺服器上的最大工作項目數：

MaxWorkItems = (950 * 4 IIS 伺服器) = 3,800

最後，檔案伺服器上估計所需的非分頁集區記憶體計算如下：

非分頁集區 = 3,800 * 20K = 76 MB

您不會用到上次修改時間的任何工作項目，不過因為網頁伺服器和檔案伺服器之間的沉重流量，會用到許多暫時工作項目。當使用上次修改時間演算法時，會採用使用者模式中的快取，但不會使用核心模式回應快取。這可能會使檔案流量的量大幅增加。因為量大的關係，為三個快取檢查上次修改時間演算法伴隨的 CPU 負荷會相當的顯著。

案例 2 的建議設定是使用 IIS 變更通知快取演算法：

在此案例中，選擇變更通知演算法即使結果會使用更多工作項目，仍然是個好主意。因為量大的關係，盡可能減少連至檔案伺服器流量的量會比較妥當。假如使用變更通知，那麼要監視的目錄數目就不會耗盡記憶體，而且您可大幅減少後端的流量。因為不需要在每次取樣間隔時檢查檔案伺服器上的上次修改時間，加上使用 HTTP.sys 快取，流量因此得以降低。

要是在實作這些設定之後，您發現要以這種方式快取的應用程式實在太多，可使用上次修改時間演算法，並將快取的失效時間延長為 30 秒，這也可大幅減少後端網路流量的量。

此案例將探討一個含有 10 個應用程式的小網站，包括靜態、ASP 和 ASP.NET 內容，接收非常頻繁的要求。

使用＜當使用檔案變更通知時估計 MaxCmds＞中所提供的公式：

MaxCmds = 10 * (1(靜態) + 1(ASP) + 1(ASP.NET)) + 50 = 80

接下來，會計算檔案伺服器上的最大工作項目數：

MaxWorkItems = (80 * 4) = 320

最後，檔案伺服器上估計所需的非分頁集區記憶體計算如下：

非分頁集區 = 320 * 20K ≈ 1.6 MB

您不會用到與變更通知相關連的任何工作項目，不過您會有暫時工作項目，並在網頁伺服器和檔案伺服器之間有龐大的流量。

在此案例中，不用說，當然是建議使用檔案變更通知快取機制。因為內容只組織在少數應用程式中，我們只需要一些工作項目即可可靠地快取內容。

要注意的是，MaxWorkItems 是 (MaxCmds * IIS 伺服器的數目)，也就是 80 * 4 = 320。這遠遠低於 MaxWorkItems 的預設值 4,096，所以不需要調整這個值。

假如遠端檔案伺服器還會將檔案傳遞給 IIS 伺服器以外的電腦，您將需要增加 MpxCt 和 MaxWorkItems 的值，以允許額外的連線。原則是對每個連至不同伺服器的連線，一次增加 50 的 MpxCt。將增加的百分之 25 至 50 包含在 MaxWorkItems 的值中。

有一點要特別注意的是，正是與 MaxCmds 搭配使用的 MaxMpxCt 允許單一用戶端在遠端伺服器上使用比其他設定允許更多的資源，因而可能提高您暴露於惡意用戶端發出的拒絕服務 (DoS) 攻擊。

案例 3 的建議設定是使用 IIS 變更通知快取演算法：

對於只有一個或幾個網站的高流量伺服器，SMB 調整並不是影響調整的主要因素。您反而應該調整 SMB 和快取演算法設定，以有效地利用處理要求的效率。

Microsoft 實驗室內的可靠性測試發現，調整這些登錄機碼可在效能方面產生相當顯著的差異。不過，還是強烈建議您先以預設值測試應用程式，再適時增加設定。您也應該查閱 Windows 中的 SMB 說明文件，並閱讀列在附錄中相關的知識庫文件。

每項技術都有自己一套優點，及伴隨的難題。伴隨著存放內容在遠端伺服器產生的問題通常與網路或驗證有關。這些問題將在下列各節解決： 提供過時內容，IIS 管理員未顯示遠端內容、對應磁碟機支援方面的變動，以及離線檔案的角色等。

若 IIS 提供過時內容，您可停用適當的快取，靜態或 AS，作為疑難排解的辦法。假如 IIS 是使用上次修改時間作為更新快取的方法，請確定您已等候預設五秒的時間 (或設定的間隔)，容快取項目重新整理。

1. 開啟 IIS 管理員。

2. 在 <ComputerName> 上按一下右鍵，當中 <ComputerName> 是您電腦的名稱，再按一下 [內容]。

3. 按一下 [編輯] 以編輯 [WWW Service Master 內容]。

4. 在 [主目錄] 索引標籤上，按一下 [設定]。

5. 在 [處理選項] 索引標籤上，選取 [不要快取 ASP 檔案選項]。

6. 按一下 [套用]，再按 [確定] 以儲存您的變更。

7. 重新啟動 IIS。

將下列的值加入登錄中：

HKLM\System\CurrentControlSet\Services\Inetinfo\Parameters

DisableMemoryCache: REG_DWORD: 1

您必須重新啟動伺服器，讓此設定生效。

警告： 不當使用登錄編輯器可能會造成嚴重問題，而必須重新安裝作業系統。Microsoft 無法保證可解決因不當使用登錄編輯器所引起的問題。您必須自行承擔使用登錄編輯器的風險。

如需如何停用靜態檔案和 ASP 範本快取的詳細資訊，請參閱此知識庫文件： https://support.microsoft.com/default.aspx?scid=kb;EN-US;q250925 (英文)。

當使用 IIS 管理員建立與遠端檔案伺服器相對應的虛擬目錄或網站時，您可能會注意到似乎有些令人混淆的錯誤訊息和行為。您可能會看到「登入失敗： 不明的使用者名稱和密碼」或「系統找不到指定的路徑」等錯誤。另外，IIS 管理員可能不會顯示存在的檔案，但當您在 Microsoft Internet Explorer 使用 URL 存取虛擬目錄時，卻又可以順利地傳遞檔案。

這是因為 IIS 管理員是使用目前登入的使用者 (如 Web 管理員) 來存取遠端內容，而不是使用當您建立網站或虛擬目錄時提供的憑證來存取所引起的。您會發現若您使用 net use (或任何其他會在登入使用者的使用者內容中建立連線的方法) 來建立與檔案伺服器的連線，IIS 管理員就會突然顯示該些檔案。您可以藉由設定檔案伺服器讓 IIS 系統管理員具備讀取遠端檔案系統的權利，來消除此問題。

若要確認您已正確設定網站或虛擬目錄，只要使用網頁瀏覽器對遠端內容發出一些要求就行了。除非適當設定，否則 IIS 管理員並不是驗證您的客戶是否能存取遠端內容的可靠方法。

基於安全考量，服務不能使用經由其他登入使用者所提供之憑證所對應的磁碟機。您可能可以在 IIS 5.0 中辦得到，但不建議您這麼做。在 Windows XP、Windows 2003 Server，以及未來版本的 Windows，服務都不能使用這些對應磁碟機。如需詳細資訊，請參閱知識庫文件： https://support.microsoft.com/default.aspx?scid=kb;en-us;Q180362 (英文)。

在撰寫本文時，Windows Server 2003 上的索引伺服器只支援製作本機內容的索引，因此，並不支援 UNC 內容搜尋。此外，Windows Server 2003 上的 FrontPage Server Extensions 2002 也不再包含 Wide Area Information Server (WAIS) 搜尋引擎，這是由使用搜尋元件的 FrontPage Web 所用。目前建議的替代方案是使用索引伺服器來取代 WAIS，使用搜尋元件的 FrontPage Web 在以 UNC 為主的存放上不能用。請參閱 https://support.microsoft.com/default.aspx?scid=kb;en-us;203796 (英文) 以取得使用索引伺服器取代 WAIS 的詳細資訊。

本文評論了 Windows 2003 Server 一些重要的新功能，這些都是與 IIS 使用透過 UNC 路徑名稱存取遠端存放的相關功能。使用傳遞驗證的功能與限制委派和通訊協定轉送相結合，開啟了將 IIS 整合至您的網路並同時提高安全性、效能和可靠性的新機會。另外還介紹了可用於 IIS 的快取方法，以及它們在不同的案例中如何影響效能。關於調整不同案例的章節說明了您如何能運用此項資訊來正確設定 IIS 及檔案伺服器，以最佳化效能和可靠性。

請參閱以下資源以取得進一步的資訊：

• 適用於網際網路開發人員的驗證和安全性資訊 (英文)

• 受到 MaxWorkItem 和 MaxMpxCt 值限制的終端機伺服器用戶端連線和登入 (英文)

• Internet Information Services (IIS) 6.0 技術概觀

如需有關 Windows Server 2003 的最新資訊，請瀏覽 Windows Server 2003 網站：https://www.microsoft.com/taiwan/windowsserver2003/default.mspx。

在過去，客戶在設定 UNC 共用時遇到的許多問題，都是因為對如何設定網頁伺服器和檔案伺服器以確保能安全且可靠地存取正確的資源有所混淆而引起，特別是當使用協力廠商檔案伺服器時。為了供您參考，此處提供了與設定裝載檔案伺服器上的內容的 Windows 2000 網頁伺服器相關一些最常見的知識庫文件。

一般

Q197964： PRB： 無法存取含有 FileSystemObject 的遠端檔案

Q286401： IIS 5.0 中的 UNCAuthenticationPassThrough 支援限制 (英文)

FrontPage

Q215421： Server Extensions 安裝到 UNC 路徑出現不正確的錯誤 (英文)

Q215459： 將 UNC 虛擬目錄轉換到子網站時發生錯誤 (英文)

檔案變更通知

Q281253： 當內容位在 UNC 共用上時，遺失檔案變更通知 (英文)

Q221790： IIS 在連接到遠端 UNC 路徑時耗盡工作項目而致使 RPC 失敗 (英文)

Q232476： 受到 MaxWorkItem 和 MaxMpxCt 值限制的終端機伺服器用戶端連線和登入

Q171148： Windows 2000 中的 MaxMpxCt 和 MaxCmds 限制 (英文)

驗證

Q280383： 當使用 UNC 共用與使用者名稱和密碼憑證時的 IIS 安全性建議 (英文)

Q257174： 透過 IIS 使用對應磁碟機 (英文)

Q180362： INFO: 服務和重新導向的磁碟機 (英文)

Q269009： UNC 對應的內容目錄上的 MMC 中出現的紅色警告符號 (英文)

Q222069： 使用遠端電腦時，IIS 4.0 要求輸入使用者名稱和密碼 (英文)

Q207671： HOWTO： 從 IIS 應用程式存取網路檔案

Q124184： 以系統帳戶身分執行的服務無法存取網路 (Null 工作階段共用) (英文)

交互操作性： NOVELL

Q267283： 當虛擬伺服器位在 Novell 共用上時，Inetmgr 顯示畫面錯誤 (英文)

Q271214： 無法從 IIS 5.0 存取 Netware 5 伺服器上的 FoxPro 資料庫 (英文)

Q271228： IIS 5.0： 無法使用 ASP 取得位在 Netware 5 伺服器上的存取資料庫資料 (英文)

Q285159： 如何在遠端 Novell Netware 共用上建立虛擬目錄 (英文)

Q250502： 當將程式執行成服務時，無法存取 Novell UNC 共用 (英文)

Q250925： IIS 與網路應用裝置檔案伺服器的 ASP 重新整理問題 (英文)