Fix ERROR_CLUSTER_NETINTERFACE_EXISTS 0x13B6

This error pops up when adding a node to a cluster and the network interface name already exists. It's usually stale cluster config or DNS lag. Here's how to clear it fast.

You're in the middle of adding a second node to your Windows Server Failover Cluster. Everything looks fine—network adapters are up, DNS resolves, firewall rules are in place. Then, boom: ERROR_CLUSTER_NETINTERFACE_EXISTS (0x000013B6). The cluster network interface already exists, according to the error. But you haven't even finished adding the node yet. I know this error is infuriating because it makes zero sense at first glance.

This typically happens when a node was previously part of a cluster (or attempted to join one) and the old cluster configuration wasn't fully cleaned up. Windows stores cluster network interface information in the cluster database, and if a stale entry with the same network adapter name (like Ethernet or Cluster NIC 1) is still there, the validation process chokes. I've also seen this after an improper node eviction or when someone manually edited cluster registry keys—don't do that, by the way.

Root cause: stale cluster database entries

The cluster service on each node has its own copy of the cluster database. When you add a node, it tries to register its network interfaces with the cluster. If the cluster already has an interface with the same name (often because the node was previously a cluster member and wasn't cleanly removed), the new registration fails with this exact error. The fix is to remove those stale entries from the cluster database before retrying.

Here's the thing: you can't just delete the interface from Failover Cluster Manager because it's not visible there—the error happens before the node joins, so the interface isn't even listed. You need to use PowerShell to clean up the cluster objects directly.

Fix: clear the stale network interface

Open PowerShell as Administrator on the node you're trying to add (not the existing cluster node). If you can't open PowerShell on that node because the cluster service is down, you can run these commands from an existing cluster node, but you'll need to specify the target node name.
First, check if there's a network interface already registered for this node in the cluster. Run:

Get-ClusterNetworkInterface | Where-Object {$_.NodeName -eq "YourNodeName"}

Replace YourNodeName with the actual node name. If you see any entries, that's your culprit. Note the Name of the interface(s).

Remove the stale interface. If the interface is not currently in use by the cluster (which it shouldn't be, since the node isn't part of the cluster yet), you can remove it directly:

Remove-ClusterNetworkInterface -Name "Ethernet" -Node "YourNodeName" -Force

If the Remove-ClusterNetworkInterface cmdlet gives you an error like "The object is not in the cluster," then the entry is likely in the cluster database but not active. In that case, you need to clear the cluster database on the existing nodes. On an existing cluster node, run:

Clear-ClusterNode -Name "YourNodeName"

This cmdlet clears the cluster configuration for that node. Caution: This wipes any cluster-specific settings for that node, so if the node was previously configured for clustered roles, you'll need to reconfigure those roles after re-adding.

After clearing, verify the interface is gone:

Get-ClusterNetworkInterface | Where-Object {$_.NodeName -eq "YourNodeName"}

Should return nothing.

Now attempt to add the node again through Failover Cluster Manager or PowerShell:

Add-ClusterNode -Name "YourNodeName"

It should sail through this time. I've seen this fix work on Server 2012 R2 through 2022, and it holds up.

If it still fails

Sometimes the stale entry isn't in the cluster database but in the local node's registry. Check the following on the failing node:

Open Registry Editor and navigate to HKLM\Cluster\Nodes. If you see an entry with your node GUID but the cluster isn't recognizing it, you can delete that key—but only if the cluster is fully healthy on other nodes. Back it up first.
Another culprit: DNS scavenging hasn't cleared the old A record for the node. That won't cause this exact error, but it can cause a cascade of other cluster validation failures. Verify with nslookup that the node's DNS record points to its current IP.
Check the cluster log for more context: Get-ClusterLog -Node "YourNodeName". Look for lines around the same timestamp as the error—they'll often show the exact network adapter that's conflicting.

If you've cleared the interface from the cluster database and confirmed no registry leftovers, but you still get the same error, then something else is holding onto that interface name. In that case, I'd suspect a third-party network driver or VLAN configuration is registering a duplicate interface at the OS level. Unbind and rebind the adapter in Network Connections, then try again. That's a long shot, but it's worked for me once in a dusty corner of a data center.

Pro tip: Always evict nodes properly using Remove-ClusterNode instead of just deleting the computer account or forcibly removing it. That's how these ghosts are born.