Don't panic, this one's a quick fix
Seeing 0XC0130011 – No network adapters are available in your Failover Cluster logs makes you think your hardware died. Nine times out of ten, it hasn't. The real problem is that Windows Cluster service can't find any networks it's allowed to use. This usually happens after you've added or removed a NIC, changed IPs, or ran the Validate Cluster wizard without re-running network validation.
The fix: Reset cluster network bindings
Open PowerShell as Administrator on the node showing the error. Run this command:
Stop-Service ClusSvc
Get-ClusterNetwork | Remove-ClusterNetwork -Force
Start-Service ClusSvc
That removes all cluster network definitions. When the Cluster service restarts, it re-enumerates all available adapters and creates fresh network objects. This works on Windows Server 2012 R2 through 2022. Don't bother restarting the whole server – just resetting the Cluster service is enough.
If the error persists after that, check the binding order. Run:
Get-ClusterNetwork | Select Name, State, Role, Metric
Look for networks showing Role: 0 (meaning ClusterOnly or ClientAndCluster) but with a Metric value of 4294967295. That's the default for "not ready". If you see that, the adapter isn't bound to the cluster properly. Fix it with:
Get-ClusterNetwork | Where {$_.Metric -eq 4294967295} | Set-ClusterNetwork -Metric 10000
Why this happens
The Cluster service maintains its own list of networks. When you add or remove a NIC, the service doesn't automatically rebuild that list. If the physical adapter is present but the cluster's internal view is stale, you get 0xC0130011. I've also seen this when a NIC is disabled in Windows but still listed in the cluster – the cluster sees the entry but can't communicate over it. The fix above wipes the slate clean.
Another common trigger: running the Validate Cluster wizard on a live cluster. That wizard can temporarily disrupt network bindings, especially if it runs network tests that fail. If you're in a change window, just rerun the wizard. But the PowerShell reset is faster and more reliable.
Less common variations
Sometimes the adapter itself is fine but the cluster's network priority is wrong. Check with:
Get-ClusterNetworkInterface
If you see an interface with State: Unavailable, the physical connection is down – check cables and switch ports. If all interfaces show State: Up but the network still errors, you might have a mismatch in VLAN IDs between nodes. That won't show in cluster logs; you need to verify switch config manually.
I've also hit this on multi-homed servers where one NIC is on a private cluster network and another on a public network. If the public NIC loses its default gateway, the cluster can still show it as available but can't route properly. That triggers the error on the public network only. The fix there is to disable the cluster role on that public network:
Get-ClusterNetwork -Name "Public" | Set-ClusterNetwork -Role 0
(Role 0 means ClientOnly – the cluster won't try to use it for cluster traffic.)
Prevention steps
- Always re-run the Validate Cluster wizard after any network change – it rebuilds bindings.
- Use consistent NIC naming across nodes. Avoid "Local Area Connection" – rename to
Cluster-PrivateandCluster-Public. - Set the cluster heartbeat network to the lowest metric (e.g., 100), and the public network to a higher metric (e.g., 10000). This prevents the cluster from trying to use your public interface for cluster traffic.
- Before making any network change, export cluster configuration with
Get-ClusterResource | Export-ClusterXml C:\ClusterBackup.xml. If the reset doesn't work, you can import it back. - If you're on VMware, disable VMQ on the virtual NICs for cluster nodes. VMQ and Failover Clusters have a messy history – I've seen it cause this exact error on ESXi 6.7 and 7.0.
That's it. You'll be back up in under five minutes. If this doesn't solve it, I'd bet money the issue is at the switch level – missing VLAN or a bad SFP module. Start there.