Windows Server Failover Clustering: Add-ClusterNode and New-Cluster both fail with "computer is joined to a cluster" on Microsoft Entra Domain Services

Question

Service

Windows Server Failover Clustering (WSFC) on Windows Server 2022 VMs

joined to Microsoft Entra Domain Services (managed domain).

Scenario

I'm adding a new node to an existing 2-node WSFC cluster that hosts a SQL

Server Always On Availability Group. Add-ClusterNode fails. I also

tried creating a brand-new, separate single-node cluster on the same

machine to rule out the existing cluster as the cause, and that fails

identically.

Result

Add-ClusterNode : The computer 'SQL-DR.sqldemo.onmicrosoft.com' is joined to a cluster.

and, separately, on the same machine:

New-Cluster : There was an error adding node 'SQL-DR' to the cluster

The computer 'SQL-DR.sqldemo.onmicrosoft.com' is joined to a cluster.

Both commands fail even though the target machine has never been a

member of any cluster (confirmed: no HKLM:\Cluster registry hive, no

CLUSDB, Get-Cluster reports the cluster service isn't running).

Environment

● Domain: Microsoft Entra Domain Services (managed domain)

● Existing cluster: 2 nodes, Windows Server 2022, currently healthy

● Target node: also Windows Server 2022, same domain, freshly deployed

● Account used: member of "AAD DC Administrators"

Troubleshooting already tried

● Rebuilt the target VM and its AD computer object from scratch (new SID) -- same error

● Tested with a second, completely unrelated new VM name -- same error

● Confirmed the account can create/delete AD computer objects (tested directly)

● Confirmed no stale cluster registry/WMI/database state on the target node

● Confirmed the existing cluster has no Cluster Name Object in AD at all

● Tried New-Cluster with -AdministrativeAccessPoint Dns (AD-detached, no CNO dependency) -- same error

Question

Is this a known limitation or issue with WSFC node validation against

Microsoft Entra Domain Services? What would help identify the cause

(cluster logs, diagnostic steps), and is there a supported path to add a

node or create a new cluster in this environment?

Answer

Hi, I would not treat this as a normal CNO/VCO permissions issue, because New-Cluster -AdministrativeAccessPoint Dns also fails and that mode is specifically intended to create an AD-detached cluster without CNO/VCO objects in AD DS. Microsoft’s WSFC documentation still assumes the nodes are in the same Active Directory domain and states that cluster creation normally depends on AD computer-object permissions, while Microsoft Entra Domain Services is a managed domain with important administrative limitations, including no Domain Admin or Enterprise Admin privileges.
I have not found an official Microsoft article confirming WSFC/SQL Always On Availability Groups as a supported deployment on Microsoft Entra Domain Services, so if this is production SQL HA, the safest supported design is still self-managed AD DS domain controllers in Azure or an extended on-prem AD DS domain. Before concluding that it is an Entra Domain Services limitation, run Test-Cluster -Node SQL-DR -Verbose and collect Get-ClusterLog -UseLocalTime -Destination C:\Temp immediately after the failure, then check Microsoft-Windows-FailoverClustering/Operational and System logs for the exact stage where the node is being classified as already clustered. Also run Clear-ClusterNode -Force locally on the target node once, because Microsoft provides this cmdlet to remove residual cluster configuration from an evicted node, even though you have not found obvious local cluster state.
If the same error persists on a freshly built VM with no cluster state and with DNS-only administrative access point, I would open a Microsoft support case and provide the cluster validation report, cluster logs, AD computer object attributes, and Entra Domain Services details, because this may be an unsupported edge case or product issue in WSFC validation against a managed domain.