Windows Management and Scripting

A wealth of tutorials Windows Operating Systems SQL Server and Azure

Windows 2012 Cluster what you must know

Posted by Alin D on March 24, 2013

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 a domain 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 PowerShell cmdlet 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 the ClusterServers OU in the fictitious windows-scripting.info domain.

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.

fter 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. Any new cluster roles that are configured will create their VCO in the same OU.

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.

 

About these ads

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

 
Follow

Get every new post delivered to your Inbox.

Join 436 other followers

%d bloggers like this: