各位朋友可能在WSFC2012上面安装群集角色时经常会碰见网络名称联机失败的问题，导致群集应用没有配置成功，最终应用不会正常对外提供服务，例如SQL Server，DTC，一些时候即便是重装也不能解决，那么到底为什么会产生这个问题，今天我们就来从头分析

The cluster resource ‘SQL Server’ could not be brought online due to an error bringing the dependency resource ‘SQL Network Name ’ online.

提到这个典型错误，如果想彻底理解，就不得不从CNO，VCO讲起，本文老王将把这些概念再串起来讲一次，力图让管理员能够彻底理解

高可用群集的一个最关键特点，就是要持续对外提供服务，因此需要实现一个逻辑对外名称，背后由群集逻辑进行协调，如果当前正在对外提供服务的某节点宕机，自动将用户对逻辑对外名称的访问请求转移至其它活着的节点上提供，让用户始终以为群集应用是活着的

这个逻辑对外名称在微软WSFC体系中实现为客户端访问点，客户端访问点，通常有DNS，CNO，VCO三部分，DNS记录用于客户端访问解析群集及群集应用，CNO用于支持群集连接，群集Kerberos验证，VCO用于帮助特定群集应用实现节点导向

对于一个群集来说，完整的客户端访问点包括群集DNS记录+群集CNO名称，如果仅使用DNS记录，例如工作组群集，多域群集，将不支持Kerberos验证。

对于一个群集应用来说，完整的群集应用访问点，包括应用DNS记录+应用VCO名称，具体采用什么级别的应用访问点，视应用情况而定，例如有的群集应用可以共用群集DNS+群集CNO，则不需要再创建应用访问点，或者仅需要DNS记录，或者创建完整应用访问点，如果群集应用是完整的应用访问点，那么应该是群集应用在身份验证，或者故障转移导向上面有所要求，需要使用单独的计算机对象实现。

  CNO   Cluster Name Object于WSFC 2008被引入

  1.作为群集访问标识的一部分，管理员或应用可以连接到CNO访问群集

  2.负责管理VCO 虚拟机计算机对象的创建，密码同步，VCO DNS记录创建维护。

  3.CNO创建完成VCO后会在VCO ACL里面写入CNO的权限

  4.CNO会被写入特定的SPN，应用程序会通过CNO来和群集完成Kerberos验证

  5.CNO会被创建和VCO之间的关联关系，在群集节点注册表中可以得到查看

  6.误删CNO或VCO对象会导致群集无法正常联机，应用无法和群集进行Kerberos验证

简单看了下概念之后下面我们通过实际案例进一步理解，为什么网络名称无法联机在WSFC 2008时代很少见，而在WSFC 2012经常看到

最关键的答案是CNO对象创建位置原则

在WSFC 2008时代，不论我们的群集节点计算机对象，在那个OU下面，群集CNO对象和VCO对象，都只会被创建在默认Computer容器下，除非我们提前在其它OU下面预置了CNO，VCO对象

如图所示，我已经按照规划把群集计算机节点放置在单独OU下

但是当安装群集的时候，WSFC 2008依然会把CNO VCO放置在默认Computers容器

又因为默认计算机容器每个对象都有权创建计算机对象，因此只要创建群集的账户具备Computers的创建计算机对象 及 读取所有属性权限 ，CNO对象和VCO对象就可以被正常创建出来，即使CNO已移到不同的OU，VCO还是会在默认计算机容器创建

因此，WSFC 2008时代基本上不会碰见网络名称无法联机的问题，网络名称无法联机，该问题通常就是指CNO或VCO对象，无法在AD中被正常创建，权限不足

为什么 WSFC 2012之后经常遇见这个错误，答案就是CNO对象创建位置原则发生了改变

最关键的两点

1. WSFC 2012开始CNO对象将跟随群集计算机对象在同一个OU下创建

2. CNO将跟随VCO对象在同一个OU下创建

规则改变后带来什么影响，好的一面是可以帮助AD计算机对象规范化，不好的一面就是带来了额外的权限授予工作

设想一下，WSFC 2012中，如果我们将群集节点计算机对象移到一个新OU下，那么群集CNO也将在该OU创建

创建CNO的工作由群集安装账户完成，因此需要确保群集安装账户对节点所在OU具备创建计算机对象 及 读取所有属性权限  或直接加入domain admins组

CNO创建完成后，紧接着我们需要在上面跑群集应用，创建VCO，而VCO是由CNO负责创建维护，但是由于不是默认计算机OU，所以CNO对于节点所在OU并没有权限，因此创建VCO过程会失败，进而群集显示网络名称无法联机。

错误呈现如下

解决办法，针对单独规划的群集OU，添加CNO计算机权限 创建计算机对象 及 读取所有属性权限 ，不论是规划好的全新安装，或是先安装好了群集，然后CNO对象和群集计算机对象移到了其它OU，都在当前CNO对象所在OU执行此操作。

权限授予完成后，再次启动群集角色，问题可解，群集应用正常联机

要规避此问题，解决办法有二

1. 不做规划，群集节点计算机就在默认计算机OU下，这样CNO和VCO就可以正常联机，也无需添加CNO权限

2. 通常情况下企业里面计算机对象很多，都放在默认计算机OU下面也不好看，不便于管理，因此老王建议为群集节点创建单独OU是应该的，CNO，VCO对象会被创建在关联的节点OU中也很好，唯独就是安装群集角色时需要单独授予CNO对象对于OU的权限，如果该OU下面会有很多个群集的话，老王建议您可以创建一个CNO计算机对象组，将所有刚安装好的群集CNO对象都自动加入到组里面，然后针对于OU授予CNO组的权限，这样每当创建应用的时候权限都是准备完好的

还有一个问题，群集名称资源在DNS中注册失败，出于以下原因，群集网络名称资源'SQL Network Name（VirutalClusterName）'注册一个或多个关联的DNS名称失败

出现这个问题，是因为CNO对象对于DNS服务器没有权限而导致，因为CNO对象负责维护VCO计算机对象和DNS记录，因此VCO的DNS记录也将由CNO对象去DNS中注册创建，出现这个错误，就是CNO对象对于DNS区域没有权限

手动为CNO添加对DNS区域的 修改权限 创建权限即可，添加完成后，再次脱机联机群集角色，问题可解

小技巧，在WSFC中，如果我们删除群集角色，则该VCO对象会变成禁用，销毁群集，CNO对象会变成禁用，如果我们规划好群集OU，看见禁用的CNO和VCO对象，就可以知道，它们是已经被删除的群集角色或群集，可以直接删除，默认情况下GUI界面销毁群集CNO对象为禁用，如果使用命令Remove-Cluster -CleanupAD销毁，则可以销毁过程直接删除CNO