Fix ERROR_CLUSTER_NODE_NOT_PAUSED (0x000013c2)

When this error actually shows up

You're trying to drain a node for maintenance, or maybe you're running Move-ClusterGroup with the -IgnorePause flag set wrong. The exact trigger: you issued a command like Suspend-ClusterNode -Drain against a node that was already running normally, and then tried some operation that expects the node to be paused. Or you're scripting a failover and got hit with Error 0x000013C2 — "The cluster node is not paused."

What's actually happening here is that the cluster API is enforcing a state precondition. Some cluster operations — like evicting a node or certain maintenance-driven moves — require the node to be in the Paused state first. If it's not paused, the API returns 0x000013C2. It's not a bug. It's the cluster saying "hey, you said to do something that only makes sense if this node is paused, but it's not."

Root cause

The cluster node state machine has three main states: Up, Paused, and Down. Up means it's participating normally. Paused means you've told the cluster "hands off — this node can't take new workloads." Down means the node is unreachable or the cluster service isn't running.

The reason you hit 0x000013C2 is almost always one of these:

You ran a drain command, but the node never actually transitioned to Paused (maybe a resource failed to move and the drain timed out).
You're scripting a node removal and forgot to pause first.
You're using Add-ClusterNode with the Existing parameter on a node that's already part of a different cluster — but that's a different error code.
Third-party backup or management software tried to pause the node but the cluster service didn't agree.

Skip trying to fix permissions or restarting services — the cluster node state is authoritative. You need to either put it into the Paused state, or stop asking for an operation that requires it.

The fix

Check the node's current state. Open PowerShell as admin on any node in the cluster. Run:
```
Get-ClusterNode | Format-Table Name, State -AutoSize
```
Look for your node. If it says Up, you have to pause it before retrying the operation.
Pause the node with drain. This moves all cluster roles off the node gracefully:
```
Suspend-ClusterNode -Name "NodeName" -Drain
```
Replace NodeName with the actual node name. The -Drain flag tells the cluster to move resources first, then pause. Without it, you'd just pause and the resources stay — which isn't what you usually want.
Wait for the drain to finish. Run this to see if the node is paused:
```
Get-ClusterNode -Name "NodeName" | fl State, DrainStatus
```
You want State: Paused and DrainStatus: Completed. If it's stuck on DrainInProgress for more than a few minutes, a resource probably refused to move. Check the cluster event log (FailoverClustering/Operational) for specific resource failures.
Retry your original operation. Whether it's evicting the node, running a validation test that requires paused state, or moving a specific group — it should work now.
If you were trying to do something that doesn't actually need a paused node (like just moving a single role), skip the pause entirely. Use Move-ClusterGroup without -IgnorePause and it won't require a paused node.

Still failing?

If you've paused the node and still get 0x000013C2, here's what to check:

Are you running the command against the right node? Sounds stupid, but I've seen scripts target the wrong variable. Double-check the node name in your command matches the output from Get-ClusterNode.
Did the node bounce back to Up? Rare, but if the cluster service restarted on that node, it'll revert to Up automatically. Check Get-ClusterNode again.
Is the cluster quorum healthy? If the cluster lost quorum, no state changes are honored. Run Get-ClusterQuorum and make sure it says Quorum: +- not Quorum: -.
Are you using Windows Server 2012 R2? There's a known issue with Suspend-ClusterNode -Drain where it sometimes doesn't set the node to Paused if a CSV (Cluster Shared Volume) is involved. The fix there is to manually move CSV ownership first with Move-ClusterSharedVolume, then pause.

If none of that helps, run a cluster validation test against the node. It'll expose any deeper issues like broken networking or disk arbitration problems that prevent the pause from sticking.

Test-Cluster -Node "NodeName" -Include "Storage", "Network" -ReportName "C:\temp\validation.htmp"

Open that report and look for failures under Verify Node States or Verify Cluster Service Responsiveness. That'll point you to the actual hardware or configuration problem.