Fix ERROR_CLUSTER_OWNER_NOT_IN_PREFLIST 0X000013DA

You're staring at Event ID 0X000013DA in your cluster logs. The exact text: ERROR_CLUSTER_OWNER_NOT_IN_PREFLIST. This shows up when you try to bring a cluster resource online on a node that's not in its preferred owners list. Happens a lot after adding a new node to an existing cluster and failing over a resource group, or when you manually move a resource to a node that wasn't originally configured to host it.

I had a client last month running Windows Server 2019 — they added a third node to a two-node cluster for a file server role. When they tried to move the file share witness to the new node, it failed with this exact error. The root cause? The preferred owners list for that resource was still set to the original two nodes only. The cluster won't let you bypass that list unless you update it first.

The cluster resource model is strict about this. Each resource has a property called PreferredOwners. That's a list of nodes that are allowed to own it. If the node you're targeting isn't in there, the cluster throws 0X000013DA and refuses the operation. There's no workaround — you have to either add the node to the list or move the resource to a node that's already listed.

What triggers this error

• Adding a new node to a cluster and trying to assign existing resources to it.
• Manually moving a resource group via Failover Cluster Manager or PowerShell to a non-preferred node.
• Automatic failover during a node outage — if all preferred nodes are down, the cluster won't auto-failover to a non-preferred node (that's by design).
• Scripting a move without checking the preferred owners list first.

How to fix it

There are two paths depending on what you want. Option A: Add the target node to the preferred owners list. Option B: Move the resource to a node already in the list. I recommend Option A if you're adding capacity, Option B if it's a temporary move.

Option A: Add the target node to PreferredOwners

1. Open Failover Cluster Manager. Connect to your cluster.
2. In the left pane, expand Roles. Find the role that has the resource causing the error.
3. Right-click the role and select Properties.
4. Go to the General tab. Under Preferred Owners, you'll see a list of nodes. Click Add and select the node you want to add.
5. Click OK to save. The cluster will update the resource's preferred owners list.
6. Now try moving the resource to that node. It should work.

Or do it in PowerShell — my preferred method when pushing changes to multiple resources:

Get-ClusterResource "YourResourceName" | Set-ClusterOwner -Owners "Node1", "Node2", "Node3"

Replace YourResourceName with the actual resource name. List all nodes that should be allowed to own it. Run this from a domain admin account on any cluster node.

Option B: Move the resource to a node already in the list

1. In Failover Cluster Manager, under Roles, right-click the role and choose Move > Select Node.
2. A dialog shows you which nodes are available — those are the ones already in the preferred owners list. Pick one.
3. If the node you want isn't listed, you can't move it there without first adding it to the list. See Option A.

What to check if it still fails

• Verify the node is online and cluster-aware. Run Get-ClusterNode in PowerShell. Make sure the node shows State = Up.
• Check resource dependencies. Some resources have dependencies that also have their own preferred owners lists. If a dependent resource doesn't include the target node, the parent resource won't work either. Check each dependency's properties.
• Look at cluster quorum settings. If the node isn't part of the quorum, the cluster might block ownership changes. Run Get-ClusterQuorum to verify.
• Check permissions. The account you're using needs Full Control on the cluster. If it's a service account, make sure it has the right permissions in AD.
• Review the cluster log. Run Get-ClusterLog -Destination C:\Logs and search for the error ID. It'll tell you exactly which resource and node are conflicting.
• Reboot the node. Yeah, I know it's cliché, but sometimes a node's cluster service gets stuck. Reboot clears it. Had a case where a pending Windows update caused this — reboot fixed it.

This error is straightforward once you understand the logic. The cluster is just enforcing its rules. Update the preferred owners list, and you're golden. Skip that, and you'll keep hitting the same wall. Save yourself the time — always check the list before moving resources to new nodes.