Fixing ERROR_DS_NCNAME_MUST_BE_NC (0X000020A5)
This error means you're trying to create or move an Active Directory object to a location that isn't a valid naming context. The fix is usually a typo in the distinguished name or a missing domain prep.
You're getting ERROR_DS_NCNAME_MUST_BE_NC (0X000020A5) — which translates to "The object must be a naming context". What's actually happening here is that the system expects a naming context (a partition root like DC=domain,DC=com), but you gave it a regular object path (like CN=Users,DC=domain,DC=com).
This happens most often when you're using a tool like ntdsutil, ADSI Edit, or a PowerShell cmdlet like Move-ADObject or Rename-ADObject. The tool expects the target container to be a naming context — basically a top-level partition that AD replicates independently — not just any folder.
Cause 1: You passed a full DN instead of a naming context
The most common trigger: you typed something like CN=Users,DC=contoso,DC=com where the tool wanted just DC=contoso,DC=com. This happens constantly when people use ntdsutil commands to list or move objects between partitions.
The fix: Identify the correct naming context for your domain. Run this in PowerShell as admin:
Get-ADRootDSE | Select-Object namingContextsYou'll see output like:
namingContexts
--------------
{DC=contoso,DC=com, CN=Configuration,DC=contoso,DC=com, CN=Schema,CN=Configuration,DC=contoso,DC=com, DC=DomainDnsZones,DC=contoso,DC=com...}Pick the right one. If you're moving a user from one domain to another in a multi-domain forest, you need the target domain's naming context — DC=child,DC=contoso,DC=com, not CN=Users,DC=child,DC=contoso,DC=com.
In ntdsutil, the command list naming contexts inside the partition management context will show all available partitions. The error fires because you gave it a path that doesn't match any of those.
Cause 2: You're trying to create a cross-ref object with a bad DN
Cross-reference objects (used for application partitions) require their nCName attribute to point to a valid naming context root. If you're using ADSI Edit to manually create a crossRef under CN=Partitions,CN=Configuration,DC=contoso,DC=com and set nCName to something like OU=Apps,DC=contoso,DC=com — that's not a naming context. It must be a domain or application partition root.
The fix: Use ntdsutil properly to create application partitions. Don't hand-edit crossRef objects unless you know exactly what you're doing. The right command sequence:
ntdsutil
partition management
list naming contexts
create NC OU=Apps,DC=contoso,DC=com \\server2.contoso.com
The last parameter is the server that'll host the partition. If you get the error there, it's because the DN you gave doesn't start with a naming context from an existing domain. The rule: every naming context must be a child of an existing naming context root or a new partition root like DC=Apps if you're building a cross-forest partition.
Cause 3: Renaming or moving objects across naming contexts incorrectly
Let's say you're using Move-ADObject to shift a user from one domain to another. The cmdlet's -TargetPath parameter expects a naming context, not a container path. If you write:
Move-ADObject -Identity "CN=John Doe,OU=Users,DC=old,DC=com" -TargetPath "CN=Users,DC=new,DC=com"
You'll get this error. The reason step 3 works is that -TargetPath must be a naming context — the destination domain's DC=new,DC=com. The move operation then places the object in the default container of that domain.
The fix: Change the command to:
Move-ADObject -Identity "CN=John Doe,OU=Users,DC=old,DC=com" -TargetPath "DC=new,DC=com"
If you need the object in a specific OU after the move, do a second Move-ADObject within the target domain.
Quick Reference
Cause What you gave What it needs Fix Wrong DN in ntdsutil / ADSI Edit CN=Users,DC=domain,DC=comDC=domain,DC=com (or another partition root)Use Get-ADRootDSE to list naming contexts CrossRef with non-root DN OU=Apps,DC=domain,DC=comA DN that starts a new partition Use ntdsutil create NC instead of manual ADSI Edit PowerShell Move-ADObject CN=Users,DC=domain,DC=comDC=domain,DC=comPass the domain root as -TargetPath
One last thing: if you're working in a multi-domain forest and trying to move objects between domains, remember that cross-domain moves require the target naming context to be a domain partition, not a configuration or schema partition. The error code doesn't distinguish — it just says "this isn't a naming context at all." Check your DN against the list from Get-ADRootDSE every time.
Was this solution helpful?