作業系統平台提供的經驗、功能和 API 可以供開發人員借鏡及使用。現在，許多開發人員會採用 Windows 已發佈版本，提供雲端運算解決方案。Windows Server 2012 是雲端優化的作業系統，表示開發人員可以付出較少的人力，傳遞更好的雲端運算解決方案。System Center 2012 已經使用 Windows Sever 2008/R2 傳遞更佳的雲端運算解決方案。在本篇部落格文章當中，我們管理部門的技術工程師 Anders Vinberg 將會介紹 System Center 2012 SP1 當中的 Virtual Machine Manager 元件（目前為提供社群技術預覽） 如何借助 Windows Server 2012 的雲端優化功能，將該解決方案提升到一個新的水準。
–Cheers！Jeffrey

Windows Server 2012 的官方名稱之前為 Windows Server “8”，幾個月前在 MMS 發佈了 System Center 2012，Microsoft 現在已經為我們的顧客提供解決方案（用於建構顧客自己的私有雲），向主機代管服務供應商提供解決方案（用於建構其自己的基礎設施，也就是服務公有雲產品和服務）。按照 Brad Anderson 在 MMS 的 主題演講 當中所闡述的重新定義移動到雲端模型以及雲端的核心原則，並且查看如何利用 Windows Server 2012 和 System Center 2012 SP1 達成此一目標。   
雲端模型
首先，雲端運算不一定就表示工作負載是在顧客之外運作，這一點很重要。工作負載可以部署在顧客的基礎設施上，或者部署在合作夥伴上，但是完全由顧客控制和管理，這是“私有雲”。工作負載還可以部署並運作在主機服務供應商的基礎設施上，由其他承租用戶共同使用，這是“公有雲”。在這二種情況下，雲端運算均是消耗資源的一種方式，並且具有 資源池、自助式服務、彈性、針對使用資源情況計費 的屬性特徵。

雲端角色
由於雲端模型將基礎設施和支援的服務解耦合，它還解耦合了二個不同的程序：供應、消耗。並且有二種相對應的角色：

· 服務供應商（資料中心管理人員）

· 服務使用者（應用程式擁有者）

這二種角色在各自的領域當中有截然不同的特性：

供應商和使用者的分離提供了極大的簡便性和靈活性。這是計算民主化趨勢的重要基礎。我們經常聽到這樣一種說法，就是使用者無需瞭解實體基礎設施的詳細情況，但是我們現在做出更有力的聲明： 不允許使用者瞭解實體基礎設施，因為這樣會限制到供應商的日常運作。供應商可能需要使用一個更有效率的新設備來代替舊的設備，但是不應該讓使用者牽涉其當中甚至不必通知他們（前提是需要達成抽象層級和服務層級協定）。這個解耦合模型不適合所有現有 IT 程序或所有現有應用程式；後續發佈的部落格還會討論 Windows Server 和 System Center 如何能容納這混合的工作模式。

達成的雲端特性
我們來分別看看這四種雲端特性，並瞭解 Windows Server 2012 和 System Center 2012 向顧客提供哪些內容。

· 資源池： 這表示我們會在整合層級而不是各個伺服器層級來處理資源。雲端會公開資源池以供應需要容量空間的服務使用，此抽象方法會將虛擬化工作負載從實體基礎設施當中解耦，允許動態工作負載分配和獨立的基礎設施管理。   
儘管現代的大型雲端通常會使用相同的硬體，並且軟體版本相同，這種情況在企業運算環境當中通常不切實際，因為這種環境當中現有軟體可能已經具有特定的硬體要求；我們的雲端模型支援異質資源池，在這裡系統會自動將軟體要求與硬體特性互相匹配。   
具有資源池表示多個承租用戶（顧客）將在此環境當中具有他們自己的工作負載，基礎設施必須在資源池之間提供必要的隔離。這種多租賃用戶環境不僅僅適用於公有雲：即使在私有雲環境當中，自助式服務模型會為使用者提供在少量監控的情況下部署服務的靈活性，這就需要在資源池之間進行強而有力的隔離動作，以防止對鄰居產生意外的影響。

o 利用 Windows Server 2012 可以透過相關功能（例如 Hyper-V 可擴充式交換機、網路虛擬化、服務品質 (QoS) 和網路隔離原則）達成對資源的共用。另外，有了即時遷移和儲存遷移的增強功能，Windows Server 平台使資源可以輕鬆的在資料中心內移動，以優化資料中心資源的使用。

o System Center 2012 透過 Virtual Machine Manager 元件可以整合運算、網路和儲存資源，並將他們公開為一個“雲端”的結構。它支援大規模的管理這些雲端，並動態的在雲端當中佈署工作負載，對於多承租用戶隔離以及向使用者委派雲端，可以使用針對角色的存取控制機制。在 SP1 當中，Virtual Machine Manager 使用網路虛擬化的平台功能以及即時遷移和儲存遷移，達成靈活的資源池管理以及環境當中的負載平衡，這樣將會符合顧客的 SLA。

· 自助式服務： 在雲端模型當中，服務使用者可以利用自助式服務經驗（通常是針對 Web 的用戶）來存取已經分配給他們的空間容量，自助式組態設定工作負載（從支援單一 VM 虛擬主機，到部署複雜的服務）管理這些工作負載的生命週期。

o Windows Server 2012 在達成資料中心完全自動化方面走了很長的一段路。自助式服務表示所有資料中心操作行為必須完全可自動化，如果未能達成，則每次在雲端當中佈建工作負載時都需要人工手動操作。Windows Server 2012 透過 PowerShell 和 WMI 達成完全自動化，達成此應用情境的介面。

o System Center 2012 針對 Windows Server 2012 的自動化功能，並提供用戶和管理功能以達成自助式服務。Service Manager 元件提供服務目錄，將自助式服務用戶推向 IT 審查工作流程，例如分配空間容量。App Controller 元件提供管理虛擬機器和服務的自助式服務體驗，同時涵蓋私有雲和 Windows Azure 公有雲。Operations Manager 元件為環境提供運作智慧，Orchestrator 元件提供 Run-book 自動化。最後，System Center 的 Data Protection Manager 元件施行業務連續性原則。

· 彈性： 雲端彈性表示基礎設施可以支援組織的變更需求，按需要部署新服務，為負載較重的服務分配更多資源，或者取消分配資源，以便在負載較輕時節省資源。借助跨雲端管理，工作負載還可以在私有雲和公有雲之間移動，提供額外的空間容量、大規模存取或其他需要的特性。

o 從 Windows Server 平台角度出發，允許運作在不同基礎設施上的多個服務透過 IPSec VPN 互相連接以達成彈性。Windows Server 2012 內建對 IKEv2 VPN 新的支援，允許它輕鬆的將私有雲和公有雲互相連接。  
另外，彈性還表示，將任何工作負載跨越雲端移動到公有雲供應商還是可能的。在目前技術條件下，非常難於達成，這是因為工作負載往往嵌入有大量的網路組態假設，例如固定的 IP 位址和子網路。借助 Windows Server 2012 網路虛擬化，現在，在保持自己的 IP 位址並將其從供應商的 IP 空間當中分離的情況下，移動工作負載是可能的。

o System Center 2012 SP1 在其網路結構當中使用平台功能進行網路虛擬化。當定義工作負載“網路”時，System Center 允許雲端使用者在它們可用的任意雲端或任意實體網路基礎設施上部署此類網路。  
VM 虛擬主機不僅允許向雲端內的服務彈性分配和發佈資源，而且還允許對雲端本身增加或刪除容量，在服務使用者看起來就好像有無限的雲端容量。

· 針對使用情況： 在雲端模型當中，顧客支付或至少被告知的雲端資源使用量，針對其實際的資源消耗用量。

o Windows Server 2012 可以為 CPU、記憶體、儲存和網路…等核心指標提供精細的計費資訊。在 Windows Server 2012 當中，當 VM 虛擬主機在環境中遷移時，這些指標也會跟隨 VM 虛擬主機。

o System Center 2012 會整合這些消耗指標，並且允許雲端操作人員針對其原則重新顯示或計算費用。

使 Windows Server 2012 成為一個雲端優化的作業系統的各種功能的詳細介紹，可以在下面的白皮書當中找到： 使用 Windows Server 8 建構基礎設施即服務 (IaaS) 雲端。

應用情境
我們上面所述當中可以看出，雲端有許多個方面。在本篇部落格文章當中，我們將主要注意服務供應商角色，特別是供應商在使用 SMB 3.0 作為 VM 虛擬主機的儲存來使用 Windows Server 2012 RC 的 Hyper-V 網路虛擬化 和 System Center 2012 SP1 Virtual Machine Manager 的社群技術預覽 (CTP) 功能方面如何支援其私有雲基礎設施。在未來的部落格文章當中，我們將會繼續深入探討雲端的其他方面。

利用 System Center 2012 SP1 支援雲端基礎設施
首先，讓我們看一下 VM 虛擬主機如何提供和管理 Hyper-V 網路虛擬化。在 System Center 2012 當中，VM 虛擬主機導入了邏輯網路，會抽象企業資料中心當中的網路的各種定義，允許資料中心管理人員使用應用程式擁有者的語言，例如用術語“我希望我的 VM 虛擬主機連接到 CORP 網路”表達連線。對於每個資料中心，邏輯網路可以有不同的定義，VM 虛擬主機當中的自動化可以確保當部署 VM 虛擬主機時，會應用適當的組態設定。有了 SP1 我們在這之上導入了另一個叫做“ VM 虛擬主機網路”的抽象概念。邏輯網路現在適合於光纖網路， VM 虛擬主機和服務現在僅連接到“ VM 虛擬主機網路”。VM 虛擬主機網路可以由 VLAN、直接邏輯網路或 Windows Server 2012（具有 Hyper-V 網路虛擬化）達成。   
在 System Center 2012 SP1 CTP 當中，VM 虛擬主機僅支援使用通用路由封裝 (GRE) 建立 Hyper-V 網路虛擬化的 VM 虛擬主機網路，這是預設建議使用的機制。在 System Center 2012 SP1 的最後版本當中，我們計畫支援用 IP Rewrite 建立 VM 虛擬主機網路，這在現有環境當中部署較為容易，且不需要更改網路基礎設施，但是對於您分配的每個顧客位址 (CA) 均需要一個供應商位址 (PA)。我強烈建議您閱讀 Hyper-V 虛擬網路 上的部落格文章，來瞭解此技術的工作原理。   
PA 是從邏輯網路空間分配得來的，所以您應該像先前所做的那樣建立一個邏輯網路，並且分配一個 IP 位址集區，VM 虛擬主機可以從當中為 PA 空間提取位址。接著，您需要建立一個 VM 虛擬主機網路，該網路會由被部署的實際服務所使用。只需點擊幾次 VM 虛擬主機控制台當中的“ VM 虛擬主機”和“ Services ”圖示上的新連結點，就可以建立 VM 虛擬主機網路。可以在 此處 查看上述操作的詳細步驟。

在上面的範例當中，您可以看到 Tailspin 網路和 Wingtip 網路均具有重疊的 IP 範圍。他們是使用 Hyper-V 網路虛擬化達成自動組態設定的，無需任何特殊的硬體或其他軟體即可提供完全隔離。建立 VM 虛擬主機時，現在它可以連接到此 VM 虛擬主機網路，因此允許其在同一 VM 虛擬主機網路上連接到其他 VM 虛擬主機，同時保持該 VM 虛擬主機與其他屬於不同顧客的 VM 虛擬主機處於隔離狀態，即便他們使用同一子網路。  
對於需要為其服務使用者（承租用戶）提供隔離環境的服務供應商來說此功能非常重要，並且提供靈活性，使得承租用戶可以將其自己的 IP 位址帶到公用雲端環境。在 CTP2 當中，如果希望 VM 虛擬主機網路上的 VM 虛擬主機可以與不在 VM 虛擬主機網路上的實體交流，則您需要在這些網路之間設定閘道。這可以使用具有正確路由規則的 Windows Server來完成，將來您可以得到指導您如何完成設定此過程的指南。另外，隨著開發功能更進一步的深入，System Center 將允許此操作無縫式完成。   
儲存是雲端和虛擬化項目的另一個重要組成部分。利用 Windows Server 2012，我們現在能夠使用 SMB 3.0 檔案共用，進而在一個叢集和獨立的環境當中承載 Hyper-V VM 虛擬主機。這有助於降低雲端成本，同時增加靈活性，並且使得管理作業更簡單。（您可以在 此處 閱讀關於儲存的更多內容。）有了 System Center 2012 SP1，使用起來非常簡便。下面的螢幕擷圖中顯示如何為叢集和獨立主機增加檔案共用作為儲存，並且在此組態設定當中 VM 虛擬主機適當的組態設定存取控制清單。

獨立主機

Hyper-V 叢集

VM 虛擬主機一經部署到主機和特定儲存子系統上時，服務供應商可能需要靈活的將工作負載移動到不同的主機，或使用不同的儲存來確保 VM 虛擬主機是可用的，即便在需要為主機提供服務或者需要維護儲存環境時也是可用的。有了 Windows Server 2012 和 VM 虛擬主機，我們現在為即時遷移 VM 虛擬主機及其相關儲存提供多種選項。您可以：

1. 在一個叢集內即時遷移 VM 虛擬主機（通常具有共用的區塊或檔案儲存）

2. 將 VM 虛擬主機即時遷移到叢集內或從叢集內遷出

3. 將 VM 虛擬主機的儲存從一個儲存子系統即時遷移到另一個儲存子系統

4. 將 VM 虛擬主機從一個主機即時遷移到另一個主機（無共用儲存）

作為資料中心管理人員，您可以想像，這些選項為您提供多麼大的靈活性。下面的螢幕擷圖中顯示 VM 虛擬主機當中的各種不同選項。

您可以從上面螢幕擷圖的左邊看到，名為 Tailspin_ 2 虛擬主機運作在一個獨立的主機 HV104 上。右邊的對話方塊顯示，該 VM 虛擬主機可以從此獨立的主機遷移到 HVClusterA 叢集的節點當中（hv103n3、hv101n1、hv102n2），還可以遷移到獨立的 HV105。System Center 會自動檢測到在 HV104 和 HVClusterA 之間有沒有共用儲存，並為這些遷移加上“Live (VSM)”標籤，表示也將遷移儲存，而不僅僅只遷移 VM 虛擬主機。  
請注意，System Center 還可以令您選擇在主機內遷移 VM 虛擬主機的儲存，而 VM 虛擬主機無須停機。對於以下範例情況： 您某個特定儲存設備上的本機存放區馬上就要用完了，您希望將 VM 虛擬主機的儲存移動到主機上具有更多容量的另一個儲存設備上，這種情況下，上述功能特別有用。   
現在您可能已經察覺到我們僅對 HV105 顯示“即時”！這是為什麼呢？它並不是一個 Bug。要對此有所瞭解，我們來看 HV104（ VM 虛擬主機當前所在的主機）和 HV105 的儲存屬性。您可能已經看到，上述每台主機都會看到相同的 SMB 3.0，因此 VM 虛擬主機可以遷移 VM 虛擬主機（無需移動該儲存）。

結語
在本篇部落格文章當中，我們討論了雲端模型和二個不同的雲端角色（“服務供應商”和“服務使用者”）。我們還介紹了 Windows Server 2012 和 System Center 2012 SP1 如何提供此模型。我們重點介紹 Windows Server 2012 和 System Center 2012 SP1 當中的 Virtual Machine Manager 元件，以及如何使供應商能夠為 VM 虛擬主機使用 SMB 3.0 儲存，同時使用 Hyper-V 網路虛擬化建立隔離網路。在接下來的幾個月當中，我們將提供更多詳細資訊：關於 VM 虛擬主機如何使資源池和承租用戶管理，以及它如何利用 Windows Server 2012 當中的更多功能。

近來我與某人談及對自身所在社區有歸屬感以及無歸屬感人們之間的差異。他說當您走在路上，看到地面上有垃圾，對於居住社區有歸屬感的人會停下來，撿起垃圾之後扔進垃圾桶，而對社區無歸屬感的人則不會這麼做。他指出有許多歸屬感的人所居住的社區通常是清潔而且無犯罪的，然而沒人願意做出貢獻的社區只會變得越來越糟糕，生活在那裡的居民也會遭受到不同的痛苦。在他看來積極參與到社區活動當中是一種開明的利己主義表現方式。您只需要做出一點點貢獻，但是卻會為他人樹立了良好的榜樣，慢慢的情況就會變得越來越好。  
你們每個人都是 Windows 社群的一員。您可以選擇歸屬於或不歸屬於我們的社群。你們中的許多人已經選擇加入我們的社群，並且使 Windows 成為了最強大的社群之一。Windows PowerShell Survival Guide 尤其令人感到興奮，它提供了關於 Windows Powershell 的豐富資訊。   
但是實際上，想要從 Windows 社群中獲益並非易事，而加入 Windows 社群則更加困難。在今天的部落格當中，Kathy Watanabe 這位伺服器暨雲端運算部門資訊體驗社群的高級總監，闡述了我們將在 Windows Server 2012 當中推出的一些創新思維和工具以協助社群自我援助。透過應用社群的智慧和知識，您可以把工作做的更好，所以請花費一些時間來學習如何使用這些工具。但是不要僅僅局限於此。請開始或進一步參與到社群當中。這一切將變得前所未有的簡單。

Cheers！ Jeffrey

對於 Windows Server 2012，我們的資訊體驗團隊重新思考如何為顧客提供出色的資訊體驗。這針對以下幾個主要原則：

· 內容整合： 我們把整合到我們的內容及社群建立的內容中進行連結（以後會更多）。這樣可以提供更豐富、更廣闊及多樣產品和解決方案指南，因此方便您在企業中計畫、部署、操作 Windows Server 2012 時找到答案。PowerShell Script Explorer 可以說明此整合內容（或策展）概念的平台之一，可以提供針對腳本的策展存取。

· 社群： “社群與您”的想法對於建構 Windows Server 2012 指南非常重要。我們曾經針對您的意見反應建立資訊體驗，同時也依靠您對其進行擴充。

· 解決方案和應用情境： 我們在 IT 專業人士空間（TechNet Library）和開發人員空間（Windows Server Application Development）中提供解決方案和應用情境。並且不斷更新這些解決方案和應用情境以反映您不斷發展的網路需求。

內容整合（策展）
有幾種類型的內容整合產品。在此部分我們將說明下列二種：

· 一種被稱為 Microsoft Script Explorer 的工具

· 針對 TechNet wiki 的“Survival Guide”

Microsoft Script Explorer
我們的一項重要的內容整合產品被稱為 Microsoft Script Explorer。Microsoft Script Explorer for Windows PowerShell 説明腳本設計師在線上儲存存放庫（例如 TechNet Script Center Repository、PoshCode、本地端或網路檔案系統和 Bing 搜尋）中找到 Windows PowerShell 腳本、程式碼片段、模組及入門指南。

利用 Semantic Web 概念進行策展
Semantic Web即可獲取通常隱藏在產品文件、部落格文章、支援論壇…等內部的資訊，並且可以透過可預見的方式來定義資訊，當然這也會讓使用者發現此類資訊。最具代表性的範例就是 PowerShell 腳本。腳本通常以文件形式隱藏在網頁內部；搜尋引擎（例如 Bing、Google、Yahoo…等）無法區分您是在搜尋含有“PowerShell Script”這一詞語的網頁，還是搜尋真正含有有效的 PowerShell 腳本的網頁。   
下圖中說明 PowerShell 腳本可以儲存在不同的地方 – 在本地端檔案系統、網路共用、網站、線上論壇和腳本存放庫內。當腳本存在於網頁中時，例如在部落格或執行緒的討論中，我們相信 HTML 5 的資料將使我們能夠把額外的中繼資料包含在內，這些中繼資料描述頁面的特定部分，而頁面中包含腳本及與腳本名稱和目的有關且將提供更佳搜尋的資訊。對於儲存存放庫來說，例如 TechNet 和 POSH，我們相信 OData 可以提供存取這些儲存存放庫的程式化方法。   
PowerShell Script Explorer 透過巧妙整合（或策展）主要儲存存放庫、部落格網站和論壇的內容來使這些內容得以顯示。下圖顯示 Script Explorer 的高層次設計。中間的虛線用來劃分在企業網內部和外部運作/存在的程式碼和儲存存放庫。Script Explorer 最有趣的方面之一是所謂的“整合服務”。該服務負責協助根據您的需求從不同的資源整合腳本。可從任意數量的儲存存放庫中提取內容，無論儲存存放庫使用何種協定或腳本以何種方式顯示，然後整合功能並將資料顯示為一種針對 OData 的來源。

正如您在上圖中所看到的，通常有二個整合服務的 Instance 運作。第一個（右手側）在 Windows Azure 上運行，負責從針對網際網路的不同儲存存放庫（例如 TechNet 或 Posh）整合來源。第二個（左手側）在 Script Explorer 上運行，負責檢索來自外部整合服務及內部資源（例如您的本地端檔案系統和您想要擁護的任何企業儲存存放庫）的腳本。  
整合服務包括一項標準方式可供開發新的Provider，這些新Provider使您僅需更改設定檔就能夠搜尋腳本的替代資源並使這些資源直接顯示在 Script Explorer 內。此外，這種想法具有可擴充性，您可以建立/塑造自己的Provider，使用您最喜歡的搜尋引擎或使用非 PowerShell Script Explorer 使用的模式。如需關於建立新儲存存放庫或建立新Provider的更多資訊，請參見發佈在 Codeplex 上的範本。

Survival Guides
另一種策展產品是Survival Guide。Survival Guide是針對 TechNet Wiki 與特定產品、技術或方案相關資訊提供的連結。由社群（包括 Microsoft）建立和管理，Survival Guide透過生命週期、區域、方案或其他連結至主要資訊的標準來對應相關資訊。連結可指向任何內容，通常包括來自不同 Microsoft 網站及社群網站（例如 部落格、維基百科、YouTube）的資訊組合。   
Survival Guide可以提供由社群管理且便於為使用者和專業人士組織的最新資訊。Windows PowerShell Survival Guide、System Center Survival Guide、Hyper-V Survival Guide 和其他Survival Guide均位於 TechNet Wiki，它們也有助於教育訓練計畫、部署以及找到由不同地區的專家提供的更多資訊。認可度提升可使參與者受益。   
加入 TechNet Wiki 並分享您最喜愛的連結，增加意見為您富有熱情的產品或技術建立新的 Survival Guide！

社群
社群是資訊體驗的重要組成部分，我們與您攜手努力共同開拓和延伸指南產品。以下列出了我們作出貢獻的方式，我們的努力如何影響您的體驗，及您的參與方式：

· 事件和錯誤指南： 相關指南由社群增加。

· 從論壇到 Wiki：論壇中常見問題以及我們的回覆內容均會發佈在 Wiki。

· 意見箱：您想讓我們增加資訊或推薦區域。

· 腳本中心： 你們所有人（和我們）建立的 PowerShell 腳本的聚集地。

事件和錯誤
可搜尋源自社群的事件和錯誤，並利用社群的故障排除經驗。使用解決單一錯誤或事件的主題，顧客可在 TechNet Wiki 上使用搜尋找到最新的故障排除資訊，或在不久的將來從 Windows 事件檢視器 (Windows Event Viewer) 轉送。當可以使用事件檢視器時，參與者將能夠建立可被轉送系統發現且可自動使用的新主題。   
該方法可以為您（我們的顧客）提供協助。由於內容在 Wiki 上，它可以不斷更新，以反映最新的技術、洞察力和最佳做法。由於 Wiki 與 TechNet 論壇、部落格、圖片存放庫和 Microsoft 的其他工具共用強大的系統，因此參與者可以被識別並且可以透過建立，或者修訂被查看數以千計次的文章而在 Wiki 上成名。   
加入 TechNet Wiki 共用您的故障排除經驗。您可以更新事件 ID 1058 – 群組原則預處理（網路）或超過 50 項其他內容或建立您自己的內容。參與非常容易，並且受到大家的讚賞！

從論壇到Wiki
論壇策展： 透過這些努力，我們可以將不同 TechNet 論壇中一些熱門程度最高的主題文章轉變為 TechNet Wiki 文章來提高清晰度。透過參加一些顧客圓桌會議（並聽取社群中其他使用者的意見反應），我們瞭解到論壇答案往往“埋沒”於眾說紛紜的多種回覆、離題內容和以前答案的更新內容之中。另外，答案也可能確實難以找到。   
例如 存取 重新命名 Windows Server 2008 Active Directory 網域 或嘗試 這些 內容之一。   
透過進入 TechNet Wiki 上的文章，社群可以透過輕鬆的方式修改資訊，而無需透過其他評論。可標記、管理並與他人輕鬆共用內容。這可為顧客提升可發現性及清晰度，且能增強對參與者的識別（社群中的常見主題，不是嗎？）。   
您能夠發揮作用。在您最喜歡的論壇上，把流行的熱門文章轉換為 Wiki 文章。包括從論壇連結至 Wiki 文章，及從 Wiki 文章連結返回至論壇，這可作為確認來源及社群工作的方式。然後請求您的網路進行審查和更新。   
意見箱
意見箱： 意見箱 是您可以分享意見和建議，優先考慮它們並且説明提供社群內容的地方。我們的目標是説明確定社群需要的資訊，與社群成員共同協力以策展、開發或連結至資訊，無論資訊位於成員的部落格、論壇、TechNet Wiki 文章、Microsoft.com 還是其他地方。只有獲取社群意見反應才能不斷改進資訊體驗。   
儘管目前的意見箱並未與 TechNet Wiki 和其他 Microsoft 社群平台共用相同的設定檔，但提出新的意見、或對現有意見進行投票、或自願提供現有請求的內容還是很容易的。它還會提供一個您在參與時間方面意見的優先順序清單，但需要提出意見。這可説明您獲取需要的內容（及您應得的參與認可）   
腳本中心
對於專注在腳本的類似體驗。請存取 腳本中心。為 Windows 7、Windows Server 2008 R2、Windows Server 2008、SharePoint、System Center、Office 和其他產品下載資源和應用程式。由於經常會增加新資源，請經常檢查並且瞭解最新內容之後。加入我們！   
Scripting Games： Scripting Games 是每一年度專為 IT 專業人士、開發人員及其他想要學習 Windows PowerShell 的人士準備的首要學習活動。由腳本專家 Ed Wilson 管理，Scripting Games 透過有趣、包容和獎勵的途徑提供了加入 PowerShell 腳本社群（或提升您作為 PowerShell 專家的地位）的卓越方法。會見社群的其他成員，編寫非常酷的腳本以及接受傑出嘉賓評委小組提供的意見反應。   
Scripting Games 將透過提高認識、促進參與和網路化、學習一些巧妙的技巧和撰寫技術、以及贏得很酷獎品的方式來為社群提供協助。請檢查 Ed Wilson 的 參與十大理由 並在日曆上標記您的明年行事曆！

解決方案和應用情境
將我們的產品和技術與解決真正顧客問題的整體解決方案互相整合，這推動了我們的資訊體驗。在建構這些解決方案時，我們也考慮了 Windows Server 2012 提供的新價值主張：

· 建構您的雲端基礎結構： 案例概觀
您可以利用網路新功能和儲存虛擬化，當它們與改進的伺服器虛擬化互相結合之後，便可以建構針對 Windows Server 2012 的雲端基礎設備。這將有助您提供基礎設施作為服務 (IaaS) 的策略或建立代管服務。

· 動態存取控制： 案例概觀
您可以在整個檔案伺服器中應用資料管理，進而控制誰可以存取資訊及審核誰已經存取了哪些資訊。

· 方便裝載的網頁伺服器平台 (IIS)：案例概觀
迅速及高效率的縮放網路應用程式可形成雲端網路平台。增強安全性、應用程式初始化、NUMA 感知的可擴充性、及各網站之間的資源分享可達成快速縮放，並且管理成本非常小。

· 提高伺服器、存放裝置及網路可用性： 案例概觀
應用 Windows Server 2012 的新功能體驗共同努力提升單一伺服器和多台伺服器（垂直擴充 Scale-Up 和水平擴充 Scale-Out）的可用性、效能和可靠性。

感謝您參與我們為 Windows Server 2012 建立令人興奮的資訊體驗。希望您會喜歡！

我在上一篇部落格文章中有提到，在我們發佈下一版本 Windows 的過程當中，我們會逐漸確定和發佈許多詳細資訊。2012 年 4 月我們宣佈，官方產品名稱（“Windows Server 2012”）以及最後版本的產品將在今年問世。2012 年 4 月 23 日 Steven Sinofsky 在日本東京舉辦的“Windows Developer Days”專題演講中表示，2012 年 6 月初，Windows 8 Release Preview 將會開始提供下載。您可以從官方 MSFTNews Twitter。得知我們計畫在哪些時間提供 Windows Server 2012 的發佈候選版本。

–Cheers！Jeffrey

一位醫生曾經在談話當中告訴我，他的一位患者在病症出現一年後才決定就醫。他說如果這位患者在病症首次出現時就立刻治療，預期的治療結果將會非常樂觀，但是現在的情況要嚴重許多。這個故事讓我想起了之前曾經多次聽到忠告“永遠不要對醫生有所隱瞞”。醫生的任務只有一個： 那就是幫助您恢復健康。醫生只有在全面掌握您的病情後才能對症下藥，因此，如果您無法坦誠的面對他們，受傷的只會是自己。此外，透過瞭解您的病情，醫生也將累積幫助其他患者所需要的知識和技能。這種模式和思考邏輯同樣適用於 Windows Server 2012 Beta 的顧客操作體驗改善計畫 (CEIP)。我們會透過該計畫請求您允許我們收集有關伺服器運作狀況和使用情況的資料。我們經常收到有關 CEIP 的各種問題，例如“什麼是 CEIP？”和“CEIP 資料將如何使用？”。在本部落格文章當中，Karen 將為您解答這些問題，以及另外一個非常重要的問題： “我為什麼要啟動 CEIP？”

本部落格文章的作者是 Windows Server Telemetry團隊的專案經理 Karen Albrecht。

–Cheers！ Jeffrey

當我們和伺服器社群談到 Windows 顧客操作體驗改善計畫 (CEIP) 時，大部分人的反應都是“從來沒聽說過”。即使是那些對本計畫有所耳聞的人，有時也會選擇不啟用本計畫，因為他們“不希望分享自己主機的資料”。在本部落格文章當中，我將會介紹什麼是 CEIP，以及在已部署的伺服器上啟用該計畫將帶給您的好處。此外，我還將介紹 Windows Server 2012 中能夠幫助您更加輕鬆啟用 CEIP 的幾項新功能。

我們先來回答“什麼是 CEIP？”這個問題。對於從未瞭解過 CEIP 的使用者，在使用 Windows Server 2012 Beta 時，您可以透過伺服器管理員 -> 本機伺服器 -> 選擇 [Customer Experience Improvement Program]（顧客操作體驗改善計畫）連結來連接該計畫。

CEIP 是用於瞭解您如何使用 Windows Server 2012 的計畫，其目的是根據您的意見反應來改進產品。您可以透過多種方式加入 Windows Server 2012 CEIP 計畫。對於 Windows Server 2012 Beta 等於發行測試版軟體 CEIP 將預設啟用，以幫助我們在最後版本發行前改進該軟體。對於 Windows Server 2008 R2 等已發行軟體，我們將透過 CEIP 使用者介面（如上所示）提供通知，方便您選擇加入該計畫。

我們知道您需要伺服器時刻保持最佳狀態，尤其是在伺服器效能和網路頻寬方面。為了滿足此一要求，我們盡可能降低 CEIP 報告收集和傳輸過程的資源消耗。Windows 會透過一個名為 Windows 事件追蹤 (ETW) 的高速追蹤元件記錄 CEIP 使用資訊。ETW 可以説是 Windows Server 2012 在對伺服器效能沒有明顯影響的情況下記錄 CEIP 使用資料。CEIP 使用資訊會使用包括 Consolidator 和 Uploader程式二項計畫任務中分為二個部分的過程傳送給 Microsoft。Consolidator會將 CEIP 資料匯出為壓縮的二進位格式以準備傳輸。該二進位檔案的大小通常小於 1 MB，能夠盡可能降低對網路頻寬的影響。Uploader 程式計畫任務則會每隔 24 小時自動運作，並且將 CEIP 二進位資料透過 Windows Telemetry協定傳輸至 Microsoft 前端伺服器。

“CEIP 會收集哪些資料？”是大家經常提出的另一個問題。這些資料包含您的伺服器如何組態設定和使用的基本資訊，包括： 已安裝的角色、已安裝的功能、使用的設定和硬體資訊。CEIP 不會刻意收集個人身份識別資訊 (PII)。因此，CEIP 報告當中不會包含您的姓名、地址或電話號碼…等連絡人資訊。這表示 CEIP 不會要求您參與調查或強迫您閱讀垃圾電子郵件，也不會透過其他方式與您聯繫。Microsoft 顧客操作體驗改善計畫隱私權聲明中詳細介紹了 CEIP 所收集的資料，以及我們將如何使用這些資料。

接下來，我們將回答“將這些資料傳送給 Microsoft 對我有什麼好處？”此一核心問題，您一定會對 Windows Server 如何使用您的資料來改善產品感到大吃一驚。以下介紹的只是這些用途的冰山一角，我們希望借由這些範例讓您一睹我們如何透過 CEIP 資料來改進產品。

1. 提高伺服器可靠性： 在 Windows Server 2012 Developer Preview 和 Windows Server 2012 Beta版本當中，可靠性分析元件 (RAC) 功能可以確定 Windows Server 崩潰、Windows Server 掛起和套用程式崩潰的根本原因。RAC 會將 CEIP 資料和 Windows 錯誤報告 (WER) 資料相結合，以便重新建構導致崩潰或掛起時的系統狀態全貌。透過綜合分析來自這二個計畫的資料，我們可以識別出多種問題，以便檢查和修復這些問題，隨著版本更新，我們的平台將會變得越來越可靠。若要詳細瞭解 WER 所收集的資料，請參閱 Microsoft 錯誤報告隱私權聲明。

2. 改善伺服器管理腳本的可程式設計性： 對於大規模部署，IT 管理人員通常會透過 PowerShell 和 WMI 腳本來完成，因為它們可以明顯的簡化大規模部署管理。如果 Commandlet 或 WMI 介面更改或刪除，重新撰寫腳本以適應平台更改可能會非常痛苦。在 Windows Server 2012 當中，我們將使用 CEIP 來監控已放棄 API 的使用情況，以便等到這些 API 對您的影響最小時再將其刪除，以解決這個問題。例如在 Windows Server 2012 中，我們曾經考慮過放棄 Win32_ServerFeature WMI 介面，並以 MSFT_ServerManagerDeploymentTasks 取代。（對於未使用過該介面的使用者，Win32_ServerFeature 會檢測已經安裝的角色和功能。）   
作為放棄過程的一部分，我們新增 CEIP 資料以記錄介面使用情況，根據來自 Windows Server 2012 Beta 的最新 CEIP 資料，我們發現 47% 的使用者正在使用 Win32_ServerFeature。籍由這些資料，我們得以確認 Win32_ServerFeature 的遷移進度，因此，我們將等到遷移至 MSFT_ServerManagerDeploymentTasks 時不會對您產生影響，再將該介面從產品中正式刪除。   

3. 多樣化的 Windows 認證硬體： “Microsoft 會與合作夥伴共用哪些 CEIP 資料？”是大家經常提出的問題之一。作為硬體認證的一部分，在某些情況下，我們會將部分 CEIP 資料（不包含 PII）與 IxVs（獨立硬體或軟體供應商）共用。為市場中多樣化的硬體提供高品質的驅動程式支援是 Windows Server 的重要功能之一。達成此一目標的困難點在於瞭解市場中的哪些設備最為常用。CEIP 資料會用於建構硬體設定檔和 Mapping 設備的多樣性，以便告知 IxVs 相應的認證策略。籍由這些資料，IxVs 可以確定需要認證的驅動程式範圍（根據市場情況）並設定認證設備的優先順序（根據熱門程度）。

4. 改善產品操作體驗： 每天，我們都會透過 CEIP 資料來瞭解大量功能的組態設定情況，以便根據您的使用模式確定工作的優先順序。例如為了降低設定新伺服器的成本，CEIP 會記錄您所使用的設定。這樣我們就可以根據最常用的模式來調整預設設定，以便幫助您更加迅速地完成新伺服器設定。此外，我們還會在內部測試中使用這些資料。為了擴大測試範圍，涵蓋真實情境的使用模式，我們會分析 CEIP 資料以瞭解產品的使用情況。這將確保我們在設計和測試過程中，始終將您的使用模式納入考慮範圍。當然，除了上述範例，CEIP 還透過許多方式籍由顧客意見反應推動了產品的改進，但鑒於時間有限，我們就此進入下一個話題，這就是如何組態設定 CEIP。

在 Windows Server 2008 R2 發佈之後，我們對 CEIP 的採用率進行了評估，並且發現市場中只有 5 ~ 7% 的伺服器傳送了 CEIP 報告。透過針對 CEIP 使用率與使用者展開的合作，我們發現儘管許多伺服器選擇加入了 CEIP，我們卻未能收到來自它們所傳送的資料。我們分析了這種情況的根本原因，並瞭解到這些伺服器之所以無法傳送報告，主要是由於它們部署在防火牆環境中。為了傳送 CEIP 資料，伺服器需要能夠透過 HTTPS（預設埠為 443）進行通訊，並且需要組態設定代理程式設定（如果伺服器部署在使用代理程式伺服器的網路中）。透過與技術採用計畫 (TAP) 使用者展開的合作，我們發現一個或多個此類設定並未組態設定，進而導致 CEIP 資料無法傳送至 Microsoft。

為了方便您傳送 CEIP 資料，Windows Server 2012 Beta 包含多項能夠克服攔截問題的新功能，幫助您一勞永逸的完成 CEIP 設定。要參加 CEIP 計畫並向我們提供 CEIP 資料，最簡單的方法就是使用名為 Windows Feedback Forwarder (Windows Feedback Forwarder，WFF) 的新功能。WFF 是一種將來自網域中電腦的 CEIP 資料透過代理程式傳送至 Microsoft 的服務。WFF 將代理程式來自 Windows 7 和 Windows Server 2008 或更高版本等 Windows 產品的 CEIP 資料。WFF 還將代理程式來自任何已啟用“傳送顧客意見反應”的 Microsoft 產品資料。

該 Forwarder 可以設定於網域當中，也可以作為邊緣伺服器。網域中的伺服器將透過群組原則組態設定為向該 Forwarder 傳送資料。當某台電腦觸發了資料收集動作時，它會透過 HTTP 將這些資料傳送至 Forwarder ，然後 Forwarder 會透過 HTTPS 將這些資料轉發至 Microsoft。

1. 安裝 Windows Feedback Forwarder

1. 採用使用者介面 (UI)

1. 在任何 Windows Server 2012 電腦上，啟動伺服器管理員，然後啟動“新增角色和功能”精靈。

2. 在“新增角色和功能”精靈中，至 [Features]（功能）頁面，然後選擇 [Windows Feedback Forwarder] 項目。

3. 指定一個埠號（預設埠號為 53533）。如果該網域具有 Proxy代理伺服器，請指定代理伺服器資訊，然後完成安裝。

4. 在伺服器管理員中，選擇左側功能視窗中的 [All Servers]（所有伺服器）選項。在 [Servers]（伺服器）項目中，按下右鍵已安裝 Windows Feedback Forwarder 的伺服器，然後選擇 [Windows Feedback Forwarder Configuration] 項目。保持該對話方塊開啟以進行下一個步驟。

2. 採用 PowerShell

1. 啟動 PowerShell 並執行“Add-WindowsFeature WFF”

2. 在伺服器管理員當中，選擇左側功能視窗中的 [All Servers]（所有伺服器）選項。在 [Servers]（伺服器）磁碟中，按下右鍵已安裝 Windows Feedback Forwarder 的伺服器，然後選擇 [Windows Feedback Forwarder Configuration] 項目。

3. 選擇 [Forwarding Settings]（Forwarder 設定）頁籤，指定一個埠號（預設埠號為 53533）。如果該網域具有 Proxy 代理伺服器，請指定代理伺服器資訊，然後按下 [Apply]“套用”。

4. 使對話方塊保持開啟狀態以進行下一個步驟。

2. 部署 Windows Feedback Forwarder 群組原則

1. 要將網域中的電腦組態設定為向 Windows Feedback Forwarder 傳送 CEIP 資料，最簡單的方法是部署群組原則。您可以透過 2 種方式部署群組原則，使用 Windows Feedback Forwarder 組態設定的對話方塊，或使用群組原則管理主控台來建立指向群組原則物件的連結。

1. 使用 Windows Feedback Forwarder 組態設定的對話方塊

1. 在 Windows Feedback Forwarder 組態設定的對話方塊中，點選 [Group Policy]（群組原則）頁籤。

2. 輸入您希望部署群組原則物件的功能變數名稱，然後按一下 [Find]（尋找）。請注意： 您可能必須在此步驟輸入認證資訊，這取決於目前使用者的設定。

3. 組織單位清單視窗彈出後，請選擇一個或多個組織單位。

4. 按一下 [Apply]（套用）按鈕

2. 手動建立群組原則物件

1. 在 Windows Feedback Forwarder 組態設定的對話方塊中，選擇 [Forwarding Settings]（轉發設定）頁籤。複製 Windows 意見反應轉發 URL，以暫時將其儲存。

2. 在 GPMC 中建立新的群組原則物件和集合：

另一個啟用 CEIP 的方法是 Windows 自動意見反應對話方塊，這是伺服器管理員中提供的一種新的多電腦選擇加入操作體驗。籍由該功能只需 3 個步驟，便可以組態設定多台傳送 CEIP 資料的電腦。

1. 啟動伺服器管理員，在左側的功能視窗中選擇 [All Servers]（所有伺服器）。

2. 在 [Servers]（伺服器）項目中，按下 Ctrl+A 以選擇所有伺服器 -> 按右鍵並選擇 [Configure Windows Automatic Feedback] 項目（組態設定 Windows 自動意見反應）

3. 按下 [Enable Both Customer Experience Improvement Program And Windows Error Reporting]（啟用顧客操作體驗改善計畫和 Windows 錯誤報告），將在連接到該伺服器管理員控制台的所有伺服器上啟用這二項計畫

我們非常希望瞭解您對本計畫的看法，以及我們如何能夠改進該計畫，以便為您的部署和 Windows Server 使用提供最佳操作體驗。請提供您的寶貴意見。

Karen Albrecht  
Windows Server Telemetry專案經理

這是本系列文章（共兩篇）的第二篇文章。在第一篇文章當中，說明了有關 PowerShell 和 DevOps 的一些技術背景資訊。在這篇文章當中，則向您介紹一些相關細節。PowerShell 3.0 與 Windows Server 2012 類似，具有大量的新功能和增強功能，因此這裡僅僅簡略介紹部份內容。  
–Jeffrey

DevOps 一直是 PowerShell 所著重的重點，PowerShell 3.0 和 Windows Server 2012 已經將DevOps提升到一個新的水準。對於 Windows Server 2012 來說，我們已經將重心從單台伺服器的作業系統轉換為多台伺服器及其連接設備的雲端作業系統，無論這些設備是實體還是虛擬、是本地端的還是遠端。為了達成此一目標，我們在以下方面重點投入心力：

1. 達成所有任務自動化。

2. 達成可靠和敏捷度自動化。

3. 使維運人員更輕鬆的執行自動化。

4. 使開發人員能夠更輕鬆使用的開發工具。

達成所有任務自動化
Windows Server 2008/R2 內建了大約 230 個 Cmdlet。Windows Server 2012 內建的 Cmdlet 超過該數字的十倍，大約有 2,430 個。現在您幾乎可以自動執行伺服器所有方面的任務。這些 Cmdlet 涵蓋網路連接、儲存、叢集、RDS、DHCP、DNS、檔案伺服器、列印、SMI-S …等。如果您閱讀過 Windows Server 2012 的部落格文章，您就可以瞭解使用 PowerShell 可以做多少事情。如果您沒有及時瞭解相關資訊，請閱讀 Jose Barreto 的“檔案伺服器”部落格文章、Yigal Edery 的“私有雲端”部落格文章、Ben Armstrong 的 Virtual PC Guy 部落格文章、“叢集和高可用性”部落格文章 或 Natalia Mackevicius 的“合作夥伴和顧客們”部落格文章，之後您就會瞭解我的意思。Windows Server 2012 是目前為止 Windows 的所有版本當中自動化程度最高的版本。

已經有大量的硬體和軟體合作夥伴發佈他們自己的 PowerShell Cmdlet，尚未發佈的合作夥伴將在其產品的後續版本中陸續發佈它們。在美國拉斯維加斯最近召開的 MMS 會議上已經非常清楚的說明了這一點，我認為您在 TechEd 大會上將會看到更多支援 Powershell Cmdlet 的廠商。在購買任何產品之前，您一定要確認該產品會提供一組完整的 PowerShell Cmdlet。如果沒有，則您應該要三思而後行並且做一些市場調查，確定您所購買的產品是最新的並且仍持續維護的。如果某些產品沒有提供 PowerShell，您需要考慮這些產品是否還缺少其它功能？ 好消息是 Windows Server 2012 發佈時將有許多產品支援 PowerShell，已經提供 Cmdlet 的產品做到這一點很容易並得到非常積極的客戶意見反應。每個發佈 PowerShell Cmdlet 的產品都會在其下一版本中增加在 PowerShell 部份的投入。  
達成可靠和敏捷的自動化
WorkFlow
我們將 Windows Workflow Foundation 引擎整合到 PowerShell，以便簡單輕鬆的自動執行需要大量時間的任務、大規模的操作任務或者需要跨多台電腦協調的多步驟任務。傳統上，Windows Workflow 一直是開發人員的專用工具，該工具需要 Visual Studio 和許多程式碼才能建立一個解決方案。我們已經將其設計成一個解決方案，維運人員使用現有的 PowerShell 腳本技能便可以方便的建立解決方案。WorkFlow為並存執行、重試操作提供直接支援，並能夠掛起和復原操作。例如 WorkFlow可以檢測一個需要人工手動介入的問題，通知維運人員此一情況，然後掛起操作直到維運人員修正此問題並且復原WorkFlow為止。   
維運人員可以利用任何可用的WorkFlow設計器建立WorkFlow。不過我們進一步透過使用 workflow 關鍵字來擴充 PowerShell 語言，從而簡化解決方案的建立。任何維運人員或開發人員現在都可以使用所有 Windows SKU 中提供的工具方便建立WorkFlow。WorkFlow的行為與函數不同，它有更多的規則，但是如果您知道如何撰寫 PowerShell 函數，則有 80% 的把握可以撰寫WorkFlow。使用 PowerShell 建立 WorkFlow比使用 XAML 容易得多，並且比WorkFlow設計器工具更容易理解。還有一個好處是，您可以將WorkFlow貼到電子郵件讓其他人閱讀/檢查，並且無需安裝特殊工具。下面是一個在多台電腦上同時運作的範例WorkFlow，該WorkFlow在每台電腦上同時收集庫存資訊。

下列的指令將從 servers.txt 中包含的伺服器清單中獲得此庫存資訊，並將結果輸出到一個檔案。如果其中任一伺服器無法存取，WorkFlow將會每 60 秒嘗試連接一次該伺服器，並且持續一小時。

WorkFlow正是 DevOps 實作人員需要可靠和重複執行的操作。DevOps 的關鍵技術之一是 A/B 測試。這種測試技術會部署一個軟體的兩個版本並且運作一段時間。然後比較一些指標（例如銷售的增加量），將勝出的版本部署到所有電腦。WorkFlow功能允許 PowerShell 長時間對大量電腦執行操作，這樣可以方便的自動執行 A/B 測試。   
計畫的作業
我們還無縫式的整合了任務計畫程式和 PowerShell 作業，以便簡單而輕鬆的自動執行調度作業或者當特定事件法發生時自動執行某些作業。下面是持久運作的WorkFlow。該WorkFlow收集組態設定資訊（磁碟資訊）然後自行掛載。WorkFlow已經啟動並且取一個眾所周知的名稱“CONFIG”。我們將使用任務計畫程式復原此WorkFlow。在本範例當中，我們註冊一個 ScheduledJob，使其在每週五下午 6 點和系統每次啟動時運作。當發生某個特定觸發事件時，將運作計畫的作業執行復原該WorkFlow。然後，該WorkFlow收集組態設定資訊，將資訊放在一個新檔案中，並且再次自行掛載。

可靠的網路連接
在以前的版本當中，PowerShell 預設情況下會停用遠端功能，維運人員需要親自到每台電腦前執行 Enable-PSRemoting Cmdlet 才能遠端管理系統。作為雲端作業系統，現在透過 PowerShell 遠端來管理伺服器已經是主流方案，因此我們減少所需的步驟並在所有伺服器組態設定中預設啟用 PowerShell 遠端功能。我們進行了廣泛的安全性分析和測試，確保此功能是安全的。

在 Wojtek Kozaczynski 的 “標準管理”部落格文章 當中，他介紹了我們如何將 WS-MAN 作為主要管理協定，並保持 COM 和 DCOM 的相容性。WS-MAN 是一個使用 HTTP 和 HTTPS 的 Web Service 協定。儘管這些是有效的 REST 協定，但是 PowerShell 仍在這些協定之上建立了一個工作階段來進行遠端過程以提高效能和利用 Session 狀態。這些 Session 在應付普通網路中斷時非常可靠，但是，如果維運人員在大樓之間漫遊時使用可擕式電腦透過 Wi-Fi 網路管理伺服器，則偶爾會發生中斷。我們已經增強了 WSMAN 的工作階段層。預設情況下，它可以忍受長達 3 分鐘的網路中斷。還向 PowerShell Session 增加中斷連接 Session 支援，使用者可以選擇從活動遠端 Session 斷開然後再重新連接到同一 Session ，而不會遺失狀態或被迫終止任務的執行。您甚至可以從其他電腦連接到 Session （就像遠端桌面 Session 一樣）。   
讓維運人員更輕鬆的執行自動化
我們希望大幅降低成功自動執行複雜解決方案所需的技術水準要求。最後希望創造這樣的一個環境，也就是維運人員只要想到所需的東西，點選幾下鍵盤按鍵即可得到。每位客戶的需求和情境各不相同，因此他們需要撰寫自己的解決方案。我們的目標是簡單而輕鬆的撰寫可以與面向高級任務的抽象概念緊密結合的腳本，簡化撰寫腳本的首要因素是 Cmdlet 的覆蓋範圍。因此 Windows Server 2012 附帶了大約 2,430 個 Cmdlet，這極大的方便了自動化作業。其中許多 Cmdlet 在處理實際資料中心內的各種狀況時非常有效。我們將 Cmdlet 與 REST API 和 JSON 物件一起使用，甚至根據需要從管理應用程式獲取、解析和發佈網頁。

為了減少執行操作所需的步驟和語法，PowerShell 3.0 簡化語言和實用程式 Cmdlet，下面的範例顯示了舊語法和新的簡化語法執行操作的方式。

PowerShell3.0 改進維運人員用來撰寫腳本和建立WorkFlow所需的撰寫工具，PowerShell-ISE 現在支援豐富的 IntelliSense、程式碼片段、協力廠商可擴充性和“顯示指令”視窗，使用該視窗可以輕鬆的找到完成任務所需的準確指令和參數。

讓開發人員能夠更輕鬆的建構工具
由於 PowerShell 功能強大、使用 C 語言慣例並且具備對 .Net 物件的程式設計能力，因此開發人員喜歡使用 PowerShell 撰寫腳本。PowerShell 3.0 解決處理 .NET 和物件過程中的大量介接的問題，並允許開發人員在更廣泛的應用情境中使用 PowerShell。   
增強建構工具
PowerShell 3.0 現在有一個 抽象語法樹 (AST)。得以應用新的智慧工具來建立、分析和操作 PowerShell 腳本成為可能。大量Microsoft 雲端服務中有一個服務依賴大量的 PowerShell 腳本來運作該各式各樣的服務。他們的開發團隊使用 AST 開發出一個腳本分析工具。該工具能夠確保維運人員執行的腳本符合最佳時間規範。公開的 AST 是 IntelliSense 異常強大的原因。IntelliSense 使用 AST 檢查程式的實際行為。   
我們修改了 PowerShell 的許多關鍵領域，使開發人員更容易使用和擴充以客製撰寫自己的工具。這包括存取我們的序列化程式、API 改進，以及 PowerShell_ISE 的可擴充性模型。   
增強腳本功能
PowerShell 3.0 現在使用 .NET 動態語言執行 (DLR) 技術。PowerShell 監控腳本的執行方式並動態編譯腳本或部分腳本以優化執行效能。腳本的效能各不相同，但某些腳本在 3.0 中的運作速度比以前快了 6 倍。   
IntelliSense（和命令列上的 Tab 自動補齊）現在可以與 .NET 命名空間和類型一起使用。

它可以尋找相關程式的原因並且使用變數類型推斷改進 IntelliSense 的品質。

我們使用兩個變體擴充了雜湊表構造，這可以讓開發人員更方便的獲取他們需要的行為：

增強平台建構功能
為了支援委派管理方案，我們已經簡化此過程。使用 PowerShell 3.0 可以註冊遠端端點，組態設定提供的指令並且指定運作這些指令的憑據。這樣可以讓一般使用者能夠使用管理員權限執行一組定義好的 Cmdlet。我們已經使用聲明式的 Session 設定檔案簡化定義可用 Cmdlet 的過程。   
PowerShell 3.0 還可以作為 WINPE 的一個可選元件來提供。   
Windows Server 2012 和 PowerShell 3.0 是優秀的 DevOps 工具
DevOps 是一個新術語，關於它會帶來什麼效益目前存在一些分歧意見，但是在本質上它完全是透過自動化保證變化的安全性並且彌合維運人員和開發人員之間的差別。在該領域有許多工作要做，但 Windows Server 2012 和 PowerShell 3.0 為達成這些目標取得了大幅度的進步。PowerShell 不會是您 DevOps 工具箱中的唯一工具，但它是每個 DevOps 工具箱中不可或缺的工具。請立即 下載 Windows Server 2012 RC 版本 並且親自體驗一下。   
Chrees！

Jeffrey Snover  
Windows Server 團隊傑出工程師及首席架構師