Workgroup and Multi-domain clusters in Windows Server 2016
Published Mar 15 2019 03:03 PM 62.7K Views
Microsoft

First published on MSDN on Aug 17, 2015
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.

    • All servers must be running Windows Server 2016.

 

    • All servers must have the Failover Clustering feature installed.

 



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

 

      1. The username and password of the account must be the same on all nodes

 

      1. The account is a member of the local ‘Administrators’ group on each node

 

      1. 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.

 

    • Primary DNS Suffix Requirements

        • Each cluster node needs to have a primary DNS suffix.

        • For Multi-domain Clusters: The DNS suffix for all the domains in the cluster, should be present on all cluster nodes…






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.


For Multi-domain Clusters ensure that the DNS suffix for all the domains in the cluster is present on all cluster nodes.

3.    Create a Cluster with the Workgroup nodes or nodes joined to different domains. You may use the Failover Cluster Manager or Microsoft PowerShell.

 

Using Failover Cluster Manager

 

The following video shows the steps to create a Workgroup or Multi-Domain cluster using the Failover Cluster Manager UI.


[video width="1920" height="1080" mp4="https://msdnshared.blob.core.windows.net/media/2016/08/WorkgroupCluster.mp4"][/video]

Using PowerShell

 

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.  This will apply to only SQL Server Always On Availability Groups (AGs).  SQL Server Failover Cluster Instances (FCI) will require Kerberos for Active Directory authentication.


File Server


Supported, but not recommended


Kerberos (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.

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.

10 Comments
Copper Contributor

John,Thanks for the article of the domain Independent Cluster, I have a question, if we already have the cluster with CNO, and wanted to add a node of the workgroup or a node from another domain ,  Is it possible to add that to the current cluster which originally is not built with DNS administrative option? or we have to destroy the current cluster and do the rebuild of all of the nodes together with DNS option. thanks.  Kokoy

Microsoft

@mkokoy

 

Unfortunately no.  The initial creation of the Cluster would define the type of nodes that can be added.  The type is defined by the AdministrativeAccessPoint value.

 

DNS = does not add to active directory but does register with DNS.  So multi-domain, workgroup, or any combination of nodes

ActiveDirectory = registers all nodes in the same active directory domain but does not register with DNS

ActiveDirectoryandDNS = registers all nodes in the same active directory domain and registers with DNS

 

Copper Contributor

Hi John,

 

Thanks for your article. It has been very helpful. I have a couple of questions. If I wanted to add another node to the workgroup cluster. What's the best way to do so? Would the traditional way (wizard or powershell) work? with the understanding that all the prerequisites are met, just the same as the other nodes? 

 

I would also like to add a Cloud witness but I would like to do it using best practices and in the most secure way. I wouldn't want to open everything to port 443. I have read some articles but they just generically mention https/443, but I assume there is also an external DNS components

 

Thanks in advance.

 

 

Copper Contributor

Trying to create a workgroup cluster via your guide. Still not able to add any other node that exact server, where I start a creation process. 2 nodes of desired cluster are in same network / subnet / mask / etc. Also both nodes can ping each other and Firewall is disabled. DNS-suffix assigned to both. DNS is the same for both nodes, according to nslookup (router gateway IP in this case). What else am I missing? 

Copper Contributor

@John Marlin If it is possible, can you please take a look at my case with the problem of workgroup windows server 2016 cluster configuration?

https://docs.microsoft.com/en-us/answers/questions/656299/problem-with-windows-server-2016-cluster-c...

Copper Contributor

Hi!

 

I was wondering here if the command "New-Cluster –Name <Cluster Name> -Node <Nodes to Cluster> -AdministrativeAccessPoint DNS" should be run when you're logged in as the user created in

 

  • 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:

or could you run the "New-Cluster ...." command logged in as an administrator and then configure the cluster service to run as the created local account?

 

rgds Christian

Copper Contributor

Hi!

 

I got this error message when I ran the New Cluster command:

 

PS C:\Windows\system32> New-Cluster –Name <Cluster Name> -Node <Nodes to Cluster> -AdministrativeAccessPoint DNS
New-Cluster : Static network xxx.xxx.xxx.xxx/27 was not configured. Please use -StaticAddress to use this network or
use -IgnoreNetwork to ignore it.
At line:1 char:1
+ New-Cluster -Name  <Cluster Name> -Node <Nodes to Cluster> ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [New-Cluster], ClusterCmdletException
+ FullyQualifiedErrorId : InvalidOperation,Microsoft.FailoverClusters.PowerShell.NewClusterCommand

 

What prerequisite did I miss to fulfill?

 

rgds Christian

Copper Contributor

Why is the user creating the cluster so important when the cluster service ends up running as "Local System Account" anyway? Why must the password be the same between the two nodes?

  1. The username and password of the account must be the same on all nodes

Has that to do with the cluster communication, or?

 

rgds Christian

Copper Contributor

Hi,

 

We've 2 node Windows Failover Cluster running on Windows Server 2016 without AD.
They have iSCSI device connected and share as continuous available share.   

Basic operation works fine. 

 

However, we test by copying a large file to the CA share then perform failover test.
During failover, we can see for all volumes on new active server node:
- resume database can be loaded
- resume key filter can be attached

 

However, see error on the current active server node after failover:

======
Event: 2103
Msg Source: Microsoft-Windows-ResumeKeyFilter
Message: The resume of handle {4B26D635-64EC-11ED-984F-005056B466E2} on file \Device\HarddiskVolume15\Shares\test\cdrom.iso failed with error status 0xC0000022.

======
Event: 1016
Msg Source: Microsoft-Windows-SMBServer
Message: Reopen failed.

Client Name: \\192.168.8.247
Client Address: 192.168.8.247:60501
User Name: NODE2\smbtest2PwX9i
Session ID: 0x4300014000069
Share Name: datacenter1-dr-veeam
File Name: cdrom.iso
Resume Key: {4B26D635-64EC-11ED-984F-005056B466E2}
Status: {Access Denied}
A process has requested access to an object, but has not been granted those access rights. (0xC0000022)
RKF Status: {Access Denied}
A process has requested access to an object, but has not been granted those access rights. (0xC0000022)
Durable: false
Resilient: false
Persistent: false
Reason: RKF resume create

Guidance:

The client attempted to reopen a continuously available handle, but the attempt failed. This typically indicates a problem with the network or underlying file being re-opened.


On client:

Event: 30611
Msg Source: Microsoft-Windows-SMBClient
Message: Failed to reconnect a persistent handle.

Error: {Access Denied}
A process has requested access to an object, but has not been granted those access rights.

FileId: 0x2000013000000D8:0x0
CreateGUID: {4b26d635-64ec-11ed-984f-005056b466e2}
Path: \testrepo\test\cdrom.iso

Reason: The server denied the create request

Previous reconnect error: The transport connection is now disconnected.
Previous reconnect reason: Disconnected because there was a network disconnect indication

Guidance:
A persistent handle allows transparent failover on Windows File Server clusters. This event has many causes and does not always indicate an issue with SMB. Review online documentation for troubleshooting information.
======


The client then prompts whether to overwrite the file, as if the file on the share is another one due to persistent handle can't be resumed.

The user used to mount the share is defined in administrator group on cluster nodes while LocalAccountTokenFilterPolicy is set to 1.

 

Would anyone please help?

Thanks a lot.

Copper Contributor

Hi John!

 

I am trying to create a workgroup cluster of 3 node in windows server2019. And I don't have a shared storage so there is a virtual machine in VMware having file server and iSCSI role enabled windows2019 server. We have added a disk of 10GB from Datastore on above file server to create a iSCSI target virtual disk for disk witness. Now we have added all 3 node's IQN with this iSCSI target virtual disk but it is connecting from 1 node at a time, if I am connecting to second node it is disconnecting from first node automatically and again if connecting from third node, it is disconnecting from second.

So, if disk is not mapped to all 3 nodes, how can I create this cluster disk witness?

 

Kindly help me it is very much urgent.

 

Thanks !

Version history
Last update:
‎Apr 09 2019 10:57 AM
Updated by: