(IIS問題專家Brett Hill提供了這些答案)
1. 我怎樣對IIS設置進行備份？
2. 什么工具能幫助我施加一個負載并進行應用程序的強度測試？
3. 當Localstart.asp返回了一個“正在創建中”響應時，發生了什么事情？
4. 能在Microsoft Windows XP Home Edition中安裝IIS或PWS嗎？
5. ISAPI篩選器能在一個單獨的進程空間中運行嗎？
6. 我在哪能獲得這樣的示例代碼--它顯示了如何在使用WebDAV的ASP中編輯文檔？
7. 當我試圖用ASP去訪問一個數據庫時，我得到了一個“拒絕訪問”的回應，這是什么原因？
8. 如何在沒有恢復原始設置的情況下運行IIS鎖定工具？
9. 在我的intranet環境中，如何處理“server-side include”語法，而不必重新命名所有的文件？
10. 在Windows 2000 Professional中，我怎樣做才能讓域用戶來管理虛擬目錄，以便域用戶能夠創建和管理他們自己的虛擬目錄？
問： 我怎樣對IIS設置進行備份？
答： 有多種方法可以用來完成此項工作。在Internet信息服務管理器控制臺（IIS插件）中所設置的屬性和值都被儲存在Metabase.bin文件中，缺省情況下，這個文件位于“C:\winnt\system32\inetsrv”目錄中。在IIS 5.0中，你可以從內置的IIS插件中來備份元數據。如果需要進行此工作，請選擇桌面上的計算機圖標然后單擊右健。然后再選擇 “備份/恢復配置”。然后你就可以選擇備份現有元數據設置或者恢復以前的版本。與此相同的選項在MetaEdit 2.2中也可找到。
當你以這種方式保存了元數據時，你的備份將以.md0文件的格式儲存在C:\winnt\system32\instrv\metaback文件夾中。當你執行備份時，文件將使用你所指定的名稱，如Pre-Lockdown.md0。如果你使用相同的文件名創建了多個備份，他們將使用數字逐漸遞增的擴展名，如Backup.md0，Backup.md1等等。
在你的元數據嚴重損壞的情況下，你將不能啟動IIS。此時，你也不能從IIS插件或metaedit中執行恢復操作。如果真的發生了類似情況，你就可以通過從備份文件夾中選用最合適的.md0（.md1等等）元數據備份文件來替換Metabase.bin。如果你的備份文件沒有錯誤，IIS將會立刻啟動。
制作元數據的備份還有其它兩個意義。你可以使用xcopy，scopy或其它復制程序來簡單地復制Metabase.bin文件。你應該先停止Internet服務，以保證你的元數據是最新的并且不在使用狀態中。
最后，我們還提供了兩個腳本--metaback.vbs和metarest.vbs--它們位于Inetpub/IISSamples/sdk/admin（如果你在IIS 5.0上安裝了IIS SDK）文件夾中或在IIS Resource Kit/Utility/ADSI Admin Scripts文件夾（如果你安裝了IIS 4.0 Resource Kit）中。這些.vbs腳本使用了一個ADSI命令，它是專門為創建元數據備份而提供的。
問： 什么工具能幫助我施加一個負載并進行應用程序的強度測試？
答： 有許多工具可以用來實現這個目的。而且有一些功能完備并且十分有用的你將會發現有相當多的可利用的商業工具可供您利用被完全裝備了，并且這些工具是有很用的。Microsoft提供了Web Application Stress Tool，在大多數情況下，對于裝載在Web服務器上施加負載來說，并檢查它在一定壓力下是否能夠正常工作這一目的當進行應用程序強度測試時，查看它們的執行情況，這個工具是足夠用的。預先執行測試是一個好主意，因為在應用程序的設計過程中，問題并不會顯現出來，除非在這個服務器上施加一定負載被加載了--而且在一個產品成品服務器上你肯定不希望發現任何問題。
Web Application Stress Tool有幾個有用的特性，它可以將您包括當你在通過Web站點中進行的指向并和點擊操作記錄為一個可重新回放的腳本路線時記錄重放腳本的能力。然后當你遠程監視服務器上的性能監視計數器時，就能同步地在一個或多個客戶端上重新播放這個腳本。另外，你還能指定詳細資料，如用于測試驗證身份驗證吞吐量所使用的用戶賬號，以及顯示請求和測試計劃日程之間的延遲。
當你在你安裝了Web Application Stress Tool的時時候，它還在計算機上安裝了一個服務，叫名為做“WebTool”的服務。如果你確信當不再需要這個工具時，您可以卸載Web Application Stress Tool。
問： 當Localstart.asp返回了一個“正在創建中”響應時，發生了什么事情？
答： 這個“正在創建中”頁面應該出現在從一個遠程的IP地址對默認的Web站點進行訪問的時候。如果你從一個內部的IP地址訪問，IIS在線文檔就會被顯示。如果你在Internet Explorer中訪問http://localhost，并且未安裝Default.htm或Default.asp，則Web站點將會運行IISStart.asp。IISStart.asp將檢查下面兩個條件：
你是否已經敲入輸入了“localhost”。
客戶端的IP地址是否與服務器端IP地址相匹配。
在任一種情況下，你都將會被重定向到Localstart.asp，然后打開所需要的頁面。
確定這些文件在你的系統上是存在的，并且在“文檔”選項卡標簽中調用的是IISStart.asp。為了確定這些，你可以嘗試寫一段簡短的.asp網頁，來顯示服務器變量的值，如下：
Your local IP address is 207.46.249.190
The client IP address is 210.82.106.28
如果IP地址沒有被識別，則可能是因為Localstart.asp頁未被調用。當然，你總是可以通過直接使用http://localhost/localstart.asp來調用它。如果沒有配置默認文檔，在直接調用Localstart.asp時就可能出現問題。腳本將返回下述消息：
目前當前，你沒有為用戶設置一個默認文檔。當前所有試圖連接到這個站點的用戶都將收到一個“正在創建中”的頁面。
問： 能在Microsoft Windows XP Home Edition中安裝IIS或PWS嗎？
答： Windows XP Home Edition不支持任何版本的IIS，沒有任何可靠的方法能使其運行IIS。Windows XP Home Edition并未設計成一個Web應用程序的開發平臺。在升級到Windows XP Professional后，你就可以在系統上安裝IIS 5.1，以便利用ASP.Net進行開發工作。在Windows XP Professional上的IIS 5.1是一個全功能的Web服務器端，但是它只能建立10個并發連接，這是因為它只是一個工作站操作系統而不是服務器平臺。Windows XP Home Edition還有一些與Windows XP Professional相同的其它限制，因為它也是一個工作站操作系統而不是服務器操作系統。大體上，你會發現，在Windows 2000 Professional和Windows 2000 Server或Advanced Server上的IIS 5.0中，這些差別是相類似的。無論怎樣，對于使用.NET Framework來開發基于Web 的應用程序來說，Windows XP Professional才是一個優秀的環境。
問： ISAPI篩選器能在一個單獨的進程空間中運行嗎？
答： 為與Web服務器協同工作所開發的應用程序都有著特殊的要求。例如，你不能從一個URL中調用一個Notepad.exe實例并且希望在客戶端的系統上看到一個記事本窗口。為了從IIS中與請求進行交互（并不是CGI），程序必須使用ISAPI編寫。ISAPI是Internet服務器應用程序接口（Internet Server Application Programming Interface）的縮寫。有兩種可執行的ISAPI：擴展和篩選器。
可以從一個URL中直接調用ISAPI擴展，如http://localhost/myisapi.dll。假設你已經在目錄上配置了IIS，允許腳本和可執行程序，并且用戶有執行NTFS的許可權限，則dll將會運行。IIS允許你指定應用程序是在進程內（作為Inetinfo部分）運行還是在進程外（作為IIS 4.0上的MTX部分，或者作為IIS 5.x部分的dllhost）運行。當一個應用程序在進程外運行時，Inetinfo就從問題中被隔離出來。如果應用程序出現故障，Web服務器也會出現故障。
ISAPI篩選器又是另一個內容。ISAPI篩選器能改變進入或離開IIS的數據流。因此，ISAPI篩選器有著非常強大的功能，能用來實現客戶日志、驗證或更改數據流。對IIS 5.0來說，在ISAPI篩選器中實現的特性包括數據壓縮、摘要驗證和URLScan。
因為篩選器在IIS中扮演了一個如此重要的角色，所以它們總是作為Inetinfo部分運行在過程內。因此，正確的ISAPI篩選器結構對服務器的正常運行是必備的。你可能希望與Microsoft 產品支持服務一起工作來確定問題，因為處理這種例外可能是一個較大的挑戰。
基于這個考慮，有兩個新技術可以使生活更加輕松，IIS 6.0就是其中的一個。由于它是一個新的體系結構，所有的ISAPI篩選器都在進程外運行。這將使Web 服務器從一個捉摸不定ISAPI篩選器中隔離開來，但這實際上并沒有真正解決問題。為了解決這個問題，你可以考試使用.NET語言在ISAPI方面做一些工作。通使用C＋＋設計ISAPI篩選器相比，使用.NET實現相同的功能要大為簡單。
問： 我在哪能獲得這樣的示例代碼--它顯示了如何在使用WebDAV的ASP中編輯文檔？
答： 從IIS上的腳本中使用WebDAV的最好方法就是使用ASP.Net的WebClient類。如果你正在使用Windows XP或Windows Server 2003，WebDAV功能就是這個操作系統的一部分。這就允許你在一個Web服務器上使用HTTP引用一個文件，就像使用一個UNC路徑名稱一樣。例如，你可以用NET USE * http://servername/directory來映射一個驅動器，然后通過使用驅動器符號來訪問這個位置。另一方面，你還可以創建一個COM對象，它是一個WebDAV的客戶端。你可以使用這個對象向IIS 5.x或IIS 6.0傳遞WebDAV動詞。
另外，如果你以WebDAV為關鍵詞搜索MSDN，你將會找到一些例子，它們教你如何使用XML來為Exchange和其它Microsoft服務器構造WebDAV的查詢。在Microsoft Exchange 2000 Server SDK中有一個WebDAV的示例應用程序。
問： 當我試圖用ASP去訪問一個數據庫時，我得到了一個“拒絕訪問”的回應，這是什么原因？
答： 有一個名為“Filemon”的優秀免費工具，你可以從Sysinternals.com上獲得它。你可以使用Filemon來快速診斷出絕大多數的權限問題，因為它能實時顯示服務器上的全部文件權限、調用的過程名稱及訪問的結果。因此，無論隱藏多么深的嵌套包含或多么模糊的臨時索引，任何“拒絕訪問”的消息都能被輕松識別。
當一個在先前的操作系統上能夠正常工作的應用程序在升級后出現問題時，它就無能為力了。但是，這種類型的問題還是有啟發意義的。IIS 4.0和IIS 5.0之間的一個差異就與COM和COM+之間的一個差異有關系。在IIS 5.0中，當一個COM+對象代表用戶訪問文件時，它的默認行為就是使用用戶的安全上下文環境來完成這些工作。這在IIS 4.0中并不算什么事情。因此，當從IIS 4.0向IIS 5.0遷移包含COM的應用程序時，你可能需要向文件提供用戶權限，而在IIS 4.0中并不需要。雖然跟以前相比這有些不方便，但是它在提高應用程序安全性設計方面的確是一個進步。即使是不能使用定制的COM對象去訪問數據庫，COM在本地的IIS組件中還是得到了廣泛的應用。
這里有一個能夠幫助您理解這種需求的例子，比如，你需要為正在創建數據庫的用戶授予請求使用Access臨時文件夾的權限。更多的信息請查閱Microsoft Knowledge Base中的Q210457和Q271071。
問： 如何在沒有恢復原始設置的情況下運行IIS鎖定工具？
答： IIS鎖定工具非常有效。這個工具允許你輕松、顯著地增加服務器的安全性。一旦運行了這個工具，它就將其活動的歷史記錄儲存到一個文件中，這個文件的位置是%systemdrive%\%systemdir%\system32\inetsrv。你將在下面的文件中找到這個信息：
Oblt-rep.log
Oblt-once.md0
Oblt-mb.md0
Oblt-undone.log也可能是最新的。
如果你刪除了這些文件，向導就會啟動，就好像IIS Lockdown tool并未被運行一樣。重復這個過程并沒有什么風險。在你這么做之前，一定要制作一個Metabase.bin的副本。
因為當它第一次運行的時候，這個過程將會讓你運行鎖定工具，就好像它從未被運行過，但并不會“解開”或反轉鎖定工具進行了一些設置，所以這個過程應該可以正常工作。
問： 在我的intranet環境中，如何處理“server-side include”語法，而不必重新命名所有的文件？
答： IIS 4.0和IIS 5.0提供了這樣一個選項，它不需要你更改所有文件的擴展名。ASP處理器也能處理服務器端的include語法，因此沒有必要使用.stm或者是.asp擴展名。那么，這對你又有什么幫助呢？通過在應用程序配置中創建一個條目，你可以將.htm 文件映射為由asp.dll處理，這樣，哪些帶有.htm擴展名的文件就將由asp.dll來處理。通過使用這種方式，那些含有includes的.htm 文件不用重命名就能被處理。現在你可能在考慮：“這會不會導致我所有的.htm文件都像腳本一樣被處理，從而降低系統的性能呢？”事實上，在IIS 4.0中，這的確是一個問題；但是，在IIS 5.0中，性能問題并不像你想象中的那么大，并且在IIS 5.1中，甚至會更好。IIS 5.0有一個特性叫做“Scriptless ASP”（無腳本ASP）用來處理這個特殊的問題。如果一個不包含腳本的文件被提交到ASP處理器，它就不會被解析，只是簡單地作為靜態頁面發送出去--在這種特定的情況中是一個有用的特性。
問： 在Windows 2000 Professional中，我怎樣做才能讓域用戶來管理虛擬目錄，以便域用戶能夠創建和管理他們自己的虛擬目錄？
答： 你需要做的最后事情就是將域用戶加入到Power Users組中，因為這樣就可以為域中任何一個擁有用戶帳號的人賦予經過提升的權限。如果你信任域中的每一個成員都可以對系統進行很好的管理，這樣做不會有什么問題，但是對于大多數計算機用戶來說，這樣的信任級別是不合適的。
為了在IIS中創建一個虛擬目錄，用戶需要有管理員權限。之所以這樣設計，是因為任何能在Web站點上創建虛擬目錄的人也能對虛擬目錄進行刪除、重命名、重定向或其它管理工作。
認識到這點后，你可能希望不為用戶提供管理員身份就能獲得類似的權力，在IIS插件中有一個特性（“操作員”標簽），能讓你指定一個Web站點操作員（不是管理員），為Web站點創建虛擬目錄。這個特性只有在Windows 2000 Server、Windows 2000 Advanced Server和Windows 2000 Datacenter Server中是可用的。相同的特性也可應用于IIS 4.0。
另外，你還可以在IIS Web站點內部創建一個虛擬目錄，并將它映射到%systemroot%\%systemdir%\inetsrv\iisadmin。你應該保護這個虛擬目錄的安全，否則那些訪問這個站點的人就能夠管理這個Web站點。還要注意，這只有在Windows 2000 Server，Windows 2000 Advanced Server，和Windows 2000 Datacenter Server (以及IIS 4.0)上面是可行的。
當你發現你自己根據操作系統的限制將擴展權限授予了其他人或別的工作組，并且試圖將你的工作站當作服務器時，你可能需要安裝一個服務器操作系統。
問： 在Windows 2000 Server上，當一個站點需要SSL時，我怎樣才能在相同的站點上使用主機頭？
答： 讓我們回顧一下SSL和主機頭的問題，因為對IIS來說，它的問題一直在常見問題解答的頭五個中。
當客戶發出一個到IIS服務器的HTTP連接請求時，這個客戶的請求包括一個叫做HOST:的字段，它包括了URL中的Web服務器請求。例如，如果你的請求將http://www.microsoft.com作為目的地，則瀏覽器將其發送到服務器，并一同提交HTTP頭中的其它信息，HOST: http://www.microsoft.com。因為此字段的名稱是“HOST”，并且它在客戶的HTTP頭中，所以我們把它稱作“主機頭”。
如果客戶請求建立一個SSL連接，主機頭字段仍然會包括在請求當中，只不過它被包含在這個包的加密部分里（在應用層中），因此Web服務器無法對其進行解密，以確定應該將請求發送到哪一個Web站點。
這就產生了一條定律：當使用SSL時，不能使用主機頭來作為識別一個Web站點的主要手段。
如果你確實想使用帶有主機頭的SSL，那么會發生什么情況呢？考慮一下這個情況。你有兩個Web站點，其中一個不使用主機頭，另一個則使用。兩個站點都使用相同的IP地址，并且都配置成使用證書。當你利用SSL訪問使用主機頭的站點時，第一個Web站點會對此做出響應。之所以發生這種情況是因為：我們使用IP地址來識別你希望用來建立連接的站點，而不是主機頭。因為第一個站點對IP地址和HTTPS有反應，所以它接受了請求。如果第一個Web站點需要主機頭，并且在不同的IP地址上，或者沒有證書，那么連接將會失敗。
因此，請考慮你的配置，在你需要SSL的相同站點上，只要不使用主機頭，你就可以做任何想做的事情。
