Fix STATUS_CLUSTER_NETWORK_NOT_FOUND (0xC0130007)

I know this error is infuriating

You're staring at a cluster node that refuses to talk to its peers. The event log shows STATUS_CLUSTER_NETWORK_NOT_FOUND (0xC0130007), and the cluster network seems to have vanished. I've been there—it usually hits after a patch Tuesday or a network reconfiguration. Let's get your nodes talking again.

Step 1: The real fix is a registry edit

Don't try to remove and re-add the network role in Failover Cluster Manager—it won't help here. This error often means the cluster service can't find the network adapter's GUID in the cluster database. The fix is to force the cluster to re-enumerate networks.

Open Registry Editor on the affected node (as Administrator).
Navigate to:
```
HKEY_LOCAL_MACHINE\Cluster\Networks
```
Right-click the Networks key and select Export to back it up. Save the .reg file somewhere safe.
Now, delete the Networks key entirely. Yes, delete it. The cluster service will regenerate it on restart.
Open an elevated Command Prompt and run:
```
net stop clussvc && net start clussvc
```
Wait about 30 seconds, then check the cluster. Open Failover Cluster Manager and see if the network shows up.

Why this works: The cluster service caches network adapter GUIDs under Networks. If the GUID changes (say, after a NIC driver update or VLAN reassignment), the cluster can't match the old GUID to any live adapter. Deleting the key forces the service to rebuild the list from scratch using the current adapters.

Step 2: If the network is missing but the error persists

Sometimes you see the network in the GUI but it still throws 0xC0130007 on cluster operations. That means the cluster database has a stale route or IPv6 configuration. Here's the fix:

On the node showing the error, run PowerShell as Administrator:

Get-ClusterNetwork

Note the name of the problematic network (e.g., "Cluster Network 1").

Remove and re-add the cluster network role:

Remove-ClusterNetwork -Name "Cluster Network 1" -Force
Add-ClusterNetwork -Name "Cluster Network 1"

Run a validation test:

Test-Cluster -Node $env:COMPUTERNAME

If that fails, check the adapter's IP configuration. The cluster network must use a static IP that's not DHCP. Also confirm IPv6 isn't disabled—I've seen that break cluster heartbeats. Enable IPv6 on the adapter (even if you don't use it) because the cluster service needs it for internal communication.

Less common triggers you should check

I've run into a few edge cases over the years:

NIC teaming gone wrong: After a Windows update, the teaming driver might reorder the member adapters. Check Event ID 1580 in the System log. If you see it, remove and recreate the team in Server Manager.
Hyper-V virtual switch conflict: If this node hosts VMs, the cluster network might share a vSwitch. That's fine, but if the vSwitch was recreated, the cluster loses track. Move VMs to a different vSwitch temporarily, then run the registry fix above.
Third-party firewall software: I've seen McAfee and Symantec endpoint solutions block cluster heartbeats. Temporarily disable the firewall service on the node and test. If the error goes away, add an exception for the cluster network subnet (typically UDP port 3343).

Prevention: Keep this from coming back

Once you've got the cluster stable, do these three things:

Document your NIC GUIDs—run Get-NetAdapter | Select Name, InterfaceGuid on each node and store them. When you replace a NIC, you'll know which GUID changed.
Test patches on a non-production node first—especially ones that update network drivers or the Hyper-V role. Schedule cluster-aware patching using Windows Server's cluster-aware updating (CAU).
Set a static IP on every cluster network—avoid DHCP at all costs. If you must use DHCP, set an infinite lease.

This error is annoying but rarely fatal. With that registry reset and a quick service restart, you'll be back up in under five minutes. If it still won't cooperate, check your network adapter driver version and update it from the OEM, not Windows Update. Good luck.