Fix ERROR_CLUSTER_MISMATCHED_COMPUTER_ACCT_NAME (0X00001711)

When Does This Error Show Up?

You're setting up or managing a Windows Failover Cluster. You've got a Client Access Point (CAP) resource—the network name that clients use to connect to your cluster. Suddenly, it won't come online. You check the cluster log, and there it is: ERROR_CLUSTER_MISMATCHED_COMPUTER_ACCT_NAME (0X00001711). The error message says something like "The name of the corresponding computer account does not match the network name for this resource."

I've seen this most often after a domain migration or when someone renames a cluster. Had a client last month who moved their cluster to a new domain, and every single CAP resource broke with this error. The IP address might still ping, but the name won't resolve or authenticate.

What's Actually Going On?

Under the hood, Windows clusters create a computer account in Active Directory for each CAP resource. That computer account has a Service Principal Name (SPN) tied to it—specifically, the HOST/ and MSClusterVirtualServer/ SPNs. The cluster expects that computer account's name to match the network name you specify for the resource. If they don't match (because the account got orphaned, renamed, or created with a different name), the resource refuses to come online.

Root cause is almost always one of these:

• The computer account in AD was manually renamed or deleted.
• The cluster resource's network name was changed after the account was created.
• An SPN conflict exists—another object in AD has the same SPN.
• The account was created in a different OU or container than expected.

How to Fix It

Step 1: Take the Resource Offline

Open Failover Cluster Manager. Find the affected CAP resource (usually named something like "Cluster Name" or "SQL Server Network Name"). Right-click it and choose Take Offline. If it's already offline, skip this step. Don't try to force it online yet—that'll just produce the same error.

Step 2: Check SPNs for Conflicts

Run this from an elevated command prompt on any cluster node:

setspn -Q HOST/yourNetworkName
setspn -Q MSClusterVirtualServer/yourNetworkName

Replace yourNetworkName with the actual resource name. If you see more than one object returned for either SPN, you've got a conflict. Note the conflicting object's name—you'll need to remove the duplicate SPN from it using setspn -D.

Step 3: Delete the Old Computer Account

Open Active Directory Users and Computers. Find the computer account that matches your CAP resource's network name. It's usually in the Computers container or a custom OU. Right-click it and choose Delete. Yes, delete it. The cluster will re-create it with the correct name.

Important: If you're running a SQL Server or Exchange cluster, double-check that the account isn't being used by other services. In most cases, it's safe to delete because the cluster manages it, but if you're paranoid, take a backup of the account's attributes first.

Step 4: Re-create the Computer Account from the Cluster

Back in Failover Cluster Manager, right-click the CAP resource and choose Bring Online. The cluster will attempt to create a new computer account in AD. This should succeed if:

• The cluster service account has permission to create computer objects in the target container.
• No duplicate SPNs exist (you already checked in step 2).
• DNS is working—the cluster tries to register A and PTR records.

If it still fails with the same error, move to the next step.

Step 5: Manually Re-create the Account with PowerShell

Sometimes the cluster's automatic creation fails because of delegation issues or permission boundaries. Use this PowerShell from a domain-joined machine with appropriate AD permissions:

$name = "yourNetworkName"
New-ADComputer -Name $name -Enabled $true -Path "CN=Computers,DC=yourdomain,DC=com"
Grant-ClusterAccess -User $name$ -Full

Replace the path with the correct container. Then in Failover Cluster Manager, right-click the resource and choose Bring Online. The cluster should pick up the existing account.

What If It Still Fails?

If you're still staring at error 0x00001711 after these steps, check these three things in order:

1. Permissions: The cluster service account (usually a gMSA or a domain user) needs Create Computer Objects rights in the target OU. Without that, the cluster can't create or update the account. Check your AD delegation.
2. DNS Scavenging: If the DNS record for the network name was scavenged, the cluster might fail to register it. Delete any stale A or PTR records manually from DNS, then try bringing the resource online again.
3. Recreate the Entire Resource: As a last resort, delete the CAP resource entirely (including its dependent IP address resource) and recreate it with a new network name. This forces a clean slate. I've had to do this twice in ten years—once because a domain controller's time was skewed by 5 minutes, causing Kerberos to reject the computer account.

One final tip: if you're running Windows Server 2012 R2 or earlier, check for a known issue where the computer account gets stuck in a disabled state. Enable it manually in AD, then run cluster.exe resource resourcename /online from the command line.