Fix ERROR_DS_CANT_CREATE_IN_NONDOMAIN_NC (0X00002169)

You're trying to create a security principal (user, group) in a non-domain NC partition. Active Directory won't let you — security objects live only in domain NCs.

Quick Answer

Create the security principal in a domain naming context (e.g., DC=domain,DC=com) — not in a configuration, schema, or application partition. Use ADSI Edit or PowerShell to move it.

Why This Happens

Active Directory stores objects in partitions called naming contexts. Domain NCs hold security principals — users, groups, computers. Non-domain NCs (Configuration, Schema, or application partitions) can't hold these. The error 0X00002169 pops up when you or a script tries to write a security principal to a partition that doesn't support it.

I see this most often when someone uses ADSI Edit and accidentally picks the wrong container — usually CN=Configuration,DC=... or CN=Schema,CN=Configuration,DC=... instead of the actual domain container. Also happens with poorly written scripts that hardcode LDAP paths pointing to Configuration partition.

Fix Steps

Identify where you're trying to create the object.
Open ADSI Edit. Connect to the partition you're targeting. Check the distinguishedName of the container. If it starts with CN=Configuration or CN=Schema, you're in the wrong place.
Verify the partition type.
Run this in PowerShell:
```
Get-ADObject -Filter * -SearchBase 'CN=Partitions,CN=Configuration,DC=domain,DC=com' -Properties nCName,trustNC | Format-Table nCName,trustNC
```
Look for the partition where you're creating the object. If its trustNC property isn't true, it's not a domain NC.
Move or recreate in the correct domain NC.
If you already created an object in the wrong partition (some apps do this), export it, delete it, and re-import into the domain NC. Example using LDIFDE:
```
ldifde -f export.ldf -d 'CN=WrongContainer,CN=Configuration,DC=domain,DC=com'
# Edit the .ldf file — change the DN to a domain container like CN=Users,DC=domain,DC=com
ldifde -i -f export.ldf
```
Check the script or app configuration.
Look for hardcoded LDAP paths. Common culprit: a service account creation script that uses LDAP://CN=Computers,CN=Configuration,... instead of LDAP://CN=Computers,DC=domain,DC=com.

Alternative Fixes

Use a different tool. If ADSI Edit gives you trouble, try Active Directory Users and Computers. It only shows domain NCs — you can't accidentally create in the wrong partition.
Check replication. Rarely, a lingering object from a partial replication lands in a non-domain NC. Run repadmin /rehost to force replication of the offending partition.
Review application partitions. Some apps create custom partitions (e.g., DC=App,DC=domain,DC=com). If you're targeting one of those, change the app to use the default domain NC instead.

Prevention

Stop using ADSI Edit as your daily driver for creating security principals. Use ADUC or PowerShell with explicit domain context. Always specify -Server parameter in PowerShell cmdlets — New-ADUser -Server 'domain.com' -Path 'CN=Users,DC=domain,DC=com'. Train your junior admins to never guess LDAP paths. If you must use ADSI Edit, pin the domain NC root and work from there.

One more thing — if you're writing scripts, always test with a throwaway OU first. Nothing worse than bulk-creating 200 users in the Configuration partition and having to clean up the mess.