Workgroup and Multi-domain clusters in Windows Server 2016

In Windows Server 2012 R2 and previous versions, a cluster could only be created between member nodes joined to the same domain. Windows Server 2016 breaks down these barriers and introduces the ability to create a Failover Cluster without Active Directory dependencies. Failover Clusters can now therefore be created in the following configurations:

  • Single-domain Clusters: Clusters with all nodes joined to the same domain
  • Multi-domain Clusters: Clusters with nodes which are members of different domains
  • Workgroup Clusters: Clusters with nodes which are member servers / workgroup (not domain joined)

Pre-requisites

The prerequisites for Single-domain clusters are unchanged from previous versions of Windows Server.

In addition to the pre-requisites of Single-domain clusters, the following are the pre-requisites for Multi-domain or Workgroup clusters in the Windows Server 2016:

  • To create a new cluster or to add nodes to the cluster, a local account needs to be provisioned on all nodes of the cluster (as well as the node from which the operation is invoked) with the following requirements:
    1. Create a local ‘User’ account on each node in the cluster
    2. The username and password of the account must be the same on all nodes
    3. The account is a member of the local ‘Administrators’ group on each node
    4. When using a non-builtin local administrator account to create the cluster, set the LocalAccountTokenFilterPolicy registry policy to 1, on all the nodes of the cluster. Builtin administrator accounts include the ‘Administrator’ account. You can set the LocalAccountTokenFilterPolicy registry policy as follows:
    •  On each node of the cluster launch a Microsoft PowerShell shell as an administrator and type:
new-itemproperty -path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System -Name LocalAccountTokenFilterPolicy -Value 1


Without setting this policy you will see the following error while trying to create a cluster using non-builtin administrator accounts.

  • The Failover Cluster needs to be created as an Active Directory-Detached Cluster without any associated computer objects. Therefore, the cluster needs to have a Cluster Network Name (also known as administrative access point) of type DNS.
  • Each cluster node needs to have a primary DNS suffix.

Deployment

Workgroup and Multi-domain clusters maybe deployed using the following steps:

  1. Create consistent local user accounts on all nodes of the cluster. Ensure that the username and password of these accounts are same on all the nodes and add the account to the local Administrators group.

 

      2.    Ensure that each node to be joined to the cluster has a primary DNS suffix.

 

      3.    Create a Cluster with the Workgroup nodes or nodes joined to different domains. When creating the cluster, use the AdministrativeAccessPoint switch to specify a type of DNS so that the cluster does not attempt to create computer objects.

 

New-Cluster –Name <Cluster Name> -Node <Nodes to Cluster> -AdministrativeAccessPoint DNS

Workload

The following table summarizes the workload support for Workgroup and Multi-site clusters.

 Cluster Workload

 Supported/Not Supported

 More Information

SQL Server

Supported

We recommend that you use SQL Server Authentication.

File Server

Supported, but not recommended

Kerboros (which is not available) authentication is the preferred authentication protocol for Server Message Block (SMB) traffic.

Hyper-V

Supported, but not recommended

Live migration is not supported. Quick migration is supported.

Message Queuing (MSMQ)

Not supported

Message Queuing stores properties in AD DS.

Quorum Configuration

The witness type recommended for Workgroup clusters and Multi-domain clusters is a Cloud Witness or Disk Witness.  File Share Witness (FSW) is not supported with a Workgroup or Multi-domain cluster.

Cluster Diagnostics

The Get-ClusterDiagnostics cmdlet is not supported on Workgroup and Multi-domain clusters in the Windows Server 2016 TP3 release.

Servicing

It is recommended that nodes in a cluster have a consistent configuration.  Multi-domain and Workgroup clusters introduce higher risk of configuration drift, when deploying ensure that:

  • The same set of Windows patches are applied to all nodes in the clusters
  • If group policies are rolled out to the cluster nodes, they are not conflicting.

DNS Replication

It should be ensured that the cluster node and network names for Workgroup and Multi-domain clusters are replicated to the DNS servers authoritative for the cluster nodes.