Fix ERROR_DS_UNWILLING_TO_PERFORM (0X00002035) on Windows Server

Lingering Objects — the #1 Cause

What's actually happening here is the target domain controller holds an object that the source DC thinks should be there, but the source DC's tombstone lifetime has expired for it. The source DC says 'I can't touch that — it's dead to me.'

This usually happens after a DC has been offline for longer than the tombstone lifetime (default 60–180 days, depending on OS version). When it comes back, it tries to replicate a renamed or deleted object, and the receiving DC refuses because the object's metadata is stale.

How to find lingering objects

1. Open an admin PowerShell or CMD on the problematic DC.
2. Run repadmin /removelingeringobjects <DC_NAME> <Naming Context> /advisory_mode. For example:

   repadmin /removelingeringobjects DC01 "DC=contoso,DC=com" /advisory_mode

3. Review the output. If it lists objects, you've got a lingering object problem.

The fix

Run the same command without /advisory_mode:

repadmin /removelingeringobjects DC01 "DC=contoso,DC=com"

You'll need to do this on every DC that has the objects. The command removes them from the local DC's database — it doesn't replicate the deletion, so it's safe. Reason step 3 works: repadmin forces the DC to accept that the source DC holds the authoritative version of the directory partition.

If you're dealing with many objects, script it:

repadmin /removelingeringobjects * "DC=contoso,DC=com"

Time Skew — More Than 5 Minutes Off

Kerberos relies on time synchronization. If a DC's clock is off by more than 5 minutes from the rest of the domain, it will refuse to process certain requests. The error code is the same: 0X00002035.

I've seen this when someone rebuilt a DC from a snapshot without running usn-rollback checks, or when a VM host's time sync service interferes with the domain's NTP hierarchy.

Check the time

Run on the problematic DC:

w32tm /query /status

The fix

1. Force resync:

   w32tm /resync /nowait

2. If that fails, reconfigure to sync with the PDC emulator:

   w32tm /config /manualpeerlist:<PDC_EMULATOR> /syncfromflags:manual /reliable:yes /update

3. Restart the service:

   net stop w32time && net start w32time

Repeat the check. You should see the time source as the PDC emulator and the offset under 5 minutes. The domain won't complain after that.

Stuck Replication or USN Rollback

When replication gets stuck — often from a DC being restored from backup or snapshot — the USN (Update Sequence Number) vector gets out of sync. The result: the DC sees updates that claim to come from a future USN state and refuses to process them.

This one's harder to spot. You'll see error 0X00002035 in repadmin output alongside USN rollback warnings.

Diagnose

repadmin /showrepl

Look for 'Last success' timestamps that are days old and 'Last failure' with 0X00002035. Also check the event log for NTDS event IDs 2095 (USN rollback detection).

The fix

If you've confirmed USN rollback, the only reliable fix is to demote and re-promote the DC. Don't try to force replication — you'll corrupt the database.

1. Run dcpromo /forceremoval (or Server Manager > Remove Roles and Features) on the offending DC.
2. Clean up metadata on another DC:

   ntdsutil \"metadata cleanup\" \"remove selected server\" \"DC=contoso,DC=com\" \"quit\"

3. Re-promote the DC. It will get a fresh USN vector from an existing DC.

I know demoting a DC sounds drastic. But USN rollback is one of those problems where any attempt to 'fix' it in-place makes things worse. Trust me, I've tried.

Quick-Reference Summary

One more thing: if none of these fit, check the schema version on the DCs. Mismatched schema versions can also trigger 0X00002035 when a newer schema operation is attempted on an older DC. Run adprep /forestprep on the schema master if you're mixing OS versions.