关于DSC的争论
期望状态配置（DSC，Desired State Configuraiton）是微软的Windows管理框架(WMF)4.0中的一项技术，主要用于声明系统配置。伴随着有些过于简化的风险，DSC需要你创建特定格式的文本文件，用来描述一个系统应当被部署配置成什么样子。然后，你只要把这些文件部署到实际的系统中，它们就会奇迹般地被配置成了它们被描述的那样。从最高层面上来看，DSC不是程序设计，它只是列出了你想要的系统是什么样子。
微软在声明配置及自动化部署的领域确实是有些迟钝的。Linux和Unix世界已经有了类似Chef和Puppet这样的工具，它们长期以来都执行着非常相似的任务。有个重要的事实是DSC不是一个附加品，而是作为Windows系统核心的一部分而存在。然而DSC的工具集还没有像Chef以及Puppet那样成熟，DSC提供了一个基于它v1版本的基本内置实现，它是如此难以置信的强大和可扩展。
DSC是PowerShell的发明者Jeffrey Snover的在他的Monad宣言中的最后一块就已经列出来的，他当时在那里设想了PowerShell自身，PowerShell Remoting，以及一个声明性的配置模块。这份宣言在自2006年PowerShell v1发布以来，已经得到了实现。对于这份宣言的绝大部分内容（你将在这份指导中读到），已经在一种非常友好的交互平台上实现了。PowerShell Remoting，甚至DSC，都是基于开放的第三方标准的。在标准化的基础上，微软可以让其他人关注工具本身，了解那些不一定要专用于Windows，而其他操作系统也可以使用同类技术的工具。
DSC对于那些经常和Windows服务器打交道的人来说非常重要。即使那不是你环境中唯一的操作系统，DSC也是相当重要的，因为它正在逐渐趋向于发展成为管理基于Windows的服务器唯一方式。这里说的口气很大，但它值得你去探索。
顺便说一下，接下来不会讨论Windows比其它系统更好/一样/更差之类的观点。这儿只会讨论Windows本身，不带任何价值评价或者比较。
Windows管理的起源
在最开始的时候，Windows主要由一些图形工具和少量的命令行管理，并直接和本地或者远程的电脑上的服务通信。你点击对话框里的一个按钮，工具就会告诉安全账户管理器（SAM）并且创建一个用户账户。
随着场景的扩大以及IT队伍的小型化，人们需要自动化很多过程。图形化工具天生就很难去自动化。Snover的Monad宣言中的第一阶段是一个提供了一致的用于自动化管理的命令行语言的命令行工具。命令行工具本身就容易实现自动化，因为它们可以被组合成简单的batch或者其他脚本文件。Windows一直没有一种具有一致性并且包罗多面的命令行语句；微软的管理压力变成了忍受尝试让PowerShell变得尽可能包罗多面的这种行动(他们仍然在投入建设这一块)。计划方案尽可能的保持一致（会带来很多好处）。
注意，命令与服务的直接通信很重要。例如，运行New-ADUser，这条指令就直接和一个运行在域控里的服务通信，从而创建这个新的用户。
可扩展是该宣言的下一个阶段。一个命令行自动化语言是不错，但是如果你一定要在你的个人电脑上运行你敲的命令，你在效率上仍然有更高的限制。在标准的通信协议下，把指令并行推到远程电脑端的能力，是我们所需要的PowerShell v2交付了它的Remoting功能。现在，一台电脑一次就可以轻易地告诉一千台其它的电脑做些什么了。Remoting也减少了指令开发者的一些负担。他们现在可以考虑他们的指令是在本地执行，还可以在其他任何电脑上执行他们的技术，以及可以让PowerShell处理网络通信。无需处理通信这一点使指令开发人员能够更加容易地开发更多指令，增加PowerShell的技术覆盖面。
但是管理员仍然可以运行指令，然后指令再与服务通话。所有事情都是必不可少的：电脑做管理员告诉他们去做的事情，或多或少，立刻或者之后。如果环境改变了，管理员不得不建立新的脚本来实现新的改变。管理员必须要回溯到以前，并且确信这项改变被正确的实施，还要持续的检查以确定事物保持在那个状态。如果有东西忘记配置，修正的话就得经常回退，然后人工重新配置。你不能仅仅运行一样的脚本，因为它用于让一个系统从A点变到B点的情况，而不适用于让产生意外之后的A点变到B点的情况。
DSC代表了（Windows）管理的一次具有意义的突破，因为它要求管理员不再与电脑上的服务直接对话。这就意味没有与服务直接对话的图形化工具。它也意味着没有与服务直接对话的既行指令。换言之，DSC不要求管理员一定要自己配置所有东西。
反而，DSC要求管理员用清楚简单的文本文件去描述他们希望一台电脑应该被配置成什么样。而作为电脑，就会读取这个文本文件，并且自己进行相应的配置。这个配置过程是细化的，那样一旦什么东西忘记配置，电脑仍然可以自己修复这一点。
DSC离不开PowerShell，因为是PowerShell给予DSC实现变化的能力。PowerShell是所有微软产品中的一项通用语言（某种程度上，它也在持续改进）。换句话说，没有PowerShell，微软的产品还没有像DSC这样有足够的连贯自动化能力。现在有了DSC，管理员可以对PowerShell投入更少的关注，因为它们可以通过一些不算复杂的层次从其中分离出来。
想象一个图形化工具，你可以通过点击向导在你的环境中添加一个新的用户。这个工具并没有真正地和域控制器通话以创建这个用户账户，或者和一个文件服务器通话来创建它们的Home目录。相反地，这些工具很少修改那些包含针对文件服务器以及域的配置文本。而这些文件服务器以及域控制器会周期性地重读这些文件，并且执行它们描述的内容。因此，你点击一个按钮，几分钟后，这个用户以及它们的home目录就神奇的出现了。这个过程是自动的，但是你无需写任何代码。这些配置文件在在你那作为管理员才能更改。
搭建环境变得更加简单，“嘿，你如果打算成为一个新的域控。那就去看看配置文件DCX34766578348 吧，让你自己变得像它所说的那样。”Duang。。。就完成了。
DSC象征着大量的改变，代表了Windows管理员期望他们的整个环境如何变化。提供的每个配置设置都可以被归结为真正随时间推移的DSC设置，那样“管理（Administration）”将变成对文本文件的适当编辑，这一点显得十分强大。