Unsolved Cluster Aware Updating gotcha's for Workgroup, multi-domain, and traditional Clusters

---

Can someone explain to me what types of Cluster Aware Updating approaches are supported with each cluster deployment scenario?

I have scoured the internet pouring over these articles and can't seem to get a clear answer..
https://docs.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating
https://docs.microsoft.com/en-us/windows-server/failover-clustering/cluster-aware-updating-requirements

Specifically I have two questions...

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

2. 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?

I found a third party thread that stated that only remote-updating mode was supported when the Cluster was deployed using an Admin Access point of DNS. Is this correct? Is this the only gotcha?

In reading the requirements, it appears the system used to initiate the remote-updating process needs to be a member of the same domain, so that seems to conflict a bit with the deployment option admin access point "DNS".

Regards,
Adam Tyler

Adam,

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:

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

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

NOW ….

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

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.

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.

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 !!!

Cheers,

Adam

Thanks Adam, that does help a lot. Thank you for that write up. Just a couple of points of clarification regarding Active Directory Detached Clusters. Am I correct in the following statements?

1. Active Directory Detached Clusters are still domain joined, it is simply a way of deploying a cluster without relying on pre-staged computer accounts and permission/delegation steps. IE.. The traditional method I have used is to create an OU, move all computer objects to said OU, create a computer object for the cluster, disable said cluster computer object, then delegate full control over the OU to the new cluster computer object.

2. Active Directory Detached Clusters require that each node be a domain joined member of the same domain. In this scenario, you could create a traditional cluster or AD detached cluster.

Regards,
Adam Tyler

Adam,

Always glad that I can help out.

Yes & Yes.

Cheers,

Adam

Thank you. For multi-domain clusters, these need to be domains in the same forest? Doesn't support clusters across a trust correct?

Regards,
Adam Tyler

Sorry I keep asking questions..... I am sure you had something else to do today. ...

You said:

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

To clarify, remote-updating is supported in Multi-domain clusters? It sounded like the coordinator computer had to be in the same domain?

Regards,
Adam Tyler

The question that sent me on this journey was related to this output a get-cluster command:

The question is basically asking if both Cluster Aware Updating methods are supported based on the output. Originally I was thinking that because the AdministrativeAccessPoint was "DNS", that automatically meant workgroup cluster which wouldn't support remote-updating. After discussing with you it seems that you could use the DNS admin access point in other scenarios.. Furthermore the domain contoso.com is listed in the output indicating that the node is domain joined. So, it appears that both self-updating and remote-updating are supported.

On the right track?

Regards,
Adam Tyler

Adam,

I hope all is well. Sorry about the delay in getting back to this conversation, I have been working remotely for most of the last week, and have been tied up on some projects, so have been absent in the forums.

The documentation does clearly state that the remote administration endpoint needs to be a member of the same domain as the machines that it will be administering.

Keep in mind that you could run the get-cluster cmdlet against a domain and get information about all of the clusters in that domain from a machine that is not part of a cluster. See the following:

https://docs.microsoft.com/en-us/powershell/module/failoverclusters/get-cluster?view=win10-ps

Now, specific to the "For multi-domain clusters, these need to be domains in the same forest? Doesn't support clusters across a trust correct?"

As far as I know, there is no support in 2016 for clusters across a trust. HOWEVER, in 2019, we have a brand spankin' new feature being rolled out:

Cross-domain cluster migration - Failover Clusters can now dynamically move from one Active Directory domain to another, simplifying domain consolidation and allowing clusters to be created by hardware partners and joined to the customer's domain later.

In previous versions of WFC moving a WFC to a new domain required that the domain membership of the WFC destroyed and re-created. Windows Server 2019 provides two PowerShell cmdlets, Remove-ClusterNameAccount and New-ClusterNameAccount, which delete the cluster name account from the original Active Directory domain, shuts down the cluster and removes it from the original domain. Then they add the cluster nodes to a workgroup, join them to the new domain and create new cluster resources in the new domain. In addition, a new Windows Server 2019 Cluster Sets feature supports grouping multiple clusters together using a Master cluster resource running on one cluster that works with a Cluster Set Worker in the member clusters enabling you hyper-scale your clusters as well as Live Migrate VMs between member clusters.

I am not sure how this may ultimately play out, and if we will see spill over into the CAU area, but it is an interesting development.

In addition, there is an even NEWER FEATURE being currently rolled out in Windows Server Insider Preview build 17650 and later for Sever 2019, CLUSTER SETS, which is not directly relevant to what you are asking, but has the potential to become a path to allow for much of what you are asking about. Read more about it here:

https://docs.microsoft.com/en-us/windows-server/storage/storage-spaces/cluster-sets

Second open item/question: "To clarify, remote-updating is supported in Multi-domain clusters? It sounded like the coordinator computer had to be in the same domain?"

Remember that for Multi-domain Clusters, you have to ensure that the DNS suffix for all the domains in the cluster is present on all cluster nodes. This ensures that all cluster members are able to resolve/find each other and be managed, even though there are no AD objects in any domains being created.

As a result, remote-updating is supported in Multi-domain clusters.

Lets tackle the "Am I correct in the following statements? …

1. Active Directory Detached Clusters are still domain joined, it is simply a way of deploying a cluster without relying on pre-staged computer accounts and permission/delegation steps. IE.. The traditional method I have used is to create an OU, move all computer objects to said OU, create a computer object for the cluster, disable said cluster computer object, then delegate full control over the OU to the new cluster computer object. ----> ADAM RESPONDS "YES" Take a look at the following for a good overview of what an AD detached cluster is and how we create one:

https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn265970(v=ws.11)

2. Active Directory Detached Clusters require that each node be a domain joined member of the same domain. In this scenario, you could create a traditional cluster or AD detached cluster." ----> ADAM RESPONDS "YES"

Hope that helps to clarify...

Cheers,

Adam

Thanks Adam, going back to my posted get-cluster output... Does the domain output of contoso.com indicate the cluster nodes are domain joined or can that field be populated if they are workgroup only servers using clustering with a domain suffix only? Trying to figure out if the output is enough information to indicate if the cluster could support remote-updating only, self-updating only, or both... Again it throws me all over the place because of the admin access point being DNS. Initially I thought workgroup cluster, which would rule out remote-updating as an option. I assume all clusters support self-updating regardless of the deployment method.

Regards,
Adam Tyler