對於 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 Beta 的顧客操作體驗改善計畫 (CEIP)。我們會透過該計畫請求您允許我們收集有關伺服器運作狀況和使用情況的資料。我們經常收到有關 CEIP 的各種問題，例如“什麼是 CEIP？”和“CEIP 資料將如何使用？”。在本部落格文章當中，Karen 將為您解答這些問題，以及另外一個非常重要的問題： “我為什麼要啟動 CEIP？”

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

–Cheers！ Jeffrey

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 安裝 Windows Feedback Forwarder

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

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

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

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

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

2. 採用 PowerShell

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

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

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

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

2. 部署 Windows Feedback Forwarder 群組原則

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Karen Albrecht  
Windows Server Telemetry專案經理

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

–Cheers！Jeffrey

技術背景

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

達成新式應用情境

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

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

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

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

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

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

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

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

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

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

功能特色概述

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

部署模式

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

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

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

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

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

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

結語

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

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

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

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

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

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