0X00002149

Fix ERROR_DS_HAVE_PRIMARY_MEMBERS (0X00002149) in AD

Cybersecurity & Malware Intermediate 👁 0 views 📅 May 29, 2026

This error pops up when you try to convert a security group with primary members to a distribution group. The fix is to clear the primary group attribute first.

Quick answer: Use ADSISearch or PowerShell to find and clear the primaryGroupId attribute on all members of the group before retrying the group type change.

This error — ERROR_DS_HAVE_PRIMARY_MEMBERS — shows up when you try converting a security-enabled group to a security-disabled (distribution) group in Active Directory. The catch is that some of the group's members have this group set as their primary group. Windows won't let you flip the security switch while those references exist. I've seen this most often with domain local groups that got used as primary groups for user accounts in older AD setups, or after migrations where group nesting got messy. The dialog just says "A group with primary members cannot change to a security-disabled group" and leaves you hanging.

The fix is straightforward: you need to identify which members point to this group as their primary group, clear that attribute on them, then retry the conversion. You don't need to remove the members from the group — just unset the primary group flag.

Step-by-step fix

  1. Identify the group's Distinguished Name (DN). Open adsiedit.msc and browse to the group. Right-click it, choose Properties, and copy the distinguishedName value. It'll look like CN=MyGroup,OU=Groups,DC=contoso,DC=com.
  2. Find all members with this group as primary. In PowerShell (run as admin), use this command:
Get-ADUser -Filter {PrimaryGroup -eq 'CN=MyGroup,OU=Groups,DC=contoso,DC=com'} -Properties PrimaryGroup | Select-Object Name, DistinguishedName

Replace the DN with yours. This lists every user whose primaryGroupId matches the group's RID. If you get no results, check groups too — computer accounts and even other groups can have a primary group set. Run this for computers:

Get-ADComputer -Filter {PrimaryGroup -eq 'CN=MyGroup,OU=Groups,DC=contoso,DC=com'} -Properties PrimaryGroup | Select-Object Name, DistinguishedName
  1. Clear the primary group on each affected object. For each user found, run:
Get-ADUser -Identity 'username' | Set-ADUser -Replace @{primaryGroupId=513}

The value 513 is the default Domain Users group RID. For computers, use 515 (Domain Computers). This shifts their primary group back to the domain default without removing them from the original group.

  1. Verify the change. Re-run the search from step 2. You should see zero results now.
  2. Convert the group. Right-click the group in AD Users and Computers, choose Properties, go to the General tab, and uncheck "Security". Or use PowerShell:
Set-ADGroup -Identity 'MyGroup' -GroupScope Universal -GroupCategory Distribution

Alternative fixes if the main one fails

If PowerShell returns nothing but the error persists, the primary group reference might be held by an object that's outside your search scope — like a deleted object or one in a protected container. Here's what to try:

  • Use ADSI Edit directly. Connect to the Configuration partition (or Domain partition), browse to CN=Deleted Objects, and check if a tombstone object still references your group as primary. You'll need to set the showDeletedObjects attribute to true in ADSI Edit to see these. If you find one, you can't undelete it, but you can purge it with Remove-ADObject -Identity 'DN' -IncludeDeletedObjects.
  • Check for foreign security principals. If your domain trusts others, a member from a trusted domain might have this group as primary. Use Get-ADObject -Filter {ObjectClass -eq 'foreignSecurityPrincipal'} and inspect the primaryGroupId attribute on each.
  • Last resort: demote and promote a DC. This is nuclear. If a lingering object in database replication is holding the reference, demoting a domain controller that holds the master copy, cleaning up metadata, then promoting it back can flush the ghost. Only do this if you're absolutely sure all other options failed and you have a backup of AD.

Prevention tip

Don't let service accounts or delegated user accounts have their primary group set to anything other than Domain Users or Domain Computers. It's a legacy NT4 thing that causes headaches. Audit your environment quarterly with a script that lists all objects where primaryGroupId is not 513 or 515. Catch these before you try any group conversion.

Was this solution helpful?