在上一篇《Windows Server 2012十大最佳特性總結》中，我們分享了對于很多系統管理員為什么要關注微軟Windows Server服務器操作系統家族最新版本的幾個理由，Windows Server 2012有很多不錯的新功能，它改進了Windows早期版本將其從“從未使用的1.0版本”階段帶入到功能與穩定性兼備的階段，并在功能性與穩定性方面與其它主流競爭對手不相上下。

　　Register網站專欄作者Trevor Pott指出：“雖然我在Server 2008 R2的部署工作中投入了大量精力，但出于以上十大理由，我認為Server 2012仍然值得自己再張羅一次升級。就連對預算一向把得很嚴的公司高管這回也一路大開綠燈。”

　　到目前為止，讀者朋友最關注的內容要數PowerShell，而且根據大家的語氣判斷，這算得上是一場混戰。有些人對其不屑一顧，有些人則認為這是微軟能夠拿出的最佳解決方案。出于篇幅的考量，我們盡量對評論原文進行了壓縮，但仍然在最大程度上保留了其語氣及內容。

　　于是我們決定進行一次實驗性嘗試：試圖將幾款熱點文章的讀者評論加以匯總，最終形成一篇新文章。有些朋友可能會把這種做法稱作素材擴展，而從社交媒體的角度則稱之為話題詳述。我們認為盡管有些評論太過偏激，但仍然有不少讀者朋友留下了他們有趣且睿智的見解。好吧，讓我們一起來聽聽讀者的聲音。

　　BuckFutter 表示：

　　沒錯，不過……你沒法把PowerShell 3跟SharePoint 2010同時使用，所以基本上目前的命令行版本在SP2010上完全無用，除非微軟決定再來一次更新。

　　另外，我再補充一項最佳功能——Server 2012能夠在核心、完整以及“最小服務器界面”三套方案之間進行切換。所謂“最小服務器界面”，是指只向用戶提供PS控制臺以及Server Manager界面。再有，我們不僅能把角色及功能刪除掉，更可以真正把它們從系統中清除出去，這對于減小攻擊面意義非凡。雖然我很討厭微軟，但我不得不承認Server 2012是一款偉大的操作系統。不過Metro仍然是最大的敗筆……

　　銅牌用戶K 則以個人名義向微軟發出戰書：

　　微軟此次的努力值得贊賞，但PowerShell仍然速度緩慢、功能有限、說明文檔簡陋不全而且對非微軟出品的應用支持不足。如果能解決這些問題，我會樂于加入到PowerShell用戶的陣營中來。

　　而另一位銅牌用戶 LDS 則對加入GUI的做法提出質疑：

　　Windows的確需要更多腳本化方案來完成任務，但GUI的加入只是在一堆PowerShell腳本之上堆疊起更緩慢、更麻煩的多余機制，而且令錯誤報告更加糟糕——這看起來跟某些蹩腳的Linux應用十分相似。GUI與命令行都應該調用相同的API，這樣無論我們通過哪種方式執行任務，都能保證整個過程以最快、最理想的方式進行。

　　Richard Gadsden 在回復中說：

　　腳本之上的GUI？就像SQL Server Management Studio（簡稱SSMS）所采用的機制？這種方式效果不錯。雖然我個人并不是PowerShell擁護者，但SSMS的表現相當出色。

　　而P Lee則補充道：

　　問題更可能出自微軟內部。他們不希望利用不受信的GUI工具來實現腳本無法完成的工作，所以才強制要求用戶以調用腳本的方式執行任務，而這就造成了處理速度上的損失。但對于企業而言，犧牲一點速度來保障安全還是值得的。

　　銀牌用戶ShelLuser 對于前面提到的十大特性一一做出回應，不過仍然把討論重心放在PowerShell身上，并強調如何最大程度改進用戶體驗。（我們對原文內容進行了刪減）

　　事實上幾乎沒什么優勢……我很好奇作者本人到底有沒有使用過他所提到的這些功能。

　　首先來看PowerShell：從2到3的版本號提升并不能算升級，因為微軟公司發布的根本就是一款沒有完工的產品。真正的出發點倒是不錯：迅速推進組件模塊化，并以此為契機實現差異性。舉例來說，本地系統現在終于能夠通過選項調整使用本地幫助了。

　　由于PowerShell 3目前仍然采用在線幫助庫，因此能夠非常方便地為剛剛更新的部分添加幫助說明，并根據各國用戶的實際需要推出翻譯文檔。

　　只有一個小問題……微軟似乎從未考慮過一旦本地系統（例如nl-NL）只擁有默認（en-US）語言的幫助說明，用戶應該如何是好？

　　更糟糕的是：他們也從未認真對待用戶對于本地幫助或者全局環境的需求。在使用help命令時，我們根本無法選擇語種。

　　僅此一點就徹底毀掉了PowerShell的使用體驗。惟一的善后方式就是由用戶手動復制“本地化目錄”。

　　我們談論的可是微軟，大家真相信他們會僅僅把它留給Server 2012嗎？經過一段時間的觀察、匯總運行錯誤并集中糾正，然后IIS8就會被廣泛應用于其它平臺了。

　　基于其它一些功能（例如Hyper、iSCSI、SMB等），我承認這都是些不錯的項目，但僅靠它們就足以撐起一款全新的服務器系統了嗎？

　　如果某些企業已經開始嘗試Server 2012，我倒也不會感到驚訝，因為他們可能有不得已的理由（例如需要批量更換舊服務器）。但我同樣相信會有不少企業選擇跳過Server 2012，就像他們會跳過Windows 8一樣。在我看來，Metro肯定會在這類選擇中起到很有份量的負面作用。

　　Bainia不是PowerShell的擁護者，因此我們采納了他的發言及其后列出的特別申訴：

　　我真的很難控制自己不去對PowerShell展開一番嘲笑。我努力讓自己放過它，但作為一款由命令行驅動的強大系統，PowerShell的能力實在太過糟糕。

　　一位匿名讀者回答了Bania提出的問題：

　　1、系統啟動需要大量時間。即使是新型硬件配置也需要11秒才能完成啟動過程。

　　在我的設備上Server 2012能夠“瞬間”啟動。只有在系統重啟后首次打開PowerShell時需要等一小會兒，也許你應該檢查一下自己的配置腳本。

　　2、缺乏大量類unix shell基本功能。

　　相反，Unix shell才缺乏“大量”PowerShell所提供的功能。

　　3、在文本處理概念方面不夠考究，所有東西都被視為一個“對象”。

　　說的沒錯。文本僅僅被視為一系列有序的字符串對象。不過你可能根本沒必要在PowerShell中使用強大的字符串功能，因為在進行對象操作時幾乎不需要與其扯上關系。

　　4、表述方式太啰嗦了，最簡單的任務也要寫一大段才能實現。

　　大多數命令都有簡化版指令，只要不怕引起混淆、所有參數名稱也都可以縮短。不要人云亦云地認為代碼描述真是越長越好，PowerShell也能夠像bash那樣簡潔——有些情況下甚至更加簡潔。

　　5、路徑中的斜杠仍然沒有用對。

　　這種說法太無知了。PowerShell中一直允許用戶根據喜好隨意使用斜杠以及反斜杠符號。

　　6、沒有持續命令歷史記錄。

　　保存一下就行了。或者設定退出時自動保存以及初始化后自動載入功能。還有更好的辦法：為實際片段建立一套庫。難道bash就沒有片段問題嗎？

　　始終作用于*sh shell中的風險管理機制哪去了？在PowerShell中我們可以通過-WhatIf運行任何命令。在這種模式下，系統不會受到任何影響。相反，系統會將命令執行后的結果以報告形式提交給用戶。另外，它同樣能作用于腳本：只要我們將-watif作為腳本參數，則“whatif”即成為全局首選項且腳本內容不會真正付諸執行。

　　*sh shell的事務整合哪去了？我們可以通過PowerShell與多臺數據庫服務器、消息隊列服務器等相連，進而在執行事務背景的任務時確保事務一致性。

　　*sh shell的中止與繼續腳本哪去了？PowerShell工作流能夠在一臺設備上對腳本或任務進行重啟及暫停，并在另一臺設備上繼續進行。

　　我們要如何創建并行*sh腳本？PowerShell支持同一工作流腳本中的并行執行功能。

　　未完待續……