What’s Going On With 0X00002084?
You're trying to remove an attribute from an Active Directory object, maybe through a script or a management tool, and you get this: ERROR_DS_CANT_REM_MISSING_ATT (0X00002084). Translation: the attribute you're trying to delete isn't actually on the object. But you know it should be, or you're getting it from a tool that insists it's there.
I had a client last month – a small law firm with a single DC running Server 2016. Their onboarding script kept failing for a new user, throwing this exact error. Turned out a stale replication from a former DC had left a phantom attribute entry in the schema cache. The fix was straightforward once we understood the root cause.
Here's the practical flow. Try each step in order. Stop when the error disappears.
30-Second Fix: Refresh the Attribute View
This sounds too simple, but it works about 20% of the time. Sometimes the tool you're using – PowerShell, ADUC, or a custom app – is caching a stale attribute list. Just refresh the connection.
- Open Active Directory Users and Computers (or your management console).
- Right-click the domain name and select Refresh.
- Close and reopen the console.
- If you're using PowerShell, run
Get-ADObjectagain to re-fetch the object's properties.
If the error sticks around, move to the next step.
5-Minute Fix: Check Attribute Presence with ADSI Edit
You need to verify the attribute actually exists on the object. ADSI Edit is the tool for this – it’s installed by default on domain controllers, but you might need to enable it in Server Manager → Tools.
- Open ADSI Edit.
- Connect to the domain: right-click ADSI Edit, choose Connect to... , and select your domain.
- Navigate to the object that's throwing the error. For a user, expand Domain NC → CN=Users → find the user.
- Right-click the object, select Properties.
- In the Attribute Editor tab (if it's not there, check View → Attributes), scroll to the attribute name from the error.
- If the attribute is present, you can delete it manually: select it, click Remove. But if it's grayed out or missing entirely, the error is accurate – there's nothing to delete.
If the attribute is missing, your tool is mistaken. Stop trying to remove it. But if you know it should be there (like after a schema update), you might have a replication issue.
15-Minute Fix: Repair Replication and Schema Cache
This is for the deeper cases where the attribute exists in the schema but is stuck in a ghost state. Common triggers: you removed a DC without proper demotion, or you ran a schema update that didn't propagate.
Step 1: Check Replication Status
Run this on the DC where the error occurs:
repadmin /replsummary
Look for any failures in the last 24 hours. If you see replication errors, fix those first. Common cause: the DC can't reach its replication partner. Check DNS and network connectivity.
Step 2: Force Replication
On the problematic DC, run:
repadmin /syncall /AdeP
This forces a full replication cycle. Wait for it to complete – it might take a few minutes.
Step 3: Clear the Schema Cache
The schema cache can hold onto attribute definitions that no longer exist. To reset it:
- Open a command prompt as Administrator.
- Stop the AD DS service:
net stop ntds - Wait 30 seconds, then start it:
net start ntds
This forces a schema cache refresh. If that doesn't work, you can also restart the Active Directory Domain Services service from the Services console.
Step 4: Authoritative Restore (Nuclear Option)
If the attribute is critical and still missing after replication, you might need an authoritative restore from a backup. Only do this if you have a verified backup from before the issue started. I've only had to do this twice in 15 years – it's rare.
- Reboot the DC in Directory Services Restore Mode (DSRM).
- Run
ntdsutiland use the authoritative restore option to restore the object. - Reboot normally. The object's attributes will be restored from the backup.
This is heavy. Only use it if the attribute is business-critical and nothing else worked.
When to Give Up and Recreate the Object
Sometimes the cleanest fix is to delete the object and recreate it. I'm serious – if the attribute is gone and your tool won't stop yelling about it, just create a new user, group, or computer. Move any group memberships manually. It's faster than chasing ghost attributes across all your DCs.
But always check replication first. I've seen a single DC with bad replication cause this error for weeks because nobody thought to check repadmin.
Pro tip: If you're scripting attribute removals, always check existence first with
Get-ADObject -Properties *before trying to delete. It saves you from staring at 0X00002084 at 2 AM.