DFSRoot Already Exists on Cluster Node — Fixing 0X000013E0

The Short Version

You're seeing ERROR_CLUSTER_NODE_ALREADY_HAS_DFS_ROOT (0X000013E0) when trying to add a DFS namespace to a failover cluster node. Windows thinks that node already hosts a DFS root — even if you can't see one. The fix is straightforward: remove the stale DFS root entry using dfsutil or poke the registry.

The Fix That Works 9 Times Out of 10

Open PowerShell as Administrator on the affected cluster node. Run this:

dfsutil root remove \\SERVER\ShareName

Replace SERVER with the cluster's network name and ShareName with the actual DFS root share. If you don't know the share name, list all DFS roots first:

dfsutil root view

If that command returns nothing (which happens when the root is orphaned), the culprit is almost always the registry. Go to:

HKLM\SYSTEM\CurrentControlSet\Services\Dfs\Roots\Standalone

Delete the key that matches the old DFS root name. Do the same under \Domain if it's a domain-based root. Reboot the node — yes, you still have to reboot after registry changes here. Don't skip it.

After the reboot, try adding your DFS namespace again. It'll work.

Why This Happens

When a DFS root is created on a cluster node, Windows stores that info in both the registry and the DFS namespace metadata. If the original root was removed improperly — say, the cluster role was deleted without cleaning up DFS, or you moved the namespace role to another node and it left a ghost — the registry entry stays. The cluster service then refuses to create a new root because it sees the old one. It's a safety lock, but a poorly designed one. It doesn't distinguish between a live root and a dead registry key.

Less Common Variations

Sometimes the error shows up even after you've deleted the registry keys. That's because the DFS namespace itself is still referenced in the AD (for domain-based roots) or in the cluster's resource list. Here's what to check:

• AD cleanup. For domain-based DFS roots, open Active Directory Users and Computers, go to System\DFS-Configuration, and delete any orphaned fTDfs objects. Use ADSI Edit if you're comfortable. I've seen these hang around for days after removal.
• Cluster resource ghost. Open Failover Cluster Manager, check under Roles for any DFS Namespace Server resource that's in a failed state. Delete it. Then run Get-ClusterResource | Where-Object {$_.ResourceType -eq 'DFS Namespace Server'} in PowerShell to confirm nothing's left.
• Third-party backup software. I've seen CommVault and Veeam create hidden DFS root entries during backup restore operations. Disable any DFS-related plug-ins in your backup software, then re-run the cleanup steps above.

If none of that works, the nuclear option is to restart the DFS service on every cluster node:

Stop-Service dfs, dfsr, dfssvc; Start-Service dfs, dfssvc

Then repeat the registry removal. This clears any in-memory caching that's holding onto the old root.

Prevention

Don't delete a DFS namespace role directly from Failover Cluster Manager without first removing the DFS root via DFS Management console. Use the proper order:

1. Open DFS Management, right-click the namespace, select Remove.
2. Wait 30 seconds.
3. Then delete the role in Failover Cluster Manager.

Also, never move a DFS namespace role between cluster nodes without removing it from the source node first. That's how these ghosts appear. Keep a quick checklist on the wiki for your team — or just remember: DFS Management first, then cluster.