Fix ERROR_CLUSTER_GROUP_MOVING (0X00001714) in Failover Clusters

Quick answer: Run Get-ClusterGroup -Name <GroupName> | Stop-ClusterGroup -Force, then move the group again. That clears the stuck move state 90% of the time.

I've seen this error a lot in Hyper-V and SQL Server clusters running Windows Server 2016–2022. It usually pops up when someone tries to move a group (like a virtual machine or a clustered application) that's already in the middle of a move. Maybe the previous move timed out, or a resource inside the group is holding a lock. The cluster API won't queue another move — it just throws 0X00001714 and says "nope."

This tripped me up the first time too. I'd click "Move" in Failover Cluster Manager and get nothing but error. The fix is straightforward once you know where to look.

Step-by-step fix

1. Identify the stuck group. Open Failover Cluster Manager or run Get-ClusterGroup in PowerShell. Look for a group with state Partially Online or Pending. That's your culprit.
2. Check the move status. Run Get-ClusterGroup -Name <GroupName> | fl *move*. If OwnerNode is blank or shows a node you didn't expect, the move is still pending.
3. Force stop the group. In PowerShell (as admin): Get-ClusterGroup -Name <GroupName> | Stop-ClusterGroup -Force. This takes the group offline forcefully. Yes, it will disrupt whatever service is running — but if the group is half-moved, it's already broken anyway.
4. Wait 10–15 seconds for the state to settle. Verify with Get-ClusterGroup -Name <GroupName>. You should see State: Offline.
5. Move the group again. Now run Move-ClusterGroup -Name <GroupName> -Node <TargetNode>. Or use the GUI — it should work cleanly now.

If the main fix doesn't work

Sometimes Stop-ClusterGroup -Force hangs. That usually means a resource inside the group is locked by a live process (like an open file handle or a pending backup).

• Check individual resource states. Run Get-ClusterResource -Group <GroupName> | fl Name,State,OwnerNode. If any resource shows Failed or Pending, try Stop-ClusterResource -Name <ResourceName> -Force on that resource alone.
• Use cluster log to see why. Run Get-ClusterLog -Group <GroupName> -Destination C:\Temp and open the .log file. Search for "0x00001714" or "MOVING". You'll often see a resource that's stuck in Offline in Progress. The log tells you exactly which resource.
• Reboot the owner node. If you can take the outage, a clean reboot of the node owning the group kills all locks and resets the cluster service. Do this only if you've tried everything else — it's a sledgehammer.

Prevention tips

• Don't double-click. I've seen admins impatiently click "Move" twice. Wait for the first move to complete — check the GUI or PowerShell for state changes.
• Update cluster validation. Run Test-Cluster quarterly. Stale network settings or mismatched DNS registrations can cause moves to time out, leaving the group stuck.
• Set cluster move timeouts. In advanced scenarios, adjust SameSubnetDelay and CrossSubnetDelay in cluster parameters to give moves more time. Defaults are 2000ms — sometimes that's too tight for large groups with many resources.
• Monitor with event logs. Watch Event ID 1135 (cluster service failed to respond) and Event ID 1233 (group move failed). Catching these early stops the error from happening repeatedly.

That's the whole fix. No registry hacks, no re-installations. Just a clear, force stop and a clean move. If you're still stuck after this, check the cluster logs — they always tell the truth.