0X000013CB

Fix Cluster Network Has Dependents (0x13CB)

EP
Erropedia Team
📅 August 23, 2026 📅 Updated Sep 8, 2026 👁 22 views Network & Connectivity Intermediate
This Failover Clustering error blocks network changes when resources depend on it. Here's how to clear those dependencies and get moving again.

Quick answer: The network can't be changed or removed because cluster resources still depend on it—identify those dependencies with PowerShell, remove or move them, then retry.

This error is a classic Failover Clustering headache. You try to take a network offline, change its role, or delete it, and Windows slams the door with ERROR_CLUSTER_NETWORK_HAS_DEPENDENTS. It's not a hardware fault; the cluster is protecting itself. The network is the backbone for client connections—maybe it's the one hosting a file share witness, or it's the only path to a storage array. The cluster won't let you cut that lifeline while resources are still using it.

I've seen this trip up admins during routine maintenance. You're trying to decommission a network after a server migration, or you're reconfiguring IP ranges, and suddenly the whole cluster refuses to cooperate. Don't panic, and don't try to force it. The fix is straightforward, but you need to be methodical.

Step 1: Identify what's holding the network

Fire up PowerShell as Administrator on any cluster node. First, get the network's name and state:

Get-ClusterNetwork

Note the name of the network throwing the error. Then list every resource that depends on it:

Get-ClusterResource | Where-Object { $_.Dependencies -like "*<NetworkName>*" } | Format-Table Name, State, OwnerNode

Replace <NetworkName> with the actual network name. This shows you the dependents. In my experience, it's usually a Client Access Point (CAP) or an IP address resource that's the culprit.

Step 2: Move or remove the dependencies

Now you have two choices: move the dependent resources to another network, or delete them if they're no longer needed.

To move a resource (like a CAP) to a different network, use:

Move-ClusterResource -Name "Cluster IP Address" -Group "Cluster Group"

Wait, that's not right for moving to another network. Actually, you need to change the resource's network—either through Failover Cluster Manager (right-click the resource, Properties, Dependencies tab) or by editing the resource's possible owners. For an IP address resource, you'd remove the old IP and add a new one on the target network.

If the resource is obsolete, just remove it:

Remove-ClusterResource -Name "OldResourceName"

Do this for each dependent resource until Get-ClusterResource shows no dependencies on the problem network.

Step 3: Retry the network operation

Once the dependencies are cleared, go back to Failover Cluster Manager or PowerShell and try your original action again—whether that's taking the network offline or removing it.

Set-ClusterNetwork -Name "NetworkName" -State Offline

If it still fails, run Get-ClusterNetwork again to double-check you didn't miss a dependent resource. I've had cases where a hidden dependency—like a resource not shown in the default view—lurked behind. Use the cluster validation report too:

Test-Cluster

It can surface hidden dependencies.

If that doesn't work: check the cluster configuration

Sometimes the dependency isn't obvious. It could be a resource that's offline or in a failed state but still references the network. In that case, you might need to evict the resource entirely:

Remove-ClusterResource -Name "StuckResource" -Force

But be careful—force-removing a resource can break the cluster if that resource was essential. Only do this if you're sure it's a zombie resource. In one deployment, I had a leftover IP address resource from an old CAP that wouldn't die. Force removal worked, but I made sure the CAP was already gone.

Another culprit: the cluster network might be marked as the cluster's heartbeat network, and you can't take it offline even if no resources depend on it. Check with:

Get-ClusterNetwork | Format-List Name, Role

If the role is ClusterAndClient or ClusterOnly, you need to change it to ClientOnly (or something else) before you can remove it:

(Get-ClusterNetwork -Name "NetworkName").Role = 0

Then retry.

Prevention: keep your dependencies tidy

Here's the thing—this error is a symptom of messy cluster hygiene. If you'd cleaned up old resources when you decommissioned services, you'd never see it. So, my advice:

  • Audit your cluster resources quarterly. Remove any that are no longer in use.
  • Always move resources to a new network before retiring the old one.
  • Document which networks carry which roles—especially witness and storage traffic.

Do that, and you'll rarely see 0x13CB again. When you do, you'll know exactly where to look.

Related Errors in Network & Connectivity
Wi-Fi Says Connected But No Internet — Real Fix 0X80100019 SCARD_E_PCI_TOO_SMALL (0X80100019) on Windows — quick fix 0X0000232D DNS RCODE REFUSED 0x232D: Why Servers Say No and How to Fix 0X00002552 DNS Error 0x00002552: Why It Happens and How to Fix It Fast
ERROR_CLUSTER_NETWORK_HAS_DEPENDENTS 0x000013CB Failover Clustering cluster network dependencies remove cluster network cluster resource dependencies Windows Server cluster network configuration error cluster network offline

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.