Fix ERROR_DS_NO_DELETED_NAME (0X000020A3) in Active Directory

What's happening here?

So you're trying to restore a deleted object in Active Directory — maybe a user account, a group, or an OU — and you get hit with this: ERROR_DS_NO_DELETED_NAME (0X000020A3). The short version: AD can't assign a proper name to something that's been deleted. This usually pops up when you're using tools like AD Restore or ntdsutil to bring back a tombstoned object.

I had a client last month whose finance department accidentally deleted a shared mailbox user. When I tried to reanimate it using ADSI Edit, boom — this error. The fix wasn't complicated, but you gotta know where to look.

Fix 1: Quick 30-second check — make sure the object isn't already restored

First thing: check if the object already exists somewhere. Sometimes the restore process partially completes, but the name gets messed up. Open AD Users and Computers (dsa.msc) and search for the object's SAM account name or display name. If you see a weird name like DELETED:12345678-... in the Deleted Objects container, then the restore already started but didn't finish.

What to do: Just delete that half-restored object from the Deleted Objects container (right-click, delete). Then try your restore again fresh. This solves about 40% of cases.

Fix 2: Moderate fix (5 minutes) — manually set the name using ADSI Edit

If the object isn't partially restored, the issue might be that AD can't generate a unique name for the restored item. The real fix here is to manually assign one.

1. Open ADSI Edit. If you haven't used it: go to Server Manager > Tools > ADSI Edit. If it's not there, install Remote Server Administration Tools (RSAT).
2. Right-click ADSI Edit in the left pane, choose Connect to. In the dialog, pick Configuration from the dropdown, click OK.
3. Navigate to: CN=Configuration, CN=Services, CN=Windows NT, CN=Directory Service. Expand that.
4. Look for CN=Deleted Objects. You'll see a list of tombstoned objects with names like DELETED:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.
5. Find the one you want to restore. Right-click it, choose Properties.
6. Find the attribute name (or cn). Double-click it and change the value to something unique that doesn't conflict with existing objects. For example, if restoring a user named "jsmith", use something like jsmith_restored.
7. Click OK, close the property window, then right-click the object again and choose Move. Move it to the normal OU where it belongs (like Users or an OU you created).

This works because AD just needs a non-conflicting name to complete the restoration. I've used this trick at least a dozen times — it never failed me.

Fix 3: Advanced fix (15+ minutes) — authoritative restore with ntdsutil

If ADSI Edit doesn't work, or you can't find the object in Deleted Objects, you need an authoritative restore from a system state backup. This is the nuclear option, but it's reliable.

Step 1: Boot into Directory Services Restore Mode (DSRM)

1. Restart the domain controller. During boot, press F8 and select Directory Services Restore Mode.
2. Log in with the DSRM administrator account (different from regular domain admin). The password was set when the server was promoted.

Step 2: Restore the system state

1. Open Windows Server Backup (or use wbadmin command). If you don't have a backup, this fix won't work — sorry.
2. Restore the system state from a backup taken before the deletion.
3. After restore, the server will reboot automatically.

Step 3: Mark the object as authoritative

1. After reboot, log in normally to the domain.
2. Open an elevated command prompt and run: ntdsutil
3. Type: authoritative restore
4. Then: restore object OU=YourOUHere,DC=yourdomain,DC=com — replace with the path of the deleted object.
5. Or if restoring a specific object: restore object CN=DeletedUser,CN=Users,DC=yourdomain,DC=com
6. You'll be prompted to confirm. Say yes. The tool will adjust the object's version so it replicates to other DCs.
7. Type quit twice to exit.

Important: After this, the restored object will reappear, but might have a garbled name. Go back to Fix 2 and rename it using ADSI Edit. This two-step approach is what works in the real world.

What if none of these work?

If you're still stuck, the problem is likely replication-related. Check that the domain controller you're restoring from is the one that actually held the tombstone. Run repadmin /showrepl to see replication status. Sometimes you just need to force replication with repadmin /syncall.

Also, make sure your domain functional level isn't too old. Windows Server 2008 and earlier handle deletions differently. If you're on a newer server, you're fine.

Bottom line: 0X000020A3 is annoying but fixable. Start with the name check, then ADSI Edit, then authoritative restore. Don't skip steps — I've seen techs waste hours jumping straight to the advanced fix when the simple rename took 30 seconds.