經過幾天的反復測試，終於完成了ADS部署XP的試驗。看來不經過反復的失敗、試驗是無法從勝利中得到技術和知識積累的。
ADS原則上是不支持桌面操作系統的，因為ADS控制客戶端必須依靠ADS代理，而進入ADS代理環境有兩種方式，第一種是在Windows 2000服務器版和Windows Server 2003上安裝代理程序，而此程序只支持有限的系統版本；另一種是使用PXE引導至ADS的代理環境。從以上所述可以看出要想真正的實現全自動化部署，ADS代理占著至關重要的地位。
經過多次的試驗，XP的全自動化部署還是可行的。重點在於選擇正確的部署順序，並修改執行任務腳本。在這次的試驗中，我的方法如下：
1、安裝XP原型機，做系統准備工作，生成全自動化mini安裝應答文件，並修改相應的變量，最後手工執行sysprep及其必須的參數；
2、在ADS服務器中添加此設備，修改默認任務為boot-to-da，添加此設備對應的變量並授予控制；
3、開啟原型機，檢查其是否順利進入代理環境並進入預備狀態；
4、創建新的Capture-Image任務腳本，其任務順序是：捕獲系統映像（或其他分區映像）—> 修改原型機的sysprep.inf（因為原型機上的sysprep.inf包含ADS變量，當重新啟動後會無法正確執行自動化mini安裝，所以要將變量修改為實際值）—> 將原型機默認任務修改為boot-to-hd —> reboot ；
注：此步驟雖然按照自動化理念執行，但是當原型機重新進入系統後，ADS的控制便會出現錯誤，首先表現在任務執行最後一步reboot無反饋，導致任務一直在執行狀態，這時候你需要手工停止任務。原因很簡單原型機上未安裝ADS代理，曾經嘗試在任務腳本最後添加adsdevice /rc ，但是發現在代理環境下不允許執行此命令，所以最終還是要手工將其釋放控制。不過，我感覺最後的reboot可以更換為shutdown，這樣原型機關閉電源後，ADS設備中就可以正常釋放控制，否則你會發現原型機重新啟動後，ADS設備管理中你無法釋放控制。
5、在ADS設備中添加要部署的客戶端設備，修改默認任務為boot-to-da，添加此設備對應的變量並授予控制；
6、開啟此客戶端，檢查其是否順利進入代理環境並進入預備狀態；
7、創建新的Deploy-Image任務腳本，其任務順序是：對客戶分區（如果存在多個分區，你可以添加多條分區指令）—> 部署映像（如果要部署多分區映像，可添加多條指令） —> 修改目標客戶端上的sysprep.inf —> 將原型機默認任務修改為boot-to-hd —> reboot ；
至此ADS部署XP就算完成，如果客戶端支持網卡遠程啟動，那麼就實現了真正意義上的全自動化。多麼希望ADS代理支持XP或者2000PRO，曾試著解包代理程序去掉系統版本驗證，可惜對這些確實不精通無奈放棄，希望其他朋友能有能力修改代理程序使其支持桌面版系統。
在此次的試驗中我大概算了一下時間，捕獲和部署映像的耗時差不多，在PIV2.4G/128M的虛擬機中，各需10多分鐘，而這個時間還只是捕獲純系統映像，如果系統安裝有應用軟件，或包含其他分區映像捕獲需要的時候可能更長。而Ghost單機克隆時，只需要3分多鐘，但是ADS的優勢還是顯而易見的。
接下來我將找一個實際的環境進行大規模部署測試，希望能拿到一個實際數據來對比Ghost網播。
