That error is a pain — here's the fix
I know this error is infuriating. One minute your cluster is humming along, the next you're staring at 0X00001398 and every service is pointing fingers. Let's get it sorted.
The root cause is almost always one node thinks it owns a cluster group, but the cluster disagrees. This usually happens after a node reboot, a network blip, or a failed failover attempt. The cluster state gets out of sync, and the node that isn't the true owner refuses to act.
The direct fix
First, open PowerShell as Administrator on the node showing the error. Then check the group's current owner:
Get-ClusterGroup | Select Name, OwnerNode, StateFind the group that's stuck. If it's not owned by the node you're on, you need to move it. But here's the catch — the move might fail with the same error. So we do this instead:
- Stop the cluster service on the problem node to force a state reset:
Stop-Service -Name ClusSvc -Force- Wait a few seconds, then start it back up:
Start-Service -Name ClusSvc- Now check the owner again. If it's still wrong, force the group to move to the correct node:
Move-ClusterGroup -Name "YourGroupName" -Node "CorrectNodeName"That usually clears it. The service restart forces the node to re-register with the cluster and re-read the group ownership table. It's like giving the node a slap on the back — works most of the time.
Why this works
The cluster uses a quorum-based voting system. When a node goes offline or the network hiccups, the cluster updates the group ownership in its configuration database. But sometimes the node that lost connection doesn't get the memo. Restarting the cluster service forces a full state re-sync. The node re-joins the cluster, sees the current owner, and stops trying to be something it's not.
There's also a simpler reason: stale process handles. Cluster services cache group ownership in memory. A restart flushes that cache. I've seen this fix work on Server 2016, 2019, and 2022 — same behavior every time.
What if the restart doesn't fix it?
Sometimes the cluster group itself is corrupted. In that case, you'll need to evict the node and add it back. That's a bit more invasive, but it's the nuclear option:
Remove-ClusterNode -Name "ProblemNode" -Force
Add-ClusterNode -Name "ProblemNode"Note: This will cause a brief outage for services hosted on that node. Do it during a maintenance window. Also, make sure you have valid quorum before you evict — otherwise you might lose the whole cluster.
Less common variations
Sometimes 0X00001398 pops up not on a node, but during a cluster validation test. That's a different beast — it means the validation tool found a configuration mismatch. Run this to see the details:
Test-Cluster -ValidateAll -ReportName "ClusterValidation"Look for any warnings about group ownership or network binding order. If you see network adapter issues, that's your culprit. The cluster needs a dedicated network for heartbeat communication. If it's sharing a NIC with regular traffic, you'll get flaky behavior that eventually triggers this error.
Another variant: you get the error when trying to add a new node to the cluster. That usually means the new node can't reach the cluster's quorum. Check the firewall — ports 3343 (TCP/UDP) for cluster communication, and 445 for SMB. I've also seen this when the new node has a different time offset. Network Time Protocol (NTP) drift of more than 5 minutes will cause authentication failures, which shows up as this exact error.
Prevention
You can avoid this headache in the future with a few habits:
- Always shut down nodes gracefully. Don't yank the power unless you absolutely have to.
- Keep the cluster network isolated. Use a separate VLAN for heartbeat traffic.
- Monitor event log for cluster warnings — especially event ID 1135 (node lost communication).
- Test failover regularly. A monthly failover test can catch these issues before they bite you.
The real fix is prevention, but when the error hits, don't panic. Restart the cluster service, move the group, and you're back in business. If that fails, evict and re-add. I hope this saves you the late-night surgery I went through the first time.