Error 0x213A: Can't Change Primary Group ID on a DC

I know this error is infuriating. You're in ADUC, you right-click a user, try to set their primary group, and Windows throws ERROR_DS_CANT_MOD_PRIMARYGROUPID (0x213A) in your face. Nine times out of ten, you're trying to change the primary group of a domain controller account. Windows flat-out forbids it.

Why? Because a domain controller's primary group is hardwired to Domain Controllers (RID 516). The operating system uses that membership for replication, Kerberos, and a bunch of internal plumbing. Letting an admin reassign it would break the DC's ability to function. So the directory blocks the write with 0x213A before it even hits the database.

Cause 1: You're targeting a domain controller account (most common)

This is the one that trips up 95% of folks. You've got a user object that looks normal in ADUC — maybe named DC01$ or a computer account someone converted — and you try to set its primary group to Domain Admins, Enterprise Admins, or something custom. Windows refuses.

Check the primaryGroupID attribute first. Open PowerShell as a domain admin:

Get-ADObject -Filter {objectClass -eq "user" -or objectClass -eq "computer"} -Properties primaryGroupID,sAMAccountName,userAccountControl |
  Where-Object { $_.sAMAccountName -like "*$" -or $_.userAccountControl -band 0x2000 } |
  Select-Object sAMAccountName, primaryGroupID, userAccountControl

If primaryGroupID comes back as 516 and the account name ends in $, you've found your culprit. The fix isn't to change the primary group — it's to stop trying. If you need that account to have additional rights, add it to the target group as a secondary member. Don't touch the primary group.

Now, the exception: if someone accidentally promoted a regular user account to a DC, or you've got a stale DC object that was never cleaned up, you can demote it properly with Uninstall-ADDSDomainController or dcpromo on older systems. Once it's no longer a DC, the primary group becomes editable. Just don't hack the attribute directly with Set-ADObject — that leaves metadata inconsistencies that'll bite you during the next replication cycle.

Real-world trigger: A helpdesk tech clones a user template that was originally a DC account back in 2012, then tries to set its primary group to a custom role group. Boom — 0x213A. The template still has the SERVER_TRUST_ACCOUNT bit set.

Clear that bit if the account truly isn't a DC anymore:

$uac = (Get-ADUser 'oldDC$' -Properties userAccountControl).userAccountControl
$uac = $uac -bxor 0x2000  # remove SERVER_TRUST_ACCOUNT
Set-ADUser 'oldDC$' -Replace @{userAccountControl=$uac}

Then set the primary group. Be careful — only do this if you're 100% sure the box is decommissioned.

Cause 2: You're editing a read-only domain controller (RODC)

RODCs have additional restrictions on the primaryGroupID attribute. Even if the object looks like a regular user, if it's tied to an RODC — or the account itself is hosted on a writable DC but you're trying to modify it via an RODC's LDAP endpoint — you'll get 0x213A. The write is blocked because the RODC can't replicate primary group changes upward by design.

Verify which DC you're connected to:

nltest /dsgetdc:yourdomain.com

If it's pointing at an RODC, force ADUC or your PowerShell session to target a writable DC:

Set-ADUser -Identity username -Server DC01.yourdomain.com -Replace @{primaryGroupID=513}

513 is Domain Users, the default. If that works, you were hitting an RODC. If it still fails against a writable DC, the object itself is likely RODC-filtered or marked read-only in the schema.

Also check the msDS-RevealedUsers and msDS-NeverRevealedUsers attributes on the RODC. If the user's credentials were never revealed to that RODC, the DC won't let you touch security-sensitive attributes.

Cause 3: Schema-level restrictions or a botched custom class

Rare, but I've seen it. Someone extends the schema with a custom object class that inherits from user or computer, then marks primaryGroupID as a system-only attribute in a way that breaks normal modification. Or they set systemFlags on the attribute schema to something that prevents writes from anything but the system.

Check it with ADSI Edit (CN=Primary-Group-ID,CN=Schema,CN=Configuration,DC=yourdomain,DC=com). Look at systemFlags. A value of 16 (FLAG_ATTR_NOT_REPLICATED) or 1 (FLAG_ATTR_IS_CONSTRUCTED) shouldn't be there for this attribute. Legit value is typically 0 or 16 combined with other flags, but not the constructed bit.

If you find systemFlags misconfigured, you're looking at a schema change that needs to be reverted. Use ldifde to export the previous state from a backup, or restore the schema partition from a system state backup. Do not hand-edit schema attributes in production without a tested rollback path. I've watched a junior admin brick an entire forest doing exactly that.

A less scary variant: group nesting depth. If the target group is nested more than 20 levels deep (unusual but possible in legacy environments), the write can fail with 0x213A because the directory can't resolve the effective primary group. Flatten the nesting.

Quick reference

The short version: if it's a DC, walk away — the error is doing its job. If it's not, check which DC you're talking to and whether the schema's been tampered with. 0x213A is almost never a bug. It's the directory saying no, you really don't want to do that.