Fix ERROR_DS_CANT_MOD_OBJ_CLASS (0X00002017) in Active Directory

This error is a brick wall when you're trying to reclassify an AD object, like turning a computer object into a user object. It's frustrating because the tool just says 'nope' and won't tell you why. Here's how to get past it.

The Direct Fix: Delete and Recreate

AD won't let you change the objectClass attribute on an existing object. That's a design limitation — it's not a bug. The quickest way around it is to delete the object and create a new one with the correct class. I've done this dozens of times for clients who accidentally created a computer object instead of a user. Here's the step-by-step:

1. Open Active Directory Users and Computers (or ADSI Edit if you're feeling brave).
2. Right-click the object and select Delete. Make sure you have a backup of its attributes (like SID or group memberships) if that matters.
3. Create a new object of the correct type using the same name and GUID if needed. For a user, right-click the OU -> New -> User.
4. Reapply any group memberships or permissions manually.

Had a client last month who spent two hours trying to modify a printer object into a shared folder object. Deleted it, recreated it, done in 10 minutes.

Why This Worked

The objectClass attribute is structural — it defines the object's schema type. AD uses it to enforce rules about what attributes are allowed. Once an object exists, changing its class would break AD's internal consistency. The system flags this with 0x00002017 and refuses the change. No amount of permission tweaks or ADSI Edit magic will bypass it because it's a core schema constraint.

Less Common Variations and Workarounds

Variation 1: You Can't Delete the Object

If the object is protected — like a built-in security principal — you can't delete it either. In that case, you're stuck. The only option is to script a new object with the same name and disable the old one. Use PowerShell to export attributes:

Get-ADObject -Identity "CN=OldObject,OU=Stuff,DC=domain,DC=com" -Properties * | Export-Clixml -Path "backup.xml"

Then recreate manually with those attributes, leaving the old object disabled.

Variation 2: You Need the Same GUID

If the object is referenced by a third-party app via its GUID, you can set the GUID on the new object. Use Set-ADObject -Identity "new" -Replace @{objectGUID="old-guid-here"} right after creation but before any replication kicks in. I've done this for Exchange servers that freak out when a mailbox's GUID changes.

Variation 3: Bulk Reclassifications

Got 50 objects that need to change class? Write a script that loops through them, exports each one's attributes, deletes, and recreates. Use a CSV input file with the old DN and new class type. Be careful with SID history if you're in a migration scenario — SID history won't transfer.

Prevention Tips

• Double-check your object type before clicking OK in the creation wizard. This sounds obvious, but I've seen people rush through it and create 20 computer objects instead of users.
• Use templates. In AD Users and Computers, create a template user (disable it, set common attributes like department), then right-click and Copy to create new users. Prevents class mistakes.
• Audit your creation process. If someone keeps making the wrong class, check if they're using a script or tool that's hardcoding the objectClass.
• Consider using a provisioning tool like Adaxes or a simple PowerShell script that validates the class before creation.

Bottom line: don't waste time trying to force AD to do something it's architecturally designed not to do. Delete and recreate is the real fix — it's clean, it's permanent, and it respects how AD works.