0XC00002A1

Fix STATUS_DS_NO_ATTRIBUTE_OR_VALUE 0XC00002A1 in Active Directory

Server & Cloud Intermediate 👁 8 views 📅 May 28, 2026

This error usually pops up when AD can't find an attribute during replication or authentication. Here's how to kill it fast.

The 30-Second Fix: Check This First

Before you dive into anything heavy, check if it's just a stale cache or a temporary glitch. The culprit here is almost always one of two things: a recent domain controller demotion that left behind metadata, or a USN rollback from an improper restore.

If you just demoted a DC, run this on every other DC:

repadmin /removelingeringobjects <DC_NAME> <FQDN> /advisory_mode

If that doesn't scream errors, run it again without /advisory_mode to purge stale objects. Then force replication:

repadmin /syncall /AdeP

Still no luck? Move on.

The 5-Minute Fix: Reset the Machine Account

Sometimes the error hits during authentication, not replication. If you see this on a specific server or workstation trying to join the domain, reset its computer account in AD:

  1. Open Active Directory Users and Computers.
  2. Find the computer object, right-click, and select Reset Account.
  3. Disjoin the machine from the domain, reboot, rejoin it.

I've seen this fix 0XC00002A1 on Windows Server 2022 boxes that had their AD account corrupted by a failed schema update. Don't skip the reboot — it forces the machine to request a new secure channel.

If the error is on a domain controller itself, you'll need a different approach. Check if the DC's NTDS settings object is missing replication partners:

repadmin /showrepl

If you see a broken link, use ADSI Edit to delete the stale NTDS Settings object under the DC's computer object, then let KCC rebuild it:

repadmin /kcc

Wait five minutes and check event logs for 0xC00002A1. If it's gone, you're done.

The 15-Minute Fix: Deep Clean with ntdsutil

When the simple stuff fails, you're looking at a lingering object that's poisoning the replication topology. This happens a lot after a failed DC demotion where the metadata wasn't cleaned up. Here's how to nuke it:

  1. Open Command Prompt as Administrator on a healthy DC.
  2. Type ntdsutil and hit Enter.
  3. Enter metadata cleanup.
  4. Select connections, then connect to server <healthy_DC_FQDN>.
  5. Type quit to go back.
  6. Run select operation target.
  7. List sites, servers, and the offending DC. Remove it with remove selected server.

Alternatively, if you're sure the DC is dead for good, just delete its object from Active Directory Users and Computers and force replication across the domain. Use repadmin /syncall /AdeP again to push the change.

Still seeing 0xC00002A1? Check for schema mismatches:

repadmin /showattr . "CN=Schema,CN=Configuration,DC=<domain>,DC=<tld>" > schema1.txt

Compare schema on two DCs. If they differ, run adprep /forestprep and adprep /domainprep on the schema FSMO holder.

One last thing: if you've just restored a DC from backup without forcing USN rollback protection, DEMOTE it via dcpromo /forceremoval (yes, that's a thing) and clean the metadata manually. Then re-promote it. I've fixed dozens of 0xC00002A1 cases this way — it's brutal but it works.

Pro tip: After any of these fixes, run dcdiag /test:replications /v to verify replication is healthy. If you see lingering object warnings, schedule a tombstone cleanup:

ntdsutil
metadata cleanup
connections
connect to server <DC>
quit
select operation target
list domains
select domain 0
list sites
select site 0
list servers for site 0
select server 0
quit
remove selected server

Then force a garbage collection cycle:

repadmin /options +DISABLE_OUTBOUND_REPL
repadmin /replicate <source_DC> <dest_DC> DN= "CN=Schema,CN=Configuration,..."
repadmin /options -DISABLE_OUTBOUND_REPL

That clears out orphaned attributes that trigger 0xC00002A1. If you still see the error after all this, you've got a deeper problem — check your backup software is using VSS and not raw file copy. But 95% of the time, one of these three steps fixes it.

Was this solution helpful?