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支持同一工作流脚本中的并行执行功能。
