STATUS_DS_CANT_MOD_PRIMARYGROUPID Fix: Don't Touch That DC Account

What Just Happened?

You tried to change the primary group of a domain controller's computer account, and Active Directory slapped your hand with 0XC00002D0. This error is Active Directory's way of saying, "No, you don't. That account is sacred."

I've seen this trip up even seasoned admins. The typical trigger: you're cleaning up a group, or you accidentally select the DC's computer account in ADUC instead of a service account. Next thing you know, you're staring at an error that makes no sense because the Member Of tab doesn't even show a primary group field for DCs.

Here's the deal: Domain controllers have a hardcoded primary group ID of 516 (Domain Controllers). Windows won't let you change it intentionally—the error is your safeguard. But if you somehow got it changed via script or a tool that bypasses the UI, you could break that DC's ability to function. If you're reading this because you just hit the error and haven't changed anything, breathe. You're fine. If you're here because you did change it and now the DC is acting weird, the fixes below will get you back.

Fix 1: The 30-Second Undo (If You Haven't Actually Changed Anything)

If ADUC or PowerShell threw the error and didn't apply the change, you're already done. The error itself is the protection. Verify the primary group is still 516:

1. Open Active Directory Users and Computers (dsa.msc).
2. Enable Advanced Features from the View menu.
3. Right-click the DC's computer account → Properties → Attribute Editor tab.
4. Find primaryGroupID and confirm it says 516.

If it's 516, you're done. No further action needed. The error was a false alarm—you tried to change it, AD said no, and nothing got modified. Move on with your day.

Fix 2: The 5-Minute PowerShell Revert (If You Actually Changed It)

If you bypassed the protection—maybe you used ADSI Edit or a script that set primaryGroupID directly—and now the DC is showing odd behavior (like not getting group policy or Kerberos failures), you need to set it back to 516. Here's the fastest way using PowerShell, from a domain-joined machine (not the DC itself, if possible):

# Run as Domain Admin
Get-ADComputer -Filter "Name -eq 'YOUR-DC-NAME'" | Set-ADComputer -Replace @{primaryGroupID=516}

Replace YOUR-DC-NAME with the actual hostname. If you don't know the name, run Get-ADComputer -Filter * | Select Name first.

If the DC is completely broken and you can't reach it via standard LDAP, you can still do this with ntdsutil in Directory Services Restore Mode (DSRM)—but that's rare. Try the PowerShell route first; it almost always works.

Fix 3: The 15-Minute Classic: ADSI Edit (When PowerShell Isn't Available)

No PowerShell module? Maybe you're on a machine without RSAT, or the AD module isn't loaded. ADSI Edit is your friend. It's the old-school way, but it gets the job done.

1. Install ADSI Edit if it's not already: Install-WindowsFeature RSAT-ADDS-Tools (Server) or add it via Features on Windows 10/11.
2. Open ADSI Edit (adsiedit.msc).
3. Right-click ADSI Edit → Connect to → choose Default naming context.
4. Drill down: Domain NC → DC=yourdomain,DC=com → CN=Computers → CN=YOUR-DC-NAME.
5. Right-click the DC account → Properties.
6. Double-click primaryGroupID, change it to 516, and click OK.

That's it. It might take a few minutes for replication to catch up, but the change will stick. I've done this on Server 2016 and 2019, and it works every time.

Why This Error Is Actually Your Friend

I get it—errors are annoying. But this one is a guardrail. Changing a DC's primary group to something like 513 (Domain Users) or a custom group would break Kerberos ticket acquisition for the DC itself. That DC would stop being able to authenticate as a domain controller, and domain trusts would fall apart. You'd be in for a long night.

So when you see 0XC00002D0, take it as a win. Someone coded that protection because they knew someone would eventually click the wrong thing. Today, that someone was you. Tomorrow, it'll be someone else. And now you know how to fix it when they panic.

Still Stuck?

If you've tried all three and the DC still shows a wrong primary group, check replication health. Use repadmin /replsummary to spot any outbound replication failures. If replication is broken, your change might be stuck on a lingering object. In that case, force replication with repadmin /syncall /AdeP and re-check.

Also—if you changed the primary group on a non-DC server account, the fix is the same, but the default should be 513 (Domain Users). The error only fires for DCs because they're special. So if you hit this on a regular server, you're trying to do something that AD doesn't allow, and the revert is the same.

You've got this. The error's scary, but the fix is simple. Go save your DC.