不管你喜欢与否，活动目录（AD）都是Windows Server故障转移群集的重要组成部分，并对其运行的稳定性产生影响。是否经历过可怕的NETLOGON事件，由于无法联系到域控制器（DC），而导致群集无法启动？由于OU权限的限制而无法创建一个群集或虚拟服务器，怎么办？微软已经意识到这些问题以及其它一些常见的AD问题，并在Windows Server 2012中投入了巨大的精力来弥补这些不足。

　　没有域控制器情况下群集的启动

　　对于群集来说，最惨重的事件莫过于建立的过程中无法联系到域控制器 （DC）。另外，当你试图将DC作为虚拟机放在Windows故障转移群集中时，也会导致这种问题。群集在启动时必须要与DC通讯，但此时DC根本没有启动。在Windows Server 2012中，群集与AD之间的这种依赖关系已经得到解决。

　　当你要创建一个Windows Server 2012群集时，需要与DC通讯，并将包括其它群集成员的认证数据存储到AD数据库中，这样才能保证群集正常工作。已经存在的群集可以在不用联系DC进行认证的情况下启动。在Windows Server 2012之前，将AD服务安装在群集的成员服务器上以解决群集在启动时对AD的依赖是受到微软支持的，但微软并不建议这样做。现在，在windows Server 2012中，按照微软的文档KB 281662，在群集节点上运行域控制器将不再受到支持，而且这样做也毫无意义。

　　灵活的OU管理

　　在Windows Server 2012中另一项被点名要解决的AD缺陷就是指定群集成员服务器计算机对象所在组织单位（OU）的能力。过去，当创建群集时，群集名称对象（CNO）所在的OU是默认的计算机OU。这项改进使得管理员不用再对那些以管理故障转移群集为目的OU进行授权，从而避免了那些痛苦的预先设置的工作。

　　在Windows Server 2012中，无论是创建群集向导还是PowerShell cmdlet的“New-Cluster”都允许你指定群集所在的OU。此外，任何高可用性群集角色相关的网络名称的虚拟计算机对象（VCO）也将被创建在同一个OU中。创建群集的用户账户必须在指定的OU具有创建计算机对象的权限。反过来，新创建的CNO必须有创建计算机对象的权限以创建VCOs。你可以在任何时候将这些计算机对象移动到不同的OU而不破坏群集的运行。但请一定记住，自定义OU必须在群集创建之前生成。

　　不幸的是，创建群集向导以及对应的PowerShell cmdlet在指定CNO所在的特定OU时，其语法很不直观。创建群集向导使用特定的语句来指定群集的名称，以及它所在的OU。在下面的示例中，群集的名称是Win2012Clus1，所在域的名称是Winners.com（如图 1），CNO所在的OU为ClusterServers。

图1. 使用群集创建向导为群集计算机对象指定一个自定义的OU