COM+的新功能之一就是Object Pooling（對象緩沖），該技術允許對象創建在緩沖池中以便重用對象，它減少了例示對象所花費的總時間。Windows NT4中不包含該技術，可以在通過Component Services將基于VB或VC組件添加COM+應用的時候試驗該技術。你會發現基于VB的組件是不能使用該技術的，而任何基于VC的組件可以使用該技術。
Visual Basic 組件不能被緩沖是因為它們是單元線程的（apartment threaded），而對象緩沖技術要求組件必須能夠運行在Neutral-threaded或者是Multithreased-apartment(MTA-多線程單元)。
Visual C++創建的組件可以被標記為Both-threaded,這意味著它們運行在MTA的模式下，因此符合對象緩沖的線程要求。但是，如果組件創建為MTS組件，它們就不能支持對象緩沖。對象緩沖技術需要組件支持聚合，而MTS要求組件不支持聚合。事實上使用ATL創建MTS的時候，在組件的頭文件中就放置了防止組件聚合的宏（Marco）。
DECLARE_NOT_AGGREGATABLE(CComponent)
對象緩沖技術的另一個要求是任何由組件分配的資源必須由組件處理（組件不維護客戶端狀態），這意味著附加的工作以確保組件被Windows 2000定義為可緩沖。你可能要做些工作才能使Visual C++的組件使用對象緩沖技術，而就不用考慮如何讓Visual Basic組件使用該技術了，至少目前如此。
不管怎么說，你的組件仍舊擁有在NT4下的功能，這才是我們將組件和相關的ASP應用遷移Windows 2000最關心的。
一旦設置好ASP開發環境并遷移成功ASP組件和MTS包，就該開始進行單元測試階段。現在讓我們看看Windows 2000中ASP本身的改變。
ASP Object Model的差異
IIS 5.0中的ASP對象模型已經發生了變化，添加一些新的方法，也改變了某些已有方法和屬性的表現。值得注意的變化是ASP緩存現在是默認的選項，而以前默認是不進行緩存。由于這個改變，所有的ASP腳本都會在頁面內容返回之前處理完畢。默認的緩存可能會影響到現有ASP應用，尤其是那些較長的數據庫查詢和時間敏感的操作。
舉例來說，可以創建一個包含200萬次循環的ASP頁面，并在循環中將循環變量設為0，顯然這段代碼毫無意義，它主要是為了能夠產生足夠長時間的進程以引起注意。然后在循環的前面和后面添加Response.Write語句。
<HTML>
<HEAD>
<BODY>
<%
Response.Write "<h3>About to perform long loop</h3>"
Dim i, j
For i = 1 To 2000000
j = 0
Next
Response.Write "<h3>Long loop is finished</h3>"
%>
</BODY>
</HTML>
先暫時關閉ASP緩存選項。操作如下：
對于站點：屬性>Home Directory>Configuration>App Options
對于虛路徑：屬性>Directory>Configuration>App Options
第一個頭會在循環結束前返回到客戶端，而第二個頭會在循環后返回（可能要花上些時候）。當重新開啟緩存選項視。循環結束前是不會返回任何內容的。
如果ASP應用涉及長數據庫查詢或其它處理，而你需要使用輸出告知客戶端正在處理，可以關閉受影響的ASP應用的緩存功能，也可以使用Response對象修改受影響的頁面使其禁止緩存，或者在執行長進程前刷新（Flush）緩存。
如果原來ASP應用已經在使用緩存，不必改變任何的代碼，多余的緩存設置并不會影響應用程序，除了會耗費些處理腳本的時間：
<% Response.Buffer = True %>
另一個可能對ASP應用產生影響的是IsConnected屬性現在會做出正確的反映而不管ASP頁面是否返回內容，而以前，如果ASP頁面不返回內容該屬性不會正常的工作。幸運的是盡管你可能在以前的應用中使用了該屬性，也可能為以前的缺陷編寫了一些代碼補救，原有的代碼仍然可以很好的工作于IIS 5.0的環境中。
IIS 5.0中的ASP添加了一些新的方法，如Server.Execute 和Server.Transfer方法，Session和Application的Collection集合的Remove，RemoveAll方法以及新的對象ASPError。使人感興趣的是，這些改進并不會對遷移應用造成影響。但是，一旦成功的遷移了應用，要校驗這些增強的選項，尤其是Server.Transfer方法。該方法會將客戶端傳遞到新的ASP頁面中而不返回瀏覽器。它同時將所有的請求（Request）信息傳遞過去，也包括了沒有完成的事務。這是諸多改進中最令人興奮的事情。
進行完單元測試以及必要的修改工作以確保ASP應用如原計劃正常工作，就可以將它們轉移到測試環境中進行兼容性測試和壓力測試。
在經受了測試環境嚴酷的考驗后，下一步也是最后一步就是將ASP應用遷移到它們真正的家中-最終生產環境。希望不要在這個時候再做什么修改了。遷移的工作完成后，打開CPU跟蹤功能跟蹤每一個遷移進來的程序，確保它們不會占用過多的CPU時間，有必要的話對那些新的應用使用CPU和帶寬扼制功能。
最后的事情就是象在Windows NT4中一樣的監視應用程序的運行狀態。
總結
本文我們提供了一個多步的進程以便創建向Windows 2000遷移的計劃。希望我們提供了足夠詳細的信息—包括設置IIS5.0、WEB安全、針對Visual Basic和Visual C++創建ASP組件開發環境、移植MTS包到COM+應用、處理ASP的不同。我們希望能夠使你在面對不同的問題時能夠清晰的認識到問題所在。
你會發現將ASP應用遷移到Windows 2000是無法抵抗的任務，你可以利用Windows 2000新的功能，而不需要花費太多的力氣，對應用本身的影響也是極小的