今天的部落格文章是為 Hyper-V 和縱向擴充VM 虛擬主機的討論做一個總結。

本部落格文章由 Windows Server 團隊的首席專案經理 Jeff Woolsey 所撰寫。

虛擬化粉絲們，大家好！

在 上一篇部落格文章 當中，我們討論了 Windows Server“8 (2012)”如何針對VM 虛擬主機中導入 Guest NUMA 感知機制，以及 Hyper-V 如何在建立 VM 虛擬主機時自動執行正確的操作。讓我們來針對此議題來進一步的討論，探討從 Windows 8 Developer Preview 到 Windows Server“8”Beta（以及 Windows 8 Consumer Preview 中的用戶端 Hyper-V）有哪些功能改進。

Developer Preview 經驗總結
下圖為 Windows Server“8”Developer Preview 中 GUI 的外觀。

Windows 8 Developer Preview Hyper-V VM NUMA 設定

在開發過程中，我們發現您確實對於這些 NUMA 感知機制設定很感興趣並且開始設定它們。（符合我們的預期…）然而，當您試用完這些設定後可能並不清楚如何恢復到原來的正確設定。您所需要的便是：

“Reset”按鈕

沒錯，這正是我們所進行的改良。如果您重新查看一下 Windows Server“8 (2012)”Beta Hyper-V，會發現設定介面已經過重新設計過。您還會看到一個新的按鈕（綠色框線），按鈕上顯示「使用硬體拓撲 (Use Hardware Topology)」。按下此按鈕之後，Hyper-V 會將Guest NUMA 拓撲組態重新設定為實體硬體的拓撲。

Windows 8 (2012) Beta Hyper-V VM NUMA 設定

因此，如果您不確定設定是否正確時，可以按下「使用硬體拓撲 (Use Hardware Topology)」按鈕來得到最佳設定。最後要提醒您注意的是，您必須要先關閉 VM 虛擬主機，之後才能進行任何 NUMA 設定的更改或按下使用硬體拓撲按鈕。據我所知，目前主流的作業系統都尚未支援在VM 虛擬主機運作中更改 NUMA 設定。

Hyper-V Guest NUMA 機制的另一個好處是能夠使您得到更好的硬體投資報酬率。無論您是在此版本的 Hyper-V 上部署現有解決方案，或是建立提供日後使用的解決方案，NUMA 機制在目前十分流行，並且日後更會得到越來越廣泛的使用。事實上 Windows Server“8 (2012)”中還有另一個很好的功能：IIS 8.0。

Windows Server“8 (2012)”Hyper-V、IIS 8.0 和 NUMA 感知機制
IIS 8.0 已經具備了 NUMA 感知功能 (參考來源 IIS 8.0 Multicore Scaling on NUMA Hardware )，IIS 8.0 透過在 NUMA（Non-Uniform Memory Access）硬體上智慧的分佈和關聯 Processors來解決此問題。

Windows Server 8 (2012) 中的 IIS(Internet Information Services) 能夠辨識 NUMA機制，並且能為 IT 管理人員提供最佳設定。接著將介紹在 NUMA 硬體上使用 IIS 8.0 達成最佳化效能的不同設定選項。  
IIS 支援下列二種工作負載分區方法：

1. 在一個應用程式資源池（Web Garden）中運作多個 Processors。
如果您使用的是此模式，在預設情況下應用程式資源池設定為運作一個 Processors。為達成效能最大化，您應該考慮使運作的Processors數量與 NUMA 節點數量相同，進而使 Processors與 NUMA 節點之間形成 1:1 的比例關係。透過將“最大化Processors數量”AppPool 設定設為 0 將可以達成此目的。使用此設定時 IIS 會確定硬體上可用 NUMA 節點的數量，並且啟動相同數量的 Worker Processors。

2. 在單一 工作負載/網站 中運作多個應用程式資源池。   
使用此設定時，工作負載網站會劃分給多個應用程式資源池。例如 該網站可能包含幾個設定為單獨的應用程式資源池中運作的應用程式。這種設定會以最有效的方式為該工作負荷/網站 運作多個 IIS Worker Processors，並且 IIS 將會智慧分佈和關聯各個Processors 以達成效能最大化。

此外，在 IIS Worker Processors即將開始運作時，IIS 8.0 會透過二種方式感知最佳的 NUMA 節點。

1. 最大化可用記憶體（預設值）
此預設方法為具有最大可用記憶體的 NUMA 節點，便是最適合代管即將開始運作的額外 IIS Worker Processors節點。IIS 瞭解每個 NUMA 節點的記憶體使用情況，並且使用此資訊來對 IIS Worker Processors進行“負載平衡”。

2. Windows
IIS 還提供讓 Windows OS 做此決定的選項。Windows OS 將會使用 輪詢 (Round-Robin) 的方式。

最後，有二種不同方法可以將 IIS Worker Processors中的執行緒與 NUMA 節點進行關聯。

1. Soft Affinity（預設值）
如果其他 NUMA 節點具有周期循環的特性，則 IIS Worker Processors的執行緒可能被排程到 Non-Affinitized NUMA 節點上。此方法將有助於充分利用系統上的所有可用資源。

2. Hard Affinity
無論系統上其他 NUMA 節點的負載程度為何，IIS Worker Processors中的所有執行緒都會關聯到使用上述方法所選定的 NUMA 節點。

效能監控和Guest NUMA
您也許會想知道：“我該如何驗證正在運作的VM 虛擬主機使用的是本地端 CPU 和記憶體資源，而不是遠端資源？”Hyper-V 同樣也提供了此功能。請查看一下 Perfmon 效能計數器，您會注意到二個新的監控項目：

1.  綠色框線： 對於虛擬處理器，提供帶有遠端執行時間計數器的 Hyper-V Hypervisor Virtual Processor。   
2.  紅色框線：在 Hyper-V VM VID Paraition中，您會看到新的遠端實體 Pages 計數器。

新的Guest NUMA 效能計數器

此數值越小越好（理想數值為 0）。兩個數值都為0（最理想的情況）表示所有虛擬處理器和記憶體分配及使用都是本地端。

總結
我們希望能夠透過 Windows Server“8 (2012)”幫助您對企業進行雲端優化，使您能夠在 Hyper-V 上代管絕大部分的工作負載。同時我們還希望您能夠從長期投資中獲得效益，而這正是此版本 Hyper-V 存在的意義：   
     • 支援超大型縱向擴充 VM 虛擬主機   
     • 引入Guest NUMA 感知機制並且自動使用最佳方式設定VM 虛擬主機拓撲

最後，考慮到您目前可能沒有大型縱向擴充系統，我在此提供幾張螢幕擷取畫面以供您參考。

Cheers – Jeff

Windows Server 2008 R2 SP1 中具備 32 個虛擬處理器的Guest OS

Windows Server“8”Beta 中具備 32 個虛擬處理器的Guest OS

具備 32 個虛擬處理器的Guest OS (Centos 6.2)

大家好！ 我是 Jeffrey Snover 是 Windows Server 團隊的傑出工程師，負責該產品的架構方向和技術策略。您也許聽說過我是 Windows PowerShell 的創始人。我們一直使用本部落格來介紹和說明 Windows Server“8 (2012)”中的新功能，我將會陸續向您介紹我們團隊成員和他們的部落格文章。我自己也將撰寫一部分部落格文章。希望能夠透過此部落格幫助您踏上 Windows Server“8 (2012)”體驗之旅。首先就從我最熟悉也最重視的內容開始吧! 那就是「管理」。

Windows Server 的管理功能是它能夠從同類產品中脫穎而出的原因所在，這也是我們所一直引以為傲的。對於 Windows Server“8 (2012)”我們的使命是提供最好的雲端優化作業系統。因此，我們需要重新打造不同的操作體驗，並且重點會放在使用者透過 PowerShell 和 WMI 針對多種應用情況對多台主機進行管理。當您親身體驗它的強大管理功能時，相信您也會和我有同樣的感受，會被它的 簡潔、強大、直覺 所吸引。此管理架構能保證您從 GUI 執行的所有操作都可以透過指令自動執行。高度的自動化運作能夠提高管理者所管理的伺服器數量，提高 IT 操作的品質和可重複性，並且幫助您可以將相關動作安排在週末，而您自己則可以悠閒的享受假期。簡單來說，管理功能的體驗就是在幫助管理人員減輕管理負擔。我們從 Windows Server“8 (2012)”中所進行的眾多改良當中選取一小部分，在本部落格文章中進行重點式的介紹。請您先閱讀本文當中的介紹，然後下載 Beta 版本 Windows Server“8 (2012)”和遠端系統管理工具，親自感受一下它們的魅力。我相信您一定能體會到無窮的管理樂趣。

本部落格文章由 Windows Server 管理團隊的合作夥伴經理 Erin Chapple 所撰寫。

–Cheers！Jeffrey

____________________________________________________________________________________________

Windows Server 的一個主要獨特之處在於一直以來我們對於提供業界領先的管理操作體驗，幫助管理人員更好更容易的管理伺服器。Windows Server“8 (2012)” 為管理人員提供的 簡單性、多樣性和強大性方面進行了許多重大方面的改善，並且讓這些特色功能達到了不同的境界。

經過重新設計的伺服器管理員和整合式體驗

在前二個版本發佈之前，我們導入了伺服器管理員。伺服器管理員提供以角色為中心的單台伺服器單一管理視窗，儲存管理人員每天需要執行和常用的管理項目。當我們了解管理人員所面臨的難題時發現到，伺服器管理員雖然是一個很好的管理起點，但是在 Windows Server“8 (2012)”當中，我們需要重新打造不同的操作體驗。因此我們開始重新設計全新的伺服器管理員，以提供雲端優化作業系統所需要的管理操作體驗。

同時管理多台伺服器

與雲端環境接軌時，伺服器管理員需要進行的重要轉變是從環境中以角色為中心的單一視窗切換到多台伺服器管理視窗。伺服器管理員所提供的多台伺服器管理功能，可以使管理人員增加他們所負責管理的伺服器，方便同時查看多台伺服器資訊（例如事件、服務、效能）並且採取相對應的措施。而且，無論是實體伺服器還是虛擬伺服器，都擁有相同的管理操作體驗。伺服器管理員透過 WMI、PowerShell 的多台主機管理功能，以及 Windows PowerShell Workload 功能來達成此一目標。幾乎所有使用伺服器管理員完成的操作，相對的都可以透過 Windows PowerShell 來完成。這使得管理人員可以自動執行各種操作，因此能夠有效節省時間、提高品質、管理一致性，並且提高管理人員與管理伺服器台數的比例。

新奇卻又熟悉的操作體驗

Microsoft 設計正逐步朝向 Metro 風格轉變，對於我們來說這是打造出現代化操作體驗的機會。Windows Server 也將需要將操作方式進行更新並重新設計。但是我們深知，所有的新式操作體驗都必須要與管理人員目前的工作方式互相關聯，以避免打亂他們目前的工作方式。因此我們在 Metro 風格設計原則 當中，將伺服器管理員進行集中在三個方面的改良：

· 介面直覺 – 管理人員透過一個單一視窗便能立即瞭解目前運作狀態以及需要注意的部份，在伺服器管理員儀表板當中提供了一個直覺式的伺服器環境視窗，並且以紅色突顯出需要注意的關鍵問題。

· 易於管理 – 管理人員可以直接根據所看到的資訊採取相對應的措施。只需要按一下滑鼠便可以解決問題，而不需要再打開其他工具。在伺服器管理員儀表板中，管理人員可以同時查看及管理多台主機上所運作的服務。

· 互相關聯 – 管理人員可以根據需求自行定義。顯示的資訊可以根據管理人員的環境及權責進行定義，以真正符合管理人員的需求，透過伺服器管理員的“管理”功能表，管理人員可以增加欲顯示在儀表板上的自訂群組。

自訂的伺服器群組將成為一個項目區塊儀表板當中顯示，使管理人員可以對該定義的群組狀態一目瞭然。

針對應用情境的整合式體驗

伺服器管理員能夠跨越伺服器提供相同的任務，使管理人員可以深入查看伺服器的特定視窗，瞭解環境狀態並採取相對應的措施。以伺服器為中心的視窗只是有效管理的其中一個重要因素。以角色為中心的視窗也同樣重要，在經過重新設計的伺服器管理員當中，能夠擴充管理某些伺服器角色，因此可以提供符合多種應用情境的角色管理操作體驗。

檔案服務、遠端桌面服務和 IP 位址管理…等服務都提供了全新的管理操作體驗，這些操作體驗都符合上述中所提到的伺服器管理員設計原則。最後的結果就是提供一種全新的操作體驗，並且這些操作體驗與管理人員所需管理的內容相關，並能在協助管理人員完成特定任務的同時提供有助於檢查問題的相關資訊。

上述應用情境當中伺服器管理員能整合和多台主機進行管理，因此相關主機資訊明顯增加。要使這些資訊具備更加強大的功能。在新的伺服器管理員操作體驗當中，您將看到豐富的過濾和管理功能，使管理人員可以查找企業所需的資訊並採取相對應措施。

支援舊版 Windows Server

管理人員所面臨的是一個需要管理多種版本的 Windows Server 環境。為了支援提供管理多台伺服器環境的統一視窗，我們建立了一系列新的 WMI 程式，使伺服器管理員可以從 Windows Server 2008 R2 和 Windows Server 2008 主機中收集資訊。這些連接程式可以透過 Windows Management Framework 3.0 進行獲取，並且當安裝在 Windows Server 2008 R2 或 Windows Server 2008 電腦中時，伺服器管理員便可立即從這些主機上收集有關事件和服務等詳細資訊，之後匯總到儀表板當中。

在進一步深入討論之前我們必須要先澄清一件事情： 我們主張為管理人員提供量身打造的豐富圖形化介面的操作體驗，並且希望幫助他們輕鬆且有效率的完成工作。全新打造的伺服器管理員和 Windows Server“8 (2012)”整合式工具對於管理人員而言將會是最佳組合。

並且 全新管理操作體驗並非只是與圖形化介面相關。

以及 該伺服器應該用於執行與伺服器相關的任務，而非僅僅作為管理介面。

接著讓我們來詳細看看這其中的每個部份。

命令列介面 (CLI) 也是管理操作體驗的一部分

某些使用者誤以為我們對於 Windows PowerShell 的投入是為了朝向 CLI 的過渡。他們把這種舉動看看是 GUI 和 CLI 二選一的問題。事實上我們從來沒有產生過這種想法。我們一直把 Windows PowerShell 當作附加選項，也就是我們一直把 GUI 和 CLI 當成是 共存 來看待。

每位管理人員的管理習慣都不相同，有部分管理人員喜歡使用GUI 圖形化介面，也有人喜歡 CLI 指令介面使自動化作業更有效率，我們將為這些管理人員提供豐富的 CLI 和 GUI 操作體驗。更重要的是隨著朝向雲端環境的邁進，如何採用自動化解決方案變得越來越重要，我們也希望管理人員能夠進行相對應的擴充。整體來說，自動化作業減少了人為因素，提高環境的可靠性、可審核性、可預測性。後續我們將有一篇完整的文章專門介紹自動化部份（敬請期待！），現在則先重點介紹 CLI 在操作體驗上的改進，例如我們投入了大量心力將 Windows PowerShell 整合腳本環境 (ISE) 打造成一個出色的 Windows PowerShell 管理工具。

下列為 Windows PowerShell ISE 當中我最喜歡的三個新功能，能夠幫助您 探索、學習、簡化伺服器任務的自動化。

顯示相關命令

Windows Server“8 (2012)”中有多達 2,300 多個指令 (cmdlet)，您腦海中出現的第一個疑問可能是： 我要怎麼樣才能找到我需要的指令？ Widows PowerShell ISE 中新增的“顯示指令”視窗可以讓您輕鬆的搜尋指令、參數，之後將執行指令或將指令插入腳本當中。“顯示指令”充分利用 Windows PowerShell 的獨特架構，此架構中每個指令都有相關的參數及其相關資訊，並且 Windows PowerShell 為每個指令提供一個通用分析程式。該架構中允許搜尋指令，並且使用參數中繼資料來為指令產生一個 GUI 介面。您可以在 Windows PowerShell 中輸入以下指令，體驗一下此架構中的樂趣：(Get-Command Get-Process).ParameterSets

智慧型感知功能 (Intellisense)

現在我已經熟悉新的相關指令接下來的問題則是： 我該如何記住我所使用的指令？ 在 Windows PowerShell 一直以來的承諾是保障一致的執行環境，使您可以構思、輸入和獲取所需要的內容。Intellisense 智慧型感知功能可以在您輸入指令時，將會自動顯示與該指令相關的參數以及語法。之所以能夠達成這樣的功能，是因為 Windows PowerShell 3.0 使用 .NET 動態語言運作時 (DRL)，採用了 並 AST 機制 (Abstract Syntax Tree)，進而使 Intellisense 功能可以推斷出指令及其執行環境。

Windows Powershell ISE 中新推出的 Intellisense 功能，可以幫助管理人員有效尋找指令及語法。

Intellisense 功能不僅僅適用於它所識別輸入內容的指令，還能夠提供檔案系統的深層資訊，使得管理人員無須記住相關路徑！

範例程式碼

我已經準備好在腳本環境中運用所掌握的指令技術，但是我該如何記住常用腳本任務的語法？ 當您啟用程式碼片���功能後，只需按下滑鼠就可以查看常用的腳本範例！ 範例程式碼還可以進行完全的擴充，也就是說您可以增加定義的腳本樣式，以避免每次撰寫新腳本時須要記住（並輸入）腳本樣式的麻煩。當您啟用“範例程式碼 (Ctrl + J)”功能之後，管理人員可以從一系列內建的腳本範例中進行選擇。

下圖中為管理人員選擇了 if-else 腳本範例，系統已經將其插入腳本視窗當中。

透過上述這些功能改進，我們大大提高了腳本的易用性，以使更多的管理人員能夠利用它達到強大的自動化功能。

“Server Core”是部署時的首選安裝模式

儘管我們很喜歡 GUI 圖形操作介面，但是我們認為它應該是存在於管理人員的個人主機上，而非伺服器上！ 伺服器硬體資源比起使用者端資源昂貴許多，在伺服器上運作 GUI 圖形介面需要額外的軟體元件。每個元件都可能會減少伺服器的安全性和服務性，因此您應該只安裝對於該伺服器工作負載來說必要的元件即可。伺服器上運作的元件越少，所需要的修補程式也就越少，因此伺服器工作負載的可用資源也就越多。在此版本中，我們能協助管理人員可以選擇“Server Core”作為 Windows Server 的主要部署選項 (也是 Server 2012 當中預設的安裝模式)。並且持續提供“GUI 圖形介面伺服器”以作為相容選項。

“Server Core”上可運作的伺服器角色數量增加到了 13 個並且支援 SQL 2012，以消除管理人員最常反應無法使用“Server Core”安裝模式的主要原因。現在所有伺服器上都預設安裝並且啟用不受防火牆影響的遠端系統管理 (WinRM) 和 Windows PowerShell，您無須進行任何設定便可以遠端管理伺服器。Windows PowerShell 中 2,300 多個指令提供適用於大多數管理應用場景的指令集。我們發佈了 Windows 8 版本的 遠端伺服器管理工具 (RSAT)，同時也在 Server 8 (2012) Beta 版本當中提供了豐富的 GUI 操作體驗，以便從 Windows 使用者端管理所有伺服器 (包括Server Core)。

然而，最重要的是我們達成能在“Server Core”和“GUI 圖形介面伺服器”，這二者之間進行切換並且無須重新安裝伺服器！ 這就表示，管理人員可以放心使用“Server Core”部署伺服器，如果後續有需要 GUI 圖形介面時，便可以透過 SCONFIG CLI 工具、Windows PowerShell、增加/刪除 角色和功能精靈隨意增加和刪除。未來我們將會發表專門介紹 Server Core 的部落格文章，向您介紹此一部署選項的所有優勢和詳細資訊，請您拭目以待。

如果上述這些還不夠，正如同在 今年年初所發表的部落格文章 當中所介紹的那麼，我們新增了“最精簡伺服器”安裝模式，該安裝模式使得 GUI 圖形工具可以在“Server Core”上運作，但是並不會安裝 Desktop Shell 或 Internet Explorer。當您登入時預設會啟動伺服器管理員和 cmd.exe，之後您可以使用它們啟動其他 GUI 工具。這安裝模式提供“Server Core”的優點，但同時具備管理人員登入伺服器時所需要的 GUI 圖形介面操作需求。

在伺服器管理員的“管理”功能表當中，管理人員可以選擇“刪除角色和功能”在“GUI 圖形介面伺服器”和“最精簡伺服器”或“Server Core”之間切換。

“最精簡伺服器”提供“Server Core”的優點，但允許管理人員運作如伺服器管理員這樣的 GUI 圖形介面工具，以及如電腦管理這樣的 MMC 工具。

Metro 風格和本機伺服器管理新體驗

既然本部落格文章是為了介紹管理體驗，那麼就必須探討一下 Windows Server 如何採用新的設計語言和 Metro 風格介面的功能才算完整。在 Windows Server“8 (2012)”設計初期，我們詢問了許多管理人員的意見，瞭解他們的需求來確定我們的設計方向。我們所得到的意見反應結果是大多數管理人員都需要同時管理伺服器和用戶端電腦。因此，資訊的一致性就顯得非常重要。資訊一致性並不僅僅適用於我們管理人員。為了使管理人員無論在本地端還是遠端桌面服務都能獲得相同的操作體驗。我們自訂了伺服器上的預設管理行為，以針對管理任務進行優化。在這個管理方向上，我們預設登入進入桌面後。便會自動運作伺服器管理員。伺服器管理員透過“工具”功能表展開全部管理工具。我們將伺服器管理員和 Windows PowerShell 等常用應用程式固定到工作列上。因此當您看到開始登入視窗時，就會看到這些熟悉且常用的應用程式。

Windows Server 的“開始”螢幕上預設固定了常用的管理工具。

有了“Server Core”作為部署作業的推薦選項，以及“最精簡伺服器”安裝模式，我們希望大多數管理人員都不再需要使用伺服器上的“開始”畫面，但是如果需要使用到，那麼應該會很快發現伺服器的操作體驗與使用者端操作體驗完全一致。如上述中所提到的，敬請期待未來詳細介紹“Server Core”和“最精簡伺服器”安裝模式的部落格文章。

結語

我們投入了大量精力打造 Windows Server“8 (2012)”的管理操作體驗，以確保管理人員可以選擇完成工作的方式，並且確保每個選項都簡潔且高效率。Windows Server“8 (2012)”將為各種企業規模的管理人員提供最快、最具擴充性和最靈活的解決方案。

立即就試用享受新一代的伺服器管理體驗！

在開發 Windows Server“8 (2012)”儲存功能的過程中，每當想到使用者即將能享用的功能以及這些背後出色的功能時，我都會情不自禁的露出笑容。無論您是使用針對區塊等級 (Block Level) 的儲存區域網路 (SAN)，還是使用針對檔案等級 (File Level) 的儲存解決方案，我們都根據您的選擇對二種儲存類型投入了大量研發精力。在本篇部落格文章當中，我們將會重點介紹我們對針對檔案儲存的投入。我們的團隊互相合作針對整個儲存堆疊進行徹底的重建。從我們更新資料的方式從 儲存空間、新一代檔案系統 (ReFS)，一直到 SMB 協定和叢集共用磁碟區 (CSV) 中的功能改進，再到對啟用 SMI-S 儲存裝置的支援，Windows Server“8 (2012)”從根本上改變我們對儲存結構和解決方案的思考方式。簡單來說 Windows Server“8 (2012)”將用於儲存的營運成本降到最低，在某些情況下降低幅度非常明顯。如果您正在使用儲存設備應該停下手中的工作，花一點時間瞭解一下 Windows Server“8 (2012)”儲存功能，並重新思考之後的工作方式。

在本篇部落格文章當中，我們將會探討由 Windows Server“8 (2012)”達成一種新的應用情境：伺服器應用程式儲存至檔案共用當中。這是起因於一個非常簡單的問題：“為什麼伺服器應用程式不能利用我們的檔案伺服器？”經過專案經理、開發人員和測試人員的全力奮戰，將問題一點一滴的逐步拆解，終於設計出一套功能全面的儲存機制達成了此一應用情境。建議您 下載 RC 版本 並且親自體驗一下。

本篇部落格文章由檔案伺服器團隊的首席專案經理 Claus Joergensen 和 Jose Barreto 所撰寫。

–Cheers！Jeffrey

技術背景

Windows 檔案伺服器主要用於儲存使用者資料。典型的企業應用情境是使用者在此存放那些非共用資料以及團隊共用資料以進行協同合作。Windows Server“8 (2012)”檔案伺服器導入了能夠在 Windows 檔案共用上儲存即時資料的伺服器應用程式支援 (例如 Hyper-V™ 和 Microsoft SQL Server)。使用者可以使用儲存於 Windows 檔案共用上的 設定檔、VHD 檔案、快照檔案 來設定 Hyper-V 虛擬主機。如下圖中顯示儲存於 Windows 檔案共用 (UNC 路徑) 上的 VHD 檔案設定的VM 虛擬主機：

達成新式應用情境

在 Windows Server“8 (2012)”規劃過程當中，使用者對於能夠在 Windows 檔案共用上儲存伺服器應用程式資料的功能表現出濃厚的興趣。對於許多中小型企業管理人員來說，這是一種可以替代 SAN 儲存架構的另一種具備經濟效益的方式，因為他們可以利用 Ethernet 基礎網路架構，並且搭配使用業界標準的伺服器。同時在建立檔案共用時，由於不需要設定 Zone 及 LUN Mapping/Masking機制，因此管理人員能夠更輕鬆的管��檔案共用。除了具備經濟效益、更易於管理之外，儲存伺服器應用程式資料的功能還可以使大型環境管理者和主機代管供應商獲得更大的靈活性，可以在資料中心內轉移工作負載，並且無須重新組態儲存設定。如果資料儲存在 UNC 共用路徑當中，只要使用正確的管理認證，就可以從資料中心的任何位置存取該資料。

有了針對此一新式應用情境的支援，所有管理人員都多了一個儲存選項，並且可以根據自己的偏好、預算和所需功能從 光纖通道、iSCSI SAN、共用 SAS 儲存陣列或檔案共用中進行儲存方案的選擇。

啟用檔案共用功能以提供伺服器應用程式進行儲存

要使伺服器應用程式能夠將即時資料儲存在檔案共用上，需要滿足二個要求。首先，伺服器角色或應用程式要能支援該功能。這包括在應用程式的安裝和管理工具中將其更新為支援 UNC 路徑 (例如 \\server\share\file.vhd)，以及在此應用情境的使用情況中完全測試應用程式。Microsoft SQL Server 2008 R2 中提供了針對在 SMB 檔案共用中儲存 SQL 使用者資料庫的支援。Microsoft SQL Server 2012 更增加了對 SQL 系統資料庫以及將 SQL Server 設定為叢集的支援。正如 //BUILD 大會上所展示的那樣，Windows Server“8 (2012)”還增加在 SMB 檔案共用中儲存VM 虛擬主機檔案的支援。

此外，檔案伺服器本身也應該支援伺服器應用程式在檔案共用上儲存資料。在 Windows Server“8 (2012)”使用者互動活動當中，我們確定了以下幾項檔案伺服器要支援儲存伺服器應用程式所應滿足的首要條件：

連續可用性： 伺服器應用程式要求儲存空間要持續可用，並且一般情況下不處理 I/O 錯誤或檔案控制碼的意外關閉。這些事件類型可能會導致VM 虛擬主機當機（因為VM 虛擬主機無法再寫入到磁碟當中），或者導致資料庫離線事件。管理人員通常會部署硬體容錯機制（例如多片網路卡、多台網路交換機和 Windows 叢集設定）以降低硬體問題所造成的影響。儘管這種配置可以使檔案伺服器迅速從故障中復原，但是這種故障復原對於應用程式來說並非透明轉移，必須要將 VM 虛擬主機重新開機以及使資料庫復原成連線狀態。Windows Server“8 (2012)”檔案伺服器解決方案必須能夠快速並且透明的從網路或節點故障中復原，不需要管理人員介入就能避免停機事件發生。

效能： 一些伺服器角色（例如 Hyper-V 和 SQL Server）對於儲存效能十分敏感，包括傳輸頻寬、延遲時間和 IOPS(每秒 I/O)。另外有一點非常重要的是，應該要將存取儲存時的 CPU 使用率保持在最低，以盡可能為應用程式提供更多的 CPU 使用率。最後，伺服器應用程式更傾向於採用與使用者端應用程式完全不同的存取模式。使用者端應用程式通常用於會完整讀取或寫入檔案的應用場合，伺服器端應用程式則更傾向於附加或更新現有資料。Windows Server“8 (2012)”檔案伺服器解決方案必須要能夠為伺服器應用程式，提供幾乎相當於具有多個 10 Gbps 乙太網路或 Infiniband 的儲存頻寬，其延遲時間、IOPS 和 CPU 使用率更應該要可以與光纖通道互相匹敵才行。

可擴充性： Windows 檔案伺服器叢集的設定通常部署成 Active-Passive 組態，這種設定會至少保留一個節點不使用。其中一種解決方法是在一個叢集當中設定多台節點主機。這將使您可以使用叢集中的多台硬體。然而，這會增加管理負載，並且共用頻寬仍舊受到目前線上節點主機可用頻寬的限制。Windows Server“8 (2012)”檔案伺服器必須要能夠支援 Active-Active 組態，在這種設定中可以透過任何節點進行存取共用，以將最大可用頻寬提升到叢集節點數量的總合頻寬，並且簡化管理作業。

資料保護： 另外一項重要功能是為資料建立應用程式一致的磁碟區陰影副本以用於備份目的，在 Windows Server中通常使用磁碟區陰影複製服務 (VSS) 達成。然而目前的 VSS 僅支援本機儲存區並不支援 UNC 路徑的檔案共用。而 Windows Server“8 (2012)”檔案伺服器解決方案必須要能夠與 VSS 完全整合支援應用程式一致的磁碟區陰影副本，並將對現有 VSS 請求程式、寫入程式和提供程式的影響降至最低。

很明顯的，這是一系列相當嚴格的要求。但是我們知道必須要解決所有問題，才能提供一個可靠、可用和可服務的檔案伺服器，進而為伺服器應用程式儲存提供最佳效能。

功能特色概述

在 Windows Server“8 (2012)”中提供對伺服器應用程式儲存的支援檔案共用，是產品團隊做出的一項重大決定。因此建置導入相關功能來確保檔案儲存能夠滿足或超過用於區塊等級儲存的要求，同時又不失去檔案儲存的輕鬆管理和經濟效益的優點。同時還需要導入新版本的 SMB 協定。這些新功能包括：

SMB 透明容錯移轉 (Transparent Failover)： 使管理人員能夠在叢集檔案伺服器上執行節點主機的硬體或軟體維護時，不會妨礙伺服器應用程式在這些檔案共用上的儲存資料。此外，如果叢集節點發生硬體或軟體故障時，此功能將使 SMB 使用者端以透明的方式重新連接到其他叢集節點，而不會妨礙伺服器應用程式在這些檔案共用上的儲存資料。無論故障發生時正在執行的操作是哪種類型，都可以達成此目的。對於針對區塊等級的儲存這等同於擁有多台控制器的儲存陣列設備。

SMB 多通道 (MultiChannel)：使您能夠同時使用多個連接和網路介面，主要有二大好處：提高吞吐量並且達成容錯功能。例如 您的 SMB 使用者端和伺服器上各有 4 個 10 GbE 介面，那麼您可以同時使用這些介面也就是合併 4 個 10 Gbps 網路介面卡有效達到 40 Gbps 的傳輸頻寬。如果其中一個網路介面卡或纜線出現故障，您的 SMB 使用者端將繼續使用其他未中斷的網路，只是整體傳輸頻寬會有所下降而以。最重要的是，您無需任何額外設定步驟便可達成此一效果。您只需要和平時一樣設定多個網路介面即可。

SMB 直接存取 (Direct)： 光纖通道儲存的一大優點是能夠具有低延遲、快速、高承載的資料傳輸。為了在檔案伺服器環境中達成類似功能，SMB 支援具有 RDMA 功能的網路介面卡，因此能在傳輸時達成 低延遲、低 CPU 使用率。當使用具有三種 RDMA 技術 （Infiniband、iWARP、RoCE）時，SMB 使用者端的 CPU 消耗非常低，這與光纖通道形成強烈的對比，並且能縮短 CPU 運算週期以供提供伺服器上的主要工作負載（例如 Hyper-V 或 SQL Server）使用。最棒的是，無須額外的 SMB 設定步驟即可檢測並運作這些網路介面。如果網路卡支援 RDMA 功能將會自動使用這些介面。

SMB 水平擴充 (Scale-Out)：籍由叢集共用磁碟區 (CSV v2.0)，管理人員可以建立的檔案伺服器叢集中所有節點以直接 I/O 方式同時存取資料檔案的檔案共用。這也表示特定共用的最大檔案服務容量不再受單個叢集節點的容量限制，而是可以達到整個叢集的總合頻寬。此外， Active-Active 設定將使您可以透過移動檔案伺服器使用者端來平衡叢集節點之間的負載，並且不會出現任何服務中斷的情況。最後，SMB 水平擴充簡化叢集檔案伺服器和檔案共用管理作業。

支援 SMB 檔案共用的 VSS： 為了使伺服器應用程式資料建立應用程式一致的快照功能，對於資料備份作業來說非常重要。在 Windows 當中通常會使用磁碟區陰影複製服務 (VSS) 機制達成。對於針對 SMB 檔案共用的 VSS 擴充了 VSS 的基礎結構，現在可以支援儲存於遠端 SMB 檔案共用中的資料製作應用程式一致性的磁碟區陰影副本，達成備份和復原資料的目的。此外，SMB 檔案共用的 VSS 可以啟用備份應用程式，以直接從磁碟區陰影副本檔案中讀取備份資料，而無須在資料傳輸過程中涉及伺服器應用程式。由於此功能利用現有的 VSS 基礎架構，因此使用者可以輕鬆完成與現有 VSS 感知備份軟體和 VSS 感知應用程式（如 Hyper-V）的整合。

針對 SMB 共用的 PowerShell： 管理檔案共用時使用的是新的支援檔案伺服器叢集的 Windows 伺服器管理員 GUI（其中包括一些用於建立 SMB 共用的設定檔），或使用全新的 SMB Windows PowerShell Cmdlet，這些 Cmdlet 使用熟悉的 Windows PowerShell 基礎架構來運作命令列和腳本。這一整套新的 Windows PowerShell 3.0 Cmdlet 專門用於管理檔案共用、檔案共用權限、使用者端對應、伺服器設定和使用者端設定。還有豐富的 Cmdlet 用於 監控Session、開啟檔案、存取連接、網路介面和多通道連接。這些 Cmdlet 是使用 WMI v2 建立在針對標準的管理協定基礎之上，使開發人員可以在 Windows 和 Linux 上建立自動化解決方案，以用於檔案伺服器的設定和監控上。

SMB 效能計數器： 在應用程式伺服器世界裡，儲存效能和測量效能的能力都非常重要。在此前提之下，Windows Server“8 (2012)”導入了伺服器和使用者端效能計數器，使管理人員可以輕鬆查看檔案儲存的關鍵指標，包括 IOPS、延遲時間、佇列長度和吞吐量。這些計數器與您所熟悉的儲存效能計數器類似，使您可以輕鬆利用現有的 Windows Server 儲存效能相關的監控規則。

效能： 效能也是 SMB 中需要重點關心的一個部份。除了達成預設啟用大型傳輸單元 (Large MTU) 之外，還需要執行大量工作來優化不同類型工作負載的效能，這些工作負載 I/O 有小有大，還會同時涉及循序存取和隨機存取。這些優化過程是在研究典型的端點到端點工作負載過程中所開發出來的，例如 線上交易處理、資料倉儲、私有雲中的虛擬 Web 伺服器、虛擬桌面基礎架構。正是這些研究帶來作業系統許多方面的功能改進。

我們來深入探討一下 SMB 透明容錯移轉機制。SMB 透明容錯移轉機制要求：

l 運作 Windows Server“8 (2012)” 容錯移轉叢集，至少要具備二個叢集節點，並且安裝設定檔案伺服器角色。最後該叢集必須要通過 “驗證設定精靈” 中的叢集驗證測試。

l 使用連續可用性屬性建立的檔案共用，該屬性是叢集檔案共用的預設組態設定。

l 存取叢集檔案共用的電腦必須是 Windows “8” Consumer Preview 或 Windows Server “8 (2012)”。

當 SMB 使用者端初次連接到檔案共用時，使用者端將會確定該檔案共用是否設定了連續可用性屬性。如果已經設定則表示該檔案共用是一個叢集檔案共用，支援 SMB 透明容錯移轉功能。當 SMB 使用者端隨後使用應用程式在檔案共用上開啟一個檔案時，它會請求一個永久檔案控制碼。當 SMB 伺服器收到使用永久控制碼開啟檔案的請求時，SMB 伺服器將會與復原金鑰過濾器進行互動，以將該檔案控制碼相關資訊，以及一個由 SMB 使用者端提供的唯一金鑰（復原金鑰）保存在儲存當中。當 SMB 使用者端遇到 SMB 伺服器發生容錯移轉時，在後續的復原操作中便會使用該復原金鑰來引用控制碼。以避免將資料寫入不穩定的快取記憶體所導致的資料遺失，並且在完全寫入狀態下始終會開啟永久檔案控制碼。

如果 SMB 使用者端所連接到的檔案伺服器叢集中節點主機發生故障，SMB 使用者端會嘗試重新連接到其他檔案伺服器叢集節點主機。一旦 SMB 使用者端成功重新連接到叢集中的另一台節點主機時，SMB 使用者端將開始使用復原金鑰執行復原的動作。當 SMB 伺服器收到復原金鑰時，它將會與復原金鑰過濾器進行互動，以將檔案控制碼復原到發生故障前的狀態，並且提供對可重複操作以及不可重複操作的端點到端點支援（SMB 使用者端、SMB 伺服器和復原金鑰過濾器）。SMB 使用者端電腦上運作的應用程式在此操作期間將不會發生任何故障或錯誤。從應用程式角度來看的話，似乎只是 I/O 操作出現了短暫的中斷而以並不影響運作。

非常重要的一點是，在容錯移轉期間應該要將 I/O 中斷次數降到最低。由於 SMB 是在 TCP/IP 的基礎上運作，SMB 使用者端通常會依賴 TCP 逾時來確定檔案伺服器叢集節點主機是否發生了故障。但是，依賴 TCP 逾時會導致相當長時間的 I/O 中斷，因為每次逾時通常都需要大約 20 秒才會判定。SMB 見證服務建立用於從計畫外故障中快速復原，使 SMB 使用者端不必等待 TCP 逾時才判定。SMB 見證是隨著容錯移轉叢集功能自動安裝的一項新服務。當 SMB 使用者端初次連接到某個檔案伺服器叢集節點主機時，SMB 使用者端會通知運作在同一台電腦上的 SMB 見證使用者端。SMB 見證使用者端會從運作在檔案伺服器叢集節點上的 SMB 見證服務獲取叢集成員清單。SMB 見證使用者端會選舉出一個不同的叢集成員，並向該叢集成員上的 SMB 見證服務發佈一個註冊請求。

如果該檔案伺服器叢集節點上發生計畫外的故障狀況，那麼另一個叢集成員上的 SMB 見證服務便會收到叢集服務的通知。SMB 見證服務也會通知 SMB 見證使用者端告知該檔案伺服器叢集節點主機已經發生了故障。因此在收到 SMB 見證通知之後，SMB 使用者端會立即開始重新連接到其他台檔案伺服器叢集節點主機上，以提高從計畫之外的故障狀況快速復原。

部署模式

在規劃 Windows Server“8 (2012)”時，從端點到端點的角度來看，伺服器應用程式的檔案儲存中需要重點關心的二大方面是針對 SMB 應用的 Hyper-V 和 SQL Server。

例如 如果使用 Hyper-V，則 Hyper-V 的單獨設定和叢集設定目前都已經完全支援 SMB 檔案儲存。事實上，現在完全可以使用檔案共用作為 Shared Storage來建置 Hyper-V 叢集。

對於檔案伺服器設定，有三種主要的部署模式：

儘管單台叢集節點檔案伺服器或單台檔案伺服器並不具有高可用性，但它能夠提供最經濟的檔案伺服器解決方案。Hyper-V 提供額外的共用儲存靈活性，使您能夠使用此一解決方案來建立叢集 Hyper-V 節點（儘管整體解決方案無法稱得上高度可用）。但是與 Block Level 儲存設備相比時，這相當於一台單一控制器的 Block Level 儲存陣列。

雙節點檔案伺���器將有希望成為最常用的檔案伺服器建置標準，它能夠以很低的成本提供連續可用性（透過 SMB 透明容錯移轉機制）。透過使用 SCSI (SAS) 硬碟儲存（JBOD 或 SAS 儲存陣列），這一類的解決方案可以擴充到數百顆硬碟。透過與少數 Hyper-V 伺服器和網路交換機配對，此一解決方案可以用於為私有雲解決方案建立機架大小的儲存空間。這相當於一台雙控制器的 Block Level 儲存陣列。

第三種選項中，為採用數量眾多的檔案伺服器以光纖通道作為共用儲存，因此允許進行更大型的設定。此種類的檔案伺服器叢集可以利用 SMB 水平擴充和 SMB DriectAccess等功能來建立共用儲存基礎結構，進而服務數十個甚至數百個 Hyper-V 節點主機。如果使用 10 GbE 或 InfiniBand 將 Hyper-V 節點主機與檔案伺服器互相連接，那麼與光纖通道解決方案相比將能有不遜色的效能表現並且大大節省成本。

結語

對於出現的在檔案伺服器上的儲存伺服器應用程式資料的新機會，我們感到激動萬分。事實上，我們從最早的一批使用者那裡收到了非常積極的意見反應，在這些部署上述應用情境和功能的使用者當中，有來自內部的使用者也有外部使用者。他們分享了我們對於為解決方案所提供的易用性、可管理性、可擴充性和高效能的滿腔熱血。

如果您想要瞭解更多詳細資訊，可以參考我們在 2011 年 9 月 //Build/ 大會期間所發佈的一系列文件。這些展示文件可從 此處 下載，此外我們還錄製了長達幾個小時的影片來提供更多詳細資訊。我們希望您能觀看這些影片。下面是與本部落格文章相關的 Windows Server“8 (2012)”主要課程列表：

• Keynote #2 – 建構連續服務
• 973 – Windows Server 8 (2012)
• 443 – 商業和合作機會：Windows Server 8 (2012) 連續可用性
• 474 – 儲存平台的改進
• 446 – 設計具備連續可用性和可擴充性的系統
• 450 – 設計具備連續可用性和可擴充性的系統 – 多節點區塊儲存
• 444 – 設計具備連續可用性和可擴充性的系統 – 多節點遠端檔案儲存
• 451- 使用 Hyper-V 建構高可用性系統
• 449 – 建構連續可用的檔案系統 NAS 設備

希望您同樣能抱著和我們整理列表時，用一樣愉快的心情觀看這些影片…

本部落格文章由 Windows 檔案伺服器團隊的首席專案經理 Claus Joergensen 和 Jose Barreto 所撰寫。

很多年以前，Microsoft 就與其他公司合作，共同定義了「硬體抽象層 (Hardware Abstraction Layer，HAL)」，這是一系列用於作業系統中抽象化個人電腦（及伺服器）上設備的標準。HAL 是業界的無名英雄，這也表示 x86 生態系統達成了無與倫比的靈活性和互通性。該技術是讓這一切“正常運作”的幕後關鍵技術之一。  
在 Windows Server 2012 中，Windows 將重心轉移到建構雲端作業系統之上，因此需要設計一個新的抽象層也就是「資料中心抽象層（Datacenter Abstraction Layer，DAL）」。Microsoft 將再次與其他公司合作共同定義 DAL。Microsoft並不是從零開始或重新推動的專有標準，而是選擇了針對標準管理以便加速該過程，以使生態系統和使用者能儘快過渡到雲端環境。   
而在讓整個業界接受針對標準管理的這條道路上，我們仍面臨許多挑戰。   
第一個挑戰就是向業界證明針對標準管理非常可靠並且能夠勝任管理作業，為了證明這一點，Microsoft在 Windows Server 2012 中針對標準管理投入的巨大心力。在此版本中，我們將全面針對標準管理作為主要管理途徑，而 DCOM 則僅僅是為了提供舊版相容而存在。   
接下來的挑戰就是幫助業界實作針對標準管理。目前現有的開放源始碼存在許多問題，阻礙了此方案在生態系統中的普及程度。   
因此在今天的部落格文章當中，Windows 管理團隊的專案經理 Otto Helweg 和 Wassim Fayed，將會為我們介紹解決此問題所付出的努力。能夠身處於目前的環境實在是我們的榮幸，我們正在全力將其推向一個新的境界，而我們的使用者也即將收穫此一進步所帶來的巨大回報。還有什麼能夠比這樣的結果更加令人振奮呢？

謹啟！Jeffrey

Microsoft 和 The Open Group 即將在針對標準管理的領域中大展身手，推出名為「開放式管理基礎架構」或 「OMI（原名為 NanoWBEM）」的全新免費開放源始碼技術。我們正在與 Arista 及 Cisco 合作，將 OMI 移植到他們的網路交換機當中，以提供我們的 Windows Azure 和雲端資料中心使用。Jeffrey Snover 曾在 TechEd Europe 上進行過一次技術展示，展示的內容包括如何使用一組針對標準的常用工具管理伺服器上的主機板控制器、Windows 作業系統和運作 OMI 的 Arista 交換機。   
OMI 公開表示您現在可以透過一個開放源始碼的套裝軟體，在任何設備或平台上輕鬆的編譯後實作出針對標準管理的服務。我們的目標是清除阻擋實作針對標準管理的一切絆腳石，以確保世界上的所有設備可以透過一種簡潔、一致、連貫 的方式進行管理，並且訓練和促進由針對標準管理的產品所組成的生態系統。   
如今，資料中心內由不同硬體和平台供應商所提供的大量設備所構成，因此需要使用不同的工具和管理方式。各家公司都在致力於開發自己的抽象層，或者需要指定單一的供應商，但這樣做會限制他們的選擇性和靈活性。要解決這個問題，必須推動整個業界接受一種針對資料中心設備和抽象平台的適當標準。   
此外，雲端運算的日益普及明顯提升企業對於自動化的需求，而這需要建立在一系列管理標準的基礎之上。因此要滿足目前的雲端管理需求，針對標準的管理必須要足夠複雜，以便支援多樣化的設備，同時它必須要方便硬體和平台供應商實作出來。DMTF CIM 和 WSMAN 標準雖然能夠提供足夠的支援卻難以有效實施。但是開放式管理基礎架構 (OMI) 解決了此一問題。

簡便且多樣化的設備支援
我們先從歷史演進開始說起。Windows 長久以來在 CIM 領域中一直獨佔鰲頭，而這一切都是從 WMI（Windows 管理基礎架構）開始。分散式管理任務組 (DMTF) 通用資訊模型 (CIM) 是一種開放式標準，用於定義如何透過一組通用的物件來表示接受管理的元素，並且使用關聯定義它們之間的關係。   
WMI 最初在 Windows NT 4.0 中導入並且與作業系統一同安裝，達成了早期版本的標準和架構。WMI 使用 DCOM 進行遠端系統管理，因為當時尚未制訂任何標準協定。但是在 Windows Server 2012 當中，我們在標準和遠端系統管理方面投入了大量心力，在 WMI 中加入了最新的 DMTF 標準和協定。   
CIM 標準具備足夠的複雜度和靈活性，可以用於所有設備的管理模式，尤其是資料中心設備。儘管這些 DMTF 標準已經存在多年，但是仍舊難以實施，並且對於現有移動式和嵌入式設備來說過於龐大。因此為了解決這些難題，Microsoft 建構了一種名為 OMI 的 CIM 物件封裝程式，OMI 具備 高度可攜式、佔用資源少、效能高 的優點，並且專門設計用於實作 DMTF 標準。並且之後，我們與 The Open Group 展開合作，以便透過 Apache 2 授權模式向所有使用者提供 OMI 的原始程式碼。OMI 的原始程式碼可以在 Linux 和 UNIX 系統中輕鬆實作。   
採用 OMI 的合作夥伴將獲得以下優勢：

· 支援 DMTF 標準： OMI 根據 DMTF 標準實作其 CIMOM 伺服器。

· 支援小型系統： OMI 在設計時也考慮到在小型系統中如何實作（包括嵌入式和移動系統）。

· 易於實作： 明顯簡化在 設備/平台中實作 Web Service 管理和 CIM 的過程。

· 支援遠端系統管理：可以透過 Windows 和非 Windows 用戶端及伺服器，以及其他支援 Web Service管理的平台即時進行遠端系統管理。

· API 相容 WMI： 可以在 Linux 和 Windows 上使用相同的 API 撰寫程式和管理應用程式。

· 支援 CIM IDE：用於建立和開發 CIM 提供程式的工具，例如 Visual Studio 的 CIM IDE。

· 可支援 PowerShell： OMI 供應商使用一系列的機制，使 Windows PowerShell 能夠自動發現，並且自動產生 Cmdlet（Windows Server 2012 中的 2,300 個 Cmdlet 就是如此實作的）。

OMI 詳細資訊
OMI 資源使用率低（基本大小 250 KB，外加 1 MB 的工作任務記憶體使用），以及高品質的程式碼將有助於開發人員更輕鬆的開發具備高效能和高穩定性針對標準的管理堆疊。對於 IT 專業人員來說，OMI 將增加您能夠管理的設備數量和類型，並且透過針對標準化管理和自動化工具（例如 Windows PowerShell 和 System Center，以及其他管理解決方案）統一管理操作體驗，進而大幅度提升您的工作效率和效益。下圖為 OMI 在 CIM 伺服器實作中所包含的元件和工具。

可擴充性
OMI 採用 Provider 程式模型，允許開發人員將 OMI 擴充到整體的設備或平台當中。在過去，撰寫Provider非常困難，通常成本較高而且不太穩定。OMI 利用大幅簡化的Provider程式模型，該模型也在 Windows Server 2012 和 Windows 8 的 WMI 中使用。簡言之，OMI 透過向開發人員提供以下功能簡化實作程序：

· 下一代Provider程式介面

· 相容 Windows Server 2012 和 Windows 8 中的新式 WMI 提供程式介面

· 建立 Provider 程式框架 (omigen)

· 建立整體 CIM 資料架構和程式碼

· 提供Provider註冊工具 (omireg)

該模型首先需要定義接受管理的內容。根據定義所接受的管理內容，omigen 工具會建立一系列用於實作管理模型的 C 語言資料架構和程式碼。開發人員可以將這些程式碼增加到框架當中並且註冊該Provider程式。

OMI 適用於嵌入式和移動系統
嵌入式和移動設備管理可能是對於管理技術來說要求最高的任務之一，因為它們的 CPU 處理器和記憶體限制最為明顯。我們認為如果能夠建構一種滿足這樣需求的管理技術，那麼 OMI 應該就能夠滿足任何設備的管理需求。因此，為了確保 OMI 較低的資源使用率和嵌入式系統適用性，我們實作出以下設計特徵：

· 小於 250 KB 的伺服器物件大小

· 伺服器完全使用 C 語言

· Provider程式介面使用 C 語言

· 無儲存程式庫伺服器

· 整體的Provider程式產生較少的程式碼

· 反覆運算式大小優化

· 無硬碟操作

安全性
安全性問題。自從 Bill Gates 著名的可信賴運作備忘錄以來，我們一直在盡力完成安全開發生命週期模型。安全性在我們開發和編碼過程的所有方面都是首要考慮因素。OMI 雖然體積小巧，卻實作出以下安全功能：

· HTTPS (SSL)

· HTTP 基本驗證

· 本地端身份驗證

· 支援 PAM (Pluggable Authentication Module) 驗證機制

· 執行 Provider 程式

o 以 requestor 運作程式

o 以 Server 運作程��

o 以 designated user 運作程式

太棒了！ 我該如何獲得 OMI？
Microsoft 已經與 The Open Group 結為合作夥伴，共同打造針對利用、支援和強化 OMI 的硬體、軟體和開發人員社群。您可以從 The Open Group 網站下載 OMI 或瞭解更多資訊。在不遠的將來，您將會見證到該網站及社群的成長，並且支援更加詳細的文件、設備和針對 OMI 開發人員的會議。

若有相關問題請與 ottoh@microsoft.com 連絡

Microsoft Windows 對於針對標準管理的支援由來已久。我們是 分散式管理工作組 (DMTF) 的創始成員之一，並且是第一個推出功能最豐富的 公用資訊模型 (CIM) 物件封裝程式 (CIMOM)，也就是大家都熟悉的 Windows Management Instrumentation (WMI)。雖然 WMI 一直很好的服務客戶們和合作夥伴，但是仍然未達成針對標準管理的高水準。總合來說，目前的管理作業仍然需要運作於供應商的特定工具環境 – 使用Windows 管理 Windows，使用Linux 管理 Linux，而網路和儲存供應商管理他們自己的內容。對於客戶們來說仍然存在管理上的孤島。某些產品雖然可以銜接這些運作環境，但是他們卻常常需要依賴特定的供應商，因此也使得管理作業再次陷入泥淖。對管理人員來說，缺少標準管理是最煩人的缺點。

我們在與合作夥伴和使用者交流活動中花費大量時間，來瞭解他們對於使用 Windows Server “8 (2012)”的需求。雲端作業系統是我們特別注意的應用情境，而且很明顯的是，對於這方面我們需要在針對標準的管理方面進行大量的投資。將雲端作業系統的重心轉變明顯增加需要解決的管理問題。不僅僅只是將重點從管理一台伺服器轉變為管理許多台伺服器，而且為了能夠融合成為綜合性的運算平台，也需要能夠管理各種異質設備。如今透過選擇非常少的一組元件和限定的元件，並且安排大量開發人員撰寫特定元件的管理工具，雲端運算正在發揮應有的作用。通用的雲端運算需要針對標準管理。這正是我們對於 Windows Server “8 (2012)”在針對標準管理方面進行大量投資的原因。

管理問題的核心在於需要一組分散的人員（他們常常具有相互衝突的問題）一同進行決策。我們針對此問題的處理策略非常簡單： 建立一個能夠輕鬆、合理的從事正確事情的價值觀。研發組織注意開發某項產品時所花費的成本，以及為他們所帶來的效益。如果評估後相關比率適當，我們便會展開相關工作否則便會放棄。因此，我們的工作是盡可能減少實作針對標準管理的成本和開銷，同時盡可能達成最大化效益。本篇部落格文章內容將介紹我們是如何達成此一目標。在本文中將不會討論其它針對標準的管理計畫： Windows Server “8 (2012)”探索和管理外部儲存陣列的儲存管理計畫規範 (SMI–S)。我們將會在之後的部落格文章當中在針對此議題進行討論。

本部落格文章中所包含的內容適合 IT 管理人員和開發人員。如果您是開發人員，本文中所提供的程式碼和架構框架可以使您的工作變得輕鬆簡單，如果您是一名 IT 管理人員您也將會發現，本文在 IT 基礎架構的部署以及如何決定出合理決策部份具有相當的價值。

本部落格文章由 Windows Server 團隊首席架構師 Wojtek Kozaczynski 所撰寫。

–Cheers！ Jeffrey

背景知識

WMI 首先在 Windows 2000 中推出（而且可以向下相容於 NT4）。它採用針對 COM 的開發模型，而且撰寫類別程式並不簡單，也就是說撰寫上非常困難，要正確撰寫更是難上加難。除了模型程式設計非常困難之外，團隊成員還必須瞭解針對標準管理的運作環境以及 CIM 架構、代管物件格式 (MOF) 語言和其它新術語、機制和工具。我們在最初的一些版本當中有進行相當全面的介紹，但是許多團隊對於其所付出與效益比並不滿意。

主要部分是效益方面。從頭開始管理生態系統是令人感到非常困難的。如果撰寫程式後無人使用，那麼會產生什麼價值？ 什麼價值也沒有!! 這正是系統管理伺服器 (SMS)，也就是所謂的 SCCM(System Center Configuration Manager)，在我們發佈的同時增加了對 WMI 支援的原因（WMI 實際上源自於 SMS 團隊）。這是一種非常不錯的做法，但是卻存在二個問題：

· 它對於撰寫在很大程度上是以庫存和監控管理的資源為重點的 WMI，程式的產生與刺激（與指令和控制項相比之外）。

· 同時 SMS 的部署並不廣泛，因此撰寫 WMI 程式的團隊並不瞭解投資對客戶們的影響。

自 WMI 發佈以來，使用 WMI 程式管理產品和工具的數量一直穩定增加，但是，長期來看這與覆蓋率的增加並不匹配。之後，隨著 Hyper–V 的發佈更開始發生變化。DMTF 定義的原始管理架構著重於已經存在的情況，這與著重管理應用情境正好相反。對於這二種策略，都各有其道理，但是在談到管理虛擬化環境時，DMTF 需要團隊的參與當架構面世時能迅速採用。Hyper–V 團隊開發出實作架構程式，而 SCVMM 團隊則開發出這些程式的管理工具。這種協同合作發揮的效用確實不錯，而且使得一些問題出現轉機，原因在於它證明 WMI 不僅僅適合於庫存和監控。WMI 可以有效的支援 組態設定、指令、控制項。雖然許多團隊已經在這之前完成類別似的工作，但是沒有一支團隊意識到 Hyper–V 和 SCVMM 具有的可見性或影響力。

針對標準管理的另一個重大變化是標準管理協定的定義和可用性。WMI 是代管許多標準類別程式的標準 CIMOM，但是同時並不存在一種可以互相操作的管理協定，因此 WMI 使用了 DCOM。但是這卻使其成為 Windows 管理 Windows 的管理孤島。它雖然發揮了效用，但是並沒有達成針對標準管理的願景。這種情況隨著 DMTF 定義和核准 WS 管理 (WS–MAN) 協定 而發生了變化。這種針對 SOAP 的防火牆協定允許任何作業系統上的用戶端，對於在任何平台上運作的 CIMOM 運算。Microsoft 在 Windows Server 2003/R2 中首次實作部分的 WS–MAN，並將其命名為 Windows 遠端系統管理 (WinRM)。它可以與其它平台上可用的許多 CIMOM/WS–MAN 堆疊後相互運作，這些平台包括 Openwsman（Perl、Python、Java、Ruby Bindings）、Wiseman（一種 Java 實作平台）、OpenPegasus。

一旦針對標準的管理用戶端和 CIMOM 可以互相操作，便已經邁出了第一步。但是，隨著供應商使用這些協定開發真正無代理程式的管理解決方案，還開始強調不斷增加的異質環境中的磨合。實作規範方法方面的差異，表示工具需要撰寫特殊情況程式碼。困難的 API 也使撰寫要求嚴格的應用程式變得非常困難。覆蓋率方面的差距表示供應商仍然必須安裝代理程式，而供應商和客戶們卻非常討厭在主機上安裝額外的代理程式。供應商討厭的原因在於他們需要大量的工作來撰寫作業系統版本，並且使它們保持最新狀態。客戶討厭的原因則在於它們使組態設定過程複雜化，而且產生另一個問題是消耗寶貴的資源並產生錯誤。

為何改變？

早在 Windows Server “8 (2012)”規劃過程中，我們便已經意識到，不在針對標準的管理方面進行大量投資，便無法達成雲端作業系統。雲端環境中需要管理的內容太多，每一項資源的管理方式截然不同。考慮到上面所描述的情形，我們得出一個結論是：

· 減少撰寫 WMI 程式和針對標準管理工具所需的工作。

· 大幅度提高可管理性的覆蓋率，特別是在 組態設定、指令和控制項等部份。

· 更新程式碼以符合最新的 DMTF 標準。

· 整合 WMI 和 Windows PowerShell。

· 提供在 Windows 或任何其它平台上使用針對標準管理的每個人具有吸引力的價值。

我們已完成的工作

現在，讓我們從二個角度瞭解一下目前已經完成的工作： IT 管理人員角度和 Windows/設備開發人員角度。

我們針對 IT 管理人員的目標是讓他們使用 Windows PowerShell 管理所有內容，因此，我們需要為他們提供容易使用的 Cmdlet，以籍由標準介面在遠端機器或異質設備上進行遠端管理系統資源。反過來說，這將會使 IT 管理人員能夠參照這些資源後撰寫腳本，並撰寫連結數十台或數萬台伺服器及設備的工作流程，並且不必針對每種資源類別型進行瞭解、配置和單獨操作的技術和工具集。

我們針對 Windows/設備開發人員的目標是讓定義和實作針對標準管理介面變得簡單、輕鬆，然後透過用戶端 API、Cmdlet 和 REST 端點顯示這些介面。對於撰寫管理工具的開發人員來說，我們希望使管理解決方案的所有元件變得簡單、輕鬆，其中包括向下相容的 DCOM Windows 伺服器、針對標準的管理作業系統、伺服器和設備。對於 Web 開發人員來說，我們希望透過 REST API 使管理 Windows 變得更加簡單且輕鬆。

現在，讓我們從開發人員的角度，開始瞭解我們已經完成的工作。下圖中顯示的便是我們稱之為 CIM 堆疊的元件。

· 在程式開發領域當中，我們為 WMI 導入新的管理基礎結構 (MI) API，明顯簡化程式（圖片中的 MI 程式）的開發作業。新的工具根據 CIM 規範產生框架程式。新的 API 支援 IT 管理人員所期望的豐富 Cmdlet 參數：–WhatIf、–Confirm、–Verbose 以及進度欄位和其它 Cmdlet 行為。當舊的 CIM 用戶端使用支援豐富參數的新程式時，這些 API 不會發生作用。但是，新的用戶端和 Windows PowerShell 可以使用這些參數，以透過新的API提供豐富的操作體驗。

· 我們使 WS–MAN 成為管理 Windows Server 的主要協定，並且相容COM 和 DCOM 。我們已經完成了整套 WS–MAN 協定操作，並且針對效率和規模進行優化。我們還增加處理連接中斷的支援程式，使管理功能更為強大。進而簡化發生中斷的情況下管理大量機器的運作。

· 對於用戶端開發人員而言，我們建立新的 MI 用戶端 API 和堆疊，它們可以透過 COM（本地端）以及 DCOM 和 WS–Man（遠端）與 WMI 進行通訊。它還可以透過 WS–MAN 與任何相容 CIM 的伺服器進行通訊。用戶端 API（C/C++ 和 .Net）與程式 MI API 一致（它們共用主要的 Header 檔案）。

上述介紹了建構在任何 CIMOM 中實作的 CIM Windows PowerShell 存取的基礎，下圖當中則對此進行說明。

· 我們建立稱為 CIM Cmdlet 的 Windows PowerShell 模組，其任務是直接回應通用的 CIM 操作。該模組建立於用戶端 .Net API 基礎之上，而且可以管理任何針對標準的管理資源。

· 我們將 Windows PowerShell 修改為能夠在運作時產生特定資源的 CIM Cmdlet。這些 Cmdlet 根據 Windows PowerShell–to–CIM Mapping 宣告性 XML 規範 (CDXML) ，可以本地端或遠端使用 CIM 程式。這使開發人員能夠撰寫 CIM 程式、撰寫 CDXML Mapping 檔案，並且產生 Cmdlet 可用於每個運作 Windows PowerShell 3.0 的 Windows 設備。這同樣對於非 Windows 的程式發生作用。請您想像一下這為設備供應商所帶來的價值。如果設備供應商實作出符合標準的程式，並且包括此 CDXML Mapping 檔案，則數億台 Windows 主機將能夠對設備進行管理，而且供應商不必撰寫、調整、分配或支援其它程式碼。當新版本的 Windows 問世時，也無需撰寫任何程式碼便能支援供應商的設備。這為設備供應商支援針對標準管理帶來了非常大的激勵效果。

在上圖當中，您可能注意到一個標有“NanoWBEM”的方框。現在，讓我們來談一下這部份的內容。隨著我們與合作夥伴和社群一起參與針對標準管理的計畫，我們得到各式各樣的意見反應。有些人覺得這是可以去做的正確事情，並且瞭解可能創造的機會，但是對於是否能真正發生作用感到懷疑。當我們對此部份展開深入研究時，我們發現合作夥伴並沒有感到他們可以成功使用現有的開放源始碼 CIMOM。同時，隨著將功能擴充到管理 Linux 伺服器時，我們自己的系統中心團隊也遇到了類別似的問題。為了解決這些問題，系統中心團隊啟動了建構可移植、佔用空間小、效能高 的 CIMOM 的專案，結果就是建構出 NanoWBEM 專案。NanoWBEM 採用可移植的 C 語言所撰寫，可以在 Linux、UNIX 和 Windows 上運作。由於它佔用空間非常小，因此適合在網路設備、儲存控制器和電話等小型設備上運作。NanoWBEM 使用與 WMI 相同的 MI 程式，因此，開發人員可以用於建立 Windows 程式的相同工具來開發適合運作於其它平台的程式。  
現在，為了解決您最初的擔憂，我們的合作夥伴和社群正在計畫使 NanoWBEM 可以用於開放源始碼社群。   
透過上面所描述的內容中您可以發現：

· 我們為 IT 管理人員提供強大的工具，以便存取透過 CIM 類別程式達成的針對標準管理的 API。如果 MI 程式沒有實作這些類別，則它們可以支援擴充的 Windows PowerShell 參數，例如 –WhatIf、–Confirm、–Verbose。

· 我們還為代管軟體和設備開發人員提供比以前更低的成本以建立新的 MI 程式工具，而且 IT 人員可以透過 Windows PowerShell 模組以進行管理。

最後，對於希望從非 Windows 平台管理 Windows 的 Web 開發人員而言，我們開發出 Management OData IIS Extension。它包含簡化建構 REST API（OData 服務端點）的工具和元件。

OData 是一組用於建構 REST API 的 URL工具、元件、程式庫。使 OData 服務脫穎而出的是它們針對明確的區域模型，這些模型定義出它們的資料內容和行為。因此能夠自動產生豐富的用戶端程式庫（例如 Windows/IoS/Android 電話、瀏覽器、Python、Java …等），簡化出可用於各種設備和平台的解決方案。

許多產品具有完整的 Windows PowerShell API，而且現在需要在雲端環境中代管它們的 REST API。這正是我們首次使用顯示 Windows PowerShell Cmdlet 的 OData 原因。

但是，我們針對未來的版本設計出一般用途的解決方案。Rest API（特別是 OData）與 CIM 資料模型非常適當的 Mapping，因此我們要做的是提供 Cmdlet Mapping 到 CIM 資料的一種機制，然後將資料模型顯示為一個 OData 服務端點。

概要介紹 CIM 堆疊

在前面小節當中，我們從高層面概括出我們已經完成的工作。這無可避免的為大家留下疑問： 它在實際環境中如何發揮作用？ 在團隊的部落格當中，我們將會深入介紹 Windows Sever “8 (2012)”管理平台的所有功能和元件。同時，對於我們當中的新手，我將會從 IT人員的操作體驗開始“概要介紹”各項功能。

CIM Cmdlet

IT 管理人員有二種機制可以管理 CIM 類別。第一種選擇是使用來自 CimCmdlets 模組的通用 CIM Cmdlet，該模組預設情況下會導入到 PowerShell_ISE 和 PowerShell。熟悉 CIM 的 IT 管理人員對於該模組的 Cmdlet 應該非常熟悉，因為它們可以直接 Mapping 到通用 CIM/WS–Man 操作。 例如，三個不同的 Get–CimInstance Cmdlet 參數直接 Mapping 到 CIM/WS–MAN 通用操作。GetInstance、EnumerateInstances 和 QueryInstances。該模組還包括用於建立遠端伺服器連接（Session）和檢查透過 CIMOM 註冊的類別定義 Cmdlet。

新的 CIM Cmdlet 取代只在 Windows 到 Windows 環境中作用的 *–Wmi* Cmdlet。經過優化的 Cmdlet 可以透過 WS–MAN 發揮作用，並且繼續透過 DCOM 無縫式的運作，因此 IT 管理人員，便不再需要二組指令便可管理 Windows 和非 Windows 機器。

下列範例說明獲取本地端電腦上的 WMI root\cimv2 命名空間中註冊 Win32_Service 類別的屬性名稱和類型。

從遠端伺服器獲取 Win32 服務名稱一樣簡單。

從 CDXML 產生針對 CIM 的 Cmdlet

IT 管理人員也可以利用 Windows PowerShell 使用 CDXML Mapping 檔案所產生的 Cmdlet。此模型允許開發人員撰寫一段程式碼，並獲取 Windows PowerShell 和 WMI 二種生態系統的好處。它還允許對某些作業系統功能團隊以本機程式碼撰寫 Cmdlet。儘管針對 CIM 的 Cmdlet 撰寫為 WMI 程式的形式，但外觀和感覺與 Windows PowerShell Cmdlet 幾乎一樣：

· 它們提供以任務為導向，隱藏命名空間、類別名稱、方法名稱等實作資訊。

· 它們支援完整的 Windows PowerShell 參數：–WhatIf、–Confirm …等

· 它們支援豐富的操作控制項目：–AsJob、–Throttlelimit …等

· 它們封裝 Windows PowerShell 模組，以 獲取/導入 模組探索Cmdlet。

用於產生針對 CIM 的 Cmdlet 的 CDXML 檔案將 Cmdlet參數 Mapping 到 Cmdlet Adapter 。Cmdlet Adapter 是將 Windows PowerShell Cmdlet 的要求 Mapping 到指定技術的 .NET 類別。我們針對 CIM 類別推出 Cmdlet Adapter，但是任何人都可以撰寫自己的 Cmdlet Adapter （例如將 Cmdlet 與 Java 類別互相 Mapping ）。 Mapping 文件的檔案副檔案名為 .CDXML（Cmdlet 定義 XML）。許多相關的 CDXML 檔案可以和描述返回的物件和如何格式化物件的檔案一起，合併至 Windows PowerShell 模組。  
這種機制的優點在於 Windows PowerShell 可以從遠端 CIMOM 導入 .CDXML 模組，然後建立管理該伺服器上的 Cmdlet 類別，而且無需具備有關它們的任何知識。換句話說 CIMOM 可以在運作時對其類別顯示伺服器特定的 Windows PowerShell 介面，並且無需安裝任何軟體！

建立 CDXML 檔案需要與指定其它 Cmdlet 相關的詳細資訊，以及有關 CIM 類別函數 Mapping 的資訊。為了簡化這項任務，我們開發出 CDXML 編輯工具，我們將在單獨的部落格文章當中進行詳細介紹。在不深入瞭解詳細資訊的情況下，現在讓我們透過一個簡單的範例，來舉例說明針對 CIM Cmdlet 背後的設計理念。上述中介紹了如何使用 CIM Cmdlet 存取 Win32_Service 類別及範例。下列的 .CDXML 檔案則定義 Get–Win32Service 產生針對 CIM 的 Cmdlet，將針對相同類別的方法。您在檔案中無法找到 Get–Win32Service Cmdlet 名稱，因為它是從預設的 Win32Service 和 Get 所預設產生出來的。檔案中 <QueryableProperties> 元素定義 Windows PowerShell 用於查詢 Win32_Service 類別範例的屬性。在我們的範例當中，我們希望查詢的屬性是服務“名稱”。

下列 Windows PowerShell 指令將 .CDXML 檔案導入為模組，列出模組當中所定義的新 Cmdlet。請注意，由於在 .CDXML 檔案中我們宣告參數“名稱”是強制的 (<CmdletParameterMetadata IsMandatory="true" CmdletParameterSets="ByName" />)，“名稱”在 Get–Win32Service Cmdlet 中顯示為唯一的強制參數。

請注意!! 如果您對我們如何完成此任務感到好奇，可以參考我們使用下列指令動態產生的 Cmdlet。

我們新建立的 Cmdlet (Get–Win32Service) 其功用與其它 Cmdlet 類似，而且正如上述中所提到的那樣，可以作為背景工作執行。 在針對大量伺服器執行指令時，限制參數 (–ThrottleLimit) 非常有效。您可以針對眾多伺服器執行指令，並且限制允許多少同時運作的未處理請求數量。

我們推出具有 130 個 Cmdlet 的 Windows PowerShell v1.0，和具有 230 個 Cmdlet 的 Windows PowerShell v2.0。對於 With Windows PowerShell v3.0，Windows Server “8 (2012)”內建超過 2,300 個 Cmdlet。大部分的 Cmdlet 使用 WMI MI 程式和 .CDXML 檔案所撰寫。這表示這些函數可以透過 Windows PowerShell 並針對標準管理進行使用。最近，我們還透過 WS–MAN 從 Linux 用戶端機器中安裝了一個 Windows 伺服器角色的能力，令使用者大為震驚！

CIM 用戶端 .Net API

Windows PowerShell 中的 CIM Cmdlet 和針對 CIM 的 Cmdlet 都可以在新的 MI .Net 用戶端 API 的基礎上實作。儘管 IT 管理人員不可能撰寫 C# 用戶端程式碼，管理工具開發人員毫無疑問會進行撰寫，那麼讓我們瞭解一個簡單的範例。

用戶端 API 支援與伺服器的同步和非同步。同步操作返回 CIM 類別範例的 IEnumerable<CimInstance> 集合。非同步作業則使用來自 The Reactive Extensions (Rx) 非同步、可觀測的集合概念，產生有效簡單且緊湊的用戶端程式碼。下列為一個簡單的範例程式，該範例程式在遠端電腦上採用 Win32_Service 類別的範例。我們的目的不是討論用戶端 API，而是說明產生的程式如何緊湊且簡潔。

處理的程式碼位於主要函數的三個突出顯示行當中。這些程式碼將 Win32_Service 範例的結果轉化為可觀測的 CimInstance 物件集合，並將物件與該集合互相關聯。範例中包含三個處理返回、最後結果、錯誤檔案。這使得在僅僅幾個程式碼當中針對遠端 CIM 伺服器執行豐富的管理功能變得簡單又輕鬆。

新的 WMI 程式

之前說過，我們大幅簡化 MI 程式的開發。許多事情有助於達成這種簡化作業。

下圖當中說明撰寫程式的步驟。程式可以實作一個或多個 CIM 類別，而第一步便是以 MOF 規範語言描述這些 CIM 類別。下一步則是產生實作 CIM 類別的程式框架。我們提供 Convert–MofToProvider.exe 實用程式來達成此步驟的自動化。此實用程式將類別定義作為輸入，並建立許多 C 標題和程式碼檔案。其中的二個檔案值得注意。

· 第一個檔案稱為架構檔案，它包含所有資料結構的定義，其中包含程式使用的 CIM 類別範例。它使程式強類型化，而且容易與 Visual Studio 的智慧型感知和自動完成功能協同運作。此檔案不得手動編輯。

· 另一個檔案是程式碼檔案，它包含程式的框架。這是唯一需要編輯的檔案。它包含所有 CIM 類別方法的程式碼，以及返回未實作結果的主體。因此，產生的程式可以建構，可以註冊並且運作，但是不執行任何操作。

接下來是用相對應的邏輯填充 CIM 類別方法。完成此一步驟之後，便可以註冊和測試程式。我們還透過建構僅僅採用一個輸入的新式註冊工具大大簡化程式的註冊作業，此工具便是程式 DLL。我們可以做到這一點的原因在於 MI 程式將它們的類別定義編譯到架構檔案當中。

為了使新的程式能夠與 Windows PowerShell 完美協同運作，我們增加了擴充的 Windows PowerShell 參數 API。該功能是程式可以在執行運算時從用戶端得到輸入值，條件是採用運算的 Cmdlet 包含 –Confirm 或 –WhatIf 參數。下列程式碼片段來自 停止和開始 Win32 服務的測試程式，並且說明功能如何發揮作用。該程式碼是停止服務並且詢問使用者（MI_PrompUser 函數）是否想停止服務運算的一部分，並且以“名稱”參數的形式指定給運算的名稱。如果答案為“否”(bContinue == FALSE) 或者函數失敗，這表示程式無法到達使用者端，程式不會停止執行程序，但是會撰寫回應給使用者的訊息（MI_WriteVerbose 函數）並且停止運算。

管理 OData

我想簡要介紹的最後一項功能是用於建構針對 OData 的 REST 管理端點其 IIS 副檔案名稱。該功能背後的設計理念是我們可以宣告性的配置，如何向 Windows PowerShell 模組中的 Cmdlet 分派端點服務請求。現在，我使用一個非常簡單可用於建立和終止 Windows 程序的範例，並解釋其工作原理端點目錄中包括如下圖所示的三個檔案：

架構檔案中包含端點實體的定義，而且在載入端點時載入架構檔案。模組檔案用於定義處理端點請求所採用的 Windows PowerShell Cmdlet。分派的檔案透過定義為不同的用戶端請求採用哪些 Cmdlet 來將另外二個專案進行關聯。在我們的範例當中，它將會查詢 Win32 程序 Mapping 到 Get–Win32_Process Cmdlet，然後以通用 CIM Cmdlet 與 WMI 進行通訊。下面的螢幕擷圖當中顯示此端點配置的結果，該結果是針對 URL 回應

http://wojtek8srv3:8000/Management/Process.svc/Win32Process?$filter=Name eq ‘svchost.exe’&$select=ProcessId

結語

Jeffrey 常常會說“沒有人會注意您的幾百萬行程式碼”。“百萬行”是任意選擇的非常大的數字，其實是暗示每一項軟體產品必須累積大量的基礎元件之後，才能帶來其意義與價值。但是，一旦達到一定程度的程式碼數量時，即使僅僅增加一些程式碼都會產生明顯的差異。

在 Windows Server “8 (2012)”當中，我們已經撰寫了“百萬行”針對標準管理平台的程式碼。我們彌補了管理逐漸複雜的雲端基礎結構 IT 管理人員，與建構必須代管 Windows 和設備開發人員之間的鴻溝。我們奠定了一個一致性的運作基礎，這一個基礎從 CIM 介面跨越至另一端以 IT 管理人員為導向的 Windows PowerShell 和 OData 介面。 我們為實作針對標準管理的異質設備創造出明確又極有吸引力的價值，同時我們達成綜合的覆蓋率，使管理工具程式可以使用標準管理來對 Windows 進行管理。