My name is Ram Malkani and I am a Support Escalation Engineer on Microsoft’s Windows Core team. I am writing to discuss how Failover Clustering is integrated with Active Directory on Windows Servers.
Windows Server Failover Clustering, has always had a very strong and cohesive attachment with the Active Directory. We made considerable changes to how Failover Clustering integrates with AD DS, as we made progression to new versions of Clusters running on Windows Servers. Let us see the story so far:
Window Server 2003 and previous version.
Windows Server 2008, 2008 R2
Windows Server 2012, 2012 R2
We needed a Cluster Service Account (CSA). A domain user, whose credentials were used for the Cluster service and the Clustered resources. This had its problems, changing the password for the account, rotating the passwords, etc. Later, we did add support for Windows Clusters on 2003 to use Kerberos Authentication which created objects in Active Directory.
We moved away from CSA, and instead, the Cluster started the use of Active Directory computer objects associated with the Cluster Name resource (CNO) and Virtual Computer Objects (VCOs) for other network names in the cluster. When cluster is created, the logged on user needed permissions to create the computer objects in AD DS, or you would ask the Active Directory administrator to pre-stage the computer object(s) in AD DS. Cluster communications between nodes also uses AD authentication.
The same information provided for Windows 2008 and 2008R2 applies, however, we included a feature improvement to allow Cluster nodes to come up when AD is unavailable for authentication and allow Cluster Shared Volumes (CSVs) to become available and the VMs (potentially Domain Controllers) on it to start. This was a major issue as otherwise we had to have at least one available Domain Controller outside the cluster before the Cluster Service could start.
What’s new with Clustering in Windows Server 2012 R2
We have introduced, a new mode to create a Failover Cluster on Windows Server 2012 R2, known as Active Directory detached Cluster. Using this mode, you would not only no longer need to pre-stage these objects but also stop worrying about the management and maintenance of these objects. Cluster Administrators would no longer need to be wary about accidental deletions of the CNO or the Virtual Computer Objects (VCOs). The CNOs and VCOs are now instead created in Domain Name System (DNS).
This feature provides greater flexibility when creating a Failover Cluster and enables you to choose to install Clusters with or without AD integration. It also improves the overall resiliency of cluster by reducing the dependencies on CNO and VCOs, thereby reducing the points of failure on the cluster.
The intra-cluster communication would continue to use Kerberos for authentication, however, the authentication of the CNO would be done using NT LM authentication. Thus, you need to remember that for all Cluster roles that need Kerberos Authentication use of AD-detached cluster is not recommended.
Before installing an Active Directory-detached Cluster, considerations must be made on what role will be on the Cluster. Not all roles will work on a Cluster in this configuration. For details on cluster roles that are not recommended or unsupported for AD detached Clusters, please read:
Deploy an Active Directory-Detached Cluster
Installing Active Directory detached Cluster
First, you should make sure that the nodes, running Windows Server 2012 R2 that you are intending to add to the cluster are part of the same domain, and proceed to install the Failover-Cluster feature on them. This is very similar to conventional Cluster installs running on Windows Servers. To install the feature, you can use the Server Manager to complete the installation.
Server Manager can be used to install the Failover Clustering feature:
Introducing Server Manager in Windows Server 2012
We can alternatively use PowerShell (Admin) to install the Failover Clustering feature on the nodes.
Install-WindowsFeature -Name Failover-Clustering -IncludeManagementTools
An important point to note is that PowerShell Cmdlet ‘Add-WindowsFeature’ is being replaced by ‘Install-WindowsFeature’ in Windows Server 2012 R2. PowerShell does not install the management tools for the feature requested unless you specify ‘-IncludeManagementTools’ as part of your command.
The Cluster Command line tool (CLUSTER.EXE) has been deprecated; but, if you still want to install it, it is available under:
Remote Server Administration Tools –> Feature Administration Tools –> Failover Clustering Tools –> Failover Cluster Command Interface in the Server Manager
The PowerShell (Admin) equivalent to install it:
Install-WindowsFeature -Name RSAT-Clustering-CmdInterface
Now that we have Failover Clustering feature installed on our nodes. Ensure that all connected hardware to the nodes passes the Cluster Validation tests. Let us now go on to create our cluster. You cannot create an AD detached clustering from Cluster Administrator and the only way to create the AD-Detached Cluster is by using PowerShell.
New-Cluster MyCluster -Node My2012R2-N1,My2012R2-N2 -StaticAddress 192.168.1.15 -NoStorage -AdministrativeAccessPoint DNS
In my example above, I am using static IP Addresses, so one would need to be specified. If you are using DHCP for addresses, the switch “-StaticAddress 192.168.1.15 ” would be excluded from the command.
Once we have executed the command, we would have a new cluster created with the name “MyCluster” with two nodes “My2012R2-N1” and “My2012R2-N2”. When you look Active Directory, there will not be a computer object created for the Cluster “MyCluster”; however, you would see the record as the Access Point in DNS.
That’s it! Thank you for your time.
Support Escalation Engineer
Windows Core Team