對於 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 打造成一款偉大的產品。

在這個分為二部分的系列文章當中第一篇文章，我將會提供有關 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 團隊傑出工程師及首席架構師

您可能不止一次聽到我提起，在規劃 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)”是優化的雲端作業系統，它在組態設定 私有雲、混合雲、公有雲 解決方案方面提供選擇和靈活性。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 之所以能夠成為一個出色的伺服器版本，其中一個重要的理由就是我們花費了大量時間聽取使用者們的意見反應，瞭解他們的使用情境和需求重點。如果從技術/功能 的角度來建構各個開發團隊，那麼團隊之間的合作將會變得非常困難，因為幫助其他團隊通常表示必須放下自己手頭上的工作。因為我們在使用者需求及營運情境上達成的共識，各個團隊很樂意互相合作並且提供幫助，所以能夠達成高水準的技術整合和跨團隊合作。當各個團隊朝向一個共同的目標攜手前進時，整個局面便發生翻天覆地的變化，各種難題都迎刃而解。今天的部落格文章就向您展示我們在這方面所取得的成就。  
在資訊安全或資料存取安全領域稍有涉獵的人都會瞭解這樣的一個事實，就是傳統的安全模型和機制並不具備足夠的靈活性，無法滿足目前所面臨的問題和情境。無論是滿足法規性要求，降低資料外洩對企業產生的影響，或是管理超大型規模的資料，目前的存取控制機制都有待改進，以便管理人員和使用者能夠更加輕鬆的解決這些難題。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