Our team focuses on cutting edge customer and partner experiences for existing and new Windows Server and Cloud releases.
Hi there! In this blog post we highlight some of the work on Windows Server 2012 Failover Clusters and Active Directory integration learning’s from engaging with customers during our Windows Server 2012 engineering validation program. Long before we reach RTM dedicated customers deploy in production, test and identify issues during the development phase to help us achieve a high quality release. Tanu Mutreja a Senior Program Manager in the Customer Engineering team focused on Cluster scenarios will take you thru the details of Windows Server 2012 Failover Clusters and Active Directory integration.
Natalia Mackevicius Group Program Manager, Partner and Customer Ecosystem Team
Enhanced efficiency & reduced complexity is one of the key feedbacks that we received from Windows Server 2012 (WS 2012) Failover Clustering TAP customers. Simplified integration between Failover Clustering and Active Directory is one such feature in WS 2012.
In Windows Server 2012 Failover Clustering, not only did we focus on enabling new capabilities but we also focused on resolving existing pain points. Throughout the WS2012 TAP program, we kept an active & open channel for voice of TAP customers to reflect in the final product.
In this blog, I’ll highlight some notable ‘WS2012 Failover Clustering – AD Integration’ improvements that most of our customers found helpful in their environments:
1. Support for Delegated Domain Administration
2. AD-less cluster bootstrapping
3. Enhanced troubleshooting & diagnostic mechanisms
4. Support for Read Only Domain Controller (RODC)
If your failover cluster is in an Active Directory (AD) Domain Controllers (DC) that is running on WS2008 R2 / R2 SP1 or WS2008 SP2, then install hotfixes mentioned in this KB Article.
As part of initial Windows Server failover cluster configuration, the cluster creates a computer object in AD. This computer object called “CNO” is associated with cluster network name resource called “Cluster Name”. In WS2012, we have enhanced the CNO creation method by allowing cluster admins to customize CNO location in AD (prior to WS2012 cluster could create CNO in a pre-defined default location only).
We have also enhanced the default location of CNO to be more meaningful i.e. now in WS2012, by default CNO objects are created in same OU as nodes and VCOs.
This new functionality has provided lot more flexibility to cluster administrators & resolved all the pain around access issues in CNO creation process. For details around this new capability, please refer to this blog post at Clustering and High-Availability blog.
Virtualization is the buzz today! Fully virtualized data center is a goal for most! IT administrators want to make all workloads virtualized and then highly available with failover clustering. And yes, for most part, this works fine!
However, when there are circular dependencies in building blocks things become difficult. Virtualizing AD Domain Controller and then making it highly available using failover clustering, is one such scenario.
In this situation where DC is virtual and is part of a failover cluster, when a cluster boots up it needs DC to authenticate cluster nodes but for the DC to boot up it needs cluster to be running. So every time the cluster boots up we end up in a ‘chicken and egg’ situation and cluster is not able to start.
Good news! In WS2012, we have solved this situation by allowing an existing cluster to boot without AD. In other words, now node that boots up first can create the cluster & can try to gain quorum without authenticating with DC. Now since other nodes can also start without contacting the DC (unless there are other technical issues blocking those nodes to start), first node gains quorum & whole cluster can start.
Better news! Many other scenarios benefit with this new capability. Since a cluster node can now boot up without authenticating with DC, if for whatever reason you run into situations where one or more (even all) cluster nodes are not able to reach a DC, those nodes can still join a cluster and the cluster can boot without issues. Later, when the DC comes up, cluster service will seamlessly turn to connecting & using this DC.
Now the best news is that the solution is implemented in failover cluster service itself. So, no additional settings or AD schema / configuration changes are required in AD.
1. Active Directory is still needed to form a cluster or to add new nodes to an existing cluster. However, once a cluster is formed WS2012 removes dependency on AD for cluster to boot or for existing nodes to join the cluster.
2. In WS2012, you can add “Priority” to individual virtual machines. By assigning “High Priority” to a virtual machine running DC, you can ensure that cluster service will start DC virtual machine before VMs with lower priority.
Windows Server failover cluster uses Active Directory to create & manage information about cluster nodes/resources. So, obviously it needs read & write permissions to the AD domain controllers. However, in certain DMZ & Branch Office scenarios, a cluster node may not have access to Read+Write DC (aka RWDC) i.e. cluster node(s) can only communicate with (i.e. read from) RODC. In WS2012, we enable failover clustering for such DMZ / branch office scenarios where cluster node can only read from DC.
In RODC environment, since no user can create any object in RODC, cluster information needs to be pre-created in RWDC which then needs to be replicated to RODC. In other words CNO & virtual computer objects (VCO) for resources needs to be pre-staged in RWDC. However, pre-staging AD object for RODC is more involved process than pre-staging object for RWDC. Stay tuned on this blog for details on those differences & additional configuration steps…
Note: In environments where a cluster can communicate with at least one RWDC, failover cluster would always choose to use that RWDC. RODC clusters are those where a cluster cannot communicate with any RWDC at all.
“Repair Cluster Name” is another new capability in WS2012 where a cluster may need to write to a DC. Since RODC allows forwarding of any password related changes to RWDC (and the changes in RWDC will replicate back to RODC), “Repair Cluster Name” is also supported in RODC environments as long as RODC can communicate with a RWDC.
For easier troubleshooting & diagnostics, in WS2012 we made failover cluster logs to be much more exhaustive. To be specific to failover cluster and AD integration scenarios, you will be able to find logs for new scenarios enabled in WS2012 (e.g. support for “delegated administration”, AD-less cluster bootstrap & RODC scenarios). As an example, now that we allow custom location for cluster computer objects, you can utilize cluster logs to see which DC’s are being connected to, which OU’s are referenced to and so on.
These are some of the key scenarios enabled in Windows Server 2012 for “failover clustering – AD integration”. Clustering and High-Availability Blog is a great resource for all WS2012 failover clustering scenario references. In particular, if you are getting started with failover clustering in Windows Server 2012, you would find many useful tips & trick in How to Troubleshoot Create Cluster failures in Windows Server 2012 blog post.
If there are other specific topics that you want to cover in details, please add your suggestions in comment section…
Tanu MutrejaSenior Program Manager Partner and Customer Engineering team
How can we enable the FailoverCluster in server 2012 server core O/S ?
I have been trying the below command but getting the error saying couldn't download source Files.
Dism /online /enable-feature /featurename:FailoverCluster-Mgmt /all /source:D:\sources\SxS
Ravi, on server core OS you can enable Failover Cluster feature by running (on elevated command prompt)
Dism /online /enable-feature /featurename:FailoverCluster-FullServer
The feature 'FailoverCluster-Mgmt' will try to install management snap-in, which isn't available on server core (since there isn't any gui). However, you can install management snap-in on a remote machine and from there manage features on server core OS.
For more information on managing server core OS, also refer to