對于IIS服務器來說，唯一標識一個網站的不是網站的名稱，而是網站的ID數值。當我們在IIS 5.0和IIS 4.0中創建一個新的網站，Web服務器將下一個可用的數字順序號指定給網站（即，Web服務器給默認站點指定的數字是1，下一個網站是2，接下來是2、3、4，等等），這個數字就是網站的唯一ID。如果要訪問一個網站的日志文件，首先必須知道該網站的ID，因為日志文件保存在/W3SVC/<網站的ID編號>目錄。如果Web服務器上運行著一個以上的網站，僅僅依靠日志文件的路徑名稱根本無法判斷哪一個日志目錄屬于哪一個網站。另外，無論是在編寫管理腳本時，還是在修改配置數據文件時，網站ID都是必不可少的，例如，在IIS配置數據文件中指定ADSI（活動目錄服務接口，Active Directory Service Interface）路徑時往往要指定正確的網站ID。

　　盡管如此，在IIS 5.0和IIS 4.0中，從IIS管理器無法直接找到網站的ID編號。為此，IIS 6.0的管理器在網站清單中增加了一個新的“標識符”列，該列的內容就是網站的ID編號。不過，即使IIS 6.0 Web服務器上只有二三個網站，網站的ID也可能很大，例如387660891（因此該網站的日志文件路徑是/W3SVC/387660891），不必奇怪，IIS 6.0不再按照順序指定網站的ID了――它根據網站的名字計算出網站的ID。

　　如果你編寫了一些腳本程序輔助管理，這些腳本要求使用原有的網站ID順序生成方式，可以禁用IIS 6.0新式的ID生成方式，具體的操作步驟是：找到HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/InetMgr/Parameters注冊子鍵，創建一個REG_DWORD值IncrementalSiteIDCreation，將它設置為2（注意，默認情況下，該鍵不存在）。

　　七、異步CGI處理

　　IIS 5.0和IIS 4.0以同步方式運行CGI（Common Gateway Interface，通用網關接口）進程，這實際上意味著每次只有一個線程能夠訪問一個CGI進程，所以IIS 5.0和IIS 4.0對CGI支持的可伸縮性不佳。IIS 6.0能夠異步運行CGI進程，所以如果一個線程調用了一個CGI應用程序，它不必再等待CGI進程處理完畢和返回信息。異步CGI改善了IIS服務器運行CGI Web應用程序的性能，使得IIS能夠運行更多執行關鍵任務的基于CGI的應用程序。

　　當Web服務器接收到包含CGI程序名和程序所需參數的URL時，CGI程序開始執行。如果將CGI程序編譯為可執行 （.exe）文件，則必須提供包含程序執行權限的目錄，以便用戶可以運行程序。如果CGI程序以腳本形式（例如Perl腳本）編寫，則既可為目錄提供執行權限，也可為其提供腳本權限。另外，如果要使用腳本權限，必須將腳本解釋程序標記為腳本引擎。

　　必須注意的是，默認情況下，IIS_WPG組不具備啟動CGI進程的權限。如果創建了新帳戶并將其添加到IIS_WPG組，還必須授予此帳戶兩種啟動CGI進程的用戶權限，即“調整進程的內存配額”和“替換進程級令牌”。

　　八、帶寬限制

　　在IIS 5.0和IIS 4.0中，Web網站屬性對話框的“性能”頁允許啟用帶寬限制功能，指定允許網站占用的最大帶寬。不過，這個功能不一定起作用，因為IIS 5.0和IIS 4.0不能直接操作服務器的網卡。

　　IIS 6.0則不同，第一次啟用帶寬限制功能時，Windows 2003自動安裝QoS數據包計劃程序供IIS服務器調用。QoS數據包計劃程序使得服務器能夠控制服務質量（即QoS），因此安裝期間Windows 2003將臨時地停止所有網絡服務。配置好QoS數據包計劃程序后，IIS才真正有了擔負起控制網站帶寬限制所需的驅動程序――對于ISP來說，這無疑是一個好消息。允許設置的最小帶寬限制值是1024 Byte/秒。不要忘了檢查一下網卡是否在windows 2003硬件兼容清單（HCL）中，因為只有最新的網卡才支持QoS功能。