I hope all is well.
Definitely can be a little confusing, as there is a lot of incorrect information floating around out there about these approaches.
The shift from 2102/R2 to 2016 creates the opportunity to "free ourselves" from dependency on Active Directory joined resources for clustering, and while that is potentially a good thing in certain scenarios, Microsoft has not done a great job of documenting this and realty explaining not just the benefits/use cases, but also the requirements associated with these approaches.
Let's see what we can clarify:
If you create a Windows cluster using the "DNS" Administrative Access Point, I see this is typically used for deploying a Workgroup cluster. Do the servers have to be in a Workgroup in order to use this admin access point option? Or can they be domain joined and still use this?
What type of Cluster Aware Updating approach is supported for clusters deployed using an admin access point of DNS, ActiveDirectory, and ActiveDirectoryAndDNS? Ie.. Remote-updating mode only, Self-updating mode only, or both?
A little bit of context and historical info here PRIOR to the answer, so you understand where we are coming from as we transition to Server 2016 and this capability:
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).
NOTE that this deployment method still requires that the failover cluster nodes are joined to an Active Directory domain.
Windows Server 2016 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
Server1.abc.local and Server2.abc.local
Multi-domain Clusters: Clusters with nodes which are members of different domains
Server3.abc.local and Server3.def.local
Workgroup Clusters: Clusters with nodes which are member servers / workgroup (not domain joined)
ServerA and ServerB
When deploying a Workgroup Cluster the members are not domain joined.
In case you need them, here is the list of pre-req's that have to be considered:
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.
~ All servers must use logo’d hardware that has been certified and the collection of servers must pass all cluster validation tests.
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:
~ Create a local ‘User’ account on each node in the cluster
~ The username and password of the account must be the same on all nodes
~ The account is a member of the local ‘Administrators’ group on each node
When using a non-builtin local administrator account to create the cluster, set the LocalAccountTokenFilterPolicyregistry policy to 1, on all the nodes of the cluster. 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
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
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.
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.
SOOOOOOOOOO... what does all that really mean?
Q1 answer ---> Workgroup Cluster members ARE NOT domain Joined.
Q2 answer ---> Not so simple based on how you framed the question. Let me quickly clarify something first:
Using an admin access point of type DNS, DOES NOT preclude the use of either type of cluster aware updating (Remote or self-updating).
What presents an issue here is the type of cluster being deployed, meaning that if you were to deploy an Active Directory-Detached Cluster, then you are only able to use Cluster-Aware Updating (CAU) in remote-updating mode, self-updating mode is not supported.
If you are deploying a Single Domain or Multi-Domain Cluster, both CAU options are supported.
If you are using a Workgroup Cluster, then only self-updating mode can be used, as If CAU is used in remote-updating mode, the Update Coordinator computer must have network connectivity to the failover cluster nodes, and it must be in the same Active Directory domain as the failover cluster.
Wow... lots of stuff to keep track of, but not too bad once you have the context and understand the different options available to you.
I hope that helps to clarify? As always, let me know what we need to continue to work through once you have a chance to read through everything and let it all sink in.
Good Luck !!!