Windows Server “8 (2012)”中針對標準的管理

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 回應

https://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 進行管理。