Fix 0X00001397: Host Node Not Resource Owner

Quick answer: Run Get-ClusterResource | Where State -ne Online to find the offending resource, then use Failover Cluster Manager to move it back to its preferred owner, or evict and re-add the node if the cluster state is corrupted.

Why this happens

I've seen this 0X00001397 pop up in two main scenarios. First, when a node comes back online after a forced shutdown or a network blip, and the cluster service hasn't properly synced ownership for a specific resource. Second, when a resource was manually moved or failed over, but the preferred owner settings got out of sync. The cluster database thinks node A owns the resource, but node B is actually running it. That mismatch triggers this error, and it'll keep nagging you until you realign things.

It's most common on Windows Server 2016 and 2019 clusters with File Server or Storage Replica roles, but I've also seen it on SQL Server FCI setups. The good news: it's rarely a hardware failure. It's usually a configuration or state issue you can fix in minutes.

Step-by-step fix

Identify the resource and its owner. Open PowerShell as admin and run:
```
Get-ClusterResource | Select Name, OwnerNode, State
```
Look for resources where OwnerNode is None or where the state is Failed or Offline. That's your culprit.
Check the preferred owners. For each problematic resource, run:
```
Get-ClusterResource "YourResourceName" | Get-ClusterOwnerNode
```
If the current owner isn't in the preferred list, that's your mismatch. Add it or change the preferred owner to match.
Force a move. The cleanest way to reset ownership is to move the resource to another node and back. In Failover Cluster Manager, right-click the resource, select Move, then pick a different node. Wait for it to come online, then move it back to the original owner.
If that fails, evict and re-add the node. This is the nuclear option, but it works when the cluster database is corrupted. Right-click the node in Failover Cluster Manager, select More Actions → Evict. Then right-click the cluster, select Add Node, and re-add the node. This forces a full cluster reconfiguration.
Validate the cluster. After any fix, run the validation wizard to make sure the cluster is healthy. It'll catch storage and network issues before they bite you again.

Alternative fixes that sometimes work

Reset the cluster service on the node

Sometimes the cluster service on the node is just in a weird state. On the affected node, open an elevated PowerShell and run:

Stop-Service -Name ClusSvc
Start-Service -Name ClusSvc

Then check if the resource comes back online. This is quick and harmless, so it's worth trying before evicting the node.

Check for time drift

I've had this error on a cluster where one node had a 5-minute clock drift after a BIOS update. Severe time skew can confuse the cluster's internal state. Verify all nodes are syncing to the same NTP source and the time difference is under a second.

Don't ignore Event IDs

The cluster logs will usually tell you more. Look for Event ID 1069 or 1135 in the System log around the same time. Those often reference the specific resource or node that's causing the problem. If you see a disk-related event, run Get-ClusterResource | Test-ClusterResource to test the health of that resource.

Prevention tips

The single best thing you can do is keep your preferred owner settings clean. Every time you add a resource, explicitly set the preferred owners and the failover threshold. When you do maintenance, don't mess with the resource ownership manually unless you're ready to realign it afterward.

Also, set up a script that periodically checks cluster resource states and emails you when a resource is on a non-preferred node. I use a scheduled task that runs every 15 minutes and alerts if the owner differs from the preferred. That way you catch the mismatch before it becomes a service outage.

Finally, patch your cluster nodes consistently. This error is more common on older builds of Windows Server 2019. Make sure you're on the latest cumulative update, because Microsoft has fixed several cluster state sync bugs in recent patches.

If none of these steps clear the error, you might be dealing with a deeper issue like a corrupted cluster database. In that case, plan a maintenance window and rebuild the cluster from scratch. It's painful, but it resets everything and gives you a clean slate.