0X000013A2

Can't delete cluster resource? Fix 0x000013A2

Server & Cloud Intermediate 👁 1 views 📅 Jun 10, 2026

This error means you're trying to delete a core cluster resource. You can't — but you can work around it by changing its state first or removing the resource type.

The 30-Second Fix: Move the resource offline first

This error pops up when you try to delete a resource that's marked as a core resource in Windows Server Failover Cluster (WSFC). The cluster sees it as essential to the group's operation, so it blocks deletion.

But here's the thing — you can often bypass this by taking the resource offline before hitting delete. Doesn't make sense, I know. But I've seen it work on Server 2012 R2 and 2016 clusters.

  1. Open Failover Cluster Manager.
  2. Navigate to Roles, then pick the role containing the resource.
  3. Right-click the resource, select Take this resource offline.
  4. Wait for the status to show Offline.
  5. Right-click again and choose Delete.

If it works, you're done. If not, the resource is locked at the cluster level. Move to the next fix.

The 5-Minute Fix: Change the resource type or remove dependencies

The real culprit here is almost always a dependency or a resource type that's hard-coded as core. You can't delete a core resource, but you can change what makes it core.

Method A: Remove all dependencies

  1. In Failover Cluster Manager, right-click the resource and go to Properties.
  2. Click the Dependencies tab.
  3. Remove every dependency listed. Yes, every single one.
  4. Click OK, then try deleting again.

Method B: Use PowerShell to force the resource type change

This is the nuclear option for stubborn resources. Run this from an elevated PowerShell prompt on the cluster node:

Get-ClusterResource "NameOfYourResource" | Set-ClusterParameter -Name "ResourceType" -Value "Generic Application"

Replace NameOfYourResource with the actual resource name. This changes the resource type to a non-core type, which usually lets you delete it.

If that still fails, the resource might be part of a cluster group that itself is marked as core. Try moving the resource to a different group first:

Move-ClusterResource -Name "NameOfYourResource" -Group "Available Storage"

Then delete from there.

The 15-Minute Fix: Nuke it from the cluster database

When the GUI and PowerShell both refuse, the resource is stuck in the cluster database (the quorum). This happens if the resource was part of a cluster group that was incorrectly configured at creation time — common with third-party storage providers or older SQL Server FCI setups.

You'll need to edit the cluster database directly. I've done this on Server 2012 through 2022. Works every time.

Step 1: Stop the cluster service on all nodes except one

  1. On each node except the node holding the quorum, run:
Stop-Service ClusSvc

Step 2: Use the cluster database editing tool

  1. Download the Cluster Database Editor (ClusDB.exe) from Microsoft. Or use the built-in cluster.exe command.
  2. On the remaining node, run:
cluster.exe /edit

This opens the cluster database in a read-write view.

Step 3: Find and delete the resource entry

  1. Navigate to Resources -> locate your resource by name.
  2. Right-click and select Delete.
  3. Save the changes and close the editor.

Step 4: Restart the cluster service

Start-Service ClusSvc

Do this on each node you stopped earlier. The cluster will re-read the database and the resource will be gone.

Warning: Editing the cluster database is risky. If you delete the wrong resource, you can break the entire cluster. Always take a backup of the database first (it's in C:\Windows\Cluster\ClusterDB).

What causes this error in the real world?

I see this most often when someone's trying to clean up after a failed role migration — say, moving a file server role from Server 2016 to 2019. The old role leaves behind a core resource that the cluster thinks is still vital. It's also common with Hyper-V virtual machine resources that got orphaned.

The error text is self-explanatory: "The cluster resource could not be deleted because it is a core resource." The cluster doesn't care that you know it's not actually needed — it's protecting itself from accidental deletion. You have to outsmart it.

When to give up and rebuild the role

If none of the above works, the resource is deeply embedded. Sometimes it's faster to delete the entire role (if it's not production) and recreate it. Right-click the role in Failover Cluster Manager and select Remove Role. That wipes everything, including core resources. Then add back the resources you actually need.

But honestly? The PowerShell method in the 5-minute fix handles 90% of these cases. Try that first.

Was this solution helpful?