Active Directory Schema Move Error 0X00002184 Fix

1. You're trying to move an object inside the Schema Naming Context

This error trips up IT pros who've worked with AD for years. You're running some script or tool that tries to move an object—maybe a class or attribute—within the schema partition (CN=Schema,CN=Configuration,DC=...). And boom: 0X00002184.

Here's the thing: the Schema NC isn't like your Users or Computers containers. Microsoft designed it as a static, ordered tree. Moving objects around inside it would break class hierarchy and attribute references. So the directory service flatly refuses. The error code ERROR_DS_NO_OBJECT_MOVE_IN_SCHEMA_NC is the result.

Most common trigger? An old VBScript or PowerShell script that uses [ADSI] with MoveHere against a schema object. Or third-party AD management tools that try to reorganize schema classes.

What to do instead

1. Identify the exact object class or attribute you need to move.
2. You can't move it—period. But you can deactivate it and create a new one with the desired naming and location. Schema objects support deactivation by setting showInAdvancedViewOnly or modifying isDefunct.
3. If you're trying to change the object's placement in the hierarchy (like moving an auxiliary class to a different container), don't bother—the schema is flat. All class and attribute objects live under the Schema NC root. Microsoft doesn't support nesting.

# This won't work—expect 0X00002184
$schemaPath = "LDAP://CN=Schema,CN=Configuration,DC=contoso,DC=com"
$adsi = [ADSI]$schemaPath
$adsi.MoveHere("LDAP://CN=myClass,CN=Schema,CN=Configuration,DC=contoso,DC=com", "CN=myRenamedClass")

Replace the move with a deactivation + re-creation approach. Or accept that the schema naming context is immutable.

2. Your move target is outside the schema NC—but the source is inside

Another scenario: you're trying to move a schema object into a different naming context (like CN=Users or CN=Computers). That's also a no-go. Schema objects belong exclusively to the Schema NC. You can't drag a class definition into an OU.

This happens when admins confuse static schema objects with dynamic directory entries. For example, someone copies a user class schema object and tries to move it into an organizational unit as a user account. That's mixing levels—LDAP won't allow it.

Correct approach

1. If you need a new user account, create it in the appropriate OU using New-ADUser or the ADUC console.
2. If you need to modify the schema class itself, edit the schema definition—don't move the schema object.
3. Use ntdsutil or ldifde to export the class, modify it, and re-import.

# Export schema class to LDIF
ldifde -f schema_user.ldf -d "CN=User,CN=Schema,CN=Configuration,DC=contoso,DC=com"

3. Your application or script is using an older ADSI version that misbehaves

I've seen this on Windows Server 2008 R2 and 2012 boxes running ancient scripts. The ADSI provider in those older OS versions sometimes sends malformed move requests to the schema NC—even when you think you're targeting a different NC. The result is 0X00002184.

The fix here isn't about AD design but about tooling.

Steps to resolve

1. Update your ADSI version. On Windows Server 2016 or later, ADSI is built-in and stable. If you're still on 2008 R2, upgrade.
2. Rewrite the script using PowerShell Active Directory module cmdlets (Move-ADObject). These cmdlets validate the target NC and refuse schema moves gracefully.
3. If you must use ADSI, explicitly bind to the target container outside the schema NC, and pass the source object's distinguishedName as a string—not an ADSI object.

# Safe approach with AD module
Move-ADObject -Identity "CN=myUser,CN=Users,DC=contoso,DC=com" -TargetPath "OU=Employees,DC=contoso,DC=com"

Only use Move-ADObject on objects outside the Schema NC. Inside it? No dice.

Quick-reference summary

This error is one of those "it's not a bug, it's a feature" situations. Once you know the schema NC is read-only for moves, you stop fighting it. Work around it, and move on.