桌面檔案自訂 Windows 部署服務

Wes Miller

目錄

汰舊換新
分析堆疊
網路開機程式
WDS PXE 提供者
TFTP 精靈
開機設定資料存放區
Windows PE
傳輸伺服器
自訂多點傳送
總結

話說三個月以來，我一直都在探究 Windows 部署服務 (WDS) — 它的起源，接著是概觀，再接下來是深入探討一些像是 WDSUtil 和多點傳送的進階主題。在本系列的最後一篇，我們將討論您可以在何處以及如何自訂和設定 WDS，來滿足貴公司的需要。Microsoft 工具的設計多半具備一定程度的可設定性。但總是得等到實際運用之後，才知道這些工具是否符合您的需求，還是需要做一些調整 (往往都是如此) 才能在您的案例下運作。

汰舊換新

最近我常常被讀者問到：「我有 x (現有的部署技術)，WDS 對我來說適用嗎？它有類似於 x 的同等功能嗎？」。隨著反對自動部署服務 (ADS) 的聲浪高漲，特別令人感興趣的一個話題是「我要如何執行高容量快速部署或伺服器的重新佈建，WDS 可以幫我做到這點嗎？」。

WDS 的設計並不是要完全對等的方式來取代 ADS，事實上，真要取代，它還缺乏一些主要元件呢，不過稍微下點功夫，您就可以讓 WDS 接下 ADS 的崗位。同樣地，若是 WDS 某些層面的現狀對您來說不適用，您會發現它的許多元件都可以替換 — 複雜度和工程設計的程度不等。讓我們來討論一下透過 WDS 進行部署，並分析您可能想要自訂的部分，還有您要怎麼辦到。

分析堆疊

[圖 1] 顯示了 WDS 部署程序中的元件。當中每個步驟都可以進行某種程度的自訂。我用顏色來標示每個步驟，藉此反映我認為進行取代或自訂的複雜度 (一般是指程式開發技能)。藍色的顏色越深，表示要自訂該步驟的困難度越高。

[圖 1] 自訂 WDS 的複雜度

當然，自訂每個步驟的困難度，實際上要看團隊的技能 (程式開發或編寫指令碼)，以及您對 WDS、Windows Imaging 格式 (WIM)、Active Directory 或任何其他想要整合的技術 (例如 SQL 或 ADSI) 的了解而定。讓我們分析一下各個步驟，思考您想要自訂它們的方式，以及採納的方法。

網路開機程式

您應該不太可能需要建立自訂網路開機程式 (NBP) 來取代 WDS 所提供的網路開機程式，不過要做的話，還是可行。WDS 包含的 NBP 可與無周邊系統 (一般是伺服器) 或是可能不提示 F12 的系統等搭配使用。這些 NBP 可以使用 WDSUtil 預備接移到 Active Directory，或者您可以為所有未預備的系統 (例如，您所有的系統都是無周邊，或者您永遠不想提示 F12 的話)，以您想要用的 NBP 來取代 Startom.com。

不幸的是，有關建立自己的 NBP 方面的說明文件不多 (如需詳細資訊，請參閱 msdn.microsoft.com/library/bb870970.aspx)。NBP 是非常小型 16 位元可執行檔，除了限制非常嚴苛之外，還需要特定的程式設計技能。除非您想要滿足非常特殊的需求，而且您的開發團隊具備適當技能，否則我通常建議使用 WDS 提供的現有 NBP。

WDS PXE 提供者

我們從客戶身上常收到關於遠端安裝服務 (RIS) 的意見反映是，他們想要使用 Active Directory 以外的資料存放區來存放用戶端系統資源 — 而且通常希望是 SQL Server。而 WDS 的設計為開機前執行環境 (PXE) 提供者包含了隨插即用的基礎結構。 這表示花一些程式開發的功夫，您就可以使用 Active Directory 以外的其他備份存放區來存放 PXE 資訊。

WDS 隨附使用 Active Directory 的提供者，System Center Configuration Manager (SCCM) 現在也會連接到 WDS，並實作它自己的提供者。有關撰寫您自己的提供者的說明文件少之又少，而且也沒有多少範例程式碼可用 (不過 Windows SDK 倒是提供一些說明文件和幾個範例)，所以這項工作沒有意志力的人可做不來。除非您在開機程序這方面有非常特定的需求，否則我還是建議不要嘗試自訂 PXE 提供者。

TFTP 精靈

在 WDS 問世之前，不時有客戶投資自己的 Trivial File Transfer Protocol Daemon (TFTPD)。既然 PXE 伺服器彼此會衝突，這往往表示得將就於一部 PXE 伺服器。

據我的經驗，這通常是指拿現有 (一般是 Linux 架構) 的 TFTPD，然後哄騙它啟動其他 OS。就 RIS 所採用的原始基礎架構，您無法這麼做。但是當 RAMDisk 開機成為家常便飯時就另當別論了，而且還是可以使用以 WDS 為主的開機映像來進行。

要特別注意的是，您正踏入 Microsoft 在技術上不支援的地帶，而且肯定可能產生難以診斷的問題。再者，不用 WDS 中增強的 TFTPD，您也等於是白白錯過了效能提升的好處。在理想的情況下，我建議使用現有的 WDS TFTPD，然後嘗試使用 PXE 逾時、預備和/或網路邊緣來定義要從 PXE 伺服器啟動哪個用戶端，而不要試圖對現有的伺服器東改西改。

開機設定資料存放區

使用 RIS 時，要在開機層級指定應該啟動什麼，向來是不可能的 — 您總是得經歷過 OS 選取程式，然後選取一個選項 (無論是安裝程式、Windows PE (Windows 預先安裝環境)，或其他完全不同的選項)。因為 WDS 是使用完整的載入器進行網路開機，所以它也支援提供自訂開機設定資料 (BCD) 存放區給用戶端。每個架構的預設 BCD 都位於 RemoteInstall\Boot\<arch>\Default.bcd 下，這裡的 <arch> 是要開機之系統的特定架構。

您可以針對每個用戶端自訂這個 BCD，而用戶端可以用它來開機。比方說，您可以設定一個 BCD 項目用於啟動安裝程式，設定另一個用來執行 Windows 修復環境 (WinRE)，再設定一個用於執行記憶體測試 — 或者您可以把完全自動化的安裝程式項目作為預設值，然後把手動方式 (或自訂安裝經歷) 作為使用者可選擇的選項 (如需詳細資訊，請前往＜如何使用 Bcdedit 修改 BCD 存放區＞(英文)，網址是 go.microsoft.com/fwlink/?LinkId=115267)。

想也知道，大部分的 WDS 粗活都是發生在 Windows PE 中 — 所以調整 Windows PE 以符合您的需要，可說是自訂經歷當中關鍵的焦點區。WDS 預設會提供一個非常標準的範本來進行安裝，當中包括了完整安裝經歷。根據您的部署需要，這種方式對您來說有時候可能不適用。在這種情況下，您可以建立自己的 Windows PE 開機映像。就讓我們從頭開始吧。

除了使用 BCD 來指明要使用哪個映像之外，您也可以透過在 Active Directory 中為電腦自訂電腦帳戶物件 (MAO) 的方式來指定映像。在 RIS 中，每個項目都會儲存一個特定的 MAO 屬性 (要使用哪個 Startrom 和 Unattend — SIF — 檔案)。而在 WDS 中，這些是在 netBootMirrorDataFile 項目下儲存成名稱值組。例如，特定電腦要使用的開機映像和 Unattend 檔案便是儲存在這個項目中。項目的形式類似以分號分隔的名稱值組清單。用來修改開機映像和 Unattend 檔案的項目分別是 BootImage 和 UnattendFilePath。

當然啦，您可能會發現您想要完全捨棄現有的安裝經歷，直接建置自己的安裝經歷。或許是您需要更高的可設定性、更多自動化，或是由 SQL Server 自動化的組建。您可能想要效法早期一些客戶對 RIS 和 Windows PE 所做的，建置您自己的前端來進行安裝。但是無論您編寫的安裝經歷為何，都必須完成下列主要工作：

• 找出每台電腦或每個使用者的任何資訊。舉例來說，這項資訊可從使用者輸入，從 SQL Server，或從文字檔中取得。
• 複製和套用安裝映像到用戶端系統。這項工作可直接使用安裝程式來完成，使用 ImageX 來套用網路共用的映像，或是透過多點傳送 (只要複製該映像，然後透過 ImageX 來套用它就行了)。
• 提供 Unattend 檔案 (例如 Unattend.xml 或 sysprep.inf，視要部署的 Windows 版本而定)，以便完成安裝程式。
• 自動化您想要執行的任何安裝後移轉步驟 (或是在 Windows Server 2008 的情況下要套用角色的任何步驟)。

ADS 介紹了工作順序的概念，允許將可重複的步驟指定到一或多部電腦。由於 ADS 的設計並不是要與 Windows XP 搭配使用，也不支援這麼做，因此您無法用它來部署該 OS。但是 ADS 工作順序其實不過是結構化的指令碼，因此您可以使用自訂安裝程序來執行相同的步驟。

我愛用 Microsoft SQL Server 已有一段時間 (自 SQL Server 6.5 版開始)，所以我的直覺是使用 SQL 來建置這樣的結構。當然啦，您必須在 Windows PE 的組建中加入 SQL 功能來進行這項作業。此外，您還可以撰寫自己的 GUI — HTML 應用程式 (HTA) 或已編譯的可執行檔 — 或是使用 Windows Script Host (WSH) 來執行極簡的僅命令列安裝經歷。HTA 或 WSH 也必須加入 Windows PE 中才能提供使用。

設計您自己的安裝經歷時，複雜程度完全要看您的技能和想像力而定。我就看過光是使用 SQL 和 WSH 或 HTA — 這是很容易上手的技能 — 也能定義出相當高雅的系統。不過，謹記我在前一篇專欄提到的限制是很重要的：

• Windows PE 的特色是無 Windows on Windows (WOW) 子系統，所以您必須針對打算支援的架構各編譯一次。
• 如果您需要透過 x64 或 IA64 Windows PE 部署，就無法使用 Visual Basic 6.0。
• 您可以使用 Visual Studio 2005 或 2008 來建置應用程式，但是必須建置 Unmanaged Visual C++ 應用程式，因為 Windows PE 上不支援任何 Microsoft .NET Framework 版本。
• 在沒有 .NET Framework 的情況下，您也無法使用 Windows PowerShell 進行自動化。

如果您願意撰寫自己的安裝經歷，當然也可以透過 WDS 使用協力廠商映像處理公用程式。雖然我認為 WIM 格式和 ImageX 可以滿足大部分的部署案例需求，但您現有的映像處理工具可能可以滿足您特定的需求。

同樣地，特定的案例可能需要自訂磁碟分割 — 您可能是部署含 BitLocker 的 Windows Vista，或是建置 Windows XP 系統，並且把設定檔資料存放在第二個磁碟區上，又或許您部署的是 Windows Server 系統，並且想要在相同的磁碟上建立不同的磁碟區供記錄之用。這些任務都需要自動化 DiskPart，就跟在舊版一樣，方法是將內含您想要執行的命令且以結束善終 (藉以結束 DiskPart) 的指令碼 (任何檔案格式) 提供給 DiskPart。

要建立您自己的安裝經歷，膽小者勿試，因為您基本上是重建安裝執行檔 (或至少是對應它的功能)，而且設計和建置的工作可能蠻吃重的。但最重要的是，您想要內建多少預設功能，還有您建置的基礎為何 (HTA 或 WSH，或是編譯的程式設計語言)。

傳輸伺服器

如果您沒有使用 WDS 大部分的現成功能 (例如 Active Directory)，或是正在設計您自己的完整自訂解決方案，傳輸伺服器可能可以滿足您的需要，而且不會產生您不要的需求。[圖 2] 中的表格 (複製自 go.microsoft.com/fwlink/?LinkID=115298 的＜使用傳輸伺服器＞(英文)) 說明 WDS Transport Server role 內含的項目。

[圖 2] 部署伺服器與傳輸伺服器比較

我說傳輸伺服器實作起來很複雜，並不是指角色本身，那其實部署起來很容易 (見 [圖 3])。費功夫的地方出在以傳輸伺服器為中心自訂安裝實作。而使用 Transport server role 等於是把作為角色內建 WDS 所提供的使用便利性幾乎剝奪掉了。

[圖 3] 傳輸伺服器可能對自訂部署案例非常實用 (按一下以放大影像)

自訂多點傳送

無論您是否正在使用 Transport server role — 特別是如果您有使用的話 — 若是您正在進行多系統部署，利用多點傳送可達到不錯的成效。ADS 有個非常強大的多點傳送功能，您使用 WDS 搭配多點傳送就能摹造這項功能。WDS 自己也有多點傳送功能，但若是您正在建置自己的自訂解決方案，可以使用 WDSMCast 來運用多點傳送，這點我在上個月曾提到 (見 [圖 4])。請記住，您必須傳輸要部署的映像檔，而且必須套用它們。一般來說，這表示您需要有足夠的本機磁碟空間來存放和套用映像。

[圖 4] 執行 WDSMCast (按一下以放大影像)

總結

WDS 本身具備相當的威力 — 足以滿足許多公司的需求。但若是您期望建置自己的解決方案，超越 WDS 的界線，您肯定可以這麼做 — 限制您的只有自己的想像力、時間表和技能。

Wes Miller 在位於德州奧斯汀的 CoreTrace (CoreTrace.com) 擔任資深技術產品經理。他之前任職於 Winternals Software，並且曾在 Microsoft 擔任專案經理一職。您可以透過電子郵件與 Wes 聯絡：technet@getwired.com。