October 2008 October 2008
虛擬化: Windows Server 2008 中的 Hyper-V 簡介
Hyper-V 的推出使得虛擬化成為 IT 環境下陣容更加堅強的解決方案。概略認識一下當今的虛擬化市場，並了解 Hyper-V 如何改進虛擬化的易管理性、可靠性和安全性。 Rajiv Arunkundram
虛擬化: 透過 VMM 2008 管理虛擬環境
System Center Virtual Machine Manager 可提供管理虛擬基礎架構所需的整合介面。最新的版本添增了對 Windows Server 2008 Hyper-V，還有對 VMware 虛擬機器的支援。一同來探索新功能，以及大致了解如何使用 VMM 來集中化管理工作。 Edwin Yuen
虛擬化: Microsoft Application Virtualization 入門
Microsoft Application Virtualization (App-V) 可讓您將虛擬化桌上型電腦傳遞給整個公司內的用戶端系統。此舉不但簡化了系統管理，也使得員工不再受桌上型電腦的侷限。讓我們一同仔細瞭解 App-V 的運作，以及探索將它部署在貴公司的方式。 Anthony Kinney
虛擬化: 實現 Hyper-V 高可用性
將伺服器彚總到少數實體機器有許多優點，但為您的系統作規劃以使它高度可用也非常地重要。本文是使用 Windows Server 2008 容錯移轉叢集將高可用性帶入您的 Hyper-V 虛擬機器的指南。 Steven Ekren
虛擬化: 伺服器虛擬化的備份和嚴重損壞修復
虛擬化大改嚴重損壞修復的全貌。本文將介紹如何在您的嚴重損壞修復計畫當中，將 Microsoft 虛擬化平台的因素列入考量，並且將深入探討 Windows Server 2008 Hyper-V 的備份和還原選項以及考量因素。 Adam Fazio
虛擬化: 規劃虛擬基礎結構的基本工具
您的基礎結構已經準備好虛擬化了嗎？Microsoft Assessment and Planning Toolkit 這個全網路基礎結構評估工具可幫助您更加了解您的 IT 基礎結構，並判斷您的系統是否準備好升級或移轉到各種技術，包括虛擬化在內。 Jay Sauls and Baldwin Ng
Columns
編輯的話: 虛擬化世代的到來: | 讀者來信: 讀者有話直說: | 工具箱: 適合 IT 專家的新產品:
SQL 問答集: 大型交易記錄檔，何時使用修復，以及其他: 本期 Paul Randal 解答了有關備份和還原的疑問、探討記錄傳送和資料庫鏡像之間的差別，並且解釋修復功能只能作為最後手段。Paul S. Randal | 公用程式焦點: Offline Virtual Machine Servicing Tool: 離線存放的虛擬機器無法自動接收必要的更新來確保安全性與相容性，因此可能為整體 IT 環境帶來風險。一同了解免費的 Offline Virtual Machine Servicing Tool 如何協助您自動化虛擬機器的更新作業。Peter Skjøtt Larsen and Suveen Kumar Reddy Vuppala | Windows PowerShell: 設定檔的威力: 想要在為您量身打造的工作環境中使用 Windows PowerShell 嗎？Don Jones 示範如何使用設定檔來自訂 Windows PowerShell 殼層。Don Jones
嗨，Scripting Guy！: 有名的遺言: Scripting Guy 討論蘇格拉底並重溫查詢 XML 檔案的主題。不過這一次，XML 檔案的結構不再使用子節點，而是將其他屬性值設成屬性。The Microsoft Scripting Guys | 桌面檔案: 自訂 Windows 部署服務: Wes Miller 探究 Windows 部署服務，向您示範要如何自訂和設定 WDS，來滿足貴公司的需要。Wes Miller | 安全性監控: 重新認識安全性的十大不變法則，第 1 篇: 「安全性十大不變法則」發表至今已有 8 年之久，世界早已物換星移。從本月份開始，Jesper Johansson 將以三篇系列文章，從現今的角度分析這些法則，看看它們是否經得起考驗。Jesper M. Johansson
現場筆記: 高容量彩色條碼: Gavin Jancke 開發出一種使用色彩和三角形的新條碼，其資料容量遠高於傳統的黑白條碼。現在就讓我們仔細探討這些高容量的彩色條碼。Gavin Jancke | Windows 機密文件: 努力一點，而不是聰明一點: Raymond Chen 看了錯誤與失敗的扭曲關係，解釋為什麼程式設計師除了提供結果之外，吃苦也是同樣重要的一環。Raymond Chen


虛擬化
Windows Server 2008 中的 Hyper-V 簡介
Rajiv Arunkundram
綜覽：
  • 何謂虛擬化？
  • 三種虛擬化架構
  • 微核心式與整合型 Hypervisor
  • Hyper-V 的功用

目錄
伺服器虛擬化的市場
伺服器虛擬化的運作方式
虛擬化解決方案的類型
Windows Hypervisor
父磁碟分割
裝置共用架構
整合元件
Hyper-V 功能集
延展性
高可用性
安全性
易管理性
總結
最近關於虛擬化的議論紛紛，當中尤以伺服器虛擬化為甚。這是業界當中最令人雀躍的趨勢動向之一，也是在未來幾年內最有可能改變 IT 系統部署型態的發展。但伺服器虛擬化不僅會改變 IT 系統管理員和架構設計師怎麼看待伺服器和系統使用狀況，它還會對管理未來肯定會更加動態的環境所使用的程序和工具產生影響。
虛擬化存在已有一段歷史，但是技術仍處於發展階段。事實上，這個詞本身對不同的人來說仍舊代表著不同的事物。然而就廣義而言，虛擬化是指將技術堆疊的其中一層從下一層分隔開來，例如將存放裝置從伺服器分開，將 OS 從作業系統分開。分離出不同的層次能夠轉而達成彙總及提高管理性。
在概念上，虛擬化適用於存放裝置、網路、伺服器、應用程式和存取。就存放裝置和網路而言，虛擬化的目標是要彙總一組不同的裝置，以便讓總資源集區看起來和作用起來像是單一項目。比如，您可以設定一個 40TB 存放裝置解決方案，來取代一組 20 個 2TB 的存放裝置。但就其他元件來說，虛擬化的作用恰恰相反，它會幫助您讓單一系統看起來像是多部系統。其中最常見的範例是伺服器虛擬化，在這種情況下，您是在單一伺服器上主控多個 OS 執行個體和環境。
Microsoft 從幾個不同的層面著手虛擬化，透過伺服器虛擬化、應用程式虛擬化、展示虛擬化，以及桌上型電腦虛擬化的解決方案，從桌上型電腦延伸到資料中心。所有這些當中最廣為討論的是 Microsoft System Center 的管理功能。針對本文，我將把重點放在伺服器虛擬化元件，特別是 Windows Server 2008 的主要功能 Hyper-V 在動態資料中心的方程式裡所扮演的角色。

伺服器虛擬化的市場
首先，我想值得討論一下現今的大環境，以及整體市場的走向。要看您讀的是什麼樣的研究資料，有些分析師估計目前市售的所有實體伺服器中，有 5-9% 是用作為虛擬化主機。您可能會認為在每年推出超過九百萬部實體伺服器的市場裡面，這樣比例的系統為數不少。但是有件事是肯定的：潛伏的商機還有很多，因為有越來越多的客戶開始熟悉虛擬化，而且想要採用它。
採納虛擬化的場合不容忽視。企業客戶不用說是率先投入測試的早期採納者。然而，還有一些中小型企業也部署虛擬化。虛擬化的採用遍及各種類型的工作負載，從商務應用程式和管理到網路和電子郵件，無所不包。
那麼為什麼虛擬化現在這麼紅呢？因素有好幾個，其中最重要的是時機。好幾個重要的產業因素同時相輔相成，為提高虛擬化的採納度推波助瀾。這些產業因素包括移向 64 位元運算、多核心處理器，甚至是提高系統使用率的永續運算磁碟。
系統的規模越來越大，因此需要像虛擬化的技術來徹底利用系統威力。雖說核心技術 (和摩爾定律) 在產生高於系統可用的處理能力方面，一直保持遙遙領先的地位，但我們現在對環境的衝擊、電源需求和冷卻成本等議題也比較關注。
所有這些因素，加上採用虛擬化可輕易獲得的投資報酬率，共同加速大小型企業採納虛擬化的腳步。而我們 IT 專業人員可預期所有重要的相關人員會在未來的幾年繼續投資這項技術，並改進其功能。

伺服器虛擬化的運作方式
一般來說，伺服器虛擬化可讓您在單一實體裝置上安裝 (以及同時執行) 兩個或以上的 OS 環境，這些環境可能截然不同，並且具有不同的識別、應用程式堆疊等等。Hyper-V 是下一代 64 位元 Hypervisor 架構的虛擬化技術，提供可靠且可擴充的平台功能。與 System Center 結合，它還為實體和虛擬資源提供單一的整合式管理工具組。
所有這些都能夠降低成本、提高使用率、最佳化基礎結構，以及允許企業快速佈建新伺服器。為了幫助您更加了解 Hyper-V 是如何架構而成的，我想要先討論一下不同類型的虛擬化解決方案。

虛擬化解決方案的類型
伺服器虛擬化所採用的一般架構基本上有三種，如 [圖 1] 所示。主要的差異與虛擬化層和實體硬體之間的關聯息息相關。我所謂的虛擬化層是指稱為虛擬機器監視器 (VMM，請勿與 Virtual Machine Manager 相混淆) 的軟體層。正是這一層提供了建立多個隔離的執行個體共用相同基本硬體資源的能力。
[圖 1] 虛擬化的三種架構 (按一下以放大影像)
類型 2 VMM 架構是透過 Java Virtual Machines 來示範。虛擬化在此處的目標是要建立執行階段環境，讓處理序不必仰賴主機系統，即能夠在其內執行一組指令。在本例中，隔離是用於不同的處理序，它允許應用程式在不同的 OS 上執行，而不用擔心 OS 依存性。而伺服器虛擬化並不在此列。
您會發現類型 1 VMM 和混合式 VMM 可能是當今採納最廣泛的兩種方法。在混合式 VMM 的階段中，VMM 與主機 OS 並排執行，並且能夠以混合式 VMM 為基礎建立虛擬機器。混合式 VMM 的範例包括 Microsoft Virtual Server、Microsoft Virtual PC、VMware Workstation，以及 VMware Player。您應該要注意的是，雖然這類解決方案非常適合只在部分時間執行虛擬機器的用戶端案例，但 VMM 還是會增加可觀的額外負荷，因此並不適合耗用大量資源的工作負載。
在類型 1 VMM 架構中，VMM 層是直接在硬體上執行。這通常稱為 Hypervisor 層。這個架構當初是 IBM 在 1960 年代針對大型主機系統設計的，而且最近在 x86/x64 平台上透過各種解決方案提供，包括 Windows Server 2008 Hyper-V。
還有一些解決方案是在韌體內嵌入 Hypervisor。不過，這只是一種封裝選項，並不會實際改變基本的技術。
分析一下類型 1 VMM，架構 Hypervisor 解決方案基本上有兩大方法：微核心式和整合型。如 [圖 2] 所示，這兩種方法都是不折不扣的類型 1 VMM，將 Hypervisor 直接安裝在實體硬體上。
[圖 2] 架構 Hypervisor 解決方案的兩種方法 (按一下以放大影像)
整合型 Hypervisor 方法會在單一層中主控 Hypervisor/VMM，這一層也包括大部分必要的元件，例如核心、裝置驅動程式和 I/O 堆疊。這是 VMware ESX 和傳統大型主機系統等解決方案所採用的方法。
微核心式方法則是使用非常精簡的專門化 Hypervisor，只執行確保磁碟分割隔離和記憶體管理的核心工作。這一層並不包含 I/O 堆疊或裝置驅動程式。這是 Hyper-V 所採取的方法。在這種架構中，虛擬化堆疊和硬體特定的裝置驅動程式都是位在專門化的磁碟分割中，稱為父磁碟分割。

Windows Hypervisor
確保多個 OS 之間有明確的區隔，是透過建立虛擬處理器、記憶體、計時器和插斷控制器來達成的。OS 使用這些虛擬資源的方式跟使用實體資源沒什麼兩樣。
Windows Hypervisor 屬於 Hyper-V 的一部分，它執行下列工作：
  • 建立邏輯磁碟分割。
  • 管理為虛擬 OS 排程的記憶體和處理器。
  • 提供機制以利虛擬化輸入/輸出，以及在磁碟分割之間溝通。
  • 強制記憶體存取規則。
  • 強制 CPU 使用率的原則。
  • 公開簡單的程式設計介面，稱為 Hypercall。
因為採用微核心式方法的關係，Windows Hypervisor 相當的小 (大小不到 1MB)。佔用量這麼微小，有助於提高系統的整體安全性。
執行 Hyper-V 的需求之一是，您需要有配備 Intel VT 或 AMD-V 技術的 x64 系統。x64 技術可讓您存取較大的位址空間，並且支援含更多記憶體的系統，因此在單一主機系統上容許更多虛擬機器。Intel VT 和 AMD-V 是硬體輔助虛擬化解決方案，在環狀架構中提供超特權層，有助於將 Hypervisor 的執行環境與系統的其餘部分相區隔。它們也允許 Hyper-V 在沒有明顯的模擬效能償失下，執行未經修改的虛擬 OS。

父磁碟分割
Hyper-V 包含一個父磁碟分割，這基本上是具備特殊或特權存取的虛擬機器。它是唯一可直接存取硬體資源的虛擬機器。所有其他虛擬機器，亦稱為來賓磁碟分割，都必須經過父磁碟分割存取裝置。
父磁碟分割的存在相當透明化。開始安裝 Hyper-V 時，您必須做的第一件事是在實體系統上安裝 Windows Server 2008 x64 Edition。接著您必須前往伺服器管理員，啟用 Hyper-V 角色，然後重新啟動系統。系統一重新啟動後，會先載入 Windows Hypervisor，接下來堆疊的其餘部分會轉換成父磁碟分割。
父磁碟分割具有鍵盤、滑鼠、視訊顯示和其他連接到主機伺服器的裝置的擁有權。它並不能直接控制 Hypervisor 所使用的計時器和插斷控制器。
父磁碟分割包含 Windows Management Instrumentation (WMI) 提供者，使虛擬化環境各層面的管理工作更具效率，它也包含虛擬堆疊，以代表子磁碟區執行硬體相關的工作。此外，主機系統硬體所需的任何獨立硬體廠商 (IHV) 驅動程式都包含在父磁碟分割中，而針對 Windows Server 2008 x64 Edition 建立的任何驅動程式也能在父磁碟分割中運作。

裝置共用架構
Hyper-V 中創新的架構元件之一，是全新的裝置共用架構，它支援每個虛擬 OS 中的模擬和綜合裝置。裝置模擬對於支援內含針對舊一代硬體設計的裝置驅動程式的舊版 OS 相當有利。比方說，Hyper-V 包含模擬的 Intel 21140 網路介面卡，它在許多舊版 OS 發行時是稱為 DEC 21140 網路介面卡。
一般來說，裝置模擬的速度緩慢，既不容易擴充，也不好調整。但是模擬仍舊有其重要性，因為它可讓您在 Hyper-V 執行大多數的 x86 OS。由於虛擬化現在正從主要用於測試和開發的專門技術，轉型成適用於生產環境的基本技術，因此使用者也需要更佳的效能來執行更大型的工作負載。模擬裝置已不再滿足這些不斷成長的需要。
對此的替代解決方案是使用 Hyper-V 綜合裝置。綜合裝置是直接對應到實體裝置的虛擬裝置。與模擬裝置不同的是，綜合裝置並不會模擬舊式硬體。透過 Hyper-V 硬體共用模型，支援的虛擬 OS 可直接與可能沒有實體裝置的綜合裝置進行互動。這些 OS 是使用虛擬服務用戶端 (Virtual Service Client，VSC)，這在虛擬 OS 當中是以裝置驅動程式的身分運作。
VSC 並不會直接存取實體硬體，而是使用 VMBus (高速的記憶體中匯流排) 來存取父磁碟分割中的虛擬服務提供者 (Virtual Service Provider，VSP)。父磁碟分割 VSP 接著會管理對基本實體硬體的存取作業，如 [圖 3] 所示。綜合裝置的主要優點之一，就是它在 VMBus 上的綜合裝置效能更接近非虛擬化硬體裝置的效能。
[圖 3] VSC 使用 VMBus 來存取 VSP，VSP 接著會管理對基礎實體硬體的存取 (按一下以放大影像)

整合元件
Hyper-V 是為了在單一電腦上執行的不同執行個體之間提供明確界限而建置的。為了讓虛擬 OS 與主機 OS 之間進行互動，也為了針對支援的虛擬 OS 提供一些附加功能，Hyper-V 提供了整合元件。
Hyper-V 整合元件支援下列功能：
  • 時間同步處理
  • 磁碟區陰影複製服務 (VSS)
  • 活動訊號功能
  • 來賓關閉
  • 關鍵值組交換 (用來存取虛擬 OS 的登錄)
  • OS 識別
Hyper-V 功能集
不用說，虛擬化平台的運作方式越接近實體伺服器，對公司來說就越容易部署和仰賴虛擬工作負載。在我的觀點看來，您可以從四大區域查看虛擬化平台的不同功能。
現今大多數以 Hypervisor 為基礎的虛擬化解決方案，在功能性方面可說不相上下。進一步分析的話，像整體擁有成本 (TCO) 和方便使用等將是重要的區別因素。而管理解決方案將不斷投資與發展，帶我們實現動態 IT 環境的願景，除了讓基礎結構富於彈性，足以適應業務的需要之外，還有模型和原則，幫助推動自動化和管理。

延展性
使用微核心式 Hypervisor 架構的 Hyper-V，承擔的 CPU 負荷非常低，而留下充裕的空間將工作負載虛擬化。Hyper-V 透過讓虛擬機器利用強大的功能和硬體，例如多核心技術、改良的磁碟存取和更多記憶體，而提升了虛擬平台的延展性和效能。
Hyper-V 與 Windows Server 2008 其餘的功能相結合，可讓您將大多數的工作負載 — 包括 32 位元和 64 位元工作負載 — 彙總到單一系統上。而且它能夠幫助您在採納 64 位元技術與持續支援整個環境內已採用的 32 位元工作負載之間取得平衡點。
Hyper-V 要求 64 位元主機系統進行硬體輔助虛擬化，有助於確保主機系統將能夠存取大量的記憶體資源。Hyper-V 可在主機上支援多達 1TB 的記憶體，其中每台虛擬機器多達 64 GB 的記憶體。對於打算虛擬化會耗用大量記憶體的工作負載 (例如 Exchange Server 和 SQL Server) 的人來說，這是關鍵所在。
Hyper-V 也在主機系統上支援多達 16 顆邏輯處理器，使得 Hyper-V 可擴充成大多數含多核心之商用雙插槽和四插槽系統。您也可以建立多達四顆虛擬處理器的虛擬機器，以支援需要或利用多處理器功能的工作負載。
透過 Hyper-V 來彙總伺服器也可讓這些伺服器利用穩健的網路支援，包括 VLAN、網路位址轉譯 (NAT)，以及網路存取保護 (NAP) 原則 (隔離)。同為 Windows Server 2008 的功能，Hyper-V 也與其他 Windows Server 功能搭配無間，例如 BitLocker 和 Windows PowerShell。

高可用性
高可用性是指 Hyper-V 與主機叢集化功能合作協助解決業務持續性和嚴重損壞修復需求的情況。業務持續性是盡可能減少排程和非排程停機的能力。這包括例行職務所流失的時間，例如維護和備份，以及非預期的服務中斷。
嚴重損壞修復是業務持續性的重要元件。自然災害、惡意攻擊，甚至是簡單的設定問題 (像是軟體衝突)，都可能使服務和應用程式受損，而且要等到系統管理員解決問題並還原資料才可能恢復。可靠的商務和嚴重損壞修復策略必須盡可能減少資料損失，並提供強大的遠端管理功能。
在分析高可用性時，您應該考量三個不同的類別 — 計畫停機、非計畫停機，以及備份。通常為了協助將虛擬機器移出主機系統，以利您執行硬體維護或套用修補程式到主機系統或虛擬化平台 (有可能需要重開機)，因此需要保障計畫停機。
大部分的公司都有規劃維護時段，而您在此要做的是盡可能縮短或消除主機系統停機進行維護時，虛擬機器無法使用的時間。利用「快速移轉 (Quick Migration)」功能，您可以在幾秒內迅速在實體節點間移轉執行中的虛擬機器。如此一來，您就可以在原始主機上執行維護作業時，提供虛擬機器作為實際執行之用。維護作業一完成，您接著便可以使用「快速移轉」將虛擬機器歸還到原始的主機系統。
非計畫停機是無法預測的停機。它實質上有可能是大災難，也有可能單純是某人不小心拔掉電源線而使伺服器關機。雖然聽起來難以置信，不過這幾年來我在 Tech•Ed、VMworld 和其他研討會碰過不少系統管理員娓娓道出有些伺服器怎麼被同事不小心關機的。
利用 Hyper-V，您可以針對不同的主機系統設定主機叢集，並將所有虛擬機器設定成叢集資源，如此一來當其中一台主機失敗時，它們便可以容錯移轉到不同的系統。同時，Windows Server 2008 的多站叢集功能可讓您設定地理位置分散的叢集，這樣一來，主要資料中心失敗時，您就能夠將不同的虛擬機器復原到遠端資料中心。
這對於保護您所有的分公司也很實用。透過 Hyper-V 支援非計畫停機的好處之一，就是它具有虛擬 OS 中立性，換句話說，您可以將它的高可用性優點延伸到 Linux 虛擬機器和舊版的 Windows Server，以同樣的方式來保護和復原該些系統。
在考慮非計畫停機時，要特別注意的一點是，修復作業就跟關閉系統後重新啟動沒什麼兩樣，也就是說您會遺失所有狀態資訊。這不一定會構成問題，要看您在虛擬機器中執行的工作負載而定。這也是為什麼在討論高可用性時一定要提到備份的原因。
Hyper-V 可讓您製作每台虛擬機器的備份，或使用 VSS 在所有可感知 VSS 的虛擬機器還在執行時製作一致的備份。透過 VSS，您可以設定備份在不影響實際執行工作負載的可用性下，於固定間隔進行，並同時確保您有連續的備份計畫，以便在發生非計畫停機時輕鬆復原狀態。如需關於透過 Hyper-V 提供高可用性解決方案的詳細資訊，請參閱本期《TechNet Magazine》中，由 Steven Ekren 所著的＜實現 Hyper-V 的高可用性＞一文 (technet.microsoft.com/magazine/cc837977)。

微核心式 Hypervisor 架構的設計是為了盡可能縮小受攻擊面及強化安全性，尤其是當 Hyper-V 實作成 Server Core role 的情況下。Server Core 是 Windows Server 2008 的安裝選項。Hypervisor 並不包含任何裝置驅動程式或協力廠商程式碼，為執行中的虛擬機器提倡更穩定、精簡和安全的基礎。Hyper-V 也與 Active Directory 整合提供強固的角色型安全性，而且 Hyper-V 可讓虛擬機器從硬體層級的安全性功能獲益，例如執行停用 (NX) 位元，進一步協助提高虛擬機器的安全性。
就跟 Windows Server 其餘的元件一樣，Hyper-V 也經歷過安全性開發週期 (SDL)，而且為了確保 Hyper-V 是高度安全的虛擬化平台，也進行了廣泛的威脅模型和分析。當您部署 Hyper-V 時，請確實遵守部署 Windows Server 2008 的最佳作法，以及 Hyper-V 的最佳作法。並且在計畫當中一併納入 Active Directory、防毒軟體和反惡意程式碼解決方案。另外也要使用委派系統管理功能，確定您對 Hyper-V 主機妥當使用系統管理存取權。

易管理性
伺服器偶然間散佈的輕微問題，很容易大規模蔓延到虛擬機器。會有這樣的風險，看看部署虛擬機器有多容易就知道了。加上虛擬機器的行動力提高，您也有額外的責任清楚地知道不同的虛擬機器在什麼場合執行，記錄它們的安全性內容等。
所幸，有了 Hyper-V，您不用為虛擬環境另外建立管理基礎結構。它可與 Microsoft 管理工具、System Center Virtual Machine Manager，以及 Microsoft System Center Operations Manager，還有協力廠商管理工具整合。這可讓您從單一主控台同時管理實體和虛擬資源。如需 System Center Virtual Machine Manager 2008 的詳細資訊，請參閱本期《TechNet Magazine》中，由 Edwin Yuen 所著的＜透過 VMM 2008 管理虛擬環境＞一文 (technet.microsoft.com/magazine/cc836456)。同時，對 Windows PowerShell 的支援也使得自動化工作更加容易。
Hyper-V 也提供虛擬機器前所未有的能力來使用可用的硬體。因為所有通過 Windows 硬體裝置品質實驗室 (WHQL) 認證的驅動程式都能夠在父磁碟分割上執行，所以 Hyper-V 也提供了與驅動程式和裝置的廣泛相容性，更方便管理在您環境中執行的各種驅動程式。

總結
我在前文有提到，管理將是開發和區別的重點領域。未來幾年內，您肯定會在這個領域中看到活躍的景象。整體來說，這確實是虛擬化跨入更主流角色的興奮時刻。如果您還沒試過 Hyper-V，或單純想了解更多詳細的資訊，請前往 microsoft.com/Hyper-V。
Rajiv Arunkundram 在 Microsoft 的 Windows Server 行銷部門擔任資深產品經理，專攻伺服器虛擬化。Rajiv 的主要職責是與客戶和夥伴合作，協助他們從技術和商務的觀點來了解虛擬化策略和 Microsoft 的解決方案。


虛擬化
透過 VMM 2008 管理虛擬環境
Edwin Yuen

本文是根據 Virtual Machine Manager 2008 的搶鮮版所撰寫。本文包含的所有資訊均有可能變更。
綜覽：
  • 對 VMware VM 的支援
  • 以 Windows PowerShell 為基礎的指令碼處理和自動化
  • 整合式集中化管理
  • 安裝程序

目錄
Virtual Machine Manager 2008 簡介
與 System Center 整合
Virtual Machine Manager 2008 安裝
新增 VMware ESX 主機
VMotion 移轉
結論
Microsoft 在去年推出了 System Center Virtual Machine Manager 2007，提供整合介面用以管理執行 Microsoft Virtual Server 2005 的虛擬基礎結構。現在，為了與全新的 Windows Server 2008 Hyper-V Hypervisor 一同發行，新版本的 Virtual Machine Manager (VMM) 也應運而生。System Center Virtual Machine Manager 2008 不僅管理 Microsoft Virtual Server 2005 和 Windows Server 2008 Hyper-V 安裝，而且支援也擴展到了 VMware Infrastructure 3 (ESX/ESXi) 伺服器。透過 VMM，您現在有整合式管理介面可與整個虛擬基礎結構搭配運作，包括 Microsoft 和 VMware 兩種系統。
VMM 支援所有傳統虛擬化工作，例如從範本和預先設定 VM 快速部署虛擬機器 (VM)，實體轉虛擬 (P2V)，集中化的虛擬基礎結構物件庫，甚至從 VMware 虛擬機器 (VMX 設定檔外加 VMDK 虛擬磁碟) 轉換成 Hyper-V VM 的虛擬轉虛擬 (V2V)。另外，VMM 還與其餘的 System Center 系列整合，透過單一平台管理實體和虛擬系統。
在本文中，我將探討 VMM 2008，以及它帶給 IT 系統管理員的新功能。接著我會說明 VMM 安裝的相關需求及步驟。最後，我將深入討論如何使用 VMM 2008 的部份新功能。

Virtual Machine Manager 2008 簡介
System Center Virtual Machine Manager 2008 是獨立的應用程式，為 Microsoft Virtual Server 2005 R2 SP1、Windows Server 2008 Hyper-V、Microsoft Hyper-V Server 2008 和 VMware Infrastructure 3 (ESX/ESXi) 伺服器下執行的虛擬機器，提供集中化的企業級管理。VMM 與其他 System Center 產品結合，可提供端對端實體和虛擬基礎結構管理。[圖 1] 顯示了 Virtual Machine Manager 的架構配置。
[圖 1] System Center Virtual Machine Manager 2008 架構 (按一下以放大影像)
熟悉 VMM 2007 的人會發現在 VMM 2008 中明顯有更多的 VMM 系統介面 (見 [圖 1])。左上方的方塊代表 VMM 2008，右上方的方塊代表 System Center Operations Manager 2007，而管理系統和介面則顯示在下方。紅色的方塊表示管理伺服器，藍色方塊顯示系統輸入，而綠色方塊則是管理的主機系統，它們的管理物件是以黃色標示。
左上方的紅色方塊代表 Virtual Machine Manager 2008 伺服器服務。在它上面的是進入服務的不同介面：系統管理員主控台、Windows PowerShell 介面，以及具委派使用者存取權的自助入口網站。Windows PowerShell 是構成對 VMM 伺服器進行的所有存取的基石。VMM 系統管理員主控台完全是以 Windows PowerShell 為基礎建置，所以只要建立 VMM 伺服器服務執行的 Windows PowerShell 指令碼就行了。因此，VMM 2008 的公用 API 是 Windows PowerShell，而任何程式都可以使用 Windows PowerShell 來利用 VMM。有一個最佳的範例是 Citrix 的 XenDesktop Desktop Delivery Controller 與 Virtual Machine Manager 的整合，這便是完全透過 Windows PowerShell 完成的。
支援 VMM 是 SQL Server 2005 或 SQL Server 2008 資料庫，如果沒有任何其他可用的資料庫，可進行完整安裝或 SQL Server Express Edition。雖然圖表中顯示 Operations Manager 和 Virtual Machine Manager 都是指向 SQL Server，但是這兩種程式並不會共用資料庫。它們只是同時在相同版本的 SQL Server 上執行。Virtual Machine Manager 與 Operations Manager 之間實際的整合是透過 VMM 提供的連接器達成的。此連接器允許 VMM 和 OpsMgr 共用資料，進而將虛擬化資訊帶入 OpsMgr，將 OpsMgr 資料帶入 VMM 以採取動作。
圖表的下半部顯示受管理的主機。VMM 2008 仍舊管理 Virtual Server 2005 R2 SP1 虛擬機器主機和中央程式庫共用，就跟在 VMM 2007 中一樣。另外應該注意的是，在 VMM 中的程式庫共用並不是特別的檔案存放區或伺服器。它只是 VMM 管理的 Windows 檔案共用。您可以透過 VMM 來管理程式庫，或是輕鬆地在檔案共用中複製和刪除檔案，讓 VMM 來探索這些變更。您也可以有多個程式庫，這對於委派的伺服器組，以及遠端辦公室中的伺服器都蠻實用的。
管理 Hyper-V 和 ESX Hypervisor 是 VMM 2008 中的新功能。Hyper-V 主機的管理工作是透過 Windows 遠端管理 (WinRM) 和 Windows Management Instrumentation (WMI) 介面來進行。事實上，在新增潛在 Hyper-V 主機時，如果 Windows Server 2008 中沒有啟用 Hyper-V 角色，VMM 可以為系統管理員自動啟用該角色。這項功能也可用於 Windows Server 2003 系統潛在虛擬伺服器主機。
VMware VI3 ESX 主機的管理工作實際上是透過 VMware VirtualCenter 伺服器來進行。VMM 2008 會透過 VirtualCenter Web 服務 API 與 VirtualCenter 進行互動。因此，要管理 VMware，必須要有 VirtualCenter 伺服器才行，而 VMware 大多數的企業安裝都至少有一部 VirtualCenter 伺服器。VMM 2008 獨樹一格的地方在於它能夠管理多部 VirtualCenter 伺服器。VMM 可以新增多部 VirtualCenter 伺服器，允許系統管理員將整個 VMware 基礎結構彙總，並提供單一企業檢視，這在以前是不可能辦到的。
身為 System Center 系列產品的一份子，VMM 在系統管理員主控台中使用 System Center 或 Outlook 樣式的介面。VMM 系統管理員主控台並不是 MMC 嵌入式管理單元，它是全新的應用程式，採用 Microsoft .NET Framework 2.0 建置而成，而且是搭建在 Windows PowerShell 1.0 的基礎上。前文有提到，系統管理員主控台中的任何動作其實都會呼叫相關的 Windows PowerShell 命令，因此 UI 實際上是使用 Windows PowerShell。所以，在系統管理員主控台中進行的任何命令或函數，也可以透過 Windows PowerShell 中的命令列來完成。
系統管理員主控台中的每個精靈也都有一個 [檢視指令碼] 按鈕，可針對要執行的命令顯示相關的 Windows PowerShell 指令碼 ─ 這點對於剛開始學習 VMM 相關的 Windows PowerShell 有很大的幫助。VMM 2008 中全新的 [檢視指令碼] 動作現在會在記事本中開啟這些指令碼，所以您可以直接從 VMM 輕鬆編輯它們。您也可以毫不費力地儲存已編輯的指令碼，然後直接從 VMM 程式庫重複使用 — 這是 VMM 2008 中另一項新功能。VMM 2007 的指令程式在 VMM 2008 中也已經過更新，包括對 VMware 伺服器的支援。相同的指令程式可在虛擬平台間運用，因此像是 New-VM 等指令程式可同時在 Microsoft 和 VMware 系統上運作。這麼一來，IT 系統管理員就能夠使用一組指令程式來管理 Virtual Server、Hyper-V 和 VMware ESX 主機。
Virtual Machine Manager 2008 經過精心設計，能為 IT 系統管理員提供三大優點：
  • 充分利用資源
  • 提高靈活度
  • 運用現有的技能
不少特性和功能更是將這些優點發揮到極致。首先，VMM 透過整合管理您整個虛擬基礎結構 (無論 Hypervisor 為何)，藉此充分利用您的資源。VMM 2008 藉著整合 Microsoft 與 VMware 系統來提供所有主機和虛擬機器的單一檢視，如 [圖 2] 所示，並讓系統管理員依參數來篩選和檢視他們的系統，例如主機、作業系統、擁有者、新增的日期等。
[圖 2] VMM 主控台顯示整合的 Microsoft 和 VMware 管理 (按一下以放大影像)
VMM 也透過像是 P2V 和 V2V 的轉換來進行簡易的伺服器彙總，藉以幫助充分利用系統資源。P2V 可讓您將現有的實體機器彙總成虛擬機器，而不用重新安裝這些機器。這對於轉換硬體使用率不高的機器特別有用，因此您可以把好幾部低使用率的機器放在同個實體硬體上，以充分利用資源。P2V 是 VMM 的整合功能，而且不需要額外的軟體或伺服器。在 VMM 2008 中，還加入了對更多實體系統的支援，包括 Windows Vista、Windows Server 2008 和 x64 主機。VMM 的 P2V 功能是諸如 Microsoft Assessment and Planning (MAP) 工具 (在本期《TechNet Magazine》中，Baldwin Ng 和 Jay Sauls 所著的文章中有討論到) 等一些規劃工具的好夥伴，這些工具可幫助識別適合伺服器彙總的候選機器。
如果您已經有虛擬機器是使用 VMware 的 VMDK 格式，VMM 可讓您使用 V2V 將現有的 VMDK 轉換成 VHD 格式。這個程序是離線進行 — VMware VM 必須關閉，因為 V2V 作業是將實際的 VMDK 檔案轉換成 VHD。您也可以使用 P2V 功能來轉換執行中的 VMware VM。這可能有點容易混淆，不過重要的是，記住虛擬機器是機器為先，虛擬為後。既然所有其他系統都把 VM 當作是執行中的機器，VMM 的 P2V 功能也不例外，如此可讓您將在任何虛擬化軟體上執行的 VM 轉換成 Microsoft VHD。
VMM 透過幾項功能為 IT 系統管理員提供更高的靈活度。VMM 提供的其中一項關鍵功能是，在主機間移轉 VM，而這可幫助維持高可用性和伺服器最佳化。對於 Hyper-V 主機，VMM 2008 支援「快速移轉 (Quick Migration)」，只要幾秒的停機時間即可在 Hyper-V 主機間移動 VM。這需要有 Windows Server 2008 叢集和共用存放裝置，但 VMM 有助於減輕管理和設定的負擔。
而對於 VMware ESX 主機，VMM 2008 也支援 VMware VMotion，這項 VMware 功能可在使用者察覺不到的停機下移動 VM。跟「快速移轉」一樣，也需要有啟用 VMotion 的 VMware ESX 主機，另外也需要叢集和 SAN 後端。我將在本文稍後帶您使用 VMM 2008 逐步完成 VMotion。
最後，VMM 2008 可將現有的 Virtual Server 2005 VM 移轉到 Hyper-V 主機上，自動執行移轉作業所需的所有升級和轉換動作。
就像任何 VM 部署程序一樣 (包括上述的移轉作業)，無論是經由轉換而開始或全新部署，VMM 都會採用稱為「智慧定位 (Intelligent Placement)」的程序，將 VM 部署到主機上。它也會使用「智慧定位」來查詢所管理的所有虛擬機器主機，擷取幾個有關這些主機的資源可用性的參數，然後傳回您可部署 VM 的建議主機加權清單。跟您在 [圖 3] 中看到的一樣，「智慧定位」支援 Microsoft 和 VMware 主機，及其存放裝置設定。VMM 2008 中的「智慧定位」同時可感知平台和設定。因此，它只會建議符合正確主機平台的主機，如果需要高可用性的話，則只建議經過叢集化的主機，至於 x64 VM 則只建議具備 x64 功能的主機。
[圖 3] 「智慧定位」分析所有可用的主機 (按一下以放大影像)

與 System Center 整合
VMM 2008 的關鍵功能之一，是與 System Center Operations Manager 2007 的整合。雖然 VMM 2007 已與 Operations Manager 有某種程度的整合，但 VMM 2008 則包括了適用於 Operations Manager 的產品連接器，可大幅提升整合的功能性。VMM 透過自身與 Operations Manager 的整合，在系統管理員主控台，以及透過稱為「效能和資源最佳化 (Performance and Resource Optimization，PRO)」的新功能，提供了整合式作業管理員報告。
PRO 可讓 VMM 2008 建立稱為「PRO 提示 (PRO Tips)」的警示，甚至根據 Operations Manager 的監視參數執行自動化動作對策。[圖 4] 顯示了一些「PRO 提示」範例。當使用啟用 PRO 的管理套件時 (PRO 套件)，VMM 2008 可執行自動化動作，例如根據主機、Hypervisor、硬體，甚至是工作負載為主的效能參數，來移轉 VM 和建立新 VM。
[圖 4] 「PRO 提示」針對虛擬基礎結構中的問題提供警示和對策 (按一下以放大影像)

Virtual Machine Manager 2008 安裝
執行 System Center VMM 2008 安裝有幾項必要條件和新的系統需求。首先，VMM 2008 伺服器必須要有 Windows Server 2008 x64。該伺服器在 Windows Server 2003 或 x86 版本的 Windows Server 2008 上無法安裝。系統管理員主控台和其他元件仍然可以安裝在 Windows Server 2003 和 Windows XP 或 Windows Vista 上 (就主控台而言)，需求和安裝程序跟 VMM 2007 一樣。
其次，VMM 2008 需要將 Active Directory 網域作為它的安全性模型進行安裝。VMM 2008 支援管理周邊網路 (未加入網域) 的主機，包括非網域系統的 P2V，這是 VMM 2008 的新功能。使用 Windows Server 2008 作為安裝平台的優點之一是，VMM 的許多必要條件 (例如 .NET Framework 3.0、WinRM 和 Windows PowerShell 1.0) 都已經內建。最後，VMM 2008 需要有 Windows 自動化安裝套件 (WAIK) 3.0，不過 VMM 2008 安裝程式包含這些安裝檔案。
雖然我建議在生產環境內，將每個 VMM 元件安裝在不同的實際執行伺服器上，但我還是會討論一下單一伺服器安裝。VMM 伺服器安裝的硬體建議為執行 2.8GHz 或更高速度且至少具有 2GB RAM 的 x64 架構伺服器。由於這是使用本機 SQL 資料庫的單一伺服器安裝，因此需要 7GB 的硬碟空間。請注意，若是使用遠端資料庫，VMM 安裝本身就只需要 1GB。對於本機程式庫安裝，則建議另外配備 80GB 的磁碟空間。
前面有提到，VMM 是在 Windows Server 2008 x64 安裝上執行。其他軟體需求包括 .NET Framework 3.0、Windows PowerShell 1.0、WinRM，以及 IIS 6.0 或之後版本 (用於自助入口網站)。另外還需要 Microsoft MSXML 6.0 Parser，但它已包含在 .NET Framework 3.0 中。
開始 VMM 安裝時，會提供您五個選項：Virtual Machine Manager 伺服器、系統管理員主控台、自助入口網站，以及本機代理程式，還有一個設定 Operations Manager 管理套件的選項。如前文所述，我會將所有元件安裝在單一機器上，先從 VMM 伺服器開始。安裝程式一啟動，第一個畫面即會檢查系統必要條件。
除了之前提到的需求之外，電腦還必須位於網域上。VMM 伺服器安裝將自動為您啟用內建功能，讓您不用手動啟用它們。
一啟動安裝程式之後，我建議使用 Windows Update 選項來確保 VMM 2008 保持在最新狀態。安裝程式接著會檢閱選項，主要是與 SQL 資料庫安裝相關的選項。在本例中，我將使用 SQL Server 2005 Express Edition。
接下來，精靈會要求您識別中央程式庫的位置。這個位置可以是 VMM 伺服器上的本機目錄 (精靈會為該目錄建立共用)，也可以是現有的檔案共用。預設位置是 C:\ProgramData\Virtual Machine Manager Library Files。
接下來是指派連接埠。在此我要設定系統管理員主控台與核心 VMM 伺服器服務連線所使用的連接埠 (預設為 8100)、WinRM 用來執行管理功能的連接埠 (預設為 80)，以及背景智慧型傳送服務 (BITS) 用來將檔案移至虛擬機器主機的連接埠 (預設為 443)。一但輸入這項資訊後，將會出現摘要畫面，伺服器安裝接著就告完成。
接下來，我要安裝系統管理員主控台，它的系統必要條件與 VMM 伺服器的類似。除了安裝目錄以外唯一可用的設定選項，是確認與核心 VMM 伺服器服務所使用的通訊連接埠。這個連接埠應該是 8100，正如 VMM 伺服器安裝中的設定。
在安裝結尾，您可以選擇為系統管理員主控台建立桌面捷徑，以及在結束安裝時開啟主控台。兩個選項都選是個不錯的主意。第一次開啟系統管理員主控台時，系統會提示您連線到伺服器。在單一伺服器安裝中，localhost 位在連接埠 8100 是正確的，您只需按下 Enter 鍵即可啟動主控台。
最後，我將安裝自助入口網站。這項安裝的必要條件包括 IIS 6.0 或 7.0、.NET Framework 3.0，還有 Windows PowerShell 1.0 (之所以需要 Windows PowerShell 是因為自助入口網站不過是核心 VMM 服務的另一種介面，而 VMM 服務使用 Windows PowerShell)。對於 Windows Server 2008，您必須先啟用 IIS 角色，才能開始 VMM 2008 安裝。進行這個動作的時候，請確定已啟用下列 IIS 角色服務：
  • 一般 HTTP 功能 (靜態內容、預設文件、目錄瀏覽、HTTP 錯誤)
  • 應用程式開發 (ASP.NET、.NET 擴充性、ISAPI 延伸模組、ISAPI 篩選器)
  • 安全性 (要求篩選)
  • IIS 6.0 管理相容性
如果這些角色服務都已啟用，安裝便會通過必要條件檢查，並且繼續執行。在安裝期間，設定選項只會處理自助入口網站所用的連接埠。首先是連線到核心 VMM 服務的連接埠，亦即 8100，這與系統管理員主控台的設定一樣。其次是執行入口網站的連接埠。預設為連接埠 80，但在許多設定中，該連接埠已被佔用，若是如此，VMM 安裝程式會警告您。必要時，可將連接埠變更為可用的連接埠，如 8080。安裝程式接著會建立稱為 Microsoft System Center Virtual Machine Manager 2008 自助入口網站首頁的網站，您可以在伺服器管理員中變更其設定。
完成 IIS 安裝之後，只要在 Internet Explorer 中前往 localhost:8080 就可以開啟此網站。如果您在開啟網站時收到驗證的提示，這是因為 Internet Explorer 安全性設定的緣故。自助入口網站應該在 Internet Explorer 的內部網路內容中執行，而且您可能需要在 Internet Explorer 中，將 VMM 伺服器新增到內部網路網站清單。完成這些設定後，您就可以開始在 VMM 2008 中建立及使用有啟用自助功能的 VM 了。

新增 VMware ESX 主機
雖然 VMM 2008 中有許多新功能，但最萬眾期待的功能當屬新增對 VMware ESX 主機管理的支援。透過這項支援，VMM 現在能夠管理大多數企業 IT 部門的虛擬基礎結構。
新增 ESX 主機到 Virtual Machine Manager 2008 的程序相當簡單。我在前文有提到，VMM 2008 是透過 VirtualCenter 伺服器 (必須是第 2.0.1 或 2.5 版) 來管理 VMware 主機。若要新增 VMware ESX 伺服器到管理主控台，只要使用位於 [執行] 窗格右上方的 [新增 VMware VirtualCenter 伺服器] 動作來新增 VirtualCenter 伺服器即可。
啟動精靈之後，輸入 VirtualCenter 伺服器的電腦名稱，以及 VirtualCenter 伺服器的系統管理帳戶。VMM 將新增 ESX 主機 (包括 VirtualCenter 現有的「主機群組」結構) 到 VMM 介面。這項工作可能會花幾分鐘的時間，但是您可以從 VMM [工作] 功能表監視進度。
所有伺服器都匯入之後，您應該能夠在 VMM 中看到如同 VirtualCenter 顯示的 VMware ESX 主機伺服器結構。若要新增其他 VirtualCenter 伺服器，只要重複相同的步驟就行了。主機結構一加入 VMM 後，您便可以新增非 VMware 伺服器到相同的群組結構。當然，非 VMware 伺服器並不會顯示在 VirtualCenter 中。
雖然 VMM 2008 是使用 VirtualCenter 來管理 ESX 主機，對於特定的功能，它還是需要能夠直接存取 ESX 主機本身，例如 V2V、儲存狀態，以及從 ESX 主機複製 VM。因此，在您新增 VirtualCenter 伺服器到 VMM 之後，主機會顯示成 [確定 (有限制)]。若要啟用完整的管理功能，請在 VMM 中前往個別 ESX 主機的 [內容] 頁，然後提供適當的主機憑證以便直接管理伺服器。

VMotion 移轉
每次討論到 Virtual Machine Manager 2008 中的 VMware 管理，必定有的疑問是 VMM 是否能執行 VMotion 和其他 VirtualCenter 功能。既然 VMM 是使用 VirtualCenter 來管理 VMware，答案是肯定的！
在功能上，VMM 對待 VMotion 就跟對待任何其他移轉作業一樣。若要啟動 VMotion，首先請選擇您要移轉的 VM，然後從 VMM 右手邊的 [執行] 窗格中選擇 [移轉虛擬機器] 選項。完成這個步驟之後，VMM 會顯示該 VMM 的 [智慧定位 (Intelligent Placement)] 視窗，並列出可能的目標主機，以及 [即時] 的傳輸類型，如 [圖 5] 所示。「智慧定位」可幫助您為您的 VM 選擇適當的目標主機。請注意，這個程序與使用 Hyper-V 主機執行「快速移轉」的程序一樣。
[圖 5] 使用「智慧定位」的 VMotion (按一下以放大影像)
為 VM 選擇目標主機 — 在本例中，它是稱為 cqaesxi003.contoso.com 的伺服器，再按一下 [下一步]。[圖 6] 中顯示的最後摘要視窗，將顯示要求的動作。
[圖 6] VMotion 摘要視窗 (按一下以放大影像)
前面有提到，VMM 中的每個精靈都有一個 [檢視指令碼] 按鈕，可將某工作的 Windows PowerShell 指令碼顯示在記事本中。這讓我們有機會觀察 Windows PowerShell 在 VMM 2008 中與 VMware 搭配運作的情況。下面是這個動作的指令碼：
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq "cqaesxi003.contoso.com"}
$VMHost = Get-VMHost -VMMServer localhost |   where {$_.Name -eq "cqaesxi003.contoso.com"}
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
三個簡單的命令為此系統執行 VMotion。在我的例子中，我是把 VM MyVM 從 VMware 伺服器 cqaesxi003.contoso.com 移到伺服器 cqaesxi001.contoso.com。第一個命令是識別要透過 VMotion 移轉的虛擬機器。如您所見，在這行命令列中，我把虛擬機器值指定成變數 $VM：
$VM = Get-VM -VMMServer localhost -Name "MyVM" |
  where {$_.VMHost.Name -eq " cqaesxi003.contoso.com"}
第二個命令是要識別 VM 的目標 ESX 主機系統。在這行當中，我把變數 $VMHost 指定成 ESX 主機 cqaesxi003.contoso.com：
$VMHost = Get-VMHost -VMMServer localhost | where
  {$_.Name -eq " cqaesxi003.contoso.com"}
最後，我使用 Move-VM 命令來進行實際移動 VM 的動作。下面是 Move-VM 的完整命令列和參數：
Move-VM [-VM] [<String VM>] -VMHost [<String Host>]
  [-JobGroup <Guid>] [-JobVariable <String>] [-Path
  <String>] [-PROTipID] [-RunAsynchronously]
  [-StartVMOnTarget <Boolean>] [-UseLAN <Boolean>]
  [<CommonParameters>]
為了與 Virtual Machine Manager 中異質管理的體系保持一致，您可以看到命令並不是針對特定的廠商或軟體。若要完成 VMotion，請發出此命令：
Move-VM -VM $VM -VMHost $VMHost –RunAsynchronously
這會告訴 VMM 對 $VM 中的 VM 執行 Move-VM，移轉到 $VMHost 中的主機系統，並以非同步的方式執行工作。工作一開始，即可從 VMM 中的 [工作] 視窗監視整個程序。再次強調，這個基本命令同樣可以使用 LAN 為主的傳輸，在 Hyper-V 叢集甚或是非叢集主機上針對「快速移轉」來進行。
您可以看到，System Center Virtual Machine Manager 2008 以嶄新的管理平台和全新功能，擴充了 Virtual Machine Manager 2007 的強大功能和特性。藉著探討安裝程序和幾項功能，在此希望我已展示了在 VMM 2008 中管理多部 Hypervisor 有多麼簡單。
VMM 2008 是為了作為虛擬化的整合式管理軟體而設計的，它統合了 Microsoft 與 VMware 的實體和虛擬系統。透過這個新版的 Virtual Machine Manager，VMware 系統管理員、Microsoft Virtual Server 2005 系統管理員，以及新的 Hyper-V 系統管理員，全都能夠針對他們的虛擬基礎結構，充分利用單一工具、單一指令碼介面，以及最重要的，單一管理程序。

Edwin Yuen 在 System Center Virtual Machine Manager 的 Windows 企業管理部門擔任技術產品經理。他因 Microsoft 於 2006 年 7 月併購 Softricity 而加入 Microsoft。Edwin 也在商業及聯邦法雙領域擁有 13 年技術諮詢經驗，並具有約翰霍普金斯大學 (Johns Hopkins University) 的電機理學士學位。


虛擬化
Microsoft Application Virtualization 入門
Anthony Kinney

本文是根據 App-V 的搶鮮版撰寫。本文包含的所有資訊均有可能變更。
綜覽：
  • App-V 架構
  • 管理虛擬應用程式
  • 使用 App-V Sequencer
  • 將 App-V 與 Configuration Manager 整合

目錄
App-V 架構
App-V 完整基礎結構的運作方式
更新虛擬應用程式
編序
第 4.5 版
Microsoft Application Virtualization (或 App-V) 深得我心，App-V 的前身是 SoftGrid，而我是在 Microsoft 併購建立 SoftGrid 的公司 (稱為 Softricity) 時，加入 Microsoft 的。我很高興有機會為《TechNet Magazine》撰寫本文，因為自併購之後發生了許多變動。
要認識 App-V，最好先談談 IT 專業人員在企業管理方面所面臨的挑戰。現今的商務桌上型電腦充斥著應用程式，應用程式在安裝之前，必須先經歷冗長的迴歸測試，以確保它能夠與系統上安裝的其他應用程式並存，而不影響它們適當執行的能力。接下來還要再經過一連串的部署程序之後，才進入實際執行階段。而且因為應用程式基本上只在有安裝它的地方可用，所以您的使用者也受限於特定的電腦。這使得複雜的重要專案 (例如作業系統和應用程式移轉、安全性更新，以及嚴重損壞修復規劃等) 更加複雜。
App-V 則大改其觀，透過它，桌上型電腦管理的程序不再是一連串佔用資源又耗費時間的複雜步驟，而是變得更簡單、更自動化。您可以更輕鬆地部署、修補、更新和終止應用程式，並且成效更為顯著。
有了 App-V，使用者可以坐在任一部桌上型電腦前存取他的應用程式。應用程式是視需要才提供，但執行起來會像實際安裝在本機一樣。因此，完全不需要安裝應用程式元件或修改主機裝置。
這種虛擬化的應用，一改 IT 專業人員管理桌上型電腦的方式。不修改主機裝置而改執行虛擬化應用程式有很多優點，包括：
  • 減少應用程式衝突
  • 更快速且更簡單的更新應用程式
  • 能夠並排執行同一應用程式的多個版本
  • 增加應用程式的彈性，讓它隨著使用者上下線
  • 減少應用程式對應用程式的迴歸測試

App-V 架構
現在就讓我們看看 App-V 平台背後真正的運作原理。這個平台包括幾個主要的元件：Sequencer、資料庫、用戶端、管理伺服器、Streaming Server，以及管理主控台 (見 [圖 1])。
[圖 1] App-V 環境的配置 (按一下以放大影像)
App-V 系統的核心是 App-V 用戶端。可用的用戶端有兩種 — 終端機伺服器用戶端和桌上型用戶端。無論是哪一種用戶端，都必須安裝在您打算部署虛擬應用程式的每部桌上型電腦和終端機伺服器上。用戶端佔用的磁碟空間相當小，它會安裝一個驅動程式，並且有一個顯示成工作匣指示器的可見使用者執行階段元件。
用戶端會從 App-V 管理伺服器收集虛擬伺服器清單，並顯示可用的虛擬應用程式。它會在使用者初始化時，負責啟動這些應用程式，以及管理用戶端快取。用戶端也肩負管理虛擬執行階段環境的管理工作，並且確保每個環境都是在它自己的虛擬泡泡裡面執行。這樣的虛擬環境含有幾個元件，其中包括虛擬登錄、虛擬檔案系統和虛擬服務管理員。
App-V 4.5 中有三種基礎結構部署選項可用：完整基礎結構、輕量型基礎結構和獨立模式。在部署完整基礎結構時，後端包括了 App-V 管理伺服器和 App-V Streaming Server (這是新元件，我稍後會討論到)。App-V 管理伺服器會主控和提供集中化的虛擬應用程式，也會在套用補充程式或更新時更新虛擬應用程式。
這部管理伺服器是仰賴 SQL Server 來主控 App-V 資料庫，當中包含了虛擬應用程式的組態和設定。您應該使用 Active Directory 群組作為佈建和控制虛擬應用程式權限的中央管理工具。
為了管理設定和組態，App-V 平台提供了 Microsoft .NET Framework Web 服務，只要裝有 IIS，便可將它載入相同的伺服器上。這個 Web 服務在 App-V 管理主控台 — 一種 Microsoft Management Console (MMC) 嵌入式管理單元 — 與 App-V 資料庫之間扮演著溝通者的角色。系統管理員可使用主控台來發行和管理虛擬應用程式、指定 Active Directory 群組，以及控制伺服器設定，也可以執行有關虛擬化應用程式使用狀況的報告 (見 [圖 2])。
[圖 2] 管理主控台 (按一下以放大影像)
輕量型基礎結構包括 App-V Streaming Server，它提供串流處理功能，例如主動/封裝更新。這個選項並不需要 Active Directory 或 SQL Server，它並沒有桌上型電腦設定服務，也缺乏授權和計量功能。不過，輕量型基礎結構倒是允許將串流處理功能新增到 System Center Configuration Manager (SCCM) 和其他協力廠商企業軟體部署 (ESD) 解決方案。
在獨立模式中，App-V Sequencer 可建立 MSI 檔案來自動化虛擬應用程式的新增作業 (見 [圖 3])。MSI 檔案包含的中繼資料可讓任何 ESD 系統辨別它，並控制虛擬化應用程式。這個模式會要求用戶端進入獨立模式，這種模式只接受以 MSI 為基礎更新虛擬應用程式，而不接受串流處理。這種模式能讓公司利用 App-V 隔離功能。
[圖 3] App-V Squencer (按一下以放大影像)
MSI 檔案極具彈性，只要有 App-V 用戶端，就可以獨立執行，完全不需要任何伺服器元件。這表示它們可以使用磁碟或透過任何傳統部署工具手動加以部署。
App-V 4.5 現在都支援 HTTP 和 HTTPS 通訊協定進行串流處理。如果連同更廣泛採納的通訊協定來進行串流處理，將可提升效能，特別是跨安全廣域網路 (WAN) 環境和網際網路進行串流處理。

App-V 完整基礎結構的運作方式
使用者登入裝有其中一個用戶端 (App-V 終端機服務或桌上型用戶端) 的裝置，然後用戶端傳送要求到伺服器，要求取得指定給目前使用者的應用程式清單。接著伺服器與 Active Directory 通訊，判斷使用者所屬的群組之後，再將應用程式清單傳回給用戶端。用戶端便開始為已指定給該特定使用者的虛擬化應用程式建置通告。
在這個發行程序當中，執行了幾個動作：
  • 複製設定檔
  • 建立桌面圖示
  • 建立 [傳送到] 連結
  • 建立 [開始] 功能表資料夾
  • 設定檔案類型
這個程序非常快速，而且最重要的是，可以確保環境看起來沒有任何視覺變更，完全符合使用者的預期。虛擬應用程式的舉動跟安裝在本機沒什麼兩樣，但是它們不會修改主機。圖示不是指向存在程式檔案目錄中的可執行檔，而是指向 App-V 用戶端，而這必須仰賴啟動器檔 (OSD 檔案) 來進行設定。
要特別注意的是，這個程序幾乎不會對網路造成任何衝擊，因為它與傳統軟體部署不同，它並不會安裝任何東西。這一點提供了很多好處，尢其在漫遊使用者的環境中更是，因為供使用者使用的應用程式是在啟動之後才開始傳遞。這種通告方法正是提供 App-V 視需要和漫遊應用程式功能的基礎。
當使用者啟動虛擬應用程式時，用戶端會讀取一直存放在本機電腦上的 OSD 設定檔。它會告訴用戶端，在與 App-V 管理伺服器通訊時要使用哪一個通訊協定，以及應用程式位在哪一部伺服器上。
適當的伺服器會以串流處理初始啟動閾值 (一般是完整應用程式的 20-40%) 來回應用戶端。一旦整個啟動閾值都經過串流處理後 (再次強調，是應用程式的 20-40%)，虛擬應用程式就可以開始執行了。
在 App-V 提出的概念轉型當中，串流處理其實是關鍵要素之一。它可以只傳送足以執行的應用程式，節省寶貴的網路頻寬。所有傳遞給用戶端的資料都存在裝置上的本機快取檔案中，而且應用程式隨後的啟動作業會從本機快取啟動，以消弭額外的網路流量。
虛擬應用程式一完成串流處理後，用戶端便會建置隔離的環境，預防應用程式修改本機電腦 (換句話說，應用程式無法支配用戶端)。但是，用戶端會讓虛擬應用程式在儲存和編輯檔案時存取本機檔案系統，而且只要使用者在本機系統上具備適當的權限，它也允許應用程式與本機服務 (例如列印) 互動。但是虛擬應用程式對本機系統的檔案和登錄所作的任何變更，都會重新導向到虛擬化環境，讓主機裝置保持原封不動。
在執行應用程式時，之前未使用的任何功能都會在需要的時候傳遞，並且快取起來供隨後使用。其優點是，初次啟動時只會載入使用者所需的元件，不讓不需要的功能佔用網路資源 (新版本提供的一些用戶端快取增強功能，可以更聰明的使用快取和背景串流處理)。
以 Consider Microsoft Office Word 為例，由於使用者幾乎都會使用拼字檢查程式 (沒有它，我可能無法寫完這篇文章呢！)，因此它也屬於初始啟動的一部分。但是 Word 裡面的說明功能呢？使用這項功能的人並不多，因此不需要在初始啟動中傳遞它，而是等到使用者第一次使用它時再傳送給他。
使用者用畢並關閉應用程式之後，用戶端就會摧毀虛擬環境，並把所有使用者設定存放在使用者特定的位置中，好讓環境保持到下次啟動時重建。無論串流處理了多少百分比的虛擬應用程式，都會保留在本機快取中，供下次啟動使用。而且要是有其他使用者登入相同的主機系統，並啟動相同的虛擬應用程式，新使用者也可以從已經存放在快取中的應用程式受益。
若要移除虛擬應用程式通告，只要將使用者從適當的 Active Directory 群組移除即可。而要完全將虛擬應用程式從桌上型電腦解除安裝，只要清除快取就行了。應用程式從未真正安裝在本機，因此也不會有煩人的提示詢問您「是否想要移除這個共用元件？」。
要注意的是，即使虛擬應用程式是存放在快取中，也不表示所有的使用者都可以存取它。這跟安裝在本機的應用程式不同，使用者可以搜尋或瀏覽他們無權搜尋或瀏覽的可執行檔，除非使用者透過 Active Directory 群組獲有指定的明確權限，否則虛擬應用程式在視覺或實體上並不存在。

更新虛擬應用程式
更新是利用 Sequencer 來進行。應用程式一經修訂，包含更新之後，就會被放在 App-V 管理伺服器上，並且就在前一版的旁邊。伺服器會下在次啟動時，通知用戶端已發生變更。如果前版仍在使用中，使用者還是可以繼續存取該版本，直到虛擬應用程式關閉為止。下次啟動時，更新差異便會串流處理到用戶端，並且載入快取當中，產生更新版的應用程式。
假設您有 1,000 名使用者執行 Word 2000。有一位系統管理員需要將 Word 2000 (word2K.sft) 更新為 Word 2000 SP3，因此她把 word2K.sft 檔案複製到編序站台，並在 Sequencer 中選取 [開啟以升級套件 (Open for Package Upgrade)]。選取這個選項之後，該系統管理員便從上一個套件狀態開始著手。她可以在虛擬應用程式中複製 DLL、執行更新，或者執行補充程式，將它更新到 Word 2000 SP3，然後再儲存這個經過更新的套件。
Sequencer 會自動指定新檔名 word2K_2.sft 以防檔名重複，並且指明編序的版本。新套件跟舊套件都會放在 App-V 管理伺服器的同一個目錄中，以便讓 Word 2000 (word2K.sft) 和 Word 2000 SP3 (word2K_2.sft) 最後存在同一個目錄中。接著系統管理員再使用 App-V 管理主控台，將這兩個 SFT 檔案連結在一起。
另外在用戶端這邊，如果使用者有作用中的 Word 2000 工作階段、但沒有開啟 SP3，仍可繼續正常操作。如果使用者在系統管理員完成這項連結後，啟動新的應用程式工作階段，則會收到一則訊息，告訴他已經偵測到變更。接著用戶端開始進行串流處理，並且只處理 word2K.sft 與 word2K_2.sft 之間的差異，自動將應用程式更新為 Word 2000 SP3。
由於虛擬應用程式具備動態本質，因此要進行回復也非常簡單。只要回到 App-V 管理主控台，再把新增的版本移除就可以了。這樣用戶端在重新啟動之後，就會回復為前一版。為了確保套件資料不交錯，用戶端會自動清除快取，並重新串流處理適當的 SFT 檔案。想想要回復使用更多傳統軟體部署工具實體安裝的應用程式更新所需花費的功夫，這算是相當合理的折衷辦法了。

若要充分發揮 App-V 的優點，您必須建立虛擬應用程式套件。這正是 App-V Sequencer 派上用場的地方。您從傳統軟體部署工具獲得的編寫指令碼和建立套件的知識和經驗，都有助您轉移到編序 (我應該在此註明，編序這個主題應以專文探討)。
多數軟體部署解決方案都是仰賴指令碼來擷取應用程式自行安裝的方式，然後在其他機器上重複這個程序，如此一來就不用親臨每部電腦來安裝或更新應用程式。應用程式安裝之後，一般軟體部署工具便不再理會套件。接著您必須根據自己的需要，安裝應用程式可能仰賴的任何依存性、執行其他指令碼，或是執行手動步驟來設定應用程式。
App-V 中主要的變革是，編序程序會產生已安裝應用程式的映像，並完成它的依存性和設定。這項作業可由 App-V 用戶端「執行」，而不必修改執行 App-V 的裝置。
Sequencer 會產生各種不同的檔案，當中最重要的要屬 SFT 檔案，該檔案包含了所有的應用程式資產、依存性和設定資訊。在某些情況下，它可能還包含多個應用程式。所以如果該檔很大的話，也不足為奇。雖然它有提供一些壓縮選項，但您還是得充分瞭解您的網路和裝置效能。Sequencer 建立的圖示檔案 (.ico) 是作為通告虛擬應用程式之用，以便讓它像安裝在本機一樣運作。
OSD 檔案也很重要，而且它的選項是漫無邊際的。在預設的情況下，這是一個用來告訴 App-V 用戶端如何啟動虛擬應用程式的 XML 檔案。您也可以修改 OSD 檔案，來設定和控制虛擬應用程式的啟動和執行方式。我強烈建議您閱讀《編序系統管理指南》(英文) 和＜編序最佳作法＞(英文)，熟悉一下 OSD 檔提供的屬性和值。
最近新的 manifest.xml 檔包含了以套件為主的設定資訊，而且可以和協力廠商 ESD 解決方案和 MSI 開發彼此整合。Sequencer 也可以針對虛擬應用程式套件產生 MSI 檔案，將虛擬應用程式載入到獨立 (無伺服器) 用戶端，並且通過 ESD 系統。
Sequencer 本身是以精靈為基礎的工具，它會帶您 (使用套件者) 逐步安裝應用程式，並將它轉變成虛擬應用程式的過程 (見 [圖 4])。第一個步驟可讓您設定套件的預設屬性。這些屬性是存放在 OSD 檔案中，並且包含套件名稱和註解。部分進階設定可讓您指定要從中進行串流處理伺服器、內容目錄，以及套件應該支援的作業系統。
[圖 4] 編序精靈 (按一下以放大影像)
第二步是安裝、設定和測試應用程式。在安裝期間，Sequencer 會擷取對本機系統 (包括檔案系統、登錄和系統) 所做的所有變更。這個精靈還包含一些公用程式，可用來整合像是 Windows Update 等應用程式。
下一個步驟是設定檔案類型關聯，以及指定應該放置捷徑的地方。標準的安置地方包括 [開始] 功能表、桌面和快速啟動列，但您也可以建立自訂位置。
接下來您必須啟動應用程式，並設定初始啟動閾值。在這個步驟中，App-V 會判斷需要傳遞給用戶端，讓應用程式開始執行的應用程式初始部分。
若要設定這段初始程式碼 (一般稱為 Feature Block 1 或 FB1)，只要啟動應用程式，再使用使用者要求的最常用功能即可。例如，啟動 Word 後接著初始化拼字檢查程式。應用程式在這個階段期間呼叫的任何 DLL、檔案或登錄機碼，都會自動指定為 FB1 的一部分。在這個時間點未用到的任何檔案、設定或元件，都會新增到 FB2。接下來使用應用程式時，用戶端會收到 SFT 檔案的對應圖，指出 FB1 開始和停止的地方，以及 FB2 中其他檔案的位置，以便在應用程式需要時，用戶端能夠擷取這些檔案。
編序程序的最後一步，是確保一切都有妥善設定。Sequencer 會顯示 [圖 5] 中所示的對話方塊，當中會呈現 SFT，並允許您對套件做任何最後的新增或變更作業。
[圖 5] 設定和調整最終的套件 (按一下以放大影像)

第 4.5 版
經過兩年的醞釀，App-V 4.5 終於要在今年尾發行。這是本產品的第一個 Microsoft 發行版，它並承諾要推出幾項提升應用程式虛擬化的重要加強功能，例如動態虛擬應用程式互動、擴充的延展性，以及配合 Microsoft 國際化與安全性需求的改善調整。
Dynamic Virtual Application Interaction 可讓虛擬化應用程式彼此進行互動。這種互動關係稱為 Dynamic Suite Composition (DSC)。DSC 並不是要取代新增多個應用程式到相同套件的功能，而是提供一種新管道，整合虛擬應用程式間共用的依存性、中介軟體和外掛程式。
系統管理員可指定哪些虛擬化應用程式可以彼此互動。比方說，假設您有五個 Web 應用程式都需要相同的 Java 版本。在 App-V 4.1 中，您必須在五個不同的套件當中，分別加入相同的 Java 版本。如果那個 Java 版本需要一個修補程式，系統管理員就必須再修補五個不同的套件。但是使用 DSC，即可一次將 Jave 封裝起來，設定成一個套件，讓五個 Web 應用程式使用。因此，修補 Java 時，系統管理員也只需要修補一次 Java 套件就行了。
相同的案例也適用於中介軟體和外掛程式。在 Microsoft 最終的發行版逐漸成形，並完成所有晚期的增補後，我打算再針對其他用途的案例發表部落格。
延展性包括串流處理和後端基礎結構兩方面的增強。後端元件已經過修改，以針對叢集和容錯移轉的案例提供更完備的支援，而串流處理也更適合在 WAN 和 LAN 上使用。這些增強都要拜幾項重要的新增功能所賜。
首先是全新的 Streaming Server 元件，它不需要 Active Directory 的後端基礎結構和 SQL Server，就可以進行串流處理。您仍舊享有視需要傳遞和中央更新套件的各種好處，但少了沉重的後端需求。這可廣泛運用於分公司案例，以及與協力廠商 ESD 解決方案整合的情況。
App-V 用戶端也獲得了幾項增強功能。譬如，用戶端現在是把所有使用狀況資訊存放在本機，以便在用戶端系統連線或離線時，都能追蹤這項資訊。用戶端快取也有所擴展和改良，可以提升磁碟空間有限案例的效能。另外，它也可以編序非英文版的應用程式，在非英文版作業系統上執行 App-V，以及轉換成其他數種語言。

將 App-V 與 Configuration Manager 整合
App-V 4.5 中有不少增強功能和全新功能，都是為了將 App-V 整合至 SCCM 2007 R2 而設計的。我之前已經討論過，虛擬化和串流處理提供的一些功能，可傳遞傳統軟體部署工具沒有提供的應用程式。我不是在暗示 App-V 終將取代這些工具，相反的，它可以補其不足，並且加以擴充。
透過這樣的整合，您可以魚與熊掌兼得，不但可以使用 SCCM 所有的延展性、報告、裝置辨識和 WAN 功能，也可以使用 App-V 所有的串流處理和隔離功能。以下是受惠於這兩種技術整合的幾個領域：
應用程式傳遞：SCCM R2 整合支援視需要傳遞、漫遊應用程式、初始啟動閾值，以及在不修改用戶端電腦下部署應用程式。
更新：SCCM 發佈點 (DP) 在更新套件時，可以只部署虛擬應用程式的差異變更。此舉提供您集中化功能，您只要按個按鍵，就可以將虛擬化應用程式還原為前一個版本。
管理：R2 版推出了全新的虛擬應用程式通告精靈，可讓系統管理員從單一主控台部署虛擬化應用程式，以及傳統軟體套件和通告。
封裝：將 App-V 與 SCCM 整合時，完全不需要重新封裝應用程式。應用程式的初始編序必須在 SCCM 外面使用 App-V 編序完成，但系統管理員還是能夠使用 SCCM 來更新現有的套件。
授權：使用 SCCM 中現有的工具，可追蹤虛擬應用程式來進行授權和計量。
BITS：SCCM 提供一種全新的方法，使用標準 BITS 通訊協定將虛擬化應用程式部署到 App-V。雖然 SCCM DP 可以串流處理，但還是會碰到不適合使用串流處理來部署虛擬化應用程式的情況。在透過 SCCM 進行部署時，您有兩個選擇：使用標準串流處理，或者使用 BITS 的品質服務 (QoS) 功能，以更具控制能力的方式來進行部署。如果您想要在使用者啟動虛擬應用程式之前預先載入快取，這項功能也非常實用。
電腦部署：SCCM 提供的功能，可將虛擬化應用程式部署到特定電腦，以及繼續支援 App-V 平台的使用者型鎖定方法。這一點不但可以協助將虛擬應用程式部署到膝上型電腦、資訊站和實驗室電腦，同時也能夠協助軟體進行依裝置而不是依使用者名稱授權的授權控制。
延展性：必須部署兩種不同、但卻有很多地方重疊的工具，是常見的顧慮。您可以將 SCCM 的延展性和 WAN 優點，與 APP-V 的隔離和串流處理優點彼此整合，以使用現有的 SCCM，提供單一工具來處理兩者的管理和部署作業，而完全不會添增複雜度。

Anthony Kinney 是負責 Microsoft Desktop Optimization Pack 的技術銷售專員。他因 Microsoft 於 2006 年併購 Softricity 而加入 Microsoft。Anthony 任職於 Softricity 時，為 SoftGrid (即現在的 App-V) 編寫及設計了第一個教育訓練程式。您可以透過電子郵件與他聯絡：Anthony.kinney@microsoft.com。


虛擬化
實現 Hyper-V 高可用性
Steven Ekren
綜覽：
  • 使用 Hyper-V 彚總伺服器
  • 確保虛擬機器的高可用性
  • 設定 Windows Server 2008 容錯移轉

目錄
高可用性
主機和來賓
來賓可用性
使 VM 高度可用
先決條件
HA 逐步解說
考量因素
伺服器虛擬化已蓄勢待發，準備在企業 IT 部門掀起軒然大波，而 Hyper-V 與 Windows Server 2008 將助它一臂之力。將伺服器彚總成少數實體機器，在資源和成本方面都有相當大的好處，但在規劃過程中必須考量兩個要素。使用者對軟體可用性的期望是越來越高，包括企業營運 (LOB) 應用程式和工具 (例如訊息和共同作業平台)。另外，伺服器上的問題或失敗對操作所造成的衝擊可能更大。Windows Server 2008 和 Hyper-V 提供的解決方案，可實作用來提供虛擬機器 (VM) 的高可用性 (HA)，也可以實作到 VM 內部主控的工作負載。

高可用性
可用性意謂著使用者可存取系統來進行他們的工作。而高可用性，則代表使用者永遠都可以存取系統的高度期望，因為它正是針對確保操作持續性而設計和實作的。
Hyper-V 的高可用性是藉由使用 Windows Server 2008 容錯移轉叢集功能來達成的。高可用性同時受計畫中和意外的停機所影響，而容錯移轉叢集化可大幅提高這兩種範疇內的虛擬機器可用性。
虛擬機器可由容錯移轉叢集管理，而容錯移轉叢集可用在虛擬機器內監視和移動 VM 中主控的工作負載。這兩種設定案例我都會詳細說明，但本文主要是討論管理虛擬機器。然而，在您開始之前，不妨瞧瞧「實用的 Hyper-V 專有名詞」資訊看板。

主機和來賓
因為在 Hyper-V 系統上執行的作業系統不只一個，要搞清楚討論的是哪一層或哪個 OS 可能頗具挑戰性。我用「來賓」一詞來指 Hyper-V VM 內在子磁碟分割中執行的 OS 和環境，而用「主機」一詞來指實體機器，也就是在 Hyper-V 父磁碟分割上由 OS 管理的機器。
主機可用性可解決隨著伺服器彚總導致「把雞蛋全放在同一個籃子裡」案例可能引起的問題。Hyper-V 父磁碟分割 (主機) 上可設定 Windows Server 2008 容錯移轉叢集，以便監視 Hyper-V 子磁碟分割 (虛擬機器或來賓) 的健康狀態，並且讓它們在叢集的節點之間移動。這項設定具備下列主要優點：
  • 如果執行 Hyper-V 和 VM 的實體機器需要更新、變更或重新啟動，那麼可以將 VM 移到叢集的其他節點。一旦實體機器恢復服務，即可將 VM 移回。
  • 如果執行 Hyper-V 和 VM 的實體機器失敗了 (或許是主機板失敗) 或效能大幅降級，Windows 容錯移轉叢集的其他成員將接下 VM 的擁有權，並自動將它們帶上線。
  • VM 若失敗，可在相同的 Hyper-V 伺服器上重新啟動，或移到其他 Hyper-V 伺服器。這是由 Windows Server 容錯移轉叢集偵測出來的，因此它也會根據 VM 的資源屬性內的設定自動採取復原步驟。停機也因偵測和復原的自動化而盡可能減少。
[圖 1] 呈現在這類的情況下可能發生的事情。首先，VM2 是常駐在主機 A 上，然後被移到主機 B。請注意擁有 SAN 存放裝置 LUN 2 的節點在這項移動作業期間從主機 A 變更為主機 B。為了確保您的高可用性解決方案可滿足您的可用性需要，請審慎考慮放置 VM 的位置。您必須同時考量容量和效能。
[圖 1] 虛擬機器與其存放裝置移到新主機 (按一下以放大影像)
節點的容量應該足以主控所有 VM，並允許 x 數目的節點失敗或離開作用中的叢集 (X 表示您希望叢集可接受失去但仍舊能夠主控所有 VM 的節點數量)。在決定容量時，您可以選擇保留一些節點，不讓它們定期裝載 VM。或者，您可以選擇將 VM 散置在所有節點間，確保各個節點都有足夠的額外容量，以便在有任何 x 數目的節點失敗時，順利接掌擁有權並啟動 VM。
基於日常效能的理由，將 VM 散置在叢集的所有節點間可能比較恰當。如果節點被保留起來而且沒有主控任何 VM，那麼主控 VM 的節點會使用更多的資源，而這可能會降低 VM 以及管理磁碟分割的效能。將 VM 散置在節點間可減輕每個節點的負載，而且可為 VM 和管理磁碟分割提供較佳的效能。不過，它也可能使容量規劃更具挑戰性。在這方面，管理軟體 (例如 System Center Virtual Machine Manager 2008) 可提供節點失敗和 VM 配置的預估容量來助您一臂之力。

來賓可用性
來賓可用性主要是要讓在 VM 內部執行的工作負載高度可用。常見的工作負載包括檔案和列印伺服器、IIS 和 LOB 應用程式。針對 VM 內部的工作負載分析高可用性的需求和解決方案，跟在獨立伺服器上進行分析沒什麼太大的差別。解決方案將視特定的工作負載而定。
有些工作負載可透過 Windows 網路負載平衡 (NLB) 達到高可用性，這允許多部伺服器成為具有共同網路名稱的集區的一部分。用戶端可使用虛擬網路名稱提出連線要求，而連線會連接到 NLB 叢集的其中一個節點。使用 NLB 叢集的典型案例是使用 IIS 建置 Web 伺服陣列，當中各個系統的 IIS 都有相同的網頁，並存取相同的資料。NLB 除了提供負載平衡之外，也提供移除伺服器成員資格以利維護，或是在伺服器發生問題時移除伺服器成員資格的功能，因而提供某種程度的高可用性。如果 Hyper-V VM 是執行 Windows Server 2008 (或是包含 NLB 的舊版 Windows Server)，那麼來賓可以與相同或不同 Hyper-V 主機上的其他來賓同為 NLB 叢集的成員。
執行 Windows Server 2008 的來賓可使用 Windows 容錯移轉叢集功能，為它們的工作負載提供高可用性。在來賓內使用 Windows 容錯移轉叢集 (來賓叢集化) 有幾個優點：
工作負載狀況監控 Windows 容錯移轉叢集有個資源監視器可呼叫叢集相關的資源 DLL。每項資源都有狀況監控會測試該資源所管理的應用程式或服務，以確保它的運作正確無誤。這些檢查一般稱為 isAlive/looksAlive 檢查。如果資源無法完成其中一個呼叫，該資源本身也會失敗。視資源的屬性而定，資源可能會嘗試重新啟動服務或應用程式，或者可能會被移到 Windows 容錯移轉叢集的其他節點。
虛擬機器維護 若是 VM 的設定需要變更，或是 OS 或軟體需要更新或變更，可將工作負載移到叢集的其他節點，而 VM 會關機或是在盡可能不中斷使用者的情況下進行更新。
主機維護 假如主控 Hyper-V VM 的實體機器需要維護或是軟體更新，而 Windows 容錯移轉叢集的其他成員位於不同的 Hyper-V 主機上，可以將 VM 中的工作負載移到叢集的其他節點，並將該 VM 關機以配合實體伺服器的變更或重新開機。
虛擬機器或主機失敗 實體 Hyper-V 主機或虛擬機器來賓若產生失敗，Windows 容錯移轉叢集的其他節點會偵測到該叢集成員已不再回應或參與叢集，而繼續存在的節點會將失敗 VM 上執行的應用程式或服務帶上線。

實用的 Hyper-V 專有名詞
以下專有名詞列表有助於定義高度可用的 Hyper-V 系統 (主機叢集) 元件或功能。
父磁碟分割 在 Hypervisor 伺服器上執行的所有作業系統都有配置的硬體資源，包括 RAM、CPU 和其他系統元件。在 Hyper-V 中，管理 Hypervisor 的設定和系統資源的磁碟分割通常稱為父磁碟分割。當設定好 Hyper-V 角色，而且伺服器也重新開機之後，在系統上為原生 OS 的 Windows Server 2008 安裝遂變成 Hyper-V 伺服器的父磁碟分割中的 OS。
子磁碟分割 Hyper-V 伺服器上設定成存放虛擬作業系統以及提供硬體資源給該作業系統的隔離環境。
Hyper-V 主機 主控 Hyper-V 以及在父磁碟分割內執行的作業系統的實體伺服器。
Hyper-V 虛擬機器 Hyper-V 設定資訊和用來啟動和執行 Hyper-V 子磁碟分割的資料。這包括用來建立子磁碟分割和 VHD 檔案或穿透包含其資料之磁碟的設定資訊。
穿透式磁碟 在 [磁碟管理] 中公開成實體磁碟，並指定由 Hyper-V 來賓專用的存放裝置。Hyper-V 來賓會掛接磁碟，並將它當作本機連線的存放裝置一樣使用。
虛擬硬碟 (VHD) 由向作業系統公開成存放裝置 (磁碟) 的 Hyper-V 子磁碟分割連接的檔案。.vhd 檔案是位在由父磁碟分割掛接的存放裝置上，而且可以作為直接連接的存放裝置，或作為透過 SAN、NAS 或 SMB 連接的存放裝置。
使 VM 高度可用
要將虛擬機器設為高度可用很簡單，只要在 [容錯移轉叢集管理] 下完成「HA 角色精靈」就行了。Hyper-V 虛擬機器有幾個重要的元件在管理成高度可用時，需要特別列入考量。讓我們來看看一些重要的概念和一般的先決條件。
容錯移轉叢集節點 屬於容錯移轉叢集一部分的每一部實體伺服器都稱為節點。對於主機叢集化，容錯移轉叢集服務是在 Hyper-V 系統的父磁碟分割上的 Windows Server 2003 中執行。這可讓在相同實體伺服器上的子磁碟分割內執行的 VM 被設定成高度可用的虛擬機器。針對 HA 設定的虛擬機器將會在 [容錯移轉叢集管理] 主控台中顯示為資源。
HA 存放裝置 您可將高度可用的虛擬機器設定成使用虛擬硬碟 (VHD)、穿透式磁碟和差異磁碟。為了讓虛擬機器能夠在容錯移轉叢集節點之間移動，需要有存放裝置 (在 [磁碟管理] 中顯示為磁碟) 供任何可能主控 VM 而且由容錯移轉叢集服務管理的節點存取。穿透式磁碟應該作為磁碟資源新增到容錯移轉叢集中，而 VHD 檔案必須位於作為磁碟資源新增到容錯移轉叢集的磁碟上。
虛擬機器資源 這是代表虛擬機器的容錯移轉叢集資源類型。當虛擬機器資源上線時，Hyper-V 便會建立子磁碟分割，並且會啟動虛擬機器中的 OS。虛擬機器資源的離線功能會在主控 VM 的節點上將它從 Hyper-V 中移除，而且子磁碟分割也會從 Hyper-V 主機移除。若虛擬機器關機，停止或置於儲存狀態，這項資源將被置於離線狀態。
虛擬機器設定資源 這是用來管理 VM 的設定資訊的容錯移轉叢集資源類型。每台虛擬機器都有一項虛擬機器設定資源。這項資源的屬性包括設定檔的路徑，而這個檔案包含將虛擬機器新增到 Hyper-V 主機所需的全部資訊。虛擬機器資源必須存取設定檔才能啟動。由於設定是由不同的資源所管理，因此即使 VM 處於離線狀態，還是可以修改 VM 資源的設定。
虛擬機器服務及應用程式群組 若要透過容錯移轉叢集使服務或應用程式高度可用，相同容錯移轉叢集節點上必須裝載多項資源。為了確保這些資源永遠位於相同的節點上，而且彼此適當交互操作，會將資源放到一個 Windows Server 2008 容錯移轉叢集稱為「服務或應用程式」的群組裡面。VM 的虛擬機器資源和虛擬機器設定資源始終都是位於相同的「服務或應用程式」群組內。「服務或應用程式」群組中也可能有一或多個包含 VHD 或設定檔案或穿透式磁碟的實體磁碟 (或其他存放裝置類型) 資源。
資源依存性 請務必確保在讓虛擬機器資源上線 (啟動) 前，先將虛擬機器設定資源帶上線，而且將虛擬機器資源先帶離線 (停止) 之後，再讓虛擬機器設定資源離線。設定虛擬機器資源的屬性，讓它依賴虛擬機器設定資源，藉此確保此上線/離線的順序。如果有個存放裝置資源包含用於虛擬機器設定資源或虛擬機器資源的檔案，就應該將該資源設為依賴該存放裝置資源。比方說，假如虛擬機器使用磁碟 G: 和磁碟 H: 上的 VHD 檔案，就應該使虛擬機器資源仰賴設定檔資源和磁碟 G: 上及磁碟 H: 上的資源。

先決條件
下面是使用 Windows Server 2008 容錯移轉叢集功能使 Hyper-V 虛擬機器高度可用的三項先決條件：
  1. 必須為叢集的每個節點設定 Windows Server 2008 容錯移轉叢集功能。如需關於設定和管理容錯移轉叢集的詳細資訊，請參閱「Hyper-V 資源」資訊看板。
  2. 必須安裝 Hyper-V 角色。應該針對容錯移轉叢集的每個節點安裝 Hyper-V 更新，以及設定角色 (也請參閱「Hyper-V 資源」資訊看板)。Hyper-V 有個更新套件會安裝 Hyper-V 伺服器元件，還有另一個更新套件會安裝 Hyper-V 管理主控台。一旦為 Hyper-V 伺服器元件安裝好更新之後，就可以透過伺服器管理員或 ServerManagerCMD 新增角色。
  3. 您必須提供共用存放裝置給虛擬機器使用。存放裝置可由容錯移轉叢集當作內建實體磁碟資源類型加以管理，或者您可以使用協力廠商解決方案來管理共用存放裝置。當然啦，協力廠商解決方案必須支援 Windows Server 2008 容錯移轉叢集才行。

HA 逐步解說
現在讓我們來看看高可用性解決方案要怎麼設定。第一步是設定虛擬機器，在裝有 Hyper-V 角色的容錯移轉叢集的其中一個節點上，使用 Hyper-V 管理員設定一台虛擬機器 (見 [圖 2])。這可以是手動設定的新 VM，或者您可以匯入現有的 VM。VHD 應該位在 Windows Server 2008 容錯移轉叢集所管理，而且目前在設定 VM 的節點上是處於線上狀態的磁碟上。
[圖 2] 設定虛擬機器 (按一下以放大影像)
現在把虛擬機器置於停止狀態，方法是將它關機、關閉或儲存狀態。唯有處於停止狀態的虛擬機器才能設定由容錯移轉叢集管理。
在執行 Windows Server 2008 容錯移轉叢集角色的任何伺服器上，或是在執行遠端伺服器管理工具 (RSAT) 的 Windows Vista 用戶端上開啟 [容錯移轉叢集管理] 主控台 (如 [圖 3] 所示)。連接到容錯移轉叢集，方法是選取 [管理叢集...] 動作，然後選取一個節點或叢集名稱，或是選取在執行主控台的節點上連接到叢集的選項。
[圖 3] 容錯移轉叢集管理中的虛擬機器 (按一下以放大影像)
從 [容錯移轉叢集管理] 主控台，選取 [設定服務或應用程式...] 動作。這會開啟「高可用性精靈」，這個精靈會帶您完成設定要由容錯移轉叢集管理的服務、應用程式或虛擬機器。在精靈的 [選取服務或應用程式] 頁上，選取 [虛擬機器]，然後選取 [下一步]。
[選取虛擬機器] 頁會顯示在容錯移轉叢集的任何節點上設定的所有虛擬機器。選取一台虛擬機器，再選取 [下一步]。精靈的 [設定] 頁將顯示任何警告或錯誤。在這個步驟中，會檢查虛擬機器設定，以確認可以將它設定成 HA 資源，而且節點應該能夠裝載它。在此處選取 [下一步] 會將虛擬機器作為高度可用資源新增到容錯移轉叢集。
[摘要] 頁提供了將虛擬機器新增為高度可用資源的相關結果，包括任何警告。[檢視報告…] 按鈕會向您顯示讓虛擬機器高度可用所進行的工作的詳細資料，以及任何警告或錯誤。最後，選取 [完成] 來關閉「高可用性精靈」。
如 [圖 3] 中的視窗所示，[容錯移轉叢集管理] 主控台會將具有預設名稱 Virtual Machine(x) 的物件列在左窗格中的叢集名稱和 [服務或應用程式] 下方。從樹狀結構選取虛擬機器，屬於該「服務或應用程式」群組的資源便會顯示在主控台的中間窗格中。如果有任何其他虛擬機器的檔案同樣位於所選虛擬機器的存放裝置上，那麼也會將它新增到群組中。對於每台放入群組的虛擬機器，都會顯示虛擬機器和虛擬機器設定資源。
「服務或應用程式」群組的資訊窗格會顯示該群組的 [狀態]、[警示]、[慣用擁有者] 和 [目前擁有者] 資訊。[擁有者] 節點是目前設定或執行的虛擬機器所在的節點。選取 [將虛擬機器移到其他節點 (Move Virtual Machine(s) to another node)] 動作，將虛擬機器帶離線，然後在另外一個節點上帶上線。一般最佳的作法是，將 VM 移到容錯移轉叢集中可以主控它的各個節點，來確認該項移動作業進行順利，而且 VM 可以啟動和執行。

Hyper-V 資源
  • 適用於 Windows Server 2008 的 Hyper-V 技術發行版的更新說明 (英文)
  • Hyper-V 逐步指南：測試 Hyper-V 和容錯移轉叢集 (英文)
  • Windows Server 2008 容錯移轉叢集簡介 (作者 Chuck Timon，2008 年 7 月號《TechNet Magazine》)
  • NLB 主機在 Windows Server 2008 Hyper-V 虛擬機器上的作用範圍不如預期 (英文)
  • Win2008 叢集網路廣播 (英文)
  • Windows Server 2008 容錯移轉叢集的 Microsoft 支援原則 (英文)
考量因素
以下是在設定虛擬機器的高可用性時，需謹記在心的一些重點：
存放裝置 如果虛擬機器在相同的共用磁碟上含有 VHD 檔案，那麼即使它們是位於相同磁碟的不同磁碟區上，還是會被放在相同的「服務或應用程式」群組中。共用磁碟的優點之一，就是它能更妥善地利用可用的共用存放空間。
然而，需要取捨的是，虛擬機器每次一經移動，無論是因為虛擬機器發生問題而自動復原，還是因為系統管理員選擇這麼做，群組當中所有的虛擬機器都會跟著一起移動。
磁碟機代號和 GUID 您可以不指定磁碟機代號來建立磁碟區。虛擬機器還是可以使用這些磁碟區，而磁碟區可由容錯移轉叢集來管理。如果磁碟資源擁有的磁碟區使用的是 GUID 而不是磁碟機代號，則該 GUID 會顯示在 [叢集管理] 中。當您建立虛擬機器並為 VHD 指定路徑時，請務必確定路徑中的 GUID 與該磁碟區顯示在 [叢集管理] 中的 GUID 相符。如果不符，虛擬機器可能無法在容錯移轉叢集的其他節點上順利啟動 (上線)。
有幾種情況可能會導致 GUID 不符。若磁碟區是在節點當作容錯移轉叢集管理的磁碟資源新增之前被帶上線，該磁碟區在每個節點上便可能具有不同的 GUID。磁碟區也可能在單一節點上擁有多個 GUID。當把磁碟當作實體磁碟資源新增到容錯移轉叢集時，在磁碟處於線上狀態的節點上所使用的磁碟區 GUID 會在磁碟資源的屬性內註明。
磁碟區的 GUID 會在磁碟資源帶上線時新增到節點。這可確保容錯移轉叢集為磁碟區註明的特定 GUID 在帶磁碟上線的任何節點上，都是有效的路徑。該節點可能擁有其他也與相同磁碟區相關聯的 GUID。因此，使用者可能會在該節點上找到對磁碟區來說有效的 GUID，但它並不是容錯移轉叢集確定可用在其他節點上的磁碟區的同一個 GUID。這個問題的徵兆是虛擬機器資源 (通常是設定資源) 無法上線，並且會顯示錯誤訊息來指出路徑是無效的。錯誤訊息中的路徑顯示的是 GUID 並不是叢集為磁碟區管理的 GUID。
掛接點 掛接到其他磁碟區中的資料夾，而不是指定磁碟機代號或使用 GUID 的磁碟區，可與 Hyper-V 和容錯移轉叢集搭配使用。由於掛接的磁碟區與主控掛接點的磁碟區兩者都必須位在相同的容錯移轉叢集節點上，因此您必須讓屬於掛接點一部份的所有磁碟都位於相同的容錯移轉叢集「服務或應用程式」群組內。
假如磁碟區都位在相同的磁碟上，這很顯然並不構成問題。然而，要是磁碟區位在不同的磁碟上，肯定會造成問題。同樣很明顯但還是值得一提的是，掛接的磁碟區與掛接點的主機兩者都必須是設定為受容錯移轉叢集管理的共用存放裝置。
差異磁碟 屬於差異磁碟一部分的所有 VHD 檔案在「服務或應用程式」群組中都必須位在與使用差異磁碟的 VM 一樣的共用存放裝置上。設定最簡單的差異磁碟有兩個 VHD。一個 VHD 是父代，並且擁有一組用作為基底的資料。另一個 VHD 是與父代相關聯的子代。
差異磁碟在初次使用時看起來就像父代一樣。如果資料是位在父代，就會從該 VHD 讀取。所有的寫入作業都是發生在子代 VHD 上。假如資料是位在子代上，那麼對該資料的讀取作業會參考子代 VHD。
若 VM 因某種原因而設定成讓子代 VHD 位在共用存放裝置上，但父代 VHD 卻不在相同群組的共用存放裝置上，也不位在從本機連接的存放裝置上，那麼 VM 在被移到其他節點後將無法啟動 (上線)。「高可用性精靈」應該檢查以確保這在 VM 的設定正確，並且在偵測到這個問題時提供錯誤訊息，但要特別注意變更 VM 設定的情況下的需求。

Steven Ekren 在 Windows Server 容錯移轉叢集和高可用性小組擔任資深專案經理一職。Steven 在 Microsoft 技術支援投入了 12 年的時間，協助企業客戶實作和疑難排解 Windows Server 容錯移轉叢集與虛擬化技術，包括 Windows Hyper-V、System Center Virtual Machine Manager、Microsoft Virtual Server 和 Microsoft Virtual PC。


虛擬化
伺服器虛擬化的備份和嚴重損壞修復
Adam Fazio
綜覽：
  • 規劃嚴重損壞修復的考量因素
  • 嚴重損壞修復的高可用性解決方案
  • 透過 Windows Server Backup 進行備份和還原

目錄
嚴重損壞修復規劃 101
嚴重損壞修復和虛擬化
實體轉虛擬
虛擬機器快照集
備份 Hyper-V
Windows Server Backup
使用 WSB 備份 VM
考量因素
使用 WSB 還原 VM
Data Protection Manager
指令碼式備份
DiskShadow
總結
隨著伺服器虛擬化技術逐漸成形，以及業界廣為採納，各組織也開始發現虛擬化所提供的好處遠超過普遍的理由：降低基礎結構成本，以及提高 IT 靈活度。下一個境界是運用虛擬化平台作為提供或加強嚴重損壞修復 (DR) 策略的途徑。
DR 的整備為什麼一直以來都是 IT 產業面臨的最熱門話題之一呢？相關研究指出，公司停機每小時平均損失 $80,000 到 $90,000 美元，鮮少有公司能從毀滅性資料損失長期倖存下來。本文將介紹使用 Microsoft 虛擬化平台的 DR，還會深入探討 Windows Server 2008 Hyper-V 的備份和還原選項和考量因素。

嚴重損壞修復規劃 101
DR 是指在停機的情況下還原關鍵服務的過程，而且應該屬於每家公司業務持續性計畫的一部分，其中定義著公司在碰到這類災難期間或之後要如何繼續運作。這些計畫是任何 DR 行動的基石。
有些廠商宣稱它們的 DR 自動化技術不太需要或完全不需要詳盡和充分演練的計畫。雖然自動化能夠改善修復的時間，並降低對人為介入的依存，在此還是要做個公眾服務通告：光靠技術是無法成功舒緩大災難的。人員和程序一向與技術同等重要。
事實上，您會發現到若不先認識 DR 規劃過程中出現的所有限制和目標，要選擇適當的技術是不可能的。雖然定義整個 DR 計畫已超過本文討論範圍，但我還是要強調一下選擇適當技術和實作的必備要素。所以，就讓我們迅速簡述一下 DR 計畫當中一些重大的技術推動力吧。
服務定義和優先處理您想要保護的整個服務定位在哪哩，還有它對於貴公司有多重要？[圖 1] 顯示任何 DR 計畫中可能包含的公司服務範例。
[圖 1] 服務定義和優先處理範例
服務 | 主要元件 | 依存性 | 商業用途 | SLA
公用網站 | 網路負載平衡器，三部網頁伺服器，兩部資料庫伺服器 | DNS，網路，防火牆，目錄，儲存區域網路 (SAN) 存放裝置 | 產品採購和訂單追蹤，電子商務，客戶支援入口，公司資訊 | 99.99%
財務系統 | 兩部資料庫伺服器，一部應用程式伺服器 | DNS，網路 | 記錄公司營收，如法規所要求 | 99.99%
電子郵件系統 | 三部電子郵件伺服器，一部網頁伺服器 | DNS，網路，防火牆，目錄 | 公司通訊，客戶支援 | 99.5%
一定義好服務之後，就可以開始確認要針對哪種 DR 策略，鎖定哪些系統和依存性。您可能會在看過整組服務和依存性之後，才發現到您需要考慮幾個不同等級的 DR 功能，因為若將單一 DR 解決方案用於所有關鍵型服務，可能過於昂貴和複雜。
服務等級協定 (SLA) SLA 是服務提供者 (IT) 與客戶 (公司) 之間，針對指定服務來定義可用性目標的協定或合約。這些協定可長可短，也可以很親切，例如「電子郵件系統除了排定的維護作業期間外，一般營業時間內的可用度為 99.95%，而在非一般營業時間則為 98%，每月都會進行測量」。SLA 通常會分成幾個可指定 IT 服務的階層，並且在預先定義的時段內進行測量。
作業等級協定 (OLA) OLA 基本上是幾個共同支援 SLA 的 IT 群組之間所訂下的協定，包括提供其服務的程序和回應時間。假設您關鍵型網站的 SLA 目標為 99.99%，但是它的內容所仰賴的資料庫，其可用性目標只有 95%。那麼 OLA 可幫助您釐清這些不協調的現象，讓 IT 小組合作朝著相同的目標前進。
復原點和復原時間目標 (RPO/RTO) RTO 是指服務可以停擺多久持續性才會中斷，而 RPO 則是公司認為可以接受的資料損失等級。因此，如果服務每月測量得到 99% 的 SLA，它的 RTO 就是 7 個小時和 18 分鐘。如果您把該值與比方說 24 小時的 RPO 配對，就可以準確定義您的備份方法和排程了。
資料保留原則 公司的資料保留原則所指定的是備份要保留多久的時間，以及保留在哪裡。這些通常是依據法規的需求而定。
資料分類 另外，您還應該考慮資料的本質。如果您把資料分門別類，很快就可以看出並非所有資料都需要考慮採用相同等級的 DR。比方說，單一資料庫的可用性需求，可能與含有多個網域控制站、各自都包含目錄複本的 Active Directory 截然不同。同樣地，檔案伺服器資料的還原程序，也可能與 CRM 資料大相逕庭。
嚴重損壞的案例 針對所有您想要規劃的案例下定義是很重要的，因為每個都會有不同的還原程序、業務衝擊，以及相關聯的成本。您可以分析所有可能的案例，然後在針對您的環境進行 DR 規劃時，決定想要鎖定哪一個案例目標，這個做法很有幫助。
  • 喪失整個網站
  • 喪失單一資料中心
  • 喪失系統 (作業系統或硬體失敗)
  • 喪失資料 (資料刪除或損毀)
  • 喪失關鍵依存性
復原喪失的整個網站，與復原喪失的單一系統，兩者要考量的因素完全不同。您也需要根據 SLA 來定義復原閾值。譬如，讓我們假設整個網站是因為主要的 ISP 網路中斷而離線。如果根據 SLA，受影響的服務需要 8 個小時來還原服務，需要 48 個小時來還原資料，您可能會選擇將服務容錯移轉到備份網站，而不會執行資料復原程序，因為這麼做預計很快就會回復到實際執行的網站了。
哎呀！連相關技術都還隻字未提，就這麼煞費周章了！千萬不要低估規劃的必要性，DR 實作若沒有根據記錄下來的計畫進行，不過是「DR 空談」罷了。

嚴重損壞修復和虛擬化
DR 規劃的基礎討論完畢之後，接下來要看看虛擬化扮演什麼角色。許多公司都指出，虛擬化伺服器只需幾分鐘的時間就能夠還原完成，比起需要好幾天、甚至好幾個星期還原的實體伺服器來說快多了。因為整個伺服器作業系統不過是一組擷取自基礎實體硬體的檔案，因此為復原性開啟了新視野。
當今普遍的理論都認為部分或全部的 DR 目標，可以透過高可用性 (HA) 解決方案達成。其構想是假設您在不同的實體位置安置了叢集節點，而且各站台間的資料都保持同步，萬一發生失敗時，被動節點仍然可以繼續運作，您因此得以在近乎即時的情況下復原。
這一點是沒有錯，但要是您回想一下前文定義的嚴重損壞案例，就不難發現這並不是適用於所有案例的解決方案。您需要結合各項技術為所有案例做好準備，而這一般包括某種形式的定期備份。HA 並不能為所有可能的停機提供保障，而且它多少也需要某種形式的備份策略。
若將 HA 搭配 Hyper-V 使用，必須審慎規劃存放裝置層，因為這是復原的關鍵要素。舉例來說，如果雙節點 Hyper-V 叢集含有共用存放裝置，還是會有存放裝置子系統和資料這個單一失敗點，即使叢集節點位於不同的資料中心也一樣。
但是，如果同樣的雙節點 Hyper-V 叢集所含的是非共用存放裝置，它的其中一個節點或另一個節點，就能逃過存放裝置或資料損失的毀滅。不過，這需要複寫技術才能使存放裝置保持同步，而且程序非常複雜 (見 [圖 2])。
[圖 2] 多站台 Hyper-V 叢集 (按一下以放大影像)
資料複寫和同步處理領域的發展有的非常有趣，但是都與 Microsoft 目前提供的無關。您不妨看看 Windows Server 2008 多站叢集網頁 (microsoft.com/windowsserver2008/en/us/clustering-multisite.aspx) 所展示的合作夥伴。另外一項資源是 Windows Server Catalog (請參閱 windowsservercatalog.com)，當中列有具有經過 Windows Server 2008 認證提供之複寫技術的存放裝置廠商。
如您所見，您要考慮的 HA 和存放裝置設定相當多。這也是為什麼您必須定義商務要求，並透過它們來推展技術需求，而不是反其道而行的原因。

實體轉虛擬
虛擬化顯然提供了一些獨一無二的復原靈活性，但那些不適合虛擬化的實體系統怎麼辦呢？System Center Virtual Machine Manager (SCVMM) 可以對執行中的 Windows 伺服器進行實體轉虛擬 (P2V) 作業，而產生與實體來源伺服器完全一樣的可開機 Hyper-V 虛擬機器 (VM)。因此，現在您就可以跨園區或跨國界來複寫這個 VM，就像複寫虛擬化機器一樣，達到類似的復原效果。
這套方法與傳統裸機還原的不同之處在於，復原位置中的實體系統數量或類型，不必與實際執行位置一樣。因此，您可以超量預訂復原硬體，並在需要的時候，依據嚴重損壞的影響狀況加以擴充。
雖然 SCVMM 還沒有預定推出 P2V 轉換的時間表，不過既然 GUI 可完全以 Windows PowerShell 為基礎來執行，使用 New-P2V 指令程式很容易就可以編寫出轉換的指令碼。事實上，SCVMM 中所有的精靈都會顯示它們用來執行工作的程式碼，而且您可以在環境內複製測試 P2V 的程式碼，加以修改供未來自動化之用。[圖 3] 顯示一些範例程式碼，您可以在環境內執行 SCVMM P2V 精靈，以取得獨特且可自訂的 Windows PowerShell 指令碼。
[圖 3] SCVMM P2V 精靈所產生的程式碼
$Credential = get-credential

New-MachineConfig -VMMServer <VMM SERVER> -SourceComputerName "<SOURCE P2V SERVER>"
-Credential $Credential -RunAsynchronously

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -SourceNetworkConnectionID "00:14:D1:3C:66:2F"
-PhysicalAddress "00:14:D1:3C:66:2F" -PhysicalAddressType Static -VirtualNetwork "External"
-MachineConfig $MachineConfig

$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -VMMServer <VMM SERVER> -VMHost $VMHost -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -VolumeDeviceID "C" -Dynamic -IDE -Bus 0 -LUN 0 -MachineConfig $MachineConfig

$Credential = get-credential
$VMHost = Get-VMHost -VMMServer <VMM SERVER> | where {$_.Name -eq "<TARGET HYPER-V HOST>"}
$MachineConfig = Get-MachineConfig -VMMServer <VMM SERVER> | where {$_.Name -eq "<SOURCE P2V SERVER>"}

New-P2V -Credential $Credential -VMMServer <VMM SERVER> -VMHost $VMHost -Path
"C:\ProgramData\Microsoft\Windows\Hyper-V" -Owner "DOMAIN\username" -RunAsynchronously -JobGroup
e823f50d-dbc7-4a41-9087-fb01bb44dc26 -Trigger -Name "<SOURCE P2V SERVER>" -MachineConfig
$MachineConfig -CPUCount 1 -MemoryMB 512 -RunAsSystem -StartAction NeverAutoTurnOnVM
-UseHardwareAssistedVirtualization $false -StopAction SaveVM

虛擬機器快照集
VM 快照集在技術上雖然不是備份，但它提供了一個可讓您使用差異磁碟和 VM 設定檔複本進行還原的時間點。假如嚴重損壞意外刪除了 VM 內部的資料，便可將這視作 DR 功能，因為您可把 VM 回復到快照集，將所造成的損害復原 (我們稍後會探討磁碟區陰影複製服務 (或 VSS) 快照集)。

備份 Hyper-V
主機型備份 伺服器虛擬化最令人雀躍的優點之一，就是可以不用再個別備份虛擬化系統。既然這些系統現在不過是存在主機檔案系統上的檔案，那麼直接備份檔案不就好了嗎？事情可沒那麼簡單，因為這些都是由記憶體中的資料，磁碟、系統和設定上的資料，以及開啟檔案所構成的即時電腦，有幾件事需要考慮。那麼我們要如何確保所有這些活動組件的備份資料都能保持一致呢？
Windows Server Backup 故事的一大轉折要拜 Windows Server 2003 和 VSS 的問世所賜，其中的改進提供了一組標準的可延伸 API，可讓 VSS 寫入器 (會連接到應用程式和服務，幫助提供一致的陰影複本) 用來建立開啟檔案和應用程式的備份。有了 VSS 服務、提供者和寫入器的鼎力相助，備份應用程式很快就能夠產生磁碟區的時間點複本，應用程式不但能感知這樣的複本，也能適當進行處理。
Hyper-V 有自己的 VSS 寫入器，容許軟體製造商建立陣容堅強的備份解決方案。寫入器可讓備份應用程式對執行中的 VM 進行主機型 VSS 備份。假如在 VM 內部執行的作業系統同時裝有 Hyper-V 整合元件和 VSS 服務 (Windows XP SP1 和 Windows Server 2003 及其後版本皆有提供)，那麼主機型備份便會像在來賓內部執行一樣進行，備份會在 VM 處於執行狀態時執行，而且資料將會保持一致 (見 [圖 4])。
[圖 4] VSS 備份 (按一下以放大影像)
然而，要是虛擬作業系統不支援整合元件或 VSS，備份程序會要求把來賓機器置於儲存狀態，並且要求製作 VM 資料檔案的主機 VSS 快照集，以便用於時間點復原。處於儲存狀態的 VSS 快照集會產生一些 VM 停機時間 (一般可以限制為 5-10 分鐘的時間)，對資料的 VSS 複本進行完整的備份到磁帶程序。
來賓型備份 在實際環境中，伺服器和應用程式都需要個別進行備份，而這樣的備份方式也必然會延用到虛擬化資料中心。因此，備份 VM 時也要考慮相同的因素，例如網路型備份的網路容量需求，以及備份期間對系統的效能衝擊等。透過來賓型備份，您可以選擇在主機中擁有一個專用的實體 NIC，繫結到所有來賓使用的虛擬網路。

Windows Server Backup
Windows Server 2008 內含具備 VSS 功能的 Windows Server Backup (WSB)，可用來執行 VM 的 Hyper-V 主機型和來賓型備份。因為它具備完整的 VSS 功能，所以能夠對執行中的 VM 執行主機型備份，而這也是慣用的備份方式。
但若是您的 VM 沒有安裝整合元件，則不會使用 VSS。在這種情況下，您有幾個選擇，您仍舊可以使用 WSB 來備份沒有安裝整合元件的 VM，也就是說，VM 的狀態將會儲存下來，然後備份會抓取 VM 的虛擬磁碟和設定檔。
不過，這種作法對於像是 Exchange 之類的應用程式可能不太恰當，因為應用程式無法感知備份已經執行，而且應用程式記錄檔也不會被截斷。此外，VM 也會發生停機，視備份所花的時間而定。
另外一個可行的方法是，把 VM 當作實體機器一般，使用 NTBackup 或 WSB (視 VM 的 OS 而定) 從 VM 內部執行備份。讓我們來看看要如何將 WSB 用於裝有整合元件的支援來賓。

使用 WSB 來備份 VM
Hyper-V 並不會自動註冊它自己的 VSS 寫入器，以與 WSB 搭配使用。您必須手動新增 [圖 5] 所示的登錄機碼和值後，WSB 才會支援 Hyper-V 備份。您可以透過命令列來新增它們，如下所示：
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}"
reg add "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /v
  "Application Identifier" /t REG_SZ /d Hyper-v
[圖 5] 用於註冊 Hyper-V VSS 寫入器的機碼和值
路徑 | 登錄機碼或值 | 類型
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\ {66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE} | 機碼 | n\a
HKLM\Software\Microsoft\windows nt\currentversion\WindowsServerBackup\ Application Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}\Application Identifier | 值 | REG_SZ (例如，Hyper-V)
這個動作並不需要重開機，因為 WSB 會在備份執行階段搜尋這個機碼/值。下列命令將顯示項目是否已設定：
reg query "HKLM\Software\Microsoft\windows nt\
  currentversion\WindowsServerBackup\Application
  Support\{66841CD4-6DED-4F4B-8F17-FD23F8DDC3DE}" /s
以下說明如何安裝 WSB。按一下 [開始] | [伺服器管理員]，再依序按一下左窗格中的 [功能]，和右窗格中的 [新增功能]。然後在 [選取功能] 頁上展開 [Windows Server Backup 功能]，並勾選 [Windows Server Backup] 和 [命令列工具] 核取方塊。接著按照下列步驟來設定您的備份：
  1. 前往 [開始] | [系統管理工具] | [Windows Server Backup]。
  2. 若是備份遠端主機，請選取 [連線到另一台電腦]，然後輸入 Hyper-V 主機。
  3. 選擇 [單次備份] 或 [備份排程]。
  4. 選擇備份設定 — [完整伺服器] 或 [自訂]。若選取 [自訂]，請務必加上所有包含您備份之 VM 相關資料 (包括 VM 設定資料、虛擬磁碟和快照集) 的磁碟區。
  5. 選擇要存放備份的位置。
  6. 選擇 [VSS 完整備份] 或 [複製備份]。如果是主機型備份，也就是 VM 沒有在進行其他備份，請選擇 [VSS 完整備份]。
  7. 一旦確認詳細資料後，請選取 [備份]。
考量因素
  • 您必須備份與 VM 相關的所有磁碟區，包括虛擬硬碟 (VHD)、VM 設定檔和快照集在內。
  • 如果您要建立備份排程，必須使用可經過格式化並完全由 WSB 使用的專用本機磁碟區。相反的，如果您執行的是單次備份工作，則可以把備份存放在非專用的本機磁碟區、卸除式裝置或網路共用上。
  • 若是在備份的 VM 內未安裝整合元件，WSB 會儲存執行中的 VM 狀態，以確保備份資料的一致性。
  • 完成後，備份組便具備可攜性，而且可與任何 Hyper-V 主機搭配使用。
使用 WSB 來還原 VM
雖然 WSB 確實具備還原個別檔案的功能，但這項功能並不會使用 VSS，因此若是 VM 在備份當時處於執行狀態，可能會導致還原不一致。若要還原執行中的 VM，您必須還原整個磁碟區。
如果要這麼做，必須前往 [開始] | [系統管理工具] | [Windows Server Backup]，在 [執行窗格] 中選取 [復原]。然後選取要從中復原資料的伺服器 (WSB 備份資料所在的伺服器)，再選取要從該資料還原的資料。接著就可以選擇復原類型了。
您必須在這裡做個決定，如果您需要整個 VM，包括它的設定、快照集和虛擬磁碟 (譬如，在發生主機徹底失敗的情況下)，請依序選取 [應用程式還原] 和 [Hyper-V]，如 [圖 6] 所示。在這種情況下，您不能選擇還原個別檔案，必須還原包含在該備份組內的一切項目。請注意，這個動作並不會覆寫自上次備份以來變更的現有 Hyper-V 和 VM 設定資料。
[圖 6] 還原 Hyper-V 備份 (按一下以放大影像)
如果您只需要 VHD 本身，而且 VM 的設定資料和快照集很健康，可以選取 [檔案和資料夾]，然後挑選所需的個別 VHD 檔案。請注意，這項程序並不會使用 VSS 寫入器，VM 應該先儲存它的狀態，再使用寫入器來進行備份。
如果您徹底損失系統和資料，而且需要復原 Hyper-V 主機本身 (包括 Windows Server 2008 作業系統及其內執行的全部 VM)，則必須開機到 Windows 修復環境，並從該處執行還原作業。您可以從 Windows Server 2008 開機磁碟或預先設定的磁碟分割來完成這項作業。

Data Protection Manager
我們討論過 Hyper-V 主機和來賓使用可靠、免費、內建的 WSB 進行備份和還原的步驟和考量因素，但 WSB 並不是企業級的資料保護解決方案。它所缺乏的地方，Data Protection Manager (DPM) 2007 SP1 都能一一補齊。DPM SP1 目前是排定在 2008 年尾發行，它將支援 Hyper-V，並提供一些令人讚賞的功能：
  • 適用於所有 Hyper-V 主機和來賓的單一管理主控台。
  • 連續資料保護，以高達 15 分鐘的間隔擷取 VSS 型快照集，並且只擷取程序當中有變更的位元。
  • Hyper-V 叢集的感知能力，允許備份隨著它在叢集節點之間移動時追隨 VM。
  • DPM 伺服器對 DPM 伺服器複寫。:-)
  • 支援磁碟和磁帶媒體 (磁碟到磁碟、磁碟到磁帶，或磁碟到磁碟到磁帶)。
  • 跨整個資料幅度進行備份和還原的能力，包括 Hyper-V 主機和來賓；對執行中的來賓進行無代理程式的 VSS 備份；支援還原個別 VM；容錯移轉叢集資料；以及適用於 SQL Server、Exchange、SharePoint、Hyper-V 和 Virtual Server 的頂級應用程式專屬功能。
  • 備份前和備份後指令碼處理。
假如您目前是使用協力廠商備份解決方案，請留意應用程式的更新，大多數廠商都竭力推出 Hyper-V 主機型解決方案。

指令碼式備份
WSB 包含一個命令列介面 WBadmin.exe，另外也包含了一組 Windows PowerShell 指令程式，可與指令碼搭配使用。在使用這些功能時，前述的備份規則也適用，另外還需要透過登錄手動註冊 Hyper-V VSS 寫入器。
[圖 7] 顯示一些 WBAdmin 命令。如需完整的 WBAdmin 說明文件，請參閱 go.microsoft.com/fwlink/?LinkId=124380。您可以看到，WBAdmin 裡面並沒有東西可以設定備份原則本身，但是有一個 Windows PowerShell 嵌入式管理單元可用來管理這些設定。您可以使用下列命令來測試看看這個嵌入式管理單元是否已註冊：
Get-PSSnapin -Registered
[圖 7] WBAdmin 命令
WBAdmin 命令 | 描述
ENABLE BACKUP | 啟用或修改排程的日常備份。
DISABLE BACKUP | 停用執行中的排程日常備份。
START BACKUP | 執行備份。
STOP JOB | 停止目前執行中的備份或復原作業。
GET VERSIONS | 列出從特定位置復原的備份詳細資料。
GET ITEMS | 列出備份中所含的項目。
START RECOVERY | 執行復原。
GET STATUS | 報告目前執行中的工作的狀態。
GET DISKS | 列出目前上線的磁碟。
START SYSTEMSTATERECOVERY | 執行系統狀態復原。
START SYSTEMSTATEBACKUP | 執行系統狀態備份。
DELETE SYSTEMSTATEBACKUP | 刪除系統狀態備份。
而且您可以使用下列命令，載入名為 Windows ServerBackup 的嵌入式管理單元：
Add-PSSnapin windows.serverBackup
把它載入之後，您就可以存取適用於 WSB 的 Windows PowerShell 指令程式，如 [圖 8] 所示。如需每個指令程式的詳細說明，請執行下述命令：
Get-Command -PSSnapin windows.serverBackup | select name | get-help –full
[圖 8] Windows Server Backup 指令程式
指令程式 | 描述
Add-WBBackupTarget | 新增備份目標到備份原則。
Add-WBVolume | 新增磁碟區到備份原則。
Get-WBBackupTarget | 從原則取得備份目標。
Get-WBDisk | 取得所有磁碟。
Get-WBPolicy | 取得目前備份原則。
Get-WBSchedule | 取得原則當中的備份排程。
Get-WBSummary | 取得備份歷程記錄和摘要。
Get-WBVolume | 取得所有磁碟區。
New-WBBackupTarget | 新建備份目標。
New-WBPolicy | 新建空白原則。
Remove-WBBackupTarget | 將備份目標從原則移除。
Remove-WBPolicy | 刪除備份原則。
Remove-WBVolume | 將磁碟區從原則移除。
Set-WBPolicy | 儲存 WBPolicy 物件以建立排程備份。
Set-WBSchedule | 設定備份原則的排程。

另外還有一個內建至 Windows Server 2008 的公用程式也可以利用 Hyper-V VSS 寫入器，並為您的指令碼選項添加一些彈性。DiskShadow.exe 允許將陰影複本製作並掛接成磁碟機，跟使用 WSB 比起來，這可讓系統管理員進行選擇性較高的備份。而且您要牢記一個重點，DiskShadow 並不接受 Windows PowerShell 管線輸入，它反而要求命令透過指令碼傳遞給它，看起來可能像這樣：
Delete Shadows Volume C:
Set Context Persistent
Begin Backup
Writer Verify {66841cd4-6ded-4f4b-8f17-fd23f8ddc3de}
Add Volume C: ALIAS MyShadow
Create
End Backup
Expose %MyShadow% X:
Exit
這個指令碼首先會刪除磁碟 C: 任何現有的陰影複本，然後確認該陰影複本在 DiskShadow 執行後會繼續存在。接下來，它會建立一個交易區塊 — 如果當中有任何步驟失敗，整個程序也會失敗。在這個區塊中，DiskShadow 會確認 Hyper-V 的寫入器已載入，並新增磁碟機 C:到要備份的磁碟機清單中。
磁碟機 C:會取得 GUID 以利識別，而且這個 GUID 會儲存在名為「MyShadow」的環境變數中。該動作完成後，便會建立陰影複本。
備份是利用環境變數公開成磁碟機 X:。利用 X: 上的資料可以完成不同的事項，接著可使用命令 Unexpose X: 再次執行 DiskShadow 來移除磁碟機。
請注意，要還原透過 DiskShadow 備份的 Hyper-V VM，目前還是必須以手動方式進行 (VM 必須重新建立，快照集也不會保留等)。雖然這有些明顯的缺點，但至少資料有受到保護。
總結
DR 的艱辛過程可能看似永無止盡，但伺服器虛擬化帶來了一線光明，這全都要歸功於技術和所產生的低成本進入點。Microsoft 不光是提供虛擬化而已，它提供的是整個生態系統。伺服器虛擬化平台與 System Center 系列產品相結合，為各公司所面臨的不斷增加的複雜挑戰 (包括 DR 在內)，提供了更周全的解決方案。
在此特別感謝 James O’Neil 對本文所作的貢獻。

Adam Fazio 在兩年多前加入微軟顧問服務 (Microsoft Consulting Services) 的行列，現居美國國民住宅。他投入 IT 產業已有 10 多個年頭，曾為美國财星前一百大 (Fortune 100) 公司，還有網路創業公司處理過各種基礎結構專案和資料中心作業。他目前在 Microsoft 擔任全球虛擬化快速部署專案 (Virtualization Rapid Deployment Program) 的技術呈報主任。


虛擬化
規劃虛擬基礎結構的基本工具
Jay Sauls 和 Baldwin Ng
綜覽：
  • 控制成本
  • 清查電腦
  • 判斷 CPU、磁碟 I/O 和網路使用率

目錄
工具特點
了解您所擁有的
判斷目前使用率
伺服器安置建議
虛擬機器設定
安置限制
慎重考量您的選項
需求
總結
虛擬化不是一門新興的技術，但它現在正邁入許多新領域，遠遠超越 IBM 在 1960 年代開發的原始平台虛擬化。這樣的劇幅成長，主要歸功於虛擬技術具備了幫助控制資料中心和 IT 部門之間成本的潛力。隨著能源成本的高漲，以及貴公司不同部門對 IT 服務的胃口大增，您可能必須千辛萬苦才能趕上伺服器的成長，同時壓抑操作成本。這時候，虛擬化就可以幫上您的忙。不僅如此，Microsoft 和其他軟體製造商也不斷地開發新技術 (包括伺服器、桌上型電腦和應用程式虛擬化)，更廣泛地提供虛擬資源。
在本文中，我們將探討可幫助您處理虛擬化專案的工具組 — Microsoft Assessment and Planning Toolkit (MAP)，它是 Microsoft 解決方案加速器系列產品之一。什麼是解決方案加速器？簡單的說，就是幾乎每項 IT 專案必備的自動化工具和指南。解決方案加速器是免費的授權資源，可幫助您積極規劃、交付和操作您的 IT 基礎結構 — 從桌上型電腦到伺服器，從實體到虛擬。
解決方案加速器是透過與業界專家合作設計，以及在真實客戶環境內測試而成，可以提供適當等級的慣例指南和自動化來達成高效能，並且建置跨產品的 IT 基礎結構 — 全都不用重造。這些資源把焦點集中在各種規模的公司的重要考量，例如基礎結構評估及規劃、虛擬化、通訊和共同作業，以及安全性和循規。

工具特點
新發行的 MAP Toolkit 3.1 (見 [圖 1]) 是全網路的基礎結構評估工具，專門協助您快速初步了解伺服器和桌上型電腦，包括它們是否已經準備好升級，或移轉到諸如 Hyper-V、Microsoft Application Virtualization、Windows Server 2008、Windows Vista、Office 2007 和 SQL Server 等技術。
[圖 1] Microsoft Assessment and Planning Toolkit 3.1 (按一下以放大影像)
如 [圖 2] 所示，MAP 會自動產生整備評估報告和提議，為您省下不少自己動手的功夫。MAP Toolkit 3.1 支援伺服器和桌上型電腦兩種案例，包括評估桌上型電腦是否適合升級至 Windows Vista，以及規劃 Microsoft Application Virtualization 的推行。
[圖 2] 自動產生的移轉提議範例 (按一下以放大影像)
對於伺服器虛擬化規劃，這項工具有三大功能可以幫助您判斷哪些實體電腦是不錯的候選者：清查伺服器、收集效能指標，以及虛擬化安置建議。讓我們逐步解說一個案例，說明如何使用這些功能來建置您當前環境的詳盡藍圖，並為轉換至虛擬化做好規劃。

了解您所擁有的
許多大型企業都設有某種形式的伺服器管理基礎結構，例如 System Center Operations Manager。但有些環境的管理就沒有這麼積極。如果您真的搞不清楚您的工作環境到底設有哪些伺服器或者執行哪些程式，「伺服器清查 (Server Inventory)」功能可迅速幫您釐清。「伺服器清查」能夠使用 Active DIrectory、IP 位址範圍掃描或只是從一般檔案匯入電腦清單，來探索您環境中的電腦。如 [圖 3] 所示，您也可以結合使用多種探索方法 (比如，Active Directory 搭配 IP 位址掃描)，來尋找應該位在 Active Directory 中卻不在當中的電腦。
[圖 3] 選擇電腦探索方法 (按一下以放大影像)
探索到電腦之後，MAP Toolkit 3.1 會嘗試連線到每部電腦，並透過 Windows Management Instrumentation (WMI) 擷取 50 種類別以上的資料。根據這項資料可產生好幾種不同的報告。對於透過虛擬化進行的伺服器彙總，我們最感興趣的報告是您在選擇移轉特定角色和服務到 Windows Server 2008 時所建立的報告。
即使您現在並沒有要移轉到 Windows Server 2008，這種案例所建立的兩份報告仍舊相當實用，它們可以判斷您環境內的硬體類型 (包括安裝的處理器類型和速度、磁碟大小和記憶體)，以及您指定給每部伺服器的軟體角色 (DNS 伺服器、網域控制站和終端機服務)。
這些報告是以 Microsoft Excel 活頁簿的形式提供給您，所以可在 Excel 中方便地使用排序和篩選工具，找出您環境中哪些機器適合進行虛擬化。
伺服器清查報告提供的資料具備幾項特性，可以在選擇要虛擬化哪些伺服器時將它們列入考慮。舉例來說，如果您想要確定您要虛擬化的電腦，是執行 Hyper-V 虛擬化平台所支援的作業系統，可以在伺服器清查程序所建立的 WS2008HardwareAssessment Excel 活頁簿中，檢查 [伺服器清查 (Server Inventory)] 索引標籤下的 [目前的作業系統和 Service Pack (Current Operating System and Service Pack)] 欄位，找出任何可能需要升級的系統。

判斷目前使用率
尋找虛擬化候選者的下一步，是測量實體機器的使用狀況有多吃重。MAP Toolkit 3.1 (見 [圖 4]) 中的「效能指標精靈 (Performance Metrics Wizard)」，會從您認定為虛擬化候選者的機器清單中記錄效能計數器。CPU 使用率、磁碟 I/O 使用率和網路使用率全都會擷取起來供稍後檢閱。
[圖 4] 效能指標精靈 (按一下以放大影像)
這部分的工具是為了在一段相當長的時間內 (長達一個月) 觀察電腦，讓您彈性選擇如何使用它而設計的。如果您已經很清楚環境內使用率最高的時段是什麼時候 (例如，每週可能有批次處理的時段)，可以把精靈設定在那個時段執行幾個小時。但是如果不確定使用率最高的時段是什麼時候，或是您想要觀察許多尖峰使用時間不一的電腦，可以設定精靈執行幾天或幾週的時間，從電腦記錄資料，讓工具從範圍較廣的資料組中自動識別出尖峰使用率。
您可以利用稍早清查的資訊，存取 Excel 中的排序和篩選功能來建立您要監視的電腦清單。「效能指標精靈」會把這份清單當作一般檔案接受，一行一個電腦名稱。您可以將電腦名稱清單從 Excel 複製到記事本中一個新的空白文字檔，然後儲存起來。等畫面出現提示時，再將這個檔案匯入精靈中，然後設定效能指標收集時段的結束時間。這時精靈會進入資料收集模式，並且每隔五分鐘從指定的電腦收集效能計數器。
當「效能指標精靈」完成作業時，會建立一份詳細的 Excel 報告，列出觀察到的所有電腦，以及不同使用類別的所有效能指標：CPU、實體磁碟、邏輯磁碟和網路。您可以運用這項資訊，進一步過濾考慮進行虛擬化的候選名單。
您可以把目標鎖定在使用率極低的電腦，並將幾部這樣的電腦在單一主機上彙總成虛擬機器 (VM)，或者也可以將這項資訊與清查資料相結合，找出具備需要高可用性之關鍵型服務的電腦。虛擬化可針對高可用性環境，提供增強的嚴重損壞修復功能。分析完畢後，您可以繼續進行最後的步驟，亦即產生虛擬機器安置建議。

伺服器安置建議
「伺服器虛擬化和彙總精靈 (Server Virtualization and Consolidation Wizard)」可讓您就 CPU、網路、磁碟子系統和記憶體，來指定假定的虛擬化主機的設定。「伺服器虛擬化和彙總精靈」會使用「效能指標精靈」收集到的效能資料，計算出 VM 來賓與 VM 主機的適當對應關係，確保每台主機都能有效利用，而不致於在尖峰使用期間過度使用。
「伺服器虛擬化和彙總精靈」完成時，會產生一份詳細的 Excel 試算表，內含對來賓 VM 與實體主機的對應關係的提議。報告會顯示每台 VM 和主機的預估磁碟 I/O、網路 I/O 和 CPU 使用率。來賓 VM 在調整程序期間會新增到實體主機，而之前的主機一達到容量上限，也會跟著配置新主機。每台新主機都會顯示一則訊息，指出必須配置新主機的原因。
假如您有數台主機收到相同的訊息，可以考慮採用不同的主機設定，重新執行「安置精靈 (Placement Wizard)」，以增加指定給每台主機的來賓數目。比方說，若是您有好幾台主機顯示它們已達記憶體上限的訊息，則可以重新執行精靈，並在主機設定上指定較大的 RAM。這樣應該會增加可指定給每台主機的來賓數目。

虛擬機器設定
「伺服器虛擬化和彙總精靈」中的每一頁，都可以讓您設定假定電腦設定的主要元件，作為 VM 主機的容量模型。Virtual Server 2005 R2 和 Hyper-V 都能使用這個模型，而且精靈的第一頁會詢問您要使用哪種虛擬化技術 (見 [圖 5])。
[圖 5] 選擇要用於安置建議的虛擬化技術 (按一下以放大影像)
CPU 設定頁上有提供適用於 AMD 和 Intel 的幾個 CPU 系列的模型。如果找不到適合您 CPU 的模型，請選擇最相近的模型。您可以在這一頁設定每個核心實際的處理器、核心和超執行緒數目。請注意，若是您選擇 Hyper-V 作為虛擬化平台，那麼只能選擇 64 位元 CPU (見 [圖 6])。
[圖 6] 主機 CPU 設定 (按一下以放大影像)
精靈中的第三頁可讓您根據磁碟機的數量和 RAID 技術，來計算主機上可用的磁碟空間總數以及磁碟子系統的輸送量值，藉此設定磁碟子系統。輸送量值是根據所選的介面技術和磁碟可靠性和效能監視器 (Reliability and Performance Monitor，RPM) 速度來提供。
在 MAP Toolkit 3.1 中，對於製作存放區域網路 (SAN) 和網路連接儲存裝置 (NAS) 磁碟解決方案的模型，並沒有提供直接的支援。若要取得大約的估計值，請選擇 SCSI 磁碟技術，然後針對類似速度的磁碟，設定與您 SAN 設定類似的 RAID 層級。這項估計值應該足以幫助您進行初步規劃。

安置限制
當虛擬化來賓電腦對應到實體主機時，您必須考慮六個因素，來評估來賓是否在主機其餘的容量範圍內。
  • CPU 使用率
  • 網路 I/O 使用率
  • 磁碟子系統 I/O 使用率
  • 記憶體
  • 磁碟空間
  • 對指定的虛擬化技術的來賓 OS 支援
CPU、網路和磁碟子系統使用率都很直接明瞭。在實體虛擬化來賓候選機器上測得的使用率，都會在虛擬主機上轉換成對等的使用率，隨後再加到主機的現有使用率中。如果針對該項資源指派給主機的所有來賓最後總使用率，低於閾值上限，那麼就會將來賓指派給主機。如果高於閾值上限的話，就不會安置該來賓，而會嘗試其他來賓，看看有誰符合條件。
舉例來說，假設您在一部含有 1.2 GHz Pentium 4 CPU 的電腦上收集到的效能指標，指出 CPU 使用率是 32%。如果您設定一部含四核心 Intel Xeon 5300 系列 CPU 的虛擬化主機，那麼從潛在來賓電腦測得的原始 CPU 使用率，在主機上會被推斷為相同的預估使用率。如果 CPU 架構較新、CPU 時脈速度不同，而且加入更多核心，這個新使用率將比原始測得的值還低。
相反地，如果您所設定的主機，其 CPU 威力比來賓的還低弱，那麼在主機上推斷的預估使用率會高於原始測得的值。無論是哪一種情況，都會使用新推斷的 CPU 使用率來計算指派來賓給主機時的主機整體使用率。
至於記憶體和磁碟空間的使用率如何決定，也值得稍微討論一下。每一個潛在虛擬化來賓所安裝的實體記憶體量，都會保留在主機上。此外，主機本身還會保留少量的記憶體 (512 MB)。當主機上的總記憶體因指定來賓外加主機的額外負荷而耗盡時，該主機就不能再安置任何虛擬化來賓了。
另外，處理磁碟空間的方式也很類似：每台潛在虛擬化來賓的實體磁碟空間總數，都會保留在主機上。此外，還會保留 50 MB 的磁碟空間供虛擬化主機使用。當指派給主機的所有來賓總磁碟使用量加上保留給主機本身的空間，到達主機設定所指定的大小時，就不能再指派任何來賓了。
所選的虛擬化平台會進行檢查，以確保來賓電腦上所執行的作業系統，實際上受到該虛擬化平台的支援。譬如，Virtual Server 2005 R2 並不支援將 64 位元作業系統當作來賓，因此如果您選擇它作為虛擬化技術的話，就不會安置這些作業系統。

慎重考量您的選項
您只要執行幾次「伺服器虛擬化和彙總精靈」，就可以輕易比較虛擬主機選擇不同硬體所產生的結果。每一次執行精靈時，都可以選擇不同的 CPU、磁碟和記憶體選項，以找出最適合您環境的解決方案。
請特別注意伺服器彙總 Excel 活頁簿的 [彙總建議 (Consolidation Recommendations)] 標籤上的 [最後一次安置失敗的原因 (Last Placement Failed Reason)] 一欄。這些原因可以提供線索，幫助您瞭解為什麼某一部主機不能安置更多來賓電腦。如果有好幾台主機都顯示相同的原因，例如來賓的記憶體使用率超過主機上可用的記憶體，那麼增加主機設定上的記憶體量，也許可以減少必要的主機總數。

需求
MAP Toolkit 3.1 的優點之一是，它並不需要在進行清查的電腦上安裝任何軟體，所有的作業都是從遠端進行。不過，若要讓一切適當運作，必須要考慮幾個因素。
為了讓「清查精靈 (Inventory Wizard)」和「效能指標精靈 (Performance Metrics Wizard)」完成它們的工作，目標電腦上必須開啟幾個 TCP 連接埠，而且這些連接埠必須能夠從安裝 MAP Toolkit 的電腦存取。《入門指南 (Getting Started Guide)》對這方面的需求有詳盡的說明，簡言之，要清查的電腦上必須開啟連接埠供驗證、DCOM 和 WMI 使用。如果執行 MAP Toolkit 3.1 的電腦和清查目標之間的網路上有安裝任何防火牆的話，也必須將它們設定為允許這個流量通過。
MAP Toolkit 3.1 是為了清查多達 100,000 部電腦的環境，以及一次向多達 3,000 部電腦收集效能指標而設計的。根據預設，這項工具會安裝 SQL Server 2005 Express Edition 的私用執行個體。由於 SQL Server Express 有 4GB 的資料庫大小限制，因此這個設定只能讓您清查大約 20,000 部電腦，再清查下去就會觸及 SQL Server Express 規定的檔案大小限制。若要在清查期間處理更多電腦，必須修改一些預設值。
若要在規模較大的環境內工作，您必須使用完整版的 SQL Server，例如 SQL Server 2005 Standard Edition。在安裝 MAP Toolkit 之前，請先安裝一個新的 SQL Server 2005 執行個體，並將該執行個體命名為「MAPS」。接著在同一部電腦上，像平常一樣執行 MAP Toolkit 安裝程式。.MAP Toolkit 需要一個 SQL Server 本機執行個體，而且安裝程式會自動偵測出資料庫伺服器的本機「MAPS」執行個體，然後安裝到該執行個體裡面，而不是安裝 SQL Server Express Edition。
對於規模甚至更大的環境，您可以利用向外擴充功能，讓多部裝有 MAP Toolkit 的輔助電腦共同執行大型清查作業，並且把收集到的資料全部儲存到一個中央資料庫中。不過要使用這種設定，也必須使用 SQL Server Standard Edition 來避開 4 GB 的檔案大小限制。
如果您需要如何以這個設定安裝這項工具，以及如何針對這個模型妥善編輯資料庫連接字串的詳細資訊，請參閱《入門指南 (Getting Started Guide)》。您也可以利用向外擴充功能，將 SQL Server 放置在其他沒有安裝 MAP Toolkit 的電腦上。

像 Microsoft Assessment and Planning Toolkit 等類的解決方案加速器，都是為了幫您承擔 IT 專案吃重的工作，不用您親自動手。MAP Toolkit 已經為許多使用者省下了幾百小時的 Hyper-V 部署 IT 規劃時間。您準備好放手一試了嗎？
您可以在 microsoft.com/map 免費下載 Microsoft Assessment and Planning Toolkit，也可以在 microsoft.com/vsa 取得其他 Microsoft 解決方案加速器。我們也鼓勵您造訪 MAP Toolkit 小組部落格以尋找更多秘訣，以及觀賞示範影片，網址是 blogs.technet.com/mapblog。

Jay Sauls 在 Microsoft 的解決方案加速器小組擔任資深專案經理一職，他負責設計和實作像是 Windows Vista Hardware Assessment 和 Microsoft Assessment and Planning Toolkit 等工具。Jay 過去曾服務於其他 Microsoft 產品團隊，包括 Microsoft Commerce Server、Microsoft BizTalk，以及 System Center Capacity Planner。

Baldwin Ng 是 Microsoft 解決方案加速器核心工程設計 (Core Engineering) 團隊的資深產品經理，他目前負責的專案包括 Microsoft Assessment and Planning Toolkit 和虛擬器解決方案加速器。Baldwin 在 IT、電子商務和無線網際網路服務擁有 16 年以上與 Microsoft、Corbis 和 Alltel 合作的產品管理和開發經驗。他經常在 blogs.technet.com/MAPBLOG 發表部落格。


編輯的話 虛擬化世代的到來
Joshua Hoffman

虛擬化不是什麼新玩意兒。這句話作為開場白也許不算有趣，不過卻是實話。虛擬化 (把作業系統和基本硬體資源分開) 的概念，早在 1967 年隨著 IBM CP/CMS 作業系統的推出即問世，至今也許已被大家奉為圭臬，但是過去四十多年來它也經歷了不少改變。
終於在 2008 年，電腦虛擬化即將到達引爆點。隨著降低成本、簡化管理，以及確立運算環境的需求，與更強大的多核心處理器和新 Hypervisor 技術的會合，虛擬化的時代也跟著來臨了。這就是本期《TechNet Magazine》的主題。本期文章詳細描述了 Windows Server 2008 當中令人驚豔的新 Hyper-V 平台、管理虛擬環境的工具，以及部署虛擬應用程式的技術等等。
在此我希望代表所有《TechNet Magazine》的工作人員，向惡名昭彰的 Microsoft Scripting Guy 特約編輯 Greg Stemp 和 Jean Ross，表達誠摯的感謝。我知道當您發現 Microsoft Scripting Guy 其實不是一個頭大得驚人，穿著實驗室制服，一手拿著試管，一手拿著指令碼，在 Microsoft 大廳跑來跑去的小人時，也許會大吃一驚。確切一點的說，過去三年來，《TechNet Magazine》的《嗨，Scripting Guy！》專欄都是由 Greg 和 Jean 負責執筆，而他們的表現也深獲全球讀者讚賞。《嗨，Scripting Guy！》不僅成為我們所發行的專欄當中最受歡迎的一個，而且一路走來也獲得不少奬項，來自讀者的電子郵件更是不計其數。
正因為這些以及其他許多原因 (絕不是因為我們特別喜歡他們)，我們要在本月份的《TechNet Magazine》，向 Greg 和 Jean 感傷道別。不過，誠如最佳人才必走的路，Greg 和 Jean 也將轉向更好的前程發展。雖然如此，他們還是會繼續穿梭在 Redmond 大廳，為 Microsoft 客戶貢獻才華。在此祝福他們鴻圖大展，並且也希望有朝一日他們的文章能夠再度榮耀我們的版面。
另一方面，我們也感謝 Dean Tsaltas 這位可敬的 Scripting Guy 校友，在我們積極尋找下一代 Scripting Guy 的過渡時期，同意暫時接手《嗨，Scripting Guy！》。Dean 將在下個月加入我們的陣容，共同探索 Windows Management Instrumentation 的奧妙，千萬不要錯過了！—Joshua Hoffman

感謝下列 Microsoft 技術專家： Karri Alexion-Tiernan、Carmen Asher、Scott Culp、Steve Ekren、Trina Gorman、Michael Michael、Mike Mitchell、Michael Murgolo、Rob Polly、Dan Reger、Jez Sadler、Bill Scheidel、Bryon Surace 以及 Jim Truher。


讀者來信 讀者有話直說

SQL 資料庫管理
向 2008 年 8 月號的＜SQL Server：有效維護資料庫的最佳秘訣＞(technet.microsoft.com/magazine/cc671165) 致意！終於在 SQL 類區看到一篇文章，是專為我們這些純心想要確保這個叫做 SQL Server 的應用程式能夠執行和備份的「非自願 DBA」而寫的。
不僅如此，緊接在此文下一頁，還有一篇相關的後續報導＜Windows 系統管理：為您的伺服器把脈＞(technet.microsoft.com/magazine/cc718984)。實在太感人了！我把這兩篇文章從雜誌上撕下來妥善保管 (換了數位電子雜誌，可就不能這麼做了)，以備日後經常參考。請繼續努力，寫出好作品。
感謝您對這兩篇文章的抬愛。一直以來，我們都非常期盼讀者覺得我們的內容受用。但即使對於過度的褒獎，我們也不會拒絕，所以請繼續給予我們支持鼓勵！如果您希望我們編寫哪一方面的主題，請不吝告訴我們，我們永遠歡迎讀者的意見。
—Joshua Hoffman，總編輯

Image X 和 Windows PE
謝謝您撰寫有關透過 ImageX 和 Windows PE 部署舊版作業系統的那篇專欄 (請參閱 2008 年 2 月份的＜Windows XP 和 Windows PE 2.0 雙重開機＞，technet.microsoft.com/magazine/cc194422)。其實我在去年就發現這些工具的潛能，並且開始實驗用它們取代我們公司的映像處理工具 (Acronis Snap Deploy)。大約六個月前，實驗完全達到我的需求而圓滿落幕，因此現在它已經正式成為我們唯一使用的映像處理工具了。
接著我就讀到您的文章，並且注意到您提出增加 bootsect.exe /n52 選項的建議。我從未聽過這個選項。我們在套用映像之前，只用 DiskPart 和內含的指令碼 (commands.txt) 徹底清除硬碟。雖然到目前為止尚未發生任何問題，但有沒有可能造成日後的問題呢？
這個命令在早期的確有需要用到。但是在那篇文章登出之後，一位小組成員告訴我，現在已經不需要了，因為開機碼 _now_ 內含的邏輯會尋找新型的開機管理程式碼，如果找不到，就會暫時採用 NTLDR 直到失敗為止。所以您可以把它完全省略，沒問題。
—Wes Miller，專欄作家，桌面檔案

測試映像環境
我拜讀過您的一篇《桌面檔案》專欄，內容描述如何使用 ImageX 工具來實作映像，以及透過 Windows 部署服務或 WDS 來啟用多點傳送 (＜Windows XP 和 Windows PE 2.0 雙重開機＞)。我想要掛接一個測試環境，因此希望確實瞭解需要準備哪些工具。如果要實作多點傳送，必須安裝 Windows Server 2008 嗎？另外，如果是鏡像映像，需要使用 ImageX 來安裝 Deployment 4 或 Windows 自動化安裝套件 (WAIK) 和 WDS 嗎？
如果要以 WDS 來使用多點傳送，必須先安裝 Windows Server 2008。Windows Server 2003 並沒有多點傳送元件，以後也不會有。
如果要使用多點傳送，不必安裝 Deployment 4，但是必須取得 Windows Server 2008，以及 WAIK for Windows Server 2008 的發行版。該版的 WAIK 是第一個含有多點傳送到 Windows PE 所需要件的產品。
—Wes Miller

WDS 多點傳送
我試著使用 ImageX 將映像複製到電腦，以及從電腦複製映像。但很快就遇到一個問題：ImageX 並不支援多點傳送傳輸。如果我以 WDS 伺服器搭配多點傳送傳輸來進行同樣的動作，行得通嗎？聽說 Wdsmcast 命令好像做得到。但是 WDS 用戶端要如何告知 WDS 伺服器下載哪一個映像呢？
ImageX 本身的確無法處理多點傳送。您必須使用 Windows Server 2008 WAIK 中的 Wdsmcast，在伺服器上啟動它們之後，再指定要連接到哪一個傳輸。《使用傳輸伺服器》(英文) 白皮書 (technet.microsoft.com/library/cc725964) 當中就有詳細說明如何使用 Wdsmcast 來連接傳輸。請參閱＜如何使用 Wdsmcast.exe 將用戶端伺服器連接到命名空間＞(英文)一節。
—Wes Miller

與我們連絡 您有話要說嗎？您可以透過電子郵件地址 tnmag@microsoft.com 與我們聯絡，或者造訪我們的部落格論壇，網址為 blogs.technet.com/tnmag。


工具箱 適合 IT 專家的新產品
Greg Steen

隨身攜帶應用程式
PortableApps.com
PortableApps.com
身為 IT 專家，您可能常常要在不同的電腦上工作。這時，您多半希望手邊能有一套標準的應用程式、工具和文件。有一個很棒的方法可以滿足您的需求，就是從 PortableApps.com 提供的這類啟動程式平台下手。在 PortableApps.com 的網站上，您可以找到免費並且有開放原始碼的 PortableApps.com Platform，還有一些能夠在 USB 快閃磁碟機、記憶卡、可攜式硬碟或數位音樂播放器上獨立執行的可攜式應用程式。
網站上也提供 PortableApps.com Suite。這個便利的下載套件包含一組可用的可攜式應用程式以及基礎平台，全都放入同一個安裝程式中。此套件有兩種版本。Suite Light 包含 Mozilla Firefox、Thunderbird 及 Sunbird，再加上 ClamWin 防毒軟體、Pidgin 立即訊息工具、Sumatra PDF 讀取器、KeePass 密碼管理員、AbiWord 文書處理器、音訊播放棄和一些小遊戲。Suite Standard 則包含上述所有應用程式，外加 Writer、Calc、Impress、Base 與 Draw 的 OpenOffice.org 辦公室套件。
此外，網站上也提供其他一些「可攜式」有開放原始碼的應用程式，包括具備 FTP 功能的 FileZilla、具備 Telnet 和 SSH 功能的 PuTTY、具備 SFTP 和 SCP 功能的 WinSCP、具備快速清單功能的 PNotes 和 Task Coach、可封存的 7-Zip、命令提示字元、可清除檔案的 Eraser、可燒錄 CD/DVD 的 InfraRecorder、可視覺化磁碟內容的 WinDirStat、可驗證檔案的 winMd5Sum，以及具備檔案和目錄差異功能的 WinMerge (此《工具箱》專欄的忠實讀者可能會發現，我在前幾期專欄中已經討論過其中一些應用程式了)。
另外還有一個很活躍的使用者社群，正在嘗試開發 WinPCap 和 Wireshark 等網路公用程式的可攜式版本 (這兩樣工具對於系統管理及移難排解工作有莫大的幫助)。此論壇甚至另闢專區讓人建議想要的可攜式應用程式。
這些應用程式都可以在您使用的存放裝置上獨立執行。如果應用程式寫入登錄，或者需要進行磁碟以外的存取，應該會在結束時，恢復成其執行前的狀態。即使不使用 PortableApps.com Platform 也可以執行應用程式 — 這些應用程式都已經包裝在本身的安裝程式中，好讓您單獨使用。儘管如此，您可能還是想要使用 Platform 的各項功能，而 Suite 正是讓您開始著手可隨身攜帶的自訂環境的好處所。
PortableApps.com Platform 是設定成自動執行。因此，當您將 USB 隨身碟或可攜式磁碟插入 Windows 主機電腦時，會出現執行平台應用程式的選項。啟動平台後，便會顯示系統匣圖示。按一下此圖示將出現類似 Windows [開始] 功能表的功能表。這個應用程式啟動程式提供所有可攜式應用程式的快速連結，還有可攜式磁碟上的文件資料夾連結、顯示磁碟剩餘空間的指示器、用來備份磁碟上的文件的公用程式、搜尋工具以及安裝新的可攜式應用程式的連結。您可以將此介面自訂化，並從 30 種以上的介面語言擇一使用。
把玩平台一陣子之後，您可能有興趣知道如何將應用程式修改成可攜式。網站也提供高人氣的可攜式應用程式開發 (Portable App Development) 論壇來指引您的方向。綜觀來看，這個可攜式套件囊括了一組很棒的工具集。

價格： 免費。
PortableApps 可讓您隨身攜帶工具

疑難排解遠端系統
TeamViewer
teamviewer.com
當您移難排解應用程式問題、發表產品示範與教學課程，或單純想要了解使用者的問題時，最好能夠直接面對出問題的電腦來解決問題。但這往往是不可能的事。那麼退而求其次的選擇就是使用工具協助您「身處其境」而不必親自坐陣現場。TeamViewer GmbH 推出的 TeamViewer 正符合此需求。
此公用程式的安裝程序很簡單，可讓您快速連線到遠端機器。TeamViewer 支援四種基本操作模式。一種是遠端支援 (Remote Support)，可讓您控制遠端機器進行移難排解、協助操作與維護，以及引導使用者完成某項活動。一種是展示 (Presentation)，可在遠端使用者的系統上顯示您的桌面，以便示範活動或提供簡報。另一種模式是檔案傳輸 (File Transfer)，可讓您在兩台機器間傳輸檔案，而無須實際共用桌面。最後一種模式是 VPN，可在您的電腦和主機電腦之間建立即時虛擬私人網路 (此模式使用 TeamViewer VPN 介面卡安裝選項)。
就安全性而言，此應用程式使用 RSA 金鑰交換與 256 位元 AES 工作階段編碼。金鑰交換可確保不會有「中間人」(TeamViewer 路由伺服器也包含在內) 打探您的資料流。除此之外，當您連線到 Supporter 工作階段 (Supporter 一詞指的是主控工作階段者) 時，會產生工作階段識別碼與密碼，遠端使用者必須輸入此識別碼與密碼才能連線。假如您想要連線到另一端無人看管的電腦 (譬如說，管理您的伺服器)，TeamViewer 提供安裝成系統服務的選項，如此一來，您仍然可以輕鬆地傳輸檔案、使用遠端控制功能、建立 VPN，甚至是重新啟動遠端機器。
TeamViewer QuickSupport (亦稱為 Customer 模組) 模組是另一項很酷的功能，特別是當您想要使用應用程式來提供支援或簡報時。這個可執行檔比較小，無須軟體安裝或遠端機器上的安裝權限即可執行。使用者只要按兩下 exe 檔案，輸入工作階段識別碼與密碼，您就可以開始將工作階段連線至該電腦。
TeamViewer 有一些很實用的組態選項。您可以最佳化顯示中共用的色彩數目、從顯示中移除遠端底色圖案，或選擇繼續啟用 Windows Vista Aero Glass。您也可調整工作階段的一般品質/速度設定。此外，您還可以控制是否要允許各種功能，包括遠端控制、檔案傳輸、VPN 連線、遠端鍵盤及滑鼠輸入、切換本機與遠端主機之間的控制，以及檢視遠端畫面。
您可以記錄工作階段，供稍後重新執行或用於稽核。如果您不希望從 TeamViewer 的伺服器路由 (也許是基於安全性設定的緣故)，您可以選擇讓 TeamViewer 只使用 LAN 連線來自我路由。
Premium 版本支援不限次數的 Supporter 安裝，其中也包括 Portable 版本可讓您放入 CD 或 USB 快閃磁碟，以便將工具帶著走。Premium 版本還包含 TeamViewer Manager，這項工具會記錄工作階段詳細資料，並讓您儲存合作夥伴的詳細資訊，這兩種功能都很方便您追蹤、呈報和寄送發票給用戶端。TeamViewer 也可用於 Mac OS X，它支援跨平台存取，因此您可以一面使用 Windows 電腦，一面連線到 Mac。

價格： 非商業使用免費。商用版的單次 Supporter 安裝為 $699 美元起。Premium 版本為 $1,399 美元，可提供不限次數的 Supporter 安裝。
使用 TeamViewer 連線至遠端系統

書評
End-to-End Network Security:Defense-in-Depth
今日的網路安全性結合了許多層的主動式技術，來減少安全性事故的風險，並降低網路基礎結構內外產生安全性漏洞的可能性。Omar Santos 的著作《End-to-End Network Security:Defense-in-Depth》(Cisco Press，2007 年) 可以在日益複雜的網路防禦環境中助您一臂之力
雖然這本書基於明顯的原因，比較偏愛 Cisco 裝備，但仍然提供了許多廣義的安全性資訊，因此非常適合當作想了解基礎結構安全性的網路專業人員或系統管理員的參考資料。
這本書一開始介紹網路安全性技術的概觀，範圍從防火牆與 VPN 到入侵偵測/預防系統與身份識別管理，應有盡有。接著，書中詳細討論處理安全性事件的六步驟方法：準備、識別 (安全性威脅)、分類 (安全性威脅)、追溯、反應和事後檢討。
這本書接下來討論主動式安全性架構，這個架構運用各式各樣的裝置與工具，包括 IDS/IPS、NAC、AAA、SNMP、Syslog 及 VLAN。內容接著轉入 Cisco 深度防禦方法，主要討論的是無線網路、IP 語音、資料中心安全性和 IPv6 安全性，因為此方法在上述的網路安全性方面與 Cisco 解決方案有關。本書以三個案例研究收尾，其中討論了真實世界的大、中和小型企業安全性解決方案。

價格： $49.50 美元 (直接售價)。

調查裝置識別碼
PCIDatabase.com
PCIDatabase.com
曾經嘗試過升級系統，最終卻得到一兩個未知裝置，而且除了指出「PCI 裝置」以外別無說明，讓您不曉得如何取得驅動程式或找出裝置類型，不得已只好掀開機器外殼，拿著手電筒東摸西找嗎？或許您已經試過想找出已知裝置上的底層晶片組到底是什麼。那麼，有一個免費的服務可以派上用場，就是 PCIDatabase.com。
這個支援使用者的資料庫，可讓您根據廠商和裝置名稱及識別碼進行搜尋來尋找更多資訊。只要開啟 [裝置管理員]，以滑鼠右鍵按一下有疑問的裝置，然後依序選取 [內容]、[詳細資料] 索引標籤和 [硬體識別碼] 屬性。在此您會看到一組包含幾個十六進位值的字串，並以「VEN_」(代表廠商) 和「DEV_」(代表裝置) 開頭。
這個網站提供一些有用資源的連結，協助您尋找所查詢的裝置有無可用驅動程式 (當然，也別忘了查看製造商的網站)。
您在 PCIDatabase.com 還可以找到另一項很棒的功能：查詢特定廠商時，有一頁會列出總公司地址、電話號碼、相關網站、連絡資訊、供應商的 PCI 裝置的十六進位識別碼，以及此網站所知該廠商所有裝置的列表。由於此網站是為了支援使用者，因此也鼓勵您一起貢獻所知。

價格： 免費。
從 PCIDatabase.com 取得廠商和裝置資訊 (按一下以放大影像)

稽核和清查資產
CCS Network Inventory
crowcanyon.com
若能不離開座位就得知用戶端機器中安裝的內容，將可省下不少時間。而且面對現實吧 — 每隔一陣子追蹤這些資產本來就是您工作的一部份。Crow Canyon Systems 提供的 CCS Network Inventory 解決方案能協助您執行這些工作。
此應用程式是一個無代理程式的清查和稽核工具，它會掃描 LAN 上的工作站 — 收集硬體、軟體、服務與使用者資訊。由於 CCS Network Inventory 並不使用遠端代理程式，因此您的執行內容需要 RPC、電腦瀏覽器服務、遠端登錄服務、檔案及印表機共用，以及要清查之電腦的 ADMIN$ 共用存取 (正如同其他大多數的無代理程式清查產品一樣)。
此應用程式允許您使用替代的憑證來進行查詢，這在您掃描多個網域時很實用。安裝完應用程式之後，您可以掃描 IP 位址範圍、使用 Windows 網路探索、匯入電腦清單，或手動指定要清查的 Windows 工作站清單。
就 CCS Network Inventory 稽核的內容而言，應用程式會收集軟體詳細資料：應用程式安裝的項目、已經套用的 Hotfix、電腦安裝的 OS 與 Service Pack，甚至是所安裝的字型。就電腦組態而言，您可以看到有哪些服務和其他處理程序正在執行、哪些是共用的資料夾、磁碟機對應、環境變數、使用者帳戶、排程的工作、啟動命令，及哪些網路通訊協定正在執行。就硬體而言，您可以看到相連接的監視器、印表機、硬碟 (和大小與磁碟分割)、CD 與 DVD 磁碟機資訊、處理器、記憶體等等的詳細資料。此外，您可以針對登錄值、檔案計數 (例如，誰的 mp3 檔案最多) 和磁碟機可用空間設定自訂掃描。
所有這些資訊都儲存在應用程式的自訂資料庫中，您可以使用這些資料來建立報告。CCS Network Inventory 提供一些內建報表來具體化和傳輸這些資料，以便作為稽核與報告之用。如果內建報表與查詢資訊不能完全滿足您的需求，您可以使用內建的 SQL 查詢產生器工具，對資料編寫和執行更詳盡或特定的查詢。
每隔一段時間最好能為環境建立快照集，以方便您檢視變更情況。CCS Network Inventory 可讓您藉由比較兩個資訊資料庫的執行個體，來檢視這些變更。譬如說，您可以比較目前的掃描結果與一年前的掃描結果，了解有多少工作站切換成 Windows Vista，有多少工作站在去年進行硬體元件更新，或是哪些使用者在您提出警告後仍然繼續執行不支援的軟體。
在撰文的同時，CCS Network Inventory 尚未完全支援 Windows 2008 Server，不過它確實支援至 Windows Vista 以降的其他 Windows 版本。

價格： 25 個節點以內 $235 美元起。
使用 CCS Network Inventory 管理遠端資產

與工具箱連絡 如果您想要推薦喜愛的工具或公用程式，請將郵件寄到 tntools@microsoft.com 給作者。

Greg Steen 是一位技術專家和企業家，為人十分熱心。他總是四處探尋新的工具，協助 IT 專家更輕鬆地進行操作、品管及開發。


SQL 問答集 大型交易記錄檔，何時使用修復，以及其他
Paul S. Randal

問：我注意到備份有一些怪異的行為，希望您能解釋一下。我們三不五時就會備份 62GB 的實際執行資料庫，重新整理應用程式開發人員所使用的資料。在還原新複本前，我們一定會先把舊的刪掉。還原的複本大小跟實際執行資料庫一樣，資料看起來也一樣，但是還原程序所花的時間卻遠比備份程序長。怎麼會這樣呢？為什麼跟備份比起來，還原會花這麼久的時間呢？
答：其實沒什麼好奇怪的，以您的情況來說，通常這都是預期之內的行為。備份與還原所需的時間會有差異，是因為每個程序必須執行的步驟不同。
備份資料庫包括兩個步驟，基本上它只是在資料庫上讀取 IO，然後在備份裝置上寫入 IO。
備份步驟 1 讀取資料檔中所有配置的資料，並將它寫入備份裝置。
備份步驟 2 讀取一些交易記錄檔，並將它寫入備份裝置。
實際所需的交易記錄量可能因情況不同而有很大的差異，但它其實是將還原的資料庫復原到一致時間點所需的數量 (針對這點，我在部落格文章有深入的解釋，網址是 sqlskills.com/blogs/paul/2008/01/31/MoreOnHowMuchTransactionLogAFullBackupIncludes.aspx)。
另一方面，還原資料庫可能多達四個步驟，而且它所牽涉的工作，比單純讀取和寫入 IO 還要複雜得多：
還原步驟 1 假如資料庫檔案不存在，則建立它們。
還原步驟 2 從備份讀取所有的資料和交易記錄檔，並將它們寫入相關的資料庫檔案中。
還原步驟 3 在交易記錄檔上執行復原的 REDO 階段。
還原步驟 4 在交易記錄檔上執行復原的 UNDO 階段。
備份的兩個步驟所耗用的時間，大概跟還原步驟 2 所需的時間差不多 (假設硬體相似，而且伺服器沒有使用者活動的話)。如果資料檔很大，而且必須初始化為零 (這是 SQL Server 2000 的行為，以及 SQL Server 2005 的預設行為)，則還原步驟 1 可能會花很長一段時間。
若要避免這種情況，請不要在還原之前刪除現有的檔案。或者，您也可以選擇啟用立即初始化功能，快速建立檔案 (相關資訊，請參閱 msdn.microsoft.com/library/ms175935.aspx)。
還原步驟 3 和 4 是在還原的資料庫上執行復原，以便在交易層面保持一致性，這個程序就跟資料庫經歷故障修復的程序一樣。復原所花的時間，要根據所需處理的交易記錄量而定。比方說，如果在製作備份的同時，正在進行一項長時間執行的交易，那麼該交易的所有交易記錄檔都會備份起來，而且必須加以回復。

問：我不知道要選擇記錄傳送還是資料庫鏡像，來提供實際執行資料庫的備份複本。我顧慮的是必須在伺服器之間傳送的交易記錄量，特別是每晚進行的索引重建作業。聽說鏡像會傳送實際的重建命令，不是交易記錄檔，而重建作業是在鏡像上完成。是這樣嗎？如果是，那麼鏡像應該比用 BULK_LOGGED 復原模式進行記錄傳送更理想對吧？
答：您聽說的並非屬實。資料庫鏡像的運作方式，是將實際的交易記錄檔記錄從主體資料庫傳送到鏡像伺服器，在該伺服器的鏡像資料庫中「重新執行」。鏡像資料庫上不會進行任何形式的轉換或篩選，也不會進行任何一種 T-SQL 命令攔截。
資料庫鏡像只支援 FULL 復原模式，也就是說，索引重建作業一定會完整記錄下來。根據您所考慮的索引大小而定，它可能會產生大量的交易記錄檔，接著在主體資料庫上產生一個大型記錄檔以及可觀的網路頻寬，以便將記錄檔記錄傳送到鏡像。
您可以把資料庫鏡像想成即時記錄傳送 (事實上，這項功能在 SQL Server 2005 開發早期便是採用這個名稱)。在記錄傳送中，主要資料庫的交易記錄檔備份會定期傳送到次要伺服器，並在次要資料庫上還原。
記錄傳送支援 FULL 和 BULK_LOGGED 復原模式。在 FULL 復原模式的記錄傳送資料庫中進行的索引重建作業，它所產生的交易記錄量，跟鏡像資料庫所產生的量一樣。不過，在記錄傳送的資料庫案例中，資料是放在記錄備份 (或一連串記錄備份) 一起傳送到備份資料庫，而不是以連續流程傳送。
如果索引重建在完成時，記錄傳送資料庫所用的是 BULK_LOGGED 復原模式，那麼它所產生的交易記錄量最少。但是下一個交易記錄檔備份，也會包含由記錄最少的索引重建作業所變更的所有資料檔案範圍。這表示在 BULK_LOGGED 復原模式涵蓋索引重建的記錄檔備份大小，跟那些在 FULL 復原模式中涵蓋索引重建的記錄檔備份大小幾乎一模一樣。
因此需要傳送給備份資料庫的資料量，與在鏡像資料庫上和記錄傳送資料庫上的索引重建，幾乎完全一樣。實際的差別在於傳送資訊的方式 — 連續傳送或是批次傳送。
在這兩種方法之間擇其一時，必須考慮其他許多因素 (因素之多，無法在單期的《SQL 問答集》中一一討論)。在做決定之前，最好能夠看看這些因素符不符合您的需求 (例如，可接受的資料損失限制以及可允許的停機時間)。

問：我用的是 SQL Server 2005，其中一個資料庫的交易記錄檔不斷增大。這個資料庫是採用完整復原模式，而且我進行的是交易記錄檔備份。我記得這樣應該可以防止交易記錄檔變大吧。所以到底是哪裡出錯了呢？
答：在完整復原模式下製作交易記錄檔備份，的確可以防止交易記錄檔變大。但是導致交易記錄檔變大的可能因素不只於此。關鍵在於，到底是什麼東西需要用到 (或處於作用狀態) 交易記錄檔。除了缺乏交易記錄檔之外，其他像複寫、資料庫鏡像，以及作用中的交易等，都是可能造成問題的常見因素。
複寫是指以非同步的方式讀取您的交易記錄檔記錄，然後載入交易以複寫到另一個散發資料庫。只要是尚未被複寫記錄讀取器工作讀取的交易記錄檔記錄，都不能釋放出來。如果您的工作負載會產生許多交易記錄檔記錄，而且您設定執行複寫記錄讀取器的間隔時間也比較長，那就可能累積大量的記錄，而使交易記錄檔增大。
如果您是執行非同步資料庫鏡像，那麼也許是因為有積存的交易記錄檔記錄未從主體傳送至鏡像資料庫 (稱為鏡像 SEND 佇列的資料庫) 的緣故。交易記錄檔記錄要等到全都順利送出之後才能釋放。若是交易記錄檔記錄產生的頻率偏高，加上網路上的頻寬有限 (或其他硬體問題)，積存的規模可能會變得非常可觀，而導致交易記錄檔增大。
最後，如果使用者開始進行明確的交易 (例如使用 BEGIN TRAN 陳述式)，然後進行某些修改 (例如 DDL 陳述式，或插入/更新/刪除動作)，那麼所產生的交易記錄檔記錄必須一直保留到使用者認可或回復交易為止。這表示其他交易所產生的任何後續交易記錄檔記錄也不能釋放，因為交易記錄檔不能選擇性的釋放。比方說，如果使用者沒有完成當天的交易就回家了，該交易記錄檔就會繼續增長，因為交易記錄檔記錄不斷產生，卻無法釋放出來。
您可以查詢 sys.databases 系統目錄檢視，然後分析 log_reuse_wait_desc 一欄，藉此找出交易記錄檔無法釋放的原因，如下所示：
SELECT name AS [Database],
  log_reuse_wait_desc AS [Reason]
FROM master.sys.databases;
如果導因是源自於作用中的交易，您可以使用 DBCC OPENTRAN 陳述式取得與該交易相關的詳細資訊：
DBCC OPENTRAN ('dbname')

問：我聽說要從損毀復原，應該採用從備份還原的作法，最後不得已才使用 REPAIR_ALLOW_DATA_LOSS。您可以解釋為什麼不應該採用「SQL Server 2005 的修復」呢？如果它這麼「危險」的話，為什麼還把它放在產品中呢？
答：首先，編寫 SQL Server 2005 修復的正是敝人在下我。REPAIR_ALLOW_DATA_LOSS (以下稱為修復) 的問題出在它的運作方式模糊不清。修復選項的名稱由來，是因為執行它可能會導致資料庫資料損失。功能修復損毀資料庫結構一般採用的方式，是刪除損毀的結構，然後修正資料庫中參考或被已刪除結構參考的其他一切項目。修復其實是保持資料庫結構一致的最後一種途徑 — 它的重點並不是要儲存使用者資料。修復並不會大費周章去刪除使用者的資料，但也不會費盡心思去儲存使用者的資料。
這樣看來，修復好像不是一個很負責任的作法，但是當需要用到修復選項時，最快也最可靠的方法還是修正損毀。在嚴重損壞修復的情況下，速度是相當重要的因素，而正確性也不容許有任何差池。要設計出比它更複雜的修復演算法，並證明可在所有情況下快速且正確地運作，幾乎是不可能的。修復程式碼中有些複雜的演算法，會解決像是兩個索引配置有相同頁面或範圍的情況，但演算法主要是要修復加修正。
儘管如此，修復還是有些您應該注意的問題：
  • 修復在刪除損毀結構時，並不會考慮外部索引鍵條件約束，因此它可能會從資料表刪除與其他資料表具有外部索引鍵關聯的記錄。在執行修復後一定要執行 DBCC CHECKCONSTRAINTS，才能判斷是否有發生這種情況。
  • 修復並不會 (而且也無法) 考慮在應用程式層級定義的任何繼承商務邏輯或資料關聯，因為這些關聯可能會被一些已刪除的資料打斷。再次強調，您一定要執行應用程式內建的任何自訂一致性檢查，才能判斷有沒有任何東西已被破壞。
  • 部分修復作業無法複製。如果在對等式拓樸中的發行者或節點上執行修復，可能會在拓樸當中產生不一致的情況，因此您必須手動進行修正。
因此，要從損毀復原時，選擇備份一定比選擇執行修復選項來得明智。但是在產品中提供修復，是因為您隨時有可能碰到資料庫損毀，卻沒有備份可用，而需要用某種方法讓資料庫快速上線的情況。

問：我才剛剛在新公司擔任 DBA 一職，負責數個應用程式及其後端資料庫。其中一個應用程式在進行更新時，效能非常低落。經過調查後，我發現該應用程式所使用的每個資料表上面，都有大量的索引。問過許多人之後，才知道原來前任 DBA 習慣在每個資料表資料行新增索引，外加一些組合。我不相信這些索引都有存在的必要 — 但我要怎麼判別哪些索引可以放心捨棄呢？我們執行的是 SQL Server 2005。
答：如您所臆測，數量龐大的索引很有可能是導致效能不良的主要肇因。每次在資料表中插入、更新或刪除資料列時，也必須在每個非叢集索引內進行相對應的作業。這在 I/O、CPU 使用率和產生交易記錄檔方面加重許多負擔。
要在 SQL Server 2000 中判斷用了哪些索引，唯一的辦法是使用設定功能，並分析查詢計畫。SQL Server 2005 有一個全新的動態管理檢視 (DMV) 會追蹤索引使用量 — sys.dm_db_index_usage_stats。
資料庫部分啟動之後，每次一使用索引，這個 DMV 都會加以追蹤 (包括追蹤使用方式)。當 SQL Server 關閉時，所有資料庫的統計資料都會跟著遺失，而當單一資料庫關閉或卸除時，其統計資料也會遺失。其理論是，如果索引沒有顯示在輸出中，就表示它從資料庫啟動以來尚未被用過。
要追蹤索引在一段時間內的使用量，有一個簡單的方法，就是定期擷取 DMV 輸出的快照集，然後比較這些快照集。許多人都忽略了一件事，那就是您必須追蹤整個商務週期的索引使用量。如果您只取得單天的快照集，可能會發現有好幾個索引都沒用到。但如果這些索引的目的是加速執行月底報告，也許就不應該移除它們。如果索引在整個商務週期都沒有用到過，那麼不妨直接放棄，取回空間，恢復效能。
如需一些可用來定期擷取 DMV 快照集的簡單程式碼，請參閱我的部落格文章，網址是 sqlskills.com/blogs/paul/2007/10/05/IndexesFromEveryAngleHowCanYouTellIfAnIndexIsBeingUsed.aspx。

Paul S. Randal 是 SQLskills.com 的常務董事，同時也是 SQL Server MVP。Paul 曾為 SQL Server 2005 撰寫過 DBCC CHECKDB/repair，並且在 SQL Server 2008 開發期間負責核心儲存引擎。身為嚴重損壞修復、高可用性和資料庫維護方面的專家，Paul 也經常在研討會上發表演說。他的部落格位於 SQLskills.com/blogs/paul。


公用程式焦點 Offline Virtual Machine Servicing Tool
Peter Skjøtt Larsen 和 Suveen Kumar Reddy Vuppala

目錄
安全性夢魘
深入探討
服務基礎結構
使用工具
即將推出
將電腦工作負載虛擬化，單純是表示使用虛擬機器 (VM) 來分攤底層硬體的工作負載。現代的 IT 部門發現 VM 在很多情況下都能派上用場：
轉移工作負載 使用 VM 可以輕易地隨著使用需求變更來增加或減少多重安裝的工作負載頻寬，而無須採取對應的硬體變更措施。
開發和測試應用程式 您不必指定專屬硬體，就可以建立多台 VM 來代表應用程式所要支援的各種組態。
軟體升級 您可以使用 VM，在將軟體套件的舊版本帶下線之際讓新版本上線 — 全都在相同的硬體上執行。
軟體發佈 VM 可以用來當作企業營運應用程式的發佈單位，以便在預先測試的套件中維持一致的軟體組合。

安全性夢魘
使用 VM 的好處之一是您能夠在離線狀態將 VM 另存成 VM 映像。當您需要 VM 時，就可以「喚醒」這些 VM，比起部署同等的硬體，部署這些 VM 的速度要快許多。
不過，讓越來越多的運算環境在離線狀態下等待，將產生維護上的挑戰。許多軟體更新機制需要處於線上狀態的系統，才能自動檢查更新或接受更新。
當 VM 不處於線上狀態時，它只是一個待在電腦中的檔案，因此無法與任何更新機制互動。經過幾個月的離線狀態後才上線的 VM 可能對網路造成威脅，抑或是受到網路的威脅。
此時不只是缺少 OS 更新那麼簡單。過時的應用程式或病毒設定檔可能導致 VM 的安全性漏洞，或使得 VM 不符公司標準。
為了協助客戶克服讓離線 VM 保持最新狀態的挑戰，Microsoft 解決方案加速器小組打造了 Offline Virtual Machine Servicing Tool。這個工具可與 System Center Configuration Manager (SCCM) 2007、Windows Server Update Services (WSUS) 3.0 及 System Center Virtual Machine Manager (VMM) 2007 搭配用來統整更新已儲存 VM 的作業。[圖 1] 顯示此工具的概念呈現，以及它如何與各種外部元件相連結。
[圖 1] Offline Virtual Machine Servicing Tool 的運作方式 (按一下以放大影像)
為了讓 VM 進行更新，此工具使用 VMM 將 VM 暫時部署到維護主機。由於維護主機組態通常擁有同時執行多個 VM 所需的 CPU 和記憶體，因此這個工具可以透過批次的方式管理 VM。
當 VM 在維護主機上啟用之後，SCCM 或 WSUS 就可以為它們提供必要的更新。套用更新之後，這個工具會使用 VMM 使 VM 返回至原本的離線狀態 (請注意，這個工具只支援由 VMM 管理的 VM)。

深入探討
Offline Virtual Machine Servicing Tool 使用 Windows Workflow Foundation (WF) 來統整更新 VM 的程序。這項程序有多處決策點，首先是選擇適當的更新管理系統，為 VM 挑選下一個合適可用的維護主機，確保更新已執行，最後是處理例外狀況。
使用 Windows WF 架構的解決方案能讓開發小組靈活應變和改善流程，也能為使用者提供針對特殊需求量身訂製的可靠解決方案；在程序當中的關鍵時刻，內建的前置與後置工作流程步驟可提供自訂的機會。
這個工具使用 Windows PowerShell 來實作工作流程層級底下的個別工作，並與 VMM 提供的 Windows PowerShell API 完美結合。而且 Microsoft .NET Framework 架構的 UI 的外觀與使用方式類似 System Center 產品，因此新使用者也能得心應手。

服務基礎結構
服務基礎結構有一個基本原則，就是在更新過程中設定網路安全性來保護 VM 免受侵害。在 1.0 版的工具中，這項工作是使用與 VMM 和適當更新系統 (WSUS 或 SCCM) 相連的虛擬私人網路 (VPN) 來完成。最適合 VMM 程式庫的基礎結構應該是連接光纖通道的存放區域網路 (SAN)，SAN 可提供將 VM 映像快速移轉到維護主機的管道。
所有 VM 都必須同屬於使用 Active Directory 與 DNS 的網域的成員。您可以為 VMM、WSUS、SCCM 和 VMM 程式庫指定專屬的個別伺服器，但是小型環境也可使用虛擬伺服器組合。當然，維護主機必須是實體伺服器。

使用工具
設定好服務基礎結構之後，您需要先檢查特定設定是否正確，才能啟動工具。請確保 VMM 管理著所有適當的 VM，也就是每個 VM 都已安裝合適的更新用戶端，而且已經在 WSUS 或 SCCM 中設定必要的更新套件。至於確認 VMM 中是否設定維護主機群組則是選擇性選項。
準備好之後，請啟動 Offline Virtual Machine Servicing Tool，這項工具本身也包含數個設定步驟。您必須指定 VMM 伺服器和適當的 WSUS 或 SCCM 伺服器，接著指定要使用的維護主機群組 (如果維護主機已分組)，以及要使用該群組的哪個維護主機 (見 [圖 2])。您可能還想設定要管理的 VM 群組，不過這個動作是選擇性的。
[圖 2] 設定 Offline Virtual Machine Servicing Tool (按一下以放大影像)
設定好工具之後，您要建立服務工作。服務工作包含此工具用來管理特定 VM 的所有資訊，包括是否使用 WSUS 或 SCCM 進行更新；VMM 伺服器與 WSUS 或 SCCM 伺服器的位置；要管理的 VM 的身分識別；用於此作業程序的網路類型 (和可能需要的身份識別)；要使用的維護主機的身份識別；存取 VM、VMM 伺服器及 WSUS 或 SCCM 伺服器所需的帳戶認證；最後還有執行服務工作的排程 (立即執行或於指定日期和時間執行)。
如果您為服務工作指定日期和時間，Windows 工作排程器便會決定何時啟動服務工作。當服務工作執行時，Offline Virtual Machine Servicing Tool 會針對各個 VM 依序執行以下動作：
  • 從 VMM 程式庫選取下一個 VM。
  • 查詢 VMM 以取得最適合的維護主機。
  • 將 VM 部署到維護主機。
  • 確認 VM 連線到正確的網路。
  • 啟動 VM。
  • 確認 VM 上已安裝適當的更新用戶端。
  • 觸發更新作業。
  • 等候更新作業完成。
  • 關閉 VM。
  • 將 VM 存回 VMM 程式庫。
更新 VM 程式庫所需的時間差異很大，端視維護主機的數量和容量、VMM 程式庫存放區的存取速度以及更新性質而定。
即將推出
要注意的是，Offline Virtual Machine Servicing Tool 的現行版本 (1.0) 並不支援網路存取保護 (NAP)，而 NAP 其實是保護 VM 不受網路傷害的理想途徑。此外，它也不支援 Windows Server 2008 的 Hyper-V 技術或使用 Windows Server 2008 作為用戶端 OS。
更新版的 SCCM、WSUS 和 VMM 很快便會推出，且 2.0 版的 Offline Virtual Machine Servicing Tool 將支援這些更新版本和 Hyper-V，也支援在用戶端上使用 Windows Server 2008。這個工具也將支援 NAP 提供的網路隔離功能。您可以從以下網址下載 Offline Virtual Machine Servicing Tool：technet.microsoft.com/cc501231。

Peter SkjØtt Larsen 是 Microsoft 的資深產品經理。加入 Microsoft 之前，Peter 從事電信營運軟體系統的架構與開發，以及無線服務的標準化與開發工作。
Suveen Kumar Reddy Vuppala 是 Microsoft 的資深軟體開發工程師。過去七年來他曾為 Microsoft 設計和開發即時監視工具與部署解決方案。


Windows PowerShell 設定檔的威力
Don Jones

目錄
殼層、主機及設定檔
使用您的設定檔？
建立自訂主控台
其他設定檔使用秘訣
設定檔注意！
如果您定期閱讀此專欄，現在應該已經知道 Windows PowerShell 支援設定檔系統。這些設定檔本質上是殼層指令碼 (副檔名是 .ps1)，當殼層執行時它們也會自動執行。舉例來說，設定檔提供絕佳的方法來定義自訂別名。您可以讓設定檔在每次殼層執行時都自動定義您的別名，方便您每次使用殼層時使用這些別名。
殼層定義下列四種不同的設定檔：
  • 套用至所有殼層和電腦中所有使用者的設定檔。
  • 套用至所有使用者，但只套用至 Microsoft PowerShell 殼層的設定檔。
  • 套用至目前使用者和所有殼層的設定檔。
  • 套用至目前使用者，但只套用至 Microsoft PowerShell 殼層的設定檔。
「所有殼層」的概念可能有點令人困惑。這個用語是源自早期開發 Windows PowerShell 時的一些概念，但最終產品並未採用這些概念。今日，「所有主機」這樣的用語應該比較貼切。

影片
觀看 Don Jones 示範如何建立設定檔來自訂 Windows PowerShell 殼層。

殼層、主機及設定檔
Windows PowerShell 本身是一套 Microsoft .NET Framework 組件。我喜歡將這部分的殼層稱為 Windows PowerShell 引擎，因為其中包含了一般被認定為 Windows PowerShell 的功能。不過系統並沒有提供內建的方法讓使用者與此引擎互動。若要實際使用殼層，必須透過主控應用程式 (或主機) 載入引擎。
您習慣執行的 powershell.exe 應用程式便是這類的主機。Windows PowerShell 2.0 Community Technology Preview (CTP) 隨附的 gpowershell.exe 應用程式則是另一種主機。主機與殼層之間的關係並不像我在前文所說的那麼單純，但至少涵蓋了您觀察到的行為。
重點是，如果您透過文字型命令列介面與殼層互動，那麼您很可能是使用 powershell.exe 主機。即使您是使用其他應用程式 (Exchange 管理命令介面) 安裝的捷徑來啟動殼層也不例外。Exchange 管理命令介面並非不同的殼層或主控應用程式。其實它只是使用捷徑來啟動的標準 powershell.exe 主機，該捷徑會指定一組預先載入的嵌入式管理單元和指令碼。殼層內的 Exchange 管理功能正是由那些嵌入式管理單元啟用。因此您仍然是使用相同的殼層。
powershell.exe 主機的設定檔位置 (在 Windows Vista 中) 如下：
  • %windir%\system32\WindowsPowerShell\v1.0\profile.ps1 用於電腦的所有使用者和所有殼層。
  • %windir%\system32\WindowsPowerShell\v1.0\Microsoft.PowerShell_profile.ps1 用於電腦的所有使用者，但只用於 Microsoft.PowerShell 殼層。
  • %UserProfile%\Documents\WindowsPowerShell\profile.ps1 只用於目前使用者和所有殼層。
  • %UserProfile%\Documents\WindowsPowerShell\Microsoft.PowerShell_profile.ps1 只用於目前使用者且只用於 Microsoft.PowerShell 殼層。
這些設定檔並非預設就建立的。只有您建立後，它們才存在。
每個主控應用程式都負責載入和執行正確的設定檔。如果某個主控應用程式「決定」什麼設定檔都不要載入，它就不用載入任何設定檔。設定檔執行作業不是由 Windows PowerShell 引擎自動執行。
要了解這些行徑，最簡單的方法是直接開啟殼層，輸入 $profile，再按 Enter 鍵。這樣會顯示殼層嘗試使用我稱之為「主要」設定檔的完整路徑 (它是針對使用者的殼層特定設定檔)。接著您可以建立或修改指令碼，而它會在每次殼層啟動時執行。

使用您的設定檔
我之前說過，設定檔的常見用途之一就是定義自訂別名。或者您也可以加入自訂 PSDrive (PSDrive 基本上是完全存在於 Windows PowerShell 內的對應磁碟機)。另一種比較少見的用法是根據環境中使用的軟體產品建立某種超級殼層，讓您進行各種所需的管理工作。為了充分解說超級殼層概念，我首先必須提供一些背景資訊。
在 Microsoft 中建立 Windows PowerShell 的產品小組負責其他許多核心管理技術，包括 Microsoft Management Console (MMC)。MMC 剛好可以當作 Windows PowerShell 運作方式的類比。執行 mmc.exe 時，一開始是使用一個沒什麼作用的空白主控台。然後加入 MMC 嵌入式管理單元來建立功能性主控台。
按照您的意思設定主控台之後，將主控台儲存成副檔名為 .msc 的檔案。這個儲存好的主控台可讓您隨時快速重新載入您的自訂主控台。
許多系統管理員都只依賴他們管理的產品所安裝的主控台，而非建立自訂 MMC 主控台。比方說，Exchange Server 會建立只包含 Exchange Server 嵌入式管理單元的主控台。Active Directory 使用者及電腦是另一個包含單一嵌入式管理單元的預建主控台。
Windows PowerShell 的運作模式也大同小異。與 Exchange Server 2007 管理工具一起安裝的 Exchange Management Shell 圖示，實際上是 powershell.exe 的捷徑，其中包含載入主控台檔案的指令。殼層主控台檔案具有 .psc1 副檔名，包含要預先載入的嵌入式管理單元清單 (很像是內含一份 MMC 為您預先載入的嵌入式管理單元清單的 .msc 檔案)。然而，您不會受到這種預先建立的殼層控制台的侷限。您可以建立自訂主控台 (就像對 MMC 一樣)，然後使用它來完成所有管理工作。而設定檔在此過程中扮演著關鍵的角色。

建立自訂主控台
若要建立自訂主控台，一開始應該找出要使用的每個嵌入式管理單元的完整名稱。確認所有必要的管理工具都已經安裝在電腦上。接著在 Windows PowerShell 中，執行 Get-PSSnapin –registered。此舉會列出所有已註冊但尚未載入的可用嵌入式管理單元。然後建立或編輯適當的 Windows PowerShell 設定檔。加入 Add-PSSnapin 命令，以便載入您希望隨時提供的各個嵌入式管理單元。其中可能包括 Exchange Server、System Center 產品的嵌入式管理單元，以及 PowerShell Community Extensions 等協力廠商嵌入式管理單元。接著儲存設定檔 (如果 Windows PowerShell 執行原則要求的話，記得以數位方式簽署設定檔)，然後關閉殼層。重新開啟殼層後，它會自動載入設定檔列出的所有嵌入式管理單元。
另一項技巧是將所有嵌入式管理單元載入殼層中 (使用 Add-PSSnapin 與殼層名稱)，然後執行 Export-Console 來建立包含目前使用的所有嵌入式管理單元的 .psc1 主控台檔案。接著您可以使用此 .psc1 主控台檔案來建立新的 Windows PowerShell 捷徑，此捷徑會指定 PSConsoleFile 參數和您的自訂 .psc1 檔案。捷徑將使用您的主控台，自動載入所有指定的嵌入式管理單元。

其他設定檔使用秘訣
我使用我的 Windows PowerShell 設定檔在殼層啟動時執行其他一些有用的工作。以下就是殼層在我的系統上啟動時會執行的一些動作：
  1. 針對網域管理員帳戶執行 Get-Credential，並以名為 $cred 的變數排序結果。這樣可在整個殼層中使用 $cred。我接著可以將它代入各種指令程式 (例如 Get-WmiObject 指令程式) 的 –credential 參數。既然 $cred 可儲存密碼，我可以直接使用這些指令程式，這樣就不會收到密碼提示的提示。
  2. 我執行 Cd C:\，好讓殼層在電腦的 C: 磁碟機根目錄啟動。
  3. 我執行 Out-File 的 New-Alias 來建立別名「of」。如此一來，我就可以使用「of」來取代「Out-File」。我常使用它，所以定義較短的別名非常方便。
我試圖在殼層的 HKLM: 磁碟機中建立測試機碼，它代表登錄的 HKEY_LOCAL_MACHINE 部分。如果發生錯誤，我就知道殼層是在沒有提高權限的情況下啟動。我所執行的工作通常都需要提高權限，因此我可以藉由這種方式，在進行重要工作之前很快得知我是否具有提高權限。
我定義一個名為 Ping-Address 的自訂函式，可接受電腦名稱或 IP 位址，並根據電腦是否可 ping 來傳回 True 或 False 值。我在工作中常用到這個函式，因此在設定檔中定義此函式，以便在殼層中通用。

本月指令程式：Get-WmiObject
細心的讀者可能已經發現我要討論的指令程式過去曾經出現過，不過我想要向您介紹它所提供的一項小花招。我常見到系統管理員使用下面的技巧，試著從多台電腦以文字檔列出名稱的方式擷取 Windows Management Instrumentation (WMI) 資訊：
Get-Content c:\computers.txt | ForEach-Object
  { Get-WmiObject Win32_Service –comp $_ }
雖然這項技巧可行，但您其實不需要這麼做，因為 Get-WmiObject 可以接受在 –computerName 參數使用電腦名稱陣列。您只要這麼做就能達到相同的效果：
Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)
將 Get-Content 命令放入括弧內可強迫殼層執行命令，並將結果 — 電腦名稱陣列 — 放入 –computerName 參數中。
設定檔注意！
請記住，powershell.exe 並非唯一可載入 Microsoft.PowerShell 設定檔或所有殼層設定檔的應用程式。提供 Windows PowerShell 支援的許多整合式開發環境 (IDE) — 包括 SAPIEN Technologies 的 PrimalScript、Quest Software 的 PowerGUI 及 ShellTools 的 PowerShell Plus — 也會載入這些相同的設定檔，以提供與 powershell.exe 主機同等的使用經驗。
載入很多嵌入式管理單元的大型設定檔可能讓應用程式的啟動速度變慢，因為 Windows PowerShell 引擎必須執行許多指令，才能準備好讓主控應用程式使用。事實上，如果您要執行的設定檔指令碼非常大，就連 powershell.exe 都需要花點時間才會啟動。
定義相同名稱的指令程式的嵌入式管理單元也可能導致衝突。比方說，如果有兩個嵌入式管理單元都定義名為 Get-User 的指令程式，那麼 Windows PowerShell 兩個都不會執行，除非您使用指令程式的完整格式名稱來指定所要執行的指令程式。完整格式名稱可能不太好看，因為嵌入式管理單元名稱可能蠻長的。遇到這種問題時，我通常是乾脆放棄同時載入這兩個嵌入式管理單元的念頭。相反地，我只會載入在設定檔中最常使用的那個，然後在需要時使用其他「全新」殼層來載入和使用另一個嵌入式管理單元。
Windows PowerShell 設定檔可以為殼層提供大量額外的便利性。但是要記住，如果設定檔被惡意程式碼不當編輯，也可能造成巨大的損失。您可以利用數位簽署設定檔的方式，並設定 Windows PowerShell 使用其 AllSigned 執行原則，或是修改所有設定檔上的 NTFS 檔案權限，讓一般使用者帳戶無法修改 NTFS 檔案權限，藉此保護設定檔的安全性。

Don Jones 是《Windows PowerShell:TFM》和《VBScript, WMI, and ADSI Unleashed》等書的作者。您可以透過 PowerShellCommunity.org 網站與他聯繫。


嗨，Scripting Guy！ 有名的遺言
Microsoft Scripting Guy

著名的希臘哲學家蘇格拉底 (歿於西元前 399 年，時值 Scripting Editor 誕生之前不久) 最家喻戶曉的名言或許是「未經審視的人生不值得一活」。很多人都聽過這句話。不過值得一提的是，Scripting Guy 最近發現蘇格拉底從未說過「未經審視的人生不值得一活」。其實是數百年前中世紀的抄寫者翻譯錯了。事實上蘇格拉底說的是：「未經審視的 XML 檔案不值得擁有」。
這麼一來，哲學名言總算有點道理了！XML 如今越來越普及；隨便搜尋一下某位 Scripting Guy 的測試電腦就可以找到 500 個以上由各式各樣系統或應用程式使用的 XML 檔案。
不用說，許多非常重要的資料也是以 XML 格式儲存。這麼做沒什麼問題，除非是這些資料未經審視。不幸的是，情況往往如此，只因為：很多人連怎麼審視 XML 檔案都不清楚。尤其是他們不知道如何查詢及搜尋 XML 檔案。
附註 如果您不太熟悉希臘哲學家蘇格拉底喜歡說多於做；事實上，他的妻子詹蒂碧曾說他是「無用的閒人」。因此也不難了解，Scripting Guy 為什麼對蘇格拉底心有戚戚焉。
當然，有些讀者可能會想：「等一等：Scripting Guy 不是已經在過去的專欄 (《對於追車 … 還有 XML 的迷戀》，網址是：technet.microsoft.com/magazine/cc162506) 中討論過如何搜尋 XML 檔案了？既然如此，為何現在要重炒這個話題；難道 Scripting Guy 真得這麼懶，想要一再重寫同樣的專欄？
信不信由您，我們比您想像的更懶。但這並非我們重寫此主題的首要原因。在之前的專欄中，我們所處理的 XML 檔案結構就像 [圖 1] 中的程式碼一樣，每個屬性值都代表檔案中的單一節點。
[圖 1] 只包含節點的 XML 檔案
<?xml version='1.0'?>
  <INVENTORY>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Human Resources
      </department>
      <name>atl-ws-001</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows XP</os>
      <department>Finance</department>
      <name>atl-ws-002</name>
    </COMPUTER>
    <COMPUTER>
      <os>Windows Vista</os>
      <department>Finance</department>
      <name>atl-ws-003</name>
    </COMPUTER>
  </INVENTORY>
看起來還不錯，只不過很快就有人寫信來指出，這並非唯一一種建構 XML 檔案的方式。在上例中，檔案中的每個電腦都有自己的節點；而每個節點都有一些子節點 (作業系統、部門及名稱)。但是 XML 檔案也可以建構成不含任何子節點的個別節點；額外的屬性值則設成屬性，就像 [圖 2] 中的檔案一樣。
[圖 2] 包含屬性的 XML 檔案
<?xml version='1.0'?>
  <HARDWARE>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-001</COMPUTER>
      <COMPUTER os="Windows XP" department="Finance">atl-ws-002</COMPUTER>
      <COMPUTER os="Windows Server 2003" department="IT">atl-fs-003</COMPUTER>
      <COMPUTER os="Windows Vista" department="IT">atl-ws-004</COMPUTER>
      <COMPUTER os="Windows Vista" department="Human Resources">atl-ws-005</COMPUTER>
      <COMPUTER os="Windows Vista" department="Finance">atl-ws-006</COMPUTER>
      <COMPUTER os="Windows XP" department="Sales">atl-ws-007</COMPUTER>
      <COMPUTER os="Windows Server 2008" department="IT">atl-fs-008</COMPUTER>
      <COMPUTER os="Windows XP" department="Human Resources">atl-ws-009</COMPUTER>
      <COMPUTER os="Windows Vista" department="Sales">atl-ws-010</COMPUTER>
  </HARDWARE>
那會造成問題嗎？事實上會的。在很久很久以前的專欄中，我們所示範的指令碼無法處理類似 [圖 2] 中的結構的 XML 檔案。無論如何也辦不到。這樣一定會產生問題，因為很多人都需要讀取這種類型的 XML 檔案。
只要您開口，我們就為您解決問題。呃，除此之外，還要等一年半，我們才會找出解決這個問題的辦法。
深入剖析之前，先來仔細看一下我們的 XML 檔案。在本例中，我們有一個檔案包含名為 HARDWARE 的主要節點；每個個別電腦都以 HARDWARE 的子節點的身份存在。此外，這些節點分別都有一對屬性：作業系統 (用來儲存電腦上安裝的作業系統名稱) 與部門 (用來儲存擁有電腦的部門名稱)。
舉例來說，假設我們想要取得所有執行 Windows XP 的電腦清單。可以使用指令碼來辦到嗎？當然沒問題：
Set xmlDoc = _
  CreateObject("Microsoft.XMLDOM")

xmlDoc.Async = "False"
xmlDoc.Load("HARDWARE.xml")

Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")

For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
我們來看一下這段程式碼。一開始，我們建立 Microsoft.XMLDOM 物件的執行個體；顧名思義，這是讓我們使用 XML 檔案的物件。建立好物件之後，接下來將 Async 屬性設為 False；這樣指令碼就知道我們要同步 (而不是非同步) 載入文件。指令碼為何會在意這點？老實說，它根本不在意；畢竟所有指令碼 (就像 Scripting Guy 一樣) 都是無生命的物件。
不過您應該在意。如果我們非同步載入文件，即使文件尚未完全載入，指令碼仍會繼續執行。這樣可不妙：想像一下，如果您嘗試在還不存在的文件上執行作業，那有多糟糕。同步載入 XML 檔案可確保在指令碼繼續執行之前，已經完全載入檔案。
巧的是，我們現在剛好要載入 XML 檔案了。方法是呼叫 Load 方法並開啟檔案 C:\Scripts\HARDWARE.xml，也就是使用以下這行程式碼：
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER[@os='Windows XP']")
我們在此是使用 SelectNodes 方法來查詢 XML 檔案，並告訴指令碼要擷取哪個 XML 節點。要注意的是，這裡的語法的確有點與眾不同。
一開始，我們需要指定 XML 檔案內的路徑。我們的 XML 檔案有一個最上層節點，稱為 HARDWARE，其下是一系列的第二層節點，稱為 COMPUTER。這些第二層節點分別代表 XML 資料檔案中的單筆記錄。因此我們的 selectNodes 查詢開頭就像這樣：
//HARDWARE/COMPUTER
這時我們遇到此建構函式：
[@os='Windows XP']
這個查詢部分類似標準 SQL 查詢中的 WHERE 子句。在 SQL 中，我們可能使用與此類似的資料庫查詢來擷取所有執行 Windows XP 作業系統的電腦清單：
SELECT Name FROM Hardware
    WHERE OS = 'Windows XP'
我們使用 SelectNodes 方法來進行相似的動作：我們要求取得 os 屬性 (@os) 等於 Windows XP 的所有電腦清單。為了指定這是 WHERE 子句，我們用方括弧括住整個子句。
附註 這種查詢類別稱為 XPath 查詢。若要進一步了解 XPath，請參閱 msdn.microsoft.com/library/ms256115.aspx。
我們說過，它看起來有些怪異，但的確有效。如果我們想要取得屬於財務部門的所有電腦清單呢？這沒什麼大不了的；我們對 selectNodes 的呼叫看起來像這樣：
Set colNodes=xmlDoc.selectNodes _
  ("//HARDWARE/COMPUTER" & _
   "[@department='Finance']")
同樣地，WHERE 子句也是以方括弧夾住，我們在屬性名稱 (department) 前面加上符號 (@)，接著指定所要的值。
很簡單吧！
呼叫 selectNodes 方法後，接下來我們可以重複檢查傳回值集合，並回應 Text 屬性，藉此來回應電腦名稱，如下所示：
For Each objNode in colNodes
  Wscript.Echo objNode.Text
Next
如此一來，我們可望取得什麼樣的資訊？說實話，我們完全能預期取得如下的資訊：
atl-ws-001
atl-ws-002
atl-ws-007
atl-ws-009
換句話說，它會傳回仍然執行 Windows XP 的所有電腦名稱。
附帶一提，您並不只限於回報電腦名稱；由於電腦名稱是每個節點的「預設」值，如果我們參考 Text 屬性，就會直接取得電腦名稱。
或者，您可以明確指定所要傳回的屬性值。例如，看一下這個修改過的 For Each 迴圈：
For Each objNode in colNodes
    Wscript.Echo objNode.Text
    Wscript.Echo objNode.Attributes. _
      getNamedItem("department").Text
    Wscript.Echo
Next
如您所見，在此迴圈中，我們依舊回應 Text 屬性的值；然而，我們也附加了這一行程式碼：
Wscript.Echo objNode.Attributes. _
  getNamedItem("department").Text
在本例中，我們使用 getNamedItem 方法來擷取 department 屬性的值；接著回應該屬性的 Text 屬性。我們就是透過這種方法來指定要 (和不要) 回應到螢幕的屬性值 (另外也請注意，我們加入 Wscript.Echo 命令以便在各筆記錄間插入空白行)。跑過這個指令碼後，會得到下列結果：
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources
沒錯，您可以選擇撰寫更複雜的查詢。舉例來說，假設您想要取得所有執行 Windows XP 或 Windows Vista 的電腦清單。在 SQL 中，您撰寫 OR 查詢來達到這個目的。您猜怎麼著？查詢 XML 檔案的作法也如出一轍：
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' or " & _
     "@os='Windows Vista']")
看出來我們怎麼辦到的嗎？我們在單獨一組方括弧中提供兩個條件：@os='Windows XP' 或 @os='Windows Vista'。您只需要這麼做，就能取得如 [圖 3] 所示的報告。
[圖 3] OR 查詢結果
atl-ws-001
Human Resources

atl-ws-002
Finance

atl-ws-004
IT

atl-ws-005
Human Resources

atl-ws-006
Finance

atl-ws-007
Sales

atl-ws-009
Human Resources

atl-ws-010
Sales
如果您仔細查看 XML 檔案，將會看見執行 Windows XP 或 Windows Vista 的電腦都包含在輸出中；執行 Windows Server 2003 或 Windows Server 2008 的電腦則不在輸出中，而且它們不應該出現在輸出中。
您有疑問嗎？您想撰寫限制條件更嚴格的查詢，只傳回執行 Windows XP 且屬於財務部門的電腦？您可能已經猜到了，這個工作很簡單；您只需要撰寫如下的 AND 查詢就行了：
Set colNodes=xmlDoc.selectNodes _
    ("//HARDWARE/COMPUTER" & _
     "[@os='Windows XP' and " & _
     "@department='Finance']")
這樣會傳回下列資料集：
atl-ws-002
Finance
為什麼報告中只有一個項目？說得對：因為財務部門只有一台執行 Windows XP 的電腦。
希望我們提供的資訊能協助大家處理這種特殊的 XML 檔案類型。如果暗地裡還有其他 XML 檔案類型，那就自求多福囉。
既然本月專欄是以一句名言作為開場白，那麼專欄最後同樣也該以名言收尾。因此我們要以 Scripting Guy 心愛的威廉大帝的名言作為總結：「朕於此宣布永久放棄普魯士國王及與之相連的德皇王位」。
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
這個每月一次的挑戰不僅測試您的解謎功力，更要測試您的指令碼技巧。

2008 年 10 月VBScript 填填看
為了解決這道謎題，請在每一列中填入 VBScript 函式名稱。完成時，組合藍色方格中的字母將出現另一個函式名稱。

答案是：
Dr. Scripto 的指令碼謎題 (Scripting Perplexer)
答案是：2008 年 10 月VBScript 填填看

The Scripting Guy (Greg Stemp 與 Jean Ross) 為 Microsoft 做事。


桌面檔案 自訂 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] 部署伺服器與傳輸伺服器比較
 | 部署伺服器 | 傳輸伺服器
伺服器需求 | 環境內需要 Active Directory 網域服務 (ADDS)、動態主機設定通訊協定 (DHCP)，以及網域名稱系統 (DNS)。 | 環境內不需要其他伺服器。
PXE | 支援以預設 PXE 提供者進行 PXE 開機。 | 並未安裝 PXE 提供者，因此您必須建立自訂 PXE 提供者。
映像伺服器 | 包括 Windows 部署服務映像伺服器。 | 不包括 Windows 部署服務映像伺服器。
傳輸方法 | 同時允許單點傳送和多點傳送。 | 只允許多點傳送。
管理工具 | 使用 Windows 部署服務 MMC 嵌入式管理單元或 WDSUTIL 命令列工具進行管理。 | 只使用 WDSUTIL 命令列工具進行管理。
用戶端電腦上的應用程式 | 使用 Windows 部署服務用戶端 (基本上是 Setup.exe 和支援檔案)、Wdsmcast.exe (內含在 Windows AIK 中)，或是自訂多點傳送應用程式。 | 只使用 Wdsmcast.exe 或自訂應用程式。
我說傳輸伺服器實作起來很複雜，並不是指角色本身，那其實部署起來很容易 (見 [圖 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。


安全性監控 重新認識安全性的十大不變法則，第 1 篇
Jesper M. Johansson

Scott Culp 在 2000 年發表了一篇標題為＜安全性的十大不變法則＞(英文) 的文章，這是我看過最棒的安全性文章。他所提出的論點，如今仍舊是所有資訊安全性成果的基石，如果您尚未讀過這篇文章，我建議您不妨看一下 (甚至把它印出來)，網址是 microsoft.com/technet/archive/community/columns/security/essays/10imlaws.mspx。
這篇文章獲得來自各方不同的迴響。有人挖苦它不過是 Microsoft 逃避解決許多被認定為嚴重問題的途徑。有人認為它是安全性方面最重要的基本文獻之一，甚至因此任意剽竊。不過也有人受到它的啟發，而自己另外研擬出一份列表，例如 edgeblog.net/2006/10-new-immutable-laws-of-it-security，這也是我最認同的迴響。
該文發表後的這八年來，安全性領域有了不少變化。所有重要蠕蟲一一亮相；資訊戰國時代正式開張 (包括集團犯罪、政治實體等)；各種新名詞相繼出現，並且成為常見的用詞，包括網路釣魚 (phishing)、網址嫁接 (pharming)、殭屍網路 (botnet)、間諜軟體 (spyware) 以及跨站冒名請求 (cross-site request forgery) 等；一些前所未見的複雜 Rootkit 開始在 Windows 上橫行；新的作業系統版本都大規模針對安全性以及其他仍然放任安全性問題不管的作業系統而設計。
社交工程逐漸成為重要威脅；大型零售業者洩露 9400 萬個信用卡號碼這種資料外洩行為，成為家常便飯的新聞 (而這種商店仍然不乏客戶上門)；美英政府同時錯放大量西方世界居民的私人資訊 (而大家還是繼續把私人資訊交給他們)；大量安全性劇場已經走入我們的生活 — 以及我們的機場。
我想該是重新認識十大法則的時候了。看看本世紀初所經歷的這些變化，我們還能宣稱這十大法則牢不可破嗎？如果能 — 如果 8 年過去它們仍然屹立不搖的話 — 那麼再撐個 10 年應該也沒什麼問題吧。
我將在這三篇系列報導中，仔細審視每一條法則。本月份審視的是第 1 條到第 3 條法則。下月份是第 4 條到第 7 條法則。最後一篇除了審視第 8 條到第 10 條法則之外，還會根據這些法則在 2000 年發表之後所發生的變化，另外提供一些看似合理的想法和意見，希望大家深思。
法則 1：倘若不肖份子能夠說服您在電腦上執行他的程式，您的電腦就淪陷了。
這條法則有效提出一個論點，那就是您在電腦上所執行的任何軟體，都有可能控制這部電腦。十大法則發表當時所用的 Microsoft 作業系統是 Windows 98、Windows Me 和 Windows NT 4.0，而現在所用的是 Windows Vista 和 Windows Server 2008。
您在 Windows 98 和 Windows Me 所執行的任何軟體，全都擁有完整的電腦掌控權。雖然 Windows NT 4.0 的基本安全性模型相當堅固，但只要以系統管理員的身分執行，就能將隔離模型有效降級至 Windows 98 和 Windows Me 的隔離模型。當然您也可以用非系統管理員的身分執行 Windows NT 4.0，不過相當麻煩，沒有幾家公司這麼做 (大概幾根手指頭就數得出來)。
如果您是以非系統管理員的身分執行 Windows NT 4.0 的話，說不定第 1 條法則在當初發表的時候，就已經不適用了對吧？答案仍是適用的。第一，Windows NT 4.0 有許多明顯的漏洞。比方說，有些權限設得不夠嚴格，尤其在核心物件和登錄方面。另外還有許多尚未發現，但專家已經預測會出現的攻擊類型。舉個例說，就在 1999 年的時候，大家還不知道在互動式桌面上以較高權限的使用者身分執行處理序，有可能會讓電腦陷入危險。一直到 2002 年 Chris Paget 針對毀壞攻擊 (Shatter attack) 發表白皮書《入侵 Win32 API》(英文) 之後，這個概念才成為主流知識 (seclists.org/bugtraq/2002/Aug/0102.html)。
難道 Microsoft 在第 1 條法則草創時，早已預見毀壞攻擊了嗎？其實不然。Microsoft 只是認清一個簡單的事實：很少有真正的安全性界限，可以防止電腦上執行的應用程式控制那部電腦。
Windows Vista 和 Windows Server 2008 是廢棄 Windows NT 4.0 的兩代產品。它們已經攻破第 1 條法則了嗎？有沒有哪些作業系統做得到這一點呢？其實全得視情況而定。新作業系統的安全性界限當然更加堅固，而且在 2000 年時，已有部分實驗性質的作業系統具有適當的安全性界限了。不過，那些界限仍屬少數。舉個例說，Microsoft .NET Framework 中的程式碼存取安全性就是一種安全性界限。它是專門為了防止在沙箱中執行的程式碼影響基礎作業系統而設計的。
Internet Explorer 中的 Iframes，是另一種安全性界限。但是 Iframes 並不會影響作業系統本身的存取，只會影響部分網頁內容之間的存取。Internet Explorer 中的受保護模式 (見 [圖 1])，則是一種作業系統層級的安全性界限，目的是防止瀏覽器中執行的程式碼直接影響基礎作業系統 (使用者不必採取任何動作)。其他還有少數安全性界限 (例如，標準使用者帳戶) 可以防止使用者帳戶影響基礎作業系統或其他任何使用者。
[圖 1]Internet Explorer 7 所用的是一種稱為「受保護模式」的安全性界限(按一下以放大影像)
在此您必須瞭解「安全性界限」的意義。它的意義並不在於構築一道不可侵犯的牆，提供無限且無法滲透的隔離，而是軟體廠商 (例如 Microsoft) 必須負責利用安全性修補程式，修補所有對該界限的觸犯事件。軟體都有錯誤，所以我們必須不斷找出更多觸犯事件，持續讓軟體廠商修補。久而久之，就會改善他們的軟體，防止弱點立即遭到入侵。也許我們可以把這一點視為第 1 條法則仍然適用的確認吧。
不過，我還需要考慮另一個重點。您或許已經注意到前面的「使用者不必採取任何動作」這句話。其實第 1 條法則點出的不是軟體的弱點，而是人性的弱點！關鍵就在「說服您」這一詞。倘若不肖份子能夠說服您執行這個程式，大概就能故意提高程式權限，說服您執行這個程式。
即使您沒有系統管理員權限也無妨，只要您是標準使用者，還是有權存取許多誘人的資訊，比方說，情書、照片、視訊、銀行檔案以及公司機密資料。這些資料都有可能吸引某一個攻擊者，而且不需提高權限就能夠一一讀取。就拿您在電腦上管理的資訊來說吧，光是執行一個惡意程式，就足以把您所做的一切動作全部交由攻擊者接辦。因此，如果您把「您的電腦」定義為「您在電腦上管理的資料」，就可以略過所有關於權限的討論內容不管，直接下「第 1 條法則適用」的結論。
即使沒有針對電腦定義吹毛求疵，第 1 條法則似乎還是禁得起時間考驗。第 1 條法則的重點是，身為電腦操作員的您，必須為您在該部電腦上執行的軟體負責。如果您安裝了惡意驅動程式或惡意視訊轉碼器，就等於把這部電腦的控制權拱手交給歹徒！
雖然現在軟體廠商已有許多防止意外入侵的對策 (這也是安全性界限的目的)，但是遊走全球的惡意軟體，通常都能破解這些保護措施。因此除了確保使用者沒有執行系統管理員工作的權限之外，使用者教育也是非常重要的一環。所以，雖然說目前第 1 條法則仍然適用，不過可能得稍微修改一下您電腦的定義。
第 2 條法則：倘若不肖份子能夠在您的電腦上改變作業系統，您的電腦就淪陷了。
從表面上看來，這條法則似乎很簡單。倘若不肖份子能夠在您的電腦上改變作業系統，這部電腦當然就不能信任了。但是，作業系統已經隨著運算需求的發展而改變，這又代表什麼意思呢？多年前我曾經為 The Blackwell Encyclopedia of Management (managementencyclopedia.com) 寫過作業系統這個詞彙的定義。我把它定義為輸入和輸出裝置的作業系統管理存取權，以及硬體存取權等。雖然我未將百科全書留底，原文也遺失了，但我很確定我所謂的作業系統並沒有包含接龍、Tablet 輸入系統以及視訊轉錄器。
隨著運算愈趨複雜，作業系統也開始支援其他許多功能。更複雜的是，OEM 常常會另外加入它們自己的軟體 — 外加的這個軟體，有的還算有用，有的卻只會搞破壞。有的軟體甚至與已經內建在核心作業系統的功能重疊。
舉個例說，預設安裝的 Windows Server 2008 Enterprise Edition，其磁碟使用量超過 5 GB。Windows Vista Ultimate Edition 所含的檔案超過 58,000 個，大小加起來超過 10 GB。但是構成作業系統的除了檔案之外，還有好幾千個組態設定，以及精靈或服務。
這些全部都是作業系統的一部分。作業系統是包含所有檔案、所有組態設定、所有服務，以及所有由檔案和組態設定建立的執行階段物件 (信號、具名管道、RPC 端點) 的集合詞彙。即使像系統時間和特定類型的資料 (例如事件記錄內容) 這種高度抽象的架構，也應該被視為作業系統的一部分。
作業系統的成長與演進如此之大，只要更改上述任何一個檔案，就會使電腦變得不值得信任了嗎？直接的答案是否定的。舉個例說，Windows Vista 有一個從 MS-DOS 起就存在的舊式行編輯器 edlin.exe。我是不太確定啦，不過我可以跟您賭濃縮三倍的大杯摩卡咖啡，那就是自從 Windows Vista 發表以來，所有安裝的 Windows Vista 只叫用過 edlin.exe 兩次，而且這兩次都是三分鐘前，我在回想語法的時候發生。如果有人更改 edlin.exe 或從未被用過的某個檔案，真的就表示這部電腦已經淪陷了嗎？
Edlin.exe 是作業系統的一部分，這一點無庸置擬，但是如果從未有人執行過這個檔案，那麼更改它又怎能導致它被入侵呢？答案自然是否定了。更改作業系統中從未用過的一部分，並不會入侵您的電腦，而且作業系統中從未用過的部分可多著呢。
因此，間接答案卻是肯定的。您不能只看是否有人執行過一個檔案，來判斷它的更改是否會使您的電腦遭到入侵。問題沒這麼單純。讓我們看看 edlin.exe 的存取控制清單 (ACL)，如 [圖 2] 所示。
[圖 2] edlin.exe 的 ACL 相當有限 (按一下以放大影像)
edlin.exe 的 ACL 相當有限，只有 TrustedInstaller 服務有權更改這個執行檔。這一點非常重要：這表示在您電腦上更改該檔的不肖份子具有間接的影響力。更改 edlin.exe 這個動作，就表示您的電腦已經淪陷了。關鍵在於惡意使用者有能力更改 edlin.exe。如果不肖份子能夠更改這個檔案，他就能夠更改任何檔案，換句話說，這表示電腦上的所有東西都不能信任了。
作業系統會保護自己。它會防止未經授權的更改入侵服務，防止未經授權的更改入侵組態設定，防止未經授權的更改入侵磁碟檔案，甚至防止未經授權的更改，入侵作業系統所用的信號和 RPC 端點。如果攻擊者能夠更改上述任何一個受保護的物件，他就能夠更改所有受保護的物件，而且很有可能早就這麼做了。
這是非常關鍵的一點。十大法則當中有好幾條都在告訴您，並不是進行了某個動作就表示您的電腦已被入侵，重要的是，某個人有能力進行某個動作。這一點絕對不容忽視。您一定要記得，無論就電腦安全性的哪一方面來說，能力常常遠比實際上正在採取的動作更為重要。
如果電腦對網際網路大開門戶，而且長達數月沒有修補，那麼它還值得信任嗎？不，您必須將那部電腦視為已經受到入侵了。只要是可能已遭入侵的系統，它所含的內容就完全不能信任 (我在五年前所寫的一篇文章＜救命啊！我被駭客入侵了，怎麼辦？＞(英文) 當中，就說過同樣的話，該文位於 technet.microsoft.com/library/cc512587)。如果您遇到的是一位高手，即使系統已遭入侵，可能也不會出現任何已遭入侵的蛛絲馬跡，而是看起來完全正常。
所以了，第 2 條法則仍然適用。如果攻擊者有能力更改您電腦上任何受保護的物件，您的電腦就淪陷了。記住，重要的是有沒有能力更改那些物件，而非實際上是否已經遭到入侵。
第 3 條法則：倘若不肖份子能夠毫無限制地存取您的電腦，您的電腦就淪陷了。
這條法則在 2000 年相當重要。許多人對於實際存取系統能夠做什麼不甚了解。事實上，就連某些應該清楚瞭解的政府官員也未能做到。當時安全性指導建議將 [允許不登入就將系統關機] 選項設為停用。這個舉動會使登入畫面上的 [關機…] 按鈕變灰。他所持的理論是，只要強制使用者必須先登入才能關機，就會留下關機者的稽核記錄。
這正是錯誤思考的最佳個案。要存取登入畫面的 [關機…] 按鈕，必須實際坐在主控台前。就算坐在主控台前，如果真的想要關機，只要按按電腦前面的大圓鈕，甚至拔掉電源線，就直接關機了，什麼稽核記錄都不會留下。
Windows 2000 有一個稱為 [允許卸除而不須登入] 的安全性設定，在 Windows Vista 仍然保留，如 [圖 3] 所示。它也是秉持同樣的理論，要求使用者必須先登入系統，才能從銜接站卸除膝上型電腦。
[圖 3] 難道使用者就不會把電腦和銜接站一起偷走嗎？(按一下以放大影像)
這個設定的實際安全性價值，其實相當不牢靠。我認為這個理論應該是，如果任何人都可以走近膝上型電腦把它卸除，那麼要竊取它不也是輕而易舉的事嗎？我是從沒動過這個念頭啦，不過如果我真的打算竊取膝上型電腦，這個預防措施擋得住我嗎？我只要把膝上型電腦和銜接站一起打包帶走就行了，嘿嘿嘿，連網路線和電源線我都不放過。這個冷笑話如何？
發明 Offline NT Password & Registry Editor 的 Petter Nordahl-Hagen，就有確實瞭解這個實際存取的要點。其實他的發明只是一個 Linux 開機磁碟，加上一個容許讀取和寫入 NTFS 磁碟區的實驗性 NTFS 檔案系統驅動程式。開機磁碟上的軟體，會在本機電腦上掛接登錄，並且將系統管理員帳戶的新密碼寫入 SAM (軟體資產管理) 登錄區中。您要做的只是實際存取該系統，並且等上一兩分鐘就行了。
第 3 條法則根本就是針對這樣的工具所寫的。事實上，許多產品示範都有採用 Nordahl-Hagen 的工具，只是大部分的觀眾從未確實認清這一點。我自己也在某些產品示範中用過這個工具，但是受不了老被人問：「我們要怎麼確定沒有人知道這種工具？」，「Microsoft 怎麼解決這個問題？」，於是就不用了。但是許多 IT 業界人士就是不願接受或瞭解實際存取勝過一切這個道理，而且為數還不少。
因此第 3 條法則就非常重要了。但是評論界卻毫不留情的群起撻伐。他們嘲諷這不過是 Microsoft 逃避解決任何可能 (甚至不太可能) 與實際存取有關之問題的一種作法。其實第 3 條法則常被用來駁回漏洞報告，包括 Offline NT Password & Registry Editor 入侵。但是封鎖具有系統實際存取權的攻擊者的作法，只有在這個前提下才有效：您必須確定他們無法染指任何東西。
這就是隱藏在第 3 條法則盔甲下的潛在漏洞。十大法則發表至今，磁碟全面加密技術已經成為可行的解決方案。硬碟全面加密 (嚴格說應該是「磁碟區全面加密」) 可以把整個磁碟區 (其他作業系統稱之為「磁碟分割」) 全部加密。因此，如果整個開機磁碟區 (亦即含有作業系統的磁碟區) 都被加密，我們的問題就變成：「第 3 條法則仍然適用嗎？」。
答案大概是肯定的。首先，您必須把解密金鑰儲存在某個地方。而放置金鑰和 BitLocker 預設選項最簡單的地方，就是電腦的可信賴平台模組 (Trusted Platforms Module) 晶片。要把金鑰放在這個地方，必須讓電腦自動開機。只要電腦一開機，資源和資金雄厚、並且具有電腦永久實際控制權的攻擊者，就有數不清的方法可以攻擊這部電腦。現在電腦已經可以連上任意網路，所有大概也有網路相關的方法可以攻擊系統了。
舉個例說，攻擊者可以藉由直接記憶體存取 (DMA) 裝置 (例如 USB 快閃磁碟機) 來讀取或寫入記憶體。電腦開始執行之後，一旦遇到擁有該電腦實際存取權的攻擊者，就毫無招架之力了。
如果金鑰不是儲存在電腦本身，那麼電腦的命運就取決於攻擊者是否能夠取得或猜出金鑰了。如果是使用 PIN 碼來開機，攻擊者也許不費吹灰之力就能猜出密碼。如果金鑰是儲存在另一個硬體裝置，或是從另一個硬體裝置衍生 (例如 USB 快閃磁碟機或單次密鑰)，攻擊者就必須存取那個裝置。雖然需要多花一點功夫，但攻擊者還是有辦法取得那些金鑰，或者為難有金鑰存取權的人。
您也可以用不太一樣的方式來解讀第 3 條法則：「如果攻擊者可以實際存取您的電腦，那麼電腦很可能已經遭竊，也就是說，電腦可能要不回來了」。從這個角度來看，它的確已經淪陷為別人的電腦了。再就這個觀點來說，攻擊者是否能夠存取電腦上的資料也不是重點所在。但這就不是第 3 條法則的精神了。第 3 條法則的意思是，攻擊者有權存取您電腦上的資料，而不只是有權存取電腦本身。
綜觀上述所有情況，第 3 條法則還是適用的。現今有些技術的確可以幫助您遏阻許多能夠實際存取的攻擊者，把能夠存取採用安全措施之電腦資料的攻擊者數目降到最低。僅管如此，攻擊者的成功率，始終取決於攻擊者的能力，新技術多半只是用來應付多條十大不變法則罷了。但是實際存取權仍然有辦法進入系統，只是方法比較複雜。
到目前為止，安全性不變法則還是非常經得起先進技術和時間的考驗。在前三條法則當中，以第 3 條法則最為薄弱，但即使如此，它仍然適用於某些情況。不過，它所具備的緩和措施功效也最強大，並且最垂手可得。下兩期的《TechNet Magazine》我將繼續討論這個話題，並且判斷第 4 條到第 10 條法則是否仍然適用。

Jesper M. Johansson 是負責安全性軟體的軟體架構設計人員，也是《TechNet Magazine》的特約編輯之一。他擁有管理資訊系統 (MIS) 的博士學位，研究安全性長達 20 多年，是 Microsoft 在企業安全性領域的最有價值專家 (MVP)。其最新著述為《Windows Server 2008 Security Resource Kit》。


現場筆記 高容量彩色條碼
Gavin Jancke

對我們來說，條碼實在是再熟悉不過的東西了，熟悉到幾乎忘了它的存在 — 從食品包裝到送貨標籤，它在我們日常生活當中幾乎無所不在。最初的條碼是 1974 年用於零售業的 1D 條碼，它結合了各種不同寬度的垂直線條，並且儲存了一個 12 位數的數字。條碼隨著運算能力的增長而逐步發展，到了 80 年代末期的黑白 2D 條碼 (矩陣條碼)，其資料密度已從僅僅幾個位數，一躍而為數百個位元組。
2003 年我接下 Microsoft Research 的專案，開始研究防仿冒的人體辨識卡。我需要儲存的不只是密碼編譯文字 (例如名稱和年齡)，還有指紋或虹膜範本。如果要以現有的黑白條碼儲存所有必要的資料，條碼本身就會大過識別卡，因此非得另覓途徑不可。
根據黑白 2D 條碼的標準，我必須判定如何在每一個符號儲存一位元以上的資訊。如果以彩色代替黑白，就可以使用四種和八種顏色，分別提升到兩個或三個位元的資料。
另外，我也以符號形狀進行實驗，看看它們是否能夠更緊密的包裝在一起，而不會在掃描時損及它們的註冊。一開始我覺得六邊形似乎不錯，但是這些形狀會全部混在一起，致使電腦無法清楚辨識。
最後我選擇三角形，因為它們在壓縮空間當中可以整齊交叉，卻又能保有清楚的識別形狀。如果使用成列的多色三角形，還可以將密度上限提升到 3D。
不過它必須對抗許多變數。使用色彩所要面對的最大挑戰之一，是列印規格和光源狀況的變化。對於人眼來說，辨識顏色是輕而易舉的事 (只要不是色盲都做得到)，但是對於電腦來說就不是那麼容易了。
我用了幾種不同的方法，確保軟體能夠精確讀取顏色。我在條碼中建立一個極其微小，小到幾乎不會注意到的調色盤，其中含有存在於真正條碼中的參考顏色。這個做法會提供一種校準機制，比方說，可以精確指定哪些顏色會構成某種特定的紅色。另外我也試了幾種更進階的技術，例如自訂和輕量型的顏色叢集演算法，利用顏色空間理論，將顏色分類成組。這兩種方法都同樣好用，而且還能彼此互補。
我為這個專案所訂的其中一個目標，是編寫一個可以讓手機讀取條碼的程式。使用手機時，必須考慮光源不足和焦點失調、固定焦距鏡頭等問題。而且，要在以整數為單位、慢如牛步的手機 CPU 上完成所有的電腦視覺，更是一大挑戰，因此小組必須建構一個牢靠的理論，不但能夠偵測影像中的條碼，同時又能儘量減少接觸像素。掃描必須在一個讀取品質範圍內進行，例如，較高亮度的聚焦 LCD 面板到較低亮度的失焦實體印本。
最終演算法對於即時攝影機視訊畫面上的條碼影像的解碼速度，比實際的畫面播放速率更快 — 在 200Mhz CPU 上大約 10 毫秒。在影像當中，條碼能夠容納最小資料裝載，而且仍然能夠偵測的最少像素，大約是 45 個像素的正方形。
為了能夠在多變的條件下完成這項工作，我前後花了兩年多的時間加以試驗改良。這項技術最近已經授權給協力廠商，後半年還會推出一些刺激好玩的應用方式。
Gavin Jancke 是 Microsoft Research 的工程總監，負責帶領進階開發小組與網路體驗小組。之前他曾擔任產品支援工程師、SQL Server 軟體工程師，以及比爾蓋茲的技術諮詢執行工作人員。


Windows 機密文件 努力一點，而不是聰明一點
Raymond Chen

對軟體開發人員來說，Windows 錯誤報告最大的優點之一，就是可以取得有關程式失敗過程的現實生活資訊。只要是在 winqual.microsoft.com 註冊的軟體廠商，都可以取得這些錯誤報告。當然嘍，您也可以在實驗室執行各種測試，但是實驗室的情況與現實生活的情況一定會有差距。這種差距很可能會產生實驗室從未發生，卻令客戶抓狂的錯誤。
幾年前，一位被產品可靠性小組指派負責一件工作的程式設計師曾告訴我這麼一個故事。該小組希望能夠解決某一個特定元件中故障和當機的前幾個原因。經過一番協商之後，雙方同意設立一個目標，也就是將這些類型的失敗數目降到原來的 2 分之 1。他們希望能夠修正導致該元件中過半故障和當機率的錯誤 (根據 Windows 錯誤報告的測量)。
我們都知道，失敗並不是採取平均分佈的方式發生的。有的失敗很罕見，有的很常見，有的則是很猖獗 (相對來說)。工程設計是一種交易遊戲；必須在資源 (時間、金錢和腦力) 有限的條件下，把資源投注在最有成效的地方。既然他們的目標是減少故障和當機率，因此明智的做法應該是研究 Windows 錯誤報告中提出的最常見錯誤、瞭解根本原因，然後再修正這些常見錯誤。
Windows 錯誤報告提供有關程式失敗的現實生活資訊 (按一下以放大影像)
這位程式設計師在研究失敗資料後，發現有五種故障和當機方式佔了報告的 60 % 以上。如果程式設計師可以修正導致這五種失敗的錯誤，他就能夠把故障和當機數量降到原來的 2.5 分之 1，比他們設定的目標 2 分之 1 更好。
根據 Microsoft 自己的 Windows 錯誤報告資料分析顯示，帕雷托法則 (Pareto principle) 非常適合套用在 Windows 故障和當機的案例；也就是說，大約 80% 的失敗，是由 20% 的錯誤所導致。但是同一份研究卻揭露了更驚人的結果：有 50% 的失敗，是由 1% 的錯誤所導致。雖說並非所有的錯誤都生而平等，但是分佈的情況扭曲得這麼厲害，也很教人嘖嘖稱奇。
那位程式設計師在仔細研究過五大失敗之後，終於瞭解所有的失敗都是出自於同一個原因。故障和當機只是以不同的方式表現同一個基本錯誤罷了。因此他開發並測試了一種修正程式，然後與品管小組成員共同合作，在下一個修補程式加入這個修正程式。正因為那個修正程式，使得該元件的假設失敗率立即降到原來的 2.5 分之 1。他的任務也以相當簡單的程式碼修正程式畫下句點。
聽到這個故事時，我很訝異該元件的錯誤分佈曲線竟然比 Windows 的更加陡峭。原來半數以上的故障和當機，都只是因為一個錯誤而起。少了 Windows 錯誤報告這種東西幫忙收集資料，要深入瞭解您的程式碼，簡直是不可能的。
您一定以為可靠性小組在這麼短的時間內達到目標，應該笑得合不攏嘴吧。當然嘍，只用一個小小的修正程式，就在短短兩個星期內攻破大家達成共識的目標，焉有不高興的道理。錯，他們氣極了。
「實在無法接受 — 我們原本預期要花兩個月的，沒想到竟然這麼簡單！」原來，他們是希望程式設計師努力一點，而不是聰明一點。
Raymond Chen 的網站「The Old New Thing」以及同名著作均探討 Windows 的歷史和 Win32 程式設計。他有 80% 的洗衣工作，洗的都是他 20% 的衣服。