.png?width=100&auto=webp&quality=80&disable=upscale "Picture of John Savill")
.png?width=400&auto=webp&quality=80&disable=upscale "John Savill")
Sign up for the ITPro Today newsletter
Stay on top of the IT universe with commentary, news analysis, how-to's, and tips delivered to your inbox daily.
Using the New Active Directory Detached Cluster Option
Understand when to use AD Detached Failover Clusters.
John Savill
October 28, 2013
1 Min Read
Q: What are good scenarios for the new Active Directory (AD) detached implementation of Failover Clustering?
A: In Windows Server 2008, an object is created (Cluster Name Object) in AD for the cluster, which is used primarily for Kerberos purposes. However, this adds some burden being able to create objects in Active Directory.
Windows Server 2012 R2 enables a cluster to be created without creating this AD object. (Note this has to be set when creating the cluster and cannot be changed post cluster creation. Set by creating the cluster with New-Cluster -AdministrativeAccessPoint DNS).
The only real workload for which this is a good fit is SQL Server clusters that don't leverage Kerberos. It is not a good fit for other workloads for various reasons:
Kerberos is required to be able to perform Live Migrations with Hyper-V clusters, and a Hyper-V cluster that can't Live Migrate is useless.
SMB prefers to use Kerberos, which means you should not use AD-detached for file server clusters.
MSMQ (does anyone still use this?) writes to AD, so is not a fit.
BitLocker of cluster shared volumes (CSV) requires the cluster name object (CNO), so AD-detached means no BitLocker of CSV volumes.
This really does emphasize how the AD-detached scenario is only for SQL environments that use SQL authentication, and isn't recommended for anything else.
About the Author
You May Also Like
.jpg?width=700&auto=webp&quality=80&disable=upscale)
