TechNet Taiwan 官方部落格

下載試用，寫心得，拿好禮！

Leah Huang — Tue, 12 Mar 2013 10:33:00 GMT

下載試用，寫心得，拿好禮！

即日起第一次下載試用Windows Server 2012或System Center 2012 SP1的使用者，撰寫一篇100字安裝試用心得，及回傳下載證明，即可獲得「小豬桌上型吸塵器」一份，限量贈品，送完為止，要搶要快!!)！

活動時間：即日起至4/30(二)止。

下載試用：立即下載試用Windows Server 2012 或 System Center 2012 SP1

繳交資料：只需完整繳交以下3項內容，寄信至tn_tw@microsoft.com，即可獲得好禮一份，限量贈品，送完為止，要搶要快喔。

1. 基本資料：

姓名	電話	信箱	地址

2. 試用心得：100字以上的心得，內容可包含Windows Server 2012或System Center 2012 SP1安裝經驗、試用過程、使用優缺點、和前一版本之比較、對工作上的幫助等，將文章儲存為Word檔，並將檔名改為您的姓名即可。

※ 若將文章上傳到個人部落格上，可再附上文章連結，TechNet將挑選優質部落格文章，加贈TechDays水瓶及Microsoft年曆一份。

3. 下載試用證明：

請擷取A.登入帳號畫面與B.下載完成和右下角時鐘，並截圖

A.登入畫面截圖

B.下載完成與右下角小時鐘截圖(須100%下載完成)

好禮實品：限量贈品，送完為止，要搶要快!!


小豬桌上型吸塵器	Microsoft年曆	TD水瓶

※ 贈品不得要求折換現金或兌換其他產品，禮品統一於4月中旬寄出。

※ 針對本活動，TechNet保有修改活動辦法及獎品之權利。如有任何變更內容或詳細注意事項將公佈於本網站，恕不另行通知。

※ 本活動參加資格與獎項僅提供居住在台澎金馬地區之居民。

Windows Server 2012 實戰影片!!

a-talin — Thu, 18 Oct 2012 08:46:00 GMT

TechNet將許多實戰影片以及概念影片，統整至TechNet超級影城，內容包含Windows、Windows Server、SQL Server、SharePoint、Exchange Server、虛擬化、Office 365、Office、System Center、Communications Server、Desktop Optimization Pack、IE、商業智慧、Security、IIS&Web等，希望這些資源能對大家有所幫助。

以下將Windows Server 2012最新的實戰影片整理至此，提供給大家學習參考唷！

標題	課程內容描述
Windows Server 2012 預覽	介紹為雲端平台而生的 Windows Server 2012 其四項關鍵價值，也就是超越虛擬化、簡化大量伺服器管理、從 App 到雲端、啟動全新工作模式。
Windows Server 2012：從 App 到雲端（Part 1）	本影片將介紹 Windows Server 2012 如何將私有雲與公有雲，這樣混合的雲端環境進行無縫式整合，例如 Windows Azure Service Bus、Windows Azure Connect、VM 虛擬主機可移植性…等。以及對於網站伺服器在密度以及效能上的功能改進，例如 IIS CPU Throttling、SSL 憑證集中管理、應用程式初始化…等。
Windows Server 2012：從 App 到雲端（Part 2）	本影片將介紹 Windows Server 2012 如何將私有雲與公有雲，這樣混合的雲端環境進行無縫式整合，例如 Windows Azure Service Bus、Windows Azure Connect、VM 虛擬主機可移植性…等。以及對於網站伺服器在密度以及效能上的功能改進，例如 IIS CPU Throttling、SSL 憑證集中管理、應用程式初始化…等。
Windows Server 2012：簡化大量伺服器管理（Part 1）	Windows Server 2012 管理多台伺服器時就像管理單台伺服器的一樣簡單，此影片將討論單台以及多台伺服器中相關功能以及跨多個站台環境，以及檔案系統高可用性、網卡群組功能 (NIC Teaming)、叢集環境、儲存機制、Hyper-V 複本…等機制。
Windows Server 2012：簡化大量伺服器管理（Part 2）	Windows Server 2012 管理多台伺服器時就像管理單台伺服器的一樣簡單，此影片將討論單台以及多台伺服器中相關功能以及跨多個站台環境，以及檔案系統高可用性、網卡群組功能 (NIC Teaming)、叢集環境、儲存機制、Hyper-V 複本…等機制。
Windows Server 2012：超越虛擬化（Part 1）	本影片將介紹新版 Hyper-V 3.0 當中相關功能特色，例如即時遷移 (Live Migration)、即時儲存遷移 (Live Storage Migration)、網路虛擬化 (Network Virtualization)，以及 Site-to-Site 之間 VM 虛擬主機故障轉移的 Hyper-V 複本 (Hyper-V Replica) 機制。
Windows Server 2012：超越虛擬化（Part 2）	本影片將介紹新版 Hyper-V 3.0 當中相關功能特色，例如即時遷移 (Live Migration)、即時儲存遷移 (Live Storage Migration)、網路虛擬化 (Network Virtualization)，以及 Site-to-Site 之間 VM 虛擬主機故障轉移的 Hyper-V 複本 (Hyper-V Replica) 機制。
Windows Server 2012：啟動全新工作模式（Part 1）	本影片將介紹微軟開發 Windows Server 2012 時，主要的技術背景以及設計理念透過 RDS (Remote Desktop Service)、DirectAccess、Branch Cache…等機制，有效部署以及簡化使用者遠端存取企業資源的操作體驗。
Windows Server 2012：啟動全新工作模式（Part 2）	本影片將介紹微軟開發 Windows Server 2012 時，主要的技術背景以及設計理念透過 RDS (Remote Desktop Service)、DirectAccess、Branch Cache…等機制，有效部署以及簡化使用者遠端存取企業資源的操作體驗。
Windows Server 2012 中新一代 Hyper-V 3.0 強大功能預覽及展示	在 TechED 2012 大會中 Windows Server Virtualization 團隊 Jeff Woolsey，現場說明以及展示新一代的雲端作業系統 Windows Server 2012 其 Hyper-V 3.0 虛擬化平台的強大功能，例如隨機的 4KB I/O、達成 100 萬 IOPS…等。
透過 Hyper-V 網路虛擬化和無共用即時遷移達成 IP 可攜性	在 TechED 2012 大會中 Windows Server and Management 團隊 Michael Leworthy 介紹，如何透過新一代 Hyper-V 3.0 中的網路虛擬化功能，以及無共用儲存即時遷移技術 (Shared-Nothing Live Migration) 達成 IP 可攜性。

利用 Windows Server 2012 和 System Center 2012 SP1 建構雲端基礎設施

a-talin — Fri, 24 Aug 2012 06:06:42 GMT

作業系統平台提供的經驗、功能和 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 Server 2012 訊息體驗

a-talin — Fri, 24 Aug 2012 06:03:00 GMT

近來我與某人談及對自身所在社區有歸屬感以及無歸屬感人們之間的差異。他說當您走在路上，看到地面上有垃圾，對於居住社區有歸屬感的人會停下來，撿起垃圾之後扔進垃圾桶，而對社區無歸屬感的人則不會這麼做。他指出有許多歸屬感的人所居住的社區通常是清潔而且無犯罪的，然而沒人願意做出貢獻的社區只會變得越來越糟糕，生活在那裡的居民也會遭受到不同的痛苦。在他看來積極參與到社區活動當中是一種開明的利己主義表現方式。您只需要做出一點點貢獻，但是卻會為他人樹立了良好的榜樣，慢慢的情況就會變得越來越好。
你們每個人都是 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 Server 2012 RC版本即將發佈

a-talin — Fri, 24 Aug 2012 06:00:00 GMT

我在上一篇部落格文章中有提到，在我們發佈下一版本 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

透過顧客意見反應改善伺服器可管理性：顧客操作體驗改善計畫，如何能夠針對 IT 專業人士改善 Windows Server 2012 產品

a-talin — Fri, 24 Aug 2012 05:57:29 GMT

一位醫生曾經在談話當中告訴我，他的一位患者在病症出現一年後才決定就醫。他說如果這位患者在病症首次出現時就立刻治療，預期的治療結果將會非常樂觀，但是現在的情況要嚴重許多。這個故事讓我想起了之前曾經多次聽到忠告“永遠不要對醫生有所隱瞞”。醫生的任務只有一個：那就是幫助您恢復健康。醫生只有在全面掌握您的病情後才能對症下藥，因此，如果您無法坦誠的面對他們，受傷的只會是自己。此外，透過瞭解您的病情，醫生也將累積幫助其他患者所需要的知識和技能。這種模式和思考邏輯同樣適用於 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專案經理

Windows Server 2012、Windows PowerShell 3.0、DevOps – Part 2

a-talin — Fri, 24 Aug 2012 05:53:34 GMT

這是本系列文章（共兩篇）的第二篇文章。在第一篇文章當中，說明了有關 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 團隊傑出工程師及首席架構師

請立即下載 Windows Server 2012 Essentials 的 Beta 版本！

a-talin — Fri, 24 Aug 2012 05:50:21 GMT

對於 Windows Server 團隊成員來說，這是多麼激勵人心的時刻啊！本周稍早時我們便宣佈 Windows Server 2012 的 RTM 和公開發佈日期，將會與 Windows 8 的發佈日期互相協調。此後，就有源源不絕激勵人心的消息，不斷的從舉辦 2012全球合作夥伴大會的城市多倫多傳來。今天我們很高興能請到 Windows Server Essentials 團隊的 Joe Nalewabau，他將為我們帶來一個令人興奮的消息。現在您可能已經注意到在這些部落格中有些主題不斷出現：

· 我們花了很多時間傾聽合作夥伴和顧客們的意見反應。

· 我們一直很重視簡單性和靈活性。

· 使用者的工作效率變得更高了，他們可以用更少的步驟執行他們想做的事情。

· 我們的合作夥伴比以往有更多的方式進行部署作業 — Windows Server 2012 Essentials 就是個絕佳的範例。

· 以合作夥伴和顧客們為中心的設計理念，使我們能夠在不同團隊之間達成有效的無縫式協同合作，進而提供協調且一致和全面的解決方案。

· 我們非常重視合作夥伴和顧客們的感受，真心希望能夠早點讓你們部署 Windows Server 2012 並使用它，以感謝你們對這款產品的厚愛。

Cheers — Jeffrey

大家好，我是 Windows Server Essentials 團隊的專案經理 Joe Nalewabau，今天我懷著激動的心情向各位隆重介紹 Beta 版本的 Windows Server 2012 Essentials （也就是 Essentials 2012）。
對於我們團隊來說，Beta 版本是一個具有重要意義的里程碑。我們非常希望能夠盡可能獲得更多有關產品的意見反應，並且您可以在 Windows Server Essentials 2012 Beta Essentials 論壇上查看並提交有關 Beta 版本的意見反應。我們將盡力在今年發佈 Essentials 2012，所以今後幾個星期，隨著我們朝著發行候選版本和最後的 RTM 版本方向不斷邁進當中，您對於 Beta 版本的意見反應對於我們來說是非常重要的。
正如 David Fabritius 在他上周發佈的文章當中所說的，Essentials 2012 表示著該產品的一個重要里程碑。我們對於伺服器市場（中小型企業和家庭辦公室…等）的看法已經發生了一些改變，並且我們在此領域中所提供的產品都針對顧客們和合作夥伴的意見反應。本文將提供我們在開發 Essentials 2012 過程當中，以及與相關的一些見解。在未來幾周當中，我們還會陸續發佈一些部落格文章，您將會瞭解到與特定功能有關更深層次的資訊。
從 IT 管理人員的角度來看，我們將圍繞以下四個核心原則來規劃 Essentials 2012：

· 為顧客們和合作夥伴提供簡單性和靈活性。

· 與 Windows Server 2012、Windows 8 更好的協同運作。

· 提升設備支援能力。

· 持續整合雲端服務。

為顧客們和合作夥伴提供簡單性和靈活性
從歷史上來看，工程團隊已經在 Windows Server 上開發並且支援了一定數量的解決方案產品。目前市場上由我們團隊所開發並支援的產品包括：Windows Small Business Server (SBS) 2011 Standard、Windows SBS 2011 Essentials、Windows Home Server (WHS) 2011、Windows Storage Server 2008 R2 Essentials。同時我們還支援以前版本的 SBS Standard 和 WHS。

這些產品的目標顧客們並不是傳統的 IT 管理人員。籍由我們廣泛的合作夥伴生態系統（OEM、加值經銷商和小型企業解決方案專家社群所組成），我們花費了大量時間建立適用於非 IT 專業人員簡單且全面的操作體驗。
我們在 Essentials 2012 中透過多種方式令使用者體驗到簡單性和靈活性：

· 簡化產品線： 在經過反復討論並且採納顧客們及合作夥伴的意見反應之後，我們決定將整個產品線簡化為一種產品。在此簡化的過程當中，我們決定從我們的其他產品中盡可能多的核心功能導入到 Essentials 2012 內（例如 Home Server 和 Storage Server Essentials 中的多媒體功能）。這種簡化動作以及稍後說明的靈活性，將會使合作夥伴能夠根據顧客們特定的業務需求來設計和部署最佳的解決方案。

· 簡化過去 25 個使用者數量限制： 有關 SBS 2011 Essentials 的重要意見反應之一就是，一旦顧客們使用超過 25 個使用者帳號的限制時，那麼他們就不得不遷移到 Windows Server Standard 版本上。但是遷移之後，他們以前所依賴的那些重要 SBS 特定功能（例如使用者端備份和遠端 Web 存取…等）便無法使用。
我們想要在 Essentials 2012 中解決此一問題，因此我們現在允許顧客們直接升級到 Windows Server 2012 Standard。現在顧客們在運作 Windows Server 2012 Standard 時不會受到任何 Essentials 2012 的授權限制，而且 Essentials 2012 的大部分功能都能夠繼續運作，並且支援最多 75 個使用者帳號及 75 台設備。（請注意!! 雖然在 Windows Server 2012 Standard 環境中沒有增加針對使用者/設備的數量限制，但是 Essentials 2012 功能依然存在最大可支援性的限制）。

· 顧客們可靈活選擇如何處理電子郵件 (本地端、代管或雲端)： Essentials 2012 中一項重要的靈活性表現在，允許合作夥伴和顧客們自由選擇其電子郵件服務的位置。在 SBS 2011 Standard 中，電子郵件預設會被安裝在本地端。SBS 2011 Essentials 包含針對 Office 365 連接的載入項目，但是無法與運作在本地端第二台伺服器上現有的 Exchange 伺服器進行整合。
在 Essentials 2012 當中，您能夠從下列選項中選擇電子郵件服務的位置：

1. 本地端： Essentials 2012 將與運作在第二台（實體或虛擬）伺服器上的本地端 Exchange 伺服器進行整合。

2. Office 365：如果顧客們有 Office 365 帳號，則可以選擇使用它來收發電子郵件。

3. Exchange 代管： Exchange代管供應商可以提供針對 Essentials 2012 的載入項目，使顧客們能夠選擇此選項。我們知道有許多不同類型電子郵件代管供應商。儘管我們主要是著重於代管 Exchange 的電子郵件代管供應商，但是我們的產品設計採用與電子郵件服務無關的機制，進而能夠允許與非 Exchange 的電子郵件代管供應商進行整合（請注意!! 此特定功能在 Beta 版本中尚未啟用運作）。

與 Windows Server 2012、Windows 8 更好的協同運作
Windows Server 2012 説明顧客們支援數量驚人的方案和關鍵技術。我們瀏覽了大量的 Windows Server 功能，並且選擇了一些特定的功能進行深度整合。我想重點介紹一些從 Windows Server 2012 和 Windows 8 中整合的主要技術或功能：

· 儲存空間：“儲存空間”為伺服器環境提供大量令人注意的解決方案，包括簡單的容量擴充機制、使用商用硬碟為實體硬碟故障狀況進行復原。能夠簡單的增加磁碟和增加儲存容量是我們的顧客們和合作夥伴一直以來的要求，所以我們在 Essentials 2012 中透過精靈和告警機制整合了“儲存空間”以確保它足夠簡單且容易使用。

· 檔案歷史記錄：“檔案歷史記錄”是一種新的 Windows 8 技術，它可以使您儲存在使用者端電腦上對檔案所做的更改，然後很容易的找到並且還原為先前的版本。在 Essentials 2012 當中，可以簡單的將 Windows 8 使用者端組態設定為打開“File History”功能並且將資料夾指向 Essentials 2012 伺服器。這對於 Windows 8 的使用者來說是個極好的使用操作體驗。在開啟此功能之後，他們便可透過將“檔案歷史記錄”儲存在伺服器上獲得更高的檔案安全性。

· 應用程式相容性： 有些 SBS 顧客們曾經回報，儘管 SBS 是在受支援的 Windows Server 作業系統基礎上開發的，但由於 SBS 不屬於受支援的作業系統，因此無法從 LOB (Line of Business) 應用程式供應商那邊獲得技術支援。我們透過努力使 Essentials 2012 成為整個 Windows Server 2012 應用標籤認證計畫的一部分。透過 Windows Server 2012 應用標籤認證要求的應用程式也將滿足在 Essentials 2012 上運作的要求。而且，我們已經盡力擴充了 Essentials 2012 應用程式相容性的測試環境。這些努力都使 ISVs 能夠為 Essentials 2012 提供更好的支援程度。

當然，顧客們還可以免費獲得各種 Windows Server 2012 技術，使得該版本對於使用者更具吸引力。
提升設備支援能力
工程團隊重點關心的另一個領域是提升我們的設備支援程度。我們知道，使用我們現有產品的顧客們一般都擁有多台設備，而且他們想要從這些設備存取資訊或控制他們的伺服器。我們已經在 Essentials 2012 中以多種不同方式來擴充我們對設備的支援程度：

· 遠端 Web 存取 (RWA)： RWA 為受到我們許多顧客們青睞的現有功能。我們在 Essentials 2012 中做了多項改進，其中最大的改進是保障 RWA 能在以觸控式為主的設備上（包括 iPad 和針對 Windows 8 的觸控設備）正常運作。RWA 除了支援 Media Streaming 伺服器之外，也改進了對於伺服器上檔案和資料夾的存取作業。

· 原生 Windows 8 Metro 應用程式： 我們正在開發用於存取 Essentials 2012 伺服器的 Windows 8 Metro 應用程式。Windows 8 將繼續支援現有的使用者端 LaunchPad，但是我們還是想開發一種 Windows 8 的原生應用程式，以便人們能夠快速、輕鬆的存取和控制他們的伺服器。這個應用程式讓我們感到非常興奮，因為它能支援一些很酷的解決方案 — 特別是適合於那些經常出差並且需要從伺服器存取檔案和資料夾或多媒體的使用者。這是我們第一個支援離線模式的使用者端應用程式，專門為經常出差在外的使用者而開發的 — 這同樣也是來自於顧客們的需求。此外，我們還在此應用程式中建立許多 Windows 8 的標準介面，進而支援一系列 Windows 8原生的新方案，例如在 Essentials 2012 上簡單進行檔案上傳和搜尋。

· 更新的 Windows Phone 應用程式： 我們已經更新現有的 Windows Phone 7 應用程式，以配合使用 Essentials 2012 伺服器 — 包括對伺服器上的檔案和資料夾進行存取的功能（此功能在上一代版本中無法使用）。

· 可擴充性的 Web 服務： 這主要是針對網站開發人員的功能，但是讓我們感到興奮的是這對於擴充所帶來的可能性。Essentials 2012 包含群組 Web 服務，使開發人員能夠為伺服器重新撰寫群組使用者端應用程式。正如前面所述，我們在 Windows 8 Metro 和 Windows Phone 應用程式中使用的就是這些服務。開發人員現在可以撰寫不同的應用程式或小工具…等，來與 Essentials 2012 伺服器互相溝通。

持續整合雲端服務
我們另外一個著重的要點是持續整合雲端服務。我們從來自顧客們的研究和意見反應中瞭解到，很多人都在探索整合雲端服務的方式，而我們一直想要確保 Essentials 2012 能夠與 Microsoft 提供的雲端服務進行更好的整合：

· 整合 Office 365：在 SBS 2011 Essentials 當中，我們已經透過 Office 365 整合模組達成對它的深度整合。我們已經將此模組直接整合到 Essentials 2012 當中，並且更新支援以顯示有關 Office 365 的詳細資訊且更新我們的功能。例如將 Office 365 帳號批次導入到 Essentials 2012 當中。是否使用 Office 365 服務完全是由您選擇的 — 這是使用者在組態設定他們的伺服器時針對電子郵件服務的其中一個選項。

· Microsoft 線上備份服務 ： Essentials 2012 已經整合 Microsoft 線上備份服務，該服務使顧客們能更容易的註冊他們的伺服器和執行線上備份作業。進而在現有的伺服器備份機制上又增加了另一個保護機制。

Essentials 2012 包含豐富的 SDK，使顧客們和合作夥伴能夠將更多服務整合到伺服器當中。我們保證，現有適用於 SBS 2011 Essentials 和 WHS 2011 的載入項目能夠在 Essentials 2012 當中繼續運作。
結語
我們對於能夠將 Beta 版本的 Essentials 2012 傳遞到您手中感到非常興奮與激動。整個工程團隊都熱切期盼能收到您的意見反應，因為您的意見反應將幫助我們將 Essentials 2012 打造成一款偉大的產品。

Windows Server 2012、Windows PowerShell 3.0、DevOps – Part 1

a-talin — Fri, 24 Aug 2012 05:36:34 GMT

在這個分為二部分的系列文章當中第一篇文章，我將會提供有關 PowerShell 和 DevOps 的一些技術背景資訊。在第二篇文章當中，則向您介紹一些相關細節。PowerShell 3.0 與 Windows Server 2012 類似，具有大量的新功能和增強功能，因此這裡僅僅簡略介紹部份內容。

–Cheers – Jeffrey

我是在介紹 2009 Velocity 大會的部落格當中第一次聽說 DevOps。在業界大多數人每年部署幾次發佈版本都會感到吃力的同時，John Allspaw 和 Paul Hammond 卻高調的宣稱“每天部署 10 次：開發人員與維運人員在 Flickr 上的協同合作”。他們創造出透過改變文化和工具傳遞營運結果的案例，並且催生出一個新名詞「DevOps」。問題是開發人員認為他們負責傳遞功能，維運人員則認為他們負責維持網站運作。開發人員與維運人員的分工不同導致在發生錯誤時互相指責。成功的營運需要共同承擔責任和互相尊重的 IT 文化：開發人員應該要考慮維運人員的需求和注意事項，同樣的維運人員也應該考慮開發人員的需求和注意事項。
他們的談話說明了企業需要如何因應快速變化，而該變化也是大多數網站關閉事件的根本原因。他們避開了傳統“避免變化”的做法，主張透過自動化使改變能更安全一些並將風險降至最低。這就是 DevOps 的工作 – 安全性變化。這是應用於 IT 操作的 Taguchi 品質方法。Taguchi 注意到，品質差的根本原因是改變。解決的辦法是首先弄清楚如何重複做一些事情。如果能夠這樣做，便可以在該過程中進行一些小小的變動，以瞭解這些變動是使事情變得更好還是更糟，停止使事情變得更糟的變動，繼續做使事情變得更好的動作關鍵是「可重複性」。可重複性使我們能夠執行一些促使改進的實驗，我們透過自動化在 IT 操作中獲得可重複性。
我們透過發佈 Monad Manifesto 開始 PowerShell，該版本清楚的說明了我們看到的問題、解決這些問題的方法以及要傳遞的元件。我們建構了一個分散式自動化引擎和一種指令碼語言。資淺的維運人員和經驗豐富的開發人員將使用該引擎和語言。催生出 DevOps 構想和價值同樣可以套用於 PowerShell 設計：

1. 專注於營運。

2. 透過自動化進行安全性變動。

3. 消除開發人員和維運人員之間的隔閡。

專注於營運
PowerShell 始終專注於在營運環境中使用電腦的人。PowerShell 需要 一致性、安全性、高效率。PowerShell 和 UNIX 之間有許多相似之處，但在此一重點上我們與 VMS/DCL、AS400/CL 更為相像。
一致性： 維運人員和開發人員沒有太多的時間學習新知識。一致性的體驗可讓他們一次性的投入精力於一套技能當中，然後可以反覆使用這些技能。PowerShell 對於所有指令使用一個通用的分析程式並且執行通用的參數驗證，在命令列語法當中提供絕對的一致性。PowerShell Cmdlet 的設計方式為，普遍存在的參數可以向所有指令提供一致性的函數（例如 –ErrorAction、–ErrorVariable、–OutputVariable …等）
安全性： 維運人員曾經告訴過我，有時他正準備做某事時就會意識到，如果做錯了他可能會被解雇。在 PowerShell 當中，如果您曾經執行某個對系統有負面影響的 Cmdlet，則可以事先鍵入–WhatIf 參數來測試如果執行此操作時會發生什麼情況。我們還支援 –Confirm、–Verbose、–Debug 參數。不過儘管有這些測試運作參數但是仍然可能發生錯誤，如果發生錯誤時 PowerShell 將會做出許多努力以加快診斷和糾正錯誤。
高效率： PowerShell 設計的每個方面都是為了最大程度提高管理人員的能力（因此而得名）。PowerShell 可以跨越大量主機輕鬆執行批次操作。PowerShell 還可以讓維運人員與開發人員之間輕鬆且高效率的協同合作，因為 PowerShell 允許他們使用共同的語言並且在腳本當中互相幫助。
透過自動化進行安全性變動
PowerShell 為 .Net 語言、指令碼語言、互動式 Shell？這已經討論過許多遍了!! PowerShell 是一個帶有指令碼語言和互動式 Shell 的分散式自動化引擎。互動式 Shell 和指令碼語言是關鍵元件，但是重點在於透過腳本達成的自動化。自動化是減少和消除由人為執行的操作過程。腳本記錄要發生的事情。管理人員可以查看腳本並且根據他們的回應修改該腳本。您可以測試腳本、觀察結果、修改腳本，如果修改效果良好則可以保持，如果效果不佳則可以停止。換句話說，腳本提供將 Taguichi 方法應用到 IT 操作的可重複性。在擁有自動化過程之後，便可以安全性的反覆應用該過程。現在資淺的管理人員可以執行這些過程。使用傳統的 GUI 管理工具時是不可能執行這些步驟的。
消除開發人員和維運人員之間的隔閡
我們的目標始終是傳遞可以滿足維運人員執行臨時操作、簡單腳本、正式腳本、進階腳本和開發人員執行系統級程式設計時所需要的單一工具。
PowerShell 花費了大量的心力嘗試計畫，針對任務並且具有統一語法和語義的高度抽象語法的環境。我們將之稱為 Cmdlet。這也正是維運人員確實有效能管理系統所需的方法。要使用 API 進行複製檔案的動作，您需要執行以下操作：

您有沒有想過為何 PowerShell 要使用大括弧 {}（和其他 C 語言構造函數），而不使用其他指令碼語言使用的 BEGIN/END？這樣做是因為我們想讓開發人員更輕鬆的採用其他 C 語言的程式設計語言： C++、Objective C、Java、JavaScript、Perl、PHP …等。我們做了一些測試並且確定維運人員能夠輕鬆適應這種語法。我們還希望提供一種在 PowerShell 和 C# 之間順利轉換的途徑。希望為從開發人員轉為維運人員提供職業移動性。
最重要的是，我們希望開發一種維運人員和開發人員都可以使用的工具，以消除這二個團隊之間的差異，並且允許他們建立通用腳本，以便互相學習攜手合作。
Windows Server 2012 和 PowerShell 3.0 是卓越的 DevOps 工具
DevOps 是一個新術語，關於它會帶來什麼好處目前還存有一些不同的意見，但是在本質上它完全是透過自動化來保證變化的安全性，並且希望消除維運人員和開發人員之間的差異。在該領域有許多工作要做，但是 Windows Server 2012 和 PowerShell 3.0 為了達成這些目標取得了相當成效的進步。PowerShell 不會是您的 DevOps 工具箱中的唯一工具，但它是每個 DevOps 工具箱中不可或缺的工具。請立即下載 Windows Server 2012 RC 版本並且親自體驗一下。
Cheers！

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

介紹伺服器和雲端合作夥伴以及顧客解決方案團隊部落格

a-talin — Fri, 24 Aug 2012 05:29:36 GMT

您可能不止一次聽到我提起，在規劃 Windows Server 2012 期間我們在顧客和合作夥伴方面花費了少少時間及心力。在規劃結束之後我們並沒有停止作業。在本篇部落格文章當中，Natalia 會先介紹自己以及她的團隊還有他們的部落格，此部落格中記錄了一些顧客/合作夥伴參與活動的詳細資訊以及他們在 Window Server 2012 中如何成功實作出來的過程。
–Cheers！Jeffrey Snover

大家好，我是 Natalia Mackevicius，是 Windows Server 合作夥伴和顧客生態系統的部門專案經理。早在去年10 月，我曾經簡單介紹了我的角色，以及我的團隊在 Windows Server 2012 的規劃和開發過程中，如何傾聽並吸取顧客和合作夥伴的所有重要聲音：Windows Server 8：傾聽顧客和合作夥伴的聲音

現在，我非常高興的推薦伺服器和雲端合作夥伴以及顧客解決方案團隊部落格。在接下來的幾個月裡，這個部落格將會分享顧客在實作 Windows Server 2012 的新功能的範例，並且重點介紹合作夥伴為 Windows Sever 2012 所開發硬體和軟體的機會。這些範例將會與 Windows Server 部落格和產品團隊部落格一起，提供關於各種功能更多詳細的技術資訊。
下列是我們將要在部落格中所發佈的內容：

· 討論早期採用該產品的顧客們如何使用 Windows Server 2012 技術來解決目前的困難點或提出新的機會和應用情境。

· 從我們運作的工程審核專案當中，提供顧客們採用產品以及最佳實作的早期資訊。

· 討論針對合作夥伴 Windows Server 2012 應用情境以及技術整合 (例如 API、硬體、應用程式)。

· 概述參考結構或合作夥伴正在開發的技術類型，以完成或擴充 Windows Server 2012 解決方案。

我們希望本篇部落格文章對您有用。我們將會在這裡提供伺服器和雲端合作夥伴以及顧客解決方案團隊部落格的定期匯總，以便您不會錯過任何內容。
隨時歡迎您的任何建議和問題。歡迎您加入討論！
請允許我來介紹我們團隊的第一篇部落格文章：Windows Server 2012 技術採用計畫 – TAP

Natalia Mackevicius
合作夥伴和顧客生態系統
部門專案經理

簡介 Windows Server “8 (2012)” Hyper-V 網路虛擬化：在雲端環境中達成快速遷移和工作負載隔離

a-talin — Fri, 24 Aug 2012 03:07:00 GMT

我們都聽說過伺服器虛擬化所帶來的靈活性。但是，我們與相關領域人員之間討論後，發現虛擬化的全部潛力還是遠遠超出他們所能承受的能力範圍。特別是缺少靈活的網路組態設定限制了您以合理的成本達到靈活性。
Windows Server “8 (2012)”是優化的雲端作業系統，它在組態設定私有雲、混合雲、公有雲解決方案方面提供選擇和靈活性。Bill Laing 在部落格文章（Windows Server “8”Beta Available Now）當中簡要介紹了相關功能其中包括 Hyper-V 網路虛擬化。在本篇部落格文章當中 Sandeep Singhal（Windows 網路團隊總經理）和 Ross Ortega（Windows 網路團隊首席專案經理），介紹了採用雲端環境的一些問題，以及 Windows Server “8 (2012)” 中的 Hyper-V 網路虛擬化將如何解決這些難題。
Cheers！– Jeffrey Snover

我們花費了數年的時間與使用者們探討他們尚未向在工作環境中部署雲端環境的原因。我們經常聽到三個主要問題。第一點，他們希望籍由靈活的混合雲解決方案逐漸開始將企業中個別服務遷移到雲端環境中。第二點，將個別服務遷移到雲端環境上的作業流程相當困難。因為它枯燥乏味、耗費時間、需要手動操作、容易出錯…等。第三點，管理人員對於遷移到雲端環境的同時，需要保持與其它承租用戶隔離的能力表示擔憂，私有雲中的其它業務部門或公有雲中的競爭對手同樣也是如此。最後，無論您是要建構自己的私有雲，或是考慮使用公有雲環境您都希望能夠輕鬆管理，在任何地方都能夠靈活的部署VM 虛擬主機（也就是說可以在雲端環境之中，也可以在雲端環境之外）並且能隔離工作負載。

網路靈活性：未履行的承諾
考慮到上述的所有擔憂，管理人員們需要能控制並且靈活的將服務遷移到雲端環境上，遷移到不同的雲端環境供應商，甚至將服務遷移回企業資料中心內。但是，這是一項相當密集的作業流程，原因在於將服務遷移到特定的雲端環境上時，雲端主機代管服務供應商有可能要求客戶們需要更改服務的 IP 位址。這看起來似乎是一個微不足道的部署細節，但是 IP 位址不僅僅只是網路組態設定人員為了定址而任意設定的。IP 位址對於企業來說具有實實在在的含義。許多網路、安全、符合性和績效原則包含都依賴於指定服務的 IP 位址。遷移到雲端環境上表示必須要重新組態設定相關原則。當然，您必須要先查閱所有原則，然後與控制這些原則的不同組織進行協調。如果想遷移到不同的雲端供應商，則新的主機代管服務提供者應該要分配不同的 IP 位址，而這也是需要重新撰寫原則。目前的情況阻礙了許多客戶們和應用情境採用雲端技術。
客戶們希望Windows 在雲端環境中的服務與在內部資料中心上運作的服務相似，同時又能遵守現有的原則並且與雲端代管環境中運作的其它VM 虛擬主機能互相隔離。當遷移到雲端環境上時，客戶們希望他們的資料如同在自已的資料中心中運作一樣可以獨立且安全。
總之，您需要能夠在任何雲端環境中的任何伺服器上運作任何服務。
我們認真對待此一重要的意見反應，並且設計了 Windows Server “8 (2012)”中 Hyper-V 網路虛擬化的新技術，來為建構雲端資料中心的客戶們提供可擴充性、高安全性的多承租用戶解決方案，並使客戶們更易於逐漸將網路基礎設施遷移到私有雲、混合雲、公有雲環境上。正如我們將在後面所描述的那樣，Hyper-V 網路虛擬化建立在現有的 IETF 和 IEEE 標準基礎之上，提供目前和未來網路設備、安全設備及操作流程的互通性。

Hyper-V 網路虛擬化：將伺服器虛擬化概念應用到網路環境中
對於傳統的伺服器虛擬化來說，每台實體主機被轉換為可以在公共實體主機上運作的VM 虛擬主機。每台VM 虛擬主機都可以在專用的硬體上運作，即使實際上共用所有硬體資源 — 記憶體、CPU、週邊設備。

網路虛擬化則是將伺服器虛擬化的概念擴充到整個網路環境中。透過網路虛擬化，每個實體網路被轉換為一個可以在公共實體網路上運作的虛擬網路。每個虛擬網路都可以在專用的網路上運作，即使實際上共用所有資源－ IP 位址、交換機和路由器。
Hyper-V 網路虛擬化允許客戶們在遷移到雲端環境時能夠保留原本的內部 IP 位址，同時與其它客戶們的VM 虛擬主機具備互相隔離的特性－即使這些VM 虛擬主機使用完全相同的 IP 位址。我們透過為每台VM 虛擬主機提供兩個 IP 位址來達成此一目標。VM 虛擬主機中可以看到一個 IP 位址在指定承租用戶的虛擬子網路環境中。遵循 IEEE 命名規則，我們將此稱為 CA (Customer Address)。其它 IP 位址在雲端資料中心內的實體網路環境中相關，稱為 PA (Provider Address)。這為承租用戶和資料中心帶來 IP 位址抽離的許多優點。
第一項優點是可以將VM 虛擬主機遷移到雲端環境上，而且無須修改VM 虛擬主機的網路組態設定或擔心資料中心內的其它問題，您的服務可以繼續運作。在本文最後引用的展示影片中，我們使用 traceroute（一種底層網路診斷工具）來說明本機服務如何與已經遷移到雲端環境的服務透明的溝通。我們強調的是當服務遷移到雲端環境之後，資料封包便可以利用一個額外的Hop 點到達雲端資料中心。虛擬子網路成為近乎透明、擴充的企業資料中心。我們還為虛擬子網路建立了安全加密的通道。簡單來說，連接到同一台虛擬交換機中即使是完全相同 IP 位址的不同客戶們其 VM 虛擬主機被互相隔離了。

想像一下上圖中紅色 VM 虛擬主機的 IP 位址為 10.1.1.7，而藍色 VM 虛擬主機的 IP 位址也是 10.1.1.7。在此範例當中，10.1.1.7 其 IP 位址是 CA IP 位址。透過為這些VM 虛擬主機分配不同的 PA IP 位址（例如 Blue PA = 192.168.1.10 和 Red PA = 192.168.1.11），因此並不存在路由分歧的問題。我們透過原則將紅色VM 虛擬主機局限於僅與其它紅色 VM 虛擬主機進行溝通，同樣的使藍色 VM 虛擬主機局限於與藍色虛擬網路進行溝通。紅色 VM 虛擬主機和藍色 VM 虛擬主機的 CA 雖然均為 10.1.1.7，但是它們可以在同一台 Hyper-V 虛擬交換機和同一個雲端資料中心中安全的共存。
第二項優點是終端主機中執行原則為多承租用戶隔離提供可擴充的解決方案。我們不需要重新組態設定網路基礎設施便可以使承租用戶互相隔離。在 Hyper-V 網路虛擬化之前，一般的解決方案是採用 VLAN 來達成隔離效果。但是 VLAN 具有可擴充性上的限制，在共用資料中心中僅支持有限數量的承租用戶。除了具有可擴充性限制之外，VLAN 比較適合於靜態網路拓撲，而不適合於動態環境上，也就是說承租用戶可能持續加入和離開雲端資料中心，或者承租用戶工作負載可能持續在實體伺服器上互相遷移，以達成負載平衡或容錯目的。在每次需要將VM 虛擬主機導入至新的伺服器時，VLAN 需要重新組態設定核心交換機。通常來說，VM 虛擬主機部署團隊為網路操作團隊建立重新組態設定具有相關 VLAN 標籤相對應交換機的服務 Token。減少了此一組態設定步驟，Hyper-V 網路虛擬化上的 VM 虛擬主機提高運作資料中心的總體營運效率。
第三項優點是允許在遷移至雲端環境時保留原有 IP 位址，Hyper-V 網路虛擬化達成了跨越子網路的即時遷移。當我們談論到即時遷移時，我們的意思是指任何與服務通訊的用戶端並不知道代管該服務的VM 虛擬主機已經從一台實體主機遷移到不同的實體主機。以前無法達成跨越子網路即時遷移，原因在於，按照定義來說如果將 VM 虛擬主機從一個子網路遷移到不同的子網路時，其 IP 位址必須要更改以符合路由環境。但是更改 IP 位址將會導致服務中斷。如果一台 VM 虛擬主機具有二個 IP 位址，則資料中心環境當中相關的 IP 位址（實體位址）便可以更改，但是並不需要更改 VM 虛擬主機的 IP 位址（客戶們位址）。因此，透過 CA 與 VM 虛擬主機溝通的用戶端並不知道 VM 虛擬主機已經實體的遷移到不同的子網路中。
真正令人興奮的是，跨越子網路即時遷移達成了全新的應用情境。回想我們的“任何服務、任何伺服器、任何雲端環境”理念。VM 虛擬主機如今可以在資料中心內在任何地方運作和即時遷移，而且不會導致服務中斷。新的資料中心效率終於可以如願以償。例如對於主機代管服務供應商來說，在輕負載期間（例如凌晨 3 點），可以將線上運作中的 VM 虛擬主機集中整合到資料中心的子網路後，關閉資料中心內其它閒置主機－所有這一切都不必重新組態設定實體網路拓撲。管理人員也不再需要擔心因為資料中心的實體 IP 位址因為被限制地理位置而使一台VM 虛擬主機陷入資料中心的某一部分。同樣的，VM 虛擬主機部署演算法可以更自由的在資料中心內任何地方分配 VM 虛擬主機，因為更改實體資料中心環境中相關的 PA 位址，與虛擬網路中相關的 CA 位址並不相關。
對於 Hyper-V 網路虛擬化來說，VM 虛擬主機完全不知道其 IP 位址已經被虛擬化。從 VM 虛擬主機的角度來看，所有通訊均透過 CA IP 位址進行。由於VM 虛擬主機並不知道它們屬於虛擬網路的一部分，因此，在 Hyper-V VM 虛擬主機中運作的任何作業系統（例如 Windows Server 2008 R2、Windows Server 2003、 Linux …等）都可以是虛擬網路的成員。Hyper-V 網路虛擬化對於客戶們的作業系統來說完全透明。

針對子網路上的 IP 位址虛擬化的二種機制
客戶們可以使用IP 虛擬化機制而不需要升級任何硬體，或者更改目前資料中心內的網路拓撲以部署 Hyper-V 網路虛擬化。我們透過在不同的終端主機之間傳送網路通訊時使用 PA 來達成 CA IP 位址的虛擬化。我們使用二種不同的機制來虛擬化 IP 位址： GRE(Generic Routing Encapsulation) 和 IP Rewrite。對於大多數網路環境來說，建議使用 GRE 機制進行網路虛擬化，因為它具有最大的靈活性和效能。但是，在目前的某些高容量資料中心內 IP Rewrite機制可能比較適合，以便提高運作效能和相容性。
在來源和目標 VM 虛擬主機監控程序當中，資料封包與虛擬子網路 ID 互相關聯。虛擬子網路 ID 允許 VM 虛擬主機監控程序區分可能共用相同 CA IP 位址的不同虛擬子網路流量（例如區分紅色 VM 10.1.1.7 和藍色 VM 10.1.1.7）。VM 虛擬主機監控程序可以使用虛擬子網路 ID 應用在每個承租用戶的原則 (例如存取控制)。
第一種 IP 虛擬化機制是 GRE(Generic Routing Encapsulation)，這是一種 IETF 標準。在此情況下，我們將 VM 虛擬主機的資料封包（使用 CA IP 位址）封裝在另一個資料封包當中（使用 PA IP 位址）。這個新資料封包的 Header 還包含虛擬子網路 ID 的副本。GRE 的優點在於，資料封包中包括虛擬子網路 ID，網路設備可以對資料封包套用每個承租用戶的原則，達成有效的流量計算、流量調整和入侵偵測。GRE 的另一個優點在於，虛擬子網路 ID 可用於將各種 IP 位址與不同的虛擬子網路區分開來，位於指定終端主機上的所有 VM 虛擬主機可以共用相同的 PA。共用 PA 對於可擴充性具有重大影響。網路基礎設施需要知悉的 IP 和 MAC 位址的數量可以大大減少。例如如果每個終端主機的 VM 虛擬主機平均數量是 20，則網路基礎設施需要知悉 IP 和 MAC 位址數量減少 20 倍。GRE 目前的不足之處在於，NIC Offloads機制不再為終端主機提供可擴充性好處，因為 NIC Offloads機制對外部 Header 發生作用，不會對內部 Header 發生作用。Offloads 機制對於 VM 虛擬主機需要 10 Gbps頻寬的高效能環境非常重要。同樣，資料中心多路徑路由減小，原因在於交換機透過位於外部資料封包中的欄位，將不會區分來自位於同一終端主機上不同VM 虛擬主機的流量。
別擔心！！我們擁有針對這些限制的解決方案。
在 Windows Server “8 (2012)”當中我們已經採用具備控制高優先順序的標準。我們與業界主要領導廠商（Arista、Broadcom、Dell、Emulex、HP、Intel）發佈指導性的草案 RFC (NVGRE)，討論使用現有的 IETF 標準 GRE 作為網路虛擬化的封裝協定。我們與伺服器、交換機和 NIC 合作夥伴一起，展開對 Hyper-V 網路虛擬化的生態系統支援。在我們的合作夥伴將 NVGRE 納入產品之後，主機代管服務提供者將在沒有效能損失的情況下獲得 GRE 可擴充性的好處。他們還見證部署多承租用戶網路設備的機會，其中包括負載平衡設備、防火牆、儲存控制器、網路監控和分析工具，以及其它安全和效能產品。
GRE 是適��大多數目前和未來資料中心網路虛擬化首選方法。對於這些環境 Windows Server “8 (2012)”支援第二種 IP 虛擬化機制 ( IP Rewrite)。
透過 IP Rewrite 我們在資料封包離開終端主機時，用相對應的 PA 位址改寫資料封包中來源和目標 CA IP 位址。同樣的，當虛擬子網路資料封包進入終端主機時，用相對應的 CA 位址改寫 PA IP 位址。IP Rewrite的一個主要優點是不需要更改資料封包格式。現有的網路硬體卸載技術，例如 LSO (Large Send Offload) 和 VMQ(Virtual Machine Queue) 可以繼續運作。這些卸載機制為 10 Gbps 乙太網路環境中的應用情境帶來了許多好處。此外，IP Rewrite完全相容於現有的網路設備，它並不會檢查任何新的流量類型或格式。當然，虛擬子網路 ID 並不會在網路上傳輸，因此現有的網路設備無法為每個承租用戶的資料封包進行處理。
逐漸建立混合雲的方法
透過 Hyper-V 網路虛擬化，我們使子網路遷移到雲端環境上變得輕鬆。但是，一旦遷移到雲端環境中，接下來要做的是讓虛擬子網路之間互相溝通。例如典型的 3-Tier 式架構包括 Front End Tier、Business Logic Tier、Database Tier。您需要一種適合這些虛擬子網路進行通訊的方法，使它們如同位於您自己的資料中心一樣。Hyper-V 網路虛擬化允許您在虛擬子網路之間路由。也就是說，不但可以將虛擬子網路引入雲端環境當中，而且還可以將整個網路拓撲引入雲端環境中。
Windows Server “8 (2012)”還提供一種 Cloud Cross-Premise 連接解決方案，這種解決方案可以將您的資料中心或私有雲與公有雲互相連接以便建立混合雲。將 Hyper-V 網路虛擬化與 Cloud Cross-Premise 連接互相結合，表示我們使雲端成為資料中心的無縫式擴充。
在 Microsoft 內部我們使用 GRE 作為 IP 虛擬化機制，在私有雲部署時採用 Hyper-V 網路虛擬化。這裡的承租用戶是伺服器和 STB(Server and Tools Business unit) 中的各個產品群組。我們希望對資料中心基礎設施進行整合，以便達成雲端環境的營運效率和資源效率，並為我們的產品群組提供在雲端環境中部署服務時所需的必要靈活性。

結語
我們對 Hyper-V 網路虛擬化感到興奮不已，因為它使遷移到私有雲、混合雲、公有雲的客戶們大為受益；為運作雲端資料中心的主機代管服務供應商和管理人員帶來新的效率體驗；並且為我們的生態系統合作夥伴提供了新的機會。Hyper-V 網路虛擬化與 Storage Live Migration、Simultaneous Live Migration、Failover Replication…等其它技術互相結合，透過 Windows Server “8 (2012)”達成了VM 虛擬主機的完全移動性。
要瞭解有關 Hyper-V 網路虛擬化的更多內容，請收看我們在 //BUILD/ 大會上提供的展示影片。我們的展示在 13 分 52 秒開始。我們在 //BUILD 影片中討論：使用 Hyper-V 網路虛擬化建構安全、可擴充性的多承租用戶雲端環境提供更詳細的技術資訊。有關部署方面詳細的資訊歡迎瀏覽 Technet 網站。

簡介 Windows Server 2012 動態存取控制

a-talin — Fri, 24 Aug 2012 02:58:00 GMT

一直以來，我們都致力於減少您完成各種任務所需要的操作步驟。Windows Server 2012 之所以能夠成為一個出色的伺服器版本，其中一個重要的理由就是我們花費了大量時間聽取使用者們的意見反應，瞭解他們的使用情境和需求重點。如果從技術/功能的角度來建構各個開發團隊，那麼團隊之間的合作將會變得非常困難，因為幫助其他團隊通常表示必須放下自己手頭上的工作。因為我們在使用者需求及營運情境上達成的共識，各個團隊很樂意互相合作並且提供幫助，所以能夠達成高水準的技術整合和跨團隊合作。當各個團隊朝向一個共同的目標攜手前進時，整個局面便發生翻天覆地的變化，各種難題都迎刃而解。今天的部落格文章就向您展示我們在這方面所取得的成就。
在資訊安全或資料存取安全領域稍有涉獵的人都會瞭解這樣的一個事實，就是傳統的安全模型和機制並不具備足夠的靈活性，無法滿足目前所面臨的問題和情境。無論是滿足法規性要求，降低資料外洩對企業產生的影響，或是管理超大型規模的資料，目前的存取控制機制都有待改進，以便管理人員和使用者能夠更加輕鬆的解決這些難題。Windows Server 2012 的動態存取控制功能由多個團隊所合作開發。我相信您將會發現，與 Windows Server 2012 包含的許多其他功能一樣，該功能對您來說正好是雪中送炭。
如果您尚未下載測試版本，請先閱讀本部落格文章內容並且觀看相關影片，之後根據自己的行程安排該測試版本的下載和試用。
本部落格文章由檔案伺服器團隊的專案經理 Nir Ben-Zvi 所撰寫。

–Cheers！ Jeffrey

大家好! 我是 Nir Ben-Zvi，在 Windows Server 團隊中任職。今天，我將懷著激動的心情向大家介紹新的「動態存取控制(Dynamic Access Control)」功能集合。
我將會深入淺出的為您介紹整體的規劃流程，討論新的集中存取原則模型，並且描述 Windows Server 2012 中內建的 End-to-End 檔案伺服器解決方案。我還將介紹我們所採用的增量部署模型，您無需將整個運作環境遷移到 Windows Server 2012 便可以使用該功能集合。此外，我還將會談到在這個領域方面與合作夥伴的合作內容。
您可以在 TechNet網站觀看有關動態存取控制的相關影片。

簡介
在目前日益複雜的 IT 環境當中，資料在分佈的系統上以驚人的速度產生，並且透過五花八門的設備進行存取。因此，滿足相關法規和標準的法規性要求，並且防止關鍵的營運資料和個人資料的外洩，成為企業和 IT 部門面臨的主要難題。控制使用者的資訊存取權限並產生針對特定資訊的存取記錄報告，對於達成資料法規性和洩露防護非常重要。
這也正是我們在數年前開始規劃 Windows Server 2012 時所觀察到的情況。在規劃期間，使用者意見反應當中頻繁出現的要點如下：

· 根據營運及法規性需要，集中管理對資訊的存取行為。

· 對於資訊的存取需要經過審核，以滿足法規性要求以及用於分析。

· 敏感資訊應該始終要獲得保護。

· 內容擁有人應該對自己的資訊負起責任，IT 管理人員不應該事必躬親。

· 確保資訊工作者的工作效率對於企業來說非常重要。

之後，我們也針對企業不同崗位上的工作人員展開相關調查，瞭解他們如何參與滿足資料法規性監管和營運要求工作，以便提供適當的技術和解決方案以組合説明解決資料法規性的難題。
最初牽涉其中的是負責確定營運及監管法規性需求的 CSO/CIO 管理階層人員。接下來，負責管理系統的 IT 管理人員和控制實際資訊的企業擁有者也加入此一行列。最後，企業希望盡可能降低對資訊工作人員的影響（最好都沒有影響）。

為了説明企業達成資料法規性，我們最後決定將著重點集中在以下項目：

· 確定滿足營運及法規性要求所需管理的資訊。

· 採用適當的資訊存取原則。

· 審核對資訊的存取行為。

· 加密資訊。

接著我們將這些重點項目轉換為一系列 Windows 功能，以便透過合作夥伴和針對 Windows 解決方案提供資料法規性功能。

· 增加在 Active Directory 中設定集中存取和稽核原則的功能。針對條件運算式的原則將考慮以下因素，以便幫助企業將營運需求轉換為高效率的原則執行，並且大幅度減少存取控制所需要的安全群組：

o 使用者的身份。

o 他們正在使用的設備。

o 正在存取的資料。

· 整合至 Windows 身份驗證 (Kerberos)，這樣使用者及設備不僅可以透過安全群組，同時還將透過描述例如：“使用者來自財務部門”和“使用者的安全等級為高”。

· 改進檔案分類基礎結構，允許企業擁有者和使用者標示（加標籤）其資料，以便 IT 管理人員能夠根據標籤分配原則。此功能可以根據內容以及其他特徵自動分類檔案，並且與檔案分類基礎結構結合使用。

· 整合授權管理服務 (Rights Management Services)，以便自動保護（加密）伺服器上的敏感性資料，如此一來即使資訊離開伺服器後也仍將獲得保護。

集中存取原則
您可以將集中存取原則視為企業在伺服器中部署的安全網路。這些安全網路原則可以強化（而非取代）應用於資訊的本地端存取原則（例如自由選擇的 ACL）。如果針對某個檔案的本地端 DACL 允許特定使用者存取該檔案，但集中原則限制同一使用者的存取，則該使用者將無法存取該檔案（反之亦然）。
部署和實施集中存取原則的原因各式各樣，並且可能來自企業的多個層級：

· 法規原則：本原則與法規性和營運要求互相關聯，在於保護對受管制資訊的正當存取原則。例如僅允許特定群組的使用者存取受到“US-EU Safe Harbor”法規保護的資訊。

· 部門授權原則：企業中每個部門都需要施行某些特殊的資料處理要求。這種情況在分散式企業中極為常見。例如財務部門希望僅允許財務人員存取財務資訊。

· 需知原則：本原則為針對原則來允許存取。例如：

o 供應商應僅能夠存取和編輯屬於自己所參與的專案其相關的檔案。

o 資訊隔離對於金融機構非常重要，它們需要確保分析師和經紀人彼此無法存取對方的資訊。

集中稽核原則
集中稽核原則是幫助企業保持安全性的利器。監管法規是安全審核的主要目標之一。SOX、HIPPA、PCI 等業界標準需要企業遵守與資訊安全和隱私相關的一系列嚴格的規則。安全審核可以幫助確認此類原則的存在（或缺點），並且證明對這些標準的法規（或違規）。此外，安全審核可以幫助檢測出異常行為，找出並且彌補安全性原則中的漏洞，同時透過建立用於取證使用者行為記錄來阻止不負責任的行為。
Windows Server 2012 允許管理人員使用運算式建立稽核原則，考慮使用者正在存取的資訊和使用者的身份，以方便企業針對任意位置駐留的特定資訊執行審核。這將使制訂內容更加豐富、更具針對性且易於管理的稽核原則成為可能。這些情境在此之前全部都難以達成或者根本無法達成。例如您現在可以輕鬆建立如下所示的稽核原則：

· 審核所有不具備高安全性，卻嘗試存取“高敏感性”資訊的使用者。

· 審核所有嘗試存取其並未參與專案的相關檔案其合作廠商。

這將有助於調整稽核事件的數量並且將範圍限制在具備相關性的資訊/使用者身上，以便您可以同時監控多台伺服器的資訊存取情況，同時不會產生難以管理的巨量稽核事件。
此外，稽核事件中還會記錄資訊標籤，以便事件收集機制提供相關報告：過去三個月內存取“高度敏性”資訊的所有使用者。

檔案伺服器解決方案
針對此一基礎結構，我們為 Windows Server 2012 Active Directory、Windows Server 2012 檔案伺服器和 Windows 8 使用者端建構了一整套針對 Windows 的 End-to-End 解決方案。該解決方案功能包括：

· 透過自動和手動檔案分類 識別資料。

· 透過應用安全網路集中存取原則，控制跨越檔案伺服器的檔案存取行為。例如您可以控制哪些使用者可以存取企業當中的健康資訊。

· 透過用於法規報告��取證分析的集中稽核原則對檔案伺服器上的檔案進行 存取稽核。例如，您可以找出在過去三個月內存取過高敏感性資訊的使用者。

· 透過自動對敏感的Microsoft Office 檔案應用授權管理服務(RMS)資料加密。例如您可以將 RMS 設定為加密所有包含健康保險攜帶和責任法案 (HIPAA) 資訊的檔案。

為了支援跨企業的多台檔案伺服器進行部署，我們還提供了支援跨多個伺服器進行配置和報告的資料分類工具包。

增量部署概念
增量部署是動態存取控制的核心設計原則之一。採用此一原則是為了確保您能夠儘快開始使用該功能集合，以解決有關資訊存取和稽核的目標營運問題。
籍由 Windows Server 2012 檔案伺服器和升級的 Active Directory 網域架構，您可以充分利用大部分動態存取控制功能。只需增加最少數量的 Windows Server 2012 網域控制站，即可達成 User Claims 等功能。您對系統各部分進行的升級都將為您提供更多功能，但您可以根據自己的情況來設定升級頻率。

合作夥伴解決方案
合作夥伴解決方案和營運應用程式可以進一步利用針對動態存取控制的 Windows 基礎架構，為使用 Active Directory 網域功能的企業創造出巨大的附加價值。我們去年在 //build/ 大會上展示過一些合作夥伴解決方案包括：

· 整合針對內容自動分類的資料外洩防護 (DLP)。

· 集中稽核分析作業。

· 透過集中存取原則進行授權管理服務(RMS)。

· 其它眾多解決方案…等。

一些可能對您有所幫助的其他資源：

l TechNet 技術文件庫 – Dynamic Access Control Scenario Overview

l Windows Sever 2012 Virtual Labs – Using Dynamic Access Control to Automatically and Centrally Secure Data

l Channel 9 – Dynamic Access Control Demo and Interview

Nir Ben-Zvi

Windows Server 2012 最終發佈時間

a-talin — Fri, 24 Aug 2012 02:48:00 GMT

在 7 月份時 Microsoft 在加拿大多倫多召開為期一周的全球合作夥伴會議。即將正式發佈的 Windows Server 2012 理所當然的成為本次會議中的焦點。事實上，我們在本次會議上宣佈 Windows Server 2012 的發佈日期定在 8 月份的第一周。產品的開發工作即將完成。我們即將把產品提供給我們的硬體合作夥伴。從 2012 年 9 月份開始，全世界的消費者將能透過多種管道獲得該產品。

Windows Server 2012 Pre-Release版本已經被使用者和合作夥伴們下載超過五十萬次，此一數字超過 Microsoft 以往其他伺服器產品。我們真心希望能夠早一點將最後版本送到您的手中！

在本次會議上，Microsoft 還公佈了 Windows 8 的發佈時間。相關資訊請參考 Windows 部落格。

– Cheers！Jeffrey

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

a-talin — Fri, 24 Aug 2012 02:44:00 GMT

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

開放式管理基礎架構

a-talin — Fri, 24 Aug 2012 02:38:29 GMT

很多年以前，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 連絡

Windows Server“8 (2012)”– 將伺服器應用程式儲存至 Windows 檔案共用中

a-talin — Fri, 24 Aug 2012 02:34:39 GMT

在開發 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)”主要課程列表：

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

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

體驗 Windows Server“8 (2012)”的管理功能

a-talin — Fri, 17 Aug 2012 07:54:00 GMT

大家好！我是 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)” Beta：Hyper-V 和縱向擴充 (Scale-Up) VM 虛擬主機 Part 2

a-talin — Fri, 17 Aug 2012 07:45:55 GMT

今天的部落格文章是為 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)

Windows Server “8 (2012)” Beta：Hyper-V 和垂直擴充 VM 虛擬主機器 Part 1

a-talin — Fri, 17 Aug 2012 07:40:21 GMT

Microsoft 最吸引我的地方在於對使用者們的需求極度重視。在加入 Microsoft 之前，我大部分的職業生涯都投入在 Microsoft 競爭對手工作當中。Microsoft 針對某個市場發佈新產品時，有時候會立即搶佔市場有時則不會。我們則故意無視於他們新產品的優勢，以能夠挑出他們產品的缺陷而感到高興，為我們在某些方面超越他們也感到歡欣鼓舞。就在 Microsoft 尚未推出 Hyper-V 3.0 之前，我們仍舊訂定出售股票權值的時程。但是我低估了 Microsoft 對於使用者們的關心程度，以及他們不遺餘力的滿足使用者一切需求的勇氣，正是這些品質吸引我加入這個團隊。Hyper-V 一直是一項出色的虛擬化技術，十分受到使用者們歡迎，但是我們仍然有些後續工作要做。我們一直堅持聆聽使用者的聲音不斷進行改良。Windows Server“8 (2012)”採用的虛擬化技術是 Hyper-V 3.0，我相信您一定會喜歡它。

Hyper-V 3.0 有一個龐大而全面的功能列表，我們將會發佈一系列部落格文章專門來進行探討。今天我們先將一篇分為二個部分的部落格文章開始，重點探討 Hyper-V 功能的其中一個方面，也就是它對於「垂直擴充 (Scale-Up) 」VM 虛擬主機的支援。單純從支援程度來看的確引人注意（支援 32顆邏輯處理器、1TB RAM、64 TB 虛擬硬碟），但是正如 Jeff Woolsey 將在本篇部落格文章中所展示的那樣，提高運作效能並非只是增大這些支援程度數字而以。Jeff 將會介紹 Hyper-V 3.0 中所支援的 Guest NUMA（Non-Uniform Memory Access）機制。過去，NUMA 機制作為一種新潮的技術但是僅用於高檔伺服器主機上，但是現在幾乎所有伺服器都已經採用這種技術，因此提供相對應的支援也變得十分重要。今天看來似乎很新潮和進階的技術到了明天就變成了常見和必備的技術了。許多工作負載（例如 SQL Server）都利用 NUMA 機制來提高可擴充性和效能。

在看到我們的 Hyper-V 3.0 垂直擴充數字和支援 Guest NUMA 機制時，您可能會認為這些功能特色遠超過您目前所需。但是最重要的是有了 Hyper-V 3.0，您就再也不用擔心有哪些工作負載是可以虛擬化的而哪些不能。Hyper-V 3.0 將使您能夠輕鬆虛擬化所有類型的工作負載，還能夠滿足未來可能出現新的資源要求。建議您下載 Beta 版本親自體驗它的強大功能。

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

虛擬化粉絲們，大家好！

首先，Windows Server 團隊成員對你們表示衷心的感謝。

自從幾周前發佈 Windows Server“8 (2012)”Beta 以來，來自世界各地的意見反應如潮水般湧來，Windows Server 中的所有技術以壓倒性的優勢贏得全球使用者的一致好評。對此，我們感到激動萬分，同時以謙卑的態度接受這些讚賞。

再次感謝您。

我們來談談垂直擴充 (Scale-Up)
在 Windows Server“8 (2012)”的開發過程當中，其中一個核心目標便是建立最優秀的雲端平台。無論是部署在小型、中型、企業級還是超大代管雲端基礎架構中，我們都希望能幫助您對營運進行雲端優化。建立最好雲端平台其中一個方面便是採用 Windows Server Hyper-V 去代管大部分的工作負載。今天，籍由 Windows Server 2008 (2012) R2 Hyper-V，我們可以輕鬆幫助您虛擬化大部分的工作負載，但是同時我們也意識到您希望虛擬化更大型的工作負載，這些工作負載可能需要數十顆核心和數百 GB 的記憶體，並且很可能連接 SAN 且具備極高的網路 I/O 要求。

Windows Server“8 (2012)”Hyper-V 正是針對這類工作負載而設計的!!

擴充並非只是增加虛擬處理器數量而以
我經常聽到有關詢問 Hyper-V 的問題是：“Hyper-V 何時能支援 4 顆以上的虛擬處理器？我需要此功能來處理 VM 虛擬主機垂直擴充工作負載。”儘管可以了解客戶們為何會有此疑問，但是這仍然只是個表面問題，沒有全面的看待這個問題的根本。讓我們回到虛擬化層面，討論一下使用實體伺服器的應用情境。

假設您部署一台具有 8 顆 CPU 的全新實體伺服器，每顆 CPU共有 10 個採用對稱式多執行緒 (SMT) 技術的核心，因此共有 160 個邏輯處理器 (8 x 10 x 2)，但是該台伺服器所配備的記憶體僅為 1 GB。在 1 GB 記憶體的限制下，邏輯處理器的運算能力就變得無關緊要，因為在記憶體不足的情況下根本無法充分利用運算資源。因此，您必須要增加 512 GB 記憶體來解決記憶體瓶頸問題。

但是，如果伺服器只配備了 2 Port 速度為 1 Gb/E 網路卡時，您仍然會受到網路 I/O 的限制。因此，您必須又新增了 4 片單 Port 的 10 Gb/E 網路介面卡來解決網路 I/O 瓶頸。然而，您的系統只配備了少數幾顆硬碟，因此又出現了另一個效能瓶頸…

因此問題的根本顯而易見!!

提高效能和達成擴充的關鍵在於「平衡」。您需要以整體的角度來看待整個系統。您需要兼顧運算能力、記憶體、網路和儲存 I/O…等，並且一次解決所有問題。增加虛擬處理器並不一定能夠提升整體效能或達成擴充的目的。

在研究建立大型 VM 虛擬主機時，我們著重於整體要求，希望提供效能卓越的垂直擴充VM 虛擬主機。目前，我們將重點放在 CPU 與記憶體之間的重要關係。這就表示我們需要探討一下NUMA (Non-Uniform Memory Access）機制。在討論 Hyper-V 和垂直擴充VM 虛擬主機之前，我們先來看一下實體伺服器上的 NUMA 機制。

NUMA (Non-Uniform Memory Access）
什麼是 NUMA？ NUMA 在設計上已經突破了傳統對稱式多處理程序 (SMP，Symmetric MultiProcessing) 結構的可擴充性限制。傳統的 SMP 機制中所有記憶體的存取動作都會傳遞到同一個共用記憶體匯流排，每顆處理器對於記憶體及 I/O 都具有相同的存取權限。（順道一提，在大約 10 年前時 NUMA 機制並不常見，但是隨著多 CPU 多核心系統的興起，NUMA 機制目前也已經得到了廣泛的應用。）在 CPU 數量相對較少時，傳統 SMP 可以滿足需求，但是當多個運算資源爭奪而對共用記憶體匯流排進行存取時，便很快會出現問題。當執行緒多達幾十個甚至數百個時，情況將會變得更糟…

NUMA 設計為透過將運算資源和記憶體分組到不同的節點來解決此一瓶頸。然後透過記憶體一致的匯流排連接到每個節點。與目前運作的 CPU Processors 位於同一個 NUMA 節點的記憶體稱為本地端記憶體，而任何不屬於目前正在運作的Processors所在節點其記憶體則被視為遠端記憶體。之所以稱之為 Non-Uniform，是因為處理器存取本地端記憶體時會比存取遠端節點記憶體來得更快。下圖為一個包含四個 NUMA 節點的系統簡單範例。圖中展示了一個最佳 NUMA 組態設定。之所以為最佳的原因包括：
     1. 系統達成平衡。每個 NUMA 節點都配有相同大小的記憶體空間。
     2. CPU 和記憶體分配在同一個 NUMA 節點中運作。

最佳 NUMA 組態設定

接著我們用一個並非最佳的 NUMA 組態設定來進行比較。下圖中展示了一個非最佳的 NUMA 組態設定，而它不是最佳的組態設定其原因在於：
     1. 系統不平衡。每個 NUMA 節點的記憶體數量及空間並不相同。
     2. NUMA 節點 2 的記憶體數量為奇數，這表示即使系統有能力使用記憶體交錯，也很可能無法達成，因為記憶體並非成對進行安裝。（另外還取決於主機板的特色要求：成對、三個一組…等。）
     3. NUMA 節點 2 和 3 的本地端記憶體空間不足，對於節點來說一部分記憶體存取是本地端，而另一部分則是遠端。這將會導致不一致、非線性的效能。
     4. NUMA 節點 4 並沒有本地端記憶體，因此所有記憶體存取均是遠端。這是最糟糕的情況。

非最佳 NUMA 組態設定

SQL Server 如何使用 NUMA
正如您在上述範例中所看到的一樣，運算和記憶體資源的不斷增加是一把二面刃。一方面，工作負載有了更多可用資源，但是另外一方面，作業系統和應用程式必須管理額外的複雜性來達成一致的擴充和更高的效能。根據這些獨特要求，垂直擴充工作負載都逐漸發展為“ NUMA 感知機制 (NUMA aware)”。Microsoft SQL Server 就是一個很好的範例。從 SQL Server 2005 開始，SQL Server 就能夠辨識 NUMA 機制，並充分利用 NUMA 機制的優勢。此篇 MSDN 文章提供了深入的介紹。

SQL Server 對於排程器程式進行分組，以根據 Windows 所顯示的硬體 NUMA 邊界將這些排程器程式對應到 CPU 的分組上。例如 16 個邏輯運算單元有 4 個 NUMA 節點，每個節點有 4 個 CPU。這使得在節點上處理運算任務時，該組排程器程式具有更多的本地端記憶體。使用 SQL Server，您將可以進一步與硬體 NUMA 節點關聯的 CPU 細分為多個 CPU 節點。這稱之為 Soft NUMA。通常，您將會細分 CPU 以跨 CPU 節點對工作進行分區。有關軟體 NUMA 的詳細資訊，請參考 MSDN – 了解NUMA (Non-Uniform Memory Access）。

當特定硬體 NUMA 節點上運作的執行緒分配記憶體時，SQL Server 的記憶體管理器將會嘗試從與 NUMA 節點關聯的記憶體中分配記憶體空間以進行本地端使用。同樣的，緩衝區將會跨硬體 NUMA 節點進行分佈。執行緒從分配到本地端記憶體的緩衝區存取記憶體，會比從外部記憶體進行存取的效率來得更高。有關詳細資訊，請參考使用 NUMA 放大和縮小緩衝集區。

每個 NUMA 節點（硬體 NUMA 或軟體 NUMA）都有一個用於處理網路 I/O 的相關 I/O 完成埠。這有助於跨多個埠分佈網路 I/O 處理。當某個用戶端連接到 SQL Server 時，將會繫結到其中一個節點。此用戶端的所有批次處理請求都將會在該節點上處理。每次在 NUMA 環境中啟動 SQL Server Instance 時，SQL 錯誤日誌都會包含說明 NUMA 組態設定的相關資訊。

周遊 NUMA 節點和遠端記憶體
您也許想知道：“周遊 NUMA 節點會對效能產生多大影響？”對此並沒有確定的答案，因為這是由許多不同因素來決定的。其中包括：
     1. 系統是否平衡？如果從一開始系統就組態設定不佳而且是不平衡的狀態，那麼任何軟體都沒有辦法來力挽狂瀾。（我將此項目列為第一條原因…）
     2. 工作負載能否正確感知 NUMA 機制？例如 SQL Server 可以正確感知 NUMA 機制，也就是說它能夠辨識 NUMA 技術，並且盡可能嘗試在實體伺服器本地端執行 CPU 和記憶體分配。
     3. 實體伺服器是在處理器中整合記憶體控制器的新型伺服器，還是具有前端匯流排 (FSB) 的舊式實體伺服器？如果是後者，而您又需要周遊前端匯流排中的 NUMA Hops，那麼就會嚴重影響效能…

需要記住重要的一點就是建立最佳的垂直擴充系統，您希望盡可能在實體伺服器本地端進行 CPU 和記憶體分配。而達成此一目標的最佳做法就是建置一個平衡的系統。這是對實體伺服器上 NUMA 機制的大致說明。現在我們將 NUMA 感知機制加入至 Hyper-V 技術中。首先，我們來簡單討論一下早期的 Hyper-V 版本。

Windows Server 2008 R2 SP1 Hyper-V 及早期版本的 NUMA 機制
在 Windows Server“8 (2012)”之前的版本中，Hyper-V 的 NUMA 感知能力是「從主機角度」來看的。也就是說 VM 虛擬主機監控程序會盡可能在實體伺服器本地端分配記憶體和 CPU 資源。預設情況下，Hyper-V 資源設定為此模式，也就是通常用戶端的工作負載會受到記憶體效能限制，而不是原始運算能力。將一個VM 虛擬主機完全部署在一個 NUMA 節點上，可以使該VM 虛擬主機的記憶體全部為本地端記憶體（假設可以按這種方式分配），進而達到最佳的整體記憶體效能。

下圖為一個簡單範例。在該範例中，假設我們有一台具備 4 顆虛擬處理器的VM 虛擬主機，其平均 CPU 使用率在 75% 以上。在 Windows Server 2008 R2 或 Windows Server 2008 R2 SP1 中，如果我們建立了一個具有 4 顆虛擬處理器的VM 虛擬主機，Hyper-V 將執行以下操作：

Windows Server 2008 /2008 R2 中具有 4 顆虛擬處理器的VM 虛擬主機

如上圖所示，Hyper-V 建立一台 VM 虛擬主機，並在一個 NUMA 節點中以最佳方式分配資源。所有 CPU 和記憶體分配動作都在本地端完成。下面的範例則與上圖的配置形成強烈的對比：

非最佳排程調度範例（與 Hyper-V 所執行的操作不同…）

上圖所示的組態設定需要執行大量周遊 NUMA 節點的動作。

從 VM 虛擬主機 的角度來說，Hyper-V 並不會在VM 虛擬主機內部提供 NUMA 拓撲。VM 虛擬主機中的拓撲看起來是一個全部記憶體均為本地端記憶體的 NUMA 節點，而不考慮實體拓撲是何種情況。在實際應用中，缺少 NUMA 拓撲對於 Windows Server 2008 R2 SP1 Hyper-V 及早期版本來說並不會是個問題，因為在單台VM 虛擬主機中可以建立的最大虛擬處理器數量為 4 顆，最大可以分配記憶體為 64 GB。這兩方面都適合現有的實體 NUMA 節點，因此為VM 虛擬主機提供合理的 NUMA 分配到目前為止都不是問題。

可擴充性的宗旨
在我們深入探討此版本 Hyper-V 帶來了哪些變化之前，先來看看有關可擴充性的主要宗旨：

>> 增加核心數量應該可以提高效能。<<

我相信這聽起來是顯而易見的事，您也一定是充滿這樣的期望才購買了多核心伺服器；然而，在某些情況下，增加核心數量可能會限制甚至降低效能，因為同步記憶體所需的代價超出額外核心所帶來的優點。下列我將透過二個範例來說明我的觀點：

假設您在 32 顆 CPU 伺服器主機 (應該所費不貲 $$$$) 上部署了工作負載，結果發現：
     • 在範例 A 當中：工作負載效能等同於 8 顆 CPU 的水準？
     • 在範例 B 當中：工作負載效能在 8 顆 CPU 時達到最高值，但更多 CPU 時卻反而下降？

您是否對大型垂直擴充系統的投資回報率感到失望？我也有同感!!

我想您心中「真正期望」的情況應該是盡可能達成接近線性的擴充，如下所示：

我們期望籍由此版本的 Hyper-V 擴充VM 虛擬主機支援程度，並且建立具有 12、16、24、32 顆虛擬處理器的VM 虛擬主機，我們知道情況必須得到改善。由於每台 VM 虛擬主機的虛擬處理器數量超出了 NUMA 節點中的實體處理器數量，單獨的主機端 NUMA 無法使我們將硬體使用率提升到最高。最重要的是，我們希望確保 Guest OS工作負載能夠得到最佳資訊，進而以最高效率的方式運作，並且與 Hyper-V 協同運作以提供最佳的可擴充性。因此，我們需要在VM 虛擬主機中啟用 NUMA 感知機制。

Windows 8 (2012) Hyper-V：VM 虛擬主機 NUMA 感知機制
透過此版本的 Hyper-V 虛擬化技術，我們為VM 虛擬主機導入了 NUMA 感知機制。使虛擬處理器和虛擬記憶體能自動分組到各個虛擬 NUMA 節點當中，而 VM 虛擬主機則根據運算和記憶體資源的基礎實體拓撲情況，為 Guest OS 提供虛擬拓撲。Hyper-V 採用 ACPI SRAT (Static Resource Affinity Table) 機制，向所有處理器和記憶體的實體位置提供拓撲資訊。（使用 ACPI SRAT 機制提供 NUMA 拓撲是一種業界標準，這表示 Linux 和其他可以感知 NUMA 機制的作業系統，也可以利用 Hyper-V Guest NUMA 機制。）

籍由 Guest NUMA 感知機制，Guest OS 工作負載便可以使用 NUMA 資訊並且根據該資料進行自我優化行為。這表示 Hyper-V 將與 Guest OS協同運作，在虛擬資源和實體資源之間建立最好、最佳的對映，進而使應用程式能夠以最高效率的方式執行、最佳的運作效能和符合線性的擴充。此外，Hyper-V 還必須為不同實體 NUMA 拓撲一起在系統之間，進行遷移的 Guest NUMA 拓撲提供精細的組態設定控制。而要提供跨越各種不同 NUMA 拓撲的可攜性，則管理者必須要確保虛擬拓撲可以對映到VM 虛擬主機，並且即將遷移到所有目的地 VM 虛擬主機的實體拓撲。

以整體角度來看，具備兩個中高負載（使用率 75% 以上）的VM 虛擬主機時情況如下：

正如您所看到的：
     • VM 虛擬主機 1 其 vNUMA 節點 A 和 B 對應實體 NUMA 節點 1 和 2
     • VM 虛擬主機 2 其 vNUMA 節點 A 和 B 對應實體 NUMA 節點 3 和 4

Guest NUMA 感知機制設定範例
在本範例中實體系統組態為： 1 顆 CPU並含有 8 個核心及 16 GB 記憶體。當我建立新的VM 虛擬主機時，Hyper-V 會存取基礎拓撲並且建立一個如以下方式組態設定 NUMA 的VM 虛擬主機：
     • 每個 NUMA 節點的最大處理器數量 = 8
     • 每個 NUMA 節點的最大記憶體 = 13,730 （此數值為總記憶體減去 Root 保留的記憶體後得出）
     • 每顆CPU上允許的最大 NUMA 節點數 = 1

組態設定的資訊如下：

這是對此實體系統而言最佳的 Guest NUMA 拓撲設定。此時您應該會感到疑惑，這不是表示我們把系統複雜化了嗎？我是不是需要開始計算所有伺服器中的核心、記憶體插槽數量？

答案是否定的。這裡有一點非常重要：

>> 預設情況下，Hyper-V 會自動執行正確的操作。<<

建立VM 虛擬主機時，Hyper-V 存取基礎實體拓撲，並且將根據許多不同因素自動組態設定 Guest NUMA 拓撲，這些因素包括：
     • 每顆實體CPU的邏輯處理器數量（每個邏輯處理器指的是一個 Core 或 Thread）
     • 每個節點的記憶體大小

此外，我們還提供了適用於不太常見情況的進階組態設定選項。這些進階設定可以幫助您在具有不同 NUMA 拓撲的硬體之間移動VM 虛擬主機。儘管這種情況並不常見，但是我們希望透過提供這些進階功能，能夠為使用者們提供他們所需的最大靈活度。在下一篇部落格文章當中，我們將介紹根據使用者意見反應，將 Windows Server 8 Developer Preview 推進為 Windows Server“8”Beta 所進行的改善。

歡迎步入雲端作業系統基礎架構的時代！

a-talin — Fri, 17 Aug 2012 06:44:29 GMT

大家好，我是 Jeffrey Snover。如果您未能參加於 6 月 11 日在奧蘭多所舉行的活動，Satya Nadella 總裁 (Server & Tools Business) 展開 2012 年北美技術教育大會序幕，此次活動的主旨為關於 Microsoft 公司對於啟用雲端服務作業系統的新時代願景的主題演講。我們鼓勵大家到此處針對 Server & Tools 部落格瞭解更多內容。請不要忘記閱讀追蹤 RSS 或將這部落格加到我的最愛當中，以即時瞭解最新 Server & Tools 方面的新聞和資訊。

希望您會喜歡！

伺服器與雲端平台團隊

參加於 6 月 11 日在美國佛羅里達州奧蘭多所舉行的北美技術教育大會，與會者正在耐心的等待 Satya 的主題演講。

SQL Server 2012 好文比賽得獎公布

a-talin — Thu, 16 Aug 2012 05:35:50 GMT

http://blogs.technet.com/b/technet_taiwan/archive/2012/07/24/sql-server.aspx

各位熱血的技術人大家好 ,

感謝6位熱血的 IT Pro 參加本次 SQLServer 2012 好文比賽，經由評審評選，

得獎名單如下:

優質大獎 TechDays 2012 門票的得主是 Chen Rico , 感謝 Chen Rico熱血的分享 .

另外5位熱血的IT Pro 分別是 TERRY CHUANG , Rainmaker , James Fu , 葉子 , Dean Ya ，將獲得 TechDays 2012 大會紀念包包與SQL Server 2012 書籍2本。

請以上6位的得獎者，立即與 TechNet 信箱聯絡，大會紀年包包將與9/24寄出，SQL 書籍將會在您來信後，3個工作天後寄出。

再次感謝這6位熱血的IT Pro參加這次的好文比賽，提供這6位的文章給後續的朋友學習參考 .

Chen Rico: (評審註解: 不但有前言介紹、完整的流程步驟，還有後續的經驗分享)

[SQL
SERVER][Denali]SQL Server 2012 – Upgrading to SQL Server 2012

[SQL
SERVER][Denali]SQL Server 2012 – Installing and managing SQL Server 2012 on Windows
Server Core

[SQL
SERVER][Denali]SQL Server 2012: AlwaysOn Availability Groups

TERRY CHUANG: (評審註解:按部就班的完整文章)

SQL
Server Virtual Labs 系列 - SQL Server 2012 Working with Contained Databases
(SQL 145)

SQL
Server Virtual Labs 系列 - SQL Server 2012 What's new in Manageability (SQL
147)

SQL
Server Virtual Labs 系列 - Creating a Report with Report Builder 3.0 (SQL
115)

James Fu: (評審註解: James Fu寫的經驗分享，真的很讚)

[SQL][VirtualLab]SQL
2012 新語法

[SQL][VirtualLab]SQL
2012 AlwaysOn 安裝練習

[SQL][VirtualLab]SQL
Server 2012 Install/Upgrade

Rainmaker:

[SQL]SQL
Server 2012 – Security and Compliance (SQL 150)

[SQL]Upgrading
to SQL Server 2012 (SQL 151)

[SQL]SQL
Server 2012 – What’s new in T-SQL (SQL 152)

葉子：

【SQL
Server好文分享】SQL
Server 2012 – What’s new in Manageability (SQL 147)

【SQL
Server好文分享】SQL
Server 2012 – Installation and Configuration (SQL 149)

【SQL
Server好文分享】SQL
Server 2012 – Security and Compliance (SQL 150)

DeanYa:

[SQL 2012 Virtual Lab] 利用 Excel 2010 來建立
PowerPivot 模型及報表

[SQL 2012 Virtual Lab] 運用 DAX 的計算功能來設計在
Excel 2010 PowerPivot 報表

[SQL 2012 Virtual Lab] 在 SharePoint 2010 上使用
Power View

Windows server 2012 (Hyper-V 3) 好文比賽得獎公布

a-talin — Fri, 10 Aug 2012 09:28:46 GMT

http://technet.microsoft.com/zh-tw/jj572394

大家好 ,

感謝3位熱血的 IT Pro 參加本次 Windows Server 2012 好文比賽，經由評審評選，

得獎名單如下:

優質大獎 TechDays 2012 門票的得主是 Jerry_IT , 感謝 Jerry_IT 熱血的分享 .

另外2位熱血的IT Pro 分別是 Weithenn 及亂馬克將有 TechDays 2012 大會紀念包包與Windows Server 學習資源書籍，

感謝這3位熱血的IT Pro參加這次的好文比賽，提供這3位的文章給後續的朋友學習參考 .

Jerry : (雖然排版有點複雜，但內容很扎實 )

Windows
Server 2012 (Hyper-V 3) 好文分享之Getting Started
with Hyper-V Replication(上)

Windows
Server 2012 (Hyper-V 3) 好文分享之Introduction to
iSCSI Diskless Boot Deployment

Windows
Server 2012 (Hyper-V 3) 好文分享之Introduction to
IIS 8

Weithenn:

Windows
Server 2012 Virtual Labs 實作筆記設定 Windows Server 2012 啟動 Hyper-V Replication 機制

設定 Hyper-V 使用高可用性 SMB 儲存空間

設定 Windows Server 2012 採用 Boot From SAN 啟動

亂馬克

[IIS]Introduction
to IIS 8

Introduction
To Windows PowerShell Fundamentals

What's
New in Windows PowerShell 3.0

Bing.com 已採用 Windows Server 2012 進行運作！

a-talin — Fri, 10 Aug 2012 03:38:46 GMT

一直以來 Microsoft 都在網際網路上運作多樣服務，但是就在幾年前情況發生轉變，也是我們 CEO Steve Ballmer 的至理名言“公司目前正在孤注一擲。雲端運算! 我們需要來一同來面對。”我們應該要同舟共濟，朝著同一個方向努力，並透過互相學習的方式來傳遞最佳的雲端產品。我們正從目前 Windows Azure 雲端服務中總結相關管理經驗，並且將其融入到我們的產品當中進行改進。在我們規劃及研發 Windows Server 2012 期間，我們在雲端服務上花費了大量的時間，以瞭解雲端服務中的相關的優點及缺點為何。當您以我們的規模運作服務時，任何一個小問題都將會被無限放大，因此每一次的改進都有著極大的效益。我們將這些經驗轉變成您目前看到的許多功能，這些功能包括自動化機制、支援資料中心拓撲架構、高可用性、最小化平均故障檢測時間 (MTTD)/平均故障復原時間 (MTTR)…等。在今天的部落格文章當中，Bing 團隊的軟體開發工程師 Mukul Sabharwal，將會討論 Windows Server 2012 的一些功能以及對 Bing 服務的影響，同時說明為何 Bing 正在以最快的速度進行應用和部署 Windows Server 2012。正如您所看到的，Windows Server 2012 是真正針對雲端環境所優化的作業系統。
Cheers !

Jeffrey

在公佈最新 Windows Server 2012 RC版本時，Bing.com 團隊同時也考慮要如何才能應用並受惠於該作業系統的相關新功能。Bing.com為遍及全球各地資料中心，並且運作在成千上萬台電腦主機上的雲端服務。效能對於 Bing 雲端服務來說非常關鍵。Bing 每秒鐘要為數千個使用者查詢請求提供服務，而使用者則要求查詢結果的準確性和回應速度。
我們在部署 Windows Server 2012 時利用四種關鍵的新功能，包括：

內建於 Windows Server 2012 中的 Microsoft .NET Framework 4.5，包括後台垃圾回收機制和相關延遲時間改善功能
改善並加快啟動時的效能反應 (在 .NET 4.5 中啟用多核心 JIT 功能)
針對由 .NET 即時編譯的 64 位元應用程式收集及堆疊功能
評估 Hyper-V 3.0（Window Server 2012 中 Hyper-V 版本）

預先安裝 .NET Framework 4.5
我們的 Rendering Tier 完全透過代管程式碼 (Managed Code) 進行運作，其依賴於 .NET Framework 和 Web 框架 ASP.NET 以及 ASP.NET MVC 的功能。我們撰寫代管程式碼的主要原因之一在於 CLR 可以提高開發人員的工作效率並且保障運作時的安全性。但是這些功能也會產生效能上的成本，例如垃圾收集 GC (Garbage Collection)。

伺服器後台垃圾回收
.NET 4.5 導入了伺服器應用程式後台垃圾回收機制。後台垃圾回收機制在 .NET 4 中發佈，該功能主要為用戶端應用程式，並且曾經風靡一時也正因如此，我們對於 Windows Server 2012 能夠將其導入到伺服器中而感到興奮不已。當然，看到這種結果我們也十分高興！
下列 InternalRequestLatency 圖表中顯示，我們的應用程式在執行非 I/O 任務時所花費的時間。（如您所知，我們的設定目標為讓第 99 th 變得更快。）

在下列的圖表當中，請注意大部分效益都源至於減少處理所建立代管記憶體 (Managed Memory) 的時間，而這是為了建立垃圾收集 GC (Garbage Collection) 請求服務的重要項目。（請注意! 日期與本部落格文章中的所有圖表都已經進行了相關處理。）

另一種最佳效能計算方式及 ASP.NET 應用程式伺服器健康狀況的指標，就是在 ASP.NET 中佇列的請求數量 (如下圖所示)。請注意 5 月 25 日時曲線的急速下滑！

升級至 Windows Server 2012 將為您的代管應用程式 (Managed Application) 帶來同樣的影響。縮短垃圾收集時間之後，表示將有更多的時間為使用者請求提供服務。因此將有效縮短延遲時間並且改善服務的處理能力。

採用多核心 JIT 進行編譯
在 Windows Server 2012 中透過 .NET 4.5 實作出的另一重要功能，便是使用多核心進行 JIT 編譯的動作。該功能為一種依照組態設定進行優化的方法，也就是在後台執行緒 (Background Thread) 編譯執行動作中執行緒可能請求的方法，在理想情況下應用程式會在需要運作時早已經完成 JIT 編譯的動作。
ASP.NET 應用程式預設便已經啟用此功能，因此只需讓您的 ASP.NET 應用程式自動獲得多核心 JIT 編譯機制，便可以立即提升整體運作效能。
您可能會納悶：為什麼啟動時間對於伺服器端的應用程式來說非常重要？因為使用者希望的是，在必要時才需要重新啟動服務，並且希望可以自行選擇時間 (避開尖峰時間) 來完成此一動作。但是，如果您的應用程式不幸發生當機的情況時該怎麼辦？
因此啟動時間的長短對於服務的高可用性來說非常重要。當服務發生中斷的情況後進行快速復原時，此時您便可以體驗到啟動時間長短的差異性有多重要了。那麼您可能會接著問，啟動時間是否真正縮短了？從下列圖表中可以看到啟動時間整整縮短了 50%，並且在服務中斷時重新復原的速度也提高了將近一倍！

針對營運伺服器上的應用程式進行採樣分析

Windows Server 2012 中另一項新增功能，便是透過 JIT 編譯 64 位元 .NET 應用程式收集及堆疊功能。

我們將效能計數器作為我們的主要監控機制，同時也是傳送給管理人員通知中的第一行內容。它們不僅涉及到我們在本文中所討論的問題（垃圾收集時間和 ASP.NET 佇列請求），而且還會涉及其他重要問題，例如 CPU 佔用時間百分比和異常數量。
效能計數器對於檢測效能發生下降時極為重要，因為它會將深入檢查操作任務的健康狀況。但是，它們通常不足以診斷效能問題的“根本原因”。因此我們假設效能計數器數值飆升。例如 CPU 佔用時間百分比增加一倍進而對延遲時間產生影響。接下來我們該怎麼做？就 Windows Server 2012 來說，我們的下一步便是啟用低資源消耗的採樣分析機制 (Sample-Based Profiling)。
Windows Server 2012 當中透過 JIT 編譯 64 位元 .NET 應用程式收集及��疊功能，.Net 應用程式透過 Windows 事件追蹤 (ETW，Event Tracing for Windows) 系統來完成。如果您熟悉事件追蹤系統，便會瞭解這是一種系統範圍內的服務，不會要求需要重新開機；因此它不具入侵性（也就是說不會附加到某個執行程序）、根據您所訂閱的事件、低資源消耗：在採樣分析機制運作時僅產生約 10% 的 CPU 資源成本。

CPU 佔用時間百分比的上升趨勢僅由 80% 上升至 90%。這將轉變為幾乎等同於百分比的延遲效能降低，如下圖所示。

當診斷效能問題的“根本發生原因”變得非常重要時，10% 的效能降低是可以接受的。
我們已經在本文當中討論了採樣分析機制，但是此功能還能擴充至其他類型的事件追蹤系統，包括 Context Switch 事件和 ReadyThread 事件。例如您不僅可以分析佔用大量 CPU 使用率的問題，而且可以嘗試解決由 I/O 或 Thread-Scheduling 所產生的問題。（請注意! 啟用 Context Switch 分析機制的資源消耗成本將高於採樣分析機制，在我們的應用程式當中對 CPU 產生約 30% 的效能影響。）
有時，僅會出現在正式環境中才會重複出現的問題，而這些問題可以在大規模範圍內產生影響。能夠採用低資源消耗的日誌分析工具是種非常巨大的優勢，就 Windows Server 2012 來說，代管的應用程式現在可以獲得與本機應用程式相同的原生支援。
（請注意! 當 Windows Server 2008 導入可在採樣分析設定檔 ETW 事件中獲得堆疊功能時，對於已經由 JIT 編譯器編譯過的 64 位元應用程式是無效的。）

Hyper-V 3 和支援 Guest NUMA 機制
在 Windows Server 2012 推出之前，採用虛擬化技術就表示會有額外的資源成本，即使考慮到它所帶來的全部效益情況依然如此。整體來說，虛擬化之後所產生的間接軟體成本讓人無法接受。此外，在我們的綜合實驗室測試中虛擬 CPU 的數量限制（最多 4 個）也成為了 VM 虛擬主機運算能力的瓶頸。
但是在 Windows Server 2012 中的 Hyper-V 3.0 功能，具備大幅度的“擴充 (Scale)”能力。其中我們對於支援 Guest NUMA 機制感到格外興奮。感知 NUMA 拓撲功能對於記憶體智慧分配機制來說非常重要，最小化跨節點的記憶體存取往往是加速應用程式的關鍵環節。
籍由全新 Windows Server 2012 所整合的 Guest OS 支援 NUMA 機制，我們正在對使用 Hyper-V 3.0 進行重新評估。我們預計 Hyper-V 將能夠滿足我們對於效能的要求，同時又能節省大量的成本。

雲端業務和雲端優化作業系統
Bing.com 已經透過使用公開的 RC 版本切換到 Windows Server 2012 中得到了明顯的改善。我們基本上可以將 CPU 佔用時間百分比降低一半，以為代管應用程式（包括垃圾收集）和減少重新啟動服務時的啟動時間提供關鍵服務。透過簡化過程監控並將其內建於作業系統中，並且我們已經在效能方面得到明顯的提升。我們還在探索如何將 NUMA 效率與 Hyper-V 3.0 互相結合，以虛擬化技術增強我們的服務。Bing.com 是公認成功的大型規模企業雲端服務，這充分說明我們如何將 Windows Server 2012 建構成一種真正的雲端優化作業系統。
Bing.com 是雲端服務。該雲端服務十分快速，它運作於成千上萬台電腦上，跨越全球範圍內大量的資料中心。目前，該雲端服務已經透過 Windows Server 2012 得到優化。

總結
全新的 Windows Server 2012 功能使 Bing.com 團隊在考慮遷移到最新作業系統時，對 Windows Server 2012 作業系統興趣十足。從初期快速遷移影響性的評估到真正的全面部署，這樣的發展過程為 .NET 4.5 功能、多核心 JIT 功能提供了巨大的效益，並且效能大幅改進的 Hyper-V 3.0 功能同樣獲得極大的效益。
現在您已經瞭解這些 Bing.com的內部優化運作機制，最後請不要忘記以下內容：全球範圍內所有 Bing.com 搜索結果現在都由 Windows Server 2012 提供服務！

內建的 .NET 4.5（包含於 Windows Server 2012 當中），包括後台垃圾回收和延遲改善功能。
透過 .NET 4.5 的多核心 JIT 功能啟用，達成啟動效能的改進。
針對由 .NET 即時編譯的 64 位元應用程式收集調用堆疊功能。
Hyper-V 3.0 在未來上的部署應用。

Windows Server 2012 RC版本發佈並提供下載

a-talin — Fri, 10 Aug 2012 03:35:07 GMT

好消息! 在前往最後版本的雲端優化作業系統道路上，我們又到達另一個重要的里程碑：Windows Server 2012 RC (Release Candidate) 版本目前已經提供下載。

如果您尚未探索新版 Windows Server 的眾多功能，那麼此一 RC 版本便是您開始探索之旅的大好時機。截至目前為止 Beta 版本已被下載約 30 萬次，使用者對於全新設計的 Windows Server 感到前所未有的驚喜。我強烈建議您加入遍及全球的 IT 專業人士和開發人員社群，因為他們早已經熟悉 Windows Server 2012 並且開始利用該作業系統所提供的最新功能。在此先感謝您把握這一次的最後機會來積極參與及評估，並且向我們提出寶貴意見和建議，以便使我們可以為您提供最出色的版本。

如果您還沒有瀏覽本部落格系列文章，那麼我建議您開始對網站中相關文章進行全面的瀏覽。它是您瞭解這一全新 Server 版本的最佳途徑，您不僅可以直接瞭解該系統研發過程中的技術背景，並且可以獲得 Microsoft部落格中豐富內容的連結。我在下方為您提供了從 3 月 1 日宣佈 Beta 版本以來所發佈的部落格文章列表。

我們期待著在奧蘭多和阿姆斯特丹定於 6 月舉行的技術大會上，您可以在離您最近地區的社群巡迴演說活動中，能夠一睹 Windows Server 2012 的風采。

-謹啟！

Jeffrey

Windows Server 2012、PowerShell 3.0、DevOps，Part 2…

Windows Server 2012、PowerShell 3.0、DevOps，Part 1…

宣佈 Windows Server 2012社群巡迴演說

簡介 Windows Server 2012 動態存取控制

透過使用者意見反應改善伺服器的可管理性：使用者體驗計畫如何改善進而使 Windows Server 2012 成為 IT 專業人士的利器

Windows Server 2012 遠端桌面服務 (RDS)

簡介伺服器、雲端合作夥伴、使用者解決方案團隊部落格

使用 Windows Server 2012 和 System Center 2012 SP1 建置雲端架構

SMB 2.2 升級為 SMB 3.0

簡介 Windows Server “8” Hyper-V 網路虛擬化：在雲端中啟用快速遷移和工作負載隔離

Windows Server “8” Beta：Hyper-V 和垂直擴充 VM 虛擬主機，Part 2…

Windows Server “8” Beta：Hyper-V 和垂直擴充 VM 虛擬主機，Part 1…

Windows Server “8” 標準化管理

Microsoft 線上備份服務

使用 Windows Server “8” Server Core 建構優化的私有雲

Windows Server “8” 管理新體驗

先前的 Windows Server “8”部落格文章何處尋

傾聽使用者與合作夥伴的心聲

a-talin — Fri, 10 Aug 2012 03:29:59 GMT

大家好，我是傑佛瑞（Jeffrey）。10月18 日 Windows伺服器和雲端生態系統合作夥伴，以及顧客生態系統團隊項目經理Natalia Mackevicius，說明我們為向使用者和合作夥伴所收集建立Windows Server 2012的重要意見所付出的努力。這對於讀者來說是一篇很值得閱讀的部落格文章：

相信大多數使用者都已經聽說過這樣一個活動，在活動現場中我們聽到使用者說 “Windows 7 正是我的理想選擇”。嗯! Windows Server 8 (2012) 將會繼續保持及傳承 Windows 7 的設計理念，成為一個名副其實的使用者真正認同的理想解決方案。

正如Bill Laing在“Windows Server 8 簡介（Windows Server 8 Introduction）”這一篇部落格文章中所提到的，傾聽使用者和合作夥伴（我們的“生態系統”）的意見及建議，是我們Windows Server產品戰略中不可或缺的一部分。我們在“顧客心聲(Voice of Customers)”活動中投入大量的資源，從市場調查 26,000多名使用者和合作夥伴，到舉辦 200多場生態系統會議（"ecosystem" meeting），並且收集了6,000多個創意想法。使得我們能從單純的產品功能開發進化至端點到端點的IT應用情境。這些是使我們新一代作業系統能夠擁有強大功能的基礎。我們為Windows Server 8 (2012) 所設定的目標是提供真正需要的功能，以改善管理人員每天在企業中實際所需的功能體驗，而不是僅僅發佈一大串功能清單。

作為“Windows Server使用者與合作夥伴生態系統”團隊的領導者，我有幸在產品計畫週期初期就密切參與到與使用者和合作夥伴的接觸活動中。我們的方法已經幫助我們改善及增強相關功能，並且擴充及更專注於提供廣泛的功能，這些功能不僅能夠為客戶們解決關鍵的營運問題，更能借助雲端運算來支援使用者的現狀以及未來的發展。

使用者告訴我們類似如下的想法：

· “我希望伺服器能夠跨越伺服器叢集進行無縫式的擴充作業，也就是說這些伺服器可以按照需求來進行增加或移除。”

· “我希望伺服器能夠具備智慧型的自我監控作業，以便即時發現需要檢查和發送告警的問題。”

· “我需要在能不中斷服務為前提的情況之下，能夠動態式的調整或分配硬體資源。”

· “我希望擁有一個真正的可攜式操作環境，使它能夠跟著我從一台設備無縫式的遷移到另一台設備上。”

當我們從200多場使用者與合作夥伴會議，以及更廣泛的市場研究調查中獲取並整合相關意見反應時，我們清楚瞭解到您正在尋找更有效率更經濟的方式和模組化的能力，以幫助您橫跨自己的私有雲環境，並且安全的連接到外部公有雲服務。您需要熟練管理基礎架構以便將執行時間最大化、故障時間最小化。您所建置的平台應該是開放式且具備擴充性以支援跨平台的應用程式。您也需要一種支援靈活移動的工作方式，也就是無論一名企業員工身處於何處，都可以授予其對資料適當的存取權限。瞭解不同市場、區域或地域其每個領域中如何發揮將是一件非常具有價值的事情。同樣的，合作夥伴協助將理想轉換為現實，在這方面他們也發揮了舉足輕重的作用。

回顧我們的方法

我們有賴於龐大的團隊努力工作以及我們完整的使用者生態系統，才到達產品週期的這個里程碑。下列圖表中展示了我們的方法。

初期規劃（Pre-Planning）是指我們廣泛接觸使用者及合作夥伴，以收集他們對於營運發展方向的構想時期。此階段中也使6,000多個創意想法（類似上述所提到的那些想法）浮現出來，為正式的計畫(Planning) 階段提供了素材。這些便成為我們與使用者及合作夥伴一起共同審核的提要和概念。一旦被驗證，它們就會成為正式的應用情境，而我們對於Windows Server 8 (2012)的構想(Vision)也就此建立。從這裡我們開始與合作夥伴共同努力的協同合作，合作夥伴們將幫助我們完成特定的應用情境，包括高可用性，Hyper-V可擴充式虛擬交換機以及 Claims-Based 存取控制機制。這些合作夥伴們都參與最近的 //build/ 大會，在大會上我們介紹了Windows Server 8 (2012) (請參考 Channel 9 以瀏覽以下合作夥伴的短片： Brocade, DynamicOps, Emulex, Gemalto, InMon, QLogic, Titus, Websense, Broadcom, Cisco, Dell, HP, IBM, Intel, NEC, NetApp)。

當我們進入開發（Development）階段時，這些合作夥伴（還有其他合作夥伴）早已經深入參與其中，以確保Windows Server 8 (2012) 實作出那些在初期規劃中所提出的重要應用情境。不論是在開發驅動程式、硬體元件、核心功能或是其它應用情境的附加功能時，生態系統都是我們真正的合作夥伴，使我們有能力滿足使用者們所提出的要求，同時建立一個能幫助及支援他們走向未來的作業平台。

對於所有 Windows Server 團隊成員來說，讓使用者以及合作夥伴加入產品週期的每個階段是受益匪淺的經驗。我們的最終目標是提供以顧客為中心的 Windows Server 解決方案。來自 //build 大會的意見反應中，我們似乎已經在此軌道上開始前進了，這都要歸功並感謝我們的生態系統。這就是目前和即將要推出的創新合作夥伴計畫和 “顧客心聲” 活動！

Natalia Mackevicius

Group Program Manager

Partner and Customer Ecosystem

TechNet Taiwan 官方部落格

下載試用，寫心得，拿好禮！

Windows Server 2012 實戰影片!!

利用 Windows Server 2012 和 System Center 2012 SP1 建構雲端基礎設施

Windows Server 2012 訊息體驗

Windows Server 2012 RC版本即將發佈

透過顧客意見反應改善伺服器可管理性： 顧客操作體驗改善計畫，如何能夠針對 IT 專業人士改善 Windows Server 2012 產品

Windows Server 2012、Windows PowerShell 3.0、DevOps – Part 2

請立即下載 Windows Server 2012 Essentials 的 Beta 版本！

Windows Server 2012、Windows PowerShell 3.0、DevOps – Part 1

介紹伺服器和雲端合作夥伴以及顧客解決方案團隊部落格

簡介 Windows Server “8 (2012)” Hyper-V 網路虛擬化：在雲端環境中達成快速遷移和工作負載隔離

簡介 Windows Server 2012 動態存取控制

Windows Server 2012 最終發佈時間

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

開放式管理基礎架構

Windows Server“8 (2012)”– 將伺服器應用程式儲存至 Windows 檔案共用中

技術背景

達成新式應用情境

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

體驗 Windows Server“8 (2012)”的管理功能

Windows Server “8 (2012)” Beta：Hyper-V 和縱向擴充 (Scale-Up) VM 虛擬主機 Part 2

Windows Server “8 (2012)” Beta：Hyper-V 和垂直擴充 VM 虛擬主機器 Part 1

歡迎步入雲端作業系統基礎架構的時代！

SQL Server 2012 好文比賽得獎公布

Windows server 2012 (Hyper-V 3) 好文比賽得獎公布

Bing.com 已採用 Windows Server 2012 進行運作！

Windows Server 2012 RC版本發佈並提供下載

傾聽使用者與合作夥伴的心聲

透過顧客意見反應改善伺服器可管理性：顧客操作體驗改善計畫，如何能夠針對 IT 專業人士改善 Windows Server 2012 產品