In Windows Server 2012 R2 , you can deploy a failover cluster without dependencies in Active Directory Domain Services (AD DS) for network names. This is referred to as an Active Directory-detached cluster. Using this deployment method enables you to create a failover cluster without the previously required permissions for creating computer objects in AD DS or the need to request that computer objects are prestaged in AD DS.

When you create an Active Directory-detached cluster, the cluster network name (also known as the administrative access point) and network names for any clustered roles with client access points are registered in Domain Name System (DNS). However, no computer objects are created for the cluster in AD DS. This includes the computer object for the cluster (also known as the cluster name object or CNO) and computer objects for any clustered roles that would typically have client access points in AD DS (also known as virtual computer objects or VCOs).

To deploy an Active Directory-detached cluster, you must use Windows PowerShell. You cannot use Failover Cluster Manager. To create the failover cluster, start Windows PowerShell as an administrator, and then use the New-Cluster cmdlet with the –AdministrativeAccessPoint parameter set to a value of Dns.

But how to create such a cluster

New-Cluster SQLCL02 –Node mvpsql021,mvpsql022 –StaticAddress 10.255.255.12 -NoStorage –AdministrativeAccessPoint Dns

 

 

 

 

 

 

New-Cluster SQLCL02 –Node mvpsql021,mvpsql022 –StaticAddress 10.255.255.12 -NoStorage –AdministrativeAccessPoint Dns

the key is in the –AdministrativeAccessPoint

The option gives you the cluster you want.

PARAMETERS
    -AdministrativeAccessPoint <AdminAccessPoint>
        Specifies the type of administrative access point that the cmdlet creates for the cluster. The acceptable
        values for this parameter are:

        — ActiveDirectoryAndDns. The cmdlet creates an administrative access point for the cluster. The
        administrative access point is registered in DNS and enabled in Active Directory Domain Services.
        — Dns. The cmdlet creates an administrative access point for the cluster. The administrative access point is
        registered in DNS but is not enabled in Active Directory Domain Services.
       — None. The cmdlet does not create an administrative access point for the cluster. Some clustered roles and
        functionality might not be available for a cluster that does not have an administrative access point. Also,
        you cannot use Failover Cluster Manager to manage a cluster that does not have an administrative access point.

       

There is only one way to show the state of the cluster

(Get-Cluster).AdministrativeAccessPoint

 

 

 

 

 

 

But is a non domain joined CNO any usefull ?

Well I see no good reasons why you would do this.

You can set the type of administrative access point only when you create the cluster. You cannot change it after the cluster is deployed.

SO If you build a SQL cluster and later you think oh I need Kerberos there is NO PowerShell option

set-cluster –AdministrativeAccessPoint ActiveDirectoryAndDns

You will have to rebuild your cluster !

 

Cluster Workload	Supported/Not Supported	More Information
SQL Server	Supported	We recommend that you use SQL Server Authentication for an Active Directory-detached cluster deployment.
File server	Supported, but not recommended	Kerberos authentication is the preferred authentication protocol for Server Message Block (SMB) traffic.
Hyper-V	Supported, but not recommended	Live migration is not supported because it has a dependency on Kerberos authentication. Quick migration is supported.
Message Queuing (also known as MSMQ)	Not supported	Message Queuing stores properties in AD DS.

In addition, be aware of the following issues for this type of cluster deployment:

• BitLocker Drive Encryption is not supported.
• Cluster-Aware Updating (CAU) in self-updating mode is not supported.