How Windows Server 2012 can solve Windows failover cluster headaches

In Windows Server 2012, Microsoft tried to smooth out some major Active Directory bumps in failover clusters. Did it fix what's bothering you?

Like it or not, Active Directory is a vital component of Windows Failover Clusters and can adversely affect its stability. Have you ever experienced the dreaded NETLOGON event, indicating that no domain controllers could be contacted, so your cluster fails to start? How about being unable to create a cluster or virtual servers due to restrictive organizational unit permissions? Microsoft has recognized these and other common AD problems and made significant efforts to fix these shortcomings in Windows Server 2012.

Cluster startup without Active Directory

Perhaps one of the most catastrophic events a cluster can face is when it can't contact adomain controller (DC) during formation. A different scenario leading to this same problem occurs when you attempt to virtualize your DCs as virtual machines in a Windows failover cluster. The cluster must contact a DC to start, but the virtual DC can't start until the cluster does. This reliance on AD for a cluster to form has been eliminated in Windows Server 2012.

You'll need to create a Windows Server 2012 cluster by contacting a DC and storing its authentication data in AD, along with any cluster members, for this function to work. Then existing clusters can start up without having to first contact a DC for authentication. Prior to Windows Server 2012, cluster startup was supported, although not recommended, to run the AD Services role on cluster members to make them more resilient to AD connectivity issues. It is no longer necessary, nor is it supported to run domain controllers as cluster nodes as Microsoft documents in KB 281662.

Flexible OU administration

Another AD shortcoming that has been addressed in Windows Server 2012 is the ability to specify in which organizational units (OU) the computer objects for the cluster will be created. In the past, when a cluster was created, the Cluster Name Object (CNO) was created in the default Computers container in the OU where the cluster members reside. This prevented admins from delegating control to specific OUs for the purpose of managing Failover Clusters without going through painful prestaging efforts.

In Windows Server 2012, both the Create Cluster Wizard and the PowerShellcmdlet New-Cluster allow you to specify in which OU the CNO will be created. In addition, any Virtual Computer Objects (VCO) for the network names associated with highly available cluster roles will be created in the same OU. The user account that creates the cluster must have the Create Computer Objects permission in the specified OU. In turn, the newly created CNO must have Create Computer Objects permission to create VCOs. You can move all these computer objects to a different OU at any point -- without disrupting the cluster. Keep in mind the custom OU must be created before you create your cluster.

Unfortunately, the syntax for specifying a particular OU where the CNO should be created isn't intuitive in the Create Cluster Wizard or the corresponding PowerShell New-Cluster cmdlet. The Create Cluster Wizard will create appropriate syntax for specifying the distinguished name of the cluster, along with the OU where it will reside. In our example, the name of the cluster is Win2012Clus1, and its CNO will be created in theClusterServers OU in the fictitious Winners.com domain (Figure 1).

Using the Create Cluster Wizard to specify a custom OU for cluster AD computer objects.

Next, look at the syntax for creating a cluster using the PowerShell New-Cluster cmdlet. In this example, the command creates a cluster with the name Win2012Cluster1, placing the CNO in the ClusterServers OU in the fictitious domain using a static IP address of 192.168.0.252 (Figure 2).

Use the New-Cluster PowerShell cmdlet to create a cluster specifying a custom OU.

After you create the Windows failover cluster, use Active Directory Users and Computers to view and manage the new CNO placed in the custom OU called ClusterServers (Figure 3). Any new cluster roles that are configured will create their VCO in the same OU.

Using Active Directory Users and Computers to view the Cluster Name Object (CNO).

Additional cluster and Active Directory enhancements

With Windows Server 2012, you can have a failover cluster located in a remote branch office or behind a DMZ with a Read-Only Domain Controller (RODC). While the CNO and VCOs must be created beforehand on a RWDC as described by Microsoft, the server supports the configuration.

Finally, AD Cluster computer objects are now created with the Protect Object from Accidental Deletion flag to ensure automated stale object scripts don't delete them. If the account that creates the cluster doesn't have this right for the OU, it will still create the object, but won't protect it from accidental deletion. A system event ID 1222 will be logged to alert you, and you can follow Microsoft KB 2770582 to fix the issue.

Microsoft has taken several steps in Windows Server 2012 to address the AD pitfalls that Windows failover clusters have endured over the years. Some of the top integration enhancements include booting clusters without AD, more flexible OU administration, support for clusters in Branch Offices and DMZs with RODCs and protecting cluster AD objects from deletion.

 Courtesy: Bruce Mackenzie-Low