Fix 0X80130005: Cluster Node Already Member

Cause 1: Stale Cluster Object in Active Directory

When you add a node to a failover cluster, Windows creates a computer object in Active Directory (usually under the Computers container). If that object is still there from a previous cluster attempt, the new node will throw 0X80130005.

This happens a lot when someone force-removes a node without properly evicting it, or when the cluster is deleted but the AD object isn't cleaned up.

Here's how to check and fix it:

1. On a domain controller, open Active Directory Users and Computers.
2. Look for a computer account that matches the node's name or the cluster's name. It's often in the Computers container, but could be anywhere.
3. Right-click the stale object and select Delete. Confirm the deletion.
4. Wait a few minutes for AD replication to catch up, or force replication with repadmin /syncall.
5. On the node, open PowerShell as Administrator and run:

Clear-DnsClientCache
Restart-Service -Name ClusSvc -Force
Get-ClusterNode

After you delete the stale AD object, try adding the node again. You should see a different error (or none). If you still get 0X80130005, move to the next cause.

Cause 2: Corrupted Cluster Database on the Node

Sometimes the node itself has leftover cluster configuration in its local cluster database. That happens when a previous cluster install didn't fully clean up, or when someone manually deleted cluster registry keys.

This one is sneaky because the node looks clean from the cluster perspective, but the local database still thinks it's a member.

Fix it by force-removing the node from the cluster (even if it's not there) and clearing the local database:

1. Log on to the node that's giving the error.
2. Open PowerShell as Administrator.
3. Run these commands to stop the cluster service and remove all cluster configuration:

Stop-Service -Name ClusSvc -Force
Remove-Item -Path "HKLM:\Cluster" -Recurse -Force
Restart-Service -Name ClusSvc

Wait, that removes the entire cluster registry hive. If the node is a member of a working cluster, this will destroy the cluster. Only do this on a node that you're absolutely sure is not part of a live cluster.

After the service restarts, try adding the node to the cluster again. This time it should see a clean slate.

If you're still stuck, the problem might be in the cluster's own configuration, not the node's.

Cause 3: Cluster Service Account Doesn't Have Permissions

Windows Server failover clusters run under a domain account (usually svc_cluster or similar). That account needs certain permissions in AD to create and manage the cluster's computer object. If the account has been moved, renamed, or its permissions have been tightened, the node can't rejoin and you get 0X80130005.

This one is common after a domain migration or a security audit.

Check and fix permissions:

1. On a domain controller, open Active Directory Users and Computers.
2. Right-click the domain or the OU where the cluster object lives, then select Properties.
3. Go to the Security tab (if you don't see it, enable Advanced Features in the View menu).
4. Click Add and add the cluster service account.
5. Grant it Full Control over the computer objects. Be careful here — you don't want to give it domain admin rights. Just enough to create and delete computer objects in that container.
6. Click OK and close the dialog.

Then, on the node, run klist purge to clear cached Kerberos tickets, and try adding the node again.

If you're not sure which account the cluster uses, run this on any node that's already in the cluster:

Get-CimInstance Win32_Service -Filter "Name='ClusSvc'" | Select-Object StartName

That shows the service account.

Quick-Reference Summary

This error almost always comes down to leftover state. The fix is to find where that stale state lives and clear it. Start with AD, then the node's local database, then the service account. You'll get it sorted.