Fix ERROR_CLUSTER_NETWORK_NOT_FOUND 0x13B5

0x13B5 hits when the cluster service can't find a network it expects. Usually a NIC got renamed, disabled, or dropped off the cluster. Re-add or clean up the network entry and it clears.

You bring a node back online after a NIC swap, open Failover Cluster Manager to check things, and there it is: ERROR_CLUSTER_NETWORK_NOT_FOUND (0x000013B5) — The cluster network was not found. Or you're running Add-ClusterNode and it blows up mid-join because two nodes can't agree on which network is which. I've seen both. Most recent case was a client who swapped a failed Intel X550 for a broadcom NIC on a 2-node SQL cluster — same subnet, same IPs, but the cluster kept throwing 0x13B5 for two hours until I cleaned up the stale network object.

What's actually going wrong

A failover cluster keeps its own database of networks. Every NIC that teams or clusters care about gets registered as a cluster network object, tied to a network interface GUID. The error means the cluster service tried to reference a network that either no longer exists in that database, no longer matches the live NIC, or was referenced by a role/resource that's pointing at a ghost.

Common triggers:

You replaced or renamed a physical NIC. Windows generates a new interface GUID. The cluster still holds the old one.
Someone disabled a NIC in Device Manager or ncpa.cpl that the cluster had registered.
A vSwitch on Hyper-V hosts got recreated, so the vNIC GUID changed underneath the cluster.
You moved a node between subnets, or a DHCP lease changed the network category and the cluster couldn't classify it.
A leftover cluster network from a removed node is still in the DB and something (usually a client access point or a cluster IP resource) still references it.

It is almost never an actual network outage. The wire is fine. The cluster's bookkeeping is wrong.

The fix, step by step

Run everything from an elevated PowerShell on a node that's currently Up in the cluster. If a node won't come up, work from any surviving node.

Look at what the cluster thinks it has. Compare that to what's really there.
```
Get-ClusterNetwork | Format-Table Name, Id, Role, Address, State
Get-NetAdapter | Format-Table Name, InterfaceGuid, Status, LinkSpeed
```
Any cluster network with State of Down, or an Id that doesn't line up with a live adapter, is your suspect. You'll usually see one entry that says "Cluster Network 3" or similar with no address.
Check what's referencing the dead network. Cluster IP resources and client access points hold a network reference. If one of those points at the dead entry, that's your 0x13B5.
```
Get-ClusterResource | Where-Object { $_.ResourceType -eq 'Network Name' -or $_.ResourceType -eq 'IP Address' } | Get-ClusterParameter Network
```
Re-register the live NIC with the cluster. If the adapter exists but isn't in the cluster DB, add it back.
```
Add-ClusterNetwork -Network "Ethernet 2"
```
Replace with the actual adapter name from Get-NetAdapter. You can also do this in Failover Cluster Manager under Networks → right-click → Add Network.
Fix the role. If a resource is still bound to the dead network, update it:
```
Get-ClusterResource "Cluster IP Address" | Set-ClusterParameter -Name Network -Value "Cluster Network 2"
```
Substitute the correct network name from step 1. Then bring the resource online.

Remove the ghost. Once nothing references the stale entry, delete it.

Get-ClusterNetwork -Name "Cluster Network 3" | Remove-ClusterNetwork

Re-run validation across the network category. This catches any remaining mismatches before the next failover surprises you.
```
Test-Cluster -Node node1,node2 -Include "Network"
```

The network name in the cluster database is not the same as the adapter name in Windows. It's a cluster-assigned label like "Cluster Network 1". Don't mix them up when you're writing commands — a lot of 0x13B5 tickets I've picked up are people adding the wrong NIC into the mix.

If it still fails

Work through these in order:

Check the interface binding. In Failover Cluster Manager, open each network, right-click Properties, and confirm the cluster is allowed to use it. If "Do not allow cluster network communication" is set on the only healthy NIC, the cluster still can't function even though the NIC is there.
Look for orphaned cluster network objects that don't appear in Get-ClusterNetwork but are referenced by an IP address resource. Get-ClusterResource | Get-ClusterParameter will show you what each resource points at.

Re-IP'd nodes. If you changed subnets, the cluster may need the network classification reset. Set it explicitly:

Get-ClusterNetwork "Cluster Network 2" | Set-ClusterParameter -Name Role -Value 1
# 1 = ClusterAndClient, 0 = None, 3 = ClusterOnly

Check the Cluster log. It tells you exactly which resource or node threw 0x13B5 and against which network ID:
```
Get-ClusterLog -TimeSpan 30 -Destination .\clusterlog
```
Look for 0x13b5 or ERROR_CLUSTER_NETWORK_NOT_FOUND in the output — the adjacent GUID is your culprit.
Hyper-V vSwitch rebuilds. If the host lost its vSwitch, all vNICs get new GUIDs and the cluster's entire network map goes stale. In that case, remove and re-add every cluster network once the vSwitch is stable. Don't try to patch it NIC by NIC — you'll chase your tail.
Last resort: if the cluster is small and you've got recent config exports, evicting and re-joining the affected node is faster than surgery. I mean it. Two hours of fiddling versus a 20-minute evict/rejoin — sometimes the rejoin wins. Back up the cluster config first with Get-Cluster | Export-Clixml cluster-config.xml.

The thing to remember: 0x13B5 is a bookkeeping error, not a cable error. Fix the cluster's view of the network and the error goes away.