虽然安装仍然很麻烦，但比以前好多了，同时，这也是近年来第一次，SystemCenter的所有模型都进行了同步修改，并且其覆盖面也有所提高。
在SystemCenter2012中，包含了对私有云的控制，虽然其重点更倾向于WindowsAzure—微软的公共云平台;同时，它也支持对虚拟化的控制，尽管其倾向于微软的Hyper-V管理程序，此外，SystemCenter2012还支持CitrixXenServer和VMwareESXi/vSphere中被大量使用(但不是所有)的功能。
SystemsCenter2012的覆盖面还包括大量的其他非Windows设备，例如，你不仅可以使用WindowsPhone，还可以使用苹果的iPad/iPhone的iOS5，或者Android手机(如果它能链接到MicrosoftExchange服务器控制的话)。微软正在试图改变其仅支持Windows的局面，这是我们看到过的微软提供的最平等的覆盖面。虽然扩大覆盖面是好事，但同时，它增加了复杂程度。
我们的评论将分为两部分，第一部分主要关于SC2012的Orchestrator编排器以及SC2012:ConfigurationManager配置管理器。
第二部分则是关于SC2012:ServiceManager服务管理器、AppController、VirtualMachineManager虚拟机管理器和DataProtectionManager数据保护管理器。微软端点保护管理器被排除在外，因为我们没有足够的资源来分析它。
需要什么基础设施
我们需要很多虚拟机形式的硬件，来实现所有模型的完整安装。每个模型至少都需要一个具有40G磁盘和合理内存的服务器/虚拟机实例。在SC2012的模型中，通常是SQLServer2008R2作为引擎。此外，很多模型可能还需要必要的繁重的硬件。
我们不建议在ActiveDirectoryDomain控制器中运行任何模型，因此需要额外的虚拟机实例。
微软想要在企业中发挥主导作用，而我们认为，对于很多以微软为中心的企业而言，SystemCenter如果不那么繁琐的话，可以算是一个很好的选择。
每个模型在安装之前都需要进行规划，如果没有UnifiedInstaller，模型将无法进行安装，这也意味着你需要做一些功课。你要做的功课包括了解每个模型的先决条件(它们都略有不同)，然后部署这些先决条件，例如上述SQLServer，以及在大多数情况下，部署具有不同设置的IIS等。我们发现这是很麻烦的工作。
在完成这些功课后，你就可以使用UnifiedInstaller来安装模型了。
尽管SystemCenter2012组件存在异构性，想都不用想，微软肯定会优先其自己的产品。更有趣的是，它还新增了功能与其竞争对手的高级功能相竞争，同时管理具有竞争性的虚拟化和云基础设施。例如，SystemCenter2012突出了微软Hyper-V基础设施的优势，而SC2012:VirtualMachineManager虚拟机管理器提供对私有云和公共云中的虚拟化实例的管理功能，这个公共云通常意味着，微软的Azure云资源。
通过Hyper-V，VirtualMachineManager虚拟机管理器可以进行裸机安装，这使Windows或者Linux实例(SuSE实例)的管理程序化裸机开始流行。
VirtualMachineManager还可以控制VMwareESX/ESXi实例，但很多VMwarevSphere5中的Vmware功能仍然需要vSphere5。这里的优势在于可以对管理基于Vmware实例中使用的共同任务进行关联控制。XenCenter和Citrix的XenCenter管理同样也是这个道理。
#p#
编排器Orchestrator
微软公司于2009年收购了Opalis—IT流程自动化工具，作为Opalis的升级版，Orchestrator可以算得上是最引人注目的模型了。通过RunbookDesigner，Orchestrator可以让Runbook完成复杂的工作，这些Runbook构成的定制脚本生成器可以深入基础设施内部。
Orchestrator模型必须至少有一台服务器，专门用于构建、管理和部署Runbook，Runbook是指令对象，其包含的指令可以用于资源的广泛分配。
Runbook是工作流指令，现在网上已经有一些runbook可用资源，可以添加到Orchestrator中。Runbook也是脚本，脚本可以进行编辑，以及使用与runbook活动(runbook/脚本将要执行的指令)相符的本地具体变量进行替换。
这些脚本还可以被存储，或者放置到工作流程时间表中，然后它们将被事件触发，例如某个应用程序的逐步安装等。
我们发现我们可以使用Orchestrator来安装SQLServer、建立IIS角色和做出必要修改以让Orchestrator运作，但我们发现时已经为时已晚。
我们可以导入runbook，或者使用RunbookDesigner，来获取对脚本的wysiwyg视图。我们还可以在流程中加入依存性以及资产和资源的具体名称，以让Orchestrator制定和执行一些相当复杂的工作。然后RunbookServer会开始运作，RunbookServer第一个添加的是PrimaryRunbookServer，后续服务器在很大程度上将自主运行。这可以让分支机构或者云环境为安装、升级和其他工作流执行自主运行脚本。
我们对在实验室和网络运营中心的服务器之间执行应用程序安装的几个runbook进行了测试。首先，我们根据简单的用户批量点击数据来对它们进行排列。随后，这些事件将被日志记录(微软警告说日志记录数据库将会变得非常巨大，我们纳闷，他们为什么不使用syslog?)。我们可以通过很多方法来控制runbook执行，这取决于被允许的并行工作数量、执行各部分工作时使用的权限以及可以执行的活动类型(包括定制活动等)。
Orchestrator还包含IntegrationPacks(集成包)，这些集成包是让runbook控制ActiveDirectory以及第三方软件的连接点。目前Orchestrator提供针对惠普iLO/OA服务器管理、惠普OperationsManager软件、惠普服务管理器、IBM的TivoliNetcool/OMNIbus基础设施管理套件以及VmwarevSphere的集成包。由于条件所限，我们并没有对这些进行测试。不过我们对我们非常熟悉的Vmware集成包进行了分析。
Orchestrator模型并没有取代vSphere，但它知道如何自动化很多日常任务。在映射很多vSphere信息(地址、机器名、主机平台信息以及管理程序数据存储信息)后，我们能够将ESXi虚拟机从一台机器转移到另一台，但这需要花费很多功夫。
在Vmware环境，对Orchestrator集成包的控制具有限制，特别是当能够使用vSphere5的决策情报来选择存储和资源管理时。
在Orchestrator能够获取一个API，来悄悄地攫取更多基础设施情报信息来移动虚拟机，从而使ESXi服务器实现负载/存储平衡之前，Orchestrator都无法“享受”vSphere控制机制的重要组成部分---这也是Vmware的秘密武器。尽管如此，Orchestrator对Vmware的集成控制仍然非常具有吸引力。
在一般情况下，Orchestrator部分事件用于执行“正常”事件，而其他时候则在监控日志。在运行Orchestrator之前，我们需要进行很多初步规划。然后，在前期阶段，我们需要“操练”runbook，让runbook完成各种各样的工作，其中某些工作可能并不需要自动化。
SystemsCenter2012:配置管理器
与Orchestrator一样，配置管理器在动手安装之前，也需要规划。配置管理器使用SQLServer2008R2作为其引擎，与Orchestrator一样，它也要位于与ActiveDirectory域控制器不同的实例中。
事实上，如果SQL服务器出现故障时，大部分工作将会被停止，为此，我们可以考虑采用频繁的备份和复制和/或群集。
配置管理器需要至少一台站点服务器和站点数据库实例(它们可以位于同一台机器或者虚拟机实例中)，以及一台组件服务器(也可以与站点或数据库服务器结合在一起)。到目前为止，我们拥有三个可以结合起来的服务器实例，但SQL服务器无法被映射，这让我们很困扰。不过，这里的高可用性很重要。
配置管理器站点包括主要站点和次级站点。次级站点被用作分发点，它们通过站点层级的组播来节约带宽。这同样适用于多分支机构/多地区的站点，在不同地区，语言或者审计/合规技术和报告可能有所不同，这也是大型企业将有必要钻研SystemCenter文档以了解如何部署配置管理器站点的原因之一。
在了解这些注意事项后，我们通过UnifiedInstaller，安装了配置管理器。
站点服务器的作用还包括：作为配置功能的存储点。这意味着存储通过Windows服务器更新服务(WSUS)的Windows更新，或者作为微软的网络访问保护政策执行修改的参照点。
配置管理器对可以应用程序实例、操作系统实例及其许可证进行盘存、部署、审计和维护，但它不能在非windows平台上进行这些工作，这与Orchestrator有所不同。然而，如果你主要使用的是windows系统，配置管理器可以规范应用程序和操作系统实例的部署，同时让工作更加简单。
配置管理器可以应用于设备的生命周期中的几个阶段。首先，Windows操作系统以及应用程序有效载荷被引入裸机中，然后基于windows的配置管理器代理被用于管理该设备(主要通过推拉信息命令)。WindowsMobile6+、SymbianBelle手机、某些windows嵌入式系统版本以及使用ExchangeActiveSyncAPI的移动设备(AppleiOS4+和Android的某些版本)也可以在其生命周期中进行配置和管理。
#p#
部署操作系统
我们发现配置管理器提供了几个很不错的操作系统部署方法，首先，找到一个合适的镜像作为有效载荷，你可以捕捉一个镜像，或者使用转换后的ISO映像。我们建议使用需要驱动器或者适当软件的镜像，这样你就可以一步完成所有工作。
下一步骤是选择分配方法。最常用的是PxE(预启动执行环境)，它使用了Windows部署服务器。事实上，你完全不需要配置管理器，就可以使用PxE。配置管理器的价值在于，它允许创建RemoteInstall文件夹，这样这些镜像就可以进出中央分配点。
我们测试了这个方法，对于Windows7专业版实例的测试是行之有效的。我们使用了WDS，建立了一个Ipv4本地网络，配置了RemoteInstall文件夹和资源有效载荷，完成了WDS配置工作(很简单)，将镜像引导到联想T520测试机中。
让库存合规
软件应用程序、内容和更新都以类似的方式分配，但配置管理器还会通过Collections创建有关库存和状态的信息对象。Collections是用户或设备组(但不是用户和设备组)。数据进行一次收集(或者简单的累计数)或者在时间间隔内进行检查。然而，微软反对在时间间隔内查询“全球”信息，因为这会产生一个巨大的无用事件。通过这个collections，我们可以满足合规要求，合规意味着检查库存对象(也许是应用程序)是否存在，或者通过自定义脚本检查其状态。我们测试了使用内置复选框的基本例子，调用客户端的WindowsInstaller文件存在，在我们的测试中，LenovoT520中安装的是WindowsOffice2010，这更加复杂，还需要部署自定义脚本。
此外，机器可以报告其电源状态，你还可以测试机器的电源设置。
报告要求SQLServer报告，很多库存、合规和一般活动日志的查询是很简单的。我们还可以对数据表进行修改以让事情看起来更完美。从审计的角度来看，审计员会注意到我们导出、操作和重新导入以让表更加清晰，但是你需要有一名知道如何操作的数据库管理员才能完成这项工作。如果我们按照规则来操作，这些报告实际上非常简单易用，通过一些注释，也很简单易懂，即使是首席信息官也能够看懂。
总结
与Orchestrator一样，配置管理器需要大量前期规划，但也可以从简单的水平开始部署。成功的部署将需要投入大量时间、精力和资源。这项工作非常复杂，需要非常深入Windows系统。配置管理器能够帮助中小企业，同时，大型企业也能够利用它的优势。
